Inicio 

/ Blog / Ciberespionaje, criptografía y criptobulos

Ciberespionaje, criptografía y criptobulos

Publicado el 21/11/2013, por Jesús Díaz (INCIBE)

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

 
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.
 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 • 10  años.
9

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").
 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.

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.

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.

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.