1. Criptografía de clave pública
1.1. Algoritmos de clave pública
1.1.1. En un algoritmo criptográfico de clave pública se utilizan claves distintas para el cifrado y el descifrado. Una de ellas, la clave pública, se puede obtener fácilmente a partir de la otra, la clave privada, pero por el contrario es computacionalmente de muy difícil obtención la clave privada a partir de la clave pública.
1.1.2. Los mecanismos deintercambio de claves permiten que dos partes se pongan de acuerdo en les claves simétricas que utilizaran para comunicar-se, sin que un tercer que esté escuchando el diálogo pueda deducir cuales son estas claves.
1.1.3. La autenticación basada en clave pública se puede utilizar si el algoritmo permite utilizar las claves a la inversa: la clave privada para cifrar y la clave pública para descifrar.
1.1.4. Ejemplos de algoritmos de clave pública
1.1.4.1. Intercambio de claves Diffie-Hellman.
1.1.4.2. RSA.
1.1.4.3. ElGamal.
1.1.4.4. DSA (Digital Signature Algorithm).
1.2. Uso de la criptografía de clave pública
1.2.1. El problema de la confidencialidad entre dos partes que sólo disponen de un canal inseguro para comunicarse se resuelve con la criptografía de clave pública.
1.2.2. Una firma digital es básicamente un mensaje cifrado con la clave privada del firmante.
1.3. Infraestructura de clave pública (PKI)
1.3.1. Certificados de clave pública
1.3.1.1. Un certificado de clave pública o certificado digital consta de tres partes básicas
1.3.1.1.1. Una identificación de usuario como, por ejemplo, su nombre.
1.3.1.1.2. El valor de la clave pública de este usuario.
1.3.1.1.3. La firma de las dos partes anteriores.
1.3.1.2. El cuerpo del certificado (“toBeSigned” en la tabla anterior) está formado por los siguientes campos:
1.3.1.2.1. El campo version es el número de versión del formato: puede ser 1, 2 ó 3. Aunque es un campo opcional, es obligatorio si la versión es 2 ó 3 (por tanto, la ausencia de este campo indica que la versión es 1).
1.3.1.2.2. El campo serialNumber es el número de serie del certificado, y sirve para distinguirlo de todos los demás que haya generado la misma CA.
1.3.1.2.3. El campo signature indica el algoritmo utilizado por la CA para formar el certificado.
1.3.1.2.4. El campo issuer es el nombre distintivo (DN) del firmante o emisor del certificado, es decir, de la CA que lo ha generado.
1.3.1.2.5. El campo validity indica el período de validez del certificado, entre un instante inicial y un instante de caducidad. Cuando hablemos más adelante de las listas de revocación, veremos la utilidad de la fecha de caducidad en los certificados.
1.3.1.2.6. El campo subject es el nombre distintivo (DN) del sujeto a nombre del cual esta emitido el certificado, es decir, el titular de la clave pública que figura en el certificado.
1.3.1.2.7. En el campo subjectPublicKeyInfo se encuentre la clave pública del sujeto: a que algoritmo corresponde, y su valor.
1.3.1.2.8. Los campos issuerUniqueIdentifier y subjectUniqueIdentifier se introdujeron en la versión 2, pero no se suelen utilizar porqué con el campo extensions son innecesarios.
1.3.1.2.9. El campo extensions se introdujo en la versión 3, y es una lista de atributos adicionales del certificado. El subcampo extnId indica de que tipo de extensión se trata.
1.3.2. Cadenas de certificados y jerarquías de certificación
1.3.2.1. Un certificado nos soluciona el problema de la autenticidad de la clave pública si está firmado por una CA en la cual confiamos, Pero que pasa si nos comunicamos con un usuario que tiene un certificado emitido por una CA que no conocemos
1.3.3. Listas de revocación de certificados (CRL)
1.3.3.1. La Recomendación X.509, además de definir el formato de los certificados, también define otra estructura llamada lista de revocación de certificados o CRL.
2. Autenticación de entidad
2.1. La autenticación de entidad se utiliza cuando en una comunicación una de las partes quiere asegurarse de la identidad de la otra. Normalmente, esta autenticación es un requisito para permitir el acceso a un recurso restringido
2.2. En general, las técnicas utilizadas para la identificación de un usuario A pueden estar basadas en
2.2.1. Algo que A sabe como, por ejemplo, una contraseña o una clave privada.
2.2.2. Algo que A tiene como, por ejemplo, una tarjeta con banda magnética o con chip.
2.2.3. Algo que A es o, dicho de otro modo, alguna propiedad inherente a A como, por ejemplo, sus características biométricas.
2.3. A continuación veremos dos grupos de técnicas que se pueden utilizar para la autenticación de entidad
2.3.1. Las basadas en contraseñas (o passwords, en inglés), también llamadas técnicas de autenticación débil.
2.3.2. Las basadas en protocolos de retorespuesta (challenge-response, en inglés), también llamadas técnicas de autenticación fuerte.
2.4. Contraseñas
2.4.1. La idea básica de la autenticación basada en contraseñas es que el usuario A manda su identidad (su identificador de usuario, su nombre de login, etc.) seguida de una contraseña secreta x A(una palabra o combinación de caracteres que el usuario pueda memorizar). El verificador B comprueba que la contraseña sea válida, y si lo es da por buena la identidad de A.
2.4.2. Lista de contraseñas en claro
2.4.2.1. La manera más simple de comprobar una contraseña es que el verificador tenga una lista de las contraseñas asociadas a los usuarios, es decir, una lista de pares (A, xA). Cuando A envía su contraseña, el verificador compara directamente el valor recibido x0A con el que figura en la lista, xA.
2.4.3. Lista de contraseñas codificadas
2.4.3.1. Una segunda opción consiste en que en la lista de contraseñas, en lugar de estar guardadas éstas en claro por pares (A, xA), cada una esté codificada con alguna transformación C de manera que no se pueda deducir su valor real. De este modo, la lista debe contener pares (A, C(xA)).
2.4.4. Técnicas para dificultar los ataques de diccionario
2.4.4.1. A continuación veremos algunas posibles técnicas para dificultar los ataques de diccionario
2.4.4.1.1. Ocultar la lista de contraseñas codificadas
2.4.4.1.2. Reglas para evitar contraseñas fáciles
2.4.4.1.3. Añadir complejidad a la codificación de las contraseñas
2.4.4.1.4. Añadir bits de sal a la codificación de las contraseñas
2.4.4.1.5. Uso de passphrases
2.5. Protocolos de reto-respuesta
2.5.1. El algoritmo para calcular la respuesta debe garantizar que no se pueda obtener sin saber la clave secreta. Esto permite al verificador confirmar que la respuesta sólo ha podido enviarla A. Si se utiliza un reto distinto cada vez, un atacante no podrá sacar provecho de la información que descubra interceptando la comunicación.
2.5.2. Dependiendo del protocolo, el verificador puede generar los retos de diversas maneras:
2.5.2.1. Secuencialmente: en este caso el reto es simplemente un número que se va incrementando cada vez (lo más normal es incrementarlo de uno en uno), y que por tanto no se repetiré nunca.
2.5.2.2. Aleatoriamente: el reto puede ser generado con un algoritmo pseudoaleatorio, pero la propiedad que tiene en este caso es que no es predecible para los atacantes.
2.5.2.3. Cronológicamente: el reto se obtiene a partir de la fecha y hora actuales (con la precisión que sea adecuada para el protocolo). Este tipo de reto también se llama marca de hora o “timestamp”.
2.5.3. Los protocolos de reto-respuesta se pueden clasificar en dos grupos:
2.5.3.1. Los basados en técnicas simétricas, en las cuales la clave secreta es compartida por el usuario A y el verificador B.
2.5.3.2. Los basados en técnicas de clave pública, en las cuales A utiliza una clave privada para calcular la respuesta.
2.5.4. Protocolos de reto-respuesta con clave simétrica
2.5.4.1. Autenticación con marca de tiempo
2.5.4.2. Autenticación con números aleatorios
2.5.4.3. Autenticación mutua con números aleatorios
2.5.4.4. Autenticación con función unidireccional
2.5.4.5. Hay dos formas de utilizar las técnicas de clave pública en los protocolos de reto-respuesta:
2.5.4.5.1. El reto se manda cifrado con clave pública y la respuesta es el reto descifrado con la correspondiente clave privada.
2.5.4.5.2. El reto se envía en claro y la respuesta es la firma del reto.
3. Protección del nivel de red: IPsec
3.1. En el momento de aplicar estos mecanismos a las redes de computadores, existen diversas opciones en cuanto al nivel de las comunicaciones donde se introduzcan les funciones de seguridad
3.1.1. La protección a nivel de red garantiza que los datos que se envíen a los protocolos de nivel superior, como TCP o UDP, se transmitirán protegidos. El inconveniente es que puede ser necesario adaptar la infraestructura de la red y, en particular los encaminadores (routers), para que entiendan las extensiones que es preciso añadir al protocolo de red (IP) para proporcionar esta seguridad.
3.1.2. La protección a nivel de transporte, por su lado, tiene la ventaja de que sólo se precisa adaptar las implementaciones de los protocolos (TCP, UDP, etc.) que haya en los nodos extremos de la comunicación, que normalmente están incorporadas al sistema operativo o en librerías especializadas. En este caso, pues, sólo sería necesario un cambio en el software.
3.1.3. La protección a nivel de aplicación puede responder mejor a las necesidades de ciertos protocolos. Un ejemplo concreto es el del correo electrónico, en el que interesa proteger los datos de aplicación, es decir, los mensajes de correo, más que los paquetes a nivel de transporte o de red. Esto es así porque un mensaje es vulnerable a ataques de acceso ilegítimo o de falsificación no sólo cuando se está transmitiendo por la red sino también cuando está almacenado en el buzón del destinatario.
3.2. La arquitectura IPsec
3.2.1. La arquitectura IPsec (RFC 2401) añade servicios de seguridad al protocolo IP (versión 4 y versión 6), que pueden ser usados por los protocolos de niveles superiores (TCP, UDP, ICMP, etc.).
3.2.2. IPsec se basa en el uso de una serie de protocolos seguros, de los cuales hay dos que proporcionan la mayor parte de los servicios:
3.2.2.1. El protocolo AH (Authentication Header, RFC 2402) ofrece el servicio de autenticación de origen de los datagramas IP (incluyendo la cabecera y los datos de los datagramas).
3.2.2.2. El protocolo ESP (Encapsulating Security Payload, RFC 2406) puede ofrecer el servicio de confidencialidad, el de autenticación de origen de los datos de los datagramas IP (sin incluir la cabecera), o los dos a la vez.
3.2.3. Los agentes que intervienen en la arquitectura IPSec son:
3.2.3.1. Los nodos extremos de la comunicación: el origen y el destino final de los datagramas.
3.2.3.2. Los nodos intermedios que suporten IPsec, llamados pasarelas seguras, como por ejemplo los encaminadores o cortafuegos con IPsec.
3.3. Para cada datagrama que llega a un nodo IPsec, se consulta una base de datos de políticas de seguridad (SPD) donde se especifican criterios para determinar cual de las siguientes 3 acciones se debe realizar:
3.3.1. Aplicar servicios de seguridad IPsec al datagrama, es decir, procesarlo según AH y/o ESP.
3.3.2. Procesarlo como un datagrama IP normal, es decir, de forma transparente a IPsec.
3.3.3. Descartar el datagrama.
3.4. El protocolo AH
3.4.1. El protocolo AH define una cabecera que contiene la información necesaria para a la autenticación de origen de un datagrama.
3.5. El protocolo ESP
3.5.1. El protocolo ESP define otra cabecera, que de hecho incluye dentro todos los datos que vengan a continuación en el datagrama (lo que en inglés se llama “payload”).
3.6. Modos de uso de los protocolos IPsec
3.6.1. La arquitectura IPsec define dos modos de uso de los protocolos AH y ESP, dependiendo de como se incluyan las cabeceras correspondientes en un datagrama IP.
3.6.1.1. En el modo transporte, la cabecera AH o ESP se incluye después de la cabecera IP convencional, como si fuera una cabecera de un protocolo de nivel superior, y a continuación van los datos del datagrama (por ejemplo, un segmento TCP con su cabecera correspondiente, etc.).
3.6.1.2. En el modo túnel, el datagrama original se encapsula entero, con su cabecera y sus datos, dentro de otro datagrama. Este otro datagrama tendrá una cabecera IP en la cual las direcciones de origen y de destino serán las de los nodos inicio y final de la SA. Por tanto, se dice que entre estos dos nodos hay un “túnel” dentro del cual viajan intactos los datagramas originales. A continuación de la cabecera IP del datagrama “externo” hay la cabecera AH o ESP.
4. Conceptos básicos de criptografía
4.1. La criptografía estudia, desde un punto de vista matemático, los métodos de protección de la información. Por otro lado, el criptoanálisis estudia las posibles técnicas utilizadas para contrarrestar los métodos criptográficos, y es de gran utilidad para ayudar a que estos sean más robustos y difíciles de atacar. El conjunto formado por estas dos disciplinas, criptografía y criptoanálisis, se conoce como criptología.
4.2. Una premisa fundamental en la criptografía moderna es la suposición de Kerckhoffs, que establece que los algoritmos deben ser conocidos públicamente y su seguridad solo depende de la clave. En lugar de intentar ocultar el funcionamiento de los algoritmos, es mucho más seguro y efectivo mantener en secreto solamente las claves.
4.3. La acción de intentar descifrar mensajes sin conocer la clave de descifrado se conoce como “ataque”
4.3.1. Existen dos formas de llevar a cabo un ataque:
4.3.1.1. Mediante el criptoanálisis, es decir, estudiando matemáticamente la forma de deducir el texto en claro a partir del texto cifrado.
4.3.1.2. Aplicando la fuerza bruta, es decir, probando uno a uno todos los valores posibles de la clave de descifrado x hasta encontrar uno que produzca un texto en claro con sentido.
4.4. Criptografía de clave simétrica
4.4.1. Los sistemas criptográficos de clave simétrica se caracterizan porque la clave de descifrado x es idéntica a la clave de cifrado k, o bien se puede deducir directamente a partir de ésta.
4.4.2. Algoritmos de cifrado en flujo
4.4.2.1. El funcionamiento de una cifrado en flujo consiste en la combinación de un texto en claro M con un texto de cifrado S que se obtiene a partir de la clave simétrica k. Para descifrar, sólo se requiere realizar la operación inversa con el texto cifrado y el mismo texto de cifrado S.
4.4.3. Algoritmos de cifrado en bloque
4.4.3.1. En una cifra de bloque, el algoritmo de cifrado o descifrado se aplica separadamente a bloques de entrada de longitud fija b, y para cada uno de ellos el resultado es un bloque de la misma longitud.
4.4.3.1.1. Muchos de los algoritmos del cifrado de bloque se basan en la combinación de dos operaciones básicas: sustitución y transposición
4.4.3.2. Ejemplos de algoritmos de cifrado en bloque
4.4.3.2.1. DES (Data Encryption Standard).
4.4.3.2.2. Triple DES.
4.4.3.2.3. AES (Advanced Encryption Standard).
4.4.4. Uso de los algoritmos de clave simétrica
4.4.4.1. Esto pasa con el cifrado en flujo si su periodo no es lo suficientemente largo, pero en un cifrado en bloque, si dos bloques de texto en claro son iguales y se utiliza la misma clave, los bloques cifrados también serán iguales. Para contrarrestar esta propiedad, se pueden aplicar distintos modos de operación al cifrado en bloque.
4.4.4.1.1. El modo ECB (Electronic Codebook) es el más simple, y consiste en dividir el texto en bloques y cifrar cada uno de ellos de forma independiente. Este modo parte del problema de dar bloques iguales cuando en la entrada existen bloques iguales.
4.4.4.1.2. En el modo CBC (Cipher Block Chaining), se suma a cada bloque de texto en claro, antes de cifrarlo, (bit a bit, con XOR) el bloque cifrado anterior. Al primer bloque se le suma un vector de inicialización (VI), que es un conjunto de bits aleatorios de la misma longitud que un bloque. Escogiendo vectores distintos cada vez, aun que el texto en claro sea el mismo, los datos cifrados serán distintos. El receptor debe conocer el valor del vector antes de empezar a descifrar, pero es necesario falta guardar este valor en secreto, sino que normalmente se transmite como cabecera del texto cifrado.
4.4.4.1.3. En el modo CFB (Cipher Feedback), el algoritmo de cifrado no se aplica directamente al texto en claro sino a un vector auxiliar (inicialmente igual al VI). Del resultado del cifrado se toman n bits que se suman a n bits del texto en claro para obtener n bits de texto cifrado. Estos bits cifrados se utilizan también para actualizar el vector auxiliar. El número n de bits generados en cada iteración puede ser menor o igual que la longitud de bloque b. Tomando como ejemplo n = 8, tenemos un cifrado que genera un byte cada vez sin que sea necesario esperar a tener un bloque entero para poderlo descifrar.
4.4.4.1.4. El modo OFB (Output Feedback) opera como el CFB pero en lugar de actualizar el vector auxiliar con el texto cifrado, se actualiza con el resultado obtenido del algoritmo de cifrado. La propiedad que distingue este modo de los demás consiste en que un error en la recuperación de un bit cifrado afecta solamente al descifrado de este bit.
4.4.4.1.5. A partir de los modos anteriores se pueden definir varias variantes. Por ejemplo, el modo CTR (Counter) es como el OFB, pero el vector auxiliar no se realimenta con el cifrado anterior sino que simplemente es un contador que se va incrementando.
4.4.5. Funciones hash seguras
4.4.5.1. Aparte de cifrar datos, existen algoritmos basados en técnicas criptográficas que se usan para garantizar la autenticidad de los mensajes. Un tipo de algoritmos de estas características son las llamadas funciones hash seguras, también conocidas como funciones de resumen de mensaje (message digest, en inglés).
4.4.5.2. Se entiende que una función hash o de resumen es segura si cumple las siguientes condiciones:
4.4.5.2.1. Es unidireccional, es decir, si tenemos H = h(M) es computacionalmente inviable encontrar M a partir del resumen H.
4.4.5.2.2. Es resistente a colisiones, es decir, dado un mensaje M cualquiera es computacionalmente inviable encontrar un mensaje.
4.5. Pero existe otro tipo de ataque más ventajoso para el atacante, llamado ataque del cumpleaños. Un ataque de este tipo parte de la suposición de que el atacante puede escoger el mensaje que será autenticado. La víctima lee el mensaje y, si lo acepta, lo autentica con su clave secreta.
5. Sistemas de autenticación
5.1. Uno de los servicios de seguridad que se requiere en muchas aplicaciones es el de la autenticación.
5.1.1. Podemos distinguir dos tipos de autenticación:
5.1.1.1. La autenticación de mensaje o autenticación de origen de datos permite confirmar que el originador A de un mensaje es auténtico, es decir, que el mensaje no ha sido generado por un tercero Z que quiere hacer creer que lo ha generado A.
5.1.1.2. La autenticación de entidad permite confirmar la identidad de un participante A en una comunicación, es decir, que no se trata de un tercero Z que dice ser A.
5.2. Autenticación de mensaje
5.2.1. Existen dos grupos de técnicas para proporcionar autenticación de mensaje
5.2.1.1. Los códigos de autenticación de mensaje o MAC, basados en claves simétricas.
5.2.1.2. Las firmas digitales, que se basan en la criptografía de clave pública.
5.2.2. Códigos de autenticación de mensaje (MAC)
5.2.2.1. Un código de autenticación de mensaje o MAC se obtiene con un algoritmo a que tiene dos entradas: un mensaje M de longitud arbitraria, y una clave secreta k compartida por el originador y el destinatario del mensaje. Como resultado da un código CMAC = a(k, M) de longitud fija.
5.2.3. Firmas digitales
5.2.3.1. Los códigos MAC, dado que se basan en una clave secreta, sólo tienen significado para quienes conozcan dicha clave. Si A envía mensajes a B autenticados con una clave compartida, sólo B podrá verificar la autenticidad de estos mensajes.
6. Protección del nivel de transporte: SSL/TLS/WTLS
6.1. Un método alternativo que no necesita modificaciones en los equipos de interconexión es introducir la seguridad en los protocolos de transporte. La solución más usada actualmente es el uso del protocolo SSL o de otros basados en SSL.
6.1.1. Este grupo de protocolos comprende
6.1.1.1. El protocolo de transporte Secure Sockets Layer (SSL), desarrollado por Netscape Communications a principios de los años 90. La primera versión de este protocolo ampliamente difundida y implementada fue la 2.0. Poco después Netscape publicó la versión 3.0, con muchos cambios respecto a la anterior, que hoy ya casi no e utiliza.
6.1.1.2. La especificación Transport Layer Security (TLS), elaborada por la IETF (Internet Engineering Task Force). La versión 1.0 del protocolo TLS está publicada en el documento RFC 2246. Es prácticamente equivalente a SSL 3.0 con algunas pequeñas diferencias, por lo que en ciertos contextos se considera el TLS 1.0 como si fuera el protocolo “SSL 3.1”.
6.1.1.3. El protocolo Wireless Transport Layer Security (WTLS), perteneciente a la familia de protocolos WAP (Wireless Application Protocol) para el acceso a la red des de dispositivos móviles. La mayoría de los protocolos WAP son adaptaciones de los ya existentes a las características de las comunicaciones inalámbricas, y en particular el WTLS está basado en el TLS 1.0. Las diferencias se centran principalmente en aspectos relativos a el uso eficiente del ancho de banda y de la capacidad de cálculo de los dispositivos, que puede ser limitada.
6.2. Características del protocolo SSL/TLS
6.2.1. El objetivo inicial del diseño del protocolo SSL fue proteger las conexiones entre clientes y servidores web con el protocolo HTTP. Esta protección debía permitir al cliente asegurarse que se había conectado al servidor auténtico, y enviarle datos confidenciales, como por ejemplo un número de tarjeta de crédito, con la confianza que nadie más que el servidor sería capaz de ver estos datos.
6.3. Los servicios de seguridad que proporcionan los protocolos SSL/TLS son:
6.3.1. Confidencialidad. El flujo normal de información en una conexión SSL/TLS consiste en intercambiar paquetes con datos cifrados mediante claves simétricas (por motivos de eficiencia y rapidez).
6.3.2. Autenticación de entidad. Con un protocolo de reto-respuesta basado en firmas digitales el cliente pude confirmar la identidad del servidor al cual se ha conectado. Para validar las firmas el cliente necesita conocer la clave pública del servidor, y esto normalmente se realiza a través de certificados digitales.
6.3.3. Autenticación de mensaje. Cada paquete enviado en una conexión SSL/TLS, a más de ir cifrado, puede incorporar un código MAC para que el destinatario compruebe que nadie ha modificado el paquete. Las claves secretas par el cálculo de los códigos MAC (una para cada sentido) también se acuerdan de forma segura en el diálogo inicial.
6.3.4. A más, los protocolos SSL/TLS están diseñados con estos criterios adicionales:
6.3.4.1. Eficiencia. Dos de las características de SSL/TLS, la definición de sesiones y la compresión de los datos, permiten mejorar la eficiencia de la comunicación.
6.3.4.2. Extensibilidad. Al inicio de cada sesión, cliente y servidor negocian los algoritmos que utilizarán para el intercambio de claves, la autenticación y el cifrado (a más del algoritmo de compresión). Las especificaciones de los protocolos incluyen unas combinaciones predefinidas de algoritmos criptográficos pero dejan abierta la posibilidad de añadir nuevos algoritmos si se descubren otros que sean más eficientes o más seguros
6.4. El transporte seguro SSL/TLS
6.4.1. La capa de transporte seguro que proporciona SSL/TLS se puede considerar dividida en dos subcapas.
6.4.1.1. La subcapa superior se encarga básicamente de negociar los parámetros de seguridad y de transferir los datos de la aplicación. Tanto los datos de negociación como los de aplicación se intercambian en mensajes.
6.4.1.2. En la subcapa inferior, estos mensajes son estructurados en registros a los cuales se les aplica, según corresponda, la compresión, la autenticación y el cifrado.
6.4.2. El protocolo de registros SSL/TLS es el que permite que los datos protegidos sean convenientemente codificados por el emisor y interpretados por el receptor.
6.4.3. Los parámetros necesarios para la protección, como pueden ser los algoritmos y las claves, se establecen de forma segura al inicio de la conexión mediante el protocolo de negociación SSL/TLS.
6.5. Ataques contra el protocolo SSL/TLS
6.5.1. Los protocolos SSL/TLS están diseñados para resistir los siguientes ataques:
6.5.1.1. Lectura de los paquetes enviados por el cliente y servidor. Cuando los datos se envían cifrados, un atacante que pueda leer los paquetes, por ejemplo utilizando técnicas de sniffing, se enfrenta al problema de romper el cifrado si quiere interpretar su contenido. Las claves que se utilizan para el cifrado se intercambian con métodos de clave pública, que el atacante tendría que romper si quiere saber cuales son los valores acordados.
6.5.1.2. Suplantación de servidor o cliente. Cuando se realiza la autenticación de servidor o cliente, el certificado digital debidamente firmado por la CA sirve para verificar la identidad de su propietario. Un atacante que quiera hacerse pasar por el servidor (o cliente) auténtico debería obtener su clave privada, o bien la de la autoridad de certificación que ha emitido el certificado para poder generar otro con una clave pública diferente y que parezca auténtico.
6.5.1.3. Alteración de los paquetes. Un atacante puede modificar los paquetes para que lleguen al destinatario con un contenido distinto del original (si están cifrados no podrá controlar cual será el contenido final descifrado, solamente sabrá que será distinto al original). Si pasa esto, el receptor detectará que el paquete ha sido alterado porque el código de autenticación (MAC) casi con total seguridad será incorrecto.
6.5.1.4. Repetición, eliminación o reordenación de paquetes. Si el atacante vuelve a enviar un paquete correcto que ya había sido enviado antes, o suprime algún paquete haciendo que no llegue a su destino, o los cambia de orden, el receptor lo detectará porque los códigos MAC no coincidirán con el valor esperado. Esto es así porque en el cálculo del MAC se utiliza un número de secuencia que se va incrementando en cada paquete.
6.6. Aplicaciones que utilizan SSL/TLS
6.6.1. Algunas aplicaciones que utilizan esta característica son:
6.6.1.1. HTTPS (HTTP sobre SSL/TLS): el protocolo más utilizado actualmente para la navegación web segura.
6.6.1.2. NNTPS (NNTP sobre SSL): para el acceso seguro al servicio de News.
7. Redes privadas virtuales (VPN)
7.1. Una red privada virtual (VPN) es una configuración que combina el uso de dos tipos de tecnologías:
7.1.1. Las tecnologías de seguridad que permiten la definición de una red privada, es decir, un medio de comunicación confidencial que no puede ser interceptado por usuarios ajenos a la red.
7.1.2. Las tecnologías de encapsulamiento de protocolos que permiten que, en lugar de una conexión física dedicada para la red privada, se pueda utilizar una infraestructura de red pública, como Internet, para definir por encima de ella una red virtual.
7.2. Dependiendo de la situación de los nodos que utilizan esta red, podemos considerar tres tipos de VPN:
7.2.1. VPN entre redes locales o intranets. Este es el caso habitual en que una empresa dispone de redes locales en diferentes sedes, geográficamente separadas, en cada una de las cuales hay una red privada o intranet, de acceso restringido a sus empleados. Si interesa que desde una de sus sedes se pueda acceder a las intranets de otras sedes, se puede usar una VPN para interconectar estas redes privadas y formar una intranet única.
7.2.2. VPN de acceso remoto. Cuando un empleado de la empresa quiere acceder a la intranet des de un ordenador remoto, puede establecer una VPN de este tipo entre este ordenador y la intranet de la empresa. El ordenador remoto puede ser, por ejemplo, un PC que el empleado tiene en su casa, o un ordenador portátil des del cual se conecta a la red de la empresa cuando está de viaje.
7.2.3. VPN extranet. A veces, a una empresa le interesa compartir una parte de los recursos de su intranet con determinados usuarios externos, como por ejemplo proveedores o clientes de la empresa. La red que permite estos accesos externos a una intranet se llama extranet, y su protección se consigue mediante una VPN extranet.
7.3. Hay protocolos que pueden ser utilizados para establecer los túneles, dependiendo del nivel de la comunicación al cual se quiera realizar la protección.
7.3.1. Túneles a nivel de red. El protocolo utilizado en la gran mayoría de configuraciones VPN es IPsec en modo túnel, generalmente con ESP par cifrar los datos, y opcionalmente con AH para autenticar los paquetes encapsulados. Las pasarelas VPN son, en este caso, pasarelas seguras IPsec
7.3.2. Túneles a nivel de enlace. En el caso de las VPN de acceso remoto o VPDN, existe la posibilidad de encapsular tramas PPP, que son las que transmite normalmente un cliente VPN de este tipo, sobre datagramas IP.
7.3.3. Túneles a nivel de transporte. El protocolo SSH (Secure Shell), como veremos en el módulo de aplicaciones seguras, ofrece la posibilidad de redirigir puertos TCP sobre un canal seguro, que podemos considerar como un túnel a nivel de transporte. Des de este punto de vista, también se podría considerar una conexión SSL/TLS como un túnel a nivel de transporte que proporciona confidencialidad y autenticación. Habitualmente, este último tipo de túnel no sirve para cualquier tipo de tráfico si no solamente para datos TCP, y por tanto no se considera parte integrante de una VPN.