How to wipe disks before encryption with dm-crypt if CBC or XTS is used internally?

Question

First, please forgive me if I'm posting this question to the wrong community. Feel free to migrate this post to the right community if I was wrong.

I'm quite new to whole disk encryption (but not with encryption), especially with dm-crypt. I'm currently running Arch Linux and have read the documentation dedicated to that GNU/Linux distribution. Please correct me if I'm wrong in the assumption I make in the following summary: I want to start my knowledge on solid foundations. ;-)

There, wiki writters/maintainers advise us to prepare the disk first. i.e.: removing/erasing all previous content. This is necessary for 2 reasons:

• (obviously) prevent the old data residing on the disk to be recovered;
• more importantly, prevent the disk from disclosing usage pattern.

I understood the second point as it: since the encryption only encrypts new blocks of data we write, we need to securely erase previous data in a way to avoid displaying to a possible attacker the limits of the encrypted container. If we had written zeroes instead, an attackers could realize and think like this "hé, look! we see garbage here, and there, it's all filled with zeroes, I know where to keep my focus on try to decipher the data".

Also the same Arch Linux documentation explains the CBC (Cipher Block Chaining) encryption mode. According to what I understood, this method uses physical sectors and divides them by the size of the block size the algorithm uses. For example, if we take AES which uses a 128 bits encryption size block and we have a physical sector of size 512 octets (Advanced Format aside), the computation to determine the number of blocks would be 512 * 8 bits = 4096 / 128 = 32 blocks. Where one block of the sector is used for the IV (initialization vector). If CBC is used with dmcrypt this means the same unencrypted content will appear encrypted differently on two different locations on the disk. In that way, when we prepare the disk for encryption, we can erase the disk content by first creating an encrypted container and filling it with zeroes. If CBC is used, the zeroes will appear differently on the disk on each locations. If CBC is not used, we indeed need to use urandom.

After some questions on IRC, it appears this is XTS which is used by default with dm-crypt. According to what I understood, XTS is just a variant of CBC allowing a physical sector size to be divided by the size of the block size of the algorithm used regardless of its size (e.g.: if a 512 sectors block was not divisible by the 128 bits of the AES algorithm, XTS would allow that).

EDIT: xts is not actually the default, this depends on how dmcrypt has been compiled in the GNu/Linux distribution. To see which algorithms and keys sizes are being used, simply type

$ 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

Thus, before correcting the Arch Linux wiki, I want to make sure what is actually used behind dm-crypt: CBC or anther encryption method? Because it is recommended here to never use zeroes with dm-crypt, but that reason is wrong since non encrypted data appears encrypted differently on two different disk locations. If CBC or a variant is not used, I'll need to correct the assumption described on the wiki page "Securely wipe disk".

Also, Arno Wagner, the official dmcrypt FAQ maintainer, describes in the point 2.19, that using zeroes directly on the disk can take a very long time and that "Using cryptsetup and a plain dm-crypt device with a random key, it is much faster and gives you the same level of security."

He then adds the following command to type: cryptsetup open --type plain -d /dev/urandom /dev/<block-device> to_be_wiped, but he is still using urandom and not zeroes. I cannot understand why he is not using zeroes instead and why using urandom in a container would be much faster than outside the container, directly on the disk.

EDIT: Ok, Argo added a precision in his FAQ. -d /dev/urandom is just used as a random password for the encryption.

Also, since I need to install encryption on 3 differents machines using 3 kinds of devices: a brand new SSD, an already used SSD, and a standard HDD. Since SSDs use flash, I don't know how to prepare the disk. The question is still present with the new SSD, do I need to wipe it with random values first? What about TRIM, is Linux smart enough to figure out he doesn't have to use TRIM since this is weakening the encryption?

Help is greatly appreciated.

Answer 1

Provided that the encryption algoritm is strong enough, using a new pristine SSD should not incur any security problems, since any files you delete inside the container will still be encrypted on the disk, so even if parts of files linger around in unused or unavailable flash cells, these parts are still encrypted. One danger however, is if you decide to change the decryption key or password. This could cause certain or all data on your disk to still be decryptable with the old, possible compromised key/password.

Any key/password change should of course be done by securely backing the data up, then secure erase on the drive (not the container). Then create a new container on the drive with your new password, move the backed up data back. Then do a secure erase on the media used for backup. Done, password change is completed.

When it comes to used drives, regardless of if its SSD or HDD, the main question is: Did, or do, they contain any sensitive info from the previous use. If the answer is no, its enough to write one pass of zeroes to "empty" the disk, and then install the container. Note that most container software will still encrypt free space in the container, so from a outside view, the container will still show random data even in unused parts of the container.

However, if the drives did previously contain sensitive info, you need to "prepare" them well. SSDs are so constructed, that you can't really wipe them from the outside. Many newer SSDs, for this purpose, do have a internal ATA command called "secure erase", that will perform a erase, normally by erasing a encryption key used for built-in hardware encryption. This will make any old content inaccessible. If the drive reports that the "Secure Erase" command is unavailable or unsupported, only way to securely get rid of the data is to send the drive to a data disposal facility, or destroy the drive yourself.

HDDs however, can be securely erased. I would recommend the method "DoD Short" inside the software DBAN (Dariks Boot and Nuke), which will write 2 passes of pseudorandom data, and one pass of zeroes (to prepare the disk for further usage) to the disk. It will also verify that Everything really are zeroes to ensure the disk do not have too fatal errors. In that case, DBAN will raise an error, on such error, only way is to send the physical HDD to a disposal facility or distroy the drive yourself.

DoD Short, is enough for "personal private data". There is possible to recover the drive in a lab, using highly specialized magnetic microscopes, that can read the subtle differences in the magnetic "wear" of the magnetic cell in question, and thus find out how many times a "one" (1) and how many times a "zero" (0) have been written to that cell, and then use equations, calculations and propabilitys, in combination with known file formats and data formats, to recover partial or all data. Note that partial data could be distrastious too, imagine recovering 100 bits of a 128 bit key. The last 28 bits would be pretty easy to crack.

BUT: Such recovery job cost ten-tousands of dollars. Thats why DoD Short is good for personal private data, and "unclassified data". Because nobody is going to spend ten-tousands of dollars to MAYBE gain access to your bank account with a few tousands or ten-tousands of dollars on. The risk is too high and the win is too low.

However, if the data is VERY sensistive, lets say you work for military. Then some government might want to spend ten-tousands of dollars to recover your information. Then you should use the longer erasing schemes like the DoD standard (7 pass), which will erase the data closer to irretrievable.