E 'possibile prevenire un attacco fisico sulla crittografia completa del disco?

14

Ho studiato alcuni metodi per garantire che le chiavi di crittografia del disco non possano essere rubate e una che ho incontrato si chiama TRESOR. Con questa patch del kernel, è possibile creare una partizione crittografata utilizzando AES e le chiavi vengono archiviate nella cache della CPU anziché nella RAM. All'inizio pensavo che fosse grandioso, ma dopo ulteriori domande, sono giunto alla conclusione che qualsiasi dato decrittografato ancora memorizzato nella RAM è vulnerabile a un dump di avvio fisico freddo. Un modo per farlo sicuro è crittografare il contenuto della RAM del sistema operativo utilizza TRESOR e quindi creare una partizione crittografata, poiché le chiavi si troveranno nella RAM crittografata e le chiavi della RAM nella cache della CPU. Non so ancora se questo è un metodo sicuro, o quanto sia sano. È persino possibile impedire un attacco fisico alla crittografia completa del disco e, in caso affermativo, come posso?

    
posta Clay Freeman 20.01.2014 - 14:09
fonte

5 risposte

8

Affinché la CPU elabori effettivamente i dati, i dati devono essere in chiaro in qualche punto. TRESOR utilizza i registri della CPU, presumibilmente più difficili da leggere rispetto alla RAM per l'aggressore fisico, ma il suo ambito è limitato a chiave di crittografia : quella chiave è nei registri, ma i dati crittografati o decrittografati sono ancora nella RAM. Ci sono solo una manciata di registri nella CPU, non c'è semplicemente spazio per più dati.

Usando un disco RAM con supporto TRESOR, hai "file crittografati" con accesso veloce (dato che è la RAM), ma sono ancora "file" nella vista del kernel e del codice dell'applicazione. I dati saranno decrittografati nella RAM ad un certo punto.

Se vuoi davvero che la tutta RAM sia sempre criptata, allora la scelta è quella di usare una CPU che include l'hardware per fare tale crittografia (ci sono alcune CPU smartcard che lo fanno, ma nessuna CPU simile a PC a mia conoscenza), o per creare una macchina virtuale completa la cui CPU virtuale è implementata come TRESOR con crittografia e decodifica automatica su ogni accesso di memoria. La modalità di crittografia effettiva avrebbe bisogno di una riflessione approfondita (non è facile crittografare i dati in modo sicuro pur consentendo una decrittazione veloce con accesso casuale). Non sono a conoscenza di alcun prototipo; ma è teoricamente fattibile. Un bel progetto per uno studente (potrebbe anche essere il risultato principale di un dottorato). Sarebbe terribilmente lento.

    
risposta data 20.01.2014 - 17:02
fonte
4

Bene, c'è un vecchio detto da Microsoft (lo so, non il meglio fonte di sicurezza) che dice:

Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

E perché è applicabile al tuo caso? Perché se hai crittografia sufficiente, il tuo disco rigido è sicuro se qualcuno lo ruba. Ma se la persona può avere accesso ai tuoi chip RAM subito dopo aver spento il server, può provare a recuperare le chiavi nello scenario che hai appena detto.

La memorizzazione delle chiavi nella cache della CPU lo ridurrebbe al minimo, come hai detto, ma i dati non crittografati potrebbero essere ancora disponibili nei chip RAM.

E se avesse accesso al tuo computer prima di accenderlo? Stai prendendo in considerazione la protezione fisica prima durante l'avvio? altrimenti, il cattivo può creare una schermata di accesso falso e prendere la password anche se l'intero sistema è crittografato. Oppure può allegare un keylogger. Oppure può collegare un dispositivo e clonare i chip della RAM dall'inizio. Oppure può cambiare il tuo BIOS e farlo anche tu. Oppure ... beh, dai un'occhiata al catalogo NSA, ad esempio, per avere qualche idea del potenziale attacco.

Quindi il tuo computer deve essere fisicamente sicuro. Ciò significa che non solo l'accesso fisico deve essere difficile (ad esempio, dato un tempo sufficiente per svanire il contenuto della RAM), ma anche che non può catturare la radiazione magnetica dalla CPU o dalla scheda madre o dalla tastiera, né rumori, né immagini da te digitando o spostando il mouse.

Se hai davvero bisogno di quel livello di sicurezza che elimina i chip RAM dal tuo computer, probabilmente hai bisogno di più sicurezza di quanto ti aspetti.

Aggiorna

Dopo il tuo commento:

I'm wanting protection so that my clients' data cannot be retrieved physically from the server while it is running, just powered off recently, or has been powered off for a while.

Penso di poter espandere un po 'la mia risposta, semplicemente pensando in questo aspetto fisico.

  • Per proteggere i tuoi dati dopo che il tuo server è stato spento per un po 'di tempo:

La crittografia è tua amica. Se qualcuno estrae un HDD crittografato con un strong algoritmo e una password complessa, impiegherà per sempre la forza bruta ad attaccarlo.

Punti da considerare:

a) la crittografia dell'intero disco richiede che tu o alcuni programmi "digitiate" la password durante il montaggio. Se sei tu, dovrai essere disponibile per accenderlo ogni volta. Se si tratta di un programma, dove memorizzare la chiave

b) crittografare solo dati / cartelle, esiste lo stesso problema "dove archiviare la chiave per accenderlo".

  • Per proteggere i dati dopo che il server è stato spento recentemente o durante l'esecuzione:

