Track File Encryption

2 Conformance🔗

Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.

All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as "Informative" or individual paragraphs that start with "Note:"

The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.

The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.

The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.

The keyword "reserved" indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword "forbidden" indicates "reserved" and in addition indicates that the provision will never be defined in the future.

A conformant implementation according to this document is one that includes all mandatory provisions ("shall") and, if implemented, all recommended provisions ("should") as described. A conformant implementation need not implement optional provisions ("may") and need not implement them as described.

Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; then formal languages; then figures; and then any other language forms.

5 Overview🔗

A Track File is an indexed, randomly-accessible MXF container for a single clip of a single essence track, such as those specified in SMPTE ST 429-3 or SMPTE ST 2067-5.

This specification defines the encryption of the sensitive essence information contained in Track Files using the 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 contained 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. It differs in the following three areas.

First, the Essence 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”. The Encrypted Essence Container is defined in Clause 6.

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 essence 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 Clause 7.

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 Triplet is encrypted, allowing the essence information to be encrypted prior to wrapping. See Clause 9 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 SMPTE ST 336 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 Triplet[1]. The value V of a source plaintext KLV Triplet is first encrypted to yield E(V). The encrypted value E(V), along with K and L, is wrapped in a K’L’V’ 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 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 Triplets is detailed in Clause 9.

Table 1 –⁠ Encrypted Essence Container Label (See 12.1 for the complete structure of the Label.)
Clip or Frame Wrapped (see note below)	`060e2b34 04010107 0d010301 020b0100`
Clip Wrapped	`060e2b34 0401010d 0d010301 020b0200`
Frame Wrapped	`060e2b34 0401010d 0d010301 020b0300`

7 Cryptographic Framework🔗

7.1 General🔗

As depicted in Figure 2, the Cryptographic Context shall be carried in encrypted Track Files as an MXF Descriptive Metadata (DM) Framework. Specifically, Track Files may contain one or more Descriptive Metadata Tracks containing each a single Cryptographic Framework. The Cryptographic Framework structure is detailed in Table 3.

NOTE 1 —⁠ DM frameworks are defined in SMPTE ST 377-1 under Plug-in Mechanism and follow the principles described in SMPTE EG 42.

NOTE 2 —⁠ The Cryptographic Framework is specified as a subclass of the DM Framework abstract superclass (see SMPTE ST 380).

