public/locksmith

Fork 0

Implement WebAuthn-signed shard recryption transport #12

New issue

Open

opened 2026-07-18 21:45:48 +00:00 by caution-bot · 3 comments

caution-bot commented

2026-07-18 21:45:48 +00:00

(Migrated from codeberg.org)

Current status — 2026-09-24

The release protocol and native/browser integrations are implemented; security hardening and deployment acceptance remain.

Published PR heads checked on 2026-09-24: Platform 1f7e296, Locksmith 9f702bb, Bootproof 821b5c6. Platform's dependency/model/mock/default-runtime pins are aligned at Locksmith d2876e9; subsequent Locksmith changes concern examples, configuration, documentation and terminology. These are published implementation states, not merged/deployed-state claims.

Implemented: Fresh destination/custody nonce and measurement checks, CA-certified holder context, verified UV, atomic single-use authorization and encrypted holder-signed output are implemented. Signed stale/future attestation tests and cross-session destination-evidence replay regressions now exist; the older comments listing those as absent are superseded. Native approval cancellation, browser cleanup and holder eligibility checks are integrated in Platform.

Remaining: Harden recovery framing/connections and HTTP admission/session fairness; implement effective revocation for old credential snapshots, including pending sessions/restarts; assess common-root/private-key capabilities with Platform #383; commission independent parser/stateful fuzzing and saturation testing. Record exact-artifact Nitro/hardware/mixed/negative/restart acceptance and finish review/merge. A holder-authorized destination PCR policy is not an independent organization workload allowlist.

Evidence: current implementation/documentation, V1 contract. The September 23 default release suite passed 11 tests; all 19 certificate-service cases passed across the initial run and socket-permission rerun. Those results apply to c33e35e, not a fresh full-suite run of the later terminology change. Earlier generation/model/loader/synthetic results remain scoped to the revisions recorded in their documentation. Current PRs remain open/unmerged.

Implemented release flow

Client selects a verified proofed-V1 bundle/holder and independently configured custody/destination PCR policies. Interactive CLI recovery checks destination attestation before holder/card prompts; the actual release verifies its own fresh connection again.
/v1/releases/begin authenticates the bundle, selected certificate, credential snapshot and CA-certified organization/bundle/index, then reserves expiring state and a destination challenge.
Client obtains the destination attestation on the submission connection. /prepare verifies that fresh challenge, the destination key/evidence and approved PCRs, then binds the release intent into WebAuthn options. Fresh client nonces bind custody response evidence to the exact request/context; the client verifies it independently.
The holder approves natively or through the Platform-origin browser flow. The browser relay transports the raw assertion; gateway login alone cannot authorize release.
/complete consumes pending authorization once, verifies the assertion/credential/RP/origin/user-verification and exact release context, derives the selected custody key, decrypts one share only inside custody, and emits the existing destination-encrypted, holder-signed Locksmith request.
The client submits it on the destination connection used for attestation and reports the receiver's acknowledgement. An approval or completed signature alone does not establish share acceptance.

Sessions expire after three minutes, with global 64 and per-authenticated-organization/bundle eight limits; four release workers retain permits through actual completion despite caller timeout/disconnect. HTTP restart invalidates approvals while retaining Keyfork's root; enclave restart requires fresh quorum recovery. The issuance bearer token grants no release authority. See migration and acceptance runbook.

Security requirements

Use fresh nonces for both Caution and target enclave attestation flows.
Bind signatures to the target enclave public key, attestation document, PCRs, Caution transport nonce, bundle ID, organization/user/credential context, and replay-resistant request metadata.
Verify Caution enclave identity from pinned PCRs or a signed PCR policy; do not rely on the network endpoint alone.
Verify the target enclave attestation before Caution releases/recrypts any shard.
Verify WebAuthn signatures against the credential associated with the Caution-backed certificate/shard in the loaded v1 bundle.
Keep decrypted shard material inside the Caution service boundary and only emit the recrypted payload.
Avoid logging raw shards, decrypted secrets, bearer tokens, private keys, raw WebAuthn secrets, raw credentials, or full attestation documents.
Fail closed on stale nonce, replay, malformed attestation, mismatched PCRs, unsupported credential, expired/unsupported certificate policy when expiration exists, invalid proof/necroproof when present, or bundle/context mismatch.

Acceptance criteria

End-to-end happy-path test covers a WebAuthn-authenticated shard recryption request.
Replay tests cover reused transport nonces and stale attestations.
Negative tests cover wrong enclave PCRs, wrong bundle ID, wrong credential/user, invalid WebAuthn signature, invalid Caution signature, invalid/mismatched Caution-backed certificate context, invalid proof material when present, and unsupported loaded bundle shape.
The transport works with v1 bundles loaded through Locksmith's latest bundle-loading API from #11.
Existing OpenPGP transport behavior remains compatible.
Documentation explains the WebAuthn transport threat model and operator/client prerequisites.

