fix(staking): BLS proof-of-possession blocks rogue-key aggregate forgery (CRITICAL)

[envestcc]

Security severity: CRITICAL, latent. Stacks on iotex-proto#173 and the IIP-52 PR chain (#4841 → #4842 → #4843 → #4847). The diff includes the IIP-52 PRs' changes until they merge; review the last commit (`fix(staking): require BLS proof-of-possession at candidate register/update`).

The vulnerability is gated today by IIP-52's `ToBeEnabledBlockHeight = math.MaxUint64` — no live chain is at risk — but must be fixed before activation. IIP-52 PR stack should NOT be allowed to merge + activate without this PR also landing.

The bug

`consensus/scheme/rolldpos/rolldpos.go` `validateAggregatedFooter` verifies the IIP-52 COMMIT-vote BLS aggregate signature using:

```go
crypto.BLSAggregateSignatureFromBytes(sig).Verify(pubKeys, msg)
// → blst.FastAggregateVerify(true, pubKeys, msg, dst)
```

with DST = `BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_`. The `POP` suffix names the IRTF Proof-of-Possession ciphersuite, which is only sound if each registered BLS pubkey arrived with a possession proof at registration.

Today registration validates only key format and subgroup membership:

```go
// action/candidate_register.go, action/candidate_update.go
_, err := crypto.BLS12381PublicKeyFromBytes(blsPubKey)
```

No PoP is checked. The proto has no PoP field.

Attack

An attacker with a single active delegate slot:

1. Reads other delegates' BLS pubkeys from chain
2. Picks any secret `x` they control
3. Computes `pk_rogue = g^x − Σ(other pubkeys)` in G1 (public-information-only)
4. Registers `pk_rogue` via `candidateRegisterWithBLS` — current handler accepts (no PoP gate)
5. For any block they want to finalize: submits a footer with bitmap set to all delegates and signature `σ = sign(x, msg)`
6. `FastAggregateVerify(Σ pubKeys, σ, msg)` collapses `Σ pk_i + pk_rogue` to `g^x`. `σ` verifies. `isMajorityCount` passes.

One delegate forges a 2/3+ quorum certificate → finalizes arbitrary blocks → consensus safety break / chain split.

Reachability gate: requires the attacker's candidate to be in `round.delegates` (economic, not cryptographic) AND `EnableBLSAggregation` active.

The fix (Ethereum 2.0 style)

Eth2's mitigation for the same primitive is the `process_deposit` PoP: the validator's deposit signature signs a message that includes the pubkey. Adopting the equivalent pattern at `candidateRegister` / `candidateUpdate`:

```go
// action/protocol/staking/bls_pop.go
const blsPopDomain = "IOTEX_BLS_POP_v1"

func BLSPopSigningRoot(blsPubKey []byte, ownerAddress address.Address) []byte {
h := sha256.New()
h.Write([]byte(blsPopDomain))
h.Write(blsPubKey)
h.Write(ownerAddress.Bytes())
return h.Sum(nil)
}
```

Three values bind into the message — closes three replay variants:

Binding	Closes
`blsPubKey`	Rogue key — attacker without the secret can't sign over the canonical message at all
`ownerAddress`	Candidate substitution — PoP for owner A doesn't validate for owner B
`IOTEX_BLS_POP_v1` prefix	Cross-domain replay — PoP can't be reused as a consensus vote or vice versa; version suffix reserves room for a future fork to rotate

Implementation

• Proto (iotex-proto#173): `bytes blsPop = 5` on `CandidateBasicInfo`. go.mod replace updated to envestcc/iotex-proto@7a486f6.

• FeatureCtx.EnforceBLSPoP: shares `IsToBeEnabled` height with `EnableBLSAggregation` today but is a semantically distinct switch — call sites read self-descriptively and the two can diverge if needed.

• action.CandidateRegister / CandidateUpdate: carry `blsPop` through constructors, Proto/LoadProto, accessors. `NewCandidateRegisterWithBLS` and `NewCandidateUpdateWithBLS` now accept `blsPop`; pre-fork callers may pass nil.

• handlers.go: `handleCandidateRegister`, `handleCandidateUpdate`, and `handleCandidateUpdateByOperator` call `VerifyBLSPop` before writing `Candidate.BLSPubKey` when `EnforceBLSPoP` is active. Failure → `ReceiptStatus_ErrUnauthorizedOperator`.

• bls_pop_test.go: 5 tests including `TestBLSPop_RogueKeyAttackBlocked` as the regression guard — models the attacker registering a pubkey they don't own, demonstrates the only PoP they can produce (signed under their own secret) does NOT validate against the target pubkey, plus the control case confirming a legitimate registrant succeeds.

Out of scope for this PR (follow-ups)

• ioctl / SDK wiring: `stake2register.go` and `stake2update.go` pass nil for `blsPop` with TODO markers. They need a flag to ingest a BLS private key and derive the PoP. Pre-fork the empty PoP is accepted; post-fork the same call will fail with the new check, so the tooling MUST be updated before the fork.

• Migration: existing pre-fork candidate records have no PoP. Before the fork activates, all active candidates must submit a `candidateUpdate` carrying a valid `blsPop`; alternative is a fork-block state migration that drops un-attested BLS pubkeys from `ActiveCandidates`. IIP draft (separate doc) covers the chosen approach.

• Receipt status code: reusing `ErrUnauthorizedOperator` (closest semantic match). Adding a dedicated `ErrInvalidBLSPoP` is another proto bump and not necessary for the fix.

Test plan

• Unit tests `TestBLSPop_*` — 5 cases, including the rogue-key regression guard
• `go test ./action/protocol/staking/ ./action/` — 470 passing locally
• `go build ./...` clean
• CI green on the IIP-52 stack base (feat(consensus): BlockFooter BLS aggregation (IIP-52) #4847) + iotex-proto#173
• Coordinate migration plan with delegates before flipping fork height

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.6% Duplication on New Code

See analysis details on SonarQube Cloud

[envestcc]

Closing in favor of a clean master-based PR — the BLS PoP fix doesn't depend on IIP-52 (the vulnerable registration path is already on master), so stacking it on the IIP-52 PR chain was unnecessary. New PR: #4854