1、 Table of Contents 1 Scope 3 2 Normative References 3 3 Overview . 4 4 Encrypted Essence Container 5 5 Cryptographic Framework. 5 5.1 Cryptographic Framework Key . 6 5.2 Length . 6 5.3 Context SR 7 6 Cryptographic Context 7 6.1 Cryptographic Context Key . 7 6.2 Length . 8 6.3 Context ID . 8 6.4 Sour
2、ce Essence Container Label . 8 6.5 Cipher Algorithm . 8 6.6 MIC Algorithm . 8 6.7 Cryptographic Key ID 9 7 Encrypted Triplet. 9 7.1 Encrypted Triplet Key 10 7.2 Length . 10 7.3 Cryptographic Context Link. 10 7.4 Plaintext Offset 10 7.5 Source Key 10 7.6 Source Length. 10 7.7 Encrypted Source Value .
3、 11 7.8 TrackFile ID optional . 11 7.9 Sequence Number optional 12 7.10 MIC optional. 12 8 Encrypted Track File Constraints 12 8.1 Encrypted Essence Track . 12 8.2 Cryptographic Framework DM Track 12 8.3 Index Tables 13 9 Reference Decryption Processing Model 13 9.1 Overall Flow 13 9.2 Modules. 14 P
4、age 1 of 25 pages SMPTE 429-6-2006 SMPTE STANDARD D-Cinema Packaging MXF Track File Essence Encryption 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 429-6-2006 Page 2 of 25 pages 10 Label
5、 and Key Structures 18 10.1 Encrypted Essence Container Label18 10.2 Cryptographic Framework Label 19 10.3 Cryptographic Framework Key.20 10.4 Cryptographic Context Key.21 10.5 Encrypted Triplet Key .22 10.6 AES-CBC with 128-bit Key UL .22 10.7 HMAC-SHA1 with 128-bit Key UL 23 Annex A Security Prope
6、rties (Informative) 24 Annex B Bibliography (Informative).25 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 countr
7、ies on six continents. 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 stan
8、dards-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. Proposed SMPTE Standard 429-6 was prepared by Technology Committee DC28. SMPTE 429-6-2006 Page 3 of 25 pages 1 Scope Th
9、is standard defines the syntax of encrypted D-Cinema non-interleaved MXF frame-wrapped track files and specifies a matching reference decryption model. It uses the AES cipher algorithm for essence encryption and, optionally, the HMAC-SHA1 algorithm for essence integrity. The D-Cinema track file form
10、at is designed to carry D-Cinema essence for distribution to exhibition sites and is specified in the Sound and Picture Track File specification. This standard assumes that the cryptographic keys necessary to decrypt and verify the integrity of encrypted Track Files will be available upon demand. Mo
11、re precisely, it does not specify the fashion with which cryptographic keys and usage rights are managed across D-Cinema distribution and exhibition environments. In addition, this document does not address, but does not preclude, the use of watermarking, fingerprinting or other security techniques
12、to provide additional protection. The scope is limited to D-Cinema and does not define a generic MXF encryption framework. 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
13、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. SMPTE 336M-2001, Television Data Encoding Protocol Using Key-Leng
14、th-Value SMPTE 377M-2004, Television Material Exchange Format (MXF) File Format Specification SMPTE 429-3-2006, D-Cinema Packaging Sound and Picture Track File IETF 2898 (September 2000). PKCS #5: Password-Based Cryptography Specification Version 2.0. IETF 2104 (February 1997). HMAC: Keyed-Hashing f
15、or Message Authentication National Institute of Standards and Technology (December 1, 2001). Recommendation for Block Cipher Modes of Operation Methods and Techniques (SP 800-38A). National Institute of Standards and Technology, FIPS 197 (November 26, 2001). Advanced Encryption Standard (AES). Natio
16、nal Institute of Standards and Technology, FIPS PUB 186-2 (+Change Notice 1) (January 27, 2000). Digital Signature Standard (DSS). SMPTE 429-6-2006 Page 4 of 25 pages 3 Overview This specification defines the encryption of the sensitive essence information contained in D-Cinema Track Files using the
17、 Advanced Encryption Standard (AES) cipher algorithm in Cipher Block Chaining (CBC) mode as defined in NIST SP 800-38A. As an option, it also allows the integrity of the same essence to be verified using the HMAC-SHA1 algorithm. More specifically this specification allows any individual track contai
18、ned within a plaintext Track File to be encrypted using a single cryptographic key. The resulting encrypted Track File is extremely similar to a plaintext Track File, which is itself a constrained version of the MXF OP-ATOM operational pattern1. It differs in the following three areas. First, the Es
19、sence Container Label associated with the plaintext track is replaced by an Encrypted Essence Container Label. The replacement Label signals the presence of encrypted essence and allows any receiving MXF application which cannot perform decryption to “fail fast” as described in SMPTE EG 41. The Encr
20、ypted Essence Container is defined in Section 4. Second, cryptographic information associated with the encrypted track as a whole is inserted in the MXF header metadata as a Cryptographic Framework. The Cryptographic Framework contains a link to the single cryptographic key used to encrypt the essen
21、ce track. It also lists the algorithms necessary to process the encrypted essence and contains the original Essence Container Label. The latter allows implementations to determine the nature of the plaintext essence without further processing. The Cryptographic Framework is defined in Sections 5 and
22、 5.1. K LCryptographicinformationVK L VK L E(V)encryption / decryptionCryptographicinformation (opt)Figure 1 Correspondence between Source and Encrypted Triplets. Red hatching depicts the encrypted portion of the Encrypted Triplet; other items are left as plaintext. Only the value item of Source Tri
23、plet is encrypted, allowing the essence information to be encrypted prior to wrapping. See Section 7 for a description of the cryptographic information associated with each Encrypted Triplet. Third, the plaintext Triplets containing essence information have been replaced by Encrypted Triplets see SM
24、PTE 336M for details on KLV (Key-Length-Value) coding. Each Encrypted Triplet, is designed to be processed independently, allowing decryption to start anywhere within the encrypted Track File. Figure 1 illustrates the correspondence between a plaintext and an Encrypted Triplet2. The value V of a sou
25、rce plaintext KLV Triplet is first encrypted to yield E(V). The encrypted value E(V), along with K and L, is wrapped in a KLV Encrypted Triplet. K is a unique label common to all Encrypted Triplets, independent of their content. L refers to the full length of V. V consists of K, L and E(V) from the
26、source Triplet as well as cryptographic information specific to the Encrypted Triplet. This cryptographic information includes, for instance, the initialization vector used in generating E(V) and the message integrity code (MIC) used to verify the integrity of the Triplet. The structure of Encrypted
27、 Triplets is detailed in Section 7. 1This specification assumes that the reader is familiar with the MXF and Track File formats. 2This specification does not require the essence to be wrapped in a KLV Triplet to enable its encryption. In other words, essence may be encrypted prior to being wrapped i
28、n an Encrypted Triplet. SMPTE 429-6-2006 Page 5 of 25 pages 4 Encrypted Essence Container In order to signal the presence of encrypted tracks, the Essence Container Label of any track containing Encrypted Triplets shall be replaced by the Encrypted Essence Container Label listed in Table 1. This rep
29、lacement shall occur both in the Preface set and in the Partition Pack. The Essence Container Label in the File Descriptor (SMPTE 377M) shall however remain unchanged to identify the underlying plaintext essence. Table 1 Encrypted Essence Container Label (See Section 10.1 for the complete structure
30、of the Label.) 060e2b34 04010107 0d010301 020b0100 5 Cryptographic Framework As depicted in Figure 2, the Cryptographic Context shall be carried in encrypted Track Files as an MXF Descriptive Metadata (DM) Framework3. Specifically, Track Files may contain one or more Descriptive Metadata Tracks cont
31、aining each a single Cryptographic Framework4. The Cryptographic Framework structure is detailed in Table 3. EssencePartition PackHeader MetadataSource PackageDM Track (Static)DM SequenceDM SegmentCryptographic FrameworkCryptographic ContextEssence ContainerEncrypted TripletTrackreference by UIDnref
32、erence by UID1reference by UID1reference by UID1reference by Context ID1CryptographicKeylinkby Track Numberlink by ContextIDlink byCryptographicKey ID1containsFigure 2 Cryptographic Framework The DM Track is static since in encrypted Track Files a single cryptographic key is associated with any give
33、n track. Each Encrypted Triplet within a Track must refer to the same Cryptographic Context. 3DM frameworks are defined in SMPTE 377M under Plug-in Mechanism and follow the principles described in SMPTE EG 42. 4(Informative) The Cryptographic Framework is specified as a subclass of the DM Framework
34、abstract superclass (see SMPTE 380M). SMPTE 429-6-2006 Page 6 of 25 pages The Cryptographic Framework forms a Cryptographic DM Scheme. The Cryptographic Framework Label listed in Table 2 shall be included in the Preface set as the identifier of the Cryptographic DM Scheme. Table 2 Cryptographic Fram
35、ework Label (See Section 10.2 for the complete structure of the Label.) 060e2b34 04010107 0d010401 02010100 The Cryptographic Framework does not contain actual cryptographic information and instead references a single Cryptographic Context, which is defined in Section 6. Its purpose is to provide co
36、mpatibility with other MXF Descriptive Metadata, allowing the Cryptographic Context to be exposed in a consistent manner. The following defines the items contained in the Cryptographic Framework Set. With the exception of InstanceID and GenerationUID, which are already defined in SMPTE 377M, all Loc
37、al Tag values for the descriptor shall be dynamically allocated as defined in SMPTE 377M section 8.2.2 (Local tag values). The translation from each dynamically allocated local tag value to its full UL value can be found using the Primer Pack mechanism defined in SMPTE 377M section 8.2 (Primer Pack)
38、. Table 3 Cryptographic Framework Set (Lengths are in bytes) Item Name Type Len UL Req ? Meaning Cryptographic Framework Key Set Key 16 060e2b34 02530101 0d010401 02010000 Req Defines the Cryptographic Framework Set Length BER Length var n/a Req Set length InstanceID UUID 16 060e2b34 01010101 010115
39、02 00000000 Req Unique identifier for the framework. GenerationUID UUID 16 060e2b34 01010102 05200701 08000000 Opt Optional Generation Identifier Context SR Strong Ref (Descrip- tive Set) 16 060e2b34 01010109 06010104 020d0000 Req Strong reference to the associate Cryptographic Context (see Section
40、6) 5.1 Cryptographic Framework Key The Cryptographic Framework Key uniquely identifies the Set as a Cryptographic Framework being subject to this specification. Table 4 Cryptographic Framework Key (See Section 10.3 for the complete structure of the Key.) 060e2b34 02530101 0d010401 02010000 5.2 Lengt
41、h The Length item specifies the length of the Cryptographic Framework encoded using Basic Encoding Rules (BER) per SMPTE 336M. SMPTE 429-6-2006 Page 7 of 25 pages 5.3 Context SR The Context SR item contains a strong reference to the Cryptographic Context associated with the Cryptographic Framework.
42、6 Cryptographic Context The Cryptographic Context Set5contains cryptographic information that applies to encrypted essence tracks as a whole. The following defines the items contained in the Cryptographic Context Set. With the exception of InstanceID and GenerationUID, which are already defined in S
43、MPTE 377M, all Local Tag values for the descriptor shall be dynamically allocated as defined in SMPTE 377M section 8.2.2 (Local tag values). The translation from each dynamically allocated local tag value to its full UL value can be found using the Primer Pack mechanism defined in SMPTE 377M section
44、 8.2 (Primer Pack). Table 5 Cryptographic Context Set (Lengths are in bytes) Item Name Type Len UL Req ? Meaning Cryptographic Context Key Set Key 16 060e2b34 02530101 0d010401 02020000 Req Defines the Cryptographic Context Set Length BER Length var n/a Req Set length InstanceID UUID 16 060e2b34 010
45、10101 01011502 00000000 Req Unique identifier for the context used by Cryptographic Framework to refer to the Context. GenerationUID UUID 16 060e2b34 01010102 05200701 08000000 Opt Optional Generation Identifier Context ID UUID 16 060e2b34 01010109 01011511 00000000 Req Unique identifier used by Enc
46、rypted Triplets to refer to the Context. Source Essence Container Label UL 16 060e2b34 01010109 06010102 02000000 Req Essence Container Label for the source essence, prior to encryption Cipher Algorithm UL or zero 16 060e2b34 01010109 02090301 01000000 Req Algorithm used for Triplet encryption, if a
47、ny. MIC Algorithm UL or zero 16 060e2b34 01010109 02090302 01000000 Req Algorithm used for Triplet integrity, if any. Cryptographic Key ID UUID 16 060e2b34 01010109 02090301 02000000 Req Unique identifier for the cryptographic key. 6.1 Cryptographic Context Key The Cryptographic Context Key item uni
48、quely identifies the Set as a Cryptographic Context being subject to this specification. 5(Informative) The Cryptographic Context is a subclass of an InterchangeObject (see SMPTE 380M Annex C) SMPTE 429-6-2006 Page 8 of 25 pages Table 6 Cryptographic Context Key (See Section 10.4 for the complete st
49、ructure of the Key.) 060e2b34 02530101 0d010401 02020000 6.2 Length The Length item specifies the length of the Cryptographic Context value encoded using Basic Encoding Rules (BER) per SMPTE 336M. 6.3 Context ID The Context ID item uniquely identifies this particular Cryptographic Context. It is represented by a UUID. This value is referenced by Encrypted Triplets. 6.4 Source Essence Container Label The Source Essence Container Label item contains the original Label of the Essence Container to which the Encrypted Triplet b
