Come cancellare i dischi prima della crittografia con dm-crypt se CBC o XTS sono utilizzati internamente?

2

In primo luogo, ti prego di perdonarmi se sto postando questa domanda alla comunità sbagliata. Sentiti libero di migrare questo post nella community giusta se mi sbaglio.

Sono abbastanza nuovo per l'intera crittografia del disco (ma non per la crittografia), specialmente con dm-crypt. Attualmente sto eseguendo Arch Linux e ho letto la documentazione dedicata a quella distribuzione GNU / Linux. Per favore correggimi se sbaglio nell'ipotesi che faccio nel seguente sommario: voglio iniziare la mia conoscenza su solide basi. ; -)

Ci , i writter / manutentori wiki ci consigliano di preparare prima il disco. vale a dire rimuovere / cancellare tutto il contenuto precedente. Questo è necessario per 2 motivi:

  • (ovviamente) impedisce il recupero dei vecchi dati presenti sul disco;
  • Ancora più importante, impedisce al disco di rivelare il modello di utilizzo.

Ho compreso il secondo punto in quanto: poiché la crittografia crittografa solo i nuovi blocchi di dati che scriviamo, dobbiamo cancellare in modo sicuro i dati precedenti in modo da evitare di visualizzare a un possibile utente i limiti del contenitore crittografato. Se avessimo invece scritto zero, un attaccante potrebbe realizzare e pensare in questo modo "guarda, vediamo la spazzatura qui, e lì, è tutto pieno di zeri, so dove mantenere la mia attenzione per cercare di decifrare i dati".

Anche la stessa documentazione di Arch Linux spiega la modalità di crittografia CBC (Cipher Block Chaining). Secondo quanto ho capito, questo metodo utilizza i settori fisici e li divide in base alla dimensione della dimensione del blocco utilizzata dall'algoritmo. Ad esempio, se prendiamo AES che utilizza un blocco di dimensioni di crittografia a 128 bit e abbiamo un settore fisico di dimensione 512 ottetti (a parte il formato avanzato), il calcolo per determinare il numero di blocchi sarebbe 512 * 8 bit = 4096/128 = 32 blocchi. Dove viene utilizzato un blocco del settore per IV (vettore di inizializzazione). Se CBC viene utilizzato con dmcrypt, ciò significa che lo stesso contenuto non crittografato apparirà crittografato in modo diverso su due diverse posizioni sul disco. In questo modo, quando prepariamo il disco per la crittografia, possiamo cancellare il contenuto del disco creando innanzitutto un contenitore crittografato e riempiendolo con zeri. Se viene utilizzato CBC, gli zero verranno visualizzati in modo diverso sul disco in ciascuna posizione. Se CBC non viene utilizzato, dobbiamo effettivamente utilizzare urandom.

Dopo alcune domande su IRC, sembra che questo sia XTS che viene usato di default con dm-crypt. Secondo quanto ho capito, XTS è solo una variante di CBC che consente di dividere le dimensioni del settore fisico in base alla dimensione della dimensione del blocco dell'algoritmo utilizzato indipendentemente dalla sua dimensione (ad esempio: se un blocco di 512 settori non è divisibile dal 128 bit dell'algoritmo AES, XTS consentirebbe quello).

EDIT : xts non è in realtà il valore predefinito, questo dipende da come dmcrypt è stato compilato nella distribuzione GNu / Linux. Per vedere quali algoritmi e dimensioni delle chiavi vengono utilizzate, digita semplicemente

$ cryptsetup --help
[...]
Default compiled-in device cipher parameters:
        loop-AES: aes, Key 256 bits
        plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
        LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom

Quindi, prima di correggere il wiki di Arch Linux, voglio essere sicuro di cosa viene effettivamente utilizzato dietro dm-crypt: CBC o un altro metodo di crittografia? Perché in questo caso è consigliabile non utilizzare mai zeri con dm-crypt, ma tale motivo è sbagliato poiché i dati non crittografati vengono visualizzati crittografati in modo diverso su due diverse posizioni del disco. Se non si usa CBC o una variante, dovrò correggere l'ipotesi descritta nella pagina wiki "Cancellazione sicura del disco".

Inoltre, Arno Wagner, il maintainer delle FAQ di dmcrypt ufficiale, descrive nel punto 2.19 , che usa gli zeri direttamente sul disco può impiegare molto tempo e "Utilizzando cryptsetup e un semplice dispositivo dm-crypt con una chiave casuale, è molto più veloce e offre lo stesso livello di sicurezza."

Quindi aggiunge il seguente comando per digitare: cryptsetup open --type plain -d /dev/urandom /dev/<block-device> to_be_wiped , ma sta ancora usando urandom e non zero. Non riesco a capire perché non stia usando gli zero invece e perché usare urandom in un contenitore sarebbe molto più veloce di fuori del contenitore, direttamente sul disco.

EDIT : Ok, Argo ha aggiunto una precisione nelle sue FAQ. -d /dev/urandom è appena usato come password casuale per la crittografia.

