Mozilla PiCL and multi-level security

Firefox users have been able to synchronize various browser features between multiple desktops and mobile devices for several years: bookmarks, history, preferences, and even installed add-ons. But that synchronization comes with a risk; the data stored remotely on the synchronization server must be protected—some of it has privacy implications, while other data (such as saved passwords) pose much greater problems if stolen. Mozilla only stores encrypted data on the server, but it is still working to make improvements. It recently began to publicize its plans for the future of the Firefox Sync service, called "Profile in the Cloud" (PiCL). The plan calls for a number of changes to the security architecture. One is a move away from requiring full-strength cryptographic keys, while another is the ability to separate high-value and low-value data for separate classes of security.

Mozilla developer Brian Warner posted a blog entry about PiCL on July 23. The architecture document on the Mozilla wiki provides an overview of the revised system, which will evidently add to the data types currently synchronized by Firefox Sync (including WebRTC bridging providers, social API preferences, and file storage). Warner's post, however, focuses on the security model.

The biggest user-visible change is likely to be the dropping of Firefox Sync's existing credentials (a username, email address, and separate encryption key) in favor of a simpler email-address–plus–password approach. But the real magic takes place behind the scenes: PiCL will offer multiple security levels and will better protect the cryptographic key that protects user data, but users will only need to remember their chosen password.

Currently, Firefox Sync randomly generates a full-strength cryptographic key on the browser, encrypts user data with it, and uploads the encrypted file to the Sync server. The key itself is stored on the user's computer, not the server. In addition, users also set up an account on the Firefox Sync server, using an email address and a user-selected password. This email/password combination is only used to completely reset an account if the key is lost.

Building levels

The revised plan as described by Warner rearranges the pieces somewhat. Users will still set up an account using their email address and a selected password, although the account setup system will make use of Mozilla's Persona, which did not exist when the current Firefox Sync system was rolled out. But, more importantly, the email/password pair will be used to derive encryption keys. Yes, there are keys, plural: for starters, one (known as kA) corresponds to the "class A" or low-value data set and one (kB) corresponds to the "class B" or high-value data set.

An important facet of the new design is that it offers users the choice between two storage options: class A data can be recovered by Mozilla, while class B data cannot. Users can choose which synchronization data is assigned to which class; Mozilla may default to saving passwords as class B and everything else as class A, but that decision is not yet final. Users can also change their minds after the initial setup, and move data from one class to another. In addition to this feature, the plan also takes steps to make brute-force attacks against account passwords as expensive as possible, even in the event of compromised servers at Mozilla.

The higher-security kB key is created client side by the browser, which then sends a verification code—but not kB itself—to the PiCL server. The server, in turn, creates kA when it creates the user's account, which is what allows class A data to be recovered in the event that the user forgets his or her password. Warner describes the key-generation and account-setup process on the Mozilla wiki. Among the salient points is that kB, even though it is derived from a user-selected password, must be strengthened as much as possible to make it resistant to brute-force guessing. PiCL does this by salting and then stretching the email/password pair on the client side. Warner cites Password-Based Key Derivation Function 2 (PBKDF2, from RFC 2898), which is computationally expensive, and scrypt, which is memory-expensive, as the stretching techniques. There are some initial parameters for the stretching algorithms under discussion, but they do not appear to be final as of now.

Naturally, even after stretching, kB will not be as random as the cryptographically strong key currently used by Firefox Sync, but the overall PiCL system takes more effort to protect kB against discovery. For comparison, the Firefox Sync system relays the user's key to each synchronized client using the J-PAKE protocol, meaning it is stored locally on multiple devices as well as occasionally being sent across the network. It is not sent in the clear, of course, but it is sent, so there are always possible attack vectors. In contrast, kB does not leave the local machine, and is never stored on any device.

In a synchronization session, the client proves to the server that it possesses kB using the Secure Remote Password (SRP) protocol. The client prompts the user for the email/password combination, derives kB, then calculates an SRP verifier code to send to the server. The server can then send encrypted class B data back to the client to use or modify as desired.

The situation for class A data is much simpler, as the server generates and possesses kA. The current plan is to use kA and kB to derive several distinct AES HMAC encryption keys (using HKDF, the HMAC-based Key Derivation Function), one for each type of data stored (e.g., passwords or preferences). Whether kA or kB is used to create the per-datatype key depends on the class in which the user wishes to save the data. Encrypting each type (e.g., bookmarks, passwords, or history) separately permits the user to have a change of heart about whether a particular data type should be saved in class A or class B.

Architecture and trade-offs

PiCL also differs from Firefox Sync in that it uses two separate servers: a keyserver, which stores kA and the kB verification code for each account, and a storage server which retains the actual encrypted data. The benefit is that both the keyserver and the storage server must be compromised for an attacker to gain access to any data, and if that happened, only the class A data would be revealed. This, Warner notes, makes class A data no more vulnerable than any "service provider holds everything" scenario, while also offering a higher level of protection with class B. Another benefit is that an attacker compromising the storage server alone would not be able to steal any keys.

Warner also points out the known vulnerabilities of the system. A user's email provider, for instance, can intercept the account-setup and account-reset emails, and obtain access to class A data. For that matter, the email provider can fake the entire password-reset process and hide that fact from the user. As for class B data, even though kB is never sent over the network (nor are the password and salt that generates it), the keyserver does retain a copy of the kB verifier code, so an attacker could attempt to guess the password by brute force. Furthermore, an attacker that compromises the keyserver can perform this attack offline. The password-stretching process is meant to make this attack as expensive as possible, but ultimately if you choose a guessable password you will make the attacker's life easier.

PiCL is still under heavy development; Warner asked for feedback on the keyserver protocol in his blog post. But there are already several features of note. First, the ability to separate high-value and low-value data will likely garner fans, especially among those who have lost an irrecoverable Firefox Sync password previously. Interestingly enough, some earlier draft documents on the wiki discuss even more security levels, so Mozilla clearly sees this as a feature desired by its users.

Second, separating the keyservers and storage servers on Mozilla's end does offer some additional protections, although it does so at the cost of additional complexity. Mozilla can presumably afford to manage this complexity, but one of the nicest features of Firefox Sync is that it is possible to run a private synchronization server. It will be harder for self-hosting users to take advantage of the split-server model. Finally, it is an interesting question (probably open for lengthy debate) whether or not the stretched-password kB key in PiCL is more secure than the random key in Firefox Sync. One is more random and thus harder to guess, but it is also transmitted over the network and stored. Since users cannot memorize the random Firefox Sync key, it must be stored—but that makes it more vulnerable to theft. The one thing everyone will agree with is that the two systems illustrate the classic security/convenience trade-off.

The name "Profile in the Cloud" certainly suggests the ability to synchronize lots and lots more data, and "the cloud" is not exactly synonymous with secure storage of private data. Thus, it will be interesting to watch where PiCL heads next. Perhaps simply forcing users to actively think about security "classes" will, if nothing else, raise awareness of the risks of storing personal information remotely.