Pulisci la RAM all'arresto per impedire l'attacco a freddo

Il mio sistema è crittografato utilizzando la Crittografia disco intero, ovvero tutto tranne / boot è crittografato utilizzando dmcrypt / luks. Sono preoccupato per Cold Boot Attacks , dove i ricercatori hanno dimostrato , che il contenuto potrebbe essere estratto per circa 5 minuti .

Potete per favore fornire istruzioni su:

• come attivare kexec in un nuovo kernel nelle ultime fasi del processo di arresto / riavvio (per garantire una disinstallazione completa, per prevenire la corruzione del file system, per garantire che il vecchio kernel venga sovrascritto)
• come creare quel kernel, che cancella tutto il ram

ad es. Puoi spiegare per favore, come fare lo stesso su Ubuntu?

Come rilevare l'arresto? Come avviare la cancellazione della RAM? La RAM deve essere cancellata quando l'utente fa clic su "arresto" o se avvia uno "script di panico".

Grazie per il tuo impegno!

Lavoro precedente:

• Introduzione alla cancellazione della RAM della coda
• Qualche informazione in più sull'implementazione della RAM RAM Wipe
• Liberte introduzione di RAM RAM Wipe
• Ulteriori dettagli sull'implementazione di Liberte Linux RAM Wipe
• memtest non cancella tutto
• Verifica se RAM Wipe funziona
• Discussione sulla mailing list
• Un'altra discussione sulla mailing list di Tails
• Segnalazione bug del kernel

Se vuoi vedere la funzionalità diventare realtà, vota Ubuntu Brainstorm!

http://brainstorm.ubuntu.com/idea/30076/

Se non stai utilizzando la vecchia RAM come DDR2, 512 MB o 1024 MB, non dovresti preoccuparti di CBA.

Dai un'occhiata alla ricerca originale qui (PDF).

Se lo leggerai attentamente, scoprirai che solo DDR2 e precedenti sono inclini a questo attacco. DDR3 perde la tensione troppo velocemente per consentire lo smontaggio e il congelamento della custodia del computer. Quindi basta semplicemente staccare la spina prima di rispondere alla porta.

Inoltre, questo documento conferma che DDR3 non è suscettibile a un CBA. Se in realtà vuoi proteggerti perché hai la RAM DDR2, abilita nel BIOS:

1. Avvio automatico dopo perdita di potenza
2. Controllo RAM all'avvio

e fare lo stesso con DDR3 ma dopo aver staccato la spina, ricollegala. Il computer si avvierà da solo e pulirà il pistone controllandolo. Se non verrà cancellato in modo sufficientemente efficiente, il processo di avvio caricherà nuovamente il sistema nella RAM. Sarà troppo veloce per consentire CBA.

Dal link che hai fornito nei commenti:

Pertanto, in conclusione, l'attacco di avvio a freddo non deve essere considerato come il metodo principale per acquisire la memoria di un sistema di computer sospetto. Invece, altre tecniche tra cui l'acquisizione basata su software e hardware (ad esempio FireWire) dovrebbero essere tentate prima di effettuare un attacco di avvio a freddo contro detto sistema. Tuttavia, qualora si verificasse una situazione in cui le suddette tecniche non sono disponibili (ovvero la mancanza di connessione FireWire o console di accesso al sistema o acquisizione della memoria remota non è possibile) o sono inefficaci, l'attacco di avvio a freddo può essere amministrato supponendo che lo sperimentatore capisca entrambi come e dove il problema può sorgere e andare storto.
Come ha dimostrato questo studio, l'attacco di avvio a freddo non può essere considerato particolarmente forense o affidabile poiché nella maggior parte degli esperimenti condotti nel presente documento non è stato possibile trovare o estrarre coerentemente le chiavi di crittografia residenti in memoria, sebbene avrebbero dovuto essere. Lo stesso si può dire anche per le varie stringhe e ricerche di parole chiave che avrebbero dovuto presentare molte più stringhe e parole chiave rispetto a quelle trovate per la maggior parte degli esperimenti. Inoltre, come è stato dimostrato, semplicemente l'atto di congelare la memoria del computer non garantisce l'acquisizione riuscita di detta memoria. Altri fattori e variabili già esaminati hanno esaminato a fondo questi problemi e le loro cause sottostanti. Così,
Infine, anche un'acquisizione di successo che ha subito poco o nessun degrado probabilmente non reggerà in tribunale come prova valida, almeno fino a quando si è verificata la giurisprudenza e si può dimostrare che l'integrità della memoria acquisita è intatta usando un suono e metodologia comprensibile. La ricerca continua a stabilire un modo più corretto e affidabile per acquisire la memoria del computer di un sospetto ...

