Scandalo PRISM: come sono stati intercettati i dati cifrati?

Sullo scandalo PRISM, che ha coinvolto milioni di cittadini statunitensi e non, si sono spesi fiumi di parole. Le rivelazioni di Edward Snowden, braccato dalle autorità d’Oltreoceano, hanno gettato un’ombra sulle attività della NSA, agenzia governativa per la sicurezza nazionale degli Stati Uniti, e sullo stesso governo Obama (USA: dati degli utenti spiati sui server dei provider?; Ecco chi ha portato alla luce il sistema di monitoraggio USA).

Stando a quanto riportato da fonti statunitensi che sarebbero “ben informate” sulla vicenda, la NSA avrebbe monitorato anche scambi di dati effettuati in forma cifrata. Si pensi ad esempio a tutte le comunicazioni che avvengono tra client e server (e viceversa) utilizzando il protocollo SSL/TLS. Il protocollo HTTPS (ossia HTTP con l’aggiunta del protocollo crittografico SSL/TLS), insieme con un certificato digitale valido, vengono comunemente usati da tutti i siti web che permettono la gestione di dati particolarmente importanti od informazioni sensibili (si pensi ai siti di e-commerce ed ai servizi online dei vari istituti di credito…).

Quando si utilizzano connessioni non sicure, facendo ricorso al solo HTTP – senza l’impiego di un protocollo di crittografia asimmetrica -, infatti, è molto facile, per un aggressore, carpire informazioni personali esaminando i dati in transito (attività di “sniffing“). Collegandosi, ad esempio, con una piattaforma ricchissima di dati personali qual è un social network utilizzando solo il protocollo HTTP, il “session cookie” creato sul proprio sistema a login effettuato viene scambiato con il server remoto per tutta la durata della sessione di lavoro. Tale cookie contiene importanti informazioni legate all’autenticazione sul sito web: qualora un malintenzionato riuscisse a mettere le mani sul contenuto del cookie, potrebbe immediatamente loggarsi sul servizio impersonificando l’altrui identità. Un’operazione del genere, sulle reti Wi-Fi pubbliche, è semplicissima da porre in essere: ecco perché l’adozione di HTTPS è divenuta un imperativo sempre più pressante (vedere anche HTTPS Everywhere invita ad usare connessioni “sicure”.

Le più recenti versioni dei vari browser web ben evidenziano quando si sta utilizzando una connessione HTTP e quando, invece, ci si è collegati ad una pagina web che fa uso del protocollo HTTPS. Sia Internet Explorer, sia Chrome, sia Firefox, ad esempio, espongono un lucchetto nella barra degli indirizzi insieme con l’indicazione https: ogniqualvolta si utilizzi una pagina che utilizza un certificato digitale e che quindi provvede a crittografare i dati cambiati tra client e server (e viceversa).

Abbiamo sempre detto che l’utilizzo della crittografia (HTTPS, quindi protocolli SSL/TLS) è di fondamentale importanza per garantire massima sicurezza durante le transazioni online. Come può, quindi, NSA essere risalita al contenuto delle conversazioni tra client e server avvenute in forma cifrata?

Se lo chiede Marco Giuliani, CEO della società italiana SaferBaytes, nella sua dettagliata analisi (vedere questo articolo). Egli solleva una domanda di grande interesse: “ci è dato sapere che tonnellate di dati siano state intercettate ed archiviate“, scrive riferendosi alla vicenda PRISM. “Se molti di questi dati sono crittografati poiché sono stati intercettati durante connessioni SSL, come può l’NSA riuscire ad analizzare tali dati?“.
Le risposte che Giuliani dà sono tre: “1) i provider hanno dato libero accesso all’NSA ai dati, ma per amor del buonsenso vogliamo ingenuamente mettere da parte tale opzione; 2) l’NSA è riuscita a fattorizzare le chiavi RSA a 1024 bit utilizzando tecnologie militari non accessibili ai comuni mortali; 3) qualcuno compiacente all’interno dei provider monitorati ha effettuato una copia della chiave RSA privata utilizzata nei server controllati, per poi lavarsene le mani e dire che essi stessi non hanno mai dato accesso ad alcun dato personale degli utenti (…)”.

Indipendentemente da ciò che può essere accaduto (siamo ancora nel campo delle semplici ipotesi), Giuliani spiega che a questo punto è indispensabile blindare ulteriormente l’algoritmo RSA. RSA, infatti, permette la generazione di due chiavi – una pubblica ed una privata – legate tra loro in maniera matematica tale che non sia possibile recuperare l’una partendo dall’altra. Esso “funge sia da protocollo di autenticazione (di garanzia, cioè, dell’identità dei due soggetti che entreranno in comunicazione) che da protocollo di scambio di chiavi“, ricorda l’esperto. “Nell’algoritmo RSA la chiave privata può essere ricavata dalla chiave pubblica applicando un procedimento matematico chiamato fattorizzazione, che consiste – semplificando di molto il concetto – nel trovare un insieme di numeri i quali permettano, partendo dalla chiave pubblica, di ritrovare la chiave privata“.
All’aumentare dei bit della lunghezza della chiave generata, aumenta in maniera esponenziale il tempo necessario per l’eventuale fattorizzazione. “Ad oggi le chiavi RSA considerate sicure sono quelle a 1024,2048,4096 bit. L’ultima lunghezza della chiave RSA che è caduta – è stata cioè fattorizzata – è stata quella a 768 bit, caduta nel 2009“, sottolinea Giuliani ricordando come molti siti web, oltre ai produttori di browser, inizino a considerare potenzialmente insicure le chiavi RSA a 1024 bit.
“L’umanità potrebbe avere adeguate risorse hardware per fattorizzare una chiave RSA 1024 entro circa 5 anni“, sostiene ancora Giuliani.

Sorge quindi la necessità non soltanto di adeguare la lunghezza delle chiavi crittografiche (Microsoft aveva recentemente messo al bando tutti i certificati digitali che utilizzano chiavi di lunghezza inferiore ai 1024 bit: Microsoft: al bando i certificati digitali sotto i 1.024 bit) ma anche di intervenire, sempre secondo il ricercatore italiano, sullo stesso algoritmo RSA.
RSA, infatti, non gode di una particolare proprietà (detta Perfect Forward Secrecy) relativamente al protocollo di scambio delle chiavi di sessione. “Ciò significa che, se si riuscisse a recuperare in qualche modo la chiave privata utilizzata nei server Outlook di Microsoft, o iCloud di Apple (ad esempio) allora tutto il traffico criptato – che nel frattempo è stato collezionato e salvato in enormi database – potrebbe come per magia essere decriptato in un batter di ciglia, per la gioia di NSA, CIA e affini“, afferma Giuliani che propone l’impiego, da parte di RSA, del noto algoritmo Diffie-Hellman nella iniziale fase di scambio reciproco delle chiavi crittografiche. Tale modus operandi, magari implementato nella forma più performante (Elliptic Curve Diffie Hellman, già utilizzata tra l’altro da Google; vedere questo confronto) offrirebbe un più elevato grado di sicurezza.

“La sicurezza di una trasmissione dati va analizzata da tutti i punti di vista, per cercare di garantire per quanto più possibile la propria privacy e la privacy dei propri utenti, per rendere il lavoro quanto più difficile a chi vuole entrare prepotentemente nella vita di tutti i cittadini del web. Escludendo ingenuamente, va ripetuto purtroppo, la possibilità che si fornisca volutamente una porta d’ingresso secondaria corrompendo qualcuno, strada molto più semplice, immediata e contro la quale non vi è tecnologia che regga“, conclude Giuliani.