Inicio / Blog / Ciberespionaje, criptografía y criptobulos

Ciberespionaje, criptografía y criptobulos

Publicado el 21/11/2013, por Jesús Díaz (INCIBE)
Ciberespionaje, criptografía y criptobulos

Recientemente, la alarma social debida a presuntos "macroprogramas" de espionaje por parte de diferentes gobiernos está alcanzando niveles casi críticos. Ejemplo de ello es el artículo publicado en The Guardian, resumiendo la opinión de expertos internacionales sobre los efectos que esto puede causar. Entre ellos, empieza a crecer la opinión de que se puede llegar a romper Internet, como consecuencia de que cada país opte por crear su red propia para asegurar la privacidad de su información y la de sus ciudadanos. Ante estas preocupaciones, se han propuesto alternativas tales como cifrar por defecto todo el tráfico Web, tarea a la que se está dedicando el grupo de trabajo HTTPbis, de la IETF, que diseña un descendiente del inseguro protocolo HTTP. Aquí no nos preocuparemos por la certeza o falsedad de estas noticias de ciberespionaje, sobre su alcance o sobre los detalles de las propuestas que pretenden resolver estos asuntos. Más bien, reflexionaremos sobre una cuestión relacionada, únicamente desde la perspectiva de la tecnología actual y las teorías matemáticas que la sustentan. Así, nos preguntamos: ¿Es (im)posible comunicarse de forma "segura"?

Repasando la historia, el espionaje no es nada nuevo, obviamente. Hay un sinfín de estudios que prueban la existencia de estas actividades desde hace siglos, así como de los métodos utilizados para protegerse de ellas. Por ejemplo, la intrincada historia de espionaje que llevó a la Reina Isabel de Inglaterra a ejecutar a su prima, la Reina María de Escocia, que utilizó un método de cifrado débil para comunicar su apoyo a un complot en contra de su prima (ver "The Codebook" de Simon Singh). Y es que, desde la antigüedad, se han utilizado algoritmos criptográficos y esteganográficos como técnicas anti-espionaje. Por resumir, aunque de manera inexacta (ya que estos no eran los únicos motivos), podríamos denominar este tipo de espionaje como espionaje militar o industrial.

No obstante, recientemente hay una creciente preocupación en la sociedad en cuanto a que, además del mencionado espionaje militar o industrial, está produciéndose un espionaje a la población, lo que podría llamarse espionaje social. En efecto, hace un siglo o más, habría parecido imposible para cualquier organización realizar este tipo de espionaje. No obstante, con Internet, esto ha cambiado. En el mundo desarrollado, con estimaciones de alrededor de 6800 millones de teléfonos móviles en 2013, unos 1600 millones de ordenadores personales en 2012 o aproximadamente 2273 millones de usuarios utilizando Internet en 2011, y teniendo en cuenta que somos una sociedad generalmente novata en estos temas, una organización con suficientes recursos puede llegar a obtener mucha información sobre casi cualquier persona. Esto hace que el medio principal para el espionaje social sea Internet, por lo que más que espionaje "clásico", podemos hablar de ciberespionaje.

Métodos de ciberespionaje

Pero, ¿cuáles son los mecanismos principales empleados en el ciberespionaje? Se podrían hacer muchas clasificaciones, pero quizá la más genérica (y que ofrece una diferenciación más clara) sea dividirlos en métodos basados en ingeniería social, basados en ataques a sistemas informáticos o basados en ataques a sistemas criptográficos, siendo su complejidad (normalmente) creciente en ese mismo orden.

Ingeniería social

Los mecanismos de espionaje basados en ingeniería social se centran en las debilidades que son consecuencia directa de la "intervención humana" en los sistemas informáticos. Ejemplos típicos son el uso de contraseñas poco robustas, pero fáciles de recordar (ver, por ejemplo, el reciente caso de Adobe), ataques iniciados con técnicas de spear phishing (como el ataque que utilizaba la red LinkedIn como "cebo" para conseguir información sobre usuarios, o falsas páginas, también de LinkedIn, para introducir malware en los sistemas de víctimas concretas). Aunque centrada en los servicios help desk de las compañías (en lugar de usuarios de a pie, que es lo que nos preocupa ahora), la gráfica mostrada en la Imagen 1, del whitepaper de SANS sobre "Help desk Security and Privacy Survey", muestra que la mayor preocupación de dichos servicios es la ingeniería social.

