ISO 26430-3: Generic Extra-Theater Message Format for D-Cinema Security

Understanding the XML Security Wrapper That Protects Digital Cinema Content Distribution

Introduction to the Generic Extra-Theater Message (ETM)

ISO 26430-3, adopted from SMPTE 430-3, defines the Generic Extra-Theater Message (ETM) format for digital cinema security communications. The ETM is a generic XML security wrapper designed for unidirectional communication channels commonly used between distributors, exhibitors, and studios in the D-Cinema ecosystem. Unlike bidirectional protocols that allow interactive negotiation, unidirectional channels demand a self-contained, verifiable message structure that can be authenticated without a return path.

The ETM format serves as the foundation for the Key Delivery Message (KDM), making it one of the most critical security building blocks in the entire digital cinema content protection chain.

ETM Three-Segment Architecture

The ETM is organized into three distinct XML segments, each serving a specific security purpose. The AuthenticatedPublic segment contains header information visible to any recipient and includes MessageId (a globally unique UUID), MessageType (a URI identifying the specific message variant), AnnotationText (human-readable description), IssueDate (UTC timestamp), Signer identification (X.509 certificate issuer and serial number), and extensibility hooks via RequiredExtensions and NonCriticalExtensions elements.

The AuthenticatedPrivate segment carries zero or more RSA-encrypted EncryptedKey blocks and an optional AES-encrypted EncryptedData block. This dual-algorithm approach combines the key management advantages of asymmetric RSA encryption with the performance benefits of symmetric AES encryption. The EncryptedKey uses RSA-OAEP with 2048-bit keys, while EncryptedData uses AES-128 in CBC mode.

The Signature segment provides authentication using XML Digital Signature primitives. It contains SignedInfo with separate SHA-256 hashes for the AuthenticatedPublic and AuthenticatedPrivate segments, the RSA-SHA256 signature value over this hash, and the signer complete X.509 certificate chain.

Segment Accessibility Encryption Purpose
AuthenticatedPublic All recipients None (signed only) Message headers, signer identity, extensions
AuthenticatedPrivate Intended recipients only RSA-OAEP + AES-128-CBC Key material, confidential payloads
Signature All recipients None (signature) Certificate chain, hash verification, RSA signature

Security Properties and Engineering Considerations

The ETM design demonstrates careful threat modeling. It resists man-in-the-middle attacks through signature verification, replay attacks via unique MessageId and IssueDate fields, message splicing through independent hashing of each segment, and adaptive chosen-ciphertext attacks by using OAEP padding for RSA encryption. The three-hash scheme (separate digests for public, private, and decrypted content) ensures that even entities who cannot decrypt the private segment can still verify its integrity a critical property for intermediate distribution nodes.

Implementations must treat CBC padding errors identically to signature verification failures. Differential error handling creates a side-channel that can leak plaintext information through adaptive chosen-ciphertext attacks.

A particularly elegant design feature is that the XML schema validates correctly in both encrypted and unencrypted forms. This allows standard XML cryptography toolkits to process ETM messages throughout their lifecycle without custom parsing logic. The use of element names like MessageId (rather than just Id) enables memory-constrained XML parsers to locate fields without tracking nesting context.

FAQs

Q: What is the relationship between ETM and KDM?
A: The Key Delivery Message (KDM) is a specific application instance of the ETM format. KDM uses the ETM structure to deliver content decryption keys from distributors to theater playback systems, with the AuthenticatedPrivate segment carrying AES keys encrypted for each recipient RSA public key.
Q: Why does the ETM use both RSA and AES encryption?
A: RSA provides secure key distribution without pre-shared secrets, but is computationally expensive for bulk data. AES is efficient for encrypting large payloads. The ETM uses RSA to encrypt AES keys (in EncryptedKey elements) and AES to encrypt the actual payload data (in EncryptedData), combining the strengths of both algorithms.
Q: How does the ETM prevent replay attacks?
A: Each ETM carries a globally unique MessageId (UUID) and a UTC IssueDate timestamp. Recipients track received MessageIds and reject duplicates. The IssueDate also requires the signer certificate chain to be valid at the specified time, limiting the window for reusing captured messages.

Leave a Reply

Your email address will not be published. Required fields are marked *