Services/Sync/P2P Key Exchange And Rotation

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 v1.1 API/v5 Data and the pairing extension of Weave Sync v1.5 API/v5 Data.

Arguable the J-PAKE based key exchange protocol used in Weave Sync v1.1/v5 already achieves this, however as discussed below a significant weakness is that it requires three round trips to complete and thus requires both the new and an already registered client to be online concurrently and with good connectivity. Also Weave Sync v1.1/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 v1.1/v5 and the Weave Sync v1.5/v5 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.

Existing Weave Sync Key Exchange Implementations

Passphrase (v1.1 API/v3 Data)

The Passphrase implementation 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

Easy Setup (v1.1 API/v5 Data)

The Easy Setup implementation generates a secret key on account registration and for additional clients performs key exchange using 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

One Password (v1.5 API/v5 Data)

Like the Passphrase implementation, the One Password (onepw) implementation derives a secret key from a user selected passphrase, however a single password/passphrase is used for both authentication and key derivation to address useability issues with maintaining independent passwords/passphrases.

'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 master key for an existing Weave Sync account
• Implement key rotation protocol to change the master key and re-distribute to other authorised (registered) clients (devices)

eXfio Peer v1

Messaging Protocol

Version 1 of the eXfio Peer protocol leverages 3DHE key exchange. A bonus of using 3DHE 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 as used in the Text Secure 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.

Protocol Sequence

0. Each client publishes an identity key (AIp, BIp) and a set of ephemeral keys (AE{1..n}p, BE{1..n}p)
1. Client A generates a new ephemeral key (AEp) and randomly selects one of Client B's ephemeral keys (BEp). Using 3DHE and a KDF, client A generates the shared secret (SK) then sends message including own ephemeral key (AE) and an identifier for Client B's ephemeral key (BEp). Client B can now also generate the shared secret (SK) and hence the message body can be encrypted immediately.

Both Client A and Client B can now continue to communicate using the shared secret (SK) as a session key.

           Alice (Client A)                       Eve (Public)     Bob (Client B)

t0         AIs                                    AIp, BIp         BIs
                                                  BE{1..n}p        BE{1..n}s

t1         AIs                                    AIp, BIp         BIs
           AEs                                    AEp, BEp         BEs
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))                      SK = KDF(3DHE(BIs, BEs, AIp, AEp))
           PT = <message>                                          CT
           CT = ENCRYPT(PT, SK)                                    PT = DECRYPT(CT, SK)
                                                                   

EphemeralKey JSON

{
  keyid:     "id of ephemeral key",
  key:       "ephemeral public key"
}

Client JSON

{
  version:   "version of client record",
  clientid:  "id of client",
  name:      "name of client",
  key:       "identity public key",
  ekeys:     [EphemeralKey1, EphemeralKey2, ..., EphemeralKeyn],
  status:    "indicates if client is authorised, i.e. 'authorised' or 'pending'",
  authlevel: "will this client accept messages from unauthorised clients, 
             i.e. 'all' indicates all clients, 'authorised' indicates authorised clients only"
  hmac:      "HMAC of all other client fields"
}

Message JSON

{
  version:      "version of message record",
  srcclientid:  "id of sender",
  srckeyid:     "id of sender's ephemeral key",
  srckey:       "sender's ephemeral key (optional after first message, i.e. sequence > 1)",
  dstclientid:  "id of receiver",
  srckeyid:     "id of receiver's ephemeral key",
  sequence:     "sequence of this message in session",
  type:         "message type",
  content:      "message content"
  hmac:         "HMAC of all other message fields"
}

Registration Protocol

IMPORTANT: If the attacker has full access to the storage, i.e. a hostile systems administrator, and knows the password a man-in-the-middle (MITM) attack is possible. At this time there is an implicit (and quite possibly incorrect) assumption that the systems administrator does not know the password. See version 2 of protocol for improved handling of this risk.

When Alice registers a new device with the Weave Sync server the client first checks if there are other authorised clients, if not it initialises the storage, if so it requests authorisation by following the procedure below.

0. Client A: Authenticate to sync server and create client record with status of 'pending'
1. Client A: Send ClientAuthRequestMessage to existing authorised clients, i.e. Client B, including authcode digest (AD)
2. Out-of-Band: Client A displays authcode (AC) and user enters it on Client B
3. Client B: If authcode (AC) is verified send ClientAuthResponseMessage with sync key

Finally Alice is notified of registration status and if successful client record is updated with status of 'approved'.

           Alice (Client A)                       Eve (Public)     Bob (Client B)

t0         AIs                                    AIp, BIp         BIs, MK
                                                  BEp              BEs