Principales preocupaciones de los servicios de Help Desk. (Fuente: SANS)

Imagen 1. Principales preocupaciones de los servicios de Help Desk. (Fuente: SANS)

La información conseguida mediante ingeniería social puede ser el fin del ataque en sí mismo, aunque muchas veces también es utilizada como paso inicial de un ataque más complejo, utilizando también mecanismos como los que se verán a continuación.

Cómo evitar estos ataques

La única forma de evitar estos ataques es mantener una vigilancia activa y una actitud crítica respecto a todo lo que se recibe u obtiene a través de fuentes desconocidas o no fiables. Incluso en el caso de fuentes que puedan parecer fiables (como páginas web de bancos o emails de amigos), hay que asegurarse de que los datos que se piden son coherentes con el servicio que se presta y sus condiciones, verificando siempre en la medida de lo posible, la identidad de quien solicita o proporciona la información.

Ataques a sistemas informáticos

Otro método de ataque, también debido originalmente a errores humanos, son los debidos a vulnerabilidades en los sistemas informáticos. Esto es, fallos en el diseño o la implementación de los diferentes programas que componen un sistema. Entre estos, hay multitud de subtipos y clasificaciones: dependiendo de a qué propiedad de seguridad afectan (confidencialidad, disponibilidad, etc.), de la facilidad de explotación (remota, local, sin autenticación necesaria…), o la complejidad técnica del ataque, entre otros. Como es normal, con el creciente número de sistemas proporcionando servicios, también ha aumentado el número de errores (ya que, por desgracia, hacer más programas no siempre equivale a hacerlos mejor). Esta evolución se muestra en la gráfica incluida en la Imagen 2, que resume el número de vulnerabilidades publicadas en la base de datos CVE (Common Vulnerability Exposure) de la corporación Mitre (nótese que los datos del año 2013 disponibles solo van hasta principios de noviembre).

 Evolución de CVEs. (Fuente de datos: CVE database)

Imagen 2. Evolución de CVEs. (Fuente de datos: CVE database)

 

Más problemáticas son las conocidas vulnerabilidades de zero-day. Su utilidad "ofensiva" ha quedado patente desde la aparición de las APTs (Stuxnet, Flame, Aurora…). Como resultado, mientras su reporte es recompensado en el llamado white market por precios de entre $2.000 y $5.000, en el gray market alcanzan valores de hasta $200.000 (o incluso hasta $500.000, como una reciente Zero Day que afectaba a iOS). Estos elevados costes respaldan la teoría de que las mencionadas APTs están soportadas por estados, ya que estos cuentan con mayores recursos económicos. La propia naturaleza de las Zero Days probablemente complique realizar estimaciones precisas sobre cuántas existen. No obstante, la Imagen 3, de Symantec, muestra el número de vulnerabilidades de este tipo encontradas entre 2006 y 2011.

Número de Zero Days entre 2006 y 2011. (Fuente: Symantec)

Imagen 3. Número de Zero Days entre 2006 y 2011. (Fuente: Symantec)

Cómo evitar estos ataques

Por parte de los usuarios de aplicaciones y sistemas, la única opción posible es ser consciente de este tipo de ataques y mantener versiones actualizadas de todos sus sistemas, ya que los fabricantes y desarrolladores suelen publicar periódicamente parches para estos fallos de seguridad (o puntualmente para vulnerabilidades críticas, como las Zero Days).

Desde el punto de vista de los desarrolladores, lo primero que hay que decir es que, en la práctica, es imposible crear programas que no tengan vulnerabilidades (al menos para los de mediano o gran tamaño). No obstante, el número de vulnerabilidades y su gravedad puede minimizarse notablemente mediante la implantación de metodologías de diseño y desarrollo que mantengan una especial atención en la seguridad del producto. Ésta debería ser, por lo tanto, una característica requerida, no únicamente deseable. Actualmente existen varias guías de buenas prácticas y metodologías para el diseño de software y protocolos seguros, como la serie Common Criteria for Information Technology Security Evaluation o el proceso SDL de Microsoft. También, aunque es un problema de gran complejidad, hay herramientas que verifican si existen vulnerabilidades en el código producido. Un listado bastante completo está disponible a través del proyecto SAMATE (en el que colaboran el departamento de Homeland Security y el NIST, de Estados Unidos). Otras herramientas, como ProVerif o Isabelle, analizan abstracciones formales de protocolos o programas, detectando si existen errores de diseño que afecten a los requisitos de seguridad.

