CPHAR's value depends entirely on the threat model it is read against. This section defines the adversary, the assumed deployment, the attacks CPHAR helps prevent or detect, and the residual risks operators inherit.
Adversary model
CPHAR considers an adversary who may:
- Physically access sealed containers between inspection cycles.
- Compromise some, but not all, operator staff.
- Operate a custom hardware lab to attempt seal extraction or cloning.
- Observe network traffic between verifier and seal.
- Tamper with registry mirrors served by untrusted infrastructure.
CPHAR does not assume the adversary can:
- Forge the seal vendor's manufacturer attestation chain.
- Compromise the inspector and the auditor and the operator simultaneously without leaving evidence.
- Break the cryptographic primitives the seal uses.
These are simplifying assumptions, not facts. Each deployment must verify they hold.
Primary attack surfaces
flowchart LR
A[Inspector] --> B[Inspection record]
B --> C[Sealing]
C --> D[Seal device]
D -.signs.- E[Verifier]
D --> F[Registry binding]
F --> G[Reserve claim]
G --> E
style A fill:#fdf1dc,stroke:#b76e00,color:#111827
style D fill:#e8edff,stroke:#2457ff,color:#111827
style F fill:#e3f4ec,stroke:#1f8a5b,color:#111827
The three high-impact surfaces are:
- Inspection corruption — out of CPHAR's scope cryptographically, but it is the load-bearing assumption everything else rests on.
- Seal hardware — extraction, cloning, side-channels, supply-chain.
- Registry integrity — wrong bindings, suppressed revocations, snapshot equivocation.
Attacks
| Threat | Impact | Mitigation | Residual risk | Detection |
|---|---|---|---|---|
| Inspector colludes with operator | High | Independent auditor sign-off on inspection; rotate inspectors; sample re-inspection | Collusion involving auditor too | Statistical re-inspection, cross-referenced records |
| Seal removed and re-attached to substitute container | High | Tamper-evident attachment + continuous attestation cadence + custody chain | Brief substitution windows during transit | High-cadence challenges, physical attachment audit |
| Seal cloned via key extraction | High | Use seals with certified tamper response; record firmware measurement at registration | Future cryptanalytic or hardware advances | Compare attested firmware measurement to registered baseline |
| Registry binding pointed at wrong lot | Medium | Append-only log; require independent co-signature on bindings | Quiet operator-side errors | Auditor inclusion proofs and binding-replay verification |
| Snapshot equivocation (two distinct snapshots presented to different verifiers) | Medium | Publish snapshot roots to a transparency log; verifiers cross-check | Local fork accepted before transparency catches up | Inclusion proofs against the transparency log |
Replay of stale SealAttestation | Medium | Strict freshness window; nonce uniqueness; domain separation | Within-window replay possible | Verifier-side nonce tracking |
| Disclosure incompleteness (off-book lots) | High | Regulatory disclosure obligations; independent inventory audit | Off-book reserves CPHAR cannot see | Cross-source inventory comparison |
Residual risks
Even with all listed mitigations applied, CPHAR-based deployments retain:
- Trust in the inspection process at sealing time.
- Trust in the seal vendor's manufacturing and tamper response.
- Trust in registry operators' commitment to append-only behavior.
- Time-bounded gaps between attestation cycles.
CPHAR shrinks the evidence gap between inspections; it does not eliminate it.
Reading the threat-model pages
When this section is expanded with per-attack pages, each will follow the structure:
- Threat
- Impact
- Mitigation
- Residual risk
- Detection method
See What CPHAR Does Not Prove for the matching non-goals.