Está en la página 1de 20

Diseño de Protocolos Criptográficos de

Autenticación
Oscar Delgado
S21sec

Resumen
De las premisas consideradas básicas para obtener sistemas de comu-
nicación seguros, confidencialidad, integridad, autenticación y no repudio,
la estrella es, sin duda, la primera de ellas, obtenida habitualmente uti-
lizando métodos de cifrado. Estos métodos son fáciles de utilizar y son
bien entendidos por los desarrolladores que los necesiten, pero no ocurre
ası́ con la autenticación que es, al menos, tan importante como las otras.
En este artı́culo trataremos de exponer los conceptos básicos sobre el di-
seño de protocolos de autenticación, sus puntos débiles y cómo evitar los
errores más comunes.

1. Introducción
Cualquier libro de criptografı́a [19][15] comienza enumerando los requisitos
básicos exigibles a un sistema seguro de intercambio de información. Los más
importantes son los de:

Confidencialidad: Caracterı́stica que asegura que la información en tránsi-


to es ininteligible para aquellas partes no autorizadas. El método más ha-
bitual de conseguir este objetivo es a través de algoritmos de cifrado, bien
sea de clave secreta o pública.
Integridad: La integridad nos asegura que los datos no han sido modifi-
cados en tránsito y que, por tanto, llegan al destinatario exactamente igual
que fueron enviados. Nótese que la información ha podido ser capturada
y/o examinada: sólo podemos estar seguros de que no ha sido alterada. La
forma más habitual de asegurar la integridad es utilizando firmas digitales
o funciones hash con clave.
Autenticación: La autenticación hace referencia a la capacidad de ase-
gurar el origen y destino de la información, evitando suplantaciones. Es
un término que suele equipararse al de identificación, aunque éste último
es más usual para referirse a personas fı́sicas. Los mecanismos habitua-
les para conseguir identificación son los biométricos, mientras que para la
autenticación de información se utilizan firmas digitales.
No repudio: Por último, el no repudio sirve para evitar que una de las
partes se desdiga, negando que ha enviado o recibido alguna información.
De nuevo esta caracterı́stica se consigue a través del uso de firmas digitales.

1
Existen otros requisitos deseables según las circunstancias, como la disponi-
bilidad de recursos, el anonimato o el sellado de tiempo, pero estas cuatro se
consideran el conjunto mı́nimo imprescindible para hablar de un sistema seguro.
Tradicionalmente se ha creido que la más importante es la confidencialidad;
sin duda es importante, pero a menudo se ha sobrevalorado su utilidad. Sin una
autenticación adecuada, un protocolo que utilice cifrado puede ser completamen-
te inútil. El problema puede surgir en la fase del diseño, debido a que incluir
confidencialidad en un protocolo es relativamente sencillo: basta con elegir un
tipo de clave adecuado (secreta o pública), una longitud de clave suficiente y,
por último, un algoritmo que cifre la información. Sin embargo, incluir la auten-
ticación de las partes en la ecuación puede no ser tan sencillo. En este artı́culo
trataremos de explicar porqué.

1.1. Notación
En el resto del artı́culo utilizaremos la siguiente notación. Las partes impli-
cadas en un protocolo serán conocidas como agentes, y serán denotadas como
A y B. Siempre asumiremos un canal de comunicación inseguro, con lo que
existirá la posibilidad de que ésta sea monitorizada y/o interceptada por un
atacante, E. Nótese que los agentes no son personas fı́sicas necesariamente. De
hecho, la mayorı́a de las veces serán ordenadores o procesos en un sistema ope-
rativo. La siguiente tabla resume el resto de sı́mbolos que utilizaremos:

Sı́mbolo Significado
{M }k Mensaje M cifrado con la clave simétrica k.
{M }PB Mensaje M cifrado con la clave pública de B.
[M ] Hash sin clave del mensaje M.
[M ]k Hash con clave k del mensaje M.
, Concatenación

2. Tipos de ataques más comunes


Antes de estudiar cómo resolver adecuadamente los problemas, vamos a des-
cribir éstos en detalle. Un ataque a un sistema de información, que técnicamente
se define como la materialización de una amenaza, es una condición del entorno
que, bajo determianadas circunstancias, podrı́a dar lugar a una violación de al-
guna de las premisas de seguridad que hemos visto: confidencialidad, integridad,
autenticación o disponibilidad.
Se han propuesto multitud de taxonomı́as para clasificar los posibles ataques
a sistemas de información [20, 1]. Por ejemplo, Stallings define cuatro grandes
categorı́as:
1. Interrupción: El recurso de un sistema es destruido o se vuelve no dispo-
nible. Ejemplos de este ataque podrı́an ser la destrucción de un elemento
hardware, como un disco duro, el corte de una linea de comunicación o el
borrado completo de una base de datos.
2. Interceptación: Una parte no autorizada consigue acceso a un recurso.
Un ejemplo tı́pico serı́a la captura de tráfico en una red, o la copia de

2
Figura 1: Clasificación de ataques de red. A y B son las partes legı́timas de la
comunicación y E, el atacante.

archivos o programas de un disco duro.


3. Modificación: Una parte no autorizada no sólo consigue acceso al recurso,
sino que es capaz de modificarlo de algún modo. Ejemplos: cambio en los
contenidos de un fichero, modificación del funcionamiento de un programa
o la alteración de los datos transferidos por una red.
4. Generación: Una parte no autorizada inserta objetos falsos en el sistema.
Por ejemplo, generación de mensajes con origen falseado en una red, o la
inserción de nuevos registros en una base de datos o fichero.
Todos los ataques conocidos a dı́a de hoy encajan en alguna o varias de las
categorı́as anteriores. Aunque por supuesto existen otras clasificaciones, como
las basadas en el entorno en el que se producen (una red de comunicación,
un sistema operativo), el objetivo de los ataques o los medios utilizados. Por
ejemplo, en la figura 1 se clasifican los posibles ataques de red según la taxonomı́a
anterior.
Sin embargo, no todos son igual de populares o utilizados. Analicemos los
más usuales.

2.1. Ataques de suplantación o man-in-the-middle


Este tipo de ataques son una categorı́a genérica consistente en la existencia
de un atacante, E, con capacidad para monitorizar, examinar y/o modificar la

