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

La crittografia comprende tutto questo, ma il nocciolo è un altro. Il nocciolo è nella sottile linea tra semplice e complesso. Alcune cose sono facili da fare, ma è complicato tornare indietro: per esempio, rompere un uovo. Altre cose sono facili da fare, ma difficile tornare indietro quando manca un piccolo pezzo decisivo: per esempio, aprire una porta chiusa quando il "pezzo decisivo" è la chiave. La crittografia studia queste situazioni e i modi per utilizzarle praticamente.

Negli ultimi anni, la collezione di attacchi crittografici si è trasformata in uno zoo di loghi stridenti, carichi di formule scientifiche, creando una sensazione generale di cupo fallimento. Tuttavia, molte di queste attacchi si basano su pochi principi comuni e le infinite pagine di formule si riducono spesso a idee semplici e comprensibili.

In questa serie di articoli esamineremo i diversi tipi di attacchi crittografici, con un focus sui principi fondamentali. In sintesi, e non necessariamente in quest'ordine, tratteremo i seguenti argomenti:

Strategie di base: brute force, analisi delle frequenze, interpolazione, abbassamento e cross-protocol.
Vulnerabilità 'brandizzate': FREAK, CRIME, POODLE, DROWN, Logjam.
Strategie avanzate: attacchi oracle (attacco Wattenberg, attacco Kelsey); metodo meet-in-the-middle, attacco dei 'giorni di compleanno', bias statistico (crittanalisi differenziale, crittanalisi integrale, ecc.).
Attacchi tramite canali laterali e i loro parenti prossimi, metodi di analisi dei guasti.
Attacchi alla crittografia a chiave pubblica: radice cubica, broadcast, messaggio collegato, attacco di Coppersmith, algoritmo Polygamous-Hellman, crivello numerico, attacco di Wiener, attacco di Bleichenbacher.

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

Strategie di base

Gli attacchi seguenti sono semplici nel senso che possono essere praticamente spiegati senza dettagli tecnici. Spiegheremo ciascun tipo di attacco nei termini più semplici, senza addentrarci in esempi complessi o varianti avanzate.

Alcuni di questi attacchi sono diventati obsoleti e non sono stati utilizzati da molti anni. Altri — dei veri veterani — continuano a insidiare regolarmente gli sviluppatori di sistemi crittografici ignari nel XXI secolo. Si può dire che l'era della crittografia moderna sia iniziata con l'emergere dell'IBM DES — il primo cifrario che ha resistito a tutti gli attacchi in questa lista.

Forza bruta semplice

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

Supponiamo di avere a disposizione del testo cifrato e stiamo cercando di decifrarlo senza alcuna informazione aggiuntiva (questo è chiamato attacco "only ciphertext"). Se in qualche modo trovassimo la chiave corretta, potremmo facilmente verificare che essa è realmente corretta se il risultato rappresenta un messaggio sensato.

Si noti che qui ci sono due assunzioni implicite. Prima di tutto, che sappiamo come effettuare la decifratura, cioè come funziona il sistema crittografico. Questa è un'assunzione standard quando si discute di crittografia. Nascondere i dettagli dell'implementazione del cifrario agli attaccanti può sembrare una misura di sicurezza aggiuntiva, ma una volta che l'attaccante scopre questi dettagli, questa sicurezza aggiuntiva si perde silenziosamente e irrevocabilmente. il principio di Kerckhoffs: la cattura del sistema nelle mani del nemico non deve causare inconvenienti.

In secondo luogo, supponiamo che la chiave corretta sia l'unica chiave che porterà a una decifratura sensata. Anche questa è un'ipotesi ragionevole; si verifica se il testo cifrato è significativamente più lungo della chiave e facilmente leggibile. Di norma, questo è vero nella vita reale, ad eccezione di chiavi enormi e poco pratiche o di altre manovre che è meglio lasciare da parte (se non ti piace che abbiamo tralasciato le spiegazioni, per favore consulta il teorema 3.8 qui).

Tenendo conto di quanto sopra, emerge una strategia: verificare ogni possibile chiave. Questo è chiamato brute force, e tale attacco funziona garantito contro tutte le cifrature pratiche — alla fine. Ad esempio, il brute force è sufficiente per rompere la cifratura di Cesare, un'antica cifratura in cui la chiave è una lettera dell'alfabeto, che implica poco più di 20 chiavi possibili.

Sfortunatamente per gli analisti crypto, l'aumento delle dimensioni della chiave protegge bene contro gli attacchi di forza bruta. Man mano che aumenta la dimensione della chiave, il numero di chiavi possibili cresce esponenzialmente. Con le dimensioni delle chiavi moderne, la semplice forza bruta non è affatto praticabile. Per comprendere cosa intendiamo, prendiamo il supercomputer più veloce conosciuto a metà del 2019: Summit di IBM, con prestazioni di picco dell'ordine di 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 servirebbero tempo che supera di circa 7800 volte l'età dell'Universo.

Dobbiamo considerare la forza bruta un anacronismo storico? Affatto: è un ingrediente necessario nel ricettario della crittoanalisi. Rare volte si incontrano cifrature così deboli da poter essere violate solo con un attacco intelligente, senza ricorrere in alcun modo alla forza. Molti attacchi riusciti usano prima un metodo algoritmico per indebolire la crittografia obiettivo e poi avviano una forza bruta.

Analisi delle frequenze

La maggior parte dei testi non è gibberish. Ad esempio, nei testi in lingua inglese ci sono molte lettere 'e' e articoli 'the'; nei file binari, ci sono molti byte zero come riempitivo tra frammenti di informazioni. L'analisi della frequenza è qualsiasi attacco che utilizza questo fatto.

Un esempio canonico di cifrario vulnerabile a questo attacco è il semplice cifrario a sostituzione. In questo cifrario, la chiave rappresenta una tabella che sostituisce tutte le lettere. Ad esempio, 'g' viene sostituita con 'h', 'o' con 'j'. Quindi, la parola 'go' diventa 'hj'. Questo cifrario è difficile da attaccare con un semplice brute force, poiché ci sono molte possibili tabelle di sostituzione. Se ti interessa la matematica, la lunghezza efficace della chiave è di circa 88 bit: questo
. Ma l'analisi della frequenza solitamente risolve rapidamente il compito.

Consideriamo il seguente testo cifrato, elaborato con un semplice cifrario 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 presumere preliminarmente che questa sia la lettera e:

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

