SMPTE ST 430-1:2023-09
Revision of SMPTE ST 430-1:2017
SMPTE Standard

D-Cinema Operations — Key Delivery Message

Approved - 2023-09-07

Table of contents🔗

  1. Foreword
  2. 1 Scope
  3. 2 Conformance
  4. 3 Normative references
  5. 4 Terms and definitions
  6. 5 Overview of the KDM (Informative)
    1. 5.1 Basic KDM Elements and D-Cinema Relationships
    2. 5.2 XML Overview of the KDM
  7. 6 Authenticated and Unencrypted Information
    1. 6.1 Overview
    2. 6.2 MessageType
    3. 6.3 RequiredExtensions
      1. 6.3.1 Overview
      2. 6.3.2 Recipient
      3. 6.3.3 CompositionPlaylistId
      4. 6.3.4 ContentTitleText
      5. 6.3.5 ContentAuthenticator (Optional)
      6. 6.3.6 AuthorizedDeviceInfo
        1. 6.3.6.1 Overview
        2. 6.3.6.2 DeviceListIdentifier
        3. 6.3.6.3 DeviceListDescription (Optional)
        4. 6.3.6.4 DeviceList
      7. 6.3.7 ContentKeysNotValidBefore
      8. 6.3.8 ContentKeysNotValidAfter
      9. 6.3.9 KeyIdList
        1. 6.3.9.1 Overview
        2. 6.3.9.2 KeyId
        3. 6.3.9.3 TypedKeyId
      10. 6.3.10 ForensicMarkFlagList (Optional)
        1. 6.3.10.1 Overview
        2. 6.3.10.2 ForensicMarkFlag
    4. 6.4 NonCriticalExtensions
  8. 7 Authenticated and Encrypted Information
    1. 7.1 Overview
    2. 7.2 EncryptedKey
      1. 7.2.1 Overview
      2. 7.2.2 KeyInfo
      3. 7.2.3 CipherData
    3. 7.3 EncryptedData
  9. 8 Signature Information
  10. Annex A Design Features and Security Goals (Informative)
  11. Annex B XML Schema for KDM (Normative)
  12. Bibliography

Foreword🔗

SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual.

At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights.

This document was prepared by Technology Committee 27C.

The following summarizes the changes from the previous edition of this document:

Copyright © 2024, Society of Motion Picture and Television Engineers. All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.

1 Scope🔗

This specification defines a Key Delivery Message (KDM) for use in Digital Cinema (D-Cinema) systems. The KDM has been designed to deliver security parameters and usage rights between D-Cinema content processing centers (e.g., from post production to distribution, or from distribution to exhibition). The KDM carries fundamentally three information types:

The KDM is based on the D-Cinema Generic Extra-Theater Message (ETM) format (SMPTE ST 430-3). It uses XML to represent the information about the content keys and TDLs, and provides security using standardized XML encryption and signature primitives. The KDM message uses X.509 digital certificates, specified in SMPTE ST 430-2, to provide authentication and trust.

2 Conformance🔗

Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.

All text in this document is, by default, normative, except: the Introduction, any clause explicitly labeled as "Informative" or individual paragraphs that start with "Note:"

The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.

The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.

The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.

The keyword "reserved" indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword "forbidden" indicates "reserved" and in addition indicates that the provision will never be defined in the future.

A conformant implementation according to this document is one that includes all mandatory provisions ("shall") and, if implemented, all recommended provisions ("should") as described. A conformant implementation need not implement optional provisions ("may") and need not implement them as described.

Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; then formal languages; then figures; and then any other language forms.

3 Normative references🔗

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

4 Terms and definitions🔗

For the purposes of this document, the terms and definitions given in the following documents and the additional terms and definitions apply:

Advanced Encryption Standard
AES
[SOURCE: NIST FIPS 197]
Coordinated Universal Time
UTC
[SOURCE: ISO 8601-1]
Digital Cinema
D-Cinema
D-Cinema Package
DCP
Extra-Theater Message
ETM
[SOURCE: SMPTE ST 430-3]
Key Delivery Message
KDM
Optimal Asymmetric Encryption Pattern
OAEP
[SOURCE: IETF RFC 8017]
Rights Owner
RO
Rivest Shamir Adleman public key algorithm
RSA
[SOURCE: IETF RFC 8017]
Trusted Device List
TDL
Universally Unique IDentifier
UUID
[SOURCE: IETF RFC 4122]
eXtensible Markup Language
XML
[SOURCE: W3C XML 1.0]

