Seal Attestation

Seal attestation is the cryptographic core of CPHAR. A verifier sends a random challenge; the intact seal signs the challenge with a non-exportable key; the verifier checks the signature against the registered public key and the seal's status. The signature is evidence that the seal is alive at signing time.

Challenge-response flow

sequenceDiagram
  participant V as Verifier
  participant R as Registry
  participant S as Cryptographic Seal

  V->>R: Look up active seal_id
  R->>V: Public key + revocation status
  V->>V: Generate fresh nonce
  V->>S: SealChallenge { seal_id, nonce, timestamp, domain }
  S->>S: Tamper check
  S->>V: SealAttestation { signature, firmware_measurement }
  V->>V: Verify signature, status, freshness

Message format

SealChallenge v0.1

A verifier-generated challenge sent to a seal device.

{
  "type": "cphar.seal.challenge",
  "version": "0.1",
  "seal_id": "seal_01H...",
  "nonce": "base64url-random",
  "timestamp": "2026-05-16T12:00:00Z",
  "domain": "cphar.org"
}

Fields

Field	Type	Required	Description
`type`	string	yes	Message type identifier
`version`	string	yes	Protocol version
`seal_id`	string	yes	Registered seal identifier
`nonce`	string	yes	Verifier-generated random challenge
`timestamp`	string	yes	Challenge creation time (RFC 3339)
`domain`	string	yes	Domain separation context

SealAttestation v0.1

The signed response a seal returns to the verifier.

{
  "type": "cphar.seal.attestation",
  "version": "0.1",
  "seal_id": "seal_01H...",
  "challenge_hash": "sha256:...",
  "signature": "base64url-signature",
  "firmware_measurement": "sha256:..."
}

What this proves

What this does not prove

That the material inside the sealed unit is unchanged. The seal proves only that it is still active.
That the seal was physically attached to the correct lot. That binding lives in the registry and depends on inspection and custody controls.
That the seal cannot be cloned, side-channelled, or extracted given sufficient adversary capability. See threat model.

Assumptions

Freshness window

A SealAttestation is meaningful only within a freshness window relative to its timestamp and challenge_hash. Recommended defaults:

Maximum age of timestamp accepted by the verifier: 60 seconds.
Maximum delay between issuing a SealChallenge and receiving the response: 30 seconds.

These are defaults, not requirements. Tighter windows reduce replay surface; looser windows accommodate satellite or store-and-forward links. Operators should document the window they enforce.