Integración de Smartcards a Kerberos V5 Luis Lizama 437591 Asesor: Dr. Roberto Gómez

Plan de la presentación Introducción Protocolo de Kerberos V5 Integración de Smartcards y Kerberos V5 Avances en la implementación

Introducción Kerberos es un protocolo de autenticación en red. Esta diseñado para proveer una autenticación robusta en aplicaciones cliente servidor usando criptografía de llave secreta.

¿Por Qué Usar Kerberos? Los esquemas de autentificación estan basados en passwords (texto plano). Los clientes utilizan servicios ejecutados en algun servidor de la red. El password del cliente cruza la red hasta llegar al servidor. Hackers que usan programas que sirven para Sniffear passwords de la red.

Pero... Esto es sólo es el comienzo de una serie de pasos más para la privacidad de datos. Ya que las aplicaciones que no mandan un password encriptado por la red son de gran riesgo para la privacidad e integridad de datos. El servidor confía en que el usuario “es quién realmente pretende ser”.

Kerberos Kerberos fue creado por el MIT como una herramienta para solucionar los problemas de la red ya mencionados. Usa una criptografía robusta para que a través de una red insegura: El cliente pueda comprobar su identidad a un servidor. El servidor pueda comprobar su identidad al cliente. Y como ventaja puede encriptar toda la comunicación que existe entre las dos partes.

Ventajas Kerberos es una aplicación gratuita disponible en el MIT (con sus respectivas restricciones). Sólo para el sistema de Unix, ya que para Windows existen restricciones de exportación.

Desventajas de Kerberos En muchas aplicaciones el programa debe ser modificado para así poder usar las librerías de Kerberos (implica un gran conocimiento de programación).

Protocolo de Kerberos Kerberos se compone de tres partes, tal que sí cualquiera de estas falla, la seguridad no se puede garantizar: El cliente. El servidor El administrador (Kerberos)

Tipos de Llaves 1. Llave privada (secretas). Conocida únicamente por Kerberos y el cliente a quien pertenece. 2. Llave de sesión. Conocida únicamente por Kerberos, el cliente y servidor que interactúan.

Llaves Llave secreta del Cliente Llave secreta del TGS Llave de sesión entre el Cliente y el TGS Llave de sesión entre el Cliente y un Servidor Llave secreta del TGS Llave secreta de un Servidor

Elementos KERBEROS KAS TGS 2 3 1 4 USUARIO CLIENTE 5 SERVIDOR 6

Solicitud de ticket para TGS cliente Quiero accesar TGS CLIENTE KAS Ticket para accesar TGS CLIENTE KAS

El ticket contiene: Ticket para accesar TGS Nombre del servidor que se desea accesar Nombre del cliente que lo obtuvo La hora de obtención (timestamp) Vigencia

Solicitud de ticket al TGS para entrar al servidor Cliente CLIENTE TGS Ticket para accesar Servidor TGS CLIENTE Cliente

SOLICITUD DE SERVICIO Y AUTENTIFICACIÓN MUTUA Tiempo Cliente Tiempo CLIENTE SERVIDOR Tiempo vs Tiempo Tiempo CLIENTE SERVIDOR Cliente Tiempo

En Resumen TGS 2 3 1 4 5 6 1) Solicitud de ticket para TGS KERBEROS TGS USUARIO CLIENTE SERVIDOR 1 2 3 4 5 6 1) Solicitud de ticket para TGS 2) Ticket para el TGS 3) Solicitud de ticket para servidor 4) Ticket para servidor 5) Solicitud de servicio 6) Autentificacion del servidor

3. Integración de Smartcards y Kerberos V5 ¿Cómo pueden las smartcards ayudar a Kerberos ? “Hay problemas insolubles sin el empleo de hardware de propósito especial; sin importar el diseño del protocolo”

Los problemas son: Necesidad de un dispositivo de encripción segura. Necesidad de un almacen seguro de llaves. Ataques de diccionario sobre passwords.

Dispositivo externo de encripción Ku es expuesto a dos partes: el usuario y la workstation Es deseable decriptar el TGT fuera de la workstation

