Quando senti la parola "crittografia", alcune persone ricordano la loro password WiFi, il lucchetto verde accanto all'indirizzo del loro sito web preferito e quanto sia difficile accedere alla posta elettronica di qualcun altro. Altri ricordano una serie di vulnerabilità degli ultimi anni con abbreviazioni eloquenti (DROWN, FREAK, POODLE...), loghi eleganti e un avviso di aggiornare urgentemente il browser.

La crittografia copre tutto, ma essenza di in un altro. Il punto è che esiste una linea sottile tra semplice e complesso. Alcune cose sono facili da fare, ma difficili da rimettere insieme, come rompere un uovo. Altre cose sono facili da fare ma difficili da recuperare quando manca una parte piccola, importante, cruciale: ad esempio aprire una porta chiusa a chiave quando la “parte cruciale” è la chiave. La crittografia studia queste situazioni e come possono essere utilizzate nella pratica.

Negli ultimi anni, la raccolta di attacchi crittografici si è trasformata in uno zoo di loghi appariscenti, pieni di formule tratte da articoli scientifici, e ha dato origine alla cupa sensazione generale che tutto sia rotto. Ma in realtà, molti degli attacchi si basano su pochi principi generali e infinite pagine di formule sono spesso ridotte a idee di facile comprensione.

In questa serie di articoli esamineremo i diversi tipi di attacchi crittografici, ponendo l'accento sui principi di base. In termini generali e non esattamente in questo ordine, ma tratteremo quanto segue:

• Strategie di base: forza bruta, analisi di frequenza, interpolazione, downgrade e protocolli incrociati.
• Vulnerabilità del marchio: FREAK, CRIMINE, BARBONCINO, ANNOGATO, Logjam.
• Strategie avanzate: attacchi oracolari (attacco Vodenet, attacco Kelsey); metodo meet-in-the-middle, attacco di compleanno, bias statistico (crittoanalisi differenziale, crittoanalisi integrale, ecc.).
• Attacchi tramite canale laterale e loro parenti stretti, tecniche di analisi dei guasti.
• Attacchi alla crittografia a chiave pubblica: radice cubica, trasmissione, messaggio correlato, attacco Coppersmith, algoritmo Pohlig-Hellman, crivello numerico, attacco Wiener, attacco Bleichenbacher.

Questo particolare articolo copre il materiale di cui sopra fino all'attacco di Kelsey.

Strategie di base

I seguenti attacchi sono semplici nel senso che possono essere spiegati quasi completamente senza troppi dettagli tecnici. Spieghiamo ogni tipologia di attacco nei termini più semplici, senza entrare in esempi complessi o casi d'uso avanzati.

Alcuni di questi attacchi sono diventati in gran parte obsoleti e non vengono più utilizzati da molti anni. Altri sono veterani che ancora nel 21° secolo si imbattono regolarmente negli ignari sviluppatori di sistemi crittografici. Si può considerare che l'era della crittografia moderna sia iniziata con l'avvento di IBM DES, il primo codice che ha resistito a tutti gli attacchi di questo elenco.

Semplice forza bruta

Lo schema di crittografia è composto da due parti: 1) la funzione di crittografia, che prende un messaggio (testo in chiaro) combinato con una chiave, e quindi crea un messaggio crittografato - testo cifrato; 2) una funzione di decrittazione che prende il testo cifrato e la chiave e produce testo in chiaro. Sia la crittografia che la decrittografia devono essere facili da calcolare con la chiave e difficili da calcolare senza di essa.

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

Si noti che ci sono due presupposti impliciti qui. Innanzitutto sappiamo come eseguire la decrittazione, ovvero come funziona il sistema crittografico. Questo è un presupposto standard quando si parla di crittografia. Nascondere i dettagli di implementazione del codice agli aggressori può sembrare una misura di sicurezza aggiuntiva, ma una volta che l’aggressore scopre questi dettagli, questa sicurezza aggiuntiva viene persa silenziosamente e in modo irreversibile. Ecco come Principio di Kerchhoff: Il sistema che cade nelle mani del nemico non dovrebbe causare disagi.

In secondo luogo, presupponiamo che la chiave corretta sia l'unica chiave che porterà a una decrittazione ragionevole. Anche questo è un presupposto ragionevole; è soddisfatto se il testo cifrato è molto più lungo della chiave ed è leggibile. Questo di solito è ciò che accade nel mondo reale, tranne tasti enormi e poco pratici o altri imbrogli che è meglio lasciare da parte (se non ti piace abbiamo saltato la spiegazione, vedi Teorema 3.8 qui).

Considerato quanto sopra, nasce una strategia: controllare ogni chiave possibile. Questa si chiama forza bruta e un simile attacco funzionerà sicuramente contro tutti i codici pratici, prima o poi. Ad esempio, per hackerare è sufficiente la forza bruta Cifra di Cesare, un antico codice in cui la chiave è una lettera dell'alfabeto, il che implica poco più di 20 possibili chiavi.

Sfortunatamente per i crittoanalisti, aumentare la dimensione della chiave è una buona difesa contro la forza bruta. All'aumentare della dimensione della chiave, il numero di chiavi possibili aumenta in modo esponenziale. Con le dimensioni delle chiavi moderne, la semplice forza bruta è completamente impraticabile. Per capire cosa intendiamo, prendiamo il supercomputer più veloce conosciuto a metà 2019: Vertice da IBM, con prestazioni di picco di circa 1017 operazioni al secondo. Oggi la lunghezza tipica della chiave è di 128 bit, il che significa 2128 combinazioni possibili. Per cercare tutte le chiavi, il supercomputer Summit avrà bisogno di un tempo pari a circa 7800 volte l'età dell'Universo.

La forza bruta dovrebbe essere considerata una curiosità storica? Niente affatto: è un ingrediente necessario nel ricettario di crittoanalisi. Raramente i codici sono così deboli da poter essere violati solo da un attacco intelligente, senza l'uso della forza in un modo o nell'altro. Molti hack di successo utilizzano prima un metodo algoritmico per indebolire il codice bersaglio e poi eseguire un attacco di forza bruta.

Analisi della frequenza

La maggior parte dei testi non sono incomprensibili. Ad esempio, nei testi inglesi ci sono molte lettere 'e' e articoli 'the'; nei file binari, ci sono molti byte zero come riempimento tra le informazioni. L'analisi della frequenza è qualsiasi attacco che sfrutta questo fatto.

L'esempio canonico di cifrario vulnerabile a questo attacco è il semplice cifrario a sostituzione. In questo codice la chiave è una tabella con tutte le lettere sostituite. Ad esempio, "g" viene sostituito da "h", "o" da j, quindi la parola "go" diventa "hj". Questo codice è difficile da usare con la forza bruta perché ci sono così tante possibili tabelle di ricerca. Se sei interessato ai calcoli, la lunghezza effettiva della chiave è di circa 88 bit: questo è
. Ma l’analisi della frequenza di solito porta a termine il lavoro rapidamente.

Consideriamo il seguente testo cifrato elaborato con un semplice codice a sostituzione:

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

Da Y si verifica frequentemente, anche alla fine di molte parole, possiamo provvisoriamente supporre che questa sia la lettera e:

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

Coppia XD ripetuto all'inizio di più 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 ulteriormente che L fiammiferi r, A - a e così via. Probabilmente ci vorranno alcuni tentativi, ma rispetto a un attacco di forza bruta completo, questo attacco ripristina il testo originale in pochissimo tempo:

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

Per alcuni, risolvere questi “crittogrammi” è un hobby entusiasmante.

