Mi è capitato di leggere un articolo di un noto sito internet italiano dedicato alla tecnologia in cui si parla delle “chiavi digitali crittografiche” utilizzate in Italia e all’estero, le chiavi alla base dei famosi certificati SSL che dovrebbero garantire la sicurezza delle transazioni online.

Nell’articolo viene detto come in Italia le istituzioni utilizzino ancora chiavi crittgrafiche RSA 128/1024 bit quando in tutto il mondo si sono già aggiornati ad utilizzare le più recenti e sicure tecnologie a 256/2048 bit. Viene inoltre spiegato come per la Posta Elettronica Certificata vengano utilizzate chiavi a 128 bit, definendola una protezione inadeguata poiché in rete circolano già miriadi di istruzioni per violare le difese a 128 bit.

Premetto di non essere un esperto di crittografia e crittoanalisi. Detto ciò mi sembra che l’articolo, le cui idee in linea generale sono valide, faccia però nella pratica molta confusione, dipingendo una verità che non corrisponde esattamente alla realtà.

Tracciamo, molto semplicemente – non me ne vogliano gli esperti del settore, come viene stabilita una sessione crittografata durante una connessione web.

Nel momento in cui un client si connette al server è necessario stabilire una password condivisa da entrambi per poter iniziare la connessione crittografata. Per fare ciò entra in gioco la crittografia asimmetrica. Il server, che possiede una coppia di chiavi, invia al client la propria chiave pubblica e tiene segreta la propria chiave privata. Il client, ricevuta la chiave pubblica, genera la chiave precondivisa che verrà utilizzata per la connessione e la cripta con la chiave pubblica del server. Il server riceve il dato e lo decripta con la propria chiave privata. Da questo momento sia server che client hanno la stessa password e possono stabilire una connessione criptata con un algoritmo di crittografia simmetrica – solitamente AES, 3DES o RC4.

Cominciamo a distinguere dunque le due fasi, la comunicazione della chiave precondivisa generata dal client e l’inizio della comunicazione vera e propria.

Nella prima fase viene utilizzato un algoritmo di crittografia asimmetrica, denominato RSA. Grazie a questo algoritmo è possibile generare una coppia di chiavi legate matematicamente tra di loro, tali che un qualsiasi dato criptato con una delle due chiavi può essere decriptato dall’altra chiave.

La coppia di chiavi generata è solitamente nell’ordine dei 1024, 2048 o 4096 bit, cioè rispettivamente 128,256,512 byte. Lo standard attuale nei certificati SSL è 2048 bit, sebbene sino ad oggi siano stati utilizzati – e ancora lo sono – certificati a 1024 bit.

La seconda fase vede lo stabilirsi di una connessione criptata per mezzo di un sistema di crittografia simmetrica quale può essere AES, 3DES o RC4, con uno stream nell’ordine di 128, 168 o 256 bit.

Fatto questo breve – molto striminzito e impreciso – preambolo, è possibile passare ad analizzare il contenuto dell’articolo in questione.

Si parla inizialmente di un sistema che vede l’Italia arretrata, con un utilizzo di chiavi a 128/1024 bit, e fin qui ci può anche stare. A cosa si riferisce quel 128? Alla dimensione in byte della chiave? A meno che nell’articolo non lo voglia riferire allo stream di dati, che è cosa ben diversa, ma comunque plausibile – non è chiara la cosa.

Una coppia di chiavi RSA 1024 è considerata ancora piuttosto sicura, sebbene siano stati dimostrati alcuni attacchi teorici in grado di forzarle – attacchi difficilmente praticabili nell’ottica di un’utenza comune. L’RSA-1024, ad oggi, non è stato ancora fattorizzato. Chiaramente un RSA 2048 è di gran lunga più sicuro, raddoppiando la lunghezza della chiave.

L’articolo afferma che le Certification Authority utilizzano chiavi a 128 bit per la Posta Elettronica Certificata. Andando a vedere però sul sito web del governo dedicato alla Posta Elettronica Certificata, si può vedere come venga utilizzata una chiave RSA a 1024 bit e uno stream di crittografia simmetrica AES a 256 bit.

Differente la situazione se si verifica la pagina web dedicata alla Posta Elettronica Certificata di Poste Italiane e di Aruba, dove viene utilizzata una chiave RSA a 1024 bit e uno stream di crittografia simmetrica RC4_128 a 128 bit.

Quindi, a questo punto, penso che i 128 bit di cui parla l’articolo siano riferiti alla chiave della crittografia simmetrica. Teoria che è avvalorata poi da un video, pubblicato nell’articolo, e relativo alla facilità con cui viene individuata una password a 128 bit in una connessione WEP.

Perché viene inserito questo video? Cosa ha in comune la tecnologia di crittografia utilizzata nelle reti wireless con il sistema di crittografia utilizzato dai siti di Poste Italiane e Aruba? La risposta è: l’algoritmo di crittografia RC4.

