Repository navigation
fix(kms): hash the SEV-SNP chip_id into device_id on the key-release path - #1247
Merged
Merged
Conversation
This was referenced Sep 20, 2026
kvinwang
force-pushed
the
fix/kms-authorization-parity
branch
from
September 24, 2026 03:38
f5727fc to
eb78259
Compare
kvinwang
changed the title
Reuse boot_info.device_id instead of re-hashing the raw device id, so the id operators register and the id key release presents come from a single derivation. This makes the dedicated parity test redundant.
kvinwang
added a commit
that referenced
this pull request
Sep 25, 2026
…ed cases #1247 hashes the SNP chip_id into device_id, #1343 requires a 20-byte SNP app_id, #1302 derives the Nitro Enclave device_id from PCR4, and #1303 gates Nitro Enclave key release. Record the expected results in the capability- blocked platform cases, and note in tc-kms-keys-certs-003 that public handover stays on by default (#1307). Signed-off-by: Kevin Wang <wy721@qq.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rescoped to a single change; the other three are split out into #1343, #1344 and #1345.
The SEV-SNP key-release path was the only site in the tree emitting a raw
chip_idasdevice_id:kms/src/main_service/amd_attest.rs(key release)verified_chip_id.to_vec()kms/src/onboard_service.rs(GetAttestationInfo)Sha256::digest(&raw_device_id)dstack-attest/src/attestation.rs(SNP verifier)sha256(parsed.chip_id)dstack-attest/src/attestation.rs(TDX)sha256(get_devide_id())verifier/src/types.rsapp_info.device_idSo the id an operator registers can never equal the id
GetAppKeypresents.auth-eth-bun'sboundedHex(32, 'device ID')andauth-eth'shex(32, …)reject a 128-hex-char value with HTTP 400 before it reaches the chain;auth-simple's unboundedz.string()accepts it and silently never matches. Device-restricted SEV-SNP key release could not succeed.The repo's own tests already asserted both answers for the same
chip_id = [0xab; 64]fixture —onboard_service.rsexpected the sha256,main_service.rsexpected the raw 64 bytes.GetAttestationInfonow reportsboot_info.device_iddirectly instead of re-hashing the raw id, so the registered and presented ids share one derivation by construction.No derived key changes.
device_idis authorization-only and never a KDF input — the only KDF contexts areapp_idandinstance_id. The three tests that pinned 64 bytes pinned the bug and are updated. Blast radius is bounded bysev_snp_key_release = falsebeing opt-in.One compat note:
auth-simpleis the only backend that ever accepted the raw form, so a config that allowlisted the 128-hex-char chip id has to be re-registered with the 32-byte hash. Such a config could not have matched anything before this change either.cargo test -p dstack-kms --all-features: 55 passed.cargo clippy -p dstack-kms -- -D warnings --allow unused_variables: clean.