t1         AIs                                    AIp, BIp         BIs, MK
           AEs                                    AEp, BEp         BEs
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))                      SK = KDF(3DHE(BIs, BEs, AIp, AEp))
           VC = RANDOM()                                           VD
           VD = DIGEST(VC + DIGEST(password))

t2         AIs                                    AIp, BIp         BIs, MK
(OoB)      VC                                                      VCui = <user input>
           VD                                                      VD
                                                                   Verified = (VD == DIGEST(VCui + DIGEST(password)))

t3         AIs, MK                                AIp, BIp         BIs, MK

Notes:

• The authcode is a random alphanumeric string which needs to be entered on the authorising device to verify the authenticity of the request. If the authcode is entered correctly then a man-in-the-middle attack is highly unlikely.

ClientAuthVerifier JSON

{
  innersalt:  "Salt value for inner hash, i.e. hash(password)
  salt:       "Salt value for outer hash
  digest:     "hash(authcode + hash(password))
}

ClientAuthRequestMessage JSON

{
  clientid:  "id of client",
  name:      "name of client",
  auth:      ClientAuthVerifier
}

ClientAuthResponseMessage JSON

{
  clientid:  "id of client",
  name:      "name of client",
  status:    "okay|fail",
  message:   "authorisation approved|authorisation rejected",
  synckey:   "Master key for Weave Sync account (required if status 'okay')"
}

Key Rotation Protocol

TODO

eXfio Peer v2

Version 2 of the eXfio Peer protocol improves the protection against a man in the middle (MITM) attack, at the expense of a more complex protocol, requiring two round-trips. Importantly the starting assumption is that an adversary has full access to the storage and knows the password, i.e. a hostile systems administrator. Fortunately an elegant means to mitigate against this threat is to use a SCIMP style hash commitment, which results in the adversary having a single opportunity to guess the authcode with a probability of 1.05 x 10^-6.

Messaging Protocol

By requiring the responding party, Bob, to nominate a key in advance using a hash commitment, a MITM adversary, Eve, is required to select a public key without knowing the either Alice key. Thus making it very difficult to launch a MITM attack without detection. See #Registration_Protocol_2

Protocol Sequence

0. Each client publishes an identity key (AI, BI) and a set of ephemeral key digests (AE{1..n}, BE{1..n}d)
1. Client A: Generates a new ephemeral key (AEp) and sends a message to Client B nominating one of client B's ephemeral key digests (BEd).
2. Client B: Using 3DHE and a KDF generates the shared secret (SK) then sends message including own ephemeral key (BEp) matching digest (BEd). Client A can now also generate the shared secret (SK) and hence the message body can be encrypted immediately.

Both Client A and Client B can now continue to communicate using the shared secret (SK) as a session key.

           Alice (Client A)                       Eve (MITM)       Bob (Client B)

t0         AIs                                    AIp, BIp         BIs
                                                  BE{1..n}d        BE{1..n}s
                                                                   BE{1..n}p

t1         AIs                                    AIp, BIp         BIs
           AEs                                    AEp              BEs
                                                  BEd              BEp

