Colisiones, haberlas hay(las). Parte 1.

jueves, 26 de abril de 2018

Coliseo
Proveniente del latín tardío “collisio”, y este a su vez de la unión de “cum” (cuando) y “leadere” (herido). El término colisión puede adoptar múltiples acepciones, siendo la más usual la referida al efecto o acción de chocar, encontrarse con violencia, dos o más entes materiales. También son muy frecuentes las referencias etéreas, como a ideas, o pensamientos contrapuestos.

Su extrema ambigüedad hace que podamos encontrar colisiones en cualquier cosa imaginable, independientemente de su naturaleza o envergadura.

Da igual en qué continente estés leyendo este artículo, el suelo que pisas está sobre una placa tectónica en constante colisión con otra. Con un poco de suerte nunca lo notarás, si lo has llegado a notar alguna vez, ya sabes de lo que hablo.

Da igual que sea de noche o de día, si te asomas por una ventana verás la luz del sol o de otras estrellas, que fue liberada hace minutos o millones de años respectivamente, en la fusión de los núcleos de átomos de hidrógeno y sus isótopos principalmente, al colisionar entre ellos, aplastados por una descomunal fuerza de gravedad. Desde que se descubrió este fenómeno se está intentando imitar: la Organización Europea para la Investigación Nuclear (CERN) ha construido un gigantesco colisionador de hadrones, solo para experimentar. Si el mismo CERN donde Tim Berners-Lee creó el protocolo HTTP, el lenguaje HTML y el sistema de locación de recursos URL, formando así el núcleo de la web, que seguro, estas utilizando para leer estas líneas.

Da igual qué dispositivo estés empleando, ya que, tanto si estás conectado a Internet a través de un cable de red o por radiofrecuencia Wifi, 3G o LTE, todos los datos que has recibido han viajado revueltos en un mar de colisiones de paquetes de red, sin que lleguemos a ser conscientes de ello. Todo esto es gracias a los mecanismos de arbitraje que implementan los protocolos de acceso al medio, como CSMA/CD, siglas en inglés de acceso múltiple con escucha de portadora y detección de colisiones,  utilizado en las redes Ethernet cableadas IEEE 802.3, o su derivado CSMA/CA, siglas en inglés de acceso múltiple por detección de portadora y prevención de colisiones, muy utilizado en aplicaciones inalámbricas como las redes Wifi IEEE 802.11.

Salvo puntuales excepciones, estas colisiones no deberían preocuparnos; pero hay otras que sí, y mucho: las colisiones criptográficas.

Colisiones Criptográficas
En criptografía se denomina colisión al hecho de que dos elementos de entrada diferentes generen un mismo elemento como resultado de aplicar un algoritmo criptográfico.

Este fenómeno aplica a cualquier criptosistema, ya sea de clave simétrica o asimétrica, pero principalmente se da en algoritmos de  hash. De hecho, es matemáticamente predecible, por lo que cada criptosistema define ciertos parámetros, como la longitud de clave a utilizar, para garantizar que no se produzcan colisiones o se resuelva el algoritmo por otros métodos de criptoanálisis en tiempo polinómico, según la capacidad computacional que tecnológicamente esté disponible.

Con solo una vez que se consiga encontrar una colisión, el algoritmo o criptosistema es automáticamente catalogado como “inseguro”, “débil”, o “vulnerable”, y en consecuencia entra en desuso, cuando no directamente deshabilitado o vetado por los protocolos o aplicaciones donde se emplea.

Cualquier vulnerabilidad en la seguridad de un criptosistema pone en riesgo todos los protocolos o aplicaciones que sustente; desde la privacidad en las comunicaciones, hasta la identificación de usuarios o incluso dispositivos, tal y como comentamos en el ElevenPaths Talk sobre Criptografía en IoT

