In pratica, è quasi resistente con la crittografia come senza, purché esegua correttamente il backup della chiave principale e dei metadati .
A parte i metadati, la corruzione interesserebbe solo il blocco del bit corrotto, nella maggior parte dei casi solo 16 byte.
Per la maggior parte delle situazioni di corruzione dei dati, con la chiave e gli strumenti (come password e Veracrypt / LUKS), si ha lo stesso accesso di un disco non crittografato, proprio come si fa normalmente con l'uso quotidiano di un disco crittografato. La crittografia aggiungerebbe solo un passaggio aggiuntivo (aprire una partizione crittografata) rispetto al normale. Quindi, in questo caso, si comporta proprio come i dati non crittografati.
Con Veracrypt o Luks, devi archiviare la chiave principale sul disco, che è crittografata con la tua password. Danneggiare questo / i settore / i causerebbe la perdita permanente dei dati. Questo può essere facilmente risolto con il backup della chiave principale (pochi kilobyte di dimensione), qualcosa di facile da fare con entrambi i software ed è altamente raccomandato a tutti.
Dettagli su non metadati
Sia Veracrypt che Luks usano XTS oggi. In questa modalità, viene calcolata una chiave per ogni blocco. In una semplificazione, per crittografare il blocco isi utilizza una chiave generata con le chiavi master e il numero di blocco. Quindi, la crittografia di un blocco in modo indipendente da un altro. Se si corrompono alcune informazioni, saranno limitate a quel blocco.
In XTS, rompe il blocco in sottoblocchi (di solito di 16 byte) e crea una chiave e crittografa quel blocco secondario con esso. Ciò significa che se cambiamo un po 'su di esso, solo questi 16 byte sarebbero interessati.
Come test, cambiando un singolo bit in un volume Luks, cambia in modo incomprensibile 16 byte del file originale, ma gli altri 496 rimangono invariati. In un file 7zip, utilizza un metodo stream, in modo che tutti i byte siano concatenati, quindi una modifica di byte influirebbe su tutti i restanti - questo non è il caso qui.
Alcuni considerano questo un problema, come puoi sapere con precisione di 16 byte quando e dove si modifica un testo semplice, confrontando solo i dati crittografati.
Informazioni più interessanti al riguardo sono disponibili su questi collegamenti:
/crypto/6185/what-is-a-tweakable-block-cipher
/security/39306/how-secure-is-ubuntus-default-full-disk-encryption
https://en.wikipedia.org/wiki/Disk_encryption_theory
Dettagli sulla chiave principale
LUKS
LUKS ha alcuni settori all'inizio della partizione (o del disco) con metadati, che memorizzano metodi di crittografia, altri parametri e 8 slot chiave. Per crittografare e decrittografare il disco, utilizza una chiave master , un grande numero casuale generato durante la creazione di un contenitore LUKS. Per memorizzarlo, crittografa la chiave master con la tua password, attraverso l'iterazione di una funzione hash crittografica molte volte sulla password e la generazione di una chiave specifica per quello slot. Puoi avere 8 password diverse per lo stesso disco, ognuna crittografando la chiave master con una password diversa in uno slot. Quando si modifica la password, è semplice come crittografare la chiave master e non modificare tutta la partizione.
Pertanto, quando questi slot e metadati sono danneggiati, non è possibile ripristinare la chiave principale utilizzata per decrittografare, perdendo tutti i dati sul disco. Questo è un modo semplice per distruggere rapidamente tutti i tuoi dati. Ma se si dispone di un backup dell'intestazione del volume, è abbastanza facile recuperarlo.
Di seguito è una copia delle FAQ LUKS sul backup estratto da https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery
6.2 Come si esegue il backup di un'intestazione LUKS?
Mentre potresti semplicemente copiare il numero appropriato di byte dall'inizio della partizione LUKS, il modo migliore è usare l'opzione di comando "luksHeaderBackup" di cryptsetup. Ciò protegge anche dagli errori quando sono stati utilizzati parametri non standard nella creazione della partizione LUKS. Esempio:
cryptsetup luksHeaderBackup --header-backup-file <file> <device>
Per ripristinare, utilizzare il comando inverso, ad es
cryptsetup luksHeaderRestore --header-backup-file <file> <device>
Se non sei sicuro di ripristinare un'intestazione, esegui prima un backup di quella corrente! Puoi anche testare il file header senza ripristinarlo usando l'opzione --header per un'intestazione staccata come questa:
cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>
Se questo sblocca le tue chiavi, sei a posto. Non dimenticare di chiudere di nuovo il dispositivo.
In alcune circostanze (intestazione danneggiata), ciò non riesce. Quindi utilizzare i seguenti passaggi:
Per prima cosa determinare la dimensione della chiave principale:
cryptsetup luksDump <device>
fornisce una riga del modulo
MK bits: <bits>
con bit pari a 256 per i vecchi valori predefiniti e 512 per i nuovi valori predefiniti. 256 bit equivalgono a una dimensione totale dell'intestazione di 1'052'672 byte e 512 bit uno di 2 MiB. (Vedi anche la voce 6.12) Se luksDump fallisce, supponi 2MiB, ma tieni presente che se lo ripristini, puoi anche ripristinare i primi 1M circa del filesystem. Non modificare il filesystem se non sei riuscito a determinare la dimensione dell'intestazione! Con ciò, il ripristino di un backup dell'intestazione troppo grande è ancora sicuro.
In secondo luogo, scaricare l'intestazione su file. Esistono molti modi per farlo, preferisco quanto segue:
head -c 1052672 <device> > header_backup.dmp
o
head -c 2M <device> > header_backup.dmp
per un'intestazione da 2 MiB. Verificare la dimensione del file di dump per essere sicuri. Per ripristinare un backup di questo tipo, puoi provare luksHeaderRestore o eseguirne uno più semplice
cat header_backup.dmp > <device>
veracrypt
Veracrypt è simile a LUKS. Non ci sono abituato come in Truecrypt, ma l'idea generale vale.
Veracrypt ha solo uno slot chiave, quindi non puoi avere più di una password contemporaneamente. Ma puoi avere un volume nascosto: memorizza i metadati alla fine della partizione (o disco o file). Il volume nascosto ha una chiave master diversa e utilizzerà la fine della partizione come spazio sovrapposto. L'idea che è necessario eseguire il backup è la stessa. Questo può essere fatto con Tools -> Backup Volume Headere Tools -> Restore Volume Header. Con la crittografia di sistema, veniva utilizzato per creare un disco di avvio con backup delle chiavi che ripristina il caricatore e le chiavi Truecrypt in caso di danni. Viene fatto prima di crittografare qualsiasi cosa, e per quanto ne so Veracrypt continua a fare allo stesso modo.
Per maggiori dettagli vedi questo link https://veracrypt.codeplex.com/wikipage?title=Program%20Menu
Considerazioni sulla sicurezza delle chiavi di backup
Se hai una password trapelata, ad esempio, e cambia la password del volume con una nuova, sicura e sicura, qualcuno con accesso al backup sarebbe comunque in grado di decrittografare i file con la vecchia password. Il backup è fondamentalmente la chiave master crittografata con la (vecchia) password. Quindi, quando si cambiano le password, è anche necessario creare un nuovo backup e distruggere quelli più vecchi. E distruggere i dati in modo permanente può essere molto complicato.
Per ogni backup che hai con quella password, è un modo possibile per decrittografare i dati con quella password. Questo può essere usato ad esempio in Veracrypt, usando una "Universal Password" (come in una società), eseguendo il backup e cambiando per un'altra password. Quindi il reparto IT. potrebbe recuperare l'accesso a quel volume anche se qualcuno ha perso la password (pensa come una password principale, ma non confondere con la chiave principale di prima).
Considerazioni finali (TL; DR)
La probabilità di danneggiare il settore specifico con la chiave master è meno probabile di un errore del disco completo. Quindi, se questi dati sono importanti, dovresti avere un backup invece delle intestazioni del volume (chiave master).
E la corruzione dei dati si è diffusa poco (16 byte), risultando accettabile per la maggior parte degli usi.
Quindi un blocco danneggiato nel mezzo della partizione o del disco influirebbe solo su quel blocco. E alcuni bit di errori in un settore sono limitati a quel settore e non influiranno nemmeno totalmente su un settore di 512 byte.
Aggiornamento (23/01/2017): aggiungere ulteriori informazioni in base ai commenti del PO.