TESORI - TRESOR

TRESOR ( acronimo ricorsivo per "TRESOR Runs Encryption Securely Outside RAM", e anche la parola francese per un tesoro) è una patch del kernel Linux che fornisce crittografia basata solo sulla CPU per difendersi dagli attacchi di avvio a freddo sui sistemi informatici eseguendo la crittografia al di fuori del solito casuale -accesso alla memoria (RAM). È una delle due soluzioni proposte per computer generici (l'altra utilizza la cache della CPU per lo stesso scopo), è stata sviluppata dal suo predecessore AESSE , presentato a EuroSec 2010 e presentato a USENIX Security 2011. Gli autori affermano che consente alla RAM di essere trattati come non attendibili dal punto di vista della sicurezza senza ostacolare il sistema.

Un documento del 2012 chiamato TRESOR-HUNT ha mostrato come un attacco DMA può violare questo sistema, iniettando un codice che funzionerebbe in modo invisibile all'anello 0 (il livello di privilegio più alto), che gli consentirebbe di leggere le chiavi e trasferirle nella memoria normale. Il documento ha anche proposto modi per mitigare tali attacchi.

Motivazione

Nella sicurezza informatica, un problema comune per la sicurezza dei dati è il modo in cui un intruso può accedere ai dati crittografati su un computer. I moderni algoritmi di crittografia, correttamente implementati e con password complesse , sono spesso infrangibili con la tecnologia attuale, quindi l'accento è stato spostato su tecniche che aggirano questo requisito, sfruttando aspetti della sicurezza dei dati in cui la crittografia può essere "infranta" con molto meno sforzo, oppure bypassato completamente.

Un attacco di avvio a freddo è uno di questi mezzi con cui un intruso può sconfiggere la crittografia nonostante la sicurezza del sistema, se può ottenere l'accesso fisico alla macchina in esecuzione. Si basa sulle proprietà fisiche dei circuiti all'interno dei dispositivi di memoria comunemente utilizzati nei computer. Il concetto è che quando un sistema informatico ha dati crittografati aperti, le chiavi di crittografia stesse utilizzate per leggere o scrivere tali dati sono solitamente archiviate su base temporanea nella memoria fisica, in una forma leggibile. (Mantenere queste chiavi in ​​forma "semplice" durante l'uso è difficile o impossibile da evitare con i normali sistemi poiché il sistema stesso deve essere in grado di accedere ai dati quando richiesto dall'utente autorizzato). Di solito questo non è un vantaggio per un intruso non autorizzato, perché non può accedere o utilizzare quelle chiavi, ad esempio a causa della sicurezza integrata nel software o nel sistema. Tuttavia, se è possibile accedere ai dispositivi di memoria al di fuori del sistema in esecuzione senza perdita di contenuti, ad esempio riavviando rapidamente il computer o rimuovendo i dispositivi su un dispositivo diverso, è possibile leggere chiaramente i contenuti correnti, comprese le chiavi di crittografia in uso. e usato. Questo può essere importante se il sistema non può essere utilizzato per visualizzare, copiare o accedere a tali dati, ad esempio il sistema è bloccato o potrebbe avere trappole esplosive o altri controlli di intrusione, o è necessario in una forma garantita intatta per scopi forensi o probatori .

Poiché questa è una proprietà fisica dell'hardware stesso e basata sulle proprietà fisiche dei dispositivi di memoria, non può essere sconfitta facilmente dalle tecniche software pure, poiché tutto il software in esecuzione in memoria nel punto di intervento diventa accessibile. Di conseguenza, qualsiasi software di crittografia le cui chiavi è possibile accedere in questo modo è vulnerabile a tali attacchi. Di solito un attacco di avvio a freddo comporta il raffreddamento dei chip di memoria o il riavvio rapido del computer, sfruttando il fatto che i dati non vengono persi immediatamente (o non persi se l'alimentazione viene ripristinata molto rapidamente) e i dati che erano conservati al momento dell'intervento verranno lasciati accessibile all'esame.

Gli attacchi di avvio a freddo possono quindi essere un mezzo di furto, perdita o accesso non autorizzato ai dati. Tali attacchi possono essere annullati se le chiavi di crittografia non sono accessibili a livello hardware a un intruso, ovvero i dispositivi in ​​cui sono archiviate le chiavi quando sono in uso non sono suscettibili di attacchi di avvio a freddo, ma questo non è il caso normale.

