TSP SDK Technical specification

This document tries to focus on aspects that pertain to the SDK; i.e. how the TSP Specification impacts the design choices for the Rust SDK. Since the TSP Specification is still in the process of being finalized, however, there may be some duplication.

Protocol overview

At its core, TSP consists of "simply sending a message" between parties; except that this message is (often) encrypted and (always) signed. In this way the parties have confidence that any messages received are always by the same entity, and trust can be built.

TSP uses Verified Identifiers to designate the sender and receiver of messages. A mechanism out of scope for this project (but that we will have to write some simple examples of) will allow applications to retrieve addresses and public keys for a VID.

A TSP message therefore contains at least the following information:

• Who is the originating sender?
• Who is the intended receiver?
• A message payload (encrypted or unencrypted), which can either be 'simple content' or a Control Message.
• A signature

So, a confidential message will conceptually look like this:

And a non-confidential message, when there is no receiver VID, will look like this:

Modes of operation

1. Direct mode: TSP messages can be exchanged directly between two parties via publicly known VID's ("Well-Known VID's"); that gives confidentiality and authenticity but not much privacy.

2. Nested mode: TSP messages can be exchanged as the 'payload' of another TSP message using not-publicly known VID's. Such a nested connection is established via TSP Control Messages. This gives a little bit more privacy.

3. Routed mode: TSP messages can be routed through intermediaries to further hide the fact that two parties are communicating. This is done by parties first establishing "nested" communication lines between every involved party and then sending a message that spans over those nested communications lines.

High-level architecture

The SDK will consist of functions that can be called by an application to completely perform all TSP-specific operations, such as:

• Generating/retrieving/storing VID's
• Control operations on a private key associated with a VID
• Obtaining transport layer address information and other metadata from a verified VID.
• Creation and processing of TSP messages

This allows applications the flexibility to incorporate TSP in an existing setup: i.e., an application can create a TSP message but chose by itself how and when to send it.

For other use cases, the SDK will also contain some convenience functions such as "generate-and-send" for some common transport layers (such as HTTPS or QUIC) for applications that don't need this flexibility.

SDK General Requirements

Cryptography

Interoperability

TSP Specification Conformance

Verified Identifiers

Demo

Security properties

The goal of TSP is to provide security guarantees for

• Authenticity
• Confidentiality
• Privacy

of communication between two parties.

Privacy in communication can be optionally enabled by using the "Routed" mode of the TSP protocol.

To get a high degree of confidence, a modern and well-analyzed cryptographic standard for signcryption is chosen. In signcryption asymmetric cryptography is used to encrypt and sign the contents of a message.

Hybrid Public Key Encryption (HPKE, RFC 9180) is a robust method of signcryption using modern cryptographic primitives ¹. It combined a "Key encapsulation Mechanism", with a "Key Derivation Function" and primitive for "Authenticated encryption with associated data" to combine asymmetric with symmetric cryptography, to obtain certain security and performance characteristics. HPKE offers the highest notion of confidentiality, namely IN-CCA2.

