feat(attestation): measured boot + remote attestation (canon L0 Genesis binding) - #561
Merged
Conversation
…is binding) The server can build a BootProofRecord (the measured-boot chain) but nothing ATTESTED it. This adds the fail-closed verifier — a device is trustworthy from power-on only if every stage it ran was pinned and matched. - src/services/bootAttestation.ts — attestBoot(record, policy) verifies the measured chain against a pinned golden policy: outcome=success; every stage verdict=verified; every pinned stage present with a matching contentHash; and — fail-closed — NO stage may run that isn't pinned (an unpinned stage is an unmeasured surface). Emits a sealed attestation. An empty policy attests nothing (anti-theater). - Closes the loop with the verified-immutable corpus (mount-intent dm-verity, PP #1367): the rootfs stage's measured hash MUST equal the pinned dm-verity root, so "the base is immutable" and "the base that booted is the pinned one" become ONE chain of evidence. - test/boot-attestation.test.mjs (11 checks): happy path + rejects non-success outcome, tampered/failed verdict, hash mismatch, unpinned stage, missing stage, dm-verity mismatch, empty policy, and enforces requireSignature. Gated in builder-contract-tests.yml. Conforms to the vendored BootProofRecord contract (verdict enum verified/skipped/failed/ tampered). Next: bind attestation to device enrollment (DeviceIdentity) under the quorum, and require a valid attestation before the build/device admission.
7 tasks
mdheller
added a commit
that referenced
this pull request
Aug 4, 2026
…um (cloud adapter) (#567) A device joins the fleet only if BOTH hold: 1. boot attests (measured chain matches the per-arch pinned golden policy, rootfs hash bound to dm-verity root) via bootAttestation.ts (PR #561). 2. a validator quorum co-signs THIS enrollment (payload hash bound to device + attested boot hash so the vote can't be replayed to another device or boot). New files: src/services/quorum.ts — TS twin of PP #1370 quorum.py; conforms to the same authoritative QuorumProof shape; no 2nd verifier. src/services/deviceEnrollment.ts — enrollDevice() fuses attestation × quorum; arch-neutral (policy keyed by archClass with platform fallback); fail-closed on missing arch policy. src/contracts/schemas/QuorumProof.json — vendored from mcp-a2a-zero-trust (authoritative); provenance file included. test/device-enrollment.test.mjs — 21 checks: happy path (time-frozen for deterministic sealed hash), tampered rootfs, wrong outcome, sub-threshold quorum, wrong payload hash, missing arch policy, enrollmentPayloadHash binds device+attest, platform fallback, quorum unit tests. CI (.github/workflows/builder-contract-tests.yml): Added "device enrollment gate" step; new service + test paths in path filters. Canon Genesis binding closes the loop: boot attestation (dm-verity ↔ measured chain) PLUS quorum co-signature = ONE evidence chain that the fleet only admits a device that ran the verified, pinned base AND was co-signed by enough validators. Co-authored-by: Michael Heller <charles.peterson@socioprophet.ai>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Executes atlas step 2 — the canon's L0 Genesis binding. The server can already build a
BootProofRecord(the measured-boot chain), but nothing attested it. This adds the fail-closed verifier: a device is trustworthy from power-on only if every stage it ran was pinned and matched.What's here
src/services/bootAttestation.ts—attestBoot(record, policy)verifies the measured chain against a pinned golden policy:outcome = success; every stage verdict= verified;contentHash;test/boot-attestation.test.mjs(11 checks): happy path + rejects non-success outcome, tampered/failed verdict, hash mismatch, unpinned stage, missing stage, dm-verity mismatch, empty policy; enforcesrequireSignature. Gated inbuilder-contract-tests.yml.Conforms to the vendored
BootProofRecordcontract.Next
Bind attestation to device enrollment (
DeviceIdentity) under the quorum (#1370), and require a valid attestation before the build/device admission (#557) — so no image is built by, and no device enrolls from, an unattested node.Touches a workflow — flagged for human review; not auto-merging.