Integrating key-exchange protocols in Waku2

[s1fr0]

Problem

26/WAKU2-PAYLOAD defines how message payloads can be encrypted using symmetric/asymmetric primitives. However, a protocol to allow users to safely exchange encryption cryptographic keys is missing. This issue proposes to integrate multiple Noise handshakes in Waku2 to address the current lack of key-exchange protocols and ultimately allow instantiation of end-to-end (E2E) encrypted communication channels between users.

After a key-exchange protocol is fully executed, all encrypted payloads satisfy the following security properties: confidentiality, integrity, authentication and perfect forward secrecy.

Depending on the type of handshake employed, some further identity-hiding property on communicating parties are also possible.

This issue addresses vacp2p/research#97.

Proposed solution

Suggested Handshake Patterns

The Noise handshakes we suggest address four typical scenarios occurring when an encrypted communication channel between Alice and Bob is going to be created:

• Alice and Bob know each others' static key.
• Alice knows Bob's static key;
• Alice and Bob share no key material, but they don't know each others' static key.
• Alice and Bob share some key material, but they don't know each others' static key.

Once the handshake is terminated, Alice and Bob will share some encryption/decryption key material which is updated according to a pre-agreed set of rules.

The K1K1 Handshake

If Alice and Bob know each others' static key (e.g., these are public or were already exchanged in a previous handshake) , they can execute a K1K1 handshake. Using Noise notation (Alice is on the left) this can be sketched as:

 K1K1:
    ->  s
    <-  s
       ...
    ->  e
    <-  e, ee, es
    ->  se

We note that here only ephemeral keys are exchanged. This handshake is useful in case Alice needs to instantiate a new separate encrypted communication channel with Bob, e.g. multiple remote connections, file transfers, etc.

The XK1 Handshake

Here, Alice knows how to initiate a communication with Bob and she knows his public static key: such discovery can be achieved, for example, through a publicly accessible register of users' static keys, smart contract, or through a previous public/private advertisement of Bob's static key.

A Noise handshake pattern that suits this scenario is XK1:

 XK1:
    <-  s
       ...
    ->  e
    <-  e, ee, es
    ->  s, se

Within this handshake, Alice and Bob reciprocally authenticate their static keys s using ephemeral keys e. We note that while Bob's static key is assumed to be known to Alice (and hence is not transmitted), Alice's static key is sent to Bob encrypted with a key derived from both parties ephemeral keys and Bob's static key.

The XX and XXpsk0 Handshakes

If Alice is not aware of any static key belonging to Bob, she can execute an XX handshake, where each party tranXmits to the other its own static key.

The handshake goes as follows:

 XX:
    ->  e
    <-  e, ee, s, es
    ->  s, se

We note that the main difference with XK1 is that in second step Bob sends to Alice his own static key encrypted with a key obtained from an ephemeral-ephemeral Diffie-Hellman exchange.

This handshake can be slightly changed in case both Alice and Bob pre-shares some secret psk which can be used to strengthen their mutual authentication during the handshake execution. One of the resulting protocol, called XXpsk0, goes as follow:

 XXpsk0:
    ->  psk, e
    <-  e, ee, s, es
    ->  s, se

The main difference with XX is that Alice's and Bob's static keys, when transmitted, would be encrypted with a key derived from psk as well.

Handshakes Integration Timeline

We propose to implement and integrate in Waku2 the suggested Noise handshakes in the following order:

1. K1K1;
2. XK1;
3. XX;
4. XXpsk0.

This is motivated by the following facts:

• XXpsk0 can be transformed to an XX handshake using an empty psk;
• XX can be transformed to an XK1 handshake if Bob doesn't transmit to Alice his static key;
• XK1can be transformed to K1K1 if Alice doesn't transmit to Bob her static key.

(we note, however, that the logic used to derive the shared key material will slightly differ among these handshakes).

In other words, a working implementation for a K1K1 handshake can be easily extended to an implementation for XK1, which in turn can be further extended to an implementation for the XX and XXpsk0 handshakes. In this way, each new added handshake implementation can be tested backwards with minor modifications.

Trade-offs

Different trade-offs exist when adopting the suggested handshakes:

• Encrypted messages satisfy all the required security guarantees only after the first 2 handshake steps are complete, i.e. after 1 round trip time communication or 1-RTT.
  However, in XK1 and K1K1, Alice can immediately encrypt messages (0-RTT) under Bob's static key exceptionally using ECIES encryption, but such messages will not be protected by perfect forward secrecy. After-handshake messages must be encrypted instead according to Noise Protocol processing rules specifications.
• Parties not necessarily need to be online at the same time to execute an handshake, but they then should rely on 11/WAKU2-RELAY and 13/WAKU2-STORE to complete it.
• If a symmetric encryption key is compromised, all messages encrypted under that key (or under a publicly computable key derived from it), can be decrypted. To reduce the number of plaintext leaked, parties should execute on each round trip message exchange an ephemeral-ephemeral Diffie-Hellman to update their encryption/decryption keys.
• Users are required to locally store a cryptographic state (i.e., different symmetric and asymmetric keys) for each party with whom they have executed and handshake. If any of such state is lost or corrupted, it cannot be recovered and messages cannot be properly encrypted/decrypted.

Context

Specifications:

• The Noise Protocol Framework
• 26/WAKU2-PAYLOAD
• 11/WAKU2-RELAY
• 13/WAKU2-STORE
• 5/SECURE-TRANSPORT
• noise-libp2p

Implementations:

• nim-libp2p noise implementation

Tools:

• Noise Explorer: formal verification of fundamental and custom Noise protocols:
  • The K1K1 handshake.
  • The XK1 handshake;
  • The XX handshake.

Acceptance Criteria

• Draft RFC proposal to update/replace 26/WAKU2-PAYLOAD.
• Evaluate the potential unknowns, issues or blockers for the integration of Noise handshakes into Waku2.

@oskarth @staheri14 @jm-clius @D4nte @cammellos