En informática , Internet Protocol Security ( IPsec ) es un conjunto de protocolos de red seguros que autentica y cifra 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 negociación de claves criptográficas a utilizar durante la sesión. IPsec puede proteger los flujos de datos entre un par de hosts ( host a host ), entre un par de puertas de enlace de seguridad ( red a red ) o entre una puerta de enlace de seguridad y un host ( red a 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 ( cifrado ) y protección de reproducción (protección contra ataques de reproducción ).
A principios de la década de 1970, la Agencia de Proyectos de Investigación Avanzada patrocinó una serie de dispositivos de cifrado ARPANET experimentales , al principio para el cifrado de paquetes ARPANET nativo y posteriormente para el cifrado de paquetes TCP/IP ; algunos de ellos fueron certificados y puestos en servicio. 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 aproximadamente en 1988 por el NIST y, de estos, el Protocolo de seguridad en la capa 3 (SP3) eventualmente se transformaría en el estándar ISO Red. Protocolo de seguridad de capa (NLSP). [3]
En 1992, DARPA CSTO financió el Laboratorio de Investigación Naval de EE. UU. (NRL) para implementar IPv6 e investigar e implementar el cifrado de IP en 4.4 BSD , compatible con arquitecturas de CPU SPARC y x86. DARPA puso su implementación a disposición gratuita a través del MIT. En el marco del esfuerzo de investigación financiado por DARPA de NRL , NRL desarrolló las especificaciones de seguimiento de estándares IETF (RFC 1825 a RFC 1827) para IPsec. [4] La implementación de IPsec de NRL se describió en su artículo en las Actas de la Conferencia USENIX de 1996 . [5] El MIT puso a disposición en línea la implementación IPsec de código abierto de NRL y se convirtió en la base para la mayoría de las implementaciones comerciales iniciales. [6]
El Grupo de Trabajo de Ingeniería de Internet (IETF) formó el Grupo de Trabajo de Seguridad IP en 1992 [7] para estandarizar extensiones de seguridad de IP abiertamente especificadas, llamadas IPsec . [8] En 1995, el grupo de trabajo organizó algunos de los talleres con miembros de las cinco empresas (TIS, Cisco , FTP, Checkpoint, etc.). Durante los talleres de IPsec, los estándares de NRL y el software de Cisco y TIS se estandarizan como referencias públicas, publicadas como RFC-1825 a RFC-1827. [9]
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 algunos otros sistemas de seguridad de Internet de uso generalizado operan por encima de la capa de red , como Transport Layer Security (TLS) que opera por encima de la capa de transporte y Secure Shell (SSH) que opera 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 diversas funciones: [10] [11]
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 anteriores del IETF para la autenticación de la versión 2 del Protocolo simple de administración de red (SNMP). miembro del conjunto de protocolos IPsec. AH garantiza la integridad sin conexión mediante el uso de una función hash y una clave secreta compartida 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 , [19] [20] utilizando la técnica de ventana deslizante y descartando paquetes antiguos.
AH opera directamente sobre IP, utilizando el protocolo IP número 51 . [21]
El siguiente diagrama de paquetes AH muestra cómo se construye e interpreta un paquete AH: [12] [13]
La carga útil de seguridad encapsulante (ESP) IP [22] 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 IETF SIPP [23], redactado en diciembre de 1993 como una seguridad. extensión para SIPP. Este ESP se derivó originalmente del protocolo SP3D del Departamento de Defensa de EE. UU., en lugar de derivarse del Protocolo de seguridad de capa de red (NLSP) ISO. La especificación del protocolo SP3D fue publicada por el NIST a finales de los años 1980, pero diseñada por el proyecto Secure Data Network System del Departamento de Defensa de EE. UU . La carga útil de seguridad encapsulante (ESP) es miembro del conjunto de protocolos IPsec. Proporciona autenticidad del origen mediante la autenticación del origen , integridad de los datos mediante funciones hash y confidencialidad mediante la protección de cifrado para paquetes IP . ESP también admite configuraciones de solo cifrado y solo autenticación , pero se desaconseja encarecidamente el uso de cifrado sin autenticación porque es inseguro. [24] [25] [26]
A diferencia del encabezado de autenticación (AH) , ESP en modo de transporte no proporciona integridad ni autenticación para todo el paquete IP . Sin embargo, en el modo túnel , donde todo el paquete IP original se encapsula con un nuevo encabezado de paquete agregado, se brinda protección ESP a todo el paquete IP interno (incluido el encabezado interno), mientras que el encabezado externo (incluidas las opciones IPv4 externas o la extensión IPv6) encabezados) permanece desprotegido.
ESP opera directamente sobre IP, utilizando el protocolo IP número 50. [21]
El siguiente diagrama de paquetes ESP muestra cómo se construye e interpreta un paquete ESP: [1] [27]
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 variedad 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 particular, para lo cual se debe acordar una vida útil y una clave de sesión . [28]
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 ambos hosts ya poseen una clave simétrica y los hosts se envían entre sí hashes de la clave compartida para demostrar que poseen 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 poseen un certificado de clave pública de una autoridad certificadora , esto se puede utilizar para la autenticación IPsec. [29]
Las asociaciones de seguridad de IPsec se establecen mediante la Asociación de seguridad de Internet y el Protocolo de administración de claves (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 . [18] [30] [31] 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. [32]
Para decidir qué protección se debe proporcionar a un paquete saliente, IPsec utiliza el índice de parámetros de seguridad (SPI), un índice de la base de datos de asociación de seguridad (SADB), junto con la dirección de destino en un encabezado de paquete, que en conjunto identifica de forma ú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 la asociación de seguridad.
Para la multidifusión IP , se proporciona una asociación de seguridad para el grupo y 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 sólo 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 y duplica la asociación en todo el grupo; se supone que una parte responsable habrá hecho la elección.
Para garantizar que la conexión entre dos puntos finales no se haya interrumpido, los puntos finales intercambian mensajes de actividad a intervalos regulares, que también se pueden utilizar para restablecer automáticamente un túnel perdido debido a la interrupción de la conexión.
La detección de pares muertos (DPD) es un método para detectar un par de intercambio de claves de Internet (IKE) muerto. El método utiliza patrones de tráfico IPsec para minimizar la cantidad de mensajes necesarios para confirmar la disponibilidad de un par. DPD se utiliza para recuperar los recursos perdidos en caso de que se encuentre muerto a un par y también se utiliza para realizar la conmutación por error de pares IKE.
UDP keepalive es una alternativa a DPD.
Los protocolos IPsec AH y ESP se pueden implementar en modo de transporte de host a host, así como en modo de túnel de red.
En el modo de transporte, normalmente sólo 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 que describen el mecanismo NAT-T han definido un medio para encapsular mensajes IPsec para el recorrido NAT {NAT-T} .
En 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). [33]
El modo túnel admite el recorrido NAT.
Los algoritmos criptográficos definidos para su uso con IPsec incluyen:
Consulte RFC 8221 para obtener más detalles.
El IPsec se puede implementar en la pila de IP de un sistema operativo . Este método de implementación se realiza para hosts y puertas de enlace de seguridad. Empresas como HP o IBM ofrecen varias pilas de IP con capacidad IPsec. [34] Una alternativa es la llamada implementación de golpe en la pila (BITS), donde no es necesario modificar el código fuente del sistema operativo. Aquí IPsec se instala entre la pila de IP y los controladores de red . De esta manera los sistemas operativos se pueden actualizar con IPsec. Este método de implementación también se utiliza tanto para hosts como para puertas de enlace. Sin embargo, al actualizar IPsec, la encapsulación de paquetes IP puede causar problemas para el descubrimiento automático de MTU de ruta , donde se establece el tamaño máximo de unidad de transmisión (MTU) en la ruta de red entre dos hosts IP. Si un host o puerta de enlace tiene un criptoprocesador separado , que es común en el ejército y también se puede encontrar en sistemas comerciales, es posible una implementación de IPsec denominada " bump-in-the-wire" (BITW). [35]
Cuando se implementa IPsec en el kernel , la gestión de claves y la negociación ISAKMP / IKE se lleva a cabo desde el espacio del usuario. La "API de administración de claves PF_KEY, versión 2", desarrollada por NRL y especificada abiertamente, se usa a menudo para permitir que la aplicación de administració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 kernel. [36] Las implementaciones de IPsec existentes generalmente incluyen ESP, AH e IKE versión 2. Las implementaciones de IPsec existentes en sistemas operativos tipo Unix , por ejemplo, Solaris o Linux , generalmente incluyen PF_KEY versión 2.
Se puede utilizar IPsec integrado para garantizar la comunicación segura entre aplicaciones que se ejecutan en sistemas de recursos limitados con una pequeña sobrecarga. [37]
IPsec se desarrolló junto con IPv6 y originalmente debía ser compatible con todas las implementaciones de IPv6 compatibles con los estándares antes de que RFC 6434 lo convirtiera solo en una recomendación. [38] IPsec también es opcional para implementaciones de IPv4 . IPsec se utiliza más comúnmente para proteger el tráfico IPv4. [ cita necesaria ]
Los protocolos IPsec se definieron originalmente en RFC 1825 a RFC 1829, que se publicaron en 1995. En 1998, estos documentos fueron reemplazados por RFC 2401 y RFC 2412 con algunos detalles de ingeniería incompatibles, aunque eran conceptualmente 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 RFC 4301 y RFC 4309, que son en gran medida un superconjunto de las ediciones anteriores con una segunda versión del estándar de 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 de Mantenimiento y Extensiones de IPsec (ipsecme) está activo en el IETF. [39] [40]
En 2013, como parte de las filtraciones de Snowden , se reveló que la Agencia de Seguridad Nacional de 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 terminales utilizados por los objetivos" como parte del programa Bullrun . . [41] Hay acusaciones de que IPsec era un sistema de cifrado dirigido. [42]
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, trabajando para el FBI, insertaron "una serie de puertas traseras y mecanismos de filtración de claves de canales laterales " en la criptomoneda OpenBSD. código. 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 del reenvío del correo electrónico. [43] Respuesta de Jason Wright a las acusaciones: "Cada leyenda urbana se vuelve más real mediante la inclusión de nombres, fechas y horas reales. El correo electrónico de Gregory Perry cae en esta categoría... Declararé claramente que no agregué puertas traseras a el sistema operativo OpenBSD o el marco criptográfico OpenBSD (OCF)". [44] Algunos días después, de Raadt comentó que "Creo que NETSEC probablemente fue contratado para escribir puertas traseras como se alega... Si se escribieron, no creo que hayan llegado a nuestro árbol". [45] Esto se publicó antes de las filtraciones de Snowden.
Una explicación alternativa presentada 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, [46] alegan que la NSA construyó especialmente un clúster informático para precalcular subgrupos multiplicativos para números primos y generadores específicos, como el segundo grupo Oakley definido en RFC 2409. En mayo de 2015, el 90% de las VPN IPsec direccionables admitían el segundo grupo Oakley como parte de IKE. Si una organización calculara previamente 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 propuso fue que Equation Group utilizó exploits de día cero contra equipos VPN de varios fabricantes que fueron validados por Kaspersky Lab como vinculados a Equation Group [47] 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. [48] [49] [50] Los firewalls Cisco PIX y ASA tenían vulnerabilidades que la NSA utilizó para escuchas telefónicas [ cita necesaria ] .
Además, las VPN IPsec que utilizan la configuración de "Modo agresivo" envían un hash del PSK sin cifrar. Esto puede ser y aparentemente es el objetivo de la NSA mediante ataques de diccionario fuera de línea . [46] [51] [52]
{{cite book}}: Mantenimiento CS1: fecha y año ( enlace )Se prefiere y se utiliza la ortografía "IPsec" en este y en todos los estándares IPsec relacionados. Todas las demás mayúsculas de IPsec [...] están en desuso.