Questo algoritmo è stato forzato più volte ed è considerato ad oggi insicuro, tuttavia c’è una precisazione da fare: l’implementazione dell’algoritmo RC4 nel protocollo WEP è diversa dall’implementazione dell’algoritmo RC4 nell’SSL.

Cito direttamente dal sito dell’RSA:

Those who are using the RC4-based WEP or WEP2 protocols to provide confidentiality of their 802.11 communications should consider these protocols to be “broken”, and to plan remedial actions as necessary to mitigate the attendant risks. Actions to be considered should include using encryption at higher protocol layers and upgrading to improved 802.11 standards when these become available.

In protocols such as WEP, it is often necessary to generate different RC4 keys from different messages (or packets) from a common base key. A method frequently suggested to obtain the keys is to add or concatenate a counter to the base key. The key-scheduling algorithm of RC4 has been widely recognized to be rather lightweight for this purpose, particularly when the initial few bytes of plaintext are easily predictable.

RSA Security has discouraged such key derivation methods, recommending instead that users consider strengthening the key scheduling algorithm by pre-processing the base key and any counter or initialization vector by passing them through a hash function such as MD5.

….

RC4 is most commonly used to protect Internet traffic using the SSL (Secure Sockets Layer) protocol. Indeed, this use of RC4 may make RC4 the most widely-used stream cipher in the world.
There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet.

Come è possibile vedere, l’utilizzo dell’RC4 a 128 bit per le sessioni SSL è ancora considerato sicuro grazie all’utilizzo degli algoritmi di hashing MD5 o SHA1, non esistono ad oggi attacchi conosciuti capaci di forzare questo sistema di crittografia.

Comunque sia esistono plugin per alcuni browser – vedi Firefox – capaci di forzare il browser stesso a non utilizzare l’algoritmo di cifratura RC4 e di passare ad un più solito AES, sia esso a 128 che a 256 bit. Entrambi considerati ad oggi sicuri – cito a riguardo un passaggio del famosissimo criptoanalista Bruce Schneier:

And for new applications I suggest that people don’t use AES-256. AES-128 provides more than enough security margin for the forseeable future. But if you’re already using AES-256, there’s no reason to change.

Mostrare quindi un video per dimostrare come sia semplice riuscire a recuperare una chiave a 128 bit è, in questo caso, fuorviante perché non si sta parlando della stessa implementazione dell’algoritmo.

Utilizzare certificati basati su chiave RSA a 1024 bit è ancora sicuro, gli attacchi dimostrati sono stati al momento solo teorici e non applicabili facilmente su larga scala. Inoltre, come detto precedentemente, l’RSA-1024 non è stato ancora fattorizzato. È altrettanto ovvio che utilizzare delle chiavi RSA a 2048 bit sia più sicuro, raddoppiando la lunghezza delle chiavi.

Utilizzare uno stream dati a 128 bit, sebbene a 256 bit sia chiaramente più sicuro per i motivi immediatamente sopra evidenziati, non è ad oggi un problema perché dipende prima di tutto dall’algoritmo utilizzato.

Inoltre, se proprio dobbiamo dire che noi italiani siamo pecoroni, bisogna ammettere che almeno siamo in buona compagnia:

  • Bank Of America utilizza una coppia di chiavi RSA a 2048 bit ma una crittografia simmetrica RC4_128 a 128 bit;
  • HSBC, famosa banca inglese, utilizza una coppia di chiavi RSA a 2048 bit ma una crittografia simmetrica RC4_128 a 128 bit;
  • il servizio Gmail di Google utilizza una coppia di chiavi RSA a 1024 bit e una crittografia simmetrica RC4_128 a 128 bit;
  • Amazon utilizza una coppia di chiavi RSA a 1024 bit e una crittografia simmetrica RC4_128 a 128 bit;
  • l’FBI utilizza una coppia di chiavi RSA a 2048 bit ma una crittografia simmetrica RC4_128 a 128 bit;
  • Windows Live utilizza una coppia di chiavi RSA a 2048 bit ma una crittografia simmetrica RC4_128 a 128 bit;
  • Barclays, nota banca inglese, utilizza una coppia di chiavi RSA a 1024 bit e una crittografia simmetrica AES a 256 bit;
  • Di esempi, andando avanti, ce ne possono essere veramente tanti. Il punto è un altro.

    Avevo già detto in passato come il governo avrebbe potuto spendere qualche soldo in più e utilizzare almeno un certificato EV SSL per garantire ancor di più la sicurezza dei propri cittadini, e sono tutt’ora convinto che le cose possano essere fatte in maniera di gran lunga migliore.

    È giusto però cercare di chiarire alcuni punti di un articolo che, a mio avviso, rischia altrimenti di fomentare ancor più i caldi animi dei cittadini in un clima sempre più arroventato.

    La tecnologia corre, fa passi da gigante, e quello che oggi può essere considerato sicuro domani non lo sarà più. È più che giusto cercare oggi di fornire le soluzioni più sicure sul mercato. Ma non è esatto dire che le soluzioni implementate oggi si possano forzare nel giro di pochissimi minuti. Non almeno senza una serie di pre-condizioni necessarie e non facilmente replicabili.