Durante l'esecuzione, è necessario che il percorso tra HDD - RAM - CPU sia crittografato, come spiega la risposta di Thomas Pornin, e che non sono a conoscenza di alcun server con una CPU in grado di farlo. E dovresti preoccuparti della compatibilità con alcune periferiche, dal momento che PCI, PCI Express, Firewire, ecc., Si affidano a DMA per velocizzare le cose. Quindi potresti avere problemi di prestazioni.

Un modo più semplice per evitare che sia, beh, proteggere fisicamente il tuo server. Come una stanza sicura, dove il server è spento e riscaldato a una certa temperatura (per evitare che qualcuno rubi i tuoi chip RAM). O addirittura distruggendo i chip con scoppi controllati o picchi di tensione. Tutto ciò che rende più difficile per qualcuno entrare e andare via con il tuo server sotto le sue braccia.

E, naturalmente, tutto questo lascia fuori che molti attacchi possono essere fatti in remoto, senza alcuna presenza fisica, usando solo il software e così via.

    
risposta data 20.01.2014 - 17:39
fonte
1

Suppongo che l'OP stia costruendo un server e lo spedisca alla struttura del colo.

La sicurezza fisica includerebbe:

  • incorpora RAM, CPU e circuiti associati con un composito PMMA / Al2O3 (elettricamente isolante, termicamente conduttivo e molto resistente)
  • opzionalmente include circuiti di dead-man in precedenza che nuke CPU e RAM
  • disconnetti tutti i connettori esterni tranne l'alimentazione e le NIC necessarie ma non altera l'aspetto esterno
  • installa più interruttori di intrusione caso, con ciascuno di essi potere di uccisione quando attivato (ancora meglio, fagli nuke CPU e RAM se non disinserito da remoto)
  • disabilita le funzionalità di gestione remota

La sicurezza del software includerebbe:

  • avvia in remoto usando dropbear per ssh in initramfs
  • dopo l'avvio, sovrascrivi i keylots e l'intestazione LUKS con i bit casuali (nessuno di quelli necessari fino al riavvio)
  • al riavvio, ssh in initramfs e ripristino dei keylots e dell'intestazione LUKS
  • fai frequenti backup sicuri

Dovrebbe farlo, eccetto contro avversari molto determinati e abili.

    
risposta data 24.01.2014 - 05:47
fonte
1

La crittografia del disco fisico è molto importante per fermare un sacco di semplici hack. Insegno informatica e sicurezza informatica, ma a volte le politiche estremamente restrittive del sistema scolastico mi inducono a lavorare sulla sicurezza. Poiché il sistema scolastico non utilizza la crittografia del disco, sono in grado di ottenere l'accesso amministratore locale sulla macchina Windows in meno di 5 minuti grazie all'accesso fisico. Non sarei in grado di farlo se stessero utilizzando la crittografia completa del disco.

    
risposta data 04.11.2018 - 19:06
fonte
0

Alcuni file system supportano DAX, che sta per Accesso diretto. È una funzionalità che aggira la cache della pagina, quindi un file system crittografato con TRESOR non colerà molto se non ci sono dati non criptati durante la lettura e la scrittura. È possibile inserire un file in tmpfs e creare un dispositivo di loopback e crittografarlo con TRESOR, quindi formattarlo con un filesystem che supporti DAX. Questo sarà un ramdisk freddo e protetto da avvio freddo.

Potresti anche creare un file system tmpfs molto grande e inserire un file enorme, occupando la maggior parte della memoria (90 o 95%), fino a quando il tuo sistema è così lento con così poca memoria da essere inutilizzabile. Quindi crittografare quel file residente in memoria con TRESOR e usarlo come file di scambio. Ciò consentirà effettivamente la maggior parte della memoria di rimanere crittografata, mentre una piccola quantità che viene utilizzata più frequentemente rimarrà non criptata. L'ho sperimentato personalmente e, almeno in una macchina virtuale, posso ridurlo a circa 256 MiB di memoria non criptata. Se modifichi il kernel e giochi con abbastanza sysctls, dovresti essere in grado di portarlo a un massimo di 64.

Alcuni progetti a cui potresti essere interessato:

CryptKeeper: miglioramento della sicurezza con la RAM crittografata

RamCrypt: crittografia dello spazio degli indirizzi basata su kernel per i processi in modalità utente

Un interprete Bytecode per l'esecuzione di un protocollo sicuro nella memoria principale non sicura

Se hai solo bisogno di crittografare lo spazio di memoria di singoli processi come nginx, php-fpm, ecc, allora RamCrypt è assolutamente quello che vuoi. È una versione modificata di TRESOR, funziona per il kernel 3.19 (anche se è molto per portarlo su kernel più recenti, con pochi scarti che coinvolgono nuovi file header e alcune funzioni che cambiano nome), e ha un impatto accettabile.

La memoria DDR3 e DDR4 supporta una funzione chiamata "rimescolamento della memoria". Viene utilizzato per ridurre l'eccessivo di / dt (interferenze da 1s e 0s successivi sul bus) e rende più difficili gli attacchi classici di avvio a freddo. Non sono a conoscenza di quale algoritmo utilizza o se è crittograficamente sicuro o meno. Leggi le pagine 26-30 su Segreto di Intel Management Engine per come ha fermato almeno un'istanza di reverse engineering .

    
risposta data 03.04.2016 - 05:39
fonte