Key lifecycle: disposable device keys, recoverable data root (recovery phrase / WebAuthn PRF), last-device loss

[lannbot]

Design the key lifecycle around the assumption that any single device can vanish. See NOTES.md — Key lifecycle.

The reality: browser storage is evictable (Safari's 7-day script-writable-storage rule for non-installed sites; navigator.storage.persist() is best-effort; installed-PWA exemptions vary by platform).

The split:

• Device signing keys: non-extractable and disposable — losing them costs a re-enrollment, so enrollment must be cheap (see the identity issue).
• The data-encryption root: separate and recoverable — wrapped under a KEK derived from a recovery phrase and/or the WebAuthn PRF extension (hardware-backed), backup bundle on the dumb storage layer.
• Losing the last device must not mean losing the data; the recovery path is the crown jewels and gets its own threat-model section.

Open sub-questions:

• PRF availability floor across the target browsers/authenticators; phrase-only fallback UX.
• Backup bundle format and where it lives (any granted storage backend? all of them?).
• Escrow spectrum: none / social recovery / provider-assisted — deliberately deferred, but the bundle format shouldn't foreclose it.
• Rotation: what a data-root rotation costs (re-wrapping vs re-encrypting history — interacts with the group-crypto issue).

[lannbot]

Finding from the keyhive spike (spikes/keyhive/, commit dc56a30): keyhive's try_from_archive requires the same signer that produced the archive. With device keys held as non-extractable platform handles (the posture this issue assumes), durable cross-session keyhive state in browsers therefore depends on platform key persistence — CryptoKey structured-clone into IndexedDB, i.e. the polymorph-webcrypto platform-keystore direction — not on anything keyhive-side. The spike validated the archive round-trip in-instance with the handle-based signer. Upstream's own wasm binding falls back to an in-memory signing key when WebCrypto is unavailable; that fallback would silently downgrade the non-extractability posture and should be rejected here. Also relevant to this issue's device-keys-disposable stance: losing the platform key = losing the archive's usability = device re-enrollment, which is exactly the recovery path this issue already plans — the finding makes the dependency explicit rather than changing the design.

[lannbot]

G5 design record + executed slice (full text in NOTES §Key lifecycle → "The identity bundle and unlock spectrum"; executable form in spikes/tasks-engine/ act 10, commit 08df819).

The shape

G4's bucket cold-boot collapsed device persistence to one question — where does the key live between sessions — because all content rehydrates from the bucket. The answer is one sealed identity bundle (keyhive archive + identity key + partition refs) under a random bundle key held in LUKS-style keyslots. Unlock methods are slots on one artifact, not competing formats:

slot	material	role
passkey-PRF	32B from the authenticator, one gesture	everyday unlock + vendor-synced or hardware-bound recovery
generated recovery phrase	~8–10 diceware words, argon2id as depth	no-hardware fallback; never user-invented for replicated copies
passphrase + argon2id	human-chosen, work-factored	downloadable device file / local unlock only

The exposure rule (structural, not policy): wrap strength must match ciphertext exposure. Bucket-replicated bundle copies omit the passphrase slot — nothing the system replicates is ever crackable via human memory (the brainwallet/LastPass lesson; and we have no trusted server to rate-limit guesses by design). The user's downloaded file may carry the passphrase slot (custody makes it have+know). Slot edits don't re-encrypt the payload.

PRF support reality (checked 2026-08): current Chromium/Apple/Android + hardware keys yes; Firefox and Windows 10 tail no — feature-detect at enrollment, never discover absence at recovery. Passkeys are origin-bound: the origin-migration story carries re-enrollment, not credential portability.

Executed (headless, wasmtime + MinIO)

Export with both slots (27 KB bundle) → fresh instance: wrong passphrase refused; correct passphrase restores the same identity id; bucket-pull rehydrates the full task list; the restored device authors a task other members accept (CGKA leaf secrets ride the archive); a third instance opens the same bundle via the PRF-shaped slot. 4/4 runs.

Two upstream-ish data points for this issue

1. polymorph:webcrypto has no private-key export at this rev — extractability is recorded mint-time policy awaiting the platform keystore slice. The spike therefore uses an explicit demo-grade Soft identity variant (in-guest key), selected at init; the honest browser path is the keystore slice (structured-clone-held keys), which also serves the silent-boot fast path under the same seam.
2. Self-rotation secrets exist only in the keyhive archive. A bundle exported before the device's own authoring cannot derive epochs that authoring created (BeeKEM leaf rotations are local state, not reconstructible from the op stream). Policy: refresh the persisted bundle after authoring — or design a re-join path for stale-bundle recovery. This is the sharpest open design item here.

Deferred, unchanged: escrow spectrum, recovery threat-model section, device-tree design.

[lannbot]

Keystore slice, first durable piece, implemented (PR #32): the demo's S3 signing credential now lives as a non-extractable sign-only HMAC CryptoKey, structured-cloned into IndexedDB — the platform-keystore direction the keyhive finding on this issue said durable browser state depends on, exercised for real.

Shape of the slice:

• At escrow (credential sheet Confirm), AWS4‖secret is imported with extractable: false, usages ["sign"], and persisted in pm-demo-keystore. The raw string exists transiently at escrow (the user typed it) and is never persisted anywhere; legacy localStorage configs are migrated and scrubbed on first load. CI now bans exportKey from host code outright.
• The engine consumes it through a store-signer import (see Network capabilities: per-destination grants, the app manifest, proxied fetch and the audit log, exfiltration stance #7 — the guest builds canonical requests and receives signatures; it never holds key bytes). Derivation is handle-to-handle with each intermediate re-imported non-extractable; honest limit stated in-code: intermediate MAC outputs transit JS memory during derivation, the durable root never does. WebCrypto has no HMAC-chained deriveKey, so this is as far as the platform allows today.
• The handle is narrower than the key: the signer refuses service != "s3" and wrong region. A raw SigV4 secret is valid account-wide across services; the escrowed handle is not — an attenuation that only exists because the secret became a capability at the boundary (Framework visor: trusted code, position+secret authentication, input suspension - the framework's own UI #22's "credentials become capabilities" ruling, now true for the engine path, not just the panel path).
• Silent boot verified: reload → setup completes from the persisted handle with no secret anywhere in storage and no user interaction — the same seam the identity-bundle fast path on this issue wants.
• Stated asymmetry, unchanged: bearer tokens (Dropbox) cannot get this treatment — they are disclosed to the destination by design and stay chrome-held verbatim, seam-injected. OAuth is less confinable than signing.

Not yet this issue's main body: the sealed identity bundle's keyslots, PRF enrollment, and recovery flows are untouched. This slice establishes the storage layer they need (CryptoKey structured-clone persistence, non-extractability surviving reload) with a live consumer.