Labs/Weave/Crypto: Difference between revisions

From MozillaWiki
< Labs‎ | Weave
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
= Overview =
= Our Design Principles =
 
* Data stored on the server should be as private, and as safe, as data on your personal computer or device
* Data is encrypted on the client by default, using a passphrase known only to the user
* Server operators <i>are unable to disclose</i> information, because they can't read it.
* Securing the personal computer is still important, and is the user's responsibility: a master password and proper care to run only trusted software are still critical.
 
= In Detail =


The Weave services were designed to be safe enough to store the same information that lives on your personal computer or device.  For the Sync application, this includes the password file, browsing history, and form history of your browser.
The Weave services were designed to be safe enough to store the same information that lives on your personal computer or device.  For the Sync application, this includes the password file, browsing history, and form history of your browser.
Line 9: Line 16:
So, if somebody were able to get your username and password, all they could get is your encrypted data records.  They would then need to know your passphrase to decrypt your data.  Now, getting access to the encrypted data could enable certain kinds of analysis, so it's important to keep your password safe, but the passphrase is the really important key.
So, if somebody were able to get your username and password, all they could get is your encrypted data records.  They would then need to know your passphrase to decrypt your data.  Now, getting access to the encrypted data could enable certain kinds of analysis, so it's important to keep your password safe, but the passphrase is the really important key.


None of this removes the need for good personal computer security, of course!  We strongly recommend that you enable a Master Password for your Firefox, which causes your passwords and form history to be encrypted; this will protect you if your computer is stolen or is infected with a trojan.  We also strongly recommand that you only run addons from trusted sources, as Firefox addons have broad access to sensitive data through internal APIs.  If you're interested in our efforts to create a more secure internal API for addons, please check out the [http://mozillalabs.com/Jetpack Jetpack] project.
None of this removes the need for good personal computer security, of course!  We strongly recommend that you enable a Master Password for your Firefox, which causes your passwords and form history to be encrypted; this will protect you if your computer is stolen or is infected with a trojan.  We also strongly recommand that you only run addons from trusted sources, as Firefox addons have broad access to sensitive data through internal APIs.  If you're interested in our efforts to create a more secure internal API for addons, please check out the [http://mozillalabs.com/Jetpac1 Jetpack] project.
 
 
= Super-short summary for experienced Crypto developers: =
 
The Weave client creates a 2048-bit RSA keypair and a salt value, and derives a symmetric key from the passphrase and salt with PBKDF2.  The private key is encrypted with that key and uploaded to the server, along with the salt and cleartext public key.
 
For each collection, a 256-bit bulk key and an IV are generated on the client.  The bulk key is encrypted with the RSA public key and uploaded, with the IV, to the server.
 
Each object is AES-256-CBC encrypted with the bulk key for its collection.  In theory, we could have multiple bulk keys for each collection, but we do not do that right now.  In theory, we could encrypt each bulk key with multiple public keys to create a key-chain; we discuss this at [[Labs/Weave/Developer/SecureDataSharing]].
 
= Longer explanation =
 
