Estaba haciendo IPsec VPN en ASA 8.0, y entiendo un poco sobre eso. El iniciador comienza enviando su política ISAKMP al respondedor, y el respondedor devuelve la política coincidente. Después de eso, la clave Diffie-Hellman se intercambia, y luego ambas envían la clave previamente compartida a la otra para la autenticación.
Ahora tenemos dos claves:
¿Qué clave se usa para cifrar la clave precompartida?
Has hecho una gran pregunta. La pregunta parece muy simple, pero en realidad la respuesta es algo más compleja. Haré todo lo posible para responderlo de manera sucinta. Además, dado que mencionó ISAKMP, voy a asumir que está interesado en IKEv1. Las cosas cambian un poco para IKEv2 (bueno, mucho), pero quería mencionar que la respuesta a continuación solo se correlaciona con IKEv1.
La fase 1 se puede lograr en dos modos diferentes: modo principal y modo agresivo. En cualquiera de los modos, el iniciador envía el primer mensaje y el respondedor envía el segundo mensaje. Ambos mensajes incluyen lo que se conoce en el mundo de la criptografía como Nonce . Un Nonce es simplemente un número generado aleatoriamente para usar en la generación de claves. (el término Nonce proviene de _N_umber utilizado _Once_) . Entonces, después del mensaje 1 y el mensaje 2, ambos lados conocen el Nonces del otro.
Los Nonce se combinan con la clave precompartida para crear un valor de semilla para generar claves secretas. La parte relativa del IKE RFC está aquí:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID es el valor de semilla que luego se utilizará para generar claves secretas adicionales. La clave precompartida y los dos valores de Nonce (Ni_b es el Nonce del iniciador y Nr_B es el Nonce del respondedor) se combinan mediante una función aleatoria PRU o Psuedo. Un PRF es como un algoritmo de hash, excepto que el resultado puede ser tantos bits como sea necesario.
Ahora, si inicialmente estaba haciendo Modo Principal, los mensajes 3 y 4 comparten las claves públicas Diffie-Hellman del Iniciador y del Respondedor (respectivamente). Ambos usan estos valores para generar el secreto compartido de Diffie-Hellman . Si estaba haciendo el modo agresivo, estos valores públicos de DH también se incluyen en el mensaje 1 y el mensaje 2 (junto con el Nonces).
El valor de la semilla se combina con el secreto compartido de DH (y algunos otros valores) para crear tres claves de sesión : una clave de derivación, una clave de autenticación y una clave de cifrado. El RFC lo declara como tal:
El resultado del modo principal o el modo agresivo son tres grupos de material de claves autenticado:
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d, _a y _e son las tres claves de sesión mencionadas anteriormente. SKEYIDes el valor de la semilla. g^xyes el secreto compartido de DH. CKY-Iy CKI-Rson las cookies de iniciador y respondedor, estos son solo valores adicionales generados aleatoriamente que se utilizan más adelante para identificar esta asociación de seguridad y de intercambio ISAKMP en particular. 0 1 2son los números literales 0, 1 y 2. El símbolo Pipe |representa la concatenación.
En cualquier caso, todos estos valores se combinan mediante un PRF que crea tres claves de sesión:
La clave de autenticación y la clave de cifrado se utilizan para asegurar / cifrar la negociación de la fase 2 resultante. En el modo principal, los mensajes 5 y 6 de la fase 1 también están protegidos por estas teclas. Además, cualquier intercambio de información de ISAKMP en el futuro (DPD, eventos Rekey, Eliminar mensajes, etc.) también está protegido por estas dos claves.
La clave derivada se entrega a IPsec, e IPsec genera su propio material de clave a partir de esta clave. Si recuerda, IPsec no incluye de forma innata un mecanismo de intercambio de claves, por lo que la única forma de adquirir claves secretas es configurarlas manualmente (lo cual es arcaico, y realmente nunca se hace), o depender de un servicio externo para proporcionar el material de claves, como ISAKMP.
El RFC lo dice así:
SKEYID_e es el material de claves utilizado por ISAKMP SA para proteger la confidencialidad de sus mensajes.
SKEYID_a es el material de claves utilizado por ISAKMP SA para autenticar sus mensajes.
SKEYID_d es el material de claves utilizado para derivar claves para asociaciones de seguridad que no son ISAKMP.
Con todo lo dicho, podemos referirnos nuevamente a su pregunta: ¿Qué clave se utiliza para asegurar la clave precompartida?
En el modo principal, la clave precompartida (PSK) se verifica en los mensajes 5 y 6. Los mensajes 5 y 6 están protegidos por las claves de sesión que genera ISAKMP, descritas anteriormente.
En modo agresivo, ninguno de los mensajes en la negociación está encriptado. Y el PSK se verifica en los Mensajes 2 y 3. Aviso, dije en ambos casos que se verificó el PSK , y nunca dije que se intercambia el PSK . Obviamente, si nada en modo agresivo está cifrado, y simplemente envió la clave precompartida a través del cable sin cifrar, habría una enorme vulnerabilidad de seguridad enorme.
Por suerte para nosotros, los escritores de ISAKMP ya pensaron en eso. Y como resultado, crearon un método especial para verificar que cada parte tenga el PSK correcto, sin compartirlo realmente a través del cable. Hay dos elementos que se utilizan para validar a cada par que ambos tienen el mismo PSK: el método de identidad y el hash de identidad .
Los pares VPN pueden elegir identificarse por varios métodos; más comúnmente, los pares simplemente usarán su dirección IP de origen. Pero tienen la opción de usar un FQDN o nombre de host. Cada uno de estos, junto con el valor de correlación para el método elegido, son los que componen el Método de Identidad. Entonces, por ejemplo, si tuviera la IP 5.5.5.5 y quisiera usar mi dirección IP para identificarme, mi método de identificación sería efectivamente [Dirección IP, 5.5.5.5] . (Nota: AMBOS valores conforman todo el método de identificación)
El Método ID se combina (usando un PRF) con el valor de Semilla que discutimos anteriormente (SKEYID), y algunos otros valores, para crear el Hash de Identidad . Recuerde, lo que fue necesario para crear SKEYID en primer lugar fue la clave precompartida.
El método de identificación y el hash de identificación se envían a través del cable, y la otra parte intenta volver a crear el hash de identificación con la misma fórmula. Si el receptor puede volver a crear el mismo ID Hash, prueba al receptor que el remitente debe haber tenido la clave precompartida correcta.
Esto se describe en el RFC aquí:
Para autenticar el intercambio, el iniciador del protocolo genera HASH_I y el respondedor genera HASH_R donde:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDii e IDir son el método de identificación. Y HASH_I y HASH_R son los hash de iniciador y respondedor. Ambos se comparten en la fase 1. Desde el RFC:
Cuando se realiza una autenticación de clave previamente compartida, el Modo principal se define de la siguiente manera:
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_REl modo agresivo con una clave previamente compartida se describe a continuación:
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
Y ahora, finalmente podemos responder su pregunta por completo:
La clave precompartida se combina usando un PRF con Nonces y un montón de otros valores conocidos por cualquier otra persona en la negociación. El resultado es un valor que solo dos partes pueden alcanzar mutuamente si ambas partes comenzaron con los mismos valores, es decir, la misma clave precompartida. El valor resultante es lo que se comparte en el cable, con lo que permite a dos partes verificar que tienen claves precompartidas coincidentes sin exponer realmente ninguna información sobre la clave precompartida.
El modo principal va un paso más seguro al cifrar también el intercambio del "valor resultante" descrito anteriormente, lo que hace aún más difícil extraer cualquier información útil sobre lo que era la clave precompartida.
(Parece que fallé miserablemente al responder esto sucintamente)
Su respuesta está en su pregunta: el intercambio Diffie-Hellman se utiliza para generar una clave común para intercambiar de forma segura una clave común (es decir, compartir previamente).
Vea esto: /security/67953/understanding-diffie-hellman-key-exchange
fuente