Trust Model
OCC guarantees single-successor semantics within the verifier-accepted measurement and monotonicity domain of the enforcing boundary.
Assumptions
| Assumption | If it fails |
|---|---|
| Boundary isolation - TEE prevents external key access | All guarantees collapse |
| Key secrecy - Ed25519 private key never leaves boundary | Proof forgery becomes possible |
| Nonce freshness - ≥128 bits, never reused | Replay within a session |
| Honest measurement - hardware correctly measures enclave | Delegated to TEE vendor |
| Monotonic counter durability - survives restarts | Anti-rollback degrades to single session |
| Causal slot integrity - slot allocated before artifact hash known | Without pre-allocation, commit order could be forged |
| Strict verifier policy - caller pins measurements + counters | Weak policy accepts more than intended |
Threat model
In-scope threats
Out-of-scope threats
- • Signing key exfiltration - assumes boundary is secure
- • TEE firmware vulnerability - delegated to hardware vendor
- • Weak verifier policy - caller responsibility
- • Physical access to enclave host - outside threat model
Ethereum front anchors
OCC does not require a blockchain to operate, but it uses Ethereum as an external write-once timeline. The same TEE that signs user proofs also periodically commits its current counter chain into an Ethereum block. The on-chain payload contains the enclave's public key, the epoch identifier, the current counter, and the latest proof hash — nothing about any individual user or file.
Each anchor is itself an OCC proof signed by the enclave, so it participates in the same counter chain as the user proofs that came before it. When the anchor lands in a finalized Ethereum block, that block's timestamp and ordering become an external witness to the position the chain had reached. Every proof committed before the anchor is then sealed against retroactive rewrite: any attempt to produce an earlier proof under that key would have to also produce a consistent chain that contradicts a value already written to a public block.
This is the mechanism behind the phrase "everything before me already existed." An anchor seals backward, not forward. It does not prove when individual proofs were created, only that they preceded the anchor block. Combined with per-epoch keypairs, anchors give OCC a bounded breach window: between one anchor and the next, a compromise could in theory rewrite the live chain, but anything before the most recent anchor is already fixed in the public Ethereum timeline.
Anchors are public, but they reveal no user-identifying information. A verifier can fetch any anchor from Ethereum and use it to bound when a proof must have existed by, without ever contacting OCC.
Epoch isolation: blast-radius containment
OCC's strongest containment property is structural, not behavioral. Each restart of the enclave generates a new Ed25519 keypair inside the boundary, derives a new epochId from fresh hardware entropy, and resets the monotonic counter. This means every epoch is a sealed compartment, identified by a key that exists nowhere else in the world.
The consequence: a compromise can only forge proofs that carry the live epoch's public key. It cannot retroactively produce valid proofs under any prior epoch's key, because that key was destroyed when its enclave terminated and never existed outside the boundary in the first place. Past proofs remain verifiable because their signatures bind to a public key that no surviving system can sign with.
Ethereum anchors tighten this further. Each epoch's counter chain is periodically sealed into an Ethereum block by the same TEE. Once an anchor is mined, every proof committed before that anchor is fixed in a public, immutable timeline that the TEE cannot rewrite even if it were later compromised. A breach window is therefore bounded on one side by the epoch boundary and on the other side by the most recent Ethereum anchor that preceded it.
Restarting the TEE is not just operational hygiene — it is a deliberate containment action. Each restart closes one compartment and opens a fresh one, so any undetected compromise is quarantined to the bounded window of a single epoch. Verifiers can refuse to accept proofs from any epoch they have not pinned, narrowing trust to known-good compartments only.
| Containment property | What it bounds |
|---|---|
| Per-epoch keypair | A compromise of one epoch cannot sign as another epoch |
| Key destroyed on restart | No surviving artifact can produce a valid signature under a closed epoch |
| Ethereum front anchors | Pre-anchor proofs are sealed against retroactive rewrite |
| Verifier epoch pinning | Trust scope can be restricted to known-good compartments only |
Non-goals
- • Global ordering from the counter alone - every TEE instance and every new epoch resets the counter to 1, so the counter by itself only orders proofs within a single epoch. Ordering relative to the outside world is established by Ethereum anchors: each anchor lands in a finalized block, and that block's position fixes where the anchored proofs sit in the public timeline — across epochs, across TEE instances, and against any other event in the world.
- • Cross-boundary double-spend - same artifact can be submitted to separate boundaries
- • Copy prevention - OCC does not prevent raw byte copying
- • Consensus replacement - OCC constrains a single boundary, not distributed parties
- • Metadata integrity - the metadata field is advisory and unsigned