Il continuo susseguirsi di notizie sul caso Swoden, il giovane 30enne ex dipendente dell’NSA – i servizi segreti americani – sta alzando un polverone diplomatico che ben da vicino ricorda quello della Guerra Fredda che il mondo intero ha vissuto con tanta ansia decadi or sono.
Le rivelazioni che l’ex agente segreto ha pubblicato online, dopo essersi rapidamente allontanato dalla terra natìa, stanno portando alla luce quello che molti definirebbero il segreto di Pulcinella, che pure Orwell nel libro 1984, una delle sue opere più famose, descrive attentamente seppur con un pizzico di fantasia: i governi controllano il mondo intero, comunicazioni, informazioni, transazioni, telefonate, qualsiasi cosa sia incanalata nei moderni sistemi di comunicazione di massa. In particolar modo, un governo specifico sembra essersi preso la briga di controllare un po tutto il mondo, giusto per non far torto a nessuno. Sembra scontato sottolineare quale sia tale governo, ma per i meno attenti si tratta degli Stati Uniti d’America.
E così, dopo Echelon, viene fuori il progetto PRISM, con il quale i servizi segreti americani avrebbero intercettato una mole di dati tale da profilare mezzo globo terrestre, persone comuni che utilizzano quotidianamente Internet per le proprie comunicazioni, sia personali che lavorative. Per questioni di sicurezza nazionale, ovviamente, ma intanto quantità industriali di dati personali sono archiviate nei database dell’NSA, in coda per essere analizzati, controllati e incrociati con informazioni di sicurezza al fine di individuare folli terroristi, criminalità organizzata, ma anche eventuali assassini della porta accanto – senza disdegnare però la possibilità di indagare se il proprio partner abbia un amante.
Sorvolando sulle questioni etiche e legali, quello che più interessa è porre dunque l’accento sulla sicurezza delle trasmissioni che ogni giorno milioni di persone effettuano tramite i propri dispositivi connessi ad Internet.
Ammesso e non concesso che Google, Microsoft, Facebook, Yahoo, Apple e amici intimi non abbiano realmente fornito, in gran segreto, una porta di accesso secondaria ai “guardoni” per poter intercettare i dati che i propri utenti si scambiano ogni minuto, la questione si sposta sulla attuale configurazione di sicurezza delle trasmissioni online, in particolare sul protocollo SSL/TLS.
Stando alle poche informazioni che ci sono date sapere, l’NSA avrebbe fatto una sorta di copia 1:1 di tutti i dati che transitano nel web, principalmente da quei giganti sopra elencati. Partendo da qui si può cominciare una riflessione su come sia stato possibile intercettare e decodificare tali dati trasmessi online.
La questione principale è che molte trasmissioni di dati online vengono effettuate in chiaro, in plain-text: dai semplici forum/board di discussione, a protocolli di posta elettronica SMTP/POP3/IMAP, alle vecchie chat di Messenger, a siti di e-commerce sviluppati dai cosiddetti programmatori della domenica. Molte informazioni vengono ancora trasmesse online senza l’utilizzo di adeguati sistemi di crittografia che oggi dovrebbero essere lo standard assoluto, quasi un obbligo.
Queste informazioni possono essere facilmente intercettate, basta configurare un analizzatore di rete in qualsiasi punto della rete, tra l’utente e il web server di destinazione. Una qualsiasi compagnia telefonica a scelta potrebbe fare al caso nostro, pardon, dell’NSA.
Poi ci sono le connessioni crittografate, quelle che le banche ci fanno gentilmente notare con la postilla “Controlla la presenza di un lucchetto sulla barra dell’indirizzo www.banca.xxx”.
L’utilizzo della tecnologia SSL/TLS per le trasmissioni di dati online dovrebbe garantire all’utente una connessione criptata e sicura end-to-end, cioè che i dati possano essere visualizzati solo dall’utente che li invia e dal server che li riceve, facendoli passare attraverso un canale criptato che nessuno nel mezzo dovrebbe essere in grado di intercettare.
Per comprendere meglio questo concetto bisogna fare un piccolo passo tecnico indietro e capire come funziona, in maniera breve ed essenziale, il protocollo SSL/TLS – non è nostro interesse andare a discutere in maniera tecnica ed approfondita i modelli matematici che permettono l’applicazione pratica di tali colonne portanti della crittografia.
La crittografia asimmetrica è una delle tecnologie fondamentali delle trasmissioni SSL/TLS, poiché permette a due entità totalmente sconosciute tra di loro di poter scambiare informazioni in maniera sicura, garantendo autenticità e la possibilità di stabilire un tunnel criptato allo stesso tempo.
L’applicazione senza ombra di dubbio più conosciuta di crittografia asimmetrica è l’algoritmo RSA, il quale 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.
Il protocollo RSA 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.
Nel momento in cui ci si connette ad un sito web protetto con tecnologia SSL/TLS, prima di cominciare a scambiarsi dati, il server ed il client effettuano le seguenti operazioni:
-
Il server contiene la propria chiave privata e invia al client che si sta connettendo la relativa chiave pubblica;
-
Il client genera casualmente una chiave di sessione e la cripta con la chiave pubblica del server;
-
Il client invia la chiave di sessione crittografata al server;
-
Il server decodifica il pacchetto, crittografato con la chiave pubblica, utilizzando la sua chiave privata (che lui, e solo lui deve avere)
Da questo momento sia il client che il server condividono una stessa chiave di sessione e possono stabilire un tunnel crittografato con algoritmi di crittografia simmetrica, quali RC4, 3DES, AES (tra i più utilizzati).
Bisogna tuttavia fare un distinguo, cioè specificare bene quando viene detto che non è possibile recuperare la coppia di chiavi partendo da una delle due chiavi.
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.
Per poter effettuare tale procedura contro le chiavi RSA sono necessarie risorse hardware inimmaginabili per le attuali tecnologie, questo perché 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.
La situazione attuale vede molti siti web utilizzare chiavi RSA a 1024 bit, una situazione che – sebbene sia accettata come scelta sicura – comincia a scricchiolare. Questo perché, secondo previsioni puramente teoriche, l’umanità potrebbe avere adeguate risorse hardware per fattorizzare una chiave RSA 1024 entro circa 5 anni.
Questo cosa significa in parole povere? Che chiunque riesca ad intercettare ed archiviare trasmissioni crittografate, potrebbe avere a breve le risorse necessarie per poter decodificare la chiave di sessione – che, ricordiamo, viene solitamente scambiata tra il client ed il server attraverso l’utilizzo della coppia di chiavi pubblica-privata. Avendo accesso a tale informazione, l’eventuale interessato potrebbe tranquillamente decodificare poi tutto il traffico generato tra client e server tramite la crittografia simmetrica.
E non importa quale sessione sia, se siano più sessioni, una volta che l’eventuale guardone è riuscito a recuperare la chiave RSA privata di quel server, può decodificare qualsiasi scambio delle chiavi di sessione, e di conseguenza qualsiasi traffico dati.
I punti deboli della crittografia asimmetrica RSA, se utilizzata non solo come protocollo di autenticazione ma anche come protocollo di scambio delle chiavi per stabilire il tunnel criptato, sono essenzialmente due:
-
Fattorizzazione della chiave RSA
-
Compromissione della chiave RSA privata
Fatto questo lungo preambolo è possibile tornare al caso PRISM per fare le dovute considerazioni.
Ci è dato sapere che tonnellate di dati siano state intercettate ed archiviate. Se molti di questi dati sono crittografati poiché sono stati intercettati durante connessioni SSL, come può l’NSA riuscire ad analizzare tali dati? Le potenziali risposte sono tre:
-
I provider hanno dato libero accesso all’NSA ai dati, ma per amor del buonsenso vogliamo ingenuamente mettere da parte tale opzione
-
L’NSA è riuscita a fattorizzare le chiavi RSA a 1024 bit utilizzando tecnologie militari non accessibili ai comuni mortali
-
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, è l’NSA che è riuscita dall’esterno ad intercettare i dati
Il punto focale della discussione è che l’RSA, utilizzato come protocollo di scambio delle chiavi e non solo di autenticazione, soffre di un punto debole non irrilevante: la chiave privata. Recuperando la chiave privata è possibile infatti decodificare a catena le chiavi di sessioni scambiate tra server e client e, infine, il traffico dati.
E a quel punto non importa quasi più il processo di fattorizzazione, perché basterebbe smettere di utilizzare le chiavi RSA 1024 e sostituirle con chiavi RSA a 2048 bit per allontanare lo spettro che qualcuno riesca in tempi ragionevoli a fattorizzare tale chiave. Cosa che, d’altronde, molte Certification Autorithy e browser stanno già facendo, decidendo di smettere di rilasciare ed accettare certificati RSA a 1024 bit e rilasciando come standard esclusivamente certificati RSA a partire da 2048 bit.
La cosa veramente critica è piuttosto il far dipendere da una chiave privata, che è statica, la generazione delle chiavi di sessioni – il tanto temuto “Single Point of Failure”.
Questo perché l’algoritmo RSA, utilizzato come meccanismo di scambio delle chiavi, non gode della proprietà del Perfect Forward Secrecy (o PFS), una proprietà dei protocolli di scambio delle chiavi che prevede che una chiave di sessione, derivata da una coppia di chiavi segrete (ad esempio pubblica-privata), non venga compromessa se una delle due chiavi segrete venisse invece compromessa in futuro.
La cosa interessante è che la quasi totalità del traffico Internet che si basa su crittografia SSL/TLS utilizza l’algoritmo RSA sia come autenticazione dei soggetti sia come 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.
Sorge quasi da sé allora la domanda: se l’RSA soffre di questa debolezza come protocollo di scambio delle chiavi, non esistono altri protocolli che possano ricoprire lo stesso ruolo ma che abbiano anche la proprietà del Perfect Forward Secrecy?
Assolutamente sì, esistono. Il protocollo per lo scambio delle chiavi Diffie-Hellman ne è il più grande esempio. Basandosi sull’operazione del logaritmo discreto, il protocollo DH permette a due entità, che non si sono mai incontrate né scambiate dati, di generare automaticamente una coppia di chiavi temporanea, le quali permetteranno di derivare una chiave di sessione, con la quale poi stabilire un tunnel crittografato tramite crittografia simmetrica (RC4, AES, 3DES e simili).
La cosa interessante di questo protocollo è che, una volta derivata la chiave di sessione, le due chiavi utilizzate per la generazione di tale chiave vengono cancellate a fine sessione, ottenendo il tanto ambito PFS.
In altre parole, anche riuscendo a recuperare in qualche modo la coppia di chiavi, un eventuale attaccante potrebbe solo recuperare la chiave di sessione di quella specifica sessione, contrariamente ad un attacco RSA dove, se si riuscisse a recuperare la chiave privata, allora si potrebbe avere accesso a tutte le chiavi di sessioni generate all’inizio delle sessioni stesse. Una bella differenza che metterebbe in difficoltà anche i servizi segreti, i quali non potrebbero fattorizzare in tempi utili le chiavi utilizzate e, allo stesso tempo, non potrebbero corrompere nessuno per recuperare la chiave privata RSA installata nei server, perché sarebbe un tentativo inutile.
Il protocollo DH, tuttavia, è meno performante del protocollo RSA per lo scambio delle chiavi e questo impatta in maniera significativa le performance dei server che vogliono implementarlo. Viene per questo in aiuto l’utilizzo della crittografia a curva ellittica (ECC) la quale, grazie a specifici modelli matematici, permette di utilizzare chiavi a minor lunghezza di bit ma resistenti tanto quanto le chiavi RSA – basti pensare che una chiave ECC a 160 bit equivale in termini di sicurezza ad una chiave RSA a 1024 bit, una chiave ECC a 224 bit equivale ad una RSA a 2048 bit e così via. Tale protocollo è conosciuto con la siglia di ECDH, o Elliptic Curve Diffie Hellman.
Ad oggi sono pochi i server che utilizzano tale protocollo di scambio delle chiavi, preferendo a quest’ultimo, per la maggior parte, l’utilizzo di RSA sia come protocollo di autenticazione che di scambio chiavi. Questo per una serie di motivi: principalmente perché RSA è noto da molto tempo, è ben testato e solido, ha delle performance ottimali e non tutti i browser e web server fino a poco tempo fa supportavano il protocollo ECDH. Solo recentemente alcuni provider hanno cominciato a convertirsi all’ECDH per lo scambio delle chiavi.
Un esempio recentissimo è Google, il quale ha da poco iniziato ad utilizzare il protocollo ECDH per lo scambio delle chiavi, garantendo dunque che, anche se qualcuno potesse recuperare la chiave privata RSA, non avrebbe comunque modo di decodificare automaticamente tutte le sessioni web sniffate e archiviate.
Il problema delle trasmissioni dati su Internet, la loro sicurezza e confidenzialità, sono argomenti più che mai attuali. E non si tratta più solo di un problema di utilizzare SSL o meno, o di utilizzare certificati RSA a 1024 bit o superiori per evitare attacchi di fattorizzazione. Si tratta di cercare di prevenire tutti i possibili punti deboli della catena, eventuale furto di certificati incluso.
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.
