Principio de intercambio de claves IKE

Cuando se utiliza la negociación dinámica IKE para establecer un túnel IPSec, existen dos tipos de SA: uno es IKE SA y el otro es IPSec SA. El propósito de establecer IKE SA es negociar un conjunto de parámetros de seguridad utilizados para proteger los túneles IPSec. Sin embargo, en el modo de negociación dinámica de IKE, IKE SA es la base. de IPSec SA, debido a que el establecimiento de IPSec SA requiere de una serie de claves luego de establecido el IKE SA.

El establecimiento manual de una SA tiene las desventajas de una configuración compleja, que no admite cambios dinámicos de la dirección del iniciador, que la SA establecida nunca envejece y que es perjudicial para la seguridad. Esta sección detalla los beneficios de la negociación dinámica y la relación entre IKE e IPSec.

(1) Reduce la complejidad de la configuración. En el modo de negociación dinámica IKE, parámetros como SPI, clave de autenticación y clave de cifrado se generarán automáticamente, mientras que en modo manual, parámetros como la dirección saliente y entrante. de la SA deben generarse automáticamente. Las instrucciones se especifican por separado.

(2) Proporciona función anti-reproducción. IPSec utiliza el número de secuencia en el encabezado AH o ESP para implementar la anti-reproducción (no se aceptan paquetes con el mismo número de secuencia). Cuando el número de secuencia en el encabezado AH o ESP se desborda (también alcanza el valor máximo y no puede continuar numerándose, y comienza una nueva ronda de renumeración), para lograr la antirreproducción, es necesario restablecer la SA Este proceso requiere junto con el protocolo IKE, la función anti-reproducción no es compatible en modo manual.

(3) Admite la autenticación de identidad cuando la dirección del iniciador de la negociación cambia dinámicamente (como usar el modo de acceso telefónico PPP.E para acceder a Internet). El método manual no es compatible y solo se puede aplicar. a líneas dedicadas en ambos extremos. El método de conexión es acceder a Internet.

(4) Admite la autenticación en línea y la gestión centralizada de identidades de pares por parte del centro de certificación CA (Autoridad de certificación), lo que favorece la implementación a gran escala de IPSec. El método manual no admite la autenticación en línea.

(5) La SA establecida a través de la negociación IKE tiene un ciclo de vida y puede actualizarse en tiempo real, lo que reduce el riesgo de que la SA sea descifrada y mejora la seguridad.

Cuando el ciclo de vida alcanza el tiempo especificado o el tráfico especificado, la SA dejará de ser válida. Antes de que la SA esté a punto de caducar, IKE negociará una nueva SA para el par. Después de negociar la nueva SA, el par adopta inmediatamente la nueva SA para proteger las comunicaciones. Hay dos formas de definir el ciclo de vida:

El protocolo IKE se basa en el marco definido por ISAKMP (Protocolo de administración de claves y asociación de seguridad de Internet) y es una capa de aplicación basada en el protocolo UDP (correspondiente a. El puerto UDP500 proporciona a IPSec intercambio automático de claves de negociación y servicios de establecimiento de SA, lo que puede simplificar el uso y la gestión de IPSec.

De hecho, IKE no es un protocolo separado, incluye tres protocolos principales: ISAKMP. (Asociación de seguridad de Internet y protocolo de administración de claves, Asociación de seguridad de Internet y protocolo de administración de claves), Oakley (Protocolo de determinación de claves de Oakley, Protocolo de determinación de claves de Oakley) y SKEME (Mecanismo de intercambio seguro de claves para Internet, Mecanismo de intercambio de claves de claves de seguridad de Internet principalmente ISAKMP). define la relación de cooperación entre pares de IKE y establece IKE SA.

El protocolo OakLey es un marco para generar e intercambiar materiales de claves IPSec y coordinar los parámetros de IPSec (incluidos los protocolos de seguridad compatibles); el protocolo SKEM E determina el método de intercambio de claves IKE, utilizando principalmente el algoritmo DH (Diffie-Hellman).

La relación entre IKE e IPSec (incluidos los protocolos AH y ESP) se muestra en la siguiente figura. IKE es un protocolo de capa de aplicación por encima de UDP (AH y ESP son protocolos de capa de red) y es el protocolo de señalización de. IPSec. IKE establece una SA para la negociación de IPSec y entrega los parámetros establecidos y las claves generadas a IPSec utiliza la SA establecida por IKE para cifrar o autenticar paquetes de IP.

Después de que se establece una IKE SA entre los pares, y la IKE SA protege el túnel IPSec, se negocia un par de SA IPSec en función del protocolo de seguridad AH, ESP configurado y otros parámetros para el emparejamiento de datos seguros. transmisión entre pares en túneles IPSec.

El protocolo IKE actualmente tiene dos versiones: IKEv1 e IKEv2. La versión IKEv1 utiliza dos fases para realizar la negociación de claves para IPSec y finalmente establecer una SA IPSec. En la primera etapa, las partes que se comunican negocian para establecer un canal seguro (es decir, un túnel) utilizado por el propio IKE, es decir, se establecen un par de SA de IKE. En la segunda etapa, este canal seguro que ha pasado la autenticación y la protección de seguridad se utiliza para establecer un par de SA IPSec para proteger la transmisión segura de datos en el túnel. La versión IKEv2 simplifica el proceso de negociación y puede generar directamente claves IPSec y SA IPSec en una sola negociación.

Primero comprendamos algunos de los mecanismos de seguridad utilizados por IKE en el proceso de generación de SA (incluidos IKE SA e IPSec SA), que se utilizarán más adelante en el proceso de negociación de IKE específico.

La razón importante por la que las soluciones de aplicaciones IPSec pueden realizar comunicaciones de red de forma segura en redes públicas (como Internet) es que se pueden implementar varias medidas de seguridad durante todo el proceso de establecimiento del túnel y transmisión de datos entre pares. se utiliza para garantizar esto. Si IKE se utiliza para el intercambio y la negociación automática de claves, también se puede hacer, porque el propio IKE tiene un conjunto completo de mecanismos de autoprotección que pueden autenticar identidades de forma segura en redes inseguras. Esto se refleja específicamente en los siguientes aspectos de la protección de la seguridad.

Al utilizar IKE para intercambiar información entre pares, primero debe identificar la legitimidad de la otra parte, lo cual es un problema de autenticación de identidad. Los mecanismos que se pueden utilizar para determinar la identidad del par (dirección IP o nombre del par) en IKE son relativamente completos, incluida la autenticación de clave precompartida PSK (clave precompartida), el certificado digital RSA (rsa-signature, o llamado RSA digital firma) autenticación y autenticación de sobre digital RSA.

En un sobre digital, el remitente usa una clave simétrica (el remitente debe generar aleatoriamente una clave simétrica por adelantado) para firmar digitalmente el mensaje que se enviará y luego usa la clave simétrica con el receptor. Al cifrar con la clave pública (esta parte se llama sobre digital), la clave simétrica cifrada se envía al destinatario junto con el mensaje firmado digitalmente. Después de recibirlo, el destinatario primero usa su propia clave privada para abrir el sobre digital y obtener la clave simétrica del remitente, y luego usa la clave simétrica para descifrar el mensaje original firmado digitalmente para verificar si la firma digital del remitente es correcta. Si es correcto, la autenticación pasa; de lo contrario, la autenticación falla.

Para el método de autenticación de clave precompartida, cuando hay un par correspondiente a varios pares, se debe configurar una clave precompartida para cada par. La cantidad es grande, por lo que este método es fácil de usar. establecerse en redes pequeñas, pero es menos seguro. El uso de certificados digitales tiene alta seguridad, pero requiere una CA para emitir certificados digitales, lo cual es adecuado para su uso en redes grandes. La autenticación de sobre digital se utiliza cuando el dispositivo debe cumplir con los requisitos de la Administración Estatal de Criptozoología (debe utilizar el algoritmo hash SM3 requerido por la Administración Estatal de Criptozoología), y este método de autenticación solo puede admitirse durante el proceso de negociación del modo principal. de IKEv1.

Las diversas claves utilizadas para la autenticación de identidad mencionadas anteriormente son todas claves de autenticación IKE. Los algoritmos admitidos son: MD5, SHA1, SHA2-256, SHA2-384, SHA2-512, SM3. El algoritmo MD5 utiliza una clave de 128 bits, el algoritmo SHA-1 utiliza una clave de 160 bits, SHA2-256, SHA2-384 y SHA2-512 utilizan claves de 256, 384 y 512 bits respectivamente. y SM3 utiliza una clave de 128 bits. El orden de seguridad de mayor a menor es: SM3gt; SHA2-512gt; SHA2-384gt; SHA1gt; Para requisitos de seguridad normales, se recomienda utilizar SHA2-256, SHA2-384 y SHA2-512 como algoritmos de autenticación. No se recomiendan MD5 y SHA1. Para lugares con requisitos de seguridad particularmente altos, se puede utilizar el algoritmo SM3.

Las claves de autenticación de identidad mencionadas anteriormente (incluidas las claves precompartidas y las claves públicas/privadas) y los certificados se utilizan como "datos de verificación" del remitente y deben enviarse a la otra parte a través del correspondiente método verificado.

El mecanismo de cifrado de datos de IPSec se utiliza principalmente en dos aspectos: primero, durante la fase de negociación IKE, protege la información de datos transmitida (como claves compartidas, certificados, claves de autenticación, etc.) utilizada para la autenticación de identidad. . clave, etc.), y el segundo es proteger los datos del usuario transmitidos en el túnel después de que se establece el túnel IPSec. Pero el mecanismo de clave simétrica utilizado en el mecanismo de cifrado de datos mencionado aquí significa que se utiliza la misma clave para el cifrado y descifrado, en lugar del sistema de clave asimétrica utilizado en las aplicaciones de autenticación de certificados digitales y firma digital presentado anteriormente.

