Protocolos de Seguridad en Redes

Transcripción

1 Protocolos de Seguridad en Redes Meleth 22 de julio de

2 1. Introducción Para asegurar que una comunicación a través de una red es segura tiene que cumplir cuatro requisitos [1] : 1.Autenticidad: Antes de comenzar la transacción todos los participantes deben estar perfectamente identificados 2.Confidencialidad: Los datos trasferidos sólo pueden ser leídos por el destinatario final 3.Integridad: Los datos enviados deben llegar al destinatario completos y sin modificaciones 4.No repudio: Debemos asegurar que una vez el destinatario ha recibidos los datos, este no puede negar haberlo hecho La autenticidad y la integridad de una comunicación se puede obtener mediante algoritmos de firma digital y hash. La confidencialidad se consigue utilizando métodos de cifrado que ocultan la información a los ojos de quien no debe verla Criptografía La Real Academia define la criptografía como el arte de escribir con clave secreta o de un modo enigmático.. La clave secreta utilizada es la que establece una distinción entre las dos clases principales de sistemas criptográficos utilizados en la actualidad: Criptografía de clave simétrica Criptografía de clave asimétrica La criptografía de clave simétrica utiliza la misma clave tanto para encriptar como para desencriptar. Obviamente los dos extremos de la comunicación necesitan la clave para poder intercambiar datos, lo cual presenta el problema de como hacer que los dos posean esta clave si el medio de transmisión es inseguro. La criptografía de clave asimétrica usa dos claves diferentes, una para encriptar el mensaje y otra para desencriptarlo. La clave utilizada para encriptar se denomina clave pública y es conocida por todo el mundo, de ahí su nombre. Además de esta clave pública existe otra denominada privada que sirve para desencriptar y que sólo conoce el destinatario de los datos. Es muy importante que conociendo la clave pública no sea posible calcular la clave Protocolos de Seguridad en Redes 2 Meleth

3 privada ya que entonces cualquiera podría leer datos que no iban dirigidos a él. Este tipo de algoritmos son mucho más costosos computacionalmente que los de clave simétrica, con lo cual lo que se suele hacer en muchos sistemas es intercambiar la clave simétrica que se va a usar en la sesión utilizando un algoritmo asimétrico de encriptación y a partir de ahí utilizar un algoritmo simétrico, mucho menos costoso, para el resto de la sesión Autentificación Tan importante como mantener los datos alejados de miradas indiscretas es asegurarse de que quien manda los datos es quien dice ser. Si pensamos en como nos identificamos habitualmente, veremos que en la mayoría de las ocasiones se nos piden dos cosas, el DNI expedido por el Ministerio del Interior y una firma que además figura en el DNI para poder comprobarlo. Obviamente este no es un método seguro al 100%, pero en la mayoría de las ocasiones si. En una red podemos pensar en utilizar el mismo mecanismo. Algún tipo de documento identificativo, expedido por alguien en quien confiemos, donde podamos ver la firma electrónica del poseedor del certificado y con el que además podamos comprobar que los datos firmados por él provienen efectivamente de esa fuente. El certificado digital usado en la actualidad es el recomendado por la Unión Internacional de Telecomunicaciones (ITU) que cumple el estándar X.509 v3. Estos certificados son expedidos por una Autoridad Certificadora de las cuales en la actualidad existen dos principales Verisign y Thawte Integridad Una vez obtenida la confianza en que la persona que esta al otro lado es con la que queremos establecer la comunicación comienza el intercambio de datos, que pueden ir cifrados o no. Vayan cifrados o no, debemos tener algún método para conocer si los datos han sido modificados durante el trayecto, bien por un error en la transmisión o bien porque alguien haya interceptado ese paquete y cambiado su contenido. La integridad se consigue mediante algoritmos de hash que obtienen un resumen del paquete dependiente de su contenido. Si el contenido del paquete cambia, el hash de ese paquete también cambiará, con lo cual calculando el hash del paquete en el receptor y comparándolo con el hash recibido, podemos saber si el paquete ha cambiado durante el trayecto. Existen multitud de algoritmos de hash como el MD5, el SHA, incluso existen otros basados en los métodos criptográficos simétricos descritos anteriormente. Estos métodos se basan en utilizar el modo CBC de encriptación como Protocolos de Seguridad en Redes 3 Meleth

