carlos / contra Public

native/2 — Secure Enclave device keypair and the keychain KEK Feature Request open

Depends on native/1.

Spec: DESIGN.md, end of "Passkey PRF fast unlock" — the daemon holds its own Secure-Enclave-backed P-256 device keypair, and the user grants access by wrapping specific vault keysets to it. Least privilege by construction: the daemon never holds RK.

Deliverable:

  1. A SEP-backed P-256 keypair, generated on device, private half non-exportable.
  2. The unlock gate. Note the honest limitation Eleven recorded and do not overclaim past it: an in-process LocalAuthentication check is not an enclave-bound kSecAccessControlBiometryCurrentSet ACL. The latter needs a signed binary with an application-identifier entitlement. Pick deliberately, and write the trade-off in a doc comment the way Eleven's vaultkek_darwin.go does.
  3. Capture-without-unlock: items sealed to the vault's drop-box public key vP_j with no unlock at all, matching the web side.

Why it matters beyond the Mac app: this is the key-handling half of the agent surface. AGENTS.md decision 5 requires the daemon to be hardened — non-dumpable, no core dumps, mlocked key pages, and a written plan to move it to its own UID with peer-credential checks on the socket. Same-UID is not a security boundary, and the threat model says so out loud. Start that posture here rather than retrofitting it.

Branch: native/device-key.