Ataques a sistemas criptográficos

El siguiente tipo de ataques, probablemente los de mayor complejidad, son los que se centran en los criptosistemas utilizados para proteger la información, ya sea mientras está en tránsito o cuando es almacenada o procesada. En el mundo de la criptología, esto se conoce generalmente como métodos de criptoanálisis. De nuevo, hay varias posibles clasificaciones y tipos de criptoanálisis. Éstos se pueden dividir en función de la información disponible para el atacante (cipher-text only, chosen cipher-text, chosen plain-text…). También se pueden clasificar en función de la estrategia de ataque: por ejemplo, los ataques de tipo Meet In The Middle, o MITM (no confundir con Man In The Middle, que es más bien un ataque sobre protocolos, por lo que podría también pertenecer a los ataques a sistemas informáticos y protocolos), donde el atacante realiza un balance entre espacio (memoria necesaria) y tiempo (en función de la capacidad de cómputo requerida) que le permita llegar a un punto de equilibrio que minimice el coste total del ataque. Otra estrategia de ataque son los conocidos como side-channel attacks, que se basan en la observación de propiedades “físicas” del criptosistema, como el tiempo de cómputo necesario o la temperatura que alcanza el procesador. Finalmente, quizá el más conocido de todos, es el ataque por fuerza bruta, es decir, probar todas las posibles claves hasta llegar a la correcta. De hecho, este último ataque es el que se suele utilizar como referencia para determinar si un criptosistema se ha roto o no.

Estrictamente, si un método de criptoanálisis es comparativamente menos costoso que un ataque de fuerza bruta, el criptosistema se puede considerar roto. No obstante, el valor específico de esta relación es relativo y no hay una regla general para determinarlo (quizá, si la reducción obtenida en la seguridad del criptosistema hace el ataque aplicable en un entorno realista, por ejemplo, en tiempo real). Para hacernos una idea del tiempo requerido por un ataque por fuerza bruta sobre un algoritmo criptográfico considerado seguro, podemos ver la siguiente tabla, del libro “Applied Cryptography” de Bruce Schneier, donde también se muestra el coste económico del hardware necesario. Aunque esta tabla utiliza como referencia hardware del año 1995, esta proporción se mantendría para hardware actual, utilizando claves unas decenas de bits más largas. Datos más recientes pueden conseguirse en la Web de NetAction (2001) o de Richard Clayton (también 2001). Para poner en contexto las cifras mostradas en la tabla incluida en la Imagen 4, la estimación actual más precisa de la edad del Universo ronda los 13,8 • 109 años.

Tiempo estimado de ataques por fuerza bruta en 1995. (Fuente: Bruce Schneier “<em>Applied Cryptography</em>”)

Imagen 4. Tiempo estimado de ataques por fuerza bruta en 1995. (Fuente: Bruce Schneier “Applied Cryptography”)

Adicionalmente, esta tabla se refiere a criptosistemas simétricos (es decir, los que utilizan la misma clave para cifrar y descifrar). Si nos centramos en criptosistemas asimétricos (los que usan distintas claves para cifrar y descifrar), podemos utilizar como referencia la tabla mostrada en la Imagen 5, con equivalencias entre la longitud de clave pública necesaria para proporcionar la misma seguridad que una clave simétrica de una determinada longitud (tabla extraída también del libro "Applied Cryptography").

Equivalencias de seguridad entre claves de criptosistemas simétricas y asimétricas. (Fuente: Bruce Schneier "Applied Cryptography")

Imagen 5. Equivalencias de seguridad entre claves de criptosistemas simétricas y asimétricas. (Fuente: Bruce Schneier "Applied Cryptography")