3
comunicación entre las partes A y B. Esta capacidad, que puede parecer mucha
a primera vista, no es ni más ni menos la que tiene cualquier persona conectada
a Internet. Existen muchas variantes de este ataque, a distintos protocolos y
para distintos propósitos, ası́ como ataques pasivos y activos. Veamos algunos
ejemplos conocidos.

2.1.1. Ataques MITM al protocolo Diffie-Hellman


El protocolo de establecimiento de claves Diffie-Hellman, en su versión básica
sin autenticación de las partes, es vulnerable a un ataque MITM ya clásico.
En pocas palabras, el protocolo Diffie-Helman [6] permite que dos partes
que no han tenido comunicación previa puedan establecer una clave simétrica,
llamada de sesión, sobre un canal inseguro, como puede observarse en la tabla
1.

Protocolo Diffie-Hellman, establecimiento de clave.

1. Configuración: Se eligen un primo p y un generador α de Z∗p , el conjunto de


los números menores de p, de forma que 2 ≤ α ≤ p − 2. Un generador α es,
precisamente, eso: un número capaz de generar todos elementos del grupo. Ası́,
Z∗p = {αi mod n | 0 ≤ i ≤ φ(n) − 1}.

2. Mensajes del protocolo:


A → B : αx mod p (1)
A ← B : αy mod p (2)
donde x e y son números aleatorios elegido por A y B respectivamente, de
forma que 1 ≤ x, y ≤ p − 2.

3. Establecimiento de clave: Para establecer la clave simétrica común k, A


x y
calcula k1 = (αy ) mod p y B, por su parte, k2 = (αx ) mod p. Claramente,
k1 = k2 = k.

Cuadro 1: Protocolo Diffie-Hellman de intercambio de claves

De esta forma, aunque un atacante E intercepte alguno de los mensajes, no


puede calcular k, pues para eso necesitarı́a deshacer la exponenciación módulo p.
Sin embargo, si toma un papel activo, modificando el contenido de los mensajes,
entonces sı́ es capaz de romper el protocolo. Para ello debe generar dos números
aleatorios x0 e y 0 , equivalentes a x e y, con los mismos criterios que hemos visto
(recordemos que p y α son públicos). A continuación:
0
1. E intercepta αx y lo reemplaza por αx . También intercepta la exponen-
0
ciación de B y la cambia por αy .
0 0
2. Ası́, A generará la clave de sesión kA = αxy y B obtiene kB = αx y .
Claramente, E es capaz de calcular ambas claves.

3. A partir de ese momento, para obtener la comunicación en claro, E lee


el tráfico de A, cifrado con kA , lo descifra, lo cifra de nuevo con kB y lo

4
reenvı́a a B. Por supuesto, realiza la misma operación en la comunicación
en sentido inverso. El resultado es que A y B no tienen forma de detectar
el ataque y creen estar comunicándose de forma segura.

Este ataque tiene implicaciones más profundas de lo que podrı́a parecer


a primera vista, ya Diffie-Hellman se que utiliza como base en multitud de
protocolos muy conocidos y utilizados hoy en dı́a, como SSL [4] o IPSec. De
hecho, el ataque que acabamos de ver, combinado con uno de envenenamiento
ARP o DNS, es directamente aplicable a SSL, incluso cuando hay autenticación
del servidor. La razón no es exclusivamente técnica, sino más bien un conjunto
de circunstancias que desembocan en una deficiente gestión por parte de los
sistemas operativos de los errores que se producen durante la ejecución del
protocolo. Por ejemplo, un usuario que utilice una navegador para conectarse a
su banca electrónica favorita y esté siendo vı́ctima de este ataque, sólo verı́a un
mensaje advirtiéndole de que existen problemas para verificar el certificado del
sitio que trata de visitar, parecido al mostrado en la siguiente figura:

Figura 2: Error que muestra Internet Explorer cuando no se verifica el certificado


del servidor.

Ahora bien, ¿cuánta gente darı́a marcha atrás automáticamente y verificarı́a


a mano la huella digital del certificado presentado por el servidor y de la CA
que lo firma?. Es más, ¿cuánta gente sabe qué demonios es la huella digital1 ?.

2.2. Ataques de repetición y reflexión


El ataque anterior a Diffie-Hellman es activo, en el sentido de que necesita
modificar los mensajes intercambiados. Sin embargo, en ocasiones basta con
reenviar ciertos mensajes en el momento adecuado para conseguir los mismos
resultados.
Ası́, cuando un atacante reenvia información de una ejecución anterior de
un protocolo al mismo o distinto destino hablamos de un ataque de repetición.
Estos ataques suelen distinguirse de los de reflexión, que “reflejan” la informa-
ción, durante la ejecución del protocolo, de un origen a un destino distinto del
legı́timo.
1 También conocido como fingerprint. No es más que un hash MD5 o SHA1 del certificado,

que se publica en el sitio Web de la Autoridad Certificadora pertinente.

5
Figura 3: Ataque de amplificación

Un ejemplo de este último tipo de ataques es el conocido Problema del Gran


Maestro de Ajedrez. En este escenario, un jugador amateur de ajedrez podrı́a
incrementar espectacular y fraudulentamente sus puntuaciones embaucando a
dos buenos jugadores. Para ello, sólo tendrı́a que jugar una partida contra uno
de ellos con piezas blancas, por ejemplo, y con negras contra el otro jugador.
Luego bastarı́a con repetir los movimientos de negras del primer jugador en
la partida del segundo y viceversa. De esta forma, dos de los tres resultados
posibles, victoria, tablas o derrota, incrementarı́an su puntuación.

2.2.1. Ataques y Factor de amplificación


