patrizio.tufarolo

RSA in GnuPG è stata violata: risvolti tecnici e patch

Un gruppo di otto ricercatori provenienti da università di tutto il mondo ha attaccato con successo RSA-1024 in Libgcrypt. Per la vulnerabilità sfruttata, denominata CVE-2017-7526, c'è la patch per Debian e Ubuntu

Roma - RSA 1024 può essere compromesso: questo è quanto dimostrato da un gruppo di ricercatori provenienti dalle università di Eindhoven, Chichago, Pennsylvania e Adelaide che in un articolo di ricerca hanno mostrato un attacco nei confronti dell'implementazione di RSA con chiavi a 1024 bit in GnuPG.

RSA è un noto algoritmo di crittografia asimmetrica, ideato da Ronald Rivest, Adi Shamir e Leonard Adleman negli anni '70. Data la sua scarsa efficienza computazionale, esso è largamente utilizzato per lo scambio di chiavi di cifratura simmetrica, o in scenari di firma digitale.
La sicurezza dell'algoritmo è fondata sulla difficoltà di fattorizzare numeri interi molto grandi in modo efficiente: per garantirne l'inviolabilità è necessario che l'operazione di fattorizzazione non sia effettuabile per lo sforzo computazionale che richiederebbe. È proprio per questa ragione che gli attacchi finora studiati possono essere applicati esclusivamente in modo naive, quando gli esponenti utilizzati nell'algoritmo sono costituiti da numeri piccoli; in casi realistici si utilizzano esponenti grandi e chiavi di 1024, 2048 o 4096 bit.