L'approccio di TRESOR

TRESOR è un approccio software che cerca di risolvere questa insicurezza archiviando e manipolando le chiavi di crittografia quasi esclusivamente sulla sola CPU e in registri accessibili solo all'anello 0 (il livello di privilegio più alto), l'eccezione è il breve periodo di calcolo iniziale al inizio di una sessione. Ciò garantisce che le chiavi di crittografia non siano quasi mai disponibili tramite lo spazio utente o in seguito a un attacco di avvio a freddo. TRESOR è scritto come una patch del kernel che memorizza le chiavi di crittografia nei registri di debug x86 e utilizza la generazione di chiavi rotonde al volo , l' atomicità e il blocco del normale accesso ptrace ai registri di debug per la sicurezza.

TRESOR è stato prefigurato da una tesi del 2010 di Tilo Muller che ha analizzato il problema dell'attacco di avvio a freddo. Concluse che i moderni processori x86 avevano due aree di registro in cui la crittografia del kernel basata sulla CPU era realistica: i registri SSE che in effetti potevano essere privilegiati disabilitando tutte le istruzioni SSE (e necessariamente, tutti i programmi che si basano su di esse), e i registri di debug che erano molto più piccoli ma non avevano problemi del genere. Lasciò quest'ultimo perché altri lo esaminassero e sviluppò una distribuzione di prova del concetto chiamata Paranoix basata sul metodo del registro SSE.

I suoi sviluppatori affermano che "eseguendo TRESOR su una CPU a 64 bit che supporta AES-NI , non vi è alcuna penalizzazione delle prestazioni rispetto a un'implementazione generica di AES " e funziona leggermente più velocemente della crittografia standard nonostante la necessità di ricalcolare la chiave, un risultato che inizialmente ha sorpreso anche gli autori.

Potenziali vulnerabilità

Il documento degli autori rileva quanto segue:

  • Sebbene non possano escludere la perdita di dati della CPU nella RAM, non sono stati in grado di osservare alcun caso che ciò sia accaduto durante i test formali. Qualsiasi caso del genere dovrebbe essere patchabile.
  • L' accesso root alle chiavi di crittografia tramite il kernel di un sistema in esecuzione è possibile utilizzando moduli del kernel caricabili o memoria virtuale ( /dev/kmem ) e memoria fisica ( /dev/mem ), se compilata per supportarli, ma per il resto sembra non essere accessibile in qualsiasi modo noto su un sistema funzionante standard.
  • Stati ACPI sleep e low power: - sui processori reali i registri vengono azzerati durante gli stati ACPI S3 (suspend-to-ram) e S4 (suspend-to-disk) poiché la CPU è spenta per questi.
  • Attacchi di avvio a freddo sulla CPU: - sui processori reali i registri vengono azzerati sia sui reset hardware che sui reset software (" Ctrl-Alt-Delete "). Tuttavia, i registri della CPU sono attualmente vulnerabili sulle macchine virtuali , poiché vengono ripristinati durante i ripristini hardware simulati ma non durante i ripristini software. Gli autori ritengono che questo sia un apparente difetto in molte implementazioni di macchine virtuali, ma notano che i sistemi virtuali sarebbero intrinsecamente vulnerabili anche se questo fosse corretto, poiché è probabile che tutti i registri su una macchina virtuale siano accessibili utilizzando il sistema host.
  • TRESOR è resistente agli attacchi di temporizzazione e agli attacchi basati sulla cache grazie alla progettazione dell'istruzione AES-NI , in cui la CPU supporta le estensioni del set di istruzioni AES . I processori in grado di gestire le estensioni AES a partire dal 2011 sono Intel Westmere e Sandy Bridge (ad eccezione di alcuni i3) e successori, AMD Bulldozer e alcuni processori VIA PadLock .
  • Nel 2012 un documento chiamato TRESOR-HUNT ha mostrato come un attacco DMA potrebbe violare questo sistema, iniettando codice che funzionerebbe in modo invisibile all'anello 0 (il livello di privilegio più alto), aggirando il "blocco" imposto da TRESOR, che gli consentirebbe di leggere le chiavi dai registri di debug e trasferirle nella memoria normale. Il documento ha anche proposto modi per mitigare tali attacchi.

Guarda anche

Riferimenti e note

link esterno