Quando si parla di «crittografia», alcuni ricordano la propria password WiFi, il lucchetto verde accanto all'indirizzo del sito web preferito e quanto sia difficile accedere alla posta altrui. Altri pensano a una serie di vulnerabilità degli ultimi anni con acronimi illustri (DROWN, FREAK, POODLE…), loghi accattivanti e l'avviso di aggiornare urgentemente il browser.

La crittografia comprende tutto questo, ma la sostanza è diversa. La sostanza è nella sottile linea tra semplice e complesso. Alcune cose sono facili da fare, ma è difficile tornare indietro: ad esempio, rompere un uovo. Altre cose sono facili da realizzare, ma difficile ritorna indietro quando manca un piccolo, ma importante, elemento decisivo: per esempio, aprire una porta chiusa a chiave quando il «pezzo decisivo» è la chiave. La crittografia studia queste situazioni e i modi per sfruttarle praticamente.

Negli ultimi anni, la collezione di attacchi crittografici si è trasformata in uno zoo di loghi stridenti, pieni di formule di articoli scientifici e ha generato una generale sensazione cupa che tutto sia rotto. Ma in realtà, molti degli attacchi si basano su pochi principi comuni, e le infinite pagine di formule spesso si riducono a idee semplici da comprendere.

In questa serie di articoli, esamineremo diversi tipi di attacchi crittografici, concentrandoci sui principi fondamentali. In linea generale e non necessariamente in questo ordine, parleremo di:

Strategie di base: forza bruta, analisi delle frequenze, interpolazione, riduzione e protocolli incrociati.
Vulnerabilità «brandizzate»: FREAK, CRIME, POODLE, DROWN, Logjam.
Strategie avanzate: attacchi oracolo (attacco di Waterner, attacco di Kelsey); metodo meet-in-the-middle, attacco del compleanno, distorsione statistica (crittanalisi differenziale, crittanalisi integrale, ecc.).
Attacchi tramite canali laterali e i loro parenti stretti, metodi di analisi degli guasti.
Attacchi alla crittografia a chiave pubblica: radice cubica, broadcast, messaggio correlato, attacco di Coppersmith, algoritmo di Pollard-Hellman, setaccio numerico, attacco di Wiener, attacco di Bleichenbacher.

Questo specifico articolo copre il materiale menzionato fino all'attacco di Kelsey.

Strategie di base

Le seguenti attacchi sono semplici nel senso che possono essere praticamente spiegati senza particolari dettagli tecnici. Spieghiamo ogni tipo di attacco in termini molto semplici, senza approfondire esempi complicati o casi d'uso avanzati.

Alcuni di questi attacchi sono sostanzialmente obsoleti e non vengono utilizzati da molti anni. Altri, invece, sono vecchi volti noti e continuano a fare capolino contro sviluppatori di sistemi crittografici ignari nel ventunesimo secolo. Si può considerare che l'era della crittografia moderna sia iniziata con l'arrivo dell'IBM DES, il primo cifrario che ha resistito a tutti gli attacchi in questo elenco.

Semplice brute force

Lo schema di crittografia consiste di due parti: 1) una funzione di crittografia, che prende un messaggio (testo in chiaro) insieme a una chiave, e poi crea un messaggio crittografato – testo cifrato; 2) una funzione di decrittografia, che prende il testo cifrato e la chiave e crea il testo in chiaro. Sia la crittografia che la decrittografia devono essere facilmente calcolabili con la chiave – e difficili senza di essa.

Supponiamo di vedere il testo cifrato e di tentare di decifrarlo senza alcuna informazione aggiuntiva (questo è chiamato attacco "solo testo cifrato"). Se in qualche modo troviamo la chiave corretta, possiamo facilmente verificare che sia effettivamente corretta se il risultato è un messaggio sensato.

Si noti che ci sono due presupposti impliciti qui. In primo luogo, che sappiamo come eseguire la decrittazione, cioè come funziona il sistema crittografico. Questo è un presupposto standard quando si discute di crittografia. Nascondere i dettagli di implementazione del cifrario dagli attaccanti potrebbe sembrare una misura di sicurezza aggiuntiva, ma una volta che l'attaccante scopre questi dettagli, questa sicurezza aggiuntiva viene persa in modo furtivo e irreversibile. Così è il principio di Kerckhoffs: la cattura del sistema da parte del nemico non dovrebbe causare inconvenienti.

In secondo luogo, presumiamo che la chiave corretta sia l'unica chiave che porterà a una decrittazione sensata. Questo è anche un presupposto ragionevole; è valido se il testo cifrato è molto più lungo della chiave e ben leggibile. In genere, questo è vero nel mondo reale, eccetto per enormi chiavi poco pratiche o altre manovre, che è meglio lasciare da parte. (se non ti piace che abbiamo saltato le spiegazioni, ti preghiamo di consultare il teorema 3.8 qui).

Detto ciò, emerge una strategia: verificare ogni possibile chiave. Questo si chiama attacco a forza bruta e tale attacco funziona garantito contro tutte le cifrature pratiche — alla fine. Ad esempio, la forza bruta è sufficiente per decifrare la cifratura di Cesare, una cifra antica in cui la chiave è una lettera dell'alfabeto, il che implica poco più di 20 chiavi possibili.

Sfortunatamente per i crittanalisti, l'aumento della dimensione della chiave protegge bene contro la forza bruta. Man mano che cresce la dimensione della chiave, il numero di chiavi possibili aumenta esponenzialmente. Con le dimensioni moderne delle chiavi, la semplice forza bruta è del tutto impraticabile. Per capire cosa intendiamo, prendiamo il supercomputer più veloce noto a metà 2019: Summit di IBM, con una prestazione di picco di circa 10^17 operazioni al secondo. Oggi la lunghezza tipica della chiave è di 128 bit, il che significa 2^128 combinazioni possibili. Per esaurire tutte le chiavi, al supercomputer Summit servirebbe un tempo che è circa 7800 volte superiore all'età dell'universo.

Dobbiamo considerare la forza bruta un curiosità storica? Assolutamente no: è un ingrediente necessario nel ricettario della crittanalisi. È raro imbattersi in cifrature così deboli che possano essere violate solo con un attacco intelligente, senza l'uso della forza in una qualche misura. Molti attacchi riusciti utilizzano prima un metodo algoritmo per indebolire la cifratura target e poi avviano la forza bruta.

Analisi delle frequenze

La maggior parte dei testi non è indecifrabile. Ad esempio, nei testi anglofoni ci sono molte lettere 'e' e articoli 'the'; nei file binari — molti byte nulli come riempitivo tra frammenti informativi. L'analisi delle frequenze è qualsiasi attacco che utilizza questo fatto.

Un esempio canonico di cifratura vulnerabile a questo attacco è la semplice cifratura a sostituzione. In questa cifratura, la chiave è una tabella che sostituisce tutte le lettere. Ad esempio, 'g' è sostituito con 'h', 'o' con 'j'. Pertanto, la parola 'go' diventa 'hj'. Questa cifratura è difficile da violare con la semplice forza bruta, poiché esistono moltissime tabelle di sostituzione possibili. Se sei interessato alla matematica, la lunghezza chiave efficace è di circa 88 bit: questo è
. Ma l'analisi della frequenza di solito si occupa rapidamente del compito.

Consideriamo il seguente testo cifrato, elaborato con una semplice cifratura a sostituzione:

XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO

Poiché Y si presenta frequentemente, anche alla fine di molte parole, possiamo preliminarmente ipotizzare che sia la lettera e:

XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO

Coppia XD riappare all'inizio di alcune parole. In particolare, la combinazione XDeLe suggerisce chiaramente la parola these o there, quindi continuiamo:

theLe ALe UGLe thWNKE WN heAJeN ANF eALth DGLAtWG thAN ALe FLeAUt GR WN OGQL ZDWBGEGZDO

