Spostamento / tmp in un tmpfs crittografato

1

BLUF: Sto usando un SSD sul mio sistema, quindi il motivo principale per usare tmpfs per aumentare la durata del mio disco spostando file di lettura / scrittura elevati nella memoria volatile. Ma dal punto di vista della sicurezza, mi piacerebbe anche sapere se avrebbe senso crittografare la memoria volatile per motivi di sicurezza.

Specifiche di sistema correnti:

OS:                 Custom Arch Linux Build

RAM:                6GB  
My build rarely goes over 1GB of RAM usage. 

Primary Drive:      128GB SSD 
    Holds the OS, setup with LUKS on LVM for full disk (-boot) encryption. 

Secondary Drive:    1TB HDD (much slower) 
    For long term storage and backup (fully encrypted).

Concern:

Così com'è quando il mio sistema si spegne, un utente richiede che la chiave sia in grado di accedere al mio disco rigido del sistema. Tuttavia, da un punto di vista anti-forense, la RAM sarebbe un obiettivo praticabile per il recupero per almeno alcuni minuti dopo l'arresto (probabilmente più lungo con un hacking di air-duster).

La mia domanda è: per evitare un ripristino dell'avvio a freddo in questo caso molto improbabile, la crittografia del contenuto di tmpfs con qualcosa come dm-crypt può essere un'opzione valida?

Fondamentalmente sto chiedendo un controllo sulla logica. Quali possibili buchi mi mancano?

    
posta Jay Holister 13.05.2015 - 18:25
fonte

1 risposta

4

Se ritieni che gli autori di attacchi possano recuperare i contenuti della RAM (un attacco di avvio a freddo ), devi prendere in considerazione gli autori di attacchi possono recuperare i contenuti della RAM . Il tuo filesystem /tmp viene utilizzato dall'applicazione come repository temporaneo per alcuni elementi di dati, ma le stesse applicazioni lo rilevano, nella RAM. Cioè, è improbabile che il filesystem basato sulla RAM contenga l'unica copia nella RAM per i dati sensibili. Qualunque cosa tu faccia con /tmp , che si tratti di crittografia o qualsiasi altra cosa, sarà solo una soluzione parziale.

Un altro punto è che un filesystem crittografato è ancora una memoria per i file, che il sistema live può leggere e scrivere. Pertanto, anche se crittografato, la chiave di decodifica (nella macchina live) deve trovarsi da qualche parte in essa ... cioè nella RAM. Se gli aggressori possono leggere la RAM, possono recuperare la chiave e rimuovere tutta la crittografia.

Ciò che potrebbe fare per ridurre la probabilità di recupero dei dati da parte di utenti malintenzionati è assicurarsi di svuotare la RAM come parte della procedura di spegnimento. Ciò comporterebbe, dall'ultimo processo in esecuzione nella macchina:

  • Smontare /tmp .
  • Disattivare lo spazio di swap (a proposito, si cripta la partizione di swap? In alternativa, si può semplicemente disattivare lo swap, lo faccio sul mio laptop).
  • Riempimento della RAM con byte casuali (o zeri), allocazione delle pagine e riempimento fino alla mancata assegnazione. A quel punto, sapete che il kernel ha trovato tutta la RAM disponibile e l'ha riempita di casualità; questo includerebbe tutte le pagine che corrispondevano al /tmp basato sulla RAM.

Da quanto ho spiegato sopra, una procedura del genere sarebbe comunque necessaria (dato che i dati sensibili potrebbero nascondersi al di fuori di /tmp ) e rende irrilevante qualsiasi crittografia di /tmp .

I problemi rimanenti sono che la RAM non dell'applicazione, nello spazio del kernel, potrebbe ancora aver bisogno di un po 'di pulizia; e una procedura di spegnimento ha effetto solo quando viene applicato un arresto. Se l'attaccante ruba la macchina dal vivo, allora può staccare la spina (o la batteria, per un laptop) per ottenere una nuova istantanea live della RAM. La crittografia non sarebbe di aiuto lì (perché la chiave di crittografia sarebbe parte dello snapshot).

    
risposta data 13.05.2015 - 20:11
fonte

Leggi altre domande sui tag