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
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.
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
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
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
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.
to post comments)