Un ejemplo concreto de los ataques de reflexión, aunque no es exclusivo de
los protocolos criptográficos, son los conocidos como ataques de amplificación.
Su objetivo es generar una denegación de servicio y se llevan a cabo creando
peticiones elegidas especı́ficamente y enviándolas a un servidor, falseando su
origen para que parezca provenir de la parte que se pretende atacar. De esta
forma, cuando el servidor responda, y dado que la respuesta es mucho mayor
en tamaño que la petición, es fácil saturar los recursos de la vı́ctima, tanto de
ancho de banda como de proceso de CPU, como puede verse en la figura 3.
Esa diferencia de tamaño entre el mensaje enviado y el recibido es conocido
como factor de amplificación y es una caracterı́stica poco conocida que habitual-
mente no se tiene en cuenta en el diseño de un nuevo protocolo. Exactamente se
define como la relación entre la cantidad de información enviada por el cliente y
la devuelta por el servidor. Esta información se puede medir en cualquier unidad
pero, dado el tamaño habitual de los mensajes en una red tı́pica, normalmente
se utilizan los bytes. Ası́, el factor de amplificación fα , se calcula de la siguiente
forma:
bytesRecibidos
fα = (1)
bytesEnviados
Lógicamente, lo deseable es que el factor de amplificación sea lo más pequeño
posible. Esto significará que nuestro protocolo produce respuestas pequeñas, con
el consiguiente ahorro de ancho de banda. Si esto no es posible, hay que procurar

6
que, como mı́nimo, fα esté alrededor de 1, de forma que el protocolo no pueda
ser utilizado en ataques de amplificación.
Como ejemplo podemos citar al protocolo DNS. El tamaño de las solici-
tudes y de las respuestas puede variar enormemente, pero imaginemos una
petición tı́pica de resolución de nombres, que ocupe 68 bytes. Una respuesta
normal puede generar fácilmente alrededor de 690 bytes, de forma que tenemos
fα (DN S) = 690 68 = 10,1. Como vemos, fα es mucho mayor que 1 y esto posibilita
un ataque de amplificación en este protocolo [21].
De hecho, utilizando los nuevos RFCs, con soporte para IPv6 o DNSSEC, se
han descrito posibles respuestas de hasta 4050 bytes, lo que eleva el factor de
amplificación hasta 60. La situación se agrava si tenemos en cuenta que, según
el CERT, el 80 % de los servidores de nombre del mundo permiten peticiones
recursivas. Tanto es ası́ que estas técnicas ya se han utilizado ataques DDoS2
recientemente, donde realizando sólo 5 peticiones por segundo a una lista de
20.000 servidores de nombres se generaron hasta 3Gbps (!) de tráfico en la
vı́ctima.
Pero este tipo de ataque no es exclusivo del protocolo DNS. En realidad, casi
cualquier protocolo UDP, como SIP, NFS, SNMP, RADIUS, TFTP, NTP, que
no necesitan del establecimiento de una conexión, lo sufren en mayor o menor
medida:

Protocolo fα
DNS 10 - 60
SMTP (con SPF) 10 - 20
SCTP 10 - 20

De hecho, éste es un tema de investigación abierto e interesante: determinar


qué protocolos y en qué medida son vulnerables a este ataque.

3. Esquemas actuales
Todos los sistemas de autenticación actuales utilizan para su funcionamiento
la posesión de un conocimiento secreto o caracterı́stica única a la entidad que
tratar de identificar. En función de dónde se sitúa ese secreto o caracterı́stica
podemos establecer la siguiente clasificación:
1. Algo conocido: Tı́picamente claves, números PIN o cualquier otro secre-
to.

2. Algo que se posee: Habitualmente un dispositivo fı́sico, como una tarjeta


o un generador de claves de un sólo uso (claves OTP).
3. Alguna caracterı́stica fı́sica humana: Incluyen todos los rasgos utili-
zados por los sistemas biométricos: huellas dactilares, firmas manuscritas,
patrones retinales o geometrı́a de manos.
2 Distributed Denial Of Service - Ataques de denegación de servicio llevados a cabo por

una red de máquinas, normalmente del orden de cientos o miles de ellas.

7
3.1. Contraseñas
El primero de los grandes y clásicos esquemas son las contraseñas o claves,
que se engloban en el primero de los criterios según la clasificación anterior.
Son, por tanto, el esquema más débil, pues su fortaleza se basa en la posesión (y
mantenimiento) de un secreto. En cualquier caso, son con diferencia el método
más utilizado, a pesar de que la lista de incovenientes de su uso es larga:
Son vulnerables a ataques de repetición. Si el esquema de usuario/contraseña
se utiliza en un protocolo de autenticación en red, la clave puede ser cap-
turada y reutilizada en algún momento posterior.
Son vulnerables a ataques de fuerza bruta, con diccionario o sin él. La
situación se agrava con el hecho de que un número muy alto de las claves
elegidas por los usuarios son muy débiles [9, 13].

Son vulnerables a ataques de ingenierı́a social. Los fraudes bancarios, o


phishings, tan de actualidad en estos momentos, son un buen ejemplo de
ello [16].
Los lugares donde se almacenan las claves pueden ser atacados. La ex-
periencia demuestra, además, que muchos de estos almacenes no están
debidamente protegidos, incluso cuando se utilizan técnicas criptográficas
para intentarlo. El fichero /etc/password de los sistemas UNIX o la defi-
ciente implementación de los hashes en el protocolo NTLM son un ejemplo
de ello.
Existen las claves por defecto. Cualquier software o dispositivo que
utilice este sistema de autenticación debe tener alguna contraseña por
defecto, que deberı́a ser cambiada antes del primer uso. Sin embargo, la
experiencia nos demuestra que, de forma habitual, éste no es el caso.

3.1.1. Almacenamiento de claves


El almacenamiento de claves es, como hemos visto, una cuestión especial-
mente sensible y uno de los mayores problemas de este esquema. Guardarlas
en claro no es, o no deberı́a, ser siquiera una opción. Las dos técnicas más
habituales son:
Guardar la clave cifrada. Para no tener que generar otra clave que cifre
la inicial, se utiliza ésta como propia clave de cifrado. No hay problema
en hacer esto mientras el algoritmo utilizado sea resistente a ataques de
texto escogido. Los sistemas operativos UNIX utilizan este sistema con
una variante de DES.
Guardar un hash de la clave. En general este método es más sencillo y
computacionalmente menos costoso.
Estos métodos son, por supuesto, preferibles al almacenamiento en claro,
pero siguen siendo vulnerables a un ataque de diccionario en el caso de que los
ficheros sean capturados. En sistemas de seguridad máxima puede ser necesario
un esquema más seguro, que podrı́a consistir en calcular un HMAC en vez de un
hash. La clave del HMAC, por supuesto, no debe residir en la propia máquina,

