Proofs
Every security property is a live, externally verifiable proof — attestation, in-VRAM consumption, post-quantum key transport, and a transparent STARK audit stream.
Nothing here is asserted. Every property is a command you can run against real
hardware and a verdict you can check. scsa prove <id> runs them all.
The live proofs
| Proof | What it demonstrates |
|---|---|
| Attestation gate | Refuses to release the key on non-attested or non-Confidential-Computing hardware. Fails closed. |
| Anti-replay | An attestation report captured for one challenge is rejected against a fresh one. |
| CC enforcement | No key is released unless Confidential Computing is active on the GPU. Fails closed. |
| In-VRAM inference | Weights are decrypted and consumed inside VRAM; only a small result leaves the device, never the plaintext. |
| Revocation | A revoked model can no longer derive its key. |
| PQ-hybrid migration | A key is migrated from classical to post-quantum-hybrid wrapping, plaintext never exposed. |
| Threshold derivation | A key is derived from a quorum's partials without the master secret ever being reassembled. |
Reading the verdicts
Each proof reports one of:
proven— the property was affirmatively demonstrated on this hardware.fail-closed— the gate correctly refused (for example, Confidential Computing is off). This is the security working, not a failure. The affirmative path simply needs CC-enabled hardware to show.failed— the gate misbehaved. A real problem.
On a stock GPU without Confidential Computing, attest and cc-check read
fail-closed — an attacker who strips CC gets denied. On a CC-enabled GPU (a
customer's own H100, a confidential cloud instance) they turn proven with a
hardware-signed report.
Why the proofs can't be faked
- The attestation report is signed by the GPU vendor's key, verified against an embedded root certificate. There is no forging a passing report without a real, CC-enabled GPU.
- The key is bound to the attested measurement, so a protected model cannot be moved to a different card.
- The audit proofs (below) are transparent — no trusted setup, no secret verification key, nothing to leak or forge.
Post-quantum key transport
The sealed payload is symmetric (ChaCha20-Poly1305), which is already
quantum-resistant. The exposed surface is key transport, and there SCSA layers
X25519 + ML-KEM-768 (FIPS 203) — two independent mechanisms. Breaking one alone
does not recover the key; you must break both classical and post-quantum. This is
the CSfC "two independent layers" model, applied to confidential compute. scsa pq
migrates a key from classical to hybrid wrapping without ever exposing it.
The audit stream (transparent STARK)
Every state transition can emit a transparent, post-quantum STARK proof that the transition is a correct link in a tamper-evident commitment chain. An external auditor verifies it from the proof bytes and public values alone — no state, no keys, no plaintext, no trusted setup.
scsa zk prove <gpu> # generate the proof on the node
scsa zk verify <proof_id> <gpu> # verify statelesslyThis is the upgrade from "trust us" to "check the proof": an auditor watching the stream can confirm each operation without ever touching the weights, the data, or the raw log. A proof can be bound to a specific policy and inference, so the stream attests what ran under which rules — not merely that a chain advanced.