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:
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:
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:
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:
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
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:
Hardware (TEE) guarantees the computation environment is genuine and isolated
Mathematics (ZK proofs) guarantees the computations are correct
Cryptography (commitments & Merkle trees) guarantees data integrity and privacy
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.
Last updated