Los algoritmos de cifrado soportados por IKE incluyen: DES, 3DES, AES-128, AES-192, AES-256, SM1 y SM4, etc. El algoritmo DES utiliza una clave de 56 bits, 3DES utiliza una clave de 168 bits, AES-128, AES-192 y AES-256 utilizan claves de 128, 192 y 256 bits respectivamente, y tanto SM1 como SM4 utilizan claves de 128 bits. claves de bits. Se recomiendan los niveles de seguridad de estos algoritmos de cifrado en orden descendente: SM4 gt; SMI1gt; AES-192 gt; AES-128 gt; 128, 3DES y DES no se recomiendan. SM1 y SM4 solo se recomiendan en lugares con requisitos de confidencialidad y seguridad muy altos porque sus velocidades de operación son relativamente lentas. El algoritmo de cifrado RSA o DSA (Digital Signature Algorithm) se suele utilizar en sistemas de claves asimétricas.

El algoritmo Diffie-Hellman es un algoritmo de clave pública. Las dos partes que se comunican pueden calcular la clave compartida por ambas partes intercambiando solo algunos datos sin transmitir la clave. Y se puede hacer que incluso si un tercero intercepta todos los datos de intercambio utilizados por ambas partes para calcular la clave, no sea suficiente para calcular la clave real.

DH se utiliza principalmente para regenerar la clave utilizada en el nuevo IPSec SA durante la negociación dinámica de IKE, porque finalmente puede calcular la clave compartida por ambas partes a través de una serie de intercambios de datos sin depender del material de generación de claves. generado en la etapa anterior. Sin embargo, DH no proporciona ninguna información sobre las identidades de ambas partes y no puede determinar si los datos intercambiados se envían a la parte legítima. El tercero puede utilizar los datos interceptados para negociar la clave con ambas partes que se comunican y disfrutar de la comunicación. obtener y transmitir información, por lo que la autenticación de identidad IKE también es necesaria para autenticar la identidad del par.

PFS (Perfect Forward Secrecy, seguridad directa perfecta) es una característica de seguridad que significa que después de descifrar una clave, no afecta la seguridad de otras claves porque no hay derivación entre estas claves.

Como puede ver en la introducción más adelante en este capítulo, la clave IPSec SA se deriva de la clave IKE SA. Dado que una negociación IKE SA puede generar uno o más pares de IPSec SA que tienen una determinada relación de derivación, cuando se roba la clave IKE, es probable que el atacante derive ilegalmente la clave IPSec SA recopilando suficiente información, por lo que ya no es segura. . Si PFS está habilitado durante la fase de generación de IPSec, se puede generar una nueva SA IPSec independiente realizando un intercambio DH adicional, garantizando así la seguridad de la clave SA IPSec.

Como se mencionó anteriormente, la versión IKEvl necesita pasar por dos etapas para generar el IPSecSA final, que se utilizan para establecer IKESA e IPSecSA respectivamente. Esta sección presenta primero la primera etapa.

El objetivo final de la primera fase de IKEvl es crear un canal seguro entre pares y establecer el IKESA de los pares. En esta fase, los pares IKE se autentican entre sí y determinan la misma clave de sesión. En esta etapa, es necesario utilizar el algoritmo Diffie-Hellman (DH) para intercambiar claves y completar el establecimiento de IKE SA, de modo que el proceso de negociación posterior en la segunda etapa esté protegido de forma segura.

En la versión IKEvl, el proceso de establecimiento de IKE SA tiene dos modos de intercambio: Modo Principal y Modo Agresivo (también llamado "modo agresivo"). Se presentan a continuación.

El proceso de establecimiento de IKE SA en el modo principal de IKEv1 incluye tres intercambios de mensajes bidireccionales y utiliza seis piezas de información. El proceso de intercambio se muestra en la figura.