4 un hash. En este modo lo que hace es coger el bloque a encriptar y hacer una operación (normalmente una XOR) entre él y el bloque cifrado anterior, con el cual el último bloque cifrado de los datos a mandar depende del contenido de todos los anteriores y puede ser utilizado como hash de los datos. Mención aparte merecen los métodos de firma digital. Anteriormente hemos hablado de los certificados X.509, estos certificados además de identificar al usuario sirven para firmar digitalmente datos de tal manera que sepamos inequívocamente que han sido enviados por el poseedor del certificado y que no han sido modificados durante la transmisión. El certificado para ello incluye una clave pública que el receptor de la información conoce. A partir de los datos a enviar se obtiene un hash como ya hemos hablado y se encripta con la llave privada del emisor. Cuando llegan los datos, desencriptamos el hash con la llave pública y lo comparamos con el que calculamos a partir de los datos que llegan. Si son iguales los datos son fiables. 2. Protocolos de seguridad en redes Existen multitud de estándares de seguridad para su uso en redes TCP/IP convencionales. En este trabajo vamos a ver brevemente los más extendidos y utilizados: IPSec SSL WEP SSH Es importante resaltar que cada uno de estos protocolos opera en un capa diferente del modelo OSI, IPSec da servicios de seguridad al protocolo IP en la capa de red, SSL se localiza entre la capa de transporte y la de aplicación, WEP da cobertura a la capa de enlace, mientras que SSH es una aplicación de shell remota segura que nos permite también hacer túneles para que otras aplicaciones puedan utilizar los mecanismos de seguridad que ofrece. Protocolos de Seguridad en Redes 4 Meleth

5 APLICACION SSH PRESENTACION SESION SSL TRANSPORTE RED IPSec ENLACE FISICA WEP 2.1. IPSec A la vez que Internet ha ido creciendo ha surgido la necesidad de dotarla de mecanismos que velen por la seguridad de los datos. Dado que IP versión 4 no implementa ningún estándar de seguridad, han aparecido multitud de soluciones propietarias para tratar de dotar de mecanismos de seguridad a estas redes. Obviamente el principal problema es la falta de interoperabilidad entre ellos que dificulta el intercambio de información. Para suplir esta carencia surgió IPSec apoyado en los estándares del IETF. IPSec es un conjunto de estándares para integrar en IP funciones de seguridad basadas en criptografía [2]. IPSec se puede integrar en IPv4 y se incluye por defecto en IPv6. Anteriormente se ha hablado de los cuatro aspectos que debe cumplir una comunicación para ser segura. A través de IPSec se consiguen servicios de autenticidad, confidencialidad e integridad. Dentro de IPSec se distinguen dos partes: Un protocolo de gestión de claves Internet Key Exchange (IKE), que se encarga de gestionar los intercambios de claves y el control de la conexión segura Dos protocolos de seguridad: IP Authentication Header (AH) IP Encapsulating Security Payload (ESP) que ofrecen servicios para proteger el tráfico IP El protocolo IKE El protocolo IKE tiene como función establecer una conexión cifrada y autentificada entre dos extremos. Para ello el protocolo negocia los parámetros que se utilizarán durante la conexión. Protocolos de Seguridad en Redes 5 Meleth