Nell'articolo sull'attacco Tempest ad AES avevamo già citato un lavoro dell'Università di Tel Aviv nel quale veniva mostrato un attacco Tempest all'implementazione di RSA 1024 in GnuPG basato sul leakage dei bit della chiave.
In un altro studio è stato mostrato un altro approccio per il leakage della chiave basato sulla cache LLC (last-level cache, la cache interpellata immediatamente prima dell'accesso diretto a memoria) delle CPU, rendendo possibili attacchi locali durante l'esecuzione dell'algoritmo.
Gli sviluppatori di Libgcrypt, la libreria di crittografia alla base di GnuPG, avevano corretto entrambe le problematiche, tuttavia, in un articolo del 2008 da ricercatori dell'Università di Princeton e di San Diego (California), aveva mostrato un'altra vulnerabilità e un attacco side-channel effettuabile tramite la ricostruzione della chiave di cifratura partendo da dati rimasti in RAM. Tale vulnerabilità, che sfrutta debolezze nel meccanismo sliding-windows (finestra a scorrimento) per il calcolo degli esponenti, era rimasta irrisolta: la libreria continuava ad usare il meccanismo delle sliding windows - nonostante fosse stata proposta una patch per l'implementazione delle fixed windows - poiché gli attacchi effettuabili non erano ritenuti particolarmente efficienti, né la patch era stata ritenuta adatta alla risoluzione della vulnerabilità.
Il nuovo articolo punta a screditare queste convinzioni, secondo le quali nel caso di una finestra di 4 bit, sarebbe possibile scoprire il 40 per cento dei bit, percentuale che scende al 33 per cento nel caso di una finestra a 5 bit.

La CVE-2017-7526, che riguarda le versioni della libreria Libgcrypt dalla 1.4.0 alla 1.7.6, ripropone pertanto una versione modificata delle tecniche illustrate nel paper del 2008 per ottenere la chiave privata a 1024-bit nella sua interezza; l'attacco può essere riprodotto anche per RSA-2048 rivelandosi efficiente in circa il 13 percento dei casi.
Il calcolo dell'esponente avviene mediante una sequenza di operazioni di elevamento al quadrato e moltiplicazioni. Un ruolo fondamentale è svolto dall'ordine in cui viene considerata tale sequenza: se la finestra viene fatta muovere da sinistra verso destra, vengono trapelate più informazioni rispetto alla modalità "da destra verso sinistra".

L'attacco, di tipo side-channel, si svolge in due fasi: in un primo step l'attaccante deve scoprire la sequenza di elevamenti e moltiplicazioni effettuata. A tal fine, il metodo utilizzato consiste nell'esecuzione iterata e temporizzata dell'istruzione x86 clflush, che ha come obiettivo quello di liberare una locazione di memoria condivisa.
Monitorando nel contempo la locazione interessata, è possibile tracciare le operazioni effettuate dalla vittima.
Questa tecnica (denominata Flush+Reload) è gia nota nell'ambito della crittoanalisi ed è di difficile applicazione in Libgcrypt, poiché il codice utilizzato nelle operazioni di elevamento a potenza è lo stesso della moltiplicazione; ciò, sebbene possa introdurre un maggiore livello di complessità computazionale, impedisce all'attaccante di identificare specificatamente le operazioni di moltiplicazione da quelle di elevamento al quadrato. I ricercatori hanno fornito diverse metodologie per affrontare la problematica.
La seconda fase dell'attacco consiste nell'utilizzo della sequenza scoperta per individuare gli specifici bit della chiave. Se i bit recuperati utilizzando le tecniche note sono prossimi al 50 per cento, la sequenza scoperta può essere utilizzata in un'euristica per dedurre la chiave nella sua completezza.

Il solo requisito, affinché entrambe le fasi possano essere portate a termine, è che l'attaccante abbia possibilità di accedere all'hardware su cui le operazioni di cifratura siano state svolte.
Ciò, in un'ottica in cui parecchi sistemi sono virtualizzati su hypervisors di terze parti o eseguiti su sistemi in outsourcing (ad esempio fornitori di servizi cloud, piuttosto che VPS tradizionali o ambienti di hosting condiviso in cui la separazione è fatta non con la virtualizzazione ma con container OpenVZ, LXC o Docker), rappresenta una casistica molto comune laddove il provider non adotta specifiche misure per garantire l'isolamento durante l'esecuzione dei processi lanciati dall'utente.

I sistemi operativi impattati dalla vulnerabilità sono Debian, Ubuntu, Red Hat e derivate.
Per le prime due sono state rilasciate apposite patch; si raccomanda dunque di aggiornare la libreria. Per quanto riguarda Red Hat e CentOS, invece, sembra che la vulnerabilità non verrà risolta, come emerge anche dalla segnalazione del bug relativa ai repository EPEL di Fedora.

Patrizio Tufarolo
Notizie collegate
10 Commenti alla Notizia RSA in GnuPG è stata violata: risvolti tecnici e patch
Ordina
  • E' dal 2007 che aspetto che alzino in maniera nativa la grandezza max della chiave fermo al 4096/4096, spero che questa sia l'occasione buona.
    (si, lo so che se modifico il file setup del sorgente e lo ricompilo lo posso sempre fare, ma la chiave non sarà supportata dalle versioni normali degli altri)
    Immagino che se c'è una falla la si potrà sfruttare comunque, ma più sarà lunga la chiave e più ci vorrà comunque, credo..
    non+autenticato
  • - Scritto da: Mao99
    > E' dal 2007 che aspetto che alzino in maniera
    > nativa la grandezza max della chiave fermo al
    > 4096/4096, spero che questa sia l'occasione
    > buona.
    > (si, lo so che se modifico il file setup del
    > sorgente e lo ricompilo lo posso sempre fare, ma
    > la chiave non sarà supportata dalle versioni
    > normali degli
    > altri)
    > Immagino che se c'è una falla la si potrà
    > sfruttare comunque, ma più sarà lunga la chiave e
    > più ci vorrà comunque,
    > credo..
    ma che cazzo dici?
    io dovrei preoccuparmi di "essere compatibile" con un deficiente che usa una rsa 1024!!!
    non hai capito una ceppa non voglio proprio essere compatibile con un tale demente perchè non dubbio che la riservatezza sia compromessa lo è per definizione ... con uno così non ho messaggi riservati da scambiare!
    non+autenticato
  • - Scritto da: Mao a puntini ... i solii 3 ...
    > ma che cazzo dici?
    Dice che sei una persona inutile
    non+autenticato
  • - Scritto da: Mao99
    > E' dal 2007 che aspetto che alzino in maniera
    > nativa la grandezza max della chiave fermo al
    > 4096/4096, spero che questa sia l'occasione
    > buona.
    > (si, lo so che se modifico il file setup del
    > sorgente e lo ricompilo lo posso sempre fare, ma
    > la chiave non sarà supportata dalle versioni
    > normali degli
    > altri)
    > Immagino che se c'è una falla la si potrà
    > sfruttare comunque, ma più sarà lunga la chiave e
    > più ci vorrà comunque,
    > credo..
    idiota col botto!
    chi ti ha detto che devi usare 1024?


    "Why does GnuPG support RSA-4096 if it’s such a bad idea?
    RSA-4096 is not a bad idea: it’s just, generally speaking, unnecessary. You gain very little in the way of additional resistance to brute-forcing and cryptanalysis"

    https://www.gnupg.org/faq/gnupg-faq.html#default_r...
    non+autenticato
  • > idiota col botto!
    > chi ti ha detto che devi usare 1024?
    >
    >
    > "Why does GnuPG support RSA-4096 if it’s such a
    > bad
    > idea?
    > RSA-4096 is not a bad idea: it’s just, generally
    > speaking, unnecessary. You gain very little in
    > the way of additional resistance to brute-forcing
    > and
    > cryptanalysis"
    >
    > https://www.gnupg.org/faq/gnupg-faq.html#default_r

    E' vero che il saggio rilegge e nel dubbio tace..
    Scusa ma nessuno sta dicendo che devi usare la 1024, che la voglio usare o altro..
    visto che non hai capito mi spiego meglio, io ho semplicemente detto che se ora sfondano la 1024 (o possono sfondarla) è ora di alzare il limite max per tutte le versioni da 4.096 (fermo da 10 anni perchè gli USA non lo permettono) al programma normale (senza modifica personale e ricompilazione) a 8.192 o 16.384..
    non+autenticato
  • i dati sono sempre "trafugati" su computer in chiaro ...
    non+autenticato
  • Red Hat Enterprise Linux 7     libgcrypt     Will not fix
    Red Hat Enterprise Linux 6     libgcrypt     Will not fix
    Red Hat Enterprise Linux 5     libgcrypt     Will not fix
    RHEV-M for Servers     mingw-virt-viewer     Will not fix

    Le distro serie hanno aggiornato il 29 di giugno.
    non+autenticato
  • - Scritto da: ...
    > Red Hat Enterprise Linux 7     libgcrypt     Will
    > not
    > fix

    > Red Hat Enterprise Linux 6     libgcrypt     Will
    > not
    > fix

    > Red Hat Enterprise Linux 5     libgcrypt     Will
    > not
    > fix

    > RHEV-M for Servers     mingw-virt-viewer     Will
    > not
    > fix

    >
    > Le distro serie hanno aggiornato il 29 di giugno.

    red hat e' una azienda statunitense e come tale e' soggetta al Patrict Act. per legge devono tenere aperte delle backdoor per lo Zio Sam.
    non+autenticato
  • - Scritto da: ...
    > - Scritto da: ...
    > > Red Hat Enterprise Linux 7     libgcrypt     Will
    > > not
    > > fix

    > > Red Hat Enterprise Linux 6     libgcrypt     Will
    > > not
    > > fix

    > > Red Hat Enterprise Linux 5     libgcrypt     Will
    > > not
    > > fix

    > > RHEV-M for Servers     mingw-virt-viewer     Will
    > > not
    > > fix

    > >
    > > Le distro serie hanno aggiornato il 29 di
    > giugno.
    >
    > red hat e' una azienda statunitense e come tale
    > e' soggetta al Patrict Act. per legge devono
    > tenere aperte delle backdoor per lo Zio
    > Sam.
    Ma che cazzotti dici dementè?
    Prova a citare in quale parte del patriota act c'è scritta sta panZanardi!
    non+autenticato
  • - Scritto da: ...

    > red hat e' una azienda statunitense e come tale
    > e' soggetta al Patrict Act. per legge devono
    > tenere aperte delle backdoor per lo Zio
    > Sam.
    1) nel patrioct act non c'è nessun testo reativo all'obbligo di back door (googla invece di sparare puttanate)
    2) Red hat non c'entra una fava non è un suo "prodotto" ma bensì è GNU.
    3) imbecille col botto!
    non+autenticato