HPKE offers the possibility to create authenticated plaintext and authenticated ciphertext in one signcryption operation. In TSP a header (containing the sender and receiver VID's) must be authenticated but not encrypted.

Although HPKE offers authentication and confidentiality between two parties, there are two characteristics that are not desirable for TSP:

• HPKE is vulnerable to key compromise impersonation (KCI). Which means that if Bob's private key is leaked to Eve, Eve can impersonate Alice toward bob.
• Although two parties communicating can verify the authenticity of messages, an outsider cannot verify that, for instance, the sender as specified in the header of the message really sends the message. Thereby a receiver can also not prove a message was sent by a particular sender to them. This is called receiver unforgeability (RUF).

The overcome to above, an additional signature is created over both the header and the (HPKE) ciphertext of a TSP message. Since both the sender and receiver's VID are present in the header of a message, one can always verify the message was created by the specified sender and that it was intended for the specified receiver. This is a method first proposed in ².

The additional "outer" signature over the message header (or envelope) plus the ciphertext makes TSP secure against KCI and RUF secure.

A modern and secure public-key signature scheme is used to construct the "outer" signature, namely Ed25519 ³, based in the same elliptic-curve cryptography as HPKE. Ed25519 satisfies properties such as EUF-CMA or SUF-CMA (existentially unforgeable under chosen message attacks, strong unforgeability).

Non goals

Hiding plaintext length

By default, TSP does not hide the length of plaintext messages. If the size of the plaintext is confidential, the application layer could take measures to hide the length by, for instance, always sending fixed size messages.

Bidirectional mode

TSP messages are unidirectional. There is no default way of "responding" to a TSP message, other than constructing a new unidirectional message.

Cryptographic primitives

The following underlying cryptographic primitives are chosen for the TSP.

Key Encapsulation Method: DHKEM(X25519, HKDF-SHA256)

Key Derivation Function: HKDF-SHA256

Authenticated Encryption with Associated Data (AEAD) Function: ChaCha20Poly1305

Signature scheme: Ed25519 SHA512

HPKE operation mode: Auth

Encoding

By default, TSP messages are encoded using CESR ⁴ with a specific extension for TSP ⁵.

The methods the seal (encrypt, sign) and open (decrypt, verify) a message also encode and decode the message using CESR in the binary domain.

Using a deterministic and predictable binary encoding helps to reliably sign and verify a TSP message.

HPKE usage

The notation below is based on RFC 9180 ⁶.

We create the message header:

Envelope = ConcatCESR(
    [VID sender, VID receiver, Additional header data]
)

We perform a HPKE Seal operation using the single-shot API in Auth mode:

Ciphertext = SealAuth(
    skS = Sender private key,
    pkR = Receiver public key,
    aad = Envelope,
    pt = Message plaintext
)

We sign the header information together with the ciphertext and encapsulated key:

Signature = Sign(
    skS = Sender private key,
    msg = Concat<CESR>(Envelope, Ciphertext),
)

We construct the final message:

Ciphertext Message = ConcatCESR(
    [Envelope, Ciphertext, Signature]
)

The receiver performs verification and decryption as follows.

Parse the CESR encoded message:

[Envelope, Ciphertext, Signature] = SplitCESR(Ciphertext Message)

[VID sender, VID receiver, Additional header data] = SplitCESR(Envelope)

Verify the outer signature:

Verify(
    pkS = Sender public key,
    msg = ConcatCESR(Envelope, Ciphertext)
)

We perform a HPKE Open operation using the single-shot API in Auth mode:

Message plaintext = OpenAuth(
    pkS = Sender public key,
    skR = Receiver private key,
    aad = Envelope,
    ct = Ciphertext
)

Streaming mode

HPKE allows sealing a stream of messages efficiently by only using symmetric cryptography for subsequent messages. We could extend TSP to allow such a streaming mode by setting up a sender and a receiver context. This context holds the key material for the current stream or "session", as described in session 5.1 of RFC 9180. When using a streaming mode in TSP, only the first message contains the full header and the outer signature.

Note that KCI is not a problem for this mode, since the first message still contains the outer signature (created using the senders’ private key). However, naively implementing a streaming mode using HPKE breaks RUF for subsequent messages. One could include a hash of the next message in each streaming message, and thereby securely links each message back to the initial, signed TSP message. In that case RUF still holds.

References

1. Richard Barnes and Karthikeyan Bhargavan and Benjamin Lipp and Christopher A. Wood, 2022, "Hybrid Public Key Encryption", https://www.rfc-editor.org/info/rfc9180 ↩

2. Jee Hea An, 2001, "Authenticated Encryption in the Public-Key Setting: Security Notions and Analyses", https://eprint.iacr.org/2001/079 ↩

3. Simon Josefsson and Ilari Liusvaara, 2017, "Edwards-Curve Digital Signature Algorithm ( EdDSA)", https://www.rfc-editor.org/info/rfc8032 ↩

4. Samuel M. Smith, 2021, "Composable Event Streaming Representation ( CESR)", https://datatracker.ietf.org/doc/draft-ssmith-cesr ↩

5. https://github.com/WebOfTrust/keripy/discussions/612#discussioncomment-7739043 ↩

6. https://www.rfc-editor.org/rfc/rfc9180.html#name-notation ↩