8
pues estarı́amos de nuevo ante el mismo problema, sino en algún dispositivo
externo seguro, como una smartcard, junto con un PIN de acceso. De esta forma,
el sistema ya no serı́a vulnerable a ataques de fuerza bruta o diccionario.

3.1.2. Borrado de claves


Otra cuestión importante es la destrucción o borrado de las claves una vez
que se decide sustituirlas. Este proceso no es tan sencillo como parece, debido
al fenómeno de la remanencia magnética [10], que consiste en la tendencia del
material magnético, del que están fabricados los discos duros y memorias de
cualquier ordenador, a guardar trazas de la información que almacenaban una
vez que ésta cambia. Se ha demostrado experimentalmente que las memorias
RAM actuales pueden mantener sus contenidos durante horas e incluso dias
después de que se corte su alimentación [2, 11].
Por otro lado, el propio sistema operativo puede jugar malas pasadas en este
aspecto. Si utilizamos sus servicios para borrar ficheros, es conocido que la infor-
mación no es realmente eliminada, sino sólo “desligada” del sistema de ficheros,
pudiéndose recuperar posteriormente con facilidad. Además, para información
especialmente sensible, como claves de sesión o números PIN, hay que tener en
cuenta otro problema, que es el uso de la memoria virtual. Como consecuencia
de un periodo de inactividad, la página de memoria que contiene claves puede
ser desplazada a disco, a espacio de swap. De esta forma, estas claves pueden
ser recuperadas con posteriodidad con facilidad, dependiendo de la actividad
del sistema. En máquinas de un propósito muy especı́fico, como un cajero au-
tomático, se han descrito casos en los que fue posible recuperar claves, números
de tarjetas de crédito e, incluso, la aplicación bancaria completa del disco duro
después de que los ficheros fueran borrados y la unidad formateada [7].
No existe una solución sencilla y efectiva, porque cada sistema operativo
gestiona de manera diferente su memoria virtual. Sin embargo, existen una serie
de contramedidas a este problema:
Un criterio común para desplazar una página a disco suele ser su frecuencia
de uso. Por tanto, moviendo las claves más sensibles entre distintas páginas
cada poco tiempo, podemos tener una seguridad razonable de que no serán
reemplazadas. Además de esta forma podemos evitar los efectos de la
remanencia magnética, que se agravan conforme más tiempo se mantiene
la información en la misma posición del disco o la memoria [11].
Podemos, también, utilizar los servicios especı́ficos del sistema operati-
vo para bloquear memoria. En entornos Windows, por ejemplo, podemos
utilizar la llamada VirtualLock() para asegurarnos de que una zona con-
creta del mapa de memoria de un proceso no será paginada a disco. En
Linux, su equivalente es mlock().

3.2. Contraseñas de un sólo uso: OTPs


Una evolución natural del esquema de contraseñas tradicional, que soluciona
parte de sus problemas, son las claves de un sólo uso. Como indica su nombre,
se trata de credenciales que se usan una sola vez, y que cambian cada autenti-
cación válida. De esta forma, aunque sean capturadas, no pueden reutilizarse.

9
Existen básicamente tres tipos de OTPs:
Algoritmos matemáticos que generan una secuencia de claves, normalmen-
te utilizando funciones hash.
Algoritmos que generan claves en función del tiempo transcurrido desde
una fecha establecida como inicial.
Algoritmos que utilizan un reto como parte del proceso de generación de
la clave.

Estos esquemas pueden implementarse en dispositivos hardware, como los


tokens SecurID de RSA, y en software. Aunque existen también otros soportes
con distintos niveles de sofisticación, como una simple hoja de papel o cartón de
las tarjetas de coordenadas bancarias, o un mensaje SMS en un teléfono móvil.

3.2.1. OTPs basados en secuencias de claves


Este esquema fue planteado por primera vez por Leslie Lamport3 en 1981
[14]. El sistema funciona estableciendo una semilla inicial s y un número máximo
de identificaciones t. A continuación utiliza una función hash f para calcular la
lista completa de claves:

ct = f (s)
ct−1 = f (f (s))
...
c2 = f (f (s))
c1 = f (f (...(f (s))))
| {z }
t veces

Un ejemplo real y conocido que utiliza este esquema es S/KEY, un sistema


de autenticación segura para sistemas UNIX, desarrollado por N. Haller de Bell
Laboratories en 1996 [12]. Su funcionamiento es sencillo:
1. El administrador genera y almacena la primera clave de cada usuario pa-
sando su semilla s a través de la función hash n veces, pn = hashn (s).
Nótese que las claves se usarán en orden inverso al que son calculadas (de
forma que, como veremos a continuación, la función hash f no pueda ser
invertida).
2. Cuando el usuario vaya a autenticarse por primera vez, el servidor pe-
dirá su clave pn−1 , que el usuario puede obtener calculando n − 1 hashes
de la semilla s.
3. Si las claves coinciden, el servidor decrementa el contador del usuario y le
concede la autenticación.
A partir de este momento, el usuario irá proporcionando y descartando claves
conforme se vayan utilizando hasta agotar la lista completa. En ese momento,
el administrador del sistema debe generar una nueva semilla y entregársela al
usuario.
3 Sı́, el mismo Leslie LATEX-Lamport.

10
La función hash utilizada implementa el algoritmo MD4 que genera salidas de
64 bits de longitud [17]. Como recordar 64 bits puede ser ligeramente incómodo
para un humano, éstos se represetan en forma de 6 palabras inglesas.
Las ventajas de este sistema son claras. Si alguna de las claves es capturada
no será posible deducir la siguiente, pues para ello habrı́a que invertir la función
hash f , lo que se considera computacionalmente muy costoso hoy en dı́a. Es de-
cir, el sistema no es vulnerable a ataques de repetición. Sin embargo, sı́ que lo es
a un ataque de suplantación, o man-in-the-middle: el atacante podrı́a suplantar
al servidor, por ejemplo a través de un ataque de red que redirigiera el tráfico de
uno a otro, y capturar una clave en tránsito. Acto seguido, utilizarı́a esta clave
en el servidor legı́timo. Sin embargo, esto provocarı́a la desincronización entre
servidor y usuario, evitando que éste pudiera autenticarse correctamente y ha-
ciendo que el ataque se descubriera rápidamente. Además, tendrı́a que repetirse
cada vez que el atacante necesitase autenticarse en el sistema. Para evitar este
ataque, el cliente deberı́a contar con un mecanismo que verificase la identidad
del servidor, como una técnica de reto-respuesta, que veremos en los siguientes
apartados.
Por otro lado, existen también algunos inconvenientes. El primero es la in-
comodidad que supone la gestión del sistema. Cuando el número de usos de la
semilla se agota, hay que generar una nueva y hacérsela llegar al usuario, lo que
puede ser engorroso si el número de usuarios es alto o hacen un uso intensivo
de las mismas. Desde el punto de vista de su seguridad, el sistema es todavia
vulnerable a un ataque de fuerza bruta por diccionario debido a que MD4 es un
algoritmo especialmente rápido4 .

