PROTOCOL BINDING
Why a valid signature or shared secret is not enough to authenticate an exchange.
A protocol can use strong algorithms, generate fresh ephemeral keys and still leave its participants with different ideas about what has been authenticated.
One side may believe it is proving possession of a credential to a reader. The other may believe it is authorising a request received through another channel. Both may calculate the expected cryptographic value. The failure is not necessarily in the primitive. It can be in the statement that the primitive was asked to protect.
Interactive protocols solve this by binding the important parts of the exchange into a transcript. The transcript is an ordered, precisely encoded record of the context that led to a cryptographic decision. It may contain messages directly, hashes of messages, identifiers, roles, capabilities, ephemeral public keys, challenges and information obtained during handover.
When a signature, message authentication code or key derivation depends on that transcript, the final result no longer says only, "this party knows a key." It says, more precisely, "this party used the key in this exchange, with these parameters, for this purpose."
That difference is where much of protocol security lives.
A key exchange does not name the exchange
An ephemeral Diffie-Hellman calculation allows two parties to derive a shared secret. On its own, that secret does not necessarily establish:
- which identities participated;
- which party acted in each role;
- which algorithms and parameters were selected;
- which request or application operation the session concerns;
- whether the public keys belong to this session rather than another;
- whether an intermediary altered the negotiation.
Authentication has to attach meaning to the result. A transcript provides the material to do so.
This is visible in TLS 1.3. Many of its cryptographic calculations depend on a transcript hash computed over the ordered handshake messages. Certificate verification and Finished messages therefore authenticate not just an isolated key, but the negotiation that produced the session. Changing an included message changes the transcript hash and causes the later authentication check to fail.
The lesson extends beyond TLS. Whenever several messages jointly define an operation, protecting only the last message is rarely sufficient.
What belongs in a transcript
There is no universal transcript format. Its contents follow from the attacks the protocol must prevent and the claims each participant expects to make.
A useful starting point is to ask whether the transcript binds the following elements.
The participants and their roles
The same public key can appear in several contexts. A protocol should make clear who is initiating, who is responding and which identity or trust relationship is attached to each role.
Role labels matter. Without them, a value created for one direction can sometimes be reflected into the other. Domain-separation strings such as Client, Server, Reader or Device are simple, but they turn an otherwise generic signature input into a protocol-specific statement.
Freshness
A challenge, nonce or fresh ephemeral key can distinguish a new exchange from a recorded one. Freshness must be checked, not merely transported. A verifier needs a policy for generation, uniqueness, lifetime and reuse.
A timestamp alone is often weaker than it appears. It requires clock assumptions, permits replay within the acceptance window and may be difficult to validate in disconnected environments. A verifier-generated challenge gives the verifier direct evidence that the response belongs to its current request.
Negotiated parameters
Algorithm identifiers, protocol versions, cipher suites, feature selections and transport options may determine how later bytes are interpreted. If negotiation is not authenticated, an attacker may be able to remove stronger options, select an unintended mode or create disagreement between the endpoints.
Binding the offered and selected values is stronger than signing only the final selection. It preserves evidence of what was available and what was chosen.
Ephemeral keys
An ephemeral public key should be bound to the session in which it is used. Otherwise, an exchange can establish a mathematically valid secret without proving that both parties associate that key with the same peer, role or operation.
This is one reason protocol implementations should resist APIs that return only a shared secret. The security meaning comes from the surrounding construction.
The requested operation
Authentication should be attached to a purpose. A signature created while requesting a limited set of attributes should not be reusable as approval for a different request. The transcript can bind the requested data, transaction amount, resource identifier, audience or other operation-specific information.
The goal is not to insert every application field indiscriminately. It is to identify which facts must remain inseparable from the proof.
ISO 18013-5 as a useful case
The mobile document protocol defined by ISO/IEC 18013-5 provides a concrete example of transcript binding across proximity engagement, session establishment and document authentication.
In a device retrieval flow, the interaction can begin with information transferred through QR or NFC. That handover helps the devices discover each other and agree how to continue, but the visual or radio transfer is not by itself the final authentication result.
The protocol constructs a SessionTranscript that incorporates engagement and handover information, including the ephemeral reader key used for the session. That transcript then participates in later authentication structures.
Device authentication binds the session transcript with the document type and the device namespaces returned by the mobile document. Reader authentication, when used, binds the session transcript with the requested data items. COSE signatures or authentication codes protect the resulting structures.
The effect is architectural:
- returned attributes belong to a specific session;
- the device proof cannot be detached from the document type and presented data;
- an authenticated reader request belongs to the same engagement observed by the device;
- the ephemeral key and handover context are not independent decorations.
This does not make every reader trustworthy or every request acceptable. Trust in issuer certificates, reader authorisation, holder consent, data minimisation and local policy remain separate decisions. Transcript binding ensures that those decisions refer to one coherent exchange.
A QR code is often only the beginning
QR-based protocols are especially prone to confusing transport with authentication.
A QR code can carry a complete signed object, a session invitation, a public key, a URL or an opaque reference. Scanning it establishes only that the reader obtained those pixels and decoded a byte sequence. The security meaning depends on what happens next.
If a QR code bootstraps a live exchange, its content should normally be bound into the authenticated session. Otherwise, a code copied from one display may be combined with a different network session. If the code contains a key, the protocol must define whose key it is, how it is encoded, how long it is valid and which later messages prove possession of the corresponding private key.
The useful question is not "is the QR signed?" It is "which complete interaction does the cryptographic proof describe?"
Transcript failures are agreement failures
Several attack classes can be understood as failures to bind enough context.
Replay
A previously valid response is accepted in a new session because freshness was absent, reused or not verified.
Unknown key share
Two parties derive the same key but disagree about the identity of the peer with whom the key is shared. Binding identities and roles to key confirmation prevents the shared secret from floating free of its intended relationship.
Downgrade
An intermediary removes or modifies stronger capabilities, and the participants authenticate only the weaker result. Protecting the negotiation makes the alteration detectable.
Request substitution
A valid response to one request is attached to another because the request itself was not included in the authenticated data.
Cross-protocol reuse
A signed value from one protocol is accepted by another because both use the same key and compatible encodings. Explicit context strings and protocol identifiers make the intended domain part of the signed statement.
These failures differ in mechanics, but they share a pattern: the primitive proves less than the application assumes.
Encoding is part of the transcript
Listing the correct fields is not enough. Both parties must construct the same bytes.
The protocol must define:
- ordering;
- serialization rules;
- treatment of absent and empty values;
- text and Unicode handling;
- integer representation;
- inclusion of message types and lengths;
- whether original encoded bytes or reconstructed values are used;
- how hashes of earlier messages are incorporated.
TLS 1.3 specifies the precise sequence of handshake messages included in its transcript hash and even defines special processing for HelloRetryRequest. ISO 18013-5 uses defined CBOR structures and encoded byte strings. These details are not formatting conventions. They determine the authenticated statement.
An implementation that parses a message and then recreates an apparently equivalent structure may produce a different transcript. The safest diagnostic view exposes both the decoded fields and the exact bytes included at each stage.
The transcript should follow the state machine
Protocol code often becomes fragile when transcript construction is spread across callbacks and transport handlers. A clearer design treats the exchange as a state machine.
At each transition, the implementation should know:
- which message is permitted;
- which bytes are added to the transcript;
- which values become fixed;
- which key material can now be derived;
- which authentication checks must succeed before the next state;
- which errors terminate the exchange.
This prevents messages from being processed in a valid format but at an invalid point in the protocol. It also makes retry, timeout and reconnection behaviour explicit.
The transcript is therefore not merely a buffer passed to a hash function. It is the cryptographic record of the state machine.
Test what each proof actually binds
Positive interoperability tests show that two implementations can agree. Negative tests show what their agreement depends on.
A useful test suite changes one transcript element at a time:
- swap initiator and responder roles;
- reuse a challenge;
- substitute an ephemeral public key;
- alter the offered algorithms without changing the selected one;
- replay a response under a new request;
- change handover data;
- reorder or re-encode a structured field;
- carry a proof from one protocol context into another.
Each modification should fail at a defined stage. A generic "authentication failed" result may be appropriate externally, but internal diagnostics should identify the first transcript divergence without logging private material.
Test vectors are most useful when they publish intermediate structures, encoded bytes and expected transcript hashes. Finished messages alone make it difficult to locate disagreement.
The statement worth authenticating
Applied cryptography is often described in terms of algorithms and keys. Interactive protocols add another object of equal importance: the history of the exchange.
The transcript turns that history into a cryptographic statement. It connects fresh keys to participants, roles, negotiations, requests and handover context. It gives each proof a domain and each session an identity.
A valid signature can establish that a key protected some bytes. A well-designed transcript establishes why those bytes belong together.