Inoltre, dal momento che ho bisogno di installare la crittografia su 3 macchine differenti utilizzando 3 tipi di dispositivi: un SSD nuovo di zecca, un SSD già utilizzato e un HDD standard. Dato che gli SSD usano il flash, non so come preparare il disco. La domanda è ancora presente con il nuovo SSD, devo prima cancellarlo con valori casuali? Per quanto riguarda TRIM, Linux è abbastanza intelligente da capire che non deve utilizzare TRIM poiché questo indebolisce la crittografia?

L'aiuto è molto apprezzato.

    
posta wget 23.08.2015 - 18:40
fonte

1 risposta

0

Se l'algoritmo di crittografia è abbastanza strong, l'utilizzo di un nuovo SSD incontaminato non dovrebbe comportare problemi di sicurezza, dal momento che tutti i file che si eliminano all'interno del contenitore saranno comunque crittografati sul disco, quindi anche se parti di file rimangono inutilizzate o celle flash non disponibili, queste parti sono ancora crittografate. Un pericolo, tuttavia, è se si decide di cambiare la chiave di decrittazione o la password. Ciò potrebbe causare la decrittazione di alcuni o tutti i dati sul disco con la vecchia chiave / password compromessa possibile.

Ovviamente qualsiasi cambiamento di chiave / password dovrebbe essere eseguito eseguendo il backup sicuro dei dati, quindi cancellando in modo sicuro l'unità (non il contenitore). Quindi creare un nuovo contenitore sull'unità con la nuova password, spostare indietro i dati di backup. Quindi eseguire una cancellazione sicura sul supporto utilizzato per il backup. Fatto, la modifica della password è completata.

Quando si tratta di dischi usati, indipendentemente dal loro SSD o HDD, la domanda principale è: ha fatto o contiene informazioni sensibili dall'uso precedente. Se la risposta è no, è sufficiente scrivere un passaggio di zero per "svuotare" il disco e quindi installare il contenitore. Tieni presente che la maggior parte del software del contenitore continuerà a crittografare lo spazio libero nel contenitore, quindi da una vista esterna, il contenitore mostrerà comunque dati casuali anche nelle parti inutilizzate del contenitore.

Tuttavia, se le unità contengono già informazioni sensibili, è necessario "prepararle" bene. Gli SSD sono costruiti in modo tale da non poterli cancellare dall'esterno. Molti SSD più recenti, a tale scopo, hanno un comando ATA interno chiamato "cancellazione sicura", che eseguirà una cancellazione, normalmente cancellando una chiave di crittografia utilizzata per la crittografia hardware integrata. Ciò renderà inaccessibile qualsiasi vecchio contenuto. Se l'unità segnala che il comando "Cancellazione sicura" non è disponibile o non è supportato, l'unico modo per liberarsi in modo sicuro dei dati è inviare l'unità a una funzione di eliminazione dati o distruggere l'unità autonomamente.

Tuttavia, gli HDD possono essere cancellati in modo sicuro. Raccomanderei il metodo "DoD Short" all'interno del software DBAN (Dariks Boot e Nuke), che scriverà 2 passaggi di dati pseudocasuali e un passaggio di zero (per preparare il disco per ulteriore utilizzo) al disco. Verificherà inoltre che Tutto è veramente zero per garantire che il disco non abbia errori troppo gravi. In tal caso, DBAN solleverà un errore, in base a tale errore, l'unico modo è quello di inviare l'HDD fisico a un impianto di smaltimento o di effettuare una distrozione autonoma dell'unità.

DoD Short, è sufficiente per "dati personali personali". È possibile recuperare l'unità in un laboratorio, utilizzando microscopi magnetici altamente specializzati, in grado di leggere le sottili differenze di "usura" magnetica della cella magnetica in questione, e quindi scoprire quante volte un "uno" (1) e quante volte uno "zero" (0) è stato scritto su quella cella, e quindi usa equazioni, calcoli e propabilità, in combinazione con formati di file e formati di dati noti, per recuperare dati parziali o tutti i dati. Si noti che i dati parziali potrebbero essere anche sfavorevoli, immagina di recuperare 100 bit di una chiave a 128 bit. Gli ultimi 28 bit sarebbero abbastanza facili da decifrare.

MA : un lavoro di recupero del genere costa dieci dollari di dollari. Ecco perché DoD Short va bene per i dati personali personali e "dati non classificati". Perché nessuno spende dieci-tousands di dollari per FORSE ottenere l'accesso al tuo conto bancario con poche migliaia o migliaia di dollari. Il rischio è troppo alto e la vincita è troppo bassa.

Tuttavia, se i dati sono MOLTO sensibili, diciamo che lavori per militari. Poi qualche governo potrebbe voler spendere dieci-tousands di dollari per recuperare le tue informazioni. Quindi dovresti usare schemi di cancellazione più lunghi come lo standard DoD (7 passaggi), che cancellerà i dati più vicino a quelli irrecuperabili.

    
risposta data 14.09.2015 - 08:29
fonte

Leggi altre domande sui tag