Design thread: https://codeberg.org/caution/locksmith/issues/7
Keymaker v1 generation: https://codeberg.org/caution/locksmith/issues/10
Locksmith v1 bundle loading: https://codeberg.org/caution/locksmith/issues/11
Public certificate service foundation merged manually from PR #13: https://codeberg.org/caution/locksmith/pulls/13
Platform org-user bundle umbrella: https://codeberg.org/caution/platform/issues/384

## Current status — 2026-09-24 **The release protocol and native/browser integrations are implemented; security hardening and deployment acceptance remain.** Published PR heads checked on 2026-09-24: [Platform `1f7e296`](https://codeberg.org/caution/platform/commit/1f7e2963932ac616ba6c4f0e9553112cb548ce72), [Locksmith `9f702bb`](https://codeberg.org/caution/locksmith/commit/9f702bbf465bc4968e0fa57adcbbc366a1c6977c), [Bootproof `821b5c6`](https://codeberg.org/caution/bootproof/commit/821b5c63e80f082f6d67ba3695c11416933489ec). Platform's dependency/model/mock/default-runtime pins are aligned at Locksmith `d2876e9`; subsequent Locksmith changes concern examples, configuration, documentation and terminology. These are published implementation states, not merged/deployed-state claims. **Implemented:** Fresh destination/custody nonce and measurement checks, CA-certified holder context, verified UV, atomic single-use authorization and encrypted holder-signed output are implemented. Signed stale/future attestation tests and cross-session destination-evidence replay regressions now exist; the older comments listing those as absent are superseded. Native approval cancellation, browser cleanup and holder eligibility checks are integrated in Platform. **Remaining:** Harden recovery framing/connections and HTTP admission/session fairness; implement effective revocation for old credential snapshots, including pending sessions/restarts; assess common-root/private-key capabilities with Platform #383; commission independent parser/stateful fuzzing and saturation testing. Record exact-artifact Nitro/hardware/mixed/negative/restart acceptance and finish review/merge. A holder-authorized destination PCR policy is not an independent organization workload allowlist. Evidence: [current implementation/documentation](https://codeberg.org/caution/locksmith/src/commit/9f702bbf465bc4968e0fa57adcbbc366a1c6977c/docs/share-release.md), [V1 contract](https://codeberg.org/caution/locksmith/src/commit/9f702bbf465bc4968e0fa57adcbbc366a1c6977c/docs/v1-contract.md). The September 23 default release suite passed 11 tests; all 19 certificate-service cases passed across the initial run and socket-permission rerun. Those results apply to `c33e35e`, not a fresh full-suite run of the later terminology change. Earlier generation/model/loader/synthetic results remain scoped to the revisions recorded in their documentation. Current PRs remain open/unmerged. ## Implemented release flow 1. Client selects a verified proofed-V1 bundle/holder and independently configured custody/destination PCR policies. Interactive CLI recovery checks destination attestation before holder/card prompts; the actual release verifies its own fresh connection again. 2. `/v1/releases/begin` authenticates the bundle, selected certificate, credential snapshot and CA-certified organization/bundle/index, then reserves expiring state and a destination challenge. 3. Client obtains the destination attestation on the submission connection. `/prepare` verifies that fresh challenge, the destination key/evidence and approved PCRs, then binds the release intent into WebAuthn options. Fresh client nonces bind custody response evidence to the exact request/context; the client verifies it independently. 4. The holder approves natively or through the Platform-origin browser flow. The browser relay transports the raw assertion; gateway login alone cannot authorize release. 5. `/complete` consumes pending authorization once, verifies the assertion/credential/RP/origin/user-verification and exact release context, derives the selected custody key, decrypts one share only inside custody, and emits the existing destination-encrypted, holder-signed Locksmith request. 6. The client submits it on the destination connection used for attestation and reports the receiver's acknowledgement. An approval or completed signature alone does not establish share acceptance. Sessions expire after three minutes, with global 64 and per-authenticated-organization/bundle eight limits; four release workers retain permits through actual completion despite caller timeout/disconnect. HTTP restart invalidates approvals while retaining Keyfork's root; enclave restart requires fresh quorum recovery. The issuance bearer token grants no release authority. See [migration and acceptance runbook](https://codeberg.org/caution/locksmith/src/commit/2da3be50bebd2dfdc4d0d3a94d05f55be02e910c/docs/service-hardening.md). ## Security requirements - Use fresh nonces for both Caution and target enclave attestation flows. - Bind signatures to the target enclave public key, attestation document, PCRs, Caution transport nonce, bundle ID, organization/user/credential context, and replay-resistant request metadata. - Verify Caution enclave identity from pinned PCRs or a signed PCR policy; do not rely on the network endpoint alone. - Verify the target enclave attestation before Caution releases/recrypts any shard. - Verify WebAuthn signatures against the credential associated with the Caution-backed certificate/shard in the loaded v1 bundle. - Keep decrypted shard material inside the Caution service boundary and only emit the recrypted payload. - Avoid logging raw shards, decrypted secrets, bearer tokens, private keys, raw WebAuthn secrets, raw credentials, or full attestation documents. - Fail closed on stale nonce, replay, malformed attestation, mismatched PCRs, unsupported credential, expired/unsupported certificate policy when expiration exists, invalid proof/necroproof when present, or bundle/context mismatch. ## Acceptance criteria - End-to-end happy-path test covers a WebAuthn-authenticated shard recryption request. - Replay tests cover reused transport nonces and stale attestations. - Negative tests cover wrong enclave PCRs, wrong bundle ID, wrong credential/user, invalid WebAuthn signature, invalid Caution signature, invalid/mismatched Caution-backed certificate context, invalid proof material when present, and unsupported loaded bundle shape. - The transport works with v1 bundles loaded through Locksmith's latest bundle-loading API from #11. - Existing OpenPGP transport behavior remains compatible. - Documentation explains the WebAuthn transport threat model and operator/client prerequisites. ## Related work - Design thread: https://codeberg.org/caution/locksmith/issues/7 - Keymaker v1 generation: https://codeberg.org/caution/locksmith/issues/10 - Locksmith v1 bundle loading: https://codeberg.org/caution/locksmith/issues/11 - Public certificate service foundation merged manually from PR #13: https://codeberg.org/caution/locksmith/pulls/13 - Platform org-user bundle umbrella: https://codeberg.org/caution/platform/issues/384

