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?
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.
.