Supponiamo ora che L corrisponde a r, A — a e così via. Probabilmente sarà necessario fare diversi tentativi, ma rispetto a un attacco di forza bruta completo, questo attacco recupera il testo originale in tempi molto brevi:

there are more things in heaven and earth horatio than are dreamt of in your philosophy

Per alcuni, risolvere tali "crittogrammi" è un hobby affascinante.

L'idea dell'analisi della frequenza è più fondamentale di quanto sembri a prima vista. Ed è applicabile a cifrature molto più complesse. Nel corso della storia, varie costruzioni di cifrature hanno cercato di difendersi da tale attacco attraverso la "sostituzione polialfabetica". Qui, durante la cifratura, la tabella di sostituzione delle lettere viene modificata in modi complessi, ma prevedibili, che dipendono dalla chiave. Tutte queste cifrature, a loro tempo, erano considerate difficili da violare; eppure, l'umile analisi della frequenza alla fine ha avuto la meglio su di esse.

La cifra polialfabetica più ambiziosa della storia e probabilmente la più famosa, è stata la cifra "Enigma" durante la Seconda Guerra Mondiale. Era relativamente complessa rispetto ai suoi predecessori, ma alla fine, grazie al lungo e tenace lavoro dei crittoanalisti britannici, è stata violata attraverso l'analisi della frequenza. Certo, non sono riusciti a sviluppare un attacco elegante come quello mostrato sopra; hanno dovuto confrontare coppie note di testi aperti e cifrati (il cosiddetto "attacco basato su testi aperti") e addirittura provocare gli utenti dell"Enigma" a cifrare determinati messaggi per analizzare il risultato ("attacco basato su testo aperto selezionato"). Ma questo non ha alleviato il destino degli eserciti sconfitti e dei sottomarini affondati.

Dopo questo trionfo, l'analisi delle frequenze è scomparsa dalla storia della crittanalisi. I codici dell'era digitale moderna sono progettati per lavorare con i bit, non con le lettere. Ciò che è ancora più importante, questi codici sono stati sviluppati con una comprensione cupa di ciò che in seguito divenne noto come il principio di Schneier: chiunque può creare un algoritmo di crittografia che non riesce a decifrare da solo. Non è sufficiente che il sistema di crittografia sembri complesso: per dimostrare il suo valore, deve superare una rigorosa revisione della sicurezza da parte di molti crittanalisti, che faranno di tutto per cercare di romperlo.

Calcoli preliminari

Prendiamo in considerazione la città ipotetica di Precum Heights con una popolazione di 200.000 persone. In ogni casa della città ci sono beni di valore mediamente di $30.000, ma non superiori a $50.000. Il mercato della sicurezza a Precum è stato monopolizzato dalla compagnia ACME Industries, che produce le leggendarie serrature da porta di classe Coyote ™. Secondo un’analisi esperta, solo una macchina ipotetica molto complessa potrebbe rompere una serratura di classe Coyote, la cui creazione richiede circa cinque anni e $50.000 di investimento. La città è al sicuro?

Probabilmente no. Alla fine, apparirà un criminale abbastanza ambizioso. Ragionerà così: «Sì, affronterò grandi costi iniziali. Cinque anni di attesa paziente e $50.000. Ma al termine del lavoro avrò accesso a tutta la ricchezza di questa città. Se gioco bene le mie carte, questo investimento ripagherà ampiamente».

Lo stesso vale per la crittografia. Gli attacchi contro un particolare codice sono sottoposti a un'analisi rigorosa dei costi e dei benefici. Se il rapporto è favorevole, non ci sarà attacco. Ma gli attacchi che colpiscono immediatamente molte potenziali vittime rendono quasi sempre, e in questo caso la migliore prassi progettuale è presupporre che siano iniziati fin dal primo giorno. Abbiamo sostanzialmente una versione crittografica della legge di Murphy: «Qualunque cosa sia realmente in grado di rompere un sistema, lo romperà».

Il più semplice esempio di un sistema crittografico vulnerabile agli attacchi con calcoli preliminari è un cifrario con algoritmo fisso che non utilizza chiavi. È stato così nel caso del cifrario di Cesare, che semplicemente sposta ogni lettera dell'alfabeto di tre posizioni in avanti (la tabella è circolare, quindi l'ultima lettera dell'alfabeto è cifrata dalla terza). Qui si manifesta ancora una volta il principio di Kerckhoffs: una volta che il sistema è stato violato, è violato per sempre.

Il concetto è semplice. Anche un programmatore alle prime armi di sistemi crittografici probabilmente riconosce la minaccia e si prepara di conseguenza. Se guardiamo all'evoluzione della crittografia, tali attacchi sono stati inappropriati per la maggior parte dei cifrari, a partire dalle prime versioni migliorate del cifrario di Cesare, fino alla caduta dei cifrari polialfabetici. Questi attacchi sono riemersi solo con l'avvento della moderna era della crittografia.

Questo ritorno è causato da due fattori. In primo luogo, finalmente sono emersi sistemi crittografici sufficientemente complessi, dove la possibilità di sfruttare il sistema dopo la violazione non era immediatamente evidente. In secondo luogo, la crittografia è diventata così diffusa che milioni di non professionisti ogni giorno prendevano decisioni su dove e quali parti della crittografia riutilizzare. Ci è voluto del tempo prima che gli esperti riconoscessero i rischi emergenti e alzassero l'allerta.

Ricordate l'attacco con pre-calcolo: alla fine dell'articolo esamineremo due esempi crittografici della vita reale, in cui ha avuto un ruolo significativo.

Interpolazione

Davanti a voi c'è il famoso detective Sherlock Holmes, che esegue un attacco di interpolazione sul malcapitato dottor Watson:

Subito ho capito che venivi dall'Afghanistan… Il mio ragionamento era il seguente: «Quest'uomo per tipo è un medico, ma la sua postura è militare. Quindi, un medico militare. È appena tornato dai tropici: il suo viso è scuro, ma questo non è il tono naturale della sua pelle, poiché i suoi polsi sono molto più chiari. Il viso è emaciato: evidentemente ha sofferto e ha affrontato malattie. È stato ferito al braccio sinistro: lo tiene immobile e un po' innaturalmente. Dove potrebbe un medico militare inglese aver sofferto così tanto nei tropici e subire una ferita? Certamente, in Afghanistan». L'intero ragionamento è durato meno di un secondo. E così ho detto che venivi dall'Afghanistan, e sei rimasto sorpreso.

Da ogni prova separatamente, Holmes poteva estrarre pochissime informazioni. Poteva giungere alle sue conclusioni solo considerando tutte insieme. Funziona in modo analogo l'attacco per interpolazione, esaminando le coppie note di testo in chiaro e di testo cifrato, ottenute applicando la stessa chiave. Da ogni coppia vengono estratti singoli dati che permettono di formulare una conclusione generale sulla chiave. Tutte queste deduzioni sono vaghe e sembrano inutili, finché all'improvviso non raggiungono una massa critica e portano all'unica conclusione possibile: per quanto incredibile possa sembrare, deve essere vera. A questo punto o la chiave viene rivelata, oppure il processo di decrittazione diventa così raffinato che può essere replicato.

Illustriamo con un semplice esempio come funziona l'interpolazione. Supponiamo di voler leggere il diario personale del nostro nemico, Bob. Cifra ogni numero nel suo diario con un semplice sistema crittografico che ha appreso da un annuncio pubblicitario sulla rivista "Prank sulla crittografia". Il sistema funziona nel seguente modo: Bob sceglie due numeri che gli piacciono: e . Da questo momento, per cifrare qualsiasi numero , calcola . Ad esempio, se Bob ha scelto e , la cifra verrà cifrata come .

Supponiamo che il 28 dicembre notiamo che Bob sta scrivendo qualcosa nel suo diario. Quando avrà finito, prenderemo il suo diario in modo discreto e guarderemo l'ultima registrazione:

