Forensic sealing (BEACON_COMMIT), ForensicBundle export, account registry, BSM adapter

[mdheller]

Closes the cryptographic + operational gaps between the committed Phase-0 metadata schema pack and a court-presentable evidence corpus — Metadata Standards §6/§8/§10, and the doc's GAP-06/07/08/09/10. Stacks on the zone-gate engine (#19).

Forensic sealing — scripts/exodus_seal.py (GAP-09, atom signing GAP-06)

TriTRPC BEACON_COMMIT custody sealing. A detached Ed25519 signature (deterministic, RFC 8032) over a canonical commit statement that binds content-hash ↔ signer ↔ sealing-time, plus a BLAKE3-256 frame hash (SHA-256 fallback, always labeled).

• verify_receipt() is independently verifiable from the receipt JSON + embedded public key — the FRE 902(14) requirement; an opposing expert needs nothing from the platform.
• Deterministic replay harness: committed receipts re-seal byte-for-byte (test_exodus_seal.py). This is the legal replay harness, not a test convenience.

ForensicBundle export — scripts/exodus_bundle.py (GAP-07)

build_bundle() → §10 ForensicBundle (manifest + compact custody snapshot + replay manifest + BLAKE3-256 & SHA-256 master hashes + Ed25519 seal). verify_bundle() re-derives every hash and checks the signature from the JSON alone. Conforms to schemas/forensic-bundle.json.

Account registry — scripts/account_registry.py (GAP-08)

Backs CHK-09: only active accounts in examples/account-registry.json may enter intake.

BSM adapter — scripts/bsm_intake.py (AC-09, GAP-10)

praudit -xn → syscall sequence, uid/pid map, file-access timeline, privilege-escalation flags. Tested against a synthetic fixture (no real audit data / praudit needed). Implementation gap closed; only operational ingest on the target Mac remains.

Canonicalization

examples/serializer-spec.canon-v0_1.json pins CANON-v0.1 (sorted-key, whitespace-free, UTF-8 JSON), consistent with the shipped intake/gate hashing; versioned so a future move to deterministic CBOR won't break older receipts.

Verification

15 assertions across 2 test scripts, wired into CI (pip install cryptography blake3): byte-exact replay, independent verification, and tamper detection (payload, receipt metadata, signature, bundle core, manifest hash, signature swap). All new instances validate against their schemas; existing validators still green.

Genuinely remaining (operational / key-custody, not implementation)

Run praudit against the live /var/audit; bind a production signing key + chain-of-trust (the committed key is a clearly-labeled synthetic test key); HellGraph atom persistence beyond the receipt layer.

🤖 Generated with Claude Code

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
34361131	Triggered	Generic High Entropy Secret	ed17b50	tests/sealing-fixtures/test-signing-key.json	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[mdheller]

Sanitized + merging (keeper, 2026-07-05). Removed all real personal data (account emails, /Users/mdheller mail path, case_id MBA-2025-06-27-CS, filename) → synthetic; the committed Ed25519 test key is removed and now derived at runtime from a seed (no private key in tree). Golden fixtures regenerated; replay+tamper harness 10/10, intake 5/5.

GitGuardian is red on branch HISTORY only — an intermediate commit still contains the (synthetic, clearly-labelled) test key. Verified the branch tip tree has no key file (seed only) and mergeStateStatus=UNSTABLE/MERGEABLE (not a required check). Squash-merge collapses to the final tree, so the key never reaches main. Treat the old synthetic key value as burned (it was only ever a test fixture).

Separately flagged: examples/valid-evidence-artifact.json still carries the real filename — it is pre-existing on public main (not this PR) and needs a history scrub in a follow-up.