The flip side of the tyranny of the hardware flash controller is that the user can't reliably lose data even if they want to. Your super secure end to end messaging system that automatically erases older messages is probably leaving a whole bunch of copies of those "erased" messages laying around on the raw flash on the other side of the hardware flash controller. This can create a weird situation where it is literally impossible to reliably delete anything on certain platforms.
There is sometimes a whole device erase function provided, but it turns out that a significant portion of tested devices don't actually manage to do that.
But then you have to find a place to store the key that can be securely erased. Perhaps there is some sort of hardware enclave you can misuse. Even a tiny amount of securely erasable flash would be the answer.
A TPM can only store a limited number of keys. You need a forseparate key for anything you want to securely delete and in a lot of applications you might have a lot of things you want to delete separately.
You can pretty easily expand one secure, rotatable key into N. 1. Don't use TPM key directly, use it to encrypt the list of working keys. 2. Store the TPM-encrypted list of working keys on disk. 3. When you need to drop a working key, remove it from the list, rotate the TPM key and reencrypt all the working keys, and store the new list on disk again. Remnants of the old list are irrecoverable because the old TPM key doesn't exist anymore, and the new list is inaccessible without the new TPM key. There, now you have an arbitrary number of secure keys and can drop them individually.
Great point. This assumes that the TPM does secure deletes. Their primary purpose is protect keys, not get rid of them. I think in practice a TPM is a small enough system that the deletion would be secure just because that is the simplest way to do that. If you do this enough then some overwriting will likely occur. I guess media endurance could be a problem in some cases.
This is the theory, where you never have to store the key on disk. In reality you store the key on disk while performing actions that would block the TPM chip from releasing the key, such as upgrading the firmware.
Great, we'll just store the key persistently on... Disk? Dammit! Ok, how about we encrypt the key with a user auth factor (like passphrase) and only decrypt the key in memory! Great. Now all we need to do is make sure memory is not persisted to disk for some unrelated reason. Wait...
Swap on zram instead of disk based prevents persisting memory to disk and also dramatically improves swap performance. It's enabled by default on Fedora. I use it everywhere - on my desktop and on production servers.
For sure, I'm not saying it's unsolvable, just that the defaults are insecure. Even if I, as an app developer, wanted to provide security for my users, I can't confidently delete sensitive data since this happens below layers I can or should control. We can argue about who is responsible, but it's not a great situation.
There is sometimes a whole device erase function provided, but it turns out that a significant portion of tested devices don't actually manage to do that.