Data: 235/520
Caro diario,
Oggi è stata una bella giornata. Tra 64 giorni ho un appuntamento con Alice, che vive nell'appartamento 843. Penso davvero che lei possa essere 26!

Poiché siamo molto determinati a seguire Bob al suo appuntamento (in questo scenario abbiamo 15 anni), è fondamentale conoscere la data e l'indirizzo di Alice. Per fortuna, notiamo che il sistema crittografico di Bob è vulnerabile a un attacco di interpolazione. Potremmo non sapere e , ma sappiamo la data di oggi, quindi abbiamo due coppie di "testo in chiaro - testo cifrato". In particolare, sappiamo che viene cifrato in , ma — in . Che annoteremo:

Poiché abbiamo 15 anni, sappiamo già del sistema di due equazioni con due incognite, il che in questa situazione è sufficiente per trovarlo. e senza particolari problemi. Ogni coppia «testo in chiaro-criptato» impone una restrizione sulla chiave di Bob, e due restrizioni insieme sono sufficienti per recuperare completamente la chiave. Nel nostro esempio la risposta e (al , quindi 26 nel diario corrisponde alla parola ‘the one’, cioè «quella giusta» — nota dell’autore).

Gli attacchi di interpolazione, ovviamente, non si limitano a tali esempi semplici. Ogni sistema crittografico che può essere ridotto a un oggetto matematico ben definito e a un elenco di parametri è a rischio di attacco di interpolazione — più l'oggetto è comprensibile, maggiore è il rischio.

I principianti spesso si lamentano che la crittografia è «l'arte di progettare le cose più brutte possibile». Probabilmente gran parte della colpa è degli attacchi di interpolazione. Bob può scegliere di utilizzare un design matematicamente elegante, oppure mantenere la riservatezza del suo incontro con Alice — ma sfortunatamente, di solito non è possibile ottenere entrambe le cose. Questo diventerà chiaro quando infine ci inoltreremo nel tema della crittografia a chiave pubblica.

Cross-protocol/downgrading

Nel film «Now You See Me» (2013), un gruppo di illusionisti cerca di estorcere l'intera fortuna dell'assicuratore corrotto Arthur Tressler. Per accedere al conto bancario di Arthur, gli illusionisti devono fornire o il suo nome utente e password, oppure costringerlo a presentarsi di persona in banca e partecipare allo schema.

Entrambe le opzioni sono molto difficili; i ragazzi sono abituati a esibirsi sul palco, non a partecipare ad operazioni dei servizi segreti. Quindi scelgono un terzo possibile opzione: il loro complice chiama la banca e si spaccia per Arthur. La banca pone alcune domande di sicurezza, come il nome dello zio e il nome del primo animale domestico; i nostri eroi estraggono facilmente queste informazioni da Arthur tramite astute tecniche di ingegneria sociale. Da questo momento, una buona sicurezza della password non ha più importanza.

