Autenticación

Seguridad
Autenticación
Juan Manuel Madrid Molina

Universidad Icesi
Contenido de la sesión
  Sistemas de autenticación
 Basados en password
 Basados en dirección
 Protocolos criptográficos de autenticación
 Intermediarios confiables (KDCs)
 Claves de sesión
 Autorización
 Delegación
Seguridad - Juan Manuel Madrid 2
1
  Autenticación de personas
 Passwords, problemas
 Tokens de autenticación
 Acceso físico
 Sistemas biométricos
  Handshake seguro
 Login
 Autenticación mutua
 Integridad y cifrado de datos
 Autenticación mediada (con KDC)
2
  Kerberos
 Tiquetes
 Configuración
 Procedimiento de logon
 KDCs replicados
 Realms (dominios)
 Cifrado
Autenticación: ¿Qué es?

  Verificaren forma confiable la identidad de
alguien (o algo)
  Mundo real
 Apariencia, voz
 Cédula con foto
 Tarjeta de crédito
  Fecha de vencimiento
  Código de seguridad (3 dígitos)
3
  Autenticación en redes
 Computador autentica computador
 Computador autentica persona

  Se puede autenticar a algo o a alguien:
 Por algo que ES
 Por algo que PUEDE GENERAR
 Por algo que TIENE
 Por algo que SABE
  Combinación de factores
4
Autenticación basada en
passwords
  Algo que el usuario conoce
  Origen: La guerra
Autenticación basada en
passwords
  Problema: Espionaje
  ¿Por qué no se usa criptografía?
 Protocolo concebido originalmente para
interacción con humanos
 Costo
 Problemas legales
  Caso: Teléfonos celulares
 ESN + número de línea
5
Problemas de los passwords
  Espionaje “por encima del hombro”
  Robo de la base de datos de usuarios
  Passwords débiles
 Fáciles de adivinar
  Reglas complicadas
 Sistema inaccesible
 ¡Los usuarios escriben los passwords!
Adivinar passwords “en línea”

Ubuntu 6.06 LTS (Dapper)
  Passwords obvios login: root
Password:
  Número de intentos
Login incorrect
 Bloqueo login: root
Password
 Cerrarconexión
Login incorrect
 Demorar el proceso …
 Puede usarse como técnica para DoS
  Importancia de los “buenos” passwords
6
Adivinar passwords
“fuera de línea”
  Robo archivo de passwords
  El atacante puede tomarse todo el tiempo
necesario
 John the Ripper
  Solución: Cifrar el archivo de passwords
 Mantenerla clave en memoria
 Windows 2000 y superiores: SYSKEY
SYSKEY
7
Otros problemas
  Usar el mismo password en múltiples
sitios
 Efecto dominó
  Cambios demasiado frecuentes
  Caballo troyano de captura de passwords
  Distribución inicial de los passwords
Tokens de autenticación
  Dos factores
  Tarjetas inteligentes
 Tarjeta de memoria protegida con PIN
 Tarjetas criptográficas desafío/respuesta
  Requieren de hardware especial en las

terminales
8
Tokens de autenticación
  Calculadoras criptográficas
 Tarjetainteligente sin lector
 No requieren de hardware especial
 Versiones en software
Acceso físico
  Puede implementarse, dependiendo de la
política de seguridad
 Guardias
 Acceso únicamente desde ciertas terminales
 Otorgar privilegios dependiendo del sitio
donde se efectúe el acceso
9
Dispositivos biométricos
  Escáner de retina
 Vasos sanguíneos
  Lectores de huella digital
10
  Lectores de huella palmar
  Geometría de la mano
  Da más falsos positivos que la
huella
  Huella de voz
 Se puede engañar con una grabación
 ¿Y si la persona se enferma?
11
  Estilo de escritura
 ¡Toda persona tiene
una forma diferente
de usar el teclado!
 Fuerza, longitud de
las pulsaciones,
pausas
  Firmas
 Dibujo + forma cómo se hace
12
  Ninguno es inherentemente seguro
 Se transmite información al computador
 Debe tenerse en cuenta algún mecanismo de
cifrado
Sistemas de autenticación
basados en localización
  No se envían passwords
  La identidad se puede inferir por la
dirección desde donde se acceden los
recursos
  Comandos “r” de Unix Berkeley
 rlogin
 rsh
 rcp
13
Comandos “r” de Unix
  Máquinas equivalentes
 /etc/hosts.equiv
  Lista
<dirección, nombre local, nombre
remoto>
  ~/.rhosts
 Por usuario
 Dirección, nombre local, nombre remoto