Inoltre, se controlli i risultati dell'esperimento, ti renderai conto che hanno estratto con successo le chiavi AES solo nel sistema 2 e 6 e quelli erano Warm Boot Attacks quando guardi le specifiche del sistema 2 - 1024 MB di RAM 533 MHz - questo è vecchio cose. L'altro sistema - sistema 6 con 256 RAM / 128 RAM - immagino che questo sia autoesplicativo.

Questo è esattamente il motivo per cui la loro conclusione è stata:

La ricerca continua a stabilire un modo più corretto e affidabile per acquisire la memoria del computer di un sospetto ...

In realtà credo che se si dispone di dati molto, molto importanti, non si dovrebbe solo utilizzare la crittografia Full Drive, ma anche conservarli in un file crittografato separato. Crittografato con algoritmi in cascata e una password diversa da quella utilizzata durante la crittografia del disco. Vuoi un modo sicuro per spegnere il PC? Ecco qui:

1. Conserva i dati protetti nel file crittografato con algoritmo a cascata True Crypt
2. Usa il serpente
3. Crea uno script per gestire l'arresto:

Per Windows:

truecrypt.exe /wipecache
shutdown -s -f -t 1

Per Linux:

truecrypt /wipecache
shutdown -h now

Cancella cache assicura che nessun dato vulnerabile rimanga nella RAM dopo l'arresto. Se qualcuno eseguirà Cold Boot Attack, avrà accesso al tuo sistema al meglio. Non avranno i dati memorizzati in un file crittografato separatamente.

Peter AH Peterson della UCLA ha scritto una tecnologia di prova del concetto e ha sviluppato la teoria per il funzionamento sicuro del sistema con RAM crittografata, e la soluzione è espressamente progettata per prevenire attacchi di avvio a freddo. Il nome del suo documento è Cryptkeeper. Non so se rende il software disponibile per il download o se è possibile concederlo in licenza dall'UCLA. Tuttavia, è apparentemente possibile, almeno in linea di principio, progettare un cryptosystem per RAM che sia sicuro anche se viene divulgato l'intero contenuto della RAM.

L'impatto sulle prestazioni misurato di questa soluzione è compreso tra un sovraccarico del 9% e un rallentamento di un fattore 9 , a seconda di quanto "patologico" sia lo scenario. La cifra del 9% viene citata come applicabile alla navigazione sul Web con Firefox, ma non hanno indicato quale caso d'uso rallenterebbe le prestazioni di un fattore 9.

La soluzione di Peterson non "cancella" la RAM come suggerito. Piuttosto, utilizza un "meccanismo sicuro di occultamento delle chiavi" per impedire che la chiave di decrittazione venga divulgata solo in virtù dell'ottenimento del contenuto della RAM. Non sono sicuro dei dettagli dell'attuazione, ma presumo che sia spiegato nel documento.

L'articolo è stato pubblicato nel 2010.

È disponibile per l'acquisto sul sito Web ieeexplore di IEEE. È anche disponibile per il download diretto in formato PDF gratuitamente dal sito Web di qualcuno; è lassù nei risultati di ricerca di Google per "RAM cryptkeeper" ... ma non sono sicuro per quanto tempo quel risultato rimarrà lì.

