Scambio di chiavi pubbliche con DHE-RSA

1

Il documento "Imperfetto Avanti Segreto: come Diffie-Hellman fallisce nella pratica" di Adrian et al. afferma che l'NSA potrebbe essere in grado di intercettare una grande percentuale di connessioni TLS, perché sono riusciti a decifrare alcuni gruppi Diffie-Hellman. Ora, presumo una situazione in cui un client è connesso a un server tramite DHE-RSA. Quello che non capisco è il motivo per cui, in questa situazione, sarebbe sufficiente intercettare Diffie-Hellman da solo. Non sarebbe necessario che la NSA ottenga anche la chiave RSA privata del server? Inserisci parole diverse: quando il client invia la sua chiave pubblica DH al server, non crittografa la sua chiave pubblica DH con la chiave pubblica RSA del server? (Se no, perché no?)

    
posta HjP 06.05.2018 - 04:19
fonte

1 risposta

0

In caso di DHE-RSA la parte RSA viene utilizzata solo per l'autenticazione che il client parla con il server corretto. Anche se potrebbe essere utilizzato per rilevare modifiche dello scambio di chiavi, non rileverà l'analisi passiva dello scambio di chiavi, ovvero proteggerà dagli attacchi che richiedono solo l'annusamento, ma non la modifica dei dati. Un utente malintenzionato che è riuscito a decifrare il gruppo DH specifico utilizzato dallo scambio di chiavi (o ha piantato una backdoor criptopforica in esso) non ha bisogno di interferire attivamente con la connessione ma ha solo bisogno di annusare passivamente la connessione per poter accedere alla chiave scambiata e decifrare il traffico.

È noto che i Five Eyes (cioè NSA, GCHQ, ...) ma anche altri servizi governativi in vari paesi hanno accesso in gran parte dei sistemi interni di internet e può quindi ascoltare passivamente questi dati. Combinato con la crittografia debole o backdoored questo rende possibile sniffare e decifrare il traffico senza modificare il traffico e in un in modo che il mittente e il destinatario non se ne accorgano.

Per rispondere alla domanda nel commento sul motivo per cui RSA non viene utilizzato per proteggere lo scambio di chiavi: si potrebbe sostenere che la conoscenza della chiave pubblica RSA dei server da parte del client renderebbe possibile crittografare la parte dello scambio di chiavi che viene inviato dal client al server poiché il server potrebbe decodificare questa parte utilizzando la sua chiave privata. Mentre questo sarebbe possibile con RSA significherebbe che lo scambio di chiavi DH è troppo legato all'uso di RSA e non più un meccanismo più o meno indipendente. Ad esempio richiederebbe al client di conoscere prima la chiave pubblica del server. Mentre è possibile con TLS 1.0 ... TLS 1.2 dove lo scambio di chiavi DH viene eseguito solo dopo che il certificato del server è noto, questo non è più il caso di TLS 1.3 dove lo scambio di chiavi DH inizia prima che il certificato sia noto. Inoltre, un meccanismo di autenticazione più moderno basato su ECC (ad esempio ECDSA) è progettato solo per la firma ma non per la crittografia, il che significherebbe che non possono essere utilizzati per proteggere lo scambio di chiavi DH in ogni caso.

    
risposta data 06.05.2018 - 06:30
fonte

Leggi altre domande sui tag