Relaynet Channel Session Protocol

  • Id: RS-003.
  • Status: Working draft.
  • Type: Implementation.

Abstract

This document describes an asynchronous key agreement and management protocol to establish and maintain secure sessions in bidirectional messaging channels. Its purpose is to add perfect forward secrecy, future secrecy and replay attack mitigation to endpoint and gateway channels.

Table of contents

  1. Introduction
  2. Roles
  3. Parameters
  4. Notation
  5. Key Agreement Protocol
    1. Generating and Distributing Initial DH Keys
    2. Sending Initial Message(s)
    3. Receiving Initial Message(s)
  6. Key Management Protocol
    1. Sending Subsequent Messages
    2. Receiving Subsequent Messages
  7. X.509 Certificate for Initial DH Key
  8. CMS Enveloped-Data Representation
  9. Limitations
  10. Relevant Specifications

Introduction

Relaynet Core defines messaging channels that use end-to-end encryption to guarantee confidentiality. But since messages are always encrypted using the same keys, compromising the keys will compromise past and future messages – In other words, Relaynet Core does not offer perfect forward secrecy.

This protocol extends Relaynet to add perfect forward secrecy, future secrecy and replay attack mitigation. It is heavily based on the Extended Triple Diffie-Hellman protocol and the double ratchet algorithm from the Signal project, with some notable differences:

  • There is no central server that can provide certificates or public keys for any node in Relaynet, but that is not necessary because peers always have each other’s certificates. For example, a client-side application will be distributed with the certificate of the server-side endpoint, and similarly, user gateways could be distributed with the certificate of their relaying gateway (or provided by a trusted relayer in a cargo relay connection).
  • This protocol must be tolerant to disruptions: Messages are most likely to arrive late, in batches and out of order, or they may be lost.
  • The Diffie-Hellman (DH) exchange can also be done with the traditional finite field approach to lower the barrier to adoption. In other words, this protocol still supports Elliptic Curve Diffie-Hellman (ECDH), but it does not require it.

The end result is a key agreement and management protocol where ephemeral keys are rotated as the recipient acknowledges the receipt of the previous ephemeral key.

Roles

This document refers to the two nodes in the session as Alice and Bob, and assumes that Alice wants to initiate a session with Bob.

Since this protocol applies to sessions on Relaynet channels, Alice and Bob MUST be either endpoints or gateways, but not a combination of the two – That is, this protocol does not apply to bindings.

Parameters

A channel implementation MUST define the following parameters:

  • Key exchange algorithm: Any key exchange algorithm allowed by RS-018.
  • Cipher: Any cipher allowed by RS-018.
  • Cryptographic hashing function: Any function allowed by RS-018.
  • Channel id: An ASCII string identifying the channel.

For example, a Relaynet service may configure its endpoints to use DH-2048 as the key exchange algorithm, AES-128 (KW and GCM) as the cipher, SHA-256 as the hashing function and My Service as the channel id.

Notation

  • X || Y denotes the concatenation of byte sequences X and Y.
  • Ka,n denotes the n-th DH key pair generated by Alice. Ka,nprivate and Ka,npublic denote its private and public keys, respectively, and Ka,nid denotes the identifier of the key pair.
  • Kb,n denotes the n-th DH key pair generated by Bob. Kb,nprivate and Kb,npublic denote its private and public keys, respectively, and Kb,nid denotes the identifier of the key pair.
  • DH(K1public, K2private) represents the shared key resulting from doing a Diffie-Hellman exchange with keys K1 and K2.
  • KDF(KM) represents 32 bytes of output from the HKDF algorithm with inputs:
    • HKDF input key material: F || KM, where KM is an input byte sequence containing secret key material, and F is a byte sequence filled with 0xFF bytes whose length matches that of KM.
    • HKDF salt: A zero-filled byte sequence with length equal to the hash output length.
    • HKDF info: The channel id.

Key Agreement Protocol

This protocol describes the initial interaction between Alice and Bob, which is used to establish a secure channel between the two.

Generating and Distributing Initial DH Keys

Alice MUST have Bob’s initial DH key Kb,1public and its id Kb,1id before running this protocol; see X.509 certificate.

The initial DH key Kb,1 SHOULD be ephemeral and used by a single node. When this is not possible, the initial DH key MAY be static and used by multiple nodes. Static keys MUST be valid for no more than 60 days, and they SHOULD NOT be valid for more than 30 days.

For example, static keys are likely to be necessary in a centralized service where client applications have to be distributed with the same initial DH key, whilst ephemeral keys could be used in a decentralized service where Bob is able to generate an initial key just for Alice.

The initial key MUST be valid in the chosen key exchange algorithm. For example, the initial DH key must be 2048-bit if the session uses DH with a 2048-bit group; similarly, the initial DH key must be X25519 if the session uses ECDH with X25519.

Sending Initial Message(s)

Alice MUST follow the following process when sending an initial message to Bob using his initial DH key (Kb,1public):

  1. Generate the ephemeral asymmetric key Ka,1.
  2. Generate the id Ka,1id randomly.
  3. Store Ka,1private and Ka,1id so that they can be used to decrypt future messages from Bob.
  4. Calculate the shared key SK1 = KDF(KM), where KM = DH(Kb,1public, Ka,1private).
  5. Encrypt the plaintext with SK1.
  6. Attach Ka,1public, Ka,1id and Kb,1id to the resulting ciphertext as metadata.

