Integración de Smartcards a Kerberos V5

1. Integración de Smartcardsa Kerberos V5 Luis Lizama 437591 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. Llave secreta del Cliente Llave secreta del TGS Llave de sesión entre el Cliente y el TGS Llave secreta de un Servidor Llave de sesión entre elCliente y un Servidor Llaves

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

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

14. El ticket contiene: Ticket para accesar TGS Nombre delservidor quese desea accesar Nombre delcliente que lo obtuvo La horade obtención(timestamp) Vigencia

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

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

17. TGS KERBEROS 2 3 1 4 5 USUARIO CLIENTE SERVIDOR 6 En Resumen 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 ...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. USER KDC Login Workstation Cliente Kinit: ticket 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 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%

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.