Implementación Automática de Servicios de Seguridad en Sistemas Distribuidos

Transcripción

1 Implementación Automática de Servicios de Seguridad en Sistemas Distribuidos N. Barcia Vázquez, C. Fernández del Val, L. Mengual Galán, J. Setien Villarán, J. Yagüez García Dpto. de Lenguajes y sistemas Informáticos e Ingeniería del Software Facultad de Informática (UPM) Boadilla del Monte, Madrid {nicolas, cfernandez, lmengual, jsetien, En este artículo proponemos un nuevo concepto de implementación de servicios de seguridad en sistemas distribuidos basado en la especificación formal de protocolos de seguridad. La idea consiste en desarrollar un código único y común a todas las aplicaciones que permita interpretar e implementar de forma automática especificaciones formales de protocolos de seguridad. El código desarrollado se ha concebido como un subnivel dentro de la arquitectura /IP capaz de ofrecer a las aplicaciones finales servicios dinámicos y flexibles de seguridad. 1. Introducción La creciente evolución de las redes de comunicaciones, así como su extensión y demanda a nivel mundial interconectando recursos informáticos de todo tipo hace necesario la implantación de medidas de seguridad (servicios de seguridad) para proteger la información en tránsito por dichas redes. Los servicios de seguridad utilizan los mecanismos implementados en una arquitectura de seguridad. Un mecanismo de seguridad implica un intercambio de unidades de datos entre entidades pares y la realización de una serie de funciones aplicadas a las unidades de datos (cifrado, cálculo de código de redundancia etc). Este intercambio entre entidades pares que tiene por objeto implementar un servicio de seguridad (un auténtico protocolo) lo denominaremos protocolo de seguridad. Diversos autores han aplicado las técnicas formales para la especificación y análisis de protocolos de seguridad. Así por ejemplo en [LAMP91] se describe la utilización de ESTELLE y LOTOS en la especificación de protocolos de autenticación y en [MIL87] se estudia la utilización de PROLOG en el análisis y evaluación de la vulnerabilidad de protocolos de distribución de claves frente a potenciales ataques. Otros ejemplos de modelos formales de seguridad los podemos encontrar en [SOH97] y [GEN97]. Finalmente, en [HWA95], [ABA97] se presentan distintos ejemplos del estudio formal de la vulnerabilidad de distintos protocolos. La aplicación de técnicas de descripción formal al campo de la seguridad debería contemplar la necesidad de especificar adecuadamente los intercambios que corresponden a los protocolos de seguridad, así como las funciones y mecanismos implicados con el objeto de ser interpretadas en fase de implementación. La implementación obtenida puede ser un producto final (con la incorporación explícita de funciones de seguridad: cifrado, sellos de tiempo, etc), o bien un prototipo que en fase de implementación simule la realización de funciones y/o mecanismos. La concepción de la implementación como un prototipo de comportamientos permite el desarrollo de un entorno de pruebas a nivel de implementación en el que probar y analizar la seguridad. Esta idea abre múltiples posibilidades en el marco de la evaluación de protocolos de seguridad. Tradicionalmente, la implementación de un protocolo de seguridad (como cualquier protocolo de comunicaciones) requería la implementación de un código específico en cada una de las entidades participantes. En este trabajo, se ha conseguido que las entidades pares en un entorno distribuido dispongan de la capacidad de interpretar una especificación de un - 1 -

2 protocolo de seguridad y que por tanto dispongan de un sólo código independiente del protocolo de seguridad específico. Los beneficios de esta nueva filosofía de implementación de protocolos de seguridad se reflejan en la figura 1: En un esquema de implementación tradicional, si aplicaciones distintas solicitasen distintos servicios de seguridad materializados con dos protocolos de seguridad diferentes (en el ejemplo, los servicios 1 y 2) necesitarían 6 códigos distintos (2 por cada entidad participante). En nuestro modelo, con un único código de interpretación de protocolos, las entidades son capaces de implementar cualquier protocolo de seguridad. Los beneficios de este esquema son indudables a la hora de ofrecer dinámicamente servicios de seguridad a las aplicaciones y usuarios A1 B1 C1 A2 B2 C2 A1 B1 C1 A2 B2 C2 Figura 1: Cambio de filosofía en la implementación de protocolos El Elemento Lógico de Implementación es la denominación de un nuevo subnivel que hemos desarrollado dentro de la arquitectura /IP y responsable de la implementación automática de un protocolo de seguridad especificado formalmente. El Elemento Lógico de Implementación es capaz de crear la infraestructura necesaria para posibilitar el establecimiento de comunicaciones seguras entre aplicaciones que soportan la arquitectura /IP. La infraestructura software desarrollada en el Elemento Lógico de Implementación permite implementar cualquier protocolo de seguridad mediante un mismo código de interpretación de protocolos localizado en cada entidad participante. Cada una de éstas entidades deberá saber cuál es su comportamiento en función de la especificación formal del protocolo. Las características de la especificación empleada, así como las funcionalidades desarrolladas por el Elemento Lógico de Implementación para conseguir una interpretación de las especificaciones formales en tiempo de ejecución, aparecen descritas en [MEN98]. 2. Propuesta de distribución e implementación automática de especificaciones formales de protocolos de seguridad en el estándar Hasta hace relativamente poco tiempo Internet y la mayoría de intranets con protocolos /IP, proporcionaban soporte para aplicaciones distribuidas relativamente simples, como el correo electrónico, transferencia de archivos y acceso remoto. Con el paso del tiempo, Internet se ha ido convirtiendo en la red soporte de múltiples aplicaciones multimedia impulsada por la popularidad del servicio Web. Al mismo tiempo las redes corporativas se han lanzado ha utilizar la Internet como red soporte de sus aplicaciones distribuidas; son las denominadas extranets. Estas organizaciones además han pasado de utilizar simples aplicaciones de correo electrónico y transferencia de archivos, a entornos cliente servidor más complejos. Todos estos avances están dejando obsoleta la capacidad de las redes basadas en IP para proporcionar los servicios y funciones requeridas. Hoy en día se demanda un entorno de redes conectadas entre sí que sea capaz de soportar tráfico en tiempo real, esquemas flexibles para controlar la congestión y funciones de seguridad. Ninguno de estos requisitos se satisface con el estándar actual IP, conocido como IPv4. Sin embargo, el mayor impulso para el desarrollo del nuevo estándar IP se debe al hecho de que el campo actual de direcciones de 32 bits se está quedando pequeño ante la creciente demanda de usuarios. Para hacer frente a las - 2 -

3 necesidades antes aludidas, el grupo Internet Engineering Task Force (IETF) realizó en julio de 1992 una petición de propuestas para un protocolo IP que se denominó en principio de nueva generación (IP-next generation, Ipng). Se recibieron diversas propuestas y en 1994 surgió el diseño final de este IPng. En enero de 1995 se publica el RFC 1752 [RFC95a] donde se recogen todas las propuestas y sugerencias respecto de este protocolo IP de nueva generación. A lo largo de 1995 se publica la especificación general del que se conoce oficialmente como protocolo IP versión-6 () a través del RFC 1883 [RFC95g] que recoge las consideraciones de seguridad descritas en las RFC 1825 [RFC95b], 1826 [RFC95c], 1827 [RFC95d] y los aspectos de direccionamiento de las RFC 1884 [RFC96a], 1885 [RFC96b], 1886 [RFC96c] y 1887 [RFC96d]. Un aspecto esencial en el desarrollo del estándar es la incorporación de funciones y mecanismos de seguridad en el propio formato del datagrama a través de cabeceras opcionales como son la Cabecera de Autenticación (CA) y la Cabecera de Encapsulado de Contenidos de Seguridad (CECS), proporcionando con ello servicios de autenticación, integridad y confidencialidad. Asimismo, un aspecto básico en la concepción de la seguridad en el estándar es la definición de Asociación de Seguridad o el conjunto de parámetros de seguridad relativos a una comunicación entre entidades pares (claves utilizadas, algoritmos de cifrado, etc). El estándar no especifica, sin embargo, ningún procedimiento para la obtención de claves (parámetro esencial de una Asociación de Seguridad), si bien propone distintas alternativas que van desde la distribución manual a la implementación de protocolos específicos de autenticación. En este apartado, se propone incorporar el modelo de distribución e interpretación automática de especificaciones formales, desarrollado en este trabajo, como una alternativa válida para la distribución de claves en el estándar. Así pues, la problemática de distribución de claves de sesión en el estándar, para aplicaciones distribuidas que requieran servicios de seguridad, se podría resolver de una manera eficiente y flexible. Para ello, bastaría incorporar las funcionalidades desarrolladas en el Elemento Lógico de Implementación en la nueva arquitectura /IP. Nuestro modelo supone una idea novedosa en la distribución automatizada de claves: primero se distribuye la especificación del protocolo de seguridad a las entidades interesadas (diseño a medida de una organización) y, a continuación, se ejecuta el protocolo en cuestión. Autoridad de autenticación C.E.C.S. Esp. Formal S.S. Datagrama C.A. Sol. S.S. Datagrama C.E.C.S. Datagrama Esp. Formal S.S. Protocolo de Seguridad E.L.I.= Elemento Lógico de Implementación C.E.C.S.= Cabecera de Encapsulado de Contenidos de Seguridad en C.A.= Cabecera de Autenticación en Usuario A Usuario B Figura 2: Distribución e interpretación automática de protocolos de seguridad y su incorporación en el estándar - 3 -

4 Una entidad par puede solicitar en cualquier momento un nuevo protocolo de seguridad con el fin de establecer comunicaciones seguras con otras entidades (ver figura 2). Para ello, haría una petición a una Entidad Autorizada transfiriendo un datagrama, conteniendo la solicitud y el servicio de seguridad requerido, con funciones adicionales de autenticación incorporadas en la Cabecera de Autenticación (CA). A continuación, la Entidad Autorizada distribuiría la especificación del nuevo protocolo a las entidades participantes incorporando la especificación dentro de los contenidos cifrados de la CECS utilizando para cifrar la última clave de sesión asignada. Una vez que las entidades pares están en posesión de la especificación formal se desarrollarán los intercambios correspondientes al protocolo de seguridad que tendrá por finalidad, en la mayoría de los casos, la distribución de una clave de sesión. Finalmente, las entidades participantes en posesión de una nueva clave de sesión podrán establecer un canal seguro para la transmisión de datos. 3. CONCLUSIONES En este trabajo hemos concebido un sistema que permite automatizar el proceso de implementación de protocolos de seguridad a partir de una especificación formal y, con ello, la versatilidad en la incorporación de distintos servicios de seguridad en entornos distribuidos. Para ello hemos desarrollado un nuevo subnivel dentro de la arquitectura /IP con la denominación de Elemento Lógico de Implementación (ELI). El sistema se ha desarrollado con un doble objetivo: Por un lado, obtener un entorno de pruebas para el análisis y evaluación de ataques reales a un protocolo de seguridad. Por otro lado, derivar un producto final con la incorporación explícita de funciones de seguridad. Finalmente, proponemos incorporar el nuevo subnivel obtenido en el estándar y, con ello, contribuir a la resolución de la problemática de distribución de claves en aplicaciones distribuidas que requieran servicios de seguridad. 4. REFERENCIAS [ABA97] Abadi M. Explicit Communication Revisited: Two New Attacks on Authentication Protocols. IEEE Transactions on Software Engineering, Vol. 23, Nº 3, March [GEN97] Gennaro R., Karger P., Matyas S., Peyravian M., Roginsky A., Safford D., Willett M., Zunit N. Two-Phase Cryptographic Key Recovery System. Computers & Security, Vol. 16, Nº 6, [HWA95] Hwang, T., Ku, W. Reparable Key Distribution Protocols for Internet Enviroments. IEEE transactions on Communications, Vol. 43, Nº 5, May [LAMP91] Lampard, R. Formal Description Techniques in Data Security: An Evaluation and Comparison. National Physical Lab., Teddington, England Div. of Information Technology and Computing, 1991, 59pp, PB /WCC. [MEN98] Mengual Galán, L. Un modelo formal para la especificación, analisis, verificación e implementación de protocolos de seguridad. Tesis Doctoral. Facultad de Informática. Universidad Politécnica de Madrid. Julio 1998 [MIL87] Millen, J.K., Clark S.C., Freedman, S.B. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, Vol. SE-13, Nº 2, February [RAM90] Ramaswamy, R. A Security Architecture and Mechanism for Data Confidentiality in /IP Protocols. Proceedings, 1990 IEEE Computer Society Symposium on Research in Security and Privacy, May [RFC95a] Bradner, S., Mankin, A. The Recommendation for the IP Next Generation Protocol.", RFC 1752, January [RFC95b] Atkinson, R. Security Architecture for the Internet Protocol.", RFC 1825, August [RFC95c] Atkinson, R. IP Authentication Header.", RFC 1826, August [RFC95d] Atkinson, R. IP Encapsulating Security Payload (ESP).", RFC 1827, August [RFC95e] Metzger, W. Simpson IP Authentication using Keyed MD5.", RFC 1828, September [RFC95g] Deering, S., Hinden, R. Internet Protocol, Version 6 () Specification", RFC 1883, December [RFC96a] Hinden, R. and Deering, S. IP Version 6 Addressing Architecture", RFC 1884, April

5 [RFC96b] Conta, A. and Deering, S. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 ()", RFC 1885, April [RFC96c] Thomson, S., Huitema, C. DNS Extensions to support IP version 6", RFC 1886, April [RFC96d] Rekhter, Y. and Li, T. An Architecture for Unicast Address Allocation ", RFC 1887, April [SOH97] Soh, B.C,, and Dillon, T.S. System Intrusion Process: a simulated model. Computers & Security, Vol. 16, Nº 1,