[NEWS] Certificati SSL 128/1024: siamo così indietro?

[c.m.g]

December 24th, 2010 by Marco Giuliani


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. Quel 128, non me ne vogliano di nuovo gli esperti del settore, si riferisce solitamente alle dimensioni della coppia di chiavi RSA, cioè 128 byte e 1024 bit. 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 asimmetrica 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 asimmetrica 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 asimmetrica RC4_128 a 128 bit;
• HSBC, famosa banca inglese, utilizza una coppia di chiavi RSA a 2048 bit ma una crittografia asimmetrica RC4_128 a 128 bit;
• il servizio Gmail di Google utilizza una coppia di chiavi RSA a 1024 bit e una crittografia asimmetrica RC4_128 a 128 bit;
• Amazon utilizza una coppia di chiavi RSA a 1024 bit e una crittografia asimmetrica RC4_128 a 128 bit;
• l’FBI utilizza una coppia di chiavi RSA a 2048 bit ma una crittografia asimmetrica RC4_128 a 128 bit;
• Windows Live utilizza una coppia di chiavi RSA a 2048 bit ma una crittografia asimmetrica RC4_128 a 128 bit;
• Barclays, nota banca inglese, utilizza una coppia di chiavi RSA a 1024 bit e una crittografia asimmetrica 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.





Fonte: PcalSicuro.com by Marco Giuliani

[Massimo Penco]

Ho già risposto direttamente al post del blog di Marco ritengo sia opportuno entrare in discussione anche qui brevemente però se no si rischia di scrivere un trattato che a molti non Interessa, interessanti ma parziali le informazioni trovate in rete e riportate nel post il fatto in pratica è che:
1) L'organismo deputato alla regolamentazione delle CA non è sicuramente RSA dove ho lavorato tanti anni fa prima di andare in Verisign "costola" di RSA tanto per specificare bensì il NIST che nel 2007 ha regolato la materi per chi vuol leggere e capire ecco il documento completo: http://csrc.nist.gov/publications/ni...Mar08-2007.pdf
2) E'un fatto che che le chiavi crittografiche abbiano un ciclo vitale per altro ben tracciato nel documento di cui sopra
3) è altrettanto un fatto che i "costruttori" dei browser debbano investire soldoni per adeguarli a nuove esigenze di sicurezza , sono processi molto lunghi, capiscono però forse più di Marco che debbano essere adeguati uno per tutti Mozilla leggete il dictact che leva ogni dubbio https://wiki.mozilla.org/CA:MD5and1024 è NON E' UN CONSIGLIO MA UNA VERA E PROPRIA LOGICA IMPOSIZIONE !
4) E'un altrettanto processo lungo cambiare le ROOT KEY così si chiamano ! di tutte le CA al mondo quelle usate per capirsi anche da TUTTE le SUB-CA Italiane ma in ottemperanza a quanto richiesto dal NIST tutte le VERE CA le hanno da anni adeguate in Italia si usano ancora quelle risalenti al 1999 della defunta Baltimore basta andare nei vari siti e vederle.
5) Marco confonde l'EV, nativo con algoritmo a 256, il cui solo scopo è quello di un autenticazione e validazione forte che nulla ha a che vedere con la chiave, anche qui basta andare in www.cabforum.org dove ci sono si le vere CA, per capirlo.
In finale per semplificare le cose nessuno non ha adeguato le chiavi di casa con sistemi più sicuri. Qui in Italia abbiamo fatto molto peggio basta andare in giro per Roma e vedere che la gente vive blindata dietro robuste grate e tra sistemi d'allarme e serrature quadruple per entrare in casa ci vuole minimo un quarto d'ora.

[eraser]

Come è già stato detto, mi sembra inutile continuare qui la discussione. Quello che dovevo scrivere in risposta, l'ho già scritto in risposta al commento.
Si sta facendo un minestrone di roba che non ha più fine

EDIT:

Ho letto ora cosa il signor Penco ha scritto in un altro blog. Ha scritto la seguente frase:

Ma ci vuole in finale una morale che è la seguente:
Chi non sa e meglio stia zitto !

Un'uscita offensiva e fuori luogo. Speravo non facesse parte della sua persona. Evidentemente mi sbagliavo. Non mi risulta di averlo mai offeso né di averlo considerato una persona che non sa le cose e tanto meno zittito.

Saluti

[riazzituoi]

.

[eraser]

Originariamente inviato da riazzituoi

La fattorizzazione di una chiave a 1024 bit è prevista per il 2018 +/- 3 anni. Comunque non potrà essere ritenuta sicura oltre il 2015, quindi meglio muoversi.

Certamente. Non mi sembra però il caso di causare allarmismi pubblicando video di sessioni WEP decriptate e utilizzarle per dire che i sistemi a 128 bit sono insicuri e violarli è un gioco da ragazzi. Non pensi?

[riazzituoi]

.

[eraser]

Originariamente inviato da riazzituoi

Sì, avevo visto quell'articolo su tom's hardware e in effetti ero rimasto un pò perplesso per la "confusione".

Ciao, e Auguri!

Appunto

Tanti cari Auguri anche a te

[eraser]

Informo che la discussione è continuata tra i commenti dell'articolo nel mio sito web. Invito chi è maggiormente interessato all'argomento a leggere lì e a tirare le proprie conclusioni.

Tanti auguri a tutti quanti

[c.m.g]

Correlata:
2016: addio a RC4 su punto informatico