Context
Checkpoint verification reconstructs the validator participant set from genesis and finalized-header deltas, then uses those participants to verify historical finalization signatures. Each active validator identity has both a node key and a BLS consensus key, and checkpoint import must preserve that binding so future certificates authorize the same participants.
Claim
Checkpoint verification uses (node_public_key, consensus_public_key) pairs from genesis and finalized-header deltas for signature verification, but the final checkpoint-state consistency check compares node keys only. A checkpoint can therefore pass verification while assigning different BLS consensus keys to the same node identities.
A malicious checkpoint provider with a correctly signed historical checkpoint chain whose terminal header already authenticates the supplied checkpoint bytes can alter BLS consensus keys in the checkpoint state while preserving node identities and active statuses. A passive public distributor cannot swap keys in an honestly signed checkpoint without changing the checkpoint-data hash and failing terminal-header verification.
Flow
The path is reachable during checkpoint import when verification receives finalized headers signed by the expected historical participants and a terminal header whose checkpoint_hash matches the supplied checkpoint bytes, while the embedded account state keeps the same node keys but changes one or more account consensus_public_key values. No evidence was found for a public RPC/P2P actor or passive checkpoint mirror changing an existing honest checkpoint and keeping verification passing.
Impact
A node bootstrapping from that checkpoint installs altered consensus keys into its local state. Future epoch participants are then derived from account keys that were not bound to the verified historical participant set, corrupting validator-set authorization after import.
Root Cause
The verifier uses full node/BLS pairs for finalized-header signature checks, then reduces the state consistency check to node-key membership instead of comparing the account's consensus key to the accumulated BLS key.
Code
Related Issues/PRs
Related issues cover related identity-binding gaps across checkpoint validator keys, live top-ups, and keyed state-root construction.
Fix
Compare each checkpoint account's consensus_public_key against the BLS key accumulated from genesis and finalized headers. Make the reverse active-validator check compare full (node_key, consensus_key) pairs, and add a negative checkpoint test that mutates only an active validator's BLS key.
Context
Checkpoint verification reconstructs the validator participant set from genesis and finalized-header deltas, then uses those participants to verify historical finalization signatures. Each active validator identity has both a node key and a BLS consensus key, and checkpoint import must preserve that binding so future certificates authorize the same participants.
Claim
Checkpoint verification uses
(node_public_key, consensus_public_key)pairs from genesis and finalized-header deltas for signature verification, but the final checkpoint-state consistency check compares node keys only. A checkpoint can therefore pass verification while assigning different BLS consensus keys to the same node identities.A malicious checkpoint provider with a correctly signed historical checkpoint chain whose terminal header already authenticates the supplied checkpoint bytes can alter BLS consensus keys in the checkpoint state while preserving node identities and active statuses. A passive public distributor cannot swap keys in an honestly signed checkpoint without changing the checkpoint-data hash and failing terminal-header verification.
Flow
The path is reachable during checkpoint import when verification receives finalized headers signed by the expected historical participants and a terminal header whose
checkpoint_hashmatches the supplied checkpoint bytes, while the embedded account state keeps the same node keys but changes one or more accountconsensus_public_keyvalues. No evidence was found for a public RPC/P2P actor or passive checkpoint mirror changing an existing honest checkpoint and keeping verification passing.Impact
A node bootstrapping from that checkpoint installs altered consensus keys into its local state. Future epoch participants are then derived from account keys that were not bound to the verified historical participant set, corrupting validator-set authorization after import.
Root Cause
The verifier uses full node/BLS pairs for finalized-header signature checks, then reduces the state consistency check to node-key membership instead of comparing the account's consensus key to the accumulated BLS key.
Code
checkpoint_hashto equalsha256(checkpoint.data), so the swapped-key state must already be in authenticated checkpoint bytes: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/checkpoint.rs#L263.Related Issues/PRs
Related issues cover related identity-binding gaps across checkpoint validator keys, live top-ups, and keyed state-root construction.
Fix
Compare each checkpoint account's
consensus_public_keyagainst the BLS key accumulated from genesis and finalized headers. Make the reverse active-validator check compare full(node_key, consensus_key)pairs, and add a negative checkpoint test that mutates only an active validator's BLS key.