Chipset, attacco tramite gestione del risparmio energetico

Ricercatori della Columbia University hanno dimostrato di poter accedere al TrustZone di ARM utilizzando un attacco differenziale. Le prospettive sono allarmanti, data l'assenza di sicurezza nell'ambito del risparmio energetico

Roma – Tre ricercatori della Columbia University hanno presentato un paper allo USENIX Security Symposium di quest’anno, trattando la sicurezza dei meccanismi di risparmio energetico presenti all’interno dei moderni chipset.

La fragilità di questi sistemi, mai approfondita in precedenza, consente una tipologia di attacco chiamato CLKSCREW (leggibile come “clock screw”). CLKSCREW è una variante di una tecnica già nota e utilizzata in crittanalisi, la DFA (Differential Fault Analysis) : essa consiste nello stressare il processore fino ad ottenere una corruzione di memoria , allo scopo di indebolire un sistema di sicurezza fino a violarlo.

Gli autori si sono concentrati in particolare sul DVFS (Dynamic Control and Frequency Scaling) , una tecnica di ottimizzazione energetica utilizzata pressoché in qualunque CPU e SoC attualmente in commercio: nel caso specifico, CLKSCREW è stato utilizzato con successo per violare la TrustZone del SoC ARMv7 di uno smartphone Google Nexus 6.

Gli attacchi descritti all’interno del paper sono due: nel primo viene violata l’esecuzione di un’app di decifratura AES in esecuzione all’interno del TrustZone, riuscendo ad estrarre la chiave utilizzata; nel secondo viene corrotta la procedura di verifica delle chiavi RSA , in modo da riuscire a caricare una propria immagine firmware all’interno del TrustZone.

Nel dettaglio, CLKSCREW si divide in quattro fasi: inizialmente vengono puliti eventuali stati residui della CPU, invocando più volte su due core distinti il thread vittima e quello utilizzato per l’attacco, in rapida successione.

In seguito, il thread vittima viene profilato, allo scopo di ottenere un punto di esecuzione ideale per effettuare l’attacco: nel caso specifico, l’attività di profilazione è basata su una tecnica già nota , facente parte di un attacco alle cache dei dispositivi, presentato allo USENIX dello scorso anno.

Prima di effettuare l’attacco vero e proprio, al fine di ottenere una maggiore precisione temporale, è necessario ritardare l’esecuzione del thread di attacco per mezzo di una serie di operazioni no-op ; viene quindi effettuato l’attacco: dato un determinato voltaggio di funzionamento, il thread di attacco aumenterà la frequenza del core utilizzato dal thread vittima ad un certo valore, mantenendola per un dato numero di cicli della CPU, per poi riportarla al valore originario.

Questo comportamento viene ripetuto più volte, partendo sempre da un determinato istante temporale e variando i cinque dati in input, fino ad ottenere una situazione di errore.

funzionamento clkscrewparametri clkscrew

Nel primo attacco preso in esame, i ricercatori sono riusciti a violare il protocollo AES, ottenendo la chiave di cifratura in circa dodici minuti : un errore di bit ottenuto durante l’ottavo round AES ha consentito di ridurre l’intervallo delle chiavi possibili da 2 128 a 2 12 ; dopodiché, attraverso una classica procedura brute force , sono state generate 3.650 chiavi, tra cui quella autentica.

Nel secondo attacco, viene indotto un errore all’interno dell’esecuzione della funzione DECRYPTSIG utlizzata dall’algoritmo RSA, in modo che il suo risultato in output coincida con l’hash del codice di attacco utilizzato. In questo caso, la percentuale di successo dell’attacco è minore (circa il 20 per cento), ma comunque significativa.

I ricercatori insistono sulla gravità della situazione, dovuta non a difetti di codice significativi, ma piuttosto ad una generale mancanza di attenzione verso la sicurezza , durante le fasi di disegno e implementazione dei meccanismi di risparmio energetico.
Inoltre, sempre secondo i ricercatori, è tecnicamente possibile effettuare attacchi di questo tipo attraverso Internet , senza quindi ottenere l’accesso fisico al dispositivo.

Elia Tufarolo

fonte immagine

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • a caccia di scimmie scrive:
    safari
    "Dalle prove dei ricercatori, Safari era quello con più bug". Ghh... quindi safari® il browser della apple® , nel mainstream, è la peggiore merda in circolazione (rotfl).Il duo coglionaggine bertusix ha già l' arringa difensiva pronta (anonimo)?
  • ma LOL scrive:
    Scheletri nell'armadio
    "È interessante notare come la differenza nel numero di bug tra Safari e Chrome si sia allargata dopo il fork di Webkit in Blink da parte di Google. Dopo la nascita di Blink il numero di vulnerabilità nell'engine di Mountain View si è notevolmente ridotto, mentre per Webkit è aumentato." Quale miglior discriminante per capire chi dei due è pigro a fixare bug?(nulla di nuovo per chi è abituato a sviluppare su quella cloaca di Safari)
    • maxsix gay etico scrive:
      Re: Scheletri nell'armadio
      - Scritto da: ma LOL
      "È interessante notare come la differenza nel
      numero di bug tra Safari e Chrome si sia
      allargata dopo il fork di Webkit in Blink da
      parte di Google. Dopo la nascita di Blink il
      numero di vulnerabilità nell'engine di Mountain
      View si è notevolmente ridotto, mentre per Webkit
      è
      aumentato."

      Quale miglior discriminante per capire chi dei
      due è pigro a fixare
      bug?
      (nulla di nuovo per chi è abituato a sviluppare
      su quella cloaca di
      Safari)gne gne gne. Non capite un cazzo e parlate pure.
Chiudi i commenti