Date post: | 25-Jan-2016 |
Category: |
Documents |
Upload: | beatriz-revuelta-gimenez |
View: | 214 times |
Download: | 0 times |
Integración de Smartcardsa Kerberos V5
Luis Lizama 437591
Asesor: Dr. Roberto Gómez
Plan de la presentación
1. Introducción
2. Protocolo de Kerberos V5
3. Integración de Smartcards y Kerberos V5
4. Avances en la implementación
1. 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).
2. 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.
LlavesLlave secreta del Cliente
Llave de sesión entre el Cliente y el TGS
Llave de sesión entre elCliente y un Servidor
Llave secreta del TGS
Llave secreta de un Servidor
Elementos
KERBEROS
TGS
USUARIO CLIENTE SERVIDOR
1
23
4
5
6
KAS
Solicitud de ticket para TGS
CLIENTE KAS
CLIENTE
cliente Quiero accesar TGS
Ticket para accesar TGS
KAS
El ticket contiene:
Ticket para accesar TGS
Nombre delservidor quese desea accesar
Nombre delcliente quelo obtuvo
La horade obtención(timestamp)
Vigencia
Solicitud de ticket al TGS para entrar al servidor
CLIENTE TGS
CLIENTE TGS
Servidor Cliente
Ticket para accesar Servidor
Cliente
SOLICITUD DE SERVICIO Y AUTENTIFICACIÓN MUTUA
CLIENTE
CLIENTE SERVIDOR
SERVIDOR
Cliente
Tiempo
Tiempo vs Tiempo
Tiempo
Tiempo
ClienteTiempo
En Resumen
1) Solicitud de ticket para TGS2) Ticket para el TGS3) Solicitud de ticket para servidor4) Ticket para servidor5) Solicitud de servicio6) Autentificacion del servidor
KERBEROS TGS
USUARIO CLIENTE SERVIDOR
1
23
4
5
6
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 ...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
– 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
Protocolo
– 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.
3.Implementación y resultados
Detalle de la Interfaz Gráfica para Expedición de Tickets
Detalle del archivo KRB5.conf
Componentes principales:
1. Nombre de Reino
2. Nombre de Host: Kdc
3. Nombre de Host: admin_server
Detalle del archivo KDC.conf
Componentes principales:
1. Nombre de Reino
2. Tiempo de vida
3. 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
Login Workstation
Cliente Kinit: ticket
y prompt password
Kinit envía a KDC
KAS: usuario definido
Regresa TGT
Kinit vs. Password
Cliente: rlogin, host remoto
Cliente rlogin envía TGT
TGS:Si usuario definido
Regresa TGS
Cliente rlogin envía TGS y el Servidor klogind autoriza
KDCUSER
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"[email protected]" ] [ 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.