Principio de intercambio de claves IKE
El establecimiento manual de una SA tiene las desventajas de una configuración complicada, no admite cambios dinámicos de la dirección del iniciador, nunca caduca y no favorece la seguridad. Esta sección presenta 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 generan automáticamente, pero en el modo manual, deben especificarse por separado de acuerdo con las direcciones de salida y entrada de SA.
(2) Proporciona función anti-repetición. IPSec utiliza el número de secuencia en el encabezado AH o ESP para implementar la prevención de 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 (ha alcanzado el valor máximo y no se puede numerar hacia abajo, lo que requiere una nueva ronda de renumeración), para evitar la repetición, es necesario restablecer la SA. Este proceso requiere. la cooperación del protocolo IKE, por lo que la función anti-repetición no es compatible en modo manual.
(3) Admitir cambios dinámicos en la dirección del iniciador de la negociación (como PPP). Acceso por marcado electrónico a Internet), el modo manual no es compatible y solo se puede aplicar en situaciones en las que ambos extremos están conectados a Internet a través de líneas dedicadas.
(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), lo que favorece la implementación a gran escala de IPSec, pero el modo 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.
SA caducará cuando el ciclo de vida alcance el tiempo especificado o el proceso especificado. Antes de que expire la SA, 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 (Internet Security Association and Key Management Protocol). Es un protocolo de capa de aplicación basado en UDP (correspondiente al puerto UDP500). Proporciona servicios para negociar e intercambiar claves automáticamente y establecer SA para IPSec, lo que puede simplificar el uso y la gestión de IPSec.
De hecho, IKE no es un protocolo separado. Incluye tres protocolos: isakmp (Protocolo de administración de claves y asociación de seguridad de Internet), oakley (protocolo de determinación de claves de Oakley, protocolo de determinación de claves de Aulick) y skeme (seguro de Internet). mecanismo de intercambio de claves). ISAKMP define principalmente 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 además de UDP (AH y ESP son protocolos de capa de red) y es el protocolo de señalización de IPSec. IKE negocia el establecimiento de una SA para IPSec y entrega los parámetros establecidos y las claves generadas a IPSec; utiliza la SA establecida por IKE para cifrar o verificar mensajes IP.
Después de que IKE SA se establece entre pares, cuando IKE SA protege el túnel IPSec, se negocia un par de SA IPSec en función de parámetros de configuración como los protocolos de seguridad AH y ESP para uso de los pares en el Túnel IPSec. Transmisión segura de datos entre.
El protocolo IKE actualmente tiene dos versiones: IKEv1 e IKEv2.
La versión IKEv1 utiliza dos fases para negociar claves para IPSec y, en última instancia, establecer IPSec SA. En la primera etapa, las partes comunicantes negocian para establecer un canal seguro (túnel) utilizado por el propio IKE, es decir, se establecen un par de SA de IKE. En la segunda fase, se establecen un par de SA IPSec, utilizando este canal seguro a través de autenticación y protección de seguridad 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 echemos un vistazo a algunos de los mecanismos de seguridad utilizados por IKE en el proceso de generación de SA (incluidos IKE SA e IPSec SA. El proceso de negociación de IKE específico se utilizará más adelante).
La razón importante por la que las soluciones de aplicaciones IPSec pueden comunicarse de forma segura en redes públicas (como Internet) es que pueden obtener el soporte de varios mecanismos de seguridad durante todo el proceso de establecimiento de túneles y transmisión de datos entre pares. Asegurar. En este sentido, también se puede lograr el intercambio y la negociación automáticos de claves si se utiliza IKE, porque el propio IKE tiene un mecanismo de autoprotección que puede realizar de forma segura la autenticación de identidad y la distribución de claves en una red insegura. 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. En IKE, los mecanismos que se pueden utilizar para determinar la identidad del par (la dirección IP o el nombre del par) son relativamente completos, incluida la autenticación de clave precompartida PSK (clave precompartida), el certificado digital rsa (rsa- (firma o firma digital RSA) 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 pública del destinatario para firmar simétricamente. el mensaje. La clave se cifra (esta parte se llama sobre digital) y luego la clave simétrica cifrada y el mensaje firmado digitalmente se envían al destinatario. 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 un par corresponde a varios pares, es necesario configurar una clave precompartida para cada par, lo que requiere una gran carga de trabajo, por lo que este método es fácil de configurar. en redes pequeñas, pero menos seguras. El uso de certificados digitales es muy seguro, pero requiere que una CA emita un certificado digital, que es adecuado para su uso en redes grandes. La autenticación de sobre digital se utiliza cuando el dispositivo necesita cumplir con los requisitos de la Administración Estatal de Criptozoología (se requiere el algoritmo hash SM3 requerido por la Administración Estatal de Criptozoología). Este método de autenticación solo puede admitirse durante el proceso de negociación del modo principal de IKEv1.
Las claves utilizadas para la autenticación 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 bits, 384 bits y 512 bits respectivamente. y SM3 utiliza una clave de 12 bits. El orden de seguridad de mayor a menor es: sm3 > SHA2-512 gt; SHA2-384 gt; SHA2-256 gt; sha 1 gt; para requisitos generales de seguridad, se recomienda utilizar SHA2-256, SHA2-384. y SHA2-512 se utilizan para algoritmos de autenticación, mientras que MD5 y SHA1 están en desuso. Para lugares con requisitos de seguridad especialmente altos, se puede utilizar el algoritmo SM3.
Las claves de autenticación mencionadas anteriormente (incluidas las claves precompartidas y las claves públicas/privadas) y los certificados se envían a la otra parte para su verificación de la manera correspondiente como los "datos de verificación" del remitente.
El mecanismo de cifrado de datos de IPSec se utiliza principalmente en dos aspectos: primero, para proteger la información de datos transmitida utilizada para la autenticación de identidad (como * * * claves compartidas, certificados, claves de autenticación, etc.) en IKE durante la fase de negociación, la otra es proteger los datos del usuario transmitidos en el túnel después de que se establece el túnel IPSec. Sin embargo, el mecanismo de cifrado de datos mencionado aquí utiliza un mecanismo de clave simétrica, es decir, 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. 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 65442. El orden de los niveles de seguridad de estos algoritmos de cifrado de mayor a menor es: sm4 > SMI 1 gt AES-256 gt AES-192 > AES-128 > 3DES gt DES recomendado, AES-256, AES-192 y AES-128, pero No se recomiendan los algoritmos 3DES y DES. SM1 y SM4 solo se recomiendan para su uso en lugares con requisitos de confidencialidad y seguridad muy altos debido a su lenta velocidad de operación. Los sistemas de claves asimétricas suelen utilizar algoritmos de cifrado RSA o DSA (Algoritmo de firma digital).
El algoritmo Diffie-Hellman es un algoritmo de clave pública. Las 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 será suficiente para calcular la clave real.
DH se utiliza principalmente para regenerar la clave utilizada por el nuevo IPSec SA durante la negociación dinámica IKE, porque finalmente puede calcular la clave compartida por ambas partes a través de una serie de intercambios de datos, sin depender de la generación anterior. Materiales de generación clave. Sin embargo, DH no proporciona ninguna información sobre las identidades de ambas partes, por lo que es imposible determinar si los datos intercambiados serán enviados a la parte legítima. Un tercero puede disfrutar de la comunicación a través de los datos interceptados negociando claves con ambas partes para obtener y transmitir información. Por lo tanto, IKE también requiere autenticación de identidad para autenticar la identidad del par.
PFS (Perfect Forward Secrecy) es una característica de seguridad, lo que significa que después de descifrar una clave, no afectará la seguridad de otras claves porque no existe una relación derivativa entre estas claves.
Como se puede ver en la introducción más adelante en este capítulo, la clave de IPSec SA se deriva de la clave de IKE SA. Dado que una negociación IKE SA puede generar uno o más pares de IPSec SA con cierta derivación, cuando se roba la clave IKE, un atacante puede derivar ilegalmente la clave IPSec SA recopilando suficiente información, lo cual no es seguro. Si PFS está habilitado durante la fase de generación de IPSec, se puede generar una nueva SA IPSec independiente realizando intercambios DH adicionales, garantizando así la seguridad de la clave SA IPSec.
Como se mencionó anteriormente, generar el IPSecSA final de la versión IKEvl requiere dos etapas, 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 IKESA de los pares. Durante esta fase, los pares IKE se autentican entre sí y determinan la misma clave de sesión. Esta fase requiere el algoritmo Diffie-Hellman (DH) para el intercambio de claves para completar el establecimiento de IKE SA, de modo que el proceso de negociación en la segunda fase esté protegido de forma segura.
En la versión IKEvl, existen dos modos de intercambio en el proceso de establecimiento de IKE SA: modo principal y modo de agregación. Se presentan a continuación.
En el proceso de establecimiento de IKE SA en el modo principal IKEv1, hay tres intercambios de mensajes bidireccionales y se utilizan seis piezas de información. El proceso de intercambio se muestra en la figura.
Estos seis mensajes son en realidad tres pasos, y cada paso contiene dos mensajes con números adyacentes.
El primer paso corresponde a los mensajes ① y ②, lo que significa que los pares en ambos extremos del túnel acuerdan la política de seguridad IKE que adoptarán entre sí intercambiando las políticas IKE configuradas entre sí. porque solo ambas partes adoptan la misma política de seguridad. Solo así se podrán identificar los datos cifrados de la otra parte y autenticar correctamente la identidad de la otra parte.
El segundo paso corresponde a los mensajes ③ y ④, es decir, los peers intercambian información de parámetros (valor público DH y nonce, etc.) A través del algoritmo DH se generan una serie de * * * claves compartidas que son Se establecen las mismas en ambos extremos, incluyendo principalmente la clave de autenticación de identidad utilizada para la negociación de la segunda fase y la clave de cifrado de los datos de negociación.
El tercer paso corresponde a los mensajes ⑤ y ⑤, utilizando la clave de cifrado creada previamente para cifrar su identidad (como la dirección IP o el nombre del par) y los datos de autenticación (como la contraseña en el método de autenticación utilizado) Los datos de clave o certificado) se envían a la otra parte y se utiliza 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 del intercambio formal de mensajes, el iniciador y el receptor primero deben calcular sus propias cookies (en el encabezado ISKMP para evitar la reproducción y los ataques DoS). Estas cookies se utilizan para identificar cada mensaje de intercambio individual. 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 la cookie. La cookie se convierte en el identificador único de la información intercambiada en la negociación IKE. La Cookie en la versión IKEv1 y la Cookie en la versión IKEv2 son el SPI (Índice de parámetros de seguridad) de IKE.
La siguiente es una introducción detallada a los seis mensajes mencionados anteriormente.
Como se muestra en la figura, el modo salvaje utiliza sólo tres datos. Los mensajes ① y ② se utilizan para negociar políticas de seguridad IKE entre pares e intercambiar claves públicas DH, información auxiliar necesaria e información de identidad (generalmente no identificada por direcciones IP, sino por nombres de host).
En comparación con el modo principal, se puede encontrar que el modo salvaje reduce la cantidad de información intercambiada y aumenta la velocidad de negociación, pero no cifra la información de identidad y los datos de autenticación porque ambas partes envían información de identidad. No hay cifrado (correspondiente a los mensajes ① y ②) (pero la información de identidad y los datos de autenticación enviados en el modo principal están cifrados, correspondientes a los mensajes ⑤ y ⑤). Aunque el Modo Salvaje no proporciona protección de identidad, aún puede satisfacer las necesidades de algunos entornos de red específicos.
Cuando hay un dispositivo NAT en el túnel IPSec, la función transversal de NAT debe habilitarse para cambiar la dirección IP del extremo opuesto. Dado que el modo salvaje no depende de la identificación de la dirección IP, el cruce de NAT solo se puede lograr en modo salvaje mediante el uso de autenticación de clave previamente compartida. Si la dirección P del iniciador no es fija o impredecible, y ambas partes quieren usar la autenticación de clave previa para crear una IKE SA, solo pueden usar el modo agresivo.
Si el iniciador conoce la política del respondedor o tiene un conocimiento integral de la política del respondedor, se puede utilizar el modo agresivo para crear una IKE SA más rápido.
La segunda etapa de ikev1 es establecer finalmente un par de sa basado en la primera etapa. La primera etapa tiene solo un modo, es decir, el 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 del modo rápido, se determinan principalmente las siguientes políticas de seguridad IPSec:
Después de llegar a un acuerdo sobre los aspectos anteriores, se establecerán dos SA PSec, respectivamente para entrada y salida. comunicación de salida.
Las recomendaciones de seguridad de IPSec en los mensajes ① y ② incluyen protocolos de seguridad, spi, modo de encapsulación IPSec, PfS (opcional), vida útil de IPSec SA, etc. Estos dos mensajes también incluyen la información de identidad de ambas partes (como la dirección IP y el puerto de la capa de transporte), datos de verificación (incluida la clave y el certificado en el mecanismo de autenticación utilizado), etc. ) y nonce (un número aleatorio utilizado para evitar la repetición, también utilizado como material para la generación de contraseñas, solo utilizado cuando PFS está habilitado).
El destinatario utilizará los datos de la contraparte recibidos para generar la clave de cifrado y el mensaje ③ es un mensaje de confirmación. Al confirmar que el remitente ha recibido el mensaje en esta etapa ②, el respondedor 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. Al tiempo que garantiza la seguridad, IKEv2 reduce la cantidad de mensajes transmitidos e intercambiados, lo que facilita su implementación.
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 del protocolo IKEv2. A diferencia de IKEV1, todos los mensajes en IKEv2 aparecen en pares en forma de "solicitud-respuesta" y 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 debe retransmitir el mensaje, lo que puede mejorar la seguridad.
IKEv2 también puede defenderse contra ataques de denegación de servicio. En IKEv1, cuando un atacante en la red reproduce mensajes continuamente, es necesario calcular el respondedor antes de responder, lo que consume recursos del dispositivo y provoca un ataque DoS en el respondedor. En KEv2, el respondedor no se apresura a calcular después de recibir la solicitud, sino que primero envía una carga útil de notificación de tipo cookie (es decir, un valor específico) al iniciador. La comunicación entre los dos debe mantener la relación entre Fcookie y el iniciador. defenderse eficazmente contra ataques DoS.
IKEv2 define tres tipos de intercambios: intercambio inicial, intercambio de protocolo de creación de subservicio (Create _Child _SA exchange) e intercambio de información. IKEv2 puede completar la negociación y el establecimiento de IKE SA y el primer par de IPSec SA mediante el intercambio inicial. Si es necesario 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 la sub-SA debe pasar por dos etapas).
El intercambio inicial de IKEv2 corresponde a la primera fase de IKEv1. El intercambio inicial consta de cuatro mensajes intercambiados dos veces, como se muestra en la figura. Los mensajes ① y ② pertenecen al primer intercambio. Negocian los parámetros de IKE SA en texto plano. Negocian principalmente algoritmos de cifrado, intercambian valores nonce y completan un intercambio DH para generar material de clave cifrado y verificar intercambios posteriores. Los mensajes ③ y ④ pertenecen al segundo intercambio. La autenticación de identidad (intercambiando información de identidad y datos de verificación), la autenticación de los dos primeros mensajes y la negociación de parámetros IPSec SA se completan mediante cifrado.
Una vez completado el intercambio inicial, cualquiera de las partes puede iniciar la creación de un intercambio sub-SA, y el iniciador de este intercambio puede ser diferente del iniciador del intercambio inicial. El intercambio debe ocurrir después de que se complete el intercambio inicial y los mensajes de intercambio están protegidos por las claves negociadas en el intercambio inicial.
El intercambio para crear sub-SA contiene dos mensajes, que se utilizan para renegociar la creación de múltiples SA IPSec o IKE a partir de una SA IKE, correspondiente a la segunda fase de IKEv1. Si necesita admitir PFS, puede crear un intercambio sub-SA para realizar intercambios DH adicionales y establecer una nueva clave que se atreva a establecer una SA IPSEC.
Durante el proceso de negociación clave entre las partes que se comunican, es posible que una parte desee enviar información de control a la otra para notificar la ocurrencia de ciertos errores o eventos. Esto debe completarse a través del "proceso de intercambio de notificaciones". .
Como se muestra en la Figura 2-15, el intercambio de notificaciones se utiliza para transmitir cierta información de control entre pares, como información de error, información 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 no puede contener ninguna carga útil. Los intercambios de notificaciones solo pueden ocurrir después del intercambio inicial, y su información de control puede ser IKE SA (el intercambio está protegido por IKES A) o sub-SA (el intercambio está protegido por sub-SA).