Awala Channel Session Protocol

  • Id: RS-003.
  • Status: Working draft.
  • Type: Implementation.
  • Issue tracking label: spec-channel-session.

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. CMS EnvelopedData Representation
  8. Public Key Representation
  9. Limitations
  10. Relevant Specifications

Introduction

Awala 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, Awala Core does not offer perfect forward secrecy.

This protocol extends Awala 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 public keys for any node in Awala, but that is not necessary because peers always have each other’s public keys. For example, a client-side application will be distributed with the public key of the server-side endpoint, and similarly, private gateways could be distributed with the public key of their Internet gateway (or provided by a trusted courier 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.
  • This protocol is not limited to the X25519 and X448 curves, or the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) from RFC 5869. To lower the barrier to adoption, algorithms that are more widely available are also supported.

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 Awala 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 specify the following parameters:

  • Key exchange algorithm: Any key exchange algorithm allowed by RS-018.
  • Key-derivation function (KDF): Any function 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. This is only needed when using HKDF as the KDF.

For example, a Awala service may configure its endpoints to use ECDH with P-256 as the key exchange algorithm, X9.63 as the KDF, 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 an ephemeral-static Diffie-Hellman exchange with keys K1 and K2.
  • KDF(KM) represents 32 bytes of output from the KDF. When using X9.63, the input MUST be as specified in Section 4.3 of RFC 6318. When using HKDF, the inputs MUST be:
    • 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.
    • Salt: A zero-filled byte sequence with length equal to the hash output length.
    • 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.

Once the session has been established, both parties MUST reject incoming messages outside the session (i.e., any message not using the Channel Session Protocol or the expected DH keys). However, they MAY agree to start a new session.

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.

The initial DH key Kb,1 MUST be ephemeral (i.e., only usable by Alice) unless Bob is a server, in which case the key MAY be static (i.e., usable by any node) as it may not be possible to distribute ephemeral keys in advance. Regardless of their type, keys MUST NOT be valid for more than 60 days and they SHOULD NOT be valid for more than 30 days.

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 unique id Ka,1id randomly or as the cryptographic digest of Ka,1public.
  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.

Upon successful completion of this process, Bob MAY send messages to Alice using the algorithm to send subsequent message.

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:
    • Reuse 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. This reuse is an optional performance optimization, as X would have fewer keys to manage.
    • Otherwise:
      1. Generate a new ephemeral key Kx,m.
      2. Generate the unique id Kx,mid randomly or as the cryptographic digest of Kx,mpublic.
      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.

CMS EnvelopedData Representation

When using a CMS EnvelopedData value to encapsulate ciphertext encrypted with these DH keys, implementations MUST comply with the following RFCs depending on the specific DH algorithm used:

  • When using ECDH, the EnvelopedData value MUST be serialized as described in RFC 5753. Additionally, the implementation MUST comply with RFC 8418 when using X25519 or X448.
  • When using (finite field) DH, the implementation MUST comply with Section 4.1.1 of RFC 3370.

Amongst other things, the RFCs above require the RecipientInfo to use the KeyAgreeRecipientInfo choice. They also require Ka,1public or Kx,mpublic to be stored as the originator’s public key, and Kb,1id or Ky,nid to be stored as the recipient’s ephemeral key identifier.

Implementations MUST store the recipient’s ephemeral key identifier in the subjectKeyIdentifier choice of the KeyAgreeRecipientIdentifier. They MUST also store the originator’s ephemeral key identifier (Ka,1id or Kx,mid) under the unprotectedAttrs field of the EnvelopedData value as the integer representation of the corresponding serial number and use the following OID:

OriginatorEphemeralKeyId OBJECT IDENTIFIER ::= { awala channel-session(1) 0 }

Public Key Representation

When distributing public keys along with their respective ids, implementations MAY use the following ASN.1 structure:

SessionKey ::= SEQUENCE {
  id  OCTET STRING,
  key SubjectPublicKeyInfo -- Per RFC 5280
}

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, an Awala 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 Awala.