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:
- A SEP-backed P-256 keypair, generated on device, private half non-exportable.
- 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
kSecAccessControlBiometryCurrentSetACL. 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'svaultkek_darwin.godoes. - Capture-without-unlock: items sealed to the vault's drop-box public key
vP_jwith 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.