Alice MUST continue to use SK1 to encrypt future messages until the first ephemeral key from Bob (Kb,2public) is received. Once that happens, any subsequent message from Alice to Bob MUST use the algorithm to send subsequent message.

Receiving Initial Message(s)

Bob MUST follow the following process when receiving an initial message from Alice:

  1. Check that the required input is present, or else abort:
    • The ciphertext.
    • Ka,1public.
    • Ka,1id.
    • Kb,1id.
  2. Retrieve Kb,1 by its id Kb,1id, or abort if it cannot be found.
  3. Calculate the shared key SK1 = KDF(DH(Ka,1public, Kb,1private)).
  4. Decrypt the ciphertext with SK1, or abort if it fails to be decrypted.
  5. Store Ka,1public along with Ka,1id in order to send messages to Alice in the future.

Key Management Protocol

Alice and Bob MUST follow the following algorithm to exchange subsequent messages. Note that X and Y correspond to the sender and the recipient, respectively (Alice and Bob, or Bob and Alice).

Sending Subsequent Messages

The sender X MUST follow the following process when sending a subsequent message to Y:

  1. Compute Kx,m:
    • Retrieve the last ephemeral key Kx,m-1 if no incoming message from Y has used it; this could mean that Y has not received Kx,m-1 yet.
    • If an incoming message from Y has already used Kx,m-1, then:
      1. Generate a new ephemeral key Kx,m.
      2. Generate the id Kx,mid randomly.
      3. Store Kx,mprivate and Kx,mid so that they can be used to decrypt future messages from Y.
  2. Retrieve Y’s last ephemeral key Ky,npublic along with its id Ky,nid.
  3. Calculate the shared key SKp = KDF(KM), where KM = DH(Ky,npublic, Kx,mprivate).
  4. Encrypt the plaintext with SKp.
  5. Attach Kx,mpublic, Kx,mid and Ky,nid to the resulting ciphertext as metadata.

Receiving Subsequent Messages

The recipient Y MUST follow the following process when receiving a subsequent message from X:

  1. Check that the required input is present, or else abort:
    • The ciphertext.
    • Kx,mpublic.
    • Kx,mid.
    • Ky,nid.
  2. Retrieve Ky,n by its id Ky,nid, or abort if it cannot be found.
  3. Calculate the shared key SKp = KDF(DH(Kx,mpublic, Ky,nprivate)).
  4. Decrypt the ciphertext with SKp, or abort if it fails to be decrypted.
  5. Store Kx,mpublic along with Kx,mid in order to send messages to X in the future, unless a different key was already used in a newer message; keep in mind that messages may arrive out of order.
  6. If Ky,n was the last key generated by Y, then delete any rotated key Ky,n-1 in order to achieve forward secrecy and future secrecy. This deletion MAY be deferred until the next incoming relay so that any in-transit messages using the rotated key can be decrypted.

X.509 Certificate for Initial DH Key

The recipient of the initial message MUST distribute its initial DH key Kb,1public as an X.509 certificate where:

  • serialNumber is set to Kb,1id.
  • subjectPublicKeyInfo:
    • algorithm is set to a valid key exchange algorithm per RS-018. If the algorithm is DH (OID 1.2.840.113549.1.3.1), then algorithmParameters MUST be set to PKIKeyAgreementDHParams as defined below:
      PKIKeyAgreementDHParams ::= SEQUENCE {
        modpGroup  PKIKeyAgreementDHGroup
      }
           
      PKIKeyAgreementDHGroup ::= INTEGER {
        modp2048 (14),
        modp3072 (15),
        modp4096 (16),
        modp6144 (17),
        modp8192 (18)
      }
      
    • subjectPublicKey is set to Kb,1public.

Note that the expiry date of the certificate MUST reflect that initial DH keys cannot last more than 60 days.

CMS Enveloped-Data Representation

When using a CMS enveloped-data value to encapsulate ciphertext encrypted with these DH keys, its RecipientInfo MUST use the KeyAgreeRecipientInfo choice with the following attributes:

  • originator: A subjectKeyIdentifier set to Ka,1id or Kx,mid.
  • ukm: Ka,1public or Kx,mpublic.
  • keyEncryptionAlgorithm: The chosen cipher in a mode that is suitable for encapsulating cryptographic key material per RS-018 (e.g., AES-128-KW).
  • recipientEncryptedKeys: A single-item sequence where KeyAgreeRecipientIdentifier will depending on the type of message:
    • Initial messages will use the issuerAndSerialNumber choice to identify the recipient’s initial key (Kb,1). These values MUST match those of the X.509 certificate.
    • Subsequent messages will use the rKeyId choice to identify the recipient’s ephemeral key (Ky,n) as previously specified by the recipient in the originator attribute.

Note that per RS-018, the ciphertext MUST be generated with the chosen cipher in a mode that is suitable for encrypting payloads (e.g., AES-128-GCM).

The constraints above apply to the payload of RAMF messages, since they use CMS Enveloped-Data.

Limitations

This protocol will not work with unidirectional communication as might be the case between two endpoints (if one of the endpoints is private and does not issue Parcel Delivery Authorizations to its peer). Consequently, a Relaynet service with one-way communication would not get perfect forward secrecy or future secrecy, unless it enables two-way communication as a workaround until there is an equivalent protocol for unidirectional communication.

Relevant Specifications

RS-018 (Cryptographic Algorithms) defines the requirements and recommendations for the use of cryptographic algorithms in Relaynet.