fix: Use the same registry version in CatchUpPackageParam and verification

[eichhorl]

The orchestrator only fetches a CUP if it has a higher height and registry version than the local CUP. Here, the relevant registry version is the one of the DKG summary.

However, when validating the CUPs signature, we used the version of the validation context, which in principal could be smaller than the one of the DKG summary. This could lead to the CUP being verified with an old public key from the registry.

With this PR, we also use the registry version of the DKG summary for signature verification. This is fine, since under normal operation, both versions should always point to the same public key:

1. The public key can only change via recovery and subnet splitting, during which both versions are equal.
2. A recovery CUP may only be adopted if the subnet is stalled, it is therefore not possible to create a summary whose validation context points to the new key, while the DKG version still points to the old key.
3. During a subnet split, the version of the validation context is intentionally frozen to one version below the one introducing the new key. The "scheduled split" summary (which bumps the context's version to the new key) is never part of a CUP. Instead, a new summary is derived for which both versions point to the new key (like in a recovery).

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to e46aeeb.

Security Overview

• 🔎 Scanned files: 3 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/f5e9d2bb-29a4-4b64-902a-391d65fd8b2d?scanId=894b9fb3-f441-450f-93e8-ddcf57edfe02&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type

Relevant files

Enhancement

► rs/consensus/cup_utils/src/lib.rs       Update tests to align registry CUP contents with registry version and add new registry version consistency checks ► rs/consensus/src/consensus/catchup_package_maker.rs       Add post-split block registry version consistency assertions in tests ► rs/orchestrator/src/catch_up_package_provider.rs       Use CUP registry_version() for verification context in provider calls and tests ► rs/orchestrator/src/catch_up_package_provider.rs       Introduce test infrastructure: RegistryVersionRecordingCrypto and tests for verifier timing ► rs/orchestrator/src/catch_up_package_provider.rs       Add test service to serve CUP content for verification tests ► (additional test-related changes within the above files)

[pierugo-dfinity]

the validation context, which in principal could be smaller than the one of the DKG summary

You mean the opposite? So it's actually the other way around, we could technically validate the CUP with a "future" public key of the subnet.

The fix is anyways still correct: we should use the same registry version for validation than the one we used to sign it. The latter is the one from the high threshold transcript of the summary, and the payload builder ensures it is equal to the summary's registry version, which is what you are using here. Though it does not look like this implicit invariant is actually enforced by any tests today.

[pierugo-dfinity]

Maybe also add an assert_ne!(verified_at, context_registry_version)

[eichhorl]

Done, also added a test making sure that both versions are the same for registry cups

[eichhorl]

the validation context, which in principal could be smaller than the one of the DKG summary

You mean the opposite? So it's actually the other way around, we could technically validate the CUP with a "future" public key of the subnet.

No, I mean that assuming the CUP is completely forged, then that forgery could also contain a validation context with a registry version that is smaller than the one of the DKG summary

Under normal operation I agree that the risk is the one you describe (although it should never happen with the argument that recovery/splitting set both versions to the same value)

[pierugo-dfinity]

Ah yes, I understand your argument