L'idea dell'analisi della frequenza è più fondamentale di quanto sembri a prima vista. E si applica a cifre molto più complesse. Nel corso della storia, vari progetti di cifratura hanno tentato di contrastare un simile attacco utilizzando la "sostituzione polialfabetica". Qui, durante il processo di crittografia, la tabella di sostituzione delle lettere viene modificata in modi complessi ma prevedibili che dipendono dalla chiave. Tutti questi codici erano considerati difficili da decifrare contemporaneamente; eppure una modesta analisi di frequenza alla fine li ha sconfitti tutti.

Il codice polialfabetico più ambizioso della storia, e probabilmente il più famoso, fu il codice Enigma della Seconda Guerra Mondiale. Era relativamente complesso rispetto ai suoi predecessori, ma dopo molto duro lavoro, i crittoanalisti britannici lo riuscirono utilizzando l'analisi della frequenza. Ovviamente non potevano sviluppare un attacco elegante come quello mostrato sopra; dovevano confrontare coppie note di testo in chiaro e testo cifrato (il cosiddetto "attacco al testo in chiaro"), provocando anche gli utenti di Enigma a crittografare determinati messaggi e analizzare il risultato (l'"attacco al testo in chiaro scelto"). Ma ciò non facilitò il destino degli eserciti nemici sconfitti e dei sottomarini affondati.

Dopo questo trionfo, l’analisi delle frequenze scomparve dalla storia della crittoanalisi. I codici nell’era digitale moderna sono progettati per funzionare con i bit, non con le lettere. Ancora più importante, questi codici furono progettati con l'oscura comprensione di ciò che in seguito divenne noto come La legge di Schneier: Chiunque può creare un algoritmo di crittografia che lui stesso non può violare. Non è sufficiente per il sistema di crittografia sembrava difficile: per dimostrare il suo valore, deve essere sottoposto a uno spietato controllo di sicurezza da parte di molti crittoanalisti che faranno del loro meglio per decifrare il codice.

Calcoli preliminari

Prendiamo l'ipotetica città di Precom Heights, con una popolazione di 200 abitanti. Ogni casa in città contiene oggetti di valore per un valore medio di 000 dollari, ma non più di 30 dollari. Il mercato della sicurezza a Precom è monopolizzato da ACME Industries, che produce le leggendarie serrature per porte di classe Coyote™. Secondo l’analisi degli esperti, una serratura di classe Coyote può essere rotta solo da un’ipotetica macchina molto complessa, la cui creazione richiede circa cinque anni e 000 dollari di investimento. La città è sicura?

Molto probabilmente no. Alla fine apparirà un criminale abbastanza ambizioso. Ragionerà così: “Sì, dovrò sostenere ingenti costi iniziali. Cinque anni di paziente attesa e 50 dollari, ma quando avrò finito, 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 contro un particolare codice sono soggetti a una spietata analisi costi-benefici. Se il rapporto è favorevole, l’attacco non avverrà. Ma gli attacchi che agiscono contro molte potenziali vittime contemporaneamente quasi sempre ripagano, nel qual caso la migliore pratica di progettazione è presumere che siano iniziati dal primo giorno. Abbiamo essenzialmente una versione crittografica della legge di Murphy: "Tutto ciò che può effettivamente rompere il sistema lo romperà".

L’esempio più semplice di un sistema crittografico vulnerabile a un attacco di precalcolo è un codice senza chiave costante. Questo è stato il caso di La cifra di Cesare, che sposta semplicemente ciascuna lettera dell'alfabeto in avanti di tre lettere (la tabella viene ripetuta in loop, quindi l'ultima lettera dell'alfabeto viene crittografata per terza). Anche in questo caso entra in gioco il principio di Kerchhoff: una volta che un sistema viene violato, rimane violato per sempre.

Il concetto è semplice. Anche uno sviluppatore di sistemi crittografici alle prime armi probabilmente riconoscerà la minaccia e si preparerà di conseguenza. Osservando l’evoluzione della crittografia, tali attacchi erano inappropriati per la maggior parte dei cifrari, dalle prime versioni migliorate del cifrario di Cesare fino al declino dei cifrari polialfabetici. Tali attacchi sono ritornati solo con l’avvento dell’era moderna della crittografia.

Questo rendimento è dovuto a due fattori. In primo luogo, sono finalmente comparsi sistemi crittografici sufficientemente complessi, in cui la possibilità di sfruttamento dopo l'hacking non era ovvia. In secondo luogo, la crittografia è diventata così diffusa che milioni di profani hanno deciso ogni giorno su dove e quali parti della crittografia riutilizzare. C'è voluto del tempo prima che gli esperti si rendessero conto dei rischi e lanciassero l'allarme.

Ricorda l'attacco pre-calcolo: alla fine dell'articolo esamineremo due esempi crittografici reali in cui ha svolto un ruolo importante.

interpolazione

Ecco il famoso detective Sherlock Holmes, che esegue un attacco di interpolazione allo sfortunato dottor Watson:

Ho subito intuito che venissi dall'Afghanistan... Il mio pensiero era il seguente: “Quest'uomo è un medico di tipo, ma ha un portamento militare. Quindi, un medico militare. È appena arrivato dai tropici: il suo viso è scuro, ma questa non è la tonalità naturale della sua pelle, poiché i suoi polsi sono molto più bianchi. Il viso è smunto: ovviamente ha sofferto molto e ha sofferto di malattie. È stato ferito alla mano sinistra: la tiene immobile e in modo un po' innaturale. Dove ai tropici un medico militare inglese potrebbe soffrire disagi e rimanere ferito? Naturalmente in Afghanistan." L'intero corso dei pensieri non durò nemmeno un secondo. E così ho detto che venivi dall'Afghanistan e sei rimasto sorpreso.

Holmes poteva estrarre pochissime informazioni da ciascuna prova individualmente. Poteva giungere alla sua conclusione solo considerandoli tutti insieme. Un attacco di interpolazione funziona in modo simile esaminando coppie note di testo in chiaro e testo cifrato risultanti dalla stessa chiave. Da ciascuna coppia vengono estratte osservazioni individuali che consentono di trarre una conclusione generale sulla chiave. Tutte queste conclusioni sono vaghe e sembrano inutili finché non raggiungono improvvisamente una massa critica e portano all'unica conclusione possibile: non importa quanto incredibile sia, deve essere vera. Successivamente, la chiave viene rivelata oppure il processo di decrittazione diventa così raffinato da poter essere replicato.

Illustriamo con un semplice esempio come funziona l'interpolazione. Diciamo che vogliamo leggere il diario personale del nostro nemico, Bob. Crittografa ogni numero della sua agenda utilizzando un semplice sistema crittografico che ha appreso da una pubblicità sulla rivista "A Mock of Cryptography". Il sistema funziona così: Bob sceglie due numeri che gli piacciono: и . D'ora in poi, per crittografare qualsiasi numero , calcola . Ad esempio, se Bob scegliesse и , quindi il numero verrà crittografato come .

Diciamo che il 28 dicembre abbiamo notato che Bob stava grattando qualcosa sul suo diario. Quando avrà finito, lo riprenderemo in silenzio e guarderemo l'ultima voce:

Дата: 235/520

Caro diario,

Oggi è stata una buona giornata. Attraverso 64 oggi ho un appuntamento con Alisa, che vive in un appartamento 843. Penso davvero che potrebbe esserlo 26!

