Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26430-1: Key Delivery Message (KDM) for Digital Cinema Operations
Technical deep dive into the D-Cinema Key Delivery Message RSA-encrypted content key delivery, CPL-key binding, Trusted Device Lists, and forensic marking control
1. KDM Architecture and Security Model
ISO 26430-1 (SMPTE 430-1) defines the Key Delivery Message (KDM) for Digital Cinema systems. The KDM is an XML-based security message that delivers content decryption keys from content processors (post-production or distributors) to exhibition facilities. It carries three fundamental information types: content keys for a specified Composition Playlist (CPL), key usage parameters (primarily a validity date/time window), and the Trusted Device List (TDL) identifying equipment permitted to use the content keys. The KDM is based on the D-Cinema Generic Extra-Theater Message (ETM) format and uses XML Encryption and XML Digital Signature primitives for security. The ETM base format provides a generic message envelope with AuthenticatedPublic and AuthenticatedPrivate sections, which the KDM extends with cinema-specific key delivery parameters. This layered architecture means that the same security infrastructure can support multiple message types beyond KDMs, such as facility management messages and security log messages, providing operational flexibility for cinema security deployments. The KDM is typically generated by a Key Management System (KMS) operated by the distributor or a third-party security provider, and delivered to the theater via email, web portal, or automated API. Each KDM is uniquely identified by its Id element, which is a UUID that enables tracking and auditing of key delivery operations across the distribution chain from content owner to exhibition.
The KDM uses RSA public-key cryptography to individually encrypt each content key. This design allows KDMs to be processed by hardware security modules with limited secure memory (as little as 4 KB). Each encrypted key block is 256 bytes (2048-bit RSA), with a 214-byte plaintext payload containing the key, metadata, and a structure ID for tamper detection. The small memory footprint is critical for the embedded security processors used in D-Cinema media blocks.
2. KDM Structure and CPL-to-Key Binding
The KDM extends the ETM format with a KDMRequiredExtensions element containing: Recipient (identifies the target certificate via IssuerName and SerialNumber), CompositionPlaylistId (UUID of the target CPL), ContentTitleText, ContentAuthenticator (optional certificate thumbprint for CPL validation), AuthorizedDeviceInfo (device list for key usage authorization), ContentKeysNotValidBefore/After (validity time window), and KeyIdList (listing all key UUIDs in the message). The actual encrypted key values are carried in the AuthenticatedPrivate portion, each wrapped in an EncryptedKey element using RSA-OAEP. Each EncryptedKey binds together: Structure ID (0xF1DC124460169A0E85BC300642F866AB), Certificate Thumbprint, CompositionPlaylistId, KeyType (e.g., “MDIK” for image, “MDAK” for sound), KeyId, validity dates, and the 128-bit AES content key. The binding between the key and the CPL is enforced cryptographically: the CompositionPlaylistId appears both in the signed (but unencrypted) AuthenticatedPublic section for routing purposes and inside the RSA-encrypted block as an authoritative value that cannot be modified without detection. This dual placement prevents man-in-the-middle attacks where an attacker might try to redirect a KDM intended for one composition to another. The Recipient element uses the certificate IssuerName and SerialNumber to identify the target decryption device, ensuring that only the intended media block can unwrap and use the content keys.
| KeyType | Hex Value | Description |
|---|---|---|
| MDIK | 4D.44.49.4B | Image essence decryption key |
| MDAK | 4D.44.41.4B | Sound essence decryption key |
| MDSK | 4D.44.53.4B | Subtitle essence decryption key |
| FMIK | 46.4D.49.4B | Image forensic marking key |
| FMAK | 46.4D.41.4B | Sound forensic marking key |
The KDM supports forensic marking flags that can disable picture or audio forensic marking on a per-key basis. This allows rights owners to control whether forensic watermarking or fingerprinting is applied during playback, providing flexibility for different release windows or regional requirements. The forensic marking key types (FMIK, FMAK) are separate from decryption key types, allowing the forensic marking function to be authorized independently of decryption.
3. Cryptographic Operations and Security Design
The KDM’s security model is layered. The AuthenticatedPublic portion is digitally signed (RSA-SHA256) and can be verified by any recipient without decryption. The AuthenticatedPrivate portion is both signed and encrypted only the intended recipient (identified by the Recipient element) can decrypt the content keys using their RSA private key. Three critical validity checks protect against attacks: (1) verify the signer’s certificate thumbprint matches the KDM signer to prevent cut-and-paste attacks; (2) verify the Structure ID to prevent substitution of RSA blocks from other message types; (3) verify the CompositionPlaylistId consistency across all locations in the KDM. The key type binding (e.g., “MDIK” only usable for image decryption) defends against cross-system attacks where a sound key might be substituted for an image key. Additionally, the AuthorizedDeviceInfo element enables device-level authorization, ensuring that only specific, trusted media blocks within a theater complex can use the delivered keys. The TDL may include multiple device thumbprints, allowing a single KDM to authorize playback across multiple screens in a multiplex environment while excluding unauthorized devices.
From an engineering implementation perspective, the KDM enables a flexible business model where a single KDM can deliver multiple keys for the same content, but different keys for different content must use separate KDMs. Processing devices can unwrap content decryption keys upon first KDM receipt and re-encrypt them with a local AES or TDES key (minimum 112-bit entropy) for secure local storage, avoiding costly RSA operations on every playback. This local key storage mechanism is critical for performance in high-throughput environments where multiple screens may start playback simultaneously.
4. Frequently Asked Questions
Q: Can a single KDM contain keys for multiple compositions?
A: No. A KDM is scoped to a single CompositionPlaylistId. All keys in a KDM are for the same content. Different content requires separate KDMs, even if delivered to the same recipient.
A: No. A KDM is scoped to a single CompositionPlaylistId. All keys in a KDM are for the same content. Different content requires separate KDMs, even if delivered to the same recipient.
Q: How are KDM validity windows enforced?
A: The ContentKeysNotValidBefore and ContentKeysNotValidAfter timestamps are embedded both in the unencrypted KDMRequiredExtensions (for routing) and inside the RSA-encrypted block (as authoritative values). Exhibition equipment must check the current time against these bounds and refuse to decrypt outside the valid window.
A: The ContentKeysNotValidBefore and ContentKeysNotValidAfter timestamps are embedded both in the unencrypted KDMRequiredExtensions (for routing) and inside the RSA-encrypted block (as authoritative values). Exhibition equipment must check the current time against these bounds and refuse to decrypt outside the valid window.
Q: What is the purpose of the AuthorizedDeviceInfo element?
A: It contains a DeviceList of certificate thumbprints identifying specific trusted devices (e.g., specific Image Media Blocks or Sound Media Blocks) that are authorized to use the delivered keys. This allows rights owners to restrict content playback to specific, trusted equipment in a theater.
A: It contains a DeviceList of certificate thumbprints identifying specific trusted devices (e.g., specific Image Media Blocks or Sound Media Blocks) that are authorized to use the delivered keys. This allows rights owners to restrict content playback to specific, trusted equipment in a theater.
Q: Can a KDM be re-used for multiple screenings?
A: Yes, as long as the screening times fall within the validity window specified in the KDM. The KDM itself is a static XML document the same KDM can be loaded once and used for all screenings during the engagement period.
A: Yes, as long as the screening times fall within the validity window specified in the KDM. The KDM itself is a static XML document the same KDM can be loaded once and used for all screenings during the engagement period.
