¿Debo cambiar la clave privada al renovar un certificado?

Diría que su sugerencia no es muy sólida, a menos que esté usando tamaños de clave horriblemente pequeños, en cuyo caso tiene un problema completamente diferente.

Una clave de 2048 bits, por mayoría de las estimaciones , lo mantendrá a salvo hasta al menos el año 2020, si no más que eso Si está ejecutando con claves de 1024 bits o menos, está por debajo del estándar y le recomiendo que actualice a 2048 bits de inmediato. Si actualmente está usando claves de 1536 bits, debe estar seguro por un año o dos.

Por supuesto, todo esto es académicamente hablando. La probabilidad de que alguien pueda (o se incline) descifrar su clave SSL de 1024 bits dentro de un año es extremadamente baja.

Como se mencionó en la pregunta que vinculó, existen ventajas e inconvenientes.

Beneficios

• Le da a un atacante menos tiempo para descifrar la clave. Algo así como un punto discutible si estás usando tamaños de clave razonables de todos modos.
• Detiene a los malhechores que pueden haber comprometido su clave privada. Es poco probable, pero desconocido.
• Te da la oportunidad de aumentar el tamaño de tu clave para estar delante de la curva.

Drawbacks

• Realmente no le brinda ninguna protección concreta contra el agrietamiento de las teclas a menos que esté usando teclas terriblemente pequeñas.
• Los complementos de verificación SSL / anti-MitM para los navegadores pueden alertar al usuario de que la clave ha cambiado. En mi opinión, este es un inconveniente débil: la mayoría de los usuarios no lo utilizarán.
• Podría causar advertencias temporales en relación con políticas e implementaciones más estrictas de HSTS .
• Requiere trabajo. Podrías estar haciendo otra cosa.

Entonces, en ambos lados hay algunas razones débiles y algunos casos de esquina que quizás debas considerar. Me inclino ligeramente hacia el ángulo de "no lo hagas a menos que necesites", siempre y cuando uses claves de 2048 bits o más.

Lo más importante es preguntar a ellos por qué creen que es necesario; puede ser que tenga una razón relacionada con la infraestructura para actualizar las claves que no conocemos. Si no pueden presentar un argumento sólido ("¿por qué no?" No es realmente válido) entonces probablemente deberían volver a evaluar sus consejos.

Cambiar la clave privada no es una práctica mejor , es una práctica extendida ; de hecho, tiene muy poco que ver con la seguridad y mucho que ver con la forma en que la CA maneja las renovaciones de certificados, es decir, la mayoría de las veces como un nuevo certificado, con una nueva generación de claves privadas. Es más simple, en el lado de CA , no hacer nada especial para una renovación. De ahí el hábito de cambiar las llaves.

Los mismos administradores de sistemas no insistirán en generar nuevas claves anualmente para sus servidores SSH, aunque la situación sea similar, desde el punto de vista de la seguridad. O, más precisamente, cambiar una clave de servidor SSH es un poco inconveniente ya que rompe los archivos .ssh/known_hosts de los clientes. Por lo tanto, es habitual evitar cambiar las claves del servidor SSH. Por lo tanto, las claves del servidor SSH son de larga duración. Nadie realmente salta un latido en eso. ¿Por qué deberían preocuparse por las claves SSL de una fuerza criptográfica similar?

La mejor práctica es cambiar la clave cuando los avances tecnológicos han hecho que su clave sea un tanto vulnerable, teniendo en cuenta la paranoia general (a menudo llamada "por razones de cumplimiento"); por lo que consideraría que en este momento, en 2013, una clave RSA de 1024 bits debería reemplazarse por una más larga, a pesar de que todavía estamos lejos de poder romper dicha clave. Si su clave RSA es de 1536 bits o más ancha, no hay ninguna razón criptográfica para crear una nueva (pero, nuevamente, quizás sea más conveniente cambiarla, en el lado de CA).

La respuesta no es técnica o criptográfica, se trata de personas. Con cosas como cambios de trabajo (¿se ha oído hablar de administradores descontentos?), Las migraciones de servidores, las pruebas de DR, las copias de seguridad y esas claves privadas pueden quedar un poco expuestas.

Dado lo anterior, la renovación de la clave es una buena práctica de seguridad.

No te preocupes por que alguien factorice tu clave RSA. Factorar una clave RSA de 1024 bits puede ser posible para adversarios a nivel estatal, pero incluso para ellos probablemente no sea rentable. Factorizar las claves de 2048 bits probablemente no será posible durante algunas décadas.

Me preocuparía principalmente por el robo de su clave privada en un servidor. La ganancia en caso de compromisos pasados no está clara, ya que el atacante podría tener malware persistente en su servidor. Por lo tanto, deberías volver a instalar el servidor para asegurar la nueva clave.

Otro problema es que algunas suites SSL débiles (principalmente la familia basada en encriptación RSA ) usan su clave a largo plazo para la confidencialidad, y no solo para la autenticación. Con estos, el compromiso de la clave de su servidor le permite descifrar todas las comunicaciones SSL anteriores con su servidor que usó una suite tan débil. El uso de una nueva clave y la eliminación segura de la anterior limita el impacto de dicho ataque.

Entonces, si su servidor aún tiene esas suites habilitadas, le recomiendo cambiar la clave con regularidad.

