Cancellazione pre-crittografia, perché?


25

Volevo sapere perché, prima di crittografare e installarsi sull'unità, Kali:

  1. cancellato l'intero disco
  2. riempito il disco con 0s
  3. riempito il disco con 1s
  4. riempito il disco con dati casuali
  5. cancellato di nuovo l'unità

So che Kali non è pensato per essere installato, ma non è questo il punto.

Quindi, come è utile prima dell'installazione, diciamo su un nuovissimo HDD? Sono abituato a vederlo sulla rimozione dell'HDD, non sull'installazione.


I passaggi 1-3 sembrano simili a ciò badblocksche controlla i settori danneggiati, scrivi e controlla 0, 1, 01, 10. Per la crittografia dell'intero disco, è comune a raccomandare un crittografato riempimento di zeri (per scrivere i dati crittografati ovunque) per i motivi in risposta di frostschultz (+1), ma facendo tutto questo prima di crittografia è insolito, dopo la crittografia poi correre badblockso mkfs di -ccsarebbe realizzare lo stesso, oltre a identificare blocchi danneggiati. Forse qualcuno di Kali è un po 'paranoico sulla memoria flash (USB, SSD) non sempre scrivendo lo stesso settore nello stesso posto e scambiando i settori da / verso i backup
Xen2050,

Risposte:


36

Non ha senso fare più passaggi. Una volta è abbastanza.

Riempire un'unità da crittografare con dati casuali ha principalmente due usi:

  • sbarazzarsi di dati vecchi e non crittografati
  • rendere lo spazio libero indistinguibile dai dati crittografati

Di solito se crittografate non volete che nessuno veda i vostri dati. Quindi è probabile che, se avessi dati vecchi e non crittografati su questa unità, anche tu vuoi sbarazzartene. Un SSD potrebbe occuparsene più facilmente e più velocemente blkdiscard. In effetti, Linux mkfsTRIMs tutti i dati senza nemmeno chiederti conferma, il che rende impossibile qualsiasi tipo di recupero dei dati. C'è troppo TRIM in Linux.

Lo spazio libero è un po 'di un'area grigia. Se non si effettua il pre-riempimento con dati casuali, su un nuovissimo HDD, i settori in cui non è mai stato scritto saranno zero. Su un SSD, se si consente di eliminare / TRIM, anche lo spazio libero sarà zero.

Sebbene ciò non influisca in alcun modo sui tuoi dati (è ancora crittografato), rivela la quantità di spazio libero / dati effettivi che hai e dove si trova questo spazio libero / dati. Ad esempio, un hexdump -CSSD crittografato e tagliato apparirà in qualche modo simile a questo:

# hexdump -C /dev/ssd | grep -C 2 '^\*'
...
--
b3eabff0  dc c9 c7 89 16 ca d3 4f  a3 27 d6 df a0 10 c3 4f  |.......O.'.....O|
b3eac000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f70000  5a 99 44 b5 9c 6b 1e 9c  81 cf 9a 43 b6 23 e9 0f  |Z.D..k.....C.#..|
b3f70010  2c e6 9a 5d 59 9b 46 5f  21 3f 4d 5f 44 5b 0a 6b  |,..]Y.F_!?M_D[.k|
--
b3f70ff0  5f 63 8d e8 c4 10 fd b1  a6 17 b5 7d 4a 57 09 68  |_c.........}JW.h|
b3f71000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f72000  5d 1c 09 dd c9 6b 57 18  db 67 e1 35 81 57 45 8e  |]....kW..g.5.WE.|
b3f72010  0f a8 be 39 ae e5 5f cf  cf e3 8b a7 c1 25 1a a3  |...9.._......%..|
--
...

Da questo si può dire che ho segmenti di spazio libero all'indirizzo 0xb3eac000 .. 0xb3f70000, b3f71000 .. b3f72000, ... e l'inverso di ciò è di segmenti di dati ovviamente come 0xb3f70000 .. b3f71000.

Cosa puoi farci? Bene, niente (*).

(*) è quello che vorrei dire. Ma le persone diventano creative . I modelli di spazio libero possono essere usati per derivare il tipo di filesystem che usi (a causa di come / dove archiviano i metadati - se c'è spazio libero in cui ext4archiviare uno dei suoi backup di metadati, molto probabilmente no ext4, ecc.). A volte rivela persino quale distribuzione usi (se il tuo installer Linux riempie il file system in modo deterministico, i file potrebbero sempre finire con gli stessi indirizzi fisici). A quel punto qualcuno potrebbe sapere dove si trova un file di sistema specifico e potrebbe modificarlo / danneggiarlo in qualche modo. (Gli installatori dovrebbero randomizzare il modo in cui popolano i filesystem per impedirlo.)

Tuttavia, tali considerazioni sono molto teoriche e presentano un rischio molto basso rispetto alla vulnerabilità della maggior parte delle installazioni crittografate dovuta ad altri motivi. Nella maggior parte delle installazioni out-of-the-box, è più probabile / semplice manomettere gli initramfs, installare un keylogger o sfruttare il sistema in esecuzione, che in qualche modo ottenere un accesso non elaborato e analizzare i dati crittografati e sperare di ottenere qualcosa in questo modo.

Dovresti preoccuparti di questi prima di preoccuparti di rivelare lo spazio libero.

Con SSD, è del tutto normale abilitare TRIM e quindi avere spazio libero rivelato in ogni momento. Questo vale anche per le soluzioni di crittografia che funzionano su un livello file anziché su un livello blocco.

Con l'HDD, esegui principalmente la pulizia casuale anche su un nuovo disco perché puoi, e non c'è motivo di non farlo poiché non comporta alcun costo (a parte una prima configurazione) e nessun aspetto negativo.


1
Il taglio non cancella necessariamente tutti i flash NAND tagliati, perché alcuni potrebbero trovarsi nello stesso blocco di cancellazione di alcuni settori non tagliati. (i blocchi di cancellazione sono più grandi dei blocchi di scrittura). Anche se mkfs ritaglia un'intera partizione prima di scrivere i nuovi metadati, i dati di altre partizioni (come la partizione di sistema EFI) sono ancora attivi e il firmware SSD non è a conoscenza delle partizioni.
Peter Cordes,

Un link a en.wikipedia.org/wiki/Trim_(computing) potrebbe essere utile nella tua risposta!
Gaurav,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.