Rimedio per non aver riempito il disco con dati casuali?

Are there any steps that can be taken after the HDD has been encrypted to make it harder to perform cryptanalysis on the disk?

Poiché il disco è già crittografato, suggerirei di riempire lo spazio restante del filesystem con dati (casuali), ad es. pipe / dev / urandom in un file (che puoi eliminare in seguito). In questo modo il dispositivo (di blocco) sottostante si riempirà di dati crittografati ("rumore").

So in the more realistic case, would it help to fill the disk with data after it has been encrypted?

Sì, sarebbe d'aiuto - vedi sopra.

Imagine the disk has actually been filled to the maximum capacity after it has encrypted, what value does then the prior filling with random data before encryption hold?

Bene, farlo prima che la crittografia iniziale ti proteggesse dal dimenticarlo in seguito. Cioè impostando la crittografia completa del disco al mattino e "Riempirò il disco più tardi questa sera", ma poi il disco è stato rubato in mezzo.

Nota: anche dopo aver completato la crittografia completa del disco, il controller del disco potrebbe non essere in grado di azzerare ogni parte del disco, vedere Data_remanence per ulteriori dettagli su questo argomento.

L'unica informazione che un utente malintenzionato dovrebbe essere in grado di estrarre da un disco crittografato che non ha avuto una sovrascrittura casuale completa è un limite superiore alla quantità di informazioni crittografate sul disco.

Per dirla in altro modo, una buona soluzione di crittografia del disco non dovrebbe fare affidamento sull'incapacità di un utente malintenzionato di determinare i limiti della partizione crittografata per qualsiasi proprietà di sicurezza.

Sono d'accordo che riempire il disco con i dati dopo la crittografia dovrebbe produrre il risultato che ci si aspetta (a condizione che la partizione crittografata possa espandersi dinamicamente per riempire l'intero disco): tutti i dati sul disco ora dovrebbero apparire casuali (meno partizione tabella ecc. a seconda della soluzione).

Filling a large HDD with /dev/urandom prior to encryption can be extremely slow (even with netcat, multiple instances in parallel, etc) and for this reason I'm sure a lot of users skip this advice even if it is recommended practice and unsafe to omit.

Sui nuovi kernel di Linux, il dispositivo /dev/urandom usa ChaCha20 per casualità, piuttosto che una più lenta funzione di mixaggio SHA1, permettendogli di essere molto, molto veloce. Se non hai un kernel più recente, una soluzione semplice è usare OpenSSL o dm-crypt per creare casualità.

OpenSSL è il più semplice, richiede un solo comando:

openssl aes-128-ctr -nosalt -in /dev/zero -out /dev/sdX -k $(head -c16 /dev/urandom | base64)

L'utilizzo di dm-crypt è più complesso, ma spesso può utilizzare una crittografia accelerata dal kernel più veloce:

cryptsetup open -M plain -c aes-cbc-plain -s 128 -d /dev/urandom /dev/sdX wipeme
cat /dev/zero > /dev/mapper/wipeme
cryptsetup close wipeme

My question is: Assume a user has omitted this step of filling the disk with /dev/urandom, or only done it partially. Are there any steps that can be taken after the HDD has been encrypted to make it harder to perform cryptanalysis on the disk?

Innanzitutto, il problema non è che semplifica la crittanalisi . AES non è così debole che solo un gigabyte di testo in chiaro noto porta al recupero delle chiavi. Alcuni dei PRNG più potenti generano dati casuali crittografando un flusso nullo con una chiave casuale. Il problema è piuttosto una perdita di metadati a livello di file system (sapendo quali blocchi sono liberi e quali no), che fornisce il layout generale del filesystem. Questo può far trapelare non solo quanto spazio è stato utilizzato, ma molte più informazioni come dimensioni dei file, posizioni, possibili azioni precedenti eseguite sui file e altro. Ci sono stati casi di arresti e condanne basati solo su metadati di un file crittografato (ad esempio, dimensioni).

I'm assuming the best case scenario for the attacker would be if the user filled the entire disk with /dev/zero and then encrypted it? Would it then help if the user filled the entire disk (after having encrypted it) by writing /dev/zero to some arbitrary file in the file system, then deleted the file to recover the 'used' space? Wouldn't this remove any stray null bytes on the device and replace everything with just encrypted data?

Sarebbe bello fare, sì. Non è perfetto, perché ci saranno ancora aree del filesystem che non verranno cancellate anche se riempite. Ad esempio, l'utente non root non può sovrascrivere l'ultimo 5% di spazio su un filesystem ext4 per impostazione predefinita. E nessun utente può sovrascrivere determinati campi di metadati che potrebbero non essere inizializzati quando viene creato il filesystem e lasciati come byte null. Dovresti esaminare il formato su disco e le tecniche di formattazione utilizzate dal tuo particolare filesystem per capire quali campi non possono essere inizializzati e potrebbero perdere informazioni sensibili. Poiché questo è spesso un compito così complesso, in genere è più facile iniziare con un dispositivo a blocchi casuali.

Un post molto utile per comprendere il problema lasciando alcuni dati non crittografati è qui . Il post riguarda specificamente TRIM su SSD, ma l'effetto è lo stesso, poiché i blocchi di zeri TRIM che vengono liberati perdono informazioni su quali blocchi sono liberi e quali no. Questo potrebbe anche rispondere alla tua domanda su come questo si applica agli SSD.