5 Overview of the KDM (Informative)🔗

5.1 Basic KDM Elements and D-Cinema Relationships🔗

This standard presents a specification for the KDM for use in a D-Cinema system. The D-Cinema KDM is normally sent:

  1. between a post-production system and a Distributor, or
  2. between a Distributor and a Theater facility.

D-Cinema systems require that content keys, key usage time window (key parameters) and “trusted equipment” information (Trusted Device List or TDL) be communicated to exhibition facilities. The KDM carries all the critical information required to enable content decryption according to a baseline interoperable security standard. The basic form of the KDM is shown in Figure 1.

Access to the full information payload of the KDM requires knowledge of the targeted recipient’s private key. Having this key, the legitimate recipient may unlock and validate both encrypted and plaintext information contents that are carried. As is explained further in the appropriate sections of this document, the structure of the KDM has been designed to allow this without the recipient having stores of root certificates. To preserve intended security, full KDM information access should only take place within a secure environment (e.g., within a D-Cinema Secure Processing Block). KDMs can, however, be authenticated by insecure devices if such devices have copies of the root certificate of the entity that created and signed the KDM.

The KDM uses XML to represent the information about content keys and provides security using the XML Encryption and XML Signature primitives. To facilitate efficient processing with hardware security chips, the KDM individually encrypts each content key (along with other information) with RSA, and is structured to allow KDMs to be processed by devices that have limited resources of physically secure memory.

Figure 1 –⁠ KDM Information Flow

The KDM message is a particular instance of the generic XML security wrapper defined by the D-Cinema Generic Extra-Theater Message Format (SMPTE ST 430-3) and uses digital certificates defined by the D-Cinema Digital Certificate specification (SMPTE ST 430-2). This document defines the characteristics that are specific to the KDM, and should be followed in combination with SMPTE ST 430-3, which in turn references SMPTE ST 430-2.

The relationship between the KDM and the Composition Playlist (CPL) is shown in Figure 2.

Figure 2 –⁠ Linking Between CPL and KDM Structures

Each CPL is identified by a globally unique value (a UUID as defined in IETF RFC 4122) that appears in the element named Id in the top-level XML element for a CPL. There are other elements in the CPL that also incorporate the abbreviation “Id”, such as the identifier for a track file, though these are not the identifier of the whole CPL itself. The KDM contains an element named CompositionPlaylistId whose value matches the UUID of the CPL for which it carries content keys. The CPL identifies the (optional) content key associated with each track file by a UUID in an element called KeyId. The KDM has matching elements called KeyId. An unencrypted list of the KeyId values that are carried in the KDM appears in the first part of the KDM. The actual content key values (and their matching KeyId) appear in an encrypted portion of the KDM that can only be decrypted by the intended recipient (typically a Security Manager in an exhibition facility).

5.2 XML Overview of the KDM🔗

A KDM is an ETM instance which has in the RequiredExtensions element a child element named KDMRequiredExtensions (defined below), and which also makes use of the AuthenticatedPrivate element of the ETM to store content keys.

The KDMRequiredExtensions element contains information that must be visible without decryption in order to properly handle the KDM within D-Cinema systems. The information made available in this element includes a list of the Content Key Ids (but not the value of those keys) in the message.

The AuthenticatedPrivate portion contains a collection of content keys each encrypted in an EncryptedKey element. These RSA encrypted elements also include the KeyId and validity dates for each content key. The optional EncryptedData element defined in SMPTE ST 430-3 is not used by the KDM. A KDM has a single recipient, so all the EncryptedKey elements can be decrypted with the same RSA private key.

The Signature element defined in SMPTE ST 430-3 carries the signer’s certificate chain and protects the integrity and authenticity of the AuthenticatedPublic portion and the AuthenticatedPrivate portion (both plaintext and ciphertext versions). The Signature section is not authenticated, though it is believed if an attacker made any beneficial modifications to the Signature section, then the authentication of the other sections would fail.

A single KDM can carry multiple content keys for the same content (the same CompositionPlaylistId), and a Composition Playlist may require content keys that are carried in multiple KDMs. For example, a separate KDM could be used to deliver content keys for region-specific dialog tracks.