(Secondo una leggenda metropolitana che abbiamo verificato e confermato, il crittografo Eli Biham si è trovato una volta di fronte a un cassiere di banca che insisteva per l'installazione di una domanda segreta. Quando il cassiere chiese il nome della nonna materna, Biham iniziò a dettare: «Maiuscola X, minuscola y, tre…»).

Anche nella crittografia, se per proteggere lo stesso attivo vengono utilizzati due protocolli crittografici contemporaneamente, di cui uno è molto più debole dell'altro, il sistema finale diventa vulnerabile a un attacco cross-protocol, in cui viene attaccato il protocollo più debole per raggiungere il premio senza toccare quello più forte.

In alcuni casi complessi, non è sufficiente contattare il server tramite un protocollo più debole, ma è necessaria la partecipazione involontaria di un cliente legittimo. Questo può essere organizzato tramite quella che viene chiamata attacco di downgrade. Per comprendere questo attacco, supponiamo che i nostri illusionisti abbiano un compito più difficile di quello del film. Supponiamo che ci siano stati imprevisti per l'impiegato della banca (cassiere) e Arthur, da cui è scaturito il seguente dialogo:

Hacker: Pronto? Sono Arthur Tressler. Vorrei ripristinare la mia password.
Cassiere: Ottimo. Per favore, guarda nel tuo libro personale dei codici segreti, pagina 28, parola 3. Tutti i messaggi successivi saranno crittografati usando questa parola specifica come chiave. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Hacker: Ehi, ehi, aspetta, aspetta. È davvero necessario? Non possiamo semplicemente parlare come persone normali?
Cassiere: Ti sconsiglio di farlo.
Hacker: Sto solo… ascolta, ho avuto una giornata di merda, chiaro? Sono un cliente VIP e non ho voglia di setacciare questi stupidi libri di codici.
Cassiere: Va bene. Se insisti, signor Tressler. Cosa desidera?
Hacker: Per favore, vorrei trasferire tutti i miei soldi al Fondo Nazionale per le Vittime di Arthur Tressler.
(Pausa).
Cassiere: Quindi, capisco. Per favore, fornisci il tuo codice PIN per transazioni di grandi dimensioni.
Hacker: Il mio cosa?
Cassiere: A tua richiesta personale, le transazioni di tale entità richiedono l'inserimento del codice PIN per transazioni di grandi dimensioni. Questo codice ti è stato fornito all'apertura del conto.
Hacker:… L'ho perso. È davvero necessario? Non puoi semplicemente approvare l'operazione?
Cassiere: No. Mi scuso, signor Tressler. Ancora una volta, è una misura di sicurezza che hai richiesto. Se vuoi, possiamo inviarti un nuovo codice PIN nella tua cassetta postale.

I nostri eroi rimandano l'operazione. Scansionano diverse grandi transazioni di Tressler, sperando di sentire il codice PIN; ma ogni volta la conversazione si trasforma in un'ibrida confusa prima che venga detto qualcosa di interessante. Finalmente, un bel giorno, mettono in atto il piano. Aspettano pazientemente il momento in cui Tressler deve effettuare una grande transazione telefonica, si collega alla linea, e poi…

Tressler: Salve. Vorrei effettuare una transazione da remoto, per favore.
Cassiere: Ottimo. Per favore, guarda il tuo libro personale dei codici segreti, pagina…
(L'hacker preme un pulsante; la voce del cassiere diventa un rumore indistinto).
Cassiere: — #@$#@$#*@$$@#* sarà cifrato con questa parola come chiave. AAAYRR PLRQRZ MMNJK LOJBAN…
Tressler: Mi scusi, non ho capito bene. Può ripetere? A quale pagina? Quale parola?
Cassiere: È la pagina @#$@#*$)#*#@()#@$(#@*$(#@*.
Tressler: Cosa?
Cassiere: La parola numero venti @$#@$#%#$.
Tressler: Sul serio! Basta, per favore! Il tuo protocollo di sicurezza è un circo. So che puoi semplicemente parlare normalmente con me.
Cassiere: Non ti consiglio…
Tressler: E io non ti consiglio di perdere tempo. Non voglio più sentire di questo finché non risolverete i problemi con la vostra linea telefonica. Possiamo effettuare questa transazione o no?
Cassiere:… sì. Va bene. Cosa desideri?
Tressler: Vorrei trasferire 20.000 dollari alla società Lord Business Investments, numero di conto…
Cassiere: Un momento, per favore. È una grande transazione. Per favore, indica il tuo codice PIN per le grandi transazioni.
Tressler: Cosa? Ah, giusto. 1234.

Ecco un attacco al ribasso. Un protocollo più debole «parla semplicemente chiaramente» era previsto come opzione un piano di emergenza. Eppure siamo qui.

Puoi chiederti chi, in pieno possesso delle sue facoltà, progettarebbe un sistema reale del tipo «sicuro, a meno che non venga richiesto diversamente», come descritto sopra. Ma proprio come una banca immaginaria prende rischi per mantenere i clienti che non amano la crittografia, così i sistemi in generale spesso si piegano a requisiti che sono indifferenti o addirittura apertamente ostili alla sicurezza.

Una storia del genere è accaduta con il protocollo SSLv2 nel 1995. Il governo degli Stati Uniti ha da tempo considerato la crittografia come un'arma, da tenere lontana da nemici esterni e interni. I frammenti di codice venivano approvati singolarmente per l'esportazione dagli Stati Uniti, spesso a condizione di un indebolimento intenzionale dell'algoritmo. Alle aziende Netscape, sviluppatore del browser più popolare, Netscape Navigator, fu concesso di utilizzare SSLv2 solo con una chiave RSA a 512 bit inizialmente vulnerabile (e 40 bit per RC4).

Alla fine del millennio, le regole si sono allentate e l'accesso alla crittografia moderna è diventato ampiamente disponibile. Tuttavia, i client e i server hanno mantenuto per molti anni la crittografia 'esportabile' indebolita a causa della stessa inerzia che mantiene il supporto per qualsiasi sistema obsoleto. I client pensavano di poter incontrare un server che non supportasse nient'altro. Anche i server facevano lo stesso. Certamente, il protocollo SSL stabilisce che client e server non dovrebbero mai utilizzare un protocollo debole quando uno migliore è disponibile. Ma la stessa premessa valeva per Tressler e la sua banca.

Questa teoria è stata applicata in due attacchi clamorosi che hanno scosso la sicurezza del protocollo SSL nel 2015, entrambi scoperti dai ricercatori di Microsoft e INRIA. Innanzitutto, a febbraio sono stati divulgati i dettagli dell'attacco FREAK, e tre mesi dopo un altro simile chiamato Logjam, di cui parleremo in dettaglio quando tratteremo gli attacchi alla crittografia a chiave pubblica.

Vulnerabilità FREAK è emerso quando i ricercatori hanno analizzato le implementazioni client/server di TLS e hanno scoperto un errore curioso. In queste implementazioni, se il client non richiede nemmeno di utilizzare una crittografia debole da esportazione, ma il server risponde comunque con quelle chiavi, il client dice 'Va bene' e passa a un insieme di cifrari deboli.

All'epoca, tutti consideravano la crittografia per l'esportazione obsoleta e vietata per l'uso, quindi l'attacco è stato un vero shock e ha colpito molti domini importanti, inclusi i siti della Casa Bianca, dell'agenzia delle entrate americana e della NSA. Peggio ancora, si è scoperto che molti server vulnerabili ottimizzavano le prestazioni riutilizzando le stesse chiavi invece di crearne di nuove per ogni sessione. Questo ha permesso, dopo una retrocessione del protocollo, anche un attacco di precomputation: violare una chiave era relativamente costoso (100 dollari e 12 ore al momento della pubblicazione), ma il costo pratico per un attacco su una connessione è notevolmente diminuito. Basta indovinare una volta la chiave del server per compromettere le cifrature per tutte le connessioni successive da quel momento in poi.

E prima di procedere oltre, vale la pena menzionare un attacco avanzato...

Attacco dell'oracolo

Moxie Marlinspike è famoso come il padre del crittomesaggista cross-platform Signal; ma a noi piace un'innovazione meno nota che ha introdotto - il principio della dannazione crittografica (Cryptographic Doom Principle). Parafrasando leggermente, si può dire così: «Se un protocollo esegue qualsiasi operazione crittografica su un messaggio proveniente da una sorgente potenzialmente dannosa e si comporta in modo diverso a seconda del risultato, è destinato a fallire». Oppure in forma più cruda: «Non prendere informazioni dal nemico per l'elaborazione, e se lo fai, almeno non mostrare il risultato.»

Lasciamo da parte i buffer overflow, le iniezioni di comandi e simili; essi esulano da questa discussione. La violazione del «principio della dannazione» porta a seri compromessi della crittografia perché il protocollo si comporta esattamente come doveva.

Per esempio, prendiamo una costruzione fittizia con un cifrario di sostituzione vulnerabile e poi dimostriamo un possibile attacco. Anche se abbiamo già visto un attacco a un cifrario di sostituzione attraverso l'analisi delle frequenze, non è solo «un altro modo per rompere lo stesso cifrario». Al contrario, gli attacchi dell'oracolo sono una invenzione molto più moderna, applicabile a molte situazioni in cui l'analisi delle frequenze fallisce, e vedremo una dimostrazione di questo nella sezione successiva. Qui, un semplice cifrario è scelto solo per rendere l'esempio più comprensibile.

Quindi, Alice e Bob comunicano utilizzando un semplice cifrario di sostituzione, usando una chiave conosciuta solo da loro. Sono molto rigorosi riguardo alla lunghezza dei messaggi: la loro lunghezza è esattamente di 20 caratteri. Pertanto, hanno concordato che se qualcuno desidera inviare un messaggio più breve, deve aggiungere un testo fittizio alla fine del messaggio, affinché sia esattamente di 20 caratteri. Dopo una certa discussione, hanno deciso che accetteranno solo i seguenti testi fittizi: a, bb, ccc, dddd e così via. In questo modo, è noto il testo fittizio di qualsiasi lunghezza necessaria.

Quando Alice o Bob ricevono un messaggio, controllano prima che il messaggio abbia la lunghezza corretta (20 caratteri) e che il suffisso sia il testo fittizio corretto. Se non è così, rispondono con un messaggio di errore appropriato. Se la lunghezza del testo e il testo fittizio sono in ordine, il destinatario legge il messaggio e invia una risposta crittografata.

Durante l'attacco, un malintenzionato si spaccia per Bob e invia messaggi falsi ad Alice. I messaggi sono completamente privi di senso: il malintenzionato non ha la chiave, quindi non può falsificare un messaggio significativo. Ma poiché il protocollo viola il principio di inevitabilità, il malintenzionato può comunque tendere una trappola ad Alice affinché riveli informazioni sulla chiave, come mostrato di seguito.

Hacker: PREWF ZHJKL MMMN. LA
Alice: Testo fittizio non valido.
Hacker: PREWF ZHJKL MMMN. LB
Alice: Testo fittizio non valido.
Hacker: PREWF ZHJKL MMMN. LC
Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Il ladro non ha idea di cosa abbia appena detto Alice, ma nota che il carattere C deve corrispondere a a, poiché Alice ha accettato il testo fittizio.

Hacker: REWF ZHJKL MMMN. LAA
Alice: Testo fittizio non valido.
Hacker: REWF ZHJKL MMMN. LBB
Alice: Testo fittizio non valido.
Dopo vari tentativi...
Hacker: REWF ZHJKL MMMN. LGG
Alice: Testo fittizio non valido.
Hacker: REWF ZHJKL MMMN. LHH
Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Ancora una volta, il ladro non ha idea di cosa abbiano appena detto Alice, ma nota che H deve corrispondere a b, poiché Alice ha accettato il testo fittizio.

E così via, finché il malintenzionato non scopre il significato di ogni carattere.

A prima vista, il metodo ricorda un attacco basato su testo in chiaro scelto. Dopotutto, l'attaccante seleziona i testi cifrati e il server li elabora docilmente. La principale differenza che rende questi attacchi praticabili nel mondo reale è che l'attaccante non ha bisogno di accesso alla decifratura effettiva: basta una risposta del server, anche una innocua come "Testo fittizio errato".

Sebbene questo specifico attacco sia istruttivo, non bisognerebbe ossessionarsi troppo sulla specificità dello schema del "testo fittizio", sul particolare sistema crittografico utilizzato o sulla sequenza esatta dei messaggi inviati dall'attaccante. L'idea principale è come Alice reagisca in modo diverso a seconda delle proprietà del testo in chiaro, e lo fa senza verificare che il testo cifrato corrispondente provenga effettivamente da una parte fidata. In questo modo, Alice consente all'attaccante di estorcere informazioni riservate dalle sue risposte.

In questo scenario, ci sono molte cose che possono essere modificate. I simboli a cui Alice reagisce, oppure la stessa differenza nel suo comportamento, o anche il sistema crittografico utilizzato. Ma il principio rimarrà lo stesso, e l'attacco in generale rimarrà praticabile in una forma o nell'altra. L'implementazione di base di questo attacco ha aiutato a scoprire diversi errori di sicurezza, che esamineremo presto; ma prima è necessario apprendere alcune lezioni teoriche. Come sfruttare questo "scenario di Alice" in un attacco capace di funzionare su un moderno sistema di cifratura? È possibile, anche solo in teoria?

Nel 1998, il crittografo svizzero Daniel Bleichenbacher ha risposto affermativamente a questa domanda. Ha dimostrato un attacco oracle in un ampiamente utilizzato sistema crittografico a chiave pubblica RSA, utilizzando uno specifico schema di messaggi. In alcune implementazioni di RSA, il server risponde con diversi messaggi di errore, a seconda che il testo in chiaro corrisponda allo schema o meno; questo è stato sufficiente per eseguire l'attacco.

Quattro anni dopo, nel 2002, il crittografo francese Serge Vaudenay ha dimostrato un attacco all'oracolo, quasi identico a quello descritto sopra nello scenario di Alice - ad eccezione del fatto che, invece di un cifrario inventato, ha violato una rispettabile classe di moderni cifrari, realmente utilizzati dalle persone. In particolare, l'attacco di Vaudenay si concentra su cifrari a lunghezza fissa di input ("cifrari a blocchi"), quando vengono utilizzati nella cosiddetta "modalità di crittografia CBC" e con uno schema di riempimento popolare, per lo più equivalente a quello dello scenario di Alice.

Sempre nel 2002, il crittografo americano John Kelsey - coautore Twofish ha proposto diverse forme di attacco all'oracolo sui sistemi che comprimono i messaggi e poi li criptano. Il più notevole tra essi è stato un attacco che ha sfruttato la possibilità di derivare spesso la lunghezza originale del testo in chiaro dalla lunghezza del testo crittografato. In teoria, ciò consente di condurre un attacco all'oracolo che recupera parti del testo originale in chiaro.

Di seguito forniamo una descrizione più dettagliata degli attacchi di Vaudenay e Kelsey (forniremo una descrizione più dettagliata dell'attacco di Bleichenbacher quando passeremo agli attacchi sulla crittografia a chiave pubblica). Nonostante i nostri sforzi, il testo diventa piuttosto tecnico; quindi, se quanto sopra è sufficiente per voi, saltate le prossime due sezioni.

Attacco di Vaudenay

Per comprendere l'attacco di Vaudenay, è prima necessario parlare un po' più in dettaglio dei cifrari a blocchi e delle modalità di crittografia. Un "cifrario a blocchi" è, come già accennato, un cifrario che prende una chiave e un input di lunghezza fissa («lunghezza del blocco») e restituisce un blocco crittografato della stessa lunghezza. I cifrari a blocchi sono ampiamente utilizzati e considerati relativamente sicuri. Il DES, ora ritirato, considerato il primo cifrario moderno, era un cifrario a blocchi. Come accennato in precedenza, lo stesso vale per l'AES, oggi ampiamente utilizzato.

Sfortunatamente, i cifrari a blocchi hanno una grave debolezza. La dimensione tipica di un blocco è di 128 bit, ovvero 16 caratteri. È evidente che la crittografia moderna richiede di lavorare con dati di dimensioni maggiori, ed è qui che entrano in gioco le modalità di crittografia. La modalità di crittografia è sostanzialmente un hack: è un modo per applicare in qualche modo un cifrario a blocchi che accetta solo dati di una certa dimensione a input di lunghezza arbitraria.

L'attacco di Waterne è indirizzato sulla modalità di funzionamento popolare CBC (Cipher Block Chaining, modo di concatenazione dei blocchi di testo cifrato). L'attacco considera il cifrario a blocchi sottostante come una scatola nera magica e inaccessibile, aggirando completamente la sua sicurezza.

Ecco un diagramma che mostra come funziona la modalità CBC:

Il segno più cerchiato indica l'operazione XOR (exclusive OR). Ad esempio, il secondo blocco di testo cifrato è stato ottenuto:

Eseguendo l'operazione XOR sul secondo blocco di testo in chiaro con il primo blocco di testo cifrato.
Cifrando il blocco ottenuto con un cifrario a blocchi, utilizzando la chiave.

Poiché CBC utilizza intensamente l'operazione binaria XOR, sfruttiamo l'occasione per rinfrescare alcune delle sue proprietà:

Idempotenza:
Commutatività:
Associatività:
Involutività:
Per byte: byte n di = (byte n di ) (byte n di )

In generale, queste proprietà implicano che se abbiamo un'equazione che coinvolge operazioni XOR e una incognita, può essere risolta. Ad esempio, se sappiamo che con l'incognita e conosciute e , allora possiamo affidarci alle proprietà sopra menzionate per risolvere l'equazione per . Applicando XOR su entrambi i lati dell'equazione con , otteniamo . Tra poco tutto ciò diventerà molto rilevante.

Tra il nostro scenario di Alice e l'attacco di Waterne ci sono due piccole differenze e una principale. Due piccole:

Nello scenario, Alice si aspettava che i testi in chiaro terminassero con i caratteri a, bb, ccc e così via. Nell'attacco di Waterne, invece, la vittima si aspetta che i testi in chiaro finiscano con N byte N (cioè esadecimale 01 o 02 02, o 03 03 03 e così via). Si tratta di una differenza puramente cosmetica.
Nello scenario di Alice era facile dire se Alice avesse ricevuto il messaggio, da la risposta "Testo fittizio errato". Nell'attacco Waterne è necessaria un'analisi più approfondita e l'implementazione esatta dal lato della vittima è cruciale; ma per brevità, diamo per scontato che questa analisi sia comunque possibile.

La principale differenza:

Poiché non utilizziamo lo stesso sistema crittografico, il legame tra i byte dell testo cifrato controllati dall'aggressore e i segreti (chiave e testo in chiaro) sarà ovviamente diverso. Pertanto, l'aggressore dovrà utilizzare una strategia diversa nella generazione dei testi cifrati e nell'interpretazione delle risposte del server.

Questa è la principale differenza — l'ultimo pezzo del puzzle per capire l'attacco Waterne, quindi prendiamoci un momento per riflettere su come sia possibile organizzare un attacco da oracolo su CBC.

Supponiamo di avere un testo cifrato CBC di 247 blocchi e vogliamo decifrarlo. Possiamo inviare al server messaggi falsi, come in precedenza si potevano inviare messaggi falsi ad Alice. Il server decifrerà i messaggi per noi, ma non mostrerà la decifratura: invece, come nel caso di Alice, il server fornirà solo un bit di informazione: se il testo in chiaro ha un riempimento valido oppure no.

Considera che nello scenario di Alice avevamo i seguenti rapporti:

$$display$$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key}) = text{plaintext}$$display$$

Chiamiamolo "l'equazione di Alice". Abbiamo controllato il testo cifrato; il server (Alice) forniva informazioni vaghe sul testo in chiaro ricevuto; e questo ci ha permesso di dedurre informazioni sull'ultimo fattore — la chiave. Analogamente, se riuscissimo a trovare un legame per lo scenario CBC, potremmo estrarre alcune informazioni segrete anche lì.

Fortunatamente, ci sono realmente rapporti che possiamo utilizzare. Consideriamo gli output dell'ultima chiamata di decifratura del cifrario a blocchi e chiamiamo questi dati . Denotiamo anche i blocchi di testo in chiaro e i blocchi di testo cifrato . Guarda di nuovo il diagramma CBC e nota cosa emerge:

Chiamiamolo "l'equazione CBC".

Nello scenario di Alice, controllando il testo cifrato e osservando le perdite di informazioni sul corrispondente testo in chiaro, siamo riusciti a organizzare un attacco che ha recuperato il terzo membro dell'equazione - la chiave. Nello scenario CBC controlliamo anche il testo cifrato e osserviamo perdite di informazioni sul corrispondente testo in chiaro. Se c'è un'analogia, possiamo ottenere informazioni su .

Supponiamo di aver davvero recuperato , e allora? Bene, possiamo subito estrarre l'intero ultimo blocco di testo in chiaro (), semplicemente inserendo (che abbiamo) e
ottenendo nell'equazione CBC.

Quindi, siamo ottimisti riguardo al piano generale dell'attacco e ora è il momento di esaminare i dettagli. Facciamo attenzione a come si verifica la perdita di informazioni sul testo in chiaro sul server. Nello scenario di Alice, la perdita si è verificata perché Alice rispondeva con un messaggio corretto solo se $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ terminava con la stringa a (o bb, e così via, ma le possibilità che queste condizioni si attivassero per caso erano molto basse). Analogamente con CBC, il server accetta il riempimento se e solo se termina con esadecimale 01. Proviamo quindi lo stesso trucco: inviare testi cifrati falsi con i nostri valori falsi , finché il server non accetta il riempimento.

Quando il server accetta il riempimento per uno dei nostri messaggi falsi, ciò significa che:

Ora utilizziamo la proprietà del byte XOR:

Conosciamo il primo e il terzo membro. E abbiamo già visto che questo consente di recuperare il membro rimanente - l'ultimo byte da :

Questo ci dà anche l'ultimo byte dell'ultimo blocco del testo in chiaro attraverso l'equazione CBC e la proprietà del byte.

Potremmo fermarci qui e accontentarci di aver condotto un attacco su un cifrario teoricamente resistente. Ma in realtà possiamo fare molto di più: possiamo davvero recuperare l'intero testo. Ciò richiede un certo trucco che non era presente nello scenario originale di Alice e non rientra nei requisiti obbligatori dell'attacco all'oracolo, ma il metodo vale comunque la pena di essere studiato.

Per comprenderlo, presta prima attenzione a che cosa deriva l'ottenimento del valore corretto dell'ultimo byte Abbiamo acquisito una nuova capacità. Ora, quando si falsificano i testi cifrati, possiamo controllare l'ultimo byte del corrispondente testo in chiaro. Ancora una volta, questo è legato all'equazione CBC e alla proprietà a byte:

Poiché ora conosciamo il secondo membro, possiamo usare il nostro controllo sul primo per gestire il terzo. Dobbiamo semplicemente calcolare:

Prima non eravamo in grado di farlo, perché non avevamo ancora l'ultimo byte. .

Come ci sarà utile? Supponiamo ora che creiamo tutti i testi cifrati in modo che nei corrispondenti testi in chiaro l'ultimo byte sia uguale a 02. Ora il server accetta il riempimento solo se il testo in chiaro termina con 02 02. Poiché abbiamo corretto l'ultimo byte, ciò accadrà solo se il penultimo byte del testo in chiaro è anch'esso uguale a 02. Continuiamo a inviare blocchi di texto cifrati falsificati, modificando il penultimo byte, finché il server non accetta il riempimento per uno di essi. A questo punto otteniamo:

E ripristiniamo il penultimo byte esattamente come abbiamo ripristinato l'ultimo. Continuiamo allo stesso modo: correggiamo gli ultimi due byte del testo in chiaro in 03 03, ripetiamo questo attacco per il terzo byte dalla fine e così via, fino a ripristinare completamente .

E il resto del testo? Nota che il valore è in realtà $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Possiamo mettere qualsiasi altro blocco al posto di , e l'attacco avrà comunque successo. In effetti, possiamo chiedere al server di applicare $inline$text{BLOCK_DECRYPT}$inline$ per qualsiasi dato. A questo punto il gioco è finito - possiamo decifrare qualsiasi testo cifrato (dai un'altra occhiata al diagramma di decifratura CBC per esserne certo; e nota che il vettore IV è pubblico).