En este aspecto, cabe mencionar en qué se basa la seguridad de los criptosistemas asimétricos (también conocidos como de clave pública). Dado que una de las claves utilizadas en estos sistemas es públicamente conocida, su seguridad no puede basarse en su secreto, sino en la dificultad de computar la clave privada asociada a partir de los parámetros públicamente conocidos. Por ello, los criptosistemas asimétricos están basados en problemas matemáticos que requieren un coste muy elevado en función del tamaño de los parámetros de entrada (en este caso, de la longitud de la clave). Estos problemas se conocen como problemas NP (Non-deterministic Polynomial-time), y su estudio en las últimas décadas ha dado lugar, entre otros factores, a la que probablemente sea la época criptográfica más fructífera de la historia. Entre los problemas más conocidos dentro de esta categoría están, por ejemplo, la factorización de enteros, el cálculo de logaritmos discretos o el problema de los raíces cuadradas módulo n. Es destacable también que, dentro de estos problemas, los hay de mayor o menor complejidad, ofreciendo por lo tanto mayores niveles de seguridad con claves de una menor longitud. Un ejemplo perfecto, y que en los últimos años ha venido provocando importantes cambios en la comunidad, es la criptografía basada en curvas elípticas. La tabla incluida en la Imagen 6, de la Web de la NSA, muestra las equivalencias entre la seguridad proporcionada por criptosistemas simétricos, asimétricos "clásicos" (RSA o DH) y asimétricos basados en curvas elípticas. Se puede observar que el resultado es sorprendente.

Equivalencias de seguridad entre claves de criptosistemas simétricos, asimétricos y asimétricos basados en curvas elípticas. (Fuente: NSA "The Case for Elliptic Curve cryptography").

Imagen 6. Equivalencias de seguridad entre claves de criptosistemas simétricos, asimétricos y asimétricos basados en curvas elípticas. (Fuente: NSA "The Case for Elliptic Curve cryptography")

Para consultar más equivalencias, la Web www.keylength.com/en/compare, de BlueKrypt, ofrece una calculadora online, configurable para varios criptosistemas e incluso teniendo en cuenta las estimaciones de hasta cuando una configuración determinada será (previsiblemente) segura.

Entonces ¿la criptografía lo resuelve todo?

Según lo comentado en el apartado anterior, parece que siempre que se cifren los datos con un criptosistema considerado seguro utilizando una longitud de clave aceptable, estos serán irrecuperables para cualquiera que no disponga de la clave apropiada para descifrarlo. No obstante, esto no tiene por qué ser así de forma directa. Veamos por ejemplo la Imagen 7.

Logo de INTECO cifrado con un criptosistema en modo ECB.

Imagen 7. Logo de INTECO cifrado con un criptosistema en modo ECB.

En este caso, el logo del INTECO (la mitad superior de la imagen) ha sido cifrado utilizando un criptosistema de clave simétrica en modo ECB (Electronic Codebook), que es un modo de funcionamiento para cifrados en bloque mediante el cual el texto plano se divide en bloques de un tamaño fijo que son cifrados de manera completamente independiente. El resultado es el mostrado en la mitad inferior de la imagen. Salta a la vista que, aunque evidentemente la imagen cambia, se sigue leyendo perfectamente el contenido principal. O, por ejemplo, el típico error al utilizar métodos de cifrado de flujo, transmitiendo distintos textos cifrados utilizando la misma clave, como el reciente caso de WhatsApp, o incluso enviando el texto cifrado junto con el correspondiente texto plano (lo cual permite derivar directamente la clave), como se hacía en una de las modalidades de autenticación del protocolo WEP, permitiendo falsas autenticaciones.

La conclusión es, por lo tanto, que no basta con usar un criptosistema robusto, también hay que saber usarlo.

¿Se ha roto SSL? ¿Se ha roto la infraestructura PKI?

De forma paralela a las noticias de espionaje por parte de gobiernos, han crecido también los rumores de ruptura de los métodos de cifrado que antes tratábamos como seguros, como los utilizados en el protocolo SSL/TLS o para implementar las PKI (Public Key Infrastructures, o Infraestructuras de Clave Pública). Algunas de estas noticias adquirían un tono dramático que podría alarmar a cualquier persona inexperta en el campo, ya que, si se rompe SSL o las PKIs, ¿cómo podremos comunicarnos de forma segura? Las consecuencias serían mucho peores que las que se pronosticaban para el Efecto 2000. La buena noticia es que los algoritmos de cifrado seguro que se utilizan en la actualidad no están rotos, y los ataques conocidos no son en realidad sobre los algoritmos en sí mismos, sino sobre sus implementaciones o sobre los sistemas que los usan, como el popular ataque del "Hacker de Comodo" o el reciente ataque BREACH sobre SSL. Los criptosistemas serán seguros mientras se sigan basando en estos algoritmos, a menos que se produzca el descubrimiento que quizá haya mantenido más ocupados a los matemáticos teóricos en las últimas décadas (y que la respuesta sea "sí"). Este problema es el famoso ¿P=NP? Como hemos mencionado antes, los criptosistemas asimétricos se basan en problemas de tipo NP, y la pregunta anterior se refiere a si los problemas del tipo P (Polinomiales) y los del tipo NP (No Polinomiales) son equivalentes. Al contrario que los problemas NP, un problema del conjunto P, es resoluble de forma más bien eficiente. La clave está en un subconjunto de los problemas NP, conocidos como NP-completos. Estos problemas son los de mayor dificultad dentro del conjunto NP (parte también del conjunto conocido como NP-duro), y son los que se suelen utilizar para el diseño de criptosistemas. La Imagen 8, de la Wikipedia, muestra mediante diagramas de Euler las consecuencias de las dos posibles respuestas a la pregunta anterior, en términos de cómo se reorganizarían los conjuntos P y NP.

