¿Qué hace un ataque de colisión para un atacante? [duplicar]

0

Estaba instalando una CA en una máquina con Windows Server 2012, y me preguntó con qué algoritmo hash quiero firmar los certificados (MD5, SHA1, SHA256, etc.). Leí que SHA256 es inmune a los ataques de colisión, mientras que los métodos más antiguos no lo son.

Por lo que entiendo, la AC usa este algoritmo de hash para crear firmas digitales. Al igual que cuando un servidor le pide a la CA una firma digital para que la gente pueda confiar en ella, la entidad emite el certificado del servidor y la cifra con la clave privada de la entidad emisora de certificados. Luego, el servidor enviará esta firma digital a sus clientes para que puedan confiar en ella.

Entonces, lo que me pregunto es ¿qué diferencia hará si elige un método de hashing más seguro que otro en la configuración de CA? ¿Qué diferencia hay si un atacante encuentra algo que produce el mismo hash que el de la firma? Él no tiene la clave privada de la CA ni la clave privada del servidor, así que, ¿qué lograría al realizar un ataque de colisión?

Editar: los enlaces no responden a la pregunta.

    
pregunta Zouzou Ibba 01.07.2017 - 19:33
fuente

1 respuesta

2

Puedes estar mezclando un ataque de colisión con un ataque de segunda preimagen. La diferencia entre los dos radica en lo que controla el atacante: en un ataque de colisión, el atacante tiene que encontrar dos cadenas que generen el mismo hash, y el atacante elija ambas cadenas . En un ataque de segunda preimagen, el atacante tiene que encontrar una cadena que genere el mismo hash que una cadena dada que el atacante no puede controlar . Vea las respuestas a esta pregunta para más información sobre la diferencia.

Preguntó "¿Qué diferencia hay si un atacante encuentra algo que produce el mismo hash que el de la firma?" - Aquí, estás describiendo un segundo ataque de preimagen. Si eso fuera posible, un atacante podría usarlo para generar un certificado falsificado con el mismo hash que el certificado válido, y luego simplemente copiar la firma del certificado válido al certificado falsificado; ya que sus hashes coinciden, la firma también coincidirá. Esto daría como resultado un fallo completo de la seguridad del certificado. Pero (al menos hasta donde sé) no hay indicios de un ataque práctico de segunda imagen contra SHA-1 (o incluso MD5), por lo que esto es bastante hipotético.

El riesgo de ataques de colisión (que son posibles contra MD5 y SHA-1) es menos directo. El problema aquí no es con su certificado de servidor real; para eso podría usar MD5, y las conexiones aseguradas con él serían completamente seguras. El problema es que un atacante puede generar dos certificados con hashes coincidentes, uno de los cuales se verá bien ante una autoridad de certificación y uno de los cuales es completamente inválido. Envían el OK a una CA confiable, lo firman, luego transfieren la firma de la CA (válida) al certificado no válido, y luego usan el certificado no válido (con la firma válida) para lo que quieran. Incluyendo simplemente reemplazando el certificado (válido) de su servidor.

Esto es no hipotético. En 2008, un grupo de investigadores del Chaos Computer Club utilizó este proceso para falsificar un certificado de CA intermedio con una firma de CA válida (MD5); dado que el certificado falsificado era un certificado de CA en sí mismo, podían usarlo para firmar lo que quisieran (aunque lo crearon intencionalmente antes de expirar, por lo que no se pudo usar). Consulte este artículo de CNET .

Para evitar ser engañados por certificados falsificados como esos, los clientes deben rechazar los certificados con firma MD5 (y probablemente pronto con la firma SHA-1). Y esa es la razón por la que debe firmar sus certificados con SHA256, no es que los certificados MD5 y SHA-1 sean inseguros, es que los clientes no pueden decir que están seguros , y por lo tanto no tienen más remedio que rechazarlos. Consulte mi respuesta a una pregunta similar aquí para más detalles.

    
respondido por el Gordon Davisson 01.07.2017 - 23:20
fuente

Lea otras preguntas en las etiquetas