Protocolos de distribución de llaves

1. Protocolos de distribución de llaves y canales seguros en sistemas distribuidos

2. Modelo cliente servidor Imagina un sistema distribuido donde los servidores tambien pueden ser clientes de otros servidores del sistema

3. 2 problemas de seguridad 1) Entablar canales seguros de comunicación. • Comunicación segura necesita autenticación, integridad del mensaje y confidencialidad. 2) Autorización. • Los recursos que el cliente en cuestión tiene derecho a accesar. Un canal seguro protege al emisor y receptor contra intercepción, modificación, y fabricaciones de mensajes. Intercepción -> Confidencialidad (El canal se asegura que los mensajes no sean espidados) Modificación y Fabricación -> Mediante protocolos de autentificación mutua e integridad de mensajes.

4. Autenticación • Autenticación e Integridad van de la mano • Sin autenticación: Si Alice recibe la noticia de que ha ganado $100000 dls como puede estar segura de que es un mensaje auténtico de los • organizadores de la lotería. • Sin integridad de mensajes: Si Alice le manda un mensaje a Bob, Bob no tiene la certeza de que el mensaje auténtico de Alice no fue modificado en algún momento

5. Autentificación basada en llaves de sesión simétricas • Laves de sesión: Llaves que al terminar la comunicación son descartadas • Ejemplo sencillo. • Supongamos que Alice y Bob ya tienen intercambiada una llave simétrica Ka,b. La autentificación se lleva a cabo mediante un protocolo de desafío y respuesta.

6. Ataque de reflección • Es importante no optimizar el envio de mensajes para hacer imposible un ataque de reflección. ¿Que es esto? Protocolo de autentificación optimizado Ataque de reflección a un protocolo de autentificación optimizado

7. Protocolos de distribución de llaves de sesión mediante llaves simétricas • Previo al invento de la llave asimétrica, para entablar una sesión era necesario usar protocolos muy robustos y centralizados para distribuir las llaves de sesión. • ¿Como enviar una llave por un medio seguro si aún no existe un medio seguro? • Una manera es usar un medio alterno, (¿reunión cara-a-cara quiza?) el problema es la escalabilidad. • En un sistema de N servidores se necesitaría distribuir N-1 llaves a cada servidor para autentificarse con los otros N-1 servidores. El sistema completo tendría N(N-1)/2 llaves.

8. Centro Distribuidor de Llaves (KDC) • La solución al problema N(N-1)/2 es usar un KDC • El total de llaves en todo el sistema serían sólo N, aquella que autentifica al Servidor con el servicio del KDC. 1) Alice le dice al KDC que quiere una comunicación A,B 2) KDC envia una llave de sesión para la comunicación entre ambos con dos encriptaciones simétricas. Una entre el KDC y Alice y otra entre KDC y Bob

9. Problema de sincronización • Este modelo del KDC tiene sus problemas, y uno es que Alice puede querer entablar comunicación con Bob antes de que este reciba la llave de sesión del KDC.

10. Solución: Ticket Una solución es enviar un Ticket a Alice y dejar que ella se encargue de enviarle la llave a Bob. Un ticket significa pasarle a Alice el mensaje cifrado Kb,kdc(Ka,b). Este es un mensaje que sólo Bob y el KDC pueden decifrar, por tanto este “Ticket” tiene que ser enviado por Alice a Bob. 1) Alice le dice al KDC que quiere comunicarse con Bob 2) El KDC le envia la llave de sesión cifrada en Ka,kdc y además envia el ticket que Alice debe enviar a Bob. 3) Alice le dice a Bob que quiere comunicarse con él y le envia el ticket.

11. Ra1, Ra2 y Rb son llamados nonce. Estos son numeros random que solo deben ser usados una sola vez. Veamos como puede ser quebrado el protocolo si el nonce no fuera usado: Protocolo Needham-Schroeder El protocolo de autentificación de Needham-Schroeder esta basado en la distribución de tickets:

12. Quebrando Needham-Schroeder • Chuck se da el tiempo para quebrar una llave Kb,kdc, y puede tardar el tiempo que quiera, aún cuando esta llave ya este expirada al haberse negociado una Kb,kdc nueva para Bob. • Chuck tiene la antigua llave oldKb,kdc de Bob. Además ha interceptado un antiguo mensaje 2 donde el KDC le daba a Alice la llave de sesión de una antigua comunición con Bob. Chuck esperará pacientemente hasta que Alice quiera entablar un nuevo canal seguro con Bob. • Cuando Alice contacte al KDC, Chuck le responderá el viejo mensaje 2 haciendola creer que proviene del KDC. El mensaje respuesta 3 de Alice podrá ser interpretado por Chuck pues el conoce oldKb,kdc. Chuck respondera acorde y engañará a Alice haciendola creer que esta hablando con Bob. • Con el uso de un nonce, Alice se asegura que la respuesta del KDC este ligada a la petición del mensaje 1.

13. Quebrando Needham-Schroeder aún con el uso del nonce • Con el uso de un nonce, Alice se asegura que la respuesta del KDC este ligada a la petición del mensaje 1. • Pero aún con este protocolo y con el uso de el nonce, si Chuck llega a decifrar una antigua llave de sesión oldKa,b podría replicar un viejo mensaje 3 y entablar una comunicación con Bob haciendolo creer que es Alice.

14. Needham-Schroeder modificado Un nonce por parte de Bob tiene que ser usado en la comunicación de Alice al KDC. De esta manera cuando Bob recibe el mensaje 5 (Equivalente al 3 en el protocolo anterior) solamente lo considerará auténtico si el Rb1 coincide con el que envió en el mensaje 2. De esta manera no importa si Chuck se dio el tiempo para quebrar una oldKa,b o oldKa,kdc o oldKb,kdc. El uso de nonces de esta manera impide el uso de viejas llaves.

15. Intercambio de llaves de sesión mediante llaves asimétricas Afortunadamente la pesadilla ha terminado, ahora es mucho más facil compartir llaves simetrícas de sesión a travez de llaves asimétricas. La razón del por que crear un canal con un tipo de llave(simétrica) diferente a la llave(asimétrica) con la que se distribuye la primera es porque cuando una llave se usa muchas veces es más fácil quebrarla,es por esto que una vez terminada la sesión la llave se tira y para abrir otra comunicación se pide otra llave. Más seguro.

16. Problema del huevo y la gallina Aún así, Si Alice y Bob son servidores totalmente nuevos y Alice le pide a Bob su llave pública, se corre el riesgo de que Chuck intercepte el mensaje y le envie su llave pública en lugar de la de Bob, haciendo creer a Alice que se trata de la llave de Bob.

17. Solución: Centralizar con un PGP Una vez más, para distribuir llaves públicas se utilizan sistemas centralizados que sean servidores de las mismas llamados PGP ("Pretty Goog Privacy"). Servidores publicos de esta tecnología utilizan una conección segura https para asegurar la integridad del mensaje entre el PGP y Alice o Bob. Solamente una trusted certificate authority puede asegurar que el PGP es auténtico, o arrojariamos un error equivalente a este:

18. Un PGP privado es mejor opción • Para esto sólo es necesario tener una lista de las autoridades certificadoras de confianza. (Si la necesitas la puedes encontrar en los browsers pues las tienen por default). • Pero siempre lo más seguro es que el PGP sea interno. La manera en la que un servidor de llaves públicas PGP se asegura que la llave pública que tiene de Bob es aútentica de Bob depende ya de ese sistema Un ejemplo simple es que hay servidores PGP que utilizan un correo electrónico de confirmación.

19. Bibliografía • Andrew T. Tanenbaum and Maarten Van Steen. Distributed Systems, principles and paradigms. 2006, Pearson Prentice Hall. New Jersey. Second Edition. • Wikipedia