Services/Sync/WEP/101

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

WEP 101 - Cryptography Proxy

• Champions: Anant Narayanan <anant at mozilla dot com>
• Status: Draft
• Created: 24 Jul 2009
• Reference Implementation: https://crypto.services.mozilla.com/
• Reference Implementation Code: http://hg.mozilla.org/users/anarayanan_mozilla.com/weave-proxy/
• WEP Index

Introduction and Rationale

This WEP describes a way of delegating all cryptographic operations related to Weave data to a "proxy" server, thus saving cpu cycles on a client.

Two important aspects of the crypto proxy are:

• Ensure that the user's data is kept as safe as possible by sharing as little information as possible with the server.

• Provide compatibility with the existing Weave storage API to minimize code rewrite on clients that decide to use the proxy server.

Current Implementation

The provided reference implementation adheres to the storage API but requires an extra header X_WEAVE_PASSPHRASE. The data is returned exactly as it would have been with the storage server, except that the ciphertext portions are replaced with their corresponding plaintext.

The disadvantage of this scheme is that the user's passphrase is transmitted every time a request is made. Also, this gives the server potential access to any of the user's data because the private key is available to it.

Proposal

We propose to modify the current implementation to address some of the stated concerns. Assuming that the crypto proxy lives in a prefix, say, https://services.mozilla.com/crypto-proxy; the following operations will be possible:

Fetch a user's unwrapped symkeys

GET [prefix]/0.1/unwrap/[user]

The X_WEAVE_PASSWORD, and X_WEAVE_PASSPHRASE headers MUST be included in the request. The return value will be unwrapped symmetric keys for all of the user's collections.

Fetch a user's unwrapped symkey for a specific collection

GET [prefix]/0.1/unwrap/[user]/[collection]

The X_WEAVE_PASSWORD, and X_WEAVE_PASSPHRASE headers MUST be included in the request. The return value will be the unwrapped symmetric key for the given collection.

Fetch plaintext WBO records

GET [prefix]/0.1/storage/[storage-api-path]

Exactly one of the X_WEAVE_PASSPHRASE or X_WEAVE_SYMKEY headers MUST be included in the request. The return value will be the WBO, except that all ciphertext is replaced with their corresponding plaintext.

Discussion

The given proposal allows for two different levels of privacy enforcement on the client. The client may delegate all cryptographic operations to the server by providing X_WEAVE_PASSPHRASE, or unwrap a symmetric key for a particular collection and ask the server to decrypt only that collection by providing X_WEAVE_SYMKEY.

In all cases, the X_WEAVE_CLUSTER header MAY be provided. In the case it is absent, the crypto proxy will query the master head to find out the user's cluster address (thus delaying response).