3.2.2. OTPs temporales


En esta categorı́a se encuadran aquellos sistemas OTPs que generan sus
claves tomando el tiempo transcurrido desde una fecha concreta como una de
sus variables de entrada. Habitualmente estos sistemas se han implementado en
hardware, como los tokens de RSA, pero ya han aparecido también versiones
software, tanto para plataformas PC como para teléfonos móviles.
Estos dispositivos permiten llevar a cabo una autenticación de doble factor,
que toman en cuenta algo que se conoce, como una clave tradicional, y algo que se
posee, el token fı́sico. Esta posesión se demuestra introduciendo correctamente
una clave variante proporcionada por el token en un pequeña pantalla LCD.
Habitualmente ambas claves se concatenan, de forma que para suplantar al
usuario habrı́a que capturar su clave y tener acceso al token.

Algoritmo RSA SecurID


Este algoritmo es el que implementan todos los tokens de RSA, que son sin
duda uno de los más conocidos y vendidos en el mundo. La función que genera
los códigos mostrados en el LCD puede modelarse con una función hash con
clave y = H(k, t), donde k es una clave secreta de 64 bits almacenada en el
token desde su fabricación, t es un valor temporal de 64 bits obtenido del reloj
cada 30 o 60 segundos e y son los códigos obtenidos de 6 u 8 dı́gitos.
Sin embargo, algunos estudios recientes [5] han descubierto que t se genera
utilizando una representación de sólo 32 bits, en vez de los 64 declarados, basada
4 De hecho, se considera el algoritmo hash de implementación más rápida. Le siguen, en

orden decreciente de velocidad, MD5, SHA1, RMD160 y MD2.

11
en la hora actual GMT en segundos desde medianoche del 1-1-865 . Un despla-
zamiento a la izquierda que se realiza posteriormente como parte del proceso
del algoritmo reduce la entropı́a de t aún más hasta sólo 24 bits. Sin embargo,
este problema no supone una rebaja de la seguridad suficiente como para que
el algoritmo pueda ser atacado a dı́a de hoy.

Federación de identidades
Sin duda el uso de tokens OTP tiene un futuro importante, ya que no son
vulnerables a ataques de repetición ni de fuerza bruta, por ejemplo. Sin embar-
go, la propia popularización de su uso puede suponer un inconveniente, pues el
usuario puede verse cargando con varios tokens el de su banco, el de su traba-
jo, el de acceso a servicios telemáticos oficiales, etc... La solución pasarı́a por
la federación de identidades, un concepto que podrı́amos equiparar al de las
jerarquı́as de Autoridades de Certificación en el mundo PKI.
La idea es compartir la identidad y autenticación de los usuarios entre dis-
tintas organizaciones, estableciendo una jerarquı́a de confianza. Un escenario
natural de este esquema es la banca online donde, sin la federación de identi-
dades, un usuario cliente de varios bancos tendrı́a que cargar y utilizar varios
tokens OTP para acceder a sus cuentas en los mismos. Ası́ como cuentan con
alianzas en otros aspectos, los bancos podrı́an llegar a un acuerdo y considerar
como válidas las autenticaciones realizadas por otras entidades.
El esquema podrı́a seguir ampliándose fácilmente. De entidades financieras
podrı́a pasarse a organizaciones completamente heterogéneas, como agencias de
viajes o grandes mayoristas en Internet, como eBay, Amazon, etc... De esta
forma, el usuario sólo tendrı́a que utilizar un único token para todas sus au-
tenticaciones, al menos en las organizaciones “federadas”. De hecho, las partes
implicadas podrı́an compartir también el precio de los tokens, que quizás sea
uno de los argumentos más poderosos para organizaciones con miles o millones
de potenciales usuarios.

4. Primitivas criptográficas
Todos los esquemas de autenticación que hemos visto son combinaciones de
una serie de primitivas u operaciones criptográficas básicas. Conocer bien estas
operaciones, qué propiedades tienen y cómo deben utilizarse es básico a la hora
de abordar el diseño de un protocolo criptográfico.

4.1. Reto-respuesta
El siguiente paso en los esquemas de autenticación, tras las claves y los
OTPs, son los de reto-respuesta. Éstos son métodos interactivos, en el sentido
que necesitan intercambiar una serie de mensajes entre las partes. El objetivo
es que una de ellas, A, demuestre a la otra, B, que conoce un secreto conocido
a ambas partes sin revelar el secreto en sı́ mismo. De esta forma, aunque la
ejecución del protocolo sea monitorizado y analizado, las respuestas no pueden
ser posteriormente utilizadas, pues el secreto no ha sido desvelado y éstas varı́an
en cada ejecución del mismo.
5 Laelección de la fecha no es casual; el fabricante de los tokens SecurID, Security Dynamics,
fue fundada en 1986.

12
Estos esquemas cuentan con medidas que los hacen invulnerables a ataques
de repetición, de fuerza bruta/diccionario y, si son implementados con cuidado,
incluso a ataques de suplantación. Son, en teorı́a, la posibilidad más segura de
autenticación a costa, normalmente, de un mayor número de mensajes inter-
cambiados.
Los esquemas de reto-respuesta pueden implementarse utilizando técnicas de
clave simétrica, asimétrica y de conocimiento cero. Para todos ellos, los nonces,
o parámetros temporales, son básicos.

4.1.1. Nonces
Los nonces se utilizan en protocolos de autenticación y establecimiento de
claves para evitar ataques de repetición. Sirven para distingur distintas instan-
cias de la ejecución de un protocolo y no son más que valores que no se utilizan
más de una vez para el mismo propósito.
Existen tres tipos de nonces: números aleatorios, números de secuencia y
sellos de tiempo.