t2         AIs                                    AIp, BIp         BIs
           AEs                                    AEp, BEp         BEs
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))     BEd              SK = KDF(3DHE(BIs, BEs, AIp, AEp)
           CT                                                      PT = <message>
           PT = DECRYPT(CT, SK)                                    CT = ENCRYPT(PT, SK)

EphemeralKey JSON

{
  keyid:     "id of ephemeral key",
  keydigest: "digest of ephemeral public key"
}

Client JSON

{
  version:   "version of client record",
  clientid:  "id of client",
  name:      "name of client",
  key:       "identity public key",
  ekeys:     [EphemeralKey1, EphemeralKey2, ..., EphemeralKeyn],
  status:    "indicates if client is authorised, i.e. 'authorised' or 'pending'",
  authlevel: "will this client accept messages from unauthorised clients, 
             i.e. 'all' indicates all clients, 'authorised' indicates authorised clients only"
  hmac:      "HMAC of all other client fields"
}

Message JSON

{
  version:      "version of message record",
  srcclientid:  "id of sender",
  srckeyid:     "id of sender's ephemeral key",
  dstclientid:  "id of receiver",
  dstkeyid:     "id of receiver's ephemeral key",
  sequence:     "sequence of this message in session",
  type:         "message type",
  content:      "message content"
  hmac:         "HMAC of all other message fields"
}

SessionRequestMessage JSON

{
  clientid:     "id of client",
  name:         "name of client"
  srckey:       "sender's ephemeral key",
  dstkeydigest: "digest of receiever's ephemeral key"
}

SessionVerifier JSON

{
  timestamp:  "time used as input in to verification"
  salt:       "salt used as input in to verification"
}

SessionResponseMessage JSON

{
  clientid:  "id of client",
  name:      "name of client",
  status:    "okay|fail",
  message:   "ephemeral key okay|ephemeral key mismatch",
  dstkey:    "ephemeral key matching dstkeydigest (if status okay)",
  auth:      SessionVerifier (if status okay)
}

Registration Protocol

The objective of the registration protocol is for a user, i.e. Alice, to authorise a new device and transfer to it the master key (sync key) thus allowing it to read and write encrypted data to and from the storage. To maintain the security of the master key the protocol must defend against a man-in-the-middle (MITM) attack from an adversary. Importantly for version 2 of the eXfio Peer protocol the starting assumption is that an adversary has full access to the storage and knows the password, i.e. a hostile systems administrator.

When a user registers a new device with the Weave Sync server the client first checks if any devices have already been registered. If there are no registered devices it generates a master key (MK) and initialises the storage. If there are existing registered devices it requests authorisation by following the procedure below.

Candidate Solution A

Candidate solution A has the benefit that all user input takes place on the new device, Client A, and thus the user experience is similar to second factor authentication (2FA) using software based one time password (OTP) application such as Google Authenticator. Out-of-band verification mitigates against the impersonation of Client A and Client B, however because only the registered device, Client B, can determine if verification of Client A has been successful if a user incorrectly enters the authcode additional messages need to be exchanged between clients potentially causing confusion as a result of the delay in notifying the user that verification has failed.

Note: When the new device is mobile a QR code could be used for the out-of-band verification, which would remove the need for user input.

0. Client A: Authenticate to sync server and create client record with status of 'pending'
1. Client A: Send SessionRequestMessage to registered devices, providing an ephemeral key (AEp) and nominating an ephemeral key digest (BEd) of other device, i.e. Client B
2. Client B: Send SessionResponseMessage including ephemeral key (BEp) nominated by Client A
3. Out-of-Band: User sights authcode displayed on Client B, generated from session key and random value, and enters it on Client A
4. Client A: If the session key component (VCS) of authcode is verified then send ClientAuthV2RequestMessage including the random value component of authcode (VCR), thus proving the user is in possession of a registered device, i.e. Client B
5. Client B: If Client A responds with proof of possessing registered device then send ClientAuthV2ResponseMessage including the master key

Finally the user is notified of the registration status and if successful client record is updated with status of 'approved'

           Alice (Client A)                       Eve (Public)     Bob (Client B)

t0         AIs                                    AIp, BIp         BIs, MK
                                                  BEd              BEs
                                                                   BEp

t1         AIs                                    AIp, BIp         BIs, MK
           AEs                                    AEp              BEs
                                                  BEd              BEp

t2         AIs                                    AIp, BIp         BIs, MK
           AEs                                    AEp, BEp         BEs
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))     BEd              SK = KDF(3DHE(BIs, BEs, AIp, AEp)
           Verified = (BEd == DIGEST(BEp))                       

t3         AIs                                    AIp, BIp         BIs, MK
(OoB)      SK                                                      SK
           VCSui = <user input>                                    VCS = DIGEST(SK)
           VCRui = <user input>                                    VCR = RANDOM()
           Verified = (VCSui == DIGEST(SK))                                        

t4         AIs                                    AIp, BIp         BIs, MK
           SK                                                      SK
                                                                   VCR
                                                                   VCRui
                                                                   Verified = (VCRui == VCR)

t5         AIs, MK                                AIp, BIp         BIs, MK

Notes:

• The authcode (VCS + VCR) is a digest of the session key and a random value respectively. This code needs to be entered on the device requesting authorisation to verify the user is in possession of registered device. If the authcode displayed by Client B matches the VCS value generated on Client A then a man-in-the-middle attack impersonating Client B is highly unlikely. Finally if the VCRui value returned to Client B matches the original VCR random value then a man-in-the-middle attack impersonating Client A is highly unlikely.
• To minimise errors during user input the authcode can be represented using a word list, i.e. PGP, Diceware, S/KEY or optionally scanned using a QR code.

Candidate Solution B

Candidate solution B has the benefit that user input for out-of-band verification takes place on the registered device, Client B, which can determine if the verification of Client A has been successful without exchanging additional messages between clients. However to detect a MITM adversary impersonating Client B an additional verification check is needed on the new device, Client A. Although this attack would not result in a compromise of the master key it could result in the sharing of confidential data. Thus if a user incorrectly enters the authcode additional messages need to be exchanged between clients, however the out-of-band verification flow and user input flow would be in alignment, thus resulting in improved user experience.

Note: Similarly to Candidate solution A, when the new device is mobile a QR code could be used for the out-of-band verification, which would remove the need for user input and mitigate against the impersonation of Client A and Client B.

           Alice (Client A)                       Eve (MITM)     Bob (Client B)

t0         AIs                                    AIp, BIp         BIs, MK
           AEs                                    AEd, BEd         BEs
           AEp                                                     BEp

t1         AIs                                    AIp, BIp         BIs, MK
(OoB)      AEs                                    AEd, BEd         BEs
           AEp                                                     BEp
           VCS = DIGEST(AIp, AEp)                                  VCSui = <user input>
           VCR = RANDOM()                                          VCRui = <user input>

t2         AIs                                    AIp, BIp         BIs, MK
           AEs                                    BEp              BEs
           AEp                                    AEd, BEd         VCSui     
           VCS                                                     VCRui
           VCR                                                     
           Verified = (BEd == DIGEST(BEp))                         

t3         AIs                                    AIp, BIp         BIs, MK
           AEs                                    AEp, BEp         BEs
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))     BEd              SK = KDF(3DHE(BIs, BEs, AIp, AEp)
           VCS                                                     VCSui
           VCR                                                     VCRui
                                                                   Verified = (VCSui == DIGEST(AIp, AEp) + AEd == DIGEST(AEp))

t4         AIs, MK                                AIp, BIp         BIs, MK
           SK                                                      SK
           VCR                                                     VCRui
           VCRui                                                   
           Verified = (VCRui == VCR)                               

Notes:

• The authcode (VCS + VCR) is a digest of Client A's identity key and ephemeral key and a random value respectively. This code must be entered on a registered device to verify the user is in possession of the device requesting authorisation. If the authcode displayed by Client A matches the VCS value generated on Client B and if Client A's hash commit matches the digest of Client A's public key then a man-in-the-middle attack impersonating Client A is highly unlikely. Finally if the VCRui value returned to Client A matches the original VCR random value then a man-in-the-middle attack impersonating Client B is highly unlikely.
• To minimise errors during user input the authcode can be represented using a word list, i.e. PGP, Diceware, S/KEY or optionally scanned using a QR code.

ClientAuthV2Verifier JSON

{
  proof:  "Proof of receiving authcode through out of band channel"
}

ClientAuthV2RequestMessage JSON

{
  clientid:  "id of client",
  name:      "name of client",
  auth:      ClientAuthV2Verifier
}

ClientAuthV2ResponseMessage JSON

No change from V1

Key Rotation Protocol

TODO

Vulnerabilities

On deeper inspection of eXfio Peer v2 there are two vectors of attack that present themselves, a honeypot and a targeted phishing attack.

Honeypot

An adversary could set up a sync server and invite users to join, with say an offer of unlimited stage. When the user creates an account the hostile sync server initialises the storage with a fictitious authorised device, thus giving the impression that the user had previously registered with the service. The user could be presented with an authcode to enter on their device this transferring a pre-generated master key, known by the server, to the newly registered device.

Countermeasures

TODO

Targeted Phishing

Similar to a honeypot, but targeted at a user that has already registered one or more devices, an adversary with control of the sync server could request the user to authorise the registration of a fictitious device, i.e. with a similar name to a device familiar to the user. If the user then enters the authcode as requested, i.e. into a web page, the master key will be transferred to the fictitious device.

Countermeasures

TODO

Other Key Exchange Protocols

SCIMP Messaging Protocol

           Alice (Client A)                       Eve (Public)     Bob (Client B)

t1         AEs                                    AEd              
           AEp

t2         AEs                                    AEd              BEs
           AEp                                    BEp              

t3         AEs                                    AEd              BEs
                                                  AEp, BEp         Verified = (AEd = DIGEST(AEp))

t4         AEs                                    AEd              BEs
           SK = ECDH(BEp, AEp, AEs)               AEp, BEp         SK = ECDH(AEp, BEp, BEs)

t5         SK                                                      SK
(OoB)      VC = DIGEST(SK)                                         VC = DIGEST(SK)
           VCui = <user input>                                     VCui = <user input>
           Verified = (VCui == VC)                                 Verified = (VCui == VC) 

Signal (TextSecure) Registration Protocol

           Alice (Client A)                       Eve (Public)     Bob (Client B)
t0                                                AUID, BUID       BIs, MK
                                                  BIp

t1         AIs                                    AUID, BUID       BIs, MK
(OoB)      AIp                                    BIp              AIp = <user input>

t2         AIs, MK                                AUID, BUID       BIs, MK
                                                  AIp, BIp