Integración de Smartcards a Kerberos V5

Presentación del tema: "Integración de Smartcards a Kerberos V5"— Transcripción de la presentación:

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

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

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

4 ¿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.

5 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”.

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

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

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

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

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

11 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

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

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

14 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

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

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

17 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

18 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”

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

20 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

21 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

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

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

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

25 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

26 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

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

28 Implementación y resultados

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

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

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

32 Los comandos La Base Datos

33 Añadiendo un principal

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

35 Uso de KINIT para Ticket
Uso de KLIST para lista

36 Detalle de Ticket

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

38 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

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

40 Habilitando los comandos
Kerberizados en xinet.d

41 Los resultados obtenidos
con rsh, rlogin, telnet

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

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