fix(chain): require K11 self-attestation at first-master bootstrap (closes #165)

[hanwencheng]

The vulnerability (CRITICAL, #165)

SidecarRegistry.registerFirstMasterDevice was unauthenticated first-call-wins: it set operatorMasterWallet[operatorOmni] = msg.sender with no binding between operatorOmni and the sender, and its attestation param was accepted but ignored (SidecarRegistry.sol:143, pre-fix). An attacker watching the mempool could copy the victim's operatorOmni and front-run with their own sender → permanent operator lockout. Surfaced by the codex adversarial review on #162.

This is a live vuln in the current EOA/cast bootstrap, independent of the web flow (#163) and the ERC-4337 migration (#164).

The fix — Approach A: K11 self-attestation bound to msg.sender

registerFirstMasterDevice now requires a K11 P-256 self-attestation, verified against the to-be-registered pubkey (k11PubX/k11PubY — there's no prior device at bootstrap) over:

challenge = keccak256(abi.encode(
  OP_REGISTER_1ST_MASTER, operatorOmni, actorOmni, deviceKeyHash,
  k11PubX, k11PubY, roles, msg.sender, block.chainid, address(this)))

Why it defeats the front-run: the challenge commits msg.sender. A front-runner replaying the victim's captured assertion with their own sender → the contract recomputes a different challenge → the embedded clientDataJSON challenge no longer matches → verifyAssertion rejects. The attacker can't forge the operator's K11 signature, and using their own K11 key yields a different operatorOmni. No chicken-and-egg: the attesting key is the key being registered (a self-attestation), enrolled by bootstrap time (arch.md §9 stage 2).

Survives ERC-4337 (#164) unchanged — the binding is to msg.sender (an EOA today, the smart-account address later).

What's in this PR

• SidecarRegistry.sol — add OP_REGISTER_1ST_MASTER; replace the ignored bytes attestation with a K11Assertion selfAttestation; verify via the existing K11Verifier + store the read signCount.
• AgentKeysV1.t.sol — new test_RegisterFirstMaster_RejectsBogusSelfAttestation (unauthenticated path closed) and test_RegisterFirstMaster_RejectsFrontRunWithDifferentSender (captured assertion is non-transferable to another sender; the legit operator still bootstraps); existing happy-path + helper updated to mock the verifier (real P-256 is covered in K11Verifier.t.sol / P256Verifier.t.sol). forge test: 41 passed, 0 failed.
• heima-register-first-master.sh — header note documenting the new ABI + the self-attestation challenge + the coordinated-redeploy activation (see below). The live cast call is left on the old ABI so it keeps working against the currently-deployed registry.

Activation (coordinated redeploy — follow-up, documented in #165)

The contract isn't redeployed by this PR. To activate: redeploy SidecarRegistry on Heima + flip heima-register-first-master.sh's cast call to the new ABI + generate the self-attestation (mirror scripts/heima-scope-set.sh --webauthn) + update docs/spec/deployed-contracts.md + scripts/operator-workstation.env + re-run verify-heima-contracts.sh. This step needs a live authenticator, so it's a deliberate operator action, not part of this code PR. The harness skips first-master in CI, so nothing breaks meanwhile.

Scope notes

• This is the do-first slice extracted from Migrate master authority to an ERC-4337 P-256 smart-account (resolves §11 gating findings) #164 (the ERC-4337 migration). Migrate master authority to an ERC-4337 P-256 smart-account (resolves §11 gating findings) #164's "authenticated first-master bootstrap" checkbox is satisfied by this.
• forge fmt is not CI-gated here; this PR keeps the repo's existing brace style (no spurious reformat).

Closes #165.

🤖 Generated with Claude Code