SMPTE ST 430-1-2017 D-Cinema Operations - Key Delivery Message.pdf

《SMPTE ST 430-1-2017 D-Cinema Operations - Key Delivery Message.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 430-1-2017 D-Cinema Operations - Key Delivery Message.pdf（18页珍藏版）》请在麦多课文档分享上搜索。

1、 Table of Contents Page Foreword . 2 Intellectual Property 2 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 Unencrypted Information 6 5.1 MessageType . 6 5.2

2、 RequiredExtentions 7 5.2.1 Recipient 7 5.2.2 CompositionPlaylistId . 7 5.2.3 ContentTitleText . 7 5.2.4 ContentAuthenticator (Optical). 8 5.2.5 AuthorizedDeviceInfo . 9 5.2.6 ContentKeysNotValidBefore 9 5.2.7 ContentKeysNotValidAfter . 10 5.2.8 KeyIDList 10 5.2.9 ForensicMarkFlagList (Optical) 11 5

3、.3 NonCriticalExtensions . 12 6 Authenticated and Encrypted Information . 12 6.1 EncryptedKey . 13 6.1.1 KenInfo . 13 6.1.2 CipherData . 13 6.2 EncryptedData . 14 7 Signature Information 14 Annex A Design Features and Security Goals (Informative) 15 Annex B XML Schema for KDM (Normative) 16 Bibliogr

4、aphy (Informative) 18 Page 1 of 17 pages SMPTE ST 430-1:2017 Revision of SMPTE 430-1:2006 SMPTE STANDARD D-Cinema Operations Key Delivery Message Approved January 12, 2017 Copyright 2017 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100

5、SMPTE ST 430-1:2017 Page 2 of 18 pages 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.

6、 SMPTEs Engineering Documents, including Standards, Recommended Practices 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 organ

7、izations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual. SMPTE ST 430-1 was prepared by Technology Committee 21DC. Intellectual Property SMPTE draws attention to the fact that it is claimed that compliance wi

8、th this Standard may involve the use of one or more patents or other intellectual property rights (collectively, “IPR“). The Society takes no position concerning the evidence, validity, or scope of this IPR. Each holder of claimed IPR has assured the Society that it is willing to License all IPR it

9、owns, and any third party IPR it has the right to sublicense, that is essential to the implementation of this Standard to those (Members and non-Members alike) desiring to implement this Standard under reasonable terms and conditions, demonstrably free of discrimination. Each holder of claimed IPR h

10、as filed a statement to such effect with SMPTE. Information may be obtained from the Director, Standards 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 attr

11、ibute is not present, the content of the field shall be English. SMPTE ST 430-1:2017 Page 8 of 18 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)

12、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 equipm

13、ent is required to understand and process it when present. SMPTE ST 430-1:2017 Page 9 of 18 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

14、 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 studi

15、os (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 ne

16、cessarily the thumbprint of the studios 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. Inform

17、ative Note: This field 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 field does not play any role in validating the KDM itself. This fiel

18、d 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 Devi

19、ceListIdentifier 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 (Opti

20、onal) 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 la

21、nguage 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 represe

22、nts 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 th

23、is KDM are not valid. The time shall be 25 characters in the form of a Universal Coordinated Time timestamp as specified in RFC 3339 Time Section 5.6 date-time. Timestamps shall not include fractional seconds (RFC 3339 time-secfrac). Timestamps shall not use Z (Zulu) time zone offset notation. It is

24、 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). SMPTE ST 430-1:2017 Page 10 of 18 pages This is an informational field that is a copy of the definitive value that appears in the RSA protected E

25、ncryptedKey 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.7 ContentKeysNotValidAfter This field specifies the time after which the content keys contained in this KDM are not vali

26、d. The time shall be 25 characters in the form of a Universal Coordinated Time timestamp as specified in RFC 3339 Time Section 5.6 date-time. Timestamps shall not include fractional seconds (RFC 3339 time-secfrac). Timestamps shall not use Z (Zulu) time zone offset notation. It is possible for a sep

27、arate 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

28、 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

29、that appear in the RSA protected EncryptedKey structures (see Section 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

30、identifies the content key. All keys shall be for use with the assets referenced by the Composition Playlist identified by the CompositionPlaylistId field. As shown below, it shall be used to identify the content key used in encrypting d-cinema assets, as defined by KLV. It shall be represented by a

31、 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 m

32、edia decryptor). The KeyID shall be as defined in Section 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

33、-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 URI value “http:/www.s

34、mpte-ra.org/430-1/2006/KDM#kdm-key-type”. Associated with this URI is the following set of key type identifiers: 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.

35、4B “FMIK” Image forensic marking key 46.4D.41.4B “FMAK” Sound forensic marking key SMPTE ST 430-1:2017 Page 11 of 18 pages Informative Note 1: 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

36、 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: Byte String (hexadecimal notation) Character String Des

37、cription 4D.44.58.31 “MDX1“ Aux Data Type 1 key 4D.44.58.32 “MDX2“ Aux Data Type 2 key Informative 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 ADTF), based on the nature of this essence. Specifically

38、, MDX1 is intended to signal that the plaintext essence (potentially forensically marked unless forensic marking is disabled per Section 5.2.9.1) is transmitted without restrictions within the exhibition environment. In contrast, MDX2 is intended to signal that the plaintext essence (potentially for

39、ensically marked unless forensic marking is disabled per Section 5.2.9.1) 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

40、“http:/www.smpte-ra.org/430-1/2017/KDM#mic-key-type-ID“, where ID conforms to the lowercase UUID string representation specified in UUID, shall be associated with the following KeyType value: Byte String (hexadecimal notation) Character String Description 4D.44.4D.4B “MDMK“ MIC key The ID shall be e

41、qual to a KeyId value within the KeyIdList element. Informative Note 3: The MDMK key is intended to define the MICKey (see KLV) to be used in conjunction with the content key identifier by the UUID embedded in the scope attribute. EXAMPLE: MDMK identifies a MIC key associated with the content key wi

42、th KeyId “e5421139-0f4a-445e-bc1f-3018a2a858ab“. 5.2.9 ForensicMarkFlagList (Optional) 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 distinct value. 5.2.9.1 Forensic

43、MarkFlag 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: SMPTE ST 430-1:2017 Page 12 of 1

44、8 pages 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 “MD

45、AK” 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 a

46、nd of KeyType equal to “MDX2“. ID in the table above shall conform to the lowercase UUID string representation specified in UUID and shall be equal to a KeyId value of the key to which the Forensic Mark Flag applies. EXAMPLE: http:/www.smpte-ra.org/430-1/2017/KDM#mrkflg-mdx1-dfc4c132-c318-44fd-a515-

47、d2a8075f4c5a-disable 5.3 NonCriticalExtensions This field is defined in ETM. Informative Note: This element may contain proprietary extensions. Conforming implementations should ignore the contents of this element. 6 Authenticated and Encrypted Information The AuthenticatedPrivate element is normati

48、vely defined in ETM. 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 label for this portion

49、, though 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 and the schema code snippet is illustrated in Figure 4. SMPTE ST 430-1:2017 Page 13 of 18 pages Figure 4 Authenticated and Private Portion of KDM (Informative) A