4.1.2. Números aleatorios


Los números aleatorios se utilizan de la siguiente forma en los protocolos de
reto-respuesta:
1. A incluye un número aleatorio r en un mensaje que envı́a a B.
2. A partir de ese momento, en la misma instancia del protocolo, A y B
deben incluir r en sus mensajes, criptográficamente unido al contenido del
mensaje, para evitar ataques de repetición. Sin esta medida, los números
aleatorios en sı́ mismos son inútiles. “Criptográficamente unido” tiene di-
ferentes significados en función del tipo de clave, secreta o pública, que
estemos utilizando para la implementación del protocolo. En los siguientes
apartados, nos ceñiremos al uso de claves simétricas.
Para ilustrar los posibles problemas analizaremos el siguiente protocolo, que
hace uso de números aleatorios:

A → B : ra
A ← B : {ra }k

A pesar de su simplicidad, o quizás precisamente por eso, es habitual en-


contrar variantes de este protocolo en autenticación de aplicaciones Web6 ; en
ese caso, A serı́a el servidor Web y B el cliente que pretende autenticarse. Pe-
ro comienzan los problemas, ya que tal y como está definido, el protocolo es
vulnerable a un ataque de reflexión, que podrı́a llevarse a cabo cuando la auten-
ticación entre las partes fuera mutua; es decir, cuando cada una de ellas pudiese
actuar como interrogador y verificador simultáneamente. En este caso, el ataque
se realizarı́a de la siguiente manera:
1. El atacante interceptarı́a el primer mensaje y lo reenviarı́a de nuevo hacia
A, de forma que pareciera provenir de B.
6 Con variaciones incluso más simples: en lugar de utilizar cifrado, la respuesta se genera

utilizando una función hash sobre el reto ra .

13
2. A cifrarı́a el reto recibido, ra , y lo enviarı́a a B.
3. El atacante interceptarı́a de nuevo este mensaje y lo volverı́a a reenviar
a A, autenticándose con éxito. En todo el proceso, ningún mensaje ha
llegado siquiera a B.
Otro problema del uso de números aleatorios es su proceso de generación.
Y es que generar numeros aleatorios en un ordenador no es tan sencillo como
parece. Y si no, que se lo digan a Netscape y su implementacion de SSL en las
primeras versiones de su navegador. En enero de 1996, Goldberg y Wagner, dos
estudiantes de postgrado de la Universidad de Berkeley, descubrieron que el na-
vegador contaba con un generador de entropı́a muy pobre. La semilla del mismo
se obtenı́a de tres parámetros predecibles, como eran la hora, el identificador
del proceso actual y el identificador del proceso padre. Como ellos demostraron,
estos parámetros podı́an obtenerse tras unos pocos intentos, pudiendo derivar
ası́ las claves simétricas de cifrado.

4.1.3. Números de secuencia


Continuando con los mecanismos utilizados en los protocolos reto-respuesta,
encontramos los números de secuencia. A diferencia de los aleatorios, éstos si-
guen una patrón, que puede ser conocido o no, con el objetivo de evitar ataques
de repetición. Un mensaje se considerará válido cuando su número de secuencia
no haya sido usado previamente y cumpla con la polı́tica de numeración. Una
caracterı́stica fundamental de estos números es que deben ser especı́ficos para
cada comunicación y distintos para cada sentido; es decir, la secuencia debe ser
diferente para los mensajes que fluyan de A a B y de B a A.
Pero no hay que olvidar que este mecanismo es una herramienta para evitar
ataques de repetición, y nada más. No es una solución en sı́ misma para generar
un protocolo correcto y seguro y debe utilizarse siempre en combinación con
otras técnicas. Si no, pueden ocurrir cosas como el conocido problema de los
números de secuencia en el protocolo TCP [3].
Respecto a los números aleatorios, tienen la ventaja de que no necesitan
un módulo generador de entropı́a, y las dificultades que se derivan de él, como
hemos visto. Sin embargo, los números de secuencia necesitan almacenar infor-
mación para cada comunicación, como el número de secuencia actual propio y
de la otra parte. Además, existe el problema de la desincronización, que puede
producirse como consecuencia de fallos, deliberados o no, en la comunicación.
Debido a estos fallos, en determinadas circunstancias serı́a necesario un meca-
nismo de reinicialización, para que ambas partes puedan volver a comunicarse
con números de secuencia conocidos.

4.1.4. Sellos de tiempo


Como último mecanismo nos encontramos con los sellos de tiempo que, en
principio, tiene algunas ventajas sobre los anteriores.
Su funcionamiento es como sigue:
1. A obtiene la fecha y hora de su reloj local, uniéndolo criptográficamente
al mensaje, sellándolo de esta forma. “Unirlo” tiene, de nuevo, distintos
significados, pero puede hacerse de una forma tan simple como generando
el siguiente mensaje:

14
A → B : {ta , M }k

2. B recibe el mensaje, obtiene ta y calcula δ = T − ta , siendo T la hora


actual de su propio reloj. El mensaje será considerado válido si δ es menor
que un umbral fijado con anterioridad. Este umbral, que puede variar de
unos pocos milisegundos a horas, variará en función del uso del protocolo,
el volumen de mensajes que se intercambian, etc...
3. De forma opcional, B puede comprobar que el mensaje recibido no ha sido
enviado con anterioridad con el mismo sello de tiempo y con el mismo
origen. De esta forma, la tolerancia de δ puede ampliarse, a costa de tener
que guardar información en memoria, con el conseguiente riesgo de generar
una vulnerabilidad de denegación de servicio.
Evidentemente, para que este mecanismo funcione es necesario una referencia
temporal común a las partes que se comunican. No es necesaria una sincroniza-
ción exacta, pero sı́ bastante aproximada. La diferencia permitida, como hemos
visto, será una función del umbral δ tolerado.
Existen varios protocolos de sincronización temporal, como NTP, pero si se
utilizan de forma distribuida pueden convertirse en objetivo de ataques y deben,
a su vez, asegurarse. En ese caso, no podrı́an utilizarse sellos de tiempo para
ello, pues entrarı́amos en un bucle.

