¿Cómo asegurar la clave privada de su CA?

24

Estoy a punto de implementar mi propia Autoridad de Certificación (CA) solo para uso interno.

Ahora hay un problema, que la CA privada nunca debe ser explotada. Así que ahora la clave privada está encriptada.

¿Qué más se podría hacer para mejorar la seguridad de la clave privada?

security certificate-authority private-key JMW
fuente
¿Podemos obtener el sistema operativo en el que está ejecutando el servidor web? Probablemente podría establecer los permisos en el archivo para que nadie pueda leerlo, excepto la aplicación y el superusuario.
Rilindo
estamos ejecutando RHEL
JMW

Respuestas:

25

Trabajé en una empresa donde la seguridad de la clave de CA era crítica para el éxito continuo del negocio. Para este fin, la clave se cifró utilizando un protocolo personalizado que requería que al menos 2 personas estuvieran presentes con tokens físicos conectados a los terminales para descifrarlo (había al menos 5 de estos tokens, cualquiera de los 2 combinados funcionaría). Los terminales se separaron físicamente de la máquina real con la tecla CA. La interfaz que tenían los usuarios que lo descifraron era un terminal VT220 que les permitía ingresar los tokens de descifrado y luego seleccionar lo que querían 'firmar' con la clave (nunca dándoles acceso a la clave descifrada). Este sistema significaba que al menos 4 personas tendrían que trabajar juntas para comprometer la clave, dos titulares de tokens, el tipo que tenía acceso al centro de datos,

Si está interesado en obtener más detalles sobre este tipo de configuración, Bruce Schneier tiene un excelente sitio que cubre el diseño y la implementación de seguridad informática:

http://www.schneier.com/

También ha publicado un libro realmente bueno sobre Criptografía Aplicada que descubrí que me ayudó a comprender los fundamentos de sistemas como este y cómo diseñar infraestructuras más seguras (legibles para personas que no usan protectores de bolsillo):

http://www.schneier.com/book-applied.html

polinomio
fuente
2
Y la operación de dos teclas (o cualquier n de m, m> = n, n> 1) es otra precaución excelente, pero para mi dinero, primero el airgap y agregar refinamientos como este segundo, dependiendo de su grado de paranoia (es decir, El costo del fracaso).
MadHatter apoya a Monica el
1
¿Por qué la persona con acceso de root no puede volcar el contenido de la memoria en un archivo mientras dos personas autorizadas están haciendo su trabajo? Esto significa que el tipo con root puede obtener la clave solo con los recursos adicionales necesarios para eliminar el volcado de memoria de la máquina.
Slartibartfast
El control de acceso físico auditado es tan importante para este tipo de seguridad como el control de acceso lógico auditado. La operación de firma no debería requerir privilegios en el cuadro (ese control se maneja mediante el requisito any-n-from-m), por lo que el titular de la contraseña raíz no debería estar allí en absoluto cuando se inicia la firma de teclas. (S) será necesario para las actividades de mantenimiento del sistema, pero estas deben llevarse a cabo de acuerdo con un guión preescrito preciso, por alguien que no sea el guionista, y auditado en tiempo real por una tercera persona con conocimientos.
MadHatter apoya a Monica el
16

Una gran ganancia es mantener la clave CA privada en una computadora dedicada completamente desconectada de la red. Luego firmaría, y posiblemente también generaría, nuevos certificados en esta máquina, y luego usaría un medio físico para transferir los nuevos certificados fuera de la máquina CA.

Tal configuración, por supuesto, también incluiría consideraciones con respecto a la disponibilidad física de la máquina, así como restricciones en los medios permitidos. Una memoria USB bien transitada probablemente no sea la mejor opción ...

(Este es, por cierto, un ejemplo muy claro sobre la compensación entre seguridad y conveniencia).

andol
fuente
Airgap es una excelente precaución de seguridad, y el peligro de los medios extraíbles puede mitigarse configurando el cuadro de firma para no ejecutar automáticamente nada, permitir binarios SUID o de cualquier otra forma confiar en ejecutables en dichos medios.
MadHatter apoya a Monica el
Esto se puede optimizar aún más mediante el uso de una tarjeta inteligente para generar, almacenar y usar la clave. Piense en una tarjeta inteligente como una máquina dedicada que tiene algunas protecciones contra la manipulación (básicamente, el chip preferiría romperse antes que entregar la clave, lo cual es difícil de hacer con un sistema más complejo) y que tiene una interfaz lo suficientemente simple como para que la pila de protocolos podría haberse auditado correctamente.
Simon Richter
Secundo la sugerencia de la tarjeta inteligente, pero hay un riesgo allí. Cuando la clave solo puede estar en un lugar, solo una pieza de hardware debe fallar para que la clave sea inaccesible. Sin embargo, creo que una o más tarjetas inteligentes podrían formar una parte importante en una práctica segura de generación y almacenamiento de claves.
Slartibartfast
Sobre el tema de ejecución automática. En el caso de un administrador de archivos GUI, también puede ser aconsejable ser explícito acerca de que no intente hacer ninguna vista previa / miniaturas inteligentes de los archivos enumerados. Si bien no es un peligro en sí mismo, puede ser un vector de ataque a las vulnerabilidades existentes.
andol
Si la seguridad es realmente importante, iría con un montón de CD-R de escritura única.
Lie Ryan
15