El NIST (National Institute of Standards and Technology), organismo de referencia en cuanto a la estandarización de criptosistemas, define seis categorías para catalogar cada algoritmo y sus longitudes de clave (NIST Special Publication 800-57 Part 1):
  • Approved (Aprobado): El algoritmo y sus longitudes de claves se encuentran especificados en los documentos del NIST o están acreditados por el FIPS (Federal Information Processing Standard) y puede ser empleados sin restricciones.
  • Acceptable (Aceptable): El algoritmo y sus longitudes de clave son seguros para su uso, no conociéndose riesgos de seguridad en ese momento.
  • Deprecated (Obsoleto): El uso del algoritmo y de la longitud de clave es tolerado, pero deben aceptarse algunos riesgos.
  • Restricted (Restringido): El uso del algoritmo o de la longitud de la clave está obsoleto y hay restricciones adicionales requeridas para procesos de protección criptográfica.
  • Legacy-use (Uso heredado): El algoritmo o la longitud de clave puede ser usado para procesar datos previamente protegidos, pero pueden existir riesgos en este proceso.
  • Disallowed (No permitido): El algoritmo o la longitud de clave no son aceptados debido a los riesgos asociados.
Existen otras organizaciones que, de forma similar al NIST, avalan o recomiendan el uso de criptosistemas en base esencialmente de la longitud de clave utilizada, la cual varía en función del tiempo según el incremento de la capacidad computacional. Es conveniente consultar estos valores con regularidad. Una web muy útil para esto es keylength.com.

imagen página web

El MITRE, además de mantener actualizado el listado de vulnerabilidades de seguridad conocidas, “CVE” (Common Vulnerabilities and Exposures), mantiene otros dos repositorios igualmente importantes: el “CWE” y el “CAPEC” para recopilar debilidades y patrones de ataque, ambos explicados en detalle en el blog de ElevenPaths.

Consultar los listados del MITRE constituye una práctica imprescindible, tanto para desarrolladores de software, como profesionales de la seguridad ante cualquier duda sobre algoritmos criptográficos, sus longitudes de clave, o diferentes implementaciones. Dentro de las múltiples debilidades relativas al uso (o carencia) de sistemas criptográficos, destacan:

  • CWE-326: Inadequate Encryption Strength (robustez de cifrado insuficiente)
  • CWE-327: Use of a Broken or Risky Cryptographic Algorithm (uso de algoritmos rotos o con riesgo) 
  • CWE-328: Reversible One-Way Hash (uso de algoritmos de hash reversible)

No obstante, cada vez que se compromete o rompe un algoritmo criptográfico en uso se produce un gran revuelo en la comunidad, apareciendo multitud de noticias que rápidamente se extienden por las redes sociales.

Uno de los casos más sonados es el del algoritmo de hash MD5. Nuestra compañera Julia nos alertaba en el Blog de ElevenPaths allá por 2013, que fue oficialmente roto por el investigador de seguridad Nat McHugh tan solo un año después. Su demostración fue con imágenes en formato JPG, pero desde entonces se han desarrollado diferentes herramientas para crear cualquier colisión de hash MD5, como “evilize” que permite crear colisiones MD5 en archivos ejecutables para Windows y Linux.


Más recientemente, a principios de 2017, los cimientos de la comunidad volvían a temblar. Pese a que el NIST catalogó desde 2011 al algoritmo de hash SHA-1 como “deprecated”, continuaba utilizándose ampliamente en multitud de protocolos de red y otras aplicaciones de seguridad. Hasta que un equipo de investigadores Google, en colaboración con la Universidad CWI de Amsterdam, literalmente lo reventaron al anunciar un método por el cual se podían generar colisiones en un tiempo rozable. Publicaron el whitepaper, compartieron el código en GitHub, e incluso crearon un sitio web shattered.io con todos los detalles, incluyendo como ejemplo dos archivos PDF muy diferentes con el mismo hash SHA-1; esto significó su final.