First, let’s get some basic definitions out of the way. Symmetric cryptography means you have one key that can perform both encryption and decryption, and they are complementary operations. For Weave, we use [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES] with a 256 bit key, and we use it in a mode that requires an ‘initialization vector’ for every decryption. Asymmetric cryptography means there’s a pair of keys (usually called ‘public’ and ‘private’ keys). A piece of text “encrypted” by one key can only be “decrypted” by the other key. Here, we use [http://en.wikipedia.org/wiki/RSA RSA] with a 2048 bit private key.
 
So, when a user first signs up for Weave using the wizard on their computer, we generate a (random) pair of public and private keys. Next, we use the user’s passphrase to create a symmetric key. This is done using a pretty standard algorithm known as [http://en.wikipedia.org/wiki/PBKDF2 PBKDF2] (short for “Password Key Derivation Function”). The PBKDF2 algorithm requires a ’salt’ value which is also stored on the server. Now that we have a symmetric key, we use it to encrypt the user’s private key and upload it along with the public key to the server. Note that the passphrase is never sent to the server, so if the user’s password ever gets compromised all the attacker can get is their encrypted private key, which really isn’t of much use (especially given that the key is 2048 bits long).
 
Whenever a particular “engine” is to be synchronized (an engine could be Tabs, Bookmarks, History etc.) we generate a random symmetric key for that engine. This key is then encrypted using the user’s public key (now, one can only retrieve the original symmetric key with the corresponding private key) and uploaded as being associated with a particular engine. All entries (the ‘ciphertext’ property in a “Weave Basic Object”) in that engine are encrypted with the symmetric key that was generated for it.
 
To make things clear, let’s enumerate the steps we would take to decrypt a single tab object for user ‘foo’:
 
# Find the user’s cluster by making a GET request to https://services.mozilla.com/user/1/foo/node/weave. It returns https://sj-weave06.services.mozilla.com/.
# Fetch the user’s encrypted private key and public key from https://sj-weave06.services.mozilla.com/0.5/foo/storage/keys/privkey and https://sj-weave06.services.mozilla.com/0.5/foo/storage/keys/pubkey respectively. The user’s password is required to access these JSON objects.
# Ask the user for their passphrase and generate a 256 bit symmetric key from it using PBKDF2 and the ’salt’ found in the privkey object.
# Use the generated symmetric key and the initialization vector found in the ‘iv’ property of the privkey object to decrypt the user’s private key.
# Fetch the user’s encrypted tab objects from https://sj-weave06.services.mozilla.com/0.5/foo/storage/tabs/?full=1.
# Fetch the corresponding symmetric key (the URL is also listed in the “encryption” property of every WBO), in this case https://sj-weave06.services.mozilla.com/0.5/foo/storage/crypto/tabs.
# Decrypt the symmetric key with the user’s private key.
# Use the decrypted symmetric key to decrypt any WBO from the tabs collection with the initialization vector found in the ‘bulkIV’ property of the tabs symmetric key WBO.
# Profit.
 
A word about the formats in which the keys are actually stored in. All values are Base64. For symmetric keys, they key is stored as-is. For asymmetric keys, I wish we used a standard format like PKCS#12, but we don’t. It’s still [http://en.wikipedia.org/wiki/ASN.1 ASN.1] though, in some format NSS exports private keys in. You need to do a bit of ASN.1 parsing to figure out the values you’re interested in.
 
Fortunately, I’ve already figured out most of the details for you – check out my [http://hg.mozilla.org/labs/weaveweb/file/tip/weave.js#l163 Javascript] or [http://hg.mozilla.org/users/anarayanan_mozilla.com/weave-proxy/file/tip/crypto/ PHP] implementations of the crypto elements required to decrypt Weave Basic Objects.
 
Finally, a quick note about why we do all this. Sharing is now reasonably easy, if you want to share your bookmarks with someone, you just need to encrypt the corresponding symmetric key with their public key and they’re good to go. Also, each WBO has it’s own ‘encryption’ property so this can be as granular as needed. Secondly, the passphrase is never stored anywhere (except possibly on the user’s computer) so the server never sees anything other than encrypted blobs of Base64′ed text. Along with making HTTPS mandatory, we think this is a pretty secure way of protecting the user’s data.
 
If you have other encryption schemes that might fit into Weave’s use cases please let us know! (We’ve already been looking at interesting developments in this area such as [http://allmydata.org/~warner/pycon-tahoe.html Tahoe]). I’d also love to hear from you if you have any questions on our current cryptography scheme. We’re constantly trying to improve the security and efficiency of our system so these details are only valid until we change our scheme :-)


----
If you are a developer, you can get a detailed explanation of the cryptographic processes used in Weave on the [[Labs/Weave/Developer/Crypto|Developer Crypto]] page.
Original text by Anant, October 11, 2009, posted at http://www.kix.in/blog/2009/10/how-does-weave-use-cryptography/

Revision as of 18:08, 5 February 2010

Our Design Principles

  • Data stored on the server should be as private, and as safe, as data on your personal computer or device
  • Data is encrypted on the client by default, using a passphrase known only to the user
  • Server operators are unable to disclose information, because they can't read it.
  • Securing the personal computer is still important, and is the user's responsibility: a master password and proper care to run only trusted software are still critical.

In Detail

The Weave services were designed to be safe enough to store the same information that lives on your personal computer or device. For the Sync application, this includes the password file, browsing history, and form history of your browser.

Our goal was to make sure that we could not disclose this information. To make this happen, we employed a layer of client-side encryption that is beyond what normal websites employ.

The Weave passphrase is what makes this work. Remember, your browser knows your passwords and form history already: it's all decrypted, in your local memory. Using the passphrase, we encrypt your information on your local computer. We then use industry-standard SSL to relay the encrypted information to the server. Your Weave account, which keeps the encrypted data organized, is protected by the username-password you select. (In practice, we actually end up using an encrypted key chain, which allows other devices to decrypt your information, once they have your passphrase: more details below).

So, if somebody were able to get your username and password, all they could get is your encrypted data records. They would then need to know your passphrase to decrypt your data. Now, getting access to the encrypted data could enable certain kinds of analysis, so it's important to keep your password safe, but the passphrase is the really important key.

None of this removes the need for good personal computer security, of course! We strongly recommend that you enable a Master Password for your Firefox, which causes your passwords and form history to be encrypted; this will protect you if your computer is stolen or is infected with a trojan. We also strongly recommand that you only run addons from trusted sources, as Firefox addons have broad access to sensitive data through internal APIs. If you're interested in our efforts to create a more secure internal API for addons, please check out the Jetpack project.

If you are a developer, you can get a detailed explanation of the cryptographic processes used in Weave on the Developer Crypto page.

Retrieved from "https://wiki.allizom.org/index.php?title=Labs/Weave/Crypto&oldid=200086"