RSA in GnuPG è stata violata: risvolti tecnici e patch

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
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

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

Link copiato negli appunti

Ti potrebbe interessare

Pubblicato il
10 lug 2017
Link copiato negli appunti