it-swarm.dev

Diffie-Hellman e il suo utilizzo TLS / SSL

Faccio fatica a capire l'uso (non) di Diffie-Hellman (DH) in TLS.

  • DH è in circolazione da molto tempo ormai, perché quasi nessuno lo usa ancora?
  • DH viene utilizzato solo per la "condivisione delle chiavi", perché nessuno usa il segreto DH per crittografare tutto? Perché abbiamo bisogno di una chiave simmetrica, quando abbiamo già un segreto DH, abbastanza buono da trasportare un altro segreto? Questo vale anche per SSH (no?). Penso che ci sia una risposta semplice a ciò, ma non sono riuscito a trovarlo.
35
David Halter

Diffie-Hellman è usato in SSL/TLS, come "effiemerale Diffie-Hellman" (la suite di cifratura con "DHE" nel loro nome; vedi lo standard =). Ciò che si incontra molto raramente è "Diffie-Hellman statico" (suite di crittografia con "DH" nel loro nome, ma né "DHE" o "DH_anon"): queste suite di crittografia richiedono che il server possieda un certificato con una chiave pubblica DH, raramente supportata per una serie di ragioni storiche ed economiche, tra cui la principale è la disponibilità di uno standard gratuito per RSA ( PKCS # 1 ) mentre lo standard corrispondente per Diffie-Hellman ( x9.42 ) costa cento dollari, che non è molto, ma sufficiente per scoraggiare la maggior parte degli sviluppatori dilettanti.

Diffie-Hellman è un protocollo di accordo chiave , nel senso che se due parti (diciamo, il client SSL e il server SSL) eseguono questo protocollo, finiscono con un segreto condiviso [~ ~ #] k [~ ~ #] . Tuttavia, né il client né il server arrivano a scegliere il valore di [~ # ~] k [~ # ~] ; dal loro punto di vista, [~ # ~] k [~ # ~] sembra generato casualmente. È segreto (solo loro sanno [~ # ~] k [~ # ~] ; gli intercettatori sulla linea no) e condiviso (entrambi ottengono lo stesso valore [~ # ~] k [~ # ~] ), ma non scelto . Questa non è crittografia. Un segreto condiviso [~ # ~] k [~ # ~] è abbastanza buono, tuttavia, per elaborare terabyte di dati con un algoritmo di crittografia simmetrica (stesso [~ # ~] k [~ # ~] per crittografare da un lato e decrittografare dall'altro), ed è quello che succede in SSL.

Tuttavia, esiste un noto algoritmo di crittografia asimmetrica chiamato RSA. Con RSA, il mittente può crittografare un messaggio [~ # ~] m [~ # ~] con la chiave pubblica del destinatario e il destinatario può decrittografarlo e ripristinarlo [~ # ~] m [~ # ~] usando la sua chiave privata. Questa volta, il mittente può scegliere il contenuto di [~ # ~] m [~ # ~] .

Quindi la tua domanda potrebbe essere: in un mondo RSA, perché ci preoccupiamo affatto di AES? La risposta sta nei seguenti punti:

  • Ci sono vincoli su [~ # ~] m [~ # ~] . Se la chiave pubblica del destinatario ha dimensioni n (in byte, ad es. n = 256 per una chiave RSA a 2048 bit), quindi la dimensione massima di [~ # ~] m [~ # ~] è n-11 byte. Per crittografare un messaggio più lungo, dovremmo dividerlo in blocchi sufficientemente piccoli e includere un meccanismo di riassemblaggio. Nessuno sa davvero come farlo in modo sicuro . Abbiamo buone ragioni per ritenere che RSA su un singolo messaggio sia sicuro, ma sottili debolezze possono nascondersi in qualsiasi sistema di suddivisione e rimontaggio e non ci sentiamo a nostro agio. È già abbastanza male con cifre simmetriche , dove la situazione matematica è più semplice,

  • Anche se potessimo gestire la divisione e il riassemblaggio, ci sarebbe un'espansione delle dimensioni. Con una chiave RSA a 2048 bit, un blocco di messaggi interno ha una dimensione massima di 245 byte, ma una volta crittografato, risulta essere una sequenza di 256 byte. Ciò spreca la nostra energia vitale, ovvero la larghezza di banda della rete. La crittografia simmetrica comporta solo un sovraccarico limitato (beh, SSL aggiunge un leggero sovraccarico proporzionale alla dimensione dei dati, ma è molto più piccolo di quanto accadrebbe con un protocollo solo RSA),

  • Rispetto ad AES, RSA è lento come l'inferno,

  • Ci piace davvero avere la possibilità di utilizzare protocolli di accordo chiave come DH anziché RSA. In tempi più remoti (prima del 2001), RSA era brevettata ma DH no, quindi il governo degli Stati Uniti stava raccomandando DH. Al giorno d'oggi, vogliamo essere in grado di cambiare algoritmo nel caso in cui uno si rompa. Per supportare i protocolli di accordo chiave, abbiamo bisogno di un po 'di crittografia simmetrica, quindi potremmo anche usarlo con RSA. Semplifica l'implementazione e l'analisi del protocollo.

Vedi questa risposta per una descrizione dettagliata di come funziona SSL.

48
Thomas Pornin

Penso Security Now ep. 412 "SSL e Perfect Forward Secrecy" ha quello che vuoi.

Forse dovresti solo cercare leggi la loro trascrizione per 'Diffie', perché questi podcast hanno molte notizie/cose varie prima che arrivino al punto.

Citando:

Ma oggi molti browser e molti server supportano quello che viene chiamato Diffie-Hellman Ephemeral, DHE. Effimero significa specificamente "solo per il momento". Quindi questo è DHE, Diffie-Hellman Ephemeral, è una tecnologia che è disaccoppiata - e questa è la chiave, "disaccoppiata" - dall'autenticazione del server. E come ho appena detto con Diffie-Hellman, una terza parte che osserva l'interscambio non ottiene alcuna conoscenza. Questa è esattamente la protezione che vogliamo nelle nostre connessioni SSL dall'archiviazione a lungo termine. L'archiviazione a lungo termine e la successiva rivelazione della chiave privata del server non offrono a nessuno alcun aiuto per decifrare la protezione effimera di Diffie-Hellman. "

Si rivolgono in modo specifico al motivo per cui non è ancora in uso:

Ma Microsoft non offre alcun effimero Diffie-Hellman [...] che ha anche RC4, che è il codice [...]. Sfortunatamente sono tutti CBC, Cipher Block Chaining. E questo è il protocollo di crittografia che è vulnerabile all'attacco di BEAST. "

Qui si riferiscono ai test SSLLabs che hanno descritto nell'ep. 395 (e 396).

4
user13695