7

How secure is blkdiscard when using it on a ssd? I tried blkdiscard /dev/sda on a ssd running Ubuntu and after executing the command the OS doesn't survive a reboot and simply plugging the disk into a other device doesn't allow me to mount the disk either so I think the data on the ssd is destroyed.

I understand blkdiscard relies on the ssd controller so I understand its only going to do as good a job as the controller does.

I also looked into secure erase but unfortunately I cannot use that as my devices only have a single disk and are in remote locations so this won't work as the disk reports as frozen. I also cannot use disk encryption as there is nobody to unlock the device in case of a reboot.

I need a option to "destroy" the data remotely with a simple command/script. The goal is to erase the data to a point where some person with reasonable IT skills and some time cannot access whatever data was on the disk.

Can I reasonably assume blkdiscard actually makes the data on the ssd unrecoverable?

muru
  • 69,900
  • 13
  • 192
  • 292
sjaak
  • 564
  • 2
  • 8
  • 17
  • You didn't say whether you ran `blkdiscard` from the OS on `/dev/sda` or booted into another system, e.g. on `/dev/sda`. The former may leak old data from buffered blocks, e.g. if the OS updates the access time for a file in a directory that is cached, the meta data in the respective block will be written back to the disk. Same for files like `/var/log/messages`. They may contain not just new lines but also a few old lines. – Joachim Wagner Jul 20 '23 at 13:13

1 Answers1

5

Like fstrim, blkdiscard just sends the appropriate commands (TRIM for [S]ATA, UNMAP for SCSI/SAS, and a Data Set Management/Deallocate for NVMe) to the SSD in question, and the disk will decide on its own when it will actually do the erasing.

To maintain its write performance, a SSD wants to keep "enough" pre-erased blocks ready for writing, as the erasing of the old data is the most time-consuming operation in the lifecycle of a SSD block. So the blkdiscard just causes the blocks to be appended to the "to be erased" queue, not actually immediately erased for real. So the primary purpose of blkdiscard is to maintain good disk performance when a SSD is recycled to new use; as a side effect, anti-recovery may or may not be achieved.

https://security.stackexchange.com/questions/109916/does-the-ata-trim-command-irrecoverably-delete-data-on-an-ssd

If a SATA disk claims to support "Deterministic read ZEROs after TRIM", that would be a promise that the data will be unrecoverable with regular OS access immediately after using blkdiscard or similar. You would see this in hdparm -I information for your SSD. Unfortunately, not all SSDs make this promise.

Also, if your attacker has the SSD physically in their hand and some tools, special knowledge and/or skills in the Electrical Engineering domain, they might be able to get the SSD into Manufacturing Mode, which will stop the SSD from processing the erase queue and allow access to the raw storage, enabling them to read the contents of any blocks that have not been actually erased yet.

See: https://blog.elcomsoft.com/2019/01/life-after-trim-using-factory-access-mode-for-imaging-ssd-drives/

You could still use disk encryption for a dedicated data partition, with the encryption key stored on a small unencrypted partition. The destruction script would then first unmount and blkdiscard the key partition, unmount the data partition and execute cryptsetup close (or equivalent) on it, then create a lot of demand for freshly-erased blocks by starting to fully overwrite the encrypted data partition with some repeating data.

Assuming your disk encryption algorithm of choice is not weak, once the blocks with the encryption keys get erased and recycled by the overwrite operation, your data should be very effectively unrecoverable even if some parts of the encrypted partition have not been completely overwritten yet.

You may find some useful parts for the destruction script here: https://security.stackexchange.com/questions/171396/ssd-erasure-verification

telcoM
  • 87,318
  • 3
  • 112
  • 232
  • I doesn't look like my ssd supports that. However it seems not all of the output from hdparm -I is supported anyway. I tried some of the sanitize options and all I got was a function not supported message. Will look into this further. If I understand correctly I cannot be sure blkdiscard clears the whole drive? For now I added some shred & sync commands to my script to clean the most important files. As far as I understand this should work on a basic ext4 volume though I guess there is always the chance of the file not getting cleared the overwritten file is saved in a different cell? – sjaak Jul 26 '21 at 08:17
  • @sjaak Even if the drive reports RZAT, you shouldn't rely on that if what you after is "security", since there have been reports that in some drives the reported RZAT value is simply *false* (in the sense of fake / bogus). Also, many drives are partially/conditionally RZAT (so the blocks may or may not read zero depending on the number of blocks TRIM'd per *ATA command* -- there's tricky story with it with the "bio" splitting approach in recent kernel). Besides, note the `with regular OS access` remark after `data will be unrecoverable` in the answer. – Tom Yan Jul 26 '21 at 08:59
  • For the solution using encryption with a key stored in a dedicated key partition, I'd recommend to also overwrite the key partition. Some SSDs only mark the data as no longer needed but still return the old data until the data blocks is actually erased. The time window could be milliseconds or weeks. – Joachim Wagner Jul 20 '23 at 13:24