16 June 2026 · Day 5 · Giordano Sconti

IKM: the key that opens Ford before any chunk makes sense

After MMCS edge GETs started returning real bytes, decrypt still failed in bulk. On 16 June 2026 the missing piece was not another range formula—it was the IKM (input keying material) that Ford AES-SIV expects before per-chunk keys exist at all.

Live behaviour (and later the EPB/oracle traces) lined up on a narrow rule: take the asset’s contents.protectionInfo wrap from the owned CloudKit record, unwrap it with the zone master (NIST KDF label for wrapping), and that unwrapped key is the IKM. It is not the casual EncryptionKey / file-list key some code paths were tempted to reuse—those look related on paper and poison Ford open checks in practice.

Only with a correct IKM does DeriveFordKeyMaterial (HKDF-SHA256, salt PCSMMCS2, empty info) produce the material that opens Ford ciphertext hosts. Without it, every later argument about ChunkInfo offsets is noise.

In the code today

AssetMaterialPipeline.cs

/// FillFordIkmFromContents:
/// 1) wrap = map["contents"].protectionInfo (owned Record + sig)
/// 2) IKM = AES-KW(NISTKDF(ZM, "wrapping key wrap me"), wrap)

public static AssetCkFile FillFordIkmFromContents(...)

FordMmcsDecryptor.cs

// Ford key derivation — salt=PCSMMCS2, info empty
public static byte[] DeriveFordKeyMaterial(ReadOnlySpan<byte> fileEncryptionKey)
{
    return HKDF.DeriveKey(HashAlgorithmName.SHA256, fileEncryptionKey.ToArray(),
        0x40, salt: PcsMmcs2Salt, info: []);
}

← All notes