Sono stato tentato di fare questo un commento piuttosto che una risposta, perché questa soluzione non "cancella" la RAM come hai chiesto. Tuttavia, credo che se la ricerca di Peterson è tecnicamente corretta, ciò avrà lo stesso effetto pratico - o forse anche un effetto "migliore" rispetto alla pulizia della RAM. Il motivo è che un abile attaccante fisico potrebbe probabilmente interrompere il tentativo del programma di sistema di cancellare la RAM se si aspettava che si verificasse tale operazione, ad esempio estraendo la batteria dall'unità o tenendo premuto il pulsante di accensione prima che l'operazione possa completare. La soluzione di Peterson è più sicura perché non si basa su una finestra temporale necessaria sotto la quale il computer è autorizzato a continuare a eseguire le istruzioni per completare la cancellazione. Invece, la memoria è costantemente protetto, anche se la CPU stessa viene istantaneamente uccisa da un'incredibile prodezza della tecnologia prima ancora che tu abbia la possibilità di reagire all'attaccante.

E per "incredibile prodezza della tecnologia" intendo qualcosa come Stuxnet.

Immagino che memtest86 sarebbe abbastanza bravo a cancellare la RAM. Ho sempre voluto provare il seguito ma non l'ho fatto. Se lo provo lo aggiornerò.

Leggi la kexecpagina man . E non provare a kexec.iso, ma devi decomprimere l'iso e catturare il binario di avvio. Sul sito memtest86 sopra puoi semplicemente scaricare il binario.

Devi usare un kexeccomando per caricare prima quello che stai avviando.

Quindi penso che quello che puoi fare sia:

kexec -l {path-to-memtest86-bootable-binary} --append=console=ttyS0,115200n8

e quando sei pronto a premere il grilletto:

kexec -e

Sto pensando (ma potrebbe essere sbagliato) che --append=console=ttyS0,115200n8memtest86 funzioni sulla porta seriale. Quindi, se ne hai uno, puoi verificare che funzioni anche se non viene visualizzato sull'uscita video, il che è una possibilità poiché memtest86 non esegue l'inizializzazione del video. Uccidere qualsiasi istanza in esecuzione di X è probabilmente una buona idea.

Il kexec-toolspacchetto Debian (disponibile anche su Ubuntu) lo aggancia negli script di spegnimento, quindi se si modifica /etc/default/kexecè possibile dire al processo di spegnimento di invocare kexeccome ultima cosa invece di riavviare. Cioè, se sei interessato a un arresto pulito.

In caso di emergenza, sync; kexec -efunzionerebbe.

Tuttavia, è possibile che alcuni chipset, una volta inizializzati, causino blocchi se vengono indirizzate determinate aree della memoria. Non so come funzionerebbe in pratica.

Un buon compromesso se kexecnon funziona è installare memtest86 sul bootloader, metterlo come elemento di avvio predefinito e avere un ritardo di 1 secondo fino alla scelta automatica (o nessun ritardo e fare affidamento su un tasto premuto per far apparire il memu). Questo potrebbe farti entrare in memtest86 da una condizione di "nuovo avvio" abbastanza rapidamente, ma non istantaneamente.

Si noti che ciò non tiene conto della RAM video. Una soluzione è quella di configurare la RAM video come dispositivo a blocchi e inviarla /dev/randomal dispositivo a blocchi per alcune iterazioni.

Questa è una vecchia domanda ma penso di poter contribuire. Come detto prima, una cancellazione della memoria basata su software non è la soluzione migliore, semplicemente perché l'alimentazione può essere improvvisamente interrotta, quindi il software di cancellazione non verrà eseguito.