Questo specifico metodo gioca un ruolo cruciale nell'attacco dell'oracolo, con cui ci confronteremo più avanti.

Attacco Kelsey

Il nostro affine John Kelsey ha esposto i principi alla base di molti possibili attacchi, e non solo i dettagli specifici di un attacco a un particolare cifrario. Il suo articolo del 2002 è uno studio sugli attacchi possibili a dati compressi cifrati. Pensavi che per compiere un attacco fosse necessaria solo l'informazione che i dati erano stati compressi prima della cifratura? A quanto pare, è sufficiente.

Questo sorprendente risultato è determinato da due principi. Innanzitutto, esiste una forte correlazione tra la lunghezza del testo in chiaro e la lunghezza del testo cifrato; per molti algoritmi, l'uguaglianza esatta. In secondo luogo, quando viene effettuata una compressione, esiste anch'essa una forte correlazione tra la lunghezza del messaggio compresso e il grado di "rumorosità" del testo in chiaro, ovvero la quota di simboli non ripetuti (termine tecnico - "alta entropia").

Per vedere il principio in azione, consideriamo due testi in chiaro:

Testo in chiaro 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Testo in chiaro 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Assumiamo che entrambi i testi in chiaro siano stati compressi e poi cifrati. Ottieni due testi cifrati risultanti e devi indovinare quale testo cifrato corrisponde a quale testo in chiaro:

