Ensure data doesn't linger after being deleted

Question

I'm trying to make a service that keeps as little data on its users as possible. To that end, I want to make sure that someone using forensic tools won't gain any more information than I would by looking at my database or filesystem. In other words, you shouldn't be able to go through my hard drive with a hex editor and find a message that a user deleted yesterday.

Measures I've taken already:

I delete logfiles with identifying info within 30 minutes. I have swap turned off. I have /tmp, /home, /root, and /var/log mounted on a RAM-disk. I've removed rm, and put a hardlink to srm in its place.

I have a hard drive that does not reallocate blocks, unless there is a bad sector.

Problems with my system currently:

1. If a sensitive file is modified and made smaller, that will (AFAIK) deallocate a sector, which will then not be shredded, even if srm is called on the file.
2. Changing rm does nothing for programs that call unlink directly.
3. I have rows in MySQL that contain sensitive data. I delete those rows, but I'm concerned that MySQL keeps them around somehow.
   Edit: It appears that SQLite has a config setting called secure_delete. I'll use SQLite instead.

Possible improvements:

• Set the chattr attribute s (secure deletion) I don't have this set now because the chattr manual says that ext2/3/4 ignores this flag. I found conflicting information about whether ext4 supports it. Which filesystems respect it?
• Wipe free space. Seems like kind of a sledgehammer approach, but I can't figure out a way to solve #1 otherwise. Also, the ways I've seen for doing this involve making a really big file, then deleting it. I'm concerned that it might make a program crash when this system is almost out of space.
• I could make text backups of the MySQL database (which definitely don't contain the deleted rows) delete the originals, then restore them.
• Switch to a different SQL daemon?
• Reboot to clear the RAM disk. However, I don't want frequent downtime. Also, it wouldn't do anything to clear out data lingering on the hard drive.

What's the best way to fix these three two problems? I'm currently using Arch Linux with ext3 and MySQL SQLite. I'm willing to change out any of those.

Thanks for your attention!

Answer 1

Destroying data properly without physically damaging the media is quite a difficult task, especially since HDDs have started coming with block reallocations. This is orders of magnitude more difficult (if not impossible) with SSDs, since there the firmware does literally magic with what is really stored in the flash. As my comment asking for more detailed information about your setup went without an answer, let's assume an SSD is involved.

Since you can't really destroy the data, the next best thing is making them inaccessible. Which is what encryption is usually rather good at (when done right). Hence your generic solution is to encrypt all the data you want to be able to forget easily and throw away the key once such a time comes.

Implementation for various services may differ a lot and may (or may not) require substantial changes to your infrastructure. In all cases however, two rules will apply:

1. use good encryption algorithm and configuration (mode of operation, IV generation)

2. make sure you will be able to discard the key (actually any sensitive plain text data for that matter!) really properly - this basically mandates storing it physically in RAM and remembering to overwrite it with something else when not needed any more¹.

A simple example (on Linux) concerning users' home directories

• Create a regular file - its size will determine the size of user's home, fill it with (pseudo)random data (one way to do it is to write zeroes to a dm-crypt device backed by that file)

• Create a dm-crypt device backed by the file, keep the password stored only in RAM (see ¹). If you used a dm-crypt device for "randomising" the backing file in the previous step, use a different password now.

• Create a file system on the crypto device;

• Mount at user's home;

• When you decide to remove the home, unmount it, throw away the key, remove the file (possibly fill it with random data again, but remember this doesn't make that much sense for SSDs).

---

¹Rather tricky part and your mileage may vary (as always with security). The point is, that even for a server there are case when that key (or other sensitive data) may be present in memory when it should not. In your case this can be for example when a service (database...) crashes (or is just stopped for maintenance) or, as suggested in a comment, in the case of a power-off, especially a forced one - i.e. the attacker physically removing the server from its place for analysis.

The first case could be solved by kernel wiping any memory pages belonging to an application after it frees them (thus including any form of application stop).

The second one is even trickier. You may ask why you should bother with RAM after a power-off and you wouldn't be the first one - read on Data remanence, Cold boot attacks and check e.g. Are there volatile memory chips which dont retain data after power off?. General answer: there's not much you can do without a specially designed hardware that would erase the RAM on power-off. And even then - can you exclude a possibility of an attacker hooking onto a running the machine on hardware level?

While this sounds paranoid, it is just a hint about what you may want to consider when implementing such a service. You have to decide what makes sense, what threats you don't really want to spend resources on and what trade-offs are acceptable. For example if you want to be able to reboot the machine unattended, then you're pretty much out of luck, since that requires it to have access to at least some unencrypted sensitive data (let's say the encryption key), which in turn breaks the whole privacy chain.

Another problem is, that you need to make sure it doesn't get swapped out - at least not an unencrypted swap storage.

To sum it up: question is not whether you can make it impossible for an attacker to get the data - it is how difficult you make it. You have to specify the how much part to see what makes sense.

Answer 2

The best solution is really the simplest.

Don't save the information you don't want to end up in someone else's hands in the first place. Don't want your logs to be recoverable after deletion? Don't log. Don't want your cookies to be used to track you? Don't use cookies. Don't want deleted messages to be recoverable later? Well, that's a tough one, because the message had to be saved before it was deleted, so I can't help you there.

This is the method that web browsers with a "privacy mode" use. Their tracks aren't recoverable because they never leave them in the first place. No cache is used, no history is saved, no passwords remembered. Of course, they also warn you that the data you send can still be intercepted once it leaves your computer, so there's always a third party whose actions you can't control.