Corporativo PKI - SHA1 depreciación

  

Este es un problema candente por razones de seguridad en su mayoría [...]

Todavía no. No hay un ataque práctico publicado todavía. Pero está en el post. La transición gradual ahora es mejor que la transición del algoritmo de hashing MD5 anterior al SHA1. En ese entonces, no existía una estrategia explícita de endeudamiento AFAIK y en realidad hubo ataques perversos que utilizaban colisiones con MD5. ( Flame ) No debemos esperar hasta que suceda lo mismo con SHA1.

  

¿Es necesario organizar una nueva ceremonia clave para la creación de una nueva cadena "SHA256"? Incluso para la cadena fuera de línea (raíz y subredes)? ¿Reedición de nuevos certificados de entidades finales con SHA256?

Sí. Fuera de línea o no, no importa. La cadena de certificados es tan fuerte como el eslabón más débil. (Excluyendo la raíz, cuya firma no importa.) Y también: un certificado CA es siempre un objetivo más juicioso para un ataque que un certificado de entidad final.

  

¿Introduciendo un período de deslizamiento para la renovación de claves?

Sí. No emita nada con SHA1 después de las fechas de corte mencionadas. Si emitió SHA1 hasta la fecha de corte, hágalo solo con una justificación por escrito y con la aprobación del administrador.

¿Es un acto de acción inmediata que se debe realizar porque los ataques son factibles ahora? No. Dicho esto, cuando trabaje con PKI, debe tener una visión larga, así que comience a planificar ahora.

Se estima que para fines de 2017, las colisiones de hash precomputadas para crear certificados impostores (y, por lo tanto, certificados de CA impostores) pueden caer por debajo de los 100.000 $ en computación, utilizando recursos de computación en la nube. Como estoy seguro de que sabe, reemplazar todos esos certificados y establecer la confianza en sus nuevas CA es no trivial.

Deberá reemplazar al menos sus CA intermedias fuera de línea y emisoras en línea, así como reemplazar todos los certificados de hoja.

Si está configurando una nueva infraestructura de CA ahora, y si los certificados tienen un ciclo de vida de dos años, y si todas sus aplicaciones (tanto las aplicaciones del lado del servidor que presentan certificados como los clientes que consumen / validan certificados) pueden hacer frente al SHA-2, y mantiene su raíz existente (para no tener que tocar los anclajes de confianza), luego, si comienza de inmediato, simplemente puede reemplazar los certificados como parte de la renovación estándar.

Supongo que al leer documentos anteriores antiguos, solo el certificado de CA autofirmado no se ve afectado por el plan de desaprobación SHA-1 y aún puede usar SHA-1, ya que los clientes tienen otros medios para verificar la integridad de la raíz certificados Todos los demás certificados deben ser reemplazados. Aquí está la descripción completa: enlace