Tra i requisiti per uno scambio di chiavi sicuro è la conferma chiave. Mi chiedo perché è necessario questo passaggio. Anche se l'altra parte non ha calcolato un valore corretto per il segreto condiviso, non importa. Non sarà in grado di decifrare le informazioni inviate comunque. Perché preoccuparsi e assicurarsi che l'altra parte possieda effettivamente il segreto condiviso corretto? Si dice che questo è un requisito per uno scambio sicuro di chiavi. Ma perché?
Potrebbero sicuramente decifrare qualsiasi cosa tu invii perché stai parlando di crittografia sincrona, in cui la stessa chiave viene utilizzata per crittografare e decrittografare il traffico. Affinché ciò funzioni, entrambe le parti devono concordare una chiave di scambio. La verifica segreta condivisa non è in realtà un requisito per uno scambio di chiavi sicuro da un punto di vista teorico, è possibile scambiare le chiavi in modo sicuro con chiunque realmente. Tuttavia, se non si verifica l'altra parte, è possibile configurare una VPN con chiunque, anche quelli che non si desidera, e inviare tutti i tipi di informazioni riservate. Questo è il motivo per cui la verifica del mittente è parte integrante di tutte le tecnologie di trasferimento sicure.
Potresti sentirti confuso mescolando tecnologia PKI e VPN, pensando erroneamente che quando la verifica viene eseguita da PKI, solo il vero destinatario può decifrare il traffico. Non è così semplice perché la decrittografia PKI (asincrona rispetto alla crittografia sincrona) è estremamente intensiva da computare, quindi i trasferimenti sicuri utilizzano quasi sempre PKI per la verifica del mittente, ma poi impostano la crittografia sincrona per i trasferimenti stessi.
EDIT: il poster dice che la fonte è una lezione
Se entrambe le parti non condividono la stessa chiave, nessuna delle due parti sarebbe in grado di decifrare il traffico dell'altro, quindi la conferma della chiave è importante dal punto di vista dell'operabilità, se non da una prospettiva di pura sicurezza. Inoltre, se si utilizza una VPN per verificare l'autenticazione (vedere IPSEC AH), è necessario verificare le chiavi o non è possibile sapere quale sia il traffico autentico. Ciò che il docente può dire è che semplicemente non funzionerà senza una verifica chiave, piuttosto che essere un processo di sicurezza.
Why bother and make sure that the other party actually possesses the correct shared secret? It is said that this is a requirement for a secure key exchange. But why?
Oltre ad altri motivi, a volte è richiesta una conferma chiave durante la convalida dell'algoritmo. Ad esempio, il del NIST
Per completezza, ecco la definizione del NIST dalla Sezione 4.1, pagina 7:
A procedure to provide assurance to one party (the key confirmation recipient) that another party (the key confirmation provider) actually possesses the correct secret keying material and/or shared secret.
Even if the other party hasn't computed a correct value for the shared secret, it doesn't matter. It won't be able to decipher the information sent anyway.
Questo potrebbe non essere necessariamente vero. Se un cattivo può in qualche modo contaminare lo scambio, può essere in grado di imparare alcune cose in assenza di un'interruzione completa controllando i parametri. In questo caso, l'esecuzione del protocollo si fermerebbe immediatamente alla fase di conferma della chiave piuttosto che dare all'attaccante più di un morso della proverbiale mela.
Protocolli per l'autenticazione e l'identificazione delle chiavi (pagine 162-63) in realtà descrive un attacco allo scambio di chiavi che è ostacolato dalla conformazione della chiave, quindi non è teorico.
Non ho mai implementato un protocollo di conferma della chiave, ma mi aspetto che si tratti di un protocollo challenge / response a due vie che non utilizza direttamente il materiale di codifica. Probabilmente aggiunge da 2 a 4 messaggi aggiuntivi al protocollo.
È bidirezionale perché entrambe le parti dovrebbero dimostrare la conoscenza della chiave. Non usa direttamente il materiale di codifica per evitare di rivelare informazioni sulla chiave effettiva di un avversario.
Su una nota correlata, non usi mai direttamente il materiale segreto / chiave condivisa. Devi spostarlo dal dominio Diffie-Hellman in un altro dominio in cui i valori sono ugualmente probabilmente (cioè, distribuiti uniformemente). IPSec utilizza HKDF per questo passaggio.
Leggi altre domande sui tag key-exchange