Coppia XD si ripete all'inizio di diverse parole. In particolare, la combinazione XDeLe implica chiaramente una parola queste o ci sono, quindi andiamo avanti:

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 brute force completo, questo approccio ripristina il testo originale nel minor tempo possibile:

ci sono più cose in cielo e in terra, Orazio, di quante ne sono sognate nella tua filosofia

Per alcuni, risolvere tali «crittogrammi» è un affascinante passatempo.

L'idea dell'analisi delle frequenze è più fondamentale di quanto sembri a prima vista. Ed è applicabile a cifrari molto più complessi. Nel corso della storia, varie costruzioni crittografiche hanno cercato di resistere a tale attacco attraverso la «sostituzione polialfabetica». Qui, durante la crittografia, la tabella di sostituzione dei caratteri viene modifica in modi complessi ma prevedibili, a seconda della chiave. Tutti questi cifrari un tempo erano considerati difficili da decifrare; eppure, l'umile analisi delle frequenze alla fine li ha sopraffatti.

Il cifrario polialfabetico più ambizioso e probabilmente il più noto nella storia è stato il cifrario "Enigma" durante la Seconda Guerra Mondiale. Era relativamente complesso rispetto ai suoi predecessori, ma dopo un lungo e incessante lavoro, i crittoanalisti britannici riuscirono a decifrarlo mediante l'analisi delle frequenze. Certo, non furono in grado di sviluppare un attacco elegante come quello mostrato sopra; dovettero confrontare coppie note di testi in chiaro e cifrati (il cosiddetto "attacco basato su testi in chiaro") e persino indurre gli utenti dell'"Enigma" a cifrare messaggi specifici analizzando i risultati ("attacco basato su testi in chiaro selezionati"). Ma questo non alleviò le sorti degli eserciti sconfitti e dei sottomarini affondati.

Dopo questo trionfo, l'analisi delle frequenze scomparve dalla storia del crittoanalisi. I cifrari dell'era digitale moderna sono progettati per lavorare con i bit anziché con le lettere. Ciò che è ancora più importante, questi cifrari sono stati sviluppati con la cupa consapevolezza di ciò che in seguito divenne noto come la legge di Schneier: chiunque può creare un algoritmo di crittografia che non riesce a rompersi da solo. Non basta che il sistema di crittografia appaia complesso: per dimostrare il suo valore, deve superare un rigoroso esame di sicurezza da parte di numerosi crittoanalisti, che faranno tutto il possibile per violare il cifrario.

Calcoli preliminari

Prendiamo in considerazione la città ipotetica di Prekom Heights con una popolazione di 200.000 persone. In ogni casa della città ci sono beni di valore mediamente pari a $30.000, ma non superiori a $50.000. Il mercato della sicurezza a Prekom è stato monopolizzato dalla società ACME Industries, che produce le leggendarie serrature di classe Coyote ™. Secondo l'analisi degli esperti, una serratura di classe Coyote può essere infranta solo da una macchina ipotetica molto complessa, il cui sviluppo richiede circa cinque anni e un investimento di $50.000. È la città al sicuro?

Probabilmente no. Alla fine, comparirà un criminale sufficientemente ambizioso. Dirà a se stesso: «Sì, sosterrò elevati costi iniziali. Cinque anni di attesa paziente e $50.000. Ma alla fine del lavoro, avrò accesso a tutta la ricchezza di questa città. Se gioco bene le mie carte, questo investimento si ripagherà molte volte.

Lo stesso vale per la crittografia. Gli attacchi a un particolare algoritmo subiscono un'analisi rigorosa di costi e benefici. Se il rapporto è favorevole, l'attacco non avverrà. Tuttavia, gli attacchi che colpiscono immediatamente molte potenziali vittime si ripagano quasi sempre, e in questo caso la miglior pratica di design è presumere che siano iniziati dal primo giorno. Abbiamo essenzialmente una versione crittografica della legge di Murphy: "Tutto ciò che può realmente rompere un sistema, romperà il sistema."

Un esempio semplice di un sistema crittografico vulnerabile a un attacco con pre-calcoli è un cifrario con algoritmo fisso senza l'uso di una chiave. È stato il caso del cifrario di Cesare, che semplicemente sposta ogni lettera dell'alfabeto di tre lettere in avanti (la tabella è circolare, quindi l'ultima lettera dell'alfabeto viene cifrata come la terza). Qui si manifesta di nuovo il principio di Kerckhoffs: una volta che il sistema è stato violato, è violato per sempre.

Il concetto è semplice. Anche un principiante nello sviluppo di sistemi crittografici probabilmente sarà consapevole della minaccia e si preparerà di conseguenza. Se guardiamo all'evoluzione della crittografia, attacchi simili sono stati inappropriati per la maggior parte dei codici, a partire dalle prime versioni migliorate del cifrario di Cesare fino al declino dei codici polialfabetici. Tali attacchi sono riemersi solo con l'avvento dell'era moderna della crittografia.

Questo ritorno è causato da due fattori. In primo luogo, sono emersi finalmente sistemi crittografici abbastanza complessi, dove la possibilità di sfruttamento dopo l'hacking non era evidente. In secondo luogo, la crittografia ha raggiunto una diffusione così ampia 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 si rendessero conto dei rischi emersi e suonassero l'allerta.

Ricorda l'attacco con pre-calcoli: alla fine dell'articolo esamineremo due esempi crittografici della vita reale in cui ha svolto un ruolo fondamentale.

Interpolazione

Davanti a voi il famoso detective Sherlock Holmes, che sta attaccando con interpolazione il malcapitato dottor Watson:

Mi sono subito reso conto che eravate arrivato dall'Afghanistan… Il mio pensiero è stato: «Quest'uomo sembra un medico, ma ha un portamento militare. Quindi, è un medico militare. È appena tornato dai tropici — ha un viso scuro, ma non è il suo colore naturale, poiché i polsi sono molto più chiari. Il viso è emaciato, — ovviamente ha sofferto e ha superato una malattia. È stato ferito al braccio sinistro — lo tiene immobile e un po' innaturalmente. Dove potrebbe un medico militare inglese aver sofferto e subito una ferita nei tropici? Certamente, in Afghanistan». L'intero ragionamento non ha preso più di un secondo. E così ho detto che eravate arrivato dall'Afghanistan, e voi siete rimasti sorpresi.