Testo cifrato 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Testo cifrato 2: DWKJZXYU

La risposta è chiara. Tra i testi in chiaro, solo il testo in chiaro 1 potrebbe essere stato compresso fino alla scarsa lunghezza del secondo testo cifrato. Lo abbiamo scoperto senza sapere nulla dell'algoritmo di compressione, della chiave di cifratura o persino del cifrario stesso. Rispetto alla gerarchia delle possibili attacchi crittografici, è una sorta di follia.

Kelsey rileva inoltre che in determinate circostanze insolite questo principio può essere utilizzato anche per condurre un attacco oracle. In particolare, descrive come un aggressore possa recuperare il testo in chiaro segreto, se può costringere il server a cifrare i dati del modulo (testo in chiaro, seguito da , mentre controlla e può in qualche modo verificare la lunghezza del risultato cifrato.

Ancora una volta, come in altri attacchi oracle, abbiamo una relazione:

Ancora una volta, controlliamo un membro (), vediamo una piccola perdita di informazioni su un altro membro (testo cifrato) e cerchiamo di recuperare quest'ultimo (testo in chiaro). Nonostante l'analogia, questa è una situazione piuttosto insolita rispetto ad altri attacchi oracle che abbiamo visto.

Per illustrare come tale attacco possa funzionare, utilizziamo uno schema di compressione inventato che abbiamo appena ideato: TOYZIP. Esso cerca righe di testo che erano già apparse in precedenza nel testo e le sostituisce con tre byte di riempimento che indicano dove trovare un'istanza precedente della riga e quante volte appare. Ad esempio, la riga helloworldhello può essere compressa in helloworld[00][00][05] lunghezza di 13 byte rispetto all'originale di 15 byte.

Supponiamo che un attaccante stia cercando di recuperare il testo in chiaro del modulo password=..., dove la password stessa è sconosciuta. Secondo il modello di attacco di Kelsey, l'attaccante può chiedere al server di comprimere e poi crittografare i messaggi del modulo (testo in chiaro, seguito da ), dove — testo arbitrario. Quando il server ha terminato, comunica la lunghezza del risultato. L'attacco si svolge nel seguente modo:

Hacker: Per favore, comprimi e crittografa il testo in chiaro senza alcun riempimento.
Server: La lunghezza del risultato è 14.
Hacker: Per favore, comprimi e crittografa il testo in chiaro a cui è stato aggiunto password=a.
Server: La lunghezza del risultato è 18.

L'attaccante nota: [originale 14] + [tre byte che hanno sostituito password=] + a

Hacker: Per favore, comprimi e crittografa il testo in chiaro a cui è stato aggiunto password=b.
Server: La lunghezza del risultato è 18.
Hacker: Per favore, comprimi e crittografa il testo in chiaro a cui è stato aggiunto password=c.
Server: La lunghezza del risultato è 17.

L'attaccante nota: [originale 14] + [tre byte che hanno sostituito password=c]. Questo implica che il testo originale in chiaro contenga la stringa password=c. Cioè, la password inizia con la lettera c

Hacker: Per favore, comprimi e crittografa il testo in chiaro a cui è stato aggiunto password=ca.
Server: La lunghezza del risultato è 18.

L'attaccante nota: [originale 14] + [tre byte che hanno sostituito password=c] + a

Hacker: Per favore, comprimi e crittografa il testo in chiaro a cui è stato aggiunto password=cb.
Server: La lunghezza del risultato è 18.

(… un po' di tempo dopo…)

Hacker: Per favore, comprimi e crittografa il testo in chiaro a cui è stato aggiunto password=co.
Server: La lunghezza del risultato è 17.

L'attaccante nota: [originale 14] + [tre byte che hanno sostituito password=co]. Secondo la stessa logica, l'attaccante conclude che la password inizia con le lettere co

E così via, fino a quando non viene recuperata l'intera password.

Il lettore può essere perdonato per pensare che si tratti di un esercizio puramente accademico e che uno scenario di attacco del genere non si verificherà mai nel mondo reale. Purtroppo, come vedremo presto, in crittografia è meglio non essere troppo sicuri.

Vulnerabilità famose: CRIME, POODLE, DROWN

Infine, dopo un'analisi dettagliata della teoria, possiamo vedere come queste tecniche vengono applicate in attacchi crittografici reali.

CRIME

Se l'attacco è mirato al browser e alla rete della vittima, alcune cose saranno più semplici e altre più complesse. Ad esempio, vedere il traffico della vittima è facile: basta sedere con essa nello stesso caffè con WiFi. Per questo motivo, di solito si raccomanda alle potenziali vittime (cioè a chiunque) di utilizzare una connessione crittografata. Sarà più difficile, ma comunque possibile, eseguire richieste HTTP a nome della vittima verso un sito esterno (ad esempio, Google). Il malevolo deve attirare la vittima su una pagina web dannosa con uno script che effettui la richiesta. Il browser web fornirà automaticamente il corrispondente cookie di sessione.

Questo sembra sorprendente. Se Bob è entrato su evil.com, davvero lo script su questo sito potrebbe semplicemente chiedere a Google di inviare la password di Bob via email a attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), ed era popolare circa a metà degli anni '90. Oggi, se evil.com provasse un trucco del genere, Google (o qualsiasi sito rispettabile) risponderebbe solitamente: «Ottimo, ma il tuo token CSRF per questa transazione sarà… mmm… tre trilioni e sette. Per favore, ripeti questo numero». I browser moderni applicano qualcosa chiamato «politica di origine identica» (same-origin policy), secondo la quale gli script sul sito A non possono accedere alle informazioni inviate dal sito web B. Pertanto, lo script su evil.com può inviare richieste a Riconnessione TCP, ma non può leggere le risposte o in realtà completare la transazione.

Dobbiamo sottolineare che se Bob non utilizza una connessione crittografata, tutte queste protezioni sono inutili. L'hacker può semplicemente leggere il traffico di Bob e recuperare il cookie di sessione di Google. Con questo cookie, può semplicemente aprire una nuova scheda Google senza uscire dal proprio browser e spacciarsi per Bob, senza affrontare le fastidiose politiche di same-origin. Ma, sfortunatamente per l'hacker, questo accade sempre meno. Internet, nel suo complesso, ha dichiarato guerra alle connessioni non crittografate, e il traffico in uscita di Bob è probabilmente crittografato, che gli piaccia o meno. Inoltre, sin dall'inizio dell'implementazione del protocollo, il traffico è stato anche comprimente prima della crittografia; è stata una prassi comune per ridurre la latenza.

Qui entra in gioco CRIME (Compression Ratio Infoleak Made Easy, semplice fuga attraverso il rapporto di compressione). Una vulnerabilità dimostrata nel settembre 2012 dai ricercatori di sicurezza Giuliano Rizzo e Thai Duong. Abbiamo già analizzato tutta la base teorica per comprendere cosa abbiano fatto e come. L'hacker può costringere il browser di Bob a inviare richieste a Google e poi intercettare le risposte nella rete locale in forma compressa e crittografata. Pertanto, abbiamo:

Qui l'hacker controlla la richiesta e ha accesso a uno sniffing del traffico, inclusa la dimensione dei pacchetti. Lo scenario fittizio di Kelsey è diventato realtà.

Comprendendo la teoria, gli autori di CRIME hanno creato un exploit in grado di rubare i cookie di sessione per un'ampia gamma di siti, tra cui Gmail, Twitter, Dropbox e Github. La vulnerabilità ha colpito la maggior parte dei moderni browser web, il che ha portato all'emissione di patch che hanno silenziosamente seppellito la funzione di compressione in SSL, affinché non venisse utilizzata affatto. L'unico protetto dalla vulnerabilità è stato l'onorevole Internet Explorer, che non ha mai utilizzato la compressione SSL.

POODLE

Nell'ottobre 2014, il team di sicurezza di Google ha fatto scalpore nella comunità della sicurezza. Sono riusciti a sfruttare una vulnerabilità nel protocollo SSL, corretta più di dieci anni fa.

Si è scoperto che, sebbene sui server fosse attivo un magnifico e nuovo TLSv1.2, molti avevano mantenuto il supporto per l'obsoleto SSLv3 per retrocompatibilità con Internet Explorer 6. Abbiamo già parlato degli attacchi al downgrade, quindi potete immaginare cosa stesse accadendo. Un sabotaggio ben organizzato del protocollo di handshake – e i server sono pronti a tornare al vecchio SSLv3, annullando di fatto gli ultimi 15 anni di ricerca nel campo della sicurezza.

Per dare un contesto storico, ecco un breve riassunto della storia di SSL fino alla versione 2 di Matthew Green:

Transport Layer Security (TLS) è il protocollo di sicurezza più importante su Internet. [..] quasi ogni transazione che effettuate su Internet dipende da TLS. [..] Ma TLS non è sempre stato TLS. Il protocollo ha iniziato la sua vita in Netscape Communications sotto il nome di «Secure Sockets Layer» o SSL. Si dice che la prima versione di SSL fosse così terribile che gli sviluppatori hanno raccolto tutte le stampe del codice e le hanno seppellite in una discarica segreta nel New Mexico. Di conseguenza, la prima versione pubblica di SSL è in realtà la versione SSL 2. È piuttosto spaventosa, e [..] è stata un prodotto della metà degli anni '90, che i moderni crittografi considerano come «i secoli bui della crittografia». Molti degli attacchi crittografici più detestabili che conosciamo oggi non erano ancora stati scoperti. Di conseguenza, gli sviluppatori del protocollo SSLv2 hanno dovuto sostanzialmente muoversi a tentoni nel buio, e hanno incontrato molti orribili mostri – a loro dispiacere e nostro beneficio, poiché gli attacchi a SSLv2 hanno lasciato lezioni preziose per la generazione successiva di protocolli.

Dopo questi eventi, nel 1996, l'azienda Netscape delusa ha riprogettato il protocollo SSL da zero. Il risultato è stato SSL versione 3, che ha corretto diversi noti problemi di sicurezza del suo predecessore.

Fortunatamente per gli hacker, «diversi» non significa «tutti». In generale, SSLv3 forniva tutti i mattoni necessari per lanciare un attacco di Waternè. Il protocollo usava un cifrario a blocchi in modalità CBC e uno schema di riempimento non sicuro (risolto in TLS; da qui la necessità di un attacco di downgrade). Se ricordi lo schema di riempimento nella nostra descrizione iniziale dell'attacco di Waternè, lo schema SSLv3 è molto simile.

Ma, sfortunatamente per gli hacker, «simile» non significa «identico». Lo schema di riempimento SSLv3 ha la forma di «N byte casuali, seguiti dal numero N». Prova in queste condizioni a selezionare un blocco immaginario di testo cifrato e passa attraverso tutte le fasi dello schema originale di Waternè: scoprirai che l'attacco estrae con successo l'ultimo byte dal corrispondente blocco di testo in chiaro, ma non va oltre. Decrittare ogni 16° byte del testo cifrato è un ottimo trucco, ma non è una vittoria.

Di fronte a questo fallimento, il team di Google ha adottato una misura estrema: sono passati a un modello di minaccia più potente — quello usato in CRIME. Se ipotizziamo che l'attaccante sia uno script eseguito nella scheda del browser della vittima, e possa estrarre i cookie di sessione, l'attacco rimane comunque impressionante. Anche se il modello di minaccia più ampio è meno realistico, nella sezione precedente abbiamo già visto che questo modello specifico è realizzabile.

Considerando tali capacità potenti dell'hacker, ora l'attacco può continuare. Tieni presente che l'aggressore sa dove nel header viene visualizzato il file cookie crittografato della sessione e gestisce la lunghezza della richiesta HTTP precedente. Pertanto, è in grado di manipolare la richiesta HTTP in modo da allineare l'ultimo byte del cookie alla fine del blocco. Ora questo byte è pronto per essere decrittografato. Basta aggiungere un carattere alla richiesta, e il penultimo byte del cookie rimarrà al suo posto e sarà adatto a essere utilizzato dallo stesso metodo. L'attacco prosegue in questo modo finché il file cookie non è completamente ricostruito. Questo si chiama POODLE: Padding Oracle on Downgraded Legacy Encryption, ovvero Oracle di riempimento su crittografia obsoleta abbassata.

DROWN

Come abbiamo già accennato, SSLv3 aveva dei difetti, ma era sostanzialmente diverso dal suo predecessore, poiché il difettoso SSLv2 era un prodotto di un'altra epoca. Qui era possibile interrompere il messaggio a metà: ci sto solo sopra il mio cadavere si trasformava in ci sto; il cliente e il server potevano incontrarsi su Internet, stabilire fiducia e scambiare segreti davanti agli occhi di un aggressore, che poi si spacciava facilmente per entrambi. C'era anche il problema della crittografia da esportazione, di cui abbiamo parlato riguardo a FREAK. Quella era la Sodoma e Gomorra della crittografia.

Nel marzo 2016, un team di ricercatori provenienti da diversi ambiti tecnici si è riunito e ha fatto una scoperta sorprendente: SSLv2 è ancora utilizzato nei sistemi di sicurezza. Sì, gli aggressori non potevano più abbassare le moderne sessioni TLS a SSLv2, poiché questa falla è stata chiusa dopo FREAK e POODLE, ma possono ancora connettersi ai server e avviare sessioni SSLv2 autonomamente.

Chiederai, che ce ne importa di cosa fanno là? Hanno una sessione vulnerabile, ma questo non dovrebbe influenzare le altre sessioni o la sicurezza del server — giusto? Beh, non proprio. Sì, dovrebbe essere così in teoria. Ma no — perché la generazione dei certificati SSL comporta un certo onere, il che porta molti server a utilizzare gli stessi certificati e, di conseguenza, le stesse chiavi RSA per le connessioni TLS e SSLv2. Ancora peggio, a causa di un bug di OpenSSL in questa popolare implementazione di SSL, l'opzione 'Disabilita SSLv2' non funzionava praticamente.

Questo ha reso possibile un attacco cross-protocollo a TLS, noto come DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, decriptazione RSA con crittografia obsoleta e indebolita). Ricordiamo che questo non è lo stesso di un attacco Downgrade; l'hacker non deve agire come un 'man in the middle' e non deve coinvolgere il cliente in una sessione non sicura. I malintenzionati avviano semplicemente una sessione SSLv2 non sicura con il server, attaccano il protocollo debole e recuperano la chiave segreta del server RSA. Questa chiave è valida anche per le connessioni TLS, e da quel momento nessuna sicurezza TLS potrà salvarla dall'hacking.

