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

25

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

In che modo questa decrittazione dello scambio di chiavi Diffie-Hellman non effimero funziona in questo contesto? È semplicemente un caso di osservare le primitive non criptate che vengono scambiate sul filo? In tal caso, che senso ha utilizzare DH, se non fornisce ulteriore sicurezza rispetto alla crittografia della chiave con RSA e RSA fornisce già l'autenticazione del server?

    
posta Polynomial 20.06.2013 - 21:10
fonte

2 risposte

20

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

Con DHE, la chiave privata del server (quella permanente, quella che è archiviata 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 casuale (la chiave privata non deve essere memorizzata, che è come perfeziona in avanti la segretezza è stata raggiunta: una chiave privata non può essere rubata in seguito se non è mai stata archiviata) e invia la chiave pubblica al client, in un messaggio che il server firma con la sua chiave privata 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 essere rubata perché il server non ha una chiave RSA. Il server ha solo un tasto DH. Quando una suite di crittografia è denominata "DH_RSA", significa "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 ".

Rubare la chiave privata DH di una parte coinvolta in uno scambio di chiavi DH consente un'ulteriore ricostruzione del segreto condiviso, proprio come RSA. In "DH effimero", la PFS è ottenuta attraverso "effimero", non attraverso "DH". Tecnicamente, sarebbe possibile avere "RSA effimero" ma non è fatto in pratica (*) perché generare una nuova coppia di chiavi RSA è piuttosto costoso, mentre produrre una nuova coppia di chiavi DH è economico.

(*) Le chiavi temporanee RSA erano possibili con vecchie versioni di SSL come parte delle suite di cifratura "export", intese a rispettare le normative di esportazione degli Stati Uniti precedenti al 2000: il server poteva avere un 1024 bit < em> signature chiave RSA e generare una coppia di chiavi RSA a 512 bit effimera per lo scambio di chiavi, utilizzata in modalità di crittografia. Non ricordo di averlo mai visto in natura, però, ed è un punto controverso dal momento che le normative statunitensi sulle esportazioni delle dimensioni delle chiavi sono state rimosse.

Esistono suite di codici DH non effimeri per consentire il funzionamento dei server con certificati DH. Le chiavi DH nel certificato esistono perché nei tempi più vecchi, RSA era stato brevettato ma DH non lo era, quindi gli organismi di standardizzazione, in particolare il NIST, stavano spingendo il DH come standard imprescindibile.

La realtà lo ha raggiunto, però. Non ho mai visto un server SSL che utilizza un certificato DH. Tutti usano RSA. Il brevetto RSA è scaduto un decennio fa comunque.

    
risposta data 28.06.2013 - 18:28
fonte
4

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 entrambe le cose:

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 _... (questo è il DH non effimero nella domanda dell'OP)

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

Il caso a cui ti stai riferendo è il 3 ° ("Non comune") e come puoi vedere, RSA non viene utilizzato né per 1 (Autenticazione) né per 2 (calcolo chiave simmetrica) e quindi non c'è alcun problema di RSA privato la chiave è trapelata. L'RSA in DH_RSA potrebbe essere fuorviante ma, come ha detto Tom Leek, l'amministratore del server fornirà le credenziali e la loro chiave pubblica DH a una CA (autorità di certificazione) che firmerà la chiave pubblica DH con la chiave privata RSA della CA.

    
risposta data 09.03.2014 - 05:34
fonte

Leggi altre domande sui tag