Criptografia y Ciberpersonaje
Criptografia y Ciberpersonaje
Criptografia y Ciberpersonaje
Métodos de ciberespionaje
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.
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.
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.
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.
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.
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.