Wandering Thoughts archives

2012-01-03

How to lose your data with full disk encryption the easy way

In the last entry I wrote that some full disk encryption schemes could cause total data loss on occasions other than you forgetting your keys (or having the entire disk die). A commentator then suggested dealing with the key loss problem this way:

Many systems support multiple keys (e.g. dm-crypt). Just keep one sealed in a safe.

Unfortunately, this is a great way to increase your chance of total data loss (in one of the ways that I was thinking of). In fact any time that you see a disk encryption scheme that allows either multiple keys or changing the key you should be very, very wary. To see why, let's ask ourselves how a multi-key scheme can possibly work.

Barring exotic cryptography where you can somehow encrypt data once so that it can be decoded with several different keys (I don't think this is possible but I don't know enough to definitely rule it out), there are only two choices. Either the system stores multiple copies of the data, each decrypted by a separate key, or there is a level of key indirection going on; there is a single master key that decrypts the data and the user-level keys you use simply decrypt the master key. Since multiple encryptions consume space (and IO bandwidth) at a prodigious rate, you can guess which option most systems take.

(Using a master key also allows the system to use a very strong one, with many very random bits. This may be important since the master key is used to encrypt a lot of data.)

Any time you have a master key, one that you the user does not provide directly, the master key has to be stored somewhere. When a master key is stored, damage to just the parts of the disk where the master key lives means that you lose the master key, which results in the usual catastrophic data loss. Axiomatically the master key is not stored all over the disk, which means that damage to less than the full disk will lose the entire disk. How much damage is required depends on the specific master key storage scheme used by your specific disk encryption scheme, in particular how many replicated copies of the master key it keeps.

For obvious reasons, a resilient system should store multiple copies of the master key (and multiple copies of the master key for each individual user-level key, because you may only know a single user-level key). However, there is a rainbow book security tradeoff here; the more replicated copies you have, the harder it is to invalidate a user-level key. Also, only having one copy of the key is simpler for the programmers creating these systems and besides, assuming that reliable storage is someone else's problem is a popular move.

Now let's ask the obvious question: how many copies of the master key does dm-crypt keep? I'm afraid that the best answer I can determine, from the LUKS on disk format specification, is one copy. Possibly effectively less than one, in that it seems that there are two separate disk locations that both have to be intact in order to retrieve the master key for a particular user-level key. This means that you are one unfortunate disk sector error or misdirected write away from total data loss. I would not be surprised if this was typical of full disk encryption software in general, but dm-crypt is the only one I've looked at.

(Misdirected writes happen for various reasons, including kernel bugs.)

Why systems that allow you to change your key are equally problematic and dangerous is because the easiest way to implement this is also to use master key (whether or not the system admits this). With a master key, changing your key simply requires re-encrypting the master key with the new user key. Without a master key, you would need to re-encrypt (ie read and rewrite) the entire disk (and either insure that the re-encryption is not interrupted partway through or handle it somehow).

tech/DiskEncryptionAndKeying written at 22:28:59; Add Comment

The drawback of full disk encryption

Via Hacker News I saw that the EFF's suggested New Year's resolution is full disk encryption on every computer you own. When I saw this I did something halfway between wincing and grinding my teeth. The issue is that full disk encryption has a significant downside, and because of this downside choosing full disk encryption is making a much deeper choice than you might think.

The downside is simple: the failure mode for meaningful full disk encryption is catastrophic data loss. If you forget your password it is game over; there is no recovery possible. Whether temporary or permanent, unless and until you remember the encryption password all of your data is gone. There is no secondary access password, no emergency back door, no special rescue mode the way there is with most other security measures.

(Some disk encryption schemes will also cause total data loss on other events, but let's assume that your disk encryption software is perfect.)

Fundamentally, using disk encryption is rainbow book security in that explicitly or implicitly you're choosing non-disclosure over availability, where you would rather risk losing your data entirely than for potential bad people to have access to it. Under some circumstances this is the right decision; for example, if you can easily restore all of the data on your machine from other sources (and especially if the data is sensitive). Under many circumstances it is probably not the right decision; you would rather have less chance of losing the data even if it means that a bad person might get access to it. Certainly the latter is the case for me. I would generally much rather have a bad person have my data (or a copy of my data) than run the risk of losing it; in the long run my data is (much) more valuable than my privacy.

I don't object to people who've considered these issues deciding that full disk encryption makes sense for them and going ahead with it. But I get annoyed when a respected source gleefully advises people to do this without talking seriously about the very real downsides and risks. The EFF does advise you to save your password somewhere, but I don't think that this goes far enough.

(You may think that the risk of forgetting your password is very low. Let me assure you that over the years I have temporarily forgotten or gotten confused over at least my ATM PIN, my Unix login password, and more than one root password, all of which I use all the time. Perhaps I'm unusual, but with frequently used passwords I get to a state where I don't actually think about the password as I enter it and in fact getting jarred into thinking about what the password actually is is a great way to get completely confused about it, much like the centipede and his legs. The less I'm normally aware of the password, the harder it is to recover from this.)

tech/DiskEncryptionDrawback written at 00:11:47; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.