SMPTE ST 429-6-2006 D-Cinema Packaging MXF Track File Essence Encryption.pdf

《SMPTE ST 429-6-2006 D-Cinema Packaging MXF Track File Essence Encryption.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 429-6-2006 D-Cinema Packaging MXF Track File Essence Encryption.pdf（25页珍藏版）》请在麦多课文档分享上搜索。

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