Cuanto más use una clave, más tiempo le dará a un atacante. A pesar de que no se considera posible romper con 2048 bits con la tecnología actual, ser extra cauteloso y reemplazar la clave no es nada malo en absoluto.

Además, alguien pudo haber logrado obtener su clave privada, sin que usted sea capaz de detectarla. Si no puede repetir la acción, entonces la ventaja de la renovación es muy clara.

• ¿Cambió sus llaves después de HeartBleed?
• ¿Qué hacen los técnicos de su centro de datos con los discos duros dañados?
• ¿Alguien ha dejado la organización de operaciones en el último año?
• ¿Cuándo fue la última vez que giraste las contraseñas de administrador y las claves ssh?

Todas estas preguntas deberían comenzar a pensar en la integridad de sus claves. No estoy diciendo que es probable que estén comprometidos o que alguien pueda usarlos mal. Estoy tratando de hacer que pienses por qué quieres rotarlos.

Las teclas giratorias deben ser súper fáciles y son una buena higiene de seguridad. Si no lo haces porque es difícil, eso es un problema serio. Construye las herramientas y procesos para hacerlo más fácil. Si no lo haces, terminarás fallando en rotar cosas mucho más importantes.

Si bien estoy de acuerdo en que hay pocas razones técnicas para generar nuevas claves cada vez que renueves un certificado, no desafiaría de inmediato a tu equipo de seguridad / gerentes y les llamaré sobre el tema.

Puede haber razones no técnicas que son tan válidas para generar nuevas claves. Por ejemplo, en una organización grande donde existen diversos niveles de centralización de TI, habilidades, procedimientos y buenas prácticas, un área de administración de seguridad centralizada puede requerir tales prácticas para ayudar a mitigar algunos de los riesgos. Esto también puede ayudar a mantener los procedimientos más pequeños y más manejable. Si bien los procedimientos más complejos pueden ser más correctos desde un punto de vista técnico, son más difíciles de documentar y dificultan que el personal sepa que los están siguiendo correctamente. Siempre que la práctica no genere una sobrecarga significativa, puede ser más fácil de adoptar y mantener el enfoque X siempre más simple.

Piénsalo desde otra perspectiva. ¿Todos los miembros de su organización que tienen alguna responsabilidad de administrar certificados tienen la misma conciencia y comprensión de los problemas que usted y son tan exhaustivos / dedicados? ¿Cuál es el nivel de rotación de personal y en qué medida es necesario preocuparse por la cantidad de datos confidenciales a los que pueden tener acceso los empleados?

Cuando se considera la seguridad, el factor humano es casi siempre tan importante o más importante que solo los aspectos técnicos. Las políticas y los procedimientos deben tener en cuenta el elemento humano y tratar de garantizar que estas políticas y procedimientos estén estructurados de tal manera que ayuden al personal a hacer lo correcto, incluso cuando es posible que no entiendan completamente por qué necesitan hacerlo.

Es lo mismo que cambiar las contraseñas realmente. Si alguien está en el proceso de descifrar su contraseña cuando la cambia, tendría que volver a empezar. O si la contraseña, o la clave privada, fue robada, la renovación invalidaría su clave robada (asumiendo que no pueden volver a robarla fácilmente).

Puede ser un buen hábito cambiar la clave privada cada año o cada pocos años solo para que sepa que no romperá nada cuando necesite cambiarla, pero no es necesario para la seguridad del certificado en sí.

SP 800-57 Parte 1 revisada, Recomendación para la administración de claves

Las recomendaciones del NIST sobre los criptoperíodos RSA parecen ser de 1 a 2 años.

Varias personas han mencionado el hecho de que las claves de host ssh rara vez se rotan como un argumento para no rotar las claves ssl. Eso parece ser otro problema a resolver. (Pido disculpas por una respuesta ligeramente fuera de tema, pero varias personas aquí lo mencionaron por lo que parece apropiado)

Vea mi respuesta anterior para por qué uno podría desear rotar las teclas.

Lo siguiente será particularmente útil para todos aquellos que, por razones de cumplimiento, deben rotar las claves de host ssh, pero a quienes les preocupa el impacto de la usabilidad en los usuarios finales.

1) Implementar un ssh_ca (Notablemente completa las instrucciones en man ssh-keygen)

ssh-keygen -f ssh_ca -b 4096

2) Distribuya el certificado a sus usuarios: agregue la línea de autoridad de certificado a ~ / .ssh / known_hosts

@cert-authority *.domain.name ssh-rsa AAAAB3[...]== Comment

3) Firme sus claves de host (asegúrese de restringir cada una a un host individual)

ssh-keygen -s ssh_ca -I host.domain.name -h -n host.domain.name -V +52w /etc/ssh/ssh_host_rsa_key.pub

4) Configure los servidores para presentar el certificado (/ etc / ssh / sshd_config):

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

El cliente confía en cualquier clave de host firmada por la CA (no se aceptan más a ciegas una firma clave la primera vez que te conectas)

Ahora se puede hacer rodar la clave de host sin interrupciones para los clientes. La firma de la clave se puede incluir en el proceso de creación / orquestación del host.

Esta es una buena referencia. Este proyecto creó algunas herramientas útiles sobre el uso de ssh_ca para el acceso de usuarios con expiración automática.