Secure deletion in SSD partitions

Question

I've been thinking of purchasing a Purism machine, which uses an SSD to store data. Now, from my research, it seems SSDs make it pretty hard to securely delete data because of wear leveling, especially when it comes to deleting a specific file as opposed to wiping out the entire device. Fortunately, Purism machines have their SSDs encrypted by default to circumvent this problem. However, that does not account for cases in which the encryption key is leaked, lost, or obtained through coercion.

My question, then, is: when you partition an SSD, can you be sure the data will stay there and not be "shuffled" to other parts of the device? Also, in this set-up, could you later use Secure Erase, TRIM, or even just overwrite the partition with gibberish n times to securely delete only what is stored in that partition? If so, what would be the best course of action to do so? How many times would I be able to re-use a partition in this manner before it became too worn?

Thank you very much for your attention!

Answer 1

While the gist of your understanding is correct, there are some small but critical bits that make a massive difference that need to be corrected.

LUKS (Linux encryption - which works analogously to bitlocker) does not use your encryption key to encrypt the data directly (in fact you can have up to 8 different encryption keys per LUKS system). The trick is that LUKS has a header, and the encryption keys are used to unlock the header, which in turn unlocks the device. If your encryption key is compromised you can simply change the key There is still a risk though - if someone has an old encryption key + a dump of the old header they can overwrite the header and recover the data with the old key - but this is a mmuch narrower and more preventable risk.

This also means that to wipe the entire partition, all you need to do is wipe the encryption header.

When you use LUKS on a disk with secure erase, you are effectively encrypting twice, with 2 headers. The advantage of secure erase is it is done in hardware, and thus knows the disk geometry and it can be sure the header has not been moved/abstracted. (The disadvantage is secure erase is not open to scrutiny and may not be as secure as believed - indeed there have been disks which could be recovered after secure erase due to a bug/backdoor - https://www.helpnetsecurity.com/2018/11/06/self-encrypting-ssds-vulnerable/)

Unfortunately these are all partition/disk level solutions. You cant absolutely guarantee deletion at the file level (although some software can use encrypted headers to act in a similar way at a file level - I suspect some password managers like keepass compatible ones do this)

Answer 2

My question, then, is: when you partition an SSD, can you be sure the data will stay there and not be "shuffled" to other parts of the device?

No, you can't because the firmware only manages wear in internal blocks in a way you cannot assume any fixed relationship between hard drive sectors and internal blocks.

Also, in this set-up, could you later use Secure Erase,

Yes you can, but would you trust the firmware? Hard drive manufacturers have already been caught implementing bad encryption. The ATA command "secure erase" in case of always encrypting devices can be handled in a way that the drive deletes the internal encryption/ decryption key. That would make the drive unreadable. But can you trust the firmware that it really deleted this key? Furthermore the drive could have reduced the number of possible key variations. Do not trust the black box.

just overwrite the partition with gibberish n times to securely delete

This is not sufficient because of the existence of internal spare blocks and the dynamic assignment to logical sectors.

only what is stored in that partition?

This does not work, explanation above.

If so, what would be the best course of action to do so?

Use full drive encryption provided by open source software, Truecrypt, Veracrypt, LUKS etc...

How many times would I be able to re-use a partition in this manner before it became too worn? TRIM, or even

Take the guaranteed number of terabytes of your manufacturer and divide it by the size of your drive. That gives you the number of times you can rewrite the whole drive.

Example: drive size is 120 GB, guarantee is 80 TB, gives 80 000 GB / 120 TB = ~667 full writes.

But those writes are not necessary. Partly overwriting the areas where the encrypted key(s) reside will be sufficient.

With regards to the comment of xxxxxx

Does that mean the header does not get moved around?

Sure it can move, but LUKS for instance is spreading the header over a big number of sectors so that any single reassignement does not enable the firmware to get hold of the full header simultaneously.

If that is your fear you still have the possibility to overwrite the data but if your storage is that much used up or broken (device does not write anymore or seems dead) you can simply physically destroy it.

Keep in mind that you need full header information and data sectors to decrypt content.