Services/Sync/P2P Key Exchange And Rotation: Difference between revisions

From MozillaWiki
< Services‎ | Sync
Jump to navigation Jump to search
(Restructured page)
Line 1: Line 1:
Support secure and intuitive key exchange and key rotation between Weave Sync clients.
Over a number of versions of Weave Sync different key exchange mechanisms have been implemented, however to date they have had significant weaknesses in either security or user experience (UX) or both. This wiki describes (yet another) proposal which attempts to find the balance between (good enough) security and an intuitive UX.
== Overview ==
== Overview ==
Support key exchange and key rotation between Weave Sync clients
The objective of the P2P Key Exchange protocol is to securely transfer a secret key to a new weave client during registration. Importantly, as such it is only relevant for Weave Sync versions which utilise a randomly generated secret key, namely [https://docs.services.mozilla.com/sync/storageformat5.html Weave Sync v5] and the [https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol#pairing-extension pairing extension] of Weave Sync v6.
 
Arguable the Weave Sync v5 J-PAKE based key exchange protocol already achieves this, however as discussed below a significant weakness is that it requires three round trips to completed and thus requires both the new and an already registered client to be online concurrently and with good connectivity. Also Weave Sync v5, as currently implemented, does not support rotation of the secret key.
 
The P2P Key Exchange Protocol aims to address these issues by implementing a [http://lists.randombit.net/pipermail/cryptography/2013-October/005558.html 3DHE] based key exchange protocol with pre-generated ephemeral keys, allowing the key exchange to be completed asynchronously and in a single round trip. The same technique can also be leveraged for key rotation, although in this case only a single message needs to be sent by the initiating client, a response is not required but can be used to indicate success. The key exchange is also implemented within Weave Sync storage meaning no changes are required to the Weave Sync registration API to implement.
 
The P2P Key Exchange protocol is inspired by [https://github.com/WhisperSystems/TextSecure/ TextSecure].


Different versions of Weave Sync implement different key exchange mechanisms, however to date they have significant weaknesses in either user experience (UX) or security.
'Pros'
* User only needs to know username and password to register device
* Secret key is randomly generated
* Secret key does not leave device
* Key exchange is implemented using Weave Sync storage and thus is compatible with both Weave Sync v5 and the Weave Sync v6 pairing extension


This wiki is (yet another) attempt to propose a solution which is both secure and an intuitive UX.
'Cons'
* Registering additional devices after the first requires access to an already registered device
* Performing key exchange within Weave Sync storage may have security ramifications (TBD).


== Existing Weave Sync Key Exchange Implementations ==
== Existing Weave Sync Key Exchange Implementations ==
Line 12: Line 28:


'Pros'
'Pros'
* Registering additional devices does not require access to an additional device
* Registering additional devices does not require access to an already registered device
* Secret key does not leave device
* Secret key does not leave device


Line 20: Line 36:


===Weave Sync v5 (Easy Setup)===
===Weave Sync v5 (Easy Setup)===
Weave Sync v5 generates a secret key on account registration and for additional clients performs key exchange using the Easy Setup protocol based on J-PAKE protocol https://wiki.mozilla.org/Services/KeyExchange
Weave Sync v5 generates a secret key on account registration and for additional clients performs key exchange using the [https://wiki.mozilla.org/Services/KeyExchange Easy Setup] protocol based on [http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling J-PAKE].


'Pros'
'Pros'
* User only needs to know username and password to register device
* User only needs to know username and password to register device
* Secret key is randomly generated and never leaves device
* Secret key is randomly generated
* Secret key does not leave device


'Cons'
'Cons'
* Registering additional devices requires access to another device that is already registered
* Registering additional devices after the first requires access to an already registered device
* J-PAKE key exchange requires three round trips and hence both devices must be connected concurrently and with good connectivity
* J-PAKE key exchange requires three round trips and hence both devices must be connected concurrently and with good connectivity


Line 36: Line 53:
'Pros'
'Pros'
* User only needs to know username and password to register device
* User only needs to know username and password to register device
* Registering additional devices does not require access to another device
* Registering additional devices does not require access to an already registered device


'Cons'
'Cons'
Line 43: Line 60:
* Registration and authentication protocol significantly more complex
* Registration and authentication protocol significantly more complex


== User Stories ==
== Design ==
* 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
=== User Stories ===
* 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
 
* Information is secure: As a user I want my data to be secure, hence the secret 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
* Easy to change key: As a user I want to be able to change the secret key and de-register a device in the case that it has become compromised, i.e. device lost or stolen


=== Desired Behaviour ===
=== Desired Behaviour ===
Line 54: Line 74:
2) If verification is required this must be no more than one additional step and involve no more than one additional device
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.
3) A registered device can change the sync key and re-distribute it to other selected devices with minimal actions, i.e. see (2) above.
 


== Implementation ==
== Implementation ==
Note for the purposes of describing the technical implementation the term ''client'' will be used in place of ''device'' and similarly ''authorised/unauthorised'' will be used in place of ''registered/unregistered''.


=== What Needs To Be Done ===
=== 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 authorised (registered) and unauthorised (unregistered) clients (devices)
* Implement messaging protocol to support sending of messages between both registered and unregistered clients
* Implement registration protocol to authorise a new client (device) and exchange the secret key for an existing Weave Sync account
* Implement key rotation protocol to change sync key and re-distribute to other registered clients
* Implement key rotation protocol to change the secret key and re-distribute to other authorised (registered) clients (devices)
 
===Messaging Protocol===
A bonus of using the 3DHE key exchange is that it naturally abstracts in to a generalised 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 at this stage it presents an opportunity to extend functionality to include peer to peer key management that can be shared between multiple devices.


=== Registration Protocol ===
=== 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.
TODO
 
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===
===Key Rotation Protocol===
TODO
TODO

Revision as of 05:00, 8 November 2014

Support secure and intuitive key exchange and key rotation between Weave Sync clients.

Over a number of versions of Weave Sync different key exchange mechanisms have been implemented, however to date they have had significant weaknesses in either security or user experience (UX) or both. This wiki describes (yet another) proposal which attempts to find the balance between (good enough) security and an intuitive UX.

Overview

The objective of the P2P Key Exchange protocol is to securely transfer a secret key to a new weave client during registration. Importantly, as such it is only relevant for Weave Sync versions which utilise a randomly generated secret key, namely Weave Sync v5 and the pairing extension of Weave Sync v6.

Arguable the Weave Sync v5 J-PAKE based key exchange protocol already achieves this, however as discussed below a significant weakness is that it requires three round trips to completed and thus requires both the new and an already registered client to be online concurrently and with good connectivity. Also Weave Sync v5, as currently implemented, does not support rotation of the secret key.

The P2P Key Exchange Protocol aims to address these issues by implementing a 3DHE based key exchange protocol with pre-generated ephemeral keys, allowing the key exchange to be completed asynchronously and in a single round trip. The same technique can also be leveraged for key rotation, although in this case only a single message needs to be sent by the initiating client, a response is not required but can be used to indicate success. The key exchange is also implemented within Weave Sync storage meaning no changes are required to the Weave Sync registration API to implement.

The P2P Key Exchange protocol is inspired by TextSecure.

'Pros'

  • User only needs to know username and password to register device
  • Secret key is randomly generated
  • Secret key does not leave device
  • Key exchange is implemented using Weave Sync storage and thus is compatible with both Weave Sync v5 and the Weave Sync v6 pairing extension

'Cons'

  • Registering additional devices after the first requires access to an already registered device
  • Performing key exchange within Weave Sync storage may have security ramifications (TBD).

Existing Weave Sync Key Exchange Implementations

Weave Sync v3 (Passphrase)

Weave Sync v3 derives a secret key from a user selected passphrase independent of the account password.

'Pros'

  • Registering additional devices does not require access to an already registered device
  • Secret key does not leave device

'Cons'

  • User needs to know passphrase in addition to username and password to register device
  • Secret key is only as secure as passphrase

Weave Sync v5 (Easy Setup)

Weave Sync v5 generates a secret key on account registration and for additional clients performs key exchange using the Easy Setup protocol based on J-PAKE.

'Pros'

  • User only needs to know username and password to register device
  • Secret key is randomly generated
  • Secret key does not leave device

'Cons'

  • Registering additional devices after the first requires access to an already registered device
  • J-PAKE key exchange requires three round trips and hence both devices must be connected concurrently and with good connectivity

Weave Sync v6 (One Password)

Like v3, Weave Sync v6 derives a secret key from a user selected passphrase, however the onepw protocol uses a single password/passphrase for both authentication and key derivation to address useability issues with v3 caused by maintaining independent passwords/passphrases. https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol

'Pros'

  • User only needs to know username and password to register device
  • Registering additional devices does not require access to an already registered device

'Cons'

  • Secret key is derived from password which is partially known by authentication server
  • Secret key is only as secure as password
  • Registration and authentication protocol significantly more complex

Design

User Stories

  • Information is secure: As a user I want my data to be secure, hence the secret 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
  • Easy to change key: As a user I want to be able to change the secret key and de-register a device 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 devices with minimal actions, i.e. see (2) above.

Implementation

Note for the purposes of describing the technical implementation the term client will be used in place of device and similarly authorised/unauthorised will be used in place of registered/unregistered.

What Needs To Be Done

  • Implement messaging protocol to support sending of messages between both authorised (registered) and unauthorised (unregistered) clients (devices)
  • Implement registration protocol to authorise a new client (device) and exchange the secret key for an existing Weave Sync account
  • Implement key rotation protocol to change the secret key and re-distribute to other authorised (registered) clients (devices)

Messaging Protocol

A bonus of using the 3DHE key exchange is that it naturally abstracts in to a generalised 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 at this stage it presents an opportunity to extend functionality to include peer to peer key management that can be shared between multiple devices.

Registration Protocol

TODO

Key Rotation Protocol

TODO