Problemas
  Intruso gana acceso a un equipo
 Tieneinmediatamente acceso a TODOS los
equipos que confíen en el equipo atacado
  Intruso falsifica las direcciones de red
 IP spoofing
14
Sistemas de autenticación
basados en criptografía
  A demuestra su identidad a B
 B proporciona un dato a A
 A efectúa una operación criptográfica sobre el
dato
 B comprueba la identidad
A quién se autentica?
  Usuario
 Bernardo desea acceder a los archivos que
tiene en un servidor
  Máquina
 Réplicas de un servicio de directorio
  Usuario + máquina
 Cajero de un banco
15
A quién se autentica?
  Diferencia
entre autenticar una persona y
un computador
 Computador
  Almacena un valor secreto de alta calidad
 Usuario
  El computador lo puede almacenar por él
  El usuario debe recordar un password
  Hash
  Descifrado de una clave más robusta
Espionaje y robo de la base de

datos
  La
criptografía de clave pública evita
ambos problemas
Soy Andrea
Andrea R Bernardo
R firmado con clave privada
16
datos
  Sin criptografía de clave pública, es difícil cubrir
ambos frentes
  Este protocolo no asegura contra el espionaje
Soy Andrea, ábrete sésamo

Andrea Bernardo

datos
  Este protocolo no protege contra el robo
de la base de datos
Soy Andrea
Andrea R Bernardo
X
17
Intermediarios confiables
  La seguridad de la red funciona con el
esquema de clave secreta
  N nodos
  Cada nodo necesita conocer N-1 claves
  ¿Qué pasa si N es muy grande?
Intermediarios confiables
  Solución: Nodo confiable
  Key Distribution Center (KDC)
  Los demás nodos sólo tienen clave del KDC
  Si A decide hablar con B:
  A solicita al KDC un tiquete para hablar con B
  El KDC genera una clave
  La cifra con la clave de B y la de A, por separado
  Envía todo el paquete a A
18
Ventajas del KDC
  ¿Usuario nuevo?
  ¿Recurso nuevo?
  ¿Clave comprometida?
  ¡Solamente hay que cambiar la clave en
un sitio!
Desventajas del KDC

  El
KDC tiene suficiente información para
validar a cualquiera contra cualquiera!
 ¿KDC comprometido?
  El KDC es un recurso crítico
 ¡Si
falla, todo el mundo se queda por fuera!
 Múltiples KDCs: Replicación
  El KDC como cuello de botella
 Múltiples KDCs
19
Autoridad de certificación (CA)
  La distribución de claves es más fácil con
un esquema de clave pública
  Problema: Publicación de las claves
 ¿Cómo asegurarse de que la información es
correcta?
  Solución: Nodo confiable
 CA: Certification Authority
Autoridad de certificación (CA)

  La CA genera certificados
 Mensajes firmados
 Nombre de usuario y clave pública
 Fecha de vencimiento
  Se verifican con la clave pública de la CA
  Los certificados se pueden guardar en
cualquier lugar
20
Ventajas de una CA sobre un
KDC
  La CA no necesita estar en línea
  Muchísimo más simple
  Si la CA sale de servicio, la red no
  No se pueden expedir certificados nuevos
  Los certificados no son sensitivos a la seguridad
  ¡Una CA comprometida no puede escuchar
conversaciones ajenas!
  Problema con las claves...
Revocación de certificados
  Se expide un certificado para un
empleado
  El empleado es despedido
  ¿Cómo negarle acceso?
 Enun KDC es fácil…
 ¿Pero con una CA?
21
  Tarjetas de crédito
 Boletínde Datacrédito
 Terminales
  Listas de certificados revocados (CRLs)
 Seriales de certificados que no se deben
aceptar
 Publicada con frecuencia
 Estándar X.509
  Se configuran las aplicaciones para que
revisen las CRLs con frecuencia
  Posibles problemas
 Tiempo de vida de los certificados
  ¿Demasiado largo? ¿Corto?
 Revocación masiva de certificados
  Solución:
Usar número de serie
únicamente
22
Claves de sesión
  Autenticación con intercambio
criptográfico vs. password
 ¡Más segura!
  Vulnerabilidades después de la
autenticación
 Espionaje de la conversación
 Modificación o “reproducción” de la sesión
 Secuestro de la sesión
Claves de sesión
  Solución:Conversación cifrada
  ¿Qué se emplea como clave?
  Clave pública
 Cifradopara confidencialidad
 Firma para integridad
 Problema: ¡Operaciones costosas!
23
Claves de sesión
  Clave secreta
 Se crea durante el handshake
  ¿Por qué generar una clave de sesión?
 Una clave se “gasta” si se usa mucho
 Inyección de paquetes de una conversación
