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.

.


Sobre el autor

Bruno Retolaza
Bruno Retolaza
Bruno Retolaza, ingeniero industrial, es parte del departamento de I+D de bintec elmeg. Dentro de este departamento forma parte del equipo que trabaja sobre protocolo IP. Además, está especializado en desarrollo de aplicaciones móviles

Comparte este post

Tweet about this on TwitterShare on LinkedInShare on Google+Email this to someone