Almacenamiento de llave seguro Un secreto es difícil de almacenar en disco o memoria porque: Un adversario potente puede leerlo y escribirlo Usualmente es respaldado en dispositivos de almacenamiento masivo, que carecen de protección física y criptográfica Almacenamiento seguro fuera de la workstation y KDC es importante

Ataque de Diccionario Cuando un usuario escoge un mal password , Ku es objeto de un ataque de diccionario Es necesario usar preatenticación :

Cuando el cliente pide el TGT, envía el nombre de usuario y el timestamp encriptado con Ku Si el KDC puede decriptar el mensaje con Ku, está seguro de que el cliente conoce Ku Después de la preautenticación el KDC envía el TGT encriptado con Ku a la estación de trabajo...

Sin embargo, el adversario puede aún espiar la red Sin embargo, el adversario puede aún espiar la red ...y reconocer el plaintext: username, realmname. El ataque de diccionario no se resuelve completamente. Es deseable usar passwords generados en forma aleatoria, almacenados en un hardware resistente. Un smartcard es el dispositivo ideal para resolver los problemas anteriores.

Metas del Diseño Usar Ku generada aleatoriamente. Lo cual requiere una manera para que los usuarios posean sus llaves. Almacenar la llave en una smartcard, porque está diseñada tamper-proof con mecanismos de comunicación restringidos. Decriptar el TGT en la smartcard. Una smartcard tiene mecanismos de encripción y decripción DES. No modificar al KDC

Protocolo Cuando la workstation recibe el TGT , no lo puede decriptar por sí mismo, en su lugar, envía el TGT al smartcard. La smartcard decripta el TGT y regresa el TGT en plaintext a la workstation

Si la workstation confirma que el TGT es correcto, el protocolo termina y el usuario es autenticado. El TGT es decriptado en una smartcard, Ku nunca deja la smartcard, Ku usa bits aleatorios, y el KDC no es modificado.

Implementación y resultados

Detalle de la Interfaz Gráfica para Expedición de Tickets

Detalle del archivo KRB5.conf Componentes principales: Nombre de Reino Nombre de Host: Kdc Nombre de Host: admin_server

Detalle del archivo KDC.conf Componentes principales: Nombre de Reino Tiempo de vida Tiempo de renovación

Los comandos La Base Datos

Añadiendo un principal

1° Agregar llave a tabla KEYTAB 2° Invocar los demonios kadmind y krb5kdc

Uso de KINIT para Ticket Uso de KLIST para lista

Detalle de Ticket

El administrador obtiene un ticket y usa una conexión segura (kadmind) para crear el secreto KDC-host servidor

KDC USER Login Workstation Cliente Kinit: ticket KAS: usuario definido y prompt password KAS: usuario definido Kinit envía a KDC Regresa TGT Cliente rlogin envía TGT Kinit vs. Password Cliente: rlogin, host remoto Regresa TGS Cliente rlogin envía TGS y el Servidor klogind autoriza TGS:Si usuario definido

shell% telnet daffodil.mit.edu Trying 128.0.0.5 ... Connected to daffodil.mit.edu. login: david Password: <- david types his password here shell% telnet -a -f -x trillium.fubar.org Trying 128.0.0.5... [ Kerberos V5 accepts you as"jennifer@fubar.org" ] [ Kerberos V5 accepted forwarded credentials ] NetBSD 1.1: Tue May 21 00:31:42 EDT 1996 Welcome to NetBSD! shell%

Habilitando los comandos Kerberizados en xinet.d

Los resultados obtenidos con rsh, rlogin, telnet

Comentarios adicionales Para evitar los cuellos de botella en los procesos de autenficación es ventajoso dividir la red en reinos (“realms”). Cada Reino tiene su propio AS , su propio TGS y su propia BD de kerberos (KBD). Cada Reino puede tener uno o más servidores esclavos con copias de sólo lectura de la KBD.

Desde la perspectiva del cliente Difícilmente notará que Kerberos está presente pero la información confidencial transmitida a través de la red permanece privada. Kerberos es un protocolo de autentificación basado en encripción convencional que ha recibido soporte amplio y es usado en una variedad de sistemas.