anterior
Claves de sesión
  ¿Por qué generar una clave de sesión?
 Evitar descifrado de conversaciones
anteriores (mal uso de la clave de largo plazo)
 Si el receptor es poco fiable, es buena idea
usar una clave desechable en lugar de una
permanente
24
Ejemplo: SSL
  Secure Sockets Layer
  Esquema más popular para cifrado de
páginas web
  Inicio: Contactar el servidor por el puerto
443
 HTTPS
SSL
Métodos de cifrado + desafío
Métodos soportados + Certificado + desafío
Verificar certificado:
- Nombre del sitio
- CA válida
- Fecha de expedición / vencimiento
25
SSL
SSL
Clave secreta preliminar
Inicio uso de clave de sesión
Fin negociación
Generación de clave Generación de clave

de sesión de sesión
26
SSL
Inicio uso de clave de sesión
Fin negociación
… Conversación cifrada …
Autorización
  Autenticación = ¿Quién soy?
  Autorización = ¿Qué puedo hacer?
  Ejemplo: Acceso en una red
ACL
Usuarios
Recursos
27
ACLs
  Cruce completo de recursos vs. usuarios
 Problemas de escalabilidad y mantenimiento
 Alta granularidad
  Grupos
 Matricularusuarios
 Especificar al grupo en la ACL
 Grupos jerárquicos
Delegación
  Trabajar en nombre de otro
  Esquemas
  Dar password propio a la persona / recurso
  Incluir a la persona / recurso en la ACL
  Delegación
  Generar mensaje firmado por el autorizador
  A quién y sobre qué se le otorga permiso
  Por cuánto tiempo
28
Delegación
  Con esquema de clave pública
 El autorizador firma el mensaje
  Con clave secreta (KDC)
 Instruiral KDC para que genere el mensaje
 Cifrarlo con la clave del KDC
 Enviarlo al autorizado
 El autorizado no puede leerlo, el KDC sí.
Handshake seguro
  Saludo inicial
  Información secreta y no secreta
  Problema
 ¡Muchos incluyen huecos de seguridad en su
diseño!
 ¡Pequeñas alteraciones (mejoras) pueden
volver inseguro un protocolo que era seguro!
29
Handshake para login con clave
secreta
  Lomás común: Enviar todo sin protección
  Mejora: Desafío / respuesta
Soy Andrea
Andrea R Bernardo
KBernardo-Andrea{R}
Debilidades
  La autenticación no es mutua
 ¡Andrea NO autentica a Bernardo!
  Sino hay más cifrado / autenticación,
alguien podría “secuestrar” la
conversación
 IP spoofing
30
Debilidades
  Sepuede tratar de averiguar el password
fuera de línea
 Desafíos + respuestas cifradas
  Si
alguien lee la base de datos del equipo
de Bernardo, puede hacerse pasar por
Andrea
 Protección de base de datos Y BACKUPS
Variante #1
Soy Andrea
Andrea KBernardo-Andrea{R} Bernardo

R
31
Diferencias
  Requiere de criptografía reversible
  El anterior se puede implementar con un hash
  Es posible averiguar la clave
  Enviarmensaje “Soy Andrea”
  Obtener KBernardo-Andrea{R}
  Kerberos v4
  Si R es reconocible (NA + timestamp), Andrea
puede autenticar a Bernardo
  Siempre que KBernardo-Andrea no haya caído en malas
manos
Variante #2
  Usar un timestamp en lugar de R
Soy Andrea, KBernardo-Andrea{TS}

Andrea Bernardo
32
Implicaciones
  Relojessincronizados
  Puede añadirse muy fácilmente a
esquemas de sólo password
  No hay necesidad de que Bernardo
recuerde los R usados
  Un espía puede hacerse pasar por Andrea
 Tolerancia de los relojes
Implicaciones
  Múltiples servidores
 Un intruso podría “reproducir” el handshake
en otra máquina
 Incluir el nombre del servidor en el mensaje
  El
intruso podría atrasar el reloj del
servidor
 Reproducción
  Y si se descuadra el reloj?
33
Handshake para login con clave
pública
  Los protocolos de clave secreta son
vulnerables a la lectura de la BD
  Se puede evitar el problema usando
claves públicas
Ejemplos
Soy Andrea
Andrea R Bernardo
FAndrea(R)
Soy Andrea
Andrea EAndrea(R) Bernardo

