13 Establecimiento de una clave compartida: intercambio de claves Diffie-Hellman: protocolo 1.-A inicia el protocolo enviando a B un mensaje que contiene (n, g, gx mod n) 2.-B responde con gy mod n. Ahora A toma gy mod n y lo eleva a la potencia x para obtener (gy mod n)x mod n que por las leyes de la aritmética modular es gxy mod n. B procede igual. Ahora A y B comparten una clave secreta: gxy mod n. Intrusos: C conoce n y g, pero le falta x e y. Además, de (gx mod n) no se conoce un algoritmo práctico para calcular logaritmos discretos módulo de un número primo muy grande.
14 Establecimiento de una clave compartida: intercambio de claves Diffie-Hellman: ataque de brigada de cubetas o ataque de alguien en medio Ataque: Cuando B recibe la tripleta (n, g, gx mod n), no sabe si es A o C quien se la ha enviado. No hay manera de saberlo. Ahora todos hacen la aritmética modular: A calcula gxz mod n, B calcula gyz mod n y C calcula las claves tanto para A como B Cada mensaje que A y/o B envía durante la sesión cifrada es capturado por C, almacenado, modificado y pasado (opcionalmente) a B y/o A. C ve todo y puede modificar los mensajes, mientras A y B están pensando equivocadamente que tienen un canal seguro entre ambos. MEJORA: utilizar un KDC, centro de distribución de claves.
15 TACACS+ y RADIUS TACACS+ (Terminal Access Controller Access Control System-RFC1492) y RADIUS (Remote Authentication Dial In User Service- RFC2138) son ejemplos de centros de distribución de claves o también conocidos como servidores de control de acceso. TACACS+ y RADIUS son protocolos para descentralizar el control del acceso, de forma que cualquier servicio en red que requiera validar, autorizar o auditar a un usuario lo puede hacer como cliente de los servidores TACACS+ y/o RADIUS. Estos servidores se utilizan generalmente como apoyo a los routers de servidor de acceso remoto, por ejemplo la gestión de usuarios que conectan desde el exterior a la Universitat por RDSI o POTS.
Ejemplo. Ambos junto Kerberos, son servidores utilizados para dar soporte a los servicios AAA de los routers de Cisco Systems: Authetication (quién), Authorization (qué), Accounting (auditoria))
Otros servidores de acceso son los servicios ACTIVE DIRECTORY de Microsoft en los Controladores de Dominio Microsoft.
16 Protocolos para AAA Access Control Server (ACS): Tacacs+, Radius, Kerberos V
17 Validación de identificación usando un centro de distribución de claves (KDC) En Diffie-Hellman no hay garantías por el ataque de alguien en medio, efectuado por un extraño o intruso. Otro inconveniente, es que para hablarle a n personas de esta manera se requerían n claves, una verdadera carga. Un enfoque diferente es introducir un centro de distribución de claves fiables (KDC), donde cada usuario tiene una sola clave compartida con el KDC, de forma que la validación de identificación y la administración de claves de sesión ahora pasan a través del KDC. El protocolo de validación e identificación más simple conocido es “la rana de boca amplia”.
18 Validación de identificación usando un centro de distribución de claves (KDC): la rana de boca amplia 1.- A escoge una clave de sesión, KS e indica al KDC que desea hablar con B usando KS. Este mensaje se cifra con la clave secreta que comparte A sólo con el KDC, KA. 2.- KDC descifra este mensaje, extrayendo la identidad de B y la clave de sesión. Construye un mensaje nuevo cifrado con KB (compartido entre KDC y B) que contiene la identidad de A y la clave de sesión y se lo envía a B. Ahora, A y B pueden hablar y saben además la clave a utilizar. La validación de identificación aquí es gratuita, en el sentido que las claves con el KDC son secretas y nadie más habría sido capaz de cifrarlo con la clave secreta de otro. A diferencia de Diffie Hellman, aquí si existe autenticación por ambas partes.
19 Ataque: un intruso C puede copiar el mensaje 2 (de KDC a B) y todos los mensajes que le siguen y reproducirlos de nuevo para B, con lo cual B creerá estar hablando con A. Pero C no sabe Ks repite sin saber lo que dice, pero interfiere en B e incluso podría generar denegación de servicio (DoS). Soluciones posibles: 1.- incluir una marca de tiempo en cada mensaje de forma que pueda descartar mensajes obsoletos, pero los relojes nunca están perfectamente sincronizados en toda una red 2.- incluir un número de mensaje único (llamado núnico), de forma que cada parte entonces tiene que recordar todos los núnicos y rechazar cualquier mensaje que contenga un núnico previamente usado Comentarios: Si una máquina se cae y pierde la lista de núnicos, es vulnerable a un ataque por repetición. Las marcas de tiempo y los núnicos pueden combinarse para limitar el tiempo que pueden recordarse los núnicos, pero el protocolo se volverá mucho más complicado. Validación de identificación usando un centro de distribución de claves (KDC): ataque por repetición
20 Validación de identificación usando un centro de distribución de claves (KDC): protocolo de Needham-Schroeder (1/2) Mejora: se basa en usar un protocolo multisentido de reto-respuesta, en vez de una única transacción. 1.- A indica al KDC que quiere hablar con B, incluyendo un número aleatorio grande, RA, como núnico. 2.- KDC devuelve el mensaje 2 que contiene RA, una clave de sesión, y un billete que puede enviar a B (identificando a A y la clave de sesión Ks). El objeto del número aleatorio, RA, es asegurar a A que el mensaje 2 es reciente, y no una repetición. La identidad de B también se incluye por si a C se le ocurre reemplazar B del mensaje 1 por su propia identidad, para que el KDC cifre el billete al final del mensaje 2 con KC en lugar de KB y sabotee a A, haciendo creer a A que habla con B, cuando en realidad lo hace con C. El billete cifrado con KB se incluye dentro del mensaje cifrado para evitar manipulaciones de C.
21 Validación de identificación usando un centro de distribución de claves (KDC): protocolo de Needham-Schroeder (2/2) 3.- A ahora envía el billete a B, junto con un nuevo número aleatorio, RA2, cifrado con la clave de la sesión, KS. 4.- En el mensaje 4, B devuelve KS(RA2-1) para demostrar a A que está hablando con el verdadero B. El envío de regreso de KS(RA2) no habría funcionado, puesto que C lo podría haber robado del mensaje 3.[1] 5.- A está convencido de que está hablando con B, y de que no se pudieron haber usado repeticiones hasta el momento. El propósito del mensaje 5 es convencer a B de que realmente está hablando con A, y de que tampoco se han usado repeticiones aquí.
[1] Al hacer que cada parte genere un reto y responda a otro, en nuestro caso (-1), se elimina la posibilidad de un ataque por repetición.
22 Validación de identificación usando un centro de distribución de claves (KDC): ataque del protocolo de Needham-Schroeder Debilidad del protocolo de Needham-Schroeder o ataque del protocolo de Needham-Schroeder: Si C llega a obtener una clave de sesión vieja KS en texto normal, puede iniciar una nueva sesión con B repitiendo el mensaje 3 correspondiente a la clave obtenida con KS(Rc) y convencerlo de que es A con KB(A,KS), que lo guardó C copiado de un mensaje 3 antiguo, completando el protocolo sin problema con los mensajes 4 y 5, y suplantando la identidad de A.
Solución: Otway y Rees publicaron un protocolo que resuelve el problema, haciendo que B hable con el KDC.
23 Validación de identificación usando un centro de distribución de claves (KDC): protocolo de Otway y Rees 1.- A comienza por generar un par de números aleatorios: R, que se usará como identificador común, y RA, que A usará para retar a B. 2.- Cuando B recibe este mensaje, construye un mensaje nuevo a partir de la parte cifrada del mensaje de A con KA, y uno análogo propio con KB. Ambas partes cifradas, identifican: A, B, el identificador común R y un reto RA o RB respectivamente. 3.- KDC comprueba que R de ambas partes es igual. Los R podrían no serlo porque C alteró el R del mensaje 1 y reemplazó parte del mensaje 2. Si los 2 R son iguales, el KDC se convence de que el mensaje de solicitud de B es válido, y genera una clave de sesión, una para A y otra para B. Cada mensaje contiene un número aleatorio del receptor como prueba de que el KDC, y no C, generó el mensaje.
24 Perro de tres cabezas y cola de serpiente según mitología griega, guardián de la entrada del Templo de Hades (Infierno). Autenticación con Kerberos Servicio de autenticación desarrollado en el Massachusetts Institute of Technology (MIT)
25 Protocolo de autentificación Kerberos Kerberos es un KDC diseñado por el MIT (Massachusetts Institute of Technology) para autentificar la identidad de los usuarios de una red digital insegura, así como para distribuir las claves secretas de sesión transitorias que permitan a los usuarios de la red establecer comunicaciones seguras. En ocasiones estas claves de sesión transitorias pueden ser un solo uso (OTP, One Time Password). Está basado en una variación de Needham-Schroeder, con la condición que requiere relojes bien sincronizados. Kerberos actúa como un árbitro en quien los usuarios confían, utilizando con cada usuario una clave secreta diferente, intercambiada con Kerberos a través de un canal seguro. El conocimiento de dicha clave se utiliza como prueba de identidad del usuario. La autentificación se produce entre cliente-servidor y servidor-cliente. En estas condiciones como Kerberos conoce las claves secretas de todos los usuarios, puede demostrar a cualquiera de ellos la autenticidad de la identidad de otro.
26 Protocolo de autentificación Kerberos: protocolo (1/2) A y B no comparten ninguna clave secreta, excepto con el servidor de claves Kerberos Ka y Kb. [A y B pueden ser usuarios, usuario-servicio,…] 1.- A solicita a Kerberos una credencial para conectarse con B y una clave de sesión, a través de un mensaje con un valor aleatorio RA y los identificadores en la red de comunicación de A y B. 2.- Kerberos genera una clave de sesión aleatoria K y define el período de validez L de la credencial, cifrando a continuación los valores K, L, RA y B con la clave secreta Ka, junto con la credencial para B, cifrando K, L y A con la clave secreta Kb
27 Protocolo de autentificación Kerberos: protocolo (2/2) A recupera K, L, RA y B para el que fue emitida la credencial. A verifica que el valor aleatorio RA corresponde con el que él previamente envió y guarda L como referencia. A continuación, A calcula el autentificador para la credencial con B, cifrando su identidad A y su sello temporal Ta para sincronización, con la clave de sesión K 3.- B descifra la credencial con su clave secreta Kb, recuperando de esta forma K, L y la identidad A y con ello utiliza K para descifrar el autentificador y recuperar los valores identidad de A y Ta, comprobando que las identidades de la credencial y el autentificador coinciden, y que el sello Ta es válido y se encuentra en los límites de L. 4- Si las comprobaciones son satisfactorias, B se convence de la autenticidad de la identidad de A, y en tal caso, B envía a A la conformidad con K(Ta+1) Por su parte A descifra la conformidad con la clave de sesión K y verifica que el valor recuperado es Ta+1, lo cual asegura a A que la clave de sesión K ha sido correctamente recibida por el usuario B.
28 Protocolo de autentificación Kerberos: comentarios (1/2) 1.-El propósito del sello temporal Ta y del período de validez L es doble que el usuario A pueda utilizar la credencial para realizar sucesivas autentificaciones ante B durante el período de validez de la clave sin necesidad de que intervenga Kerberos 2.- permite prevenir un posible ataque activo al protocolo consistente en el almacenamiento de las claves para su posterior reutilización. Esto se consigue puesto que una clave no se acepta como válida si su sello temporal no se encuentra dentro de los límites del período de validez de la misma. 3.- Kerberos viene en la mayoría de distribuciones UNIX y/o Linux, utilizado en procesos como login, rlogin o NFS (Network File System) y las versiones más utilizadas son v4 y v5 4.- es centralizado y no distribuido en una red, lo cual si falla …o si se ve comprometido, se compromete toda la red, además las claves almacenadas son privadas y no públicas. En versión 4 y/o 5 incorpora servidores secundarios.
29 Protocolo de autentificación Kerberos: comentarios (2/2) 5.- requiere la kerberización (modificación) de todas las aplicaciones, así como de la sincronización de todas las máquinas 6.- cuando un usuario está más de 8 horas (por defecto) delante de una estación de trabajo kerberizada, debe identificarse otra vez 7.- en ningún momento los passwords viajan por la red ni guardados en memoria, sólo las credenciales 8.- Cabe destacar del protocolo visto, que realmente se distinguen dos partes, por una lado la autentificación y por otro la gestión de tickets para los diferentes servicios
30 Autentificación con Kerberos: ejemplo de login Escenario: usuario A a través de login requiere de las credenciales necesarias para acceder a otros servicios Pasos: 1.- al teclear el nombre, el login kerberizado envía el nombre al servidor Kerberos solicitando un ticket 2.- si el usuario es conocido, le manda un mensaje cifrado, donde utilizará su contraseña (password) para descifrarlo. De esta forma la contraseña nunca viaja por la red 3.- de dicho mensaje extrae el ticket para realizar la petición de servicio
31 Validación de identificación de clave pública Supongamos que A y B ya conocen las claves públicas del otro EB() y EA() respectivamente y quieren establecer una sesión utilizando criptografía de clave secreta, ya que típicamente es de 100 a 1000 veces más rápida que la criptografía de clave pública. El propósito de este intercambio inicial entonces es validar la identificación de ambos utilizando sus claves públicas recíprocamente para comunicarse y utilizando las claves privadas para descifrar y tras ello acordar una clave de sesión secreta compartida con el siguiente protocolo: Vemos que el intruso C no tiene manera de conocer RA para replicar, pero dependiendo de cómo se intercambien las claves públicas, podría haber problemas…
32 Validación de identificación de clave pública (debilidades): ataque de brigada de cubetas Supongamos que A y B no conocen la clave pública del otro, por lo que bastaría simplemente A enviar a B su clave pública en el primer mensaje y pedir a B que devuelva la suya en el siguiente. El problema de este enfoque es que está sujeto a un ataque de brigada de cubetas o alguien en medio. C puede capturar el mensaje de A a B y devolver su propia clave a A, que pensará que tiene una clave para hablar con B cuando, de hecho, tiene una clave para hablar con C. Ahora C puede leer todos los mensajes cifrados con lo que A piensa es la clave pública de B. Solución: El intercambio inicial de claves públicas puede evitarse almacenando todas las claves públicas en una base de datos pública. Así, A y B pueden obtener la clave pública del otro de la base de datos. PERO, sin embargo, C aún puede poner en práctica el ataque de brigada de cubetas interceptando las solicitudes a la base de datos y enviando respuestas simuladas que contengan su propia clave. De ahí la aparición de certificados digitales gestionados por una autoridad de certificación, como veremos en la siguiente parte.
33 Validación de identificación de clave pública: protocolo de interbloqueo A?C ? B Rivest y Shamir del RSA han diseñado un protocolo que fustra el ataque de brigada de cubetas o alguien en medio de C. En su protocolo de interbloqueo, tras el intercambio de claves públicas:
A envía solo la mitad de su mensaje a B, conocido como INTERBLOQUEO. Por ejemplo sólo los bits pares (después del cifrado) B entonces responde con sus bits pares. A tras recibir los bits pares de B, envía sus bits nones, y luego lo hace B. Si A o B no realiza la entrega de sus primeras partes, el protocolo falla. El truco aquí es que, cuando C recibe los bits pares de A, no puede descifrar el mensaje, aunque tiene la clave privada. En consecuencia, C es incapaz de volver a cifrar los bits pares usando la clave pública de B. Si C envía basura a B, el protocolo continuará, pero B pronto se dará cuenta de que el mensaje reensamblado no tiene sentido y de que ha sido engañado.
34 Ejemplo de protocolo de Interbloqueo A quiere hablar con B, pero C se ha interpuesto. El protocolo de Interbloqueo, consiste en que A y B se intercambien los mensajes iniciales cifrados con las claves públicas intercambiadas, pero en dos partes (mitades). La idea es dejar a C, si se ha interpuesto, fuera de juego. Suponemos que A cifrará P=“Hola B, soy A y son ahora las 15.00”. Si en el momento inicial, C ha dado su clave EC(), suplantando la de EB(), entonces calculará EC(P)= 1100, pensando que está hablando con B. Este valor 1100 es un ejemplo. El mensaje 1100 lo parte A en 2 mitades, bits impares “1.0.” y bits pares “.1.0”. El protocolo requiere que primero se intercambian A y B la primera mitad, es decir A mandará =“1.0.” y B su primera mitad y luego A mandará “.1.0” y B su segunda mitad. El mensaje no puede ser desvelado en la primera mitad, por lo que tiene que esperar a la siguiente, pero C está obligado a mandar algo a B. ¿Qué puede mandar C? Si manda lo mismo, “1.0.” y “.1.0” B no lo podrá descifrar porque irá cifrado con EC(). Si mandase “algo” inventado con EB(), vería que el mensaje mandado por C no tenía sentido. Por tanto, C se habrá quedado fuera de juego. Nota: La forma de forzar dicha sincronización con las 15.00 puede ser con protocolos como NTP (Network Time Protocol).
| Página siguiente |