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.
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.
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
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
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
Exactly one of the
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.
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
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).