R
34
Problemas
  Primer protocolo
  ¡Se puede engañar a Andrea para que firme algo!
  Segundo protocolo
  ¡Se puede engañar a Andrea para que descifre algo!
  Solución
  ¡No permitir el uso de un protocolo para romper otro!
  Darle estructura a R
  PKCS
Autenticación mutua
  Problema: Algo ineficiente
Soy Andrea
R1
Andrea KAndrea-Bernardo{R1}
Bernardo
R2
KAndrea-Bernardo{R2}
35
Autenticación mutua
  Problema: Ataque de reflexión
Soy Andrea, R2
Andrea R1, KAndrea-Bernardo{R2} Bernardo

Ataque de reflexión
Soy Andrea, R2
1. Andrea R1, KAndrea-Bernardo{R2}

Bernardo
Soy Andrea, R1
2. Andrea R3, KAndrea-Bernardo{R1}

Bernardo
36
Ataque de reflexión
  Cómo evitarlo
  Usar claves diferentes
  Usar desafíos diferentes
  Uno par, otro impar
  Concatenar el nombre del usuario
  El protocolo largo no sufría de este problema!
  El iniciador debe comprobar primero su identidad
Ataque para averiguar la clave

  Un intruso puede
  Hacerse pasar por Andrea
  Hacer que Bernardo cifre un número
  Cómo evitarlo
  Pero el intruso podría hacerse pasar por Bernardo
Soy Andrea
R1
Andrea Bernardo
KAndrea-Bernardo{R1}, R2
37
Autenticación mutua con clave
pública
  Claves públicas correctas?
  Servidor de directorio
  CA
Soy Andrea, EBernardo(R2)
Andrea R2, EAndrea(R1) Bernardo

R1
Autenticación mutua con

timestamps
  Los timestamps deben ser diferentes
Soy Andrea, KBernardo-Andrea{TS}
Andrea KBernardo-Andrea{TS+1}
Bernardo
38
Integridad y encripción de datos
  Establecer una clave de sesión
 Se puede emplear información del handshake
para generarla
 La clave no debe ser fácilmente deducible del
intercambio
 Introducir incertidumbre
Autenticación mediada con KDC

  Problema de simultaneidad
 ¡Bernardo recibe el primer mensaje de datos
antes de la clave!
 El protocolo Kerberos resuelve este problema
Quiero hablar con B
Andrea KA{Use KAB para B}

KDC KB{Use KAB para A}
Bernardo
39
Autenticación mediada con KDC
Quiero hablar con B
KA{Use KAB para B}

KDC
Andrea KB{Use KAB para A} Bernardo
Soy A, KB{Use KAB para A}
KB{Use KAB para A} = TIQUETE para hablar con A
  Ultimo paso
  Autenticación mutua entre A y B
Kerberos
  Serviciode autenticación
  Basado en esquema de clave secreta
  Creado en el MIT
  Dos versiones: v4 y v5
40
Kerberos
  Servidor
 KDC
  Clientes
 Aplicaciones “kerberizadas”
  Compiladas con las librerías de Kerberos
 Tanto el cliente como el servidor
Kerberos
  Ejemplos de aplicaciones “kerberizables”
 Telnet
 FTP
 Comandos “r” de UNIX
 SSH
 Correo electrónico
41
Terminología
  KDC = Key Distribution Center
  AS = Authentication Server
  TGS = Ticket Granting Server
  Los dos residen en el KDC
  TGT = Ticket-Granting Ticket

  Tiquete
  Credenciales
  Clave compartida
Funcionamiento
  Usuario se identifica en una terminal
 Username + password
  La terminal solicita al KDC
 Una clave de sesión
 Un TGT
  El TGT se usa para solicitar acceso a

otros servicios / usuarios
42
Solicitud de clave y TGT
El usuario
Username, password necesita un
TGT
Estación
Usuario de KDC
trabajo KU{SU, TGT}
Crea clave SU
Busca clave KU del
usuario
TGT=KKDC{“Usuario”, SU}
Conexión a un servicio remoto

Usuario desea hablar con
Homero
telnet homero TGT=KKDC{“Usuario”, SU}
Autenticador = SU{TS}
Estación
Usuario de KDC
trabajo SU{“Homero”, KUH, tiquete a Homero}
Crea clave KUH

Desencripta el TGT para obtener SU
Desencripta y verifica el autenticador
Busca clave KH de Homero
Tiquete a Homero = KH{“Usuario”, KUH}
43
Conexión a un servicio remoto
Tiquete a Homero = KH{“Usuario”, KUH}

Autenticador = KUH{TS}
Estación
de Homero
trabajo KUH{TS + 1}
Desencripta el tiquete para obtener KUH