6 Esta negociación tiene dos fases: En la primera fase se estable el canal seguro y autentificado. Para ellos se usa un algoritmo de cifrado simétrico y un algoritmo de hash HMAC. El intercambio seguro de claves se realiza mediante un algoritmo de Diffie-Hellman modificado. Algoritmo de Diffie-Hellman modificado El algoritmo de Diffie-Hellman sirve para generar una clave de sesión compartida por dos extremos sin que la clave viaje de uno a otro Método Se acuerda un número primo muy grande que llamaremos q y una raíz primitiva de q que llamamos a (a mod q, a 2 mod q,.. a q 1 mod q son distintos) A selecciona x A (secreto) y transmite a B: y A = a x A B selecciona x B (secreto) y transmite a A: y B = a x B Ambos calculan la clave K = (y B ) x A mod q=(y A ) x B mod q Después de este paso de se produce un paso de autentificación que puede ser de dos tipos: Los dos extremos conocen un secreto compartido y demuestran al otro este conocimiento a través de un hash A través de certificados X509v3, como se explico anteriormente En la segunda fase el canal seguro establecido en la primera fase se utiliza para negociar los parámetros de la conexión, como por ejemplo si se utiliza un protocolo ESP o AH o la clave de sesión que se utilizará Los protocolos AH y ESP Una vez el protocolo IKE ha establecido el canal seguro y negociado la clave de sesión y resto de parámetros de la conexión, comienza en intercambio de datos a través de alguno de los dos protocolos que proporciona IPSec para ello, AH y ESP. El protocolo AH proporciona servicios de autentificación y no de confidencialidad, es decir no cifra los datos, sólo intenta garantizar que el dato que ha llegado no ha sido modificado y que los dos extremos de la comunicación son fiables. El funcionamiento de AH se basa en la utilización de un algoritmo HMAC que a partir del mensaje original y de la clave acordada mediante el protocolo IKE, genera un hash. Este hash es transmitido junto a los datos en el Protocolos de Seguridad en Redes 6 Meleth

7 paquete IP. El receptor que también conoce la clave de sesión recalcula el hash mediante el mismo algoritmo y lo compara, si son iguales el paquete es valido. La seguridad de AH reside en que el calculo del hash se realiza a través de una clave de sesión que solo conocen los dos extremos. El protocolo ESP proporciona servicios de confidencialidad, es decir, cifra los datos del paquete IP mediante un algoritmo de encriptación simétrico utilizando la clave acordada mediante el protocolo IKE. El receptor recibe el paquete y lo descifra utilizando esa misma clave Modo túnel y modo transporte Los protocolos AH y ESP permiten dos modos de funcionamiento. El modo túnel y el modo transporte. En el modo transporte lo que se cifra solo los datos de la capa de transporte dejando en claro las cabeceras IP. Este modo asegura la comunicación extremo a extremo, pero requiere que los dos extremos entiendan IPSec. En el modo túnel, se cifra todo el paquete IP, incluidas cabeceras. A este paquete se le añade una nueva cabecera IP que se utiliza para el encaminado. Este modo se usa cuando el receptor final de los datos no es el que realiza las funciones IPSec. Host con IPSec Comunicación segura Host con IPSec INTERNET Modo transporte Host sin IPSec Gateway IPSec Gateway IPSec Host sin IPSec INTERNET Comunicación en claro Modo túnel 2.2. SSL Modos Transporte y Túnel En 1994 Netscape desarrollo la primera versión de SSL, meses después la versión 2.0 fue liberada. En noviembre de 1995 la versión 3.0 del protocolo fue liberada convirtiendo en un estándar para comunicaciones seguras en red. SSL Secure Socket Layer es un protocolo de seguridad cuyo objetivo es crear Protocolos de Seguridad en Redes 7 Meleth

8 un canal de comunicaciones seguro entre un cliente y un servidor de forma independiente del sistema operativo y que se beneficie de forma flexible y dinámica de los nuevos adelantos en materia de cifrado a medida que estén disponibles [3]. SSL se introduce como una capa más entre el nivel de aplicación y el nivel de transporte, con lo cual es independiente de la aplicación que lo utilice. SSL toma los datos transmitidos por la aplicación y los encripta antes de que sean segmentados por la capa de transporte, recordemos que IPSec lo que realiza es una encriptación de los paquetes IP con lo cual podrían coexistir en la misma transmisión IPSec y SSL. El protocolo SSL esta formado por cuatro elementos: El protocolo de Registro Record Protocol que se encarga de encapsular los elementos de la capa superior El protocolo de Alerta que se encarga de señalizar problemas y errores de la comunicación SSL El Change Cipher Spec Protocol que indica un cambio del algoritmo de cifrado El protocolo de Handshake que es el centro de una transmisión SSL y que veremos a continuación en detalle El protocolo de Handshake de SSL El protocolo de Handshake se encarga de establecer, mantener y finalizar las conexiones SSL, negociando los parámetros de dichas conexiones. Lo primero que ocurre es que el cliente envía un mensaje Client Hello al servidor que contesta con un Server Hello. A través de estos mensajes el cliente envía datos necesarios para establecer la conexión como los algoritmos de encriptación que soporta, las longitudes de clave máximas, o las funciones hash que soporta. El servidor entonces asigna un identificador a la sesión. Este identificador se envía al cliente a través del mensaje Server Hello. Después este mensaje el servidor puede enviar su certificado X.509v3 para autentificarse y que el cliente reciba la clave pública del servidor. Si no tiene certificado, envía la clave pública a través de un mensaje Server Key Exchange. Luego si es necesario el servidor puede también enviar un mensaje pidiendo su certificado al cliente. Una vez hecho esto el servidor manda un mensaje de Server Hello Done que indica el fin de esta fase. Una vez el cliente tiene la clave pública del servidor, el cliente envía un mensaje de Client Key Exchange donde el cliente envía al servidor un número aleatorio y que se usará como clave Protocolos de Seguridad en Redes 8 Meleth

