app-server: add codex-device-key crate

[euroelessar]

Why

Device-key storage and signing are local security-sensitive operations with platform-specific behavior. Keeping the core API in codex-device-key keeps app-server focused on routing and business logic instead of owning key-management details.

The crate keeps the signing surface intentionally narrow: callers can create a bound key, fetch its public key, or sign one of the structured payloads accepted by the crate. It does not expose a generic arbitrary-byte signing API.

Key IDs cross into platform-specific labels, tags, and metadata paths, so externally supplied IDs are constrained to the same auditable namespace created by the crate: dk_ followed by unpadded base64url for 32 bytes. Remote-control target paths are also tied to each signed payload shape so connection proofs cannot be reused for enrollment endpoints, or vice versa.

What changed

• Added the codex-device-key workspace crate.
• Added account/client-bound key creation with stable dk_ key IDs.
• Added strict key_id validation before public-key lookup or signing reaches a provider.
• Added public-key lookup and structured signing APIs.
• Split remote-control client endpoint allowlists by connection vs enrollment payload shape.
• Added validation for key bindings, accepted payload fields, token expiration, and payload/key binding mismatches.
• Added flow-oriented docs on the validation helpers that gate provider signing.
• Added protection policy and protection-class types without wiring a platform provider yet.
• Added an unsupported default provider so platforms without an implementation fail explicitly instead of silently falling back to software-backed keys.
• Updated Cargo and Bazel lock metadata for the new crate and non-platform-specific dependencies.

Stack

This is stacked on #18428.

Validation

• cargo test -p codex-device-key
• Added unit coverage for strict key_id validation before provider use.
• Added unit coverage that rejects remote-control paths from the wrong signed payload shape.
• just bazel-lock-update
• just bazel-lock-check

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 69b06f874a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[viyatb-oai]

just make sure backend must verify signature against signed_payload_base64 bytes exactly. The crate now exposes exact bytes, but the security property is only real if the backend does NOT reserialize payloads. Please ensure backend verification uses the provided bytes and the token hash/nonce from the same challenge.

[euroelessar]

[codex] Addressed in 4f7294e: signedPayloadBase64 now documents that it is the exact byte string covered by signatureDer, and that verifiers must verify those bytes directly instead of reserializing the structured payload.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4189212c8a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Split targetPath allowlists by payload audience

REMOTE_CONTROL_CLIENT_PATHS mixes /client and /client/enroll, and both payload validators call validate_remote_control_target unchanged. As a result, RemoteControlClientConnection accepts enrollment paths and RemoteControlClientEnrollment accepts websocket paths, violating each payload type’s route binding. This can permit cross-endpoint proof reuse if downstream verification assumes this crate enforces the path contract.

Useful? React with 👍 / 👎.

[viyatb-oai]

Non-blocking hardening note: validate key_id shape more strictly before using it downstream. Created ids are safe random dk_... values, but sign/get_public currently only reject empty key ids; the macOS provider later uses the caller-provided key_id in Keychain tags and binding metadata paths. Requiring exactly dk_ + unpadded base64url(32 bytes) would make this namespace auditable and remove path/tag weirdness.