Da ciascuna prova singolarmente, Holmes poteva estrarre pochissime informazioni. Solo esaminandole tutte insieme riusciva a giungere alle proprie conclusioni. Funziona in modo simile l'attacco con interpolazione, che analizza coppie note di testo in chiaro e cifrato ottenute utilizzando lo stesso codice. Da ciascuna coppia si estraggono singole osservazioni che permettono di formulare una conclusione generale sul codice. Tutti questi ragionamenti risultano vaghi e sembrano inutili finché non raggiungono all'improvviso una massa critica, portando a una conseguenza inevitabile: per quanto incredibile possa apparire, deve essere vero. A questo punto, si svela il codice oppure il processo di decrittazione diventa talmente collaudato da essere replicabile.

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 utilizzando un semplice sistema crittografico appreso da un annuncio pubblicitario sulla rivista "Scherzi 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 abbiamo notato che Bob sta graffiando qualcosa nel suo diario. Quando avrà finito, lo prenderemo furtivamente e leggeremo l'ultima registrazione:

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

. Poiché siamo molto seriamente intenzionati a seguire Bob durante il suo appuntamento (in questo scenario abbiamo 15 anni), è cruciale conoscere la data e anche l'indirizzo di Alice. Fortunatamente, notiamo che il sistema crittografico di Bob è vulnerabile a un attacco di interpolazione. Potremmo anche non sapere e , ma conosciamo la data di oggi, quindi abbiamo due coppie di «testo in chiaro - testo cifrato». In particolare, sappiamo che è cifrato in , e — in . E lo annoteremo:

Poiché abbiamo 15 anni, conosciamo già il sistema di due equazioni con due incognite, sufficiente in questa situazione per trovare e senza particolari problemi. Ogni coppia «testo in chiaro - testo cifrato» impone un vincolo sulla chiave di Bob, e due vincoli insieme sono sufficienti per ripristinare completamente la chiave. Nel nostro esempio, la risposta e (a , quindi 26 nel diario corrisponde alla parola ‘the one’, ovvero «quella stessa» - nota del traduttore).

Gli attacchi di interpolazione, naturalmente, non sono limitati a esempi così semplici. Ogni sistema crittografico che si riduce a un oggetto matematico ben compreso e a un elenco di parametri è a rischio di attacco di interpolazione - più l'oggetto è comprensibile, maggiore è il rischio.

I principianti spesso lamentano che la crittografia è "l'arte di progettare oggetti il più brutti possibile". Probabilmente, gran parte della colpa ricade sugli attacchi di interpolazione. Bob può utilizzare un design matematico elegante oppure mantenere segreta la sua uscita con Alice — ma, ahimè, di solito non si può avere entrambe le cose. Questo diventerà estremamente chiaro quando alla fine passeremo alla crittografia a chiave pubblica.

Cross-protocol/downward

Nel film "Now You See Me" (2013), un gruppo di illusionisti cerca di estorcere l'intero patrimonio di un corrotto magnate delle assicurazioni, Arthur Tressler. Per accedere al conto bancario di Arthur, gli illusionisti devono presentare il suo nome utente e la password oppure costringerlo a presentarsi personalmente in banca e partecipare allo schema.

Entrambi gli scenari sono molto difficili; i ragazzi sono abituati a esibirsi sul palco, non a partecipare ad operazioni di intelligence. Perciò scelgono un terzo possibile scenario: il loro complice chiama la banca e si spaccia per Arthur. La banca pone alcune domande per verificare l'identità, come il nome dello zio e il nome del primo animale domestico; i nostri eroi lo sanno già. ottengono facilmente queste informazioni da Arthur tramite ingegneria sociale astuta.. Da questo momento in poi, una buona sicurezza delle password non ha più importanza.

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

Allo stesso modo nella crittografia, se due protocolli crittografici vengono utilizzati in parallelo per proteggere lo stesso attivo, e uno è notevolmente più debole dell'altro, il sistema finale diventa vulnerabile a un attacco cross-protocol, dove viene attaccato il protocollo più debole per accedere al premio, senza toccare quello più forte.

In alcune situazioni complesse, non basta semplicemente contattare il server tramite un protocollo più debole; è necessario un coinvolgimento involontario di un cliente legittimo. Questo può essere organizzato tramite un attacco di downgrade. Per comprendere questo attacco, supponiamo che i nostri illusionisti abbiano un compito più complesso rispetto a quanto visto nel film. Immaginiamo che ci siano delle circostanze impreviste tra un impiegato di banca (cassiere) e Arthur, dando origine a un dialogo simile a questo:

Hacker: Pronto? Sono Arthur Tressler. Vorrei ripristinare la mia password.
Cassiere: Ottimo. Per favore, controlla il tuo libro personale dei codici segreti, pagina 28, parola 3. Tutti i messaggi seguenti saranno crittografati utilizzando questa parola specifica come chiave. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Hacker: Ehi, aspetta, aspetta. È davvero necessario? Non possiamo semplicemente parlare come persone normali?
Cassiere: Non te lo consiglio.
Hacker: Io semplicemente... ascolta, ho avuto una giornata pessima, chiaro? Sono un cliente VIP e non ho voglia di frugare in questi stupidi libri di codici.
Cassiere: Va bene. Se insisti, signor Tressler. Cosa desideri?
Hacker: Per favore, vorrei trasferire tutti i miei soldi al Fondo Nazionale per le Vittime di Arthur Tressler.
(Pausa).
Cassiere: Capisco. Per favore, fornisca il suo codice PIN per le transazioni di grandi dimensioni.
Hacker: Cosa?
Cassiere: Su sua richiesta personale, le transazioni di tale importo richiedono l'inserimento del codice PIN per le transazioni di grandi dimensioni. Questo codice le è stato fornito al momento dell'apertura del conto.
Hacker:… L'ho perso. È davvero necessario? Non potete semplicemente approvare la transazione?
Cassiere: No. Mi dispiace, signor Tressler. Ancora una volta, questo è un procedimento di sicurezza che ha richiesto. Se vuole, possiamo inviare un nuovo codice PIN all'indirizzo email.

I nostri eroi sospendono l'operazione. Stanno ascoltando diverse transazioni significative di Tressler, sperando di sentire il codice PIN; ma ogni volta la conversazione si trasforma in un linguaggio cifrato prima che arrivi qualcosa di interessante. Infine, in un bel giorno, mettono in atto il piano. Attendono pazientemente il momento in cui Tressler deve effettuare una grande transazione al telefono, si collega alla linea e poi…

