it-swarm.dev

In che modo lo scambio di chiavi Diffie-Hellman non effimero viene compromesso in SSL quando si perde la chiave privata RSA?

Da quanto ho capito, uno dei motivi principali per cui consigliamo Diffie-Hellman Ephemeral (ad es. DHE o ECDHE) su DH non effimero, per SSL/TLS, è che il compromesso della chiave privata RSA (ovvero certificato privato) consentirebbe a un utente malintenzionato di decifrare conversazioni precedentemente acquisite. Al contrario, l'effimero dovrebbe impedire la decrittazione a meno che l'attaccante non sia in posizione della chiave al momento della conversazione.

Come funziona questa decrittazione dello scambio di chiavi Diffie-Hellman non effimero in questo contesto? Si tratta semplicemente di osservare le primitive non crittografate che vengono scambiate sul filo? In tal caso, qual è lo scopo dell'utilizzo di DH, se non fornisce alcuna sicurezza aggiuntiva rispetto alla crittografia della chiave con RSA e RSA fornisce già l'autenticazione del server?

27
Polynomial

Prima di tutto assicuriamoci di parlare della stessa cosa. In SSL , ci sono "suite di crittografia DH effimere" (DHE) e "suite di crittografia DH non effimere" (DH).

Con DHE, la chiave privata del server (quella permanente, quella memorizzata in un file e la cui chiave pubblica è nel certificato del server) è di tipo RSA (suite di crittografia DHE_RSA) o DSS = (Suite di crittografia DHE_DSS) e viene utilizzato solo per firme . Il server genera una nuova coppia di chiavi DH casuali (la chiave privata sarà non essere archiviato, ecco come si ottiene perfetto segreto in avanti : una chiave privata non può essere successivamente rubata se non è mai stata memorizzata) e invia la chiave pubblica al client, in un messaggio che il server firma con la sua RSA o DSS.

Con le suite di crittografia DH, la chiave privata del server permanente è una chiave privata DH. Il certificato del server contiene la chiave pubblica DH. Il server non può vedere la sua chiave RSA rubata perché il server non ha una chiave RSA. Il server ha solo una chiave DH. Quando una suite di cifratura viene chiamata "DH_RSA", significa che "la chiave del server è una chiave DH e il certificato del server era emesso (cioè firmato) da un'autorità di certificazione che utilizza una chiave RSA " .

Il furto della chiave privata DH di una delle parti coinvolte in uno scambio di chiavi DH consente un'ulteriore ricostruzione del segreto condiviso, proprio come RSA. In "effimero DH", il PFS è ottenuto attraverso "effimero", non attraverso "DH". Tecnicamente, sarebbe possibile avere "RSA effimera" ma non viene fatto in pratica (*) perché la generazione di una nuova coppia di chiavi RSA è piuttosto costosa, mentre la produzione di una nuova coppia di chiavi DH è economica.

(*) Le chiavi RSA effimere erano possibili con le vecchie versioni di SSL come parte delle suite di cifratura "export", intese a rispettare le normative statunitensi sull'esportazione precedenti al 2000: il server poteva avere una 1024 bit firma Chiave RSA e genera una coppia di chiavi RSA effimera a 512 bit per lo scambio di chiavi, utilizzata in modalità di crittografia. Non ricordo di averlo mai visto allo stato brado, tuttavia, ed è un punto controverso da quando sono state revocate le normative statunitensi sulle esportazioni di dimensioni chiave.


Esistono suite di crittografia DH non effimere per consentire il funzionamento di server con certificati DH. Le chiavi DH nel certificato esistono perché in tempi precedenti RSA era brevettato ma DH non lo era, quindi gli organismi di standardizzazione, in particolare il NIST, spingevano DH come standard da implementare.

La realtà l'ha raggiunto, però. Non ho mai visto un server SSL usando un certificato DH. Tutti usano RSA. Il brevetto RSA è comunque scaduto dieci anni fa.

23
Tom Leek

Per SSL/TLS, abbiamo bisogno di 2 cose:

1) client needs to authenticate the server.
2) client and server need to compute a symmetric session key.

Alcuni modi per fare entrambi:

Più comune: TLS_RSA_WITH_AES _...

RSA is used for both 1 (authentication) and 2 (computing symmetric key).

preferito: TLS_DHE_RSA_WITH_AES _... o TLS_ECDHE_RSA_WITH_AES _...

RSA is used for 1 (authentication) and for signing the DHE keys.
DHE is used for 2 (computing symmetric key).

Preferito, perché ottieni Perfect Forward Security (PFS)

Non comune: DH_RSA _... (questa è la DH non effimera nella domanda dell'OP)

DH is used for both 1 (Authentication) and 2 (computing symmetric key).

Il caso a cui ti riferisci è il 3 ° ("Non comune") e come puoi vedere, RSA non viene utilizzato né per 1 (Autenticazione) né per 2 (chiave simmetrica di calcolo) e quindi non vi è alcuna questione di perdita della chiave privata RSA . L'RSA in DH_RSA potrebbe essere fuorviante ma, come menzionato da Tom Leek, l'amministratore del server fornirà le credenziali e la loro chiave pubblica DH a una CA (Autorità di certificazione) che firmerà quindi la chiave pubblica DH con la chiave privata RSA della CA.

4
Babu Srinivasan