Best current methods for preventing data leakage from SSD

Question

I'm wondering about the current best practices for ensuring data confidentiality on an SSD used as an OS boot drive (under Linux). Important considerations are:

1. Ensures against data leakage in the usual conditions (stolen drive, &c.; protection of data in motion is of course a separate question)
2. Allows for comprehensive and secure data erasure on demand, preferably under pure software control
3. Does not overly interfere with normal usage

The obvious first step is to use full-disk encryption, here LUKS. This more or less satisfies condition 1 (or should). It also greatly helps condition 2, since in theory if the header is wiped the remainder of the data becomes permanently inaccessible. However, on an SSD there are some potential issues with this.

Question 1: What is the best way to securely erase a specific area (the LUKS header) from an SSD? The TRIM command is apparently intended for this, but I'm unsure of its reliability. On an HDD I would feel fairly confident just repeatedly overwriting the blocks in question, but apparently wear leveling can prevent this from working in SSD.

Question 2: Absent the ability to destroy the header alone, what about wiping the entire disk? Intuitively, repeatedly overwriting the entire disk should prevent wear leveling from being a problem, since all sectors would eventually be overwritten. However, this seems unwise to rely on, given the possibility of e.g. still-readable sectors being marked bad and excluded from the mapping table. Is the Secure Erase command now reliable? There's a study from around 2010 that says that it was not in many disks then available; do more recent data exist? (It seems that at least some disks now use their own internal encryption, and implement Secure Erase by overwriting the keys used there. This is fine, if it actually works, but closed-source and non-auditable mechanisms implemented within the drive itself don't fill me with confidence.)

There's also the possibility of using something like LUKS' detached-header mode to prevent key data from ever being stored on the SSD itself. This would require some nonstandard configuration on the system, but nothing unreasonably difficult. However, it does introduce a chicken-and-egg problem of ensuring that the device with the header is itself secure and capable of erasure. If I store the header on a separate SD card or flash drive, is erasing this actually any easier? What other kind of device could be used?

Answer 1

The short answer to your first question is that if you don't trust the secure erase implementation, and your drive uses wear leveling, you can not be satisfied all data is completely removed from the SSD without physically destroying it. [1]

A method to add some additional peace of mind to the secure erase would be to try to erase as much as possible before hand. For example, by overwriting the whole device and then running secure erase after as shown here:

# dd if=/dev/zero of=/dev/X bs=4096
# hdparm --user-master u --security-set-pass <PASS> /dev/X
# time hdparm --user-master u --security-erase <PASS> /dev/X

Where "X" is your device, and is a password. There are guides here that can provide more detail about wiping using dd:

https://wiki.archlinux.org/index.php/Securely_wipe_disk

And using secure erase:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

The dd command should zero out all storage that is not held in reserve or bad, and the secure erase "should" get everything. The only question I am left asking is how the wear leveling works - it may be possible that running the dd command multiple times might overwrite blocks that were not written to the first time - but this would require knowledge about the wear leveling I do not have.

This would of course erase the whole device (as in your second question), not just a section. To erase a section you could overwrite the data, as well as all the free space instead of the whole device. This can be done using dd, with the output going to a file instead of device. It would need to be done as root to ensure the space reserved for the root user gets overwritten as well. This adds the filesystem layer to the procedure so may not get all the storage due to restrictions there.

If you put the header on a separate device, you could simply use a device you are willing to physically destroy to ensure the header is not recoverable. Another option is to use a secure device (such as a NitroKey/SmartCard) to store store the key (or perhaps even the detached header), which could be long enough to ensure brute-force attacks are not feasible on the storage device.

[1] If there is some way you will trust secure erase; eg. reverse engineering or otherwise obtaining information about the secure erase feature on the drive, then running secure erase would do it of course.