Stavo facendo IPsec VPN su ASA 8.0 e ne capisco un po '. L'iniziatore inizia inviando la sua politica ISAKMP al rispondente e il risponditore rinvia la politica corrispondente. Dopodiché, la chiave Diffie-Hellman viene scambiata e quindi entrambi inviano la chiave pre-condivisa all'altro per l'autenticazione.
Ora abbiamo due chiavi:
Quale chiave viene utilizzata per crittografare la chiave precondivisa?
Risposte:
Hai fatto un'ottima domanda. La domanda sembra molto semplice, ma in realtà la risposta è in qualche modo più complessa. Farò del mio meglio per rispondere in modo sintetico. Inoltre, poiché hai citato ISAKMP, suppongo che tu sia interessato a IKEv1. Le cose cambiano un po 'per IKEv2 (beh, molto), ma volevo menzionare la seguente risposta correlata solo a IKEv1.
La fase 1 può essere realizzata in due modi diversi: Modalità principale e Modalità aggressiva. In entrambe le modalità, il primo messaggio viene inviato dall'iniziatore e il secondo messaggio viene inviato dal risponditore. Entrambi questi messaggi includono ciò che è noto nel mondo della crittografia come Nonce . Un Nonce è semplicemente un numero generato casualmente da utilizzare nella generazione delle chiavi. (il termine Nonce deriva da _N_umber utilizzato _Once_) . Quindi, dopo il messaggio 1 e il messaggio 2, entrambe le parti conoscono le Nonces l'una dell'altra.
I Nonce sono combinati con la chiave pre-condivisa per creare un valore seed per la generazione di chiavi segrete. La parte relativa di IKE RFC è qui:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID è il valore Seed che verrà successivamente utilizzato per generare chiavi segrete aggiuntive. La chiave pre-condivisa e entrambi i valori Nonce (Ni_b è il Nonce dell'iniziatore e Nr_B è il Nonce del risponditore) viene combinato utilizzando una funzione casuale PRF o Psuedo. Un PRF è come un algoritmo di hashing, tranne per il fatto che il risultato può essere quanti bit sono necessari.
Ora, se inizialmente stavi eseguendo la modalità principale, i messaggi 3 e 4 condividono le chiavi pubbliche Diffie-Hellman dell'iniziatore e del risponditore. Entrambi usano questi valori per generare il segreto condiviso Diffie-Hellman . Se stavi facendo la modalità Aggressiva, questi valori pubblici DH sono inclusi anche nel Messaggio 1 e Messaggio 2 (insieme alle Nonces).
Il valore Seed viene quindi combinato con DH Shared Secret (e alcuni altri valori) per creare tre chiavi di sessione : una chiave di ripristino, una chiave di autenticazione e una chiave di crittografia. La RFC lo afferma come tale:
Il risultato della modalità principale o aggressiva è costituito da tre gruppi di materiale di codifica autenticato:
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 e _e sono le tre chiavi Session menzionate sopra. SKEYIDè il valore del seme. g^xyè il segreto condiviso di DH. CKY-Ie CKI-Rsono i cookie di iniziatore e risponditore, questi sono solo altri valori generati casualmente che verranno utilizzati in seguito per identificare questa particolare associazione ISAKMP di sicurezza e scambio. 0 1 2sono i numeri letterali 0, 1 e 2. Il simbolo Pipe |indica concatenazione.
In ogni caso, tutti questi valori vengono combinati insieme utilizzando un PRF che crea tre chiavi Session:
La chiave di autenticazione e la chiave di crittografia vengono utilizzate per proteggere / crittografare la successiva negoziazione di Fase2. Nella modalità principale, anche i messaggi 5 e 6 della Fase 1 sono protetti da questi tasti. Inoltre, anche i futuri scambi di informazioni ISAKMP (DPD, eventi Rekey, Elimina messaggi, ecc.) Sono protetti da queste due chiavi.
La chiave derivata viene consegnata a IPsec e IPsec genera il proprio materiale di codifica da questa chiave. Se ricordi, IPsec non include in modo innato un meccanismo di scambio di chiavi, quindi l'unico modo per acquisire chiavi segrete è impostarle manualmente (che è arcaico e mai più fatto), O dipendere da un servizio esterno per fornire il materiale per le chiavi, come ISAKMP.
L'RFC lo dice così:
SKEYID_e è il materiale di codifica utilizzato da ISAKMP SA per proteggere la riservatezza dei suoi messaggi.
SKEYID_a è il materiale di codifica utilizzato da ISAKMP SA per autenticare i suoi messaggi.
SKEYID_d è il materiale di codifica utilizzato per derivare le chiavi per le associazioni di sicurezza non ISAKMP.
Detto questo, possiamo fare riferimento alla tua domanda: quale chiave viene utilizzata per proteggere la chiave pre-condivisa?
Nella modalità principale, la chiave pre-condivisa (PSK) è verificata nei messaggi 5 e 6. I messaggi 5 e 6 sono protetti dai tasti di sessione generati da ISAKMP, descritti sopra.
In modalità aggressiva, nessuno dei messaggi nella negoziazione è crittografato. E il PSK è verificato nei Messaggi 2 e 3. Avviso, ho detto in entrambi i casi che il PSK è verificato e non ho mai detto che il PSK viene scambiato . Ovviamente, se nulla in modalità Aggressiva è crittografato e se la chiave pre-condivisa non viene semplicemente crittografata attraverso il cavo, la vulnerabilità di sicurezza resterebbe enorme.
Fortunatamente per noi, gli autori di ISAKMP ci hanno già pensato. Di conseguenza, hanno creato un metodo speciale per verificare che ogni parte disponga del PSK corretto, senza effettivamente condividerlo attraverso il cavo. Esistono due elementi che vengono utilizzati per convalidare a ciascun peer che entrambi hanno lo stesso PSK: il metodo di identità e il hash di identità .
I peer VPN possono scegliere di identificarsi con vari metodi; più comunemente, i peer useranno semplicemente il loro indirizzo IP di origine. Ma hanno la possibilità di utilizzare un nome di dominio completo o un nome host. Ognuno di questi, insieme al valore correlato per il metodo scelto, sono ciò che costituisce il metodo di identità. Quindi, ad esempio, se avessi l'IP 5.5.5.5 e volessi usare il mio indirizzo IP per identificarmi, il mio metodo ID sarebbe effettivamente [Indirizzo IP, 5.5.5.5] . (Nota: ENTRAMBI i valori costituiscono l'intero metodo ID)
Il metodo ID viene quindi combinato (utilizzando un PRF) con il valore Seed discusso in precedenza (SKEYID) e alcuni altri valori, per creare l' Hash identità . Ricordiamo che, in primo luogo, ciò che è andato alla creazione di SKEYID è stata la chiave pre-condivisa.
Il metodo ID e l'Hash ID vengono quindi inviati attraverso il filo e l'altra parte tenta di ricreare l'Hash ID utilizzando la stessa formula. Se il destinatario è in grado di ricreare lo stesso hash ID, dimostra al destinatario che il mittente deve avere la chiave pre-condivisa corretta.
Questo è descritto nella RFC qui:
Per autenticare uno scambio, l'iniziatore del protocollo genera HASH_I e il risponditore genera HASH_R dove:
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 sono il metodo ID. E HASH_I e HASH_R sono l'hash dell'iniziatore e del risponditore. Entrambi sono condivisi in Fase 1. Dalla RFC:
Quando si esegue un'autenticazione con chiave pre-condivisa, la modalità principale è definita come segue:
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_RLa modalità aggressiva con una chiave pre-condivisa è descritta come segue:
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
E ora possiamo finalmente rispondere completamente alla tua domanda:
La chiave pre-condivisa viene combinata utilizzando un PRF con Nonces e un gruppo di altri valori noti a chiunque altro nella negoziazione. Il risultato è un valore che può essere raggiunto reciprocamente da due parti solo se entrambe le parti hanno iniziato con gli stessi valori, ovvero la stessa chiave pre-condivisa. Il valore risultante è ciò che è condiviso sul filo, con consente a due parti di verificare di avere chiavi pre-condivise corrispondenti senza in realtà esporre alcuna informazione sulla chiave pre-condivisa stessa.
La modalità principale fa un passo più sicuro crittografando anche lo scambio del "valore risultante" sopra descritto, rendendo ancora più difficile estrarre qualsiasi informazione utile su cosa fosse la chiave pre-condivisa.
(sembra che ho fallito miseramente nel rispondere in modo succinto)
La tua risposta è nella tua domanda: lo scambio Diffie-Hellman viene utilizzato per generare una chiave comune per scambiare in modo sicuro una chiave comune (cioè pre-share).
Vedi questo: /security/67953/understanding-diffie-hellman-key-exchange