Descargar este fichero PDF - Comunicación del Conocimiento

Ingeniería
y Arquitectura
Campo Científico:
Informática
Roberto Castellanos Gutiérrez
Ingeniería y
Arquitectura
Campo Científico: Informática
Roberto Castellanos Gutiérrez
Doctor en Matemáticas aplicadas a las Ciencias de la Computación por la
Universidad de Berkeley (EE UU)
* Las citas a pie de página del presente artículo se incluyen formando parte de las referencias
bibliográfica que, por ese motivo, no llevan un orden alfabético.
rEsUMEN
Este estudio propone una solución al problema de un sistema de autenticación de dos factores utilizando un sistema de claves rsA almacenadas en un dispositivo Usb generadas por la institución
que ofrece el servicio. El objetivo es asegurar la autenticidad, confidencialidad, no-repudio e integridad de las comunicaciones.
AbstrAct
this study suggests a solution to a system of two-factor authentication based in a rsA key scheme
stored in an Usb device . the rsA pair will be generated by the institution providing the service.
the goal is ensure authenticity, privacy, non-repudiation and integrity of communications.
PALAbrAs cLAVE
KEYWOrDs
1. IntroduccIón
Los avances y la potencia de cálculo de los ordenadores, en la actualidad, exigen un incremento de la seguridad en los procesos de
autenticación. Este estudio surge de las nuevas
posibilidades que nos brindan las tecnologías
emergentes como HTML5 para conseguir un
mayor nivel de seguridad sin perjudicar en exceso
la facilidad de uso.
El esquema clásico de autenticación basado
en nombres de usuarios y contraseñas se considera de manera general poco seguro en la actualidad [1] y cada vez más instituciones [2] lo
están sustituyendo por nuevos sistemas de verificación de la identidad. La tendencia actual
busca mejorar la seguridad mediante sistemas
de autenticación multifactor.
Estos sistemas no están libres de inconvenientes [3] ni de detractores, pero aun con sus desventajas, son una mejora respecto al sistema
clásico de identificación.
El esquema de autenticación multifactor utiliza,
para mejorar el esquema clásico, una aproximación de defensa en profundidad, añadiendo capas
de defensa al sistema para proteger los activos
e información clave.
El objetivo de este estudio es generar un prototipo funcional que, sin afectar de manera negativa a la facilidad de uso por parte del usuario,
mejore la seguridad de acceso al sistema. Se establece como entorno operativo un sistema con
un número moderado de usuarios (entre 500 y
1.000), pero con necesidades de protección y
confidencialidad altas, como las que se pueden
dar en un entorno operativo de una universidad
online. Las herramientas empleadas para generar
el prototipo se basarán en un sistema de autenticación multifactor. Uno de los factores empleados se basará en algo que el usuario sabe, el
clásico esquema ID / password. El otro factor
será una clave RSA generada por la entidad encargada de la autenticación. La clave para garantizar la seguridad es integrar este esquema
de autenticación en un entorno amigable y flexible
que sea lo menos intrusivo posible para el usuario[4].
Varios estudios hacen hincapié en que el eslabón más débil en la cadena de autenticación actuales es la contraseña [5]. Aun así, la mayoría
de los esquemas de autenticación actuales se
basan en esta aproximación. El mayor problema
de este esquema es el usuario. Los usuarios tienden a utilizar passwords sencillas de adivinar, utilizar la misma contraseña en varias cuentas o
incluso escribir las contraseñas en algún lugar
para evitar que se olviden. Por otra parte, los atacantes actuales cuentan con un arsenal de herramientas de uso cada vez más sencillo para
conseguir estas contraseñas. Los métodos clásicos como el ‘shoulder surfing’ y los ataques de
fuerza bruta han dejado paso en las redes actuales a ataques de tipo sniffing, eavesdropping
y phising. Aun habiendo una gran cantidad de
documentación sobre cómo conseguir que una
password sea relativamente segura [5], este sistema de autenticación continúa siendo un problema debido a las passwords débiles elegidas
por los usuarios.
En este estudio proponemos un método de
identificación alternativo: hemos elegido un sistema de autenticación de dos factores. Nos basaremos en algo que el usuario sabe (un par ID
/ password), y en algo que el usuario tiene (una
parte de una clave RSA). La otra parte de la clave
RSA quedará en custodia de la entidad que se
encargará de realizar la autenticación. El usuario
deberá descifrar mediante su clave un “token”
aleatorio generado para cada sesión. Mediante
un esquema de desafío / respuesta se solicitará
al usuario que demuestre que está en posesión
de su parte de la clave sin que sea necesario en
ningún momento que envíe su clave a través de
la red. Solamente tras comprobar que el usuario
está en posesión de su parte de la clave se le
permite el acceso. Para facilitar la interacción del
usuario con el sistema se aprovecharán las características de tipo ‘arrastrar y soltar’ presentes
en HTML5. Para realizar el cifrado y descifrado
de elementos en el navegador del cliente, se utilizará la librería de javascript JSBN.
2. trabajos relacIonados
Debemos mencionar los trabajos de uso de PKIs
sobre sistemas de tipo SmartCard [6], en el que se
utiliza una tarjeta inteligente como soporte de un certificado digital para implementar el control de acceso.
El uso de SmartCards presenta varios beneficios, como la seguridad de la tarjeta frente al robo
de claves y el cifrado de las claves almacenadas
en la propia tarjeta. Como desventajas de este
sistema, cabe señalar la necesidad de que el
usuario posea un lector compatible con el tipo de
tarjeta utilizado. Esto da lugar en un entorno de
despliegue masivo a un problema en la ubicación
de acceso desde la que los usuarios pueden acceder al sistema, ya que el ordenador utilizado para
acceder debe tener instalado el lector adecuado.
Un análisis detallado de este tipo de esquemas
de autenticación viene definido por Ramasamy y
Muniyandi [7]. En este documento se propone un
esquema de autenticación en el que el servidor
solamente almacena la hora de registro de cada
usuario. Desde nuestro punto de vista, el problema del método propuesto sigue consistiendo
en la necesidad de tener instalado en la máquina
desde la que se accede al servicio un lector de
tarjetas, lo cual es una cortapisa para el acceso
desde determinados ordenadores públicos o dispositivos móviles.
3. dIseño propuesto
Tratando de conseguir un sistema lo más sencillo
posible tanto para los administradores responsables del despliegue como para los usuarios,
hemos decidido implementar un prototipo basado
en claves RSA con una longitud de 2048 bits almacenadas en dispositivos USB. Ninguna parte
de la clave se considera pública al uso tradicional
de los sistemas RSA. Para mantener la seguridad
del sistema, ambas partes de la clave han de
permanecer en secreto. Una parte se entregará
al usuario y la otra se almacenará en el servidor.
Los diferentes componentes de la arquitectura
propuesta son:
Usuario: Persona que desea interactuar con el
servicio.
Proveedor: Entidad que proporciona los servicios a los que se desea acceder.
Navegador: Programa empleado por el cliente
para interactuar con el servidor de la aplicación.
Servidor: Entidad donde reside el servicio. Normalmente será un conjunto de host + aplicación
USBKey: Lugar de almacenamiento de la parte
de la clave RSA que se entrega al cliente.
ServerStorageKey: Lugar donde se almacena
la parte de la clave que queda en poder del servidor.
Par ID / PASS: Identificación inicial con nombre
de usuario y contraseña.
El usuario y el servidor se comunican a través
del navegador del usuario. Para poder acceder
al servicio, el usuario debe estar en posesión de
la clave almacenada en el USBKey y debe conocer el par ID / PASS suministrado por el proveedor. Ni la clave almacenada en el USBKey ni
la clave en posesión del servidor y almacenada
en el ServerStorageKey se enviaran a través de
la red. En lugar de intercambiar las claves enviándolas a través de la red, se ha optado por
implementar un sistema de tipo desafío - repuesta
detallado más adelante. Una vez validadas las
claves de usuario se permite el acceso al servicio.
La comunicación entre el servidor y el cliente
debe realizarse a través de un canal cifrado de
tipo ssl para minimizar los riesgos y disminuir las
opciones de ataque.
Figura 1
Los pasos necesarios para acceder al servicio
se detallan en la figura 2.
“token” cifrado se envía al navegador del cliente
y se le presenta a este aún cifrado.
El siguiente paso que debe realizar el cliente
es arrastrar el fichero de la clave almacenada en
su USBKey a una parte de la página preparada
al efecto. Se lanza un evento que mediante la
librería JSBN y un pequeño script realizado en
javascript sin salir del navegador del cliente, descifra el “token”. Internamente se vuelve a cifrar,
ahora mediante la clave del cliente. Este nuevo
“token” cifrado es el dato que se envía al servidor.
Figura 2
La primera parte del acceso consiste en presentar al usuario una ventana de autenticación
con el esquema clásico de usuario y contraseña.
El esquema de cifrado ssl trata de garantizar la
confidencialidad de los datos intercambiados. En
caso de un ataque de tipo sniffing ocasional, el
cifrado de las comunicaciones conseguirá este
objetivo. Sin embargo, en caso de ataques más
elaborados, este cifrado podría no ser suficiente.
El usuario suministra al servidor el par USER /
PASS y si es correcto, el servidor genera un
“token” aleatorio. Este “token” se cifra en el servidor mediante la clave RSA correspondiente al
usuario almacenada en el ServerStorageKey. El
Figura 3
Las diferentes pruebas realizadas indican los
tiempos empleados por el conjunto librería +
script en realizar las operaciones de descifrado
y cifrado necesarias para obtener T’ (El token enviado al servidor).
Una vez el cliente obtiene T’ lo envía al servidor. El servidor lo descifra mediante la clave correspondiente a ese cliente almacenada en el
ServerStorageKey y obtiene un resultado. Si este
resultado coincide con el “token” generado originalmente se permite el acceso.
El esquema detallado de este sistema de autenticación se muestra en la figura 4.
4. ImplementacIón
RegistRos
El usuario solicitará al proveedor un par ID
/PASS. El proveedor genera dicho par y un par
de claves de tipo RSA asociadas a la identidad
del usuario. Manteniendo la nomenclatura tradicional de dichas claves, se denominan claves pública y privada. La clave privada se almacena en
el dispositivo USBKey y se entrega junto con el
par ID / PASS al usuario.
Figura 4 -
Para poder comprobar en lo posible la integridad se genera un IDUSB único para el USBKey.
A partir de este ID se genera la cadena
IDCDN=ID+PASS + IDUSB + (Clave Privada).
Se realiza un hash a este IDCDN
HID=MD5(IDCDN)
El resultado de esta operación se cifra mediante AES256 y una clave que solo ha de poseer el servidor.
R=AES256(HID)
Este valor R se almacena en un fichero dentro
de la propia USBKey por si es necesario comprobar su validez en algún momento posterior. Se
procede a entregar al usuario los datos de acceso.
Login
Cuando el usuario desea acceder al servidor, se
conecta a una página https publicada al efecto.
Como se ha indicado en la figura 3, se presenta
al usuario una pantalla de verificación de nombre
de usuario y password. Una vez superado este
paso se pide al usuario que arrastre la clave almacenada en el USBKey al campo preparado al
efecto y se realiza el descifrado y cifrado del
“token” necesario para la fase desafío - respuesta. El script desarrollado para este estudio
ha demostrado ser funcional en los navegadores
modernos (IE10, Opera, Chrome 5 y FireFox 5).
AutenticAción
El servidor recibe la cadena cifrada que le envía
el navegador del cliente y mediante un script realizado del lado del servidor en Python, descifra
el mensaje con la clave almacenada en el ServerStorageKey y asociada al ID del usuario. Si
el resultado obtenido coincide con el “token” original, se permite el acceso al usuario.
Para evitar ataques de fuerza bruta se pone un
límite al número de autenticaciones que se puede
realizar. Inicialmente se introduce un retardo de
30 segundos entre intentos de autenticación a
partir del tercer intento. Si se producen más de diez
intentos de autenticación fallidos se bloquea la cuenta.
5. análIsIs de segurIdad
Para comprobar la seguridad del sistema, hemos
establecido diversos escenarios de ataque contra
el esquema de acceso propuesto.
D.o.s. (cLiente)
Los ataques de denegación de servicio contra
una cuenta concreta son posibles desde el momento en que la cuenta se bloquea cuando se
realizan más de diez intentos de acceso fallidos.
Para que el ataque sea exitoso, el atacante debe
conocer por adelantado el ID del usuario. La solución propuesta a este tipo de ataque es evitar
el bloqueo automático de la cuenta manteniendo
un tiempo mínimo entre intentos de login y almacenando las direcciones de acceso del cliente.
Un esquema de validación alternativo basado
en tiempo como el propuesto por Ramasamy y
Muniyandi [7] puede ayudar a paliar el problema.
D.o.s. (seRviDoR)
Debido a la temporización de las peticiones de
login, aumentar desde un solo ordenador el número de accesos a la aplicación de autenticación
no llega a sobrecargar la capacidad de cálculo
del servidor. El primer filtro basado en ID / PASS
no supone apenas carga para el servidor, ya que
no representa ningún cálculo.
Gran parte de la carga de cifrado y descifrado
del “token” se lleva a cabo en el navegador del
usuario, traspasándole a él la carga de cálculo
necesaria para estas operaciones.
Al retardar el número de peticiones posibles
desde una misma dirección IP se limita la carga
generada por un solo ordenador en el servidor,
de manera que no hemos encontrado posible un
ataque de denegación de servicio contra el servidor si no se realiza de manera distribuida.
AtAques poR FueRzA BRutA
Sin conocer la clave almacenada en el USBKey
es muy improbable que un ataque por fuerza
bruta pudiera prosperar contra el esquema propuesto en un tiempo razonable. A día de hoy las
claves RSA 2048 se consideran seguras computacionalmente [8] hasta el 2030.
peRDiDAs De LA usBKey
En caso de pérdida del USBKey, el atacante
debe conocer aún el par ID / PASS para lograr
el acceso al servidor.
En el momento que el usuario notifica a la entidad que provee el servicio la perdida del USBKey, la clave RSA empleada para realizar la
autenticación de dicho usuario debe eliminarse
del ServerStorageKey.
Es posible el empleo de USBKeys con código
PIN externo como medida para aumentar la seguridad, en el caso de emplear este esquema
para tareas clave que requieran una seguridad extra.
Otra alternativa es almacenar la clave en el USBKey cifrada de manera que cada vez que el
usuario desee acceder a la misma, se le requiera
un PIN. En una primera aproximación se ha desestimado este sistema debido a las complicaciones adicionales, que reducen de manera efectiva
la facilidad de uso del sistema.
AtAque MAn-in-the-MiDDLe WeBinject
Siguiendo los análisis de ataque mediante malware con virus del tipo spyeye o Zeus [9], diseñamos un programa que realiza un ataque de
este tipo sobre nuestro esquema de autenticación. El atacante introduce este software en el
ordenador del cliente y el virus se encarga de realizar un ataque de tipo ‘Man in the middle’. El
propio malware incluye un proxy que se encarga
de establecer la sesión con el servidor, violando
así el túnel ssl. Además de interceptar el tráfico
entre el cliente y el servidor el malware infecta el
sistema de certificados del navegador para que
no se detecte que el certificado enviado por el
proxy del malware no corresponde al certificado
ssl esperado del servidor.
A partir de ese momento, toda la información
pasa de forma clara a través del malware, que
puede leer el tráfico a voluntad e inyectar código
en la sesión. Para realizar esto al atacante le
basta con conocer el funcionamiento del esquema de autenticación y reconocer y enviar las
diferentes peticiones de información entre cliente
y servidor para obtener un login válido en el servidor.
Para aumentar el nivel de seguridad, se puede
proceder al cifrado mediante la clave almacenada
en el USBKey de todas las transacciones que im-
pliquen cambios en la información del usuario.
Dicho sistema de cifrado queda fuera del ámbito
del estudio actual y se propone como trabajo
futuro.
6. conclusIones
El estudio muestra un incremento de varios órdenes de magnitud en el control de acceso a la
información privada mediante el esquema propuesto.
La ventaja de centralización y del control de
las claves por parte de la institución proveedora
del servicio debe corresponderse con un alto nivel
de seguridad y responsabilidad por parte de dicha
institución.
El uso de claves almacenadas en dispositivos
de tipo USB supone una ventaja de acceso respecto a sistemas basados en SmartCard, ya que
elimina la necesidad de un lector específico externo. Aun así, siguen existiendo limitaciones al
acceso desde determinados dispositivos móviles
que no poseen puertos USB de manera nativa.
En cuanto a los ataques realizados, el sistema
ha demostrado ser seguro contra las amenazas
más habituales, pero vulnerable a un ataque específico con un esquema sofisticado de tipo proxy
‘Man in the Middle’ como el empleado por la última generación de sistemas de malware de
fraude bancario.
En resumen, podemos afirmar que el diseño
propuesto ha mostrado una mejora sustancial de
la seguridad respeto a los esquemas tradicionales, mejorando además la percepción de seguridad de uso por parte de los usuarios.
RefeRencias
[1] P. Inglesant and M. A. Sasse, “Studying Password Use in the Wild: Practical Problems and Possible Solutions,” 2010.
[2] N. Vatră, “Interoperability of Digital Signatures in Public Administration,” World of Computer Science and
Information Technology Journal, vol. 1, pp. 1–5, Aug. 2011.
[3] B. Schneier, “Two-factor authentication: too little, too late,” Communications of the ACM, vol. 48, no. 4,
Apr. 2005.
[4] N. A. Elfadil and Y. J. Al-raisi, “An approach for multi factor authentication for securing smart cards applications,” presented at the 2008 International Conference on Computer and Communication Engineering
(ICCCE), 2008, pp. 368–372.
[5] M. A. Sasse, S. Brostoff, and D. Weirich, “Transforming the ‘weakest link’—a human/computer interaction
approach to usable and effective security,” BT technology journal, vol. 19, no. 3, pp. 122–131, 2001.
[6] M. Ortega and S. Sánchez, “University Authentication System Based on Java Card and Digital X.509 Certificate,” pp. 1–7, Aug. 2012.
[7] R. Ramasamy and A. P. Muniyandi, “An Efficient Password Authentication Scheme for Smart Card,” International Journal of Network …, 2012.
[8] NIST, “Cryptographic Algorithms and Key Sizes for Personal Identity Verification,” csrc.nist.gov. [Online].
Available: http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-3.pdf. [Accessed: 22-Feb-2013].
[9] “Win32/Gataka banking Trojan – Detailed analysis | esetireland,” blog.eset.ie. [Online]. Available:
http://blog.eset.ie/2012/08/15/gataka-banking-trojan/. [Accessed: 22-Feb-2013].