En informática , el protocolo de seguridad de Internet ( IPsec ) es un conjunto de protocolos de red seguros que autentican y cifran paquetes de datos para proporcionar una comunicación cifrada segura entre dos computadoras a través de una red de protocolo de Internet . Se utiliza en redes privadas virtuales (VPN).
IPsec incluye protocolos para establecer autenticación mutua entre agentes al comienzo de una sesión y la negociación de claves criptográficas para usar durante la sesión. IPsec puede proteger flujos de datos entre un par de hosts ( host-to-host ), entre un par de puertas de enlace de seguridad ( red-to-network ) o entre una puerta de enlace de seguridad y un host ( red-to-host ). [1] IPsec utiliza servicios de seguridad criptográfica para proteger las comunicaciones a través de redes de Protocolo de Internet (IP). Admite autenticación de pares a nivel de red, autenticación de origen de datos , integridad de datos , confidencialidad de datos ( encriptación ) y protección contra ataques de repetición .
A principios de los años 1970, la Agencia de Proyectos de Investigación Avanzada patrocinó una serie de dispositivos experimentales de cifrado ARPANET , primero para el cifrado nativo de paquetes ARPANET y luego para el cifrado de paquetes TCP/IP ; algunos de ellos fueron certificados y puestos en práctica. De 1986 a 1991, la NSA patrocinó el desarrollo de protocolos de seguridad para Internet bajo su programa Secure Data Network Systems (SDNS). [2] Esto reunió a varios proveedores, incluido Motorola , que produjo un dispositivo de cifrado de red en 1988. El trabajo fue publicado abiertamente a partir de 1988 por el NIST y, de estos, el Protocolo de seguridad en la capa 3 (SP3) eventualmente se transformaría en el Protocolo de seguridad de la capa de red (NLSP) estándar de la ISO. [3]
En 1992, el Laboratorio de Investigación Naval de los Estados Unidos (NRL) recibió financiación de DARPA CSTO para implementar IPv6 e investigar e implementar el cifrado IP en 4.4 BSD , compatible con arquitecturas de CPU SPARC y x86. DARPA puso su implementación a disposición de forma gratuita a través del MIT. En el marco del esfuerzo de investigación financiado por DARPA del NRL , el NRL desarrolló las especificaciones de la vía de estándares de la IETF (RFC 1825 a RFC 1827) para IPsec. [4] La implementación de IPsec del NRL se describió en su artículo en las Actas de la Conferencia USENIX de 1996. [5] La implementación de IPsec de código abierto del NRL se puso a disposición en línea por el MIT y se convirtió en la base de la mayoría de las implementaciones comerciales iniciales. [4]
El Grupo de Trabajo de Ingeniería de Internet (IETF) formó el Grupo de Trabajo de Seguridad IP en 1992 [6] para estandarizar las extensiones de seguridad especificadas abiertamente para IP, llamadas IPsec . [7] Los estándares desarrollados por NRL fueron publicados por el IETF como RFC-1825 a RFC-1827. [8]
La suite IPv4 inicial se desarrolló con pocas disposiciones de seguridad. Como parte de la mejora de IPv4, IPsec es un modelo OSI de capa 3 o un esquema de seguridad de extremo a extremo de la capa de Internet . Por el contrario, mientras que otros sistemas de seguridad de Internet de uso generalizado funcionan por encima de la capa de red , como Transport Layer Security (TLS) que funciona por encima de la capa de transporte y Secure Shell (SSH) que funciona en la capa de aplicación , IPsec puede proteger automáticamente las aplicaciones en la capa de Internet .
IPsec es un estándar abierto como parte de la suite IPv4 y utiliza los siguientes protocolos para realizar varias funciones: [9] [10]
El encabezado de autenticación de seguridad (AH) se desarrolló en el Laboratorio de Investigación Naval de EE. UU. a principios de la década de 1990 y se deriva en parte del trabajo de estándares IETF anteriores para la autenticación del Protocolo simple de administración de red (SNMP) versión 2. El encabezado de autenticación (AH) es un miembro del conjunto de protocolos IPsec. AH garantiza la integridad sin conexión mediante el uso de una función hash y una clave compartida secreta en el algoritmo AH. AH también garantiza el origen de los datos mediante la autenticación de paquetes IP . Opcionalmente, un número de secuencia puede proteger el contenido del paquete IPsec contra ataques de reproducción , [18] [19] utilizando la técnica de ventana deslizante y descartando paquetes antiguos.
AH opera directamente sobre IP, utilizando el protocolo IP número 51. [20 ]
El siguiente diagrama de paquetes AH muestra cómo se construye e interpreta un paquete AH: [11] [12]
La carga útil de seguridad encapsulante IP (ESP) [21] se desarrolló en el Laboratorio de Investigación Naval a partir de 1992 como parte de un proyecto de investigación patrocinado por DARPA , y fue publicada abiertamente por el Grupo de trabajo SIPP [22] de IETF redactado en diciembre de 1993 como una extensión de seguridad para SIPP. Este ESP se derivó originalmente del protocolo SP3D del Departamento de Defensa de los EE. UU., en lugar de derivarse del Protocolo de seguridad de capa de red (NLSP) de ISO. La especificación del protocolo SP3D fue publicada por NIST a fines de la década de 1980, pero diseñada por el proyecto Secure Data Network System del Departamento de Defensa de los EE. UU . La carga útil de seguridad encapsulante (ESP) es un miembro del conjunto de protocolos IPsec. Proporciona autenticidad de origen a través de la autenticación de fuente , integridad de datos a través de funciones hash y confidencialidad a través de protección de cifrado para paquetes IP . ESP también admite configuraciones de solo cifrado y solo autenticación , pero se desaconseja enfáticamente el uso de cifrado sin autenticación porque es inseguro. [23] [24] [25]
A diferencia del encabezado de autenticación (AH) , ESP en modo de transporte no proporciona integridad y autenticación para todo el paquete IP . Sin embargo, en modo túnel , donde todo el paquete IP original se encapsula con un nuevo encabezado de paquete agregado, la protección ESP se brinda a todo el paquete IP interno (incluido el encabezado interno), mientras que el encabezado externo (incluidas las opciones IPv4 externas o los encabezados de extensión IPv6) permanece desprotegido.
ESP opera directamente sobre IP, utilizando el protocolo IP número 50. [20]
El siguiente diagrama de paquetes ESP muestra cómo se construye e interpreta un paquete ESP: [1] [26]
Los protocolos IPsec utilizan una asociación de seguridad , donde las partes que se comunican establecen atributos de seguridad compartidos, como algoritmos y claves. Como tal, IPsec proporciona una gama de opciones una vez que se ha determinado si se utiliza AH o ESP. Antes de intercambiar datos, los dos hosts acuerdan qué algoritmo de cifrado simétrico se utiliza para cifrar el paquete IP, por ejemplo AES o ChaCha20 , y qué función hash se utiliza para garantizar la integridad de los datos, como BLAKE2 o SHA256 . Estos parámetros se acuerdan para la sesión en particular, para la que se debe acordar un tiempo de vida y una clave de sesión . [27]
El algoritmo de autenticación también se acuerda antes de que se realice la transferencia de datos e IPsec admite una variedad de métodos. La autenticación es posible a través de una clave precompartida , donde una clave simétrica ya está en posesión de ambos hosts, y los hosts se envían entre sí hashes de la clave compartida para demostrar que están en posesión de la misma clave. IPsec también admite el cifrado de clave pública , donde cada host tiene una clave pública y una privada, intercambian sus claves públicas y cada host envía al otro un nonce cifrado con la clave pública del otro host. Alternativamente, si ambos hosts tienen un certificado de clave pública de una autoridad de certificación , esto se puede utilizar para la autenticación IPsec. [28]
Las asociaciones de seguridad de IPsec se establecen utilizando el Protocolo de administración de claves y asociación de seguridad de Internet (ISAKMP). ISAKMP se implementa mediante configuración manual con secretos precompartidos, intercambio de claves de Internet (IKE e IKEv2), negociación de claves de Internet kerberizada (KINK) y el uso de registros DNS IPSECKEY . [17] [29] [30] RFC 5386 define Better-Than-Nothing Security (BTNS) como un modo no autenticado de IPsec que utiliza un protocolo IKE extendido. C. Meadows, C. Cremers y otros han utilizado métodos formales para identificar varias anomalías que existen en IKEv1 y también en IKEv2. [31]
Para decidir qué protección se debe brindar a un paquete saliente, IPsec utiliza el índice de parámetros de seguridad (SPI), un índice de la base de datos de asociaciones de seguridad (SADB), junto con la dirección de destino en un encabezado de paquete, que juntos identifican de manera única una asociación de seguridad para ese paquete. Se realiza un procedimiento similar para un paquete entrante, donde IPsec recopila claves de descifrado y verificación de la base de datos de asociaciones de seguridad.
Para la multidifusión IP, se proporciona una asociación de seguridad para el grupo, que se duplica en todos los receptores autorizados del grupo. Puede haber más de una asociación de seguridad para un grupo, utilizando diferentes SPI, lo que permite múltiples niveles y conjuntos de seguridad dentro de un grupo. De hecho, cada remitente puede tener múltiples asociaciones de seguridad, lo que permite la autenticación, ya que un receptor solo puede saber que alguien que conoce las claves envió los datos. Tenga en cuenta que el estándar relevante no describe cómo se elige la asociación y se duplica en todo el grupo; se supone que una parte responsable habrá tomado la decisión.
Para garantizar que la conexión entre dos puntos finales no se haya interrumpido, los puntos finales intercambian mensajes de mantenimiento de conexión a intervalos regulares, que también pueden usarse para restablecer automáticamente un túnel perdido debido a una interrupción de la conexión.
La detección de pares inactivos (DPD) es un método para detectar un par inactivo de Internet Key Exchange (IKE). El método utiliza patrones de tráfico IPsec para minimizar la cantidad de mensajes necesarios para confirmar la disponibilidad de un par. La detección de pares inactivos se utiliza para recuperar los recursos perdidos en caso de que se encuentre un par inactivo y también se utiliza para realizar una conmutación por error de pares IKE.
UDP keepalive es una alternativa a DPD.
Los protocolos IPsec AH y ESP se pueden implementar en un modo de transporte de host a host, así como en un modo de tunelización de red.
En el modo de transporte, normalmente solo se cifra o autentica la carga útil del paquete IP . El enrutamiento está intacto, ya que el encabezado IP no se modifica ni se cifra; sin embargo, cuando se utiliza el encabezado de autenticación , las direcciones IP no se pueden modificar mediante la traducción de direcciones de red , ya que esto siempre invalida el valor hash . Las capas de transporte y aplicación siempre están protegidas por un hash, por lo que no se pueden modificar de ninguna manera, por ejemplo, traduciendo los números de puerto .
Los documentos RFC han definido un medio para encapsular mensajes IPsec para la travesía NAT {NAT-T} que describe el mecanismo NAT-T.
En el modo túnel, todo el paquete IP se cifra y se autentica. Luego se encapsula en un nuevo paquete IP con un nuevo encabezado IP. El modo túnel se utiliza para crear redes privadas virtuales para comunicaciones de red a red (por ejemplo, entre enrutadores para vincular sitios), comunicaciones de host a red (por ejemplo, acceso de usuario remoto) y comunicaciones de host a host (por ejemplo, chat privado). [32]
El modo túnel admite la travesía NAT.
Los algoritmos criptográficos definidos para su uso con IPsec incluyen:
Consulte RFC 8221 para obtener más detalles.
IPsec se puede implementar en la pila IP de un sistema operativo . Este método de implementación se realiza para hosts y gateways de seguridad. Varias pilas IP con capacidad IPsec están disponibles en empresas, como HP o IBM. [33] Una alternativa es la llamada implementación bump-in-the-stack (BITS), donde el código fuente del sistema operativo no tiene que ser modificado. Aquí IPsec se instala entre la pila IP y los controladores de red . De esta manera los sistemas operativos pueden ser modernizados con IPsec. Este método de implementación también se utiliza tanto para hosts como para gateways. Sin embargo, al modernizar IPsec, la encapsulación de paquetes IP puede causar problemas para el descubrimiento automático de la MTU de ruta , donde se establece el tamaño máximo de la unidad de transmisión (MTU) en la ruta de red entre dos hosts IP. Si un host o gateway tiene un criptoprocesador separado , lo cual es común en el ejército y también se puede encontrar en sistemas comerciales, es posible una implementación llamada bump-in-the-wire (BITW) de IPsec. [34]
Cuando se implementa IPsec en el núcleo , la gestión de claves y la negociación ISAKMP / IKE se llevan a cabo desde el espacio de usuario. La "API de gestión de claves PF_KEY, versión 2", desarrollada y especificada abiertamente por NRL, se utiliza a menudo para permitir que la aplicación de gestión de claves del espacio de aplicación actualice las asociaciones de seguridad IPsec almacenadas dentro de la implementación de IPsec del espacio del núcleo. [35] Las implementaciones de IPsec existentes suelen incluir ESP, AH e IKE versión 2. Las implementaciones de IPsec existentes en sistemas operativos tipo Unix , por ejemplo, Solaris o Linux , suelen incluir PF_KEY versión 2.
Se puede utilizar IPsec integrado para garantizar la comunicación segura entre aplicaciones que se ejecutan en sistemas con recursos limitados con una pequeña sobrecarga. [36]
IPsec se desarrolló en conjunto con IPv6 y originalmente se requería que fuera compatible con todas las implementaciones de IPv6 que cumplieran con los estándares antes de que la RFC 6434 lo convirtiera solo en una recomendación. [37] IPsec también es opcional para las implementaciones de IPv4 . IPsec se usa más comúnmente para proteger el tráfico de IPv4. [ cita requerida ]
Los protocolos IPsec se definieron originalmente en los documentos RFC 1825 a RFC 1829, que se publicaron en 1995. En 1998, estos documentos fueron reemplazados por los documentos RFC 2401 y RFC 2412 con algunos detalles de ingeniería incompatibles, aunque conceptualmente eran idénticos. Además, se definió un protocolo de autenticación mutua e intercambio de claves Internet Key Exchange (IKE) para crear y gestionar asociaciones de seguridad. En diciembre de 2005, se definieron nuevos estándares en los documentos RFC 4301 y RFC 4309 que son en gran medida un superconjunto de las ediciones anteriores con una segunda versión del estándar Internet Key Exchange IKEv2 . Estos documentos de tercera generación estandarizaron la abreviatura de IPsec a “IP” mayúscula y “sec” minúscula. “ESP” generalmente se refiere a RFC 4303, que es la versión más reciente de la especificación.
Desde mediados de 2008, un grupo de trabajo sobre mantenimiento y extensiones de IPsec (ipsecme) está activo en el IETF. [38] [39]
En 2013, como parte de las filtraciones de Snowden , se reveló que la Agencia de Seguridad Nacional de los EE. UU. había estado trabajando activamente para "insertar vulnerabilidades en sistemas de cifrado comerciales, sistemas de TI, redes y dispositivos de comunicación de puntos finales utilizados por los objetivos" como parte del programa Bullrun . [40] Hay acusaciones de que IPsec era un sistema de cifrado específico. [41]
La pila IPsec de OpenBSD llegó más tarde y también fue ampliamente copiada. En una carta que el desarrollador principal de OpenBSD, Theo de Raadt, recibió el 11 de diciembre de 2010 de Gregory Perry, se alega que Jason Wright y otros, que trabajaban para el FBI, insertaron "una serie de puertas traseras y mecanismos de filtración de claves de canal lateral " en el código criptográfico de OpenBSD. En el correo electrónico reenviado de 2010, Theo de Raadt al principio no expresó una posición oficial sobre la validez de las afirmaciones, aparte del respaldo implícito al reenviar el correo electrónico. [42] La respuesta de Jason Wright a las acusaciones: "Toda leyenda urbana se vuelve más real con la inclusión de nombres reales, fechas y horas. El correo electrónico de Gregory Perry cae en esta categoría. ... Diré claramente que no añadí puertas traseras al sistema operativo OpenBSD ni al Marco criptográfico OpenBSD (OCF)". [43] Algunos días después, de Raadt comentó: "Creo que NETSEC probablemente fue contratado para escribir puertas traseras como se alega. … Si esas fueron escritas, no creo que hayan llegado a nuestro árbol". [44] Esto fue publicado antes de las filtraciones de Snowden.
Una explicación alternativa propuesta por los autores del ataque Logjam sugiere que la NSA comprometió las VPN IPsec al socavar el algoritmo Diffie-Hellman utilizado en el intercambio de claves. En su artículo, [45] alegan que la NSA construyó especialmente un clúster de computación para precalcular subgrupos multiplicativos para primos y generadores específicos, como para el segundo grupo Oakley definido en RFC 2409. A partir de mayo de 2015, el 90% de las VPN IPsec direccionables admitían el segundo grupo Oakley como parte de IKE. Si una organización precalculara este grupo, podría derivar las claves que se intercambian y descifrar el tráfico sin insertar ninguna puerta trasera de software.
Una segunda explicación alternativa que se presentó fue que el Equation Group utilizó exploits de día cero contra equipos VPN de varios fabricantes que fueron validados por Kaspersky Lab como vinculados al Equation Group [46] y validados por esos fabricantes como exploits reales, algunos de los cuales eran exploits de día cero en el momento de su exposición. [47] [48] [49] Los firewalls Cisco PIX y ASA tenían vulnerabilidades que fueron utilizadas para escuchas telefónicas por la NSA [ cita requerida ] .
Además, las VPN IPsec que utilizan configuraciones de "Modo agresivo" envían un hash de la PSK sin cifrar. Esto puede ser, y aparentemente lo es, el objetivo de la NSA mediante ataques de diccionario fuera de línea . [45] [50] [51]
Se prefiere la ortografía "IPsec" y se utiliza en este y todos los estándares IPsec relacionados. Todas las demás mayúsculas de IPsec [...] están obsoletas.