“Infranti i protocolli di sicurezza usati da milioni di persone. Dal 2010 i servizi Usa e Gb possono leggere i dati cifrati. Allarme fra gli esperti della rete”, così recita oggi [un pezzo di Repubblica][1], cartaceo e Web, che vede anche un mio intervento.
Non si può chiedere di essere troppo tecnici e troppo circostanziati ad un [articolo introduttivo su Repubblica][1], soprattutto se si parla di crittografia, e il grando pregio [dell’articolo pubblicato oggi][1] su [Repubblica][1] è che apre un punto interrogativo ed uno spiraglio di informazione **sulla parte spesso taciuta dell’affaire NSA: quella degli attacchi crittografici**.
Per gli amanti della precisione tecnica e quelli che non possono sopravvivere senza avere tutti i termini giusti al posto giusto (oltre che ad avere nutrita documentazione sui signoli punti) ho creato un **addendum tecnico** alle brevi dichiarazioni mie presenti per ricapitolare la situazione. Vedetelo un po’ come [l’appendice Nerd all’articolo di oggi][1] :)
## Numeri “diversamente” casuali
Innanzitutti parliamo di numeri casuali. La prima parte delle speculazioni riguarda infatti un generatore di numeri casuali, per la precisione il Dual-EC_Drbg[^1] e il sospetto da parte di molti che il generatore causale alla cui creazione l’NSA ha partecipato attivamente, sia un po’ meno casuale di quanti si vorrebbe.
O meglio, in modo ancora più ingegnoso e difficilmente individuabile, parrebbe aver fatto sì che in talune situazioni i numeri casuali generati dal Dual-EC_Drbg[^1] non siano così casuali, consentendo di “predire” la chiave. Non è come “rompere” un algoritmo ma ci si avvicina di molto…
Se si accettano i documenti presentati di Snowden il disegno è molto chiaro:
> (…) internal memos leaked by a former N.S.A. contractor, Edward Snowden, suggest that the N.S.A. generated one of the random number generators used in a 2006 N.I.S.T. standard — called the Dual EC DRBG standard — **which contains a back door for the N.S.A.** In publishing the standard, N.I.S.T. acknowledged “contributions” from N.S.A., but not primary authorship.
> Internal N.S.A. memos describe how the agency subsequently **worked behind the scenes to push the same standard on the International Organization for Standardization.** “The road to developing this standard was smooth once the journey began,” one memo noted. “However, beginning the journey **was a challenge in finesse**.” (preso da [qui](http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/?src=twrhp&_r=1))
Attualmente lo standard Dual-EC_Drbg[^1] pare avere i giorni contati, visto che in un publis statement lo cita anche [il NIST](http://www.nist.gov/director/cybersecuritystatement-091013.cfm) stesso, fino ad arrivare ad un vero e proprio [sconsigliare in toto l’algoritmo](http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-90-A%20Rev%201%20B%20and%20C). Ed anche realtà commerciali estremamente rilevanti come RSA ne hanno [dichiarato la morte](http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/) sui loro prodotti.
E’ servito Snowden per la conferma ma che qualcosa [non andasse per il verso giusto](https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html) si sapeva già dal 2007. Senza grossi interventi. **(grazie Ale Okänd)**
Non si risolve, però, facilmente il problema del pregresso, perchè le appliance (il “ferro”) ed i sistemi operativi che lo usano ancora sono veramente tanti, nell’ordine delle centinaia di tipologie e milioni di installazioni, ed è un po’ più compleso preverede la sorte di tutti questi (o pensare tutte le macchine sparse per il mondo vengano aggiornate).
Se volete farvi venire la pelle d’oca e andare a letto terrorizzati, la lista completa è [online direttamente sul sito del NIST](http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html).
Personalmente vi consiglio di non farlo. Non concilia il sonno.
**UPDATE:** [Gabriele “asbesto” Zaverio](http://freaknet.org/asbesto/) *(peraltro lo conoscete vero il [Museo dell’Informatica Funzionante](http://museum.dyne.org/) di Palazzolo Acreide??)* mi suggerisce questo [bel thread su Reddit](http://www.reddit.com/r/linux/comments/1lucdy/did_linus_torvalds_backdoor_linux_random_number/) dal titolo emblematico di [“Did Linus Torvalds backdoor Linux random number generation?”](http://www.reddit.com/r/linux/comments/1lucdy/did_linus_torvalds_backdoor_linux_random_number/).
## Il problema di RC4
Il fronte di Dual-EC_Drbg[^2] non è, però, l’unico algoritmo crittografico da prendere in considerazione. Le voci, anche quelle sicuramente [più competenti in materia](http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying) parlano di un possibile attacco dell’NSA all’algoritmo [RC4][^2], utilizzato in circa il 50% delle connessioni SSL/TLS.
La cosa, peraltro, ache alla luce delle [recenti scoperte](https://www.schneier.com/blog/archives/2013/03/new_rc4_attack.html) di nuovi attacchi parrebbe anche possibile. [Schneier stesso](http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying), non prono certamente a prese di posizioni particolarmente complottiste, commenta il possibile attacco a NSA con una frase lapidaria:
> Someone somewhere commented that the NSA’s “groundbreaking cryptanalytic capabilities” could include a practical attack on RC4. I don’t know one way or the other, but that’s a good speculation.
Attacchi nuovi e vecchi che vanno, ovviamente, ad aggiungersi agli ormai ben noti [BEAST, CRIME, BREACH e Lucky-13](http://dcpp.wordpress.com/2013/09/20/beast-crime-breach-and-lucky-13-assessing-tls-in-adcs/), un trend che visti i budget in crittanalisi della NSA lasciano intendere uno scenario ben più che possibilista.
In questo caso il problema si complica, perchè effettivamente il numero di possibili obiettivi “sensibili” aumenta a dismisura. Pensate per un secondo se effettivamente il 50% dei servizi di VPN al mondo fossero decifrabili…
## I servizi compromessi tra cui VPN
Rimane il problema di fondo: QUALCOSA deve sicuramente esserci che attacca la crittofrafia a vari livelli, lo dicono direttamente i documenti [emersi dal GCHQ](http://www.theregister.co.uk/2013/09/05/nsa_gchq_ssl_reports) che parlano di “una vasta quantità di contenuti decifrabili”:
> “For the past decade, N.S.A. has led an aggressive, multipronged effort to break widely used Internet encryption technologies. … Cryptanalytic capabilities are now coming online. Vast amounts of encrypted Internet data which have up till now been discarded are now exploitable,” ([memo del 2010](http://www.theregister.co.uk/2013/09/05/nsa_gchq_ssl_reports))
Stessi argomenti di cui parlano peraltro [gli stessi documenti](http://www.theregister.co.uk/2013/09/05/nsa_gchq_ssl_reports) che citano come il GCHQ avesse “rotto” le chiavi per ottenere l’accesso ad almeno [30 fornitori di sistemi di VPN](http://www.theregister.co.uk/2013/09/05/nsa_gchq_ssl_reports) e di come questi fossero destinati **a salire a 300 prima del 2015**.
Ora è ben possibile che queste operazioni siano state compiute utilizzando manovre dirette di attacco al singolo gestore, magari attraverso la task force appositamente incaricata denominata [TAO (Tailored Access Operations)](http://www.foreignpolicy.com/articles/2013/06/10/inside_the_nsa_s_ultra_secret_china_hacking_group), ma personalmente penserei ad uno scenario misto in cui alcune vulnerabilità sono presenti “in the wild” e le operazioni speciali sono concentrate all’interno di una ristretta cerchia.
Lo pensa anche [Bruce Schneier stesso](https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html), se non volete credere alla mia ipotesi (e fate bene):
> The NSA deals with any encrypted data it encounters more by subverting the underlying cryptography than by leveraging any secret mathematical breakthroughs. First, there’s a lot of bad cryptography out there. If it finds an Internet connection protected by MS-CHAP, for example, that’s easy to break and recover the key. It exploits poorly chosen user passwords, using the same dictionary attacks hackers use in the unclassified world.
> (…) NSA also works with security product vendors to ensure that commercial encryption products are broken in secret ways that only it knows about. We know this has happened historically: CryptoAG and Lotus Notes are the most public examples, and there is evidence of a back door in Windows.
## Quindi siamo destinati a morire?
No, non ancora. Abbiamo piena evidenza del fatto che la NSA non è ancora in grado di decifrare la crittografia più forte, altrimenti non avrebbero dovuto, ad esempio, [chiedere le chiavi crittografiche al gestore di Lavabit](http://legalinsurrection.com/2013/11/lavabit-founder-i-had-effectively-lost-the-ability-to-control-my-own-network/) per intercettare le mail di Snowden.
La crittografia forte e open è (ancora) sicura, soprattutto se non commerciale ed opensource. Se volete saperne di più è online un [bellissimo articolo][2] sempre di Schneier sul [Guardian][2] dal titolo “[NSA surveillance: A guide to staying secure][2]” che si può riassumere in una serie di punti:
1. Nasconditi nella rete: usa Tor e gli Hidden services per essere meno ovvio e meno facilmente individuabile;
2. Cifra tutte le tue comunicazioni: usa TLS e IPsec (magari in implementazioni open che non usino Dual-EC_Drbg) in tutte le tue comunicazioni, perchè se è vero che l’NSA intercetta le comunicazioni cifrate, è anche vero che si aggiunge un layer di sicurezza che è enormemente maggiore che non mandare in chiaro!
3. Ricordati che il tuo terminale potrebbe essere compromesso. Ma che siccome la cosa richiede un attacco diretto, probabilmente non lo è. Se tratti contenuti veramente importanti, usa un computer mai connesso alla rete (e che non possa connettersi) e cifrato per qualunque operazione su contenuti cifrati
4. Abbi forti sospetti su qualcunque sistema di ciratura commerciale e non open, soprattutto se prodotto da grandi gruppi internazionali. Dice Scheier *”My guess is that most encryption products from large US companies have NSA-friendly back doors, and many foreign ones probably do as well. It’s prudent to assume that foreign products also have foreign-installed backdoors”*.
5. Cerca di usare cifrature di pubblico dominio e compatibili con gli standard. E’ più difficile, infatti, inserire backdoor in sistemi che devono essere compatibili con altri senza “rompere” qualcosa. Inoltre evitate, per ora, la crittografia a curve ellittiche, almeno sinchè non si capisce perchè l’NSA ha esplicitamente incitato ad usare [particolari costanti][3] per la creazione delle chiavi[^3]…
Certamente da notare come in effetti tramite un indebolimento degli algoritmi crittografici, l’NSA abbia a tutti gli effetti **indebolito l’intera essenza della rete**. Ed è questo, secondo me, il **più esecrabile dei crimini**, di molti ordini di magnitudo peggiore della raccolta di informazioni. Se le informazioni, infatti, sono appannaggio esclusivo della NSA, **le porte ora lasciate aperte sono varcabili da una pluralità di soggetti**.
Per il resto, come al solito, e stavolta più che mai… **Estote Parati**!
Per maggiori info:
* L'[articolo completo][1]
* L'[articolo di Schneier][2]
[^1]: Dual Elliptic Curve Deterministic Random Bit Generator, vedi [la voce di Wikipedia](https://en.wikipedia.org/wiki/Dual_EC_DRBG) per approfondimenti;
[^2]: Conosciuto anche come ARCFOUR è utilizzato praticamente ovunque, da WEP a WPA fino a TLS, vedi [la vode di Wikipedia](https://en.wikipedia.org/wiki/RC4) per approfondimenti;
[^3]: Per le problematiche legate alle curve ellittiche consiglio [Security dangers of the NIST curves di Daniel J. Bernstein e Tanja Lange](http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4×3.pdf) **(grazie Ale Okänd)**.
[2]: http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
[3]: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4×3.pdf
[1]: http://www.repubblica.it/tecnologia/2013/11/03/news/violate_le_chiavi_pi_segrete_del_web_controlli_su_conti_correnti_e_transazioni-70121962/
