[Cryptography] Shredding a file on a flash-based file system?

[Jerry Leichter]

On Jun 19, 2014, at 9:43 AM, John Denker <jsd at av8n.com> wrote:
>> Does anyone know if this assumption is reasonable?
> 
> Almost any crypto-related assumption about flash-based file
> systems is not reasonable.  Ditto for many other modern
> hardware systems.  They do too much behind your back,
> including moving data from place to place.
Absolutely concur.  In fact, for the specific case of flash, load-leveling algorithms make it virtually certain that the block you zeroed is *not* the one that contained the data you wanted to get rid of.  That block has been added to the end of some internal queue over which you have no control and which you can't even see using any standardized or even documented mechanism, where it will *eventually* be erased - but no one can tell you when.

And of course your opponent, who will have access to all kinds of hardware-hacking equipment and either has gotten - by fair means or foul - or has determined by deep hardware analysis the hidden mechanisms for reading everything hidden away on the underlying chips - will have little trouble pulling that material out.

Modern disk drives increasingly have NVRAM in them to improve their performance.  It's getting so cheap that it will eventually be universal.  (Disks have had tons of RAM for things like track buffers for years now.  Maybe some of them have an internal battery to ride out short power failures....)

> The only defense I've seen that makes any sense is to
> do full-disk encryption or something similar.  Sometimes
> file-by-file encryption suffices.  Then the problem of 
> erasing the disk (or file) reduces to the problem of
> zeroizing the key.  This is not necessarily trivial in
> absolute terms, but it is often easier in relative terms.
Every iPhone since the 4 or maybe 4S has done exactly this.  (I think iOS uses a "file-by-file" approach and only protects stuff that's been declared "sensitive".)  At least some Android phones do the same thing.

As always, the killer is the stand-alone system that has to reboot without someone there to type in the disk decryption password.  TPM's are a great solution to this problem - or would be if they hadn't gotten twisted to support DRM.

(I know of a company that has a bunch of standalone servers that need access to encryption keys and are scattered throughout the company campus.  They decided that these things are almost never shut down, so it's not worth deploying a secure way to store the keying information.  Instead, a rebooting machine has enough smarts to ping the support center for help; a person comes out and supplies the keying information.  Makes for a big fire-drill after a large power-failure - which has happened - but that's considered a worthwhile tradeoff.)
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140619/e8f71a3a/attachment.bin>