El primer ataque de colisión a SHA-1 era de esperar

Secured data transfer

En febrero de este año 2017, un equipo de investigadores de Google y del Instituto CWI en Ámsterdam anunciaron que habían sido capaces de generar dos documentos PDF con contenido diferente pero con la misma huella criptogrÔfica o hash , rompiendo así el algoritmo de cifrado SHA-1.

El hecho de que dos documentos compartan el mismo hash puede traducirse en un problema de seguridad importante para los servicios que usan el algoritmo de encriptación SHA-1 (Secure Hash Algorithm) , y que trataré de explicar mÔs adelante. Pero  pongÔmonos en situación antes de empezar.

¿Qué es un hash?

Las funciones hash son herramientas de lo mĆ”s flexibles, y son empleadas en tĆ©cnicas de cifrado modernas. Se usan en multitud de campos y soluciones (como la seguridad de navegadores, la verificación de la integridad de los datos, la gestión de repositorios de códigos, etc.). En tĆ©rminos sencillos, sirven para transformar los datos que se reciben (independientemente de su tamaƱo) en un valor de salida de un tamaƱo fijo (denominado ā€œhuellaā€).

 

Cuentan con diversas propiedades y requisitos para garantizar, por ejemplo, que no se puede deducir el contenido original a partir de la huella, o que los mismos datos de entrada producirƔn siempre el mismo hash. Su caracterƭstica mƔs interesante (y requisito mƔs complejo) es que, en teorƭa, no se puede generar dos o mƔs archivos con la misma huella.

¿Dónde estÔ el problema y por qué debería preocuparnos?

Usar funciones hash nos permite distinguir entre dos archivos diferentes (incluso si la disparidad es mínima).  De ese modo, si un hacker sustituye un archivo por otro con código malicioso sabremos que algo ha pasado con nuestros datos, porque el valor de hash serÔ distinto. Pero  ¿qué pasaría si alguien pudiera generar dos archivos con la misma huella?

sha-1

 

Encontrar dos archivos o documentos de datos con la misma huella, aunque no es viable desde un punto de vista computacional, no es algo imposible. De hecho, pese a que haría falta mucho tiempo para encontrarlos, al final alguien lo haría. A eso se le llama colisión.

Hasta febrero de este año, habíamos estado amparÔndonos en el tiempo que le llevaría a alguien encontrar una colisión.

El tiempo estĆ” de nuestra parte… ĀæO no?

Muchas de las herramientas y enfoques matemÔticos que se emplean en el campo de la seguridad se basan en la cantidad de tiempo que le llevaría a un procesador encontrar una inconsistencia o la solución a un problema. Resulta sencillo averiguar si los enfoques matemÔticos son correctos, y lo cierto es que son bastante útiles. Pero es ingenuo pensar que no hay que cambiarlos nunca y que deben seguirse a rajatabla.

En vista del ritmo al que evoluciona la electrónica y al número de investigadores que tratan de encontrar esas deficiencias, el tiempo que se precisa para desarrollar métodos o encontrar inconsistencias capaces de romper esas herramientas se ha acortado enormemente.

Hay una historia que ilustra perfectamente la falsa percepción que tenemos del tiempo y que nos permite atisbar la necesidad de desarrollar seguridad para software de manera continua. Se trata del desafío RSA-129.

En 1977, Ron Rivest, uno de los padres del algoritmo RSA, publicó en la revista Scientific American un desafío que (según él) tardaría 40 cuatrillones de años en resolverse. Reveló un número RSA-129 y retó a los lectores a factorizarlo en el par de números primos que lo componían. Se tardó sólo 17 años en resolverlo.

¿Y qué pasa con SHA-1? ¿Qué debemos hacer?

SHA-1 es la evolución del algoritmo de huella segura desarrollado por la Agencia de Seguridad Nacional de los Estados Unidos en 1995, hace mÔs de 20 años. Desde entonces, las cosas han cambiado mucho. Las nuevas unidades de procesamiento grÔfico son mil veces mÔs rÔpidas y las técnicas de ataque a las funciones hash se han vuelto mucho mÔs sofisticadas. Dicho esto, era probable que cualquiera de los equipos que trabajaba buscando debilidades en el SHA-1 encontrase algo tarde o temprano.

Pecamos de exceso de confianza y pensamos  que sortear los mecanismos que usamos en materia de seguridad llevarÔ mucho tiempo. Sin embargo, tal y como hemos visto, no siempre es así. La seguridad del software es un asunto que siempre debería preocuparnos, y últimamente puede que mÔs. Por eso, siempre deberíamos estar dispuestos a actualizar viejos protocolos y a instalar los últimos desarrollos (es decir, migrar a SHA-256 o a SHA-3).

En Teldat, somos muy conscientes de la importancia que tiene la seguridad. Por eso, invertimos y desarrollamos recursos que nos permitan implementar y utilizar los protocolos mƔs seguros.

.

Bruno Retolaza

Bruno Retolaza

Bruno Retolaza, Industrial Engineer, is part of bintec elmeg's R&D department. Within this department is part of the IP Protocol Team. He is also specialized in mobile app Development

Related PostsĀ