1、 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 Receip
2、t . 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 Authent
3、icated 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 Page 1 of 17 pag
4、es SMPTE 430-1-2006 Copyright 2006 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved October 3, 2006 SMPTE STANDARD D-Cinema Operations Key Delivery Message SMPTE 430-1-2006 Page 2 of 17 pages Foreword SMPTE (the Society of Moti
5、on 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. SMPTEs Engineering Documents, including Standards, Recommended Practices
6、and Engineering Guidelines, are prepared by SMPTEs 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 draf
7、ted in accordance with the rules given in Part XIII of its Administrative practices. SMPTE Standard 430-1 was prepared by Technology Committee DC28. SMPTE 430-1-2006 Page 3 of 17 pages 1 Scope This specification defines a “Key Delivery Message” (KDM) for use in Digital Cinema (D-Cinema) systems. The
8、 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 Lis
9、t (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 ab
10、out 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
11、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,
12、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 Oper
13、ations 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
14、 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 standar
15、d. 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
16、. HMAC-SHA-1: Hash-based Message Authentication Code based on SHA-1. See FIPS-198. IETF: Internet Engineering Task Force standards group. SMPTE 430-1-2006 Page 4 of 17 pages IP: Internet Protocol. An IETF standard. ISO: International Standards Organization. KEK: Key Encrypting Key LE: Link Encrypter
17、. 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
18、-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:
19、 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 Th
20、is 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 requi
21、re 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 st
22、andard. 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 recipients private key. Having this key, the legitimate recipient may unlock and validate both encrypted and plain text information contents carried. As is exp
23、lained 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
24、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
25、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 secur
26、e memory. SMPTE 430-1-2006 Page 5 of 17 pages RecipientPublic KeyContent Keyse.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 co
27、ntent of the field shall be English. SMPTE 430-1-2006 Page 8 of 17 pages 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
28、 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 a
29、nd process it when present. SMPTE 430-1-2006 Page 9 of 17 pages 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 sho
30、uld 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 t
31、he 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 stu
32、dios 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 t
33、o 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)
34、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 un
35、iquely 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 pres
36、ent, 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 l
37、anguage 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 c
38、onnection 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
39、 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 th
40、at 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. SMPTE 430-1-2006 Page 10 of 17 pages 5.2.7 ContentKe
41、ysNotValidAfter 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 provi
42、de 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
43、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
44、 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 dec
45、ryption 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 TypedKe
46、yId 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 d
47、efined 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 element shall have a
48、n 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 URI value “http:/www.smpte-ra.org/430-1/2006/KDM#kdm-key-type”. Associ
49、ated with this URI is the following set of key type identifiers: INFORMATIVE NOTE Receiving equipment is contemplated to use the information in this field 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. 5.2.9 ForensicMarkFlagList (Optional) When present, this element shall contain an unordered list of one or more ForensicMarkFlag elements, which a