4.1.5. Resumen
Cada uno de los métodos que hemos analizado tiene sus ventajas e incove-
nientes y, en general, no puede decirse que haya una técnica mejor que las otras
en todas las circunstancias.
Sin embargo, en términos generales, puede decirse que los mecanismos ba-
sados en sellos de tiempo necesitan menos mensajes (tı́picamente, sólo uno) y
no necesitan mantener información durante la ejecución del protocolo, como los
números aleatorios y de secuencia. Como contrapartida, necesitan mantener una
red distribuida de relojes sincronizados, lo que puede ser un problema insalvable
en ocasiones.
La tabla 2 resume los aspectos más importantes de cada método.

Método Ventajas Inconvenientes


· Implementación sencilla. · Necesidad de un generador
Números
de entropı́a fiable.
aleatorios
· Necesidad de guardar infor-
mación por cada conexión.
· Implementación sencilla. · Necesidad de guardar infor-
Números de
mación por cada conexión.
secuencia
· Problemas de desincroniza-
ción.
· Menor número de mensa- · Necesidad de un reloj
Sellos de
jes. común y seguro.
tiempo
· No se necesita guardar in-
formación.

Cuadro 2: Comparativas de los distintos nonces existentes

15
5. Implementación
Hemos comentado varias veces a lo largo del artı́culo que las técnicas crip-
tográficas son esenciales en cualquier protocolo de seguridad. Ahora bien, sólo
son efectivas si se implemetan adecuadamente.
Por ejemplo, el protocolo que hemos visto en la sección 4.1.2, que utilizaba
números aleatorios para evitar ataques de repetición, es correcto sobre el papel
desde el punto de vista criptográfico y lógico. Sin embargo, si lo implementamos
en un protocolo que se ejecute sobre una red, serı́a totalmente vulnerable a un
ataque de denegación de servicio.
En efecto, para comprobar si los números aleatorios firmados o cifrados que
el servidor recibe son correctos, éste debe guardar en memoria una lista con
los retos que ha emitido para cada comunicación. ¿Qué ocurrirı́a si un atacante
hiciese muchı́simas peticiones de autenticación y, simplemente, no respondiera
a los mensajes del servidor? Pues que la cola de peticiones de éste se llenarı́a y
estarı́amos ante un ataque de denegación de servicio en memoria. El mecanismo
subyacente es el mismo que el utilizado, por ejemplo, en el conocido SYN Flood.
Una posible solución pasa por evitar almacenar información para cada pe-
tición. Para ello, se pude utilizar al propio cliente como “almacén” de la infor-
mación. Se trata de proporcionar al cliente, debidamente protegida, los datos
que nos permitirán verificar en los mensajes posteriores si éste ha cumplido co-
rrectamente con los requisitos del protocolo de autenticación (es decir, resolver
correctamente el reto).
Tomemos, de nuevo, el protocolo de la sección 4.1.2. En él, el reto serı́a el
número aleatorio, ra , y la solución, {ra }k , que demuestra conocimiento de la
clave simétrica compartida, k. En este punto, podemos actuar básicamente de
dos maneras:
1. Proporcionar el reto al cliente, pero firmado, de forma que éste no pueda
ser falseado. Cuando recibamos el reto, verificamos primero la firma de
éste y luego comprobamos que ha sido correctamente resuelto. Es decir:

A → B : reto, [reto]
A ← B : solución, [reto]

La implementación concreta para el protocolo que estamos analizando


serı́a:

A → B : ra , [ra ]ka
A ← B : {ra }k , [ra ]ka

donde ka es una clave secreta sólo conocida por A. De esta forma, A pue-
de deshacerse del reto al enviar el mensaje a B, y no almacenar ninguna
información en memoria. Por supuesto, A debe hacer una serie de com-
probaciones al recibir el mensaje de B, como verificar que están presentes
todos los campos esperados, que tienen la longitud que les corresponde,
etc...
2. Proporcionar el reto y, al mismo tiempo, la solución al cliente, para que
éste haga, de nuevo, de almacén de la información. Evidentemente, la
solución debe entregarse cifrada. Una posible implementación serı́a:

16
A → B : ra , {{ra }k }ka
A ← B : {ra }k , {{ra }k }ka

Al recibir la solución del reto, A abrirı́a el “sobre cerrado” que entregó a


B, descifrando la solución con ka . Si coincide exactamente con la solución
recibida, la autenticación se considerará válida.
En principio, cada aproximación tiene sus ventajas e inconvenientes. La dife-
rencia principal entre ambos es que la primera retrasa la verificación del reto (lo
que supone la creación de su solución) hasta que el cliente responde al mismo,
lo que puede ser ventajoso si somos vı́ctimas de un ataque, ya que utilizare-
mos menos recursos en generar la solución. Pero esto sólo serı́a importante si
esta generación es costosa computacionalmente hablando, como en el caso de
las pruebas de trabajo (proof-of-work ) [8] o los puzzles de tiempo[18]. En ese
caso, en la generación del reto se obtienen simultáneamente su solución, con
lo serı́a aconsejable el segundo esquema, dado que la verificación posterior es
mucho más rápida.

5.1. Especificación de protocolos: ASN.1


Uno de los pasos más problemáticos del diseño de protocolos, dada la he-
terogeneidad de las partes implicadas, es su implementación. Por ejemplo, la
diferencia en los tamaños de los distintos tipos de datos en cada arquitectura
hace muy difı́cil su portabilidad.
Sin embargo, desde principios de los 80 existe una solución especı́ficamente
diseñada para paliar estos problemas, que es la denominada notación ASN.1
(Abstract Syntax Notation). Este estándar es un metalenguaje destinado a des-
cribir protocolos de comunicación entre partes heterogéneas. Por supuesto, pue-
de aplicarse perfectamente a protocolos criptográficos que es donde, de hecho,
ha obtenido más aceptación.
Veamos un ejemplo. A continuación mostramos cómo se modelizarı́a en
ASN.1 un par de claves pública y privada:

RSAPublicKey ::= SEQUENCE {


modulus INTEGER, -- n
publicExponent INTEGER -- e
}