6 Authenticated and Unencrypted Information🔗

6.1 Overview🔗

The KDM extends the ETM by including the KDMRequiredExtensions element in its RequiredExtensions element. The normative schema is defined in Annex B. The information in the AuthenticatedPublic element of the ETM (and thus, KDM) is digitally signed, and trust in the signature can be verified using the certificate chain in the Signature portion. This element is not encrypted, so any entity that has access to the message can extract this information. The word “public” that appears in the XML label for this element means that any entity that receives the message can view this portion.

The certificate chain is part of the information that is protected by the digital signature, which reduces the risk of an attacker who is able to create a small number of legitimate certificates (e.g., through social engineering). The following sections describe the elements in this portion.

6.2 MessageType🔗

The MessageType element is defined in SMPTE ST 430-3. In a KDM, this element shall contain the following URI: 

http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type

NOTE —⁠ The MessageType value http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type is legal and correct, but, in the event a future revision of the KDM specification requires a revision to the MessageType value, the MessageType value should follow the pattern http://www.smpte-ra.org/430-1/2006/KDM and match the target namespace of the schema.

6.3 RequiredExtensions🔗

6.3.1 Overview🔗

The RequiredExtensions element of the KDM shall contain exactly one KDMRequiredExtensions element, as defined in Annex B. The KDMRequiredExtensions element shall have the following child elements:

6.3.2 Recipient🔗

The Recipient element identifies the certificate associated with the intended recipient of this KDM. The public key identified in this certificate is used to encrypt keys and other information in the AuthenticatedPrivate element of the KDM. To uniquely identify the certificate, the Recipient element shall contain two elements — X509IssuerSerial and X509SubjectName. The X509IssuerSerial element identifies the name of the Certificate Authority (CA) that issued the certificate, called X509IssuerName, and the unique serial number assigned by the CA, called X509SerialNumber.

The X509SubjectName element shall contain the X.509 subject distinguished name found in the certificate. The X.509 distinguished name values in X509IssuerName and X509SubjectName elements shall be compliant with W3C XML Signature Syntax and Processing.

6.3.3 CompositionPlaylistId🔗

This element contains a machine-readable identifier for the Rights Owner’s content (such as a Composition Playlist). It is a 128-bit UUID represented in “urn:uuid:” format when used with XML (IETF RFC 4122).

This is an informational element that is a copy of the definitive value that appears in the RSA protected EncryptedKey structure. It may be ignored by mechanisms that process the EncryptedKey element.

6.3.4 ContentTitleText🔗

The ContentTitleText element shall contain a human-readable title for the composition; e.g., When Pigs Will Fly II. It is strictly meant as a display hint to the user. The optional language attribute is an IETF RFC 3066 language code and indicates the language used. If the language attribute is not present, the value of the element shall be treated as if the language attribute were en.

6.3.5 ContentAuthenticator (Optional)🔗

This element, if present, shall contain a certificate thumbprint (defined in SMPTE ST 430-2) that supports authentication of the content as an authorized version (e.g., through a Composition Playlist [SMPTE ST 429-7]). This element may be absent at the discretion of the KDM creator (who acts on behalf of the rights owner), but it is part of the RequiredExtensions element because compliant receiving equipment is required to understand and process it when present.

NOTE 1 —⁠ If this element is present, then it is intended that the recipient crosscheck the certificate chain for the signer of the CPL against this value. Specifically, one of the certificates in the signer chain of the CPL should have a certificate thumbprint that matches this element in the KDM.

NOTE 2 —⁠ This element facilitates the business requirement of allowing an exhibitor to show content produced by a wide range of studios without needing to have a business relationship with all those studios (e.g., without needing to know the root certificates for all studios). The exhibitor has a relationship with a set of distributors (and knows their root certificates), and the distributors in turn have relationships with studios. To support business flexibility, the ContentAuthenticator is not necessarily the thumbprint of the studio’s root certificate.

NOTE 3 —⁠ Of course, nothing precludes an exhibitor from knowing the root certificates of specific studios and using those certificates as part of validating the CPL.

6.3.6 AuthorizedDeviceInfo🔗

6.3.6.1 Overview🔗

This item contains three elements as described below.

