6

I've thought of a method for securely erasing single files on a solid state drive. This method will work only if the drive is encrypted, and it will work even if someone cracks the encryption key for your drive. There are basically two steps:

  1. Delete the file the normal way.
  2. Change your encryption key and re-encrypt your drive.

This way, even if your current key is compromised, e.g. through a cold boot attack, the attacker will not be able to get at the files you have deleted using this method. Of course since you have to re-encrypt your entire drive, which takes a lot of time, this method is not useful for files that you will be encrypting and decrypting frequently. But if you want to have an extra layer of security around a set of files that you only access every once in a while, this method might be a viable option.

So what do you think? Is this a good method? Or are there better methods of single file secure removal for solid state drives?

Zen Hacker
  • 571
  • 1
  • 3
  • 11
  • 1
    An interesting read [here](https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf) basically tells you there is no reliable way (yet) to clear an ssd per file. – BadSkillz Jan 11 '16 at 16:12
  • @BadSkillz: I'm fairly familiar with how solid state drives work and why you can't securely remove single files from them. However, this method may provide some sort of way. I just wish I had some sort of connection with Usenix or Black Hat so I could tell someone about it, because it seems like a good idea. – Zen Hacker Jan 11 '16 at 16:17
  • Then you might be interested in using the TRIM command, this allows you to delete pages instead of entire blocks. I'm not quite sure, but from what I've read this should allow you to instantly clear the pages your data was written to. – BadSkillz Jan 11 '16 at 16:27
  • `it will work even if someone cracks the encryption key for your drive` - but not if they get the blocks from the undeleted file and crack the original encryption drive. I'm not sure how this helps. – Neil Smithline Jan 11 '16 at 16:46
  • @Neil Smithline: Because if you haven't used that encryption key in a long time, they won't be able to use a cold boot attack to crack it. I mainly had the cold boot attack in mind. I don't know of any other side channel attacks that could be used to crack an AES or RSA encrypted drive. – Zen Hacker Jan 11 '16 at 16:50
  • @BadSkillz The trim command doesn't delete pages, it's just a message to the SSD that the block isn't used anymore. See my question about the trim command and SSDs. https://security.stackexchange.com/questions/109916/does-the-ata-trim-command-irrecoverably-delete-data-on-an-ssd – Steve Sether Jan 11 '16 at 17:27

1 Answers1

1

It is not necessarily a secure idea. Solid state drives have what is called overprovisioning space, which is a small amount of space that is accessible only to the hard drive firmware (FTL, or Flash Translation Layer), and is used for wear leveling. This means that, even when your hard drive shows 100% usage, there is still some amount which is unused. The specific sectors which are unused are randomly chosen by the FTL. Unfortunately, this also means that your master key as stored in the encryption header (e.g. your LUKS or TrueCrypt header) may not be wiped, even after you re-encrypt the whole drive. As a result, you would have to wipe the drive many times over and over, and even then, the chance that any given sector is erased is not guaranteed, it is only an increasing probability.

Solid state drives are notorious for hiding control from the operating system. You may be able to get a new open channel SSD, which is a type of SSD without an FTL (or with an extremely limited one) which defers things like wear leveling to the kernel. You may be able to tell the SSD to erase all sectors, and it will actually obey.

Many modern SSDs are support SED, which is hardware encryption used for the purpose of being able to quickly erase the drive. When you issue the ATA Security Erase command, instead of slowly wiping the whole drive, these SED drives simply wipe the encryption key (which is stored in a special area of the drive not subject to wear leveling), rendering all the data on the drive useless). Obviously the key does not provide data at rest security, as it is only used to wipe data more quickly than it could have otherwise. You can use the hdparm tool to check if your SSD supports SED. Run "hdparm -I /dev/sdX | grep 'min for'", with X being the SSD's label. If the number of minutes is very small for either of the options it displays (usually 2, I believe), then your drive supports SED.

If your drive does not support SED, and you do not have a hard disk drive which you could store a key on that you could wipe directly when you want to erase the SSD, you could try to implement a sort of poor-man's SED in a hackish way using NVRAM. On most motherboards, your CMOS RAM (also called NVRAM) is a small amount of non-volatile memory, or sometimes EEPROM, which contains BIOS configuration information. It can be exported to /dev/nvram when the nvram module is loaded. It's usually 144 bytes in size (if it's exactly that size, it means it is NVRAM. If it is larger, it means it is probably EEPROM), but the majority of it is unused. If you can identify the unused portions, which is possible with some tools, or by understanding the format, you can write to it directly at /dev/nvram. Because this area is battery-backed by the CMOS battery (that little button battery on your motherboard that also powers the RTC), it persists across reboots. But because it's not flash, it can be erased instantly and securely. You can easily store a 128 or 256 bit key in there, which could added to your own encryption key to encrypt your main SSD partition. If you ever need to erase it completely, you can just erase the key in /dev/nvram, and it would render data on the SSD inaccessible.

The moral of the story is: FTL is a bitch. Don't trust SSDs, they hide things from you.

forest
  • 64,616
  • 20
  • 206
  • 257