RSAPrivateKey ::= SEQUENCE {


version Version,
modulus INTEGER, -- n
publicExponent INTEGER, -- e
privateExponent INTEGER, -- d
prime1 INTEGER, -- p
prime2 INTEGER, -- q
exponent1 INTEGER, -- d mod (p-1)
exponent2 INTEGER, -- d mod (q-1)
coefficient INTEGER, -- (inverse of q) mod p

17
otherPrimeInfos OtherPrimeInfos OPTIONAL
}

Version ::= INTEGER { two-prime(0), multi(1) }


OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo
OtherPrimeInfo ::= SEQUENCE {
prime INTEGER, -- ri
exponent INTEGER, -- di
coefficient INTEGER -- ti
}

Una vez descrito el protocolo o estructura de datos utilizando esta notación,


la misma puede ser compilada, obteniendo código fuente que puede manipular
(generar y verificar) este tipo de estructuras. Existen compiladores de ASN.1
para múltiples lenguajes, pero quizás los más conocidos son SNACC para C y
C++, y Snacc4J para Java.

6. Un protocolo de ejemplo: Una estación me-


teorológica
En esta sección pondremos en práctica todos los conceptos que hemos visto
a lo largo del artı́culo. El escenario es el de una estación meteorológica, situada
en algún lugar inhóspito y de difı́cil acceso, que debe conectarse a un servidor
para volcar periódicamente los datos que recoge. Dado su difı́cil acceso, la es-
tación cuenta con una conexión GPRS, lo que obligará a nuestro protocolo a
ser eficiente en cuanto al ancho de banda consumido. Además, por supuesto,
queremos que la comunicación sea segura.

6.1. Requisitos
Los requisitos que buscamos en nuestro protocolo incluyen:
Autenticación mutua de ambas partes.
Resistente a ataques de repetición, suplantación y, especı́ficamente, de
denegación de servicio.
Dada la escasa capacidad de cálculo de la estación, la autenticación debe
basarse en clave simétrica. Para ello, ambas partes comparten una clave k
de larga duración (de, al menos, 128 bits).
Dadas estras premisas, podrı́amos generar un protocolo basado en el siguien-
te esquema:

E → S : re , [re ]ke
E ← S : {rs , re }k , [re ]ke , [rs ]ks
E → S : {rs }k , [rs ]ks

18
donde E y S son la estación y el servidor, respectivamente, y ke una clave
de sesión de la estación. El protocolo no guarda ninguna información durante
la ejecución del mismo, para no resultar fácilmente vulnerable a ataques de
denegación de servicio. La estación y el servidor actuarı́an ası́ para ejecutar el
protocolo:
1. E genera un número aleatorio re y lo firma con una clave secreta, por
ejemplo con una función HMAC con clave. De esta forma, puede eliminar
re de memoria.

2. S recibe re , genera su propio número aleatorio rs y cifra ambos con la


clave compartida k. A continuación, genera la firma de su propio reto rs
y lo añade al mensaje que devuelve a E.
3. E descifra los retos, obteniendo rs y re en claro. A continuación, comprue-
ba la firma sobre re para detectar si ha habido un intento de manipulación.
Si no coinciden exactamente, el protocolo es abortado. Si son exactamente
iguales, cifra el reto recibido rs con k y lo devuelve a S.
4. Finalmente, S actúa de la misma forma que E en el paso anterior: descifra
rs y comprueba su firma.
De esta forma, en cada paso del protocolo, ni E ni S han tenido que guardar
ninguna información en memoria. Esto permitirı́a a S mantener un número
ilimitadamente alto de sesiones de autenticación concurrentes, sólo limitadas
por los recursos de CPU y de ancho de banda disponibles.

Referencias
[1] Alvarez, G., and Petrovic, S. Encoding a taxonomy of web attacks
with different-length vectors. Computers and Security 22 (2003), 435.
[2] Anderson, R. J. Security Engineering: A Guide to Building Dependable
Distributed Systems. John Wiley & Sons, Inc., New York, NY, USA, 2001.
[3] Bellovin, S. M. Security problems in the TCP/IP proto-
col suite. Computer Communications Review 19:2 (1989), 32–
48,http://www.research.att.com/s̃mb/papers/ipext.pdf.
[4] Chou, W. Inside ssl: The secure sockets layer protocol. IT Professional
04, 4 (2002), 47–52.
[5] Contini, S., and Yin, Y. Improved cryptanalysis of securid, 2003.
[6] Diffie, W., and Hellman, M. E. New directions in cryptography. IEEE
Trans. Inform. Theory IT-22 (Nov. 1976), 644–654.

[7] Garfinkel, S., and et al. Remembrance of data passed: A study of


disk sanitization practices.
[8] Golze, S., and Muhl, G. Fair overload handling using proof-of-work
functions. In SAINT (2006), pp. 14–21.

19
[9] Grampp, F., and Morris, R. UNIX operating system security. Bell
System Technical Journal 62, 8 (1984).

[10] Gutmann, P. Data remanence in semiconductor devices. pp. 39–54.


[11] Gutmann, P. Secure deletion of data from magnetic and solid-state me-
mory. Proc. Sixth Usenix Security Symp, pp. 39–54.
[12] Haller, N. M. The S/KEY one-time password system. In ISOC (1994).

[13] Klein, D. A survey of, and improvements to, password security. pp. 5–14.
[14] Lamport, L. Password authentication with insecure communication.
Communications of the ACM 24, 11 (Nov. 1981), 770–771.
[15] Menezes, A. J., van Oorschot, P. C., and Vanstone, S. A. Hand-
book of Applied Cryptography. CRC Press, 1997.

[16] Rachna Dhamija, Doug Tygar, M. H. Why phishing works. In CHI


’06: Proceedings of the SIGCHI conference on Human Factors in computing
systems (January 2006), ACM Special Interest Group on Computer-Human
Interaction, pp. 581–590.
[17] Rivest, R. The md4 message-digest algorithm.
[18] Rivest, R. L., Shamir, A., and Wagner, D. A. Time-lock puzzles and
timed-release crypto. Tech. Rep. MIT/LCS/TR-684, 1996.
[19] Schneier, B. Applied Cryptography (Second Edition). John Wiley & Sons,
1996.
[20] Stallings, W. Network and Internetwork Security Principles and Prac-
tice. Prentice Hall, 1995.
[21] Vaughn, R., and Evron, G. Dns amplification attacks. http://www.
isotf.org/news/DNS-Amplification-Attacks.pdf, 2006.

20