`derive_dh_secret` hashes PKCS#8 DER — fragile to library upgrades

[pbeza]

The key derivation path in dstack/kms/src/main_service.rs feeds a DER-encoded public key into the HKDF info field. Since DER is not a canonical encoding for all key types, semantically identical keys with different DER encodings would derive different secrets.

Root Cause

The derive_dh_secret function computes SHA-256 over the full PKCS#8 DER encoding of a private key, which includes ASN.1 structure metadata (OIDs, sequence wrappers, version numbers) in addition to the raw key material. If a library upgrade changes the DER encoding format (e.g., different ASN.1 version, different optional field inclusion), the hash changes silently, breaking all derived secrets.

// kdf.rs:69-73
let dh_secret = sha2::Sha256::digest(&private_key.to_pkcs8_der()?);

Attack Path

1. dstack upgrades the p256 or pkcs8 crate dependency
2. The new version produces a slightly different DER encoding (e.g., adds or removes optional fields)
3. derive_dh_secret produces a different hash from the same underlying key
4. All RA-TLS connections using DH-derived keys break silently
5. Existing disk encryption keys or other secrets derived from DH secrets become unreachable

Impact

Silent breakage of all DH-derived secrets after a library upgrade. This could cause data loss if disk encryption keys are derived through this path, or communication failures if RA-TLS session keys change unexpectedly.

Suggested Fix

Hash only the raw key bytes instead of the full DER encoding:

let scalar_bytes = private_key.to_bytes();
let dh_secret = sha2::Sha256::digest(&scalar_bytes);

SecretKey::to_bytes() returns the raw 32-byte scalar value, which is stable across library upgrades since it represents the mathematical key itself rather than an encoding format.

---

Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.

[kvinwang]

Thanks for the detailed report and for pointing out the fragility of using PKCS#8 DER as the input to .

I‘ve opened PR #603 to stabilize this behavior. The change keeps the high-level derivation the same (HKDF from the KMS root CA key, then SHA-256 over a P-256 private key encoding), but replaces the dependency on with a fixed, Dstack-defined PKCS#8 layout for P-256 keys.

Concretely, the new implementation:

• decodes the root CA key from into a P-256 scalar,
• derives the same 32-byte scalar via HKDF as before,
• computes the corresponding P-256 public key, and
• builds a PrivateKeyInfo/ECPrivateKey structure where only the 32-byte private key and 65-byte uncompressed public key vary, with all ASN.1/DER fields and lengths fixed.

We then hash this fixed encoding with SHA-256. A regression test compares the new output to the previous -based path to ensure the derived secret remains unchanged for existing deployments, while future library upgrades (e.g., or ) can no longer silently alter the derived key material.

If you see any remaining edge cases we should cover, I’m happy to iterate further.