9 del algoritmo simétrico escogido para el intercambio de datos. Si el cliente mandó su certificado anteriormente, el servidor enviará un mensaje Certificate Verify firmado digitalmente para verificar la transacción. En este punto el cliente envía un mensaje Change Cipher Spec y seguidamente un mensaje de Finished que ya va cifrado utilizando la clave simétrica, dando por finalizada la fase. El servidor responde de la misma forma con un mensaje de Change Cipher Spec y otro de Finished cifrado, dando fin al protocolo de Handshake. SSL Client SSL Server Client Hello Certificate Client Key Exchange Certificate Verify Change Cipher Spec Finished Server Hello Certificate Certificate Request Server Key Exchange Change Cipher Spec Finished Client Application Server Application El protocolo de Registro Handshake en SSL Una vez hecho el saludo y negociación de los parámetros de la transmisión comienza el intercambio de datos. El protocolo de Registro es el encargado de la seguridad durante este intercambio, usando estos parámetros. Sus principales misiones son: La fragmentación de paquetes mayores de 2 14 bytes en bloques más pequeños La compresión de los bloques mediante el algoritmo de encriptación pactado durante el Handshake La autentificación y la integridad de los datos mediante el hash de cada mensaje recibido concatenado con un número de secuencia y un número secreto establecido durante el saludo. El resultado de esta concatenación se llama MAC y se añade al mensaje. La autentificación se comprueba mediante el número secreto, y el número de secuencia que va encriptado. La integridad se comprueba mediante la función hash Protocolos de Seguridad en Redes 9 Meleth

10 La confidencialidad, que se obtiene mediante el algoritmo de encriptación simétrico pactado 2.3. WEP El protocolo de seguridad WEP(Wired Equivalent Privacy) es el utilizado en las redes que cumplen el estándar para asegurar la confidencialidad e integridad de los datos en un medio inseguro como es el inalámbrico. Se han visto los protocolos, IPSec y SSL, y el lugar que ocupaban dentro del modelo OSI. Recordemos que IPSec se ocupaba de ofrecer servicios de seguridad a la capa de red IP, mientras que SSL tomaba los datos de la capa de Aplicación y los encriptaba entregándoselos a la capa de transporte TCP. WEP trabaja a un nivel distinto ofreciendo servicios de confidencialidad a la capa de enlace, encriptando los datos que viajan por el aire y son susceptibles de ser interceptados por cualquiera que pase por allí. WEP utiliza un algoritmo RC4 para la encriptación, usando claves de 64 y 128 bits, que en realidad son de 40 y 104, ya que los otros 24 son un vector de inicialización IV que van en el paquete Generación de llaves Para conectarse a una red que tiene el servicio WEP activado necesitamos conocer una clave o passphrase que debe ser conocida por todos los nodos de la red. A partir de esa clave se generan 4 claves de 40 o 104 bits dependiendo de la versión de WEP empleada. Para obtener estas claves se toma la passphrase y se genera una clave de 32 bits que será la semilla de un generador de números pseudo-aleatorios que generará 40 cadenas de 32 bits. La generación de esta clave de 32 bits partir de una clave es muy sencilla y se realiza dividiendo la clave en bloques de 32 bits y haciendo la operación XOR de todos ellos. Acto seguido se toma un bit de cada una de las 40 cadenas generadas obteniendo una llave de 40 bits y se generan 4 llaves de 40 bits de las cuales solo se utilizará una Encriptación WEP Lo primero que se hace es calcular el CRC del Payload de la trama para asegurar la integridad de los datos en el receptor. Este CRC es añadido a la trama y se denomina ICV Integrity Check Value. Por otro lado se selecciona una clave de las 4 generadas anteriormente y se añade un vector de inicialización (IV) de 24 bits generado aleatoriamente al principio de la clave seleccionada, quedando de esta forma configurada la clave de 64 o 128 Protocolos de Seguridad en Redes 10 Meleth

