integración de smartcards a kerberos v5

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