caution-bot commented

2026-07-19 21:20:49 +00:00

(Migrated from codeberg.org)

Updated this issue so it stays scoped to WebAuthn-signed shard recryption rather than duplicating the v1 bundle generation/loading contracts.

It now points at #10 for Keymaker v1 generation, #11 for Locksmith v1 loading, and PR #13 for the merged public certificate service foundation. It also reflects the finalized public-cert behavior where the service generates the bundle UUID server-side.

Updated this issue so it stays scoped to WebAuthn-signed shard recryption rather than duplicating the v1 bundle generation/loading contracts. It now points at #10 for Keymaker v1 generation, #11 for Locksmith v1 loading, and PR #13 for the merged public certificate service foundation. It also reflects the finalized public-cert behavior where the service generates the bundle UUID server-side.

vkobel commented

2026-09-16 16:03:29 +00:00

(Migrated from codeberg.org)

The Platform creation prerequisites are now integrated (ee9ab08, 706b2d8).

WebAuthn/mixed bundles retain verified holder certificates and credential bindings; multiple passkeys remain one share.
Mock creation and encryption tests pass. WebAuthn/mixed recovery remains explicitly blocked.

Still required: WebAuthn release authorization, single-use challenges, destination attestation verification, private-key derivation/recryption, and CLI/receiver integration. Custody-root bootstrap and real Nitro recovery validation remain outstanding.

The Platform creation prerequisites are now integrated (`ee9ab08`, `706b2d8`). - WebAuthn/mixed bundles retain verified holder certificates and credential bindings; multiple passkeys remain one share. - Mock creation and encryption tests pass. WebAuthn/mixed recovery remains explicitly blocked. Still required: WebAuthn release authorization, single-use challenges, destination attestation verification, private-key derivation/recryption, and CLI/receiver integration. Custody-root bootstrap and real Nitro recovery validation remain outstanding.

vkobel commented

2026-09-17 15:03:34 +00:00

(Migrated from codeberg.org)

The custody enclave verifies the bundle/holder association, destination evidence and UV assertion, atomically consumes authorization, and derives/recrypts only the selected share. Plaintext remains inside custody. Output uses the holder’s OpenPGP signature and existing Locksmith wire format, consistent with the later #7 clarification.

Remaining acceptance coverage:

Genuinely signed stale/future live attestations.
Reusing destination attestation evidence across independently created transport-nonce sessions.

Production checks exist for both boundaries; current synthetic tests do not establish coverage of the signed timestamp path. Add these regressions and reconcile stale deployment-status documentation before closure.

WebAuthn shard recryption is now implemented and the integrated flow has been exercised end to end. Earlier comments listing authorization, challenges, destination verification, recryption and client/receiver integration as unimplemented are stale. The custody enclave verifies the bundle/holder association, destination evidence and UV assertion, atomically consumes authorization, and derives/recrypts only the selected share. Plaintext remains inside custody. Output uses the holder’s OpenPGP signature and existing Locksmith wire format, consistent with the later #7 clarification. Remaining acceptance coverage: - Genuinely signed stale/future live attestations. - Reusing destination attestation evidence across independently created transport-nonce sessions. Production checks exist for both boundaries; current synthetic tests do not establish coverage of the signed timestamp path. Add these regressions and reconcile stale deployment-status documentation before closure.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

public/locksmith#12

No description provided.

Rows
Columns