De un día para otro se tuvo que restringir su utilización a nivel global, en favor de otros algoritmos de hash catalogados “Approved” por en NIST como lo englobados en el conjunto SHA-2 (SHA-224,  SHA-256, SHA-284 y SHA-512) desarrollados por la NSA (National Security Agency) de EEUU. Pero, ¿es suficiente con utilizar alguno de estos algoritmos para “estar” seguros? La respuesta es NO.
Esto depende en gran parte de, “para qué” y “cómo“ se utilicen. Por ejemplo, los algoritmos de hash son ampliamente utilizados para almacenar contraseñas, es decir, en lugar de guardar la contraseña en texto claro, se almacena su hash, para compararlo posteriormente en el proceso de validación de credenciales. Este mecanismo por si solo, fue válido durante un periodo muy corto de tiempo, ya que rápidamente comenzaron a recopilarse en bases de datos los pares “Contraseña  Hash” de forma masiva, permitiendo así realizar búsquedas por hash (inversas), y obtener el texto en claro de la contraseña a la que pertenece el hash consultado.

Existen varias de web públicas que ofrecen estos servicios de forma gratuita. La web del SANS dice tener un 100% de efectividad reverseando hashes MD5 y SHA-1 con una base de datos de poco más de 20 millones de contraseñas. Otras webs como hashes.org o crackstation.net soportan múltiples de algoritmos, disponiendo de bases de datos con hasta 15.000 millones de hashes, que incluso se pueden descargar.

Aunque esta “debilidad” no se puede achacar directamente al propio al algoritmo o su longitud de clave, la mayor parte de métodos tradicionales para almacenar contraseñas son susceptibles de ser atacados mediante la técnica de criptoanálisis conocida como “rainbow tables” (tablas arcoíris), que consiste en disponer de tablas de hashes precalculados, a partir de los cuales se puede llegar a inferir en texto original con un compromiso espacio-tiempo razonable. El proyecto RainbowCrack facilita el software necesario para generar tablas rainbow a discreción, e incluso las vende ya calculadas por un precio que incluye el disco duro que las contiene, ya que pueden llegar a ocupar varios Terabytes.

No obstante, hay una forma muy segura para almacenar el hash de una contraseña que evita estos inconvenientes, y es tan simple como añadir un fragmento generado aleatoriamente en el momento de creación de la contraseña, y que se almacena junto al hash resultante, para poder realizar la operación de verificación. Se denomina SALT, siendo su utilización imprescindible.


En este ejemplo se aprecia el formato con el que se almacenan las contraseñas en PHP. Puede observarse que, además del salt y del hash resultante, se indica el algoritmo utilizado, siendo recomendado emplear un algoritmo de hash “lento”, especialmente indicado para hashear contraseñas como “Bcrypt”, “Scrypt” o “PBKDF2”.

El MITRE identifica en su relación de debilidades “CWE”, algunas de ellas directamente relacionadas con la ausencia de SALT, e incluso con el uso de un SALT predecible:
  • CWE-759: Use of a One-Way Hash without a Salt (uso de algoritmo de hash sin Salt)
  • CWE-760: Use of a One-Way Hash with a Predictable Salt (uso de hash con Salt predecible)

Colisiones de Bitcoin
Los principales organismos reguladores NIST, FIPS, la misma NSA, el MITRE y otros gigantes del sector privado con Google a la cabeza, se preocupan muy mucho por la seguridad de los criptosistemas de uso general, pero…  ¿Quién vela por la seguridad de las criptodivisas?

En la comunidad de ElevenPaths vimos cómo se pueden sustraer bitcoins, incluso de wallets físicos. Si te preocupan tus bitcoins, pásate por la comunidad y déjanos tus dudas.

¿Existirán colisiones en los algoritmos utilizados en Bitcoin? Te lo contaremos todo en la segunda parte, no te pierdas la próxima entrega.

Jorge Rivera
CSA, Chief Security Ambassador

» Colisiones, haberlas hay(las). Parte 2 
» Colisiones, haberlas hay(las). Parte 3
» Colisiones, haberlas hay(las). Parte 4

No hay comentarios:

Publicar un comentario