Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 17 Packages Wiki Activity Actions 434
open-standards/sandbox/proof/hardware/2026-10-21-sev-snp
History
Exact
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science 328d89b676
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 5s
Details
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 47s
Details
standards workspaces build + test / jcp-rs (jcp-conformance, jcp/jcp-rs, -p jcp-energy --features nvml, jcp-rs, linux) (pull_request) Successful in 1m43s
Details
standards workspaces build + test / joule-ui-rs (joule-ui/joule-ui-rs, joule-ui-rs, linux) (pull_request) Successful in 1m14s
Details
standards workspaces build + test / proof-rs (proof-conformance, proof/proof-rs, proof-rs, linux, true) (pull_request) Successful in 1m33s
Details
standards workspaces build + test / sandbox-rs (sandbox-conformance, sandbox/sandbox-rs, sandbox-rs, linux) (pull_request) Successful in 2m47s
Details
standards workspaces build + test / joulecontract-rs (joulecontract/joulecontract-rs, joulecontract-rs, linux-arm64, true) (pull_request) Successful in 1m57s
Details
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 4m59s
Details
standards workspaces build + test / macOS energy backends (pull_request) Successful in 7m46s
Details
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 2m50s
Details
sandbox: a confidential run sealed on SEV-SNP hardware, verified by a third party 
The run binding of #392 had only met software-grounded reports. This runs
the reference host inside an SEV-SNP guest and records the result as
evidence anyone can re-check offline.

sandbox-runtime examples:
- confidential_run, run inside the guest. It takes reports through
  configfs-tsm and seals an S6 run against a challenge; the report_data is
  the run binding of SPEC §7.6. It then checks the attestation through the
  chip's VCEK: verified against the challenge, refused against another and
  against none.
- verify_run: the third party's check, from the attestation, the challenge
  issued and the VCEK alone.

sandbox/proof/hardware/2026-10-21-sev-snp: the attestation (with the
1184-byte v5 report), the challenge, the chip's VCEK and AMD's cert chain,
and a README saying what it shows and what it does not. The unit is a
placeholder, so this exercises the binding and verifier on silicon, not
isolation.

Checked on our side, away from the guest:
- The VCEK was fetched from AMD's KDS by the chip id and TCB inside the
  report, and openssl verifies it to ARK-Milan.
- verify_run on the build host verifies the run, and refuses another
  challenge and no challenge.
- An attestation with its outcome changed is refused ("report-data binding
  mismatch"): the AMD signature covers the outcome through the binding.

sandbox-tee: the version comment now says what the code does (v2 layout
and later; a v5 report verified on hardware).

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-21 16:25:26 -04:00
..
attestation.json sandbox: a confidential run sealed on SEV-SNP hardware, verified by a third party 2026-10-21 16:25:26 -04:00
challenge.hex sandbox: a confidential run sealed on SEV-SNP hardware, verified by a third party 2026-10-21 16:25:26 -04:00
README.md sandbox: a confidential run sealed on SEV-SNP hardware, verified by a third party 2026-10-21 16:25:26 -04:00
vcek.der sandbox: a confidential run sealed on SEV-SNP hardware, verified by a third party 2026-10-21 16:25:26 -04:00

README.md

A confidential run on SEV-SNP hardware, 2026-10-21

The report-data binding of SPEC §7.6, exercised on genuine AMD silicon and verified by a party other than the host.

What ran

  • Platform: a confidential VM with AMD SEV-SNP, on an AMD Milan processor (n2d-standard-2, image ubuntu-2404-noble-amd64-v20261016). It was created for the run and deleted after it.
  • Inside the guest: the reference host (confidential_run). It took a report through configfs-tsm (the kernel named its provider sev_guest) and sealed an S6 run. Its report_data is the run binding: the unit, the receipt, the outcome, and a 32-byte challenge chosen by the party that started the run (challenge.hex).
  • The report: version 5, 1184 bytes, signed with the chip's VCEK. It travels in the attestation as tee.report_hex.

What it shows

Verified away from the guest, from these files alone:

cd ../../../sandbox-rs
cargo run -p sandbox-runtime --example verify_run -- \
  ../proof/hardware/2026-10-21-sev-snp/attestation.json \
  "$(cat ../proof/hardware/2026-10-21-sev-snp/challenge.hex)" \
  ../proof/hardware/2026-10-21-sev-snp/vcek.der
  • The report verifies through the VCEK. Its report_data is the binding of this attestation's unit, receipt and outcome, and of the challenge issued.
  • It is refused for any other challenge, and without one.
  • An attestation whose outcome is changed is refused: the AMD signature covers the outcome through the binding.

The VCEK (vcek.der) was fetched from AMD's KDS by the chip id and reported TCB inside the report. It chains to AMD's root (cert_chain.pem: SEV-Milan, then ARK-Milan):

openssl x509 -inform der -in vcek.der -out vcek.pem
openssl verify -CAfile <ARK-Milan> -untrusted <SEV-Milan> vcek.pem

The ARK's SHA-256 fingerprint is 69:D0:63:B4:53:44:D2:6A:2E:94:E1:F4:21:0D:E4:9E:F5:55:30:82:87:D4:C1:74:44:5C:95:63:9A:54:0B:CD. Compare it with the one AMD publishes, not with this file.

What it does not show

  • The unit is a fixed placeholder. This exercises the binding and the verifier on real hardware, not an executor's isolation of a workload.
  • The receipt and Supervisor keys are fixed development keys. The trust here rests on the hardware report, not on those signatures.