NOTE —⁠ This element is intended to support authorization of devices which process content keys delivered by the KDM or perform other security services related to content protected by those content keys. The AuthorizedDeviceInfo element does not play any role in validating the KDM itself. This element facilitates the dual business requirements of (a) allowing exhibition equipment to be implemented as multiple secure devices (e.g., image media block, sound media block, and projector) and (b) allowing a rights owner to limit delivery of its content or keys to specific trustworthy devices.

6.3.6.2 DeviceListIdentifier🔗

This element shall contain a value uniquely identifying a list of trusted equipment. It is a required member of the AuthorizedDeviceInfo structure.

NOTE —⁠ This element is an aid to management of device lists and tracking of updates to them.

6.3.6.3 DeviceListDescription (Optional)🔗

The DeviceListDescription element, where present, shall contain a human-readable title description of the device list, e.g., Bigtown Multiplex facility equipment list updated June 20, 2006. It is strictly meant as a display hint to the user. The optional language attribute is an IETF RFC 3066 language code and indicates the language used. If the language attribute is not present, the value of the element shall be treated as if the language attribute were en.

6.3.6.4 DeviceList🔗

The DeviceList item shall contain a set of one or more certificate thumbprints. See SMPTE ST 430-2.

NOTE —⁠ Each entry typically represents a specific device which is authorized for use in connection with some of the keys in this KDM. However, the normative behavior of receiving equipment is outside the scope of this standard.

6.3.7 ContentKeysNotValidBefore🔗

This element specifies the time before which the content keys contained in this KDM are not valid. The time shall be 25 characters in the form of a UTC date-time timestamp as specified by IETF RFC 3339. Timestamps shall not include fractional seconds (IETF RFC 3339 time-secfrac). Timestamps shall not use the value Z in the time-offset field. It is possible for a separate KDM to provide a different time window for the same content keys (e.g., to allow a pre-view showing, or to extend an engagement).

This is an informational element that is a copy of the definitive value that appears in the RSA protected EncryptedKey element. It may be ignored by mechanisms that process the EncryptedKey element. The time windows of all content keys shall be the same in the RSA protected blocks.

6.3.8 ContentKeysNotValidAfter🔗

This element specifies the time after which the content keys contained in this KDM are not valid. The time shall be 25 characters in the form of a UTC date-time timestamp as specified by IETF RFC 3339. Timestamps shall not include fractional seconds (IETF RFC 3339 time-secfrac). Timestamps shall not use the value Z in the time-offset field. It is possible for a separate KDM to provide a different time window for the same keys (e.g., to allow a pre-view showing, or to extend an engagement).

This is an informational element that is a copy of the definitive value that appears in the RSA protected EncryptedKey element. It may be ignored by mechanisms that process the EncryptedKey element. The time windows of all content keys shall be the same in the RSA protected blocks.

6.3.9 KeyIdList🔗

6.3.9.1 Overview🔗

This element shall contain an unordered list of one or more TypedKeyId elements, which are defined below. This is an informational element that is a copy of the definitive values that appear in the RSA protected EncryptedKey elements (see 7.2). It may be ignored by mechanisms that process the EncryptedKey element.

6.3.9.2 KeyId🔗

KeyIds are 128-bit UUIDs that shall be represented in “urn:uuid:” format when they appear as an XML value (IETF RFC 4122). The KeyId element uniquely identifies the content key. All keys shall be for use with the assets referenced by the Composition Playlist identified by the CompositionPlaylistId element. As shown below, it shall be used to identify the content key used in encrypting D-Cinema assets, as defined by SMPTE ST 429-6. It shall be represented by a UUID IETF RFC 4122.

6.3.9.3 TypedKeyId🔗

A TypedKeyId is a compound element consisting of a KeyType element and a KeyId. The KeyType shall be a string of characters, further constrained as described below. The KeyType distinguishes keys targeted to different types of devices (e.g., image media decryptor, sound media decryptor). The KeyID shall be as defined in 6.3.9.2. Binding a KeyType to each KeyId assists in defending against cross-system attacks.

The KeyType element shall contain a symbol composed of four (4) characters from the set of 52 upper and lower case ASCII letters A-Z (0x41-0x5A) and a-z (0x61-0x7A).

The KeyType element shall have an optional scope attribute, which shall be a URI value identifying the normative reference which defines the four character key type identifier contained within the element. The default value of the scope attribute shall be the value http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type, which shall be associated with the following set of key type identifiers:

