# Security Model
This section provides a complete picture of the system's security architecture — what's protected, what's public, how the layers work together, and what the limitations are.
### **The Security Philosophy**
This system is built on a simple principle: **no single point of failure.**
Every critical guarantee is backed by at least two independent mechanisms. Hardware attestation and mathematical proofs. Cryptographic commitments and Merkle trees. Timeseries chaining and certificate verification.
An attacker would need to break multiple, unrelated systems simultaneously. Compromise the hardware? The math still holds. Forge the math? The hardware attestation still catches it. Tamper with the data? The Merkle root changes. Modify historical proofs? The chain breaks.
This is called **defense in depth** — the same principle used in banking vaults, nuclear facilities, and aviation safety. No single barrier is assumed to be unbreakable. Security comes from the combination.
### **What Stays Private**
These values never leave the secure enclave and are never included in proof payloads:
| Private Data | Why It Must Stay Private |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Master secret** | The key used to derive all salts. If exposed, every commitment could be opened, revealing all historical values. |
| **Individual values** | Per-custodian reserve amounts, per-position liability amounts. This is sensitive business data that reveals relationships and positions. |
| **Derived salts** | The unique secrets mixed into each commitment. Knowing a salt and a commitment lets you recover the value. |
| **Raw input data** | The unprocessed financial data before it enters the cryptographic pipeline. |
These values exist only in the enclave's memory during computation. When the enclave finishes processing, they're gone. The enclave has no persistent storage. If it restarts, its memory is wiped clean.
### **What's Public**
These values are included in every proof payload and are safe to publish:
| Public Data | Why It's Safe |
| ---------------------------- | ------------------------------------------------------------------------------- |
| **Commitments** | One-way fingerprints can't be reversed to find the value without the salt |
| **Merkle roots** | A single hash representing all data reveals nothing about individual values |
| **Total reserves** | The aggregate amount across all custodians (individual breakdown hidden) |
| **Total liabilities** | The aggregate amount across all positions (individual breakdown hidden) |
| **ZK proofs** | Mathematical proofs that verify correctness reveal nothing about private inputs |
| **Attestation document** | The hardware's signed statement needed for verification |
| **Code measurements** | Fingerprints of the code that ran public knowledge |
| **Verification keys** | Needed by anyone who wants to verify the proofs |
| **Root CA certificate** | The hardware provider's public trust anchor that’s already publicly available |
| **Collateralization status** | Whether reserves cover liabilities, the key fact users care about |
The design ensures that everything a verifier needs is public, while everything an attacker would want stays private.
### **The Four Security Layers**
#### **Layer 1: Hardware Isolation (TEE)**
The TEE enclave is a hardware-isolated environment. During computation:
* The server operator cannot read the enclave's memory
* The host operating system cannot access the enclave
* Other processes on the same machine are completely separated
* Even the cloud provider's own infrastructure team cannot peek inside
The enclave produces a hardware-signed attestation that traces back to the provider's root certificate. This proves genuine hardware produced the result.
**What it doesn't protect against:** A theoretical compromise of the hardware design itself. This is why Layer 2 exists.
#### **Layer 2: Zero-Knowledge Proofs**
ZK proofs provide mathematical certainty that:
* The Merkle root was correctly computed from the commitments
* The individual values sum to the published totals
This layer is completely independent of hardware. The proofs are based on mathematics, not trust in any manufacturer or operator. Even if the TEE were somehow compromised, the math still holds.
**What it doesn't protect against:** A compromised trusted setup ceremony (the one-time key generation). This is why Layer 1 exists — it provides an independent guarantee.
#### **Layer 3: Cryptographic Commitments & Merkle Trees**
Commitments hide individual values using strong, well-studied hash functions. Merkle trees organize commitments into a single root that changes completely if any value is modified.
These are standard cryptographic primitives used across the industry — in blockchains, in certificate transparency, in secure messaging. Their security properties are well-understood and battle-tested.
**What it doesn't protect against:** If the master secret is exposed, all salts can be derived and commitments opened. This is why the master secret lives only inside the enclave.
#### **Layer 4: Timeseries Chaining**
Each proof chains to the previous one. Modifying, deleting, or reordering any proof in the history breaks the chain from that point forward.
This is the same principle that makes blockchains tamper-evident. The difference is that here, individual proofs are also backed by hardware attestation and ZK proofs.
**What it doesn't protect against:** A completely fresh start (someone could start a new chain). This is detectable because the first proof in a chain explicitly has no predecessor — it's visible in the payload.
### **How the Layers Overlap**
The real strength of this system isn't any single layer — it's how they overlap:
Each layer covers gaps that others leave. Together, they create comprehensive coverage.
### **Threat Analysis**
#### **Threats the system handles:**
| Threat | How It's Handled |
| ------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **Server is hacked** | TEE isolation — attacker can't read enclave memory or modify computation |
| **Operator is malicious** | TEE + ZK — operator never touches the computation; proofs verify independently |
| **Data is tampered with after computation** | Merkle root + data binding — any change invalidates the attestation |
| **Historical proofs are modified** | Timeseries chaining — modification breaks the chain |
| **Values are guessed from commitments** | Salted commitments — guessing requires the salt, which never leaves the enclave |
| **Totals are fabricated** | ZK sum proofs — mathematical proof that totals are correct |
| **Wrong code is deployed** | Code measurements — fingerprints are verified against published values |
| **Proofs are fabricated from scratch** | Certificate chain — must trace to the provider's Root CA, which requires genuine hardware |
#### **Threats the system does NOT handle:**
| Limitation | Explanation | Mitigation |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Bad input data** | If a custodian reports false reserves, the system faithfully attests the wrong number. The system proves *computational integrity*, not *data truthfulness*. | Use multiple data sources and cross-reference. The system is one layer in a broader trust framework. |
| **Hardware vulnerability** | A theoretical, undiscovered vulnerability in TEE hardware could compromise isolation guarantees. | ZK proofs provide an independent mathematical guarantee. Both would need to fail simultaneously. |
| **Trusted setup compromise** | If the ZK trusted setup ceremony was dishonest, false proofs could be generated. | TEE attestation provides an independent hardware guarantee. Both would need to fail simultaneously. |
| **Master secret exposure** | If the master secret leaks, all historical commitments could be opened (values revealed). | The secret lives only inside the enclave. There's no API to extract it, and the enclave has no persistent storage or network access. Key rotation allows recovery. |
### **Financial Data Precision**
Financial data requires exact arithmetic. A rounding error of $0.01 across millions of transactions can accumulate into meaningful discrepancies. The system addresses this through:
* **Integer arithmetic** — all USD values are converted to integer form (multiplied by 1,000,000) before any computation. There are no floating-point numbers in the critical path.
* **Arbitrary precision** — the system uses a specialized decimal arithmetic library that handles numbers of any size without rounding errors.
* **Consistent formatting** — output values are always presented with 2 decimal places for clarity, but computed with 6 decimal places of precision internally.
This means $1.00 is always exactly $1.00 — never $0.999999 or $1.000001.
### **Key Management**
#### **Master Secret**
The master secret is the most sensitive value in the system. It's used to derive all salts, which protect all committed values. The system protects it through:
* **Enclave-only access** — the secret exists only inside the TEE during computation
* **No persistent storage** — the enclave has no disk; if it restarts, the secret must be re-provided
* **No network access** — the enclave cannot send the secret anywhere
* **HMAC derivation** — the secret is never used directly in commitments; it generates salts through a one-way function
#### **Key Versioning**
Salts include a version number in their derivation. This means:
* The master secret can be rotated if needed
* Old proofs remain valid with their version's salts
* New proofs use the updated version
* There's a clean transition path without invalidating history
#### **Enclave Certificates**
Each attestation includes an enclave certificate with an expiration time. This is a short-lived certificate generated by the hardware for that specific attestation. Verifiers should check that the certificate was valid at the time of attestation.
### **Comparison to Other Approaches**
| Approach | Trust Requirement | This System's Advantage |
| -------------------- | ------------------------------------ | ---------------------------------------------------------------- |
| Trusted oracle | Trust the oracle operator | No operator trust needed — hardware + math prove correctness |
| Multi-sig committee | Trust the majority of signers | No human signers — verification is automated and deterministic |
| Periodic audits | Trust the auditor; snapshots in time | Continuous, real-time verification; no waiting for audit cycles |
| On-chain only | Limited to on-chain data | Works with off-chain data (real-world assets, bank reserves) |
| Software attestation | Trust the software environment | Hardware attestation — the physical chip signs, not the software |
### **Summary**
The security model is built on overlapping guarantees:
1. **Hardware** (TEE) guarantees the computation environment is genuine and isolated
2. **Mathematics** (ZK proofs) guarantees the computations are correct
3. **Cryptography** (commitments & Merkle trees) guarantees data integrity and privacy
4. **Hash chaining** (timeseries) guarantees historical continuity
No single layer needs to be perfect. The system is secure as long as an attacker cannot break all layers simultaneously — which would require compromising both hardware and mathematics, an extraordinarily difficult proposition.