Dato che siamo seriamente intenzionati a seguire Bob al suo appuntamento (in questo scenario abbiamo entrambi 15 anni), è fondamentale conoscere la data e l'indirizzo di Alice. Fortunatamente, notiamo che il sistema crittografico di Bob è vulnerabile a un attacco di interpolazione. Forse non lo sappiamo и , ma conosciamo la data odierna, quindi abbiamo due coppie testo in chiaro-testo cifrato. Cioè, lo sappiamo crittografato E - in . Questo è ciò che scriveremo:

Dato che abbiamo 15 anni, conosciamo già un sistema di due equazioni in due incognite, che in questa situazione è sufficiente per trovare и senza alcun problema. Ciascuna coppia testo in chiaro-testo cifrato pone un vincolo sulla chiave di Bob, e i due vincoli insieme sono sufficienti per recuperare completamente la chiave. Nel nostro esempio la risposta è и (a affinché 26 nel diario corrisponde alla parola "quello", cioè "lo stesso" - ca. sentiero).

Gli attacchi di interpolazione, ovviamente, non si limitano a esempi così semplici. Ogni crittosistema che si riduce a un oggetto matematico ben compreso e a un elenco di parametri è a rischio di un attacco di interpolazione: più comprensibile è l'oggetto, maggiore è il rischio.

I nuovi arrivati ​​spesso si lamentano del fatto che la crittografia è “l’arte di progettare le cose nel modo più brutto possibile”. Probabilmente la colpa è in gran parte degli attacchi di interpolazione. Bob può utilizzare un elegante disegno matematico o mantenere privato il suo appuntamento con Alice, ma ahimè, di solito non è possibile avere entrambe le cose. Ciò diventerà molto chiaro quando finalmente arriveremo all’argomento della crittografia a chiave pubblica.

Protocollo incrociato/downgrade

In Now You See Me (2013), un gruppo di illusionisti tenta di truffare il magnate delle assicurazioni corrotto Arthur Tressler con tutta la sua fortuna. Per ottenere l'accesso al conto bancario di Arthur, gli illusionisti devono fornire il suo nome utente e la password oppure costringerlo a presentarsi di persona in banca e prendere parte al piano.

Entrambe le opzioni sono molto difficili; I ragazzi sono abituati a esibirsi sul palco e a non partecipare a operazioni di intelligence. Scelgono allora la terza opzione possibile: il loro complice chiama la banca e si finge Arthur. La banca pone diverse domande per verificare l'identità, come il nome dello zio e il nome del primo animale domestico; i nostri eroi in anticipo estraggono facilmente queste informazioni da Arthur utilizzando un'ingegnosa ingegneria sociale. Da questo momento in poi, un’eccellente sicurezza delle password non avrà più importanza.