Efectos de las posibles respuestas a ¿P=NP? (Fuente: Wikipedia)

Imagen 8. Efectos de las posibles respuestas a ¿P=NP? (Fuente: Wikipedia)

Una característica principal de los problemas NP-completos es que se puede obtener un algoritmo de resolución para cualquier problema del conjunto NP utilizando un algoritmo que resuelva un problema del tipo NP-completo. De esta forma, si se encontrase un algoritmo eficiente para resolver un problema de tipo NP-completo, automáticamente todos los problemas del conjunto NP tendrían un algoritmo eficiente para su resolución. Esto tendría unas consecuencias dramáticas para la tecnología que soporta Internet. La noticia menos buena es que nunca podremos saber con total certeza los avances científicos que tienen a su disposición las agencias de inteligencia. Ejemplo de ello es el caso del descubrimiento de la criptografía asimétrica. Mientras que la historia "oficial" es que ésta fue descubierta por Diffie y Hellman, influenciados por Merkle, hacia 1976. No obstante, después de que varios documentos secretos fueran desclasificados en 1997, ahora sabemos que ya en el año 1969, el GHCQ llegó a una conclusión equivalente de la mano de James Ellis, produciendo un criptosistema de clave pública hacia 1973 con la colaboración de Clifford Cocks y Nick Patterson. Por lo tanto, siempre cabe la posibilidad de que haya habido algún breakthrough del que todavía no tengamos conocimiento.

¿Es (im)posible comunicarse de forma segura?

Para terminar, conociendo los problemas que pueden permitir a terceros acceder a información privada, y habiendo dado unas pinceladas de la teoría que hay detrás de los algoritmos que integran los sistemas actuales, volvemos a la pregunta original: ¿Es (im)posible comunicarse de forma "segura"? La respuesta rápida es que sí es posible, aunque con varios "peros". La explicación larga a los distintos "peros" es un resumen de lo que hemos visto hasta ahora. El primer “pero” somos nosotros mismos. Para protegernos de nosotros mismos, debemos ser conscientes de ello y evitar facilitar información que pueda ser utilizada para atacar algún sistema mediante ingeniería social. El segundo son los desarrolladores de la tecnología que usamos y es que, aunque lo que estemos utilizando sean máquinas y programas dentro de máquinas, éstos han sido creados por humanos, y por lo tanto tienen fallos. La solución a este segundo “pero” es mantenernos al tanto de los parches de seguridad que afectan a los sistemas que usemos, y valorar también la fiabilidad del fabricante o desarrollador (por ejemplo, el eterno debate de software libre vs. software cerrado). El tercer “pero” y quizá el más oscuro, es el relativo a la criptografía subyacente, y se refiere a la posibilidad de que existan avances científicos que permitan resolver la pregunta ¿P=NP? Este último punto, en caso de ser cierto, daría al traste con la mayor parte de los sistemas actuales. No obstante, al menos de momento, éste parece ser el menos probable de los tres problemas, por lo que debemos centrar nuestra atención en los dos primeros. También en este último punto, cabe destacar que, para información sensible (qué es o no sensible dependerá de la situación concreta), se deberán aplicar en muchos casos mecanismos criptográficos adicionales. Por ejemplo, enviar información confidencial mediante sistemas de correo electrónico “convencionales” y considerar que sólo lo leerá su destinatario lícito, es un error común, ya que los emails viajan sin cifrar en muchos tramos de su recorrido. En este caso ilustrativo, habría que cifrar la información previamente, por ejemplo, mediante el plugin Enigmail para Thunderbird y Seamonkey y, como se ha dicho anteriormente, usando un criptosistema adecuado.