descargar - Publicador AC Raiz SUSCERTE
descargar - Publicador AC Raiz SUSCERTE
descargar - Publicador AC Raiz SUSCERTE
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Firmado electrónicamente por<br />
Piero Mangialomini Darbisi<br />
en fecha 2011-10-04 09:35:50.045<br />
ESTUDIO DE F<strong>AC</strong>TIBILIDAD PARA <strong>AC</strong>TUALIZ<strong>AC</strong>IÓN DE ALGORITMO DE HASH<br />
EN LA INFRAESTRUCTURA N<strong>AC</strong>IONAL DE CERTIFIC<strong>AC</strong>IÓN ELECTRÓNICA<br />
DEL ESTADO VENEZOLANO<br />
DERECHOS DE USO<br />
La presente documentación es propiedad de la Superintendencia de Servicios de<br />
Certificación Electrónica <strong>SUSCERTE</strong>, tiene carácter privado y confidencial y esta<br />
dirigido exclusivamente a su(s) destinatario(s), no podrá ser objeto de<br />
reproducción total o parcial, ni transmisión de ninguna forma o por cualquier<br />
medio, ya sea electrónico, mecánico, digital, registro o cualquier otro, no podrá<br />
ser distribuido sin el permiso previo y escrito de <strong>SUSCERTE</strong>, bajo ningún concepto.<br />
Si usted ha recibido este mensaje por error, debe evitar realizar cualquier acción<br />
descrita anteriormente, asimismo le agradecemos comunicarlo al remitente y borrar<br />
el mensaje y cualquier documento adjunto. El incumplimiento de las limitaciones<br />
señaladas por cualquier persona que tenga acceso a la documentación será sancionada<br />
conforme a la ley.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Destinatario: DESP<strong>AC</strong>HO DE LA SUPERINTENDENCIA<br />
Nombre del proyecto<br />
Fecha última edición 26/09/11<br />
Responsable DRA<br />
Restricciones de uso Ver cuadro inferior<br />
CONTROL DE VERSIONES<br />
Versión Áreas<br />
Modificadas<br />
Estudio de factibilidad para actualización de<br />
Algoritmo de Hash, en la Infraestructura<br />
Nacional de Certificación Electrónica del Estado<br />
Venezolano<br />
Descripción del cambio Autor Fecha<br />
1.0 Todas Versión Inicial DRA 01/09/10<br />
'1.1 Todas Formato y recomendaciones DRA 03/09/10<br />
1.2 Consideraciones Actualización de Información DRA 08/09/10<br />
1.3 Recomendaciones Actualización de Información DRA 26/09/11<br />
1.4 Anexos Actualización de Información DRA 28/09/11<br />
DERECHOS DE USO<br />
La presente documentación es propiedad de la Superintendencia de Servicios de<br />
Certificación Electrónica <strong>SUSCERTE</strong>, tiene carácter privado y confidencial y esta<br />
dirigido exclusivamente a su(s) destinatario(s), no podrá ser objeto de<br />
reproducción total o parcial, ni transmisión de ninguna forma o por cualquier<br />
medio, ya sea electrónico, mecánico, digital, registro o cualquier otro, no podrá<br />
ser distribuido sin el permiso previo y escrito de <strong>SUSCERTE</strong>, bajo ningún concepto.<br />
Si usted ha recibido este mensaje por error, debe evitar realizar cualquier acción<br />
descrita anteriormente, asimismo le agradecemos comunicarlo al remitente y borrar<br />
el mensaje y cualquier documento adjunto. El incumplimiento de las limitaciones<br />
señaladas por cualquier persona que tenga acceso a la documentación será sancionada<br />
conforme a la ley.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
ÍNDICE<br />
CONTROL DE VERSIONES....................................................................................................................2<br />
ÍNDICE......................................................................................................................................................3<br />
JUSTIFIC<strong>AC</strong>IÓN.......................................................................................................................................5<br />
CONCEPTOS.............................................................................................................................................7<br />
COLISIONES SHA...................................................................................................................................8<br />
1. Colisiones..........................................................................................................................................8<br />
2. Antecedentes en el mundo de Ataques de Colisiones SHA1...........................................................10<br />
3. Colisiones SHA1 y los Certificados Electrónicos...........................................................................12<br />
GENERALIDADES.................................................................................................................................13<br />
AUTORIDADES, ESTANDARES Y APLIC<strong>AC</strong>IONES MIGRADAS A SHA256 ó SUPERIOR.........17<br />
SITU<strong>AC</strong>IÓN <strong>AC</strong>TUAL – VENEZUELA................................................................................................20<br />
Proveedores..........................................................................................................................................20<br />
Línea de tiempo...................................................................................................................................20<br />
RECOMEND<strong>AC</strong>IONES...........................................................................................................................21<br />
BIBLIOGRAFIA......................................................................................................................................24<br />
ANEXOS..................................................................................................................................................25<br />
A. RFC 4270. Ataques a resúmenes criptográficos en protocolos de Internet...................................25<br />
B. Informe de los Investigadores de la Universidad de Shadong (China) donde demuestran los<br />
procedimientos matemáticos con los que generaron colisiones en SHA1 para romper con la<br />
seguridad.............................................................................................................................................34<br />
C. Viabilidad de SHA1.......................................................................................................................34<br />
D. Proyecto de Colisión SHA1......................................................................................................38<br />
E. Búsqueda de colisiones SHA1 .......................................................................................................40<br />
F. Ataques de Colisiones SHA1..........................................................................................................42<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
JUSTIFIC<strong>AC</strong>IÓN<br />
Las actividades desarrolladas por la Superintendencia de Servicios de Certificación<br />
Electrónica (<strong>SUSCERTE</strong>) y su funcionamiento, tienen su asidero legal en el Decreto con<br />
Fuerza de Ley Nº 1.204 de fecha 10 de Febrero de 2001, de Mensaje de Datos y Firmas<br />
Electrónicas; publicado en la Gaceta Oficial de la República Bolivariana de Venezuela Nº<br />
37.148 del 28 de febrero de 2001; en el cual se establece en el artículo 20, su creación,<br />
como un servicio autónomo con autonomía presupuestaria, administrativa, financiera y de<br />
gestión, en las materias de su competencia; en concordancia con lo previsto y sancionado en<br />
el Reglamento Parcial del Decreto de Ley Sobre Mensajes de Datos y Firmas Electrónica y el<br />
Decreto sobre Organización y Funcionamiento de la Administración Pública Nacional Nº<br />
6.732, de fecha 02 de junio de 2009, publicado en la Gaceta Oficial de la República<br />
Bolivariana de Venezuela Nº 39.202 del 17 de junio de 2009.<br />
En tal sentido, <strong>SUSCERTE</strong>, como órgano rector a nivel nacional, en materia de<br />
Certificación Electrónica, tiene como objeto entre otros, acreditar, supervisar, controlar y<br />
revocar a los Proveedores de Servicios de Certificación Electrónica, conforme a las<br />
atribuciones conferidas en los instrumentos legales supra indicados.<br />
Como ente rector en materia de certificación electrónica del Estado Venezolano,<br />
<strong>SUSCERTE</strong>, se apega a los estándares internacionales y mejores prácticas en materia de<br />
certificación electrónica y seguridad de la información; empleando elementos que garanticen<br />
la integridad, no repudio y confidencialidad de la información intercambiada, a través<br />
de algoritmos de encriptación y huella electrónica (hash). En este sentido, la<br />
Superintendencia ha realizado un análisis de las tendencias mundiales y nacionales para<br />
este tipo de tecnología, en aras de garantizar que en la emisión de los Certificados<br />
Electrónicos se utilicen herramientas y estándares adecuados a los usos internacionales, que<br />
no permitan su alteración o modificación, y que garanticen la seguridad técnica de los<br />
procesos de certificación electrónica, en cumplimiento de la Ley de Mensajes de Datos y<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Firmas Electrónicas.<br />
En otro sentido, existe lo que se denomina, La Infraestructura Nacional de<br />
Certificación Electrónica, donde se describe como el conjunto de equipamiento (hardware),<br />
programas (software), dispositivos criptográficos, políticas, leyes, procedimientos y<br />
normativas legales o sublegales; dispuestos y utilizados de manera exclusiva por el Sistema<br />
Nacional de Certificación Electrónica, que está compuesto por la Autoridad de Certificación<br />
Raíz y los Proveedores de Servicios de Certificación, acreditados por este Despacho para la<br />
generación, almacenamiento y publicación de los certificados electrónicos, así como también<br />
para la publicación de información y consulta del estado de vigencia y validez de dichos<br />
certificados electrónicos. Esta Infraestructura se basa en dos pilares fundamentales: la<br />
confianza y la tecnología.<br />
1. La confianza está enmarcada en el desarrollo e implementación de políticas de<br />
seguridad, para satisfacer los niveles requeridos de confidencialidad en la<br />
administración y emisión de certificados electrónicos.<br />
2. La tecnología, está definida como una herramienta para el mantenimiento y<br />
actualización de plataformas de hardware y software que dan soporte a la<br />
Infraestructura Nacional de Certificación Electrónica.<br />
La Infraestructura Nacional de Certificación Electrónica, fue concebida según<br />
Providencia emitida el 2 de marzo de 2007; en la cual se establecen las Normas Técnicas<br />
bajo las cuales <strong>SUSCERTE</strong>, coordinará e implementará el modelo jerárquico de dicha<br />
infraestructura, para que los Proveedores de Servicios de Certificación acreditados (PSC)<br />
emitan los certificados electrónicos en el Marco del Decreto Ley sobre Mensajes de Datos y<br />
Firmas Electrónicas y su Reglamento.<br />
Es así como <strong>SUSCERTE</strong>, promueve y divulga el uso de los certificados electrónicos y<br />
de la firma electrónica en Venezuela con la creación de la Autoridad Certificadora Raíz del<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Estado Venezolano, haciendo énfasis en el uso de claves criptográficas tanto simétricas<br />
como asimétricas, gracias al soporte y confianza que es brindado por los sistemas de<br />
clave pública a los algoritmos que se implementan con esta tecnología, siempre<br />
garantizando la confiabilidad, integridad y privacidad de la información que se intercambia, a<br />
través de métodos tecnológicos que garanticen rapidez y seguridad, con todas las ventajas<br />
de los sistemas asimétricos, incluyendo la firma electrónica. Donde además, <strong>SUSCERTE</strong><br />
esta obligado a adecuarse a los cambios tecnológicos que a nivel mundial llevan la batuta en<br />
cuanto al tema criptográfico se refiere y por ende migrar hacia las nuevas tendencias. Tal es<br />
el caso del SHA256, presentando características matemáticas funcionales que robustecen el<br />
servicio de confiabilidad, integridad y privacidad, del cual se mencionó con anterioridad.<br />
Algoritmo Criptográfico.<br />
CONCEPTOS<br />
Transformación matemática que partiendo de un texto plano lo cambia a datos<br />
ilegibles cifrados.<br />
Certificado Electrónico.<br />
Mensaje de Datos proporcionado por un Proveedor de Servicios de Certificación que<br />
le atribuye certeza y validez a la Firma Electrónica.<br />
Cifrado.<br />
Transformación de un mensaje en otro, utilizando una clave para impedir que el<br />
mensaje transformado pueda ser interpretado por aquellos que no conocen la clave.<br />
Confiabilidad.<br />
Parte que asegura que la información sólo puede ser vista y utilizada por las partes<br />
que están autorizadas. La comunicación entre partes confiables se establece una vez que se<br />
ha realizado el proceso de autenticación.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Criptografía.<br />
Rama de las matemáticas aplicadas que se ocupa de transformar mensajes en formas<br />
aparentemente ininteligibles y devolverlas a su forma original.<br />
Algoritmo SHA.<br />
SHA (Secure Hash Algorithm - Algoritmo de Hash Seguro) es un sistema de<br />
funciones hash criptográficas relacionadas de la Agencia de Seguridad Nacional de los<br />
Estados Unidos (NSA) y publicadas por el National Institute of Standards and Technology<br />
(NIST). El primer miembro de la familia fue publicado en 1993 es oficialmente llamado SHA.<br />
Sin embargo, hoy día, no oficialmente se llama sha-0 para evitar confusiones con sus<br />
sucesores. Dos años atrás más tarde el primer sucesor de SHA fue publicado con el nombre<br />
SHA-1. Este algoritmo es hoy en día utilizado para almacenar las contraseñas de forma<br />
codificada, evitando su transferencia por la red sin protección. SHA-1, también es utilizado<br />
para integrar la firma electrónica en documentos electrónicos.<br />
1. Colisiones<br />
COLISIONES SHA<br />
La idea básica de un ataque de colisión hash se basa en que el atacante crea dos (2)<br />
mensajes que tengan el mismo valor hash (figura 1) firmado y que luego utiliza dicha firma<br />
sobre el otro mensaje para algunos propósitos ilegales y nefastos.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Figura 1.<br />
Ahora bien, en principio SHA-1 toma como entrada un mensaje de longitud máxima<br />
2 64 bits (más de dos mil millones de Gigabytes) y produce como salida un resumen de 160<br />
bits. Este número es mayor que el que se utilizaba en el algoritmo SHA original, 128 bits. Ya<br />
existen nuevas versiones de SHA que trabajan con resúmenes de 224, 256, 384 e incluso<br />
512 bits.<br />
La importancia de la rotura de una función hash se debe interpretar en el siguiente<br />
sentido: Un hash permite crear una huella digital, teóricamente única, de un archivo. Una<br />
colisión entre hashes supondría la posibilidad de la existencia de dos documentos con la<br />
misma huella. La inicial similitud propuesta con la equivalencia a que hubiese personas que<br />
compartiesen las mismas huellas digitales, o peor aún, el mismo ADN no es adecuada pues,<br />
aunque fuera trivial encontrar dos ficheros con el mismo resumen criptográfico ello no<br />
implicaría que los ficheros fueran congruentes en el contexto adecuado. Siguiendo con la<br />
hipótesis de la similitud biométrica de dos personas, sería el equivalente a necesitar<br />
modificar el número de brazos en una persona para que su impresión dactilar fuera igual a la<br />
de otra.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
En este sentido, SHA1 y sus características matemáticas para blindarse ante posibles<br />
ataques de colisión ha sido puesto en duda desde hace algunos años atrás. Debido al<br />
desarrollo de la tecnología y la evolución de los procesadores matemáticos que se<br />
encuentran en los computadores, ha aumentado la capacidad de estas máquinas de realizar<br />
operaciones matemáticas complejas (criptoanálisis). Básicamente empleando la<br />
criptoanálisis, la misma se basa en que la búsqueda de un mensaje igual a otro, se puede<br />
hacer mediante fuerza bruta usando una búsqueda en las evaluaciones 2L, donde L es el<br />
numero de bits en encontrar dos mensajes.<br />
Por esta razón, se hizo posible calcular y predecir resultados iguales para distintos<br />
mensajes de entrada donde se utilice el algoritmo SHA-1, a través de una técnica conocida<br />
como “predicción de vectores de colisión”.<br />
2. Antecedentes en el mundo de Ataques de Colisiones SHA1.<br />
• El primer ataque registrado sobre este algoritmo, fue el conocido en el año 2004 como<br />
“ataque de cumpleaños”, basado en la predicción de un resultado (hash) utilizando<br />
métodos matemáticos y probabilísticos, donde en un par de días, con un equipo de<br />
computación de medianas prestaciones fue posible romper la seguridad del algoritmo.<br />
• A principios de 2005 un grupo de investigadores chinos de la Universidad de Shadong<br />
(Xiaoyun Wang y Hongbo Yu) y una colaboradora de la Universidad de Princeton<br />
(Yiqun Lisa) consiguió reducir el número de intentos para acelerar el proceso de<br />
colisión de dos mensajes cualesquiera a 2 69 . Poco después se avanzó hasta 2 63 .<br />
• Poco después, Christophe De Canni`ere, Florian Mendel, y Christian Rechberger, de<br />
la Graz University of Tecnology de Austria, realizaron pruebas exitosas de Ataques de<br />
colisión en 70 pasos, realizando entre otros un análisis del costo computacional que<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
implica realizar el ataque.<br />
• También, en el 2009, Cameron McDonald, Philip Hawkes y Josef Pieprzyk de la<br />
Universidad de Macquerie, ubicada en Sydney Australia, realizaron ataques de<br />
colisiones titulado "Camino Diferencial para SHA-1 con complejidad (2^52)", es decir<br />
4.503.599.627.370.496 de intentos, lo que se traduce en una vulneración importante;<br />
de lo cual se destaca lo siguiente: por cada unidad en la que se reduce el exponente,<br />
se reduce la fortaleza del algoritmo en un 50%. Dicho de otra manera, se puede decir<br />
que actualmente el algoritmo de firma SHA-1, se ha debilitado en más de un 99% en<br />
relación con su fortaleza inicial creada en el año de 1995. Esto se explica de la<br />
siguiente manera:<br />
➢ 2^52=4503599627370496 combinaciones.<br />
➢ Si las dividimos por las combinaciones por segundo:<br />
4503599627370496/70000000=64337138 seg<br />
➢ En horas-> 64337138/3600=17872 horas<br />
➢ En días-> 17872/24=745 días<br />
➢ En años => 2 años!.<br />
• Cloud computing de Amazon, ha realizado ataques de colisión por fuerza bruta, donde<br />
específicamente un investigador de Tecnologías de Información (TI), utilizó Amazon<br />
Web Services para romper seis (6) caracteres de la cadena de entrada de SHA-1 160<br />
bits en 49 minutos a un costo de $2,10.<br />
• Equipos en Hardware actualmente, tienen la capacidad para realizar ataques de<br />
colisión ó romper claves SHA1. Por ejemplo, el framework de Nvidia CUDA, con<br />
software Extreme GPU Bruteforcer y una Nvidea GeForce 8800GS es posible romper<br />
70 millones de claves SHA1 por segundo.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
de SHA1.<br />
Tabla resumen de los primeros estudios y pruebas realizadas en ataques de colisión<br />
Universidades o Institutos que<br />
realizaron estudios de ataque a<br />
SHA-1<br />
Universidad de Shadong (China) Xiaoyun Wang<br />
Hongbo Yu<br />
Investigadores Año<br />
2005<br />
Universidad de Princeton (E.E.U.U.) Yiqun Lisa 2005<br />
Departamento de Algoritmos y<br />
Criptografía de la Universidad de<br />
Macquarie (Australia)<br />
Tabla nº1<br />
3. Colisiones SHA1 y los Certificados Electrónicos<br />
Cameron McDonald<br />
Philip Hawkes<br />
Josef Pieprzyk<br />
2009<br />
Las firmas electrónicas, al ser simplemente un conjunto de información que se<br />
agrega a los documentos, presentan varios problemas para poder asegurar que la<br />
información sea veraz, ya que no se puede asegurar cuál es el individuo que la está<br />
enviando hasta que un tercero certifique la identidad del mismo.<br />
Suponiendo que esto no sería problema, las firmas digitales presentan un<br />
inconveniente adicional con las funciones hash ya que al convertir el conjunto universo de<br />
todos los mensajes o documentos en un resultado finito, existen muchas combinaciones que<br />
darían entonces el mismo resultado de la función hash. De esta forma, virtualmente existen<br />
varios documentos que aplicados a la misma firma electrónica, darían el mismo resultado.<br />
Esto debido a que la función hash tiene una gráfica elíptica y éste comportamiento originan<br />
las colisiones.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Las colisiones pueden ser aprovechadas por un individuo de esta forma: Se crean<br />
dos mensajes diferentes pero se logra que ambos tengan el mismo resultado hash<br />
(colisión legítima). Se le envía uno de los mensajes al receptor y se consigue que él lo<br />
acepte y lo firme digitalmente. Como la persona lo que está firmando es el resultado<br />
hash entonces sería como que firmara ambos mensajes por lo que convenientemente,<br />
luego se le presenta a esta persona el segundo mensaje y de esta forma se engaña<br />
legítimamente. Este escenario es complicado, pero con el avance en la obtención de<br />
colisiones se prevé que en el futuro cercano no sea una tarea muy complicada.<br />
Lo mismo sucede con los certificados electrónicos, ya que se puede lograr<br />
que se acredite un individuo el cual utiliza su firma electrónica. Si otro individuo logra<br />
generar la misma firma, pero que esta tenga otra información al enviar un mensaje, podría<br />
utilizar el mismo certificado y el receptor no tiene la obligación de corroborar estos datos<br />
con el Certificado de modo que podría creer que es un mensaje válido cuando no lo es.<br />
Definitivamente en el caso de los Certificados Electrónicos, los problemas son<br />
menores debido al control en el proceso de acreditación, pero debido a que los Sistemas de<br />
Información no son infalibles, existen muchas formas de violentar el debido proceso de los<br />
Certificados.<br />
GENERALIDADES<br />
Cuando empezaron a aparecer debilidades del SHA-1, en el año 2004, se empezó a<br />
oír hablar del relevo, los algoritmos de la familia SHA-2, que incluyen los algoritmos SHA224,<br />
SHA256, SHA384 y SHA512. A todos estos algoritmos se les denomina “sha2”.<br />
A continuación, en la tabla nº2 se establece una matriz comparativa para estudiar la<br />
factibilidad en la actualización del algoritmo hash para su uso en certificados electrónicos y<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
firmas electrónicas de SHA-1 a SHA-256:<br />
Característica SHA 1 SHA 256<br />
Tipo Algoritmo de hash Algoritmo de hash<br />
Creación 1995 2002<br />
Estándar ANSI FIPS 180-3 / FIPS 140-2<br />
Longitud del bloque de<br />
entrada (bits)<br />
Longitud del bloque de<br />
salida (bits)<br />
2 64 2 64<br />
160 bits 256 bits<br />
Longitud de Clave 1024 bits de cifrado 2048 bits de cifrado<br />
Operaciones<br />
matemáticas<br />
Ruptura (cantidad de<br />
operaciones necesarias)<br />
2 128<br />
2 256<br />
2 52 2 251,7<br />
Tiempo de ruptura 56 horas 38 mil años<br />
Equipo utilizado para<br />
ruptura<br />
Fecha de deprecación /<br />
Organización emisora<br />
Cluster de Servidor Quadcore<br />
1.90 Ghz; 8 GB RAM<br />
Cluster de Servidor Quadcore<br />
1.90 Ghz; 8 GB RAM<br />
2005 / NIST N/A<br />
Alerta de uso en Adobe 2010 N/A<br />
Alerta de uso en Linux 2010 N/A<br />
Alerta de uso en<br />
Microsoft<br />
Estudios sobre ataques<br />
publicados<br />
internacionalmente<br />
2010 N/A<br />
Departamento de Ciencias<br />
Físicas y Matemáticas de la<br />
Universidad de Tecnología de<br />
Nanyang (Singapur). 2005.<br />
Departamento de Algoritmos y<br />
Criptografía de la Universidad<br />
de Macquarie (Australia).<br />
2009.<br />
Ataques conocidos Ataque del “Cumpleaños”<br />
Ataque de Búsqueda de<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
N/A<br />
N/A<br />
De Uso Público
Herramientas para<br />
romper algoritmo<br />
colisiones<br />
Ataque de Resistencia a<br />
Colisiones<br />
Ataque por Vectores<br />
Perturbadores<br />
Exploits para Crackear SHA-1 N/A<br />
Tabla nº2. Tabla comparativa SHA1 vs. SHA256<br />
Entes o Instituciones por país que han actualizado al algoritmo de firma SHA-2.<br />
Entes o Instituciones que implementan SHA-2. País<br />
Instituto Nacional de Tecnología da Informação - ITI Brasil<br />
Gobierno de España, Ministerio del Interior España<br />
CERES España<br />
ANF-<strong>AC</strong> España España<br />
CERTICAMARA Colombia<br />
ANF-<strong>AC</strong> Ecuador Ecuador<br />
Tabla nº3<br />
Sistemas que en la actualidad son compatibles con SHA-2.<br />
Sistemas que son compatibles con SHA-2<br />
GNU/Linux Debian 3.x y 4.x<br />
Ubuntu desde 7.x<br />
Mepis<br />
Microsoft Windows Windows 32 bits<br />
Windows 2000<br />
Windows XP<br />
Windows Vista<br />
Windows Server 2008<br />
Windows 7<br />
Windows 64 bits<br />
Windows Vista<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Windows Server 2008<br />
Windows 7<br />
M<strong>AC</strong> OS Mac OS X, 10.4.x, 10.5.x y 10.6.x (Intel y PPC)<br />
Resumen de los resultados de los ataques a los distintos Algoritmos de Hash Seguros<br />
(SHA), comparando la fuerza ideal de cada algoritmo contra la fuerza residual frente a este<br />
ataque, lo que ilustra el grado de debilitamiento obtenido contra colisiones.<br />
Función Bits Fuerza Ideal de<br />
colisión<br />
Fuerza Residual postataque<br />
de colisión<br />
SHA-0 160 2 80 2 40<br />
SHA-1 160 2 80 2 39<br />
(1)SHA-224 224 2 112 2 39 (a) y 2 9 (b)<br />
(1)SHA-256 256 2 128<br />
2 39 (a) y 2 9 (b)<br />
(1)SHA-384 384 2 192 2 39 (a) y 2 9 (b)<br />
(1)SHA-512 512 2 256<br />
Tabla nº4<br />
2 39 (a) y 2 9 (b)<br />
En la tabla anterior se muestran las funciones de SHA atacadas ilustrando la<br />
reducción de la Fuerza Ideal frente a colisiones, es decir el grado de debilitamiento resultante<br />
en cada uno. (1) Estos algoritmos estándar FIPS 180-2 han sido informalmente agrupados<br />
cono familia SHA-2. (a) Valores con estados iniciales por vuelta desconocidos del registro<br />
(b) Valores con estados iniciales por vuelta conocidos del registro.<br />
Navegadores Web que actualizaron sus códigos para poder emplear el algoritmo SHA-<br />
2, fortaleciendo la seguridad de los sistemas de certificación.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Mozilla Firefox<br />
Internet Explorer 9<br />
Google Chrome<br />
Chromiun<br />
Safari<br />
Opera<br />
Iceweasel<br />
Konqueror,<br />
Midori<br />
AUTORIDADES, ESTANDARES Y APLIC<strong>AC</strong>IONES MIGRADAS A SHA256 ó SUPERIOR<br />
A continuación se dan a conocer las diferentes Autoridades de Certificación que han<br />
implementado algoritmos de cifrado SHA256 y que a su vez han tramitado la publicación de<br />
estos certificados en:<br />
Programa de Certificados Raíz de Microsoft (Internet Explorer), Repositorio de<br />
Certificados Raíz de Mozilla (Firefox), Aplicaciones y Estándares::<br />
<strong>AC</strong> Nombre de la <strong>AC</strong><br />
Tamaño de la<br />
Raíz<br />
Hash<br />
AffirmTrust AffirmTrust Commercial 2048 SHA256<br />
AffirmTrust AffirmTrust Premium 4096 SHA384<br />
AffirmTrust AffirmTrust Premium ECC ECDSA384 SHA384<br />
Česká pošta (Czech<br />
Post, PostSignum)<br />
PostSignum Root QCA 2<br />
Comodo COMODO ECC Certification<br />
Authority<br />
Comodo COMODO RSA Certification<br />
Authority<br />
Comodo USERTrust RSA Certification<br />
Authority<br />
2048 SHA256<br />
ECC384 SHA2<br />
4096 SHA384<br />
4096 SHA384<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Comodo USERTrust ECC Certification<br />
Authority<br />
Entrust Entrust Root Certification<br />
Authority - G2<br />
ECDSA384 SHA384<br />
2048 SHA256<br />
GlobalSign GlobalSign Root CA R3 2048 SHA256<br />
GoDaddy Go Daddy Root Certificate<br />
Authority – G2<br />
GoDaddy Starfield Root Certificate<br />
Authority – G2<br />
2048 SHA256<br />
2048 SHA256<br />
GoDaddy Starfield Services Root – G2 2048 SHA256<br />
Government of The<br />
Netherlands,<br />
PKIoverheid<br />
Government of the<br />
United States of<br />
America, Federal<br />
PKI<br />
República<br />
Bolivariana de<br />
Venezuela,<br />
Superintendencia de<br />
Servicios de<br />
Certificación<br />
Electrónica<br />
(<strong>SUSCERTE</strong>)<br />
I.CA První<br />
certifikační autorita,<br />
a.s.<br />
I.CA První<br />
certifikační autorita,<br />
a.s.<br />
Staat der Nederlanden Root<br />
CA - G2 4096 SHA256<br />
Federal Common Policy CA<br />
Autoridad de Certificación Raíz<br />
de la República Bolivariana de<br />
Venezuela<br />
2048 SHA256<br />
4096 SHA384<br />
I.CA - Standard Certification<br />
Authority 2048 SHA256<br />
I.CA - Qualified Certification<br />
Authority 2048 SHA256<br />
KEYNECTSIS Keynectsis Root CA 2048 SHA256<br />
Microsec e-Szignó<br />
CA<br />
Microsoft<br />
Corporation<br />
Microsec e-Szigno Root CA<br />
2009<br />
Microsoft Root Certificate<br />
Authority 2010<br />
2048 SHA256<br />
4096 SHA256<br />
NetLock Ltd. NetLock Arany (Class Gold) 2048 SHA256<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Főtanúsítvány<br />
NetLock Ltd. NetLock Platina (Class<br />
Platinum) Főtanúsítvány<br />
SECOM Trust<br />
Systems Co. Ltd.<br />
Security Communication<br />
RootCA2<br />
4096 SHA256<br />
2048 SHA256<br />
SwissSign AG SwissSign Gold Root CA - G3 4096 SHA256<br />
SwissSign AG SwissSign Platinum Root CA -<br />
G3<br />
4096 SHA256<br />
SwissSign AG SwissSign Silver Root CA - G3 4096 SHA256<br />
Taiwan-CA Inc.<br />
(TWCA)<br />
TWCA Root Certification<br />
Authority 2<br />
VeriSign VeriSign Universal Root<br />
Certification Authority<br />
4096 SHA256<br />
2048 SHA256<br />
VeriSign thawte Primary Root CA - G3 2048 SHA256<br />
VeriSign GeoTrust Primary Certification<br />
Authority - G3<br />
VeriSign VeriSign Class 3 Public<br />
Primary Certification Authority -<br />
G4<br />
2048 SHA256<br />
ECDSA SHA384<br />
VeriSign thawte Primary Root CA - G2 ECDSA SHA384<br />
VeriSign GeoTrust Primary Certification<br />
Authority - G2<br />
ECC384 ECDSA<br />
Verizon Business Verizon Global Root CA 2048 SHA256<br />
AffirmTrust AffirmTrust Commercial 2048 SHA256<br />
AffirmTrust AffirmTrust Premium 4096 SHA384<br />
AffirmTrust AffirmTrust Premium ECC ECC ECC<br />
COMODO CA<br />
Limited<br />
COMODO ECC Certification<br />
Authority<br />
GeoTrust Inc. GeoTrust Primary Certification<br />
Authority - G3<br />
ECC ECC<br />
2048 SHA256<br />
GlobalSign 2048 SHA256<br />
GoDaddy.com, Inc. Go Daddy Root Certificate<br />
Authority - G2<br />
2048 SHA256<br />
IZENPE S.A. Izenpe.com 4096 SHA256<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Microsec Ltd. Microsec e-Szigno Root CA<br />
2009<br />
NetLock Kft. NetLock Arany (Class Gold)<br />
Főtanúsítvány<br />
Staat der<br />
Nederlanden<br />
Starfield<br />
Technologies, Inc.<br />
Starfield<br />
Technologies, Inc.<br />
Staat der Nederlanden Root<br />
CA - G2<br />
Starfield Root Certificate<br />
Authority - G2<br />
Starfield Services Root<br />
Certificate Authority - G2<br />
2048 SHA256<br />
2048 SHA256<br />
4096 SHA256<br />
2048 SHA256<br />
2048 SHA256<br />
thawte, Inc. thawte Primary Root CA - G2 ECC ECC<br />
thawte, Inc. thawte Primary Root CA - G3 2048 SHA256<br />
VeriSign, Inc. VeriSign Class 3 Public<br />
Primary Certification Authority -<br />
G4<br />
VeriSign, Inc. VeriSign Universal Root<br />
Certification Authority<br />
ESTANDARES Y APLIC<strong>AC</strong>IONES<br />
ECC ECC<br />
2048 SHA256<br />
FIPS Para el Estándar 180-1, sufre una actualización el 01 de agosto<br />
2002, surgiendo el 180-2 el cual añade tres algoritmos hash<br />
adicionales que utilizan grandes tamaño de clave (SHA256,<br />
SHA384 y SHA512).<br />
OPENSSL Actualmente Openssl (Secure Socket Layer) en sus versiones<br />
v0.9 y v1.0, soportan algoritmos SHA256, SHA384 y SHA512<br />
(v1.0).<br />
ADOBE • La suite Flash Player Security incorporó en su biblioteca<br />
criptográfica el algortimo SHA256.<br />
• El producto Flex 3 del Runtime Versions: Flash Player 9,<br />
AIR 1.1, incorporó el paquete mx.utils con Classpublic<br />
class SHA256 .<br />
Tabla nº5<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Proveedores<br />
SITU<strong>AC</strong>IÓN <strong>AC</strong>TUAL - VENEZUELA<br />
Actualmente ambos proveedores, la Fundación Instituto de Ingeniería para el<br />
Desarrollo Tecnológico y Procert, cumplen con la infraestructura tecnológica necesaria para<br />
actualizar al algoritmo de firma de SHA256, debido a que sus respectivos equipos de<br />
dispositivos criptográficos que almacenan, generan y protegen la clave criptográfica manejan<br />
este tipo de algoritmo.<br />
Descripción de los dispositivos criptográficos de los Proveedores de Servicio de<br />
Certificación Electrónica.<br />
Equipo de Hardware criptográfico NetHSM 500, marca NCIPHER. FIPS 140-2 Nivel 3,<br />
capacidad de procesamiento de 2000 peticiones RSA 1024 bits por segundo, soporta SHA-1,<br />
SHA-256, SHA-384 Y SHA-512.<br />
Línea de tiempo<br />
Noviembre 2005<br />
Colisión SHA1<br />
Diciembre 2010<br />
<strong>AC</strong> Raíz SHA384<br />
Septiembre 2010<br />
Notificación a los proveedores<br />
para migrar a SHA256<br />
31 Diciembre 2010<br />
Revocación Certificado<br />
<strong>AC</strong> Raíz SHA1<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
RECOMEND<strong>AC</strong>IONES<br />
Dado lo expuesto con anterioridad, donde se han demostrado que efectivamente el<br />
sha1 posee diversas vulnerabilidades, se establecen algunas recomendaciones:<br />
1. Actualizar a tecnología SHA-256 o superior, debido a las vulnerabilidades descubiertas<br />
en la implementación del algoritmo SHA-1. Siendo SHA-256 uno de los algoritmos de<br />
hash más utilizados en distintas aplicaciones a nivel mundial, se cuenta con soporte<br />
para su implementación en forma nativa.<br />
2. Sistemas operativos y herramientas altamente utilizadas, tanto libres como privativas<br />
(caso de Canaima, Ubuntu, Windows, Adobe, OpenOffice, LibreOffice, Thunderbird,<br />
Aponwao, Arapan, Cunaguaro, Guácharo, Firefox, entre otros), a partir del año 2010<br />
alertan sobre la actualización del algoritmo hacia uno mas robusto, debido a las<br />
vulneraciones de las que ha sido víctima.<br />
3. Con la implementación del Algoritmo SHA-256 (tecnología existente en la Nación), la<br />
Superintendencia de Servicios de Certificación Electrónica, garantiza que cualquier<br />
intento por descifrar la información donde se haya utilizado el algoritmo de hash<br />
vulnerable, es en la práctica casi imposible.<br />
4. Divulgación del estándar FIP 140-2 (FIPS - Federal Information Processing Standard-<br />
estándares federales de procesamiento de la información), titulado como<br />
“Requerimientos de seguridad para módulos criptográficos” creado en el 2001 para la<br />
estandarización de módulos criptográficos en los que incluye componentes hardware y<br />
software basados también en código abierto. Esto motivado a que el FIPS 140-2, hoy<br />
en día es uno de los estándares que ha estado comprometido a actualizaciones,<br />
donde el NIST (Instituto Nacional de Normas y Tecnología - Institute of Standards and<br />
Technology) explícitamente obliga al FIPS-140-2 a ser actualizado cada 5 años.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
5. Promover el uso de hardware con certificación FIP 140-2 tanto en los Proveedores de<br />
Certificación Electrónica (PSET) acreditados ante <strong>SUSCERTE</strong> como en la<br />
Infraestructura de PKI del estado Venezolano. Donde la Certificación FIPS asegura<br />
que el producto en Hardware ha sido revisado en un laboratorio para el cumplimiento<br />
del estándar 140-2, al menos en el nivel uno (1), de los cuatro (4) existentes.<br />
6. No obstante, con el descubrimiento de nuevas tecnologías, existiría un incremento en<br />
la vulnerabilidad de los sistemas de cifrado en Venezuela, en consecuencia<br />
<strong>SUSCERTE</strong> como órgano rector en materia de Certificación Electrónica debe tomar,<br />
las medidas necesarias para fortalecer la confianza y seguridad al Sistema Nacional<br />
de Certificación Electrónica.<br />
7. Para los certificados emitidos utilizando algoritmo de hash SHA-1, se recomienda<br />
sigan vigentes hasta el 31 de Diciembre de 2011, ya sea que caduquen o en caso se<br />
extienda su validez, deban ser revocados.<br />
8. De forma complementaria, y en aras de mitigar vulnerabilidades presentes en los<br />
sistemas criptográficos, se recomienda el empleo de certificados electrónicos con<br />
claves criptográficas de 2048 bits de cifrado para las nuevas emisiones, a partir del 01<br />
de Enero de 2011, debiendo revocar todo certificado con una longitud de clave menor<br />
que no caduque antes del 31 de Diciembre de 2013. Si se diera el caso que los<br />
dispositivos de hardware empleados no aceptan certificados con la longitud de clave<br />
mencionada, pueden ser emitidos certificados con claves de 1536 bits en adelante.<br />
9. Utilizar sistemas y productos fiables que estén protegidos contra toda alteración y que<br />
garanticen la seguridad técnica.<br />
10.Tomar medidas contra la falsificación de certificados y en el caso de la generación de<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
firmas electrónicas, garantizar su confidencialidad durante el proceso de generación y<br />
su entrega.<br />
11. Establecer Common Criteria (criterios comunes para la evaluación de la seguridad<br />
Tecnologías de la Información) en el sistema de infraestructura de clave pública de la<br />
nación así como en la plataforma tecnológica de los Proveedores de Servicios de<br />
Certificación Electrónica (PSET). Se recomienda que se evalúen como requisito<br />
mínimo a partir del EAL2, según los siguientes niveles mostrados a continuación:<br />
EAL1<br />
EAL2<br />
EAL3<br />
EAL4<br />
Nivel básico. Se evalúa la<br />
utilización apropiada de los<br />
algoritmos cripto, pero no su<br />
correcta implantación<br />
Nivel moderado de seguridad.<br />
Se analizan las funciones de<br />
seguridad utilizando<br />
especificaciones funcionales.<br />
Nivel medio de seguridad. Se<br />
analizan las funciones de<br />
seguridad y su diseño a alto<br />
nivel.<br />
Nivel alto de seguridad. Se<br />
analizan las funciones de<br />
seguridad y su diseño a alto y<br />
bajo nivel, su correcta<br />
implantación.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
BIBLIOGRAFIA<br />
RFC-4270. P. Hoffman, B. Schneier, “Attacks on Cryptographic Hashes in Internet<br />
Protocols”, Counterpane Internet Security November 2005.<br />
Xiaoyun Wang1, Yiqun Lisa Yin, and Hongbo Yu. “Finding Collisions in the Full<br />
Sha-1n”. Shandong University, Jinan 250100, China.<br />
Siler Amador Donado, Luz Ángela Quijano Vidal y Edna Marcela Yela Meneses.<br />
“Colisiones en el algoritmo de ciframiento sha-1”. Junio de 2.009.<br />
Javier Jarauta Sánchez. “Seguridad Informática, Capitulo 20: Estándares de<br />
Seguridad”. Universidad Pontificia. Madrid, España<br />
Christophe De Canni`ere, Florian Mendel, and Christian Rechberger. “Collisions<br />
for 70-step SHA-1:On the Full Cost of Collision Search”. Graz University of<br />
Technology. Graz, Austria.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
ANEXOS<br />
A. RFC 4270. Ataques a resúmenes criptográficos en protocolos de Internet<br />
Network Working Group P. Hoffman<br />
Request for Comments: 4270 VPN Consortium<br />
Category: Informational B. Schneier<br />
Counterpane Internet Security<br />
November 2005<br />
Attacks on Cryptographic Hashes in Internet Protocols<br />
Status of This Memo<br />
This memo provides information for the Internet community. It does<br />
not specify an Internet standard of any kind. Distribution of this<br />
memo is unlimited.<br />
Copyright Notice<br />
Copyright (C) The Internet Society (2005).<br />
Abstract<br />
Recent announcements of better-than-expected collision attacks in<br />
popular hash algorithms have caused some people to question whether<br />
common Internet protocols need to be changed, and if so, how. This<br />
document summarizes the use of hashes in many protocols, discusses<br />
how the collision attacks affect and do not affect the protocols,<br />
shows how to thwart known attacks on digital certificates, and<br />
discusses future directions for protocol designers.<br />
1. Introduction<br />
In summer 2004, a team of researchers showed concrete evidence that<br />
the MD5 hash algorithm was susceptible to collision attacks<br />
[MD5-attack]. In early 2005, the same team demonstrated a similar<br />
attack on a variant of the SHA-1 [RFC3174] hash algorithm, with a<br />
prediction that the normally used SHA-1 would also be susceptible<br />
with a large amount of work (but at a level below what should be<br />
required if SHA-1 worked properly) [SHA-1-attack]. Also in early<br />
2005, researchers showed a specific construction of PKIX certificates<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
[RFC3280] that use MD5 for signing [PKIX-MD5-construction], and<br />
another researcher showed a faster method for finding MD5 collisions<br />
(eight hours on a 1.6-GHz computer) [MD5-faster].<br />
Because of these announcements, there has been a great deal of<br />
discussion by cryptography experts, protocol designers, and other<br />
concerned people about what, if anything, should be done based on the<br />
RFC 4270 Attacks on Hashes November 2005<br />
news. Unfortunately, some of these discussions have been based on<br />
erroneous interpretations of both the news and on how hash algorithms<br />
are used in common Internet protocols.<br />
Hash algorithms are used by cryptographers in a variety of security<br />
protocols, for a variety of purposes, at all levels of the Internet<br />
protocol stack. They are used because they have two security<br />
properties: to be one way and collision free. (There is more about<br />
these properties in the next section; they're easier to explain in<br />
terms of breaking them.) The recent attacks have demonstrated that<br />
one of those security properties is not true. While it is certainly<br />
possible, and at a first glance even probable, that the broken<br />
security property will not affect the overall security of many<br />
specific Internet protocols, the conservative security approach is to<br />
change hash algorithms. The Internet protocol community needs to<br />
migrate in an orderly manner away from SHA-1 and MD5 -- especially<br />
MD5 -- and toward more secure hash algorithms.<br />
This document summarizes what is currently known about hash<br />
algorithms and the Internet protocols that use them. It also gives<br />
advice on how to avoid the currently known problems with MD5 and<br />
SHA-1, and what to consider if predicted attacks become real.<br />
A high-level summary of the current situation is:<br />
o Both MD5 and SHA-1 have newly found attacks against them, the<br />
attacks against MD5 being much more severe than the attacks<br />
against SHA-1.<br />
o The attacks against MD5 are practical on any modern computer.<br />
o The attacks against SHA-1 are not feasible with today's computers,<br />
but will be if the attacks are improved or Moore's Law continues<br />
to make computing power cheaper.<br />
o Many common Internet protocols use hashes in ways that are<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
unaffected by these attacks.<br />
o Most of the affected protocols use digital signatures.<br />
o Better hash algorithms will reduce the susceptibility of these<br />
attacks to an acceptable level for all users.<br />
2. Hash Algorithms and Attacks on Them<br />
A "perfect" hash algorithm has a few basic properties. The algorithm<br />
converts a chunk of data (normally, a message) of any size into a<br />
fixed-size result. The length of the result is called the "hash<br />
RFC 4270 Attacks on Hashes November 2005<br />
length" and is often denoted as "L"; the result of applying the hash<br />
algorithm on a particular chunk of data is called the "hash value"<br />
for that data. Any two different messages of any size should have an<br />
exceedingly small probability of having the same hash value,<br />
regardless of how similar or different the messages are.<br />
This description leads to two mathematical results. Finding a pair<br />
of messages M1 and M2 that have the same hash value takes 2^(L/2)<br />
attempts. For any reasonable hash length, this is an impossible<br />
problem to solve (collision free). Also, given a message M1, finding<br />
any other message M2 that has the same hash value as M1 takes 2^L<br />
attempts. This is an even harder problem to solve (one way).<br />
Note that this is the description of a perfect hash algorithm; if the<br />
algorithm is less than perfect, an attacker can expend less than the<br />
full amount of effort to find two messages with the same hash value.<br />
There are two categories of attacks.<br />
Attacks against the "collision-free" property:<br />
o A "collision attack" allows an attacker to find two messages M1<br />
and M2 that have the same hash value in fewer than 2^(L/2)<br />
attempts.<br />
Attacks against the "one-way" property:<br />
o A "first-preimage attack" allows an attacker who knows a desired<br />
hash value to find a message that results in that value in fewer<br />
than 2^L attempts.<br />
o A "second-preimage attack" allows an attacker who has a desired<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
message M1 to find another message M2 that has the same hash value<br />
in fewer than 2^L attempts.<br />
The two preimage attacks are very similar. In a first-preimage<br />
attack, you know a hash value but not the message that created it,<br />
and you want to discover any message with the known hash value; in<br />
the second-preimage attack, you have a message and you want to find a<br />
second message that has the same hash. Attacks that can find one<br />
type of preimage can often find the other as well.<br />
When analyzing the use of hash algorithms in protocols, it is<br />
important to differentiate which of the two properties of hashes are<br />
important, particularly now that the collision-free property is<br />
becoming weaker for currently popular hash algorithms. It is<br />
certainly important to determine which parties select the material<br />
being hashed. Further, as shown by some of the early work,<br />
RFC 4270 Attacks on Hashes November 2005<br />
particularly [PKIX-MD5-construction], it is also important to<br />
consider which party can predict the material at the beginning of the<br />
hashed object.<br />
2.1. Currently Known Attacks<br />
All the currently known practical or almost-practical attacks on MD5<br />
and SHA-1 are collision attacks. This is fortunate: significant<br />
first- and second-preimage attacks on a hash algorithm would be much<br />
more devastating in the real world than collision attacks, as<br />
described later in this document.<br />
It is also important to note that the current collision attacks<br />
require at least one of the two messages to have a fair amount of<br />
structure in the bits of the message. This means that finding two<br />
messages that both have the same hash value *and* are useful in a<br />
real-world attack is more difficult than just finding two messages<br />
with the same hash value.<br />
3. How Internet Protocols Use Hash Algorithms<br />
Hash algorithms are used in many ways on the Internet. Most<br />
protocols that use hash algorithms do so in a way that makes them<br />
immune to harm from collision attacks. This is not by accident: good<br />
protocol designers develop their protocols to withstand as many<br />
future changes in the underlying cryptography as possible, including<br />
attacks on the cryptographic algorithms themselves.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Uses for hash algorithms include:<br />
o Non-repudiable digital signatures on messages. Non-repudiation is<br />
a security service that provides protection against false denial<br />
of involvement in a communication. S/MIME and OpenPGP allow mail<br />
senders to sign the contents of a message they create, and the<br />
recipient of that message can verify whether or not the signature<br />
is actually associated with the message. A message is used for<br />
non-repudiation if the message is signed and the recipient of the<br />
message can later use the signature to prove that the signer<br />
indeed created the message.<br />
o Digital signatures in certificates from trusted third parties.<br />
Although this is similar to "digital signatures on messages",<br />
certificates themselves are used in many other protocols for<br />
authentication and key management.<br />
o Challenge-response protocols. These protocols combine a public<br />
large random number with a value to help hide the value when being<br />
sent over unencrypted channels.<br />
RFC 4270 Attacks on Hashes November 2005<br />
o Message authentication with shared secrets. These are similar to<br />
challenge-response protocols, except that instead of using public<br />
values, the message is combined with a shared secret before<br />
hashing.<br />
o Key derivation functions. These functions make repeated use of<br />
hash algorithms to mix data into a random string for use in one or<br />
more keys for a cryptographic protocol.<br />
o Mixing functions. These functions also make repeated use of hash<br />
algorithms to mix data into random strings, for uses other than<br />
cryptographic keys.<br />
o Integrity protection. It is common to compare a hash value that<br />
is received out-of-band for a file with the hash value of the file<br />
after it is received over an unsecured protocol such as FTP.<br />
Of the above methods, only the first two are affected by collision<br />
attacks, and even then, only in limited circumstances. So far, it is<br />
believed that, in general, challenge-response protocols are not<br />
susceptible, because the sender is authenticating a secret already<br />
stored by the recipient. In message authentication with shared<br />
secrets, the fact that the secret is known to both parties is also<br />
believed to prevent any sensible attack. All key derivation<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
functions in IETF protocols take random input from both parties, so<br />
the attacker has no way of structuring the hashed message.<br />
4. Hash Collision Attacks and Non-Repudiation of Digital Signatures<br />
The basic idea behind the collision attack on a hash algorithm used<br />
in a digital-signature protocol is that the attacker creates two<br />
messages that have the same hash value, causes one of them to be<br />
signed, and then uses that signature over the other message for some<br />
nefarious purpose. The specifics of the attack depend on the<br />
protocol being used and what the victim does when presented with the<br />
signed message.<br />
The canonical example is where you create two messages, one of which<br />
says "I will pay $10 for doing this job" and the other of which says<br />
"I will pay $10,000 for doing this job". You present the first<br />
message to the victim, get them to sign it, do the job, substitute<br />
the second message in the signed authorization, present the altered<br />
signed message (whose signature still verifies), and demand the<br />
higher amount of money. If the victim refuses, you take them to<br />
court and show the second signed message.<br />
RFC 4270 Attacks on Hashes November 2005<br />
Most non-repudiation attacks rely on a human assessing the validity<br />
of the purportedly signed message. In the case of the hash-collision<br />
attack, the purportedly signed message's signature is valid, but so<br />
is the signature on the original message. The victim can produce the<br />
original message, show that he/she signed it, and show that the two<br />
hash values are identical. The chance of this happening by accident<br />
is one in 2^L, which is infinitesimally small for either MD5 or<br />
SHA-1.<br />
In other words, to thwart a hash collision attack in a nonrepudiation<br />
protocol where a human is using a signed message as<br />
authorization, the signer needs to keep a copy of the original<br />
message he/she signed. Messages that have other messages with the<br />
same hash must be created by the same person, and do not happen by<br />
accident under any known probable circumstances. The fact that the<br />
two messages have the same hash value should cause enough doubt in<br />
the mind of the person judging the validity of the signature to cause<br />
the legal attack to fail (and possibly bring intentional fraud<br />
charges against the attacker).<br />
Thwarting hash collision attacks in automated non-repudiation<br />
protocols is potentially more difficult, because there may be no<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
humans paying enough attention to be able to argue about what should<br />
have happened. For example, in electronic data interchange (EDI)<br />
applications, actions are usually taken automatically after<br />
authentication of a signed message. Determining the practical<br />
effects of hash collisions would require a detailed evaluation of the<br />
protocol.<br />
5. Hash Collision Attacks and Digital Certificates from Trusted Third<br />
Parties<br />
Digital certificates are a special case of digital signatures. In<br />
general, there is no non-repudiation attack on trusted third parties<br />
due to the fact that certificates have specific formatting. Digital<br />
certificates are often used in Internet protocols for key management<br />
and for authenticating a party with whom you are communicating,<br />
possibly before granting access to network services or trusting the<br />
party with private data such as credit card information.<br />
It is therefore important that the granting party can trust that the<br />
certificate correctly identifies the person or system identified by<br />
the certificate. If the attacker can get a certificate for two<br />
different identities using just one public key, the victim can be<br />
fooled into believing that one person is someone else.<br />
RFC 4270 Attacks on Hashes November 2005<br />
The collision attack on PKIX certificates described in early 2005<br />
relied on the ability of the attacker to create two different public<br />
keys that would cause the body of the certificate to have the same<br />
hash value. For this attack to work, the attacker needs to be able<br />
to predict the contents and structure of the certificate before it is<br />
issued, including the identity that will be used, the serial number<br />
that will be included in the certificate, and the start and stop<br />
dates of the validity period for the certificate.<br />
The effective result of this attack is that one person using a single<br />
identity can get a digital certificate over one public key, but be<br />
able to pretend that it is over a different public key (but with the<br />
same identity, valid dates, and so on). Because the identity in the<br />
two certificates is the same, there are probably no real-world<br />
examples where such an attack would get the attacker any advantage.<br />
At best, someone could claim that the trusted third party made a<br />
mistake by issuing a certificate with the same identity and serial<br />
number based on two different public keys. This is indeed<br />
far-fetched.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
It is very important to note that collision attacks only affect the<br />
parts of certificates that have no human-readable information in<br />
them, such as the public keys. An attack that involves getting a<br />
certificate with one human-readable identity and making that<br />
certificate useful for a second human-readable identity would require<br />
more effort than a simple collision attack.<br />
5.1. Reducing the Likelihood of Hash-Based Attacks on PKIX Certificates<br />
If a trusted third party who issues PKIX certificates wants to avoid<br />
the attack described above, they can prevent the attack by making<br />
other signed parts of the certificate random enough to eliminate any<br />
advantage gained by the attack. Ideas that have been suggested<br />
include:<br />
o making part of the certificate serial number unpredictable to the<br />
attacker<br />
o adding a randomly chosen component to the identity<br />
o making the validity dates unpredictable to the attacker by skewing<br />
each one forwards or backwards<br />
Any of these mechanisms would increase the amount of work the<br />
attacker needs to do to trick the issuer of the certificate into<br />
generating a certificate that is susceptible to the attack.<br />
RFC 4270 Attacks on Hashes November 2005<br />
6. Future Attacks and Their Effects<br />
There is a disagreement in the security community about what to do<br />
now. Even the two authors of this document disagree on what to do<br />
now.<br />
One of us (Bruce) believes that everyone should start migrating to<br />
SHA-256 [SHA-256] now, due to the weaknesses that have already been<br />
demonstrated in both MD5 and SHA-1. There is an old saying inside<br />
the US National Security Agency (NSA): "Attacks always get better;<br />
they never get worse." The current collision attacks against MD5 are<br />
easily done on a single computer; the collision attacks against SHA-1<br />
are at the far edge of feasibility today, but will only improve with<br />
time. It is preferable to migrate to the new hash standard before<br />
there is a panic, instead of after. Just as we all migrated from<br />
SHA-0 to SHA-1 based on some unknown vulnerability discovered inside<br />
the NSA, we need to migrate from SHA-1 to SHA-256 based on these most<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
ecent attacks. SHA-256 has a 256-bit hash length. This length will<br />
give us a much larger security margin in the event of newly<br />
discovered attacks. Meanwhile, further research inside the<br />
cryptographic community over the next several years should point to<br />
further improvements in hash algorithm design, and potentially an<br />
even more secure hash algorithm.<br />
The other of us (Paul) believes that this may not be wise for two<br />
reasons. First, the collision attacks on current protocols have not<br />
been shown to have any discernible real-world effects. Further, it<br />
is not yet clear which stronger hash algorithm will be a good choice<br />
for the long term. Moving from one algorithm to another leads to<br />
inevitable lack of interoperability and confusion for typical crypto<br />
users. (Of course, if any practical attacks are formulated before<br />
there is community consensus of the properties of the cipher-based<br />
hash algorithms, Paul would change his opinion to "move to SHA-256<br />
now".)<br />
Both authors agree that work should be done to make all Internet<br />
protocols able to use different hash algorithms with longer hash<br />
values. Fortunately, most protocols today already are capable of<br />
this; those that are not should be fixed soon.<br />
The authors of this document feel similarly for new protocols being<br />
developed: Bruce thinks they should start using SHA-256 from the<br />
start, and Paul thinks that they should use SHA-1 as long as the new<br />
protocols are not susceptible to collision attacks. Any new protocol<br />
must have the ability to change all of its cryptographic algorithms,<br />
not just its hash algorithm.<br />
RFC 4270 Attacks on Hashes November 2005<br />
7. Security Considerations<br />
The entire document discusses security on the Internet.<br />
The discussion in this document assumes that the only attacks on hash<br />
algorithms used in Internet protocols are collision attacks. Some<br />
significant preimaging attacks have already been discovered<br />
[Preimaging-attack], but they are not yet practical. If a practical<br />
preimaging attack is discovered, it would drastically affect many<br />
Internet protocols. In this case, "practical" means that it could be<br />
executed by an attacker in a meaningful amount of time for a<br />
meaningful amount of money. A preimaging attack that costs trillions<br />
of dollars and takes decades to preimage one desired hash value or<br />
one message is not practical; one that costs a few thousand dollars<br />
and takes a few weeks might be very practical.<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
B. Informe de los Investigadores de la Universidad de Shadong (China)<br />
donde demuestran los procedimientos matemáticos con los que<br />
generaron colisiones en SHA1 para romper con la seguridad.<br />
Link de descarga: http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf<br />
C. Viabilidad de SHA1<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
D. Proyecto de Colisión SHA1<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
E. Búsqueda de colisiones SHA1<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
F. Ataques de Colisiones SHA1<br />
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público
Av. Andrés Bello, Torre BFC, Piso 13, Sector Guaicaipuro, Caracas – Venezuela<br />
Tlfs. +58 212 5785674 – Fax +58 212 5724932 . http://www.suscerte.gob.ve<br />
De Uso Público