(Secondo una leggenda metropolitana che abbiamo verificato e verificato personalmente, il crittografo Eli Beaham una volta incontrò un cassiere di banca che insisteva per porre una domanda di sicurezza. Quando il cassiere chiese il nome di sua nonna materna, Beaham iniziò a dettare: “Maiuscola X, piccola y, tre...").

È lo stesso in crittografia, se due protocolli crittografici vengono utilizzati in parallelo per proteggere la stessa risorsa e uno è molto più debole dell’altro. Il sistema risultante diventa vulnerabile a un attacco multiprotocollo, in cui viene attaccato un protocollo più debole per raggiungere il premio senza toccare quello più forte.

In alcuni casi complessi non è sufficiente contattare semplicemente il server utilizzando un protocollo più debole, ma è necessaria la partecipazione involontaria di un client legittimo. Questo può essere organizzato utilizzando il cosiddetto attacco di downgrade. Per comprendere questo attacco, supponiamo che i nostri illusionisti abbiano un compito più difficile rispetto al film. Supponiamo che un impiegato di banca (cassiere) e Arthur si siano imbattuti in circostanze impreviste, dando luogo al seguente dialogo:

Ladro: Ciao? Questo è Arthur Tressler. Vorrei reimpostare la mia password.

cassiere: Grande. Per favore dai un'occhiata al tuo libro dei codici segreti personali, pagina 28, parola 3. Tutti i messaggi successivi verranno crittografati utilizzando questa parola specifica come chiave. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Ladro: Ehi, ehi, aspetta, aspetta. È davvero necessario? Non possiamo semplicemente parlare come persone normali?

cassiere: Non consiglio di farlo.

Ladro: È solo che... guarda, ho avuto una giornata schifosa, ok? Sono un cliente VIP e non ho voglia di frugare in questi stupidi libri di codici.

cassiere: Bene. Se insiste, signor Tressler. Cosa vuoi?

Ladro: Per favore, vorrei donare tutti i miei soldi all'Arthur Tressler National Victims Fund.

(Pausa).

cassiere: E' chiaro adesso? Fornisci il tuo PIN per transazioni di grandi dimensioni.

Ladro: Il mio cosa?

cassiere: Su tua richiesta personale, transazioni di queste dimensioni richiedono un PIN per transazioni di grandi dimensioni. Questo codice ti è stato dato quando hai aperto il tuo account.

Ladro:... L'ho perso. È davvero necessario? Non puoi semplicemente approvare l'accordo?

cassiere: NO. Mi dispiace, signor Tressler. Ancora una volta, questa è la misura di sicurezza che hai chiesto. Se lo desideri, possiamo inviare un nuovo codice PIN alla tua casella di posta.

I nostri eroi rimandano l'operazione. Ascoltano di nascosto molte delle grandi transazioni di Tressler, sperando di sentire il PIN; ma ogni volta la conversazione si trasforma in un linguaggio senza senso prima che venga detto qualcosa di interessante. Alla fine, un bel giorno, il piano viene messo in atto. Aspettano pazientemente il momento in cui Tressler dovrà effettuare una grossa transazione telefonica, si mette in linea e poi...

Tressler: Ciao. Vorrei completare una transazione remota, per favore.

cassiere: Grande. Per favore dai un'occhiata al tuo libro dei codici segreti personali, pagina...

(Il ladro preme il pulsante; la voce della cassiera si trasforma in un rumore incomprensibile).

cassiere: - #@$#@$#*@$$@#* verrà crittografato con questa parola come chiave. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Scusa, non ho capito bene. Ancora? In quale pagina? Quale parola?

cassiere: Questa è la pagina @#$@#*$)#*#@()#@$(#@*$(#@*.

Tressler: Che cosa?

cassiere: Parola numero venti @$#@$#%#$.

Tressler: Sul serio! Già abbastanza! Tu e il tuo protocollo di sicurezza siete una specie di circo. So che puoi parlarmi normalmente.

cassiere: Non lo consiglio…

Tressler: E non ti consiglio di farmi perdere tempo. Non voglio saperne più finché non risolverai i problemi della linea telefonica. Possiamo concludere questo accordo oppure no?

cassiere:… SÌ. Bene. Cosa vuoi?

Tressler: Vorrei trasferire $ 20 a Lord Business Investments, numero di conto...

cassiere: Un minuto, per favore. È un grosso problema. Fornisci il tuo PIN per transazioni di grandi dimensioni.

Tressler: Che cosa? Oh, esattamente. 1234.

Ecco un attacco al ribasso. Era previsto il protocollo più debole "parla direttamente". opzione in caso di emergenza. Eppure eccoci qui.

Potresti chiederti chi sano di mente progetterebbe un vero sistema "sicuro fino a quando non viene richiesto diversamente" come quello descritto sopra. Ma proprio come una banca immaginaria corre dei rischi per mantenere i clienti a cui non piace la crittografia, i sistemi in generale spesso gravitano verso requisiti indifferenti o addirittura addirittura ostili alla sicurezza.

Questo è esattamente quello che è successo con il protocollo SSLv2 nel 1995. Il governo degli Stati Uniti ha iniziato da tempo a considerare la crittografia come un’arma che è meglio tenere lontana dai nemici interni e stranieri. Pezzi di codice venivano approvati individualmente per l'esportazione dagli Stati Uniti, spesso a condizione che l'algoritmo fosse deliberatamente indebolito. Netscape, lo sviluppatore del browser più popolare, Netscape Navigator, ha ottenuto l'autorizzazione per SSLv2 solo con la chiave RSA a 512 bit intrinsecamente vulnerabile (e 40 bit per RC4).

Entro la fine del millennio, le regole si erano allentate e l’accesso alla crittografia moderna era diventato ampiamente disponibile. Tuttavia, client e server supportano da anni la crittografia di "esportazione" indebolita a causa della stessa inerzia che mantiene il supporto per qualsiasi sistema legacy. I clienti credevano che avrebbero potuto incontrare un server che non supportava nient'altro. I server hanno fatto lo stesso. Naturalmente, il protocollo SSL impone che client e server non debbano mai utilizzare un protocollo debole quando ne è disponibile uno migliore. Ma la stessa premessa valeva anche per Tressler e la sua banca.

Questa teoria è stata alla base di due attacchi di alto profilo che hanno scosso la sicurezza del protocollo SSL nel 2015, entrambi scoperti da ricercatori Microsoft e INRIA. Innanzitutto, i dettagli dell’attacco FREAK sono stati rivelati a febbraio, seguito tre mesi dopo da un altro attacco simile chiamato Logjam, di cui parleremo più in dettaglio quando passeremo agli attacchi alla crittografia a chiave pubblica.

vulnerabilità FREAK (noto anche come "Smack TLS") è venuto alla luce quando i ricercatori hanno analizzato le implementazioni client/server TLS e hanno scoperto un curioso bug. In queste implementazioni, se il client non chiede nemmeno di utilizzare la crittografia di esportazione debole, ma il server risponde comunque con tali chiavi, il client dice "Oh bene" e passa a una suite di crittografia debole.

All'epoca, la crittografia per l'esportazione era ampiamente considerata obsoleta e off-limits, quindi l'attacco fu uno shock totale e colpì molti domini importanti, tra cui la Casa Bianca, l'IRS e i siti della NSA. Ancora peggio, si scopre che molti server vulnerabili ottimizzavano le prestazioni riutilizzando le stesse chiavi anziché generarne di nuove per ogni sessione. Ciò ha permesso, dopo aver declassato il protocollo, di effettuare un attacco pre-calcolo: crackare una chiave è rimasto relativamente costoso (100 dollari e 12 ore al momento della pubblicazione), ma il costo pratico dell'attacco alla connessione è stato notevolmente ridotto. È sufficiente selezionare una volta la chiave del server e da quel momento in poi decifrare la crittografia per tutte le connessioni successive.

E prima di proseguire, c'è un attacco avanzato che merita di essere menzionato...

Attacco dell'Oracolo

Moxie Marlinspike meglio conosciuto come il padre dell'app di messaggistica crittografica multipiattaforma Signal; ma personalmente ci piace una delle sue innovazioni meno conosciute: principio del destino crittografico (Principio del destino crittografico). Parafrasando leggermente, possiamo dire questo: “Se il protocollo funziona qualsiasi esegue un'operazione crittografica su un messaggio proveniente da una fonte potenzialmente dannosa e si comporta in modo diverso a seconda del risultato, è condannato." O in una forma più nitida: "Non prendere informazioni dal nemico per l'elaborazione e, se necessario, almeno non mostrare il risultato".

Lasciamo da parte buffer overflow, iniezioni di comandi e simili; vanno oltre lo scopo di questa discussione. La violazione del "principio del destino" porta a gravi attacchi alla crittografia perché il protocollo si comporta esattamente come previsto.

Ad esempio, prendiamo un progetto fittizio con un codice di sostituzione vulnerabile e poi dimostriamo un possibile attacco. Sebbene abbiamo già assistito ad un attacco a un codice di sostituzione utilizzando l'analisi della frequenza, non si tratta semplicemente di "un altro modo per violare lo stesso codice". Al contrario, gli attacchi oracle sono un’invenzione molto più moderna, applicabile a molte situazioni in cui l’analisi della frequenza fallisce, e ne vedremo una dimostrazione nella prossima sezione. Qui si sceglie la cifra semplice solo per rendere l'esempio più chiaro.

Quindi Alice e Bob comunicano utilizzando un semplice codice di sostituzione utilizzando una chiave nota solo a loro. Sono molto severi riguardo alla lunghezza dei messaggi: sono esattamente 20 caratteri. Quindi hanno concordato che se qualcuno avesse voluto inviare un messaggio più breve, avrebbe dovuto aggiungere del testo fittizio alla fine del messaggio per renderlo esattamente di 20 caratteri. Dopo qualche discussione, hanno deciso che avrebbero accettato solo i seguenti testi fittizi: a, bb, ccc, dddd ecc. Pertanto, è noto un testo fittizio di qualsiasi lunghezza richiesta.

Quando Alice o Bob ricevono un messaggio, controllano innanzitutto che il messaggio abbia la lunghezza corretta (20 caratteri) e che il suffisso sia il testo fittizio corretto. In caso contrario, rispondono con un messaggio di errore appropriato. Se la lunghezza del testo e il testo fittizio sono corretti, il destinatario legge il messaggio stesso e invia una risposta crittografata.

Durante l'attacco, l'aggressore si spaccia per Bob e invia messaggi falsi ad Alice. I messaggi sono completamente senza senso: l'aggressore non ha la chiave e quindi non può creare un messaggio significativo. Ma poiché il protocollo viola il principio del destino, un utente malintenzionato può comunque intrappolare Alice inducendola a rivelare le informazioni chiave, come mostrato di seguito.

Ladro: PREWF ZHJKL MMMN. LA

Alice: Testo fittizio non valido.

Ladro: PREWF ZHJKL MMMN. LB

Alice: Testo fittizio non valido.

Ladro: 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 il simbolo C deve combaciare a, poiché Alice ha accettato il testo fittizio.

Ladro: REWF ZHJKL MMMN. LAA

Alice: Testo fittizio non valido.

Ladro: REWF ZHJKL MMMN. LBB

Alice: Testo fittizio non valido.

Dopo una serie di tentativi...

Ladro: REWF ZHJKL MMMN. LGG

Alice: Testo fittizio non valido.

Ladro: 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 cosa abbia appena detto Alice, ma nota che H deve corrispondere a b poiché Alice ha accettato il testo fittizio.

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

A prima vista, il metodo assomiglia ad un attacco con testo in chiaro scelto. Alla fine, l’aggressore seleziona i testi cifrati e il server li elabora obbedientemente. La differenza principale che rende questi attacchi praticabili nel mondo reale è che l’aggressore non ha bisogno di accedere alla trascrizione effettiva: è sufficiente una risposta del server, anche innocua come “Testo fittizio non valido”.

Sebbene questo particolare attacco sia istruttivo, non fissarti troppo sulle specifiche dello schema del "testo fittizio", sullo specifico sistema crittografico utilizzato o sull'esatta sequenza di messaggi inviati dall'aggressore. L'idea di base è come Alice reagisce in modo diverso in base alle proprietà del testo in chiaro, e lo fa senza verificare che il testo cifrato corrispondente provenga effettivamente da una parte fidata. Pertanto, Alice consente all'aggressore di estrarre informazioni segrete dalle sue risposte.

C’è molto che può essere cambiato in questo scenario. I simboli a cui Alice reagisce, o la differenza stessa nel suo comportamento, o anche il crittosistema utilizzato. Ma il principio rimarrà lo stesso, e l’attacco nel suo insieme resterà praticabile in una forma o nell’altra. L'implementazione di base di questo attacco ha contribuito a scoprire diversi bug di sicurezza, che esamineremo tra breve; ma prima ci sono alcune lezioni teoriche da imparare. Come utilizzare questo fittizio "script Alice" in un attacco che possa funzionare su un vero codice moderno? È possibile, anche in teoria?

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

Quattro anni dopo, nel 2002, il crittografo francese Serge Vaudenay ha dimostrato un attacco oracolare quasi identico a quello descritto nello scenario di Alice sopra, tranne per il fatto che invece di un codice fittizio, ha rotto un'intera classe rispettabile di codici moderni che le persone effettivamente utilizzano. In particolare, l'attacco di Vaudenay prende di mira i cifrari a dimensione di input fissa ("cifrari a blocchi") quando vengono utilizzati nella cosiddetta "modalità di crittografia CBC" e con un certo schema di riempimento popolare, sostanzialmente equivalente a quello dello scenario Alice.

Sempre nel 2002, il crittografo americano John Kelsey è coautore Twofish - ha proposto vari attacchi Oracle a sistemi che comprimono i messaggi e poi li crittografano. Tra questi il ​​più notevole è stato un attacco che ha approfittato del fatto che spesso è possibile dedurre la lunghezza originale del testo in chiaro dalla lunghezza del testo cifrato. In teoria, ciò consente un attacco oracolare che recupera parti del testo in chiaro originale.

Di seguito forniamo una descrizione più dettagliata degli attacchi Vaudenay e Kelsey (daremo una descrizione più dettagliata dell'attacco Bleichenbacher quando passeremo agli attacchi alla crittografia a chiave pubblica). Nonostante i nostri migliori sforzi, il testo diventa alquanto tecnico; quindi se quanto sopra ti basta, salta le due sezioni successive.

L'attacco di Vodene

Per comprendere l’attacco Vaudenay, dobbiamo prima parlare un po’ di più dei codici a blocchi e delle modalità di crittografia. Un "codice a blocchi" è, come accennato, un codice che prende una chiave e un input di una certa lunghezza fissa ("lunghezza del blocco") e produce un blocco crittografato della stessa lunghezza. I codici a blocchi sono ampiamente utilizzati e considerati relativamente sicuri. Il DES, ormai in pensione, considerato il primo cifrario moderno, era un cifrario a blocchi. Come accennato in precedenza, lo stesso vale per AES, che oggi è ampiamente utilizzato.

Sfortunatamente, i codici a blocchi hanno un evidente punto debole. La dimensione tipica del blocco è di 128 bit o 16 caratteri. Ovviamente, la crittografia moderna richiede di lavorare con dati di input più grandi, ed è qui che entrano in gioco le modalità di crittografia. La modalità di crittografia è essenzialmente un hack: è un modo per applicare in qualche modo un codice a blocchi che accetta solo input di una certa dimensione su input di lunghezza arbitraria.

L'attacco di Vodene si concentra sulla popolare modalità operativa CBC (Cipher Block Chaining). L'attacco tratta il codice a blocchi sottostante come una scatola nera magica e inespugnabile e ne aggira completamente la sicurezza.

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

Il segno più cerchiato indica l'operazione XOR (OR esclusivo). Ad esempio, viene ricevuto il secondo blocco di testo cifrato:

1. Eseguendo un'operazione XOR sul secondo blocco di testo in chiaro con il primo blocco di testo cifrato.
2. Crittografia del blocco risultante con un codice a blocchi utilizzando una chiave.

Dato che CBC fa un uso così massiccio dell'operazione XOR binaria, prendiamoci un momento per ricordare alcune delle sue proprietà:

• Idempotenza:
• Commutatività:
• Associatività:
• Autoreversibilità:
• Dimensione byte: byte n di = (byte n di ) (byte n di )

Tipicamente, queste proprietà implicano che se abbiamo un'equazione che coinvolge operazioni XOR e un'incognita, può essere risolta. Ad esempio, se lo sappiamo con l'ignoto e famoso и , allora possiamo fare affidamento sulle proprietà sopra menzionate per risolvere l'equazione per . Applicando XOR su entrambi i lati dell'equazione con , noi abbiamo . Tutto questo diventerà molto rilevante tra un momento.

Ci sono due differenze minori e una differenza maggiore tra il nostro scenario di Alice e l'attacco di Vaudenay. Due minori:

• Nella sceneggiatura, Alice si aspettava che i testi in chiaro finissero con i personaggi a, bb, ccc e così via. Nell'attacco Wodene, la vittima si aspetta invece che i testi in chiaro finiscano N volte con l'N byte (cioè esadecimale 01 o 02 02, o 03 03 03, e così via). Questa è puramente una differenza estetica.
• Nello scenario di Alice era facile capire se Alice aveva accettato il messaggio dalla risposta "Testo fittizio errato". Nell'attacco di Vodene è necessaria una maggiore analisi ed è importante un'attuazione precisa da parte della vittima; ma per brevità diamo per scontato che questa analisi sia ancora possibile.

Differenza principale:

• Poiché non utilizziamo lo stesso sistema crittografico, la relazione tra i byte del testo cifrato controllati dall'aggressore e i segreti (chiave e testo in chiaro) sarà ovviamente diversa. Pertanto, l’aggressore dovrà utilizzare una strategia diversa durante la creazione di testi cifrati e l’interpretazione delle risposte del server.

Questa differenza principale è l'ultimo pezzo del puzzle per comprendere l'attacco di Vaudenay, quindi prendiamoci un momento per pensare al perché e al come un attacco Oracle a CBC possa essere organizzato in primo luogo.

Supponiamo che ci venga fornito un testo cifrato CBC di 247 blocchi e che vogliamo decrittografarlo. Possiamo inviare messaggi falsi al server, proprio come prima potevamo inviare messaggi falsi ad Alice. Il server decodificherà i messaggi per noi, ma non mostrerà la decrittazione; invece, ancora una volta, come con Alice, il server riporterà solo un bit di informazione: se il testo in chiaro ha un riempimento valido o meno.

Considera che nello scenario di Alice avevamo le seguenti relazioni:

$$display$$testo{SIMPLE_SUBSTITUTION}(testo{testo cifrato},testo{chiave}) = testo{testo semplice}$$display$$

Chiamiamola "equazione di Alice". Controllavamo il testo cifrato; il server (Alice) ha fatto trapelare vaghe informazioni sul testo in chiaro ricevuto; e questo ci ha permesso di dedurre informazioni sull'ultimo fattore: la chiave. Per analogia, se riusciamo a trovare una tale connessione per lo script CBC, potremmo essere in grado di estrarre alcune informazioni segrete anche lì.

Fortunatamente, ci sono davvero relazioni là fuori che possiamo sfruttare. Considera l'output della chiamata finale per decrittografare un codice a blocchi e denota questi dati come . Indichiamo anche blocchi di testo in chiaro e blocchi di testo cifrato . Dai un'altra occhiata al diagramma CBC e nota cosa succede:

Chiamiamola “equazione CBC”.

Nello scenario di Alice, monitorando il testo cifrato e osservando la corrispondente perdita di testo in chiaro, siamo stati in grado di sferrare un attacco che ha recuperato il terzo termine dell'equazione: la chiave. Nello scenario CBC monitoriamo anche il testo cifrato e osserviamo fughe di informazioni sul corrispondente testo in chiaro. Se l'analogia vale, possiamo ottenere informazioni su .

Supponiamo di aver davvero ripristinato , cosa poi? Bene, allora possiamo stampare l'intero ultimo blocco di testo in chiaro in una volta (), semplicemente inserendo (che abbiamo) e
ricevuto nell'equazione CBC.

Ora che siamo ottimisti riguardo al piano d'attacco complessivo, è tempo di elaborare i dettagli. Si prega di prestare attenzione a come le informazioni in chiaro vengono divulgate sul server. Nello script di Alice, la perdita si è verificata perché Alice avrebbe risposto con il messaggio corretto solo se $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ terminava con la riga a (o bb, e così via, ma le probabilità che queste condizioni si innescassero per caso erano molto piccole). Similmente al CBC, il server accetta il riempimento se e solo se termina in esadecimale 01. Quindi proviamo lo stesso trucco: inviare falsi testi cifrati con i nostri falsi valori finché il server non accetta il riempimento.

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

Ora utilizziamo la proprietà XOR byte-byte:

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

Questo ci fornisce anche l'ultimo byte del blocco finale di testo in chiaro tramite l'equazione CBC e la proprietà byte per byte.

Potremmo lasciare le cose così e accontentarci di aver effettuato un attacco a un codice teoricamente forte. Ma in realtà possiamo fare molto di più: possiamo recuperare effettivamente tutto il testo. Ciò richiede un trucco che non era nella sceneggiatura originale di Alice e non è richiesto per l'attacco all'oracolo, ma vale comunque la pena impararlo.

Per capirlo, notare innanzitutto che il risultato dell'emissione del valore corretto dell'ultimo byte è abbiamo una nuova abilità. Ora, quando forgiamo testi cifrati, possiamo manipolare l'ultimo byte del testo in chiaro corrispondente. Ancora una volta, questo è correlato all'equazione CBC e alla proprietà byte per byte:

Poiché ora conosciamo il secondo termine, possiamo usare il nostro controllo sul primo per controllare il terzo. Calcoliamo semplicemente:

Non potevamo farlo prima perché non avevamo ancora l'ultimo byte .

In che modo questo ci aiuterà? Supponiamo ora di creare tutti i testi cifrati in modo tale che nei corrispondenti testi in chiaro l'ultimo byte sia uguale a 02. Il server ora accetta il riempimento solo se il testo in chiaro termina con 02 02. Dato che abbiamo corretto l'ultimo byte, ciò accadrà solo se anche il penultimo byte del testo in chiaro è 02. Continuiamo a inviare blocchi di testo cifrato falsi, modificando il penultimo byte, finché il server non accetta il riempimento per uno di essi. A questo punto otteniamo:

E ripristiniamo il penultimo byte proprio come l'ultimo è stato restaurato. Continuiamo con lo stesso spirito: correggiamo gli ultimi due byte del testo in chiaro in 03 03, ripetiamo questo attacco per il terzo byte dalla fine e così via, ripristinando infine completamente .

E il resto del testo? Si prega di notare che il valore in realtà è $inline$testo{BLOCK_DECRYPT}(testo{chiave},C_{247})$inline$. Possiamo invece mettere qualsiasi altro blocco , e l'attacco avrà comunque successo. Infatti, possiamo chiedere al server di eseguire $inline$text{BLOCK_DECRYPT}$inline$ per qualsiasi dato. A questo punto il gioco è finito: possiamo decrittografare qualsiasi testo cifrato (dai un'altra occhiata al diagramma di decrittazione CBC per vederlo; e nota che l'IV è pubblico).

Questo particolare metodo gioca un ruolo cruciale nell'attacco all'oracolo che incontreremo più avanti.

L'attacco di Kelsey

Il nostro simpatico John Kelsey ha esposto i principi alla base di molti possibili attacchi, non solo i dettagli di un attacco specifico a un codice specifico. Il suo Articolo 2002 dell'anno è uno studio sui possibili attacchi ai dati compressi crittografati. Pensavi che le informazioni relative alla compressione dei dati prima della crittografia non fossero sufficienti per sferrare un attacco? Si scopre che è abbastanza.

Questo risultato sorprendente è dovuto a due principi. Innanzitutto, esiste una forte correlazione tra la lunghezza del testo in chiaro e la lunghezza del testo cifrato; per molti codici l'uguaglianza esatta. In secondo luogo, quando viene eseguita 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 non ripetitivi (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 quindi crittografati. 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 compresso nella magra lunghezza del secondo testo cifrato. Lo abbiamo capito senza sapere nulla dell'algoritmo di compressione, della chiave di crittografia o persino della cifratura stessa. Rispetto alla gerarchia dei possibili attacchi crittografici, questo è un po’ pazzesco.

Kelsey sottolinea inoltre che in determinate circostanze insolite questo principio può essere utilizzato anche per effettuare un attacco oracolare. In particolare, viene descritto come un utente malintenzionato può recuperare il testo in chiaro segreto se riesce a forzare il server a crittografare i dati del modulo (il testo in chiaro seguito da mentre ha il controllo e può in qualche modo controllare la lunghezza del risultato crittografato.

Ancora una volta, come altri attacchi agli oracoli, abbiamo la relazione:

Ancora una volta, controlliamo un termine (), vediamo una piccola fuga di informazioni su un altro membro (testo cifrato) e proviamo a recuperare l'ultima (testo in chiaro). Nonostante l’analogia, questa è una situazione un po’ insolita rispetto ad altri attacchi agli oracoli che abbiamo visto.

Per illustrare come potrebbe funzionare un attacco del genere, utilizziamo uno schema di compressione fittizio che abbiamo appena ideato: TOYZIP. Cerca righe di testo apparse in precedenza nel testo e le sostituisce con tre byte segnaposto che indicano dove trovare un'istanza precedente della riga e quante volte appare lì. Ad esempio, la linea helloworldhello può essere compresso in helloworld[00][00][05] 13 byte di lunghezza rispetto ai 15 byte originali.

Supponiamo che un utente malintenzionato tenti di recuperare il testo in chiaro di un modulo password=..., dove la password stessa è sconosciuta. Secondo il modello di attacco di Kelsey, un utente malintenzionato potrebbe chiedere al server di comprimere e quindi crittografare i messaggi del modulo (testo in chiaro seguito da dove  - testo libero. Quando il server ha finito di funzionare, segnala la lunghezza del risultato. L'attacco è questo:

Ladro: Si prega di comprimere e crittografare il testo in chiaro senza imbottitura.

Server: Durata del risultato 14.

Ladro: Si prega di comprimere e crittografare il testo in chiaro a cui viene aggiunto password=a.

Server: Durata del risultato 18.

Il cracker nota: [14 originali] + [tre byte sostituiti password=]+ a

Ladro: Si prega di comprimere e crittografare il testo in chiaro a cui viene aggiunto password=b.

Server: Durata del risultato 18.

Ladro: Si prega di comprimere e crittografare il testo in chiaro a cui viene aggiunto password=с.

Server: Durata del risultato 17.

Il cracker nota: [14 originali] + [tre byte sostituiti password=c]. Ciò presuppone che il testo in chiaro originale contenga la stringa password=c. Cioè, la password inizia con una lettera c

Ladro: Si prega di comprimere e crittografare il testo in chiaro a cui viene aggiunto password=сa.

Server: Durata del risultato 18.

Il cracker nota: [14 originali] + [tre byte sostituiti password=с]+ a

Ladro: Si prega di comprimere e crittografare il testo in chiaro a cui viene aggiunto password=сb.

Server: Durata del risultato 18.

(… Qualche tempo dopo…)

Ladro: Si prega di comprimere e crittografare il testo in chiaro a cui viene aggiunto password=со.

Server: Durata del risultato 17.

Il cracker nota: [14 originali] + [tre byte sostituiti password=co]. Utilizzando la stessa logica, l'aggressore conclude che la password inizia con le lettere co

E così via fino al ripristino dell'intera password.

Il lettore potrebbe pensare che si tratti di un esercizio puramente accademico e che uno scenario di attacco del genere non si verificherebbe mai nel mondo reale. Ahimè, come vedremo tra poco, è meglio non rinunciare alla crittografia.

Vulnerabilità del marchio: CRIME, POODLE, DROWN

Infine, dopo aver studiato la teoria in dettaglio, possiamo vedere come queste tecniche vengono applicate negli attacchi crittografici nella vita reale.

CRIMINALITA '

Se l'attacco è mirato al browser e alla rete della vittima, alcuni attacchi saranno più facili, altri più difficili. Ad esempio, è facile vedere il traffico della vittima: basta sedersi con lui nello stesso bar con WiFi. Per questo motivo si consiglia generalmente alle potenziali vittime (ovvero a tutti) di utilizzare una connessione crittografata. Sarà più difficile, ma comunque possibile, effettuare richieste HTTP per conto della vittima a qualche sito di terze parti (ad esempio Google). L'aggressore deve attirare la vittima su una pagina Web dannosa con uno script che effettua la richiesta. Il browser web fornirà automaticamente il cookie di sessione appropriato.

Sembra sorprendente. Se Bob andasse a evil.com, lo script su questo sito potrebbe semplicemente chiedere a Google di inviare tramite email la password di Bob a [email protected]? Beh, in teoria sì, ma in realtà no. Questo scenario è chiamato attacco di falsificazione di richieste tra siti (Falsificazione richiesta su più siti, CSRF) ed era popolare intorno alla metà degli anni '90. Oggi se evil.com prova questo trucchetto, Google (o qualsiasi sito web che si rispetti) solitamente risponde: “Ottimo, ma il tuo token CSRF per questa transazione sarà... ehm... три триллиона и семь. Per favore ripeti questo numero." I browser moderni hanno una cosiddetta "politica della stessa origine" in base alla quale gli script sul sito A non hanno accesso alle informazioni inviate dal sito web B. Quindi lo script su evil.com può inviare richieste a google.com, ma non riesco a leggere le risposte o a completare effettivamente la transazione.

Dobbiamo sottolineare che, a meno che Bob non utilizzi una connessione crittografata, tutte queste protezioni sono prive di significato. Un utente malintenzionato può semplicemente leggere il traffico di Bob e recuperare il cookie di sessione di Google. Con questo cookie, aprirà semplicemente una nuova scheda Google senza uscire dal proprio browser e impersonerà Bob senza incontrare fastidiose politiche sulla stessa origine. Ma, sfortunatamente per un ladro, questo sta diventando sempre meno comune. Internet nel suo insieme ha da tempo dichiarato guerra alle connessioni non crittografate e il traffico in uscita di Bob è probabilmente crittografato, che gli piaccia o no. Inoltre, fin dall'inizio dell'implementazione del protocollo, anche il traffico lo è stato ristretto prima della crittografia; questa era una pratica comune per ridurre la latenza.

È qui che entra in gioco CRIMINALITA ' (Compression Ratio Infoleak Made Easy, semplice perdita attraverso il rapporto di compressione). La vulnerabilità è stata rivelata nel settembre 2012 dai ricercatori di sicurezza Juliano Rizzo e Thai Duong. Abbiamo già esaminato l'intera base teorica, che ci permette di capire cosa hanno fatto e come. Un utente malintenzionato potrebbe forzare il browser di Bob a inviare richieste a Google e quindi ad ascoltare le risposte sulla rete locale in forma compressa e crittografata. Pertanto abbiamo:

Qui l'aggressore controlla la richiesta e ha accesso allo sniffer del traffico, inclusa la dimensione del pacchetto. Lo scenario immaginario di Kelsey ha preso vita.

Comprendendo la teoria, gli autori di CRIME hanno creato un exploit in grado di rubare cookie di sessione per un'ampia gamma di siti, tra cui Gmail, Twitter, Dropbox e Github. La vulnerabilità ha colpito la maggior parte dei browser Web moderni, determinando il rilascio di patch che hanno nascosto silenziosamente la funzionalità di compressione in SSL in modo che non venisse utilizzata affatto. L'unico protetto da questa vulnerabilità era il venerabile Internet Explorer, che non utilizzava mai la compressione SSL.

BARBONCINO

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 che era stata corretta più di dieci anni fa.

Si scopre che mentre i server eseguono il nuovo brillante TLSv1.2, molti hanno lasciato il supporto per il legacy SSLv3 per la compatibilità con Internet Explorer 6. Abbiamo già parlato degli attacchi di downgrade, quindi puoi immaginare cosa sta succedendo. Un sabotaggio ben orchestrato del protocollo di handshake e i server sono pronti a tornare al buon vecchio SSLv3, annullando sostanzialmente gli ultimi 15 anni di ricerca sulla sicurezza.

Per il 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 tutte le transazioni effettuate su Internet dipendono da TLS. [..] Ma TLS non è sempre stato TLS. Il protocollo ha iniziato la sua vita nel Comunicazioni Netscape chiamato "Secure Sockets Layer" o SSL. Si dice che la prima versione di SSL fosse così terribile che gli sviluppatori raccolsero tutte le stampe del codice e le seppellirono in una discarica segreta nel New Mexico. Di conseguenza, la prima versione di SSL disponibile pubblicamente è in realtà versione SSL2. È piuttosto spaventoso e [..] era un prodotto della metà degli anni '90, che i moderni crittografi considerano "secoli bui della crittografia" Molti degli attacchi crittografici più atroci di cui siamo a conoscenza oggi non sono ancora stati scoperti. Di conseguenza, gli sviluppatori del protocollo SSLv2 sono stati sostanzialmente lasciati a brancolare nel buio e si sono trovati di fronte un sacco di mostri terribili - con loro disappunto e nostro vantaggio, poiché gli attacchi a SSLv2 hanno lasciato lezioni preziose per la prossima generazione di protocolli.

In seguito a questi eventi, nel 1996, un frustrato Netscape riprogettato da zero il protocollo SSL. Il risultato è stato SSL versione 3, che risolto diversi problemi di sicurezza noti del suo predecessore.

Fortunatamente per i ladri, “alcuni” non significa “tutti”. Nel complesso, SSLv3 ha fornito tutti gli elementi necessari per lanciare un attacco Vodene. Il protocollo utilizzava un codice a blocchi in modalità CBC e uno schema di riempimento non sicuro (questo è stato corretto in TLS; da qui la necessità di un attacco di downgrade). Se ricordate lo schema di riempimento nella nostra descrizione originale dell'attacco Vaudenay, lo schema SSLv3 è molto simile.

Ma sfortunatamente per i ladri “simile” non significa “identico”. Lo schema di riempimento SSLv3 è "N byte casuali seguiti dal numero N". Provate, in queste condizioni, a selezionare un blocco immaginario di testo cifrato e ripercorrete tutti i passaggi dello schema originale di Vaudene: vi accorgerete che l'attacco estrae con successo l'ultimo byte dal corrispondente blocco di testo in chiaro, ma non va oltre. Decifrare ogni sedicesimo byte del testo cifrato è un ottimo trucco, ma non è una vittoria.

Di fronte al fallimento, il team di Google ha fatto ricorso all'ultima risorsa: è passato a un modello di minaccia più potente, quello utilizzato in CRIME. Supponendo che l'aggressore sia uno script in esecuzione nella scheda del browser della vittima e possa estrarre cookie di sessione, l'attacco è comunque impressionante. Sebbene il modello di minaccia più ampio sia meno realistico, abbiamo visto nella sezione precedente che questo particolare modello è fattibile.

Date queste capacità più potenti dell’attaccante, l’attacco può ora continuare. Tieni presente che l'aggressore sa dove appare il cookie di sessione crittografato nell'intestazione e controlla la lunghezza della richiesta HTTP che lo precede. Pertanto è in grado di manipolare la richiesta HTTP in modo che l'ultimo byte del cookie sia allineato con la fine del blocco. Ora questo byte è adatto per la decrittazione. Puoi semplicemente aggiungere un carattere alla richiesta e il penultimo byte del cookie rimarrà nello stesso posto e potrà essere selezionato utilizzando lo stesso metodo. L'attacco continua in questo modo finché il file cookie non viene completamente ripristinato. Si chiama POODLE: Padding Oracle on Downgraded Legacy Encryption.

ANNEGARE

Come abbiamo accennato, SSLv3 aveva i suoi difetti, ma era fondamentalmente diverso dal suo predecessore, poiché il traballante SSLv2 era un prodotto di un’era diversa. Lì potresti interrompere il messaggio a metà: соглашусь на это только через мой труп diventato соглашусь на это; il client e il server potrebbero incontrarsi online, stabilire un rapporto di fiducia e scambiarsi segreti davanti all'aggressore, che potrebbe quindi facilmente impersonare entrambi. C'è anche il problema con la crittografia di esportazione, di cui abbiamo parlato parlando di FREAK. Queste erano Sodoma e Gomorra crittografiche.

Nel marzo 2016 un team di ricercatori provenienti da diversi settori tecnici si è riunito e ha fatto una scoperta sorprendente: SSLv2 è ancora utilizzato nei sistemi di sicurezza. Sì, gli aggressori non potrebbero più eseguire il downgrade delle moderne sessioni TLS a SSLv2 poiché quel buco è stato chiuso dopo FREAK e POODLE, ma possono comunque connettersi ai server e avviare sessioni SSLv2 da soli.

Potresti chiedere, perché ci interessa cosa fanno lì? Hanno una sessione vulnerabile, ma non dovrebbe influire sulle altre sessioni o sulla sicurezza del server, giusto? Beh, non proprio. Sì, in teoria dovrebbe essere così. Ma no, perché la generazione di certificati SSL impone un certo onere, con il risultato che molti server utilizzano gli stessi certificati e, di conseguenza, le stesse chiavi RSA per le connessioni TLS e SSLv2. A peggiorare le cose, a causa di un bug OpenSSL, l'opzione "Disabilita SSLv2" in questa popolare implementazione SSL non funzionava.

Ciò ha reso possibile un attacco multiprotocollo a TLS, chiamato ANNEGARE (Decrittografia RSA con crittografia obsoleta e indebolita, decrittografia RSA con crittografia obsoleta e indebolita). Ricordiamo che questo non è la stessa cosa di un attacco breve; l'aggressore non ha bisogno di agire come un "uomo nel mezzo" e non ha bisogno di coinvolgere il client per partecipare ad una sessione non sicura. Gli aggressori avviano semplicemente una sessione SSLv2 non sicura con il server stesso, attaccano il protocollo debole e recuperano la chiave privata RSA del server. Questa chiave è valida anche per le connessioni TLS e, da questo momento in poi, nessuna misura di sicurezza TLS impedirà che venga compromessa.

Ma per risolverlo, è necessario un attacco funzionante contro SSLv2, che consenta di recuperare non solo traffico specifico, ma anche la chiave segreta del server RSA. Sebbene si tratti di una configurazione complessa, i ricercatori hanno potuto scegliere qualsiasi vulnerabilità che fosse stata completamente chiusa dopo SSLv2. Alla fine hanno trovato una soluzione adatta: l’attacco Bleichenbacher, di cui abbiamo parlato prima e che spiegheremo in dettaglio nel prossimo articolo. SSL e TLS sono protetti da questo attacco, ma alcune funzionalità casuali di SSL, combinate con chiavi brevi nella crittografia di livello esportazione, hanno reso possibile un'implementazione specifica di DROWN.

Al momento della pubblicazione, il 25% dei siti più importanti di Internet erano colpiti dalla vulnerabilità DROWN e l'attacco poteva essere effettuato con risorse modeste a disposizione anche di hacker solitari dispettosi. Il recupero della chiave RSA del server ha richiesto otto ore di calcolo e 440 dollari, e SSLv2 è passato da obsoleto a radioattivo.

Aspetta, che ne dici di Heartbleed?

Non si tratta di un attacco crittografico nel senso sopra descritto; Si tratta di un overflow del buffer.

Facciamo una pausa

Abbiamo iniziato con alcune tecniche di base: forza bruta, interpolazione, downgrading, protocollo incrociato e precalcolo. Successivamente abbiamo esaminato una tecnica avanzata, forse la componente principale dei moderni attacchi crittografici: l’attacco all’oracolo. Abbiamo impiegato un bel po' di tempo per capirlo e abbiamo compreso non solo il principio di base, ma anche i dettagli tecnici di due implementazioni specifiche: l'attacco Vaudenay alla modalità di crittografia CBC e l'attacco Kelsey ai protocolli di crittografia pre-compressione.

Nell'esaminare gli attacchi di downgrade e di precalcolo, abbiamo brevemente delineato l'attacco FREAK, che utilizza entrambi i metodi facendo eseguire il downgrade dei siti target a chiavi deboli e quindi riutilizzando le stesse chiavi. Per il prossimo articolo, salveremo l'attacco (molto simile) Logjam, che prende di mira gli algoritmi a chiave pubblica.

Abbiamo poi esaminato altri tre esempi di applicazione di questi principi. Innanzitutto, CRIME e POODLE: due attacchi che si basavano sulla capacità dell'attaccante di inserire testo in chiaro arbitrario accanto al testo in chiaro di destinazione, quindi esaminare le risposte del server e poi, utilizzando la metodologia di attacco Oracle, sfrutta queste sparse informazioni per recuperare parzialmente il testo in chiaro. CRIME ha seguito la strada dell'attacco di Kelsey alla compressione SSL, mentre POODLE ha invece utilizzato una variante dell'attacco di Vaudenay a CBC con lo stesso effetto.

Abbiamo poi rivolto la nostra attenzione all'attacco DROWN multiprotocollo, che stabilisce una connessione al server utilizzando il protocollo legacy SSLv2 e quindi recupera le chiavi segrete del server utilizzando l'attacco Bleichenbacher. Per ora abbiamo tralasciato i dettagli tecnici di questo attacco; come Logjam, dovrà aspettare finché non avremo una buona comprensione dei crittosistemi a chiave pubblica e delle loro vulnerabilità.

Nel prossimo articolo parleremo di attacchi avanzati come meet-in-the-middle, crittoanalisi differenziale e attacchi compleanno. Facciamo una breve incursione negli attacchi side-channel e poi passiamo alla parte divertente: i crittosistemi a chiave pubblica.

Fonte: habr.com