When designing a secure service that stores user data, you might be temped to say “let’s make sure the data is encrypted.” That statement implies that you’re proposing adding goodness, without taking anything away. Something like “I’d like some of that delicious gravy on my roast turkey, please.” Clearly, turkey with gravy is strictly better than dry turkey. Who can possibly say no to gravy?
Unfortunately, encryption is not gravy. There are deep consequences to the product you’re building once you choose to encrypt data, and the consequences differ greatly depending on the key management mechanism you choose. I wrote about this in part in my previous crypto-realism post, encryption is not magic:
For the most part, encryption isn’t magic. Encryption lets you manage secrets more securely, but if users are involved in the key management, that almost certainly comes at the expense of usability and features.
That last point bears repeating: if you design a system with encryption where users manage keys, you’re going to lose features. You want gravy on that turkey? Sorry, no stuffing for you. “What?” you say. But I want my stuffing and my gravy! I want to believe I can have it all!
I’ve been there, and I’ve made that mistake. A few times. Every fan of cryptography, everyone who’s ever glimpsed that awesomeness and beauty, wants to believe that they can have all their features and all their crypto. They want to believe so badly that, when the glaring missing features come to light, denial is often the only escape. I’ve done this in my work on voting and health-data systems. End-user crypto was appropriate, I thought, users would get it, I thought. It’s their vote, their health data! How much more important does it get? If users don’t care about crypto and accept some inconvenience in those cases, when will they ever care?
Exactly. Users won’t accept inconvenience. Because the inconveniences aren’t small. If users are left to manage crypto keys, that means their data disappears if they lose the key. This is a mathematical certainty that makes absolutely no sense to non-cryptographers. Even safe deposit boxes can be forced open if you lose your key. The most expensive cars have unlocking fallbacks. There is nothing in the intuitive physical world that maps to the helplessness of losing your crypto key.
Now don’t get me wrong. You can still use crypto. The voting system I’ve proposed still does, and I’m not arguing it shouldn’t. I’m only saying that, whatever crypto you use, involving the user as an agent in the cryptographic protocol is bound result in significant usability limitations, often deal-breakers.
so what are my options
Broadly speaking, you have three:
- full-strength, randomly generated, user-managed key. This is the most secure setting. Access to the full server data gives the attacker no useful information. Unfortunately, it is also the most difficult to use. Enabling a new device requires coordination with an existing device. If users lose all of their devices, e.g. if they only have one device and it breaks, there’s no way to recover.
- password-derived key. The data is encrypted with a key derived from the user’s password. This is not as secure as the previous setting, since most user passwords are not nearly as strong as full-strength crypto keys. However, as my colleague Brian Warner is exploring, it may be possible to still make it quite expensive to break into a single user’s dataset, and prohibitively expensive to go fishing for data across many user accounts. Usability is significantly increased: a user can set up a new device simply by typing in their password. However, the crypto conundrum remains: lose your password, lose your data.
- server-side security. Users don’t manage keys, and servers technically have access to the user data. A number of techniques can be used to meaningfully restrict the chance of a leak (e.g. disk encryption or other type of encryption where the server holds the key somewhere.) Security against insider attackers is not nearly as high as with the two previous solutions. This is, of course, how almost every service on the Internet works today. It is the only model that maps to user intuition, where a user can forget their password, lose their devices, and still recover. Because that’s how the physical world works.
where Mozilla fits in
We’re having important discussions about these issues right now. I gave a talk about these issues a few weeks ago:
Firefox Sync fits the first, most secure model, but suffers because it is not the product that users think it is. In particular, most users of Sync use it as backup. In practice, it’s not: lose your device, lose your data. It’s also impossible to set up a new device without coordinating with an existing device. We are looking at providing new services based on password-derived keys, so that users can set up a new device with just their password and, if they remember their password, recover from complete device failure.
There remains a problem if users lose their device and forget their password. How often might that happen? I fear too often to make this solution complete for all data types. We will probably have to solve this by providing different, configurable levels of security, with corresponding feature compromises.
The discussion is ongoing. We have to keep in mind that the dilemma is very real. End-to-End Encryption is not gravy. We cannot have it for free. The choice of encryption architecture is as much a product decision as it is a technical one.
Benlog 
Comments
24 responses to “encryption is not gravy”
Ben, what do you think of Google’s “print out a small sheet of backup keys” solution to this problem for their two-factor encryption scheme? I don’t recall the exact mechanics right now but it seemed like a somewhat reasonable compromise.
You *can* use Sync as a backup if you think to get the passphrase out and in a safe place before losing your data… But it’s not obvious (esp. with the new design — I was an early user of Weave 😉 and clearly not designed for this. Average Joe won’t be able to use Sync as a backup solution.
Regardless of whether you have your recovery key, one shouldn’t rely on Sync as a backup.
For example, if a disk dies, your data dies — the system as a whole is designed such that the clients on the edges have the canonical copy of your data, and so can rebuild your account after node reassignment or another client wiping the server.
“There remains a problem if users lose their device and forget their password. How often might that happen?”
Very often. Because chances are the first they’ve done is tell the device to remember their password for them, and promptly forgotten it.
You forgot one also important downside of server-side security: Differently to the other two methods, you can (and therefore probably have to, depending on legislation) hand out data when requested by a powerful enough 3rd party, like a government, police or court.
In the other two models, that’s just not possible. I’m not advocating safe-havens for criminals, but the cases are increasing (esp. with some planned legislation) where normal citizens have a hard time differentiating between legal and illegal activities, and I’d also rather not give us too many possibilities to get to a 1984-style government (in some areas, many countries and even more corporate-owned processes are shockingly near to that already anyhow).
Who is going hack into your server to find my bookmarks. The default should be the third kind of encryption for that use-case.
Problem=opportunity. I am glad that crypto comes with some shortcoming. If there exists a drawback it’s only because we are not thinking hard enough or creatively enough to tackle the problem.
Yes, you’re right, though I tend to include that under the realm of “insider attacker,” as I like to think of it as the government forcing a service provider to go evil on their user.
It’s interesting, but I don’t think it’s enough. I suspect most users wouldn’t do it, or would lose it. I actually wonder what Google’s “ok, I really lost everything” user flow looks like in that case. And of course, 2-factor auth at Google is still a choice you opt into. They’ve done a great job with it, but I suspect it won’t be the default… maybe ever.
how to eat a cake and keep it hole. you take the cake and put it in your moth, as a hole
maw hu uwau
I hope that despite the importance of realism here, you maintain the ability to use the current system for Firefox Sync. In particular, for someone like me with multiple devices (5) that have Firefox, J-PAKE is much much easier to use than remembering a password, in addition to providing more security. If Sync switches to be password based, the first thing I’ll have to do is reset mine. 🙂
Perhaps there’s a way to handle Sync accounts with more than one device differently than those with only one.
Quite a few people use Google 2 factor auth because they realize the need for it. Even some people who aren’t specially into security.
But quite a few means something like what? I’m getting its 1%, 2%.
I used 2 factor auth and their implementation, while one of the most convenient, is still very .. inconvenient.
1/print backup keys. well, many don’t even have printers anymore. plus it doesn’t guarantee you won’t lose it. that being said i put that stuff on a usb stick /cd in general, but I know many just don’t.
2/reset every X day. Don’t wanna 2 type 2 passwords every 45 days. Pain. Yep even if it’s 45 days, it’s still painful.
3/Non-2-factor native web apps. Those need extra one time password. Super mega pain. Main reason why I stopped using Google’s 2 factor.
And in the end, their 2 factor doesn’t encrypt data Google side anyway. I’m not bothered about people stealing my encrypted laptop (which has a much stronger setup and doesn’t involve too much pain).
As an informed user I’m bothered about:
– trojans on my system. 2 factor won’t really help against that anyway. Not much does, except, well, GnuPG with an offline private master key (so you can untrust local encryption, signing keys, once you discover the issue)
– Google servers being compromised
Specially the later, which is generally not public for various reasons and yet does happen often enough, in any big data center I know of. Disk encryption of the systems do not help. Only user-side encryption does. Besides, with Google, it’s slightly different: Google crawls through that data for analysis anyway, even if it doesn’t leak direct private data (at least, I couldn’t find that), they still make their stats and keywords on it.
Felix, this is actually not quite true. Sync was designed such that the canonical source of data is one of your devices. The data on the servers is volatile and that’s OK for sync but not for backup because it can simply reach down to one of your devices to get an update if necessary. As it was designed it is not a back-up solution.
That design is changing, but suggesting that the key management is the only problem could cause users to have a wrong idea about the service and possibly lose all their data.
I think the only real solution is to default to server-side encryption, and offer a layer of end-to-end on top for the more paranoid/savvy users as an option.
Ah, interesting. I don’t have that many devices, so the only regular use I make of Sync is data transfer for new devices or new Firefoxes. That’s not actual backup, but given that I do it because I often do not have access to my old or other devices, I’d assumed it would work fine as a backup solution.
I’m no cryptographer, but aren’t we really talking about identify here?
When you ask for a password to unlock something you are asking someone to prove who they say they are.
When you unlock your safety deposit box you are proving your right to open the box by physical possession of the key.
When you lose the key for your safety deposit box you would have to prove your identity to get it unlocked.
Is there a way on the interwebs to prove identity, to get the key, to unencrypt the data?
Further if that identity was wrapped into something like Facebook then you could say ‘encrypt this document and let my friends see it’.
Easy
Oh my godness! I came occasionally across this blog and miss the most important questions: What to you want to secure and against what do you want to be protected. Only a user himself can answer this. If you want to have your files protected, a server side encryption is definitvly not an answer. There are administrators…. Not to say that they are the most dangerous category of people, but they are the most exposed. And there are more options to secure a key: Ever thought about using a smart card or the like? I know another hassle is introduced. But many business notebooks have readers. However, you are definitly right, when you say, encryption just moves the problem somewhere else.
what you’re talking about is server-side encryption only: the server gets to crack open the safe if it properly authenticates you. And I agree 100% that this is the most intuitive approach for users. It’s probably not the right model for all data, because server-side encryption means that the server has access to the data, since it has the authority to decide who is “authenticated.”
Similar to the way World of Warcraft’s “key”?
[…] devices in a way that does not allow Mozilla, as an organization, to access it. On the downside, encryption has a cost, as my colleague Ben Adida […]
Hello everyone. As i have ever read about Encryption is that it is used
to protect the unsecured data while transferring from one point to
another. But after reading this article i have also the same questions
which Steve had asked.
[…] of my colleagues, I don’t believe we can simply forgo the Cloud or use end-to-end encryption. Encryption cannot be layered on without consequences. You cannot provide the value that users want without some centralization of data and […]
[…] heard folks argue that PRISM means we need to bet it all on end-to-end encryption. I think that’s wrong, because that doesn’t fulfill users’ needs. But even putting that aside: if you believe […]
[…] Bei all der Freude um mit PGP/GPG-geschützte E-Mails, in TrueCrypt-Containern gesicherte Dateien, Server-Zertifikate, in Passwortmanagern gespeicherte, superkomplizierte Passwörter und andere Möglichkeiten der Verschlüsselung und Datensicherung, darf man niemals die Kehrseite kryptografisch gesicherter Daten vergessen, die hier schon einmal präsentiert wurde: Wer seine (Widerrufs-) Zertifikate, Passwörter oder Keys verliert, verliert den Zugang zu seinen verschlüsselten Daten für immer und ewig. […]