SHA-1 cómo y cuándo es realmente un problema

  

Un atacante crea un certificado para example.com y el valor de SHA-1 también es igual a X, así que nuevamente, tenemos una colisión, ¡pero esta vez no es de ninguna CA confiable!

La CA para un certificado se especifica en el campo emisor dentro del certificado. El certificado se verifica buscando un certificado de confianza que tenga a este emisor como sujeto y luego use este certificado para validar la firma.

Esto significa que si un atacante tiene un certificado válido firmado con SHA-1 por una CA de confianza y quiere usar esta firma para su propio certificado falso, el certificado falso debe tener la misma información de emisor que el certificado original y el resultado en el mismo SHA-1. Si se otorga a ambos, este certificado falso se considera de confianza como el original. Dado que el atacante tiene el control total sobre el contenido del certificado falso, también tiene el control del campo del emisor y, por lo tanto, podría configurarlo según sea necesario.

Hay mucho alarmismo acerca de SHA1.

Comprende que hay diferentes tipos de ataques en una función hash. El ataque de colisión actual en sha1 le permite al atacante hacer lo siguiente.

1. Elija un prefijo común para los dos archivos en conflicto antes generando los "bloques de colisión".
2. Elija un sufijo común para los dos archivos en conflicto después generando los "bloques de colisión".

Esto es típico de los ataques de colisión iniciales encontrados en las funciones hash de merkle-damgaurd.

Normalmente, los ataques para este tipo de ataque de colisión toman la siguiente forma.

1. El atacante elige un formato de archivo en el que la basura se puede ocultar fácilmente y en la que se puede implementar una lógica razonablemente compleja (pdf es el elemento secundario del cartel).
2. El atacante construye un prefijo común que contiene el encabezado del pdf y cierta lógica para omitir los bloques de colisión.
3. El atacante genera los bloques de colisión.
4. El atacante genera un sufijo común distinto que mira los bloques de colisión y cambia el contenido aparente del documento en función de cuál de los bloques de colisión está presente.
5. El atacante convence a la víctima para que firme el documento "bueno".
6. El atacante trasplanta la firma al documento "malo".

El atacante ahora tiene una copia del documento "malo" que aparentemente firmó la víctima. Puede usar ese documento para convencer a las personas de que la víctima aceptó algo que realmente no aceptó.

Ahora, ¿cómo se relaciona esto con las AC?

El atacante pretende trasladar una firma de un certificado legítimo firmado por una CA a un certificado Evil. El certificado legítimo será para un dominio que el atacante posee legítimamente, el certificado Evil puede ser para un dominio que el atacante quiere suplantar o puede ser un "certificado intermedio" que permite al atacante firmar certificados a voluntad para los dominios que quiere personificar.

Esto es mucho más difícil que el ataque descrito anteriormente por dos razones.

1. Las CA solo le dan al cliente un control limitado sobre el contenido de los certificados.
2. Los formatos de certificado de Afaict no tienen espacio para el nivel de lógica complicada posible en algo como un pdf.

Debido a esto, no creo que sea posible explotar un ataque de colisión "simple" contra una CA.

Más peligroso es un ataque de colisión "prefijo elegido distinto". Actualmente no se conoce ningún ataque de colisión con prefijo distinto para SHA1. Para MD5, se encontró uno aproximadamente 5 años después de que se encontró la primera colisión básica.

En este caso, el atacante puede.

1. Elija dos prefijos elegidos distintos antes generando los bloques de colisión.
2. Elija un único sufijo común elegido después de generar los bloques de colisión.

Un ataque de colisión con prefijo distinto es mucho más peligroso porque el contenido del archivo "maligno" no tiene que estar oculto dentro del archivo "bueno". Solo un pequeño bloque de basura aparentemente aleatoria tiene que estar oculto. También significa que mientras el atacante pueda predecir la mayor parte del contenido del archivo, solo necesita controlar una pequeña parte del mismo.

Sin embargo, todavía hay un problema, los certificados tienen un "número de serie". Dado que el número de serie es uno de los primeros campos en el certificado, inevitablemente aparecerá antes de los bloques de colisión y, por lo tanto, el atacante debe poder predecirlo por adelantado.

El foro de CA / navegador requiere que las CA coloquen al menos 64 bits de aleatoriedad en sus números de serie. Si las AC siguen las reglas, sería prácticamente imposible para el atacante predecir el número de serie.

OTOH si una CA es descuidada y no usa números de serie aleatorios, explotar los ataques de colisión de prefijo distintos elegidos se vuelve más factible. Tal ataque fue demostrado con éxito con MD5 por un grupo de académicos. Una vez que se demostró el ataque, la CA en cuestión comenzó a asignar al azar sus números de serie.

Si se encuentra un ataque de colisión de prefijo elegido en SHA1 y el atacante puede encontrar una CA lo suficientemente descuidada, puede crear un certificado SHA1 falsificado.

Aparentemente, eso es suficiente para que los proveedores del navegador decidan eliminar SHA1.

El ataque final en una función hash sería un ataque previo a la imagen. Con tal ataque, el atacante podría trasplantar una firma de cualquier certificado existente a su nuevo certificado. Sin embargo, los ataques de preimagen son mucho más difíciles que los ataques de colisión. Afaict, incluso con MD5, los ataques de preimagen aún no son computables.

En 2008 se demostró un ataque práctico de colisión contra la PKI de la web, explotando CA que aún utiliza MD5. La estructura general del ataque fue:

1. Cree dos solicitudes de firma de certificado diseñadas para colisionar: una honesta para un sitio web legítimo y una deshonesta que suplanta una CA intermedia y, por lo tanto, está autorizada para emitir certificados .
2. Presente la CSR honesta a un CA. Ya que es una CSR legítima, la CA emitirá un certificado honesto para ella.
3. Combine la firma en el certificado honesto y el CSR deshonesto para elaborar un certificado de CA intermedio falsificado.
4. Use el certificado falsificado para emitir los certificados que desee, para el sitio que desee.

La página tiene los detalles esenciales, pero esto ilustra la forma general de los ataques de colisión contra firmas digitales: el problema es que si Eve puede hacer que Alice firme un documento legítimo que fue diseñado para colisionar con una falsificación, entonces Eve puede usar la firma legítima para convencer a Bob de que Alice firmó el documento falsificado. En el ataque PKI web, Alice es una CA y Bob es un navegador web.

Los ataques de colisión contra MD5 que permitieron este ataque fueron más poderosos que el ataque de hoy en SHA1, por lo que no podemos llevar a cabo tal ataque hoy contra los certificados de SHA1. Pero un principio clave aquí es que deberíamos estar anticipándonos a los ataques antes de que ocurran , no solo reaccionando a ellos después de que estén sobre nosotros. El hecho de que se haya encontrado una colisión para SHA1 significa que es probable que se produzcan ataques más poderosos en el futuro cercano, por lo que debemos abandonar SHA1.

Para usar la historia como ejemplo, la primera colisión de MD5 se encontró en 2004, cuatro años antes del ataque práctico de PKI en la web que he vinculado anteriormente. No sabemos cuándo se encontrarán (o se han encontrado ya) ataques mejorados similares contra SHA1, ni qué ventana tan grande tendremos entre un descubrimiento secreto y conocimiento público.