Table 1 –⁠ Base KeyTypes
Byte String (hexadecimal notation) Character String Description
4D.44.49.4B MDIK Image essence key
4D.44.41.4B MDAK Sound essence key
4D.44.53.4B MDSK Subtitle essence key
46.4D.49.4B FMIK Image forensic marking key
46.4D.41.4B FMAK Sound forensic marking key

NOTE 1 —⁠ Receiving equipment is contemplated to use the information in this element to restrict delivery of key information to devices which serve the intended D-Cinema roles. However, the normative behavior of receiving equipment is outside the scope of this document.

The scope attribute with the value http://www.smpte-ra.org/430-1/2017/KDM#kdm-key-type shall be associated with the following KeyType values:

Table 2 –⁠ Aux Data KeyTypes
Byte String (hexadecimal notation) Character String Description
4D.44.58.31 MDX1 Aux Data Type 1 key
4D.44.58.32 MDX2 Aux Data Type 2 key

NOTE 2 —⁠ The MDX1 and MDX2 values allow two distinct sets of security policies to be associated with essence carried in Aux Data Track Files (see SMPTE ST 429-14), based on the nature of this essence. Specifically, MDX1 is intended to signal that the plaintext essence (potentially forensically marked unless forensic marking is disabled per 6.3.10.2) is transmitted without restrictions within the exhibition environment. In contrast, MDX2 is intended to signal that the plaintext essence (potentially forensically marked unless forensic marking is disabled per 6.3.10.2) is transmitted over encrypted links within the exhibition environment. Conformance to these security policies is not specified here and is left to other documents.

The scope attribute with a value that conforms to the syntax http://www.smpte-ra.org/430-1/2017/KDM#mic-key-type-{ID}, where {ID} conforms to the lowercase UUID string representation specified in IETF RFC 4122, shall be associated with the following KeyType value:

Table 3 –⁠ MIC KeyType
Byte String (hexadecimal notation) Character String Description
4D.44.4D.4B MDMK MIC key

The {ID} shall be equal to a KeyId value within the KeyIdList element.

NOTE 3 —⁠ The MDMK key is intended to define the MICKey (see SMPTE ST 429-6) to be used in conjunction with the content key identifier by the UUID embedded in the scope attribute.

EXAMPLE —⁠ <KeyType scope="http://www.smpte-ra.org/430-1/2017/KDM#mic-key-type-e5421139-0f4a-445e-bc1f-3018a2a858ab">MDMK</KeyType> identifies a MIC key associated with the content key with KeyId e5421139-0f4a-445e-bc1f-3018a2a858ab.

The scope attribute with the value http://www.dolby.com/cp850/2012/KDM#kdm-key-type shall be associated with the following KeyType value:

Table 4 –⁠ Immersive Audio KeyType
Byte String (hexadecimal notation) Character String Description
4D.44.45.4B MDEK Immersive sound essence key

6.3.10 ForensicMarkFlagList (Optional)🔗

6.3.10.1 Overview🔗

When present, this element shall contain an unordered list of one or more ForensicMarkFlag elements, which are defined below. Each ForensicMarkFlag element in the list shall have a unique value.

6.3.10.2 ForensicMarkFlag🔗

A ForensicMarkFlag element shall contain a single URI value indicating whether forensic marking is to be used in conjunction with a particular KeyType contained in the KDM. The following table lists the forensic marking requirements defined by this standard:

Table 5 –⁠ Forensic Mark Flags
URI Value Requirement
http://www.smpte-ra.org/430-1/2006/KDM#mrkflg-picture-disable Disable forensic marking in connection with keys of KeyType “MDIK”
http://www.smpte-ra.org/430-1/2006/KDM#mrkflg-audio-disable Disable forensic marking in connection with keys of KeyType “MDAK”
http://www.smpte-ra.org/430-1/2017/KDM#mrkflg-mdx1-{ID}-disable Disable forensic marking in connection with key with KeyId equal to {ID} and of KeyType equal to “MDX1”
http://www.smpte-ra.org/430-1/2017/KDM#mrkflg-mdx2-{ID}-disable Disable forensic marking in connection with key with KeyId equal to {ID} and of KeyType equal to “MDX2”
http://www.smpte-ra.org/430-1/2019/KDM#mrkflg-enh-audio-disable Disable forensic marking in connection with keys of KeyType “MDEK”