11 bits. A este conjunto IV+clave se le aplica un algoritmo de cifrado RC4. El resultado de este cifrado es combinado con el Payload+ICV generado anteriormente mediante una operación XOR dando lugar al texto cifrado final. A este texto se le añade la cabecera de la trama , el IV, y el número de clave usado de las cuatro posibles. El proceso ilustrado es siguiente: IV Clave i RC4 Payload IV+i Payload+ICV cifrado CRC ICV Encriptación WEP Para desencriptar el receptor genera también las cuatro claves y escoge la que le indica el paquete, luego la combina con el IV que recibe y utiliza el algoritmo RC4 para generar la clave con la cual a través de una nueva operación XOR desencripta el paquete. Una vez desencriptado, calcula el CRC del paquete y lo compara con el ICV recibido para comprobar la integridad. El protocolo WEP como hemos visto es sencillo y eficiente, pero presenta graves problemas de seguridad. El principal problema es que la clave utilizada no suele cambiar nunca, y tiene una longitud muy pequeña con lo cual mediante un análisis estadístico de las tramas durante unas cuantas horas es posible romper el cifrado. Para un análisis más detallado de las vulnerabilidades del protocolo WEP se puede consultar la bibliografía. Para lo que a nosotros concierne nos quedamos con que el protocolo WEP ofrece servicios de seguridad e integridad de forma simple y eficiente a costa de ser bastante vulnerable SSH Secure Shell (SSH)[6] es un protocolo utilizado para login y ejecución de procesos remotos. SSH nos permite entre otras cosas: Iniciar sesiones en equipos remotos Protocolos de Seguridad en Redes 11 Meleth

12 Ejecutar comandos remotamente Realizar túneles IP cifrados Quizas la parte más importante en este contexto es la posibilidad de realizar túneles cifrados, lo que se conoce como SSH tunneling, gracias a esta posibilidad podemos redirigir nuestras conexiones a través de uno de estos túneles obteniendo una confidencialidad que la aplicación que lo utiliza no ofrece. Por ejemplo podemos usar un túnel para realizar una sesión de ftp en la cual todos los paquetes viajan cifrados gracias a SSH Descripción del protocolo SSH Conociendo como funcionan otros protocolos es inmediato enterder el funcionamiento de SSH. Para iniciar una conexión SSH el cliente realiza los siguientes pasos: 1. El cliente abre una conexión TCP con el host servidor 2. Se acuerda la versión del protocolo a utilizar 3. El servidor envía al cliente su clave pública RSA 4. El cliente compara la clave pública del servidor con la que tiene almacenada, si no tenia ninguna almacenada avisa al usuario, y le pide que la acepte 5. El cliente genera una clave de sesión aleatoria y selecciona un algoritmo simétrico de cifrado 6. El cliente envia un mensaje con la clave de sesión y el algoritmo de cifrado seleccionado, encriptandolo con la clave pública del servidor 7. Comienza la transmisión segura de datos utilizando el algoritmo de cifrado simétrico seleccionado Referencias [1] Miguel García Feal, Seguridad en Internet [2] Santiago Pérez Iglesias, Análisis del protocolo IPSec: el estándar de seguridad en IP Protocolos de Seguridad en Redes 12 Meleth

13 [3] Jose María Morales Vazques, SSL, Secure Socket Layer y Otros Protocolos Seguros para el Comercio Eléctronico [4] Miguel García Feal. Seguridad en Internet. SSL [5] Pau Oliva Fora, (In)seguridad en redes b [6] Javier Smaldone, Introducción a Secure Shell Protocolos de Seguridad en Redes 13 Meleth