Poche settimane fa ho scritto un lungo post sul progetto “BULLRUN” della NSA per sovvertire i moderni standard di crittografia. Avevo intenzione di tornare su questo ad un certo punto, dal momento che non ho avuto il tempo di discutere i problemi in dettaglio. Ma poi le cose si sono messe in mezzo. Un sacco di cose, in realta’. Alcuni dei quali spero di scrivere in un prossimo futuro.

Ma prima di arrivarci, e con il rischio di annoiarvi tutti fino alle lacrime, ho voluto tornare su questo argomento almeno un’altra volta, se non altro per pontificare un po ‘ su una domanda che mi ha infastidito.

Vedete, la NSA BULLRUN briefing sheet menziona che la NSA ha infranto alcune tecnologie di crittografia, alcune delle quali sono più interessanti di altre. Una di queste tecnologie è particolarmente sorprendente per me, dal momento che non riesco a capire come la NSA potrebbe farlo. In questo post estremamente lungo cercherò di scavare un po ‘ più a fondo nella domanda più importante di Internet oggi.

In particolare: come diavolo sta rompendo SSL NSA?

Sezione del foglio informativo BULLRUN. Fonte: New York Times.

Per mantenere le cose sul bersaglio ho intenzione di fare alcune regole di base di base.

Innanzitutto, sono ben consapevole che NSA può installare malware sul tuo computer e pwn qualsiasi crittografia tu scelga. Questo non mi interessa affatto, per la semplice ragione che non scala bene. L’NSA puo ‘farti questo, ma non puo’ farlo per un’intera popolazione. E questo è davvero ciò che mi preoccupa delle recenti fughe di notizie: la possibilità che la NSA stia rompendo la crittografia ai fini della sorveglianza di massa.

Per lo stesso motivo, non ci preoccuperemo degli attacchi man-in-the-middle (MITM). Mentre sappiamo che l’NSA li gestisce, sono anche un attacco molto mirato. Non solo i MITM sono rilevabili se li fai su larga scala, non si comportano con ciò che sappiamo su come la NSA fa intercettazioni su larga scala, per lo più tramite splitter e rubinetti. In altre parole: siamo molto preoccupati per la sorveglianza passiva.

Le regole di cui sopra non sono assolute, ovviamente. Prenderemo in considerazione attacchi mirati limitati ai server, a condizione che in seguito consentano la decrittografia passiva di grandi quantità di traffico; ad esempio, la decrittografia del traffico verso i principali siti web. Prenderemo in considerazione anche modifiche arbitrarie a software e hardware – qualcosa che sappiamo NSA sta già facendo.

Un ultimo punto: per evitare che le cose vadano fuori dai binari, ho utilmente diviso questo post in due sezioni. Il primo riguarderà gli attacchi che utilizzano solo tecniche conosciute. Tutto in questa sezione può essere implementato da un dipendente TAO con sufficiente gumption e l’accesso al software. La seconda sezione, che ho intitolato il ‘Tinfoil Hat Spectrum’ copre le cose divertenti e speculative-che vanno dai nuovi attacchi di canale laterale fino a quell’enorme computer quantistico che la NSA tiene accanto a BWI.

Inizieremo con il ‘pratico’.

Attacchi che utilizzano tecniche note

Furto di chiavi RSA. Il modo più ovvio per “crack” SSL non comporta realmente il cracking di nulla. Perché perdere tempo e denaro in crittanalisi quando puoi semplicemente rubare le chiavi? Questo problema è particolarmente preoccupante nei server configurati per l’handshake TLS RSA, in cui una singola chiave server da 128 byte è tutto ciò che serve per decifrare ogni connessione passata e futura effettuata dal dispositivo.

In effetti, questa tecnica è così ovvia che è difficile immaginare che la NSA spenda molte risorse su sofisticati attacchi crittanalitici. Sappiamo che GCHQ e NSA sono perfettamente comodi suborning anche fornitori statunitensi all’estero. E all’interno dei nostri confini, hanno dimostrato la volontà di ottenere chiavi TLS/SSL usando poteri di citazione e ordini di gag. Se si utilizza una connessione RSA a un sito Web importante, potrebbe essere ragionevole supporre che la chiave sia già nota.

