feat(ca2a): mutual attestation design, and the challenge primitive

[imran-siddique]

Design only, no code. cA2A is the one asset with no funded competitor, so it is worth getting the protocol change right rather than fast.

What is actually one-directional

Not the primitives. Either peer can bind a channel key into a report and either can appraise one — that is why attestation.md says the design composes into mutual attestation, and why claim C6 drives both directions.

The reference transport is. The callee verifies the caller's delegation chain, which is authorization: it proves the caller holds a credential whose scope covers the request. It says nothing about what the caller is running. A callee cannot tell an enclave from a laptop.

The change

A callee-issued challenge, and a caller offer bound to it. Three properties fall out, each a requirement rather than a consequence:

• The challenge must come from the callee. A caller that picks its own nonce proves it can produce a report, not that it produced one for this exchange — the same replay the caller's nonce already prevents in the other direction.
• The callee must appraise before it acts, not before it responds. The payload is sealed to the callee's key and readable the moment it arrives, so appraising afterwards means an unattested caller has already had its work done. This ordering is the whole value of the change and needs a test that fails if the calls are swapped.
• The caller's key must be used, or it is ceremony. Sealing the response to it makes the callee's answer readable only by the enclave it appraised. An attested key that is appraised and discarded adds a round trip and no property.

The decision I did not make

A challenge is worth nothing unless it is single-use and expiring, and the server keeps no state today.

	Gives	Costs
Challenge store	exactly-once within one process	server becomes stateful; a challenge issued by one instance is unknown to the next
Stateless HMAC	works across instances, no storage	single-use is unachievable; replay is bounded by a window, not eliminated

What it still would not give

Not simultaneous — there is an instant where the caller has committed a sealed payload and the callee has not yet verified it. Not trustworthiness — it establishes what each side is running, and the delegation chain remains what says it is allowed. And it does not make the recorded cross-operator hardware run mutual; that run had the caller appraise a real TDX quote and the callee appraise nothing. This makes a mutual run possible.

🤖 Generated with Claude Code

[imran-siddique]

Updated: the design decisions are recorded and the challenge primitive is in. Transport wiring follows in a second PR so the security-critical piece gets reviewed on its own.

Decisions taken, all three now in the document:

1. Stateless HMAC challenge. Works across instances, no storage, and the guarantee is at-most-once-per-window rather than exactly-once. That weaker property is written down rather than implied — a deployment needing exactly-once wants the challenge store this was chosen over.
2. Record the outcome, requirement configurable. A callee does not demand attestation by default and can be told to.
3. Seal the response to the caller's attested key, so that key is load-bearing rather than ceremonial.

Two details in challenge.py that are decisions, not style

The MAC is verified before the expiry is read. Pulling a timestamp out of an unauthenticated string and acting on it means trusting an attacker's arithmetic, and answering expired to a forgery tells the sender their forgery was well-formed. A test pins that a forgery reports as forged.

The secret is per-process and never persisted. Restarting the callee invalidates outstanding challenges, which is correct rather than incidental: a restarted enclave is a different enclave, and a challenge it never issued should not verify.

16 tests, including that extending a captured challenge by editing its timestamp is caught by the MAC.