8

The recommended way of securely erasing a SSD is the ATA secure erase. Most of the BIOSes disable this function by freezing the drive. Some tricks around the BIOS freeze exist and may or may not work depending on the setup. This makes ATA secure erase difficult to use.

Could triming be misused as an alternative to securely erasing a SSD?

One could delete any existing partition table and create a new GPT with one ext4 partition filling the whole SSD. Triming the ext4 partition would cause the SSD to erase all logical blocks on the SSD but the blocks holding the GPT and the ext4 super block. Reserve blocks which are not assigned to a logical block are erased by definition. This way all physical blocks would either be erased or contain useless GPT/ext4 meta information.

Do you see any flaw in this plan?

Please do not answer that ATA secure erase should be used to securely erase a SSD, this is not the question.

Stéphane Tréboux
  • 273
  • 2
  • 9
  • 1
    [TRIMming *is* used to erase an SSD.](http://superuser.com/a/283608/83694) – Deltik Apr 03 '16 at 15:15
  • In my question yes :-). According to Shimpi, Anand Lal. (2009-03-18). p. 10.: "Trimming enables the SSD to handle garbage collection overhead, which would otherwise significantly slow down future write operations to the involved blocks, in advance." (found on [Wikipedia](https://en.wikipedia.org/wiki/Trim_%28computing%29)). It just happens that preparing the flash for future write operation involves erasing it; it could be otherwise with other memory technologies. – Stéphane Tréboux Apr 03 '16 at 15:41

2 Answers2

8

If data security is your concern, it should be noted that neither a SECURE_ERASE nor a TRIM actually erase the flash cells. The SSD firmware keeps a list of which cells are allocated and which are not. A TRIM simply marks a cell as unallocated the same way deleting a file causes the filesystem to mark a cluster as unallocated. No attempt is made to actually erase the data. A read request from an unallocated cell simply causes the device to return 0x00 (or some other bit pattern) without actually checking the cell's contents.

There is no effective way of securely wiping an SSD. Forensics tools that can interface with the firmware directly can see the cells' contents. Also, there is more storage on the device than what is accessible from user-space. These extra cells are used in garbage collection. Garbage collection can reallocate cells on-the-fly and can still work even on a drive that is 100% full. A SECURE_ERASE may (probably does) TRIM those cells, but a blkdiscard or fstrim certainly wouldn't, since they use sector numbers to identify the areas to be TRIMmed.

The only way to securely erase an SSD is to destroy it. This is the policy of most companies in health care, banking, and government when surplussing equipment.

Wes Sayeed
  • 13,662
  • 6
  • 41
  • 76
  • A secure erase is required to actually erase the medium, not just the block translation tables. – psusi Apr 05 '16 at 02:14
  • 2
    This is a very interesting answer which raises many questions. What is the meaning of a secure erase according to the ATA specification? Can you maybe cite sources? I understand that trimming may not lead immediately to a cell erase. Still after some fixed (probably not to long) amount of time the trimmed cell need to be physically erased; otherwise after this amount of time a drop of write performance would be noticeable because the SSD would run out of fresh cells (like on SSDs without trim support). What do you think? – Stéphane Tréboux Apr 05 '16 at 06:53
  • Furthermore I understand that there is a lot of speculation and guessing in my reasoning; for very sensible data a big organization would prefer physical destruction to rule out any risk of a backdoor or bug in the SSD firmware. My concern is more about the normal consumer reselling his drive. – Stéphane Tréboux Apr 05 '16 at 06:54
  • I found an old draft of the ATA spec here (you have to pay for the real thing): http://t13.org/Documents/UploadedDocuments/docs2008/D1699r6a-ATA8-ACS.pdf. It does not mention trimming (probably to old). According to this document both normal and enhanced secure erase modes are expected to actually delete user data by replacing it with other data. By the way it means that the SSD does not necessarily leaves the cells in erased state after a secure erase. As mentioned before the user still must trust its device in that there is no bug or backdoor in the firmware. The relevant passages are: – Stéphane Tréboux Apr 05 '16 at 07:58
  • When Normal Erase mode is specified, the SECURITY ERASE UNIT command shall replace the contents of LBA 0 to the LBA reported by the larger of READ NATIVE MAX or READ NATIVE MAX EXT with all binary zeroes or all binary ones. If the device replaces the contents of native max address + 1 to the Maximum LBA reported in DEVICE CONFIGURATION IDENTIFY data words 3-6 it shall use the same data pattern found in LBA 0. IDENTIFY DEVICE or IDENTIFY PACKET DEVICE word 89 gives an estimate of the time required to complete the erasure. – Stéphane Tréboux Apr 05 '16 at 07:59
  • The Enhanced Erase mode is optional. IDENTIFY DEVICE or IDENTIFY PACKET DEVICE word 128, bit 5 indicates whether the mode is supported. When Enhanced Erase mode is specified, the device shall write vendor specific data patterns from LBA 0 to the Maximum LBA reported in DEVICE CONFIGURATION IDENTIFY data words 3-6. In Enhanced Erase mode, all previously written user data shall be overwritten, including sectors that are no longer in use due to reallocation. IDENTIFY DEVICE or IDENTIFY PACKET DEVICE word 90 gives an estimate of the time required to complete the erasure. – Stéphane Tréboux Apr 05 '16 at 07:59
  • 1
    Vendors never really cared about the definitions of ATA Secure Erase when they make an SSD or one of those drive (HDD/SSD) that supports hardware encryption. It makes sense since the definitions (zero/one/pattern-filling) simply does not fit well in SSD, and there is (or was, I think they added something recently) no feature/command defined that allows implemention of hardware encryption (I mean, a means for users to trigger a regeneration of encryption key, pretty much the whole point of those non-OPAL encryption). So at the end of the day, the vendors simply implement it in the way they like – Tom Yan Apr 05 '16 at 12:13
  • Precisely I guess you can say that ATA Secure Erase is never TRIM because TRIM is a bit in the DSM command, and ATA Secure Erase is simply another command. What we really mean is the outcome (and the required time) is mostly (if not always) the same as a full drive (DZAT) TRIM, but how the each vendor implement it internally? Only the vendor knows. But you should never see that any implementation in an SSD that will apparently works like those in HDDs, like, taking hour(s) to finish. – Tom Yan Apr 05 '16 at 12:17
  • @StéphaneTréboux also if you consider "read zero" safe (without the concern of lower layer remanence), then as I said, full drive hexdump guarantees you that; what you really need to know is how to get that from the TRIM implementation of your drive (and I've told you about the trickiest case(s); whether it reports DRAT/DZAT never really matters in my experience, 'cause TL;DR: ATA and vendors suck) – Tom Yan Apr 05 '16 at 12:26
  • Will erasing the files with CCleaner or bit killer remove the files completely? It's my understanding that it overwrites those sections with random data or 0s – Alex Jan 23 '18 at 08:23
  • 1
    @Alex over-writing files on SSD does not erase them from the media, the new bits go onto a different physical location - you might as well just use TRIM. – Jasen Sep 03 '18 at 22:26
7

Let's put it this way:

The truth is, in most, if not all, SSDs, ATA Secure Erase is an equivalence to a full device TRIM. Except those with "hardware encryption", where ATA Enhanced Secure Erase is basically a regeneration of the encryption key. So after all ATA Secure Erase in SSDs is not really THAT secure, unless yours support "hardware encryption".

On the other hand, fstrim is not the only way to TRIM a device. You can use blkdiscard to wipe a whole block device (disk/partition) including the GPT and superblock and whatsoever.

However, be aware that TRIM implementation in some of the disks has a "requirement" in the TRIM commands issued, so only when it is fulfilled, all the blocks on the drive will then "read zero" after TRIM.

For example, the Intel 530 SSD requires the TRIM block ranges to be "aligned" to 8 blocks. So when I want to wipe it clean with blkdiscard or hdparm, I will need to make sure that no "minimum unit" is "covered" by two TRIM ranges.

With blkdiscard, I'll need to specify -p 33550336 (65528 blocks * 512 bytes, where 65528 = 65535 (max no. of block in a single range) - 65535 % 8), assuming the starting offset is 0 (or a multiple of [8 * 512]), otherwise there will be leftover blocks that will not be wiped. This can be checked with something like hexdump after the TRIM.

See the difference of my Intel 530 (sda) and Silicon Power S70 (sdb):

enter image description here

and the difference when the ranges are not aligned and aligned:

enter image description here

(There are still leftover at the end since 65535 * 2 = 131070 is not a multiple of 8, but you can see that 131064 blocks [0x3FFF000 / 512] are continuously wiped.)

No cheating:

enter image description here

P.S. I've also seen drives from SanDisk that its "head" and "tail" cannot be wiped with TRIM command in any form. The "minimum unit" of it is 256 blocks.

Tom Yan
  • 9,075
  • 2
  • 17
  • 36
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/38071/discussion-on-answer-by-tom-yan-triming-as-alternative-to-securely-erasing-a-ssd). – Sathyajith Bhat Apr 07 '16 at 10:56