diff --git a/pkg/tbtc/signer/docs/roast-phase-5-rollout-runbook.md b/pkg/tbtc/signer/docs/roast-phase-5-rollout-runbook.md index 08e06bf435..3bc8c4f106 100644 --- a/pkg/tbtc/signer/docs/roast-phase-5-rollout-runbook.md +++ b/pkg/tbtc/signer/docs/roast-phase-5-rollout-runbook.md @@ -32,6 +32,18 @@ Before Stage 1 canary: - p95/p99 signing latency 5. Baseline worksheet populated: - `docs/frost-migration/roast-phase-5-baseline-calibration.md` +6. Provenance attestation rotation cadence scheduled: a production + signer installs its configuration once at process start (the + init-time config FFI, `frost_tbtc_init_signer_config`) and the + attestation material in it is immutable for the process lifetime, + while attestation TTL is capped at 7 days + (`TBTC_SIGNER_PROVENANCE_MAX_ATTESTATION_TTL_SECONDS`). Operators + MUST restart (re-init) each signer with fresh attestation material + within every attestation window, and rollout stage scheduling must + absorb that restart cadence. Live re-attestation without a restart + is deliberately unsupported: it would require a dedicated, + narrowly-scoped FFI, never general config mutation, which would + reopen the split-brain risk the immutable install design closed. ## 3. Rollout Stages diff --git a/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md b/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md index 859fb17bc7..689afc5818 100644 --- a/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md +++ b/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md @@ -46,6 +46,48 @@ Recommended stages: 2. Stage 2: 25% signer fleet / broader cohort, hold for 24h. 3. Stage 3: 100% rollout after Phase 5 acceptance criteria remain green. +## Cryptographic Dependency Audit Status (Gate 1 Input) + +The signer pins `frost-secp256k1-tr = "=3.0.0"` (`Cargo.toml`), the Zcash +Foundation FROST implementation's Taproot (BIP-340/341) ciphersuite, +released 2025-04-23. + +External audit coverage of that stack, verified against upstream +statements as of 2026-06-12: + +- **NCC Group, "Zcash FROST Security Assessment"** (report dated + 2023-10-20, published October 2023): audited the **v0.6.0** release + (commit `5fa17ed`) of `frost-core`, `frost-ed25519`, `frost-ed448`, + `frost-p256`, `frost-secp256k1`, and `frost-ristretto255` - key + generation (trusted dealer and DKG) and FROST signing. All findings + were addressed and re-reviewed by NCC. + Report: +- The upstream README states explicitly: *"This does not include + frost-secp256k1-tr and rerandomized FROST."* +- **Least Authority, FROST Demo audit (Q1 2025)**: covered the + `frost-client` and `frostd` demo tooling only - not the library + crates this signer consumes. + +- No 2.x or 3.x release notes mention additional audit coverage. + +**Consequence for Gate 1:** the exact ciphersuite this signer uses for +production signatures (`frost-secp256k1-tr`) and the v0.6.0 → 3.0.0 +evolution of `frost-core` have **no external audit coverage**. The +NCC assessment establishes pedigree for the core protocol +implementation but cannot be cited as covering the pinned version +range. Gate 1 sign-off must therefore do one of: + +1. Commission (or await) an external audit covering `frost-core` 3.x + and the `frost-secp256k1-tr` ciphersuite - the follow-up + checklist's "external audit as merge gate for ECDSA-retirement + phases" decision; or +2. Record an explicit, written risk acceptance for the unaudited + range, scoped to the canary stages of Gate 3 and revisited before + full rollout. + +This section records the facts; choosing between (1) and (2) is a +team decision. + ## Provisional Rollback Thresholds (Draft) These thresholds are intentionally conservative and should be tuned once the