Seven composable layers.
SCSA is the cryptographic core that powers SyntheticCC, Vault, Forge and Relay. Each layer is a standalone guarantee; stacked, they make decryption a property of measured hardware and elapsed time, not of key possession.
- L1
GPU Silicon Attestation
SHA3-256ECDSA P-384NVIDIA CCKeys derive from a SHA3-256 measurement of the GPU die identity, VBIOS/firmware hash, and Confidential Computing state, verified against NVIDIA's P-384 attestation chain. Data sealed to a GPU decrypts on that GPU and nowhere else.
Supports H100, H200, B100, and B200 in Confidential Computing mode: encrypted CPU-GPU transfers over the bus (AES-256-GCM), performance-counter suppression, debug disable, and device memory isolation. The measurement, not a raw identifier string, feeds key derivation, so spoofing a UUID is not enough.
Hover for detailThe attestation handshake walks NVIDIA's certificate chain from the device certificate to the embedded root CA, all on the P-384 curve. NVML readings are cross-checked against the signed report, and any mismatch between claimed and measured CC state aborts derivation before a single byte decrypts. Report signatures verify against NVIDIA's device root of trust — the same chain our attestation verifier validates against captured production reports.
- L2
TPM2 Boot-Chain Binding
PCR Policy SealingPlatform Configuration Register policies anchor keys to the exact boot chain. If the OS or firmware has been tampered with, the measurement changes and the key never materializes.
Two-factor hardware binding: combining the TPM platform secret with the GPU measurement means an attacker must compromise both the silicon and the boot chain simultaneously.
Hover for detailSealing uses PCR policies over the measured boot chain, with the platform secret released only inside an authorization session. Rotating firmware legitimately means resealing under the new measurement, an explicit operation that leaves an audit entry.
- L3
Threshold MPC
Threshold DPRF over ristretto255Feldman VSSDistributed key generationCustody is split t-of-n (default 3-of-5) across independent parties. Any t can cooperate to derive keys; t−1 shares reveal mathematically nothing. Shares are dealt in a distributed key-generation ceremony rather than handed out by a dealer who knew the secret first.
Feldman verifiable secret sharing makes a cheating dealer detectable at distribution time, and the ceremony produces a signed transcript every participant countersigns — the artifact an auditor asks for. Proactive share refresh re-deals the same secret on a schedule, so shares an attacker gradually collects go stale before they combine.
Hover for detailThe default derivation path is zero-reconstruct by design: each party computes a partial evaluation against its own share and the results combine in the exponent, so a compromised combiner yields one derived key rather than the master that derives all of them. An opt-in Shamir mode reassembles the data key on a single worker instead, and is the weaker of the two. Reed-Solomon coding tolerates lost shares without weakening the threshold. The threshold path has not yet had independent cryptographic review.
- L4
Forward-Secure State Ratchet
Sequential Time-LockIterated SHA3Secure ZeroingAn iterated hash chain is inherently sequential and cannot be parallelized, so a time-lock cannot be shortcut with more hardware, only waited out. After each access, old keys are securely zeroed.
Each epoch irreversibly advances state: the chain output is mixed with fresh entropy, and the previous state is destroyed with volatile writes. A breach today cannot decrypt yesterday.
Hover for detailThe time-lock is iterated SHA3 with periodic checkpoints, so a verifier replays short segments in milliseconds instead of recomputing days of work. Each epoch ratchets the key material forward and zeroizes the old state, which makes a seized snapshot worthless for anything already opened.
- L5
Path ORAM
Binary-Tree BucketsStash EvictionEvery read or write touches a full root-to-leaf path, so a storage-side observer learns nothing about which fragments are accessed, how often, or in what order.
Oblivious RAM defeats traffic analysis on the storage layer itself. The host serving the ciphertext cannot infer structure from your access behavior.
Hover for detailEvery logical read or write touches one full root-to-leaf path in the binary tree, then remaps the block to a fresh random leaf. Stash occupancy is bounded and monitored, and bucket padding keeps real and dummy traffic indistinguishable on the wire.
- L6
STARK Zero-Knowledge Proofs
Hash-based STARKTransparentPost-QuantumTransparent, hash-based STARK proofs attest that every state transition happened correctly, without disclosing state, keys, or plaintext. Verifiable by anyone from the proof alone. Compliance without exposure.
Auditors and regulators verify the proof, not the data, holding only the published transition values. No trusted setup, and security rests on collision-resistant hashing alone, so the proofs stand against quantum adversaries.
Hover for detailEach proof is a FRI-based STARK over the transition's public binding values. There is no trusted setup and no lattice assumption: a verifier needs only the proof bytes to confirm the transition followed policy, learning nothing else. Externally verifiable without ever touching the state.
- L7
Fragment Dependency Topology
Self-Mutating DAGMerkle CommitmentsEncrypted fragments live in a directed acyclic graph whose topology is derived from state and mutates every epoch. Structural analysis of stored data yields nothing stable to analyze.
Topology variation doubles as forensic watermarking: each authorized copy carries a distinct, provable graph structure, so a leak identifies its source device.
Hover for detailEach epoch the dependency DAG re-randomizes: fragments are re-encrypted, re-linked, and re-committed under a fresh Merkle root. An adversary who mapped yesterday's structure holds a map of a building that no longer exists.