Naturalmente, anche dove la NSA non ricorre a misure dirette, c’è sempre la possibilità di ottenere chiavi tramite un exploit software remoto. Il bello è che questi attacchi non richiedono nemmeno l’esecuzione di codice remoto. Data la vulnerabilità giusta, potrebbe semplicemente richiedere una manciata di richieste SSL malformate per mappare l’intero contenuto dell’heap OpenSSL/SChannel.

Fonte: New York Times

Chip di crittografia hardware suborning. Una frazione significativa del traffico SSL su Internet è prodotta da dispositivi hardware come terminatori SSL e router abilitati VPN. Fortunatamente non dobbiamo speculare sulla sicurezza di questi dispositivi — sappiamo già che NSA/GCHQ ha collaborato con i produttori di hardware per “abilitare” la decrittografia su diversi importanti chip di crittografia VPN.

I documenti NSA non sono chiari su come funziona questa funzionalità o se coinvolge anche SSL. Se lo fa, l’ipotesi ovvia è che ogni chip crittografa ed exflitrates bit della chiave di sessione tramite campi “casuali” come IVs e handshake nonces. In effetti, questo è relativamente facile da implementare su un dispositivo hardware opaco. La domanda interessante è come si assicura che queste backdoor possano essere sfruttate solo dalla NSA-e non dalle agenzie di intelligence rivali. (Alcuni pensieri su questo qui.)

Attacchi a canale laterale. Tradizionalmente quando analizziamo algoritmi crittografici ci preoccupiamo degli input e degli output attesi del sistema. Ma i sistemi reali perdono tutti i tipi di informazioni extra. Questi “canali laterali”, che includono il tempo di funzionamento, il consumo di risorse, i tempi di cache e le emissioni RF, possono spesso essere utilizzati per estrarre materiale chiave segreta.

La buona notizia è che la maggior parte di questi canali sono sfruttabili solo quando l’attaccante si trova in prossimità fisica di un server TLS. La cattiva notizia è che ci sono condizioni in cui l’attaccante può avvicinarsi. L’esempio più ovvio riguarda i server TLS virtualizzati nell’impostazione cloud, in cui un malintenzionato intelligente può condividere risorse fisiche con il dispositivo di destinazione.

Una seconda classe di attacco utilizza le informazioni di temporizzazione remota per recuperare lentamente una chiave RSA. Questi attacchi possono essere disabilitati tramite contromisure come RSA accecante, anche se in modo divertente, alcuni co-processori hardware ‘sicuri’ possono effettivamente disattivare queste contromisure per impostazione predefinita! Per lo meno, questo rende l’hardware vulnerabile agli attacchi di un utente locale, e potrebbe anche facilitare il recupero remoto delle chiavi RSA.

Generatori di numeri casuali deboli. Anche se si utilizzano forti cifrari Perfect Forward Secrecy, la sicurezza di TLS dipende fondamentalmente dalla disponibilità di numeri casuali imprevedibili. Non a caso, la manomissione degli standard del generatore di numeri casuali sembra essere stata una particolare attenzione degli sforzi della NSA.

I numeri casuali sono fondamentali per un certo numero di elementi in TLS, ma sono particolarmente importanti in tre punti:

1. Sul lato client, durante la stretta di mano RSA. L’RNG viene utilizzato per generare il segreto pre-master RSA e il padding di crittografia. Se l’attaccante può prevedere l’output di questo generatore, può successivamente decifrare l’intera sessione. Ironia della sorte, un guasto del server RNG è molto meno devastante per la stretta di mano RSA.*
2. Sul lato client o server, durante le strette di mano Diffie-Hellman. Poiché Diffie-Hellman richiede un contributo da ciascun lato della connessione, un RNG prevedibile su entrambi i lati rende la sessione completamente trasparente.
3. Durante la generazione di chiavi a lungo termine, in particolare di chiavi RSA. Se succede, sei fottuto.

E non ho nemmeno menzionato i piani di Intel per sostituire il kernel Linux RNG con il proprio hardware RNG.

