UNIVERSIDAD CARLOS III DE MADRID

TESIS DOCTORAL
METODOLOGA PARA LA VALIDACIN Y EVALUACIN REMOTA DE IMPLEMENTACIONES DE PROTOCOLOS DE SEGURIDAD. APLICACIN A LA ARQUITECTURA IPSEC

Autor:

Antonio Izquierdo Manzanares

Director:

Jose Mara Sierra Cmara

DEPARTAMENTO DE INFORMTICA

Legans, Octubre de 2.006

Resumen

Las redes de comunicaciones han pasado a ser parte fundamental de las tecnolog de la informacin, siendo el medio a travs del cual los sisteas o e mas informticos de todo tipo (desde ordenadores personales hasta cajeros a automticos y ordenadores de a bordo en los coches) intercambian la infora macin que necesitan para llevar a cabo las tareas para las que han sido o diseados. Estos intercambios de informacin estn regidos por protocolos n o a de comunicaciones que gobiernan la forma en la que diferentes entidades proceden a enviarse la informacin de la forma ms eciente y conveniente o a posible. En muchas ocasiones estos intercambios de informacin requieren o de servicios de seguridad (como son la condencialidad, la autenticacin o o el no repudio) de los que carecen los protocolos diseados al comienzo de la n expansin de las redes de comunicaciones (protocolos que son los ms exteno a didos y utilizados en la actualidad). Para cubrir este vac de seguridad se o han diseado y estandarizado protocolos y arquitecturas de seguridad que n proporcionan los servicios de seguridad requeridos al resto de protocolos de comunicaciones. La arquitectura de seguridad IPsec est ampliamente exa tendida debido a su transparencia de cara a aplicaciones y usuarios, y a que su integracin en los protocolos de red de siguiente generacin garantiza que o o la migracin se podr llevar a cabo de la forma menos traumtica posible. o a a Sin embargo, el uso de estos protocolos y arquitecturas de seguridad ha ocasionado la aparicin de nuevos problemas, entre los que se pueden destacar o los problemas de interoperabilidad entre las diferentes implementaciones de los protocolos y arquitecturas, o una mayor predisposicin a sufrir ataques o de denegacin de servicio. Con el objetivo de ofrecer informacin acerca de o o la implementacin que ayude a evitar este tipo de problemas, en esta tesis o se propone una metodolog que permita evaluar el nivel de conformidad a de una implementacin de un protocolo o arquitectura de seguridad con o el estndar y el rendimiento que dicha implementacin puede ofrecer. La a o metodolog propuesta se desarrolla para aplicarse a la arquitectura de sea guridad IPsec con el n de demostrar la aplicacin prctica de la propuesta, o a y se presentan los resultados obtenidos mediante la evaluacin de diferentes o implementaciones de IPsec.

Abstract

Communication networks have become a key component of information technologies, being the means through which computer systems all around the world, independently of their nature (from personal computers to ATMs, and on-board computers in high-end cars) share the information they need in order to accomplish the tasks they are charged with. These information exchanges are carried out following the guidelines of communications protocols, which guide and direct the way in which several entities exchange information in the most ecient and convenient way. As it happens more often than not, these information exchanges require some security services to be present (such as condentiality, authentication or non-repudiation) which are not included in protocols designed in the early years of communication networks (those same protocols that are now widely spread and used nowadays). In order to provide with a solution for this need for security, security protocols and architectures which provide security services to other network protocols have been standardized. The IPsec security architecture is widely spread thanks to its seamless integration with applications and users, and also due to its integration with next-generation communication protocols provides a means for migrating to those new protocols in a safe and more convenient way. However, with the use of these security protocols and architectures new problems have emerged, some of which are the interoperability issues among dierent implementations of those protocols and architectures, or an increased chance to suer denial of service attacks. In order to gather information about those implementations that helps to prevent these kind of problems, in this thesis a new methodology that allows the evaluation of the conformance with the standard, as well as the performance of such implementation is proposed. The methodology is applied to the IPsec security architecture in order to demonstrate the practical application of our proposal, and the results obtained when evaluating several IPsec implementations are presented.

 Indice general
. . Indice de guras Indice de tablas
VIII XI

1. Introduccin o 1.1. Origen de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Interoperatividad . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Rendimiento de los protocolos de seguridad . . . . . . . . . . 1.4. Objetivos de la tesis . . . . . . . . . . . . . . . . . . . . . . . 1.4.1. Identicacin de parmetros de conformidad con el o a estndar . . . . . . . . . . . . . . . . . . . . . . . . . . a 1.4.2. Identicacin de parmetros de rendimiento . . . . . . o a 1.4.3. Establecimiento de un marco de anlisis y desarrollo a para protocolos y arquitecturas de seguridad . . . . . 1.4.4. Metodolog de validacin y evaluacin de implemena o o taciones de protocolos y arquitecturas de seguridad . . 1.4.5. Aplicacin de la metodolog a la arquitectura de seo a guridad IPsec . . . . . . . . . . . . . . . . . . . . . . . 1.4.6. Desarrollo de una plataforma de evaluacin remota de o implementaciones de IPsec . . . . . . . . . . . . . . . 1.5. Organizacin de la tesis . . . . . . . . . . . . . . . . . . . . . o 2. Estado de la Cuestin o 2.1. Estandarizacin de la seguridad . . . . . . . . . . . . . . . . . o 2.1.1. Protocolos y arquitecturas de seguridad . . . . . . . . 2.1.2. Mecanismos criptogrcas . . . . . . . . . . . . . . . . a 2.1.3. Otras estandarizaciones . . . . . . . . . . . . . . . . . 2.2. Validacin y Seguridad . . . . . . . . . . . . . . . . . . . . . . o 2.2.1. Validacin de la seguridad en el desarrollo . . . . . . . o i

1 1 5 6 9 11 11 12 12 13 13 14 15 15 16 27 28 29 30

 INDICE GENERAL 2.2.2. Gu de conguracin de la seguridad . . . . . . . . . as o 2.2.3. Conjuntos de pruebas de seguridad . . . . . . . . . . . 2.2.4. Validacin de protocolos de seguridad . . . . . . . . . o 2.2.5. Metodolog de evaluacin de la seguridad de sisteas o mas de informacin . . . . . . . . . . . . . . . . . . . . o 2.3. Evaluacin del rendimiento . . . . . . . . . . . . . . . . . . . o 2.3.1. Evaluacin del rendimiento de los protocolos de seguo ridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Anlisis de la Conformidad con el Estndar a a 3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 3.2. Identicacin de aspectos de conformidad . . . . . . . . . . . o

II

33 35 39 42 44 47 49 51 51 51

3.2.1. Correcta implementacin de los mecanismos criptogro a cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2.2. Conformidad de protocolos y subprotocolos . . . . . . 3.2.3. Mecanismos de autenticacin . . . . . . . . . . . . . . o 3.2.4. Opciones de gestin de las claves criptogrcas . . . . o a 3.2.5. Otras caracter sticas . . . . . . . . . . . . . . . . . . . 3.3. Mtodos de validacin de los factores de conformidad . . . . . e o 3.3.1. Correcta implementacin criptogrca . . . . . . . . . o a 3.3.2. Conformidad de protocolos y subprotocolos . . . . . . 3.3.3. Autenticacin . . . . . . . . . . . . . . . . . . . . . . . o 3.3.4. Gestin de Claves . . . . . . . . . . . . . . . . . . . . o 3.3.5. Otras caracter sticas . . . . . . . . . . . . . . . . . . . 3.4. Consideraciones de implementacin . . . . . . . . . . . . . . . o 4. Anlisis del Rendimiento a 4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.2. Identicacin de los factores de rendimiento . . . . . . . . . . o 4.2.1. Anlisis de SSL . . . . . . . . . . . . . . . . . . . . . . a 4.2.2. Resultados del anlisis . . . . . . . . . . . . . . . . . . a 4.2.3. Ancho de banda . . . . . . . . . . . . . . . . . . . . . 4.2.4. Mximo nmero de tneles criptogrcos establecidos a u u a 4.2.5. Capacidad de establecimiento de nuevos tneles cripu togrcos . . . . . . . . . . . . . . . . . . . . . . . . . a 4.2.6. Tiempo de proceso . . . . . . . . . . . . . . . . . . . . 55 56 56 57 57 58 60 63 64 65 65 69 69 69 70 79 80 81 82 83

III

INDICE GENERAL 4.3. Medicin de los factores de rendimiento . . . . . . . . . . . . o 4.3.1. Ancho de banda . . . . . . . . . . . . . . . . . . . . . 4.3.2. Mximo nmero de canales seguros simultneas . . . . a u a 4.3.3. Capacidad de establecimiento de canales seguros . . . 4.3.4. Tiempo de proceso . . . . . . . . . . . . . . . . . . . . 4.4. Aspectos a tener en cuenta . . . . . . . . . . . . . . . . . . . 83 83 84 86 86 87 93 93 94 95 96 96 97 97 97 98 98 98 99 99

5. Metodolog de Validacin y Evaluacin a o o 5.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 5.2. Deniciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Conformidad y Rendimiento . . . . . . . . . . . . . . . . . . . 5.4. Fase 1: Tareas Preliminares . . . . . . . . . . . . . . . . . . . 5.4.1. Determinar el tipo de anlisis . . . . . . . . . . . . . . a 5.4.2. Identicacin de los recursos necesarios . . . . . . . . o 5.5. Fase 2: Documentacin Preliminar . . . . . . . . . . . . . . . o 5.6. Fase 3: Anlisis del Estndar . . . . . . . . . . . . . . . . . . a a 5.7. Fase 4: Validacin de la Conformidad . . . . . . . . . . . . . . o 5.7.1. Identicacin de los mecanismos criptogrcas . . . . o a 5.7.2. Identicacin de los caracter o sticas obligatorias . . . . 5.7.3. Identicacin de los caracter o sticas opcionales que deben ser evaluadas . . . . . . . . . . . . . . . . . . . . . 5.7.4. Diseo de pruebas . . . . . . . . . . . . . . . . . . . . n

5.8. Fase 5: Evaluacin del Rendimiento . . . . . . . . . . . . . . . 100 o 5.8.1. Rendimiento de los mecanismos criptogrcas . . . . . 100 a 5.8.2. Identicacin de parmetros dependientes del trco . 100 o a a 5.8.3. Identicacin de parmetros independientes del trco 100 o a a 5.8.4. Diseo de pruebas . . . . . . . . . . . . . . . . . . . . 101 n 5.9. Fase 6: Denicin de Perles de Trco . . . . . . . . . . . . 101 o a 5.10. Fase 7: Otras Consideraciones . . . . . . . . . . . . . . . . . . 102 5.11. Fase 8: Tareas Finales . . . . . . . . . . . . . . . . . . . . . . 102 6. Aplicacin de la Metodolog a IPsec o a 103

6.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 o 6.2. Conformidad con el estndar . . . . . . . . . . . . . . . . . . 104 a 6.2.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.2.2. Conguracin de las pruebas . . . . . . . . . . . . . . 105 o 6.2.3. Pruebas de conformidad criptogrca . . . . . . . . . 107 a

 INDICE GENERAL

IV

6.2.4. Validacin de protocolos y subprotocolos . . . . . . . . 111 o 6.2.5. Validacin de los mecanismos de autenticacin . . . . 115 o o 6.2.6. Validacin de la gestin de claves . . . . . . . . . . . . 117 o o 6.2.7. Validacin de otras caracter o sticas . . . . . . . . . . . 119 6.3. Evaluacin del rendimiento . . . . . . . . . . . . . . . . . . . 122 o 6.3.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 122 6.3.2. Conguracin de las pruebas . . . . . . . . . . . . . . 123 o 6.3.3. Perles de trco . . . . . . . . . . . . . . . . . . . . . 125 a 6.3.4. Ancho de banda . . . . . . . . . . . . . . . . . . . . . 129 6.3.5. Mximo nmero de AS simultneas a u a . . . . . . . . . . 131 6.3.6. Capacidad de establecimiento de asociaciones de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . 133 6.3.7. Tiempo de proceso . . . . . . . . . . . . . . . . . . . . 137 7. Dise o e Implementacin n o 141

7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 o 7.2. Pruebas atmicas . . . . . . . . . . . . . . . . . . . . . . . . . 141 o 7.2.1. Relacin de pruebas atmicas desarrolladas . . . . . . 144 o o 7.2.2. Ejemplos de ejecucin de pruebas atmicas . . . . . . 162 o o 7.3. Diseo de la plataforma . . . . . . . . . . . . . . . . . . . . . 173 n 7.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 8. Evaluacin de la Tesis o 8.1. Evaluacin de la tesis o 183 . . . . . . . . . . . . . . . . . . . . . . 183

8.1.1. Identicacin de los parmetros de conformidad con o a el estndar . . . . . . . . . . . . . . . . . . . . . . . . 183 a 8.1.2. Identicacin de los parmetros de rendimiento . . . . 185 o a 8.1.3. Establecimiento de un marco de anlisis y desarrollo a para protocolos y arquitecturas de seguridad . . . . . 187 8.1.4. Metodolog de validacin y evaluacin de implemena o o taciones de protocolos de seguridad . . . . . . . . . . . 188 8.1.5. Aplicacin de la metodolog a la arquitectura de seo a guridad IPsec . . . . . . . . . . . . . . . . . . . . . . . 189 8.1.6. Desarrollo de una plataforma de validacin y evaluao cin remota de implementaciones de IPsec . . . . . . . 190 o 8.2. Evaluacin de Implementaciones de IPsec . . . . . . . . . . . 191 o 8.2.1. Validacin de la conformidad . . . . . . . . . . . . . . 192 o 8.2.2. Evaluacin del rendimiento . . . . . . . . . . . . . . . 194 o

INDICE GENERAL 199 199 199 201 202 203 203 204 206

9. Conclusiones 9.1. Aportaciones de la tesis . . . . . . . . . . . . . . . . . . . . . 9.1.1. Anlisis de conformidad . . . . . . . . . . . . . . . . . a 9.1.2. Anlisis de rendimiento . . . . . . . . . . . . . . . . . a 9.1.3. Marco de anlisis y desarrollo para protocolos y ara quitecturas de seguridad . . . . . . . . . . . . . . . . . 9.1.4. Metodolog de validacin y evaluacin remota de ima o o plementaciones de protocolos de seguridad . . . . . . . 9.1.5. Aplicacin de la metodolog a la arquitectura IPsec . o a 9.1.6. Plataforma de validacin y evaluacin remota de imo o plementaciones de IPsec . . . . . . . . . . . . . . . . . 9.2. Futuras L neas de Investigacin . . . . . . . . . . . . . . . . . o

9.2.1. Aplicacin a otros protocolos y arquitecturas de seguo ridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.2.2. Integracin de la plataforma con otras herramientas . 207 o 9.2.3. Interpretacin de los informes . . . . . . . . . . . . . . 207 o 9.2.4. Estandarizacin de la metodolog . . . . . . . . . . . 209 o a Bibliograf a 211

 INDICE GENERAL

VI

 Indice de guras
2.1. Pila de protocolos TCP/IP tradicional (izquierda) y pila TCP/IP tras aadir la capa de TLS . . . . . . . . . . . . . . . . . . . 18 n 2.2. Pila de protocolos TLS. La capa de aplicacin y los subproo tocolos de negociacin, alerta y cambio de cifrado generan o paquetes que son protegidos y enviados por el protocolo de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Pila de protocolos IPsec en modo transporte y en modo tnel u 2.4. Papel que juega cada protocolo de IPsec en el establecimiento y proteccin de tneles seguros . . . . . . . . . . . . . . . . . o u

18 23 24

2.5. Posibles modos de funcionamiento de IPsec, desde el punto de vista de su operacin como pasarela o como dispositivo nal 26 o 2.6. Modelo de utilizacin de herramientas automatizadas. Su inso talacin en un equipo permite analizar otros equipos de la o misma red (anlisis interno), o incluso de otras redes (anlisis a a externo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. Tiempo empleado por el cliente en la trasmisin y recepcin o o de una determinada cantidad de datos utilizando diferentes canales de comunicacin . . . . . . . . . . . . . . . . . . . . . o 4.2. Tiempo empleado por el servidor en la transmisin y recepo cin de una determinada cantidad de datos utilizando difeo rentes canales de comunicacin . . . . . . . . . . . . . . . . . o 4.3. Cantidad de operaciones de cifrado por segundo que llevan a cabo los equipos evaluados . . . . . . . . . . . . . . . . . . . . 4.4. Cantidad de operaciones de rma y vericacin que llevan a o cabo los equipos evaluados . . . . . . . . . . . . . . . . . . . . 4.5. Esquema de medicin del ancho de banda. . . . . . . . . . . . o 4.6. Arquitectura de red necesaria para generar trco y hacer que a aparezcan en la red las condiciones deseadas . . . . . . . . . . vii

38

72

73 77 78 85 91

 INDICE DE FIGURAS

VIII

4.7. Arquitectura de red en la que un dispositivo de red adicional genera las condiciones deseadas . . . . . . . . . . . . . . . . .

91

6.1. Esquema de red utilizado para la validacin de una impleo mentacin de IPsec actuando como pasarela . . . . . . . . . . 106 o 6.2. Esquema de red utilizado para la validacin de una impleo mentacin de IPsec actuando como equipo nal . . . . . . . . 106 o 6.3. Posible esquema de red utilizado para la evaluacin del reno dimiento de una implementacin IPsec. . . . . . . . . . . . . 124 o 7.1. Diagrama de estados de la prueba atmica de validacin de o o la autenticacin utilizando secreto compartido en Main Mode o de IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7.2. Diagrama de estados del mdulo servidor de la prueba de o evaluacin del nmero mximo de SA que puede establecer o u a una implementacin de IPsec . . . . . . . . . . . . . . . . . . 166 o 7.3. Diagrama de estados del mdulo cliente de la prueba de evao luacin del nmero mximo de SA que puede establecer una o u a implementacin de IPsec . . . . . . . . . . . . . . . . . . . . . 167 o 7.4. Esquema de la plataforma que implementar el conjunto de a pruebas propuesto. . . . . . . . . . . . . . . . . . . . . . . . . 177 7.5. Esquema de utilizacin de la plataforma en el que un usuario o selecciona las pruebas a llevar a cabo en la implementacin de o IPsec existente en el mismo equipo que utiliza para conectarse al interfaz web de la plataforma . . . . . . . . . . . . . . . . . 179 7.6. Esquema de utilizacin de la plataforma en el que un usuario o selecciona las pruebas a llevar a cabo en la implementacin o de IPsec existente en otro dispositivo . . . . . . . . . . . . . . 180 9.1. Posible diseo de la metodolog al integrar el anlisis de vuln a a nerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

 Indice de tablas
1.1. Recursos del sistema que ejecuta el mecanismo de seguridad Port-Knocking, con un intervalo de tiempo entre cada muestra de datos de 5 segundos. Las las en negrita representan los momentos en los que el ataque tuvo lugar. Las ultimas dos las de la tabla muestran cmo an despus de nalizar el o u e ataque, el sistema an se encontraba procesando los intentos u de conexin recibidos . . . . . . . . . . . . . . . . . . . . . . . o 3.1. Combinaciones de herramientas criptogrcas vlidas durana a te el proceso de negociacin de TLS 1.1 . . . . . . . . . . . . o 4.1. Especicaciones de los sistemas empleados en la prueba de concepto de SSL . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Solicitudes de memoria (en KBytes) durante la ejecucin de o la prueba de concepto . . . . . . . . . . . . . . . . . . . . . . 4.3. Tamao de Memoria Residente y Virtual (en KBytes) de las n pruebas de concepto . . . . . . . . . . . . . . . . . . . . . . . 4.4. Equipos utilizados en la evaluacin del rendimiento . . . . . . o 4.5. Comparacin del rendimiento de varios equipos al cifrar y o calcular resmenes criptogrcos, en miles de operaciones por u a segundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Comparacin del rendimiento de varios equipos al cifrar dao tos, en miles de operaciones por segundo . . . . . . . . . . . .

55

71 74 75 76

76 78

7.1. Especicaciones de la implementacin mediante pruebas atmio o cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 7.2. Relacin de pruebas atmicas de validacin de las herramieno o o tas criptogrcas utilizadas en ESP . . . . . . . . . . . . . . . 145 a 7.3. Relacin de pruebas atmicas de validacin de las herramieno o o tas criptogrcas utilizadas en la Fase 1 de IKE . . . . . . . . 146 a ix

 INDICE DE TABLAS

7.4. Relacin de pruebas atmicas de validacin de las herramieno o o tas criptogrcas utilizadas en la Fase 2 de IKE . . . . . . . . 147 a 7.5. Relacin de pruebas atmicas de validacin del desarrollo de o o o los protocolos en modo tnel . . . . . . . . . . . . . . . . . . 149 u 7.6. Relacin de pruebas atmicas de validacin del desarrollo de o o o los protocolos en modo transporte . . . . . . . . . . . . . . . 150 7.7. Relacin de pruebas atmicas de validacin de los mecanismos o o o de autenticacin . . . . . . . . . . . . . . . . . . . . . . . . . 151 o 7.8. Relacin de pruebas atmicas de validacin de la gestin de o o o o claves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 7.9. Relacin de pruebas atmicas de validacin de otras caraco o o ter sticas adicionales . . . . . . . . . . . . . . . . . . . . . . . 153 7.10. Relacin de pruebas atmicas de evaluacin del ancho de banda.154 o o o 7.11. Relacin de pruebas atmicas de evaluacin del nmero mxio o o u a mo de asociaciones de seguridad . . . . . . . . . . . . . . . . 157 7.12. Relacin de pruebas atmicas de evaluacin de la capacidad o o o de establecimiento de nuevas asociaciones de seguridad . . . . 158 7.13. Relacin de pruebas atmicas de evaluacin del tiempo de o o o proceso de la Fase 1 de IKE . . . . . . . . . . . . . . . . . . . 159 7.14. Relacin de pruebas atmicas de evaluacin del tiempo de o o o proceso de la Fase 2 de IKE . . . . . . . . . . . . . . . . . . . 160 7.15. Relacin de pruebas atmicas de evaluacin del tiempo de o o o establecimiento de un tnel criptogrco completo . . . . . . 161 u a 7.16. Validacin de la autenticacin mediante secreto compartido . 164 o o 7.17. Ejecucin del mdulo servidor de la evaluacin de cantidad o o o de asociaciones de seguridad simultneas que soporta la ima plementacin de IPsec . . . . . . . . . . . . . . . . . . . . . . 169 o 7.18. Ejecucin del mdulo cliente de la evaluacin de cantidad de o o o asociaciones de seguridad simultneas que soporta la implea mentacin de IPsec . . . . . . . . . . . . . . . . . . . . . . . . 171 o 8.1. Especicaciones de la implementacin IPsec evaluada . . . . . 192 o 8.2. Resultados de validacin de las herramientas criptogrcas o a utilizadas en ESP . . . . . . . . . . . . . . . . . . . . . . . . . 192 8.3. Resultados de validacin de las herramientas criptogrcas o a utilizadas en la Fase 1 de IKE . . . . . . . . . . . . . . . . . . 193 8.4. Resultados de validacin de las herramientas criptogrcas o a utilizadas en la Fase 2 de IKE . . . . . . . . . . . . . . . . . . 193 8.5. Resultados de validacin del desarrollo de los protocolos en o modo tnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 u

XI

INDICE DE TABLAS 8.6. Resultados de validacin del desarrollo de los protocolos en o modo transporte . . . . . . . . . . . . . . . . . . . . . . . . . 194 8.7. Resultados de validacin de los mecanismos de autenticacin 195 o o 8.8. Resultados de validacin de la gestin de claves . . . . . . . . 195 o o 8.9. Resultados de validacin de otras caracter o sticas adicionales . 8.10. Resultados de evaluacin del ancho de banda. . . . . . . . . . o 8.11. Resultados de evaluacin del nmero mximo de asociaciones o u a de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.12. Resultados de establecimiento de asociaciones de seguridad (Extracto) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 196 197 197

 INDICE DE TABLAS

XII

Cap tulo 1

Introduccin o
1.1. Origen de la tesis

En los ultimos aos hemos visto cmo las redes de comunicaciones han n o pasado a ser parte de nuestra vida cotidiana. A medida que el tiempo ha pasado, las redes de ordenadores han dejado de ser un medio de comunicacin o para un segmento espec co de la poblacin para pasar a ser utilizadas por o la mayor de los ciudadanos y empresas, utilizndose para actividades que a a var desde la compra electrnica hasta el control log an o stico en puertos y aeropuertos internacionales. Este incremento en el uso de las redes de comunicaciones ha tenido mltiples consecuencias, pudiendo destacar entre ellas u el aumento de la cantidad y la importancia de la informacin que uye por o estas redes. En muchos casos nos encontramos con que esta informacin reo quiere de algn tipo de proteccin en su trnsito por las diferentes redes, ya u o a sea mediante servicios de condencialidad, de autenticacin, etc. . . . Adems, o a el aumento en el uso de las redes de comunicaciones ha llevado aparejado un incremento en el tipo de dispositivos que pueblan dichas redes: desde supercomputadores y ordenadores pertenecientes a mltiples empresas hasta u telfonos mviles, agendas personales e incluso consolas y plataformas de e o juegos, llegando al extremo en el que el trmino redes de ordenadores ha e sido desplazado por el de redes de comunicaciones. Esta popularizacin de las redes de comunicaciones ha llevado aparejao da el incremento de informacin que se transmite por ellas, y actualmente o es habitual utilizarla para operaciones tan comunes como llevar a cabo transacciones con la Administracin pblica (por ejemplo, la presentacin de o u o la declaracin de impuestos), adquirir entradas para mltiples espectcuo u a los culturales o deportivos, e incluso descargar pel culas directamente a la televisin de nuestro hogar. Sin embargo, otra consecuencia de esta popuo larizacin ha sido el incremento de actividades delictivas llevadas a cabo o utilizando estas redes. Dichas actividades delictivas se presentan de muchas 1

Cap tulo 1. Introduccin o

formas, desde actualizaciones de estafas y engaos tradicionales hasta la n completa suplantacin de identidad gracias a informacin personal recabao o da de la v ctima. Debido a esta proliferacin de ataques y al ya mencionado incremento o de la informacin que se transmite a travs de las redes de comunicaciones, o e es necesario proporcionar los medios necesarios para proteger a los usuarios y sus datos de estos ataques. De manera general, las medidas de seguridad pueden clasicarse en medidas que protegen los equipos o dispositivos, y medidas que protegen la comunicacin en s misma. Las primeras estn o a orientadas a proteger de ataques que permitan obtener o destruir la informacin que en ellos se almacena (mediante, por ejemplo, virus o caballos de o Troya) el sistema, equipo o dispositivo que se utiliza para acceder a la red o que proporciona un servicio determinado en esa red. Tradicionalmente estas medidas de seguridad se llevan a cabo instalando algn tipo de software o u hardware en el sistema, que se encargar de proporcionar las herramientas a y medidas necesarias. Por el contrario, las medidas de seguridad que protegen la comunicacin tienen por objetivo hacer que la transmisin de informacin a travs de o o o e redes de comunicaciones se lleve a cabo de la manera ms segura posible, a proporcionando herramientas para poder asegurar que el equipo o sistema al que se est enviando (o del que se est recibiendo informacin) es aqul a a o e con el que se desea intercambiar la informacin, para prevenir el acceso no o autorizado por parte de terceras personas a la informacin en trnsito, para o a asegurar que la informacin no es modicada (accidental o intencionadao mente) durante su transmisin, etc. . . . La proteccin de la comunicacin se o o o lleva a cabo mediante el uso de protocolos de seguridad que se integran en la pila de protocolos que utilizan los extremos de la comunicacin. Depeno diendo del nivel de la pila al que se realice la integracin, ser necesario o a hacer que las aplicaciones o el sistema operativo incluyan las operaciones correspondientes al protocolo de seguridad. Dado que el diseo de estos protocolos de seguridad no es una tarea n trivial y su realizacin incorrecta puede poner en peligro la seguridad de o todo un sistema si el protocolo resultante es defectuoso, el diseo y anlisis n a de estos protocolos se ha dejado en manos de los organismos encargados de disear y estandarizar el resto de los protocolos de comunicaciones. En los n ultimos aos, mltiples protocolos de seguridad se han estandarizado, de n u forma que las especicaciones de estos mecanismos para proteger la informacin estuviesen disponibles para cualquier grupo de desarrollo. Algunos o de estos estndares que se encuentran ampliamente integrados con las hea rramientas de comunicaciones en la actualidad son Transport Layer Security (TLS, [49]), IPsec [90],[91] y todos sus protocolos internos (Internet Key Exchange, IKE [65], [25], Authentication Header, AH [88], [86]), Kerberos (en su versin 5, [107]), Secure Shell (SSH, [154]), Extensible Authentication o

1.1. Origen de la tesis

Protocol (EAP, [1]), etc. . . ., y muchos otros. Esta situacin ha llevado apao rejada la aparicin de mltiples fabricantes con productos que proporcionan o u mecanismos para asegurar las redes de comunicaciones. El nmero y tipo u de soluciones de seguridad que podemos encontrar hoy en d para proteger a nuestra red son muy elevados, disponiendo de soluciones hardware, software, integradas con el sistema operativo o completamente independientes, utilizando criptograf fuerte o ligera, etc. . . . a Sin embargo, la competencia en este mercado ha llevado a los fabricantes a tener que mejorar su solucin para disponer de una ventaja competitiva o frente al resto, y eso ha hecho que las soluciones de seguridad hayan sido dotadas de caracter sticas adicionales: mejoras en el rendimiento y mayor variedad de suites criptogrcas son algunas de las ventajas ms comunes que a a podemos encontrar hoy en d en las soluciones de seguridad. Por desgracia, a estas mejoras y modicaciones a las soluciones de seguridad han conducido en muchos casos a modicaciones en la forma en la que el estndar se implea menta en la solucin de seguridad, haciendo que los dispositivos o programas o que incorporan estas mejoras se vean afectados por mltiples problemas u de interoperabilidad cuando intentan establecer un canal de comunicaciones seguro con implementaciones de distinto fabricante, las cual no incorpora las modicaciones llevadas a cabo sobre el estndar, como podemos ver en [99], a donde podemos encontrar una lista de implementaciones de IPsec que pueden establecer tneles criptogrcos con la implementacin OpenS/WAN, y u a o en [45], donde se citan las implementaciones que han pasado una prueba de interoperabilidad desarrollada por los autores. Esta situacin se est convirtiendo en algo cada vez ms corriente, deo a a bido por un lado a la multiplicidad de fabricantes de soluciones de seguridad para las redes de comunicaciones, y por otro a la creciente dicultad que es la programacin en dispositivos con un elevado nivel de heterogeneidad (que o incluye los lenguajes de programacin utilizados, los recursos disponibles, o etc. . . ). De manera general, la mayor parte de las desviaciones del estndar a que podemos encontrar en las implementaciones de protocolos de seguridad estandarizados tienen su origen en alguna de las siguientes causas: No utilizacin de algoritmos criptogrcos estandarizados, o impleo a mentacin deciente de los mismos ([31], [32]) o Programacin defectuosa al implementar las especicaciones del estndar o a ([33], [30]) Modicaciones y optimizaciones que los fabricantes realizan sobre lo establecido en el estndar para aumentar el valor competitivo de sus a productos ([34], [29]) Las consecuencias en el mbito de la seguridad de estos problemas son a

Cap tulo 1. Introduccin o

ms graves de lo que en un inicio se podr pensar, por dos motivos princia a pales: 1. El problema se produce en el software o hardware cuya funcin es proteger la informacin. Si el funcionamiento de este hardo o ware o software es irregular se est provocando en el usuario del mismo a una falsa sensacin de seguridad que podr poner en un riesgo inneceo a sario la informacin hasta que el problema sea detectado y solucionado. o 2. Otras herramientas o mecanismos de seguridad pueden sufrir las consecuencias. Un funcionamiento deciente de una herramienta de seguridad al, por ejemplo, negociar los parmetros criptogrcos a a que se utilizarn posteriormente para proteger la condencialidad de a la informacin transmitida, podr hacer que las pol o a ticas de seguridad destinadas a proteger la informacin se vean vulneradas inconso cientemente. Adicionalmente, si nuestro problema es incorrectamente identicado por terceras partes como un intento de utilizar soluciones de seguridad de baja calidad, podr ocurrir que mediante redes de a conanza esa reputacin se transmita, impidindonos utilizar otros o e servicios necesarios para el correcto desempeo de las labores de nuesn tra empresa o persona. Una de las arquitecturas de seguridad que mayores problemas de interoperatividad presenta es IPsec. Uno de los motivos que se suelen utilizar para justicar esta situacin es la constante evolucin y revisin que sufre o o o la arquitectura. Como ejemplo, cabe decir que en la actualidad existen dos versiones estandarizadas de IPsec: la original, de 1.998 y una ms reciente a de Diciembre de 2.005 que se encuentra en estado de PROPOSED STANDARD en el IETF. Esta nueva versin no modica las capacidades ni las o caracter sticas de operacin de la arquitectura IPsec, sino que pasa a ino cluir en el estndar algunos aspectos que eran opcionales en aquella primera a versin (como la noticacin de congestin de la red (ECN, Explicit Congeso o o tion Notication) o se modican los mecanismos para solucionar problemas o situaciones especiales (como el NAT traversal, con el que se ofrece una solucin para que la modicacin de la direccin de red de los equipos se coo o o nectan a la red no afecte a las propiedades de seguridad ni a los dispositivos que utilizan NAT). Otro de los cambios importantes que se han producido en esta versin es el agrupamiento de todos los protocolos y mecanismos de o gestin de claves (IKEv1, ISAKMP, etc. . . .) en IKEv2, con lo que la secueno cia de mensajes utilizados ha sido revisada y actualizada. Por este motivo las dos versiones que se pueden encontrar hoy en d de IPsec ofrecen la a misma funcionalidad aunque no son compatibles entre s . Sin embargo, una de las causas de esta deciente interoperatividad entre las implementaciones de IPsec es la escasez de metodolog que puedan as

1.2. Interoperatividad

informar acerca de las capacidades de interoperatividad de una implementacin dada. Las metodolog existentes se centran en analizar un sistema de o as informacin en un entorno concreto y determinado, pero sin evaluar el nivel o de cumplimiento de los requisitos (que en el caso de una implementacin de o los protocolos de seguridad, vendr dados por el estndar del protocolo). an a Esto quiere decir que muchos de los anlisis que plantean no tienen sentido a o no son aplicables a la implementacin de un protocolo de seguridad (por o ejemplo, el control de acceso). Esta claro que como desarrollos que son, las implementaciones de los protocolos de seguridad siempre podrn someterse a a un anlisis por parte de una de estas metodolog pero el haber obtenido a as, un nivel de seguridad determinado no implica que la implementacin sea o conforme al estndar, y por lo tanto, no asegura la interoperatividad a con otros dispositivos. Sin embargo, es posible encontrar proyectos focalizados en la interoperatividad de las implementaciones, como es el caso del proyecto IPsec-WIT, del National Institute of Standards and Technology (NIST) estadounidense ([120]).

1.2.

Interoperatividad

En el mbito de la interoperatividad, las consecuencias de que las ima plementaciones, ya sean en hardware dedicado o en software que se integre con el sistema operativo, no se ajusten al estndar se pueden resumir en la a imposibilidad de conectarnos con redes que utilicen dispositivos diferentes al nuestro. Por un lado esto es un problema econmico (ya que una empresa o quedar ligada al proveedor de esa solucin a menos que pueda permitirse a o desechar todos los equipos o licencias adquiridas y comprar otras nuevas de otro fabricante, las cuales pueden llevar asociado el mismo problema), pero por otro lado es un obstculo importante al desarrollo de las redes de a comunicaciones. El alcance de estos problemas ya ha sido detectado por los responsables de la investigacin tanto en Europa como en Estados Unidos, y as en o , el VII Programa Marco de la Unin Europea, se proponen varias reas de o a inters con un mbito de trabajo importante para el desarrollo de la segue a ridad, una de las cuales se centra en la Integracin e Interoperatividad de o los Sistemas de Seguridad ([126]). Las acciones que se lleven a cabo en este rea deben estar orientadas a contribuir al desarrollo de otras propuestas e a intereses al proporcionar los medios para asegurar y validar la interoperatividad de esos sistemas. De esta manera, las actividades fomentadas desde este rea se centrarn en estudiar, evaluar y mejorar la interoperatividad e a a intercomunicacin de sistemas, equipos, servicios y procesos de seguridad. o A travs de esta rea de inters, la Unin Europea ha reconocido la e a e o existencia del problema de interoperatividad en los mecanismos para prote-

Cap tulo 1. Introduccin o

ger las redes de comunicaciones, y pretende proporcionar las herramientas, mecanismos y diseos necesarios para evitarlos. Adems, en este VII Pron a grama Marco tambin se desea afrontar la denicin de metodolog que e o as se lleven a cabo para evitar la falta de continuidad de los resultados que se alcancen. Adicionalmente, el desarrollo de los ecosistemas digitales (cuyo inicio se sita en el VI Programa Marco, siendo continuado en el VII) tiene tambin u e importantes implicaciones en lo que respecta a la necesidad de asegurar que diferentes sistemas, mecanismos y soluciones sean capaces de operar entre ellos sin especiales dicultades. Dado que los ecosistemas digitales abarcan desde pequeas y medianas empresas hasta grandes agrupaciones internan cionales de compa para la consecucin de los objetivos propuestos hay nas, o que proporcionar una plataforma universal y compuesta de estndares, de a manera que cualquier componente del ecosistema digital pueda hacer uso de ella, independientemente de los dispositivos o tecnolog propias que utilice as para acceder a la plataforma. Por todos estos motivos podemos decir que el VII Programa Marco es un respaldo importante a la investigacin recogida en esta tesis doctoral, ya o que demuestra que la necesidad de evaluar y asegurar la interoperatividad de los sistemas, especialmente en el rea de seguridad, ha sido identicada a por otros organismos y centros de investigacin internacionales, al tiempo o que deja entrever que las metodolog de evaluacin y validacin existentes as o o no ofrecen solucin alguna para estos problemas. o Como hemos podido observar, los protocolos y arquitecturas de seguridad se encuentran en la actualidad en una situacin delicada, ya que, de o proseguir la tendencia actual, la futura interoperatividad entre los diferentes sistemas que utilicen las redes de comunicaciones tendr que llevarse a cabo a sin mecanismos que garanticen los requisitos de seguridad necesarios.

1.3.

Rendimiento de los protocolos de seguridad

Adems de la interoperatividad y la conformidad con los estndares, a a tambin existen otras caracter e sticas de las implementaciones que es necesario conocer de cara a disear otras soluciones de seguridad globales o con un n a mbito de operacin mayor que el de la propia implementacin. Por ejemo o plo, lad herramientas destinadas a la deteccin de ataques de denegacin o o de servicio requieren del conocimiento previo acerca de las capacidades que puede ofrecer un dispositivo de red (por ejemplo, ancho de banda), con el n de detectar cundo los recursos disponibles estn siendo sobreutilizados a a sistemticamente. Ejemplos de herramientas similares propuestas por la coa munidad cient ca las podemos encontrar en [135], donde la aplicacin de o tcnicas y mecanismos relacionados con la calidad de servicio (QoS) pere

1.3. Rendimiento de los protocolos de seguridad

mite gestionar de forma eciente los recursos, o en [153], donde se utilizan tcnicas similares para prevenir denegaciones de servicio (DoS). Este tipo de e informacin no slo ayuda a implementar de forma ms eciente los mecao o a nismos de seguridad que protegern nuestra red, sino que, desde el punto de a vista de la investigacin, un mejor conocimiento del impacto de los protocoo los de seguridad en las capacidades de computacin y comunicacin de un o o dispositivo o equipo ayudar a introducir mecanismos de seguridad en otro a tipo de comunicaciones que actualmente se encuentran desprotegidas, como las comunicaciones de voz sobre IP (VoIP, [95]), o los terminales mviles o ([13]). Desde un punto de visto prctico, el conocimiento del rendimiento que a puede ofrecer una solucin de seguridad es importante para, principalmente, o evitar ocasionar una denegacin de servicio a nuestra propia red o sistema o (como se describe en [5]) al exigir de la solucin de seguridad un rendimiento o mayor del que puede ofrecer, al tiempo que sirve de baremo comparativo entre las diferentes soluciones que los proveedores de seguridad pueden ofrecer. Un ejemplo de este tipo de situaciones lo podemos ver en los telfonos mvie o les y agendas electrnicas disponibles hoy en d En estos dispositivos se o a: nos suele ofrecer la posibilidad de cifrar los datos que almacenamos en ellos (por ejemplo, contactos, calendario, citas, etc. . . .), pero si tenemos almacenada una gran cantidad de informacin (entendiendo por gran cantidad o un valor relativo a las capacidades de este tipo de dispositivos, como puede ser ms de 5 MBytes), el rendimiento de dichos dispositivos al realizar las a operaciones de cifrado y descifrado se reduce drsticamente. a En general, la vulnerabilidad de los sistemas a ataques de este tipo es muy comn, especialmente en los dispositivos mviles. Por lo tanto, es u o extremadamente factible el llevar a cabo una denegacin de servicio contra o un determinado dispositivo o sistema que utilice de forma poco apropiada los mecanismos y herramientas de seguridad (como se puede ver en [79], donde los recursos que requiere la tcnica de control de acceso Port-Knocking hace e que sea muy sencillo el inutilizar dicho mecanismo de seguridad). Un ejemplo de cmo un ataque de este tipo afecta a un mecanismo de seguridad puede o verse en la Tabla 1.3, donde un sistema con el mecanismo de autenticacin o es atacado enviando 60.000 intentos de conexin a puertos aleatorios1 . o

La descripcin completa del ataque puede encontrarse en [79] o

Cap tulo 1. Introduccin o

Tabla 1.1: Recursos del sistema que ejecuta el mecanismo de seguridad PortKnocking, con un intervalo de tiempo entre cada muestra de datos de 5 segundos. Las las en negrita representan los momentos en los que el ataque tuvo lugar. Las ultimas dos las de la tabla muestran cmo an despus de o u e nalizar el ataque, el sistema an se encontraba procesando los intentos de u conexin recibidos o Memoria CPU Swap Libre Buffer Cache Usuario Sistema Libre 0 7536 8920 119524 0 0 100 0 7536 8920 119524 2 0 98 0 7536 8920 119524 0 1 99 0 7536 8920 119524 0 1 99 0 3784 8924 119524 0 0 100 0 3976 8924 117472 12 47 42 0 3264 8916 116648 23 77 0 0 3628 8920 112636 58 42 0 0 3708 8920 111668 81 19 0 0 3816 8920 110696 85 15 0 0 3960 8920 109720 92 8 0 0 3052 8920 109732 88 12 0 0 3576 8928 107916 50 50 0 0 3832 8928 106092 41 59 0 0 3908 8924 102180 89 11 0 0 3900 8928 102180 83 17 0 0 3900 8928 102180 89 11 0 0 3900 8928 102180 78 13 9 0 3896 8928 102180 0 0 100 0 3896 8928 102180 0 0 100 0 7688 8932 102180 1 0 99 0 7688 8932 102180 1 1 98

1.4. Objetivos de la tesis

Desde este punto de vista, es necesario disponer de mecanismos que nos proporcionen informacin acerca de las caracter o sticas de rendimiento de un nuevo dispositivo de seguridad para as poder dimensionar y conocer las caracter sticas de nuestro sistema con mayor exactitud. Es en este punto en el que la importante relacin entre conformidad con o el estndar y el rendimiento de nuestra solucin de seguridad se pone de maa o niesto, ya que el uso de tcnicas y mecanismos no recogidos en el estndar e a que dene los protocolos de seguridad (y que de hecho, convierten nuestra implementacin en incompatible con el mismo), puede llevarnos a una situao cin en la que, de todas las posibles opciones de algoritmos criptogrcos, o a mtodos de autenticacin, etc. . . . ofertadas por nuestra implementacin, las e o o unicas que pueden ser utilizadas al conectarnos a otras implementaciones son aquellas que ofrecen un peor rendimiento, lo que nos puede conducir a una auto-denegacin de servicio. o Esta situacin es un problema para los sistemas que ofrecen servicios en o red, ya que su capacidad de crecimiento puede verse repentinamente frenada al no disponer de sistemas capaces de dar servicio a todos los clientes que lo necesitan. Pero para los clientes es tambin un problema, ya que pueden e disponer de dispositivos con escasos recursos computacionales (por ejemplo, los telfonos mviles o las agendas electrnicas) o de ordenadores personales e o o potentes, pero con un elevado nmero de aplicaciones ejecutndose en ellos, u a con lo que si uno de los procesos consume demasiados recursos, el resto de aplicaciones se vern afectadas, incidiendo este hecho seriamente en la a usabilidad del sistema ([105]). Adicionalmente, existe el problema de que la medicin de los recuro sos necesarios para realizar cada operacin criptogrca de forma aislada o a en nuestro sistema no es informacin suciente, ya que la existencia de coo municaciones seguras establecidas anteriormente afecta al comportamiento de nuestro sistema, siendo diferente el impacto si esas comunicaciones slo o estn establecidas (pero no se transmite trco) o si se estn transmitiena a a do datos (variando tambin los resultados en funcin del volumen de datos e o que se env Esta informacin de rendimiento no suele proporcionarse con e). o los conjuntos de pruebas de rendimiento tradicionales, aunque al utilizar protocolos de seguridad la importancia de este factor sea enorme.

1.4.

Objetivos de la tesis

Tras analizar todos los motivos expuestos en este cap tulo, y siguiendo con las l neas de investigacin ya fomentadas en proyectos del NIST eso tadounidense y por la Unin Europea, con el n de garantizar y dotar de o seguridad las capacidades de interconexin entre las diferentes entidades que o hacen uso de las Tecnolog de la Informacin y Comunicaciones (como queas o

Cap tulo 1. Introduccin o

10

da expresado en las l neas de actuacin del VII Programa Marco de la Unin o o Europea), se hace necesario disponer de las herramientas necesarias que permitan validar y evaluar los mecanismos de seguridad que se utilizan para la interconexin de redes. o La presente tesis tiene por objetivo general el proporcionar los mtodos e y mecanismos necesarias para llevar a cabo una evaluacin de las impleo mentaciones de protocolos de seguridad que proporcione informacin able o e independiente acerca de: 1. Conformidad con el estndar: Se analizarn las especicaciones a a de los protocolos y arquitecturas de seguridad para identicar aquellos aspectos cr ticos a la hora de establecer la conformidad o no de una implementacin con respecto a lo descrito en el estndar y se deo a nir una metodolog que permita obtener la informacin relevante a a o en este aspecto. 2. Interoperabilidad: A partir de los resultados en las pruebas de conformidad con el estndar, y contando con los resultados obtenidos de a la evaluacin de la conformidad de otras implementaciones, ser posio a ble emitir un informe acerca de las capacidades y limitaciones en la a interoperabilidad de la implementacin con otras implementaciones. o 3. Rendimiento de la implementacin: Tras llevar a cabo los pasos o indicados en la metodolog se proporcionar al usuario la informaa, a cin acerca del rendimiento que se puede obtener de la implementacin o o analizada, tanto en aspectos tradicionalmente evaluados en conjuntos de pruebas de rendimiento para redes como en otros aspectos no evaluados pero que resultan de inters en el mbito de los protocolos de e a seguridad, como ya se ha apuntado anteriormente. 4. Sugerencias de conguracin: Se denirn las directrices que pero a mitirn, a partir de los resultados anteriores (tanto los relevantes a a conformidad como al rendimiento), proporcionar informacin acerca o de las conguraciones que permiten maximizar las posibilidades de interconexin al tiempo que se indican las limitaciones de rendimiento o que se presentan con dicha conguracin. o Para poder alcanzar las metas propuestas, los objetivos detallados que se marca la presente tesis son la identicacin de los parmetros que o a inuyen en la conformidad con el estndar, la identicacin de a o parmetros de rendimiento que resultan de inters en implementacioa e nes de protocolos de seguridad y el establecimiento de un marco de anlisis y desarrollo para protocolos y arquitecturas de seguridad a a partir del cual poder desarrollar una metodolog que permita valia dar y evaluar implementaciones de protocolos y arquitecturas de

11

1.4. Objetivos de la tesis

seguridad. Por su parte, la aplicacin de la metodolog a la arquio a tectura de seguridad IPsec junto con el desarrollo de una plataforma de validacin y evaluacin remota de implementaciones IPsec son o o los objetivos que permitirn evaluar esta tesis. A continuacin analizaremos a o cada uno de estos objetivos con mayor profundidad.

1.4.1.

Identicacin de parmetros de conformidad con el o a estndar a

En el documento con el que se estandariza un protocolo de seguridad aparecen especicados en lenguaje natural gran cantidad de requisitos, formatos, estructuras de datos, operaciones, suites criptogrcas, etc. . . , que a cualquier implementacin del protocolo deber respetar. Sin embargo, el o a tratar de realizar una validacin de una implementacin leyendo el estndar o o a del protocolo representa una tarea prcticamente imposible de llevar a cabo, a debido tanto a la cantidad de elementos a tener en cuenta como a su diversa naturaleza. Adicionalmente, el hecho de que el estndar se encuentre redaca tado en lenguaje natural no ayuda a identicar de manera ecaz ni eciente dichas caracter sticas que necesitamos. Por este motivo, el primer objetivo que la presente tesis aborda es la identicacin de aquellas caracter o sticas de los protocolos y arquitecturas de seguridad estandarizados que debern ser tenidas en cuenta al evaluar la a conformidad. Con el n de facilitar su posterior tratamiento y anlisis de caa ra al desarrollo de la metodolog en esta fase se proceder a identicar los a, a parmetros por los que estas diferentes caracter a sticas pueden agruparse. Es decir, todas aquellas caracter sticas denidas en el estndar que deban ser a evaluadas siguiendo tcnicas o procedimientos similares, debern ser agrue a padas y presentadas como una familia de caracter sticas, con el n de que los mtodos que se determinen como idneos para evaluar cada una de esas e o caracter sticas pueda aplicarse a todos los dems. a

1.4.2.

Identicacin de parmetros de rendimiento o a

Como se ha comentado anteriormente, los parmetros de rendimiento a que podemos obtener a partir de los conjuntos de pruebas de rendimiento de red actuales pueden no ser los ms adecuados para las implementacioa nes de protocolos de seguridad, bien por problemas de implementacin, bien o porque la informacin obtenida no satisface nuestras necesidades como ado ministradores de la red. Como se ver ms detalladamente en el Cap a a tulo 4, las operaciones criptogrcas que utilizan los protocolos de seguridad hacen a dif predecir los resultados de rendimiento, de forma que no es factible cil prever a priori cul va a ser el comportamiento de una determinada implea mentacin de un protocolo de seguridad, ni siquiera en el caso de disponer o

Cap tulo 1. Introduccin o

12

de la informacin que proporciona el fabricante para un dispositivo, equipo o o software similar, ya que cualquier cambio en la arquitectura del sistema, en el procesador, en la memoria, etc. . . . tiene repercusiones en la ejecucin o de las operaciones criptogrcas. a Para afrontar esta problemtica, en esta tesis se analizarn las especiales a a caracter sticas de los protocolos de seguridad, para as obtener un conjunto de parmetros de rendimiento que es necesario conocer para planicar las a capacidades de operacin de la implementacin analizada. Los parmetros o o a que se identiquen debern cubrir las necesidades de informacin para toa o do tipo de implementaciones (hardware, software, . . . .), posibles modos de funcionamiento (pasarela, equipo nal), tipos de usuario (usuario personal, administrador de red corporativa), etc. . . .

1.4.3.

Establecimiento de un marco de anlisis y desarrollo a para protocolos y arquitecturas de seguridad

El siguiente de los objetivos planteados dentro de esta tesis doctoral se centra en el desarrollo de un marco de anlisis para protocolos y arquiteca turas de seguridad, de tal forma que los estudios que se lleven a cabo para identicar los parmetros de conformidad y rendimiento sean extrapolables a a cualquier protocolo o arquitectura de seguridad, as como a otras solucio nes de seguridad llevando a cabo unicamente modicaciones m nimas en el trabajo realizado. Asimismo, en este marco se englobarn los desarrollos para la implea mentacin de la plataforma de validacin y evaluacin remota, de forma o o o que, en la medida de lo posible, las librer desarrolladas permitan su posas terior aplicacin a otros protocolos, mecanismos y arquitecturas de segurio dad, as como la actualizacin del juego de pruebas a las que se someten las o implementaciones estudiadas.

1.4.4.

Metodolog de validacin y evaluacin de implemena o o taciones de protocolos y arquitecturas de seguridad

Una vez conocidos los parmetros que deben ser evaluados, tanto en a lo referente a la conformidad con el estndar como a parmetros de rendia a miento, en esta tesis se presentar una metodolog para la evaluacin de a a o implementaciones de protocolos y arquitecturas de seguridad. En esta metodolog se propondrn los principios, prcticas y procedimientos para evaluar a a a las implementaciones utilizando para ello las redes de comunicaciones que conecten la implementacin que se desea evaluar con el sistema evaluador. o Esta metodolog presentarn, de forma estructurada y razonada, los a a mtodos que permitirn obtener la informacin necesaria para llevar a cabo e a o la validacin de la conformidad y evaluacin del rendimiento de implemeno o

13

1.4. Objetivos de la tesis

taciones de protocolos y arquitecturas de seguridad. Adicionalmente, en la metodolog tambin se incluirn las pautas y recomendaciones que debern a e a a tenerse en cuenta a la hora de ofrecer gu de conguracin orientativas o as o comparaciones de los resultados obtenidos.

1.4.5.

Aplicacin de la metodolog a la arquitectura de seo a guridad IPsec

Como consecuencia directa de la denicin de la metodolog ya comeno a tada, surge la necesidad de llevar a cabo la aplicacin de dicha metodolog a o a la validacin y evaluacin de implementaciones de un protocolo o arquitectuo o ra de seguridad concretas. En esta tesis se ha decidido aplicar la metodolog a a la arquitectura de seguridad IPsec, por sus caracter sticas de aceptacin e o implantacin, proyeccin futura y completitud en cuanto a servicios y mecao o nismos de seguridad. Esta aplicacin de la metodolog a una arquitectura o a de seguridad concreta permitir obtener una referencia tanto del paso de la a metodolog genrica a conjuntos de pruebas concretos para un protocolo a e de seguridad determinado, como de soluciones y propuestas para solventar aquellas dicultades que aparezcan en dicha transicin. o Esta aplicacin de la metodolog deber contemplar todas las fases, o a a procedimientos, mecanismos y mtodos de los que consta la metodolog e a, pero siempre teniendo en cuenta cules son las caracter a sticas de la arquitectura a la que se van a aplicar dichos mecanismos.

1.4.6.

Desarrollo de una plataforma de evaluacin remota de o implementaciones de IPsec

Finalmente se desarrollar de una plataforma de validacin y evaluaa o cin remota de implementaciones de IPsec que desarrolle todo lo especicado o por la aplicacin de la metodolog a la arquitectura de seguridad IPsec. La o a plataforma resultante deber cubrir todos los aspectos desarrollados en la a aplicacin, desde el anlisis de los aspectos que limitan la conformidad con el o a estndar, hasta la generacin de esquemas de conguracin. Esta implemena o o tacin deber servir como modelo para posteriores optimizaciones o mejoras, o a al tiempo que propondr soluciones a problemas de implementacin que se a o presenten. La implementacin de la plataforma conlleva un doble desarrollo: por o un lado es necesario generar todas las pruebas individuales que evalan una u unica caracter stica descrita en la la aplicacin de la metodolog y por o a, otro es necesario despus integrar todas esas pruebas de concepto en una e plataforma unica, con un interfaz desde el que el usuario pueda interac tuar. Adicionalmente, la plataforma que se desarrolle en esta tesis doctoral deber tener en cuenta la posibilidad de integrarse con otras herramientas. a

Cap tulo 1. Introduccin o

14

1.5.

Organizacin de la tesis o

Esta tesis doctoral se organiza de la siguiente manera: En el cap tulo 2 se revisar el estado de la cuestin en los aspectos de estandarizacin y a o o validacin de la seguridad, analizando las metodolog de validacin de la o as o seguridad del software y la validacin de una implementacin de un protoo o colo de seguridad (seccin 2.2). En este apartado se estudiarn los diferentes o a enfoques de la evaluacin de protocolos de seguridad en la actualidad, utio lizando para ello un proyecto representativo de cada uno de estos enfoques (apartado 2.2.4) para posteriormente revisar las caracter sticas de diferentes conjuntos de pruebas de rendimiento para dispositivos de red (seccin 2.3). o En el cap tulo 3 se afrontar el primero de los objetivos marcados paa ra esta esta tesis: el anlisis de las caracter a sticas de conformidad con los estndares de IPsec, prosiguiendo en el cap a tulo 4 con anlisis de los parmea a tros de rendimiento que es necesario evaluar en una implementacin de IPsec. o Como resultado de estos anlisis, en el cap a tulo 5 se presentar la metodoa log de evaluacin de implementaciones de protocolos y arquitecturas de a o seguridad que recoge las aportaciones de los cap tulos anteriores y las convierte en el cap tulo 6 en una gu para evaluar las implementaciones de a la arquitectura de seguridad IPsec. Finalmente, en el cap tulo 7 se estudiar la implementacin de esta metodolog propuesta, para llevar a cabo a o a la validacin y evaluacin remota de implementacin de IPsec. o o o El cap tulo 8 se dedica por completo a presentar los resultados de evaluar implementaciones comerciales de IPsec utilizando la plataforma desarrollada, analizando los resultados obtenidos. Por ultimo, en el cap tulo 9 se presentarn las conclusiones de esta a tesis doctoral, tanto en lo referente a las aportaciones realizadas en la misma (comparndolas con los objetivos propuestos en dicha tesis) como a los a documentos y desarrollos que surgen de la misma (seccin 9.1). o

Cap tulo 2

Estado de la Cuestin o
En este cap tulo analizaremos cul es el estado de la cuestin tanto a o en la estandarizacin y evaluacin de la seguridad, como en el anlisis de o o a rendimiento, especialmente de los protocolos y arquitecturas de seguridad. En primer lugar se llevar a cabo un estudio de la situacin de los estndares a o a utilizados en el mbito de la proteccin de las comunicaciones. a o Por lo tanto, el cap tulo comenzar describiendo en la seccin 2.1 el a o estado actual de los protocolos y arquitecturas de seguridad que han sido estandarizados, as como los estndares ms relevantes desde el punto de a a vista de la seguridad en las comunicaciones en cuanto a mecanismos criptogrcas. A continuacin, en la en la seccin 2.2 pasaremos a analizar el a o o estado de la cuestin en el mbito de la validacin de la seguridad, donde o a o se estudiarn los diferentes enfoques en la validacin de la seguridad que es a o posible encontrar en la literatura cient ca en la actualidad. En esta seccin o merecen especial atencin los apartados sobre metodolog de evaluacin o as o de seguridad (apartado 2.2.5) y sobre validacin de protocolos de seguridad o (apartado 2.2.4), en los que se analizan los temas que tienen una mayor relacin con el mbito de esta tesis. Finalmente, en la seccin 2.3 se analizar el o a o a estado de la cuestin en lo tocante al anlisis de rendimiento de protocolos o a de red, haciendo especial hincapi en los anlisis de rendimiento centrados e a en los protocolos de seguridad (apartado 2.3.1).

2.1.

Estandarizacin de la seguridad o

En esta seccin se presentarn las contribuciones de la comunidad cient o a ca en los pasados aos al campo de la estandarizacin de la seguridad, espen o cialmente en cuanto a los protocolos y arquitecturas de seguridad se reere. Adicionalmente, tambin se revisarn los trabajos de estandarizacin de hee a o rramientas criptogrcas ms relevantes para los protocolos de seguridad. a a 15

Cap tulo 2. Estado de la Cuestin o

16

2.1.1.

Protocolos y arquitecturas de seguridad

En este apartado se analizarn los protocolos y arquitecturas de segua ridad en uso actualmente, de forma que podamos conocer cul ha sido su a evolucin, los servicios de seguridad que ofrecen y los mecanismos y herrao mientas criptogrcas que utilizan para proteger la informacin, as como el a o nivel de la pila de comunicaciones al que trabaja cada uno de los protocolos o arquitecturas estudiados. El anlisis se llevar a cabo sobre el protocolo a a TLS y la arquitectura de seguridad IPsec, debido a la amplia aceptacin o de ambos por parte de la comunidad cient ca, y su amplia (casi totalitaria en algunos casos) adopcin de ambos para la proteccin de los servicios de o o Internet. La aceptacin de ambos ha sido tal, que la aparicin de nuevos o o dispositivos y sistemas de comunicacin que no pod implementar estos o an protocolos (bien por los requisitos computacionales necesarios, bien por problemas al implantar la pila de protocolos requerida), ha llevado aparejado el desarrollo de nuevos protocolos que sustituyesen a TLS o IPsec. El caso ms notorio es el de WTLS (Wireless Transport Layer Security, [57]), que a ofrece funcionalidad similar a TLS a los dispositivos que operan con WAP (Wireless Application Protocol, [56]), principalmente telfonos mviles. e o 2.1.1.1. SSL y TLS

Descripcin o El protocolo SSL (Secure Socket Layer ) fue desarrollado por la compa na Netscape Communications desde el inicio del desarrollo del navegador web de dicha compa Desde los trabajos en el navegador Mosaic por la Nana. tional Center for Supercomputing Applications (NCSA) en 1.993 ([106]) la necesidad de incluir algn mecanismo de seguridad se hizo evidente. Por u este motivo, y de cara a incluirse con la versin 1.0 de Netscape Navigator, o la compa desarrolladora de este navegador inici el diseo de la versin na o n o 1.0 de SSL, proceso que se culminar slo 8 meses ms tarde, a mediados a o a de 1.994. Posteriormente, a nales de ese mismo ao Netscape distribu la n a primera versin de su navegador con soporte para la versin 2.0 del protoo o colo SSL. Esta nueva versin estaba orientada a subsanar deciencias que se o detectaron en la versin 1.0 del protocolo, principalmente en la gestin de o o claves criptogrcas. a La adopcin de SSL como un estndar de facto por parte de la induso a tria se aanzar en 1.995, cuando Microsoft Corporation lanz su navegador a o Internet Explorer e incluy en el mismo el soporte para SSL, que, recordeo mos, en aquel momento segu siendo un protocolo desarrollado por una a compa rival y cuyo proceso de estandarizacin no hab comenzado. Por na o a este mismo motivo, Microsoft public en 1.995 la especicacin de un nuevo o o protocolo que sustituir a SSL: el protocolo PCT (Private Communication a

17

2.1. Estandarizacin de la seguridad o

Technology) versin 1.0. Aunque este intento de Microsoft por hacerse con o el control de los protocolos de seguridad en Internet no fructic, las proo puestas y mejoras que se recog en esa especicacin fueron incorporadas an o a SSL en su versin 3.0, publicada por Netscape a nales de ese mismo ao. o n En este punto de la historia tuvo lugar un cambio en el diseo y desan rrollo de SSL: hasta el momento, Netscape Corporation hab desarrollado a las tres primeras versiones del protocolo siguiendo un proceso abierto y en el que animaba a participar a otras compa y comunidades del sector. nas Sin embargo, el que la compa siguiera siendo propietaria del protocolo na (de hecho, Netscape Corporation solicit con xito una patente sobre este o e protocolo) no animaba a potenciales competidores a colaborar, al tiempo que la comunidad internacional miraba con recelo las posibles implicaciones futuras de este modelo de desarrollo. Por este motivo, en Mayo de 1.996 Netscape cedi el desarrollo de SSL, que pas a encontrarse bajo el control o o del Internet Engineering Task Force, que es el responsable del desarrollo del mismo en la actualidad. Debido a la propiedad de Netscape del nombre SSL, una de las primeras acciones del IETF fue renombrar el protocolo a TLS (Transport Layer Security). La versin 1.0 de este protocolo (ya estandario zado) se public en enero de 1.999 ([48]), y est basada en SSL 3.0 (hasta o a el punto de que las diferencias entre SSL 3.0 y TLS 1.0 son menores que las existentes entre SSL 2.0 y SSL 3.0). En la actualidad la gran mayor del software que hace uso de Intera net de una forma u otra cuenta con soporte para SSL o TLS, ya que este protocolo se ha convertido en el estndar de proteccin de informacin en a o o Internet. Dadas las similitudes entre ambos protocolos, de aqu en adelante hablaremos de TLS para referirnos indistintamente a ambos protocolos. Funcionamiento TLS es un protocolo de seguridad que se sita sobre la capa de transporte u de la pila de comunicaciones, ms concretamente, sobre el protocolo TCP. a Una de sus caracter sticas principales es que al introducirse en la pila de protocolos, lo hace de forma transparente a las capas inmediatamente superior e inferior, de forma que no es necesaria ninguna modicacin al protocolo o TCP (ya que TLS utilizar los mecanismos de comunicacin que ofrece TCP, a o en concreto, los sockets) ni a la capa de aplicacin (ya que sta podr hacer o e a uso de los sockets seguros de TLS prcticamente de igual forma que utilia zaba los sockets TCP). Un esquema de este funcionamiento puede verse en la Figura 2.1. Gracias a este funcionamiento, TLS crea una capa adicional en la pila de comunicaciones que permite a las aplicaciones que securicen sus comunicaciones sin tener que realizar modicaciones importantes en su cdigo. o En cuanto a los mecanismos internos que utiliza TLS para proteger

Cap tulo 2. Estado de la Cuestin o

18

Figura 2.1: Pila de protocolos TCP/IP tradicional (izquierda) y pila TCP/IP tras aadir la capa de TLS n

Figura 2.2: Pila de protocolos TLS. La capa de aplicacin y los subprotoo colos de negociacin, alerta y cambio de cifrado generan paquetes que son o protegidos y enviados por el protocolo de registro

19

2.1. Estandarizacin de la seguridad o

la informacin, TLS est compuesto por varios subprotocolos espec o a cos para llevar a cabo tareas concretas. La pila de subprotocolos de TLS puede verse en la Figura 2.2. La funcin de cada uno de estos subprotocolos es la o siguiente: Protocolos de Negociacin (Handshake Protocols): El protocolo de o negociacin de TLS es el encargado de permitir a los diferentes extreo mos de la comunicacin negociar los parmetros de seguridad que se o a aplicarn posteriormente para proteger la informacin (el protocolo de a o registro ser el encargado de aplicar los parmetros que se negocien a a con este protocolo), as como de autenticar a las entidades que toman parte en la comunicacin, instanciar los parmetros de seguridad neo a gociados y noticar las posibles condiciones de error que se pudieran dar. Cada una de estas funciones es llevada a cabo por un subprotocolo diferente, por lo que el protocolo de negociacin realmente consta de o 3 subprotocolos, que son los siguientes: Subprotocolo de Cambio de Cifrado (Change Cipher Spec Protocol): Este subprotocolo es el encargado de noticar al otro extremo de la comunicacin segura un cambio en los parmetros o a utilizados para proteger la informacin, mediante el env de un o o unico mensaje (securizado con los parmetros de proteccin an a o tiguos), que marca el n del uso de los parmetros anteriores, ya a que todos los mensajes posteriores se protegern con los nuevos a parmetros. a Subprotocolo de Negociacin (Handshake Protocol): El subo protocolo de negociacin es el encargado de negociar los parmeo a tros que regirn la seguridad de la comunicacin. Los parmetros a o a ms importantes que se negocian son: la versin del protocolo a a o utilizar (pudindose utilizar cualquier versin de SSL o TLS que e o soporten las partes implicadas en la comunicacin), los algorito mos de cifrado, rma digital y compresin que se utilizarn, los o a parmetros de autenticacin y las tcnicas de clave pblica con a o e u las que se generarn los secretos compartidos. Los pasos concretos a que se han de llevar a cabo para nalizar con xito este proceso e son: Intercambiar los mensajes iniciales (Hello Messages) para acordar los algoritmos a utilizar Intercambiar valores aleatorios con los que generar material criptogrco a Comprobar si es posible continuar una sesin SSL / TLS o anterior Intercambiar la informacin criptogrca necesaria para que o a

Cap tulo 2. Estado de la Cuestin o

20

ambas partes puedan disponer de un secreto compartido (secreto pre-maestro). Intercambiar la informacin criptogrca necesaria para que o a ambas partes puedan autenticarse (el servidor debe hacerlo de forma obligatoria; para el cliente es opcional). Generar un secreto compartido (secreto maestro) a partir del secreto pre-maestro y los valores aleatorios anteriores. Proporcionar los parmetros y valores de seguridad necesaa rios al protocolo de registro. Permitir a la otra entidad vericar que los parmetros de a seguridad y valores criptogrcos (especialmente el secreto a maestro) se han intercambiado sin incidencias, y sin que haya evidencia de ningn ataque durante esta fase de negociacin. u o

Una vez que estos parmetros han sido acordados, el subprotocolo a de negociacin se encargar de proporcionar al protocolo de regiso a tro la informacin necesaria para que pueda proceder a proteger o la informacin. o Subprotocolo de Alerta (Alert Protocol): El subprotocolo de alerta es el encargado de noticar al resto de protocolos y subprotocolos, as como al otro extremo de la comunicacin, de una o condicin de error, informando al tiempo de la gravedad de dicha o condicin. En caso necesario, un mensaje de alerta puede llegar o a implicar el n de la comunicacin. o Protocolo de Registro (Record Protocol): Es el encargado de tomar los mensajes que las capas superiores de TLS o la capa de aplicacin o de TCP desean enviar, y fragmentarlos en bloques del tamao aden cuado, comprimirlos, aplicarles los mecanismos de condencialidad y autenticidad necesarios y transmitirlos a las capas inferiores de la pila de comunicaciones. A la hora de recibir los mensajes, este protocolo ser el encargado de realizar las operaciones inversas: comprobar la a autenticidad del mensaje, descifrarlo, descomprimirlo, reensamblarlo y transmitirlo a la aplicacin o subprotocolo de TLS al que vaya dirigido o ese mensaje. Un aspecto importante del funcionamiento de TLS es la diferencia entre los conceptos de sesin y conexin. Una sesin es el conjunto de parmetros o o o a de seguridad y valores utilizados para proteger la comunicacin entre dos o sistemas que utilizan TLS, mientras que una conexin es un ujo de datos o entre esos dos sistemas, que se protege utilizando los parmetros y valores a de la sesin TLS en la que se instancia dicha conexin. Los parmetros que o o a denen una sesin son: o Un identicador un voco, arbitrario y elegido por el servidor.

21

2.1. Estandarizacin de la seguridad o Un certicado del sistema con el que se establece el canal seguro. Un mtodo de compresin que aplicar a la informacin antes de ser e o o protegida. Una suite criptogrca con la que proteger la informacin a o Un secreto maestro de 48 bits, compartido entre el cliente y el servidor. Un indicador de si la sesin es reiniciable o no, es decir, de si los valores o y parmetros negociados deben ser almacenados para usos posteriores a sin necesidad de tener que llevar a cabo otra negociacin. o

Las suites criptogrcas denen conjuntos de algoritmos y mecanismos a de seguridad que se utilizarn para proporcionar los servicios de seguridad a deseados. Por ejemplo, una suite criptogrca aceptable en la versin 1.1 de a o TLS es TLS\_DHE\_DSS\_WITH\_DES\_CBC\_SHA, que especica los siguientes parmetros: a Die-Hellman ef mero con rmas DSS ([112]) como algoritmo de intercambio de claves. El cifrador de bloque DES operando en modo CBC para cifrar la informacin. o SHA como funcin resumen. o Servicios de seguridad que proporciona TLS proporciona los servicios de seguridad de condencialidad e integridad, y, opcionalmente, autenticacin. Dado que TLS soporta tres niveles o de autenticacin (mutua autenticacin, autenticacin del servidor y auseno o o cia de autenticacin), el servicio de autenticacin puede estar presente o no. o o Cuando existe autenticacin de al menos una de las partes, el tnel cripo u togrco es resistente a ataques de hombre en el medio, ya que para autena ticarse cada entidad debe presentar una cadena de certicados que conduzca a una autoridad de certicacin aceptada por la otra parte, utilizando para o ello los servicios de una infraestructura de clave pblica. Mediante el uso de u las suites criptogrcas que se negocian, cada sistema involucrado es capaz a de proteger la informacin que env al tiempo que la inclusin de cdigos o a, o o de autenticacin del mensaje (MAC, Message Authentication Codes [137]) o permite detectar modicaciones ileg timas a la informacin que uye por el o tnel criptogrco. u a

Cap tulo 2. Estado de la Cuestin o 2.1.1.2. IPsec

22

Descripcin o La arquitectura de seguridad IP (IPsec) es una propuesta del Internet Engineering Task Force (IETF) para dotar de proteccin basada en criptograf o a con alto nivel de seguridad a la capa de red IP (tanto para la versin 4 (IPv4) o como para la versin 6 (IPv6)), manteniendo la interoperatividad entre los o dispositivos o equipos que implementen esta arquitectura de seguridad. Como arquitectura de seguridad, est compuesta por mltiples protocolos ina u ternos, algunos de los cuales son obligatorios para la correcta proteccin de o la informacin, mientras que otros son meras propuestas. o Entre los objetivos de IPsec se encuentra el que, cuando se encuentra correctamente implementado y desplegado, no debe afectar a las aplicaciones ni a los usuarios que no protejan sus comunicaciones con esta arquitectura. Adems, la modularidad de los protocolos que lo conforman (todos ellos son a criptogrcamente independientes) permite que las aplicaciones y usuarios a que s hacen uso de la arquitectura puedan recibir una proteccin acorde a o sus necesidades, y que afecte lo menos posible a las operaciones que se llevan a cabo. La especicacin de IPsec se hizo pblica en 1.995, con la publicacin o u o de las RFCs en las que se den las especicaciones para una arquitectura an de seguridad a nivel de red ([11], [9], [10], [103], [83]), aunque en 1.998 una revisin general de la arquitectura dej obsoletas las antiguas especicacioo o nes, liberndose una nueva versin de las mismas en las que se estandariza a o una arquitectura conceptualmente similar a la primera versin, pero incomo patible con la misma ([90], [88], [89], [101], [85], [54], [70]). A nales de 2.005 se public una nueva versin de las especicaciones, en la que se reorganio o zaron los protocolos internos, as como algunos de los servicios de seguridad ofrecidos ([91], [86], [87], [136]). IPsec consta de varios protocolos, cada uno de los cuales se encarga de llevar a cabo una tarea determinada dentro de la arquitectura IPsec: gestin o de claves criptogrcas, autenticacin, condencialidad, . . . ; dependiendo a o del conjunto de protocolos que se utilice para proteger una determinada comunicacin, los servicios de seguridad que se ofrecern variarn. Algunos o a a de estos protocolos son de obligada implementacin, mientras que otros son o propuestas del IETF que sirven de ejemplo para el desarrollo de posibles protocolos alternativos (aunque posteriormente estas propuestas hayan sido aceptadas como estndares de facto). a

23

2.1. Estandarizacin de la seguridad o

Figura 2.3: Pila de protocolos IPsec en modo transporte y en modo tnel u

Funcionamiento IPsec tiene dos modos de funcionamiento independientes, con objetivos diferentes. Por un lado se dene el modo transporte para los datos, en el que se protegen los datos de nivel superior a IP (TCP, ICMP, etc.); en modo modo tnel, sin embargo, lo que se protegen son los propios paquetes de la capa u IP, encapsulndolos en otro paquete IP. Un esquema de la pila de protocolos a resultante en ambos casos puede verse en la Figura 2.3, donde se muestra qu informacin se protege en cada caso. e o Por otro lado, IPsec est compuesto varios protocolos que se encargan a de las tareas de gestin de informacin criptogrca y proteccin de la inforo o a o macin. La gestin de las claves recae sobre los protocolos IKE e ISAKMP o o en la especicacin de 1.998 y sobre IKE en la especicacin de 2.005 (o o o sobre cualquier protocolo que realice sus funciones, ya que los mecanismos de gestin de claves propuestos en los estndares son recomendaciones, y o a pueden ser sustituidos por cualquier otra solucin que cumpla los requisio tos). Por su lado, la proteccin de la informacin es responsabilidad de los o o protocolos ESP y/o AH, dependiendo de los parmetros de seguridad que se a hayan negociado. Por lo tanto, y teniendo en cuenta que la negociacin de o los parmetros de seguridad se lleva a cabo en dos fases que se explicarn a a a continuacin, el papel que juega cada protocolo en IPsec se ve reejado en o la Figura 2.4.

Cap tulo 2. Estado de la Cuestin o

24

Figura 2.4: Papel que juega cada protocolo de IPsec en el establecimiento y proteccin de tneles seguros o u En la fase de negociacin de IPsec el objetivo es acordar los parmeo a tros criptogrcos que regirn el posterior intercambio de informacin. Sin a a o embargo, en lugar de llevar a cabo una negociacin similar a la de TLS, en o IPsec el proceso se lleva a cabo de tal forma que el proceso de autenticacin slo se requiere una vez entre cada pareja de dispositivos IPsec, de tal o o forma que negociaciones posteriores no debern volver a llevar a cabo ese a mecanismo. De forma breve, el proceso de negociacin de claves se lleva a o cabo de la siguiente manera: En la Fase 1 de la negociacin los sistemas que establecern el tnel o a u seguro se autentican mutuamente utilizando cualquiera de los mtoe dos previstos para ello en el estndar, y acuerdan los parmetros de a a seguridad que se utilizarn en la Fase 2 de la negociacin. a o La Fase 2 de la negociacin se lleva a cabo cada vez que es necesario o establecer una nueva asociacin de seguridad entre dos entidades IPsec. o En esta fase (en la que todo el trco ya se transmite protegido por a los parmetros negociados en la Fase 1), se negocian los parmetros a a de seguridad concretos con los que se proteger la comunicacin de a o capas superiores. Entre los aspectos que se negocian se encuentran el protocolo a utilizar para proteger la informacin: ESP o AH. o Como podemos ver, de esta forma es posible negociar mltiples tneles u u seguros llevando a cabo una unica autenticacin de las partes, lo que reduce o

25

2.1. Estandarizacin de la seguridad o

considerablemente la cantidad de proceso a llevar a cabo, a costa de una mayor complejidad en la negociacin de claves. Adicionalmente, con esta o estructura se protege a cada una de las fases de potenciales problemas de seguridad en capas anteriores: si un atacante consiguiera hacerse con las claves negociadas en una Fase 1, los parmetros de seguridad negociados a en ejecuciones de la Fase 2 anteriores no se comprometen, por lo que esos tneles seguros pueden mantenerse operacionales.1 . u Otro concepto fundamental que ya ha sido mencionado son las asociaciones de seguridad (Security Associations, SA), que son conjuntos de servicios de seguridad que se aplicarn a las comunicaciones que cumplan a con un patrn determinado. Las asociaciones de seguridad constan de un o identicador unico (Security Parameter Index, SPI), los algoritmos de ci frado y autenticacin a utilizar (en caso necesario), el tiempo de vida de la o asociacin de seguridad, el modo de funcionamiento, y el protocolo que se o utilizar para proteger la informacin. Opcionalmente tambin puede incluir a o e el contenido de la ventana de datos para deteccin de ataques de reenv de o o paquetes, el valor de la MTU y contadores para los nmeros de secuencia de u AH o ESP. Las deniciones de las asociaciones de seguridad se almacenan en la base de datos de pol ticas de IPsec (Security Policy Database, SPD), en la que tambin se incluyen los parmetros del trco que se proteger con e a a a cada una de las asociaciones de seguridad. Por ultimo, cabe destacar que una implementacin de IPsec puede ope o rar como un equipo intermedio que proporciona el servicio de seguridad a otros equipos (lo que se suele llamar un IPsec gateway o pasarela IPsec), o como un dispositivo o equipo independiente que protege su trco con a IPsec, o cualquier combinacin de este tipo de modos de operacin, como o o se muestra en la Figura 2.5. La proteccin que ofrecer cualquiera de eso a tas implementaciones de IPsec sern las acordes al conjunto de pol a ticas de seguridad denidas en el dispositivo por el administrador. Para determinar cul de estas pol a ticas es la que debe utilizarse para cada canal de comunicacin o paquete de datos concreto, IPsec establece mecanismos, llamados o Selectors, que permiten realizar esta discriminacin basndose en datos de o a la cabecera IP o de la cabecera del siguiente nivel. Servicios de seguridad que proporciona

Los servicios de seguridad que ofrece la arquitectura de seguridad IPsec dependen en gran medida de qu protocolos son los utilizados para proteger e la informacin que se desea transmitir. Por lo tanto, es necesario realizar o
Para que esta armacin sea totalmente cierta es necesario que se utilice la opcin de o o Perfect Forward Secrecy (PFS), que independiza totalmente las claves de cada fase de las utilizadas en fases anteriores
1

Cap tulo 2. Estado de la Cuestin o

26

Figura 2.5: Posibles modos de funcionamiento de IPsec, desde el punto de vista de su operacin como pasarela o como dispositivo nal o un estudio de los servicios de seguridad que proporciona cada uno de estos protocolos para conocer cul es el conjunto de servicios que se encuentran a disponibles en la arquitectura: Authentication Header (AH): este protocolo proporciona los servicios de integridad de la comunicacin (siempre teniendo en cuenta o que las labores de control de ujo y de la conexin se llevan a cabo o por la capa de transporte de la pila de comunicaciones), autenticacin del origen de los mensajes, y, opcionalmente, proteccin contra el o o reenv de mensajes, que aunque es de obligada implementacin para o o el emisor, tiene carcter opcional para el receptor. a Encapsulating Security Payload (ESP): al igual que AH, ESP es capaz de proteger la informacin transmitida por los tneles cripo u togrcos proporcionando los servicios de integridad, autenticacin del a o origen de los mensajes y proteccin contra el reenv de mensajes. o o Adicionalmente, con ESP es posible contar con los servicios de condencialidad, ya que la informacin se transmite cifrada entre emisor y o receptor, y proteccin contra el anlisis de trco o a a En cuanto a los servicios de seguridad, ESP y AH ofrecen una cobertura diferente de los mismos, como pasamos a detallar: AH, cuyo soporte en una implementacin IPsec es opcional, ofrece o servicios de integridad y autenticacin del origen de los datos, con la o posibilidad opcional (a eleccin del receptor) de utilizar tcnicas para o e

27

2.1. Estandarizacin de la seguridad o evitar el reenv de paquetes. Adicionalmente, proporciona servicios o de control de acceso mediante la distribucin de claves criptogrcas o a segn se dena en las pol u ticas de seguridad que gobiernan IPsec. ESP, cuyo soporte en una implementacin IPsec es obligatorio, ofrece o los mismos servicios que AH, y adems proporciona condencialidad. a Esta condencialidad tambin se aplica parcialmente a los datos ree lativos al trco original (como el tamao de los datos, etc.). Adicioa n nalmente, ESP es capaz de ofrecer resistencia a ataques de reenv de o mensajes.

Adicionalmente, es posible contar con proteccin frente a posibles atao ques de anlisis de trco si la arquitectura de seguridad IPsec se utiliza para a a funcionar en modo tnel, de forma que la informacin que un posible atau o cante pueda recuperar se limite a la m nima indispensable para encaminar los mensajes desde el equipo o red de origen hasta el destinatario.

2.1.2.

Mecanismos criptogrcas a

La estandarizacin de mecanismos criptogrcos se ha llevado a cao a bo por diferentes organismos de estandarizacin, dependiendo del alcance y o mbito que se pretendiese abarcar con dicho estndar. Por un lado, organisa a mos como IEEE e ISO han estandarizado en los ultimos aos mecanismos de n seguridad integrados en protocolos (como por ejemplo, los mecanismos de proteccin WEP y WPA denidos en el estndar 802.11b, o los mecanismos o a de seguridad incluidos en el estndar 802.11i ([43] y [44] respectivamente)) a o arquitecturas de seguridad,(como las descritas en el estndar ISO/IEC a 10181 ([42]), en el que se revisan los marcos de trabajo para la seguridad en sistemas abiertos). Por otro lado, en estos procesos de estandarizacin de herramientas o criptogrcas tambin han participado organismos como el NIST estadoua e nidense (con repercusin legal unicamente en Estados Unidos, pero que crea o estndares de facto en toda la comunidad internacional), la Unin Intera o nacional de Telecomunicaciones (Intenational Telecommunications Union, ITU) y el Internet Engineering Task Force, que en su proceso de estandarizacin de las herramientas utilizadas en el desarrollo y utilizacin de Ino o ternet tambin estandariza las suites criptogrcas vlidas para su uso por e a a los diferentes protocolos y arquitecturas de seguridad (como por ejemplo al e estandarizar AES CMAC ([142])). Sin embargo, este organismo tambin es el responsable de la estandarizacin de las funciones resumen MD5 ([134]) o y los algoritmos de cifrado CAST ([2] y [3]). Por su parte, el ITU (a travs e de su rama de estandarizacin, la ITU-T) ha liberado estndares tan ino a teresantes y extendidos como el estndar de clave pblica y certicado de a u atributos, X.509 ([72]), en la que se sientan las bases de las infraestructuras

Cap tulo 2. Estado de la Cuestin o

28

de clave pblica, al especicar el formato de los certicados de clave pblica u u ms extendido en la actualidad, y un algoritmo para la validacin de un a o certicado de clave pblica siguiendo la jerarqu de la infraestructura de u a clave pblica. u En cuanto a la estandarizacin de las herramientas de seguridad que o lleva a cabo el NIST, este proceso se encuadra en las labores de esta organizacin, como gestora de los Estndares Federales de Procesamiento de la o a Informacin (Federal Information Processing Standards, FIPS). Entre estos o documentos podemos encontrar las especicaciones de los requisitos para los mdulos criptogrcos ([111] y [114]), las especicaciones de generadores auo a tomticos de claves y contraseas ([110]), las especicaciones del algoritmo a n estndar de cifrado, AES ([113]) y las de la funcin resumen SHA ([116]). a o Finalmente, conviene destacar la existencia de gran cantidad de herramientas criptogrcas desarrolladas por la comunidad cient a ca, y que no han sido sometidas a procesos de estandarizacin por ningn organismo, coo u mo es el caso de RIPEMD y RIPEMD-160 ([50]) o el algoritmo de cifrado Blowsh ([138]), que pese a estar ampliamente aceptado y soportado por los sistemas de seguridad, al no estar respaldado por ninguna normativa ni organismo internacional ve cmo su uso queda prcticamente relegado al o a entorno acadmico. e

2.1.3.

Otras estandarizaciones

Adems de los ya mencionados procesos de estandarizacin de protocoa o los y arquitecturas de seguridad por un lado, y de herramientas criptogrcas a por otro, en los ultimos aos se han producido otras estandarizaciones por n parte de organismos de estandarizacin, dirigidos principalmente a entornos o industriales y de negocios, en lugar de a los mbitos cient a cos en los que encontramos los anteriores estudiados previamente. Por ejemplo, en esta l nea de estandarizacin nos encontramos con la o serie X.800 de la Unin Internacional de Telecomunicaciones, en la que se o abordan los problemas de seguridad y se ofrecen marcos de trabajo para la interconexin segura de sistemas abiertos (recomendacin X.810, [78]), o o o modelos de seguridad aplicados a diferentes niveles de la pila de protocolos, estudiando el impacto de diversos factores a los mecanismos de seguridad (recomendaciones X.802 ([77]) y X.803 ([76])). Estas recomendaciones de la ITU tienen su correspondiente estandarizacin por parte la Organizacin Internacional de Estndares (ISO), que ha o o a estandarizado el marco de trabajo para la interconexin segura en la norma o ISO/IEC 10181 ([42]), y los modelos de seguridad aplicados a ciertos niveles de la pila de comunicaciones en las normas ISO/IEC 10745 (capas superiores, [40]), ISO/IEC 13594 (capas inferiores, [38]) e ISO/IEC 111577 (capa de red, [39]).

29

2.2. Validacin y Seguridad o

Adicionalmente ISO cuenta con documentos adicionales en los que se estandarizan tcnicas y mecanismos de seguridad, siendo la norma mas exe tendida la ISO/IEC 11770 ([41]), en la que se propone un marco de trabajo y mecanismos de operacin para gestionar y operar claves criptogrcas, o a tanto simtricas como asimtricas. e e Por ultimo, merece la pena destacar la aportacin del ISO al estandari o zar las normas ISO/IEC 9646 y 13245 ([37], [36]), ya que en ellas se recogen los aspectos formales de los anlisis de conformidad para el anlisis de la a a interoperatividad entre sistemas abiertos, incluyendo una metodolog para a llevar a cabo dicho anlisis. Sin embargo, como se comentar en el apartado a a 2.2.4 donde se analiza el problema en detalle para los protocolos de seguridad, los anlisis de interconexin deben realizarse tanto desde un punto de a o vista formal del sistema o protocolo en cuestin (como el que proponen las o normas) como desde el punto de vista de la implementacin del sistema o o del protocolo.

2.2.

Validacin y Seguridad o

En esta seccin se revisarn las propuestas existentes en la comunidad o a cient ca en lo referente a mecanismos de validacin relacionados con la o seguridad. Como veremos a continuacin, por un lado nos encontramos con o la validacin de la implantacin de mecanismos y herramientas de seguridad o o en sistemas de informacin, validacin llevada a cabo durante el proceso de o o su desarrollo en el sistema. Tras revisar el estado de la cuestin de estos o mtodos de validacin, analizaremos dos de las ms recientes propuestas e o a por parte de organismos de estandarizacin, el Information Security in the o System Development Life Cycle y el Automated Security Functional Testing, ambos promovidos y desarrollados en el National Institute of Standards and Technology (NIST) estadounidense. Por otro lado, como un proceso posterior a la fase de desarrollo, ms a relacionado con el mantenimiento de los sistemas, surgen las gu de conas guracin de la seguridad, que llevan a cabo un anlisis del estado de los o a mecanismos y servicios de seguridad en el sistema. En esta misma l nea surgen los conjuntos de pruebas de seguridad (security benchmarks en la literatura inglesa), de los que tambin estudiaremos las tendencias ms ree a presentativas. En cuanto a la validacin de protocolos de seguridad, en el apartado o 2.2.4 analizaremos el papel de la validacin formal de protocolos y su relacin o o con la validacin que se propone en esta tesis doctoral. Asimismo, revisareo mos las contribuciones de la comunidad cient ca en cuanto a la validacin o de implementaciones de esos protocolos, analizando la situacin actual de o dichas propuestas.

Cap tulo 2. Estado de la Cuestin o

30

Por ultimo, revisaremos el papel de las metodolog de evaluacin de as o seguridad en el mbito de las comunicaciones seguras, centrndonos en las a a propuestas ms actuales. a

2.2.1.

Validacin de la seguridad en el desarrollo o

En el apartado de validacin de una solucin de comunicaciones seguo o ra, la literatura cient ca nos proporciona una gran cantidad de material relacionado con dos aspectos fundamentales: Validacin del desarrollo (normalmente software, aunque tambin pueo e den aplicarse a desarrollos hardware) Validacin y vericacin del protocolo de seguridad o o En cuanto a la validacin del desarrollo, podemos encontrar en la lio teratura con las metodolog tradicionales de evaluacin del software, cenas o tradas en asegurar un desarrollo correcto en las fases de especicacin de o requisitos (mediante la inclusin de requisitos de seguridad), diseo, e imo n plementacin ([18]). Los ejemplos ms conocidos de estas tcnicas son los o a e que se encuentran integrados en las propias metodolog de desarrollo y en as los mtodos formales de desarrollo, como puede verse en [18], [129], [16] y e [55]. Estas tcnicas tienen por objeto minimizar los errores durante el proe ceso de desarrollo de tal forma que los resultados se ajusten a los requisitos planteados en las primeras fases del propio desarrollo. Sin embargo, debido a la fuerte dependencia del diseador en esa especicacin de requisitos, es pon o sible que los requisitos se interpreten errneamente o que sean incompletos, o sin que este problema sea detectado por las actuales tcnicas de desarroe llo seguro. En algunos casos, esta ambigedad se ha traducido en que las u propias medidas de seguridad se vuelvan contra nosotros, como se comenta en [108], donde mltiples casos en los que herramientas de seguridad tales u como cortafuegos, detectores de intrusos o cifradores de datos han impedido el desarrollo normal de la actividad que deb proteger. Por lo tanto, es an perfectamente posible que un desarrollo hardware o software que haya pasado por las metodolog tradicionales pueda no ser conforme al estndar, as a y por lo tanto, presentar problemas al establecer una conexin segura con o una implementacin diferente. o Otras propuestas en esta misma l nea que se se aproximan al tema de tesis propuesto son las metodolog de evaluacin del software, tales como as o la System Security Engineering Capability Maturity Model (SSE-CMM, [66], [67], [75]), o los Common Criteria (CC, [121], [122], [123]), que ha sustituido tanto a Trusted Computer System Evaluation Criteria (TCSEC, [119]) como a Information Technology Security Evaluation Criteria (ITSEC, [125]).

31

2.2. Validacin y Seguridad o

Todas estas metodolog evalan de una forma u otra la seguridad de un as u desarrollo (normalmente software) en un entorno concreto, midiendo el nivel de conformidad con unos requisitos denidos en la metodolog en cuestin. a o En los ultimos aos han surgido nuevos enfoques para la validacin n o espec ca de sistemas y herramientas de seguridad que s tienen en cuenta los requisitos, bien especicados como estndares o como pruebas formales a que el diseo debe superar. Sin embargo, podemos ver que la gran mayor n a de la literatura realiza pruebas de caja blanca para validar el sistema ([93], [17], [149], [62], [98], [35]). Desgraciadamente, este tipo de pruebas no ayuda a analizar el funcionamiento del sistema tal y como lo ven otros sistemas (es decir, como una caja negra), y, dado que estamos hablando de sistemas cuyo objetivo es conectarse a otros, es razonable establecer un conjunto de pruebas de caja negra para evaluar el nivel de cumplimiento de los requisitos. 2.2.1.1. Information Security in the System Development Life Cycle

El proyecto Information Security in the System Development Life Cycle (IS SDLC) del NIST estadounidense est enfocado a identicar, analizar y a revisar el papel de la seguridad en el ciclo de vida de los sistemas de informacin, utilizando para ello modelos existentes en los que se identicarn o a los requisitos y caracter sticas de seguridad necesarias. Aunque el proyecto no ha producido ninguna documentacin pblica, si o u se puede acceder a los objetivos generales y a la descripcin del enfoque que o se utilizar en este proyecto. Dicho enfoque consiste en identicar las fases a comunes a los diferentes ciclos de vida de los sistemas de informacin, para o analizar cules de las tareas que se llevan a cabo en cada una de ellas tiene a relacin con la seguridad, de forma que sea posible identicar las necesidades o y objetivos de seguridad que deben ser satisfechos. Aspectos clave de este proyecto son la identicacin de los servicios de seguridad requeridos en o cada fase, as como la evaluacin de la necesidad de dichos servicios en o relacin con el papel del sistema de informacin dentro de la organizacin o o o que har uso de l. Tambin es un aspecto importante la identicacin de a e e o los diferentes aspectos regulatorios y normativos que afectan a la forma en que dichos servicios de seguridad se ofrecen, as como la identicacin de o las amenazas a las que deber hacer frente el sistema. Todos estos aspectos a sern analizados y el proceso de anlisis y evaluacin de estos servicios de a a o seguridad en particular, y de los objetivos y necesidades a los que hac amos referencia en general, ser integrado en las diferentes fases del ciclo de vida a del sistema de informacin. o Como podemos ver, este proyecto se encuentra en la l nea de las metodolog de evaluacin del software mencionadas en el apartado 2.2.1, en las as o que el proceso se centraba unicamente en la fase de desarrollo dentro del ciclo

Cap tulo 2. Estado de la Cuestin o

32

de vida. Aunque este proyecto abarca todo el ciclo de vida, la visin general o es la misma que la de las metodolog ITSEC, TCSEC y los Common as Criteria, abstrayndose de la implementacin concreta de cada mecanismo e o de seguridad, y centrndose en el tratamiento que se le dan a esas necesidades a dentro de la planicacin del ciclo de vida del sistema de informacin. Un o o enfoque similar al de este proyecto es el que se lleva a cabo en la Operationally Critical Threat, Asset, and Vulnerability EvaluationSM (OCTAVESM , [4]), desarrollada por el Instituto de Ingenier del Software de la Carnegie Mellon a University, en Estados Unidos. 2.2.1.2. Automated Security Functional Testing

Por su parte, el proyecto Automated Security Functional Testing (ASFT), tambin llevado a cabo en el NIST, tiene por objetivo el desarrollo formal e de un modelo de especicaciones del comportamiento de las funciones de seguridad que sirva de base para automatizar el proceso de evaluacin de o dichas funciones, incluyendo la generacin de vectores de prueba, generacin o o de cdigo de prueba y anlisis de los resultados. o a Entre los productos que han surgido de este proyecto se encuentra el marco de trabajo de automatizacin de pruebas (Test Automation Frameo work ), que ayuda a automatizar el proceso de evaluacin de un sistema al o proporcionar herramientas que permiten disear modelos funcionales, anan lizar dichos modelos, generar cdigo que evale dicho modelo y llevar a cao u bo las pruebas generadas, analizando posteriormente el resultado de dichas pruebas. Sobre este marco de trabajo, la herramienta TAF-SFT permite llevar a cabo el mismo proceso centrndose en las funciones de seguridad del a sistema. Como podemos observar, este proyecto lleva a cabo un doble anlisis a de la seguridad en el sistema evaluado: Por un lado, lleva a cabo un anlisis formal sobre la funcionalidad a que se pretende obtener, validando su correcto diseo y el comportan miento previsto para el sistema al utilizar dicha funcin. o Por otro lado, estudia el comportamiento de la implementacin, al o evaluar con el cdigo generado las funcionalidades que aparecen en el o modelo del sistema. Sin embargo, tal y como ocurre con otras propuestas ya mencionadas anteriormente, para llevar a cabo los anlisis hacia los que est enfocado a a este proyecto es necesario conocer detalladamente el funcionamiento interno del sistema de informacin. Esto convierte los anlisis en pruebas de caja o a blanca, lo que no permite evaluar de forma able la funcionalidad resultante de cara a una entidad externa al sistema.

33

2.2. Validacin y Seguridad o

2.2.2.

Gu de conguracin de la seguridad as o

A partir de la validacin durante el proceso de desarrollo, surgi la o o necesidad de evaluar la seguridad de los sistemas de informacin durante el o periodo operativo de dicho sistema, de forma que los anlisis que se llevaron a a cabo durante el proceso de desarrollo se complementen con el estudio de la seguridad del sistema una vez desplegado en el entorno en el que debe realizar su funcin. o Durante el proceso de despliegue del sistema de informacin los anlisis o a toman la forma de gu de conguracin segura de los diferentes sistemas, as o permitiendo evaluar si todos los pasos necesarios para que la seguridad del sistema no se vea comprometida por defectos en los procesos de instalacin o y conguracin. Algunas de las listas de conguracin ms utilizadas en la o o a actualidad tienen un carcter artesanal en la mayor de las casos, como a a puede ser el caso de [27] y [28]. Sin embargo, en este apartado revisaremos algunas de las gu de conguracin de la seguridad ms representativas as o a en la actualidad, que cuentan con un respaldo mayoritario por parte de la comunidad internacional y que cuentan con mayor grado de formalidad que las gu anteriormente citadas. as

2.2.2.1. NSA

Gu de conguracin de la seguridad as o

La Agencia Nacional para la Seguridad estadounidense (NSA) publica gu as de conguracin de la seguridad en mltiples dispositivos de red y sistemas o u operativos, con gu especializadas en tecnolog que, bien por su popuas as laridad, bien por problemas detectados por su diseo, pueden ser origen n de graves problemas de seguridad tanto para particulares como para compa en las que se instalen dichos sistemas. Dichas gu son puestas a nas as disposicin del pblico, y pueden ser consultadas y descargadas desde [118], o u encontrndose en la actualidad gu para la conguracin segura de sistea as o mas operativos, aplicaciones, servidores de bases de datos, encaminadores, conmutadores, arquitecturas de Voz sobre IP, servidores y navegadores web, y redes inalmbricas 802.11. a Adicionalmente, dentro de este conjunto de gu de conguracin tamas o bin se encuentran documentos que discuten la situacin de algunas tece o nolog de seguridad en entornos concretos, o la forma de aplicar todo el as conjunto de mecanismos y herramientas de seguridad de manera que maximice la seguridad de nuestro sistema de informacin. Ejemplos de estas gu o as son las recomendaciones para implantar la seguridad en profundidad, las recomendaciones a la hora de redactar informes de seguridad o de vulnerabilidades, y discusiones acerca del papel de los diferentes tipos de cortafuegos

Cap tulo 2. Estado de la Cuestin o en las redes corporativas.

34

Estas gu de conguracin ofrecen una detallada recopilacin de taas o o reas y comprobaciones a llevar a cabo para validar la correcta conguracin o de la seguridad en el sistema, servicio o dispositivo que se evala, junto u con los procedimientos para corregir posibles errores en dicha conguracin. o Estas recopilaciones se acompaan de una discusin sobre el problema de n o seguridad al que se est haciendo frente, junto con referencias a bibliograf a a y documentacin adicional con la que profundizar en el tema que se discute. o Por lo tanto, el papel que juegan estas gu de conguracin es el de as o servir de base para un proceso manual de vericacin de la seguridad en un o sistema de informacin una vez ste ha sido implementado y se encuentra, o e bien en funcionamiento, bien dispuesto a pasar a modo operativo en breve. Estas gu llevan a cabo un anlisis de la seguridad del sistema centrndose as a a en aspectos de la conguracin que ayuden a proporcionar el mximo nivel de o a seguridad mientras se ofrece el servicio al que dicho sistema est destinado. a

CIS Por su parte, el Centro para la Seguridad de Internet (Center for Internet Security, CIS), ofrece tambin gu de conguracin de seguridad, a las e as o que acompaa con un sistema de calicacin y evaluacin, de forma que sea n o o posible evaluar y comparar el nivel de seguridad de dos sistemas de informacin diferentes. Aunque en un nmero menor que las gu de la NSA, o u as las gu publicadas por el CIS cuentan con un documento parejo en el que as se muestran el proceso de evaluacin llevado a cabo con varios productos, o comerciales o no, en el que se disea una arquitectura de pruebas, y se llevan n a cabo evaluaciones sobre aspectos muy concretos de la conguracin de los o dispositivos. Como resultado nal, se obtiene una valoracin global de los o diferentes dispositivos o versiones de los sistemas, con la que es posible el nivel de adecuacin a unas necesidades determinadas. o Otro aspecto importante de estos conjuntos de pruebas es que desde su concepcin inicial denen al menos dos niveles de seguridad y estudian el o impacto de cada uno de los aspectos analizados en cada gu de conguracin a o para cada uno de los niveles de seguridad denidos, lo que permite considerar la importancia de cada aspecto de la conguracin que se revisa en la gu o a de forma relativa al nivel de seguridad objetivo para el sistema. Adicionalmente los conjuntos de pruebas del CIS se complementan con herramientas de evaluacin ms o menos automatizadas (como por ejemplo, o a las conguraciones pre-generadas para utilizar con bastille-linux ([14]), como medio de congurar un sistema con un determinado nivel de seguridad de forma automatizada, o la especicacin de las pruebas a llevar a cabo en o lenguaje XCCDF (del que se hablar con mayor detenimiento en el apartado a

35

2.2. Validacin y Seguridad o

2.2.3.1), lo que permite su utilizacin por parte de cualquier herramienta con o soporte para dicho lenguaje. Como podemos ver, en el caso del CIS las gu de conguracin no se as o limitan unicamente a una recopilacin de aspectos que deben ser tenidos en o cuenta a la hora de congurar un sistema de informacin, sino que se incluyen o herramientas y mecanismos para automatizar el anlisis y conguracin de a o esos aspectos, permitiendo as una mayor eciencia a la hora de llevar a cabo estos procedimientos en un nmero elevado de sistemas. u

2.2.3.

Conjuntos de pruebas de seguridad

La evolucin lgica de las gu de conguracin nos lleva a la automao o as o tizacin del proceso de evaluacin y pruebas de un sistema de informacin, o o o en el que el sistema se evala automticamente, de forma local o remota, u a segn el tipo de anlisis que se desee llevar a cabo, comprobando por un u a lado si la conguracin utilizada en la actualidad puede ser utilizada por un o potencial atacante para quebrantar la seguridad del sistema, y por otro lado para comprobar si ataques, vulnerabilidades y vectores de ataque que hayan aparecido desde la puesta en funcionamiento del sistema de informacin tieo nen efecto en el mismo. Este tipo de anlisis de caja negra es muy utilizado a en la actualidad para llevar a cabo pruebas de penetracin en sistemas de o informacin, ya que los resultados que ofrecen se reeren a los sistemas como o cajas negras, tal y como reaccionan a mensajes y eventos de otros sistemas. En este mbito de la automatizacin de las pruebas de seguridad poa o demos encontrarnos en la actualidad tres l neas de trabajo diferentes pero complementarias: La primera de ella, apoyada sobre todo desde las organizaciones encargadas de la estandarizacin de mtodos y procedimientos, o e lleva a cabo trabajos para disear medios y herramientas que permitan el n intercambio de la informacin relativa a estas pruebas independientemente o de la plataforma y sistema de pruebas que se utilice; por otro lado, el desarrollo de herramientas automatizadas de evaluacin de la seguridad de los o sistemas de informacin, especialmente de aquellos que ofrecen servicios en o red, es otro rea en la que se estn llevando a cabo importantes avances en a a los ultimos aos; por ultimo, la investigacin en el rea de la auto-evaluacin n o a o de la seguridad por parte de los sistemas de informacin es otro aspecto en o el que se estn llevando a cabo importantes avances en los ultimos aos. a n A continuacin se revisarn las ms importantes contribuciones de estos o a a ultimos aos en cada una de las tres l n neas de trabajo. 2.2.3.1. Extensible Conguration Checklist Description Format

El lenguaje extensible de denicin de listas de conguracin (Extensible o o Conguration Checklist Description Format, XCCDF, [157]) es un lenguaje

Cap tulo 2. Estado de la Cuestin o

36

descriptivo diseado para la denicin de listas de seguridad como las desn o critas en el apartado 2.2.2.1, conjuntos de pruebas automatizados (como los que se estudiarn en el siguiente apartado) y otros documentos relacionados a (tales como gu de usuario o manuales). El desarrollo de XCCDF depenas de del NIST estadounidense, aunque otras agencias gubernamentales (como la Agencia Nacional de Seguridad) se encuentran tambin involucradas en e dicho proceso. Este lenguaje se basa en tecnolog existentes y extendidas como XML as para representar colecciones estructuradas de reglas de conguracin pao ra la evaluacin de la seguridad en determinados sistemas de informacin. o o Este lenguaje permite y facilita el intercambio de informacin entre sisteo mas de evaluacin automatizados, as como la interpretacin de documentos o o generados y la modicacin de las especicaciones para dar soporte a neo cesidades particulares. De esta forma se pretende proporcionar unas bases uniformes sobre las que denir pruebas y evaluaciones de seguridad particulares, as como conjuntos de pruebas ms extensos y complejos, y por ello a la actual especicacin dene un modelo para almacenar los resultados de o pruebas de conformidad obtenidos a partir de herramientas automatizadas. Los objetivos que se plantean para este lenguaje en particular, y para esta l nea de investigacin en general son, principalmente, los siguientes: o Proporcionar los mecanismos para denir reglas y conguraciones de seguridad de forma eciente y gil. a Permitir la interoperabilidad de diferentes herramientas, libres y comerciales, en cuanto a lo que la denicin de reglas y conguraciones o se reere. Facilitar la validacin de un conjunto de reglas y conguraciones contra o una base de datos de pol ticas (que pueden venir dadas por requisitos formales, legales o de otra naturaleza). Habilitar la comparacin de diferentes herramientas de evaluacin de o o la seguridad, as como de los resultados obtenidos por dichas herra mientas. 2.2.3.2. Herramientas automatizadas de evaluacin de la segurio dad

Como una segunda l nea de investigacin en el mbito de los conjuntos o a de pruebas de seguridad se presentan las herramientas automatizadas para la evaluacin de la seguridad. Estas herramientas llevan a cabo un conjunto o de pruebas que evalan aspectos concretos de la seguridad del sistema que u evalan, generando nalmente un informe en el que se recogen los resultados u de las pruebas llevadas a cabo y otra informacin util (como por ejemplo, o

37

2.2. Validacin y Seguridad o

referencias a los problemas de seguridad que se hayan podido detectar, como informes de vulnerabilidades o la base de conocimiento del fabricante del sistema). Aunque estas herramientas (sobre todo las que llevan a cabo evaluaciones de la seguridad de los servicios de comunicaciones) se han utilizado tradicionalmente en el mbito de los atacantes para obtener informacin a o acerca de posibles vectores de ataque a un sistema de informacin, su uso o no est restringido a las actividades de ataque, sino que su utilizacin coa o mo herramienta de deteccin de vulnerabilidades est muy extendida tanto o a entre responsables de los sistemas como entre los profesionales del sector. Entre las aplicaciones ms representativas en la actualidad de estas hea rramientas de evaluacin de la seguridad podemos encontrar Nessus y Sara, o ambos derivados de la Security Administrators Tool for Analyzing Networks (SATAN), desarrollado en 1.995. Mientras que Sara ([147]) se centra en la realizacin de pruebas que no daen el sistema evaluado (por lo que no ino n cluye ninguna prueba de denegacin de servicio) con el n de que las pruebas o puedan realizarse sobre sistemas operativos sin el riesgo de interrumpir el servicio, Nessus ([139]) por su parte centra su potencial en su mayor base de datos de ataques y vulnerabilidades, por lo que es capaz de llevar a cabo un anlisis ms completo de los sistemas evaluados. a a La otra gran diferencia fundamental entre ambas herramientas es la forma en la que la informacin sobre las vulnerabilidades es almacenada o e incorporada a la aplicacin: mientras que Sara utiliza la base de datos o de vulnerabilidades mantenida por el NIST ([117]), siendo compatible con el formato CVE de los informes de cha base de datos, Nessus utiliza un lenguaje propio denominado NASL (Nessus Attack Scripting Language) en el que se codican todos los parmetros de cada vulnerabilidad que debe ser a evaluada. El modo de funcionamiento de ambas herramientas es muy similar, utilizando una arquitectura de red como la que se puede ver en la Figura 2.6, en la que un sistema en el que se ejecuta la herramienta de evaluacin de o la seguridad lleva a cabo pruebas de seguridad, remotas si se llevan a cabo en otros sistemas, y locales si se llevan a cabo en el propio sistema. Las pruebas se llevan a cabo siguiendo las pol ticas de temporizacin y paralelizacin o o que se hayan denido, y al nalizar el proceso de evaluacin se obtiene un o informe de resultados. En la actualidad, uno de los mayores problemas que tienen estas herramientas es la gran cantidad de falsos positivos que generan, debido principalmente a la falta de rigor formal en la realizacin de las pruebas, lo que o lleva a la interpretacin de toda aquella respuesta imprevista como un error o del sistema, lo que se asocia a la vulnerabilidad que se lleva a cabo en el momento en que se recibe la respuesta.

Cap tulo 2. Estado de la Cuestin o

38

Figura 2.6: Modelo de utilizacin de herramientas automatizadas. Su instao lacin en un equipo permite analizar otros equipos de la misma red (anlisis o a interno), o incluso de otras redes (anlisis externo) a

2.2.3.3.

Automated Security Self-Evaluation Tool

La ultima l nea de investigacin que se analizar en el rea de los cono a a juntos de pruebas de seguridad es la de la auto-evaluacin por parte de o los sistemas de informacin acerca de sus propias vulnerabilidades y proo blemas de seguridad, en lugar de depender de sistemas externos que lo evalen. El proyecto ms representativo en ste mbito es la Herramienu a e a ta de Auto-Evaluacin de Seguridad Automatizada (Automated Security o Self-Evaluation Tool, ASSET, [115]), desarrollado por el NIST como consecuencia de la publicacin del informe especial de seguridad 800-26 ([143]), o en el que se proporcionan las l neas generales que deben regir los procesos de auto-anlisis por parte de los sistemas de informacin. a o En la actualidad el proyecto no se encuentra nalizado, por lo que uni camente es posible llevar a cabo la evaluacin de un sistema de informacin o o a partir de cuestionarios realizados a los usuarios del sistema, que, junto con las reglas y pol ticas que denen los diferentes niveles y requisitos de seguridad, sirven para obtener los resultados de la evaluacin de la seguridad del o propio sistema de informacin. o

39

2.2. Validacin y Seguridad o

2.2.4.

Validacin de protocolos de seguridad o

Por lo que respecta a la evaluacin de los protocolos de seguridad, en o la actualidad podemos encontrar en la literatura cient ca dos enfoques diferentes, cada uno de ellos centrado en un aspecto diferente del protocolo de seguridad. El primero de estos enfoques se centra en el anlisis del protoa colo en s mismo, estudiando el ujo de informacin entre las entidades, el o intercambio de mensajes, las propiedades criptogrcas de las herramientas a utilizadas, etc. . . ., todo ello desde un punto de vista formal y terico, sin o analizar las implementaciones de ese protocolo. El segundo enfoque se centra en el anlisis de las implementaciones de los protocolos de seguridad, y es a un enfoque eminentemente prctico, que no intenta averiguar si el protocoa lo utilizado es seguro o no, sino que analiza cmo se ha implementado esa o denicin terica del protocolo. o o Cada uno de estos enfoques ha sido analizado y estudiado por cient cos de todo el mundo, realizndose grandes avances tanto en uno como en otro a sentido. Por este motivo se proceder a analizar el estado de la cuestin de a o cada uno de estos enfoques utilizando como gu un proyecto representativo a de cada uno de ellos: el proyecto AVISPA para la validacin formal de proo tocolos y el proyecto IPsec-WIT como representante de la validacin de o las implementaciones.

2.2.4.1.

Validacin formal del protocolo: Proyecto AVISPA o

En lo tocante a la validacin formal del protocolo, abundan hoy en d o a trabajos que hacen uso de estas herramientas (ya sean lgicas formales ([24]), o modelos simblicos ([22]), modelos de razonamiento ([74]), conjuntos de evio dencias formales de la seguridad ([109]) o nuevos sistemas de vericacin o ([128])). Sin embargo, todas estas tcnicas estn orientadas a la validacin e a o del protocolo en s mismo, mientras que lo que en esta tesis se desarro llar ser un sistema para evaluar la implementacin del protocolo de a a o seguridad. Un ejemplo de este tipo de validaciones lo podemos encontrar en el proyecto AVISPA. El proyecto AVISPA (Automated Validation of Internet Security Protocols and Applications) es un proyecto englobado en el V Programa Marco de la Unin Europea, dentro del programa de Tecnolog Emergentes y o as Futuras. Su mbito de trabajo es la validacin de los protocolos y aplicaa o ciones de seguridad utilizados en Internet mediante un enfoque formal, de forma que los vectores de ataque y las posibles vulnerabilidades puedan ser detectados antes de que ese protocolo defectuoso haya sido implementado y puesto a funcionar en un entorno de produccin. Para conseguir estos objeo tivos el proyecto AVISPA desarroll nuevos lenguajes de alto nivel con los o que es posible expresar las especicaciones de los protocolos de seguridad

Cap tulo 2. Estado de la Cuestin o

40

(favoreciendo la transicin desde el lenguaje formal utilizado en el estndar o a a otro lenguaje que pueda ser procesado automticamente) que facilitaban a el posterior anlisis y evaluacin. a o Este proyecto se centraba en el anlisis de los protocolos y las aplicaa ciones en s mismos (es decir, del diseo del protocolo o de la aplicacin), n o proporcionando como resultado informacin acerca de la bondad del diseo o n del protocolo o de la aplicacin. El anlisis llevado a cabo se basa en un o a conjunto de pruebas que tienen su origen en ataques existentes o vulnerabilidades conocidas de otros protocolos y aplicaciones de seguridad, a los cuales es sometido el protocolo o aplicacin que se desea estudiar. En la o medida en que estos tests requieren del acceso a los mecanismos internos de la aplicacin o del protocolo para funcionar, es sensato calicar los mismos o como pruebas de caja blanca. El interfaz de usuario del proyecto AVISPA est basado en tecnolog a as web, tanto para el diseo de nuevos conjuntos de pruebas como para la evan luacin de protocolos y aplicaciones. Las posibilidades que ofrece el interfaz o van desde la edicin de protocolos y las pruebas, hasta la revisin de los o o resultados de pruebas llevadas a cabo anteriormente. Estos resultados constan, por un lado, de los resultados de las pruebas en s mismos, y por otro, de los recursos que han sido necesarios para llevar a cabo las pruebas. Aunque el enfoque utilizado en el proyecto AVISPA es importante para la validacin de los protocolos de seguridad, sus resultados slo afectan o o al diseo del protocolo, sin que la implementacin que se hace de ese din o seo sea analizada en ningn momento. Esto quiere decir, entre otras cosas, n u que este tipo de anlisis no puede proporcionar informacin acerca de la a o interconectividad entre las diferentes implementaciones. 2.2.4.2. Validacin de la implementacin: Proyecto IPsec-WIT o o

El otro enfoque principal que encontramos hoy en d en lo tocante a a la validacin de protocolos de seguridad se centra en el anlisis de las o a implementaciones de los protocolos en lugar de analizar los protocolos, de forma que la informacin que se obtiene hace referencia a cmo se comporta o o la implementacin frente a otros dispositivos y sistemas. Como podemos o ver, el anlisis que se lleva a cabo es totalmente diferente que en el caso a anterior, ya que la informacin que se busca obtener se encuentra en un plano o diferente al anterior. Como proyecto que ejemplica las caracter sticas de este enfoque se ha seleccionado el proyecto IPsec-WIT, del National Institute of Standards and Technology estadounidense. IPsec-WIT ([120]) es un proyecto llevado a cabo por el NIST estadounidense a partir de una peticin del IETF solicitando sistemas que llevasen a o cabo pruebas de interoperabilidad para IPsec. Cuando el IETF constat los o problemas que empezaban a surgir concernientes a la interoperabilidad de

41

2.2. Validacin y Seguridad o

las implementaciones de protocolos de seguridad lanz esta solicitud para o que se diseasen e implementasen conjuntos de pruebas de interoperabilin dad. IPsec-WIT (que quiere decir IPsec Web Interoperability Test) fue una de las propuestas que surgieron a partir de esa llamada, y ten como objea tivo el ser una herramienta de referencia con un interfaz web que probase la conformidad de una implementacin con los estndares de IPsec. o a IPsec-WIT se basaba en la implementacin de referencia del NIST de los o protocolos que componen IPsec (llamadas PlutoPLus y Cerberus), y ofrec a la posibilidad de probar la conformidad de las diferentes suites criptogra cas para cada protocolo de IPsec, as como la ejecucin del protocolo y la o negociacin de los diferentes parmetros en las diferentes fases del establecio a miento de las asociaciones de seguridad. Todas estas pruebas se conguraban y arrancaban a travs de un interfaz web que el NIST ofrec en su servidor. e a Este proyecto tuvo que hacer frente a varios problemas que hacen inviable su utilizacin en la actualidad. En primer lugar, las pruebas que se o llevaban a cabo requer de un gran nivel de reconguracin (y por lo tanto, an o de intervencin por parte del usuario/administrador) en el proceso, conviro tindose sta en una tara muy tediosa para las personas que deb llevarla e e an a cabo (personas que en la mayor de los casos deb decidir si las pruebas a an se llevaban a cabo o no). Adicionalmente, el proyecto ha sido interrumpido y no se trabaja ms en l, y debido a que la plataforma utilizada no se ha hea e cho pblica (tests, implementaciones de los protocolos de IPsec, etc. . . .) no u es posible tratar de dar continuidad al proyecto. Por ultimo, los resultados obtenidos por la plataforma informaban acerca de la implementacin que o hab sido probada de forma aislada, sin proporcionar informacin acerca a o de las posibilidades de interconexin con otros dispositivos o soluciones que o podamos encontrar. IPsec-WIT fue el primer2 proyecto importante en abordar el problema de la interconectividad entre las diferentes implementaciones de los protocolos de seguridad, centrndose en las implementaciones de IPsec. En su cona tra, es importante destacar que carec de algunas caracter a sticas de anlisis a y facilidad de uso que son necesarias actualmente, especialmente cuando las tareas a llevar a cabo requieren de un prolongado espacio de tiempo. Sin embargo, su gran contribucin (adems de ser el primer proyecto en abordar el o a problema) probablemente sea el proporcionar un interfaz web desde el que gestionar el conjunto de pruebas, ya que de esta forma se est utilizando a un soporte que la gran mayor de los dispositivos actuales son capaces de a gestionar.
De hecho, la unica referencia a otro trabajo similar en cualquiera de los cuerpos estandarizacin, en el que el objeto de evaluacin sea la implementacin del protocolo o o o seguridad en s misma, y no el protocolo que se implementa, es un borrador de RFC caducado, en el que se establec los criterios para la evaluacin de implementaciones an o Redes Privadas Virtuales ([155])
2

de de ya de

Cap tulo 2. Estado de la Cuestin o

42

Como podemos ver, este enfoque complementa al anterior, en tanto que uno se preocupa de la seguridad del protocolo, llevando a cabo estudios tericos sobre el mismo, mientras que el otro concentra sus esfuerzos en o analizar cmo se ha trasladado esa denicin terica de un intercambio de o o o informacin con ciertas propiedades que coneren seguridad a dicho intero cambio a un dispositivo, sistema o software determinado. Ambos enfoques son necesarios para garantizar en la medida de lo posible la seguridad del sistema,

2.2.5.

Metodolog de evaluacin de la seguridad de sisteas o mas de informacin o

Una vez llevada a cabo la revisin del estado de la cuestin en aspectos o o concretos de la validacin y evaluacin de la seguridad, cabe preguntarnos o o por la existencia de metodolog que lleven a cabo una validacin de los as o mecanismos de seguridad integrados en los sistemas de informacin. Aco tualmente podemos encontrar mltiples metodolog que llevan a cabo una u as evaluacin de la seguridad en un sistema de informacin; sin embargo, nos o o encontramos con que la mayor de estas propuestas resultan ser mtodos (es a e decir, conjuntos de pasos a seguir) y no metodolog ya que sus propuestas as, se centran en la especicacin de pasos concretos a seguir para obtener ino formacin concreta con la que elaborar un informe nal (como es el caso de o la Open Source Security Testing Methodology, desarrollada por el ISECOM (Institute for Security and Open Methodologies), y que puede encontrarse en [68]. La unica propuesta actualmente vigente en la que realmente se propo ne una metodolog para llevar a cabo una evaluacin de la seguridad de a o los sistemas de informacin es la Metodolog de Revisin de la Seguridad o a o (Security Review Methodology) desarrollada por la Agencia de Sistemas de Informacin para la Defensa (Defense Information Systems Agency, CISA), o del gobierno estadounidense ([127]), y que pasaremos a estudiar con mayor detalle a continuacin. o 2.2.5.1. Metodolog de Revisin de la Seguridad a o

Esta metodolog describe el proceso de evaluacin de sistemas de ina o formacin (en concreto, aplicaciones software) en cuanto a su seguridad, con o el n de determinar que el sistema analizado: 1. No introducir problemas de seguridad en la red en la que se instale a 2. No requiere que se relajen las medidas de seguridad existentes para que pueda operar

43

2.2. Validacin y Seguridad o

Para poder llevar a cabo esta evaluacin en la metodolog se describen o a siete fases (inicio, documentacin, conguracin bsica preliminar, instalao o a cin y conguracin, pruebas de seguridad, pruebas funcionales, resultados) o o en las que dividir el proceso de evaluacin, aunque la propia metodolog ado a mite que es posible alterar el orden o incluso omitir algunas de las fases si no se est interesado en la informacin que se obtiene de dicha fase. Asimismo, a o se denen dos niveles de evaluacin diferentes: aquel en el que la evaluacin o o se lleva a cabo sobre las especicaciones del producto, y aquella en la que la evaluacin se centra en la identicacin de problemas de seguridad que o o surjan del uso del sistema evaluado. Para cada una de las diferentes fases en las que se divide el proceso, la metodolog proporciona los objetivos a alcanzar en dicha fase, junto con las a diferentes pautas de desarrollo de la fase de acuerdo al nivel de evaluacin o que se lleve a cabo. Adicionalmente, para cada elemento de decisin, proo cedimiento, o mecanismo que deba llevarse a cabo o utilizarse se describen situaciones comunes y recomendaciones acerca de cmo deben ser resueltas. o Estas situaciones van desde aspectos tcnicos (en qu sistema operativo se e e instalar el producto a probar) hasta legales (el responsable de la evaa luacin rmar los acuerdos de condencialidad establecidos en las normas o a reguladoras). El proceso completo de evaluacin, tal y como se describe en la metoo dolog consta de los siguientes pasos: a, 1. Inicio a) Determinacin del tipo y alcance de la evaluacin o o b) Obtencin de los recursos humanos y tcnicos necesarios o e c) Firma de documentos legales y acuerdos de condencialidad d ) Creacin del soporte de datos necesario para la evaluacin o o 2. Documentacin o a) Determinacin del nivel de seguridad del producto segn Como u mon Criteria b) Lectura de la documentacin del producto o c) Bsqueda de vulnerabilidades del producto en Internet u d ) Instalacin en un sistema de pruebas para familiarizarse con el o producto e) Documentacin de los resultados preliminares o 3. Conguracin Bsica Preliminar o a

Cap tulo 2. Estado de la Cuestin o a) Desplegar una plataforma conforme a STIG3

44

b) Anlisis de la seguridad del sistema tras la instalacin de la plaa o taforma 4. Instalacin y Conguracin o o 5. Pruebas de Seguridad a) Realizacin de las pruebas de seguridad de la aplicacin o o b) Comparacin de las conguraciones iniciales y nales o c) Anlisis de la seguridad del sistema tras la instalacin y congua o racin de la aplicacin o o 6. Pruebas Funcionales a) Desarrollo de las pruebas funcionales b) Ejecucin de las pruebas funcionales o 7. Resultados a) Generacin de los informes de resultados o b) Revisin de la calidad de la evaluacin o o c) Generacin y diseminacin del informe nal de la evaluacin o o o d ) Liberacin del equipamiento y personal o Como podemos observar, el objetivo de la metodolog no es describir a los pasos individuales necesarios para llevar a cabo una evaluacin de un o producto determinado, sino que desgrana el proceso de evaluacin genrico o e para cualquier sistema que deba evaluarse, dejando al evaluador la libertad suciente para que pueda adaptarse convenientemente al producto evaluado, e incluyendo los necesarios controles de calidad para asegurarse de que la evaluacin se lleva a cabo de acuerdo a las pautas establecidas por pol o ticas internas a la organizacin. o

2.3.

Evaluacin del rendimiento o

Al estudiar las soluciones para evaluar el rendimiento de un sistema de comunicaciones seguro, podemos encontrar varias metodolog de evaluaas cin del rendimiento de sistemas de comunicaciones, tales como [53] (dono de se proponen mtodos para desarrollar entornos de pruebas adaptados a e
Una plataforma conforme a STIG es aquella en la que todos los sistemas presentes en dicha plataforma han sido instalados conforme a las gu tcnicas de conguracin de la as e o seguridad (STIGs) de la Agencia de Sistemas de Informacin para la Defensa, el mismo o organismo que desarrolla esta metodolog a
3

45

2.3. Evaluacin del rendimiento o

nuestras necesidades particulares), [51] (en la que se utilizan pares clienteservidor para llevar a cabo las mediciones) o [23] (donde se exponen mtodos e para utilizar entornos de pruebas personalizados y comparar los resultados con otros bancos de pruebas). Sin embargo, el denominador comn de esu tas metodolog es que no estn pensadas para ser utilizadas en sistemas as a de comunicaciones que incluyan la seguridad en sus caracter sticas. Como hemos visto anteriormente, la alta variabilidad que presentan los resultados de rendimiento al llevar a cabo operaciones criptogrcas hacen que la exa trapolacin de datos no sea recomendable, lo que convierte algunas de las o propuestas en inviables. El otro gran problema que se presenta con las metodolog tradicionales as de evaluacin del rendimiento es que, dado que el mero establecimiento de o una conexin sin seguridad no supone una sobrecarga importante para el o servidor, el impacto que el volumen de conexiones simultneas tiene en el a rendimiento del sistema no se evala, pese a la importancia de este factor u en las comunicaciones seguras. Alrededor del establecimiento de la conexin o existen una conjunto de parmetros que es importante conocer para obtener a informacin relevante acerca del rendimiento. o El problema de que estas metodolog estn pensadas para sistemas as a de comunicaciones que no incluyen la seguridad en sus caracter sticas hace que en las ocasiones en las que se intentan utilizar estas metodolog en as sistemas con seguridad, los resultados carezcan del rigor cient co necesario. Por ejemplo, al intentar medir la sobrecarga que introduce la securizacin o del canal de comunicaciones con respecto al canal de comunicaciones no seguro, es comn realizar un nmero m u u nimo de medidas y de ah extrapolar el resto de datos. Sin embargo, dado el amplio espectro de tecnolog y as anchos diferentes disponibles hoy en d sta no es una opcin vlida para a, e o a un anlisis exhaustivo de la implementacin del protocolo seguro. a o Analizando las propuestas de la comunidad cient ca en los ultimos aos, podemos encontrar que las bases de la medicin actual del rendimienn o to para protocolos y dispositivos de red se remonta a 1.996, ao en el que n se publicaron las propuestas para el anlisis del rendimiento en aplicaciones a cliente / servidor ([52]) y las herramientas netpipe ([141]) y NetPerf ([81])se consideran estables. En estos art culos y herramientas se determinaban que los aspectos relevantes de la medicin de rendimiento eran, bsicamente, el o a ancho de banda que se pod ofrecer, la sobrecarga que se produce en los a diferentes protocolos al variar ciertos parmetros de la transmisin, la laa o tencia de la red y la prdida de tramas producida en casos de saturacin. e o Para que los resultados que se obtienen sean ables y averiguar cul es la a variacin del rendimiento entre las diferentes conguraciones, se establecen o modicaciones del tamao del paquete de datos a enviar, se evala el comn u portamiento con transferencias de ujos y con transferencias de bloques de datos, etc. . . .

Cap tulo 2. Estado de la Cuestin o

46

A partir de ese momento se pueden observar dos tendencias claramente diferenciadas: por un lado se han ido desarrollando nuevas herramientas para obtener la informacin de rendimiento, que optimizan o mejoran las tcnicas o e propuestas en 1.996, como es el caso de la herramienta iPerf ([73]), o propuestas como [156]. Estas propuestas mejoran las caracter sticas, el tiempo de ejecucin o los recursos necesarios para llevar a cabo el anlisis de reno a dimiento propuesto por otros autores anteriormente. Por otro lado, nuevas propuestas en cuanto a la medicin del rendimiento se han ido sucediendo, o aunque el inters se ha trasladado de la medicin en si misma a la medicin e o o en determinados entornos o protocolos, y a la medicin del rendimiento de o los procesadores de red. Por estos motivos, podr amos decir que el ultimo gran trabajo en cuanto al anlisis de los parmetros que es necesario evaluar para obtener informaa a cin able y realista acerca del rendimiento de red ha sido la publicacin por o o parte del IETF de la RFC Benchmarking Methodology for Network Interconnect Devices ([19]), en la que no slo se analizan cules son los parmetros o a a que es necesario evaluar, sino tambin qu problemas suelen darse al tomar e e las medidas (por ejemplo, realizar una medicin en un pico de trco, lo o a que originar informacin falsa) y proporciona mtodos para evitar estos a o e problemas. Sin embargo, en los ultimos aos el propio IETF est revisando n a y actualizando las metodolog de evaluacin del rendimiento, aunque en as o lugar de proporcionar una gran metodolog para todo tipo de dispositivos a y trco, est optando por publicar mltiples metodolog que se adapten a a u as a las particularidades de un protocolo, grupo de protocolos o tipo de dispositivos ([100], [15], [69]) (en la l nea de la segunda tendencia mencionada anteriormente. Al estudiar las propuestas de evaluacin del rendimiento que han surgio do de esa segunda tendencia podemos ver cmo las propuestas que evalan o u el rendimiento de los procesadores de red (como por ejemplo NpBench ([96]), CommBench ([151]) o NetBench [102]) se centran en el rendimiento del procesador, por lo que su enfoque es de muy bajo nivel, evaluando el tipo y cantidad de instrucciones de bajo nivel que ejecuta un procesador de red en determinadas situaciones. Sin embargo, dada la proximidad de este rea con a la evaluacin del rendimiento en procesadores tradicionales, podemos ver o cmo su evolucin ha sido ms rpida, disponiendo de algunas metodolog o o a a as de evaluacin del rendimiento que sirven de gu y referencia para llevar a o a cabo este tipo de mediciones (por ejemplo, [148]). La otra rama de la evaluacin del rendimiento que ha surgido de o esa segunda tendencia que mencionbamos anteriormente se ha centrado en a mejorar la medicin del rendimiento en determinadas redes, arquitecturas o o protocolos, estudiando cules son las particularidades de la red en la que se a va a llevar a cabo el estudio, y as mejorar tanto la captura de datos como la interpretacin de resultados. Algunos resultados de esta l o nea de inves-

47

2.3. Evaluacin del rendimiento o

tigacin podemos verlos en [61], donde se analizan la inuencia de utilizar o comunicaciones TCP en paralelo en redes con poca abilidad, [97], donde se proponen tcnicas para medir el rendimiento de la red en entornos Grid, o e [20], donde se estudia cul es la sobrecarga que impone en las comunicacioa nes el protocolo CONFIDANT. En esta misma l nea podemos citar tambin e los propios trabajos del IETF en los ultimos aos ([100], [15]), y algunos n estudios realizados referentes a la sobrecarga que introducen los protocolos de seguridad ([7] y [8] analizan SSL/TLS, mientras que [104] proporciona una comparativa entre IPsec y SSL/TLS). Una ultima tendencia que est cobrando fuerza en los ultimos aos es a n la de integrar la medida del rendimiento de una red o protocolo con estudios acerca del uso que se hace de dicha red o protocolo, con el n de facilitar las previsiones de crecimiento y evolucin futura de las redes. Algunos ejemplos o de este tipo de trabajos los podemos encontrar en [12], donde se utiliza la combinacin de perles de usuarios y rendimiento de la red para planicar la o aplicacin de parmetros de calidad del servicio, [152], donde dinmicamente o a a se construyen modelos basados en la utilizacin y rendimiento de la red, de o forma que sea posible predecir el comportamiento tanto de la red como de los usuarios en un futuro, y [13], donde se utilizan los perles de uso de dispositivos mviles para limitar las funciones disponibles y as eliminar o posibles puntos de ataque.

2.3.1.

Evaluacin del rendimiento de los protocolos de seguo ridad

Centrndonos en la evaluacin del rendimiento de los protocolos de sea o guridad, tras investigar en la literatura cient ca nos encontramos con que todos los trabajos son de reciente factura, encontrando los estudios ms a antiguos en 1.999, cuando Apostolopoulos et al. realizan el primer anlia sis a fondo del protocolo SSL ([8]), estudio que repitieron en 2.000 sobre TLS ([7]). Estos estudios coinciden con el momento en que la cantidad de dispositivos, protocolos, redes, aplicaciones, etc. . . . se incrementa exponencialmente, haciendo que estudios anteriores sobre el rendimiento de la red y los dispositivos de red pierdan parte de su validez, al no tener en cuenta las caracter sticas de los nuevos dispositivos, protocolos y aplicaciones. A partir de este momento asistimos a una preocupacin generalizada o por estudiar cul es el rendimiento de los protocolos y arquitecturas de a seguridad, tanto en redes genricas (centrndose en esos casos en la inuencia e a que tienen los diferentes aspectos del protocolo de seguridad (como por ejemplo, la autenticacin) en el rendimiento de todo el protocolo (como o el anlisis realizado sobre el impacto del uso de clave pblica en Kerberos en a u [63])) como en las nuevas redes que se expand en esos aos (por ejemplo, an n las redes de telfonos mviles GSM, GPRS y similares en [64]). e o

Cap tulo 2. Estado de la Cuestin o

48

Sin embargo, todos estos estudios se caracterizan por aplicar a protocolos o arquitecturas de seguridad las metodolog y conjuntos de pruebas as de rendimiento que se aplican a protocolos y arquitecturas no seguros, lo que hace que los resultados nos proporcionen informacin asimilable para o topolog de red, dispositivos, equipos o algoritmos diferentes de los que se as utilizaron para llevar a cabo el estudio. Adicionalmente, en los ultimos aos hemos podido observar cmo la n o problemtica que representan los protocolos de seguridad al evaluar el rena dimiento ha sido el centro de atencin de mltiples instituciones, compa o u nas e investigadores. De esta forma hemos podido ver cmo el IETF comenzaba o a desarrollar algunas metodolog de evaluacin de rendimiento para disas o positivos de red con servicios de seguridad ([69]), cmo los protocolos de o seguridad eran analizados para comprender cules son las particularidades a de cada operacin y mensaje que se transmite, etc. . . . o Como resultado de esta nueva mentalidad, la evaluacin del rendimiento o de los protocolos de seguridad se est realizando en la actualidad de forma a ms cauta y elaborada. En el caso de IPsec, los estudios ms elaborados a a acerca del rendimiento son IPSec Virtual Private Networks: Conformance and Performance Testing de 2.003 ([82]), y Tutorial on NPFs IPsec Forwarding Benchmark ([26]) y Validating IPsec Network Security Devices ([146]), de 2.004 ambos. El primer estudio plantea la necesidad de llevar a cabo anlisis de cona formidad con el estndar y de rendimiento a las implementaciones IPsec. a Aunque en el documento se plantea la necesidad de llevar a cabo ambos anlisis, el enfoque se decanta sobre todo por los anlisis del rendimiento de a a la implementacin, limitando el anlisis de la conformidad a las respuestas o a que la implementacin puede dar como receptor de la solicitud de estableo cimiento de nuevos tneles IPsec, al tiempo que limita las pruebas que se u llevan a cabo al anlisis de mensajes concretos, sin llegar nunca a evaluar el a completo desarrollo de los protocolos. Adicionalmente, en el estudio del rendimiento que se propone en ningn momento se tiene en cuenta la inuencia u de factores como el ancho de banda dedicado a cada tnel criptogrco o u a la inuencia de la arquitectura de red utilizada para el desarrollo de las pruebas. En el segundo de esos estudios podemos ver cmo ya se incluye la neo cesidad de tener en cuenta los parmetros del trco que se va a proteger a a con IPsec, ya que las operaciones de cifrado y descifrado no son equivalentes en sus requerimientos. Tambin se incluye en este trabajo la necesidad de e evaluar la latencia del protocolo, ya que el establecimiento de la conexin o ahora implica la negociacin de una clave mediante tcnicas criptogrcas, o e a lo que puede signicar un retardo importante. El ultimo de los estudios es ms completo incluso que los dos anterio a

49

2.4. Resumen

res, ya que en l se tienen en cuenta otros aspectos de IPsec, tales como la e capacidad de establecer nuevos tneles criptogrcos para proteger la inforu a macin (aspecto que no se trata en el primer estudio), la cantidad mxima o a de tneles que el dispositivo o equipo puede soportar simultneamente, o el u a impacto de utilizar Perfect Forward Secrecy. Sin embargo, este tercer estudio tambin adolece de un anlisis en proe a fundidad de los escenarios en los que habitualmente se despliega una arquitectura IPsec, y no tiene en cuenta aspectos importantes para el rendimiento. Por ejemplo, uno de los mayores problemas que se pueden encontrar radica en que la medicin de la cantidad de tneles criptogrcos que se pueden o u a establecer no tiene en cuenta cunto trco se est transmitiendo por los a a a tneles ya establecidos, o el impacto de realizar las conexiones en rfagas u a (t picas en las redes corporativas a las horas de inicio de los turnos de trabajo, por ejemplo). Por todos estos aspectos nos encontramos en posicin de decir que, o aunque en los ultimos aos se ha avanzado mucho en la evaluacin del ren n o dimiento de los dispositivos cuando se utilizan protocolos de seguridad, an u queda trabajo por hacer en lo referente al anlisis de las caracter a sticas que afectan al rendimiento y que, por lo tanto, deben ser analizadas con mayor rigurosidad.

2.4.

Resumen

En este cap tulo hemos llevado a cabo un breve anlisis de los estndaa a res existentes en el mbito de la seguridad, en el que hemos profundizado en a los protocolos y arquitecturas de seguridad ms extendidos en la actualidad. a Igualmente se ha analizado el estado actual de los estndares de herramiena tas criptogrcas y otras metodolog arquitecturas, marcos de trabajo y a as, propuestas que han sido estandarizados por alguno de los organismos de estandarizacin existentes, tanto a nivel internacional como de forma local o para un pa o territorio concreto. s Posteriormente hemos realizado un anlisis del estado de la cuestin en a o lo referente a la validacin de la seguridad, partiendo de la validacin de los o o mecanismos de seguridad durante el proceso de desarrollo, para continuar analizando las gu de conguracin de la seguridad en sistemas de inforas o macin (correspondientes a la fase de despliegue en el ciclo de vida), y a las o herramientas automatizadas de evaluacin de la seguridad, correspondientes o a la fase de mantenimiento del sistema de informacin. Posteriormente nos o hemos centrado en las aportaciones de la comunidad cient ca en cuanto a la validacin de protocolos de seguridad, para concluir esa seccin estudiando o o las propuestas existentes de metodolog de evaluacin de la seguridad en as o sistemas de informacin. o

Cap tulo 2. Estado de la Cuestin o

50

Por ultimo, hemos revisado las principales contribuciones en el mbito a de la medicin del rendimiento de protocolos y dispositivos de red, analizano do las caracter sticas de las principales propuestas y estudiando por qu los e modelos tradicionales de medicin del rendimiento no son adecuadas para o evaluar el rendimiento de implementaciones de protocolos de seguridad. Finalmente, hemos dirigido nuestra atencin a las propuestas ms novedosas o a en lo referente a la medicin del rendimiento de protocolos de seguridad, o revisando sus aportaciones y sealando las carencias de cada una de ellas. n

Cap tulo 3

Anlisis de la Conformidad a con el Estndar a

3.1. Introduccin o

En este cap tulo se proceder a exponer cules son las caracter a a sticas que es necesario evaluar para realizar un completo estudio acerca de la conformidad con el estndar de implementaciones de protocolos y arquitectua ras de seguridad. Una vez identicadas estas caracter sticas, se proceder a a describir de qu forma se debe lleva a cabo su evaluacin, estudiando los die o ferentes mtodos, herramientas y tcnicas que es posible utilizar para llevar e e a cabo los anlisis necesarios, presentando las ventajas y los inconvenientes a de cada uno de ellos y otros problemas que pueden surgir al llevar a cabo dicha evaluacin de la conformidad con el estndar. o a

3.2.

Identicacin de aspectos de conformidad en o protocolos y arquitecturas de seguridad

Como se ha comentado anteriormente, el origen de un elevado nmero u de los problemas que se presentan en las implementaciones de los protocolos de seguridad se encuentra en las mejoras introducidas en dichas implementaciones (por ejemplo, el uso exclusivamente de suites criptogrcas ligeras a en lugar de las denidas en los estndares para cada protocolo). Por lo tana to, es necesario un estudio de los documentos en los que los protocolos, mecanismos, herramientas, etc. . . utilizados en los protocolos y arquitecturas de seguridad se denen, para as proceder a identicar a los factores que resultan vitales al evaluar la conformidad de una implementacin con el o estndar. a Tras llevar a cabo un anlisis de las especicaciones de protocolos y a 51

Cap tulo 3. Anlisis de la Conformidad con el Estndar a a

52

mecanismos de seguridad se concluye que aquellos aspectos que debern ser a evaluados a la hora de estudiar la conformidad con los estndares cuentas a con las siguientes caracter sticas: Rigurosa denicin de las estructuras de datos a utilizar o Gran dependencia de la exactitud de la implementacin para un coo rrecto funcionamiento Uso intensivo de determinados mecanismos durante el desarrollo de la arquitectura de seguridad, sin posibilidad de utilizar alternativas, y Obligacin de que ambas partes utilicen los mismos parmetros. o a Por manejo de estructuras de datos entendemos la utilizacin de estruco turas de datos en las que no se permite margen de libertad al preparar los datos de entrada o en la representacin de los datos de salida. Por ejemplo, o en los cifradores de bloque los datos de entrada deben ser bloques de datos de un tamao determinado, con una clave de cifrado de un tamao conn n creto, y la salida ser un bloque de datos de un tamao especicado. Si la a n implementacin del cifrador no prepara correctamente los datos de entrada o o no reserva memoria suciente para almacenar el bloque de datos de salida se producir un error al utilizar ese cifrador que ha sido implementado a incorrectamente. Del mismo modo, las estructuras de datos que conforman los diferentes campos de datos con los que operan los protocolos de seguridad han de seguir unas reglas estrictas acerca del modo en que se opera con esos campos: formatos, codicacin, valores de relleno, etc. . . . Cualquier o implementacin que modique la forma de utilizar esos campos de datos con o respecto a lo especicado en el estndar del protocolo correspondiente genea rar problemas de interoperabilidad con otras implementaciones que traten a los campos tal y como se especica en el estndar. a La dependencia de la exactitud de la implementacin hace referencia o a la necesidad de las herramientas (especialmente las que poseen un alto componente formal, de que las implementaciones de dichas herramientas sean perfectamente conformes a la especicacin, ya que en caso contrao rio pueden perderse las propiedades que convierten dicha herramienta en idnea para una labor determinada. Por ejemplo, un protocolo de seguridad o normalmente es analizado tericamente para prevenir ltrados de informao cin a terceras partes; sin embargo, una implementacin deciente puede o o hacer posible que un atacante recabe informacin que deber estar proteo a gida. Del mismo modo, el desarrollo de un protocolo de seguridad consta de determinados pasos encaminados al intercambio ordenado y seguro de informacin, y dichos pasos estn denidos estrictamente en la especicacin o a o del protocolo. Una implementacin que no siga esos pasos especicados se o encontrar con problemas a la hora de establecer canales seguros con otras a

53

3.2. Identicacin de aspectos de conformidad o

implementaciones que sigan el desarrollo del protocolo como se dene en el estndar. a El uso intensivo de un mecanismo durante el desarrollo de la arquitectura de seguridad implica que el factor (ya sea una herramienta, una propiedad que debe preservarse o un conjunto de datos concretos) es utilizado bien en mltiples fases del protocolo o arquitectura, bien en una fase pero de forma u intensiva, por lo que el impacto de dicho factor en el desarrollo de cada una de las fases y de la arquitectura en general es muy importante. El ejemplo ms claro es la implementacin de los cifradores, ya que estas herramientas a o se utilizan en todas las fases de los protocolos y subprotocolos involucrados, bien para proteger datos del usuario, bien para proteger la negociacin de o otros parmetros de seguridad. Otro ejemplo que podr a amos utilizar son los modos en los que puede operar el protocolo IKE dentro de IPsec para negociar los parmetros que regirn las fases posteriores de IPsec: aunque estos a a modos unicamente se utilizan en la fase inicial de IKE y al renegociar las claves criptogrcas, el correcto desarrollo de la negociacin de claves cripa o togrcas depende completamente de la correcta utilizacin de estos modos. a o Por ultimo, el hecho de que las dos partes que participan en un pro tocolo o arquitectura de seguridad deban utilizar los mismos parmetros de a seguridad y comunicaciones para poder proceder al intercambio y proteccin o de la informacin de forma eciente y con los niveles de seguridad deseados o hace que todos aquellos parmetros que se pueden considerar opcionales o a de conguracin deban ser analizados y estudiados. En estos casos la imporo tancia no slo radica en la utilizacin de estos parmetros por s mismos, o o a sino tambin en los mecanismos con los que la implementacin anuncia que e o proceder a utilizar la conguracin o herramienta opcional, y la gestin a o o que realiza de las respuestas (tanto de aceptacin como de rechazo) que se o recibe. Un ejemplo de parmetro de este tipo es la utilizacin de compresin a o o en la capa IP utilizando IPComp ([140]) o el uso de certicados de cliente en SSL para autenticar al cliente ([58], [49]). Teniendo en cuenta estos hechos, y partiendo de las especicaciones de protocolos y arquitecturas de seguridad en concreto, tales como el protocolo TLS o la arquitectura IPsec, podemos estudiar cules son los aspectos que a son susceptibles de ser fuente de problemas al ser trasladados a una implementacin real. Un estudio de los documentos en los que se denen algunos o de estos protocolos y arquitecturas ([49], [58], [91], [86], [87], [25], [85], [54], [136], [70], [71], [133]) nos ha permitido identicar los aspectos que resultan cr ticos al evaluar el nivel de delidad con los que una implementacin se ha o ajustado a las especicaciones de un estndar. a Tanto los mecanismos criptogrcos como los protocolos que confora man las arquitecturas de seguridad son los componentes fundamentales de estas arquitecturas, por lo que son utilizados intensivamente tanto durante el establecimiento de un canal seguro como en la posterior transmisin o

Cap tulo 3. Anlisis de la Conformidad con el Estndar a a

54

de informacin a travs del mismo. Adems, tanto en los mecanismos cripo e a togrcos como en los protocolos utilizados el componente matemtico a a formal es muy elevado, lo que se complementa con la escasa exibilidad que presentan a la hora de manejar estructuras de datos. Complementariamente, los procesos de autenticacin y gestin de claves o o que se encuentran en los protocolos y arquitecturas de seguridad son altamente dependientes tanto de los procesos criptogrcos como de los protocoa los utilizados para intercambiar la informacin: Sin embargo, la importancia o de estos procesos de autenticacin y gestin de claves, as como la entidad o o independiente de estos procesos dentro del establecimiento de canales seguros los convierte en otros mecanismos que deben ser analizados de cara a evaluar el nivel de conformidad de la implementacin evaluada. o Por lo tanto, los aspectos que debern ser estudiados son la correcta a implementacin criptogrca, el desarrollo de los protocolos, la geso a tin de las claves criptogrcas y los mecanismos de autenticacin. o a o Adicionalmente, existen otros factores propios de cada fase de la arquitectura de seguridad y que tambin presentan caracter e sticas que hacen que necesiten ser evaluados, como se detallar a continuacin. a o

3.2.1.

Correcta implementacin de los mecanismos criptogro a cos

Dado que muchos de los problemas y desviaciones del estndar se maa niestan en la implementacin deciente de los algoritmos criptogrcos, es o a necesario que las metodolog evalen dichas implementaciones, tanto en as u los algoritmos de cifrado como en los utilizados para calcular los resmenes u criptogrcos (funciones hash), incluyendo en las pruebas y evaluaciones las a herramientas criptogrcas utilizadas: modos de cifrado, mtodos de intera e cambio de claves (por ejemplo, aqu ser necesario probar los diferentes a grupos de Die-Hellman denidos en el estndar, . . . .), mtodos de autena e ticacin y cualquier otra herramienta criptogrca que se utilice. o a Todas estas pruebas implicarn un conjunto muy elevado de comprobaa ciones posibles a realizar, aunque posteriormente la cantidad de dichos tests que es necesario llevar a cabo no sea tan elevado, dado que el nmero de u combinaciones algoritmo de cif radotama o de clavetama o de bloque n n algoritmo de resumen grupo de Dif f ie Hellman se reduce rpidamena te en el caso de que no todos los algoritmos, tamaos de clave y bloque o n grupos de Die Hellman estn implementados o estn especicados como a e combinaciones vlidas en la especicacin de la arquitectura o protocolo de a o seguridad empleado: por ejemplo, en [49] se especica que la unica combina cin de herramientas criptogrcas que las implementaciones de TLS versin o a o 1.1 deben soportar es TLS_RSA_WITH_3DES_EDE_CBC_SHA, mientras que las unicas combinaciones aceptables en una negociacin son las que podemos o

55

3.2. Identicacin de aspectos de conformidad o

ver en la Tabla 3.1. Tabla 3.1: Combinaciones de herramientas criptogrcas vlidas durante el a a proceso de negociacin de TLS 1.1 o Suite Criptogrca a
TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS TLS NULL WITH NULL NULL RSA WITH NULL MD5 RSA WITH NULL SHA RSA WITH RC4 128 MD5 RSA WITH RC4 128 SHA RSA WITH IDEA CBC SHA RSA WITH DES CBC SHA RSA WITH 3DES EDE CBC SHA DH DSS WITH DES CBC SHA DH DSS WITH 3DES EDE CBC SHA DH RSA WITH DES CBC SHA DH RSA WITH 3DES EDE CBC SHA DHE DSS WITH DES CBC SHA DHE DSS WITH 3DES EDE CBC SHA DHE RSA WITH DES CBC SHA DHE RSA WITH 3DES EDE CBC SHA DH anon WITH RC4 128 MD5 DH anon WITH DES CBC SHA DH anon WITH 3DES EDE CBC SHA

Interc. Clave
NULL RSA RSA RSA RSA RSA RSA RSA DH DSS DH DSS DH RSA DH RSA DHE DSS DHE DSS DHE RSA DHE RSA DH anon DH anon DH anon NULL - NULL NULL - MD5 NULL - SHA RC4 128 - MD5 RC4 128 - SHA IDEA CBC - SHA DES CBC - SHA 3DES EDE CBC - SHA DES CBC - SHA 3DES EDE CBC - SHA DES CBC - SHA 3DES EDE CBC - SHA DES CBC - SHA 3DES EDE CBC - SHA DES CBC - SHA 3DES EDE CBC - SHA RC4 128 - MD5 DES CBC - SHA 3DES EDE CBC - SHA

Como podemos ver, teniendo 7 mtodos de intercambio de clave, 5 cie fradores diferentes y 3 funciones resmenes diferentes utilizadas, unicamente u 19 combinaciones de las 105 posibles pueden ser utilizadas en TLS.

3.2.2.

Conformidad de protocolos y subprotocolos

Las ejecuciones de los protocolos y subprotocolos presentan otro de los aspectos que es necesario evaluar para llevar a cabo una evaluacin del nivel o de conformidad de una implementacin de un protocolo o arquitectura de o seguridad con el estndar. Esta evaluacin deber evaluar en qu medida a o a e la implementacin analizada es capaz de proteger la informacin utilizando o o los diferentes protocolos y subprotocolos denidos en los estndares. Por a lo tanto, es necesario considerar la mquina de estados que representa la a ejecucin de cada protocolo para evaluar si la mquina de estados de la o a implementacin se corresponde con la descrita en los estndares. o a En aquellos casos en los que el protocolo o arquitectura de seguridad

Cap tulo 3. Anlisis de la Conformidad con el Estndar a a

56

se componga de mltiples protocolos, como es el caso de IPsec, que consta u de IKE para gestionar las claves criptogrcas, y ESP y AH para proteger a el trco), es necesario que cada protocolo se evale por separado (evaluaa u cin de la correccin de la implementacin del protocolo), pero tambin o o o e ser necesario comprobar tanto si el resultado de la ejecucin del protocolo a o es el deseado (por ejemplo, si los parmetros de seguridad negociados con a IKE son los esperados, especialmente cuando existen ms de una propuesta a de parmetros) como si la negociacin y los parmetros negociados con dia o a cho protocolo son aplicados correctamente durante el establecimiento de los tneles criptogrcos. u a

3.2.3.

Mecanismos de autenticacin o

Aunque estos mecanismos pueden ser incluidos en el rea de correcta a implementacin de las herramientas criptogrcas debido a que los mecaniso a mos de autenticacin se basan en herramientas criptogrcas ms o menos o a a complejas, la importancia de la autenticacin en los protocolos de seguridad o aconseja prestar especial atencin a este aspecto. Los diferentes mecaniso mos de autenticacin que se utilizan en la actualidad pueden variar desde o una simple contrasea (un secreto preestablecido) hasta cadenas de certin cacin que utilizan los servicios de una autoridad de certicacin y una o o infraestructura de clave pblica completa1 . u En el caso en que un protocolo soporte mltiples mtodos de autentiu e cacin, la metodolog de evaluacin deber proporcionar los medios para o a o a probar y evaluar todos ellos. Adems, cuando sea posible utilizarlos congua rando el nivel de seguridad (por ejemplo, en IKE es posible congurar si se desea vericar la validez del certicado X.509 que se recibe de la entidad con la que se establece el tnel criptogrco o si basta unicamente con que dicho u a certicado sea sintcticamente correcto), la metodolog deber evaluar los a a a diferentes niveles que se hayan establecido como vlidos en la especicacin a o del protocolo en cuestin. o

3.2.4.

Opciones de gestin de las claves criptogrcas o a

La mayor de los protocolos de seguridad incluyen parmetros cona a gurables (en el cliente, en el servidor o en ambos) en aspectos tales como cundo deben caducar las claves secretas negociadas (expresado en tiempo a pasado desde que se empez a utilizar y/o en el volumen de datos que ha o sido protegido con esa clave), y proporcionan mtodos y tcnicas para que e e
En algunos casos se da la situacin de que un mecanismo de autenticacin se encuentra o o encubierto, por lo que puede ser incorrectamente identicado como un mecanismo nuevo (como es el caso de, por ejemplo, port-knocking ([46], [94])). Esto hace que se deba prestar atencin a los usos que se hace de los mecanismos de autenticacin para evitar cometer o o errores pasados, como se puede ver en ([79])
1

57

3.3. Mtodos de validacin de los factores de conformidad e o

se pueda forzar una renovacin de claves, etc. . . . Dada la importancia de o estas medidas ([137], [6]), es necesario que la gestin de las claves se realice o de la forma ms segura posible, motivo por el que la gestin propuesta en a o los estndares ha sido sometida al escrutinio de la comunidad cient a ca. Por lo tanto, resulta necesario comprobar que las implementaciones de los protocolos y arquitecturas de seguridad estudiados llevan a cabo la gestin de las claves criptogrcas de la forma descrita en su correspondiente o a especicacin. Al igual que ocurr con los mecanismos de autenticacin, o a o los procedimientos de gestin de claves podr englobarse en el apartado o an de implementacin de las herramientas criptogrcas, pero la importancia o a de esta gestin en la seguridad nal del tnel criptogrco hace que se o u a requiera de un anlisis espec a co acerca de los aspectos de renovacin y o caducidad de las claves, tanto planicados (es decir, los acordados durante la negociacin de los parmetros de seguridad) como no planicados (aquellos o a que son requeridos por alguna de las partes sin estar sujetos a los parmetros a acordados en la fase de negociacin. o

3.2.5.

Otras caracter sticas

Normalmente las caracter sticas denidas como opcionales en los estndaa res son una fuente de problemas, ya que la implementacin que cada fabrio cante hace de ellas es muy dependiente de su modelo de desarrollo y de la habilidad al trasladar los diseos a una implementacin concreta en un lenn o guaje de programacin. Adems, es habitual que las caracter o a sticas que se denen como opcionales en una versin del estndar pasen a ser obligatorias o a en la siguiente versin (como es el caso de traversal-NAT ([92]), opcional o en la primera versin de IPsec pero que debe ser soportado por todas las o partes segn la versin estandarizada en Diciembre de 2.005). Sin embargo, u o dado el carcter opcional, el juego de pruebas a realizar no ser tan intenso a a y exhaustivo como lo debe ser al evaluar las implementaciones criptogrcas a o de ejecucin del protocolo. o

3.3.

Mtodos de validacin de los factores de cone o formidad

Al llevar a cabo una validacin de los factores anteriormente descritos o como clave para poder asegurar la conformidad con el estndar de un protoa colo o arquitectura de seguridad y, consiguientemente, la interoperabilidad con otras implementaciones de dicho protocolo o arquitectura, es necesario llevar a cabo un anlisis de cada uno de dichos factores, para as estudiar a las caracter sticas de dicho elemento en la arquitectura de seguridad y el control del que disponemos de dicho factor en la implementacin analizao

Cap tulo 3. Anlisis de la Conformidad con el Estndar a a

58

da. Este anlisis nos permitir evitar el uso de tcnicas de evaluacin que a a e o resultan inviables o inadecuadas para el tipo de caracter stica analizada.

3.3.1.

Correcta implementacin criptogrca o a

La evaluacin de la correcta implementacin de herramientas criptogro o a cas es un tema que se ha tenido en cuenta por los diseadores de estas hen rramientas, que en los diseos incluyen los llamados vectores de prueba n ([137]). Estos vectores de prueba son conjuntos de entradas-salidas a la herramienta criptogrca pensados para evaluar la implementacin, probando a o los valores l mites para las entradas y para las operaciones internas que lleva a cabo la herramienta. Esto implica que para poder realizar las pruebas de los vectores de prueba es necesario poder controlar totalmente los valores de entrada a la herramienta criptogrca: claves, datos de entrada, generadores a aleatorios, etc. . . . Sin embargo, al afrontar una evaluacin de una implementacin de IPsec o o como una caja negra (y ms si el anlisis se lleva a cabo de forma remota), a a nos encontramos con que no disponemos del control necesario sobre las herramientas criptogrcas para poder llevar a cabo ese anlisis. En la mayor a a parte de las implementaciones de IPsec las librer criptogrcas apareas a cen encapsuladas y el usuario nal no dispone de acceso a dichas librer as para poder llevar a cabo las pruebas necesarias. Adems, no es posible cona trolar aspectos como los generadores aleatorios que construyen las claves criptogrcas de IPsec, o incluso el hecho de que existan diferentes librer a as criptogrcas para cada fase de IPsec. Disponer de dicho conocimiento cona vertir el anlisis en un estudio de caja blanca, que no es el objetivo de la a a metodolog a. Por lo tanto, es necesario disponer de un mtodo de evaluacin de las e o herramientas criptogrcas que pueda ser llevado a cabo por un examinador a externo a la implementacin, y sin disponer de conocimiento alguno acerca o de la organizacin interna de la implementacin. Adems, para poder utilio o a zar los resultados obtenidos como medida de interoperabilidad, es necesario que la evaluacin sea tan parecida como sea posible a lo que una tercera o parte se encontrar al establecer tneles criptogrcos mediante IPsec con a u a la implementacin analizada. o Dado que los vectores de prueba son las unicas herramientas de vali dacin prctica de las que disponemos a partir de los anlisis formales del o a a diseo de las herramientas, el mtodo de evaluacin escogido deber ser n e o a capaz de utilizar, de alguna forma, estos vectores de pruebas para pronunciarse acerca de la implementacin de las herramientas criptogrcas en la o a implementacin bajo nuestro estudio. o Tras analizar todos estos requisitos y limitaciones, el mtodo de evaluae cin escogido consistir en aplicar la transitividad para poder evaluar las o a

59

3.3. Mtodos de validacin de los factores de conformidad e o

herramientas criptogrcas: Al llevar a cabo el anlisis de la implementacin a a o que se desea estudiar ser necesario disponer de una implementacin propia a o del protocolo o arquitectura de seguridad con la que negociar y establecer tneles criptogrcos. Esta implementacin se encontrar bajo nuestro u a o a control, y por lo tanto es factible validar que las herramientas criptogra cas utilizadas en esta implementacin evaluadora ofrecen los resultados o esperados cuando se les somete a los vectores de prueba. Una vez evaluada nuestra implementacin, la forma de evaluar la imo plementacin que no controlamos pasa por establecer tneles criptogrcos o u a entre ambas implementaciones, y procediendo al env de mensajes de alo to nivel a travs de los tneles. En el caso de que la implementacin de e u o las herramientas criptogrcas en la implementacin bajo anlisis presena o a te alguna deciencia, durante el intercambio de mensajes esta deciencia saldr a relucir en forma de mensaje interpretado incorrectamente o mensaa jes rechazados. Por lo tanto, los mensajes de alto nivel debern ser escogidos a cuidadosamente, para poder cubrir todas las opciones posibles de cifrado y descifrado, clculo y validacin de resmenes, etc. . . a o u Al analizar qu tipo de mensajes de alto nivel se utilizarn para crear el e a trco, las posibilidades que se nos presentan son mltiples: desde trco de a u a protocolos ampliamente utilizados, como HTTP, POP, DNS, . . . hasta la utilizacin de generadores de trco propios. Sin embargo, estos protocolos de o a nivel de aplicacin tienen el problema de que, a priori, no es posible conocer o la respuesta que deber amos obtener a una peticin. Adems, la dependencia o a de un servidor del protocolo escogido y de su correcto funcionamiento hacen que estas opciones no sean las ms recomendables. a Sin embargo, mediante la utilizacin de mensajes ICMP ([130]) es poo sible conocer de antemano qu respuesta ser la que debamos recibir. Por e a ejemplo: utilizando mensajes ICMP echo request con un campo de datos aleatorio (campo de datos que deber aparecer igual en el mensaje de a respuesta echo reply) podremos comprobar si la implementacin de IPsec o que se est analizando ha sido capaz de descifrar y comprobar el resumen del a mensaje recibido y cifrar correctamente y calcular el resumen del mensaje que deb devolver. La posibilidad de enviar otro tipo de mensajes ICMP, a con sus consiguientes respuestas, ampl las posibilidades de cara a la evaluaa cin de las herramientas criptogrcas, ya que disponemos de informacin o a o generada dinmicamente que la implementacin de IPsec deber procesar a o a a travs de los aparatos criptogrcos que estemos evaluando en cada moe a mento. Por lo tanto, el mtodo propuesto para la evaluacin de las herramientas e o criptogrcas de la implementacin consiste en el establecimiento de tneles a o u criptogrcos protegidos mediante los protocolos ESP o AH (dependiendo a de la herramienta criptogrca que deseemos evaluar) por los que se ena viarn mensajes ICMP de los que se conoce de antemano la respuesta que a

Cap tulo 3. Anlisis de la Conformidad con el Estndar a a deber generar la implementacin analizada. a o

60

3.3.2.

Conformidad de protocolos y subprotocolos

En la actualidad, y como se ha visto en la revisin de los protocolos o y arquitecturas de seguridad llevado a cabo en el cap tulo 2, los protocolos y arquitecturas de seguridad utilizados en la actualidad comprenden un conjunto de protocolos que se encargan de tareas que van desde la gestin o de claves hasta la proteccin del trco entre los dispositivos. Cada uno de o a estos protocolos se encuentra altamente integrado con el resto de la arquitectura, por lo que las interdependencias son muy fuertes. Por ejemplo, de la negociacin que se lleve a cabo con un protocolo dependern los algoritmos o a de cifrado que se utilizarn en otro y cada cunto habr que renovar las a a a claves de cifrado que se utilizan en dicho protocolo. Por este motivo, la validacin del desarrollo de los protocolos deber reao a lizarse no slo de cada protocolo en concreto, sino que tambin deber como e a probarse que la interaccin entre los diferentes protocolos es la esperada. o Por este motivo la evaluacin del correcto desarrollo de los protocolos deo ber llevarse a cabo analizando cada uno de los protocolos individualmente a primero, y junto al resto de protocolos despus. Aunque este mtodo implica e e un mayor nmero de pruebas, las implicaciones de un error en la interaccin u o entre protocolos son demasiado grandes como para evitar llevar a cabo estos anlisis. a En cuanto al anlisis de cada uno de los protocolos, en general podea mos encontrarnos dos tipos de protocolos: aquellos destinados a proteger la informacin (por ejemplo, ESP en IPsec) y aquellos encargados de gestioo nar los parmetros que gestionan esa proteccin de la informacin (como a o o el protocolo de negociacin en TLS, Handshake protocol). Dado que la o funcionalidad y los objetivos de cada uno de estos tipos de protocolos son completamente diferentes tambin la evaluacin deber llevarse a cabo de e o a forma diferente. Para los protocolos destinados a proteger la informacin, el anlisis de o a la conformidad con el estndar est descrito en el apartado Requisitos de a a Conformidad del estndar de cada protocolo2 . En estos cap a tulos se declara que los requisitos que una implementacin de esos protocolos debe cumplir o para poder asegurar la conformidad con el estndar son: a Interpretar cada campo de los mensajes generados y recibidos como se especica en el estndar. a Generar los mensajes con la sintaxis especicada.
En aquellos protocolos y arquitecturas de seguridad en los que no se incluy dicha o seccin en el estndar en su d posteriormente han aparecido actualizaciones en las que o a a, se especican cules son esos parmetros. a a
2

61

3.3. Mtodos de validacin de los factores de conformidad e o

Por lo tanto, para evaluar si una implementacin es conforme o a los estndares necesitaremos evaluar si los mensajes que genera a tienen el formato y la informacin especicada en el estndar, y o a si la implementacin es capaz de interpretar mensajes que hayan o sido generados por otros sistemas y que sean correctos seg n la u especicacin del estndar. o a Hay que tener en cuenta que existen casos en los que protocolos o subprotocolos que son alternativos (es decir, es necesario escoger entre uno u otro), no presentan las mismas posibilidades de operacin, por lo que la o cantidad y tipo de pruebas que es necesario llevar a cabo en cada caso es diferente. Por ejemplo, en IPsec AH unicamente se admite un modo de operacin mientras que ESP puede operar ofreciendo slo condencialidad, o o condencialidad e integridad o condencialidad, integridad y autenticacin o de origen. Esto quiere decir que todos los modos de operacin de ESP deo bern ser tratados de forma independiente y deben evaluarse con su propia a bater de pruebas. a En lo tocante a los protocolos de gestin de claves su evaluacin requieo o re de un anlisis ms elaborado. Partiendo tambin de los Requisitos de a a e Conformidad especicados en los documentos de los estndares, podemos a identicar cules son las caracter a sticas que es necesario evaluar para llevar a cabo el anlisis de conformidad del protocolo. En concreto, estos aspeca tos (que se reejarn en ms o menos pruebas dependiendo del desarrollo a a interno del protocolo concreto que est siendo evaluado) son: a Desarrollar un proceso completo de negociacin e intercambio de clao ves, utilizando todos los modos de operacin en los que el protocolo o pueda trabajar. Desarrollar un proceso completo de negociacin de parmetros de proo a teccin de la informacin, utilizando todos los modos de operacin en o o o los que el protocolo pueda trabajar. Llevar a cabo procesos de autenticacin utilizando los diferentes meo canismos soportados por el protocolo. Adicionalmente, otras caracter sticas que no se encuentren expl citamente englobadas en los puntos anteriores, pero que se encuentren relacionadas con el desarrollo de los protocolos de gestin de claves deber ser o a evaluado. Por ejemplo, en IPsec la caracter stica de Perfect Forward Secrecy representa un cambio sustancial tanto en la seguridad del sistema como en las propiedades de la informacin intercambiada, por lo que deo ber ser incluida en en conjunto de factores a analizar. 3 . a
3 Sin embargo, como veremos al desarrollar la metodolog para la validacin de la a o conformidad y evaluacin del rendimiento en implementaciones de IPsec en el cap o tulo 5,

Cap tulo 3. Anlisis de la Conformidad con el Estndar a a

62

Por otro lado, la autenticacin ser estudiada en detalle ms adelante, o a a por lo que en la metodolog no se incluirn los diferentes mtodos de aua a e tenticacin en la evaluacin de los protocolos en s mismos. De esta manera o o podremos diferenciar los problemas que puedan derivarse de una ejecucin o incorrecta de los protocolos de aquellos cuyo origen es el procesado de autenticacin o Como ultimo paso en la evaluacin de la ejecucin de los protocolos o o y subprotocolos implicados, es necesario incluir en el diseo de las pruebas n de conformidad aquellas caracter sticas que, sin pertenecer estrictamente hablando al desarrollo de los protocolos, afectan al modo en el que se lleva a cabo la ejecucin de los mismos durante la proteccin de trco. Por ejemplo, o o a la posibilidad que ofrece IPsec de separar en tneles criptogrcos diferentes u a aquellas comunicaciones con diferentes protocolos, servicios, etc. . . hace que la mquina de estados interna se ejecute de forma diferente cuando esta a caracter stica se lleva a cabo y cuando no. Por este motivo, la correcta ejecucin de los protocolos involucrados debe evaluarse teniendo en cuenta o estos factores. Para llevar a cabo esta evaluacin se debe crear trco desde la red o a protegida por la implementacin objeto de nuestro anlisis, en el que unicao a mente cambie un parmetro de las caracter a sticas de comunicaciones (puerto, protocolo, equipo origen, equipo destino, etc. . . ), y comprobar cmo la imo plementacin evaluada solicita la creacin de nuevos tneles criptogrcos. o o u a El caso contrario, en el que el trco se origina hacia la implementacin a o que est siendo analizada no deber presentar problemas, ya que la ima a plementacin unicamente recibir solicitudes para establecer nuevos tneo a u les criptogrcos y responder a ellos; posteriormente el trco de vuelta a a a ser enviado por un tnel u otro en funcin de la base de datos de pol a u o ticas, lo que resulta en un caso similar a la generacin de trco desde la red o a protegida, como propon amos anteriormente. Un aspecto importante de esta prueba es que el establecimiento de nuevos tneles criptogrcos es una operacin costosa en recursos (como u a o se ha ver en la seccin 4.2). Por lo tanto, el trco que se genere para a o a comprobar si la implementacin es capaz de aislar el trco en tneles indeo a u pendientes deber espaciarse en el tiempo lo suciente para permitir que la a implementacin negocie todos los parmetros de seguridad para cada tnel. o a u Adicionalmente, no se deber enviar trco por el tnel, ya que con el estaa a u blecimiento de la conexin es suciente para forzar el establecimiento de un o nuevo tnel, y la presencia de trco que debe ser cifrado slo empeorar u a o a el rendimiento de la implementacin en la generacin de tneles. o o u Por todo lo anterior podemos decir que el establecimiento de conexiones
no es obligatorio para las implementaciones de IPsec el incluir Perfect Forward Secrecy, por lo que estas posibles situaciones deben ser tenidas en cuenta a la hora de desarrollar metodolog y bater de pruebas as as

63

3.3. Mtodos de validacin de los factores de conformidad e o

TCP desde la red que protege la implementacin objeto de la evaluacin, o o sin env de trco posterior es el mtodo ms adecuado para evaluar o a e a la posibilidad de aislamiento del trco en diferentes tneles criptogrcos. a u a Finalmente, a modo de evaluacin de la interoperabilidad de todos los o protocolos y subprotocolos de la arquitectura o protocolo de seguridad trabajando conjuntamente, es necesario incluir la evaluacin del proceso como pleto de proteccin de la informacin, desde el establecimiento de tneles o o u criptogrcos hasta la transmisin de informacin a travs de dichos tneles, a o o e u como forma de evaluar la correcta interaccin de todos los protocolos. o

3.3.3.

Autenticacin o

Como hemos comentado anteriormente, uno de los requisitos para poder armar que una implementacin de un protocolo o arquitectura de segurio dad es conforme al estndar es poder autenticar y autenticarse al establecer a un tnel criptogrco. El proceso de autenticacin aparece denido en los u a o estndares como parte de los protocolos (ya que es un paso fundamental en el a desarrollo de la negociacin inicial para establecer nuevos tneles criptogro u a cos, y tambin para validar el origen de los mensajes protegidos mediante e los protocolos correspondientes), por lo que su estudio podr incluirse en el a anlisis de la ejecucin de los subprotocolos implicados. a o Igualmente, debido al fuerte uso de herramientas criptogrcas en los a diferentes mtodos de autenticacin soportados por la arquitectura de segurie o dad, ser tambin posible haber llevado a cabo el estudio de la autenticacin a e o junto con el resto de algoritmos y mecanismos criptogrcos. a Sin embargo, debido a que la autenticacin debe hacer uso de las heo rramientas criptogrcas y de los protocolos y subprotocolos que conforman a la arquitectura, es necesario independizar las pruebas de estas herramientas de las de la autenticacin, para evitar identicar incorrectamente problemas o en la ejecucin del protocolo (o en la utilizacin de determinado algoritmo o o criptogrco) como problemas de la autenticacin, o viceversa. a o Es importante tambin tener en cuenta que, de cara a la conformidad e con el protocolo, es necesario evaluar cules de los mtodos de autenticacin a e o incorporados a las implementaciones se encuentran recogidos por el estndar a como necesarios, y cules son unicamente opcionales. En algunos casos es a habitual encontrar mtodos de autenticacin opcionales que se encuentran e o ampliamente extendidos y aceptados, u otros casos en los que recientes modicaciones al estndar han incorporado nuevos mtodos de autenticacin a e o (normalmente, con carcter opcional), pero que por su implicacin en la sea o guridad o interoperatividad del protocolo o arquitectura de seguridad con otros mecanismos y herramientas de autenticacin, es altamente recomendao ble estudiar la disponibilidad de dichos mecanismos en las implementaciones que se evalen. Un ejemplo de este tipo de mecanismos es la autenticacin u o

Cap tulo 3. Anlisis de la Conformidad con el Estndar a a

64

mediante EAP ([1]), que permite la integracin de servicios de autenticacin o o que hagan uso de diferentes protocolos particulares para llevar a cabo dicha autenticacin, abstrayendo el uso y manejo concreto de las credenciales que o se utilicen en cada caso, tal como se expone en ([131]). La evaluacin de la implementacin de los mecanismos de autenticacin o o o deber llevarse a cabo haciendo que la implementacin ejerza los roles de a o parte autenticada y de autenticador, de forma que sea posible evaluar los mecanismos tanto de generacin como de validacin de credenciales. Este o o proceso se llevar a cabo con todos los mtodos de autenticacin soportados a e o en la especicacin del protocolo o arquitectura de seguridad que implemente o el dispositivo o software bajo anlisis, aunque siempre teniendo en cuenta a cules son los mtodos de autenticacin exigidos por la especicacin, y a e o o cules son opcionales. a

3.3.4.

Gestin de Claves o

Dentro de todo el proceso de gestin de claves que llevan a cabo los o protocolos y arquitecturas de seguridad, uno de los aspectos que requieren especial atencin es la gestin de las claves criptogrcas negociadas. Esta o o a gestin es la que se encarga de renegociar las claves criptogrcas para evitar o a un uso excesivo de la misma clave y de proporcionar mecanismos para aislar las claves de diferentes fases de la arquitectura, de forma que el compromiso de una clave no afecta al resto de claves negociadas (por ejemplo, en IPsec dicha propiedad es cierta si se utiliza la opcin de Perfect Forward Secrecy, o PFS). Al evaluar la gestin de las claves, es necesario comprobar dos aspectos o diferentes: Por un lado, hay que comprobar que la implementacin estudiada o es capaz de detectar la caducidad de una clave e iniciar el proceso de renovacin de la misma de acuerdo a lo denido en la especicacin del protocolo. o o Esta renovacin por caducidad puede dispararse por diversos factores, tales o como el tiempo que dicha clave ha estado en uso, o la cantidad de informacin que se ha protegido con ella. Adems, los sistemas implicados en el o a tnel criptogrco pueden contar con algn mecanismo de sincronizacin o u a u o no, por lo que dicho aviso de caducidad de la clave puede llegar de forma s ncrona o as ncrona, lo que hace necesario evaluar el comportamiento de la implementacin tanto cuando acta como el sistema que avisa de que la clave o u ha caducado, como cuando su papel es el de receptor de dicha noticacin. o Por otro lado, la respuesta de la implementacin ante solicitudes as o ncronas de renegociacin de la clave no correspondientes con caducidades o planicadas de la clave es el otro aspecto de la gestin de las claves cripo togrcas que debe ser validado. En este aspecto es necesario comprobar a cul es el comportamiento de la implementacin objeto del anlisis a la hora a o a de solicitar una renegociacin de claves, as como su reaccin cuando recibe o o

65 una solicitud similar.

3.4. Consideraciones de implementacin o

Al igual que se hacia hincapi a la hora de validar los mecanismos de e autenticacin, de cara a establecer el nivel de conformidad de una impleo mentacin con el estndar del protocolo o arquitectura de seguridad que o a desarrolla es necesario diferenciar entre los comportamientos denidos como vlidos en la especicacin de dicho protocolo o arquitectura, y aquellos a o comportamientos que, incluso estando ampliamente extendidos entre las implementaciones ms populares, unicamente aparecen recogidos como opcioa nales. Al igual que se comentaba anteriormente, aquellas opciones, mecanismos y comportamientos que resulten de especial inters para la proteccin e o de la informacin o para la funcionalidad del sistema podrn ser analizadas, o a pero siempre teniendo en cuenta su carcter opcional. a

3.3.5.

Otras caracter sticas

Como colofn al estudio de la conformidad con el estndar, es necesario o a evaluar en qu medida las implementaciones de un protocolo o arquitectura e de seguridad hacen uso de otras herramientas que, si bien estn denidas a en el estndar, su utilizacin es bien opcional, bien enfocada a determinaa o das situaciones o arquitecturas espec cas. Estas herramientas puede ofrecer funcionalidad adicional a la incluida en el protocolo o arquitectura, o pueden habilitar el uso de caracter sticas de seguridad en determinadas arquitecturas, topolog de red, o situaciones particulares. as Para cada una de estas caracter sticas ser necesario denir un escenario a de pruebas en el que se den las condiciones necesarias para que la implementacin del protocolo de seguridad tenga que hacer uso (tanto por iniciativa o propia como a peticin del otro extremo del tnel criptogrco) de estas o u a opciones. Por ejemplo, para poder validar la conformidad con el estndar a del NAT traversal en una implementacin IPsec ser necesario utilizar una o a arquitectura de red que permita a la implementacin evaluada hacer uso de o la tecnolog de NAT, y as poder generar trco que deba ser protegido a a mediante IPsec utilizando NAT traversal.

3.4.

Consideraciones de implementacin o

Como se ha podido deducir de los mtodos propuestos para analizar e los aspectos de conformidad con el estndar, para llevar a cabo todas las a pruebas es necesario poder enviar y recibir mensajes de negociacin de claves o y parmetros de seguridad, de caducidad de las mismas claves, etc. . . . Por a lo tanto, se debe disponer de una implementacin de IPsec que podamos o controlar y a la que podamos forzar a enviar mensajes incorrectos cuando sea necesario. Adems, esta implementacin debe ofrecernos la seguridad a o

Cap tulo 3. Anlisis de la Conformidad con el Estndar a a

66

de que, en el caso de que aparezcan problemas al establecer los tneles u criptogrcos, todos los problemas sern debidos a la implementacin que a a o est siendo analizada, y no a la que estamos utilizando para generar las a conexiones, etc. . . Mientras que es importante disponer de una implementacin que podao mos controlar segn nuestras necesidades (existen mltiples implementaciou u nes de cdigo abierto que nos permitir llevar a cabo esta tarea), el hecho o an de que la implementacin utilizada deba ser conforme a los estndares nos o a introduce en el problema de cmo validar si la implementacin es conforme o o o no. De hecho, el problema se presenta realmente al evaluar el correcto desarrollo de los protocolos, ya que para las herramientas criptogrcas podemos a usar los vectores de pruebas con las librer criptogrcas que se utilicen, de as a forma que podamos validar dichas librer Sin embargo, validar la ejecucin as. o del protocolo es un problema sin una solucin tan clara. o Por un lado se podr utilizar una implementacin de cdigo abierto y a o o llevar a cabo una auditor del cdigo para vericar si el comportamiento a o es correcto o no, pero este mtodo presenta los mismos problemas que se e comentaron para los mtodos de validacin del desarrollo en la seccin 2.2. e o o Por lo tanto, este mtodo deber ser evitado en la medida de lo posible. e a Por otro lado, podr amos desarrollar nuestra propia implementacin del o protocolo o arquitectura de seguridad correspondiente y someterla a un proceso de evaluacin estableciendo tneles criptogrcos con mltiples impleo u a u mentaciones diferentes. A medida que surjan problemas se deber estudiar a a qu implementacin de las implicadas en el tnel criptogrco se deben die o u a chos problemas. Este mtodo presenta la desventaja de que, al estudiar una e implementacin que no ha participado del proceso de depuracin de nuestra o o plataforma, no es posible determinar a priori si la presencia de problemas de interoperatividad se debe a la implementacin que est siendo evaluada o a o a la que se est utilizando para evaluar al resto. a Otra posible solucin pasar por la utilizacin de implementaciones o a o estandarizadas de los protocolos o arquitecturas de seguridad. En muchos casos, al tiempo que se estandariza un protocolo o arquitectura de comunicaciones el organismo internacional correspondiente publica implementaciones de ese protocolo o arquitectura de forma que estn disponibles para el pblie u co en general. En otros casos, como resultados de proyectos de investigacin o o de labores de evaluacin en centros pblicos, se pone a disposicin de la o u o comunidad internacional una implementacin que, sin ser ocial, s que es o conforme con lo estandarizado en los documentos correspondientes. En estos casos en los que estas implementaciones se encuentran disponibles, ser a posible utilizarlas como punto de partida para validar la conformidad de la implementacin que nos interesa. o En otro orden de cosas, es necesario tener en cuenta que para llevar

67

3.4. Consideraciones de implementacin o

a cabo todos los anlisis que se describirn en la memoria, ser necesario a a a disponer de una infraestructura de red que nos permita enviar trco a travs a e de los tneles criptogrcos que se establezcan. Por lo tanto, debe asegurarse u a el acceso correspondiente a la implementacin y su conguracin a travs de o o e la red (es decir, conrmando que no hay cortafuegos bloqueando el trco, a que la conguracin de los tneles criptogrcos no previene el env de o u a o la conguracin, etc. . . .). Idealmente, se contar con una infraestructura o a dedicada para llevar a cabo las pruebas en cuestin, lo que mejorar la o a ejecucin de los diferentes tests y evitar posibles falsos informes de error. o a Otra consideracin que hay que realizar es que es necesario disponer o de acceso a la conguracin de la implementacin para poder cambiarla a o o medida que la realizacin de las oportunas pruebas as lo requiera. Igualmeno te, ser obligatorio gestionar equipos que se encuentren en la red protegida a por la implementacin evaluada, para poder generar trco hacia el tnel o a u criptogrco cuando se requiera. a Por ultimo, es preciso destacar que el anlisis de la conformidad de a una implementacin de un protocolo o arquitectura de seguridad presenta o el problema del orden en el que deber evaluarse los diferentes factores: an Si se comienza evaluando la conformidad criptogrca nos encontramos con a que para probar la conformidad de los algoritmos utilizados debemos llevar a cabo un desarrollo, completo o parcial, de los protocolos de negociacin o y/o proteccin de la informacin. Sin embargo, si se comenzase evaluando o o la correcta implementacin de los protocolos nos encontrar o amos con que las herramientas criptogrcas son utilizadas desde el primer momento para a proceder con las negociaciones. Esto nos introduce en un problema circular de dependencias, con dif cil solucin prctica. En esta tesis se ha optado por comenzar evaluando la o a conformidad criptogrca, ya que de esta forma podremos descartar mua chos de los problemas que se presentan en las implementaciones de hoy en d Adems, la presencia de errores en la ejecucin de alguno de los proa. a o tocolos se manifestar en forma del mismo error, independientemente de a las herramientas criptogrcas utilizadas, lo que no ocurrir si el problea a ma es slo de una herramienta criptogrca. Mediante esta tcnica estamos o a e en disposicin de evaluar la conformidad criptogrca y el desarrollo de los o a protocolos de forma muy able, allanando el camino para las evaluaciones que siguen a aqullas. En cualquier caso, los errores detectados en esta fase e debern acompaarse de todos los datos que puedan ser recopilados, con el a n n de proporcionar informacin suciente para permitir detectar el error en o caso de que as sea.

Cap tulo 3. Anlisis de la Conformidad con el Estndar a a

68

Cap tulo 4

Anlisis del Rendimiento a

4.1. Introduccin o

En este cap tulo se describirn cules son los aspectos del rendimiento a a que es importante conocer en las implementaciones de protocolos y arquitecturas de seguridad, comparando estos aspectos con aquellos recogidos en otros conjuntos de pruebas de rendimiento para dispositivos y software de red propuestos por la comunidad cient ca. Est anlisis de la particularie a dad de los protocolos de seguridad en general servir de piedra angular para a presentar a continuacin los mtodos y herramientas necesarios para llevar o e a cabo una medicin de dichos aspectos de rendimiento, as como otras paro ticularidades que deben ser tenidas en cuenta al realizar estas mediciones. Con el n de poder referirnos genricamente a los protocolos y arquitecturas e de seguridad sin tener que utilizar todas las diferentes nomenclaturas existentes, en este cap tulo se hablar de asociacin de seguridad para referirnos a o al conjunto de parmetros negociados que denen cmo se protegern las a o a comunicaciones entre dos sistemas (concepto equivalente a las asociaciones de seguridad de IPsec y similar al de las sesiones SSL).

4.2.

Identicacin de los factores de rendimiento o

Como ya se ha comentado en la seccin 2.3.1, la evaluacin del rendio o miento de los protocolos de seguridad tiene su origen en la evaluacin del o rendimiento de los protocolos y redes de comunicaciones, compartiendo con esta rama las bases, tanto metodolgicas como de sujetos del anlisis, que o a conforman su estructura, aunque las diferencias entre los protocolos de comunicaciones con seguridad integrada y los protocolos sin ella hacen que ambas disciplinas se hayan alejado progresivamente en los ultimos aos. Por n este motivo nos encontraremos con que en mltiples casos los parmetros u a que se intentan evaluar son similares a los que se tienen en cuenta en la eva69

Cap tulo 4. Anlisis del Rendimiento a

70

luacin tradicional de redes y protocolos, aunque los motivos para realizar o las pruebas, as como los detalles de dichas pruebas, son muy diferentes.

4.2.1.

Anlisis de SSL a

Dado que la principal diferencia entre un protocolo de comunicaciones tradicional y un protocolo de seguridad es la inclusin de tcnicas o e criptogrcas para proporcionar determinados servicios de seguridad en el a protocolo de seguridad, comenzaremos nuestro anlisis estudiando cul es a a el impacto en el rendimiento al incluir estas herramientas criptogrcas en a un protocolo de comunicaciones en seguridad. Con este n se ha desarrollado una prueba de concepto con un cliente y servidor de echo (el cliente env un mensaje al servidor y ste devuelve el mismo mensaje) sobre TCP, a e y posteriormente se le han incluido caracter sticas de seguridad utilizando el protocolo SSL (Secure Socket Layer). Los motivos para utilizar SSL en esta prueba de concepto son varios: Por un lado, para obtener informacin o able acerca de los tiempos de ejecucin y recursos empleados es necesario o utilizar un proler, que se enlaza dinmicamente con el cdigo a analizar a o y registra los recursos utilizados, grafos de ejecucin, etc. . . . En el caso de o otros protocolos y arquitecturas como IPsec, dado que las implementaciones se integran con el ncleo del sistema operativo para poder crear capas adiu cionales en la pila TCP/IP de forma transparente a aplicaciones y usuarios, el uso de uno de estos proler representa una operacin compleja (ya que o obtendr amos informacin de todas las llamadas y funciones del ncleo del o u sistema operativo, entre las que habr que localizar las correspondientes a a IPsec) y poco able, dado que por su propia naturaleza los proler introducen retardos en la ejecucin del cdigo; si esos retardos se producen en o o el propio ncleo del Sistema Operativo, nos encontramos con que el rendiu miento que estamos midiendo tiene poco o nada que ver con el rendimiento real del protocolo de seguridad. Por otro lado, aunque los servicios de seguridad proporcionados por SSL e IPsec son, en muchos casos, similares (aunque aplicados a capas de la pila TCP/IP diferentes, o con herramientas criptogrcas ms o menos a a complejas y elaboradas), la complejidad de IPsec es mucho mayor. Esta elevada complejidad hace que al implementar una prueba de concepto que sirva de gu inicial a posteriores investigaciones se elija SSL, sealando en a n los resultados las posibles diferencias con las que nos podremos encontrar posteriormente, para evitar posibles confusiones. Las caracter sticas tcnicas de los sistemas utilizados para llevar a cabo e esta prueba de concepto aparecen recogidas en la Tabla 4.1 1 2 . Antes de
Las opciones del compilador utilizadas para la activacin y enlazado del proler no o aparecer recogidas en esta tabla 2 La opcin del compilador -lgnutls se utiliza unicamente para las versiones del cliente o
1

71

4.2. Identicacin de los factores de rendimiento o

proceder a analizar los resultados, hay que destacar dos aspectos importantes de esta prueba de concepto. El primero de ellos es el hecho de que la propia utilizacin de los proler introduce variaciones en el rendimiento o que los sistemas, ralentizando su ejecucin debido a las medidas que conso tantemente se estn tomando para proporcionar la informacin deseada. Por a o otro lado, tambin hay que denir el concepto de solicitud de memoria e que aparecer posteriormente como un dato proporcionado por uno de estos a proler: Solicitud de memoria hace referencia a la cantidad de memoria que un programa solicita al sistema operativo a travs de funciones como e malloc en C. Por lo tanto, esta solicitud de memoria no hace referencia a la memoria real que necesita un programa para ejecutarse (ya que la memoria utilizada por las variables que no requieran de solicitud de memoria expl cita por parte del programador no aparecen recogidas en el informe), ni al tamao mximo del programa en memoria (ya que esas solicitudes de memoria n a sern liberadas en un momento u otro mediante instrucciones free), valor a que aparece en esta memoria como Memoria Residente (tamao mximo n a del programa en RAM) y Memoria Virtual (cantidad total de memoria reservada para el programa). Como veremos posteriormente, todos estos datos proporcionan informacin acerca del uso intensivo de la memoria por parte o de las implementaciones de herramientas criptogrcas muy valiosa. a Tabla 4.1: Especicaciones de los sistemas empleados en la prueba de concepto de SSL Pentium M Centrino 800 MHz 1024 MB en cada equipo Fast Ethernet con conexin directa o entre cliente y servidor Sistema Operativo Gentoo Linux con kernel 2.6.15 Compilador GCC 3.4.5 Opciones del Compilador -Wall -O3 -lgnutls Librer Criptogrcas GnuTLS 1.2 as a Algoritmos Criptogrcos AES 256 & SHA1 a Mtodo de Autenticacin Certicados X.509 e o Proler de CPU FunctionCheck Prolers de Memoria ccmalloc y exmap Procesadores Memoria Red

Los tiempos de ejecucin obtenidos para el cliente se muestran en la o Figura 4.2.1, mientras que los resultados del servidor pueden verse en la Figura 4.2.1. En ambos casos la serie nombrada GnuTLS 1 se reere a una implementacin del canal seguro con SSL en el que cliente y servidor unio
y del servidor que utilizan SSL

Cap tulo 4. Anlisis del Rendimiento a

72

Figura 4.1: Tiempo empleado por el cliente en la trasmisin y recepcin de o o una determinada cantidad de datos utilizando diferentes canales de comunicacin o camente cifran los datos que se transmiten, mientras que en la implementacin GnuTLS 2 se incluye la autenticacin tanto de cliente como de servidor. o o Como podemos observar, al utilizar el canal protegido con SSL el tiempo necesario para la transmisin de la misma cantidad de informacin se mulo o tiplica por ms de 20 con respecto a la transmisin de la misma cantidad de a o informacin sin ningn tipo de proteccin. Adicionalmente, podemos apreo u o ciar cmo la implementacin que lleva a cabo la autenticacin del cliente y o o o del servidor ofrece un rendimiento ligeramente peor. En el caso concreto de estas pruebas de concepto la diferencia es m nima, pero extrapolando esta informacin a IPsec, en el que peridicamente es necesario descartar la inforo o macin criptogrca negociada y volver a acordar nuevas claves basndose o a a en la informacin de autenticacin, el impacto puede ser mucho mayor. Asio o mismo, es necesario considerar el impacto en entornos en los que mltiples u clientes se autentican frente al mismo servidor, ya que lo que para el cliente es una unica autenticacin y puede no representar una sobrecarga consi o derable, en el servidor se convierte en un gran volumen de operaciones de autenticacin, lo que s que puede representar un impacto importante en o el rendimiento. Estas situaciones son ms propicias a aparecer en aquellos a entornos en los que mltiples cliente se conectan al mismo servidor de seguu ridad en un corto espacio de tiempo, como puede ser el inicio de la jornada laboral en una empresa.

73

4.2. Identicacin de los factores de rendimiento o

Figura 4.2: Tiempo empleado por el servidor en la transmisin y recepcin o o de una determinada cantidad de datos utilizando diferentes canales de comunicacin o En lo tocante a la utilizacin de la memoria, en la Tabla 4.2 podemos ver o los resultados ofrecidos por ccmalloc para cada una de las implementaciones de cliente y servidor3 . El efecto que estas solicitudes de memoria tienen en el rendimiento es muy importante, ya que, como primera conclusin que o podemos extraer de estos resultados, la cantidad de memoria disponible en el sistema denir qu tipo de autenticacin es posible utilizar (ya que la a e o cantidad de memoria necesaria para utilizar un secreto preestablecido (por ejemplo, una contrasea) no es la misma que la necesaria para utilizar un n certicado de clave pblica X.509 tanto en cliente como en el servidor), y, por u extensin, cules son los requisitos m o a nimos para los diferentes dispositivos que deseen establecer un tnel criptogrco utilizando dichos mtodos de u a e autenticacin. o Por otro lado, podemos ver tambin que la diferencia de solicitudes e de memoria entre las diferentes implementaciones de SSL no representa la mayor parte de dichas solicitudes, por lo que podemos deducir que son las operaciones de proteccin de la informacin (es decir, el cifrado y el deso o cifrado). Esto quiere decir que el cifrado y descifrado de bloques de datos no son unicamente operaciones costosas en tiempo de CPU, sino tambin e
Dado que las librer de comunicaciones del sistema no fueron compiladas con los as enlaces del proler para obtener informacin acerca de ellas, ccmalloc devuelve un o valor de 0 reservas de memoria para el servidor en claro.
3

Cap tulo 4. Anlisis del Rendimiento a

74

Tabla 4.2: Solicitudes de memoria (en KBytes) durante la ejecucin de la o prueba de concepto Cantidad Cliente en claro Cliente GnuTLS 1 Cliente GnuTLS 2 de Datos 1 MB 1,4 10.011,3 10.171,1 5 MB 1,4 48.873,4 49.023,1 10 MB 1,4 97.448,6 97.609,0 50 MB 1,4 486.046,3 486.196,1 100 MB 1,4 971.786,4 971.918,2 Servidor en claro Servidor GnuTLS 1 Servidor GnuTLS 2 1 MB 0 10.200,7 10.588,4 5 MB 0 49.233.7 49.759,4 10 MB 0 97.852.6 98.107,9 50 MB 0 486.325.7 486.587,3 100 MB 0 972.441.8 972.517,9

en memoria, y por lo tanto, esto habr de tenerse en cuenta al disear el a n conjunto de pruebas que evalen en rendimiento del sistema. En concreto, u ser necesario evaluar cmo afecta la existencia de tneles criptogrcos por a o u a los que se transmite informacin a la capacidad de establecimiento de nuevos o tneles criptogrcos, as como cul es el impacto de variar la velocidad a u a a la que se transmite informacin por esos tneles (y por ende, la velocidad o u a la que la implementacin del protocolo de seguridad solicita memoria al o sistema). En cuanto a la memoria realmente utilizada por cada una de las implementaciones, en la Tabla 4.3 podemos ver el resumen de los datos obtenidos con la herramienta Exmap acerca de la memoria residente (es decir, la memoria reservada en la RAM f sica del equipo) y la memoria virtual (mximo a tamao de memoria que puede utilizar el proceso) para cada una de las n implementaciones, tanto clientes como servidores. Dado que la cantidad de memoria reservada en un momento dado y en total por las implementaciones no var con el tamao de la informacin transmitida4 , en esta tabla a n o podemos ver cmo unicamente disponemos de los dos datos ya comentados o para cada implementacin. o

Esto se debe a que al tener que solicitar una nueva porcin de memoria se libera la o anterior, aspecto que no quedaba reejado si unicamente nos atenemos a los datos de la Tabla 4.2

75

4.2. Identicacin de los factores de rendimiento o

Tabla 4.3: Tamao de Memoria Residente y Virtual (en KBytes) de las n pruebas de concepto Transferencia en GnuTLS 1 GnuTLS 2 claro Residente 77.8 428.4 534.2 Cliente Virtual 1492 2676 2688 Residente 63.0 426.6 529.8 Servidor Virtual 1360 2672 2680

4.2.1.1.

Prediccin del rendimiento de las soluciones de seguridad o

Uno de los motivos por los que es tan importante el conocer el rendimiento de nuestra solucin de seguridad es que no es factible asegurar a o priori el rendimiento que una determinada solucin de seguridad va a poo der proporcionar, incluso en sistemas similares, dado que el rendimiento de las operaciones criptogrcas es variable. Factores como la optimizacin por a o hardware, la inclusin de mltiples ncleos en cada CPU, la optimizacin o u u o que haya introducido el compilador, otros procesos que se ejecuten en el sistema, etc. . . . Todos estos aspectos inuyen en gran medida en el rendimiento que nuestro sistema pueda ofrecer, y dicultan sobremanera la estimacin o del servicio que puede ofrecer nuestro sistema, como puede verse en [104] y en [7]. En estos dos estudios se puede ver que el impacto de protocolos de seguridad (IPsec y SSL en el primero de ellos, y exclusivamente SSL en el segundo) en el rendimiento var entre el 10 y el 90 %, segn los algoritmos de a u cifrado y resumen que se utilicen, si es posible utilizar tarjetas criptogrcas a o implementacin hardware de las herramientas criptogrcas utilizadas, la o a diferencia entre el tamao de bloque de los cifradores y el tamao de la n n informacin a proteger, la existencia de redundancia o balanceo de carga en o el servicio de seguridad y si se deciden reutilizar claves criptogrcas o no. a Para llevar a cabo un estudio acerca del rendimiento en el cmputo de o operaciones criptogrcas y la viabilidad de la prediccin de este rendimiento a o de forma acertada, se ha realizado un anlisis comparativo utilizando varios a equipos con diferentes familias de procesadores. En este caso, y debido al diseo de las pruebas llevadas a cabo, unicamente la informacin acerca del n o procesador es relevante, dado que nunca se llevan a cabo pruebas en paralelo ni se trabaja con ms de 8 KBytes de datos simultneamente. La lista de a a equipos involucrados en la evaluacin puede verse en la Tabla 4.1. o Las pruebas llevadas a cabo han consistido en la realizacin de los test o de velocidad incluidos en OpenSSL, que miden la cantidad de operaciones criptogrcas que un procesador es capaz de realizar por unidad de tiempo, a

Cap tulo 4. Anlisis del Rendimiento a Tabla 4.4: Equipos utilizados en la evaluacin del rendimiento o Equipo Equipo Equipo Equipo Equipo Equipo Equipo 1 Intel Pentium II 350 MHz 2 AMD Athlon K7 550 MHz 3 Intel Pentium III 750 MHz 4 Intel Pentium M (Centrino) 2.0 GHz 5 Intel Pentium D (Dual Core) 2.8 GHz 6 AMD Athlon64 3000+ 2.0 GHz 7 Intel Pentium IV 3.6 GHz

76

Tabla 4.5: Comparacin del rendimiento de varios equipos al cifrar y calcular o resmenes criptogrcos, en miles de operaciones por segundo u a MD4 MD5 SHA1 RC4 Blowsh AES128 1 2 3 4 5 57.453 111.662 150.733 346.824 411.080 47.508 96.600 114.691 326.515 508.208 18.569 58.580 62.300 206.982 282.564 35.821 76.149 82.706 311.886 114.466 11.859 23.399 26.206 74.069 103.244 7.264 14.317 16.512 45.385 44.828 6 396.987 234.239 190.068 157.284 78.731 99.555 7 523.556 651.656 361.643 143.746 132.831 84.574

ofreciendo informacin de esta velocidad para cada algoritmo de cifrado y o rma disponible en el sistema. En la Tabla 4.5 se encuentran reejados los resultados obtenidos a la hora de evaluar el rendimiento de los equipos al realizar operaciones de cifrado sobre bloques de 8KBytes de datos, utilizando los algoritmos de cifrado RC4, Blowsh y AES128, y al calcular resmenes criptogrcos de esos bloques u a de datos con las funciones MD4, MD5 y SHA1. Esta misma informacin o se puede encontrar en la Figura 4.3, para poder observar la evolucin y o comparacin de los resultados de forma grca. Como podemos observar, o a la velocidad del procesador no es un indicativo vlido del rendimiento que a dicho procesador es capaz de ofrecer a la hora de cifrar o calcular resmenes u criptogrcos de bloques de informacin. a o Como podemos observar, estas pruebas ofrecen resultados sorprendentes, tanto en cuanto un procesador concreto aumenta de forma sustancial su rendimiento al utilizar un algoritmo de cifrado determinado (como es el caso del Pentium M (Centrino) al cifrar datos con RC4, o el AMD Athlon64 al utilizar AES128), mientras que otros procesadores reducen considerablemente su capacidad de proteger los datos al utilizar otros algoritmos (como es el caso del Pentium IV y el Pentium D (Dual Core) con RC4, o el Pentium

77

4.2. Identicacin de los factores de rendimiento o

Figura 4.3: Cantidad de operaciones de cifrado por segundo que llevan a cabo los equipos evaluados

M (Centrino) al cifrar con Blowsh). Esta alta variabilidad se debe a los cambios en la arquitectura de los procesadores introducidos de una familia a otra, y al diseo de base de n cada uno de los fabricantes probados, y que acaban repercutiendo en la capacidad para realizar determinadas operaciones de bajo nivel de forma ms eciente, afectando a otras. Dado que los algoritmos criptogrcos se a a denen principalmente como conjuntos de operaciones de bajo nivel (tales como desplazamientos a nivel de bit, permutaciones de bits, etc. . . un cambio en el rendimiento de cualquiera de esas operaciones afectar enormemente a al rendimiento que el procesador ofrece con dicho algoritmo criptogrco. a En otros casos, algunas optimizaciones, tales como la integracin del o procesador de la tarjeta wireless 802.11 con el procesador del sistema en los equipos Pentium-M (Centrino) hace que el rendimiento de los algoritmos criptogrcos utilizados en esas redes (en concreto, RC4) se vea aumentado a debido a que el procesador del sistema cuenta con un procesador dedicado y optimizado para dichos algoritmos. En cuanto a los algoritmos de rma digital y vericacin, en la Tabla o 4.6 y en la Figura 4.4 podemos observar cules son los resultados obtenidos. a Como podemos observar, el equipo con un procesador AMD Athlon64 ofrece un rendimiento muy superior al resto, algo que sorprende a tenor de los resultados obtenidos con los algoritmos de cifrado y resumen criptogrco. a

Cap tulo 4. Anlisis del Rendimiento a

78

Tabla 4.6: Comparacin del rendimiento de varios equipos al cifrar datos, o en miles de operaciones por segundo 1 RSA512 Firma 194 RSA512 Verif. 2.007 DSA512 Firma 230 DSA512 Verif. 140 2 414 5.053 544 458 3 4 5 517 1.414 1.165 5.699 16.102 13.317 631 1.794 1.429 528 1.549 1.207 6 3.811 46.255 6.472 5.719 7 1.405 16.478 1764 1514

Figura 4.4: Cantidad de operaciones de rma y vericacin que llevan a cabo o los equipos evaluados

79

4.2. Identicacin de los factores de rendimiento o

Asimismo, tambin es destacable el hecho de que el Pentium M y el e Pentium IV ofrecen un rendimiento prcticamente idntico, pese a la difea e rencia de velocidad y a lo dispares que son los resultados obtenidos en las pruebas anteriores.

4.2.2.

Resultados del anlisis a

Como se puede deducir del apartado anterior, la utilizacin de mecaniso mos de seguridad hace que los protocolos de seguridad requieran de mayores recursos al establecer conexiones y proteger la informacin que por ellas se o transmita. Este hecho puede ser utilizado por atacantes para lanzar ataques de denegacin de servicio contra nuestra infraestructura de red de mltiples o u formas diferentes. Algunos ejemplos podr ser: an Solicitar el establecimiento de nuevos t neles criptogrcos y u a abortar la operacin cuando todav no se ha completado la o a negociacin, con el consiguiente gasto de ciclos de CPU y memoria. o Env de falsos paquetes de los protocolos de negociacin o o informando de falsos errores forzando renegociaciones de las claves en el mejor de los casos, y consiguiendo cerrar el tnel criptogrco en u a el peor. Adems, algunos ataques podr ser lanzados por usuarios leg a an timos de la arquitectura, incluso inconscientemente. Por ejemplo, como ya se ha comentado, en la versin 2 de IKE las partes no negocian los valores de caduo cidad de las claves, por lo que una implementacin congurada con valores o extremadamente bajos puede forzar a ambas partes a utilizar ms recursos a en renegociar informacin criptogrca que en proteger informacin. o a o Aunque algunos de estos ataques de denegacin de servicio pueden no o llegar a evitar que la implementacin ofrezca servicio a los usuarios leg o timos, s que pueden lograr que la calidad del servicio ofertado sea de muy baja calidad (reduccin del ancho de banda, retardos, etc. . . ), consiguiendo que o los usuarios eviten utilizar la arquitectura de seguridad para poder llevar a cabo sus tareas, como ya ha ocurrido con otras herramientas anteriormente ([6], [150]). Con todo lo visto en esta seccin podemos elaborar una lista de los aso pectos que es interesante evaluar en una implementacin de un protocolo o o arquitectura de seguridad en relacin con el rendimiento, relacionando cada o elemento con aquellas caracter sticas del sistema con las que est relacionaa do, y otros elementos que pueden inuir en dichos aspectos.

Cap tulo 4. Anlisis del Rendimiento a

80

4.2.3.

Ancho de banda

El ancho de banda que puede ofrecer una implementacin de un proo tocolo de seguridad es una medida fundamental del rendimiento que puede ofrecer dicha implementacin. Como podemos deducir, la autenticacin y o o negociacin de nuevas claves no afectan realmente al ancho de banda que o puede ofrecer una implementacin, ya que son operaciones que tienen lugar o en momentos muy concretos de todo el proceso de intercambio de informacin. Por lo tanto, sern la implementacin que se haya realizado de los o a o protocolos de proteccin de la informacin la que debamos evaluar. o o Dado que estos protocolos son aplicaciones criptogrcas de los algorita mos y tcnicas negociados en fases anteriores, nos encontramos con que la e mayor limitacin del sistema en cuanto al ancho de banda ser (adems de o a a aspectos f sicos de la propia red, como el tipo de red utilizado, el cableado, las tarjetas de red, etc. . . .) la potencia de la(s) CPU(s) del sistema. Como vimos anteriormente, las operaciones criptogrcas tienen mayores requisia tos de tiempo de CPU que su equivalente en claro, por lo que el principal recurso que afectar al ancho de banda ser la CPU. Para poder evaluar a a cul es el mximo ancho de banda que una implementacin puede ofrecer, a a o deberemos utilizar un unico tnel criptogrco por el que se transmita infor u a macin tan rpido como sea posible (en el apartado 4.4 se elaborar con ms o a a a detalle las condiciones y parmetros que deben regular dicha transmisin de a o informacin). o Adicionalmente, tambin hemos visto que las necesidades de los proe tocolos de seguridad en general no son unicamente tiempo de CPU, sino tambin memoria para poder llevar a cabo las operaciones criptogrcas. e a Sin embargo, las necesidades globales de un unico tnel criptogrco no u a representan grandes problemas en proporcin con el cifrado de informao cin, incluso para los dispositivos con mayores limitaciones. Por este motivo o ser necesario evaluar cmo afecta la existencia de mltiples tneles cripa o u u togrcos simultneos al ancho de banda que puede ofrecer una implemena a tacin concreta. Por cada tnel criptogrco deber transmitirse el volumen o u a a de trco equivalente al reparto equitativo del ancho de banda de un unico a tnel entre todos los tneles que se establezcan. De esta forma estaremos en u u condiciones de evaluar el impacto de la memoria del sistema analizado en el rendimiento. Evaluar el rendimiento de cada una de las suites criptogrcas sopora tadas por un dispositivo nos ayudar a seleccionar aquellas suites que, ofrea ciendo el nivel de seguridad deseado, son capaces de ofrecer un mayor ancho de banda a cada usuario, lo que, adems de las propias ventajas de esta a conguracin, hace que el sistema presente un mejor comportamiento ante o ataques de denegacin de servicio contra la implementacin. o o Por ultimo, debemos destacar que el rendimiento de diferentes suites

81

4.2. Identicacin de los factores de rendimiento o

criptogrcas es completamente diferente en diferentes plataformas hardwaa re, diferentes sistemas operativos, etc. . . ., como hemos podido observar a la luz de los resultados obtenidos en el Apartado 4.2.1.1. Adems, no es posible a realizar suposiciones, por muy generales que sean, referente al rendimiento que determinados algoritmos pueden ofrecer, ya que debido a optimizaciones o implementaciones defectuosas podemos encontrarnos con que algoritmos que deb ofrecer sobre el papel un rendimiento mejor que otros resultan ser an mucho ms lentos. Por este motivo, el ancho de banda que una implemena tacin puede ofrecer deber ser evaluado para todos las suites criptogrcas o a a (algoritmo de cifrado, funcin resumen, mtodo de autenticacin) en las que o e o se est interesado conocer el rendimiento. e

4.2.4.

Mximo n mero de t neles criptogrcos establecidos a u u a

Dado que en el establecimiento de cada tnel criptogrco se negou a cian unos determinados parmetros que posteriormente sern utilizados paa a ra proteger la informacin, la cantidad de tneles que una implementacin o u o determinada puede mantener simultneamente es tambin limitada, princia e palmente por la memoria de la que pueda disponer para almacenar dichos parmetros negociados. El uso de la CPU en este proceso no es tan impora tante, ya que nuestro principal inters en este momento es la utilizacin de e o la memoria como l mite a conexiones futuras. De esta forma estaremos en condiciones de evaluar la cantidad de tneles que un dispositivo es capaz de u aceptar sin descartar ninguna conexin. o Para evaluar este importante aspecto ser necesario proceder al estaa blecimiento de nuevos tneles criptogrcos hasta encontrar el l u a mite en el que la implementacin estudiada debe descartar alguna conexin (bien la o o nueva conexin entrante, bien una conexin establecida anteriormente). Es o o importante resaltar que por los tneles que se establezcan no deber transu a mitirse informacin, ya que dicha transmisin requerir de memoria que no o o a ser empleada en aceptar nuevas conexiones, por lo que el resultado que a obtendremos no ser able. Por este mismo motivo es necesario que los a establecimientos de conexin estn espaciados una cantidad prudencial de o e tiempo, para as evitar que las operaciones criptogrcas asociadas a la nego a ciacin de un tnel afecten al establecimiento de otros tneles, especialmente o u u cuando la cantidad de tneles establecidos es elevada. u En cuanto a la inuencia de la suite criptogrca que se utilice, al igual a que ocurr en el caso del ancho de banda, es necesario realizar diferentes a pruebas y anlisis utilizando todas las suites en las que estemos interesados. a Sin embargo, al contrario de lo que ocurr en el ancho de banda, el impacto a de elegir una suite u otra en los resultados no deber ser (a priori) tan a acusado, ya que la mayor de la informacin que se utiliza en las fases de a o negociacin de los protocolos de seguridad tiene un tamao jo, indepeno n

Cap tulo 4. Anlisis del Rendimiento a

82

dientemente de la suite criptogrca, protocolos que se protejan, etc. . . . a

4.2.5.

Capacidad de establecimiento de nuevos t neles cripu togrcos a

Como complemento al mximo nmero de tneles criptogrcos que a u u a nuestra implementacin es capaz de establecer, debemos conocer cules son o a las capacidades de establecimiento de nuevos canales seguros, es decir, cmo o se comporta nuestra implementacin cuando debe hacer frente al estableo cimiento simultneo de mltiples tneles criptogrcos. Dado que en este a u u a aspecto estn involucrados tanto CPU como memoria, podemos ver cmo se a o aunan parte de los anlisis realizados para el ancho de banda con el nmero a u mximo de tneles. a u Por lo tanto, ser necesario establecer rfagas de establecimientos de a a conexin y evaluar cul es el tiempo que la implementacin del protocolo de o a o seguridad necesita para establecer los tneles criptogrcos y estar disponiu a ble para la siguiente rfaga, hasta completar el nmero mximo de tneles a u a u que se deni anteriormente. En el caso de que alguna de las conexiones se o rechace, deberemos iniciar las pruebas desde el principio, ya que el sistema no es capaz de procesar las conexiones al ritmo que se le est exigiendo. a Este aspecto es importante de cara a conocer cules son las capacidades a de funcionamiento de nuestro sistema, de cara a ayudarnos a realizar una planicacin de la infraestructura que sea able y que nos evite el llevar a o cabo inconscientemente un ataque de auto denegacin de servicio en nueso tra propia red. Por ejemplo, un escenario en el que mltiples clientes deben u conectarse de forma segura a una red corporativa puede sufrir de un ataque como el comentado si alguno de los usuarios, conscientemente o inconscientemente, decide crear un tnel criptogrco nuevo por cada conexin nueva u a o con la red corporativa, en lugar de proteger todas esas conexiones con el mismo tnel. u Por lo tanto, la medicin de este parmetro de rendimiento deber hao a a cerse en condiciones cercanas a la realidad, en las que por los tneles preu viamente establecidos hay trco que est siendo protegido, y que requiere a a de ciertos recursos de la implementacin de IPsec para poder continuar con o su ujo de intercambio de informacin. Consiguientemente, un factor imo portante en estas pruebas es el trco que se transmite por cada uno de los a tneles criptogrcos establecidos, ya que en este caso no estamos evaluando u a unicamente la capacidad de tener los tneles establecidos, sino la capacidad u de responder a rfagas de trabajo, lo que implica tiempo de CPU (para llea var a cabo las operaciones criptogrcas asociadas a la negociacin), y que a o por lo tanto se ver afectada por la ocupacin de la CPU al cifrar y descifrar a o el trco. a

83

4.3. Medicin de los factores de rendimiento o

4.2.6.

Tiempo de proceso

El ultimo de los aspectos que es necesario evaluar para completar el estudio del rendimiento es el del tiempo necesario para establecer un tnel u criptogrco, o dicho de otra manera, cul es la sobrecarga que introducen a a la(s) fases de negociacin, as como las operaciones de cifrado y descifrado o en el protocolo que se utilice. De esta forma se evaluar cul es el impacto de a a proteger con el protocolo elegido aquellos servicios que son dependientes del tiempo, tales como la transmisin de contenidos multimedia (videoconfereno cia, voz sobre IP, etc. . . .) o aplicaciones de tiempo real. Con esta informacin o nos encontraremos en condiciones de decidir si la sobrecarga que se introduce es aceptable para los servicios que se desean proteger, o si por el contrario dicha sobrecarga har el servicio inservible. a Dado que algunos protocolos, como IKE en IPsec, permiten la reutilizacin de parmetros negociados para posteriores negociaciones (en concreto o a IKE permite reutilizar material de la Fase 1 para negociaciones en la Fase 2, y a su vez tambin es posible reutilizar la negociacin de la Fase 2 para e o mltiples tneles ESP o AH), es necesario conocer cul es la sobrecarga que u u a introduce cada fase por separado, as como el conjunto completo de negocia ciones. De esta forma nos encontramos en condiciones de decidir cul de las a conguraciones de agrupamiento y reutilizacin que ofrece IPsec es la que o ms se ajusta a nuestras necesidades. a Dado que en este caso el unico factor involucrado es la capacidad para realizar las operaciones criptogrcas de las diferentes negociaciones de la a forma ms rpida posible, la potencia de clculo de la implementacin es a a a o el unico aspecto que se evala. Por este motivo, y como ya se ha analizado u anteriormente, es necesario realizar mltiples pruebas en las que se evalen u u los tiempos necesarios cuando se utilizan diferentes suites criptogrcas. a

4.3.
4.3.1.

Medicin de los factores de rendimiento o

Ancho de banda

Para evaluar el ancho de banda que la implementacin de un protocolo o o arquitectura de seguridad puede ofrecer es necesario conocer qu informacin e o acerca del ancho de banda nos interesa, ya que el mximo ancho de banda a depende de factores tales como el tipo de trco que se transmite, si el a trco es entrante o saliente (ya que las operaciones de descifrado son ms a a complejas computacionalmente y por lo tanto requieren de mayor cantidad de recursos), etc. . . Por lo tanto, una primera necesidad para llevar a cabo esta medida es la de conocer qu tipo de trco queremos utilizar para llevar a cabo e a la evaluacin del rendimiento. Mientras que trco genrico (como por o a e

Cap tulo 4. Anlisis del Rendimiento a

84

ejemplo slo trco UDP, o slo trco TCP) nos dar informacin acerca o a o a a o de las capacidades mximas de nuestro sistema, dichos modelos de trco a a son irreales, y por lo tanto no son utiles desde un punto de vista prctico. a Por otro lado, un modelo de trco ms realista (por ejemplo, 20 % de a a trco UDP y 80 % de trco TCP), aunque ms realistas, presentan el a a a problema de que su medicin nunca ofrecern informacin acerca de las o a o mximas posibilidades de la implementacin, sino que unicamente presentan a o datos concretos del modelo utilizado. Para solventar este problema, en la metodolog se apuntarn ciertos a a modelos o perles de trco que debern ser utilizados para las pruebas a a de rendimiento de forma obligatoria para obtener informacin acerca de las o mximas capacidades del sistema, y se permitir al usuario utilizar sus proa a pios modelos de trco para que as obtenga informacin concreta acerca a o del ancho de banda que puede obtener de acuerdo a sus patrones de utilizacin de la red de comunicaciones actuales. Con nes meramente orientativos, o se incluirn en la metodolog algunos patrones de trco que representan a a a aproximadamente perles comunes de utilizacin de los recursos de red. Un o anlisis ms detallado de los perles de trco se realizar en el apartado a a a a 4.4. El siguiente problema que se nos plantea es cmo llevar a cabo la medida o de estos valores. Dado que es posible utilizar protocolos como UDP, que no cuentan con medidas de noticacin de prdida de paquetes o de congestin o e o de la red, los unicos puntos en los que se puede realizar la medida es en los puntos nales de la comunicacin, ya que unicamente el trco que haya o a llegado a su destino ha sido procesado por la implementacin evaluada. En o la Figura 4.3.1 podemos ver un ejemplo ilustrativo: El ancho de banda del trco A se computar en el equipo 2, mientras que el ancho de banda del a a trco B ser medir en el equipo 1. El ancho de banda total ser la suma a a a a de ambos valores. Para evitar sobrecargar innecesariamente los equipos que establecen los tneles criptogrcos unicamente se establecer un tnel criptogrco con u a a u a el que se proteger todo el trco que se genere. Adicionalmente, no es a a recomendable utilizar ms de un equipo origen y destino en cada extremo a de los tneles, con el n de evitar sobrecargas en la red que pudieran alterar u los resultados de nuestras mediciones.

4.3.2.

Mximo n mero de canales seguros simultneas a u a

Al evaluar el mximo nmero de conexiones seguras que una implemena u tacin de un protocolo de seguridad puede mantener abiertas simultneao a mente, es necesario evaluar cules son los parmetros que inuyen en la a a capacidad de negociar canales seguros. Como en este caso no estamos evaluando la rapidez de negociacin de nuevos tneles criptogrcos, el factor o u a

85

4.3. Medicin de los factores de rendimiento o

Figura 4.5: Esquema de medicin del ancho de banda. o

que ms inuencia tiene es la memoria del dispositivo. Sin embargo, al llea var a cabo un anlisis en profundidad nos encontramos con que, al acercarse a a los l mites de canales de seguridad que pueden establecerse, la respuesta de las implementaciones va hacindose cada vez ms lenta. Por este motivo e a es necesario que la evaluacin de la cantidad de tneles criptogrcos que o u a puede establecer la implementacin que se est estudiando se lleve a cabo o a utilizando la menor cantidad de recursos posibles para cada asociacin de o seguridad. La solucin a este problema pasa por establecer canales seguros en los o que, una vez establecido el tnel criptogrco, no se transmite informacin u a o por dicho tnel. Sin embargo, la comunicacin sigue establecida (mediante u o la utilizacin de un protocolo orientado a conexin, como TCP) y por este o o motivo no es viable que ninguna de las implementaciones fuerce el cierre de ninguna de las conexiones seguras establecidas. Adicionalmente, para evitar que se produzcan renegociaciones de las claves criptogrcas mientras se a lleva a cabo esta prueba, se congurarn ambas implementaciones de forma a que la caducidad de las claves sea un valor muy alto en el tiempo, superior al que se emplear en este anlisis. a a Un problema adicional que nos podemos encontrar es que, a partir de cierto volumen de conexiones seguras establecidas, el establecimiento de nuevas conexiones requiere de un tiempo lo sucientemente elevado como para que el solapamiento de dos solicitudes de establecimiento de conexin cono lleve el rechazo de una de ellas, aun cuando la implementacin sea capaz de o establecer ms tneles criptogrcos. a u a Para solventar este problema en la metodolog se propone la repeticin a o de esta prueba separando las solicitudes de establecimiento de nuevas conexiones seguras con tiempos crecientes. En el momento en que varias pruebas generan los mismos resultados, habiendo espaciado sus solicitudes unos intervalos de tiempo mayores cada vez, podemos concluir que la cantidad alcanzada de conexiones seguras es el mximo nmero que puede soportar a u la implementacin. o Hay que destacar que, dado que la cantidad de conexiones seguras que puede soportar una implementacin de seguridad puede ser muy elevado, la o

Cap tulo 4. Anlisis del Rendimiento a

86

forma de evaluar este parmetro requerir el establecimiento de conexiones a a seguras independientes para cada comunicacin que se establezca entre las o redes protegidas por las implementaciones, sin que se agrupe el trco de a acuerdo a ningn parmetro, con el n de facilitar la prueba y evaluacin u a o de este parmetro. a

4.3.3.

Capacidad de establecimiento de canales seguros

Como combinacin de las medidas de ancho de banda y mximo nmero o a u de canales seguros surge la medicin de la capacidad de establecimiento de o conexiones seguras. Esta medida combina parte de las caracter sticas de la medicin del ancho de banda (en cuanto a que ser necesario generar trco o a a para controlar el ancho de banda en cada tnel criptogrco), y parte de las u a caracter sticas del establecimiento de conexiones seguras. Sin embargo, la problemtica para medir este factor es menor que en a casos anteriores: En este caso el tipo de trco que se utiliza no es importante, ya que a al dividir el ancho de banda entre mltiples conexiones ningn canal u u llegar a tener por s mismo un porcentaje de uso de la red tan elevado a que se vea afectado por el tipo de protocolo utilizado5 . S que debe utilizarse un protocolo orientado a conexin para facilitar la medicin o o del trco cursado. a El tiempo que se debe dejar entre las solicitudes de negociacin de o nuevas conexiones es uno de los factores que se pretenden medir en esta prueba, por lo que no es necesario llevar a cabo ninguna suposicin o o introducir un valor preliminar a la espera de los resultados. Por estos motivos, el anlisis de la capacidad de establecimiento de a conexiones seguras se evaluar estableciendo una comunicacin entre las a o redes protegidas que obligue a solicitar una nueva conexin para proteger o esa comunicacin, y procediendo a transmitir por dicho tnel criptogrco o u a informacin, de tal forma que se utilice un ancho de banda predenido. o

4.3.4.

Tiempo de proceso

Al evaluar el tiempo de proceso de cada uno de los protocolos que conforman un protocolo o arquitectura de seguridad nos encontramos con el problema de que la arquitectura de red utilizada para conectar los dispositivos que establecen los tneles criptogrcos introduce retardos en las u a
Habitualmente todos los protocolos de red pueden utilizar un mximo de, al menos, a el 60 % del ancho de banda mximo de la red sin tener que recurrir a optimizaciones de a ning n tipo u
5

87

4.4. Aspectos a tener en cuenta

comunicaciones. Este factor nos impedir evaluar cuanto tarda exactamente a la implementacin en llevar a cabo todas las operaciones necesarias para o establecer el tnel criptogrco, ya que no podemos tomar medidas ables u a en nuestra implementacin, ni podemos acceder a los registros de la imo plementacin analizada. Sin embargo, podemos obtener informacin acerca o o de cunto tiempo tarda, visto desde la implementacin que controlamos, lo a o que viene a representar el tiempo tal y como lo percibe el usuario, no el procesador de red. Por lo tanto, aunque utilizaremos nuestra implementacin para ofrecer o informacin acerca del tiempo empleado para llevar a cabo la negociacin o o de cada una de las fases de negociacin y para comenzar la transmisin de o o informacin protegida mediante los parmetros negociados, los valores que o a ofrecen informacin ms interesante son los que provengan de capturar el o a tiempo m nimo desde que se env un mensaje que requiere del establecia miento de una nueva asociacin de seguridad hasta que se recibe la respuesta o a dicho mensaje. Este factor de rendimiento es muy dependiente de la infraestructura hardware que se est utilizando para llevar a cabo las pruebas: una infraese tructura m nima, con conexiones directas entre los equipos que establecen el tnel criptogrco implicar un valor ms realista en cuanto a tiempo de u a a a proceso empleado por la implementacin, mientras que una infraestructura o ms compleja, pero ms parecida a la que utilicen los usuarios del sistea a ma ofrecer informacin real acerca de los retardos que experimentarn los a o a usuarios. Esta informacin puede ser muy importante en el caso en que se o desee utilizar el protocolo o arquitectura de seguridad para proteger trco a de red con necesidades de tiempo real, como Voz sobre IP. Como ya se ha comentado, la evaluacin de este factor vendr dada por o a un lado por los tiempos que registre la implementacin bajo nuestro control, o y por otro, por los tiempos registrados por una aplicacin de usuario desde o que env un mensaje a otro equipo al otro lado del tnel criptogrco hasta a u a que recibe la respuesta.

4.4.

Aspectos a tener en cuenta

Al igual que ocurr con la evaluacin de la conformidad de la implemena o tacin del protocolo o arquitectura de seguridad, al medir las capacidades y o el rendimiento de dicha implementacin entran en juego factores que pueo den inuir en los resultados, por lo que es necesario conocer y estudiar cmo o hacer frente a dichos factores. Estos factores son los perles de trco que se a utilizan al medir el ancho de banda, y la arquitectura de red que se utiliza para llevar a cabo la evaluacin. o Al estudiar el rendimiento que puede ofrecer un dispositivo de red (es-

Cap tulo 4. Anlisis del Rendimiento a

88

pecialmente los que desarrollan protocolos de seguridad) es importante remarcar la importancia de los perles de transmisin de informacin que o o se utilizan durante las evaluaciones anteriores, y, aunque no es un aspecto a evaluar en s mismo, su impacto en otros factores es lo sucientemente relevante como para estudiarlo. Por perles de trco estamos haciendo rea ferencia a un modelo de utilizacin de las redes de comunicaciones, en el que o se especican los protocolos de comunicaciones que se estn utilizando para a transmitir la informacin, as como a la relacin entre la cantidad de datos o o enviada por cada entidad de la comunicacin. As por ejemplo, podr o , amos hablar del perl UDP simtrico rerindonos a un perl que utiliza UDP e e para la transmisin de datos, y en el que ambas partes estn enviando la o a misma cantidad de informacin. o Un aspecto de los perles de trco que afecta al rendimiento que ofrea cen los dispositivos de red (en este caso, las implementaciones del protocolo de seguridad) es la cantidad de datos que se env en cada paquete TCP, a UDP, . . . . Si estamos interesados en conocer cul es el mximo rendimiento a a de la implementacin deberemos utilizar paquetes en los que el tamao del o n campo de datos es muy cercano al MTU para la tecnolog de red que se a est utilizando. Por contra, paquetes en los que la carga util es muy reducida a nos dan informacin acerca de la sobrecarga que introduce IPsec en la red. o Por lo tanto, al denir un perl es necesario indicar tambin qu tamao de e e n bloques de datos se estn utilizando para enviar los mensajes a travs de la a e red. Esta decisin contrasta con la propuesta de la metodolog para el eso a tudio del rendimiento de dispositivos de red del IETF ([19]), en la que las pruebas de medicin del ancho de banda se realizan con mltiples tamaos o u n de paquete. Sin embargo, al encapsular la informacin utilizando algoritmos o de cifrado cuyos bloques de salida son de tamao constante y al incluirse n la posibilidad de rellenar campos de datos con valores nulos para aumentar la entrop nos encontramos con que, independientemente del tamao del a, n paquete origen, los paquetes de salida tienen un tamao jo que escapa a n nuestro control. Por este motivo nuestra propuesta no requiere de la realizacin de las pruebas con mltiples tamaos de bloque, si no que el tamao o u n n de bloque viene determinado por el perl de trco que se utilice. a A pesar de que en la metodolog se denen algunos perles para obtea ner informacin que sea relevante, y otros que representan usos genricos de o e las redes de comunicaciones, siempre ser recomendable el realizar pruebas a adicionales con perles de trco tan parecidos al trco real que ser proa a a tegido por IPsec como sea posible. Ejemplos de algunas herramientas que pueden servir para denir estos perles de trco a partir de trco real son a a [152] y [47]. En cuanto a la arquitectura de red que se utilice, es indudable que las capacidades de los dispositivos de red utilizados para interconectar los dispo-

89

4.4. Aspectos a tener en cuenta

sitivos que implementan el protocolo o arquitectura de seguridad, la cantidad de dispositivos intermedios, la distancia entre los equipos y los dispositivos de red, etc. . . pueden inuenciar algunos de los parmetros que se deben a medir. Por este motivo, es esencial comprobar que la infraestructura de red que se utilizar puede soportar la cantidad de trco que se enviar por a a a ella, as como comprobar que los equipos que se utilizarn para enviar y a recibir trco pueden soportar la cantidad de canales seguros necesaria para a conocer el mximo que soporta la implementacin que se estudia. a o El problema que se nos presenta es que, dado que an no se dispone de u informacin able acerca del rendimiento de la implementacin, no conoceo o mos a priori dnde estn los l o a mites de la implementacin que se estudia. o Para solventar este problema se puede optar por dos enfoques diferentes: Utilizar la informacin de rendimiento suministrada por el fabricante como o valor orientativo de los mximos valores que podremos obtener, o bien calcua lar el rendimiento mximo terico que se puede ofrecer teniendo en cuenta a o la cantidad y el tipo de interfaces de red de los que dispone el sistema. Cada uno de estos mtodos tiene sus limitaciones, ya que, por ejemplo, e al utilizar los datos proporcionados por el fabricante podemos encontrarnos que las unicas especicaciones disponibles estn basadas en el procesador a criptogrco, pero no en la arquitectura nal de la implementacin6 . Si se a o decide utilizar el segundo mtodo hay que prestar atencin a las limitaciones e o de conguracin en algunas plataformas, especialmente hardware, que limio tan la cantidad de interfaces f sicos cuyo trco puede ser protegido, siendo a de este modo que unicamente estos interfaces son los que han de tenerse en cuenta para el cmputo del mximo ancho de banda que podr ofrecer la o a a implementacin. o Un aspecto adicional que no se ha mencionado hasta el momento es el estado de la red en el momento en que se llevan a cabo las pruebas, ya que aspectos tales como el retardo de la red, la fragmentacin, la prdida o e de tramas o las colisiones que pueda haber afectarn a los valores de rena dimiento que obtengamos. Por un lado, este hecho podr ser obviado ya a que el uso de infraestructura de red dedicada para llevar a cabo las pruebas necesarias evitar que se den condiciones hostiles en la red que no hayan a sido generadas por las propias pruebas, por lo que no ser necesario tenerlas a en cuenta. Sin embargo, dado que el objetivo de estas pruebas es conocer cul es el comportamiento de la implementacin estudiada y obtener infora o macin realista del rendimiento que se puede esperar de ella, es necesario o
6 Por ejemplo, es comn encontrarse con especicaciones en las que el fabricante asegura u que su implementacin puede proteger un ancho de banda de hasta 400 Mbps, cuando el o dispositivo o sistema al que se reeren esas especicaciones unicamente cuenta con una tarjeta de red de 100 Mbps. En estos casos es recomendable utilizar el segundo mtodo, e ya que las especicaciones del fabricante no nos aportan informacin util para nuestras o estimaciones

Cap tulo 4. Anlisis del Rendimiento a

90

incluir estos factores en las pruebas. Con el n de exibilizar la utilizacin o de estos parmetros y poderlos conjugar con otros parmetros tales como a a protocolos utilizados (parmetros de los que ya se ha hablado anteriormena te), se propone la inclusin del estado de la red en los propios perles de o utilizacin de la red. o De cara a la realizacin de las pruebas, la inclusin del estado de la red o o como factor a tener en cuenta durante la realizacin de las pruebas hace que o debamos considerar cules son las opciones que se nos presentan para poder a controlar estos aspectos de la red, ya que la utilizacin de infraestructura o de red dedicada har que no se produzcan espontneamente, y de forma a a ajena al trco correspondiente a las pruebas, las condiciones para que la a red fragmente los paquetes de datos, aumente la latencia de la red (tanto de forma simtrica como asimtrica), o los dispositivos comiencen a descartar e e paquetes para poder hacer frente a la carga de la red. Las soluciones que se plantean en este momento son dos: Generacin de trco en la red para que se den las condicioo a nes necesarias. Mediante la utilizacin de equipos situados en cada o uno de los segmentos de red utilizados en la infraestructura de red utilizada para llevar a cabo las pruebas de rendimiento, ser posible a generar trco entre dichos equipos para generar las condiciones de a red en las que deseemos llevar a cabo las pruebas, como aparece reejado en la Figura 4.6. El trco se generar entre equipos del mismo a a segmento de red (sealado en rojo) cuando se desee alcanzar una situan cin concreta en un segmento de red determinado, o entre segmentos o de red diferentes (sealado en amarillo) para forzar las condiciones en n un conjunto de segmentos concretos. Frente a la indudable ventaja que representa el hacer la evaluacin o del rendimiento en las condiciones de red reales, surgen importantes inconvenientes, de los que la gran cantidad de recursos necesarios para poder forzar ciertas condiciones (como por ejemplo, el descarte de paquetes o el incremento sustancial del retardo) en redes de alta velocidad, y la parametrizacin del trco que se genera de forma manual, o a debiendo llevar a cabo para cada red diferente cules son los valores a de generacin de trco que ocasionan los niveles de retardo y prdida o a e de tramas que deseamos establecer en la red. Utilizacin de dispositivos de red adicional que fuerce las cono diciones de red deseadas. Haciendo uso de dispositivos de red adicionales que hagan las funciones de puentes entre segmentos de red diferentes y que sean capaces de generar articialmente las condiciones de red necesarias al llevar a cabo esa interconexin entre los segmentos o de red, es posible forzar a que el tnel criptogrco entre los segmentos u a de red involucrados se desarrolle en las condiciones deseadas. En este

91

4.4. Aspectos a tener en cuenta

Figura 4.6: Arquitectura de red necesaria para generar trco y hacer que a aparezcan en la red las condiciones deseadas

Figura 4.7: Arquitectura de red en la que un dispositivo de red adicional genera las condiciones deseadas caso el esquema de red bsico para llevar a cabo las pruebas ser el a a mostrado en la Figura 4.7, en el que el dispositivo en rojo es el encargado de generar articialmente el retardo en la red, la prdida de e paquetes, la fragmentacin etc. . . o En este caso, la principal desventaja es que las condiciones de red que se estn forzando son irreales, por lo que, dependiendo de la calidad del a dispositivo utilizado y de la exibilidad a la hora de congurar dicho dispositivo, existe la posibilidad de que los resultados que se obtengan en las pruebas se vean alterados y no sean vlidos para obtener infora macin acerca del rendimiento de la implementacin del protocolo o o o arquitectura de seguridad. Sin embargo, las ventajas que ofrece esta solucin son las derivadas de los escasos requisitos hardware y software o adicionales que son necesarios para desplegar esta solucin, as como o la posibilidad de seleccionar exactamente cules son las condiciones a que se desean utilizar en la red, incluyendo el margen de error con el que se trabaja. Otro problema que se nos presenta, aunque con un impacto en los resultados mucho menor, es el tiempo necesario para llevar a cabo las pruebas. Con el n de conseguir que los resultados obtenidos sean lo sucientemente relevantes estad sticamente, se debern tener en cuenta aspectos ampliaa

Cap tulo 4. Anlisis del Rendimiento a

92

mente aceptados referentes a la capacidad de repeticin, la varianza y la o representatividad estad stica. Esto nos lleva a que, partiendo de los valores y estudios que se pueden ver en [19], [144] y [84]. Por lo tanto, cada prueba deber repetirse al menos 3 veces, (recomendable 5) para obtener valores con a una abilidad mucho mayor, lo que implica que la realizacin de los tests o utilizando todas las posibles suites criptogrcas soportadas por la implea mentacin supondr un tiempo considerable. Por este motivo es necesario o a que se seleccionen aquellas suites criptogrcas que ms interesantes nos rea a sultan. Es de destacar el hecho de que, tras haber llevado a cabo las pruebas de conformidad con el estndar y correccin criptogrca descritos en la a o a seccin 3.2, unicamente sern candidatas a ser seleccionadas aquellas suites o a criptogrcas que hayan resultado ser criptogrcamente correctas, ya que a a el resto de dichas suites no pueden ser evaluadas desde la implementacin o de referencia. La seleccin de las suites criptogrcas deber realizarse indicando para o a a cada una de ellas en qu fases del protocolo o arquitectura de seguridad e deber ser evaluada: negociacin o proteccin de la informacin. Esto se a o o o debe a que es posible que no todas las suites criptogrcas deban utilizarse a en todas las fases de protocolo, reduciendo de esta manera la cantidad de pruebas a llevar a cabo durante la evaluacin del rendimiento. o

Cap tulo 5

Metodolog de Validacin y a o Evaluacin Remota de o Protocolos y Arquitecturas de Seguridad

5.1. Introduccin o

Una vez estudiados y revisados aquellos factores que deben ser analizados a la hora de llevar a cabo estudios acerca de la conformidad (cap tulo 3) y el rendimiento (cap tulo 4) de implementaciones de protocolos y arquitecturas de seguridad, nos encontramos en situacin de presentar la metodolog o a de validacin y evaluacin remota de protocolos y arquitecturas de segurio o dad, que representa el ncleo en torno al que se estructura esta tesis. La u metodolog se divide de forma que inicialmente se presentan las denicioa nes de trminos que utilizarn en la metodolog (seccin 5.2), y un anlisis e a a o a acerca de la conformidad y el rendimiento (seccin 5.3). Posteriormente se o presentan 8 fases en las que se abarcan desde las tareas preliminares a llevar a cabo hasta los procedimientos de nalizacin una vez terminada la valio dacin y evaluacin (secciones 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 5.10 y 5.11. Estas o o fases se desarrollarn de forma secuencial, aunque la ejecucin de cada una a o de ellas es opcional, si los objetivos que se persiguen no se ajustan a los del evaluador1 .

1 Por ejemplo, la fase de documentacin preliminar puede ser omitida si los conocimieno tos bsicos acerca del protocolo o arquitectura de seguridad ya se poseen a

93

Cap tulo 5. Metodolog de Validacin y Evaluacin a o o

94

5.2.

Deniciones

Conjunto de Pruebas: Un conjunto completo de pruebas individuales que se llevan a cabo para obtener informacin acerca de una determinada o caracter stica o funcionalidad en la IEP. Exito (resultado): Resultado de las pruebas de conformidad en las que la IEP demuestre ser conforme al estndar en el aspecto evaluado. a Fallo (resultado): Resultado de las pruebas de conformidad en las que la IEP demuestre no ser conforme al estndar en el aspecto evaluado, o a genere eventos no contemplados en la especicacin del protocolo o o arquitectura. IDR: Implementacin de referencia; aquella que es conforme al estndar. o a IEP: Implementacin en pruebas. o Medios de Prueba: Combinacin de equipos y procedimientos que pueo den llevar a cabo la validacin o evaluacin deseada. o o Perl de Trco: Conjunto de caracter a sticas que denen un uso de la red determinado, as como el estado de la propia red. Prueba de Capacidad: Prueba que determina si una determinada caracter stica se encuentra implementada en la IEP. Prueba de Comportamiento: Prueba que determina si uno o ms rea quisitos de conformidad dinmicos (ver seccin 5.3) se cumplen en la a o IEP. Pruebas de Conformidad: Validacin del nivel de conformidad con el o estndar de una IEP. a Pruebas de Rendimiento: Evaluacin del rendimiento de la IEP en dio versas condiciones de operacin. o Registro de Pruebas: Registro en formato legible por las personas de los resultados obtenidos en la realizacin de una prueba o un conjunto de o pruebas. Repetibilidad de los Resultados: Caracter sticas de un conjunto de pruebas, tal que repetidas ejecuciones del mismo conjunto de pruebas sobre la misma IEP en las mismas condiciones, conducen a los mismos resultados. Resultado Obtenido: Resultado de una prueba de conformidad obtenido para una IEP concreta.

95

5.3. Conformidad y Rendimiento

Resultado Previsto: Resultado de una prueba de conformidad de acuerdo con las especicaciones del protocolo o arquitectura. Sistema de Pruebas: Conjunto de equipos, dispositivos y software utilizado para realizar las diferentes pruebas sobre la IEP.

5.3.

Conformidad y Rendimiento

Una implementacin de un protocolo o arquitectura de seguridad es o conforme a la especicacin de dicho protocolo o arquitectura si dicha imo plementacin presenta todas las caracter o sticas y requisitos descritos en esa especicacin. Estos requisitos de conformidad pueden ser obligatorios, o cuando deben ser respetados en todo momento, condicionales, cuyo cumplimiento se reduce a los casos en los que se dan un conjunto determinado de condiciones, u opcionales, cuando su cumplimiento por parte de las implementaciones es totalmente voluntario. Adicionalmente, nos encontramos con que los requisitos de conformidad pueden estar expresados de forma positiva (se especica lo que debe hacerse) o negativa (cuando se detalla lo que no debe hacerse). Por ultimo, podemos comprobar cmo los requisitos o de conformidad se pueden agrupar en requisitos de conformidad esttica o a 2. conformidad dinmica a La conformidad esttica es aquella que establece l a mites a las combinaciones de caracter sticas permitidas en las implementaciones de los protocolos o arquitecturas de seguridad, as como el conjunto de caracter sticas m nimo que permite la interoperabilidad. Por su parte, la conformidad dinmica especica el comportamiento observable que es admisible para las a implementaciones del protocolo en cuestin. La denicin de los protocolos o o de seguridad en los estndares es el caso ms claro de conformidad dinmica: a a a el uso y formato que se asigna a las unidades de informacin, transiciones o entre estados, reglas de negociacin, etc. . . . La conformidad dinmica estao a blece l mites a la funcionalidad de las implementaciones, por lo que dene el mximo conjunto de caracter a sticas que una implementacin puede tener. o En cuanto al rendimiento que ofrece una implementacin de un protoo colo o arquitectura de seguridad, los parmetros que se evalan pueden ser a u dependientes del trco de red o independientes del trco de red. a a Aquellos parmetros que dependen del trco de red modican sus resultados a a en funcin del tipo de mensajes que se utilizan para evaluarlo: protocolos, o tamao de los mensajes, sentido de los mensajes, . . . . Tambin se ven afecn e tados por el trco existente en la red en la que se realizan las pruebas, y a por la saturacin de dicha red. Esta variabilidad afecta a la repetibilidad de o los resultados de rendimiento que se obtienen al llevar a cabo la evaluacin. o
2

Esta nomenclatura es la misma utilizada por las normas ISO/IEC 9646 e ITU-T X.290

Cap tulo 5. Metodolog de Validacin y Evaluacin a o o

96

Los parmetros de rendimiento que no dependen del trco de red son a a aquellos en los que las caracter sticas de los mensajes intercambiados no inuyen en los resultados obtenidos. En la medicin de estos parmetros el o a nivel de saturacin de la red afecta de forma marginal a los resultados, por o lo que la repetibilidad de las pruebas no resulta afectada.

5.4.

Fase 1: Tareas Preliminares

En la fase inicial de las pruebas, se determinar cules son las implemena a taciones a validar y evaluar, quin llevar a cabo dichos procesos y qu ree a e cursos sern necesarios para completar esta tarea. Para poder llevar a cabo a este proceso ser preciso determinar cul va a ser el objetivo de los anlisis a a a que se lleven a cabo, y obtener los recursos necesarios para desarrollar esos estudios.

5.4.1.

Determinar el tipo de anlisis a

Existe la posibilidad de llevar a cabo tres tipos de anlisis, dependiendo a del tipo de informacin que se desee obtener: o Validacin de la conformidad En este caso unicamente se llevarn a o a cabo pruebas de conformidad sobre la IEP. Se obtendr informacin acerca a o de la conformidad de la implementacin con el estndar y de las capacidades o a de la IEP. Se desarrollarn conjuntos de pruebas de capacidad y de compora tamiento. Interpretando los resultados de varias implementaciones es posible deducir las posibilidades de interoperatividad entre ellas. Evaluacin del rendimiento Al llevar a cabo este anlisis se someter a o a a la IEP a pruebas de rendimiento que proporcionen informacin acerca de o la capacidad de proteccin de informacin de dicha IEP. Los anlisis estn o o a a compuestos de conjuntos de pruebas de comportamiento. Validacin de la conformidad y evaluacin del rendimiento Es poo o sible llevar a cabo los procesos de validacin de la conformidad y evaluacin o o del rendimiento de forma conjunta. El anlisis nal constar de la ejecucin a a o de cada uno de los anlisis de forma secuencial. a Adicionalmente, se debern determinar cul es la versin del protocolo a a o o arquitectura de seguridad que se va a evaluar, el sistema de pruebas en el que el proceso de validacin y evaluacin se llevar a cabo, la versin de la o o a o IDR que se utilizar y otros recursos software o de infraestructura que sean a necesarios.

97

5.5. Fase 2: Documentacin Preliminar o

5.4.2.

Identicacin de los recursos necesarios o

Es posible que no todos los recursos necesarios determinados en el apartado anterior sean accesibles al pblico en general, por lo que en esta fase u el responsable del estudio deber llevar a cabo las gestiones necesarias paa ra averiguar qu herramientas y utilidades pueden dar el servicio necesario e (especialmente la IDR), identicando aquellas cuya disponibilidad sea mayor. Todos los recursos que se emplearn para llevar a cabo los anlisis se a a incluirn en un registro para su posterior comprobacin en la fase nal de a o esta metodolog a.

5.5.

Fase 2: Documentacin Preliminar o

Dado que los evaluadores no deben disponer de conocimientos previos acerca del protocolo o arquitectura de seguridad cuya implementacin se o evaluar, es necesario que, como paso previo al diseo de las pruebas de a n conformidad y de rendimiento, se adquiera este conocimiento. Del mismo modo, en esta fase se incluir la documentacin acerca de los problemas de a o interoperabilidad ms frecuentes en las implementaciones de este protocolo a o arquitectura. Se proceder tambin a instalar la IDR en un entorno de pruebas paa e ra adquirir conocimientos adicionales acerca de las implementaciones del estndar que ampl los conocimientos del evaluador en este rea. a en a Para nalizar la presente fase se documentarn los aspectos generales a del protocolo o arquitectura de seguridad, as como los problemas de inte roperatividad y rendimiento ms frecuentes en la actualidad. a

5.6.

Fase 3: Anlisis del Estndar a a

En esta fase se llevar a cabo un estudio exhaustivo del estndar que a a permita ampliar los conocimientos adquiridos en la fase anterior. Al nalizar este proceso, los evaluadores deben ser capaces de: Identicar aquellos aspectos fundamentales del estndar que deben ser a evaluados tanto en lo referente a conformidad como a rendimiento. Identicar aquellos aspectos del estndar que deben ser evaluados dea bido a su importancia para la seguridad. Identicar aquellos aspectos del estndar que deben ser evaluados por a su inuencia en problemas de interoperabilidad existentes.

Cap tulo 5. Metodolog de Validacin y Evaluacin a o o

98

Identicar aquellos aspectos del estndar que deben ser evaluados por a su importancia en determinadas situaciones o arquitecturas determinadas. Identicar aquellos aspectos del estndar que deben tenerse en cuenta a en la evaluacin del rendimiento o La presente fase nalizar documentando la informacin obtenida en a o cuanto a los aspectos del estndar que deben ser incluidos en los anlisis. a a

5.7.

Fase 4: Validacin de la Conformidad o

Para llegar a denir un conjunto de pruebas que permitan el anlisis de a la IEP, es necesario identicar aquellas capacidades que aparecen recogidas en el estndar y que deben ser desarrolladas por las implementaciones de a una forma determinada.

5.7.1.

Identicacin de los mecanismos criptogrcas o a

Dado que muchas de las diferentes conguraciones surgirn a partir de a variaciones en los mecanismos criptogrcos que se utilizan, es necesario a identicar cules son las suites criptogrcas permitidas por el estndar en a a a cada una de las fases del desarrollo del protocolo de seguridad. Adicionalmente, se identicarn aquellos mecanismos que deben ser implementados a obligatoriamente y aquellos que son opcionales. Teniendo en cuenta la constante evolucin de los estndares de los protoo a colos, se prestar especial atencin a la presencia de mecanismos opcionales a o en la actualidad pero que pasarn a ser obligatorios en un corto periodo a de tiempo (normalmente identicados como SHOULD+ en los estndares) y a aquellos que son obligatorios pero dejarn de serlo (sealados como MUST-). a n

5.7.2.

Identicacin de los caracter o sticas obligatorias

Las especicaciones de los protocolos y arquitecturas de seguridad incluyen un conjunto m nimo de funcionalidades que deben ser incluidas en cualquier implementacin de dicho protocolo o arquitectura. Este conjuno to m nimo de funcionalidades debe ser identicado para poder incluir su validacin en el conjunto de pruebas. Deber prestarse especial atencin a o a o aquellas funcionalidades o mecanismos que se encuentran en evolucin, bien o para pasar a ser obligatorios, bien porque pronto dejarn de serlo. a

99

5.7. Fase 4: Validacin de la Conformidad o

5.7.3.

Identicacin de los caracter o sticas opcionales que deben ser evaluadas

En los protocolos y arquitecturas de seguridad se incluyen mltiples u mecanismos y opciones que colaboran a aumentar la seguridad del sistema o a hacer el protocolo o arquitectura utilizable en diferentes arquitecturas y topolog de red. Aquellos mecanismos que, pese a ser opcionales, sean as importantes para la seguridad de la informacin protegida, o sean necesarios o para poder utilizar el protocolo en determinadas arquitecturas, debern ser a incluidos en los aspectos a analizar durante el estudio. Tambin se incluirn e a en el conjunto de pruebas aquellas funcionalidades que en la actualidad presentan mayor cantidad de problemas de interoperatividad. Deber tenerse a en cuenta a la hora de determinar los resultados de conformidad que estas capacidades de las que estamos hablando son opcionales, por lo que una implementacin puede ser conforme al estndar sin desarrollar ninguna de o a estas capacidades.

5.7.4.

Dise o de pruebas n

Una vez se disponga de informacin suciente acerca de los aspectos o del estndar que se van a validar, se proceder a denir el conjunto de a a pruebas que servir para estudiar la IEP. Las pruebas de conformidad sern a a pruebas de capacidad y de comportamiento, segn el aspecto del estndar u a que pretende validarse. La denicin de cada prueba constar de: o a Objetivos, capacidad que se pretende validar con cada una de las pruebas. Obligatoriedad, de la implementacin de dicha capacidad. o Medios de prueba, conguracin del sistema de pruebas, y arquio tectura necesaria. Resultado previsto, para las implementaciones conformes. Descripcin de xito y fallo para cada prueba concreta. Reaccin ante los o e o resultados previstos ms habituales. a Conguraciones vlidas, variaciones de parmetros que es necesario a a realizar a la hora de llevar a cabo el anlisis. a Medicin de los resultados, incluyendo los registros de pruebas. o

Cap tulo 5. Metodolog de Validacin y Evaluacin a o o

100

5.8.

Fase 5: Evaluacin del Rendimiento o

Para llegar a denir un conjunto de pruebas que permita el anlisis a del rendimiento ofrecido por la IEP, es preciso identicar aquellos aspectos del rendimiento del protocolo o arquitectura de seguridad que es necesario evaluar.

5.8.1.

Rendimiento de los mecanismos criptogrcas a

El rendimiento de los diferentes mecanismos criptogrcos es muy vaa riable entre distintos sistemas, incluso de la misma arquitectura. Por este motivo es necesario identicar los diferentes conjuntos de mecanismos involucrados en cada uno de los aspectos del rendimiento que es necesario evaluar, para as poder llevar a cabo la evaluacin del rendimiento de dicho o aspecto considerando la utilizacin de cada uno de esos mecanismos. o Teniendo en cuenta la constante evolucin de los mecanismos cripo togrcos utilizados en los protocolos de seguridad, se prestar especial a a atencin a la presencia de mecanismos identicados como SHOULD+ (es decir, o opcionales actualmente pero obligatorios a corto plazo) y aquellos sealan dos como MUST- (obligatorios en la actualidad, pero que pronto dejarn de a serlo).

5.8.2.

Identicacin de parmetros dependientes del trco o a a

Aquellos parmetros de rendimiento que sean dependientes del trco a a que circule por la red, o de las caracter sticas concretas del trco que se a utiliza para llevar a cabo la evaluacin, debern ser identicados. En los o a conjuntos de pruebas que evalen estos parmetros deber determinarse u a a cules son las condiciones en las que dicha prueba debe llevarse a cabo, con a el n de facilitar la repetibilidad de la evaluacin. o

5.8.3.

Identicacin de parmetros independientes del tro a a co

Se identicarn los aspectos del rendimiento a los que el estado de la a red y las caracter stica de trco de prueba no afectan directamente. Los a conjuntos de pruebas que evalen estos parmetros no deben considerar u a el estado de la red ni el tipo de trco utilizado. Sin embargo, dado que a es posible que al llegar a los l mites de rendimiento que ofrece la IEP se produzcan variaciones por estos motivos, los conjuntos de pruebas debern a incluir los mecanismos necesarios para detectar estas situaciones, y obtener resultados repetibles.

101

5.9. Fase 6: Denicin de Perles de Trco o a

5.8.4.

Dise o de pruebas n

Una vez se disponga de informacin suciente acerca de los aspectos o del rendimiento que se van a evaluar, se proceder a denir el conjunto a de pruebas. Las pruebas de rendimiento son pruebas de comportamiento unicamente, por lo que ninguna prueba deber considerar a la IEP como a algo ms que una caja blanca. a La denicin de cada prueba de rendimiento constar de: o a Objetivos, aspecto que se pretende evaluar con cada una de las pruebas. Medios de prueba, conguracin del sistema de pruebas, y arquio tectura necesaria. Conguraciones vlidas, variaciones de parmetros que es necesario a a realizar a la hora de llevar a cabo el anlisis del rendimiento. a Medicin de los resultados, incluyendo los registros de pruebas. o

5.9.

Fase 6: Denicin de Perles de Trco o a

Los perles de trco denen las condiciones de la red en el momento a de llevarse a cabo la validacin y la evaluacin de la IEP. Tambin recogen o o e cules son las caracter a sticas del trco que se utiliza para llevar a cabo los a anlisis de los diferentes aspectos de rendimiento. Dado que las pruebas de a conformidad y algunas pruebas de rendimiento no se ven afectadas por estas condiciones, unicamente en algunos conjuntos de pruebas de rendimiento se hace uso de estos perles. Las caracter sticas que deben aparecer recogidas en un perl de trco a son: Protocolo: Cul es el protocolo o protocolos utilizados para el env a o de datos. En el caso de ser varios protocolos, se informar de la distria bucin porcentual de los mensajes en dichos protocolos. o Tama o de los paquetes de datos n Sentido: Puede ser del IEP al IDR, del IDR al IEP o bidireccional. En el caso de ser bidireccional, si el trco es asimtrico se indicar cul a e a a es la proporcin en cada sentido. o Medicin: Equipo o sistema que lleva a cabo la medicin del parmeo o a tro de rendimiento. Retardo: Retardo articial incluido en la red.

Cap tulo 5. Metodolog de Validacin y Evaluacin a o o Prdida de paquetes: Porcentaje de prdida de paquetes. e e Reenv de paquetes: Porcentaje de paquetes reenviados. o Descripcin o

102

Se denirn perles de trco que permitan la obtencin de informacin a a o o del rendimiento a efectos comparativos entre las diferentes implementaciones (esto es, que permitan obtener informacin acerca del rendimiento mximo o a que la implementacin es capaz de ofrecer), y perles que aporten inforo macin acerca del rendimiento de la implementacin en condiciones ms o o a realistas en cuanto a tipo de trco a proteger y estado de la red durante a su operacin. o

5.10.

Fase 7: Otras Consideraciones

En esta fase se analizarn otras consideraciones que deban ser tenidas en a cuenta a la hora de llevar a cabo la validacin y evaluacin de la IEP. Aspeco o tos tales como recomendaciones de arquitecturas a utilizar, limitaciones de los conjuntos de pruebas propuestos, disponibilidad de la IDR, herramientas necesarias o recomendadas para la realizacin de las pruebas, etc. . . . deben o ser analizados y documentados en esta fase de la metodolog a.

5.11.

Fase 8: Tareas Finales

Para nalizar el proceso de anlisis de la IEP, se llevar a cabo la rea a copilacin de todo el material generado en fases anteriores, tanto referente o al protocolo o arquitectura de seguridad, como las deniciones de los conjuntos de pruebas que deben aplicarse. Esta informacin se compilar en un o a formato que sea fcilmente accesible y manejable por los responsables de los a anlisis. a Se prestar especial atencin a la utilizacin de herramientas necesarias a o o para llevar a cabo el anlisis de las implementaciones, con el n de asegurar a que las herramientas seleccionadas en la fase 1 de esta metodolog fueron a acertadas y no se han realizado modicaciones en ese aspecto.

Cap tulo 6

Aplicacin de la Metolodog o a a la Arquitectura IPsec

6.1. Introduccin o

En este cap tulo se proceder a aplicar la metodolog de validacin y a a o evaluacin de implementaciones de protocolos y arquitecturas de seguridad o a la arquitectura de seguridad IPsec. Con el n de solventar los problemas y necesidades expresados anteriormente, esta aplicacin de la metodolog o a denir conjuntos de pruebas detallados de los que se a la evaluacin de a o la conformidad con los diferentes estndares que denen la arquitectura de a seguridad IPsec, y por otro a la obtencin de informacin able acerca del o o rendimiento de la implementacin estudiada. o Los motivos por los que se ha elegido IPsec sobre otros protocolos y arquitecturas de seguridad existentes, estandarizados y ampliamente extendidos son varios: IPsec es la arquitectura de seguridad que se utilizar en la a prxima generacin de redes IP, al encontrarse incluido en la vero o sin 6 del protocolo IP (IPv6), lo que hace necesario el evaluar las o capacidades de interoperabilidad y rendimiento de las actuales implementaciones, con el objeto de prevenir problemas de interoperatividad y/o rendimiento futuros. IPsec es una arquitectura de seguridad compleja, en la que se dan gran parte de los mecanismos de seguridad ofrecidos por los diferentes protocolos y arquitecturas, siendo posible la utilizacin de o mltiples mecanismos y herramientas para llevar a cabo cada una de u las funciones. Esto convierte a esta arquitectura en un examen exigente para la metodolog que servir para medir hasta qu nivel la a, a e metodolog es lo sucientemente completa como para abarcar todas a 103

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

104

las posibilidades de IPsec, al tiempo que es lo sucientemente exible como para permitir denir conjuntos de pruebas adaptados a cada protocolo y mecanismo presente en la arquitectura. IPsec, junto con TLS, son los estndares de seguridad ms a a extendidos en la actualidad, al tiempo que las implementaciones de IPsec son las que ms problemas de interoperabilidad entre ellas prea sentan. Por este motivo es necesario desarrollar un conjunto de pruebas que nos permitan conocer cules son las capacidades y limitaciones de a una implementacin determinada. o

6.2.

Conformidad con el estndar a

Para las implementaciones de protocolos y arquitecturas de seguridad la conformidad con el estndar es un aspecto que debe ser evaluado de cara a a poder disponer de informacin acerca del nivel de delidad en el cumplio miento de lo especicado en los documentos que denen los protocolos y herramientas criptogrcas utilizadas. Esta informacin podr ser utilizada a o a posteriormente para evaluar la interoperatividad de la implementacin eso tudiada con otras implementaciones de IPsec diferentes. En esta seccin se o denen las pruebas que es necesario llevar a cabo para poder evaluar el nivel de conformidad con el estndar de una implementacin IPsec. a o

6.2.1.

Requisitos

Para poder llevar a cabo las pruebas descritas en este documento, ser necesario disponer de una implementacin IPsec de referencia, confora o me a los estndares de IPsec y sobre la que se disponga de control absoluto. a Esta implementacin de referencia debe poder ser capaz de desarrollar los o protocolos IKE (e ISAKMP en el caso de IKEv1), ESP y AH para establecer tneles criptogrcos, al tiempo que debe ser posible forzar a la implemenu a tacin a enviar mensajes de cualquiera de los protocolos fuera de orden. o Hay que resaltar que, dado que las especicaciones de IPsec de 1.998 (IPsec versin 1) y las de 2.005 (IPsec versin 2) no son compatibles entre s la imo o , plementacin de referencia que utilicemos deber utilizar la misma versin o a o de la arquitectura de seguridad que la implementacin que se desea evaluar. o Es tambin un requisito para la realizacin de las pruebas el disponer del e o control sobre la implementacin que se validar, ya que ser necesario realio a a zar cambios en la conguracin del establecimiento de tneles criptogrcos o u a tanto en la implementacin de referencia como en la implementacin a valio o dar. Tambin es necesario disponer de mecanismos para generar las credene ciales necesarias para validar los diferentes mtodos de autenticacin: una e o

105

6.2. Conformidad con el estndar a

infraestructura de clave pblica con una autoridad de certicacin que emiu o ta certicados X.509 y un generador de pares de claves RSA. En el caso de utilizar IPsec versin 2 y desear llevar a cabo la autenticacin mediante o o EAP, los mecanismos necesarios para generar credenciales que puedan encapsularse en dicho protocolo tambin sern necesarios. En muchos casos e a podremos encontrarnos con que la propia implementacin de IPsec que se o desea validar puede desarrollar los mecanismos necesarios para generar certicados X.509, pares de claves RSA, etc. . . . Sin embargo, el uso de esos mecanismos para generar las credenciales no se recomienda, ya que existe la posibilidad de que incompatibilidades en dichas credenciales (por ejemplo, el no reconocer la autoridad de certicacin ra utilizada para rmar o z los certicados X.509) puedan propagarse hasta el proceso de autorizacin, o generando falsos resultados.

6.2.2.

Conguracin de las pruebas o

Para llevar a cabo todas las pruebas de conformidad es necesario disponer de una implementacin de referencia con la que establecer los tneles o u criptogrcos con la implementacin evaluada. Cada una de estas implemena o taciones deber congurarse para proteger una red en la que deber existir a a al menos un equipo de usuario. Las direcciones de red asignadas debern a ser tales que no produzcan ningn conicto con el resto de la infraestrucu tura de red existente. En la metodolog para anlisis del rendimiento del a a IETF ([19]) se propone el uso del rango de direcciones desde 192.18.0.0 hasta 192.19.255.255, que ya ha sido reservado por el IANA para la aplicacin de o metodolog de rendimiento. Sin embargo, es posible que esas direcciones se as encuentren en uso al estar llevando a cabo alguna medicin del rendimiento o de otros dispositivos de red, por lo que siempre es necesario comprobar la disponibilidad de las direcciones escogidas. En las Figuras 6.2.2 y 6.2.2 se muestran las conguraciones necesarias para evaluar la conformidad de la implementacin de IPsec cuando funciona o en modo pasarela (Figura 6.2.2) y cuando funciona en modo de equipo nal (Figura 6.2.2). En estas guras se proponen tambin unas direcciones de e red que sern las que se utilicen durante la elaboracin de este conjunto a o de pruebas con el n de eliminar posibles ambigedades1 , por lo que al u desarrollar la metodolog podrn ser reemplazadas por los valores reales a a utilizados en la red en la que se lleve a cabo la validacin. Hay que destacar o que en ambos esquemas de red la implementacin de referencia aparece o representada funcionando en modo pasarela. Sin embargo, la utilizacin de o implementaciones de referencia que funcionen en modo de equipo nal no plantea problema alguno, por lo que puede aplicarse sin ningn tipo de u problemas.
1

Estas direcciones han sido escogidas de acuerdo a las directrices del IETF en [19]

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

106

Figura 6.1: Esquema de red utilizado para la validacin de una implemeno tacin de IPsec actuando como pasarela o

Figura 6.2: Esquema de red utilizado para la validacin de una implemeno tacin de IPsec actuando como equipo nal o

107

6.2. Conformidad con el estndar a

Dado que el rendimiento no es el objeto de los anlisis que se llevarn a a a cabo, resulta indiferente la infraestructura de red existente entre las dos implementaciones de IPsec, pudiendo existir tantos nodos intermedios como sea necesario. Antes de comenzar las pruebas propuestas es necesario comprobar que la conguracin de red de todos los dispositivos es correcta, por lo que, o desactivando la utilizacin de IPsec, se comprobar que todos los dispositivos o a pueden establecer una comunicacin con el resto de equipos involucrados en o las pruebas mediante ICMP y los puertos UDP 500 (utilizado por ESP y AH) y UDP 4500 (utilizado al hacer uso de NAT traversal). Se recomienda prescindir de la utilizacin de NAT hasta llevar a cabo los anlisis del resto o a de componentes de IPsec, siguiendo el orden establecido. Por ultimo, es tambin necesario evaluar las herramientas criptogr e a cas de la implementacin que utilicemos como referencia. Para ello podremos o utilizar los vectores de pruebas existentes en la documentacin de los difeo rentes algoritmos criptogrcos. a

6.2.3.
6.2.3.1.

Pruebas de conformidad criptogrca a

Objetivos

Determinar la correcta implementacin de las herramientas criptogro a cas utilizadas por IPsec y denidas en [70] y [60]. Aunque las recomendaciones y los algoritmos soportados se encuentran en constante evolucin, las o recomendaciones del IETF acerca de la conformidad con IPsec se restringen a un determinado conjunto de algoritmos y herramientas, que sern los a validados de forma obligatoria. 6.2.3.2. Conguracin necesaria o

Las implementaciones de IPsec se congurarn para establecer los tnea u les criptogrcos en modo tnel. Tambin debern utilizar el algoritmo a u e a NULL en la negociacin de las Fases 1 y 2 de IKE2 . En la Fase 1 de IKE se o utilizar el modo acelerado. Para proteger el trco se utilizar el protocoa a a lo ESP. Para generar trco se enviar un mensaje Echo Request con el a a campo de datos AAAA hasta completar un tamao m n nimo de 512 bytes. La autenticacin se establecer a un secreto compartido seleccionable por el o a usuario. La conguracin de ESP para proteger el trco en la implementacin o a o a analizar consistir en las siguientes suites criptogrcas: a a
En algunas implementaciones el algoritmo NULL no aparece como tal, sino que aparece como una opcin para deshabilitar la condencialidad o el cifrado en las Fases 1 y o 2
2

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a Algoritmo de cifrado NULL - Sin control de integridad 3DES en modo CBC y HMAC-SHA1-96

108

AES con 128 bits de clave en modo CBC - AES-XCBC-MAC-96 Opcionalmente se podrn congurar otras suites criptogrcas que sean a a de inters para el usuario. e Posteriormente, se congurar ESP para proteger el trco utilizando a a el algoritmo NULL y sin control de integridad, al tiempo que se congura la Fase 2 de IKE para que utilice las siguientes suites criptogrcas: a Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 2 (1024 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con AES en modo CBC y AESXCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96 Finalmente, se restablecer la conguracin de la Fase 2 de IKE para a o que utilice 3DES y HMAC-SHA1-96, y se congurar la Fase 1 de IKE para a que utilice las siguientes suites criptogrcas: a Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-MD5-96

109

6.2. Conformidad con el estndar a Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 2 (1024 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con AES en modo CBC y AESXCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96

Las conguraciones que utilizan HMAC-MD5-96 pertenecen en la actualidad al conjunto de conguraciones criptogrcas que deben ser sopora tadas por las implementaciones de IPsec v1, pero que el propio IETF ha excluido de las recomendaciones de IPsec v2. Sin embargo, al encontrarnos en la actualidad en un periodo de transicin entre ambas especicaciones se o ha decidido incluir esta conguracin entre las que es necesario evaluar. o Al igual que con ESP, el usuario tiene la potestad de validar otras suites criptogrcas en cualquier fase de IKE utilizando el mismo procedimiento a a continuacin de estas pruebas obligatorias. o 6.2.3.3. Procedimiento

Para cada una de las conguraciones reseadas en el apartado anterior, n el equipo 2 (con direccin 192.168.200.10) enviar al equipo 1 (192.168.100.10) o a mensajes ICMP Echo Request con las caracter sticas comentadas anteriormente. Estos mensajes originarn la creacin de un tnel criptogrco entre a o u a las implementaciones de IPsec y el env de mensajes a travs del mismo o e que generarn respuestas conocidas de antemano. Una vez enviados al mea nos diez de estos mensajes ICMP se proceder a comprobar las respuestas a

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

110

(conforme a la evaluacin que se indica en el apartado siguiente). Finalizado o este proceso, se congurarn las implementaciones de IPsec con la siguiente a conguracin a evaluar y se repetir el proceso. o a Con el n de agilizar el proceso, es posible congurar todas las conguraciones a probar como alternativas aceptables en la implementacin a o evaluar; de esta forma, tras nalizar las pruebas con una conguracin unio camente ser necesario modicar la implementacin de referencia para que a o unicamente acepte la alternativa que deseamos evaluar. En el caso de desear evaluar otras suites criptogrcas, hay que tener a en cuenta que: Cada grupo de Die-Hellman debe validarse con todos los algoritmos criptogrcos y funciones resumen utilizados. a Cada algoritmo criptogrco debe validarse con todos los grupos de a Die-Hellman y funciones resumen utilizados. Cada funcin resumen debe validarse con todos los algoritmos cripo togrcos y grupos de Die-Hellman. a 6.2.3.4. Mediciones y resultados

Para validar el resultado de cada prueba, ser necesario analizar los a mensajes Echo Reply que habrn llegado al equipo 2 procedentes del equia po 1. Para que un mensaje se considere correcto debe: Tener el mismo tamao que el mensaje Echo Request enviado. n Contener la misma informacin en el campo de datos. o En el caso de que se reciban los mensajes Echo Reply (tantos como mensajes Echo Request se enviasen) y todos ellos cumplan las dos condiciones anteriores, podemos constatar que la implementacin evaluada es capaz de o cifrar, descifrar, generar y validar resmenes criptogrcos correctamente u a con la suite criptogrca utilizada en la capa de IPsec que se congurase en a cada momento. En caso de que alguno de los mensajes Echo Reply presente algn prou blema ser necesario almacenar la pareja de mensajes Echo Request y Echo a Reply para llevar a cabo las labores de auditor posterior. a 6.2.3.5. Informe de resultados

Se informar de una implementacin exitosa de una suite criptogrca a o a concreta en una capa determinada de IPsec cuando todos los mensajes recibidos cumplan los requisitos determinados en el apartado anterior. En caso

111

6.2. Conformidad con el estndar a

contrario se informar de la cantidad de mensajes que presentaron errores y a se informar del tipo de error encontrado. a

6.2.4.
6.2.4.1.

Validacin de protocolos y subprotocolos o

Objetivos

Determinar la correcta implementacin de los protocolos que forman o parte de la arquitectura de seguridad IPsec, tal y como se dene en [90] y [91] y sus documentos asociados. A pesar de la incompatibilidad entre ambas versiones de IPsec la aplicacin de la metodolog proporciona la forma de o a evaluar ambas ya que la funcionalidad y estructura es idntica en ambas. e 6.2.4.2. Conguracin necesaria o

La infraestructura necesaria para llevar a cabo la validacin de los proo tocolos que componen la arquitectura de seguridad IPsec ser la descrita en a el apartado 6.2.2. En cuanto a la conguracin de las implementaciones IPsec, ambas o debern estar conguradas para llevar a cabo la autenticacin mediante un a o secreto compartido escogido por el usuario, y debern utilizar siempre, en a todos los protocolos, el algoritmo de cifrado NULL sin control de integridad. La implementacin de IPsec a evaluar deber estar congurada de tal forma o a que no agrupe el trco similar en el mismo tnel criptogrco. a u a Las conguraciones de los diferentes protocolos seguirn el siguiente a plan: Modo Tnel, Fase 1 de IKE con Main Mode, Fase 2 de IKE con Quick u Mode, sin PFS, ESP Modo Tnel, Fase 1 de IKE con Main Mode, Fase 2 de IKE con Quick u Mode, sin PFS, AH Modo Tnel, Fase 1 de IKE con Main Mode, Fase 2 de IKE con Quick u Mode, con PFS, ESP Modo Tnel, Fase 1 de IKE con Main Mode, Fase 2 de IKE con Quick u Mode, con PFS, AH Modo Tnel, Fase 1 de IKE con Modo Acelerado, Fase 2 de IKE con u Quick Mode, sin PFS, ESP Modo Tnel, Fase 1 de IKE con Modo Acelerado, Fase 2 de IKE con u Quick Mode, sin PFS, AH

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

112

Modo Tnel, Fase 1 de IKE con Modo Acelerado, Fase 2 de IKE con u Quick Mode, con PFS, ESP Modo Tnel, Fase 1 de IKE con Modo Acelerado, Fase 2 de IKE con u Quick Mode, con PFS, AH Modo Transporte, Fase 1 de IKE con Main Mode, Fase 2 de IKE con Quick Mode, sin PFS, ESP Modo Transporte, Fase 1 de IKE con Main Mode, Fase 2 de IKE con Quick Mode, sin PFS, AH Modo Transporte, Fase 1 de IKE con Main Mode, Fase 2 de IKE con Quick Mode, con PFS, ESP Modo Transporte, Fase 1 de IKE con Main Mode, Fase 2 de IKE con Quick Mode, con PFS, AH Modo Transporte, Fase 1 de IKE con Modo Acelerado, Fase 2 de IKE con Quick Mode, sin PFS, ESP Modo Transporte, Fase 1 de IKE con Modo Acelerado, Fase 2 de IKE con Quick Mode, sin PFS, AH Modo Transporte, Fase 1 de IKE con Modo Acelerado, Fase 2 de IKE con Quick Mode, con PFS, ESP Modo Transporte, Fase 1 de IKE con Modo Acelerado, Fase 2 de IKE con Quick Mode, con PFS, AH Para generar trco se enviar un mensaje Echo Request con el cama a po de datos AAAA hasta completar un tamao m n nimo de 2000 bytes. Al establecer nuevos tneles criptogrcos se enviar desde el equipo origen un u a a inicio de conexin TCP o UDP a puertos aleatorios del equipo destino. o 6.2.4.3. Procedimiento

Para cada una de las conguraciones propuestas en el apartado anterior se proceder a establecer desde la implementacin de referencia un tnel a o u criptogrco con los parmetros denidos en la conguracin. Una vez esa a o tablecido el tnel criptogrco, se proceder a enviar trco ICMP desde u a a a el equipo 2 hacia el equipo 1, enviando un m nimo de 10 mensajes. Los mensajes de respuesta debern cumplir que: a Tienen el mismo tamao que el mensaje Echo Request enviado. n Contienen la misma informacin en el campo de datos. o

113

6.2. Conformidad con el estndar a

A continuacin se proceder a enviar los mensajes especialmente preo a parados para cada uno de los protocolos de IPsec, siguiendo la siguiente secuencia: Tienen el mismo tamao que el mensaje Echo Request enviado. n Contienen la misma informacin en el campo de datos. o Seguidamente se proceder a enviar mensajes especialmente formados a desde la implementacin de referencia para evaluar las respuestas de la imo plementacin evaluada. Las pruebas que deben generar el rechazo de la imo plementacin evaluada son: o Solicitud de regeneracin de las claves reutilizando el Nonce anterior. o Solicitud de regeneracin de las claves reutilizando el Vector de Iniciao lizacin anterior. o Solicitud de conguracin (CFG REQ) invlido. o a Env de un mensaje de repuesta de conguracin (CFG REP) sin o o mensaje de solicitud de conguracin (CFG REQ) previo. o Env de un identicador de equipo (FQDN) terminado en NULL. o Env de un identicador de equipo (FQDN) terminado en CR. o Env de un identicador de equipo (FQDN) terminado en CRLF. o Negociacin de suites criptogrcas en las que aparece una longitud o a de clave para algoritmos con clave de tamao jo. n Negociacin de suites criptogrcas en las que aparecen mltiples vao a u lores para un mismo atributo en la misma suite. Negociacin de suites criptogrcas en las que se propone un algoritmo o a de cifrado e integridad, y otro que unicamente ofrece integridad en la misma suite. Env de un mensaje de IKE con un SPI con valor 0. o Mensaje cifrado encapsulado en otro mensaje cifrado. Env de un mensaje de noticacin indicando un SPI invlido, cifrado o o a dicho mensaje. Env de un mensaje que obligue a generar una respuesta de noticao cin, y transmitir un nuevo mensaje en el que se altera el estado de la o asociacin de seguridad. o

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a Utilizacin de la clave de la Fase 1 de IKE en la Fase 2. o

114

Env del secreto compartido durante la negociacin terminado en o o NULL. Env del secreto compartido de ms de 64 bits durante la negociacin. o a o Env de ms trco del que soporta la implementacin evaluada (ino a a o dicado por la ventana de transmisin). o Solicitud de respuesta a un mensaje informativo. Solicitud de cierre de un SPI y posterior reutilizacin de dicho SPI. o Uso del bit cr tico en una cabecera invlida de IKE. a Por su parte, los mensajes que deben ser aceptados por la implementacin evaluada son los siguientes: o Env de una propuesta de conguracin con ESP y AH en la misma o o propuesta (slo uno de los protocolos aparecer en la respuesta). o a Solicitud de renovacin de una asociacin de seguridad antes de tiempo o o y posterior env de trco cuando la asociacin de seguridad nueva y o a o la antigua estn activas. a Codicacin del secreto compartido durante la negociacin en hexao o decimal. Finalmente, restableciendo la conguracin inicial de las implementao ciones de IPsec3 , se proceder a establecer un m a nimo de 5 tneles cripu togrcos diferentes entre las implementaciones de IPsec. Para ello se genea rar trco desde el equipo 1 hacia el equipo 2 estableciendo conexiones a a a diferentes puertos TCP y UDP. 6.2.4.4. Mediciones y resultados

Para cada una de las conguraciones anteriores se almacenar todo a el trco intercambiado entre las implementaciones de IPsec, as como los a registros que pudieran haberse generado. Para cada mensaje especialmente formado se almacenar la respuesta de la implementacin evaluada. a o Para que una implementacin pueda considerarse que implementa coo rrectamente los protocolos de IPsec, el resultado de las pruebas debe ser
3 Puede ser necesario reiniciar el equipo en caso de que se haya producido algn error u durante las pruebas.

115

6.2. Conformidad con el estndar a

tal que se haya podido establecer el tnel criptogrco entre las implemenu a taciones de IPsec con la conguracin indicada, se hayan rechazado todos o los mensajes especialmente creados denidos en el primer grupo del apartado anterior, y se han aceptado los mensajes denidos en el segundo grupo, adaptando el funcionamiento a lo indicado en dichos mensajes, y adems, la a implementacin de IPsec evaluada ha sido capaz de separar el trco geneo a rado desde el equipo 1 hacia el equipo 2 en diferentes tneles criptogrcos. u a 6.2.4.5. Informe de resultados

Se informar de una implementacin exitosa de una conguracin cona o o creta cuando se cumplan las especicaciones determinadas en el apartado anterior. En caso contrario se informar de qu errores se han encontrado, a e indicando cul ha sido el resultado obtenido y cul es el resultado esperado. a a

6.2.5.
6.2.5.1.

Validacin de los mecanismos de autenticacin o o

Objetivos

Determinar la correcta implementacin de los mecanismos de autentio cacin denidos en [65] y [25] y sus documentos asociados. En la siguiente o relacin de pruebas se indicar aquellos casos en los que alguna prueba unio a camente deba aplicarse a una versin determinada de IPsec. o 6.2.5.2. Conguracin necesaria o

La infraestructura necesaria para llevar a cabo la validacin de los meo canismos de seguridad denidos para la arquitectura de seguridad IPsec ser la descrita en el apartado 6.2.2. a En cuanto a la conguracin de las implementaciones IPsec, ambas o debern estar conguradas para establecer tneles criptogrcos utilizando a u a ESP. Las suites criptogrcas a utilizar dependern de los resultados obtenia a dos en las pruebas de conformidad criptogrca, debiendo utilizarse alguna a que haya pasado satisfactoriamente dichas pruebas. Las conguraciones de los diferentes protocolos seguirn el siguiente a plan: Autenticacin unicamente mediante secreto compartido, protegido con o MD5, utilizando Main Mode en la Fase 1 de IKE Autenticacin unicamente mediante secreto compartido, protegido con o MD5, utilizando Modo Acelerado en la Fase 1 de IKE Autenticacin unicamente mediante secreto compartido, protegido con o SHA-1, utilizando Main Mode en la Fase 1 de IKE

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

116

Autenticacin unicamente mediante secreto compartido, protegido con o SHA-1, utilizando Modo Acelerado en la Fase 1 de IKE Autenticacin unicamente mediante claves RSA, utilizando Main Moo de en la Fase 1 de IKE Autenticacin unicamente mediante claves RSA, utilizando Modo Aceo lerado en la Fase 1 de IKE Autenticacin unicamente mediante certicados X.509, utilizando Main o Mode en la Fase 1 de IKE Autenticacin unicamente mediante certicados X.509, utilizando Moo do Acelerado en la Fase 1 de IKE (Slo para IKEv2) Autenticacin unicamente mediante algn mecao o u nismo encapsulado en EAP, utilizando Main Mode en la Fase 1 de IKE (Slo para IKEv2) Autenticacin unicamente mediante algn mecao o u nismo encapsulado en EAP, utilizando Modo Acelerado en la Fase 1 de IKE Para generar trco se enviar un mensaje Echo Request con el campo a a de datos AAAA hasta completar un tamao m n nimo de 512 bytes. 6.2.5.3. Procedimiento

Para cada conguracin diferente descrita en el apartado anterior se o proceder a enviar un mensaje desde el equipo 2 al equipo 1, lo que ocasioa nar el establecimiento del tnel criptogrco entre las dos implementaciones a u a de IPsec, llevando a cabo la autenticacin segn el modo seleccionado. En o u esta primera prueba las credenciales de las dos implementaciones debern a permitir el establecimiento del tnel. Una vez establecido el tnel se prou u ceder a enviar un mensaje Echo Request conrmando la recepcin de la a o respuesta. A continuacin se cerrar el tnel criptogrco establecido y se modio a u a carn las credenciales en la implementacin de referencia, de tal forma que a o sea la implementacin evaluada la que rechace el establecimiento del tnel o u criptogrco. a Finalmente, se restaurarn las credenciales en la implementacin de a o referencia y se modicarn en la implementacin evaluada, lo que llevar a a o a la implementacin de referencia a denegar el establecimiento del tnel. o u Estas pruebas se llevarn a cabo para todas las conguraciones descritas a en el apartado anterior.

117 6.2.5.4.

6.2. Conformidad con el estndar a Mediciones y resultados

Para cada una de las conguraciones anteriores se almacenar todo a el trco intercambiado entre las implementaciones de IPsec, as como los a registros de autenticacin que se pudieran haber generado. o Para que una implementacin pueda considerarse que implementa coo rrectamente los mtodos de autenticacin de IPsec, el resultado de las pruee o bas debe ser tal que se haya podido establecer el tnel criptogrco entre u a las implementaciones de IPsec con la conguracin indicada. Para que una o implementacin sea conforme con los mtodos de autenticacin de IKE baso e o tar con que implemente correctamente los mtodos de autenticacin mea e o diante secreto compartido y certicados X.509. 6.2.5.5. Informe de resultados

Se informar de una implementacin exitosa de un mtodo de autentia o e cacin concreto cuando el establecimiento de los tneles criptogrcos haya o u a sido exitoso en el caso de que las credenciales utilizadas fueran correctas y haya sido denegado en caso contrario. Se informar de una implementacin a o conforme a IPsec si los mtodos de autenticacin mediante secreto compare o tido y certicados X.509 estn implementados correctamente. La implemena tacin incorrecta de otros mtodos originar mensajes de aviso advirtiendo o e a de la imposibilidad de utilizar dicho mecanismo.

6.2.6.
6.2.6.1.

Validacin de la gestin de claves o o

Objetivos

Determinar la correcta implementacin de los protocolos de gestin de o o claves de IPsec. Aunque los protocolos de gestin de claves pueden ser lio bremente implementados por los fabricantes (aunque la mayor opta por a utilizar el propuesto en los estndares: IKE), todos ellos deben contar con a una serie de caracter sticas que hagan posible su interoperatividad. 6.2.6.2. Conguracin necesaria o

La infraestructura necesaria para llevar a cabo la validacin de los meo canismos de seguridad denidos para la arquitectura de seguridad IPsec ser la descrita en el apartado 6.2.2. a En cuanto a la conguracin de las implementaciones IPsec, ambas o debern estar conguradas para establecer tneles criptogrcos utilizando a u a ESP. Las suites criptogrcas a utilizar dependern de los resultados obtenia a dos en las pruebas de conformidad criptogrca, debiendo utilizarse alguna a que haya pasado satisfactoriamente dichas pruebas.

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

118

En el caso de utilizar IPsec v1 las implementaciones necesitar negociar los parmetros de conguracin, por lo que la secuencia de conguraciones a o necesarias ser la siguiente para ambas implementaciones: a Caducidad de la clave de la Fase 1 de IKE en 30 segundos. Caducidad de la clave de la Fase 2 de IKE en 30 segundos. Caducidad de la clave de la Fase 1 de IKE al transmitir 10 KBytes. Caducidad de la clave de la Fase 2 de IKE al transmitir 10 KBytes. Sin embargo, si se utiliza IPsec v2 las conguraciones que sern utilizaa das son4 : Caducidad de la clave de la Fase 1 de IKE en 30 segundos en la implementacin de referencia. o Caducidad de la clave de la Fase 2 de IKE en 30 segundos en la implementacin de referencia. o Caducidad de la clave de la Fase 1 de IKE al transmitir 10 KBytes en la implementacin de referencia. o Caducidad de la clave de la Fase 2 de IKE al transmitir 10 KBytes en la implementacin de referencia. o Caducidad de la clave de la Fase 1 de IKE en 30 segundos en la implementacin evaluada. o Caducidad de la clave de la Fase 2 de IKE en 30 segundos en la implementacin evaluada. o Caducidad de la clave de la Fase 1 de IKE al transmitir 10 KBytes en la implementacin evaluada. o Caducidad de la clave de la Fase 2 de IKE al transmitir 10 KBytes en la implementacin evaluada. o Para generar trco se enviar un mensaje Echo Request con el campo a a de datos AAAA hasta completar un tamao m n nimo de 2000 bytes.
4 Para cada una de estas conguraciones la implementacin de la que no se dice nada o tiene valores mayores de caducidad de las claves

119 6.2.6.3. Procedimiento

6.2. Conformidad con el estndar a

Para cada conguracin diferente descrita en el apartado anterior se o proceder a establecer un tnel criptogrco entre las implementaciones de a u a IPsec, comprobando si el proceso de renegociacin de claves se lleva a cabo o de forma satisfactoria. Debido a las caracter sticas de la caducidad de las claves en IKEv1 y en IKEv2, si estamos evaluando una implementacin de o IKEv1 basta con evaluar el caso en que ambas implementaciones acuerdan renovar las claves, mientras que en IKEv2 es necesario evaluar el caso en el que cada implementacin necesita renegociar las claves. o Para las conguraciones en las que la caducidad se dene en funcin del o trco protegido, una vez establecido el tnel criptogrco se proceder a a u a a enviar informacin desde el equipo 2 al equipo 1, hasta forzar el proceso de o renegociacin de claves. o Estas pruebas se llevarn a cabo para todas las conguraciones descritas a en el apartado anterior. 6.2.6.4. Mediciones y resultados

Para cada una de las conguraciones anteriores se almacenar todo a el trco intercambiado entre las implementaciones de IPsec, as como los a registros de log que pudieran haberse generado. Para que una implementacin pueda considerarse que implementa coo rrectamente la gestin de claves criptogrcas tal y como se describe en la o a arquitectura de seguridad IPsec, el resultado de las pruebas debe ser tal que se hayan realizado todos los procesos de renegociacin de claves de forma o satisfactoria; esto es, sin producirse errores que interrumpan una posible comunicacin entre las redes protegidas. o 6.2.6.5. Informe de resultados

Se informar de una implementacin exitosa de la gestin de claves a o o en IPsec cuando en todas las conguraciones anteriores la implementacin o evaluada haya realizado exitosamente la gestin de claves. o

6.2.7.
6.2.7.1.

Validacin de otras caracter o sticas

Objetivos

Determinar la correcta implementacin de caracter o sticas incluidas en los estndares que conforman la arquitectura de seguridad de IPsec y que son a necesarias para establecer tneles criptogrcos en determinadas topolog u a as de red o situaciones concretas. Estas caracter sticas son la compresin de o

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

120

datos a nivel IP mediante IPComp (denido en [140]), el NAT traversal (denido en [65] y [25]) y la noticacin expl o cita de congestin en la red o (denida en [132] e incorporada a la arquitectura IPsec en [25]). 6.2.7.2. Conguracin necesaria o

La infraestructura necesaria para llevar a cabo la validacin de los meo canismos de seguridad denidos para la arquitectura de seguridad IPsec ser la descrita en el apartado 6.2.2. Para poder evaluar la utilizacin de a o NAT traversal ser necesario que las dos implementaciones de IPsec realicen a NAT sobre la red que protegen. En cuanto a la conguracin de las implementaciones IPsec, ambas o debern estar conguradas para establecer tneles criptogrcos utilizando a u a ESP. Las suites criptogrcas a utilizar en IKE dependern de los resultados a a obtenidos en las pruebas de conformidad criptogrca, debiendo utilizarse a alguna que haya pasado satisfactoriamente dichas pruebas. En cuanto a ESP se recomienda utilizar el algoritmo NULL para proteger la informacin, o aunque la utilizacin de otros algoritmos no alterar el resultado de estas o a pruebas. Para poder llevar a cabo las pruebas de compresin de datos en la capa o IP ser necesario que ambas implementaciones de seguridad incluyan en su a conguracin la necesidad de utilizar dicha caracter o stica. Para generar el trco necesario para la evaluacin de la noticacin de a o o la congestin de red se establecern dos conexiones UDP entre los equipos o a 1 y 2 (una en cada sentido) y se proceder a transmitir informacin tan a o rpidamente como sea posible. Para el resto de pruebas la comunicacin a o se establecer enviando mensajes Echo Request con el campo de datos a AAAA hasta completar un tamao m n nimo de 2000 bytes. 6.2.7.3. Procedimiento

Para evaluar el funcionamiento de la implementacin de NAT traversal o se establecern dos tneles criptogrcos entre los equipos 1 y 2 (uno en a u a cada sentido), para cada una de las siguientes conguraciones: La implementacin evaluada utiliza NAT traversal; la implementacin o o de referencia no utiliza NAT traversal. La implementacin evaluada no utiliza NAT traversal; la implementao cin de referencia utiliza NAT traversal. o La implementacin evaluada utiliza NAT traversal; la implementacin o o de referencia utiliza NAT traversal.

121

6.2. Conformidad con el estndar a

Tras el establecimiento de cada par de tneles criptogrcos se transu a mitir informacin por dichos tneles hasta enviar un m a o u nimo de 5 mensajes en cada sentido. La evaluacin de la compresin de datos en la capa IP se llevar a cabo o o a habilitando esta opcin en ambas implementaciones. Una vez establecido un o tnel criptogrco en estas condiciones se proceder a enviar un m u a a nimo de 5 mensajes desde el equipo 1 hacia el equipo 2. Por ultimo, para llevar a cabo la evaluacin de la noticacin expl o o cita de congestin, se establecer un tnel criptogrco entre ambas implemeno a u a taciones y se proceder a enviar trco tal y como se describe en el apartado a a anterior durante un m nimo de 30 segundos. 6.2.7.4. Mediciones y resultados

Al llevarse a cabo las pruebas para la evaluacin de la implementacin o o del NAT traversal se almacenarn los posibles registros de log que se hayan a generado, as como el resultado del establecimiento de la comunicacin entre o los equipos 1 y 2 y los mensajes ICMP de respuesta que hayan recibido los equipos 1 y 2. Para que una implementacin desarrolle correctamente el NAT o traversal los mensajes deben haber sido respondidos en ambos sentidos sin errores y en las tres conguraciones propuestas en el apartado anterior. En cuanto a la compresin en la capa IP, al llevarse a cabo esta prueba se o almacenarn los registros de log que se hayan generado durante la ejecucin a o de la misma y los mensajes ICMP de respuesta recibidos por el equipo 1. La implementacin evaluada desarrollar correctamente esta tcnica de o a e compresin si los mensajes ICMP recibidos se corresponden con mensajes o ICMP de Echo Reply correspondientes a los enviados por ese mismo equipo. Por ultimo, la evaluacin de la noticacin expl o o cita de la congestin o de la red requiere del almacenamiento de los registros de log producidos por las implementaciones de IPsec, as como los de otros dispositivos de red que pudieran existir en la infraestructura de pruebas y los mensajes ICMP que otros equipos hayan podido generar al detectar la congestin de o la red. La implementacin evaluada necesitar haber enviado los mensajes de o a noticacin de la congestin y haber operado en consecuencia (por ejemplo, o o reduciendo su ventana de transmisin) para poder ser considerada como o conforme al estndar. a 6.2.7.5. Informe de resultados

Se informar de una implementacin exitosa de NAT traversal cuando a o en todas las conguraciones anteriores la implementacin evaluada haya sido o capaz de redirigir el trco a travs del NAT al equipo de destino correcto, a e sin prdida de datos. e

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

122

Se informar de un desarrollo exitoso de la compresin de datos en la a o capa IP cuando la implementacin estudiada haya podido negociar y utilizar o dicha caracter stica al establecer canales seguros con la implementacin de o referencia. Se informar de una implementacin exitosa de la noticacin expl a o o cita de congestin en la red cuando la implementacin haya enviado y recibido o o los mensajes de noticacin de la congestin al incrementar el trco en la o o a red, y haya modicado sus parmetros de env de datos para adaptarse a a o la nueva situacin. o

6.3.

Evaluacin del rendimiento o

El rendimiento de una implementacin de un protocolo de seguridad es o un aspecto fundamental para poder conocer y planicar la evolucin futura o de nuestra red de comunicaciones. De esta forma, adems de adquirir un a conocimiento acerca de nuestra infraestructura que es indispensable de cara a prevenir ataques que pudieran impedir el desarrollo de las actividades para las que estaba prevista dicha red (por ejemplo, los ataques de Denegacin de o Servicio), estamos facilitando el identicar, promover y utilizar las conguraciones, tcnicas y herramientas que mejor rendimiento pueden ofrecernos; e es decir, estamos asegurndonos de utilizar la implementacin de IPsec de a o forma ptima. En esta seccin se denen las pruebas que es necesario llevar o o a cabo para poder evaluar correctamente el rendimiento que puede ofrecer nuestra implementacin de IPsec. o

6.3.1.

Requisitos

Las pruebas estn orientadas a la evaluacin del rendimiento de la ima o plementacin de IPsec, por lo que es necesario que la infraestructura de red o sobre la que se realizan las pruebas cuente con las siguientes caracter sticas: Sea una arquitectura dedicada, de forma que no haya otros equipos o dispositivos que puedan interferir en la medicin de resultados5 . o Tenga una capacidad mayor que la mxima del dispositivo que se a evala. Al establecer cul es la mxima capacidad de trco se habr de u a a a a considerar que el dispositivo puede utilizar el mximo ancho de banda a en modo Full-Duplex para cada una de sus conexiones de red por las que establezcan tneles IPsec. u Adicionalmente, ser necesario disponer de sucientes equipos en cada a una de las redes protegidas (la red protegida por la implementacin a evaluar o
5 Como ya se discuti en el cap o tulo 5, es posible utilizar una arquitectura de red no dedicada, pero los resultados que se obtendrn no sern precisos a a

123

6.3. Evaluacin del rendimiento o

y la protegida por la implementacin de referencia descrita en el apartado o 6.2.1) para poder saturar la red que unir ambas implementaciones. a Dado que es necesario modicar la conguracin de las suites cripo togrcas utilizadas en el establecimiento de tneles criptogrcos y la proa u a teccin de la informacin, es preciso disponer del control sobre la impleo o mentacin que se validar. Esta conguracin se centrar sobre todo en las o a o a herramientas criptogrcas que se utilizarn, por lo que el haber llevado a a a cabo la validacin de la conformidad con el estndar previamente es tambin o a e una necesidad. En cuanto a la medicin y generacin del trco que se utilizar, ser neo o a a a cesario contar con software o hardware capaz de establecer comunicaciones ICMP, TCP y UDP entre diferentes equipos, enviando datos tanto a una velocidad determinada (por ejemplo, 3 Mbps) como sin l mite en la velocidad de transferencia. Tambin ser preciso que este software pueda iniciar e a conexiones nuevas entre equipos a intervalos regulares de tiempo, mientras mantiene las conexiones establecidas de antemano y env informacin por a o dichas conexiones. En cuanto a la medicin, ser necesario disponer de heo a rramientas similares a IPtraf ([80]) en ambas redes y en la red que une las implementaciones de IPsec.

6.3.2.

Conguracin de las pruebas o

Con el n de ejecutar las pruebas de rendimiento que se describirn a a continuacin ser necesario disponer de una implementacin de IPsec con o a o la que la implementacin de IPsec analizada pueda establecer tneles cripo u togrcos, tal y como se ha descrito en el apartado anterior. Adicionalmente, a es necesario que ambas implementaciones protejan una red en la que debern a existir al menos tantos equipos como sea preciso para saturar los enlaces de red que comunican la implementacin de referencia con la implementacin o o evaluada. Por ejemplo, si las implementaciones de IPsec estn unidas por a dos enlaces Fast Ethernet de 100 Mbps, ser necesario que en cada una de a las redes existan equipos sucientes para generar un trco de, al menos, 200 a Mbps en direccin a la otra red. Antes de comenzar a realizar las pruebas o de rendimiento es aconsejable vericar que los equipos, sin utilizar IPsec, pueden utilizar el mximo ancho de banda posible en la infraestructura de a red utilizada (en el caso anterior, deber poderse obtener un ancho de bana da acumulado de alrededor de 400 Mbps, resultante de obtener el mximo a ancho de banda de la red (100 Mbps) por cada enlace f sico (2 enlaces) y en cada sentido (al utilizar Full-Duplex es posible obtener el mximo ancho de a banda de Ethernet en cada sentido de la comunicacin)). o Entre ambas redes se situar un equipo de red que sea capaz de alterar a las condiciones de la red (retardo, prdida y reenv de paquetes) de forma e o articial, lo que nos permitir comprobar cul es el comportamiento de la a a

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

124

Figura 6.3: Posible esquema de red utilizado para la evaluacin del rendio miento de una implementacin IPsec. o implementacin IPsec en determinadas condiciones de la red. Este equipo de o red debe tener capacidad de proceso suciente para distribuir todo el trco a que deber enviarse por la red en ambos sentidos. Una posible solucin a o es la utilizacin de un ordenador personal con software de emulacin de o o condiciones de red, como por ejemplo [124]. Al igual que ocurr anteriormente, las direcciones de red asignadas a debern ser tales que no produzcan ningn conicto con el resto de la ina u fraestructura de red existente. En este caso se recomienda utilizar una infraestructura de red dedicada, por lo que las direcciones de red utilizadas no deber afectar a las pruebas; sin embargo, si esto no es posible, se rean comienda utilizar el rango reservado por el IANA para este tipo de pruebas (desde 192.18.0.0 hasta 192.19.255.255). Por lo tanto, una posible infraestructura de red en este caso ser la a representada en la gura 6.3.2. En el caso de que la implementacin evaluada o slo pueda operar en modo de equipo nal, la conguracin se simplica, o o ya que los mximos anchos de banda posibles son menores. Sin embargo, a todas las pruebas pueden ser llevadas a cabo igualmente, por lo que no se especicar si las pruebas se llevan a cabo en una conguracin o en otra. a o Antes de comenzar las pruebas propuestas es necesario comprobar que la conguracin de red de todos los dispositivos es correcta, por lo que, o

125

6.3. Evaluacin del rendimiento o

desactivando la utilizacin de IPsec, se comprobar que todos los dispositivos o a pueden establecer una comunicacin con el resto de equipos involucrados en o las pruebas mediante ICMP y un rango de al menos 1000 puertos TCP y otros 1000 UDP. En cada uno de los equipos instalados en las redes protegidas por las implementaciones de IPsec se implantar un medidor del trco de red ena a viado y recibido y un generador de trco de red con las caracter a sticas descritas anteriormente.

6.3.3.

Perles de trco a

Para llevar a cabo mediciones de rendimiento realistas y alejadas de mximos tericos que no se corresponden con situaciones reales, se denen a o perles de trco para obtener informacin de rendimiento en funcin del a o o tipo de uso que se haga de la red de comunicaciones. Los siguientes perles de trco sern obligatorios en aquellas pruebas en las que sea necesario utilizar a a perles de trco. Queda a voluntad del usuario el incluir otros perles en a el conjunto de aquellos que se utilizarn en las pruebas. a Perl: Mximo ancho de banda a Protocolo UDP Tama o de los paquetes de datos Igual al MTU n Sentido Bidireccional (ambas entidades se env trco) an a Medicin En el receptor. El ancho de banda total ser la suma del trco o a a en los dos receptores. Retardo articial 0ms Prdida de paquetes 0 % e Reenv de paquetes 0 % o Descripcin En este perl las entidades involucradas se env mensajes o an utilizando el protocolo UDP sin esperar ni generar ninguna respuesta. Dado que no se garantiza que todo el trco UDP que se env llegue a a a su destino, la medicin del trco que ha sido transmitido por el canal o a IPsec se realizar en el destino. a

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a Perl: Ancho de banda en red saturada Protocolo UDP Tama o de los paquetes de datos Igual al MTU n Sentido Bidireccional (ambas entidades se env trco) an a

126

Medicin En el receptor. El ancho de banda total ser la suma del trco o a a en los dos receptores. Retardo articial 1500ms Prdida de paquetes 40 % e Reenv de paquetes 65 % o Descripcin En este perl las entidades involucradas se env mensajes o an utilizando el protocolo UDP sin esperar ni generar ninguna respuesta. Dado que no se garantiza que todo el trco UDP que se env llegue a a a su destino, la medicin del trco que ha sido transmitido por el canal o a IPsec se realizar en el destino. Las condiciones de red se modican a articialmente para obtener informacin del comportamiento en una o red saturada.

Perl: Usuario Tradicional Protocolo 90 % TCP, 9 % UDP, 1 % ICMP Tama o de los paquetes de datos 250 bytes n Sentido Unidireccional (una entidad env trco; la otra slo env ACKs). a a o a Los equipos situados en la red protegida por la implementacin de o IPsec analizada realizan el papel de clientes de estas comunicaciones. Medicin En el receptor, debido a la presencia de trco UDP. o a Retardo articial 0ms Prdida de paquetes 1 % e Reenv de paquetes 2 % o Descripcin Este perl simula un comportamiento de trco similar al de o a la mayor de los usuarios de redes de ordenadores, utilizando protoa colos basados en TCP de forma mayoritaria, y dejando unicamente un pequeo margen para el trco UDP e ICMP. n a

127

6.3. Evaluacin del rendimiento o

Perl: TCP Asimtrico Entrante e Protocolo TCP Tama o de los paquetes de datos Igual al MTU n Sentido Unidireccional (una entidad env trco; la otra slo env ACKs). a a o a Los equipos situados en la red protegida por la implementacin de o IPsec analizada realizan el papel de servidores de esta comunicacin. o Medicin En el emisor o en el receptor. o Retardo articial 0ms Prdida de paquetes 1 % e Reenv de paquetes 2 % o Descripcin Este perl modela la utilizacin de protocolos basados en o o TCP de forma mayoritaria. Su inters radica en la elevada desigualdad e entre el nivel de trco enviado y recibido. a

Perl: TCP Asimtrico Saliente e Protocolo TCP Tama o de los paquetes de datos Igual al MTU n Sentido Unidireccional (una entidad env trco; la otra slo env ACKs). a a o a Los equipos situados en la red protegida por la implementacin de o IPsec analizada realizan el papel de clientes de esta comunicacin. o Medicin En el emisor o en el receptor. o Retardo articial 0ms Prdida de paquetes 1 % e Reenv de paquetes 2 % o Descripcin Este perl modela la utilizacin de protocolos basados en o o TCP de forma mayoritaria. Su inters radica en la elevada desigualdad e entre el nivel de trco enviado y recibido. a

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a Perl: TCP Simtrico e Protocolo TCP Tama o de los paquetes de datos Igual al MTU n Sentido Bidireccional (ambas entidades se env trco) an a Medicin En el emisor o en el receptor. o Retardo articial 0ms Prdida de paquetes 1 % e Reenv de paquetes 2 % o

128

Descripcin Este perl sirve para obtener informacin acerca del mximo o o a rendimiento que la implementacin podr ofrecer al utilizar aplicacioo a nes basadas en TCP. El rendimiento de este perl ser menor que el a del perl de mximo rendimiento ya que la necesidad de esperar la a conrmacin de la entrega de los mensajes ralentiza la comunicacin. o o

Perl: TCP Simtrico en red saturada e Protocolo TCP Tama o de los paquetes de datos Igual al MTU n Sentido Bidireccional (ambas entidades se env trco) an a Medicin En el emisor o en el receptor. o Retardo articial 1500ms Prdida de paquetes 40 % e Reenv de paquetes 65 % o Descripcin Este perl sirve para obtener informacin acerca del mximo o o a rendimiento que la implementacin podr ofrecer al utilizar aplicacioo a nes basadas en TCP. La saturacin articial de la red nos indicar cul o a a es el comportamiento de la implementacin en situaciones no ptimas. o o Para generar articialmente las condiciones de red descritas en los perles, se recomienda la utilizacin de hardware especializado, o herramientas o como NIST Net ([124]), que permiten introducir alteraciones en el comportamiento de la red con gran exibilidad y ecacia.

129

6.3. Evaluacin del rendimiento o

6.3.4.
6.3.4.1.

Ancho de banda
Objetivos

Determinar el mximo ancho de banda que la implementacin de IPsec a o puede proteger cuando la informacin es transmitida de acuerdo a los pao trones de trco denidos en el apartado anterior y a otros en los que el a usuario pueda estar interesado. Ntese que en los perles se hace referencia o al tamao de los paquetes que se env n an, aunque realmente nos referimos al tamao de los mensajes que se transmiten, sean del nivel que sean. n 6.3.4.2. Conguracin necesaria o

Las implementaciones de IPsec se congurarn para establecer los tnea u les criptogrcos utilizando en las dos fases de IKE cualquier suite cripa togrca y mecanismo de autenticacin que permita la interoperatividad a o entre ellas. La conguracin de los protocolos ESP y AH para proteger el trco en o a la implementacin a analizar consistir en las siguientes suites criptogrcas: o a a ESP utilizando el algoritmo de cifrado NULL - Sin control de integridad ESP utilizando 3DES en modo CBC y HMAC-MD5-96 ESP utilizando 3DES en modo CBC y HMAC-SHA1-96 ESP utilizando AES con 128 bits de clave en modo CBC - AES-XCBCMAC-96 AH utilizando HMAC-MD5-96 AH utilizando HMAC-SHA1-96 AH utilizando AES-XCBC-MAC-96 Opcionalmente se podrn congurar otras suites criptogrcas que sean a a de inters para el usuario. e En los equipos situados en las redes protegidas por las implementaciones de IPsec se congurarn los mecanismos de medicin del trco emitido y a o a recibido por cada equipo. Asimismo, se congurarn tambin los mecanismos a e de generacin del trco para utilizar, al menos, los siguientes perles: o a Mximo ancho de banda a Usuario Tradicional

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a TCP Asimtrico entrante e TCP Asimtrico saliente e TCP Simtrico e

130

Tras realizar los anlisis con estos perles de trco se podrn utilizar otros a a a en los que el usuario est interesado. e El uso de compresin en la capa de datos IP no afecta a la medida del o ancho de banda, aunque se desaconseja para evitar efectos colaterales en la implementacin analizada o 6.3.4.3. Procedimiento

Para cada una de las conguraciones de ESP reseadas en el apartan do anterior, se generar trco de acuerdo con cada uno de los perles de a a trco que se utilicen, utilizando tantos equipos como sea necesario. Una a vez iniciada la generacin de trco, se mantendr dicha generacin durante o a a o al menos 10 segundos, para facilitar que las velocidades de transmisin se o estabilicen. Pasado este tiempo de estabilizacin, se iniciar la medicin del o a o ancho de banda utilizado, de acuerdo con lo especicado en el perl. Dicha medicin se llevar a cabo durante al menos 5 segundos, almacenando el o a ancho de banda medio que se ha utilizado durante este periodo de medicin. o Este proceso se repetir 3 veces, calculando nalmente el valor medio de a esas tres medidas. El procedimiento descrito se llevar a cabo para cada perl de trco a a en cada conguracin, por lo que el m o nimo nmero de medidas a realizar u ser de 75 medidas. Hay que tener en cuenta que tras sobrecargar la red a puede ser necesario reiniciar los dispositivos o, al menos, cerrar todas las asociaciones de seguridad y esperar un periodo entre 15 y 30 segundos para que la implementacin libere recursos ocupados. o Si se decide utilizar otros perles de trco, es necesario recordar que a cada perl de trco debe ser evaluado utilizando todas las conguraciones a de ESP y AH posibles. 6.3.4.4. Mediciones y resultados

La medicin del ancho de banda utilizado en cada tnel criptogrco se o u a har de acuerdo a lo especicado en cada perl. En caso de duda, hay que a tener en cuenta que el trco de los protocolos que no aseguran la entrega a del trco cursado ha de ser medido en el receptor de dicho trco, ya que a a no hay garant de que todos los mensajes enviados por el origen hayan sido as transmitidos a travs del tnel IPsec. El trco de protocolos que s incluyen e u a

131

6.3. Evaluacin del rendimiento o

mecanismos para asegurar la entrega de los mensajes puede ser medido en el origen o en el destinatario indistintamente. La medicin debe llevarse a cabo tras haberse estabilizado las velocidao des de transmisin. Normalmente 10 segundos bastan para ello, aunque si al o iniciar la medicin se detectase una alta variabilidad en los anchos de banda o que se transmiten, se deber esperar un periodo adicional de seguridad. Al a llevar a cabo la medida habr que llevar a cabo la medicin del ancho de a o banda durante un periodo m nimo de 5 segundos, almacenndose los valoa res medio, mximo y m a nimo de ese periodo. Este proceso se repetir tres a veces, calculando la media aritmtica de los valores medios, y almacenando e los valores mximos y m a nimos totales. Al nalizar todas las medidas se dispondr de informacin acerca del a o ancho de banda mximo que podemos obtener para cada perl de trco, a a segn cada una de las conguraciones de los protocolos ESP y AH. u

6.3.4.5.

Informe de resultados

Al nalizar las pruebas se informar al usuario de los resultados oba tenidos, informando para cada par Perl - Conguracin de ESP / AH o de: Valor medio del ancho de banda medido.6 . Valor mximo del ancho de banda medido. a Valor m nimo del ancho de banda medido.

6.3.5.
6.3.5.1.

Mximo n mero de AS simultneas a u a

Objetivos

Determinar la cantidad mxima de asociaciones de seguridad que la a implementacin de IPsec analizada puede mantener negociadas simultneao a mente, sin que se transmita informacin alguna por dichas asociaciones. El o establecimiento de las asociaciones de seguridad se llevar a cabo de acuera do a lo especicado en [65], [101] y [25]. La medicin de este parmetro se o a llevar a cabo basndose en la propuesta similar del IETF para la medicin a a o del rendimiento de cortafuegos, especicada en [69].
Este valor medio representa el Ancho de Banda mximo que podemos esperar para a este perl de trco con esta conguracin, ya que no representa un extremo estad a o stico o outlier
6

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a 6.3.5.2. Conguracin necesaria o

132

Las implementaciones de IPsec se congurarn para establecer los tnea u les criptogrcos utilizando en las dos fases de IKE cualquier suite cripa togrca y mecanismo de autenticacin que permita la interoperatividad a o entre ellas, ya que el rendimiento de los mecanismos utilizados no afectar a a los resultados de las pruebas. Se congurar el protocolos AH para protea ger el trco, utilizando cualquier mecanismo disponible. Se congurarn a a las bases de datos de pol ticas de IPsec de tal forma que cada conexin se o proteja mediante un tnel criptogrco propio. u a En los equipos situados en las redes protegidas por las implementaciones de IPsec se congurarn los mecanismos para establecer conexiones a TCP entre dos mquinas, sin intercambio de informacin alguno por dichas a o conexiones. En las redes protegidas por la(s) implementacin(es) de IPsec o de referencia se situarn los clientes, mientras que en red protegida por la a implementacin evaluada se situarn los servidores. Estos mecanismos debes o a ser capaces de iniciar una nueva conexin pasado un determinado tiempo, o mientras mantiene el resto de conexiones abiertas. Adems, estos mecanisa mos alertarn en el caso de que una conexin establecida se haya cerrado, o a o si un intento de conexin es infructuoso. o El uso de compresin en la capa de datos IP no afecta a la medida o del nmero mximo de asociaciones de seguridad simultneas, aunque se u a a desaconseja para evitar efectos colaterales en la implementacin analizada o 6.3.5.3. Procedimiento

Una vez congurados los dispositivos y la infraestructura de red, se proceder a establecer conexiones entre los dispositivos protegidos por las a implementaciones IPsec de referencia y la implementacin analizada, a razn o o 7 . Este proceso continuar hasta que se de una nueva conexin por segundo o a de una de las siguiente condiciones: 1. Un intento de establecimiento de conexin resulta fallido. o 2. Una conexin previamente establecida se cierra. o En este momento se almacenar la cantidad de asociaciones de seguridad a establecidas hasta el momento en que se ha dado la situacin que ha ino terrumpido el proceso, y se cerrarn todos los tneles criptogrcos que a u a permanezcan abiertos. Se repetir este mismo proceso incrementando a 2 segundos el periodo a entre conexiones, con el n de descartar saturaciones de la CPU de la imple7 Este tiempo empezar a medirse a partir de la nalizacin del establecimiento de coo nexin anterior, para evitar el solapamiento de establecimientos de conexin. o o

133

6.3. Evaluacin del rendimiento o

mentacin. En el caso de que la cantidad de asociaciones de seguridad sea o la misma que en caso anterior, se nalizar la prueba; en caso contrario, se a repetir el proceso incrementando el periodo entre conexiones. Unicamente a cuando dos procesos de establecimiento de conexiones con diferentes intervalos entre conexiones ofrezcan los mismos resultados se nalizar el desarrollo a de estas pruebas. En caso de estimar que el valor inicial de un segundo entre cada establecimiento de conexin es demasiado alto o bajo para la implementacin o o que se est analizando, es posible utilizar otro valor que se aproxime ms a a al valor con el que determinaremos el nmero mximo de asociaciones de u a seguridad.

6.3.5.4.

Mediciones y resultados

En el momento en que el proceso de establecimiento de conexiones se interrumpa por alguna de las condiciones indicadas en el apartado anterior, se almacenar el nmero de asociaciones de seguridad establecidas previamena u te. Al conrmar que la cantidad de asociaciones de seguridad establecidas es el mximo para la implementacin estudiada (segn se describe en el a o u apartado anterior), se presentar ese valor como resultado de las pruebas a realizadas.

6.3.5.5.

Informe de resultados

El informe de resultados de estas pruebas indicar, para todas las iteraa ciones en el proceso de establecimiento de conexiones llevadas a cabo, cul ha a sido su intervalo entre establecimiento de conexiones y cuntas asociaciones a de seguridad se han llegado a establecer.

6.3.6.
6.3.6.1.

Capacidad de establecimiento de asociaciones de seguridad

Objetivos

Determinar la cantidad mxima de asociaciones de seguridad que la a implementacin de IPsec puede establecer por unidad de tiempo, mientras o cada asociacin de seguridad protege un determinado ancho de banda. El o establecimiento de asociaciones de seguridad mientras otros tneles cripu togrcos previamente establecidos hacen uso de parte del ancho de banda a disponible para transmitir informacin es una situacin muy normal hoy en o o d y que puede ser origen de ataques de denegacin de servicio. a o

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a 6.3.6.2. Conguracin necesaria o

134

Las implementaciones de IPsec se congurarn para establecer los tnea u les criptogrcos de acuerdo a las siguientes conguraciones para IKE y ESP a / AH: IKE Fase 1 Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 2 (1024 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96 IKE Fase 2 Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96

135

6.3. Evaluacin del rendimiento o Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 2 (1024 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96 ESP / AH ESP con Algoritmo de cifrado NULL - Sin control de integridad ESP con 3DES en modo CBC y HMAC-SHA1-96 ESP con AES (128 bits de clave) en modo CBC - AES-XCBCMAC-96 AH con HMAC-SHA1-96 AH con AES-XCBC-MAC-96

En los equipos situados en las redes protegidas por las implementaciones de IPsec se congurarn los mecanismos para establecer conexiones a TCP entre dos mquinas, intercambiando informacin por dichas conexioa o nes segn el perl TCP Simtrico. La velocidad a la que la informacin u e o se transmitir y la cantidad de conexiones que se establecern ser variable a a a entre prueba y prueba8 . En la siguiente lista vemos las combinaciones de ancho de banda por cada tnel criptogrco y cantidad de asociaciones de u a seguridad que se evaluarn (M es el mximo ancho de banda (en Mbps) para a a comunicaciones con el perl TCP asimtrico, calculado anteriormente): e
M 0,5

tneles, transmitiendo 0,5 Mbps por cada tnel. u u

M tneles, transmitiendo 1 Mbps por cada tnel. u u

M 2 M 3 M 4 M 5
8

tneles, transmitiendo 2 Mbps por cada tnel. u u tneles, transmitiendo 3 Mbps por cada tnel. u u tneles, transmitiendo 4 Mbps por cada tnel. u u tneles, transmitiendo 5 Mbps por cada tnel. u u

El ancho de banda total que debe utilizarse se distribuir equitativamente entre ambos a sentidos. Por lo tanto, una prueba que requiera utilizar un ancho de banda de 2 Mbps por cada tnel enviar 1 Mbps de la implementacin de referencia a la implementacin u a o o evaluada y 1 Mbps en sentido contrario.

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

136

En el caso de que se desee evaluar otras velocidades de transmisin, o ser posible, siempre que la cantidad de asociaciones de seguridad creadas a (AS) venga dada por la siguiente expresin (en la que V es la velocidad que o se desea medir, en Mbps): M AS = (6.1) V El uso de compresin en la capa de datos IP no afecta a la medida o del nmero mximo de asociaciones de seguridad simultneas, aunque se u a a desaconseja para evitar efectos colaterales en la implementacin analizada o 6.3.6.3. Procedimiento

Para cada combinacin de: o Conguracin de Fase 1 de IKE, o Conguracin de Fase 2 de IKE, o Conguracin de ESP / AH, y o Velocidad de transmisin y asociaciones de seguridad a crear, o se congurarn las implementaciones IPsec de acuerdo a la conguracin a o correspondiente de IKE y ESP / AH. A continuacin se comenzarn a estao a blecer las conexiones entre los equipos protegidos por las implementaciones de IPsec, de tal forma que se empezarn a negociar asociaciones de segua ridad entre ellas. Al establecerse cada conexin los equipos transmitirn o a informacin a la velocidad establecida para la cantidad de asociaciones de o seguridad a establecer. El intervalo de tiempo que separar las conexiones a nuevas ser de 1 segundo, incrementndose en caso de que no sea posible a a establecer todas las conexiones; es decir, en caso de que: 1. Un intento de establecimiento de conexin resulta fallido. o 2. Una conexin previamente establecida se cierre. o 3. Una vez establecidas todas las conexiones no sea posible mantenerlas durante al menos 10 segundos. En caso de fallo se cerrarn todas las conexiones establecidas y se volver a a a comenzar, incrementando el intervalo entre cada intento de conexin en un o segundo. Cuando se hayan establecido y mantenido todas las asociaciones de seguridad se dar por concluida la prueba para esta conguracin, y se a o proceder a evaluar la siguiente combinacin de factores. a o

137

6.3. Evaluacin del rendimiento o

En caso de estimar que el valor inicial de un segundo entre cada establecimiento de conexin es demasiado alto o bajo para la implementacin o o que se est analizando (partiendo, por ejemplo, de la informacin recogida a o en la prueba del nmero mximo de asociaciones de seguridad que la impleu a mentacin es capaz de establecer simultneamente), es posible utilizar otro o a valor que se aproxime ms al valor con el que determinaremos el nmero a u mximo de asociaciones de seguridad. a 6.3.6.4. Mediciones y resultados

Cada vez que una prueba nalice, ya sea satisfactoriamente o no, se almacenar el intervalo de tiempo entre conexiones que se estaba utilizando a y el nmero de asociaciones de seguridad que se ha llegado a establecer. u Tambin se almacenar la conguracin de IKE y ESP/AH que se estaba e a o utilizando, as como el ancho de banda por cada conexin. o 6.3.6.5. Informe de resultados

Los resultados de esta prueba mostrarn el intervalo necesario para a el establecimiento de un determinado nmero de asociaciones de seguridad u bajo una conguracin concreta, cuando por cada asociacin de seguridad o o se transmite informacin a una determinada velocidad. o

6.3.7.
6.3.7.1.

Tiempo de proceso
Objetivos

Determinar el tiempo necesario para que la implementacin de IPsec o que se evala lleve a cabo un desarrollo completo de un tnel criptogrco u u a con IPsec, as como la sobrecarga que introduce el cifrado de los datos en la latencia de la red. 6.3.7.2. Conguracin necesaria o

Las implementaciones de IPsec se congurarn para establecer los tnea u les criptogrcos combinando las siguientes conguraciones de IKE: a IKE Fase 1 Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-MD5-96

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

138

Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 2 (1024 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96 IKE Fase 2 Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-MD5-96 Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 2 (1024 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y HMAC-SHA1-96 Grupo de Die-Hellman 2 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96 Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96 Para generar trco entre equipos se enviar un mensaje Echo Rea a quest con el campo de datos AAAA hasta completar un tamao de 64 n bytes.

139 6.3.7.3. Procedimiento

6.3. Evaluacin del rendimiento o

Para cada conguracin diferente para la Fase 1 de IKE se iniciar la o a negociacin de un tnel criptogrco entre una implementacin de referencia o u a o y la implementacin evaluada. La implementacin de referencia evaluar el o o a tiempo necesario para completar la negociacin de la Fase 1 de IKE y proo ceder a cancelar la negociacin del tnel. Este proceso se repetir 3 veces a o u a para cada conguracin de la Fase 1. o Una vez nalizados los estudios de la Fase 1, se llevar a cabo un proceso a similar con la Fase 2: Se proceder a negociar una Fase 1 completa con la a ultima conguracin probada, para despus proceder a la negociacin de la o e o Fase 2. Para cada conguracin de la Fase 2, la implementacin de referencia o o medir el tiempo necesario para llevar a cabo la negociacin y proceder a a o a cerrar la asociacin de seguridad, pasando a la siguiente conguracin a o o evaluar. Por ultimo, se evaluar el tiempo necesario para el desarrollo completo a de la arquitectura de seguridad IPsec. Para ello se cerrarn todas las negoa ciaciones pendientes, y se enviar desde un equipo en la red protegida por a la implementacin de referencia un mensaje a un equipo protegido por la o implementacin de IPsec evaluada. El equipo que env el mensaje medir el o a a tiempo necesario para obtener el mensaje de respuesta del otro sistema al utilizar las siguientes conguraciones de IPsec: IKE (ambas fases): Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-MD5-96; ESP: 3DES en modo CBC y HMACMD5-96 IKE (ambas fases): Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-MD5-96; ESP: 3DES en modo CBC y HMACMD5-96 IKE (ambas fases): Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-SHA1-96; ESP: 3DES en modo CBC y HMACSHA1-96 IKE (ambas fases): Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-SHA1-96; ESP: 3DES en modo CBC y HMACSHA1-96 IKE (ambas fases): Grupo de Die-Hellman 2 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96; ESP: AES128 en modo CBC y AES-XCBC-MAC-96 IKE (ambas fases): Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96; ESP: AES128 en modo CBC y AES-XCBC-MAC-96

Cap tulo 6. Aplicacin de la Metodolog a IPsec o a

140

IKE (ambas fases): Grupo de Die-Hellman 2 (1024 bits), con 3DES en modo CBC y HMAC-SHA1-96; AH: HMAC-SHA1-96 IKE (ambas fases): Grupo de Die-Hellman 14 (2048 bits), con 3DES en modo CBC y HMAC-SHA1-96; AH: HMAC-SHA1-96 IKE (ambas fases): Grupo de Die-Hellman 2 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96; AH: AES-XCBC-MAC-96 IKE (ambas fases): Grupo de Die-Hellman 14 (2048 bits), con AES en modo CBC y AES-XCBC-MAC-96; AH: AES-XCBC-MAC-96 6.3.7.4. Mediciones y resultados

La implementacin de referencia tomar medidas del tiempo necesario o a desde que comienza la negociacin de cada una de las fases de IKE hasta o que el proceso de negociacin naliza. Cada una de estas mediciones se o llevar a cabo 3 veces, almacenando el valor medio, con el n de eliminar a errores estad sticos y minimizar la inuencia de la red en todo este proceso de evaluacin. o El equipo que env el mensaje de Echo Request deber medir el tiempo a a que pasa desde que env el mensaje hasta que recibe la respuesta del otro a equipo. Al igual que ocurr anteriormente, este proceso se llevar a cabo 3 a a veces, recordando siempre destruir las asociaciones de seguridad existentes antes de proceder a la siguiente prueba. Los resultados de estas pruebas sern los valores medios de los valores a capturados en la negociacin de cada fase de IKE y en la ejecucin completa o o del protocolo. 6.3.7.5. Informe de resultados

Los resultados de estas pruebas detallarn, para cada suite criptogrca a a utilizada en la negociacin de cada fase, cules han sido los valores medidos y o a cul es el valor medio de todos ellos. Asimismo, para los tiempos empleados a en la ejecucin completa del protocolo se mostrar la conguracin de IKE o a o y de ESP / AH utilizada, junto con todos los tiempos medidos y el valor medio de dichas medidas.

Cap tulo 7

Dise o e Implementacin n o
7.1. Introduccin o

Al implementar el conjunto de pruebas resultante del trabajo desarrollado aplicando la metodolog de validacin y evaluacin de protocolos de a o o seguridad, se han planteado dos enfoques diferentes pero complementarios. Por un lado se han desarrollado pequeas pruebas atmicas que desarrollan n o cada una de las pruebas y evaluaciones descritas en la el cap tulo 6. Por otro lado, la implementacin de una arquitectura en la que se agrupen todas las o pruebas, ofreciendo al usuario ventajas desde el punto de vista de la usabilidad (como un interfaz desde el que congurar las diferentes pruebas a llevar a cabo), representa un paso ms hacia la difusin del uso de la metodolog a o a aqu propuesta. En la seccin 7.2 se describir la implementacin realizada en forma o a o de pruebas atmicas de cada una de los aspectos en los que se desarrolla el o conjunto de pruebas descrito en el cap tulo 6. Posteriormente, en la seccin o 7.3 se estudiarn las caracter a sticas, requisitos y problemtica que se prea sentan para implementar las pruebas en una unica plataforma remota desde la que se llevan a cabo tanto los tests como la interpretacin de resultados. o A partir de este anlisis se presentar un diseo de la plataforma, a partir a a n del cul se llevar a cabo el proceso de desarrollo. a a

7.2.

Pruebas atmicas o

Al implementar pequeos programas que realizasen la evaluacin de n o aspectos concretos de una implementacin IPsec se plantean mltiples cueso u tiones, algunas de las cuales ya fueron detectadas al llevar a cabo el anlisis a de la conformidad con el estndar y del rendimiento (cap a tulos 3 y 4). En aquellos cap tulos se procedi a realizar un estudio de algunos factores que o pod originar problemas, tanto desde un punto de vista terico como al an o 141

Cap tulo 7. Dise o e Implementacin n o desarrollar una implementacin de las propuestas que all se hac o an.

142

Por ejemplo, el problema de necesitar una implementacin que fuese de o antemano conforme con los estndares plantea una complicacin eminentea o mente prctica, ya que no es factible disponer de implementaciones de las a que sepamos de antemano que son conformes a estndar, y que podamos a controlar hasta el punto de obligar a la implementacin a enviar mensajes o invlidos durante el establecimiento de asociaciones de seguridad. a Como ya se apuntaba en el propio cap tulo 3, la solucin elegida ha o pasado por adoptar parte de la implementacin desarrollada por el NIST o americano (llamada Pluto Plus y englobada dentro del proyecto IPsec-WIT ([120]), y combinarla con implementaciones de las que dispusisemos el cdie o go fuente. De esta forma se combinar la conformidad con los estndares a a de PlutoPlus, y se le aadir las nuevas herramientas criptogrcas incorn an a poradas a IPsec desde el desarrollo del proyecto IPsec-WIT. Sin embargo, debido al nivel de modicaciones que ha sido necesario llevar a cabo, la integracin esperada ha resultado en unas librer de proo as gramacin que permiten comportarse como una implementacin de IPsec o o conforme a los estndares. Estas librer permiten tanto el establecimiento a as de tneles criptogrcos de acuerdo a las especicaciones de los estndares, u a a como el env de mensajes de IKE y ESP mal formados1 . o Otras dicultades a las que se ha tenido que hacer frente durante el desarrollo de estas pruebas atmicas han sido los problemas para encono trar implementaciones de las nuevas especicaciones de IPsec (publicadas en Diciembre de 2.005), la necesidad de integrar mltiples herramientas en u cada desarrollo atmico y la exigencia de disear herramientas propias para o n solventar problemas que han aparecido en momentos dados. La dicultad para encontrar implementaciones de las nuevas especicaciones de IPsec ha supuesto un problema de cara al desarrollo de las pruebas. De hecho, en la actualidad unicamente es posible encontrar imple mentaciones an en desarrollo y entornos de programacin en los que parte u o de la funcionalidad ya se encuentra disponible, pero el resto queda pendiente para ser programado por nosotros mismos. Esta situacin nos ha hecho o decantarnos por desarrollar la implementacin de las pruebas atmicas unio o camente para la especicacin de IPsec de 1.998, de la que existen mltiples o u implementaciones disponibles. En cuanto a la integracin de mltiples herramientas en cada desarroo u llo atmico, esta situacin se daba especialmente en los desarrollos de las o o pruebas de rendimiento, ya que era necesario integrar generadores de trco a
En concreto, permite enviar los mensajes correspondientes a la evaluacin de la conforo midad de los protocolos utilizados para el establecimiento de tneles criptogrcos IPsec u a descritos en el apartado 6.2.4.3 de la aplicacin de la metodolog a la arquitectura de o a seguridad IPsec
1

143

7.2. Pruebas atmicas o

junto con medidores de trco, controladores de tiempo y ancho de bana da utilizado y un sistema rudimentario que permitiese informar a todos los equipos de eventos como el inicio del env de trco o el n de las pruebas a o a llevar a cabo. Algunos de estos componentes se han podido obtener de herramientas de cdigo abierto (como IPtraf, del que se han obtenido las librer o as de medicin de trco), y otros han sido desarrollados expl o a citamente para estas pruebas atmicas. o El resultado inmediato de incluir tanta funcionalidad en cada desarrollo atmico ha sido un crecimiento de los recursos necesarios para poder ejecuo tar las pruebas, as como la redundancia de librer y funciones comunes as en muchos de los desarrollos. De cara a una utilizacin futura de estos deo sarrollos, esta sobrecarga de funcionalidad ha originado un cdigo dif de o cil mantener debido a la variedad de interfaces, estilos de programacin que se o han integrado en cada una de las pruebas, etc. . . . Por otro lado, el hecho de tener que desarrollar nuestras propias herramientas en determinados casos ha representado un reto ya que, en la mayor a de ocasiones, ya exist soluciones previas a ese problema. Sin embargo, en an muchos casos estas soluciones no se ajustaban a los requisitos del desarrollo que se estaba llevando a cabo, o bien resultaban excesivamente complejas para el objeto que persiguen estas pruebas atmicas. Por ejemplo, en el cao so del sistema de noticacin entre equipos del inicio y n de las pruebas, o existen mltiples librer de comunicaciones y control de eventos en red, u as pero su utilizacin es demasiado complicada para el n buscado con estos o desarrollos. Estos dos ultimos factores han contribuido a limitar la portabilidad de las pruebas atmicas desarrolladas entre sistemas, poniendo coto a la o utilidad de las mismas fuera del entorno en el que han sido implementadas. Un ultimo problema presente en los desarrollos de pruebas atmicas o es la elevada complejidad de su utilizacin: Al ser herramientas basadas en o l nea de comandos, estas herramientas no disponen de las ayudas visuales que proporciona un interfaz grco al manejar cualquier tipo de software. a Adems, el hecho de tener que recongurar manualmente las implementaa ciones de IPsec cuando sea necesario para llevar a cabo las pruebas hace que la realizacin de las mismas no resulte una tarea sencilla. o Sin embargo, y pese a estas dicultades, el desarrollo de las pruebas atmicas ha permitido completar, desde el punto de vista de la implementao cin, el anlisis de los parmetros de conformidad y rendimiento estudiados o a a en los cap tulos 3 y 4. Estos desarrollos han permitido comprender mejor qu factores afectan al rendimiento, cmo mejorar la validacin de las hee o o rramientas criptogrcas, o posibles soluciones para solventar los problemas a derivados del orden en el que se lleva a cabo la validacin de los componentes o de IPsec (discutido en el cap tulo 3).

Cap tulo 7. Dise o e Implementacin n o

144

Tabla 7.1: Especicaciones de la implementacin mediante pruebas atmicas o o Sistema Operativo Linux (kernel 2.6.15) Lenguaje C y Bash script Opciones del Compilador -Wall -O3 Implementacin IPsec utilizada OpenS/WAN y Pluto Plus o Librer Criptogrcas as a OpenSSL 0.9.7j

Adicionalmente, estas pruebas han resultado ser plenamente funcionales, por lo que en la actualidad es posible validar una implementacin de o IPsec de acuerdo con la especicacin del estndar y llevar a cabo una evao a luacin del rendimiento que dicha implementacin puede ofrecer tal y como o o se describe en el estndar, utilizando estas pruebas atmicas. a o Sin embargo, debido a las limitaciones que se comentaban anteriormente en cuanto a portabilidad, y uniendo a esto los problemas relativos a facilidad de uso, su utilizacin se enfoca ms hacia la ayuda y evaluacin en el o a o desarrollo de implementaciones de IPsec que hacia el uso por parte de un usuario de dichas implementaciones. Las caracter sticas tcnicas del entorno en el que se han desarrollado e estas pruebas atmicas se resumen en la tabla 7.1. o

7.2.1.

Relacin de pruebas atmicas desarrolladas o o

A continuacin se expondr la relacin completa de las pruebas atmio a o o cas desarrolladas, listadas de acuerdo a los diferentes apartados en los que se agrupaban en el cap tulo 6 para una mayor facilidad al identicar su funcionalidad. 7.2.1.1. Validacin de la conformidad o

Validacin criptogrca Las pruebas atmicas descritas en las Tablas o a o 7.2, 7.3 y 7.4 han sido desarrolladas con el n de realizar las pruebas de conformidad de las diferentes herramientas criptogrcas utilizadas por las a implementaciones de IPsec.

145

7.2. Pruebas atmicas o

Tabla 7.2: Relacin de pruebas atmicas de validacin de las herramientas o o o criptogrcas utilizadas en ESP a Nombre Descripcin o EspNull Establece un tnel criptogrco utilizando el modo acelerau a do en la Fase 1 de IKE y el algoritmo NULL en las Fases 1 y 2 de IKE. Protege el trco ESP con el algoritmo NULL. a Esp3Des Establece un tnel criptogrco utilizando el modo acelerau a do en la Fase 1 de IKE y el algoritmo NULL en las Fases 1 y 2 de IKE. Protege el trco ESP con el algoritmo 3DES y a HMAC-SHA1-96. EspAES Establece un tnel criptogrco utilizando el modo acelerau a do en la Fase 1 de IKE y el algoritmo NULL en las Fases 1 y 2 de IKE. Protege el trco ESP con el algoritmo AES128 a y AES-XCBC-MAC-96.

Cap tulo 7. Dise o e Implementacin n o

146

Tabla 7.3: Relacin de pruebas atmicas de validacin de las herramientas o o o criptogrcas utilizadas en la Fase 1 de IKE a Nombre Descripcin o Fase13DesMD5 Establece un tnel criptogrco utilizando el modo u a acelerado en la Fase 1 de IKE y el algoritmo NULL en la Fase 2 de IKE y en ESP. Protege la Fase 1 de IKE con el algoritmo 3DES y HMAC-MD5-96 y los grupos de Die-Hellman 2 y 14. Fase13DesSHA1 Establece un tnel criptogrco utilizando el modo u a acelerado en la Fase 1 de IKE y el algoritmo NULL en la Fase 2 de IKE y en ESP. Protege la Fase 1 de IKE con el algoritmo 3DES y HMAC-SHA1-96 y los grupos de Die-Hellman 2 y 14. Fase13DesAES Establece un tnel criptogrco utilizando el modo u a acelerado en la Fase 1 de IKE y el algoritmo NULL en la Fase 2 de IKE y en ESP. Protege la Fase 1 de IKE con el algoritmo 3DES y AES-XCBC-MAC-96 y los grupos de Die-Hellman 2 y 14. Fase1AesSHA1 Establece un tnel criptogrco utilizando el modo u a acelerado en la Fase 1 de IKE y el algoritmo NULL en la Fase 2 de IKE y en ESP. Protege la Fase 1 de IKE con el algoritmo AES128 y HMAC-SHA1-96 y los grupos de Die-Hellman 2 y 14. Fase1AesAES Establece un tnel criptogrco utilizando el modo u a acelerado en la Fase 1 de IKE y el algoritmo NULL en la Fase 2 de IKE y en ESP. Protege la Fase 1 de IKE con el algoritmo AES128 y AES-XCBC-MAC-96 y los grupos de Die-Hellman 2 y 14.

147

7.2. Pruebas atmicas o

Tabla 7.4: Relacin de pruebas atmicas de validacin de las herramientas o o o criptogrcas utilizadas en la Fase 2 de IKE a Nombre Descripcin o Fase23DesMD5 Establece un tnel criptogrco utilizando el modo u a acelerado y el algoritmo NULL en la Fase 1 de IKE y en ESP. Protege la Fase 2 de IKE con el algoritmo 3DES y HMAC-MD5-96 y los grupos de DieHellman 2 y 14. Fase23DesSHA1 Establece un tnel criptogrco utilizando el modo u a acelerado y el algoritmo NULL en la Fase 1 de IKE y en ESP. Protege la Fase 2 de IKE con el algoritmo 3DES y HMAC-SHA1-96 y los grupos de DieHellman 2 y 14. Fase23DesAES Establece un tnel criptogrco utilizando el modo u a acelerado y el algoritmo NULL en la Fase 1 de IKE y en ESP. Protege la Fase 2 de IKE con el algoritmo 3DES y AES-XCBC-MAC-96 y los grupos de DieHellman 2 y 14. Fase2AesSHA1 Establece un tnel criptogrco utilizando el modo u a acelerado y el algoritmo NULL en la Fase 1 de IKE y en ESP. Protege la Fase 2 de IKE con el algoritmo AES128 y HMAC-SHA1-96 y los grupos de DieHellman 2 y 14. Fase2AesAES Establece un tnel criptogrco utilizando el modo u a acelerado y el algoritmo NULL en la Fase 1 de IKE y en ESP. Protege la Fase 2 de IKE con el algoritmo AES128 y AES-XCBC-MAC-96 y los grupos de DieHellman 2 y 14.

Cap tulo 7. Dise o e Implementacin n o

148

Validacin de protocolos Las pruebas atmicas que se pueden observar o o en las Tablas 7.5 y 7.6 tienen por objeto el anlisis del desarrollo de los a diferentes protocolos de IPsec que lleva a cabo una implementacin de esta o arquitectura de seguridad. Todas estas pruebas establecen un tnel cripu togrco de acuerdo a los parmetros indicados en la descripcin de cada a a o una, y posteriormente lleva a cabo el env de mensajes especialmente foro mados descritos en la seccin 6.2.4. o

149

7.2. Pruebas atmicas o

Tabla 7.5: Relacin de pruebas atmicas de validacin del desarrollo de los o o o protocolos en modo tnel u Descripcin o Establece un tnel criptogrco en modo tnel utiliu a u zando Main Mode para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y ESP para proteger el trco. a No utiliza Perfect Forward Secrecy. TunelMMQMAH Establece un tnel criptogrco en modo tnel utiliu a u zando Main Mode para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y AH para proteger el trco. a No utiliza Perfect Forward Secrecy. TunelMMQMESPPFS Establece un tnel criptogrco en modo tnel utiliu a u zando Main Mode para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y ESP para proteger el trco. a Utiliza Perfect Forward Secrecy. TunelMMQMAHPFS Establece un tnel criptogrco en modo tnel utiliu a u zando Main Mode para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y AH para proteger el trco. a Utiliza Perfect Forward Secrecy. TunelAMQMESP Establece un tnel criptogrco en modo tnel utiliu a u zando Modo Acelerado para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y ESP para proteger el trco. No utiliza Perfect Forward Secrecy. a TunelAMQMAH Establece un tnel criptogrco en modo tnel utiliu a u zando Modo Acelerado para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y AH para proteger el trco. No utiliza Perfect Forward Secrecy. a TunelAMQMESPPFS Establece un tnel criptogrco en modo tnel utiliu a u zando Modo Acelerado para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y ESP para proteger el trco. Utiliza Perfect Forward Secrecy. a TunelAMQMAHPFS Establece un tnel criptogrco en modo tnel utiliu a u zando Modo Acelerado para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y AH para proteger el trco. Utiliza Perfect Forward Secrecy. a Nombre TunelMMQMESP

Cap tulo 7. Dise o e Implementacin n o

150

Tabla 7.6: Relacin de pruebas atmicas de validacin del desarrollo de los o o o protocolos en modo transporte Descripcin o Establece un tnel criptogrco en modo transporte u a utilizando Main Mode para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y ESP para proteger el trco. No utiliza Perfect Forward Secrecy. a TranspMMQMAH Establece un tnel criptogrco en modo transporte u a utilizando Main Mode para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y AH para proteger el trco. No utiliza Perfect Forward Secrecy. a TranspMMQMESPPFS Establece un tnel criptogrco en modo transporte u a utilizando Main Mode para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y ESP para proteger el trco. Utiliza Perfect Forward Secrecy. a TranspMMQMAHPFS Establece un tnel criptogrco en modo transporte u a utilizando Main Mode para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y AH para proteger el trco. Utiliza Perfect Forward Secrecy. a TranspAMQMESP Establece un tnel criptogrco en modo transporte u a utilizando Modo Acelerado para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y ESP para proteger el trco. No utiliza Perfect Forward Secrecy. a TranspAMQMAH Establece un tnel criptogrco en modo transporte u a utilizando Modo Acelerado para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y AH para proteger el trco. No utiliza Perfect Forward Secrecy. a TranspAMQMESPPFS Establece un tnel criptogrco en modo transporte u a utilizando Modo Acelerado para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y ESP para proteger el trco. Utiliza Perfect Forward Secrecy. a TranspAMQMAHPFS Establece un tnel criptogrco en modo transporte u a utilizando Modo Acelerado para la Fase 1 de IKE, Quick Mode para la Fase 2 de IKE y AH para proteger el trco. Utiliza Perfect Forward Secrecy. a Nombre TranspMMQMESP

151

7.2. Pruebas atmicas o

Tabla 7.7: Relacin de pruebas atmicas de validacin de los mecanismos de o o o autenticacin o Nombre Descripcin o PskMd5MM Lleva a cabo una autenticacin utilizando un secreto o compartido, utilizando MD5 como funcin resumen. o En la Fase 1 de IKE se utiliza Main Mode. PskMd5AM Lleva a cabo una autenticacin utilizando un secreto o compartido, utilizando MD5 como funcin resumen. o En la Fase 1 de IKE se utiliza Modo Acelerado. PskSha1MM Lleva a cabo una autenticacin utilizando un secreto o compartido, utilizando SHA1 como funcin resumen. o En la Fase 1 de IKE se utiliza Main Mode. PskSha1AM Lleva a cabo una autenticacin utilizando un secreto o compartido, utilizando SHA1 como funcin resumen. o En la Fase 1 de IKE se utiliza Modo Acelerado. RsaMM Lleva a cabo una autenticacin utilizando pares de o claves RSA. En la Fase 1 de IKE se utiliza Main Mode. RsaAM Lleva a cabo una autenticacin utilizando pares de clao ves RSA. En la Fase 1 de IKE se utiliza Modo Acelerado. X509MM Lleva a cabo una autenticacin utilizando certicados o X.509. En la Fase 1 de IKE se utiliza Main Mode. X509AM Lleva a cabo una autenticacin utilizando certicados o X.509. En la Fase 1 de IKE se utiliza Modo Acelerado.

Validacin de los mecanismos de autenticacin Con el n de validar o o el desarrollo de los diferentes mecanismos de autenticacin presentes en una o implementacin de IPsec contamos con las pruebas atmicas enumeradas o o en la Tabla 7.7. Cada una de estas implementaciones lleva a cabo las tres pruebas especicadas, esto es: autenticacin correcta, env de credenciales o o incorrectas y recepcin de credenciales incorrectas. o

Cap tulo 7. Dise o e Implementacin n o

152

Tabla 7.8: Relacin de pruebas atmicas de validacin de la gestin de claves o o o o Nombre Descripcin o Fase1Tiempo Establece un tnel criptogrco mediante IPsec en el u a que se negocia la caducidad de las claves de la Fase 1 de IKE en funcin del tiempo. El valor por defecto o es de 30 segundos, aunque es modicable mediante parmetros. La Fase 2 tiene un tiempo de caducidad a de 1 hora. Fase2Tiempo Establece un tnel criptogrco mediante IPsec en el u a que se negocia la caducidad de las claves de la Fase 2 de IKE en funcin del tiempo. El valor por defecto o es de 30 segundos, aunque es modicable mediante parmetros. La Fase 1 tiene un tiempo de caducidad a de 1 hora. Fase1Trafico Establece un tnel criptogrco mediante IPsec en el u a que se negocia la caducidad de las claves de la Fase 1 de IKE en funcin del volumen de trco protegio a do. El valor por defecto es de 10 KBytes, aunque es modicable mediante parmetros. La Fase 2 tiene un a tiempo de caducidad de 1 hora. Fase2Trafico Establece un tnel criptogrco mediante IPsec en el u a que se negocia la caducidad de las claves de la Fase 2 de IKE en funcin del volumen de trco protegio a do. El valor por defecto es de 10 KBytes, aunque es modicable mediante parmetros. La Fase 1 tiene un a tiempo de caducidad de 1 hora.

Validacin de los mecanismos de gestin de claves En la Tabla 7.8 o o podemos ver un listado completo de las pruebas atmicas desarrolladas con o el n de evaluar el grado de conformidad de los mecanismos de renovacin o y caducidad de las claves con respecto a lo especicado en el estndar. a

153

7.2. Pruebas atmicas o

Tabla 7.9: Relacin de pruebas atmicas de validacin de otras caracter o o o sticas adicionales Nombre Descripcin o NAT Establece, secuencialmente, tres tneles criptogrcos, u a de acuerdo a los requisitos especicados en el conjunto de pruebas. Entre el establecimiento de cada tnel se u solicita al usuario que revise y actualice en caso necesario la conguracin de la implementacin evaluada. o o IPComp Establece un tnel criptogrco en el que se utiliza u a IPComp, transmitiendo por dicho tnel mensajes que u deben generar una respuesta determinada. ECN Establece un tnel criptogrco y posteriormente sau a tura la red, obligando a las implementaciones a noticar de la existencia de congestin en la red. o

Validacin de otras caracter o sticas Para la implementacin de los ultio mos anlisis de conformidad necesarios, se han desarrollado las pruebas a atmicas que aparecen en la Tabla 7.9. o 7.2.1.2. Evaluacin del rendimiento o

Ancho de banda Las pruebas atmicas que se detallan en la Tabla 7.10 o han sido desarrolladas con el n de llevar a cabo una medicin able del o ancho que banda que una implementacin de IPsec puede ofrecer. Estas o pruebas atmicas no establecen t neles criptogrcos, sino que utilizan o u a la implementacin de referencia para ello. Por lo tanto, cualquier variacin o o respecto a los parmetros del tnel se lleva a cabo en la conguracin de a u o la implementacin de referencia, y no en las pruebas atmicas. Es necesario o o destacar que debido al carcter compacto de las pruebas atmicas, as coa o mo a la complejidad de la inclusin de la funcionalidad necesaria, no se o han implementado las pruebas atmicas de evaluacin del rendimiento que o o corresponden a perles de trco de redes saturadas. a

Cap tulo 7. Dise o e Implementacin n o

154

Tabla 7.10: Relacin de pruebas atmicas de evaluacin del ancho de banda. o o o Nombre Descripcin o BWTMax-Serv Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl Mximo Ancho de Banda. Este mdulo lleva a o a cabo las funciones de servidor, por lo que espera las conexiones entrantes. Tras 10 segundos de transmisin o mide el ancho de banda utilizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin y repite el proceso completo otras 2 o veces. Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas. BWTMax-Clie Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl Mximo Ancho de Banda. Este mdulo lleva a o a cabo las funciones de cliente, por lo que se conecta al servidor instalado en otro dispositivo y comienza el env de trco. Tras 10 segundos de transmisin mide o a o el ancho de banda utilizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin y repite el proceso completo otras 2 veces. o Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas. Trad-Serv Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl Usuario Tradicional. Este mdulo lleva a cao bo las funciones de servidor, por lo que espera las conexiones entrantes. Tras 10 segundos de transmisin o mide el ancho de banda utilizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin y repite el proceso completo otras 2 o veces. Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas. Trad-Clie Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl Usuario Tradicional. Este mdulo lleva a cao bo las funciones de cliente, por lo que se conecta al servidor instalado en otro dispositivo y comienza el env de trco. Tras 10 segundos de transmisin mio a o de el ancho de banda utilizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin y repite el proceso completo otras 2 o veces. Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas.

155

7.2. Pruebas atmicas o

Nombre Descripcin o TCPAsimIn-Serv Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl TCP Asimtrico. Este mdulo lleva a cabo las e o funciones de servidor, por lo que espera las conexiones entrantes y comienza el env de trco. Tras 10 o a segundos de transmisin mide el ancho de banda utio lizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin y repite el o proceso completo otras 2 veces. Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas. TCPAsimIn-Clie Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl TCP Asimtrico Entrante. Este mdulo lleva e o a cabo las funciones de cliente, por lo que se conecta al servidor instalado en otro dispositivo y comienza el env de trco. Tras 10 segundos de transmisin mide o a o el ancho de banda utilizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin y repite el proceso completo otras 2 veces. o Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas. TCPAsimOut-Serv Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl TCP Asimtrico Saliente. Este mdulo lleva e o a cabo las funciones de servidor, por lo que espera las conexiones entrantes y procede al env de tro a co. Tras 10 segundos de transmisin mide el ancho de o banda utilizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin o y repite el proceso completo otras 2 veces. Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas. TCPAsimOut-Clie Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl TCP Asimtrico Saliente. Este mdulo lleva e o a cabo las funciones de cliente, por lo que se conecta al servidor instalado en otro dispositivo y no env a trco alguno (salvo los ACKs de TCP que se env a an automticamente). Tras 10 segundos de transmisin a o mide el ancho de banda utilizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin y repite el proceso completo otras 2 o veces. Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas.

Cap tulo 7. Dise o e Implementacin n o

156

Nombre Descripcin o TCPSim-Serv Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl Usuario Tradicional. Este mdulo lleva a cao bo las funciones de servidor, por lo que espera las conexiones entrantes. Tras 10 segundos de transmisin o mide el ancho de banda utilizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin y repite el proceso completo otras 2 o veces. Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas. TCPSim-Clie Genera trco entre dos equipos separados por un a tnel criptogrco de acuerdo a los parmetros del u a a perl Usuario Tradicional. Este mdulo lleva a cao bo las funciones de cliente, por lo que se conecta al servidor instalado en otro dispositivo y comienza el env de trco. Tras 10 segundos de transmisin mio a o de el ancho de banda utilizado de media a intervalos de 1 segundo, durante 5 segundos. Posteriormente cierra la conexin y repite el proceso completo otras 2 o veces. Finalmente, informa del ancho de banda medio que se ha estado transmitiendo durante las medidas.

Mximo n mero de asociaciones de seguridad simultneas Para a u a llevar a cabo la evaluacin del mximo nmero de asociaciones de segurio a u dad simultneas que una implementacin de IPsec puede establecer, se han a o desarrollado las pruebas atmicas que aparecen descritas en la Tabla 7.11. o Estas pruebas atmicas no establecen t neles criptogrcos, sino que o u a utilizan la implementacin de referencia para ello. Su labor se centra, por lo o tanto, en la evaluacin del rendimiento. o Establecimiento de nuevas asociaciones de seguridad En la Tabla 7.12 se pueden consultar cules han sido las pruebas atmicas desarrolladas a o para permitir la evaluacin de la capacidad de establecimiento de nuevas o asociaciones de seguridad de la implementacin de IPsec evaluada. Estas o pruebas atmicas no establecen t neles criptogrcos, sino que utilizan o u a la implementacin de referencia para ello. Su labor se centra, por lo tanto, o en la evaluacin del rendimiento. o Tiempo de proceso Por ultimo, las pruebas atmicas disponibles para o permitirnos medir el tiempo de proceso necesario para el desarrollo completo

157

7.2. Pruebas atmicas o

Tabla 7.11: Relacin de pruebas atmicas de evaluacin del nmero mximo o o o u a de asociaciones de seguridad Nombre Descripcin o MaxSA-Servidor Establece servidores en el equipo en el que se instala a medida que se establecen conexiones, de forma que se puedan recibir comunicaciones entrantes. Cuando alguna conexin falla evala o u si es necesario repetir la medicin (porque unio camente hay una medida o porque los resultados de las dos ultimas pruebas no coinciden), y en caso necesario vuelve a comenzar el proceso. MaxSA-Cliente Establece conexiones con el equipo en el que se ejecuta el mdulo servidor a intervalos regulao res. Cuando alguna conexin falla evala si es o u necesario repetir la medicin (porque unicameno te hay una medida o porque los resultados de las dos ultimas pruebas no coinciden), y en caso ne cesario vuelve a comenzar el proceso.

de los diferentes protocolos de IPsec aparecen en las Tablas 7.13, 7.14 y 7.15.

Cap tulo 7. Dise o e Implementacin n o

158

Tabla 7.12: Relacin de pruebas atmicas de evaluacin de la capacidad de o o o establecimiento de nuevas asociaciones de seguridad Nombre Descripcin o CapacidadSA-Servidor Establece servidores en el equipo en el que se instala a medida que se establecen conexiones, de forma que se puedan recibir comunicaciones entrantes. Cuando alguna conexin falla evala o u si es necesario repetir la medicin (si no se han o establecido el nmero de tneles especicado), y u u en caso necesario vuelve a comenzar el proceso. CapacidadSA-Cliente Establece conexiones con el equipo en el que se ejecuta el mdulo servidor a intervalos regulao res, enviando datos por cada tnel de tal forma u que el ancho de banda total se reparta equitativamente entre todos los tneles. Cuando alguna u conexin falla ajusta el periodo de espera eno tre el establecimiento de los tneles y vuelve a u comenzar el proceso.

159

7.2. Pruebas atmicas o

Tabla 7.13: Relacin de pruebas atmicas de evaluacin del tiempo de proo o o ceso de la Fase 1 de IKE Nombre Descripcin o TiempoF1-3desMd5 Establece un tnel criptogrco utilizando en la u a Fase 1 los algoritmos 3DES y HMAC-MD5-96. Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o TiempoF1-3desSha1 Establece un tnel criptogrco utilizando en la u a Fase 1 los algoritmos 3DES y HMAC-SHA1-96. Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o TiempoF1-3desAes Establece un tnel criptogrco utilizando en la u a Fase 1 los algoritmos 3DES y AES-XCBC-MAC96.Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o TiempoF1-AesSha1 Establece un tnel criptogrco utilizando en la u a Fase 1 los algoritmos AES128 y HMAC-SHA196.Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o TiempoF1-AesAes Establece un tnel criptogrco utilizando en u a la Fase 1 los algoritmos AES128 y AES-XCBCMAC-96.Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o

Cap tulo 7. Dise o e Implementacin n o

160

Tabla 7.14: Relacin de pruebas atmicas de evaluacin del tiempo de proo o o ceso de la Fase 2 de IKE Nombre Descripcin o TiempoF2-3desMd5 Establece un tnel criptogrco utilizando en la u a Fase 2 los algoritmos 3DES y HMAC-MD5-96. Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o TiempoF2-3desSha1 Establece un tnel criptogrco utilizando en la u a Fase 2 los algoritmos 3DES y HMAC-SHA1-96. Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o TiempoF2-3desAes Establece un tnel criptogrco utilizando en la u a Fase 2 los algoritmos 3DES y AES-XCBC-MAC96.Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o TiempoF2-AesSha1 Establece un tnel criptogrco utilizando en la u a Fase 2 los algoritmos AES128 y HMAC-SHA196.Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o TiempoF2-AesAes Establece un tnel criptogrco utilizando en u a la Fase 2 los algoritmos AES128 y AES-XCBCMAC-96.Negocia varias conguraciones diferentes, haciendo uso de los grupos de Die-Hellman 2 y 14, y habilitando o deshabilitando PFS. Realiza 3 medidas de cada conguracin. o

161

7.2. Pruebas atmicas o

Tabla 7.15: Relacin de pruebas atmicas de evaluacin del tiempo de estao o o blecimiento de un tnel criptogrco completo u a Nombre Descripcin o T-3desMd5-ESP-3desMd5 Establece un tnel criptogrco utilizando en u a IKE los algoritmos 3DES y HMAC-MD5-96. Protege el trco utilizando ESP con los algoa ritmos 3DES y HMAC-MD5-96. Utiliza cuatro conguraciones diferentes, habilitando y deshabilitando el uso de PFS, y utilizando los grupos de Die-Hellman 2 y 14. Realiza 3 medidas de cada conguracin. o T-3desSha1-ESP-3desSha1 Establece un tnel criptogrco utilizando en u a IKE los algoritmos 3DES y HMAC-SHA1-96. Protege el trco utilizando ESP con los algoa ritmos 3DES y HMAC-SHA1-96. Utiliza cuatro conguraciones diferentes, habilitando y deshabilitando el uso de PFS, y utilizando los grupos de Die-Hellman 2 y 14. Realiza 3 medidas de cada conguracin. o T-AesAes-ESP-AesAes Establece un tnel criptogrco utilizando en u a IKE los algoritmos AES128 y AES-XCBCHMAC-96. Protege el trco utilizando ESP a con los algoritmos 3DES y HMAC-MD5-96. Utiliza cuatro conguraciones diferentes, habilitando y deshabilitando el uso de PFS, y utilizando los grupos de Die-Hellman 2 y 14. Realiza 3 medidas de cada conguracin. o T-3desSha1-AH-Sha1 Establece un tnel criptogrco utilizando en u a IKE los algoritmos 3DES y HMAC-SHA1-96. Protege el trco utilizando AH con el algoa ritmo HMAC-SHA1-96. Utiliza cuatro conguraciones diferentes, habilitando y deshabilitando el uso de PFS, y utilizando los grupos de Die-Hellman 2 y 14. Realiza 3 medidas de cada conguracin. o T-AesAes-AH-Aes Establece un tnel criptogrco utilizando en u a IKE los algoritmos AES128 y AES-XCBCHMAC-96. Protege el trco utilizando AH a con el algoritmo AES-XCBC-HMAC-96. Utiliza cuatro conguraciones diferentes, habilitando y deshabilitando el uso de PFS, y utilizando los grupos de Die-Hellman 2 y 14. Realiza 3 medidas de cada conguracin. o

Cap tulo 7. Dise o e Implementacin n o

162

7.2.2.

Ejemplos de ejecucin de pruebas atmicas o o

En este apartado se mostrarn dos ejemplos de ejecucin de las pruebas a o atmicas, de modo que sirvan como ejemplo de la estructura y funcionao miento del conjunto completo de pruebas detallado en el apartado anterior. Adems del resultado de la ejecucin de las pruebas se incluye tambin un a o e diagrama explicativo acerca de las operaciones internas de cada una de las pruebas atmicas o 7.2.2.1. Ejemplo 1: Autenticacin mediante secreto compartido o (PSK) en Main Mode de IKE

Para validar la autenticacin mediante secreto compartido en IKE al o utilizar Main Mode se ha desarrollado una aplicacin que negocia el estableo cimiento de tneles IPsec hasta el nal de la Fase 1 de IKE, autenticndose u a mediante secreto compartido. Esta aplicacin lleva a cabo, para cada funcin o o resumen seleccionada, tres pruebas diferentes: Autenticacin correcta (ambas implementaciones env credenciales o an correctas) Env de credenciales incorrectas o Recepcin de credenciales incorrectas o Para poder llevar a cabo las tres pruebas sin requerir al usuario que altere la contrasea en la implementacin evaluada, la aplicacin automtin o o a camente lleva a cabo modicaciones en el resumen de la contrasea esperada, n de forma que al recibir las credenciales de la implementacin evaluada, stas o e sern rechazadas. El grafo de ejecucin de esta prueba atmica puede verse a o o en la Figura 7.1. Un ejemplo de la ejecucin de esta prueba atmica puede verse en la Tao o bla 7.16. Aqu se puede ver cmo la aplicacin necesita recibir como parme o o a tros las funciones resumen a utilizar, la direccin de red en la que se encueno tra la implementacin de IPsec a evaluar, y el secreto compartido que se o debe utilizar2 .

2 A la aplicacin se le debe suministrar el secreto compartido correcto, ya que ella se o encarga de alterarla en los casos en los que sea necesario

163

7.2. Pruebas atmicas o

Figura 7.1: Diagrama de estados de la prueba atmica de validacin de la o o autenticacin utilizando secreto compartido en Main Mode de IKE o

Cap tulo 7. Dise o e Implementacin n o

164

Tabla 7.16: Validacin de la autenticacin mediante secreto compartido o o usuario@host# ./validacion/auth-psk-mm --resumen md5 --direccion 192.168.0.100 --clave "abcdefghijklmnop" Test 1: Autenticacion Correcta Estableciendo Conexion ... Establecida Enviando Propuesta de SA ... Enviada Recibiendo SA aceptada ... Recibida y OK Enviando Diffie-Hellman y Nonce ... Enviados Recibiendo Diffie-Hellman y Nonce ... Recibido y OK Enviando Credenciales ... Enviadas Recibiendo Credenciales ... Recibidas y OK Fase 1 negociada con exito. Fin del test 1

Test 2: Envio de Credenciales Invalidas Modificando credenciales ... Hecho Estableciendo Conexion ... Establecida Enviando Propuesta de SA ... Enviada Recibiendo SA aceptada ... Recibida y OK Enviando Diffie-Hellman y Nonce ... Enviados Recibiendo Diffie-Hellman y Nonce ... Recibido y OK Enviando Credenciales ... Enviadas Recibiendo Credenciales ... Recibidas -- Rechazo Fase 1 interrumpida. Fin del test 2

Test 3: Recepcion de Credenciales Invalidas Modificando credenciales ... Hecho Estableciendo Conexion ... Establecida Enviando Propuesta de SA ... Enviada Recibiendo SA aceptada ... Recibida y OK Enviando Diffie-Hellman y Nonce ... Enviados Recibiendo Diffie-Hellman y Nonce ... Recibido y OK Enviando Credenciales ... Enviadas Recibiendo Credenciales ... Recibidas y OK Rechazando Credenciales ... Hecho Fase 1 interrumpida. Fin del test 3

165

7.2. Pruebas atmicas o RESULTADOS Test 1: Obtenido: FASE 1 OK Esperado: FASE 1 OK Test 2: Obtenido: Nuestras Credenciales Rechazadas Esperado: Nuestras Credenciales Rechazadas Test 3: Obtenido: Rechazamos Credenciales Esperado: Rechazamos Credenciales RESULTADO FINAL: 3/3 Autenticacion mediante PSK en MM con MD5 conforme usuario@host#

Cap tulo 7. Dise o e Implementacin n o

166

Figura 7.2: Diagrama de estados del mdulo servidor de la prueba de evaluao cin del nmero mximo de SA que puede establecer una implementacin o u a o de IPsec 7.2.2.2. Ejemplo 2: Mximo n mero de asociaciones de seguridad a u

La aplicacin que desarrolla las pruebas atmicas para la evaluacin de o o o la capacidad de establecimiento de asociaciones de seguridad de una implementacin de IPsec consta de dos mdulos independientes. El primero de o o ellos (mdulo servidor) se encarga de crear servidores TCP que se encarguen o de aceptar las conexiones entrantes, conexiones que generarn el establecia miento de nuevos tneles criptogrcos. Este mdulo se ejecutar en la red u a o a protegida por la implementacin evaluada. o Por su parte, el mdulo cliente se encargar de crear clientes que se o a comunicarn con los servidores creados por el mdulo servidor. Adems, este a o a mdulo ser el encargado de controlar la velocidad a la que se establecen las o a conexiones, as como el xito o no de dicha conexin. e o Los diagramas de estado de esta prueba se pueden ver en las Figuras 7.2 (mdulo servidor) y 7.2.2.2 (mdulo cliente). o o Por su parte, el resultado de la ejecucin del mdulo servidor puede o o verse en la Tabla 7.17. En ella podemos ver cmo el mdulo servidor no o o requiere de datos adicionales por parte del usuario. Sin embargo, en la Tabla

167

7.2. Pruebas atmicas o

Figura 7.3: Diagrama de estados del mdulo cliente de la prueba de evaluao cin del nmero mximo de SA que puede establecer una implementacin o u a o de IPsec

Cap tulo 7. Dise o e Implementacin n o

168

7.18 vemos cmo, en la ejecucin del cliente, es necesario incluir parmetros o o a adicionales, que se corresponden con el tiempo inicial que debe pasar entre cada inicio de conexin y la direccin de red del equipo en el que se ejecuta o o el mdulo servidor. o

169

7.2. Pruebas atmicas o

Tabla 7.17: Ejecucin del mdulo servidor de la evaluacin de cantidad de o o o asociaciones de seguridad simultneas que soporta la implementacin de a o IPsec usuario@host# ./evaluacion/maxsa-servidor Iniciando Fase 1 Iniciando servidor #1... Conexion establecida... Iniciado servidor Conexion establecida... Iniciado servidor [...] Conexion establecida... Iniciado servidor Conexion establecida... Iniciado servidor Conexion establecida... Iniciado servidor ALERTA: Se pierde la conexion #1 Cerrando todos los servidores... Iniciando Fase 2 Iniciando servidor #1... Conexion establecida... Iniciado Conexion establecida... Iniciado [...] Conexion establecida... Iniciado Conexion establecida... Iniciado Conexion establecida... Iniciado Conexion establecida... Iniciado [...] Conexion establecida... Iniciado Conexion establecida... Iniciado ALERTA: Se pierde la conexion #76 Cerrando todos los servidores... Es necesario utilizar otra Fase

#2 #3 #254 #255 #256

servidor #2 servidor #3 servidor servidor servidor servidor #254 #255 #256 #257

servidor #264 servidor #265

Cap tulo 7. Dise o e Implementacin n o Iniciando Fase 3 Iniciando servidor #1... Conexion establecida... Iniciado Conexion establecida... Iniciado [...] Conexion establecida... Iniciado Conexion establecida... Iniciado Conexion establecida... Iniciado Conexion establecida... Iniciado [...] Conexion establecida... Iniciado Conexion establecida... Iniciado

170

servidor #2 servidor #3 servidor servidor servidor servidor #254 #255 #256 #257

servidor #264 servidor #265

ALERTA: Se pierde la conexion #152 Cerrando todos los servidores... Prueba Finalizada usuario@host#

171

7.2. Pruebas atmicas o

Tabla 7.18: Ejecucin del mdulo cliente de la evaluacin de cantidad de o o o asociaciones de seguridad simultneas que soporta la implementacin de a o IPsec usuario@host# ./evaluacion/maxsa-cliente 1 192.168.100.10 Iniciando Fase 1 (tiempo entre conexiones, 1 segundo) Estableciendo conexion #1... conexion establecida Estableciendo conexion #2... conexion establecida Estableciendo conexion #3... conexion establecida [...] Estableciendo conexion #254... Conexion establecida Estableciendo conexion #255... Conexion establecida Estableciendo conexion #256... Conexion NO establecida ALERTA: conexion #256 no establecida (TimeOut) Cerrando todas las conexiones... Iniciando Fase 2 (tiempo entre conexiones, 2 segundos) Estableciendo conexion #1... conexion establecida Estableciendo conexion #2... conexion establecida Estableciendo conexion #3... conexion establecida [...] Estableciendo conexion #254... Conexion establecida Estableciendo conexion #255... Conexion establecida Estableciendo conexion #256... Conexion establecida Estableciendo conexion #257... Conexion establecida [...] Estableciendo conexion #264... Conexion establecida ALERTA: Se pierde la conexion #76 Cerrando todas las conexiones... Es necesario utilizar otra Fase

Cap tulo 7. Dise o e Implementacin n o

172

Iniciando Fase 3 (tiempo entre conexiones, 3 segundos) Estableciendo conexion #1... conexion establecida Estableciendo conexion #2... conexion establecida Estableciendo conexion #3... conexion establecida [...] Estableciendo conexion #254... Conexion establecida Estableciendo conexion #255... Conexion establecida Estableciendo conexion #256... Conexion establecida Estableciendo conexion #257... Conexion establecida [...] Estableciendo conexion #264... Conexion establecida ALERTA: Se pierde la conexion #152 Cerrando todas las conexiones... Prueba Finalizada La implementacion es capaz de establecer, simultaneamente, 263 asociaciones de seguridad usuario@host#

173

7.3. Dise o de la plataforma n

Como podemos ver, en la ejecucin de esta prueba se han llevado a o cabo 3 fases en las que se establec tantas asociaciones de seguridad como an resultaba posible. En la Fase 1 de dicha ejecucin una escasez de recursos o en la implementacin analizada ha originado que el establecimiento de una o asociacin de seguridad nueva no se pudiese llevar a cabo. Sin embargo, o ampliando el tiempo entre cada establecimiento de conexin ha sido posible o establecer un nmero mayor de asociaciones de seguridad. u

7.3.

Dise o de la plataforma de validacin y evan o luacin remota o

De cara a proporcionar una plataforma desde la que realizar la validacin y evaluacin de las implementaciones IPsec de forma conveniente y con o o mayor facilidad de uso que la que se lleva a cabo con las pruebas atmicas, la o implementacin de una plataforma que desarrollase el conjunto de pruebas o generado a partir de la metodolog propuesta en esta tesis de forma remota a mediante un interfaz amigable es el siguiente paso a llevar a cabo. Los requisitos que se plantean de cara al desarrollo de esta arquitectura son los siguientes: Validacin y Evaluacin Remotas: La plataforma deber ser capaz o o a de llevar a cabo el desarrollo de todas las pruebas remotamente, es decir, sin que el usuario de la plataforma deba estar conectado al mismo segmento de red en el que se encuentra la plataforma. Idealmente cualquier usuario deber poder indicar la direccin de la implementacin a o o de IPsec que desea evaluar y las pruebas se empezar a procesar an automticamente, sin mayor intervencin del usuario. Sin embargo, a o aspectos tales como la necesidad de disponer de software generador y medidor del trco de red en la red protegida por la implementacin a o de IPsec que se analiza, la necesidad de recongurar la implementacin de IPsec mltiples veces a lo largo de las pruebas, etc. . . hacen o u que la intervencin del usuario durante el desarrollo de las pruebas sea o inevitable. An as al implementar esta arquitectura se estudiarn las implemenu , a taciones atmicas de las que ya se dispone, para optimizarlas en cuanto o a usabilidad e intervencin del usuario requerida, de tal forma que la o intervencin del usuario pueda ser reducida al m o nimo posible. En cuanto al hecho de que el usuario utilice la red para conectarse a la plataforma, este hecho introduce una serie de retos y restricciones que es interesante considerar. Por un lado, al habilitar el acceso mediante las tecnolog de red a un interfaz en el que se conguran as las pruebas a llevar a cabo y se obtienen los resultados, es importante

Cap tulo 7. Dise o e Implementacin n o

174

disear el interfaz de tal forma que la amplia variedad de dispositivos n que hoy d pueden hacer uso de las redes de comunicaciones y que a pueden implementar la arquitectura de seguridad IPsec sean capaces de hacer uso del interfaz de forma sencilla, ecaz y consistente entre plataformas. Este problema se solucionar utilizando tecnolog esa as tandarizadas para los contenidos en Internet, principalmente aquellas incluidas en la tecnolog AJAX ([59]), ya que todas ellas se encuentran a estandarizadas por el World Wide Web Consortium (W3C) y su integracin permite el manejo dinmico de la informacin que proporcione o a o un origen de datos as ncrono. Por otro lado, el hecho de que el usuario pueda no encontrarse en la misma red que la implementacin que se desea analizar hace que sea o necesario desarrollar nuevas herramientas que permitan obtener informacin que normalmente se obtendr del usuario (como por ejemplo, o a el valor del MTU, necesario para las pruebas de rendimiento). Estas herramientas debern integrarse en el resto de la plataforma de forma a que, en caso necesario, podamos obtener esos datos sin intervencin o del usuario. Adicionalmente es necesario tener en cuenta que el hecho de utilizar una plataforma basada en la red para llevar a cabo evaluaciones del rendimiento de la red puede introducir conictos y problemas que devalen la informacin proporcionada. Por ejemplo, al evaluar el mxiu o a mo ancho de banda que una implementacin de IPsec puede proporo cionar es importante que la infraestructura de red entre la implementacin que genera las pruebas y la implementacin evaluada cuente con o o capacidad para soportar todo el trco necesario para saturar la implea mentacin evaluada. Sin embargo, las tecnolog de conexin a redes o as o remotas (bien sea mediante acceso telefnico, ADSL, etc. . . ) cuentan o con un ancho de banda mximo menor que cualquiera de las tecnoa log de red de rea local utilizadas en la actualidad (siendo stas las as a e que se encuentran soportadas por las implementaciones IPsec), por lo que los resultados obtenidos pueden verse desvirtuados. Estos problemas debern ser estudiados y analizados antes de decidir a un diseo denitivo para la plataforma, con el n de evitar utilizar n diseos que posteriormente representen un problema para solucionar n estas cuestiones. Modularidad: La implementacin deber ser modular, en el sentido o a de que la inclusin de nuevos conjuntos de pruebas deber ser una o a tarea viable. De esta forma estaremos previniendo la obsolescencia de la plataforma en cuanto se lleve a cabo alguna modicacin de los o estndares, al tiempo que facilitamos la ampliacin de las pruebas que a o se llevan a cabo. Por otro lado la actualizacin de la plataforma en o

175

7.3. Dise o de la plataforma n caso necesario se convertir en una tarea ms asequible al necesitar a a actualizar unicamente aquellos mdulos que lo requieren, en lugar de o toda la plataforma. Para afrontar este requisito deber disearse unas interfaces de proa n gramacin y cheros de descripcin de pruebas a realizar desde los o o que se acceder a los desarrollos de las pruebas en s permitiendo de a , esta forma que cualquier conjunto de pruebas que sea conforme con los interfaces descritos pueda ser utilizado junto con la plataforma. Estos interfaces de programacin debern proporcionar toda la funcionalidad o a necesaria para que todas las pruebas puedan adquirir la informacin o que necesitan, al tiempo que llevan a cabo los pasos necesarios para desarrollar sus tareas. Fraccionamiento de las Pruebas: Como se puede ver en los cap tulos 5 y 6, al aplicar la metodolog propuesta en esta tesis se genera a un elevado nmero de pruebas y ejecuciones de cada una de las prueu bas, lo que hace que el anlisis de una implementacin se extienda en a o el tiempo de forma importante. Adems, hemos visto tambin cmo a e o varias de las pruebas a realizar necesitan de modicaciones constantes en la conguracin de la implementacin de IPsec, con el n de o o evaluar el impacto de algn factor determinado en el rendimiento o la u conformidad con el estndar. a Dado que esta situacin no es la ms recomendable de cara a la usabilio a dad de la plataforma, se debe proporcionar a los usuarios la posibilidad de que el conjunto de pruebas que se llevarn a cabo se fraccionen en a mltiples sesiones. El conjunto de estas sesiones abarcar todas las u a pruebas necesarias y nalmente proporcionar los resultados de la vaa lidacin y evaluacin de la implementacin tal y como si se hubiese o o o llevado a cabo todo el anlisis en una unica sesin. a o Adicionalmente, ser deseable que el usuario pudiese agrupar todas a aquellas pruebas que requieren de conguraciones similares en la implementacin de IPsec estudiada, lo que permitir llevar a cabo todos o a esos anlisis sin tener que alterar la conguracin del dispositivo. De a o esta forma el usuario podr contar con paquetes de pruebas que a pueden ejecutarse como un proceso por lotes, sin necesidad de estar alerta ante la necesidad de alterar la conguracin de un dispositivo o o equipo cada poco tiempo. La solucin preliminar que se propone para integrar esta caracter o stica en la plataforma incluye el uso de tecnolog de almacenamiento as (como por ejemplo, una Base de Datos) para almacenar los resultados de cada una de las sesiones parciales, y anlisis detallados de los a requisitos de cada prueba, con el objetivo de poder agrupar aquellas pruebas cuyos requisitos son compatibles, maximizando el nmero de u

Cap tulo 7. Dise o e Implementacin n o pruebas en cada grupo y minimizando el nmero de grupos. u

176

Interpretacin de Resultados: Un ultimo requisito de la plataforma o de validacin y evaluacin remota es la inclusin de algn tipo de o o o u interpretacin de los resultados obtenidos que facilite la comprensin o o por parte del usuario del signicado prctico de los valores obtenidos a tras los procesos de validacin y evaluacin. o o En este aspecto estamos trabajando en dos l neas diferentes: Por un lado se ofrecern gu de conguracin en la que se detallen las cona as o guraciones ptimas desde dos puntos de vista diferentes: primando la o interoperatividad y primando el rendimiento. De esta forma se proporcionar a los usuarios informacin acerca de cmo mejorar las prestaa o o ciones de su implementacin de IPsec en estos dos aspectos. o El otro aspecto en el que se trabaja es la comparacin de los resultados o de la implementacin estudiada con respecto a otras implementaciones o que hayan sido anteriormente analizadas en la plataforma, con el n de que el usuario disponga de una visin de la posicin relativa de su imo o plementacin en el conjunto de implementaciones IPsec del mercado. o Para contar con esta informacin se utilizar el soporte de almacenao a miento de datos del que hablbamos al analizar el fraccionamiento de a las pruebas. Sin embargo, esta informacin no podr ser generada hasta que no se o a disponga de un nmero de implementaciones analizadas m u nimo, que permita establecer comparaciones realistas y signicativas. Como podemos ver, la implementacin de la arquitectura introduce o nuevos retos que resolver, al tiempo que proporciona mejoras importantes con respecto a las pruebas atmicas en mltiples aspectos. Por estos motivos o u es muy importante dedicar el tiempo necesario a realizar un anlisis y diseo a n riguroso, de forma que evitemos encontrarnos posteriormente con problemas que exijan deshacer parte del trabajo hecho. Como punto de partida se utilizar el diseo mostrado en la Figura 7.4. a n En este esquema se muestra un interfaz Web que evita que los usuarios deban interactuar directamente con las pruebas en s mismas. Los mdulos o de pruebas aparecen representados en la parte superior, existiendo un mduo lo de pruebas de validacin de la conformidad, otro mdulo de pruebas de o o evaluacin del rendimiento, etc. . . . Un mdulo de control se encarga de coo o municar el interfaz web con el sistema de almacenamiento de resultados y con cada uno de los mdulos de pruebas. Asimismo, el mdulo de control o o tambin se comunica y congura el dispositivo encargado de generar artie cialmente las condiciones de red denidas en los perles de trco3 , y con a
3 En esta implementacin de la plataforma se ha optado por utilizar NIST Net ([124]) o sobre un equipo con Linux que hace las funciones de puente entre las implementaciones.

177

7.3. Dise o de la plataforma n

Figura 7.4: Esquema de la plataforma que implementar el conjunto de a pruebas propuesto.

Cap tulo 7. Dise o e Implementacin n o

178

los sistemas que cuentan con la implementacin de referencia, desde los que o se lanzarn realmente las pruebas hacia la implementacin que es objeto de a o la evaluacin. Este mdulo de control tambin es el responsable de gestionar o o e el ujo de las pruebas que se estn llevando a cabo, y comunicarse con el a interfaz web para proporcionar informacin al usuario acerca del estado de o las pruebas. Todos los resultados y eventos de inters se almacenan en una Base de e Datos, a la que es necesario acceder a travs del mdulo de control, o de cada e o una de los mdulos de pruebas en s mismas. Por ultimo, aparece tambin o e un interfaz de programacin (API) que permitir a terceras aplicaciones o a acceder a los datos almacenados en la Base de Datos y al mdulo de control, o de forma que otros desarrollos puedan acceder tanto a las librar de anlisis as a (a travs del mdulo de control) como la informacin de la Base de Datos e o o sin necesidad de utilizar el interfaz web. Una de las principales ventajas de este diseo es su modularidad, ya n que al independizar los mdulos responsables de la comunicacin con el o o usuario (interfaz web), conguracin y control de la evaluacin (control y o o cada mdulo de pruebas adicional) y los sistemas que realmente llevan a o cabo la bater de pruebas contra el sistema evaluado, es posible distribuir a estas funcionalidades entre uno o varios sistemas diferentes, de acuerdo con los requisitos y caracter sticas de cada usuario. Por ejemplo, en la Figura 7.5 podemos ver un ejemplo de despliegue para un usuario particular, en el que la implementacin a evaluar se encuentra en el mismo equipo desde o el que el usuario se conecta a la plataforma. Sin embargo, en la Figura 7.6 se propone una instalacin en la que las funciones se encuentran repartidas o entre mltiples sistemas, con lo que la capacidad de generacin de trco y u o a de uso en paralelo de la plataforma es mayor. Otro efecto de la modularidad de este diseo es que al independizar las n funciones de interfaz y control de los sistemas que realmente llevan a cabo las pruebas, se da pie a que la utilizacin de la plataforma pueda llevarse a cabo o simultneamente por mltiples usuarios. Para esto es necesario disponer de a u una infraestructura de red capaz de soportar todo el trco de red que se a genere y de sucientes implementaciones de IPsec de referencia como para poder establecer los sucientes canales seguros como sea necesario. Por ultimo, al separar los sistemas que llevan a cabo las pruebas de los mdulos que interactan con el usuario, se ha eliminado uno de los poteno u ciales problemas a los que nos enfrentbamos: la utilizacin de la red por a o parte del usuario para estudiar el rendimiento de la propia red. Con este diseo podemos observar que existen tres tipos de trco diferente: n a 1. Trco del usuario al interfaz: este trco se corresponde con el a a existente entre el interfaz web de la plataforma y el equipo desde el que el usuario hace uso de la mima. Es el que se genera al congurar

179

7.3. Dise o de la plataforma n

Figura 7.5: Esquema de utilizacin de la plataforma en el que un usuario o selecciona las pruebas a llevar a cabo en la implementacin de IPsec exiso tente en el mismo equipo que utiliza para conectarse al interfaz web de la plataforma

Cap tulo 7. Dise o e Implementacin n o

180

Figura 7.6: Esquema de utilizacin de la plataforma en el que un usuario o selecciona las pruebas a llevar a cabo en la implementacin de IPsec existente o en otro dispositivo

181

7.4. Conclusiones las pruebas que se llevarn a cabo y al recibir los resultados de dichas a pruebas.

2. Trco del mdulo de control a los sistemas de pruebas: este a o trco es el que permite a la plataforma congurar los diferentes sistea mas que se utilizarn para llevar a cabo las pruebas, as como iniciar a y nalizar cada una de las pruebas individuales. 3. Trco entre los sistemas de pruebas y la implementacin a o evaluada: este trco es el que se genera para la realizacin de cada a o una de las pruebas que se llevan a cabo. Al independizar los mdulos que generan estos tres tipos de trco es o a posible aislar estos canales de comunicaciones, evitando que, por ejemplo, el trco generado por el usuario con el interfaz de la plataforma interera a con el desarrollo de las pruebas (como puede verse en la Figura 7.6. Adicionalmente, este aislamiento acta como un mecanismo de seguridad que u permite que en caso de que la comunicacin entre el usuario y la platao forma se interrumpa (debido, por ejemplo, a la realizacin de pruebas con o caracter sticas de IPsec que no estn soportadas en la implementacin del a o usuario), esto no origine prdida de datos alguna, ya que la comunicacin e o entre los sistemas de pruebas y el mdulo de control es independiente del o sistema del usuario. De esta forma el usuario podr acceder posteriormente a al interfaz de la plataforma para consultar los resultados almacenados a la nalizacin de las pruebas, independientemente de si la comunicacin entre o o su equipo y la plataforma se ha interrumpido o no.

7.4.

Conclusiones

Como se ha podido ver en este apartado, las implementaciones desarrolladas en esta tesis han seguido dos caminos diferenciados: por un lado se han desarrollado pruebas atmicas que sirviesen de evaluacin al conjunto o o de pruebas generado a partir de la aplicacin de la metodolog a la arquio a tectura IPsec; por otro lado se ha iniciado el desarrollo de una plataforma de validacin y evaluacin remota de implementaciones IPsec, en la que todas o o las aportaciones de esta tesis interoperen y ofrezcan resultados conjuntos. Las pruebas atmicas se han desarrollado teniendo en mente que deb o an ser una evaluacin para los mtodos de medicin y evaluacin propuestos o e o o en la metodolog y que deb ser completamente funcionales. El hecho a, an de representar una evaluacin para mtodos propuestos desde un plano ms o e a cercano al anlisis terico ha signicado que al implementar cada una de las a o pruebas se han encontrado problemas y dicultades que se han solucionado bien replanteando la estrategia de la prueba en cuestin, bien ofreciendo o soluciones novedosas a los problemas que se planteaban. Por otro lado, al

Cap tulo 7. Dise o e Implementacin n o

182

ser estas pruebas completamente funcionales es posible obtener informacin o able acerca de una implementacin de IPsec utilizando dichas pruebas. o El conjunto de las pruebas atmicas abarca completamente el conjunto o denido en el cap tulo 6, por lo que dicho conjunto de pruebas representa la primera implementacin funcional de la metodolog propuesta. Sin emo a bargo, la implementacin llevada a cabo en las pruebas atmicas carece de o o facilidad de uso para los usuarios, al tiempo que no presentan optimizacin o y gestin adecuada de los recursos y librer que utilizan. o as Para paliar estos problemas y dar respuesta a otros requisitos, la siguiente implementacin del conjunto de pruebas se ha llevado a cabo mediante o una plataforma de validacin y evaluacin remota de implementaciones de o o IPsec. Desde esta plataforma es posible realizar anlisis completos de una a implementacin de IPsec, de forma remota incluso, obteniendo la misma ino formacin que al utilizar las pruebas atmicas, aunque con mayor facilidad o o de uso. El desarrollo de esta plataforma ha tenido que hacer frente a nuevos retos y dicultades, algunos de los cuales han sido ya abordados durante el diseo de la plataforma mientras que otros se han manifestado a la hora n de trasladar las pruebas atmicas a una plataforma que integrase todas o ellas. Utilizando un diseo que independiza las labores de interfaz, motor n de pruebas y control ha sido posible proporcionar una solucin elegante, o escalable y con mecanismos para preservar la informacin en determinados o casos de error.

Cap tulo 8

Evaluacin de la Tesis o
En este cap tulo se proceder a evaluar la presente tesis, analizando a el grado de consecucin de los objetivos planteados en el cap o tulo 1. Este estudio se llevar a cabo en dos fases: en la primera de ellas, desarrollada a en la seccin 8.1, se analiza cada uno de los objetivos propuestos para esta o tesis, evaluando su grado de cumplimiento. La segunda fase, que se llevar a a cabo en la seccin 8.2, se centra en comprobar los resultados de someter a o una implementacin de IPsec a un conjunto de pruebas generado a partir o de la metodolog propuesta, estudiando los resultados obtenidos. a

8.1.

Evaluacin de la tesis o

Con el n de evaluar el nivel de satisfaccin de los objetivos propuestos o en la presente tesis es necesario analizar, para cada uno de los que se propusieron, el grado de cumplimiento. En esta seccin se llevar a cabo dicho o a anlisis, en el que uno a uno se estudiar en qu medida la tesis ha cumplia a e do con cada objetivo, analizando si la solucin encontrada es susceptible de o mejora.

8.1.1.

Identicacin de los parmetros de conformidad con o a el estndar a

El primero de los objetivos propuestos en esta tesis es la identicacin, o a partir del estudio de especicaciones de protocolos y arquitecturas de seguridad estandarizados, de aquellos parmetros que condicionan el que a una implementacin sea conforme al estndar o no. La complejidad de los o a protocolos y arquitecturas de seguridad (tanto por la cantidad de protocolos y herramientas que la componen, como por su estructura modular en la que gran cantidad de esos componentes pueden ser reemplazados por otros), hace que sea muy complicado denir unos parmetros m a nimos que todas 183

Cap tulo 8. Evaluacin de la Tesis o las implementaciones debieran cumplir para poder interoperar.

184

El anlisis de los parmetros de conformidad con el estndar que es a a a necesario evaluar parte de los propios documentos que denen las especicaciones de cada protocolo y componente de estos protocolos, en los que se encuentran recogidos los requisitos denidos por el organismo que estandarice el protocolo en cuestin, relativos a la conformidad con el estndar o a de cada componente. Este anlisis, aunque vlido, tiene el problema de que a a unicamente comprobar un conjunto m a nimo de requisitos para llevar a cabo el desarrollo de los protocolos. Sin embargo, los protocolos de seguridad dependen tambin en amplio grado de la utilizacin de las herramientas e o criptogrcas (denidas tambin en otros documentos que forman parte del a e estndar, como por ejemplo [54], donde se denen y ampl las suites cripa an togrcas que pueden y deben utilizarse con el protocolo ESP), al igual a que lo hace de los mecanismos de autenticacin y de gestin de claves que o o se integran en dichos protocolos. El motivo por el que en los documentos del estndar unicamente se hace referencia a la ejecucin de los protocoa o los en los apartados de conformidad se debe a que dichos requisitos son los m nimos para que una implementacin pueda establecer canales seguo ros con otro dispositivo semejante. Sin embargo, la interoperatividad con otras implementaciones de otros fabricantes no se pone a prueba en ningn u momento. Adicionalmente, los requisitos que se establecen para la conformidad resultan ser en muchos casos unos m nimos que, si bien aseguran que una implementacin que cumpla con ellos no tendr un comportamiento errtico o a a en cuanto al env y recepcin de mensajes pertenecientes a cada uno de los o o protocolos, no garantizan en ningn caso que dicha implementacin sea cau o paz de recuperarse de la recepcin de mensajes mal formados o incorrectos, o ya que el estndar unicamente dene que la implementacin aceptar o no a o a aceptar dicho mensaje. Esto ha llevado a que algunas implementaciones a sean conformes con lo descrito en el estndar ya que, al recibir un mensaje a mal formado la implementacin interrumpe y destruye los canales seguros eso tablecidos, como ocurre con la implementacin de IPsec FreeS/WAN ([21]). o Dado que este comportamiento no es el aconsejable, en esta tesis se han diseado las pruebas de tal forma que se identica no slo si una implementan o cin es capaz de identicar un mensaje errneo o mal formado, sino tambin o o e si posteriormente la implementacin es capaz de recuperarse del error y cono tinuar operando sin que sea necesario interrumpir las comunicaciones que dicha implementacin protege. o Por todos estos motivos, el anlisis de los requisitos de conformidad nea cesarios para los protocolos y arquitecturas de seguridad llevado a cabo en esta tesis no slo recoge la correcta ejecucin del protocolo, sino que incluye o o el uso correcto de las herramientas criptogrcas, mecanismos de autentia cacin y de gestin de claves, as como otras caracter o o sticas que, aunque

185

8.1. Evaluacin de la tesis o

inicialmente opcionales, deben ser evaluadas en el caso de utilizar arquitecturas de red concretas (como en el caso de NAT traversal en IPsec). Adicionalmente el anlisis llevado a cabo para identicar estos parmea a tros que es necesario evaluar, proporciona una lista de aspectos que deben ser evaluados, junto con un anlisis acerca de los problemas que pueden surgir a al validar esos parmetros y proponiendo posibles soluciones para superar a dichos problemas. Gracias a este anlisis hemos podido constatar cmo se ha proporcioa o nado una aproximacin terica a problemas que pueden surgir al llevar a o o cabo la validacin de la implementacin, tanto de un punto de vista terio o o co (como por ejemplo, la necesidad de disponer de una implementacin de o referencia en la que basar nuestro anlisis) como prctico (la necesidad de a a enviar mensajes mal formados y llevar a cabo operaciones no permitidas segn el estndar). Como consecuencia, en esta tesis se han propuesto soluu a ciones novedosas para la validacin de la implementacin de herramientas o o mantenindose en los l e mites marcados para la metodolog Por ejemplo, a. cabe citar el uso de la transitividad para evaluar la implementacin de heo rramientas criptogrcas en implementaciones que son tratadas como cajas a negras, y a las que no podemos aplicar los vectores de pruebas propuestos en las especicaciones de dichas herramientas. Por otro lado, el hecho de que las medidas propuesta hayan podido ser llevadas a la prctica en forma de pruebas atmicas que desarrollan anlisis a o a concretos, nos indica que el estudio llevado a cabo acerca del modo en el que implementar dichos anlisis ha dado sus frutos, aplicando la metodolog en a a un conjunto de pruebas cuya implementacin es viable y sus resultados ofreo cen informacin concreta acerca de aspectos determinados, aspectos que son o los que determinan el grado de conformidad con el estndar de la implemena tacin de IPsec y sus posibilidades de interoperatividad. o

8.1.2.

Identicacin de los parmetros de rendimiento o a

Otro de los objetivos de esta tesis es la identicacin de parmetros o a que afecten al rendimiento de los protocolos y arquitecturas de seguridad. En este caso el problema era diferente, ya que, aunque existen mltiples u propuestas y herramientas para obtener informacin acerca del rendimiento o de los sistemas de comunicaciones, dichos sistemas no aportan informacin o util al introducir mecanismos de seguridad en dichos sistemas, como se vio en el cap tulo 2. Aunque en teor hubiese sido posible llevar a cabo un estudio del a rendimiento de las implementaciones de protocolos de seguridad utilizando metodolog de anlisis de rendimiento tradicionales, hemos visto cmo as a o los anlisis realizados indican que las diferencias entre las comunicaciones a cuando en el proceso de transmisin se integran mecanismos de seguridad no o

Cap tulo 8. Evaluacin de la Tesis o

186

afectan unicamente a las medidas de rendimiento, sino que tambin afectan e al conjunto de aspectos que es necesario evaluar. En esta tesis se ha llevado a cabo un anlisis exhaustivo de las difea rencias entre el rendimiento de los sistemas de comunicaciones sin ningn u tipo de mecanismo de seguridad integrado, y el rendimiento de los mismos sistemas al utilizar un protocolo de seguridad como SSL/TLS o una arquitectura de seguridad como IPsec. A partir de las diferencias obtenidas ha sido posible analizar cules son los recursos que se ven ms afectados al utia a lizar este tipo de soluciones de seguridad, y en qu afectan estos recursos al e rendimiento del sistema. Una aportacin importante de esta tesis es la identicacin del estao o blecimiento de conexin como uno de los componentes que ms recursos o a requieren, especialmente ciclos de proceso en la CPU y espacio de memoria, al contrario que en una comunicacin sin mecanismos de seguridad, en o la que el establecimiento de conexin tiene unos requisitos mucho menores. o Este tipo de diferencias sutiles han sido detectadas durante la fase de anlia sis del rendimiento de los protocolos de seguridad, lo que nos ha llevado a evitar replicar una metodolog tradicional de anlisis del rendimiento de a a redes de comunicaciones, haciendo hincapi en las caracter e sticas propias de los protocolos y arquitecturas de seguridad. Por otro lado, y fruto de este mismo enfoque, ha surgido la necesidad de utilizar perles de trco para evaluar correctamente el rendimiento de a las implementaciones de los protocolos de seguridad, ya que una de las principales caracter sticas identicadas es la diferencia entre los requisitos para cifrar y descifrar, por lo que, desde el punto de vista del rendimiento, no es lo mismo recibir trco a una velocidad determinada que generar trco a a a esa misma velocidad. Este aspecto, que en las comunicaciones sin mecanismos de seguridad no afecta a los resultados de los anlisis de rendimiento, a es crucial para las implementaciones de los protocolos de seguridad. As pues, la conjuncin del estudio llevado a cabo para la identica o cin de los parmetros de rendimiento que es necesario evaluar, y el anlisis o a a posterior de los mtodos que pueden emplearse para llevar a cabo dicha evae luacin, conforman un estudio en profundidad acerca de la evaluacin del o o rendimiento en implementaciones de protocolos y arquitecturas de seguridad. Al igual que ocurr anteriormente, el haber podido trasladar este anlia a sis a implementaciones prcticas con las que se llevan a cabo pruebas necea sarias indican que la evaluacin del rendimiento segn el anlisis propuesto o u a es factible, obtenindose resultados que permiten conocer en detalles cul e a ser el comportamiento de la implementacin evaluada al llevar a cabo su a o funcin, y tambin cmo responder a denegaciones de servicio (accidentales o e o a o provocadas).

187

8.1. Evaluacin de la tesis o

8.1.3.

Establecimiento de un marco de anlisis y desarrollo a para protocolos y arquitecturas de seguridad

El anlisis llevado a cabo ha permitido estudiar las caracter a sticas y particularidades de los protocolos y arquitecturas de seguridad, tanto en lo referente a conformidad e interoperabilidad como en lo tocante al anlisis del a rendimiento. Muchos de los conocimientos adquiridos y estudios realizados son una valiosa base para el desarrollo de posteriores aplicaciones similares a otros protocolos y arquitecturas de seguridad, generndose as un marco a de trabajo que englobe tanto las labores de anlisis que se han llevado a a cabo como los desarrollos que han surgido de esta tesis. El anlisis de los aspectos que es necesario evaluar en lo tocante a cona formidad y rendimiento que se ha llevado a cabo en la presente tesis proporciona unos fundamentos sobre los que construir y desarrollar en profundidad un estudio ms detallado y amplio, en el que se abarquen otras arquitectua ras y protocolos de seguridad, as como los problemas de interoperatividad y rendimiento que se presentan y los or genes de dichos problemas. De esta forma se podr construir una base comn en la que aparezcan reejadas a u todas las caracter sticas sobre las que llevar a cabo los anlisis, de forma a que la mejora de esta base comn permita hacer avanzar los conocimientos u y desarrollos sobre la interoperatividad y rendimiento de implementaciones de protocolos y arquitecturas de red. En este aspecto la presente tesis ha contribuido a este objetivo trabajando en dos frentes diferentes pero complementarios: Por un lado, los estudios de rendimiento e interoperatividad se basan en caracter sticas de los protocolos y arquitecturas de seguridad que los distinguen de los protocolos de red sin seguridad incluida. Posteriormente, esas caracter sticas se reejan en la metodolog que se ha a propuesto en el cap tulo 5 y se ha desarrollado en el cap tulo 6 para la arquitectura IPsec, pero el ncleo abstracto del estudio puede u ser aplicado a la gran mayor de los protocolos y arquitecturas de a seguridad. Adicionalmente, los anlisis acerca de mtodos y mecanismos que pera e mitan salvar las dicultades que puedan surgir al implementar los mtodos de validacin y evaluacin propuestos, se han llevado a cae o o bo evitando proponer soluciones particulares para una arquitectura o protocolo concreto, resultando por lo tanto que los avances logrados mediante dichos anlisis pueden ser aplicables al resto de protocolos y a arquitecturas de seguridad. Por otro lado, al implementar las pruebas surgidas de la aplicacin de o la metodolog a IPsec se ha independizado el motor de prueba de las a librer necesarias para trabajar con IPsec, resultando de este mtodo as e

Cap tulo 8. Evaluacin de la Tesis o

188

de desarrollo unas librer de validacin y evaluacin de protocolos as o o de seguridad que, mediante una adecuada integracin y desarrollo de o puntos de entrada, permitir su utilizacin con otros protocolos de a o seguridad. Este aspecto seguir mejorndose junto con el desarrollo de la plataa a forma de validacin y evaluacin remota, para permitir que el trabajo o o desarrollado pueda ser utilizado para obtener informacin de otros o protocolos y arquitecturas. Por todos estos motivos podemos decir que la presente tesis ha cumplido con el objetivo que se marc en sus inicios, al haber proporcionado los medios o necesarios para que los conocimientos y desarrollos fruto de la labor realizada puedan ser reutilizados y mejorados en el futuro.

8.1.4.

Metodolog de validacin y evaluacin de implemena o o taciones de protocolos de seguridad

La metodolog de validacin y evaluacin de implementaciones de proa o o tocolos de seguridad parte de los anlisis anteriores para, utilizando los mtoa e dos de evaluacin propuestos en cada uno de los anlisis, construir una meo a todolog que permita evaluar la conformidad con el estndar y evaluar el a a rendimiento de implementaciones de protocolos de seguridad. La metodolog propuesta ofrece un conjunto estructurado de gu y a as orientaciones enfocadas a validar aspectos concretos de la conformidad y evaluar el rendimiento de la implementacin del protocolo de seguridad que se o desea analizar. Para cada aspecto que deba ser evaluado se analizan qu ase pectos deben tenerse en cuenta a la hora de llevar a cabo esa evaluacin, los o mecanismos y tcnicas que pueden utilizarse para las tareas de captura de e datos, los pasos a llevar a cabo para la obtencin y procesado de los resulo tados que se obtengan. Este anlisis propuesto en la metodolog permite a a recabar informacin acerca de aquellos aspectos que se han identicado como o cruciales para asegurar la interoperabilidad entre diferentes implementaciones de los protocolos de seguridad. Por lo tanto, la metodolog tambin a e permite obtener informacin que puede utilizarse para evaluar el nivel de o interoperabilidad de dos implementaciones independientes. Adicionalmente, la estructura modular (en fases) de la metodolog pera mite su constante revisin y actualizacin para mantenerla al d e incoro o a porar modicaciones y actualizaciones a la misma. Del mismo modo, en algunos aspectos (como por ejemplo, la conformidad de la implementacin o de herramientas criptogrcas) la metodolog es exible, de tal forma que a a permite abarcar los diferentes protocolos y arquitecturas de seguridad existentes, sin cerrarse a ninguno ni entrar en detalles espec cos de alguno de ellos.

189

8.1. Evaluacin de la tesis o

En cuanto a la evaluacin del rendimiento de una implementacin IPsec, o o la metodolog propone bater de pruebas que permiten identicar cul es a as a el coste de utilizar IPsec para proteger el trco de nuestra red (en latencia a de la red y ancho de banda efectivo del que se puede disponer), cmo afecta o dicha penalizacin segn la conguracin de IPsec que se utilice, cmo afeco u o o ta el trco de red a la capacidad de establecer nuevos tneles criptogrcos a u a (y por lo tanto, a la capacidad de crecimiento de la red utilizando la misma implementacin de IPsec) y qu fases de IPsec representan o pueden o e representar un cuello de botella en el rendimiento. Los anlisis que se proponen son exhaustivos, en tanto que todos los a aspectos que pueden afectar al rendimiento son tenidos en cuenta para obtener la informacin de rendimiento. Aunque este enfoque eleva la cantidad o total de pruebas que se generan al aplicar esta metodolog a un protoa colo o arquitectura de seguridad concreto, el resultado nal es un anlisis a pormenorizado del que se puede extraer cul la inuencia exacta de cada a caracter stica en el rendimiento que la implementacin est ofreciendo. o a Al igual que hemos comentado para la validacin de la implementacin, o o la modularidad de los conjuntos de pruebas descritos para la evaluacin del o rendimiento hace que sea posible mantener la metodolog actualizada o a incluso adaptada a necesidades particulares. Por lo tanto, la metodolog propuesta es capaz de presentar mtodos a e estructurados para evaluar los diferentes aspectos de conformidad y rendimiento que deben ser analizados en una implementacin de un protocolo o o arquitectura de seguridad.

8.1.5.

Aplicacin de la metodolog a la arquitectura de seo a guridad IPsec

Una vez denida la metodolog en el cap a tulo 5, se ha procedido a vericar la aplicabilidad de la metodolog a una arquitectura de seguridad a concreta; en este caso, IPsec. En el cap tulo 6 se ha llevado a cabo una aplicacin de las directrices formuladas en la metodolog a la arquitectuo a ra de seguridad, lo que ha generado un conjunto de pruebas destinados a llevar a cabo los procesos de validacin de la conformidad y evaluacin del o o rendimiento. A la hora de aplicar la metodolog se ha podido comprobar cmo ha a o sido posible desarrollar conjuntos de pruebas que forman un conjunto completo respecto de las caracter sticas que toda implementacin de IPsec debe o desarrollar para ser conforme con el estndar. Para ello se han analizado tal a y como especica la metodolog todos y cada uno de los componentes de la a arquitectura: protocolos, algoritmos criptogrcos, etc. . . . y se han diseado a n pruebas que permitiesen obtener informacin acerca de cmo se encuentran o o implantados cada uno de esos componentes en la implementacin que se o

Cap tulo 8. Evaluacin de la Tesis o est analizando. a

190

En cuanto a la evaluacin del rendimiento, ha sido posible denir cono juntos de pruebas que analizan los diferentes aspectos del rendimiento de protocolos y arquitecturas de seguridad que es interesante conocer (segn u el anlisis llevado a cabo en el cap a tulo 4) aplicados a la idiosincrasia de la arquitectura de seguridad IPsec. Estos conjuntos de pruebas permiten evaluar el rendimiento de la implementacin cuando se utilizan determinadas o combinaciones de protocolos, algoritmos y mecanismos de seguridad, por lo que permiten obtener una visin general del rendimiento global, as como o detalles espec cos acerca del rendimiento en condiciones concretas. Por ultimo, cabe destacar que en la aplicacin de la metodolog a IPsec o a se ha llevado a cabo tambin un proceso de denicin de perles de utilizae o cin de la implementacin que es interesante utilizar a la hora de obtener o o informacin realista acerca del rendimiento de la implementacin. Algunos o o de estos perles tienen por objetivo la identicacin de valores representao tivos del rendimiento de la implementacin (por ejemplo, el mximo ancho o a de banda que se puede proteger), mientras que otros estn orientados a la a recogida de informacin acerca del rendimiento que la implementacin pueo o de ofrecer en condiciones realistas (por ejemplo, utilizando comunicaciones con TCP, UDP e ICMP, y existiendo un 1 % de paquetes descartados en la red).

8.1.6.

Desarrollo de una plataforma de validacin y evaluao cin remota de implementaciones de IPsec o

Los desarrollos llevados a cabo durante el desarrollo de la presente tesis han seguido dos enfoques diferentes, aunque complementarios. Por un lado se han desarrollado las pruebas atmicas que implementan cada una de las o pruebas y anlisis individuales descritos en la aplicacin de la metodolog a o a a la arquitectura IPsec; por otro lado, el diseo y desarrollo de una platan forma de validacin y evaluacin remota pretende ser el hito nal en el que o o interoperan todas las aportaciones de la presente tesis. Las pruebas atmicas desarrolladas como paso inicial en la implemeno tacin del conjunto de pruebas propuesto han resultado ser un mtodo de o e evaluacin del anlisis llevado a cabo para los factores de conformidad y o a de rendimiento, as como para los mtodos de medicin y evaluacin que e o o se hab propuesto en dichos anlisis. En esta faceta de sistema de autoan a control para las propuestas que se han realizado en esta tesis, las pruebas atmicas han resultado ser un mtodo ecaz a la par que sencillo de llevar o e a cabo. Por otro lado, las pruebas atmicas tambin han servido para establecer o e un punto de partida para la implementacin de la plataforma de validacin o o y evaluacin remota de implementaciones de IPsec, desde el que llevar a o

191

8.2. Evaluacin de Implementaciones de IPsec o

cabo el diseo y establecer diferencias entre ambas implementaciones. Este n estudio de las diferencias entre las pruebas atmicas y la plataforma de o validacin e implementacin remota es una ventaja fundamental de cara al o o anlisis de requisitos e identicacin de las dicultades con las que podremos a o encontrarnos. Sin embargo, no debemos olvidar que las pruebas atmicas tambin son o e un desarrollo de las pruebas generadas al aplicar la metodolog a implemena taciones IPsec, y como tal, son capaces de analizar una implementacin de o IPsec y ofrecernos informacin acerca de su conformidad con el estndar y o a del rendimiento que dicha implementacin puede ofrecer, como se ver en la o a seccin 8.2. o En cuanto a la plataforma de validacin y evaluacin remota de impleo o mentaciones IPsec, su desarrollo ha permitido contar con un entorno amigable que sirva para llevar a cabo la validacin de la conformidad de una o implementacin de IPsec, al tiempo que evaluamos el rendimiento que dicha o implementacin es capaz de ofrecer. Durante el proceso de desarrollo de la o plataforma se ha llevado a cabo una labor de anlisis que ha permitido, por a un lado, independizar el motor de pruebas de la implementacin del protocoo lo de seguridad,y por otro, denir mecanismos para que la plataforma pueda integrarse con otras herramientas que maximicen el valor de la informacin o recabada en la plataforma. Las implementaciones de los conjuntos de pruebas que se han desarrollado, tanto en forma de pruebas atmicas como siendo parte de la platao forma, han sido utilizadas en varios proyectos de investigacin, permitiendo o obtener informacin acerca de la conformidad y el rendimiento de varias imo plementaciones de IPsec de diversos fabricantes. Asimismo, diversos grupos de investigacin de centros internacionales han mostrado su inters por la o e plataforma de validacin y evaluacin remota. o o

8.2.

Evaluacin de Implementaciones de IPsec o

Con el n de conocer cules son los resultados que ofrece la metodolog a a al analizar una implementacin de IPsec, en esta seccin presentamos los reo o sultados obtenidos al aplicar la metodolog haciendo uso de las pruebas a, atmicas y de la plataforma de evaluacin descritas en la seccin 7.2. La imo o o plementacin analizada ha sido OpenS/WAN v2.4.4 , ejecutndose sobre un o a sistema operativo Linux. Las caracter sticas completas del sistema evaluado pueden verse en la Tabla 8.1. Los resultados obtenidos al aplicar las pruebas que desarrollan la metodolog para la arquitectura IPsec se desarrollarn en los siguientes apara a tados. En ellos se har referencia a los nombres de las pruebas atmicas tal a o y como se declararon en el cap tulo 7.

Cap tulo 8. Evaluacin de la Tesis o Tabla 8.1: Especicaciones de la implementacin IPsec evaluada o Sistema Operativo Linux (kernel 2.6.15) Procesador AMD Athlon 550 MHz Memoria 384 MB Implementacin de IPsec OpenS/WAN 2.4.4 o Herramientas Criptogrcas Compiladas en el ncleo del a u sistema operativo: HMACMD5, HAC-SHA1, MD4, MD5, SHA256, SHA384, SHA512, DES, 3DES, Blowsh, Twosh, Serpent, AES, CAST5, CAST6, TEA, ARC4 Versin de IPsec o IPsec versin 1 o Tecnolog de Red a Fast Ethernet dedicada, con enlace directo entre las implementaciones

192

Tabla 8.2: Resultados de validacin de las herramientas criptogrcas utilio a zadas en ESP Prueba EspNull Esp3Des EspAES Resultado OK OK OK

8.2.1.

Validacin de la conformidad o

Como podemos ver, la implementacin evaluada unicamente presenta o problemas de conformidad al utilizar AES-XCBC-MAC-96, ya que dicho algoritmo no se encuentra disponible en dicha implementacin. Todo el resto o de pruebas realizadas ofrecen resultados positivos, tanto para la Fase 1 como la Fase 2 y en ESP. Dado que el actualmente AES-XCBC-MAC-96 es opcional para IPsec v1, las herramientas criptogrcas en OpenS/WAN a son conformes a lo especicado en el estndar. a Tambin podemos observar cmo, en lo tocante al desarrollo de los proe o tocolos, la implementacin evaluada no presenta ningn problema en ninguo u no de los protocolos, modos de funcionamiento ni opciones disponibles. Por lo tanto, la implementacin de los protocolos tambin es conforme o e a los estndares. a

193

8.2. Evaluacin de Implementaciones de IPsec o

Tabla 8.3: Resultados de validacin de las herramientas criptogrcas utilio a zadas en la Fase 1 de IKE Prueba Fase13DesMD5 Fase13DesSHA1 Fase13DesAES Fase1AesSHA1 Fase1AesAES Resultado OK OK No Disponible OK No Disponible

Tabla 8.4: Resultados de validacin de las herramientas criptogrcas utilio a zadas en la Fase 2 de IKE Prueba Fase23DesMD5 Fase23DesSHA1 Fase23DesAES Fase2AesSHA1 Fase2AesAES Resultados OK OK No Disponible OK No Disponible

Como podemos ver, OpenS/WAN no permite la utilizacin de certio cados X.509 para llevar a cabo los procesos de autenticacin. Dicha funo cionalidad est soportada mediante parches que no fueron aplicados a la a implementacin evaluada, por lo que no es posible evaluar esta caracter o stica. Por lo tanto, y dado que la autenticacin mediante certicados X.509 o es un requisito para la arquitectura de seguridad IPsec, OpenS/WAN no es conforme al estndar en este aspecto. a En cuanto a la gestin de claves, OpenS/WAN no presenta o ning n problema al controlar las renovaciones de claves criptogrcas, u a tanto en la Fase 1 como en la Fase 2. Por ultimo, las caracter sticas adicionales que es posible que sean necesarias para utilizar IPsec en nuestra topolog de red estn irregularmente a a implementadas en OpenS/WAN. Mientras que NAT traversal no presenta problema alguno, la compresin de datos en la capa IP preo senta problemas al interoperar con otras implementaciones. Por ultimo, la noticacin de la congestin de la red no se encuentra implementada en o o OpenS/WAN.

Cap tulo 8. Evaluacin de la Tesis o

194

Tabla 8.5: Resultados de validacin del desarrollo de los protocolos en modo o tnel u Prueba TunelMMQMESP TunelMMQMAH TunelMMQMESPPFS TunelMMQMAHPFS TunelAMQMESP TunelAMQMAH TunelAMQMESPPFS TunelAMQMAHPFS Resultado OK OK OK OK OK OK OK OK

Tabla 8.6: Resultados de validacin del desarrollo de los protocolos en modo o transporte Prueba TranspMMQMESP TranspMMQMAH TranspMMQMESPPFS TranspMMQMAHPFS TranspAMQMESP TranspAMQMAH TranspAMQMESPPFS TranspAMQMAHPFS Resultados OK OK OK OK OK OK OK OK

8.2.2.

Evaluacin del rendimiento o

A la hora de evaluar el rendimiento, se han incorporado a los resultados los valores obtenidos al utilizar los perles en los que la red se encuentra saturada. Estos valores aparecen en las siguientes tablas con el sujo -sat para su fcil identicacin. a o

195

8.2. Evaluacin de Implementaciones de IPsec o

Tabla 8.7: Resultados de validacin de los mecanismos de autenticacin o o Prueba PskMd5MM PskMd5AM PskSha1MM PskSha1AM RsaMM RsaAM X509MM X509AM Resultado OK OK OK OK OK OK No Disponible No Disponible

Tabla 8.8: Resultados de validacin de la gestin de claves o o Prueba Fase1Tiempo Fase2Tiempo Fase1Trafico Fase2Trafico Resultado OK OK OK OK

Tabla 8.9: Resultados de validacin de otras caracter o sticas adicionales Prueba NAT IPComp ECN Resultado OK ERROR No Disponible

Cap tulo 8. Evaluacin de la Tesis o

196

Tabla 8.10: Resultados de evaluacin del ancho de banda. o Prueba BWTMax BWTMax BWTMax BWTMax BWTMax BWTMax-sat BWTMax-sat BWTMax-sat BWTMax-sat BWTMax-sat Trad Trad Trad Trad Trad TCPAsimIn TCPAsimIn TCPAsimIn TCPAsimIn TCPAsimIn TCPAsimOut TCPAsimOut TCPAsimOut TCPAsimOut TCPAsimOut TCPSim TCPSim TCPSim TCPSim TCPSim TCPSim-sat TCPSim-sat TCPSim-sat TCPSim-sat TCPSim-sat Conguracin Resultado o ESP NULL 95 Mbps ESP 3DES - MD5 65 Mbps ESP 3DES - SHA1 50 Mbps AH MD5 80 Mbps AH SHA1 70 Mbps ESP NULL 35 Mbps ESP 3DES - MD5 25 Mbps ESP 3DES - SHA1 22 Mbps AH MD5 30 Mbps AH SHA1 28 Mbps ESP NULL 65 Mbps ESP 3DES - MD5 50 Mbps ESP 3DES - SHA1 42 Mbps AH MD5 60 Mbps AH SHA1 56 Mbps ESP NULL 52 Mbps ESP 3DES - MD5 44 Mbps ESP 3DES - SHA1 41 Mbps AH MD5 49 Mbps AH SHA1 47 Mbps ESP NULL 54 Mbps ESP 3DES - MD5 47 Mbps ESP 3DES - SHA1 44 Mbps AH MD5 52 Mbps AH SHA1 48 Mbps ESP NULL 69 Mbps ESP 3DES - MD5 55 Mbps ESP 3DES - SHA1 48 Mbps AH MD5 63 Mbps AH SHA1 60 Mbps ESP NULL 28 Mbps ESP 3DES - MD5 22 Mbps ESP 3DES - SHA1 20 Mbps AH MD5 20 Mbps AH SHA1 19 Mbps

197

8.2. Evaluacin de Implementaciones de IPsec o

Tabla 8.11: Resultados de evaluacin del nmero mximo de asociaciones de o u a seguridad Nombre MaxSA Resultado 163 Asociaciones de Seguridad

Tabla 8.12: Resultados de establecimiento de asociaciones de seguridad (Extracto) Conguracin o Mbps / SA DH2, IKE: 3DES MD5, ESP: 3DES SHA1 0,5 Mbps DH2, IKE: 3DES MD5, ESP: 3DES SHA1 1 Mbps DH2, IKE: 3DES MD5, ESP: 3DES SHA1 2 Mbps DH2, IKE: 3DES MD5, ESP: 3DES SHA1 3 Mbps DH2, IKE: 3DES MD5, ESP: 3DES SHA1 4 Mbps DH2, IKE: 3DES MD5, ESP: 3DES SHA1 5 Mbps DH2, IKE: AES SHA1, ESP: AH SHA1 0,5 Mbps DH2, IKE: AES SHA1, ESP: AH SHA1 1 Mbps DH2, IKE: AES SHA1, ESP: AH SHA1 2 Mbps DH2, IKE: AES SHA1, ESP: AH SHA1 3 Mbps DH2, IKE: AES SHA1, ESP: AH SHA1 4 Mbps DH2, IKE: AES SHA1, ESP: AH SHA1 5 Mbps Conexiones / seg. 1 1 0,5 0,3 0,2 0,2 1,4 1 0,8 0,5 0,5 0,4

Al analizar el rendimiento de la implementacin de IPsec, vemos que, sin o aplicar ningn tipo de proteccin al trco, la implementacin unicamente u o a o es capaz de transmitir 95 Mbps. Este bajo resultado hace que el resto de valores se vean afectados y se obtengan velocidades de transmisin en torno o a los 50 Mbps, un 25 % del mximo terico del canal. Asimismo, podemos a o ver cmo la saturacin del canal de datos afecta al rendimiento que es capaz o o de ofrecer la implementacin. o En cuanto a la capacidad de establecer asociaciones de seguridad, vemos que el nmero mximo de asociaciones que se pueden establecer es de 163. u a Sin embargo, si por los tneles criptogrcos se transmite informacin, la veu a o locidad a la que dichos tneles se pueden establecer es ms lenta, llegndose u a a a casos en los que hay que esperar hasta 5 segundos entre una conexin y o otra.

Cap tulo 8. Evaluacin de la Tesis o

198

Cap tulo 9

Conclusiones
En este cap tulo se procedern a presentar las conclusiones de la prea sente tesis. Estas conclusiones partirn de un anlisis de las aportaciones a a novedosas de la tesis, para continuar con un estudio de las futuras l neas de investigacin a las que el desarrollo de esta tesis nos puede conducir. o

9.1.

Aportaciones de la tesis

Las principales aportaciones de la presente tesis se corresponden con los objetivos que se denieron al inicio de la misma: identicacin y anlisis o a de los parmetros que son relevantes para evaluar la conformidad con el a estndar, identicacin y anlisis de los parmetros que resultan relevantes a o a a para evaluar el rendimiento de la implementacin, establecimiento de un o marco de anlisis y desarrollo para protocolos de seguridad, propuesta de a una metodolog de validacin y evaluacin remota de implementaciones de a o o protocolos de seguridad, aplicacin de la metodolog a la arquitectura de o a seguridad IPsec y desarrollo de una plataforma de validacin y evaluacin o o remota de implementaciones de IPsec. A continuacin desarrollaremos las conclusiones que se pueden obtener o de cada uno de estos aspectos de la tesis por separado.

9.1.1.

Anlisis de conformidad a

El anlisis de los aspectos de la conformidad con las especicaciones del a estndar que deben ser incluidos en una metodolog que se ha llevado a a a cabo en el marco de esta tesis, ha ofrecido aportaciones interesantes, no slo o en el mbito de los aspectos de un protocolo o arquitectura de seguridad que a es necesario analizar, sino tambin en el mbito de los mtodos que deben e a e utilizarse para llevar a cabo dichos anlisis. a 199

Cap tulo 9. Conclusiones

200

Por lo tanto, los anlisis llevados a cabo se han compuesto de dos partes a diferenciadas, aunque relacionadas: En una primera fase, las diferentes caracter sticas de los protocolos de seguridad que denen la conformidad de una implementacin con o respecto al estndar que dene dicho protocolo o arquitectura, han sido a identicadas y agrupadas en familias de aspectos que facilitasen su posterior utilizacin. o A continuacin, los diferentes mtodos para evaluar dichas caracter o e sticas han sido revisados y su idoneidad para ser incluidos en la metodolog ha sido evaluada. Dado el especial enfoque de la metodolog a a propuesta muchos de los mtodos de evaluacin existentes no eran e o adecuados para utilizarse en dicha metodolog por lo que se han a, propuesto nuevos mtodos alternativos que obtengan la informacin e o necesaria ajustndose a los requisitos de la metodolog a a. Este anlisis de las caracter a sticas de los protocolos y arquitecturas de seguridad que es necesario evaluar ha permitido denir, de forma estructurada y fcilmente manejable, aquellos aspectos que son origen de los problemas a de interoperatividad entre implementaciones de diferentes fabricantes. Adicionalmente, el anlisis ha permitido que sea posible denir pruebas comunes a para aquellos aspectos que pertenecen a la misma familia, simplicndose a enormemente tanto la identicacin como la evaluacin de las caracter o o sticas que es necesario evaluar. Por otro lado, la necesidad de proponer mtodos de evaluacin que se e o ajustasen a los requisitos de la metodolog (especialmente, al requisito de a operar con la implementacin unicamente como si de una caja negra se o tratase) ha hecho que en la mayor de los casos se hayan propuesto nuevas a tcnicas de evaluacin de los aspectos en cuestin. e o o Adicionalmente, el anlisis de los problemas existentes entre las difea rentes implementaciones de IPsec ha conducido a la identicacin de amo bigedades en los requisitos m u nimos denidos en los estndares de IPsec, a por lo que los mtodos de evaluacin propuestos a partir de este anlisis e o a se basan en requisitos ms estrictos que los denidos en el estndar, pero a a que permiten conocer cul ser el comportamiento de la implementacin a a o estudiada al operar con otras implementaciones. Por todos estos motivos podemos decir que el anlisis de los aspectos de a conformidad con la arquitectura de seguridad IPsec ha servido para realizar aportaciones interesantes a los mtodos de evaluacin de caracter e o sticas de conformidad. Asimismo, se han utilizado agrupaciones de estas caracter sticas para ofrecer un manejo de estos parmetros que facilitase la posterior a incorporacin en la metodolog o a.

201

9.1. Aportaciones de la tesis

9.1.2.

Anlisis de rendimiento a

En cuanto al anlisis de rendimiento, el trabajo llevado a cabo en esta a tesis ha desarrollado un anlisis en el que se estudian los factores de rendia miento que mayor inuencia tienen durante el desarrollo de un protocolo o arquitectura de seguridad. Este anlisis ha partido de un estudio particular, a estudiando las caracter sticas del protocolo TLS, para despus generalizar e los resultados obtenidos a cualquier protocolo o arquitectura de seguridad. Una de las principales diferencias que presenta el anlisis llevado a cabo a con respecto a las metodolog de evaluacin del rendimiento en comunias o caciones sin seguridad integrada, es que, mientras que las ultimas pueden incluir entre sus operaciones la extrapolacin de resultados a partir de meo diciones en condiciones que no representan la situacin que se desea evaluar, o en un protocolo o arquitectura de seguridad esto no es as ya que el anli, a sis ha demostrado cmo no es posible predecir el comportamiento de las o diferentes arquitecturas al llevar a cabo operaciones criptogrcas. a Por lo tanto, el anlisis de rendimiento ha denido el conjunto de a parmetros cuya evaluacin nos proporcionar informacin completa acerca a o a o del rendimiento que se puede esperar de una implementacin de un protocoo lo de seguridad. Adicionalmente, de esta relacin de parmetros a evaluar, o a junto con el estudio de los mecanismos que pueden aplicarse para obtener la informacin requerida, ha surgido un conjunto de pruebas que permiten o obtener la informacin requerida. o Adicionalmente al desarrollo del conjunto de pruebas a llevar a cabo, la otra gran aportacin de este anlisis ha sido la constatacin de que, al o a o utilizar un protocolo de seguridad, el tipo de trco que se protege afecta a al rendimiento que se obtendr. Por lo tanto, el rendimiento obtenido no a ser el mismo si se protege trco TCP en una unica direccin que si lo que a a o se protege es trco UDP en ambas direcciones. Igualmente, las condiciones a en las que se encuentra la red (saturacin, prdida de tramas, retransmisin o e o de paquetes, etc. . . .) afecta a los resultados de rendimiento que se obtienen, por lo que se ha incluido en la denicin de los diferentes perles de trco o a el estado de la red. Esta aportacin se ve reejada en la tesis en la denicin de mltio o u ples perles de trco que deben ser utilizados para obtener distinto tipo a de informacin de rendimiento en cada una de las pruebas resultantes del o anlisis. La ejecucin de la misma prueba con diferente perl de trco gea o a nerar unos resultados diferentes, con un signicado diferente en funcin de a o las caracter sticas de trco y de la red que dena el perl. a En conclusin, el anlisis de los factores de rendimiento de un protoo a colo o arquitectura de seguridad ha proporcionado informacin acerca de la o inuencia de los mecanismos de seguridad utilizados por los protocolos y arquitecturas de seguridad en el rendimiento, al tiempo que ha proporcio-

Cap tulo 9. Conclusiones

202

nado los medios para llevar a cabo mediciones exhaustivas en las que poder obtener toda la informacin de rendimiento que resulta interesante conocer. o

9.1.3.

Marco de anlisis y desarrollo para protocolos y ara quitecturas de seguridad

Otro de los objetivos denidos para esta tesis es el establecimiento de un marco de anlisis y desarrollo para protocolos y arquitecturas de seguria dad. Este objetivo se fundamenta en la necesidad de llevar a cabo estudios similares a los que se han llevado a cabo durante el desarrollo de esta tesis, aplicando la metodolog a otros protocolos o arquitecturas de seguridad, a y amplindola en caso necesario. Dado que en la presente tesis se han llea vado a cabo anlisis y desarrollos que operan con los propios fundamentos a de los aspectos que se desea evaluar, la reutilizacin de dicho trabajo en o estudios futuros es una posibilidad que permitir concentrar esfuerzos en las a caracter sticas distintivas. En la presente tesis el marco de anlisis y desarrollo se ha visto refrena dado por dos tipos de aportaciones: Por un lado, los anlisis de los factores de conformidad y rendimiena to que se han llevado a cabo tienen su fundamento en el anlisis de a protocolos y soluciones concretas, anlisis del que posteriormente se a extrapolan los factores que son comunes a la mayor de protocolos y a arquitecturas de seguridad. Esta extrapolacin permite que cualquier anlisis similar que se quiera o a llevar a cabo de una solucin de seguridad particular pueda partir de o la generalizacin llevada a cabo, con el consiguiente ahorro de tiempo o y esfuerzo. Por otro lado, las implementaciones desarrolladas en esta tesis han proporcionado un conjunto de librer de desarrollo en las que se pueden as encontrar los mtodos de medicin denidos en la metodolog que e o a, han sido independizados de los procesos de generacin de mensajes y o establecimiento de tneles propios de IPsec. Cualquier otra propuesta u que se base en estos mtodos de captura de la informacin requerida e o podr utilizar dichas librer de desarrollo para evitar la duplicacin a as o de esfuerzos. Asimismo, dichas librer podrn ser actualizadas y meas a joradas segn sea necesario. u Como vemos, el marco de anlisis y desarrollo para protocolos de segua ridad ha sido establecido, y las primeras aportaciones a dicho marco se han producido, tanto en el mbito del anlisis de los protocolos y arquitecturas a a de seguridad como en el desarrollo de herramientas para llevar a cabo los anlisis propuestos. a

203

9.1. Aportaciones de la tesis

9.1.4.

Metodolog de validacin y evaluacin remota de ima o o plementaciones de protocolos de seguridad

El desarrollo de una metodolog de validacin y evaluacin que, a partir a o o de los resultados de los anlisis de conformidad y rendimiento obtenidos a anteriormente, permitiera llevar a cabo un estudio en profundidad acerca de las capacidades de interoperatividad y rendimiento de las implementaciones de protocolos de seguridad representa la principal aportacin de esta tesis. o Como hemos comentado, la metodolog se basa en los anlisis de faca a tores de conformidad y de rendimiento llevados a cabo anteriormente, y de hecho utiliza sus resultados como base sobre la que denir el conjunto de l neas de actuacin que conforman de la metodolog A partir de los estudios o a: acerca de los mtodos idneos para llevar a cabo mediciones sobre cada uno e o de los aspectos concretos que se desean evaluar, tanto en relacin con el reno dimiento como en relacin con la conformidad, se describen los pasos a dar o para generar conjuntos de pruebas que permitan la validacin y evaluacin o o de implementaciones de un protocolo o arquitectura de seguridad. Sin embargo, la metodolog no generar unicamente conjuntos de pruea a bas a llevar a cabo, sino que aspectos tales como los mecanismos para realizar las medidas, la interpretacin de los resultados obtenidos en cada una de las o pruebas y la inclusin de caracter o sticas que sin ser obligatorias son necesarias para utilizar el protocolo o arquitectura de seguridad son tambin e denidos y especicados a partir de la metodolog a. Todos estos factores hacen que la metodolog propuesta genere cona juntos exhaustivo de pruebas que permitan obtener informacin pormenoo rizada acerca de la conformidad de una implementacin con el estndar o a correspondiente, as como conocer las capacidades de rendimiento que dicha implementacin puede ofrecer. o

9.1.5.

Aplicacin de la metodolog a la arquitectura IPsec o a

La aplicacin de la metodolog de validacin y evaluacin remota de o a o o implementaciones de protocolos de seguridad a la arquitectura IPsec ha generado un conjunto de pruebas que, diseadas a partir de las gu y actuan as ciones denidas en la metodolog llevan a cabo una completa validacin a, o de la conformidad con el estndar y evaluacin del rendimiento. En este dea o sarrollo del conjunto de pruebas las aportaciones pueden clasicarse en tres tipos diferentes: Los conjuntos de pruebas en s mismos Los mtodos de de evaluacin y recogida de informacin e o o Los perles de trco denidos a

Cap tulo 9. Conclusiones

204

En cuanto a los conjuntos de pruebas a llevar a cabo para cada uno de los factores de conformidad y rendimiento que es necesario evaluar, el conjunto de pruebas se estructura de la siguiente forma: Conformidad con el estndar a Conformidad criptogrca a Conformidad de los protocolos Conformidad de los mecanismos de autenticacin o Conformidad de los mecanismos de gestin de claves o Conformidad de otras herramientas y mecanismos Rendimiento Ancho de banda Mximo nmero de asociaciones de seguridad simultneas a u a Capacidad de establecimiento de asociaciones de seguridad Tiempo de proceso Cada una de estas categor consta de pruebas que han surgido del as anlisis de las caracter a sticas de la arquitectura de seguridad IPsec, estando diseadas para obtener la informacin necesaria de forma eciente a la n o par que ecaz. Parte de esta ecacia viene dada por los mtodos de evaluae cin y recogida de la informacin propuestos, que han permitido adaptar o o cada prueba a las particularidades de IPsec, al tiempo que se optimizan los recursos necesarios para obtener la informacin deseada. o Por ultimo, algunos de los perles de trco que se han denido permi a ten obtener informacin acerca del rendimiento mximo que puede ofrecer la o a implementacin, lo que nos permitir comparar diferentes implementaciones o a entre ellas, mientras que otros de los perles nos proporcionan informacin o concerniente al rendimiento de la implementacin en condiciones de la red o y de tipo de trco a proteger concretas. a

9.1.6.

Plataforma de validacin y evaluacin remota de imo o plementaciones de IPsec

Los desarrollos que se han llevado a cabo durante las diferentes fases de la presente tesis se han dividido en dos grupos claramente diferenciados: las implementaciones atmicas y la plataforma de validacin y evaluacin o o o remota. Las implementaciones atmicas son desarrollos especializados que, cono centrndose en una prueba concreta del conjunto generado a partir de la a metodolog permiten la ejecucin de dicha prueba en unas condiciones a, o

205

9.1. Aportaciones de la tesis

concretas, obteniendo la informacin que se hab denido como objetivo de o a la prueba. Estas pruebas atmicas han servido como evaluacin de los procesos de o o anlisis llevados a cabo, ya que las pruebas atmicas implementan los mtoa o e dos de medicin y captura de datos descritos en dichos procesos. Asimismo, o las pruebas atmicas han permitido comprobar la completitud de la metoo dolog a la hora de generar conjuntos de pruebas y mtodos de evaluacin. a e o En el caso de que alguno de los mtodos propuestos no fuese vlido para obe a tener informacin al aplicarse a una situacin real, el desarrollo de la prueba o o atmica nos permitir detectar esta situacin, facilitando la correccin del o a o o error. Por otro lado, las pruebas atmicas tambin han permitido conocer o e problemas adicionales que deben afrontar las implementaciones de la metodolog y que, por lo tanto, sern aplicables a la plataforma de validacin a, a o y evaluacin remota. Estos problemas y condiciones que es necesario supeo rar vienen dados tambin por el anlisis de las diferencias entre la implee a mentacin de las pruebas atmicas y la plataforma de evaluacin y validao o o cin remota. Este estudio nos presenta nuevos requisitos y restricciones que o ser necesario tener en cuenta al implementar la plataforma, y que ya se han a tenido en cuenta a la hora de disear la plataforma. n Sin embargo, todas estas funciones desarrolladas por las pruebas atmio cas no deben dejar de lado uno de los aspectos ms importantes: las pruea bas atmicas son desarrollos perfectamente funcionales de la metodolog o a propuesta, y como tales permiten obtener informacin vlida acerca de la o a conformidad con el estndar y el rendimiento de una implementacin IPsec. a o En cuanto a la plataforma de validacin y evaluacin remota, se han o o llevado a cabo numerosos anlisis acerca de los nuevos retos que se presena tarn para desarrollar el conjunto de pruebas resultante de la aplicacin de a o la metodolog a la arquitectura IPsec, proponindose soluciones a dichos a e problemas que servirn para minimizar el impacto de dichos retos en la a utilidad de la plataforma. Por lo tanto, podemos ver cmo los diferentes desarrollos que han surgio do en esta tesis orientados a la plataforma de validacin y evaluacin remota, o o no slo han servido para validar los anlisis llevados a cabo anteriormente, o a sino que han permitido llevar a cabo un primer anlisis de los requisitos y a particularidades de las implementaciones que ha facilitado el diseo nal y n el desarrollo de la plataforma. Adicionalmente, estos desarrollos han proporcionado un conjunto de pruebas que abarcan todo el conjunto de pruebas propuesto, siendo capaces de ofrecer informacin acerca de todos los aspectos o que se denen en la misma. Adicionalmente, la utilizacin de la plataforma en varios proyectos de o investigacin ha servido como evaluacin de la utilidad de la misma, as como o o

Cap tulo 9. Conclusiones

206

del inters existente en la industria actualmente por este tipo de herramiene tas. Por otro lado, el inters de miembros de la comunidad cient e ca internacional por dicha plataforma y por la metodolog en s misma servir para a a evitar el estancamiento del trabajo realizado.

9.2.

Futuras L neas de Investigacin o

Para nalizar, en esta seccin se analizarn futuras l o a neas de investigacin que surgen a partir de esta tesis doctoral, realizando un pequeo o n anlisis acerca de cada una de estas l a neas.

9.2.1.

Aplicacin a otros protocolos y arquitecturas de seguo ridad

Una primera l nea de investigacin que surge es la aplicacin de la meo o todolog a otros protocolos y arquitecturas de seguridad. Esta aplicacin a o nos permitir obtener conjuntos de pruebas que lleven a cabo los diferentes a anlisis de conformidad y rendimiento a implementaciones de mltiples proa u tocolos y arquitecturas, lo que tendr una doble aportacin. Por un lado, a o se podr contar con un conjunto de pruebas adaptado a cada protocolo y a arquitectura, que, unido a los mtodos de medicin de informacin y cape o o tura de resultados nos permitir contar con una recopilacin de pruebas y a o mtodos que servirn de base a muchos desarrollos futuros. e a Por otro lado, al disponer de dicha recopilacin de pruebas y mtodos o e ser posible llevar a cabo un estudio acerca de las particularidades de cada a protocolo y arquitectura de seguridad, partiendo de las caracter sticas reejadas en los conjuntos de pruebas. Este anlisis servir de retroalimentacin a a o para los conjuntos de pruebas, que pueden beneciarse de los resultados que se obtengan. Una segunda fase de esta aplicacin a otros protocolos y arquitectuo ras de seguridad nos permitir comparar tanto los protocolos en s mismos a (cules ofrecen mayores problemas de compatibilidad, cules ofrecen maa a yor rendimiento), como cada uno de los componentes de seguridad de los que constan (mecanismos de autenticacin, sistemas de gestin de claves, o o etc. . . .). Por ultimo la validacin y evaluacin de mltiples implementaciones o o u de diferentes protocolos de seguridad utilizando los conjuntos de pruebas que se generen nos permitirn llevar a cabo el anlisis y comparacin de a a o la conformidad y el rendimiento en mltiples implementaciones, incluyendo u aquellas en dispositivos mviles o reducidos, que puedan presentar mayores o limitaciones computacionales. De esta forma ser posible llevar a cabo una a comparativa que permita escoger entre aquellos protocolos y arquitecturas

207

9.2. Futuras L neas de Investigacin o

de seguridad que mejor se adapten a nuestras necesidades.

9.2.2.

Integracin de la plataforma con otras herramientas o

Otra l nea de investigacin que surge a partir de las aportaciones de la o presente tesis es la integracin de la plataforma de validacin y evaluacin o o o remota con otras herramientas de gestin de la seguridad. Estas herramieno tas pueden ser otras metodolog de evaluacin de la seguridad o incluso as o mdulos de anlisis de vulnerabilidades como los que se han analizado en el o a apartado 2.2.3 de esta tesis. Otro aspecto de la integracin de la plataforma con herramientas de o gestin es el uso de mecanismos de conguracin y gestin centralizada o o o de los dispositivos de seguridad existentes en la red (como el propuesto para los dispositivos de redes privadas virtuales en [145]). Esta integracin o permitir que las conguraciones recomendadas obtenidas de la plataforma a sean directamente procesadas, traducidas al lenguaje de conguracin de la o implementacin, e instaladas remotamente en los dispositivos en cuestin. o o Al llevar a cabo algunas de estas integraciones es posible que surja la necesidad de aunar el diseo de las pruebas en la metodolog especialmente n a, si dichas pruebas tambin surgen a partir de metodolog de anlisis de la e as a seguridad. En este caso, ser posible llegar a ampliar la metodolog (y por a a extensin, los conjuntos de pruebas y la plataforma), incorporndose mduo a o los a medida que sea necesario (como puede verse en la Figura 9.1). Esto es posible ya que la metodolog contempla la posibilidad de llevar a cabo a anlisis espec a cos independientes, o integrados en conjuntos de pruebas que abarquen todas las reas. a

9.2.3.

Interpretacin de los informes o

Una tercera l nea de investigacin que surge a partir de este proyeco to es la de implementar mecanismos que permitan interpretar los informes generados por la plataforma, de forma que no se presenten unicamente los resultados de la realizacin de cada una de las pruebas. Algunos tipos de o interpretacin que pueden desarrollarse son los siguientes: o Para las pruebas de conformidad, relacin con el estndar, descripcin o a o del resultado esperado y del obtenido. Explicacin de los resultados o fallidos ms comunes. a Interpretacin de los resultados de conformidad: qu signican los o e resultados obtenidos? Relacin con los resultados obtenidos por otras implementaciones del o protocolo o arquitectura de seguridad: con qu implementaciones y e en qu condiciones puede interoperar la implementacin evaluada? e o

Cap tulo 9. Conclusiones

208

Figura 9.1: Posible diseo de la metodolog al integrar el anlisis de vulnen a a rabilidades

Comparacin del rendimiento ofrecido por la implementacin que es o o objeto del anlisis con respecto a otras implementaciones analizadas a anteriormente.

Esta interpretacin tendr un punto clave en la elaboracin de gu o a o as de conguracin que optimicen la utilizacin de la implementacin en funo o o cin de los resultados de conformidad y rendimiento obtenidos. Estas gu o as resolver preguntas como Con qu conguracin puedo establecer canales an e o seguros con una mayor cantidad de implementaciones, al tiempo que maximizo mi rendimiento?. En una fase posterior, las gu de conguracin podr generarse as o an dinmicamente, de forma que a medida que se introducen parmetros acerca a a de la infraestructura en la que dicha implementacin debe operar, y otros o requisitos de seguridad, rendimiento e interoperabilidad, se generen conguraciones de la implementacin que permitan llevar a cabo la labor de o proteccin de la informacin en el entorno que se describe. o o Llegados a este punto, y si se ha conseguido la integracin con herrao mientas de gestin y conguracin que se ha mencionado en el apartado o o anterior, ser posible generar cheros de conguracin que se enviar a a o an las propias implementaciones, instalndose remotamente y preparando la a implementacin para operar bajo dicha conguracin. o o

209

9.2. Futuras L neas de Investigacin o

9.2.4.

Estandarizacin de la metodolog o a

Por ultimo, un objetivo a largo plazo ser la estandarizacin de la meto a o dolog y de los conjuntos de pruebas que se generen a partir de ella a travs a e de algn organismo de estandarizacin. Como se coment en los cap u o o tulos 1 y 2, en los ultimos aos el IETF ha procedido a estandarizar conjuntos de n pruebas que permitan evaluar el rendimiento de diversos dispositivos de red. Por su parte, ISO e ITU-T cuentan con metodolog de anlisis formales as a de la conformidad en sistemas abiertos, lo que indica que el inters de estos e organismos por estas metodolog existe. as La estandarizacin, tanto de la metodolog como de los conjuntos de o a pruebas que se generan al aplicarla a protocolos de seguridad concretos, permitir responder a la llamada de la Unin Europea en el VII Programa a o Marco, proporcionando mtodos, herramientas y mecanismos para facilitar e la interoperabilidad entre sistemas de informacin e identicar aquellos proo blemas potenciales que puedan darse. Adicionalmente, la aplicacin de la metodolog a protocolos y arquio a tecturas de seguridad podr incluirse en el proceso de diseo y estandaa n rizacin de nuevos protocolos, de tal forma que junto con la especicacin o o del protocolo se publiquen conjuntos de pruebas espec cas que permitan a los desarrolladores y usuarios conocer si las implementaciones que tienen disponibles son conformes al estndar o no. a

Cap tulo 9. Conclusiones

210

Bibliograf a
[1] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz. Extensible authentication protocol (eap). Request For Comments RFC 3748, Internet Engineering Task Force, 2004. [2] C. Adams. The cast-128 encryption algorithm. Request For Comments RFC 2144, Internet Engineering Task Force, 1997. [3] C. Adams and J. Gilchrist. The cast-256 encryption algorithm. Request For Comments RFC 2612, Internet Engineering Task Force, 1999. [4] C. Alberts and A. Dorofee. OctaveSM criteria. Technical Report CMU/SEI-2001-TR-016, ESC-TR-2001-016, National Institute of Standards and Technology, 2001. [5] K. Anagnostakis, M. Greenwald, S. Ioannidis, A. Keromytis, and D. Li. A cooperative immunization system for an untrusting internet, 2003. [6] R. J. Anderson. Security Engineering: A Guide to Building Dependable Distributed Systems. John Wiley & Sons, Inc., New York, NY, USA, 2001. [7] G. Apostolopoulos, V. Peris, P. Pradhan, and D. Saha. Securing electronic commerce: reducing the SSL overhead. IEEE Network, 14(4):8 16, July 2000. [8] G. Apostolopoulos, V. G. J. Peris, and D. Saha. Transport layer security: How much does it really cost? In INFOCOM, pages 717725, 1999. [9] R. Atkinson. Authentication header. Request For Comments RFC 1826, Internet Engineering Task Force, 1995. [10] R. Atkinson. Ip encapsulating security payload (esp). Request For Comments RFC 1827, Internet Engineering Task Force, 1995. [11] R. Atkinson. Security architecture for the internet protocol. Request For Comments RFC 1825, Internet Engineering Task Force, 1995. 211

BIBLIOGRAF IA

212

[12] A. Balachandran, G. M. Voelker, P. Bahl, and P. Venkat Rangan. Characterizing user behavior and network performance in a public wireless lan. In SIGMETRICS, pages 195205. ACM, 2002. [13] G. Bartolomeo, F. Berger, H. J. Eikerling, F. Martire, and S. Salsano. Handling user proles for the secure and convenient conguration and management of mobile terminals and services. In DEXA Workshops, pages 272277. IEEE Computer Society, 2005. [14] J. Beale. Bastille linux hardening program, 2006. [15] H. Berkowitz, E. Davies, S. Hares, P. Krishnaswamy, and M. Lepp. Terminology for benchmarking bgp device convergence in the control plane. Request For Comments RFC 4098, Internet Engineering Task Force, 2005. [16] V. Berzins. Software Engineering with Abstractions. Addison-Wesley Professional, Reading, MA, rst edition, July 1991. [17] O. Billet, H. Gilbert, and C. Ech-Chatbi. Cryptanalysis of a white box aes implementation. In H. Handschuh and M. Anwar Hasan, editors, Selected Areas in Cryptography, volume 3357 of Lecture Notes in Computer Science, pages 227240. Springer, 2004. [18] M. Bishop. The Art and Science of Computer Security. AddisonWesley, Reading, Massachusetts, rst edition, December 2001. [19] S. Bradner and J. McQuaid. Benchmarking methodology for network interconnect devices. Request For Comments RFC 2544, Internet Engineering Task Force, 1999. [20] Sonja Buchegger and Jean-Yves Le Boudec. Performance analysis of the condant protocol. In MobiHoc, pages 226236. ACM, 2002. [21] OpenS/WAN bug tracking software. Opens/wan without nat-t crashes on nat-t conn, 2005. [22] J. R. Burch, E. M. Clarke, and D. E. Long. Symbolic model checking with partitioned transistion relations. In VLSI, pages 4958, 1991. [23] C. W. Burrell. A methodology for planning and executing custom benchmarks. In Int. CMG Conference, pages 363372. Computer Measurement Group, 1997. [24] M. Burrows, M. Abadi, and R. M. Needham. A logic of authentication. ACM Trans. Comput. Syst., 8(1):1836, 1990. [25] Ed C. Kaufman. Internet key exchange (ikev2) protocol. Request For Comments RFC 4306, Internet Engineering Task Force, 2005.

213

BIBLIOGRAF IA

[26] M. Castelino and F. Hady. Tutorial on npfs ipsec forwarding benchmark. Embedded.com, October 2004. [27] CERT Coordination Center. Unix conguration guidelines, 2006. [28] CERT Coordination Center. Windows nt conguration guidelines, 2006. [29] CERT. Multiple implementations of the radius protocol contain a digest calculation buer overow. Vulnerability Note VU#589523, US Computer Emergency Response Team, 2002. http://www.kb.cert.org/vuls/id/589523. [30] CERT. Multiple implementations of the radius protocol do not adequately validate the vendor-length of the vendor-specic attributes. Vulnerability Note VU#936683, US Computer Emergency Response Team, 2002. http://www.kb.cert.org/vuls/id/936683. [31] CERT. Multiple vendors ssh transport layer protocol implementations contain vulnerabilities in key exchange and initialization. Vulnerability Note VU#389665, US Computer Emergency Response Team, 2002. http://www.kb.cert.org/vuls/id/389665. [32] CERT. Multiple vulnerabilities in ssl/tls implementations. Vulnerability Note VU#104280, US Computer Emergency Response Team, 2003. http://www.kb.cert.org/vuls/id/104280. [33] CERT. Check point isakmp vulnerable to buer overow via certicate request. Vulnerability Note VU#873334, US Computer Emergency Response Team, 2004. http://www.kb.cert.org/vuls/id/873334. [34] CERT. Ieee 802.11 wireless network protocol dsss cca algorithm vulnerable to denial of service. Vulnerability Note VU#106678, US Computer Emergency Response Team, 2005. http://www.kb.cert.org/vuls/id/106678. [35] S. Chow, P. A. Eisen, H. Johnson, and P. C. van Oorschot. White-box cryptography and an aes implementation. In K. Nyberg and H. M. Heys, editors, Selected Areas in Cryptography, volume 2595 of Lecture Notes in Computer Science, pages 250270. Springer, 2002. [36] Information Technology Committee. Information technology framework formal methods in conformance testing. ISO/IEC standard ISO/IEC 13245, International Organization for Standardization, 1995. [37] Information Technology Committee. Information technology open systems interconnection conformance testing methodology and framework. ISO/IEC standard ISO/IEC 9646, International Organization for Standardization, 1995.

BIBLIOGRAF IA

214

[38] Information Technology Committee. Information technology open systems interconnection lower layers security model. ISO/IEC standard ISO/IEC 13594, International Organization for Standardization, 1995. [39] Information Technology Committee. Information technology open systems interconnection network layer security protocol. ISO/IEC standard ISO/IEC 11577, International Organization for Standardization, 1995. [40] Information Technology Committee. Information technology open systems interconnection upper layers security model. ISO/IEC standard ISO/IEC 10745, International Organization for Standardization, 1995. [41] Information Technology Committee. Information technology security techniques key management. ISO/IEC standard ISO/IEC 11770, International Organization for Standardization, 1995. [42] Information Technology Committee. Information technology open systems interconnection security frameworks for open systems. ISO/IEC standard ISO/IEC 10181, International Organization for Standardization, 1997. [43] LAN/MAN Standards Committee. Ieee standard for information technology - telecommunications and information exchange between systems - local and metropolitan area networks - specic requirements part 11: Wireless lan medium access control (mac) and physical layer (phy) specications amendment 2: Higher-speed physical layer (phy) extension in the 2.4 ghz band corrigendum 1. IEEE Standard for Information Technology 802.11b, IEEE Computer Society, 2001. [44] LAN/MAN Standards Committee. Ieee standard for information technology - telecommunications and information exchange between systems - local and metropolitan area networks - specic requirements part 11: Wireless lan medium access control (mac) and physical layer (phy) specications amendment 6: Medium access control (mac) security enhancements. IEEE Standard for Information Technology 802.11i, IEEE Computer Society, 2004. [45] VPN Consortium. Vpnc testing for interoperability. Interoperatibility tests results, VPN Consortium, 2004. [46] R. deGraaf, J. Aycock, and M. J. Jacobson Jr. Improved port knocking with strong authentication. In ACSAC, pages 451462. IEEE Computer Society, 2005.

215

BIBLIOGRAF IA

[47] L. Deri. Network top (ntop). Recurso Electrnico o http://www.ntop.org, Centro Serra of the University of Pisa, 2005. [48] T. Dierks and C. Allen. The transport layer security (tls) protocol version 1.1. Request For Comments RFC 2246, Internet Engineering Task Force, 1999. [49] T. Dierks and E. Rescorla. The transport layer security (tls) protocol version 1.1. Request For Comments RFC 4346, Internet Engineering Task Force, 2006. [50] Hans Dobbertin, Antoon Bosselaers, and Bart Preneel. Ripemd-160: A strengthened version of ripemd. In Dieter Gollmann, editor, Fast Software Encryption, volume 1039 of Lecture Notes in Computer Science, pages 7182. Springer, 1996. [51] J. J. Dujmovic, R. E. Kinicki, and S. Subbanna. Network benchmarking using distributed client/server pairs. In Int. CMG Conference, pages 183194. Computer Measurement Group, 1995. [52] J. J. Dujmovic, R. E. Kinicki, and S. Subbanna. A distributed client/server benchmark for network performance measurement. Informatica (Slovenia), 20(1), 1996. [53] J. J. Dujmovic and H. Lew. A method for generating benchmark programs. In Int. CMG Conference, pages 379388. Computer Measurement Group, 2000. [54] D. Eastlake. Cryptographic algorithm implementation requirements for encapsulating security payload (esp) and authentication header (ah). Request For Comments RFC 4305, Internet Engineering Task Force, 2005. [55] International Organization for Standardization. Information technology open distributed processing unied modeling language (uml) version 1.4.2. Standard 19501:2005, International Organization for Standardization, 2005. [56] WAP Forum. Wireless application protocol architecture specication. Protocol Specication WAP-210-WAPArch-20010712, Wireless Application Protocol Forum, 2001. [57] WAP Forum. Wireless transport layer security. Protocol Specication WAP-261-WTLS-20010406-a, Wireless Application Protocol Forum, 2001.

BIBLIOGRAF IA

216

[58] A. Freier, P. Karlton, and P. Kocher. The ssl protocol version 3.0. Internet Draft 3.0, Netscape Communications, 1996. [59] J. J. Garrett. Ajax: A new approach to web applications, 2005. [60] R. Glenn and S. Kent. The null encryption algorithm and its use with ipsec. Request For Comments RFC 2410, Internet Engineering Task Force, 1998. [61] T. J. Hacker, B. D. Athey, and B. Noble. The end-to-end performance eects of parallel tcp sockets on a lossy wide-area network. In IPDPS. IEEE Computer Society, 2002. [62] A. Haley and S. H. Zweben. Development and application of a white box approach to integration testing. Journal of Systems and Software, 4(4):309315, 1984. [63] A. Harbitter and D. A. Menasc. Performance of public-key-enabled e kerberos authentication in large networks. In IEEE Symposium on Security and Privacy, pages 170183, 2001. [64] A. Harbitter and D. A. Menasc. The performance of public keye enabled kerberos authentication in mobile computing applications. In ACM Conference on Computer and Communications Security, pages 7885, 2001. [65] D. Harkins and D. Carrel. The internet key exchange (ike). Request For Comments RFC 2409, Internet Engineering Task Force, 1998. [66] R. Hefner. Lessons learned with the systems security engineering capability maturity model. In ICSE, pages 566567, 1997. [67] R. Hefner. A process standard for system security engineering: Development experiences and pilot results. In ISESS 97: Proceedings of the 3rd International Software Engineering Standards Symposium (ISESS 97), page 217, Washington, DC, USA, 1997. IEEE Computer Society. [68] P. Herzog. Open-source security testing methodology manual. Special Publication 2.1.1, Institute for Security and Open Methodologies, 2005. [69] B. Hickman, D. Newman, S. Tadjudin, and T. Martin. Benchmarking methodology for rewall performance. Request For Comments RFC 3511, Internet Engineering Task Force, 2003. [70] P. Homan. Cryptographic suites for ipsec. Request For Comments RFC 4308, Internet Engineering Task Force, 2005.

217

BIBLIOGRAF IA

[71] R. Housley. Using advanced encryption standard (aes) ccm mode with ipsec encapsulating security payload (esp). Request For Comments RFC 4309, Internet Engineering Task Force, 2005. [72] R. Housley, W. Polk, W. Ford, and D. Solo. Internet x.509 public key infrastructure certicate and certicate revocation list (crl) prole. Request For Comments RFC 3280, Internet Engineering Task Force, 2002. [73] C. Hsu and U. Kremer. IPERF: A framework for automatic construction of performance prediction models. In Workshop on Prole and Feedback-Directed Compilation (PFDC), 1998. [74] M. Huth and M. Ryan. Logic in Computer Science : Modelling and Reasoning about Systems. Cambridge University Press, Cambridge UK, second edition, August 2004. [75] International Systems Security Engineering Association (ISSEA). Systems security engineering capability maturity model sse-cmm model description document. Technical Report version 3.0, International Systems Security Engineering Association (ISSEA), 2003. [76] ITU-T. Information technology - open systems interconnection - upper layers security model. ITU-T Recommendation X,803, Internet Telecommunication Union, 1994. [77] ITU-T. Information technology - lower layers security model. ITU-T Recommendation X,802, Internet Telecommunication Union, 1995. [78] ITU-T. Information technology - open systems interconnection - security frameworks for open systems: Overview. ITU-T Recommendation X,810, Internet Telecommunication Union, 1995. [79] A. Izquierdo, J. Torres, J. M. Estvez, and J. C. Hernndez. Attacks e a on port knocking authentication mechanism. In O. Gervasi, M. L. Gavrilova, V. Kumar, A. Lagan`, H. Pueh Lee, Y. Mun, D. Taniar, a and C. Jeng Kenneth Tan, editors, ICCSA (4), volume 3483 of Lecture Notes in Computer Science, pages 12921300. Springer, 2005. [80] G. P. Java. Iptraf - ip network monitoring software, 2005. [81] R. Jones. Netperf: A network performance benchmark. White Paper Revision 2.1, Hewlett Packard, 1995. [82] S. Kalidindi and E. Stewart. Ipsec virtual private networks: Conformance and performance testing. White paper, Ixia, 2003.

BIBLIOGRAF IA

218

[83] P. Karn, P. Metzger, and W. Simpson. The esp des-cbc transform. Request For Comments RFC 1829, Internet Engineering Task Force, 1995. [84] Vikas Kawadia and P. R. Kumar. Experimental investigations into tcp performance over wireless multihop networks. In E-WIND 05: Proceeding of the 2005 ACM SIGCOMM workshop on Experimental approaches to wireless network design and analysis, pages 2934, New York, NY, USA, 2005. ACM Press. [85] S. Kent. Extended sequence number (esn) addendum to ipsec domain of interpretation (doi) for internet security association and key management protocol (isakmp). Request For Comments RFC 4304, Internet Engineering Task Force, 2005. [86] S. Kent. Ip authentication header. Request For Comments RFC 4302, Internet Engineering Task Force, 2005. [87] S. Kent. Ip encapsulating security payload (esp). Request For Comments RFC 4303, Internet Engineering Task Force, 2005. [88] S. Kent and R. Atkinson. Ip authentication header. Request For Comments RFC 2402, Internet Engineering Task Force, 1998. [89] S. Kent and R. Atkinson. Ip encapsulating security payload (esp). Request For Comments RFC 2406, Internet Engineering Task Force, 1998. [90] S. Kent and R. Atkinson. Security architecture for the internet protocol. Request For Comments RFC 2401, Internet Engineering Task Force, 1998. [91] S. Kent and K. Seo. Security architecture for the internet protocol. Request For Comments RFC 4301, Internet Engineering Task Force, 2005. [92] T. Kivinen, B. Swander, A. Huttunen, and V. Volpe. Negotiation of nat-traversal in the ike. Request For Comments RFC 3947, Internet Engineering Task Force, 2005. [93] D. Konz. A white box look at the performance of 802.11 wireless and its variants. In Int. CMG Conference, pages 285302. Computer Measurement Group, 2004. [94] M. Krzywinski. Port knocking: Network authentication across closed ports. SysAdmin Magazine, 12:1217, 2003.

219

BIBLIOGRAF IA

[95] R. Kuhn, T. J. Walsh, and S. Fries. Security considerations for voice over ip systems. Recommendation Guide 800-58, National Institute of Standards and Technology, 2005. [96] B. K. Lee and L. K. John. Npbench: A benchmark suite for control plane and data plane applications for network processors. In ICCD, pages 226233. IEEE Computer Society, 2003. [97] C. A. Lee, J. Stepanek, R. Wolski, C. Kesselman, and I. Foster. A network performance tool for grid environments. In Supercomputing 99: Proceedings of the 1999 ACM/IEEE conference on Supercomputing (CDROM), page 4, New York, NY, USA, 1999. ACM Press. [98] H. E. Link and W. D. Neumann. Clarifying obfuscation: Improving the security of white-box des. In ITCC (1), pages 679684. IEEE Computer Society, 2005. [99] Linux FreeS/WAN mailing list. Linux frees/wan compatibility guide. Interoperatibility tests results, Linux FreeS/WAN mailing list, 2004. [100] V. Manral, R. White, and A. Shaikh. Ospf benchmarking terminology and concepts. Request For Comments RFC 4062, Internet Engineering Task Force, 2005. [101] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet security association and key management protocol (isakmp). Request For Comments RFC 2408, Internet Engineering Task Force, 1998. [102] G. Memik, W. H. Mangione-Smith, and W. Hu. Netbench: A benchmarking suite for network processors. In ICCAD, pages 39, 2001. [103] P. Metzger and W. Simpson. Ip authentication using keyed md5. Request For Comments RFC 1828, Internet Engineering Task Force, 1995. [104] S. Miltchev, S. Ioannidis, and A. D. Keromytis. A study of the relative costs of network security protocols. In C. G. Demetriou, editor, USENIX Annual Technical Conference, FREENIX Track, pages 41 48. USENIX, 2002. [105] M. Minow. Minicomputer timesharing performance and usability. SIGMINI Newsl., 4(3):416, 1978. [106] NCSA. Ncsa mosaic history, 2000. [107] C. Neuman, T. Yu, S. Hartman, and K. Raeburn. The kerberos network authentication service (v5). Request For Comments RFC 4120, Internet Engineering Task Force, 2005.

BIBLIOGRAF IA

220

[108] P. Neumann. Computer-Related Risks. Addison-Wesley Professional, Reading, MA, rst edition, October 1994. [109] P. G. Neumann, R. J. Feiertag, K. N. Levitt, and L. Robinson. Software development and proofs of multi-level security. In ICSE, pages 421428, 1976. [110] NIST. Automated password generator. Federal Information Processing Standard 181, National Institute of Standards and Technology, 1993. [111] NIST. Security requirements for cryptographic modules. Federal Information Processing Standard 140-1, National Institute of Standards and Technology, 1994. [112] NIST. The transport layer security (tls) protocol version 1.1. Federal Information Processing Standard 186-2, National Institute of Standards and Technology, 2000. [113] NIST. Advanced encryption standard. Federal Information Processing Standard 197, National Institute of Standards and Technology, 2001. [114] NIST. Security requirements for cryptographic modules. Federal Information Processing Standard 140-2, National Institute of Standards and Technology, 2001. [115] NIST. Automated security self-evaluation tool, 2004. [116] NIST. Secure hash standard (shs). Federal Information Processing Standard 180-2, National Institute of Standards and Technology, 2004. [117] NIST. National vulnerability database, 2006. [118] NSA. Gu de conguracin de la seguridad. Security Conguracion as o Guides-, National Security Agency, 2006. http://www.nsa.gov/snac/. [119] Department of Defense. Trusted computer system evaluation criteria (orange book). Department of Defense Standard DOD 5200.28-STD, National Institute of Standards and Technology, 1985. [120] National Institute of Standards and Technology. Ipsec web interoperability tester, 2000. [121] National Institute of Standards and Technology. Common criteria for information technology security evaluation, part 1: Introduction and general model. CCMB-2005-08-001 version 2.3, National Institute of Standards and Technology, 2003.

221

BIBLIOGRAF IA

[122] National Institute of Standards and Technology. Common criteria for information technology security evaluation, part 2: Security functional requirements. CCMB-2005-08-002 version 2.3, National Institute of Standards and Technology, 2003. [123] National Institute of Standards and Technology. Common criteria for information technology security evaluation, part 3: Security assurance requirements. CCMB-2005-08-003 version 2.3, National Institute of Standards and Technology, 2003. [124] National Institute of Standards and Technology. Nist net, 2005. [125] Commission of the European Communities. Information technology security evaluation criteria. Council Recommendation version 1.2, Commission of the European Communities, 1991. [126] Commission of the European Communities. i2010 a european information society for growth and employment. Technical report, Commission of the European Communities, 2005. [127] Field Security Operations. Security review methodology. Security Technical Implementation Guide Version 2 Release 1, Defense Information Systems Agency, 2005. [128] S. Owre, J. M. Rushby, and N. Shankar. Pvs: A prototype verication system. In D. Kapur, editor, CADE, volume 607 of Lecture Notes in Computer Science, pages 748752. Springer, 1992. [129] S. Peeger. Software Engineering: The Production of Quality Software. Macmillan Publishing Company, New York, USA, second edition, March 1991. [130] J. Postel. Internet control message protocol. Request For Comments RFC 792, Internet Engineering Task Force, 1981. [131] A. R. Prasad, P. Schoo, and H. Wang. An evolutionary approach towards ubiquitous communications: A security perspective. In SAINT Workshops, pages 689695. IEEE Computer Society, 2004. [132] K. Ramakrishnan, S. Floyd, and D. Black. The addition of explicit congestion notication (ecn) to ip. Request For Comments RFC 3168, Internet Engineering Task Force, 2001. [133] M. Richardson and D. H. Redelmeier. Opportunistic encryption using the internet key exchange (ike). Request For Comments RFC 4322, Internet Engineering Task Force, 2005. [134] R. Rivest. The md5 message-digest algorithm. Request For Comments RFC 1321, Internet Engineering Task Force, 1992.

BIBLIOGRAF IA

222

[135] M. Roughan, S. Sen, O. Spatscheck, and N. G. Dueld. Class-ofservice mapping for qos: a statistical signature-based approach to ip trac classication. In A. Lombardo and J. F. Kurose, editors, Internet Measurement Conference, pages 135148. ACM, 2004. [136] J. Schiller. Cryptographic algorithms for use in the internet key exchange version 2 (ikev2). Request For Comments RFC 4307, Internet Engineering Task Force, 2005. [137] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley & Sons, Inc., New York, NY, USA, 1995. [138] Bruce Schneier. Description of a new variable-length key, 64-bit block cipher (blowsh). In Ross J. Anderson, editor, Fast Software Encryption, volume 809 of Lecture Notes in Computer Science, pages 191204. Springer, 1993. [139] Tenable Network Security. Nessus vulnerability scanner, 2006. [140] A. Shacham, B. Monsour, R. Pereira, and M. Thomas. Ip payload compression protocol (ipcomp). Request For Comments RFC 3173, Internet Engineering Task Force, 2001. [141] Q. Snell, A. Mikler, and J. Gustafson. Netpipe: A network protocol independent performance evaluator, 1996. [142] JH. Song, R. Poovendran, J. Lee, and T. Iwata. The aes-cmac algorithm. Request For Comments RFC 4493, Internet Engineering Task Force, 2006. [143] M. Swanson. Security self-assessment guide for information technology systems. Special Publication 800-26, National Institute of Standards and Technologies, 2001. [144] Dyaptive Systems. Cdma network performance testing. White paper, Dyaptive Systems, 2003. [145] J. Snchez-Arvalo and J. M. Sierra. Sec-point : gestin segura de a e o pol ticas de interconexin. Proyecto de n de carrera, Universidad o Carlos III de Madrid, 2004. [146] Agilent Technologies. Validating ipsec network security devices. White Paper 598 9-1448EN, Agilent Technologies, 2004. [147] B. Todd. Security auditors research assistant, 2006. [148] M. Tsai, C. Kulkarni, C. Sauer, N. Shah, and K. Keutzer. A benchmarking methodology for network processors, 2002.

223

BIBLIOGRAF IA

[149] P. Wernick and M. M. Lehman. Software process white box modelling for feast/1. Journal of Systems and Software, 46(2-3):193201, 1999. [150] A. Whitten and J. D. Tygar. Usability of security: A case study. Computer Science Technical Report CMU-CS-98-155, Carnegie Mellon University, 1998. [151] T. Wolf and M. Franklin. Commbench a telecommunications benchmark for network processors, 2000. [152] A. K. Y. Wong, T. S. Dillon, W. W. K. Lin, and M. T. W. Ip. M2 rt: A tool developed for predicting the mean message response time of communication channels in sizeable networks exemplied by the internet. Computer Networks, 36(5/6):557577, 2001. [153] D. K. Y. Yau, J. C. S. Lui, F. Liang, and Y. Yam. Defending against distributed denial-of-service attacks with max-min fair server-centric router throttles. IEEE/ACM Trans. Netw., 13(1):2942, 2005. [154] T. Ylonen and C. Lonvick. The secure shell (ssh) transport layer protocol. Request For Comments RFC 4253, Internet Engineering Task Force, 2006. [155] J. Yu, L. Jou, A. Matthews, and V Srinivasan. Criteria for evaluating vpn implementation mechanisms. Internet Draft-, Internet Engineering Task Force, 2000. [156] J. K. Yun. Measuring network software performance. Dr. Dobbs Journal, 25(3):80, 8291, Mar 2000. [157] N. Ziring and S. Quinn. Specication for the extensible conguration checklist description format (xccdf) version 1.1.2. Interagency Report 7275, National Institute of Standards and Technologies, 2006.

BIBLIOGRAF IA

224