Posso immaginare lo scenario migliore per illustrare il problema: gestisci attività illegali sul tuo computer di casa. Un giorno, l'energia elettrica scompare improvvisamente, e poi una squadra dell'FBI fa irruzione nella porta di casa tua, ti arresta e poi un tecnico secchione apre rapidamente il case del tuo computer e usa al suo interno un gas freddo per congelare lo stato della memoria per acquistare un po ' tempo di fare un attacco di avvio a freddo.

Quindi, il modo migliore per risolvere questo problema è rendere più sicuro il case del computer, rendendo difficile l'apertura (qualcosa come un caveau) o persino distruggere la memoria riscaldando la scheda usando una resistenza a batteria, accesa da un tamper passare al caso. Pochi secondi ad alte temperature possono distruggere i dati o persino distruggere i chip, in questo caso la strega non è un grosso problema.

Il problema è se il computer è in esecuzione e lo schermo è bloccato. A questo punto, la chiave AES è memorizzata nella RAM e l'utente è lontano dal computer. Un intruso potrebbe aprire il case del computer e rimuovere i moduli RAM, mantenendoli alimentati e collocandoli in un dispositivo separato che legge il loro contenuto. Non è necessario arrestare il sistema o congelare i moduli prima dell'estrazione. La RAM non è affidabile per contenere la chiave AES, ma la cache del processore lo è, come la soluzione denominata TRESOR. Sfortunatamente ciò richiede un vecchio kernel Linux e una conoscenza avanzata delle patch e della compilazione del kernel.

Scusa, ma sei paranoico. In primo luogo, come indicato da altri utenti, apparentemente Cold Boot Attack funziona solo su hardware meno recente.

Se pensi ancora che sia una minaccia, la pulizia non è la soluzione.

Il Cold Boot Attack prevede:

• avvio a freddo della macchina
• l'avvio di un sistema operativo leggero per eliminare le chiavi di crittografia dalla memoria

Se qualcuno riesce a eseguire l'avvio a freddo, ovviamente il tuo tergicristallo non avrà l'opportunità di correre. Quindi non ha senso installarne uno.

Questo è il caso principale dell'attacco. Supponiamo ora che l'attaccante non voglia riavviare a freddo se stesso il server in esecuzione (ad es. Perché ciò innescherebbe un avviso di monitoraggio), invece aspetta di eseguire l'attacco entro 5 'da un arresto pulito. In questo caso:

• Un wiper RAM generico non ti farà bene. Poiché si presume che l'attaccante sia fisicamente presente al fine di accendere la macchina e cercare i tasti, può anche avviare a freddo la macchina appena prima che il tergicristallo inizi a funzionare. (Sono previsti avvisi di monitoraggio a questo punto.)
• Un programma specializzato che prima cancella la posizione esatta delle chiavi di crittografia FS prima di cancellare il resto della RAM (ad esempio truecrypt /wipecachemenzionato da mnmnc) potrebbe rendere più difficile il lavoro dell'attaccante. Ancora:
  • L'attaccante sarebbe comunque in grado di recuperare parte del contenuto della RAM non lasciando che il tergicristallo passi attraverso l'intera RAM. Ma almeno la maggior parte dei dati sull'FS sarebbe al sicuro.
  • La soluzione non sarebbe infallibile al 100%, ma renderebbe solo più difficile per l'attaccante il cronometraggio dell'avvio a freddo.

Quindi, se sei davvero preoccupato per questo attacco, ti suggerirei di imparare il kung-fu e stare in guardia per 5 'vicino alla macchina ogni volta che lo spegni. O forse utilizzare una password di avvio nel BIOS? Entrambe le misure suggerite non devono essere efficaci al 100%: gli aggressori potrebbero comunque batterti e leggere la password del BIOS dal tuo MB usando mezzi tecnici. Devi solo ritardarli di 5 'in modo che la finestra temporale di attacco scada.

Alla fine, se sei preoccupato per qualcuno che esegue l'intera impresa da remoto, sei già messo duro.