Tressler: Salve. Vorrei effettuare una transazione remota, per favore.
Cassiere: Ottimo. Per favore, dai un'occhiata al tuo libro personale dei codici segreti, pagina…
(L'hacker preme il pulsante; la voce del cassiere si trasforma in un rumore incomprensibile).
Cassiere: — #@$#@$#*@$$@#* sarà crittografato con questa parola come chiave. AAAYRR PLRQRZ MMNJK LOJBAN…
Tressler: Scusa, non ho capito bene. Puoi ripetere? A quale pagina? Quale parola?
Cassiere: È la pagina @#$@#*$)#*#@()#@$(#@*$(#@*.
Tressler: Cosa?
Cassiere: La parola numero venti @$#@$#%#$.
Tressler: Sul serio! Basta già! Con il tuo protocollo di sicurezza è un vero circo. So che puoi semplicemente parlare normalmente con me.
Cassiere: Non te lo consiglio…
Tressler: E io non ti consiglio di sprecare il mio tempo. Non voglio più sentire nulla di questo finché non sistemate i problemi con la vostra linea telefonica. Possiamo chiudere questo affare o no?
Cassiere:… sì. Va bene. Cosa desidera?
Tressler: Vorrei trasferire $20.000 alla società Lord Business Investments, numero di conto…
Cassiere: Un momento, per favore. È un affare importante. Per favore, fornisci il tuo codice PIN per transazioni importanti.
Tressler: Cosa? Ah, giusto. 1234.

Ecco un attacco a ribasso. Il protocollo più debole «parliamo direttamente» era previsto come opzione una soluzione di emergenza. Eppure siamo qui.

Ti puoi chiedere chi, in un sano stato mentale, progetterebbe un vero sistema del tipo "è sicuro finché non chiedi il contrario", come descritto sopra. Ma proprio come una banca immaginaria si assume dei rischi per mantenere clienti che non amano la crittografia, così anche i sistemi in generale tendono spesso a piegarsi a requisiti che sono indifferenti o addirittura ostili alla sicurezza.

Questa è esattamente la storia che è accaduta con il protocollo SSLv2 nel 1995. Il governo degli Stati Uniti aveva già cominciato a considerare la crittografia come un'arma da mantenere lontana da nemici interni ed esterni. I frammenti di codice venivano singolarmente approvati per l'esportazione dagli Stati Uniti, spesso con la condizione di un'intenzionale indebolimento dell'algoritmo. Alle aziende Netscape, sviluppatrice del browser più popolare Netscape Navigator, fu concessa l'autorizzazione per SSLv2 solo con una vulnerabilità originaria del chiave RSA di 512 bit (e 40 bit per RC4).

Entro la fine del millennio, le normative si sono allentate e l'accesso alla crittografia moderna è diventato ampiamente disponibile. Tuttavia, i clienti e i server hanno mantenuto per anni una crittografia "esportativa" indebolita a causa della stessa inerzia che porta a mantenere il supporto per qualsiasi sistema obsoleto. I clienti temevano di incontrare un server che non supportasse nient'altro. I server facevano lo stesso. Certamente, il protocollo SSL stabilisce che i clienti e i server non dovrebbero mai utilizzare un protocollo debole quando uno migliore è disponibile. Ma la stessa premessa si applicava a Tressler e alla sua banca.

Questa teoria ha trovato applicazione in due attacchi eclatanti che hanno messo in discussione la sicurezza del protocollo SSL nel 2015, entrambi scoperti dai ricercatori di Microsoft e INRIA. Prima a febbraio sono stati diffusi i dettagli dell'attacco FREAK, e tre mesi dopo un altro attacco simile chiamato Logjam, di cui parleremo più dettagliatamente quando ci occuperemo degli attacchi alla crittografia a chiave pubblica.

Vulnerabilità FREAK (noto anche come «Smack TLS») si è manifestato quando i ricercatori hanno analizzato le implementazioni client/server di TLS e hanno scoperto un curioso errore. In queste implementazioni, se il client non richiede nemmeno l'uso di una crittografia debole da esportazione, ma il server risponde comunque con quelle chiavi - il client dice «Va bene» e passa a un set di cifratura debole.

All'epoca, tutti consideravano la crittografia da esportazione obsoleta e vietata, quindi l'attacco è stato un vero shock e ha colpito molti domini importanti, incluso il sito della Casa Bianca, quello dell'agenzia delle entrate degli Stati Uniti e della NSA. Peggio ancora, è emerso che molti server vulnerabili ottimizzavano le prestazioni riutilizzando le stesse chiavi invece di crearne di nuove per ogni sessione. Questo ha permesso, dopo il downgrade del protocollo, di eseguire anche un attacco di precalcolo: compromettere una chiave era relativamente costoso (100 dollari e 12 ore al momento della pubblicazione), ma il costo pratico dell'attacco su una connessione è significativamente diminuito. Era sufficiente comprometterne una sola volta - e decifrare le chiavi per tutte le successive connessioni da quel momento in poi.

E prima di procedere, è necessario menzionare un attacco avanzato…

Attacco dell'oracolo

Moxie Marlinspike è noto principalmente come il padre del messenger crittografico multipiattaforma Signal; ma a noi piace uno dei suoi meno noti innovazioni — il principio della condanna crittografica (Cryptographic Doom Principle). Riassumendo, si può dire così: «Se un protocollo esegue qualsiasi operazione crittografica su un messaggio proveniente da una fonte potenzialmente dannosa e si comporta in modo diverso a seconda del risultato, è condannato». O in termini più bruschi: «Non accettare informazioni dal nemico per l'elaborazione, e se lo fai, almeno non mostrare il risultato».

Lasciamo da parte gli overflow del buffer, le iniezioni di comando e simili; essi esulano da questa discussione. La violazione del «principio di condanna» porta a gravi falle crittografiche poiché il protocollo si comporta esattamente come dovrebbe.

Prendiamo come esempio una costruzione fittizia con un cifrario a sostituzione vulnerabile e poi dimostriamo un possibile attacco. Sebbene abbiamo già visto un attacco a un cifrario a sostituzione tramite analisi delle frequenze, questo non è semplicemente "un altro modo per rompere lo stesso cifrario". Al contrario, gli attacchi oracle sono un'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 è stato scelto solo per rendere l'esempio più comprensibile.

Quindi, Alice e Bob comunicano utilizzando un semplice cifrario a sostituzione, con una chiave nota solo a 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ù corto, deve aggiungere del testo fittizio alla fine del messaggio, affinché sia esattamente 20 caratteri. Dopo una certa discussione, hanno deciso che accetteranno solo i seguenti testi fittizi: a, bb, ccc, dddd ecc. Così, è noto il testo fittizio di qualsiasi lunghezza necessaria.

Quando Alice o Bob ricevono un messaggio, innanzitutto verificano che il messaggio abbia la lunghezza corretta (20 caratteri) e che il suffisso contenga il testo fittizio corretto. Se non è così, rispondono con un messaggio di errore appropriato. Se la lunghezza del testo e il testo fittizio sono a posto, il destinatario legge il messaggio stesso e invia una risposta crittografata.

Durante l'attacco, un malintenzionato si finge Bob e invia messaggi falsi ad Alice. I messaggi sono completamente senza senso, poiché il malintenzionato non possiede la chiave e quindi non può falsificare un messaggio significativo. Tuttavia, poiché il protocollo viola il principio dell'inevitabilità, il malintenzionato può comunque attirare in trappola Alice, inducendola a rivelare 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!

L'hacker non ha idea di cosa abbia appena detto Alice, ma nota che il simbolo C deve corrispondere 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, l'attaccante non ha idea di ciò che Alice ha appena detto, ma nota che H deve corrispondere a b, poiché Alice ha utilizzato un testo fittizio.

E così via, finché l'attaccante non apprende il significato di ciascun carattere.

A prima vista, il metodo ricorda un attacco basato su attacchi a testo in chiaro. Alla fine, l'attaccante raccoglie i testi cifrati, e il server li elabora diligentemente. La principale differenza che rende questi attacchi praticabili nel mondo reale è che all'attaccante non è richiesto di accedere alla decifratura reale: è sufficiente la risposta del server, anche una così innocua come 'Testo fittizio errato'.

Sebbene questo specifico attacco sia istruttivo, non bisogna focalizzarsi troppo sulle specifiche del schema del "testo fittizio", sul sistema crittografico utilizzato o sulla precisa sequenza di messaggi inviati dall'attaccante. L'idea principale è come Alice reagisce in modo diverso sulla base delle caratteristiche del testo in chiaro, e lo fa senza verificare che il corrispondente testo cifrato provenga effettivamente da una parte fidata. In questo modo, Alice consente all'attaccante di estrarre informazioni segrete dalle sue risposte.

In questo scenario, ci sono molte cose che possono essere cambiate. I simboli a cui Alice reagisce, o la differenza nel suo comportamento, o persino il sistema crittografico utilizzato. Ma il principio rimarrà lo stesso e l'attacco, nel suo complesso, sarà ancora valido in un modo o nell'altro. L'implementazione di base di questo attacco ha aiutato a scoprire diversi errori di sicurezza che esamineremo presto; ma prima è importante apprendere alcune lezioni teoriche. Come si può utilizzare questo «scenariò inventato di Alice» in un attacco che possa funzionare su una crittografia moderna reale? È possibile, anche solo in teoria?

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

Quattro anni dopo, nel 2002, il crittografo francese Serge Vaudenay ha dimostrato un attacco da oracolo, quasi identico a quello descritto in precedenza nello scenario di Alice — tranne per il fatto che, invece di un cifrario inventato, ha compromesso un'intera classe rispettabile di cifrari moderni che le persone utilizzano realmente. In particolare, l'attacco di Vaudenay prende di mira i cifrari con dimensione fissa dell'input (cifrari a blocchi), quando vengono utilizzati nel cosiddetto 'modo di crittografia CBC' e con un particolare schema di padding popolare, sostanzialmente equivalente a quello nello scenario di Alice.

Sempre nel 2002, il crittografo americano John Kelsey — co-autore Twofish — ha proposto vari attacchi da oracolo su sistemi che comprimono i messaggi e poi li crittografano. Tra questi, il più notevole è stato un attacco che sfrutta il fatto che spesso è possibile dedurre la lunghezza originale del testo in chiaro dalla lunghezza del testo crittografato. In teoria, ciò consente di effettuare un attacco da oracolo che ricostruisce parti del testo originale.

Di seguito forniamo una descrizione più dettagliata degli attacchi di Vodenë e Kelsi (forniremo una descrizione più dettagliata dell'attacco di Bleichenbacher quando passeremo agli attacchi alla 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 Vodenë

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

Purtroppo, i cifrari a blocchi presentano una grave vulnerabilità. La dimensione tipica di un blocco è di 128 bit, ovvero 16 caratteri. È evidente che la crittografia moderna deve lavorare con dati in ingresso di dimensioni maggiori, ed è qui che entrano in gioco le modalità di crittografia. La modalità di crittografia è fondamentalmente un hack: è un modo per applicare un cifrario a blocchi, che accetta solo dati di dimensioni specifiche, a dati in ingresso di lunghezza arbitraria.

L'attacco di Vaudenay è mirato alla popolare modalità CBC (Cipher Block Chaining, modalità di concatenamento 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 (esclusivo «O»). 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 il cifrario a blocchi, utilizzando una chiave.

Poiché CBC utilizza così intensamente l'operazione binaria XOR, cogliamo l'occasione per rivedere alcune delle sue proprietà:

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

In generale, queste proprietà implicano che se abbiamo un'equazione che include operazioni XOR e una variabile sconosciuta, essa può essere risolta. Ad esempio, se sappiamo che con l'incognita e i valori noti e , possiamo fare affidamento sulle proprietà menzionate sopra per risolvere l'equazione per . Applicando l'XOR su entrambi i lati dell'equazione con , otteniamo . Tra poco tutto questo diventerà molto rilevante.

Tra il nostro scenario di Alice e l'attacco di Wodene ci sono due piccole differenze e una differenza principale. Le due piccole differenze sono:

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

La principale differenza:

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

Questa è la principale differenza: l'ultimo pezzo del puzzle per comprendere l'attacco Waterner, quindi prendiamoci un momento per riflettere su come e perché è possibile organizzare un attacco oracolo su CBC.

Supponiamo di avere un testo cifrato CBC composto da 247 blocchi e vogliamo decifrarlo. Possiamo inviare al server messaggi falsi, proprio come prima potevamo inviare messaggi ingannevoli ad Alice. Il server decifrerà i messaggi per noi, ma non mostrerà la decifratura — invece, come nel caso di Alice, il server fornirebbe solo un bit di informazione: se il testo in chiaro ha un riempimento valido o meno.

Si prega di notare che nel contesto di Alice avevamo le seguenti relazioni:

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

Chiamiamolo "l'equazione di Alice". Noi controllavamo il testo cifrato; il server (Alice) meritava 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 una connessione per lo scenario CBC, potremmo estrarre alcune informazioni segrete anche lì.

Fortunatamente, ci sono effettivamente relazioni che possiamo sfruttare. Consideriamo i dati di output dell'ultima chiamata alla decifratura del cifrario a blocchi e definiamo questi dati come . Definiamo inoltre i blocchi di testo in chiaro e i blocchi di testo cifrato . Dai un'altra occhiata al diagramma CBC e fai attenzione a ciò che ne risulta:

Chiamiamo questo «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 ripristinato il terzo membro dell'equazione - la chiave. Negli scenari CBC controlliamo anche il testo cifrato e osserviamo perdite di informazioni sul corrispondente testo in chiaro. Se l'analogia regge, potremmo ottenere informazioni su .

Supponiamo di aver veramente ripristinato , e allora? Bene, allora possiamo immediatamente estrarre l'intero ultimo blocco del testo in chiaro (), semplicemente inserendo (che abbiamo) e
ottenuto nell'equazione CBC.

Quindi, siamo ottimisti riguardo al piano generale di attacco e ora è il momento di elaborare i dettagli. Facciamo attenzione a come avviene la perdita di informazioni sul testo in chiaro sul server. Nel caso di Alice, la perdita si è verificata perché Alice rispondeva correttamente solo se $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ terminava con una stringa a (o bb, e così via, ma le possibilità di attivare casualmente queste condizioni erano molto basse). Analogamente al CBC, il server accetta il riempimento se e solo se si conclude con un esadecimale 01. Quindi, proviamo 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, significa che:

Ora usiamo la proprietà byte-wise dell'XOR:

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

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

Potremmo chiudere qui e accontentarci di aver condotto un attacco su un cifrario teoricamente resistente. Ma in realtà possiamo fare molto di più: possiamo effettivamente recuperare tutto il testo. Questo richiede un certo trucco che non era presente nello scenario originale di Alice e non rientra nelle condizioni obbligatorie dell'attacco dell'oracolo, ma il metodo vale comunque la pena studiarlo.

Per comprenderlo, innanzitutto osserva che, come risultato, otteniamo il valore corretto dell'ultimo byte. Abbiamo guadagnato una nuova capacità. Ora, quando falsifichiamo i testi cifrati, possiamo controllare l'ultimo byte del corrispondente testo in chiaro. Ancora una volta, questo è legato all'equazione CBC e alla proprietà del byte-by-byte:

Poiché ora conosciamo il secondo membro, possiamo usare il nostro controllo sul primo per gestire il terzo. Semplicemente calcoliamo:

In passato non potevamo farlo, perché non avevamo ancora l'ultimo byte. .

Come ci aiuterà? Supponiamo ora di creare tutti i testi cifrati in modo tale che l'ultimo byte dei testi in chiaro corrisponda 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ò avverrà solo se il penultimo byte del testo in chiaro è anch'esso uguale a 02. Continuiamo a inviare blocchi di testi cifrati falsi, modificando il penultimo byte, finché il server non accetta il riempimento per uno di essi. A questo punto otteniamo:

E noi recuperiamo il penultimo byte allo stesso modo in cui abbiamo recuperato l'ultimo. Continuiamo su questa strada: correggiamo gli ultimi due byte del testo aperto su 03 03, ripetiamo questo attacco per il terzo byte dalla fine e così via, fino a ripristinare completamente .

Che dire del resto del testo? Si noti che il valore è in realtà $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Possiamo inserire qualsiasi altro blocco al suo posto , e l'attacco avrà comunque successo. In effetti, possiamo chiedere al server di eseguire $inline$text{BLOCK_DECRYPT}$inline$ per qualsiasi dato. A questo punto il gioco è fatto - possiamo decrittografare qualsiasi testo cifrato (dai un'altra occhiata al diagramma di decrittazione CBC per verificarlo; e nota che il vettore IV è pubblico).

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

Attacco Kelsey

Il nostro affine John Kelsey ha esposto i principi alla base di molti possibili attacchi, non solo i dettagli specifici di un attacco su un particolare cifrario. Il suo articolo del 2002 Questo studio riguarda le possibili attacchi ai dati crittografati compressi. Pensavate che per condurre un attacco non fosse sufficiente sapere che i dati erano stati compressi prima della crittografia? In realtà, è sufficiente.

Questo risultato sorprendente è dovuto a due principi. Prima di tutto, esiste una forte correlazione tra la lunghezza del testo in chiaro e la lunghezza del testo cifrato; per molti algoritmi di crittografia, l'uguaglianza precisa. In secondo luogo, quando si verifica la compressione, esiste anche una forte correlazione tra la lunghezza del messaggio compresso e il grado di "rumore" del testo in chiaro, cioè la proporzione di caratteri unici (il 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

Supponiamo che entrambi i testi in chiaro siano compressi e poi cifrati. Riceverete due testi cifrati risultanti e dovrete indovinare quale testo cifrato corrisponde a quale testo in chiaro:

Testo cifrato 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Testo cifrato 2: DWKJZXYU

La risposta è chiara. Tra i testi aperti, solo il primo testo aperto potrebbe essere ridotto a una scarna lunghezza del secondo testo cifrato. Lo abbiamo scoperto, senza sapere nulla dell'algoritmo di compressione, della chiave di crittografazione o persino della cifra stessa. Rispetto alla gerarchia delle possibili attacchi crittografici, è una sorta di pazzia.

Kelsey osserva inoltre che, in determinate circostanze straordinarie, questo principio può essere utilizzato per condurre un attacco oracle. In particolare, descrive come un attaccante possa ripristinare il testo aperto segreto, se può costringere il server a crittografare dati del modulo (testo aperto 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 (), osserviamo una piccola fuga di informazioni su un altro membro (il testo cifrato) e tentiamo di ripristinare l'ultimo (testo aperto). Nonostante l'analogia, questa è una situazione piuttosto insolita rispetto ad altri attacchi oracle che abbiamo visto.

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

Supponiamo che un hacker stia cercando di recuperare il testo in chiaro del modulo password=..., dove la password stessa è sconosciuta. Secondo il modello di attacco di Kelsey, l'hacker 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 finito, comunica la lunghezza del risultato. L'attacco procede come segue:

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

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

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

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

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

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

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

(… qualche tempo dopo…)

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

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

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

È comprensibile per il lettore pensare che si tratti di un esercizio puramente accademico e che uno scenario del genere non si verificherà mai nel mondo reale. Purtroppo, come vedremo a breve, nella crittografia è meglio non essere troppo sicuri.

Vulnerabilità indicate: CRIME, POODLE, DROWN

Infine, dopo aver esaminato in dettaglio la teoria, possiamo vedere come questi metodi vengano applicati in attacchi crittografici reali.

CRIME

Se un attacco è mirato al browser e alla rete della vittima, alcune cose saranno più facili, mentre altre saranno più complesse. Ad esempio, vedere il traffico della vittima è facile: basta sedere con lei nello stesso caffè con WiFi. Per questo motivo, spesso si consiglia alle potenziali vittime (cioè a tutti) di utilizzare una connessione crittografata. Sarà più complicato, ma comunque possibile, effettuare richieste HTTP a nome della vittima verso un sito esterno (come Google). L'attaccante deve indurre la vittima a visitare una pagina web dannosa con uno script che effettui la richiesta. Il browser web fornirà automaticamente il cookie di sessione pertinente.

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

Dobbiamo sottolineare che se Bob non utilizza una connessione crittografata, tutte queste protezioni risultano inutili. Un hacker può semplicemente leggere il traffico di Bob e ricostruire il cookie di sessione di Google. Con quel cookie, può semplicemente aprire una nuova scheda di Google, senza disconnettersi dal proprio browser, e impersonare Bob, senza affrontare le fastidiose politiche della same-origin policy. Ma, sfortunatamente per l'hacker, situazioni del genere si verificano sempre meno. Internet ha da tempo dichiarato guerra alle connessioni non crittografate, e il traffico in uscita di Bob è probabilmente crittografato, che a lui piaccia o meno. Inoltre, fin dall'inizio dell'implementazione del protocollo, il traffico è stato anche compresso prima della crittografia; questa era una pratica comune per ridurre la latenza.

Qui entra in gioco CRIME (Compression Ratio Infoleak Made Easy, facile fuga tramite il rapporto di compressione). Una vulnerabilità che è stata dimostrata a settembre 2012 dai ricercatori della sicurezza Giuliano Rizzo e Thai Duong. Abbiamo già esaminato tutta la base teorica che consente di capire cosa hanno fatto e come. Un attaccante può indurre il browser di Bob a inviare richieste a Google, per poi intercettare le risposte in rete locale in forma compressa e crittografata. Pertanto, abbiamo:

Qui l'attaccante controlla la richiesta e ha accesso a uno sniffer di traffico, inclusa la dimensione dei pacchetti. Lo scenario immaginario di Kelsey è diventato realtà.

Comprendendo la teoria, gli autori di CRIME hanno creato un exploit in grado di rubare i cookie di sessione per una vasta gamma di siti, tra cui Gmail, Twitter, Dropbox e Github. La vulnerabilità ha colpito la maggior parte dei moderni browser web, portando 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'illustre Internet Explorer, che non ha mai utilizzato la compressione SSL.

POODLE

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

È emerso che, sebbene sui server fosse in esecuzione un ottimo TLSv1.2, molti avevano mantenuto il supporto per l'obsoleto SSLv3 per garantire la retrocompatibilità con Internet Explorer 6. Abbiamo già parlato degli attacchi di downgrading, quindi potete immaginare cosa stesse succedendo. Un sabotaggio ben organizzato del protocollo di handshake — e i server sono pronti a tornare al vecchio SSLv3, annullando sostanzialmente gli ultimi 15 anni di ricerche nel settore della sicurezza.

Per 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 con il nome "Secure Sockets Layer" o SSL. Si racconta che la prima versione di SSL fosse così orribile che gli sviluppatori raccolsero tutte le stampe del codice e le seppellirono in una discarica segreta nel New Mexico. Di conseguenza, la prima versione pubblica di SSL è in realtà la versione SSL 2. Era piuttosto spaventosa, e [..] era un prodotto della metà degli anni '90, che gli attuali crittografi considerano come i«secoli bui della crittografia». Molti degli attacchi crittografici più terribili che conosciamo oggi non erano ancora stati scoperti. Di conseguenza, gli sviluppatori del protocollo SSLv2 dovettero sostanzialmente muoversi a tentoni nell'oscurità, e si trovarono di fronte a moltitudini di mostri terribili — a loro dispiacere e nostro vantaggio, poiché gli attacchi a SSLv2 hanno lasciato insegnamenti preziosi per la generazione successiva di protocolli.

Dopo questi eventi, nel 1996, la delusa azienda Netscape ha riprogettato il protocollo SSL da zero. Il risultato è stata la versione SSL 3, che ha corretto alcuni dei problemi di sicurezza noti del suo predecessore..

Fortunatamente per gli hacker, "alcuni" non significa "tutti". In generale, SSLv3 forniva tutti i mattoni necessari per lanciare l'attacco Wadené. Il protocollo utilizzava una crittografia a blocchi in modalità CBC e uno schema di padding insicuro (questo è stato corretto in TLS; di conseguenza, è emersa la necessità di un attacco di downgrade). Se ricordi lo schema di padding nella nostra descrizione iniziale dell'attacco Wadené, lo schema SSLv3 è molto simile.

Ma, sfortunatamente per gli hacker, "simile" non significa "identico". Lo schema di padding di SSLv3 ha la forma di "N byte arbitrari, seguiti da un numero N". Prova a scegliere in queste condizioni un blocco immaginario di testo cifrato e a passare attraverso tutte le fasi dell'originale schema Wadené: scoprirai che l'attacco estrae con successo l'ultimo byte dal corrispondente blocco di testo in chiaro, ma non va oltre. Decifrare ogni 16° byte del testo cifrato è un ottimo trucco, ma non è una vittoria.

Di fronte a un fallimento, il team di Google ha adottato l'ultima risorsa: si è spostato su un modello di minaccia più potente, quello già utilizzato in CRIME. Se ipotizziamo che l'aggressore sia uno script eseguito nella scheda del browser della vittima e che possa estrarre i cookie di sessione, l'attacco rimane comunque impressionante. Anche se un modello di minaccia più ampio è meno realistico, nel capitolo precedente abbiamo già visto che questo modello specifico è realizzabile.

Considerando queste capacità avanzate dell'attaccante, ora l'attacco può continuare. Tieni presente che l'aggressore sa dove nell'intestazione viene visualizzato il file di cookie della sessione crittografato e controlla la lunghezza della richiesta HTTP che lo precede. Pertanto, può manipolare la richiesta HTTP in modo da allineare l'ultimo byte del cookie con la fine del blocco. Ora questo byte è pronto per la decifratura. È possibile semplicemente aggiungere un carattere alla richiesta, e il byte penultimo del cookie rimarrà allo stesso posto e sarà utilizzabile per il tentativo dallo stesso metodo. L'attacco continua in questo modo fino a quando il file di cookie non viene completamente ripristinato. Questo è chiamato POODLE: Padding Oracle on Downgraded Legacy Encryption.

DROWN

Come abbiamo già accennato, SSLv3 presentava delle vulnerabilità, ma era radicalmente diverso dal suo predecessore, poiché il difettoso SSLv2 rappresentava un prodotto di un'altra epoca. Qui era possibile interrompere il messaggio a metà: lo accetterò solo sul mio cadavere si trasformava in lo accetterò; il cliente e il server potevano incontrarsi su Internet, stabilire fiducia e scambiare segreti davanti a un aggressore, che poi si spacciava facilmente per uno o l'altro. E c'era anche il problema della crittografia esportabile, che abbiamo menzionato quando abbiamo trattato FREAK. Era una vera e propria Sodoma e Gomorra della crittografia.

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

Vi chiederete quale sia il nostro interesse in ciò che fanno? Hanno una sessione vulnerabile, ma questo non dovrebbe influire su altre sessioni o sulla sicurezza del server, giusto? Bene, non proprio. Sì, teoricamente dovrebbe essere così. 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 in OpenSSL in questa popolare implementazione, l'opzione "Disabilita SSLv2" non ha effettivamente funzionato.

Questo ha reso possibile un attacco cross-protocollo a TLS, noto come DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, decrittografia RSA con crittografia obsoleta e indebolita). Ricordiamo che questo non è lo stesso di un attacco di downgrade; l'hacker non ha bisogno di agire come un "uomo in mezzo" e non deve coinvolgere il cliente in una sessione non sicura. Gli aggressori iniziano semplicemente una sessione SSLv2 non sicura con il server, attaccano il protocollo debole e recuperano la chiave privata del server RSA. Questa chiave è valida anche per le connessioni TLS, e da questo momento in poi, nessuna sicurezza TLS lo salverà da un attacco.

Ma per l'attacco è necessaria una tecnica funzionante contro SSLv2, che permette di recuperare non solo il traffico specifico, ma anche la chiave privata del server RSA. Anche se si tratta di un compito complesso, i ricercatori avrebbero potuto scegliere qualsiasi vulnerabilità che fosse stata completamente chiusa dopo SSLv2. Alla fine, hanno trovato un'opzione adatta: l'attacco di Bleichenbacher, di cui abbiamo parlato in precedenza e di cui daremo una spiegazione dettagliata nel prossimo articolo. SSL e TLS sono protetti contro questo attacco, ma alcune funzionalità collateralmente di SSL insieme a chiavi brevi nella crittografia di classe export, hanno reso possibile. una specifica implementazione di DROWN.

Al momento della pubblicazione, il 25% dei principali siti web era vulnerabile a DROWN, e l'attacco poteva essere eseguito con risorse modeste, accessibili anche ai hacker solitari. Per estrarre la chiave RSA dal server erano necessarie otto ore di calcolo e 440 dollari, mentre SSLv2 ha cambiato il suo stato da 'obsoleto' a 'radioattivo'.

Aspetta, e per quanto riguarda Heartbleed?

Questa non è un attacco crittografico nel senso descritto sopra; è un overflow di buffer.

Facciamo una pausa

Abbiamo iniziato con alcuni metodi di base: brute force, interpolazione, downgrade, cross-protocol e pre-computazione. Poi abbiamo esaminato una tecnica avanzata, forse il principale componente degli attacchi crittografici moderni: l'attacco dell'oracolo. 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 di Waters sul modo di cifratura CBC e l'attacco di Kelsey sui protocolli di cifratura con compressione anticipata.

Nella nostra analisi delle attacchi a ribasso e con calcoli preliminari, abbiamo brevemente esposto l'attacco FREAK, che utilizza entrambi i metodi, in quanto i siti bersaglio vengono ridotti a chiavi deboli e poi riutilizzano le stesse chiavi. Per il prossimo articolo abbiamo lasciato l'attacco Logjam, molto simile, che prende di mira gli algoritmi a chiave pubblica.

Successivamente, abbiamo esaminato altri tre esempi di applicazione di questi principi. Innanzitutto, CRIME e POODLE: due attacchi che si basavano sulla capacità dell'attaccante di iniettare testo in chiaro casuale accanto al testo in chiaro bersaglio, per poi analizzare le risposte del server e poi, utilizzando la metodologia dell'attacco oracolo, impiegare queste scarse informazioni per il recupero parziale del testo in chiaro. CRIME ha seguito la strada dell'attacco Kelsey sulla compressione SSL, mentre POODLE ha invece utilizzato una variante dell'attacco Vaudenay sul CBC con lo stesso effetto.

Successivamente, abbiamo prestato attenzione all'attacco cross-protocollo DROWN, che stabilisce una connessione con il server tramite il protocollo obsoleto SSLv2 e poi recupera le chiavi segrete del server attraverso l'attacco di Bleichenbacher. Per ora, abbiamo tralasciato i dettagli tecnici di questo attacco; come per il Logjam, dovrà attendere finché non studiamo 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, la crittografia differenziale e l'attacco dei 'giorni di nascita'. Faremo una breve incursione negli attacchi attraverso canali laterali, per poi concentrarci sulla parte più interessante: i sistemi crittografici a chiave pubblica.

Fonte: habr.com