{ID} in the table above shall conform to the lowercase UUID string representation specified in IETF RFC 4122 and shall be equal to a KeyId value of the key to which the ForensicMarkFlag applies.

EXAMPLE —⁠ http://www.smpte-ra.org/430-1/2017/KDM#mrkflg-mdx1-dfc4c132-c318-44fd-a515-d2a8075f4c5a-disable

6.4 NonCriticalExtensions🔗

This element is defined in SMPTE ST 430-3.

NOTE —⁠ This element may contain proprietary extensions. Conforming implementations should ignore the contents of this element.

7 Authenticated and Encrypted Information🔗

7.1 Overview🔗

The AuthenticatedPrivate element is normatively defined in SMPTE ST 430-3. It is described here only to illustrate the use of this element for carrying encrypted keys in a KDM. This portion of the KDM is authenticated by the signature, and encrypted for the recipient before being transmitted. The word “private” appears in the XML name for this element, although this does not mean that the information is proprietary or vendor-specific. It means that through encryption only a specified recipient is allowed to view this information. The recipient performs standard XML decryption operations to recover the private information.

The normative schema is defined in Annex B.

Anyone can verify the signature on the KDM and validate the certificate chain to decide whether the message has been modified and whether it was created by a trusted entity. However, only an entity that knows the private key of the recipient can decrypt this portion of the message.

For the KDM, the ETM’s EncryptedData element shall be omitted and each EncryptedKey element shall carry one content key and its associated information. The KDM shall only have a single recipient. The following sections describe how the KDM message uses the EncryptedKey element.

7.2 EncryptedKey🔗

7.2.1 Overview🔗

The RSA public key algorithm shall be used to carry the EncryptedKey data. This element contains information encrypted with the RSA public key algorithm along with all the parameters and information needed to extract that information. It is normatively defined in SMPTE ST 430-3. Child elements of EncryptedKey not listed below shall be unchanged from their SMPTE ST 430-3 definition.

7.2.2 KeyInfo🔗

This element is defined in SMPTE ST 430-3. This element is optional for KDMs, since the Recipient’s certificate is identified in the Recipient element of the RequiredExtensions element of the KDM. It identifies the certificate that contains the public key that was used for the RSA encryption. If this element is present, the certificate identified by the KeyInfo element shall be the same for all EncryptedKey elements in the KDM.

7.2.3 CipherData🔗

The CipherData element is generally defined in SMPTE ST 430-3. For the KDM message, the CipherData element carries a specially formatted plaintext payload. The plaintext consists of the following fixed length elements concatenated together, with the most significant byte first, starting with the first item in the table.

Table 6 –⁠ KDM CipherData Fields
Length Field Description
16 Structure ID. A 128-bit identifier for this structure. The value of the Structure ID shall be f1.dc.12.44.60.16.9a.0e.85.bc.30.06.42.f8.66.ab (hexadecimal).
20 Certificate Thumbprint in binary form as specified in “Certificate and Public Key Thumbprint” of SMPTE ST 430-2.
16 CompositionPlaylistId, a UUID in binary form as specified in IETF RFC 4122.
4 KeyType, a byte string of length four bytes (see 6.3.9.3 tables).
16 KeyId, a UUID in binary form as specified in IETF RFC 4122.
25 NotValidBefore, a UTC date-time encoded as specified in 6.3.7, e.g., 2004-05-01T13:20:00+00:00.
25 NotValidAfter, a UTC date-time encoded as specified in 6.3.8, e.g., 2004-06-30T13:20:00+00:00.
16 Content Key
138 Total

NOTE —⁠ The “Structure ID” is a unique value within the scope of the XML namespace name declared in Clause 6 above. By including a known unique plaintext value in the structure, the system is protected in the event that an attacker attempts compromise by substituting the expected encrypted key block by other data encrypted with the same public key.

The following three KDM validity checks are informative:

  1. The KDM recipient should check that the thumbprint of the signer’s certificate matches the signer of the KDM. If it is not correct, the KDM should be rejected. This prevents cut and paste attacks that would allow a rogue distributor to sign a KDM using the RSA blocks from the real distributor.
  2. The KDM recipient should check the Structure ID. If it is not correct, the KDM should be rejected. This prevents an RSA block that was created for a different type of message (not a KDM) from being used in a KDM.
  3. The KDM recipient should check that the CompositionPlaylistId in the RSA block matches the CompositionPlaylistId in the other portions of the KDM. The information in the RSA block is considered authoritative. The recipient may choose to reject the KDM if the CompositionPlaylistId does not match in all places that it occurs in the KDM.