Debolezze esoteriche nei sistemi PFS. Molti server web, tra cui Google e Facebook, ora utilizzano Perfect Forward Secrecy ciphersuites come effimero Diffie-Hellman (DHE e ECDHE). In teoria questi cifrari forniscono il meglio di tutti i mondi possibili: le chiavi persistono per una sessione e poi scompaiono una volta terminata la connessione. Anche se questo non ti salva dai problemi RNG, rende il furto di chiavi molto più difficile.

I cifrari PFS sono una buona cosa, ma una varietà di problemi sottili può ostacolare il loro stile. Per prima cosa, il meccanismo di ripresa della sessione può essere schizzinoso: le chiavi di sessione devono essere memorizzate localmente o crittografate e distribuite agli utenti sotto forma di ticket di sessione. Sfortunatamente, l’uso dei ticket di sessione diminuisce in qualche modo la “perfezione” dei sistemi PFS, poiché le chiavi utilizzate per crittografare i ticket rappresentano ora una delle principali debolezze del sistema. Inoltre, non puoi nemmeno tenerli interni a un server, dal momento che devono essere condivisi tra tutti i server front-end di un sito! In breve, sembrano una specie di incubo.

Un’ultima area di preoccupazione è la convalida dei parametri Diffie-Hellman. L’attuale design SSL presuppone che i gruppi DH siano sempre generati onestamente dal server. Ma un’implementazione dannosa può violare questa ipotesi e utilizzare parametri errati, che consentono l’intercettazione di terze parti. Questo sembra un viale piuttosto improbabile per consentire la sorveglianza, ma va a mostrare quanto siano delicati questi sistemi.

The Tinfoil Hat Spectrum

Ho intenzione di fare riferimento al prossimo gruppo di attacchi come vulnerabilità ‘tinfoil hat’. Laddove i problemi precedenti sfruttano tutte le tecniche ben note, ciascuna delle seguenti proposte richiede tecniche crittanalitiche totalmente nuove. Tutto ciò è un modo per dire che la seguente sezione è pura speculazione. È divertente speculare, ovviamente. Ma ci impone di assumere fatti non in prova. Inoltre, dobbiamo stare un po ‘ attenti a dove ci fermiamo.

Quindi da qui in avanti stiamo essenzialmente conducendo un esperimento mentale. Immaginiamo che la NSA abbia una capacità passiva di interruzione SSL; e inoltre, che non si basi sui trucchi della sezione precedente. Cosa resta?

Il seguente elenco inizia con le teorie più “probabili” e lavora verso il vero pazzo.

Rottura delle chiavi RSA. C’è una voce persistente nel nostro campo che la NSA sta rompendo le chiavi RSA a 1024 bit. E ‘ dubbio che questa voce deriva da qualsiasi reale conoscenza delle operazioni della NSA. Più probabilmente è guidato dal fatto che il cracking delle chiavi a 1024 bit è altamente fattibile per un’organizzazione con risorse della NSA.

Quanto è fattibile? Diversi ricercatori credibili hanno tentato di rispondere a questa domanda, e si scopre che il costo è inferiore a quanto si pensi. Nel lontano 2003, Shamir e Tromer stimarono million 10 milioni per una macchina appositamente costruita che poteva calcolare una chiave a 1024 bit all’anno. Nel 2013, Tromer ridotto quei numeri a circa $1 milione, factoring in progressi hardware. E potrebbe essere significativamente più basso. Questo è il cambiamento tasca per NSA.

Lungo linee simili, Bernstein, Heninger e Lange hanno esaminato la fattibilità di cracking RSA utilizzando reti distribuite di PC standard. I loro risultati sono piuttosto inquietante: in linea di principio, un cluster circa le dimensioni della botnet Conficker vita reale potrebbe fare violenza grave a chiavi a 1024 bit.

Dato tutto questo, si potrebbe chiedere perché questa possibilità è anche nella categoria ‘tinfoil hat’. La risposta semplice è: perché nessuno l’ha effettivamente fatto. Ciò significa che è almeno concepibile che le stime di cui sopra siano drammaticamente troppo alte o addirittura troppo basse. Inoltre, le chiavi RSA-1024 vengono rapidamente eliminate. Cracking chiavi a 2048 bit richiederebbe significativi progressi matematici, portandoci molto più in profondità nel cappello di carta stagnola.**

