ISO 26430-1:2008
(Main)Digital cinema (D-cinema) operations — Part 1: Key delivery message
Digital cinema (D-cinema) operations — Part 1: Key delivery message
ISO 26430-1:2008 defines a “key delivery message” (KDM) for use in digital cinema systems. The KDM has been designed to deliver security parameters and usage rights between digital cinema content processing centres (e.g. from post production to distribution, or from distribution to exhibition). The KDM carries fundamentally three information types: content keys for a specified composition play list (CPL); content key parameters – primarily the permitted key usage date/time window; the trusted device list (TDL) which identifies equipment permitted to use the content keys.
Opérations du cinéma numérique (cinéma D) — Partie 1: Message de remise de clé
General Information
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 26430-1
First edition
2008-07-15
Digital cinema (D-cinema) operations —
Part 1:
Key delivery message
Opérations du cinéma numérique (cinéma D) —
Partie 1: Message de remise de clé
Reference number
ISO 26430-1:2008(E)
©
ISO 2008
---------------------- Page: 1 ----------------------
ISO 26430-1:2008(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2008 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 26430-1:2008(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
ISO 26430-1 was prepared by the Society of Motion Picture and Television Engineers (as
SMPTE 430-1-2006) and was adopted, under a special “fast-track procedure”, by Technical Committee
ISO/TC 36, Cinematography, in parallel with its approval by the ISO member bodies.
ISO 26430 consists of the following parts, under the general title Digital cinema (D-cinema) operations:
⎯ Part 1: Key delivery message
⎯ Part 2: Digital certificate
⎯ Part 3: Generic extra-theater message format
© ISO 2008 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 26430-1:2008(E)
Introduction
The International Organization for Standardization (ISO) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent.
ISO takes no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has assured ISO that he is willing to negotiate licences under reasonable and
non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of
the holder of this patent right is registered with ISO. Information may be obtained from:
Eastman Kodak Company
Intellectual Property Transactions
343 State Street
Rochester, NY 14650
USA
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights other than those identified above. ISO shall not be held responsible for identifying any or all such patent
rights.
iv © ISO 2008 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
SMPTE STANDARD
D-Cinema Operations —
Key Delivery Message
Page 1 of 17 pages
Table of Contents Page
1 Scope . 3
2 Normative References . 3
3 Glossary . 3
4 Overview of the KDM (Informative). 4
4.1 Basic KDM Elements and D-Cinema Relationships. 4
4.2 XML Overview of the KDM . 6
5 Authenticated and Enencrypted Information. 6
5.1 Message Type . 6
5.2 RequiredExtentions. 7
5.2.1 Receipt . 7
5.2.2 CompositionPlaylisted. 7
5.2.3 ContentTitleText. 7
5.2.4 ContentAuthenticalor (Optical). 8
5.2.5 AuthorizedDeviceInfo. 9
5.2.6 ContentKeysNotValidBefore . 9
5.2.7 ContentKEysNotValidAfter. 10
5.2.8 LeyIDList . 10
5.2.9 ForensicMarkFlagList (Optional). 10
5.3 NonCriticalExtensions. 11
6 Authenticated and Excrypted Information. 11
6.1 EncryptedKey. 12
6.1.1 KenInfo. 12
6.1.2 CipherData. 12
6.2 EncryptedData . 13
7 Signature Information. 13
Annex A Design Features and Secutiry Goals (Informative) . 14
Annex B Bibliography (Informative) . 15
Annex C XML Schema for KDM (Normative). 16
Copyright © 2006 by THE SOCIETY OF
Approved
MOTION PICTURE AND TELEVISION ENGINEERS
October 3, 2006
3 Barker Avenue, White Plains, NY 10601
(914) 761-1100
© ISO 2008 – All rights reserved 1
---------------------- Page: 5 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
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 Part XIII of its
Administrative practices.
SMPTE Standard 430-1 was prepared by Technology Committee DC28.
Page 2 of 17 pages
2 © ISO 2008 – All rights reserved
---------------------- Page: 6 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
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:
• Content keys for a specified Composition Play List (CPL).
• Content key parameters – primarily the permitted key usage date/time window.
• The Trusted Device List (TDL) which identifies equipment permitted to use the content keys.
The KDM is based on the D-Cinema generic Extra-Theater Message (ETM) format [ETM]. It uses XML to
represent the information about the content decryption keys and TDLs, and provides security using
standardized XML encryption and signature primitives. The KDM message uses X.509 digital certificates,
specified in [D-Cinema Digital Certificate], to provide authentication and trust.
NOTE – The brackets convention “[…]” as used herein denotes either a normative or informative reference.
2 Normative References
The following standards contain provisions which, through reference in this text, constitute provisions of this
standard. At the time of publication, the editions indicated were valid. All standards are subject to revision,
and parties to agreements based on this standard are encouraged to investigate the possibility of applying the
most recent edition of the standards indicated below.
[KLV] SMPTE 429-6-2006, D-Cinema Packaging — MXF Track File Essence Encryption
[D-Cinema Digital Certificate] SMPTE 430-2-2006, D-Cinema Operations — Digital Certificate
[ETM] SMPTE 430-3-2006, D-Cinema Operations — Generic Extra Theater Message Format
[RFC2253] Lightweight Directory Access Protocol (v3):UTF-8 String Representation of Distinguished Names,
December 1997. See: http://www.ietf.org/rfc/rfc2253.txt
[Time] UTC, RFC 3339: Date and Time on the Internet: Timestamps. G. Klyne and C. Newman. Informational,
July 2002. See: http://ietf.org/rfc/rfc3339.txt
[UUID] “A Universally Unique Identifier (UUID) URN Namespace” July 2005. See:
http://www.ietf.org/rfc/rfc4122.txt
3 Glossary
The following paragraphs define the acronyms used in this standard.
AES: Advanced Encryption Standard secret key algorithm. See [FIPS-197].
ASN.1: Abstract Syntax Notation 1.
Base64: A printable encoding of binary data. See [Base64].
DES: Data Encryption Standard. See [FIPS-46-3].
ETM: Extra Theatre Message [See ETM]
FIPS: Federal Information Processing Standards of NIST.
HMAC-SHA-1: Hash-based Message Authentication Code based on SHA-1. See [FIPS-198].
IETF: Internet Engineering Task Force standards group.
Page 3 of 17 pages
© ISO 2008 – All rights reserved 3
---------------------- Page: 7 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
IP: Internet Protocol. An IETF standard.
ISO: International Standards Organization.
KEK: Key Encrypting Key
LE: Link Encrypter.
LD: Link Decrypter.
MD: Media Decrypter.
NIST: National Institute of Standards and Technologies.
OAEP: Optimal Asymmetric Encryption Pattern. See [PKCS1].
RO: Rights Owner.
RSA: Rivest Shamir Adleman public key algorithm.
SE: Security Entity. Any Digital Cinema entity that performs cryptography.
SHA-1: Secure Hash Algorithm revision 1. See [FIPS-180-2].
SHA-256: Secure Hash Algorithm. See [FIPS-180-2].
SM: Security Manager.
S/MIME: Secure Multipurpose Internet Mail Extensions.
SPB: Secure Processing Block.
TCP: Transmission Control Protocol. IETF standard for reliable bi-directional streams.
TDES: Triple DES. See [FIPS-43-3].
TLS: Transport Layer Security protocol. See [Rescorla].
TMS: Theater Management System.
X.509. A widely used and supported digital certificate standard.
XML: Extensible Markup Language.
4 Overview of the KDM (Informative)
4.1 Basic KDM Elements and D-Cinema Relationships
This standard presents a specification for the Key Delivery Message (KDM) for use in a Digital Cinema (D-
Cinema) system. The D-Cinema Key Delivery Message 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 plain text information
contents 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 decryption keys and provides security using
the XML Encryption and 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.
Page 4 of 17 pages
4 © ISO 2008 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
Recipient Recipient
Public Key Private Key
Content Keys Content Keys
Key Delivery
& Parameters & Parameters
Message
Issuer Recipient
TDL TDL
Issuer Issuer
Private Key Public Key
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 Theatre Message Format [ETM] and uses digital certificates defined by the D-Cinema Digital
Certificate specification. This document defines the characteristics that are specific to the KDM, and should
be followed in combination with [ETM], which in turn references the digital certificate specification.
The relationship between the KDM and the Composition Play List (CPL) is shown in figure 2.
CPL KDM
Id Message Id
Composition
Play
Track File Asset
Key Id
Key Id List
Key Id
Track File Asset
Key Id
Key Id
EncryptedKey
Key Id
Key Value
EncryptedKey
Key Id
Key Value
Figure 2 – Linking Between CPL and KDM Structures
Page 5 of 17 pages
© ISO 2008 – All rights reserved 5
---------------------- Page: 9 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
Each CPL is identified by a globally unique value [UUID] that appears in the element named “Id” in the top-
level XML structure for a CPL. There are other elements in the CPL that are also called “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 keys.
The CPL identifies the (optional) 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 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).
4.2 XML Overview of the KDM
NOTE – The XML figures shown in this specification are informative. See Annex C for the normative XML schema that
defines the KDM. The XML diagrams in this document conform to the legend given in [ETM].
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 encryption 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 decryption 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 [ETM] 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 [ETM] 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 decryption keys for the same content (the same
CompositionPlaylistId), and a Composition Play List may require keys that are carried in multiple KDMs. For
example, a separate KDM could be used to deliver content keys for region-specific dialog tracks.
5 Authenticated and Unencrypted Information
The KDM extends the ETM by including the KDMRequiredExtensions element (see Figure 4 below) in its
RequiredExtensions element. The normative schema is defined in annex C. 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.
5.1 MessageType
The MessageType field is defined in [ETM]. In a KDM, this field shall contain the following URI:
http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type
Page 6 of 17 pages
6 © ISO 2008 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
5.2 RequiredExtentions
The RequiredExtentions element of the KDM shall contain exactly one KDMRequiredExtensions element, as
defined in Annex C and illustrated in figure 3. The KDMRequiredExtensions element shall have the following
child elements:
5.2.1 Recipient
The Recipient field shall identify the intended certificate/subject of this KDM. The public key identified in this
certificate is used to encrypt the keys found in the AuthenticatedPrivate portion of the KDM message. An
X.509 certificate is identified by the name of the Certificate Authority (CA) that issued it, called IssuerName,
and the unique serial number assigned by the CA, called SerialNumber. To aid in routing of KDMs, the X.509
SubjectName that is found in the certificate shall also be placed in the Recipient element. The Distinguished
Name value in the X509IssuerName element shall be compliant with RFC 2253 [RFC2253].
5.2.2 CompositionPlaylistId
This field 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 [UUID].
This is an informational field 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 field.
5.2.3 ContentTitleText
The ContentTitleText parameter 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 ISO 3166 language
code and indicates the language used. If the language attribute is not present, the content of the field shall be
English.
Page 7 of 17 pages
© ISO 2008 – All rights reserved 7
---------------------- Page: 11 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
Figure 3 – KDMRequiredExtensions Element (Informative)
5.2.4 ContentAuthenticator (Optional)
This field, if present, shall contain a certificate thumbprint (defined in [D-Cinema Digital Certificate]) that
supports authentication of the content as an authorized version (e.g. through a Composition Playlist [CPL]).
This field may be absent at the discretion of the KDM creator (who acts on behalf of the rights owner), but it is
part of the RequiredExtentions elements because compliant receiving equipment is required to understand
and process it when present.
Page 8 of 17 pages
8 © ISO 2008 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
INFORMATIVE NOTES
1 If this field 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 field in the KDM.
2 This field 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.
3 Of course, nothing precludes an exhibitor from knowing the root certificates of specific studios and using those
certificates as part of validating CPL.
5.2.5 AuthorizedDeviceInfo
This item contains three elements as described below.
INFORMATIVE NOTE – This field is intended to support authorization of devices which process keys delivered by the
KDM, or perform other security services related to content protected by those keys. The AuthorizedDeviceInfo field does
not play any role in validating the KDM itself. This field 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, projector) and (b)
allowing a rights owner to limit delivery of his content or keys to specific trustworthy devices.
5.2.5.1 DeviceListIdentifier
This field shall contain a value uniquely identifying a list of trusted equipment. It is a required member of the
AuthorizedDeviceInfo structure.
INFORMATIVE NOTE – This field is an aid to management of device lists and tracking of updates to them.
5.2.5.2 DeviceListDescription (Optional)
The DeviceListDescription parameter, 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 ISO 3166 language code and indicates the
language used. If the language attribute is not present, the content of the field shall be English.
5.2.5.3 DeviceList
The DeviceList item shall contain a set of one or more certificate thumbprints [See D-Cinema Certificate].
INFORMATIVE 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.
5.2.6 ContentKeysNotValidBefore
This field specifies the time before which the content keys contained in this KDM are not valid. The time shall
be in the form of a Universal Coordinated Time timestamp as specified in RFC 3339. Timestamps shall not
include fractional seconds. 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 field 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 field. The time
windows of all content keys shall be the same in the RSA protected blocks.
Page 9 of 17 pages
© ISO 2008 – All rights reserved 9
---------------------- Page: 13 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
5.2.7 ContentKeysNotValidAfter
This field specifies the time after which the content keys contained in this KDM are not valid. The time shall be
in the form of a Universal Coordinated Time timestampas specified in RFC 3339. Timestamps shall not
include fractional seconds. 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 field 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 field. The time
windows of all content keys shall be the same in the RSA protected blocks.
5.2.8 KeyIdList
This field shall contain an unordered list of one or more TypedKeyId elements, which are defined below. This
is an informational field that is a copy of the definitive values that appear in the RSA protected EncryptedKey
structures (see 6.1). It may be ignored by mechanisms that process the EncryptedKey field.
5.2.8.1 KeyId
KeyIds are 128-bit UUIDs that shall be represented in “urn:uuid:” format when they appear as an XML value
[UUID]. The KeyId parameter uniquely identifies the content decryption key. All keys shall be for use with the same
content (identified by the CompositionPlaylistId field). As shown below, it shall be used to identify the cryptographic
key used in encrypting d-cinema assets, as defined by [KLV]. It shall be represented by a UUID [UUID].
5.2.8.2 TypedKeyId
A TypedKeyId is a compound element consisting of a KeyType field 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 5.2.8.1. 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 elemen
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.