7.3 EncryptedData🔗

This EncryptedData element defined in SMPTE ST 430-3 shall not be present in KDM instances.

8 Signature Information🔗

This portion of the KDM message is defined in SMPTE ST 430-3.

Since the EncryptedData element is not used in the KDM, the Signature element shall only contain two Reference elements, one for the AuthenticatedPublic and one for the AuthenticatedPrivate (covering the ciphertext form of the EncryptedKey elements).

Annex A
Design Features and Security Goals (Informative)🔗

This annex summarizes the main design features and security goals of the KDM. Additional considerations appear in SMPTE ST 430-3.

Annex B
XML Schema for KDM (Normative)🔗

The XML Schema document (see W3C XML Schema Part 1: Structures) presented in this annex normatively defines the structure of a Key Delivery Message using a machine-readable language. While this schema is intended to faithfully represent the structure presented in the normative prose portions (Clause 6 and Clause 7) of this document, conflicts in definition may occur. In the event of such a conflict, the normative prose shall be the authoritative expression of the standard. 

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Copyright (c) 2006 Society of Motion Pictures and Television Engineers. All rights
  reserved.

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are
  met:
  
  1. Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

  2. Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in the
  documentation and/or other materials provided with the distribution.

  3. Neither the name of the copyright holder nor the names of its
  contributors may be used to endorse or promote products derived from
  this software without specific prior written permission.

  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
  IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
  TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
  PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
  HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
  TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
  PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
  LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
  NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
  SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 -->
<xs:schema
  targetNamespace="http://www.smpte-ra.org/schemas/430-1/2006/KDM"
  xmlns:kdm="http://www.smpte-ra.org/schemas/430-1/2006/KDM"
  xmlns:etm="http://www.smpte-ra.org/schemas/430-3/2006/ETM"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified" attributeFormDefault="unqualified">

  <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" />
  <xs:import namespace="http://www.smpte-ra.org/schemas/430-3/2006/ETM" />

  <xs:element name="KDMRequiredExtensions" type="kdm:KDMRequiredExtensionsType"/>

  <xs:complexType name="KDMRequiredExtensionsType">
    <xs:sequence>
      <!-- Identifies the certificate of the entity receiving the KDM. -->
      <xs:element name="Recipient">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="X509IssuerSerial" type="ds:X509IssuerSerialType"/>
            <xs:element name="X509SubjectName" type="xs:string"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>

      <xs:element name="CompositionPlaylistId" type="etm:UUID"/>
      <xs:element name="ContentTitleText" type="etm:UserText"/>
      <xs:element name="ContentAuthenticator" type="xs:base64Binary" minOccurs="0"/>
      <xs:element name="ContentKeysNotValidBefore" type="xs:dateTime"/>
      <xs:element name="ContentKeysNotValidAfter" type="xs:dateTime"/>
      <xs:element name="AuthorizedDeviceInfo" type="kdm:AuthorizedDeviceInfoType"/>

      <xs:element name="KeyIdList">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="TypedKeyId" type="kdm:TypedKeyIdType" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>

      <xs:element name="ForensicMarkFlagList" minOccurs="0">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="ForensicMarkFlag" type="xs:anyURI" maxOccurs="unbounded"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="AuthorizedDeviceInfoType">
    <xs:sequence>
      <xs:element name="DeviceListIdentifier" type="etm:UUID"/>
      <xs:element name="DeviceListDescription" type="etm:UserText" minOccurs="0"/>
      <xs:element name="DeviceList">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="CertificateThumbprint" type="ds:DigestValueType" maxOccurs="unbounded" />
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="TypedKeyIdType">
    <xs:sequence>
      <xs:element name="KeyType">
        <xs:complexType>
          <xs:simpleContent>
            <xs:extension base="xs:string">
              <xs:attribute name="scope" type="xs:anyURI" use="optional"
                 default="http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type" />
            </xs:extension>
          </xs:simpleContent>
        </xs:complexType>
      </xs:element>
      <xs:element name="KeyId" type="etm:UUID" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

</xs:schema>

Bibliography🔗