Overview
Support key exchange and key rotation between Weave Sync clients
Different versions of Weave Sync implement different key exchange mechanisms, however to date they have significant weaknesses in either user experience (UX) or security.
This wiki is (yet another) attempt to propose a solution which is both secure and an intuitive UX.
Existing Weave Sync Key Exchange Implementations
TODO
User Stories
- Information is secure: As a user I want my data to be secure, hence the sync key must be secure
- Easy to register: As a user I want to be able to register a new device with only the username and password, hence the key exchange must be very efficient and ideally transparent
- Easy to change key: As a user I want to be able to change the sync key in the case that it has become compromised, i.e. device lost or stolen
Desired Behaviour
1) Register a device using only username and password
2) If verification is required this must be no more than one additional step and involve no more than one additional device
3) A registered device can change the sync key and re-distribute it to other selected clients with minimal actions, i.e. see (2) above.
Implementation
What Needs To Be Done
- Implement registration protocol to authenticate a new client to an existing Weave Sync account
- Implement messaging protocol to support sending of messages between both registered and unregistered clients
- Implement key rotation protocol to change sync key and re-distribute to other registered clients
Registration Protocol
Two options immediately present themselves; use a passphrase as input in to a key derivation function (KDF)[^4]; Generate a random secret key and use an appropriate key exchange mechanism.
Importantly the Mozilla Weave project[^5] has implemented both of these solutions; a passphrase is used in the Weave storage API v3; and a random, but human readable, secret key is used in Weave storage API v5. Mozilla have found significant short comings with both of these solutions and are in the process of moving to a third solution in storage API v6, which uses a single password for both authentication and as input into a KDF. This is more convenient for the user, but importantly is significantly more complicated to implement as for this solution to be robust the password must not be known by the server even in the form of a salted hash.
For the secure contacts a random secret key implementation was chosen, however using an alternative key exchange mechanism so as not to be dependent on Mozilla services J-PAKE[^6] based key exchange, which requires two clients to be online concurrently and an unintuitive three step process. Secure contacts uses 3DHE[^7]and pre-generated ephemeral keys allowing key exchange two be completed in two steps and is abstracted from the underlying storage protocol.
Messaging Protocol
A bonus of using the 3DHE key exchange is that it naturally abstracts in to a generalised messaging protocol that can be abstracted to general messaging protocol that can be used to send an arbitrary messages encrypted with the session key derived during the 3DHE key exchange. In addition perfect forward secrecy can be achieved using axolotl key ratcheting[^8] as used in the Text Secure[^9] application. Although this is not implemented in Secure Contacts at this stage it presents an opportunity to extend functionality to include peer to peer key management that can be shared between multiple devices.
Key Rotation Protocol
TODO