I’ve been working on the security design for the next version of Firefox Sync, which is the bit that keeps your bookmarks\/history\/saved-passwords\/etc synchronized between Firefoxes on all your various devices. The working title is “PiCL”, which stands for “Profile In the CLoud”. In the coming year, this will be deployed to roughly 500 million Firefox users.<\/p>\n
I’m looking for feedback on our design. It involves key-stretching (PBKDF2 and scrypt), secure handling of password-derived keys, SRP, and a healthy distrust of SSL. If you’re interested, read on!<\/p>\n
<\/p>\n
Unlike the previous Sync design, in which a full-strength random key was transferred between paired devices with a J-PAKE-based protocol, PiCL is obligated to use a traditional email+password as account credentials. My task has been to provide as much cryptographic protection of the user’s private data as possible, given that constraint. Our goal is to enable the user to have some data that is not visible to Mozilla (we run the servers) or their email-provider (through which a forgotten password can be reset).<\/p>\n
I’m focusing on the portion of the system that gets from email+password to a pair of master keys “kA” and “kB” (described below) and a session token. There are a lot of parts you can ignore for now, like how we use kA\/kB to encrypt the user’s data later (we’ll use HKDF to get per-datatype AES\/HMAC keys), how BrowserID certificates authorize communication with the storage-server, and how the data actually gets synchronized (efficient delta transfer, resolving merge conflicts, etc).<\/p>\n
The protocol is mainly described here:<\/p>\n
with some additional background here:<\/p>\n
The protocol page might be missing some context, so here’s a summary:<\/p>\n
My goal is for the confidentiality of the class-B data to be no weaker than the account password, and for this password never be revealed outside the user’s browser. If your password can’t be brute-forced, your data should remain safe, even if our keyserver is compromised. Class-A data should be no weaker than the typical “service-provider sees everything” approach. We also do a lot of key-stretching on the password, to make a brute-force attack as expensive as possible.<\/p>\n
It’s supposed to reject all but the following attacks:<\/p>\n
In particular, the storage servers shouldn’t be any better off than a random stranger, to keep the security perimeter small.<\/p>\n