Estos seis mensajes son en realidad tres pasos en total, cada uno de los cuales contiene dos mensajes numerados adyacentes.

El primer paso corresponde a los mensajes ① y ②, que es cuando los pares en ambos extremos del túnel negocian la política de seguridad IKE a adoptar intercambiando las políticas IKE configuradas entre sí, porque solo dos partes Sólo adoptando la misma política de seguridad podrán identificar los datos cifrados de cada uno y autenticar correctamente la identidad de cada uno.

El segundo paso corresponde a los mensajes ③ y ④, que son la información de parámetros requerida para la generación de claves entre pares a través del algoritmo DH (valor público DH y número aleatorio nonce, etc.), estableciendo una serie de mensajes compartidos. claves que son iguales en ambos extremos, incluyendo principalmente la clave de autenticación de identidad utilizada para la negociación en la segunda fase y la clave de cifrado para los datos de negociación.

El tercer paso corresponde a los mensajes ⑤ y ⑥, utilizando las claves de cifrado creadas previamente para enviarse entre sí sus respectivas identidades (como la dirección IP o el nombre del par) y datos de verificación (la clave utilizada en el método de autenticación de identidad, o datos de certificado, etc.), utilice el método de autenticación correspondiente para realizar la autenticación de identidad entre pares. Finalmente se completa la constitución de IKE SA.

Antes de intercambiar mensajes formalmente, el iniciador y el receptor primero deben calcular sus respectivas cookies (en el encabezado ISKMP para evitar la repetición y los ataques DoS). Estas cookies se utilizan para identificar a cada individuo para negociar e intercambiar mensajes. El RFC recomienda cifrar la dirección IP de origen/destino, el número de puerto de origen/destino, el número aleatorio generado localmente, la fecha y la hora para generar una cookie. La cookie se convierte en el identificador único para la información intercambiada en la negociación IKE. En la versión IKEv1, es Cookie. En la versión IKEv2, la cookie es IKE SPI (Índice de parámetros de seguridad).

La siguiente es una introducción detallada a los seis mensajes mencionados anteriormente.

Como se muestra en la figura, el modo agresivo solo utiliza tres piezas de información. Los mensajes ① y ② se utilizan para negociar políticas de seguridad IKE entre pares, intercambiar claves públicas DH, información auxiliar necesaria e información de identidad (generalmente no). identificado por dirección IP, sino por nombre de host).

Al comparar el modo agresivo y el modo principal, se puede encontrar que, en comparación con el modo principal, el modo agresivo reduce la cantidad de información intercambiada y aumenta la velocidad de negociación, pero no cifra la información de identidad. y datos de verificación, porque la información de identidad enviada por ambas partes (correspondiente a los mensajes ① y ②) no está cifrada (pero la información de identidad y los datos de verificación enviados en el modo principal están cifrados, correspondientes a los mensajes ⑤ y ⑥). Aunque el modo agresivo no proporciona protección de identidad, aún puede satisfacer las necesidades de ciertos entornos de red.

Cuando hay un dispositivo NAT en el túnel IPSec, la función transversal de NAT debe estar habilitada y la conversión de NAT cambiará la dirección IP del par, ya que el modo agresivo no depende de la dirección IP. para identificar la identidad, si es anterior* **Cuando se utiliza el método de verificación de clave compartida, el recorrido NAT solo se puede lograr en modo agresivo. Si la dirección P del iniciador no es fija o impredecible, y ambas partes desean utilizar el método de verificación de clave precompartida para crear una IKE SA, solo pueden usar el modo agresivo.

Si el iniciador conoce la política del respondedor o tiene un conocimiento completo de la política del respondedor, se puede utilizar el modo agresivo para crear una SA IKE más rápido.

ikev1 versión 1 La segunda etapa Es finalmente establecer un par de SA basadas en la primera etapa. Tiene un solo modo, Modo Rápido. La negociación en modo rápido está protegida por SA y todo el proceso de negociación se muestra en la figura.

Durante el proceso de negociación en modo rápido se determinan principalmente las siguientes políticas de seguridad IPSec:

Tras llegar a un acuerdo sobre los aspectos anteriores, se establecerán dos SA PSec, una para Inbound y otra para comunicaciones salientes.

Las propuestas de seguridad IPSec en los mensajes ① y ② incluyen protocolos de seguridad, spi, modo de encapsulación IPSec, PfS (opcional), ciclo de vida IPSec SA, etc. Estos dos mensajes también incluyen la información de identidad de ambas partes (como la dirección IP, el puerto de la capa de transporte), datos de verificación (incluidas claves, certificados, etc. en el mecanismo de autenticación de identidad utilizado) y nonce (un número aleatorio, utilizado para resistir Replay, también usado como material de generación de contraseñas, solo usado cuando PFS está habilitado). La parte receptora utilizará los datos recibidos de la otra parte para generar una clave de cifrado. El mensaje ③ es un mensaje de confirmación. Al confirmar que el remitente ha recibido el mensaje ② en esta etapa, la parte que responde sabe que es posible una comunicación formal.