Ma per eseguire l'attacco è necessaria un'attacco funzionante contro SSLv2, che consenta di recuperare non solo il traffico specifico, ma anche la chiave segreta del server RSA. Anche se è una sfida complessa, i ricercatori potevano scegliere qualsiasi vulnerabilità che fosse stata completamente chiusa dopo SSLv2. Alla fine hanno trovato la variante adatta: l'attacco di Bleichenbacher, di cui abbiamo parlato in precedenza e che spiegheremo in dettaglio nel prossimo articolo. SSL e TLS sono protetti da questo attacco, ma alcune funzioni casuali di SSL, insieme a chiavi corte nella crittografia di esportazione, hanno reso possibile una certa implementazione di DROWN..

Al momento della pubblicazione, il DROWN era vulnerabile nel 25% dei siti web di punta di Internet, e l'attacco poteva essere condotto con risorse modeste, accessibili anche ai temerari hacker solitari. Per estrarre la chiave RSA del server erano richieste otto ore di calcolo e $440, e SSLv2 ha cambiato stato da 'obsoleto' a 'radioattivo'.

Aspetta, e per quanto riguarda Heartbleed?

Non è un attacco crittografico nel senso descritto sopra; è un overflow del buffer.

Facciamo una pausa.

Abbiamo iniziato con alcune tecniche di base: brute force, interpolazione, downgrade, cross-protocol e pre-calcolo. Poi abbiamo esaminato una tecnica avanzata, forse il componente principale degli attacchi crittografici moderni: è l'attacco oracle. Ci abbiamo lavorato a lungo - e abbiamo capito non solo il principio alla base, ma anche i dettagli tecnici di due specifiche implementazioni: l'attacco VoDené al modo di cifratura CBC e l'attacco Kelsey ai protocolli di cifratura con compressione preventiva.