Cracking RC4. Sulla carta, TLS supporta una varietà di algoritmi di crittografia forti. In pratica, circa la metà di tutto il traffico TLS è protetto con il vecchio codice RC4 scricchiolante. E questo dovrebbe preoccuparti-perché RC4 sta iniziando a mostrare la sua età. In effetti, come usato in TLS è già vulnerabile agli attacchi pratici (borderline). Quindi sembra un bel candidato per un vero progresso crittanalitico da parte della NSA.

Sfortunatamente il problema con questa teoria è che semplicemente non sappiamo di alcun attacco che permetterebbe alla NSA di decifrare utilmente RC4! Le tecniche conosciute richiedono che un utente malintenzionato raccolga migliaia o milioni di testi cifrati (a) crittografati con chiavi correlate (come in WEP) o (b) contengano lo stesso testo in chiaro. L’attacco più noto contro TLS assume quest’ultima forma: richiede alla vittima di stabilire miliardi di sessioni e anche in questo caso recupera solo elementi di testo in chiaro fissi come cookie o password.

Il controargomento è che la comunità di ricerca pubblica non ha pensato molto a RC4 negli ultimi dieci anni — in parte perché pensavamo che fosse così rotto che le persone avevano smesso di usarlo (oops! Se avessimo concentrato tutta la nostra attenzione su di esso (o meglio, l’attenzione della NSA), chissà cosa avremmo oggi.

Se mi dicessi che la NSA aveva una capacità crittanalitica veramente nuova, sarei d’accordo con Jake e punterei il dito su RC4. Soprattutto perché le alternative sono molto più spaventose.

Nuovi attacchi a canale laterale. Per la maggior parte, gli attacchi di temporizzazione remota sembrano essere stati uccisi dall’implementazione di contromisure come l’accecamento RSA, che confondono i tempi moltiplicando un fattore di accecamento casuale in ogni testo cifrato prima della decrittografia. In teoria questo dovrebbe rendere le informazioni di temporizzazione essenzialmente inutili. In pratica, molte implementazioni TLS implementano compromessi nel codice accecante che potrebbero resuscitare questi attacchi, cose come la quadratura di un fattore accecante tra le operazioni di decrittografia, piuttosto che generarne uno nuovo ogni volta. È abbastanza improbabile che ci siano attacchi qui, ma chi lo sa.

Roba Goofy. Forse NSA ha qualcosa di veramente sorprendente nella manica. Il problema con l’apertura di questo vaso di Pandora è che è davvero difficile farlo chiudere di nuovo. Jerry Solinas ha davvero cucinato le P-curve del NIST per supportare un nuovo incredibile attacco (che la NSA conosceva nel lontano 1990, ma non l’abbiamo ancora scoperto)? La NSA ha un supercomputer gigante chiamato TRANSLTR che può forzare brute qualsiasi criptosistema? C’è un gigantesco computer quantistico nell’allegato dell’amicizia della BWI? Per le risposte a queste domande si può anche solo scuotere la magia 8-Ball, perché non ho la minima idea.

Conclusione

Non sappiamo e non possiamo conoscere la risposta a queste cose, e onestamente ti farà impazzire se inizi a pensarci. Tutto quello che possiamo davvero fare è prendere NSA / GCHQ in parola quando ci dicono che queste capacità sono “estremamente fragili”. Questo dovrebbe almeno darci speranza.

La domanda ora è se possiamo indovinare abbastanza bene da trasformare quella fragilità da un avvertimento in una promessa.
Note:

* Un errore del server RNG potrebbe causare alcuni valori prevedibili come il ServerRandom e gli ID di sessione. Un utente malintenzionato in grado di prevedere questi valori potrebbe essere in grado di eseguire attacchi attivi contro il protocollo, ma — almeno nella RSA ciphersuite — non ammette compromessi passivi.

* * Anche se le chiavi RSA a 1024 bit vengono eliminate, molti server usano ancora 1024 bit per Diffie-Hellman (principalmente per motivi di efficienza). Gli attacchi a queste chiavi sono simili a quelli usati contro RSA — tuttavia, la differenza principale è che le nuove chiavi “effimere” di Diffie-Hellman vengono generate per ogni nuova connessione. Rompere grandi quantità di traffico sembra piuttosto costoso.