Disk encryption key collision when no_instance_id=true + HKDF context ambiguity #549

The HKDF key derivation in dstack/kms/src/main_service.rs and dstack/dstack-util/src/system_setup.rs concatenates variable-length info slices without length prefixes, enabling context collisions between different (app_id, instance_id) pairs. Combined with no_instance_id=true, all instances of the same app derive identical disk encryption keys.

Root Cause

Two independent issues combine:

1. When no_instance_id=true, the instance_id is empty, so all instances of the same app derive the same disk encryption key. This means every CVM running the same app-compose shares identical disk encryption keys.

2. The HKDF expand() call concatenates info slices without length prefixes. For example, expand(&[app_id.as_bytes(), instance_id.as_bytes()]) concatenates the raw bytes, so (app_id="abc", instance_id="def") produces the same HKDF context as (app_id="abcdef", instance_id="").

Attack Path

1. MPC uses no_instance_id=true in its compose configuration
2. All nodes for the same app derive the same disk encryption key
3. If one node's disk is compromised, the same key decrypts all other nodes' disks
4. Additionally, the HKDF ambiguity allows crafting a different (app_id, instance_id) pair that produces the same disk key as a target app

Impact

All nodes running the same app-compose configuration share identical disk encryption keys. Compromising one node's disk key compromises all nodes. The HKDF ambiguity additionally allows cross-app key collisions through careful choice of app_id and instance_id values.

Suggested Fix

1. For the key collision: generate a random per-instance salt even when no_instance_id=true, or use the VM's unique identifier as part of the key derivation context
2. For the HKDF ambiguity: use a structured encoding (e.g., CBOR or length-prefixed fields) for the HKDF info parameter to ensure unambiguous separation of variable-length inputs:

// Option A: structured encoding (preferred)
#[derive(serde::Serialize)]
struct DiskKeyContext<'a> {
    app_id: &'a str,
    instance_id: &'a str,
}
let info = serde_cbor::to_vec(&DiskKeyContext { app_id, instance_id })?;
hkdf.expand(&[&info], &mut okm)?;

// Option B: manual length-prefixing
let mut info = Vec::new();
info.extend_from_slice(&(app_id.len() as u32).to_be_bytes());
info.extend_from_slice(app_id.as_bytes());
info.extend_from_slice(&(instance_id.len() as u32).to_be_bytes());
info.extend_from_slice(instance_id.as_bytes());
hkdf.expand(&[&info], &mut okm)?;

Note: changing the KDF derivation will invalidate all existing derived keys, requiring a migration strategy for deployed instances.

Note

Reported to dstack as GHSA-whv5-vxvv-q856. Pending triage.

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