Figure 2 –⁠ Cryptographic Framework. The DM Track is static since in encrypted Track Files a single cryptographic key is associated with any given track. Each Encrypted Triplet within a Track must refer to the same Cryptographic Context.

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 Framework Label (See 12.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 Clause 8. Its purpose is to provide compatibility 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 ST 377-1, all Local Tag values for the descriptor shall be dynamically allocated as defined in SMPTE ST 377-1. 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 ST 377-1.

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 01011502 00000000`	Req	Unique identifier for the framework.
GenerationUID	UUID	16	`060e2b34 01010102 05200701 08000000`	Opt	Optional Generation Identifier
Context SR	Strong Ref (Descriptive Set)	16	`060e2b34 01010109 06010104 020d0000`	Req	Strong reference to the associated Cryptographic Context (see Clause 8)

7.2 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 12.3 for the complete structure of the Key.)
`060e2b34 02530101 0d010401 02010000`

7.3 Length🔗

The Length item specifies the length of the Cryptographic Framework encoded using Basic Encoding Rules (BER) per SMPTE ST 336.

7.4 Context SR🔗

The Context SR item contains a strong reference to the Cryptographic Context associated with the Cryptographic Framework.

8 Cryptographic Context🔗

8.1 General🔗

The Cryptographic Context Set contains 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 SMPTE ST 377-1, all Local Tag values for the descriptor shall be dynamically allocated as defined in SMPTE ST 377-1. 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 ST 377-1.

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 01010101 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 Encrypted 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 any.
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.

NOTE —⁠ The Cryptographic Context is a subclass of an InterchangeObject (see SMPTE ST 380).

8.2 Cryptographic Context Key🔗

The Cryptographic Context Key item uniquely identifies the Set as a Cryptographic Context being subject to this specification.

Table 6 –⁠ Cryptographic Context Key (See 12.4 for the complete structure of the Key.)
`060e2b34 02530101 0d010401 02020000`

8.3 Length🔗

The Length item specifies the length of the Cryptographic Context value encoded using Basic Encoding Rules (BER) per SMPTE ST 336.

8.4 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.

8.5 Source Essence Container Label🔗

The Source Essence Container Label item contains the original Label of the Essence Container to which the Encrypted Triplet belongs. This allows the type of essence contained in the Encrypted Container to be readily determined.

8.6 Cipher Algorithm🔗

The Cipher Algorithm ID item identifies the algorithm and mode used to encrypt the Encrypted Triplets associated with this Cryptographic Context. It shall contain one of the values listed in Table 7.

Table 7 –⁠ Cipher Algorithms
Description	Value
No cipher algorithm used.	`00000000 00000000 00000000 00000000`
AES-CBC with 128-bit key.	`060e2b34 04010107 02090201 01000000`

The first row of Table 7 is a special value that shall be used to indicate that no cipher algorithm is necessary to process the Encrypted Triplets associated with the Cryptographic Context. The second row identifies the sole permitted value of the cipher algorithm — 12.6 defines the complete structure of this label.

8.7 MIC Algorithm🔗

The MIC Algorithm ID item identifies the algorithm used to compute the (optional) message integrity code contained in the Encrypted Triplets associated with this Cryptographic Context. It shall contain one of the values listed in Table 8.

Table 8 –⁠ Message Integrity Code Algorithms
Description	Value
No MIC algorithm used.	00000000 00000000 00000000 00000000
HMAC-SHA1 with 128-bit key.	060e2b34 04010107 02090202 01000000

The first row of Table 8 is a special value that shall be used to indicate that no MIC algorithm is necessary to process the Encrypted Triplets associated with the Cryptographic Context. The second row identifies the sole permitted value of the MIC algorithm — 12.7 defines the complete structure of this label.

8.8 Cryptographic Key ID🔗

The Cryptographic Key ID item uniquely identifies the cryptographic key used as input to the cipher and message authentication code algorithms applied to Encrypted Triplets. It shall be encoded as a UUID. See 11.2 for a description of its use.

9 Encrypted Triplet🔗

9.1 General🔗

The Encrypted Triplet Variable Length Pack, shown in Table 9, contains both encrypted data and cryptographic information specific to the Triplet. As a Variable Length Pack, each individual item in the Value field comprises a Length field and the individual item value. Byte 6 of the Key value (04h) defines that the length field for each individual item is BER short or long form encoded in accordance with SMPTE ST 336. All items in a pack are required. Any item labeled Opt means that the value of the Length-Value pair is not present and therefore the Length is zero.

Table 9 –⁠ Encrypted Triplet Variable Length Pack
Item Name	Type	Len	UL	Req ?	Meaning
Encrypted Triplet Key	Pack Key	16	`060e2b34 02040101 0d010301 027e0100`	Req	Defines the Encrypted Triplet Variable Length Pack
Length	BER Length	var	n/a	Req	Pack length
Cryptographic Context Link	UUID	16	`060e2b34 01010109 06010106 03000000`	Req	Link to the Cryptographic Context associated with this Triplet (see Clause 8)
Plaintext Offset	UInt64	8	`060e2b34 01010109 06090201 03000000`	Req	Offset within the source at which encryption starts
Source Key	Key	16	`060e2b34 01010109 06010102 03000000`	Req	Key of the source Triplet.
Source Length	UInt64	8	`060e2b34 01010109 04061002 00000000`	Req	Length of the value of the source Triplet
Encrypted Source Value	Array of Bytes	var	`060e2b34 01010109 02090301 03000000`	Req	Encrypted Source value starting at Plaintext Offset
TrackFile ID	UUID	16	`060e2b34 01010109 06010106 02000000`	Opt	Identifies the Track File containing this Triplet.
Sequence Number	UInt64	8	`060e2b34 01010109 06100500 00000000`	Opt	Sequence number of this Triplet within the Track File
MIC	Array of Bytes	20	`060e2b34 01010109 02090302 02000000`	Opt	Keyed Hashing for Message Authentication (HMAC)

9.2 Encrypted Triplet Key🔗

The Encrypted Triplet Key item uniquely identifies the Triplet as a Triplet being subject to this specification.

Table 10 –⁠ Encrypted Triplet Key (See 12.5 for the complete structure of the Key.)
`060e2b34 02040101 0d010301 027e0100`

9.3 Length🔗

The Length item specifies the length of the value of the Encrypted Triplet encoded using Basic Encoding Rules (BER) per SMPTE ST 336.

9.4 Cryptographic Context Link🔗

The Cryptographic Context Link item is a link to the Cryptographic Context where the cryptographic information used to create the Encrypted Source Value property is defined. Specifically it contains a UUID, which is the InstanceID of the target Cryptographic Context.

9.5 Plaintext Offset🔗

The Plaintext Offset item shall specify, in bytes, the offset within the Source Value where first byte of encryption started. The Plaintext Offset value shall be less than or equal to the Source Length. As detailed in 11.3.4, implementations processing the Encrypted Track File shall handle any legal value of this parameter.

The purpose of the Plaintext Offset item is to allow some header portion of the Source Value to remain in the clear. The selection of appropriate values for the Plaintext Offset will likely depend on the kind of essence contained in the Encrypted Track File, and is hence beyond the scope of this standard.

9.6 Source Key🔗

The Source Key item contains the unmodified Key of the source plaintext Triplet. Note that this Key refers to the identifier of a Triplet, not a cryptographic key.

9.7 Source Length🔗

The Source Length item contains the length of the source plaintext Triplet encoded as a UInt64 integer. It shall be used in conjunction with the Length item to determine the amount of padding, in bytes, introduced by the encryption process.

9.8 Encrypted Source Value🔗

Figure 3 –⁠ Encrypted Source Value structure.

The overlay red hatches indicate encryption. The Initialization Vector (IV), Check Value (C) and Padding (P) values are integral to the Encrypted Source Value item and, as such, are not independent items within the Encrypted Triplet Pack. The Encrypted Source Value corresponds to the hatched portion of Encrypted Triplet depicted in Figure 1.

As shown in Figure 3, the Encrypted Source Value contains the encrypted source value of the Source Triplet, including Initialization Vector, Check Value and Padding values. It is divided into plaintext and encrypted portions. The plaintext portion contains a 16-byte Initialization Vector (IV) and the first (Plaintext Offset) bytes of the source value[2]. The encrypted portion contains a 16-byte Check Value (C) and the last (Source Length - Plaintext Offset) bytes of the Source Value followed by Padding (P). The size (Padding Length) of the latter is at least one and must be chosen so that (Source Length - Plaintext Offset + Padding Length) is a multiple of 16 bytes, the block size of the AES-128 algorithm. The Padding bytes shall be set in accordance with the 16-byte block mode of the RC5-CBC-Pad encryption scheme specified at IETF RFC 2898. The encryption process shall use the algorithm and cryptographic key found in the Cipher Algorithm and Cryptographic Key ID items, respectively, of the Cryptographic Context with which the Encrypted Triplet is associated. The Check Value shall consist of the 16-byte value listed in Table 11, and may be used to verify that the correct cryptographic key is being applied. In other words, upon decryption of the Encrypted Triplet, the processing application may verify that the proper cryptographic key was used by comparing the Check Value recovered with that of Table 11.

Table 11 –⁠ Encrypted Triplet Check Value (hexadecimal notation in network byte order)
`4348554B 4348554B 4348554B 4348554B`

The IV should be chosen randomly for each Encrypted Triplet. The IV shall not be based on an easily predictable sequence.

9.9 TrackFile ID [optional]🔗

The optional TrackFile ID item uniquely identifies the Track File to which the Encrypted Triplet belongs. It shall be present if and only if the MIC item is present. This item is a UUID, and shall have the same value for all Encrypted Triplets within a given Track File.

NOTE —⁠ Use of this identifier is described under Package IDs in SMPTE ST 429-3; SMPTE RP 205 gives guidance on assignment of UMIDs.

If no TrackFile ID is associated with the Encrypted Triplet, then the length of the TrackFile ID item shall be 0.

9.10 Sequence Number [optional]🔗

The optional Sequence Number item shall contain an integer which increments by one for each successive Encrypted Triplet contained in a given essence track. It is present if and only if the MIC item is present. The Sequence Number of the first Encrypted Triplet in a given essence track should be 1.

If no Sequence Number is associated with the Encrypted Triplet, then the length of the Sequence Number item shall be 0.

9.11 MIC [optional]🔗

The optional MIC item contains a message integrity code computed using a MIC algorithm that uses a cryptographic key (the MIC Key). As with the Cipher Key, the method by which the MIC Key is obtained is left to applications of this document.

If the MIC item is present, the TrackFile ID item and the Sequence Number item shall also be present. The MIC algorithm shall be applied to every byte preceding the MIC item starting at the first byte of the Encrypted Source Value item (i.e. the first byte of the IV value). Length fields of TrackFileID, SequenceNumber, and MIC shall be included.

If no MIC is associated with the Encrypted Triplet, then the length of the MIC item shall be 0.

Annex B specifies a method to derive the MIC Key from the Cipher Key. This method was previously required by the Reference Decryption Processing Model specified at Clause 11, but is no longer so required.

NOTE —⁠ SMPTE ST 430-1 specifies a method to carry a MIC Key in the KDM, using the "MDMK" key type.

10 Encrypted Track File Constraints🔗

10.1 Encrypted Essence Track🔗

A single cryptographic key, and hence Cryptographic Context, shall be used to encrypt any given essence track. In other words, all Encrypted Triplets associated with a given encrypted track shall refer to the same Cryptographic Context.

10.2 Cryptographic Framework DM Track🔗

Track Files may contain one or more DM Tracks in the MXF File Package which describe the Track File. Since the same cryptographic key is used to encrypt all Encrypted Triplets within a given encrypted essence track, the Cryptographic Framework DM Track shall be a Static DM Track (see SMPTE ST 377-1).

Each Cryptographic Framework DM Track shall contain a DM Sequence comprising one DMSegment, which shall contain a strong reference to a Cryptographic Framework (see SMPTE ST 377-1).

Linking between the Cryptographic Framework DM Tracks and the Essence Track shall be made using the TrackIDs property of the DM Segment contained within the DM Track.

In most cases, Files contain only a single Essence Track, and thus the TrackIDs property may safely be omitted. If applications require separate Cryptographic Contexts for separately encrypted tracks, metadata or essence, TrackIDs shall be specified.

10.3 Index Tables🔗

In a plaintext Track File, each Index Table entry locates a Triplet. Similarly, in an encrypted Track File, each Index Table entry shall point to an Encrypted Triplet wrapping a single Triplet.

NOTE —⁠ As Index Tables for encrypted and plaintext Track Files point into different data streams, their contents can differ. KLV Fill packets can be used, as defined in SMPTE ST 377-1, to support any KAG requirements and/or allow for identical Index Tables in encrypted and plaintext representations, or Index Tables using a non-zero EditUnitByteCount value (see SMPTE ST 377-1 at Index Table Segments).

11 Reference Decryption Processing Model🔗

11.1 General🔗

This section specifies the complete decryption processing model for encrypted Track Files. More specifically it defines a reference process by which a valid encrypted Track File is mapped into a valid plaintext Track File. It does not however define subsequent operations, such as rendering the underlying essence.

The objective of a fully-specified decryption model is to alleviate the need for a formal specification of the encryption process and facilitate compliance testing. This is conceptually modeled on the exact match approach taken by the Advanced Video Coding video compression standard as specified at Rec. ITU-T H.264 | ISO/IEC 14496-10, which defines a single correct bit pattern at the output of a compliant decoding process. The decryption model itself does not force the output to be a valid Track File. It is the responsibility of the creator of the encrypted Track File to produce an input file which will result in a valid plaintext Track File when decrypted – assuming all relevant cryptographic keys are available. To be considered valid, an encrypted Track File must meet this requirement, in addition to complying with other parts of the specification.

If the input file is not a valid encrypted Track File, then the decryption may terminate on an unrecoverable error. In fact, even if the input is a valid encrypted Track File, the lack of proper decryption keys will disrupt the decryption process, effectively resulting in an error status. The decryption model will report encountered errors but implementation behavior of under such conditions is left to the application.

11.2 Overall Flow🔗

This section describes the overall flow of information in the decryption model. The decryption model is divided into modules which perform specific functions using specific inputs and outputs. Some of these modules are weakly coupled and could accommodate different algorithms or specialized needs that are outside the scope of this standard.

In Figure 5, the Cryptographic Key ID is provided to the Key Management module and its value is used to identify the Cipher Key required to decrypt the encrypted triplets and the MIC Key used to verify triplet integrity. The definition of the Key Management module is beyond the scope of this standard.

Figure 5 –⁠ Decryption Process Flowchart. The Key Management module is outside the scope of this specification and shown here only for reference.

11.3 Modules🔗

11.3.1 Overview🔗

The reference processing model contains a number of modules, each with specific interfaces. This section describes these modules in detail.

11.3.3 Encrypted Triplet Integrity Module🔗

If the optional MIC item is present in the Encrypted Triplet, the Encrypted Triplet Integrity module may be used to verify the integrity of the encrypted source value and MIC items of the Encrypted Triplet. As depicted in Figure 7, it takes as input a single Encrypted Triplet and cryptographic key, and produces as output the same Encrypted Triplet and an error status code. The value of the latter indicates whether the integrity check succeeded. The module carries no state information between successive Encrypted Triplets, i.e. it is memory-less.

NOTE —⁠ Elements of the MIC may be used to detect duplicated, missing, or reordered Encrypted Triplets as noted in Annex A; however this function is not included in the Reference Processing Model.

Figure 7 –⁠ Encrypted Triplet Integrity Module.

The module shall operate using the sole algorithm defined in 8.7, i.e. the HMAC-SHA1 algorithm. Given an input Encrypted Triplet, the module shall create its output Encrypted Triplet and Error status according to the following rules.

The output Encrypted Triplet shall be identical to the input Encrypted Triplet.
If the input Triplet is not encrypted (i.e. the K item is not the Encrypted Triplet Key in Table 10), or if the optional MIC item is not present, no other processing shall occur. If the input Triplet is encrypted and the MIC item is present, the rules below shall apply.
Using the input cryptographic key, the HMAC-SHA1 algorithm shall be applied to the concatenation of every byte preceding the MIC item starting at the first byte of the Encrypted Source Value item. The result of this computation is compared with the MIC item of the Encrypted Triplet. If the two differ, the integrity check has failed and an error status shall be returned.

11.3.4 Encrypted Triplet Decryption Module🔗

The core decryption operations, e.g. executing an AES block decryption, occur in the Encrypted Triplet Decryption module. As depicted in Figure 8, the latter takes as input a single Triplet and cryptographic key, and produces as output a single Triplet and an error status code as output. The module carries no state information from one KLV Triplet to the next, i.e. it is memory-less.

Figure 8 –⁠ Encrypted Triplet Decryption Module.

The module shall operate using the sole algorithm defined in 8.5, i.e. AES-128 in CBC mode, as specified in NIST FIPS 197 and NIST SP 800-38A. Given an input Encrypted Triplet, the module shall create its output KLV Triplet according to the following rules, also illustrated in Figure 9.

If the input Triplet is not encrypted (i.e. the K item is not the Encrypted Triplet Key of Table 10), the output Triplet shall be set equal to the input Triplet and no other processing shall occur. If the input Triplet is encrypted, the rules below shall apply.
The output K item shall be equal to the Source Key item of the input Encrypted Triplet.
The output L item shall be equal to the Source Length item of the input Encrypted Triplet.
If the Plaintext Offset item is equal to the output L item (i.e., there is no encrypted portion of the essence) then the first 32 bytes of the Encrypted Source Value item shall be ignored and the following L bytes copied to the output V item, and no other processing shall occur. If the Plaintext Offset does not equal L, the following steps shall apply.
The first 16 bytes (in network byte order) of the Encrypted Source Value item found in the input Encrypted Triplet shall be used as the Initialization Vector used by the CBC mode.
The next 16 bytes of the Encrypted Source Value item shall be processed according to AES-128 in CBC mode. The 16-byte output block shall be equal to the Check Value of Table 11; if not an error status shall be returned and no Triplet is output.
The next (Plaintext Offset) bytes of the Encrypted Source Value item shall be copied to the beginning of output V item unchanged, i.e. as plaintext. If (Plaintext Offset) is larger than the output L, then an error status shall be returned and no Triplet shall be output.
The remaining length of the Encrypted Source Value input field must be a multiple of 16 bytes – the block size of AES-128. If not, an error status shall be returned and no Triplet shall be output.
Subsequent groups of 16 bytes shall be processed as cipher blocks according to AES-128 in CBC mode, using the Cryptographic Key input.
The first (L - Plaintext Offset) bytes produced by this process shall be copied to the output V item. If there have not been enough ciphertext blocks to generate (L - Plaintext Offset) bytes, then an error status shall be returned and no Triplet shall be output. This step removes the cryptographic padding that was added during encryption to make the AES input a multiple of 16 bytes long. Notice that the values of the padding bytes are specified but not checked.

Figure 9 –⁠ Encrypted Triplet Decryption process.

11.3.5 Index Table Generation Module🔗

Figure 10 –⁠ Index Table Generation Module.

The Index Table Generation module conceptually operates in two phases, namely operational and post-operational phases. In the operational phase, the plaintext triplets shall be passed through unmodified while positional information is extracted. In the post-operational phase, the module outputs an index table as defined in 11.3.5.

12 Label and Key Structures🔗

12.1 Encrypted Essence Container Label🔗

Table 12 –⁠ Encrypted Essence Container Label
Byte No.	Description	Value (hex)	Meaning
Bytes 1-12 of this label are defined by the essence container label SMPTE ST 379-1.
13	Essence Container Kind	02h	MXF Generic Container
14	Mapping Kind	0Bh	Encrypted Essence Container
15	Locally Defined	01h	Clip or Frame Wrapped
		02h	Clip Wrapped
		03h	Frame Wrapped
16	Reserved	00h

12.2 Cryptographic Framework Label🔗

Table 13 –⁠ Cryptographic Framework Label
Byte No.	Description	Value (hex)	Meaning
Bytes 1-12 of this label are defined for MXF descriptive metadata schemes SMPTE ST 377-1
13	Scheme Kind	02h	Cryptographic DM Scheme
14	Scheme Designator	01h	Cryptographic Scheme version 1
15	Scheme Designator	01h	Encrypted Track File Cryptographic Framework
16	Reserved	00h

12.3 Cryptographic Framework Key🔗

Table 14 –⁠ Cryptographic Framework Key
Byte No.	Description	Value (hex)	Meaning
Bytes 1-12 of this key are specified for structural metadata sets in SMPTE ST 377-1
13	Scheme Kind	02h	Cryptographic DM Scheme
14	Set Designator	01h	CryptographicFramework
15,16	Reserved	00h

12.4 Cryptographic Context Key🔗

Table 15 –⁠ Cryptographic Context Key
Byte No.	Description	Value (hex)	Meaning
Bytes 1-12 of this key are specified for structural metadata sets in SMPTE ST 377-1
13	Scheme Kind	02h	Cryptographic DM Scheme
14	Set Designator	02h	CryptographicContext
15,16	Reserved	00h

12.5 Encrypted Triplet Key🔗

Table 16 –⁠ Encrypted Triplet Key.
Byte No.	Description	Value (hex)	Meaning
Bytes 1-8 of this label are defined by the KLV data encoding protocol specified in SMPTE ST 336
9	Item Designator	0Dh	Organizationally Registered
10	Organisation	01h	AAF Association
11	Application	03h	Essence containers
12	Structure Version	01h	Version 1
13	Essence Container Kind	02h	MXF Generic Container
14	Mapping Kind	7Eh	Encrypted Essence
15	Locally Defined	01h	Encrypted Triplet
16	Reserved	00h

12.6 AES-CBC with 128-bit Key UL🔗

Table 17 –⁠ AES-CBC with 128-bit Key UL.
Byte No.	Description	Value (hex)	Meaning
Bytes 1-8 of this label are defined by the KLV data encoding protocol specified in SMPTE ST 336
9	Item Designator	02h	Administrative
10		09h	Encryption
11		02h	Data Encryption
12		01h	Data Encryption Algorithms
13	Algorithm Designator	01h	AES-128 CBC
14-16	Reserved	00h

12.7 HMAC-SHA1 with 128-bit Key UL🔗

Table 18 –⁠ HMAC-SHA1 with 128-bit Key UL
Byte No.	Description	Value (hex)	Meaning
Bytes 1-8 of this label are defined by the KLV data encoding protocol specified in SMPTE ST 336
9	Item Designator	02h	Administrative
10		09h	Encryption
11		02h	Data Encryption
12		02h	Data Hashing Algorithms
13	Algorithm Designator	01h	HMAC-SHA1 128
14-16	Reserved	00h

Annex A
Security Properties (Informative)🔗

This specification has the following security properties:

The standard allows the first part of the essence KLV Triplet value to be unencrypted. The size of this part can be set independently for each KLV Triplet.
The second part of each essence KLV Triplet is encrypted using a strong algorithm (AES) in an appropriate and well-understood mode (Cipher Block Chaining).
The proposal provides partial integrity protection (tamper detection). Assuming that the 44-byte sequence consisting of the TrackFile ID, Sequence Number, and MIC items is delivered to a secure processing device along with the Encrypted Source Value, some types of manipulation may be detected.
An attack which changes the order of essence KLV Triplets in the Track File will be detectable, based on sequence numbers.
An attack which deletes or repeats complete KLV Triplets will be detectable, based on sequence numbers.
An attack which inserts or substitutes KLV Triplets from a different Track File will be detectable, even if that Track File uses identical encryption and MAC keys, based on TrackFile ID.
An attack which deletes, adds, or changes any bits of the ciphertext will be detectable.
An attack which splices together parts of different KLV Triplets will be detectable.
Certain types of tampering are not detectable using the Integrity Check Pack.
An attacker is free to change the length of KLV Fill items.
An attacker is free to change all the metadata in the file including the Key and Length of any triple and most of the fields within the Value portion of the triples (e.g., the Plaintext Offset or Cryptographic Context Link, but not the Integrity Check Pack), and all the fields in the Cryptographic Context and the Cryptographic Framework.
The derived MIC key may be computed in a secure environment and delivered to a less secure integrity-checking device without risking the exposure of the Cipher Key encrypting the content itself.
Only an entity that knows the decryption key can tell whether the file will decrypt properly. For example, an attacker could interfere with cryptographic key delivery or synchronization (e.g., by modifying the Cryptographic Context Pack while it is on the server), and only during playback will the problem be noticed.

Annex B
Legacy MIC Key derivation algorithm (Informative)🔗

Previous editions of this document specified a method to derive the MIC Key from the Cipher Key, based on an algorithm defined in NIST FIPS PUB 186-2:

The key used in the MIC algorithm (MIC Key) is derived from the key (Cipher Key) referred to by Cryptographic Key ID using the combination of algorithms defined in Appendix 3.1 and Appendix 3.3 of NIST FIPS 186-2. Specifically the MIC Key shall equal to x1 per Appendix 3.1 using Cipher Key as the seed-key XKEY, setting XSEEDj = 0 and constructing the function G(t,c) per Appendix 3.3. In addition, since Appendix 3.1 is being used as a general random number generator, the term “mod q” in step 3.c shall be omitted, per the “General Purpose Random Number Generation” of the Change Notice 1 addendum. x0 shall be discarded.

NOTE —⁠ NIST FIPS PUB 186-2 has been withdrawn and the method is reproduced below to allow the interpretation of Track Files that conform to previous editions of this document.

The method uses the notations and conventions from IETF RFC 3174 and IETF RFC 4187.

# The "|" character denotes concatenation
# "^" denotes exponentiation
# f(t; B, C, D), K(t) and S^n(X) are defined in IETF RFC 3174

# Pseudo-Random Number Generator (IETF RFC 4187)

XKEY = CipherKey

For i = 0 to 1 do
  XVAL = XKEY mod 2^b

  # the following equivalent to applying SHA-1 to a single block message M1,
  # but using different padding (IETF RFC 3174)

  M1 = XVAL | 0^(512-b)          # The first b bits of M1 contain XVAL, and the remaining
                                 # (512-b) bits are set to zero

  W(0) | W(1) | ... | W(15) = M1 # divide M1 into 16 words where W(0) is the left-most word
  For t = 16 to 79 let
    W(t) = S^1(W(t-3) XOR W(t-8) XOR W(t-14) XOR W(t-16))

  A = 67452301 
  B = EFCDAB89 
  C = 98BADCFE 
  D = 10325476 
  E = C3D2E1F0

  For t = 0 to 79 do
    TEMP = S^5(A) + f(t;B,C,D) + E + W(t) + K(t)
    E = D
    D = C
    C = S^30(B)
    B = A
    A = TEMP

  H0 = H0 + A
  H1 = H1 + B
  H2 = H2 + C
  H3 = H3 + D
  H4 = H4 + E

  w_i = H0 | H1 | H2 | H3 | H4

  XKEY = (1 + XKEY + w_i) mod 2^b

  MICKey = w_0 | w_1

D-Cinema Packaging — Track File Encryption

Table of contents🔗

Foreword🔗

1 Scope🔗