He votado a favor de las otras dos respuestas y he comentado al respecto, porque creo que ambas son excelentes. Si usted decide ir a por los dos, y que bien podría ser el caso, yo fuertemente la atención asesorar en la generación inicial de la clave, ya que el mejor momento para poner en peligro una clave no está en uso (donde muchos estándar, precauciones repetibles pueden ser aplicado), pero en el momento de la generación, que es una oportunidad única es mucho más fácil de subvertir.

Esta excelente guía para llevar a cabo una ceremonia de generación de claves describe algunos de los protocolos estándar que pueden ayudar a asegurar la generación de claves, aunque en su mayoría se reducen a (a) tener todo presenciado por múltiples auditores expertos, que (b) están haciendo registros contemporáneos de todo lo que se hace (c) de acuerdo con un protocolo predeterminado escrito por alguien que no sea el ejecutor.

MadHatter apoya a Monica
fuente
Sí, buen punto sobre la generación de claves inicial.
andol
7

Dependiendo de lo serio que sea, debería considerar usar el hardware FIPS 140-2 ( http://en.wikipedia.org/wiki/FIPS_140#Security_levels ) para almacenar claves CA y copias de seguridad de esas claves. Debe tener una CA raíz y una CA intermedia para que pueda mantener su CA raíz fuera de línea y físicamente segura. La raíz solo es necesaria para renovar o firmar nuevas AC intermedias, mientras que las AC intermedias permanecen en línea para las operaciones diarias. Como otros han sugerido, la generación segura de claves y la gestión de claves con un control n of m es importante.

El CPS VeriSign (ahora Symantec) es una buena referencia de cómo una CA comercial genera y protege sus claves. Mire los capítulos 5 y 6, específicamente: http://www.verisign.com/repository/cps/ . (Trabajé en VeriSign durante varios años)

Además, NIST tiene varias buenas publicaciones sobre Key Management ( http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-57-Part1-Rev3_May2011.pdf ) y generación, y su empresa también debería tener un CPS que especifica las políticas y prácticas que utiliza para administrar su CA. El IETF proporciona una buena plantilla: http://www.ietf.org/rfc/rfc2527.txt

Sidra de pera
fuente
1

Gran pregunta y algunas excelentes respuestas también.

Tenga en cuenta que está aproximadamente un 90% por delante de la mayoría de las personas simplemente considerando este problema en lugar de cargar a ciegas.

Después de tener eso en mente y tomar el otro consejo aquí, simplemente agregaría: no descanses en tus laureles; Esté atento a las noticias de seguridad y criptografía tanto para problemas generales relacionados con la emisión de certificados, revocación, craqueo, etc. y más definitivamente sobre vulnerabilidades y problemas con los productos específicos que utiliza para generar y administrar sus claves.

Por último: seguridad física. Hacer algo 'a prueba de piratas informáticos' no ayuda si puedo conseguir un trabajo como limpiador por contrato en su edificio y luego poner el disco que contiene su certificado raíz en mi bolsillo algún día. Te sorprendería cuántas personas extrañan ese.

Rob Moir
fuente
Me alegra escucharlo @jmw: como dije, ya estás por delante del 90% o incluso del 99% de la mayoría de las personas, y parece que lo tienes todo en la mano. Te sorprendería la cantidad de personas que pasan semanas y toneladas de dinero mirando el lado del software sin hacer nada para proteger físicamente los datos.
Rob Moir
Gracias, tiene toda la razón: mantenerse informado sobre los nuevos riesgos es obligatorio para todos los administradores. :-) sobre seguridad física: el centro de datos, donde están nuestros servidores, tiene una alta seguridad física. por lo tanto, hay contraseñas bios && grub configuradas. la partición donde se almacena el material de CA también está encriptada. Además, la clave de CA está encriptada. Y nagios activaría alertas de "servidor inactivo" en caso de robo físico. Estoy más preocupado por las hazañas "no físicas". :-)
JMW