It’s been more than a month since my last status report. Here’s what happened since then:
Firefox 4.0b8, Firefox Mobile 4.0b3, Sync 1.6
We’re getting ready to ship Firefox 4.0b8 and Firefox Mobile
4.0b3. Along with those beta releases we will ship Sync 1.6 as an add-on for Firefox 3.5/3.6. It will match the version of Sync built-in to the betas so that you can sync between Firefox 3.5/3.6 and the betas releases. Here’s what’s new in these releases and what we’ve been working on these past weeks:
Easy setup
Up until now, setting up Sync on a new computer has been a bit of a chore. With the wizard redesign by Alex Faaborg we reduced the number of necessary steps, but you still have to type your account name, password and Sync Key — particularly annoying on mobile devices.
We looked at how other systems cope with this problem in terms of usability. Bluetooth is a good example where you pair another device with an existing one while it’s often hard or even impossible to type on one of them. Obviously for Sync we need something that works on all platforms where Firefox is supported, ranging from desktop computers to mobile phones. Moreover, it needs to be secure so that Sync’s mission of protecting the user’s privacy isn’t compromised in any way.
The solution was PAKE (password-authenticated key agreement), a cryptographic mechanism for two parties to agree upon a strong key based on a weak shared secret, e.g. a Bluetooth-like PIN. In our case it allows a desktop computer that’s already connected to Sync to securely transfer the credentials to, say, a mobile phone. The mobile phone displays a random PIN that simply has to be entered on the desktop computer. Then both devices will go through the PAKE algorithm (J-PAKE in our case) to agree upon a strong key, communicating through a simple server via HTTPS. Once it’s verified on both sides, the desktop will send the credentials to the mobile phone. This way, you can set up a mobile phone for Sync with zero typing on the phone itself. Of course, this also works for setting up another desktop or laptop computer.
 |
 |
 |
|
This project included design and implementation work at all levels: designing and implementing the server API and communication protocol with my colleagues, making a prototype implementation of the J-PAKE algorithm, refactoring it to be based on the J-PAKE implementation Brian Smith created for NSS, and implementing the easy setup UI. It was challenging, sometimes outside my comfort zone, but possibly the most fun I’ve had in years.
Simpler crypto
Then and now
Up until now, Sync would protect your personal data as follows:
- Your Sync Key (a.k.a. secret phrase) is turned into a 256 bit AES key using PBKDF2.
- That key is used to encrypt/decrypt the private key of an RSA key pair that’s stored on the server.
- The RSA key pair is used to encrypt/decrypt 256 bit AES bulk keys, one per collection, that are used to encrypt/decrypt your private data.
The original vision was that indirection introduced by the RSA key pair as well as the simple PKI we had on the server would allow for easy sharing mechanisms. Alas these weren’t and aren’t a priority — rightly so IMHO — and the complexity of the setup had some serious impact on client and server performance. It also had some shortcomings security-wise.
We now have a much simpler setup that still guarantees the security and privacy of your personal data (better in some places, in fact).
- The Sync Key is now always a 128 bit random key, user generated Sync Keys are a thing of the past. This means you will no longer have to come up with a secure secret phrase of some kind, let alone understand what it means for a secret phrase to be cryptographically secure (fact is, most users don’t). When shown in the UI we encode the Sync Key in a modified base32 alphabet, making it 26 characters long. Fortunately you will rarely have to type those, thanks to the new easy setup mechanism.
- A 256 bit AES key and a 256 bit HMAC key are derived from the Sync Key using an HKDF.
- This key bundle is used to encrypt/decrypt a special keys record on the server. It contains the 256 bit AES and HMAC bulk keys that are used to encrypt/decrypt your personal data. By default there’s only one pair of AES and HMAC keys.
What gives?
So instead of storing at least half a dozen individual records on the server for the various keys, we only have one server record to fetch at the beginning, and we have plans to even cache that locally in the password manager. With 256 bit keys everywhere this is much more viable now.
On average the simplified crypto setup reduces the number of request per sync by ca. 15%. Our ops guys love us for this. On the client it makes the first sync per browser session much faster because there are fewer requests to the server and no RSA crypto is involved — particularly important on mobile devices. It also makes the first sync ever much faster because no RSA key pair has to be generated. Moreover, we can now optimize our crypto code for the simpler setup much better. Initial investigations have shown that a ~25% speed up and ~50% improvement in memory usage might be possible.
I can’t take all the credit for this. Our resident cryptographer Brian Smith helped us design much of the system and, following the proud Mozilla tradition of giving newbies projects that end up touching every single piece of code in the system, our new colleague Richard Newman implemented nearly all of the code.
Tighter integration with Places
Sync interacts a lot with Places, Firefox’s history and bookmark database. Now that Sync is being integrated into Firefox proper, we can couple them more tightly and gain better performance as a result.
For instance, Places will assign the GUIDs as used by Sync to history records and bookmarks as they are created, so that by the time Sync needs to deal with them, they will already be there. Having Places take over the disk I/O here means it will be not on the main thread and it will be part of operations that Places has to do anyway, so it’s less disk I/O overall.
We’re also considering adding more asynchronous APIs to Places, specifically with Sync’s usage in mind.
Coming up
Simplified crypto and easy setup were the last big changes we had lined up for Firefox 4. We still have a lot of work to do, but it’s mostly polish and paper cuts from here on.
There’s also increasing interest from third party developers in building clients for other browsers. Marcus Wolschon, for instance, has written a Firefox Sync client for the popular Androind browser Dolphin HD. Unfortunately, our API and developer docs are currently scattered across many pages in different locations of the Mozilla wiki. As we get closer to Firefox 4, I would like to spend some time collecting and updating that info and putting it in its own section on MDC/MDN.