Desencripta y verifica el autenticador
KDCs replicados
  El KDC es un recurso crítico
  ¿Qué pasa si falla? ¿Desempeño?
  Replicación
  Un sitio: Copia maestra
  Recibe todas las actualizaciones
  Luego se distribuyen
  Si el maestro se daña, no se pueden crear

usuarios / recursos nuevos
44
Realms de Kerberos
  Se asocian con los dominios
  Permiten manejar regiones en redes
grandes
Autenticación entre realms

SOL_TGS
(“usuario@icesi”,
univalle@icesi)
KDC
Credenciales a Univalle Icesi
KDC
SOL_TGS(“usuario@icesi”, mafalda@univalle) Univalle
Usuario Mafalda
Credenciales a Mafalda
Autenticación
45
Cifrado
  PCBC (Plaintext Cipher Block Chaining)
m1 m2 m3 m4 m5
IV + + + + +
E E E E E
c1 c2 c3 c4 c5
Diferencias entre Kerberos

v4 y v5
  Kerberos v4
 Formato propietario para mensajes
 Usa solamente DES para cifrado
 Solamente opera sobre TCP/IP
  Kerberos v5
 Estándar ASN.1 para formato de mensajes
 Algoritmos de cifrado múltiples
 Protocolos múltiples
46

Autenticación

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Autenticación

Încărcat de

Drepturi de autor:

Formate disponibile

Seguridad

Juan Manuel Madrid Molina

Seguridad - Juan Manuel Madrid 2

Seguridad - Juan Manuel Madrid 3

Seguridad - Juan Manuel Madrid 4

Seguridad - Juan Manuel Madrid 5

Autenticación: ¿Qué es?

Seguridad - Juan Manuel Madrid 6

Seguridad - Juan Manuel Madrid 7

Autenticación: ¿Qué es?

Seguridad - Juan Manuel Madrid 8

Seguridad - Juan Manuel Madrid 9

Seguridad - Juan Manuel Madrid 10

Seguridad - Juan Manuel Madrid 11

Adivinar passwords “en línea”

 Puede usarse como técnica para DoS

 Importancia de los “buenos” passwords

Seguridad - Juan Manuel Madrid 12

Seguridad - Juan Manuel Madrid 13

Seguridad - Juan Manuel Madrid 14

Seguridad - Juan Manuel Madrid 15

 Requieren de hardware especial en las

Seguridad - Juan Manuel Madrid 16

Seguridad - Juan Manuel Madrid 17

Seguridad - Juan Manuel Madrid 18

Seguridad - Juan Manuel Madrid 19

Seguridad - Juan Manuel Madrid 20

Seguridad - Juan Manuel Madrid 21

Seguridad - Juan Manuel Madrid 22

Seguridad - Juan Manuel Madrid 23

Seguridad - Juan Manuel Madrid 24

Seguridad - Juan Manuel Madrid 25

Seguridad - Juan Manuel Madrid 26

Seguridad - Juan Manuel Madrid 27

Seguridad - Juan Manuel Madrid 28

Seguridad - Juan Manuel Madrid 29

Seguridad - Juan Manuel Madrid 30

 Descifrado de una clave más robusta

Seguridad - Juan Manuel Madrid 31

Espionaje y robo de la base de

Seguridad - Juan Manuel Madrid 32

Soy Andrea, ábrete sésamo

Seguridad - Juan Manuel Madrid 33

Espionaje y robo de la base de

Seguridad - Juan Manuel Madrid 34

Seguridad - Juan Manuel Madrid 35

Seguridad - Juan Manuel Madrid 36

Seguridad - Juan Manuel Madrid 37

Desventajas del KDC

Seguridad - Juan Manuel Madrid 38

Seguridad - Juan Manuel Madrid 39

Autoridad de certificación (CA)

Seguridad - Juan Manuel Madrid 40

Seguridad - Juan Manuel Madrid 41

Seguridad - Juan Manuel Madrid 42

Seguridad - Juan Manuel Madrid 43

Seguridad - Juan Manuel Madrid 44

Seguridad - Juan Manuel Madrid 45

Seguridad - Juan Manuel Madrid 46

Seguridad - Juan Manuel Madrid 47

Seguridad - Juan Manuel Madrid 48

Seguridad - Juan Manuel Madrid 49

Métodos de cifrado + desafío

Métodos soportados + Certificado + desafío

 Puede usarse como técnica para DoS

  Importancia de los “buenos” passwords

  Requieren de hardware especial en las

  Descifrado de una clave más robusta

  TGT = Ticket-Granting Ticket

  El TGT se usa para solicitar acceso a

  Si el maestro se daña, no se pueden crear