Pre-encryption wipe, why?
I wanted to know why, before encrypting and installing itself on the drive , Kali :
- wiped the whole drive
- filled the drive with 0s
- filled the drive with 1s
- filled the drive with Random data
- wiped the drive again
I know that Kali isn’t meant to be installed, but that’s not the point here.
So, how is this useful before installing, say on a brand new HDD? I’m used to see that on HDD removal, not install.
There is no point in doing multiple passes. Once is enough.
Filling a to-be-encrypted drive with random data mainly has two uses:
- get rid of old, unencrypted data
- make free space indistuingishable from encrypted data
Usually if you encrypt you don’t want anyone to see your data. So chances are, if you had old, unencrypted data on this drive, you want to get rid of it too. An SSD might take care of it easier and faster with
blkdiscard. In fact, Linux
mkfs TRIMs all data without even asking you for confirmation, which makes any kind of data recovery impossible. There is too much TRIM in Linux.
Free space is a bit of a grey area. If you don’t pre-fill with random data, on a brand new HDD, sectors that were never written to will be zeroes. On a SSD, if you allow discard/TRIM, free space will also be zero.
While this does not affect your data in any way (it’s still encrypted), it reveals how much free space/actual data you have, and where this free space/data is located. For example a
hexdump -C of an encrypted, trimmed SSD will look somewhat like this:
# 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.._......%..| -- ...
From this you can tell I have free space segments at address
0xb3eac000 .. 0xb3f70000,
b3f71000 .. b3f72000, … and the inverse of that is of course data segments like
0xb3f70000 .. b3f71000.
What can you do with it? Well, nothing(*).
(*) is what I’d like to say. But people get creative. Free space patterns can be used to derive the type of filesystem you use (due to how/where they store metadata – if there is free space where
ext4 would store one of its metadata backups, it’s very likely not
ext4, etc.). Sometimes it even reveals which distribution you use (if your Linux installer fills the filesystem deterministically, files might always end up at the same physical addresses). At that point someone might know where a specific system file is located and could modify/damage it in some way. (Installers should randomize the way they populate filesystems to prevent this.)
However such considerations are very theoretical, and very low risk compared to how vulnerable most encrypted installations are due to other reasons. In most out of the box installs, it’s more likely / simpler to just tamper with the initramfs, or install a keylogger, or exploit the running system, than somehow get raw access to and analyze encrypted data and hope to achieve anything this way.
You should worry about these first before worrying about revealing free space.
With SSD, it’s completely normal to enable TRIM and thus have free space revealed at all times. This is also the case for encryption solutions that work on a file layer rather than block layer.
With HDD, you mainly do the random wipe even on a new disk because you can, and there is no reason not to as it involves no cost (aside from a first-time setup) and no downsides.