Static HKDF salt "RATLS" with no key versioning

[pbeza]

The disk encryption key derivation in dstack/kms/src/main_service.rs uses a hardcoded, empty HKDF salt rather than a per-instance random salt, reducing HKDF's security margin and making all derived keys deterministic given the same input keying material.

Root Cause

The RA-TLS key derivation uses a hardcoded salt b"RATLS" for all HKDF operations. There is no key versioning mechanism and no support for key rotation. If the HKDF input keying material (IKM) is compromised at any point, all historically derived keys are also compromised because the salt is static and publicly known.

// kdf.rs:28
const SALT: &[u8] = b"RATLS";

Attack Path

1. Attacker compromises the HKDF input keying material (e.g., via a KMS vulnerability)
2. Because the salt is static and hardcoded, the attacker can re-derive all keys ever produced by this KDF
3. No key versioning means there is no way to distinguish keys from different epochs
4. Key rotation requires changing the IKM, but old keys remain derivable from old IKM + static salt

Impact

No forward secrecy in the key derivation hierarchy. Compromise of the IKM at any point reveals all past and future derived keys. The static salt provides no additional entropy or domain separation beyond what the IKM already provides.

Suggested Fix

1. Include a version number in the salt or info parameter: format!("RATLS-v{}", version)
2. Support key rotation by allowing the salt to be updated periodically
3. Consider using a random salt persisted alongside the derived keys

---

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 write-up and for calling this out.

We took a closer look at how the HKDF is used in our current design. In our case, the input key material is a high-entropy, long‑term secret key (KMS root CA key / k256 signing key), and we use the HKDF context data to provide domain separation between different uses (e.g. app_id, instance_id, "app-disk-crypt-key", "env-encrypt-key", "app-key"). Given that setup, a static, public salt like "RATLS" is acceptable from a cryptographic point of view: the security still reduces to the secrecy of the upstream key material and the correctness of the context.

More importantly, the forward‑secrecy property you are aiming for cannot be achieved purely by changing the salt. If the upstream key material is ever compromised, an attacker can in principle re-derive all keys that were derived from it, regardless of whether the salt was static or randomly chosen, as long as they know the context inputs. Achieving forward secrecy in this hierarchy would require a broader design change around key rotation and/or using shorter‑lived intermediate keys, not just a different salt string.

On the other hand, changing the HKDF salt or derivation scheme now would immediately change all derived keys (disk_crypt_key, env_crypt_key, app ECDSA keys, etc.), and would require a careful migration story for existing deployments. We do not think the security benefit of tweaking the salt alone justifies that operational cost at this point.

We do agree that explicit key versioning and a better‑defined rotation story are worthwhile improvements. We are treating this issue as a design/roadmap input for a future iteration of the key hierarchy rather than a near‑term security bug to patch. When we redesign the KDF layer with explicit versioning and rotation, we will revisit the salt and context structure as part of that work.

Thanks again for the analysis and suggestions.

[h4x3rotab]

Maintainer triage update: this remains open intentionally and is recorded in the public security report table: https://github.com/Dstack-TEE/dstack/blob/master/docs/security/public-security-reports.md#public-reports-and-findings

Disposition: valid roadmap, open. Static salt is acceptable with high-entropy KMS root material and explicit context, but key versioning and rotation need a broader compatibility and migration design before implementation.