Nella recensione degli attacchi al ribasso e con calcoli preliminari, abbiamo riassunto brevemente l'attacco FREAK, che utilizza entrambi i metodi, poiché i siti target vengono ridotti a chiavi deboli e poi riutilizzano le stesse chiavi. Per il prossimo articolo, abbiamo lasciato (un attacco molto simile) Logjam, che attacca gli algoritmi a chiave pubblica.

Successivamente abbiamo esaminato altri tre esempi di applicazione di questi principi. In primo luogo, CRIME e POODLE: due attacchi che si basano sulla capacità dell'hacker di inserire testo in chiaro arbitrario accanto al testo in chiaro target, per poi analizzare le risposte del server e poi, utilizzando la metodologia dell'attacco oracolo, sfruttare queste informazioni scarse per il ripristino parziale del testo in chiaro. CRIME ha seguito il percorso dell'attacco di Kelsey sulla compressione SSL, mentre POODLE ha utilizzato invece una variante dell'attacco di Vaudenay sul CBC con lo stesso effetto.

Poi abbiamo focalizzato l'attenzione sull'attacco cross-protocol DROWN, che stabilisce una connessione con il server tramite il protocollo obsoleto SSLv2, per poi recuperare le chiavi segrete del server tramite l'attacco di Bleichenbacher. A questo punto abbiamo tralasciato i dettagli tecnici di quest'attacco; come nel caso di Logjam, dovrà aspettare fino a quando non avremo esaminato a fondo i sistemi crittografici a chiave pubblica e le loro vulnerabilità.

Nel prossimo articolo parleremo di attacchi avanzati, come il metodo meet-in-the-middle, l'analisi crittografica differenziale e l'attacco dei "giorni di compleanno". Effettueremo un breve intermezzo sugli attacchi attraverso canali laterali, per poi dedicarsi al succo del discorso: i sistemi crittografici a chiave pubblica.

Fonte: habr.com