IKEv1 necesita pasar por dos etapas e intercambiar al menos 6 mensajes antes de establecer finalmente un par de SA PSec. Sin embargo, IKEv2 reduce la cantidad de información transmitida e intercambiada al mismo tiempo que garantiza la seguridad, lo que facilita su implementación. Simple.

IKEv2 conserva la mayoría de las características de IKEv1, y algunas características extendidas de IKEv1 (como el recorrido NAT) se introducen en el marco de IKEv2 como parte integral del protocolo IKEv2. A diferencia de IKEV1, todos los mensajes en IKEv2 aparecen en pares en forma de "solicitud-respuesta". El respondedor debe confirmar el mensaje enviado por el iniciador. Si el mensaje de confirmación no se recibe dentro del tiempo especificado, el iniciador necesita Los paquetes. se retransmiten para mejorar la seguridad.

IKEv2 también puede defenderse contra ataques DoS. En IKEv1, cuando el atacante en la red sigue reproduciendo el mensaje, el respondedor debe responder después del cálculo, lo que consume recursos del dispositivo y provoca un ataque DoS en el respondedor. En KEv2, después de recibir la solicitud, el respondedor no tiene prisa por calcular, pero primero envía una carga útil de notificación de tipo cookie (es decir, un valor específico) al iniciador. La comunicación posterior entre los dos debe mantener la relación entre Fcookie y el iniciador. iniciador. La relación correspondiente entre ellos previene eficazmente los ataques DoS.

IKEv2 define tres tipos de intercambio: Intercambios iniciales (InitialExchanges), Crear intercambio SA secundario (Create _Child _SA Exchange) e Intercambio de notificaciones (InformationalExchange).

IKEv2 puede completar la negociación y el establecimiento de una SA IKE y el primer par de SA IPSec a través de intercambios iniciales. Si se requiere establecer más de un par de SA IPSec, cada par de valores de SA IPSec solo debe agregarse una vez para crear un intercambio sub-SA (y si se usa IKEv1, la creación de sub-SA aún necesita pasar por dos etapas).

El intercambio inicial de IKEv2 corresponde a la primera fase de IKEv1. El intercambio inicial incluye dos intercambios de cuatro mensajes, como se muestra en la figura. Los mensajes ① y ② pertenecen al primer intercambio. Completan la negociación de parámetros de IKE SA en texto plano. Negocian principalmente algoritmos de cifrado, intercambian valores nonce y completan un intercambio DH para generar materiales clave para el cifrado y verificación de intercambios posteriores. Los mensajes ③ y ④ pertenecen al segundo intercambio, que completa la autenticación de identidad de forma cifrada (mediante el intercambio de información de identidad y datos de verificación), la autenticación de los dos primeros datos y la negociación de parámetros de IPSec SA.

Una vez completado el intercambio inicial, cualquier parte puede iniciar la creación de un intercambio sub-SA. El iniciador de este intercambio puede ser diferente del iniciador del intercambio inicial. Este intercambio debe ocurrir después de que se haya completado el intercambio inicial y los mensajes de intercambio estén protegidos por las claves negociadas en el intercambio inicial.

El intercambio Create Sub-SA contiene dos mensajes, que se utilizan para crear múltiples SA IPSec para una SA IKE o renegociar IKE, correspondiente a la segunda fase de IKEv1. Si necesita admitir PFS, cree un intercambio sub-SA y realice un intercambio DH adicional para establecer una nueva clave que se atreva a establecer una SA IPSEC.

Durante la negociación clave entre las partes que se comunican, es posible que una de las partes desee enviar información de control a la otra para notificar la ocurrencia de ciertos errores o eventos. Esto debe completarse mediante el "proceso de intercambio de notificaciones". "

El intercambio de notificaciones, como se muestra en la Figura 2-15, se utiliza para transmitir cierta información de control entre pares, como información de error, mensajes de eliminación o información de notificación. La parte que recibe el mensaje de información debe responder, y el mensaje de respuesta puede no contener información. Contiene ninguna carga útil. El intercambio de notificación solo puede ocurrir después del intercambio inicial, y su información de control puede ser de la IKE SA (el intercambio está protegido por IKES A) o de la sub-SA (. el intercambio está protegido por la sub-SA).