Digital Cinema Initiatives

Archives

WARNING: All documents in the section have all been replaced with more current versions.

DCI SYSTEM REQUIREMENTS AND SPECIFICATIONS FOR DIGITAL CINEMA

DCI Specification, Version 1.2 with Errata as of 30 August 2012 Incorporated


THIS IS AVAILABLE IN ARCHIVES ONLY

Digital Cinema Initiatives, LLC (DCI) has adopted a revised Version 1.2 of its Digital Cinema System Specification with errata as of 30 August 2012 incorporated.

The new DCI Specification, Version 1.2 with Errata as of 30 August 2012 Incorporated, dated 10 October 2012, incorporates the 96 erratum previously released for Version 1.2 of the DCI Specification that was dated 7 March 2008. With the integration of these errata into the body of the Specification, readers will now be able to use the Specification without having to cross-reference to these 96 errata.

Future errata will modify the Current DCI Specification - See Current Specification

Click here for:
Digital Cinema System Specification Version 1.2 with Errata as of 30 August 2012 Incorporated, dated 10 October 2012 (PDF)

 

Two addenda remain supplements to the DCSS:

 


 

ERRATA TO DCI DIGITAL CINEMA SYSTEM SPECIFICATION
VERSION 1.2 WITH ERRATA AS OF 30 AUGUST 2012 INCORPORATED

Errata items continue to be evaluated and will be posted after agreement by the DCI membership that the specific erratum needs to modify the DCI Digital Cinema System Specification, Version 1.2 With Errata As Of 30 August 2012 Incorporated. Suggested Erratum issues may be emailed to dci.info@dcimovies.com. Please include "Errata" in the subject line.

DCI SPECIFICATION ERRATA LISTING 1 and 2 Approved: 21 AUGUST 2013

pdf DOWNLOAD: ERRATA #1 and #2, Approved: 21 AUGUST 2013

DCI SPECIFICATION ERRATA LISTING 3-9 Approved: 04 SEPTEMBER 2014

pdf DOWNLOAD: ERRATA #3 to #9, Approved:04 SEPTEMBER 2014

pdf DOWNLOAD: CHAPTER 9 REPLACEMENT

pdf DOWNLOAD: "changes-marked" document
This is a draft document that shows the differences (additions and deletions) between chapters 7 and 9 of the previous DCI Specification, Version 1.2 with Errata as of 30 August 2012 Incorporated, and the current version of the DCSS noted above. The actual documents (not this "changes-marked" document) are the definitive expressions of their respective DCSS versions and prevail in the event any interpretation is required.

DCI SPECIFICATION ERRATA LISTING #10-#13, Approved: 26 AUGUST 2015

ERRATA  #10 to #13, 26 AUGUST 2015 DOWNLOAD: ERRATA #10 to #13, Approved: 26 AUGUST 2015
Note: Page numbers of this errata reference Replacement Chapter 9 of Erratum 9

DCI SPECIFICATION ERRATA LISTING #14, Approved: 25 SEPTEMBER 2015

ERRATA #14 25 SEPTEMBER 2015 DOWNLOAD: ERRATA #14 Approved: 25 SEPTEMBER 2015
Note: Page numbers of this errata item reference Replacement Chapter 9 of Erratum 9
Also see September 25 2015 Revisions to The CTP

DCI SPECIFICATION ERRATA LISTING #15-23, Approved: 31 MARCH 2016

ERRATA #15-23 31 March 2016 DOWNLOAD: ERRATA #15-23, Approved: 31 MARCH 2016
Note: Page numbers of this errata item reference Replacement Chapter 9 of Erratum 9

DCI SPECIFICATION ERRATA LISTING #24, Approved: 28 APRIL 2016

ERRATA #15-23 31 March 2016 DOWNLOAD: ERRATA #24, Approved: 28 APRIL 2016
Note: Page numbers of this errata item reference Replacement Chapter 9 of Erratum 9

DCI SPECIFICATION ERRATA LISTING #25-38, Approved: 2 MARCH 2017

DCI SPECIFICATION ERRATA LISTING #25-38, Approved: 2 MARCH 2017 DOWNLOAD: ERRATA #25-38, Approved: 2 MARCH 2017
Note: Page numbers of this errata item reference Replacement Chapter 9 of Erratum 9

DCI SPECIFICATION ERRATUM LISTING #39, Approved: 2 AUGUST 2017

DCI SPECIFICATION ERRATA LISTING #39, Approved: 2 AUGUST 2017 DOWNLOAD: ERRATA #39, Approved: 2 AUGUST 2017
Note: Page numbers of this errata item reference Replacement Chapter 9 of Erratum 9

DCI SPECIFICATION ERRATA LISTING #40-42, Approved: 29 AUGUST 2017

DCI SPECIFICATION ERRATA LISTING #40-42 Approved: 29 AUGUST 2017 DOWNLOAD: ERRATA #40-42, Approved: 29 AUGUST 2017
Note: Page numbers of this errata item reference Replacement Chapter 9 of Erratum 9

DCI SPECIFICATION ERRATA LISTING #43, Approved: 05 OCTOBER 2017

DCI SPECIFICATION ERRATA LISTING #43 Approved: 05 OCTOBER 2017 DOWNLOAD: ERRATA #43, Approved: 05 OCTOBER 2017
Note: Page numbers of this errata item reference Replacement Chapter 9 of Erratum 9

DCI SPECIFICATION ERRATA LISTING #44-45, Approved: 24 JANUARY 2018

DCI SPECIFICATION ERRATA LISTING #44 and #45 Approved: 4 JANUARY 2018 DOWNLOAD: ERRATA #44-45, Approved: 24 JANUARY 2018
Note: Page numbers of this errata item reference Replacement Chapter 9 of Erratum 9

ALL ERRATA TO DCI DIGITAL CINEMA SYSTEM SPECIFICATION
VERSION 1.2 WITH ERRATA AS OF 30 AUGUST 2012 INCORPORATED
Erratum Spec. 1.2
with Errata
Incorporated
Page No.
Section(s) Affected Description

1

26

Section
3.3.3

Section 3.3.3 is replaced in its entirety with the following:
3.3.3. Channel Labeling and Channel Routing

Channel labeling indicates where an audio channel is to be reproduced in an auditorium. Channel routing is the process of using these labels to direct each audio channel to the Media Block output that corresponds to the intended loudspeaker or device.

The playback device is required to perform channel routing.

The channel labels and schema in SMPTE ST 429-2 "D-Cinema Packaging-DCP Operational Constraints" shall be utilized.

2

100

Section
9.4.3.5

The following sentence is added to the end of item #5 (i.e., below "b. Audio - Process..."):

The SM shall prevent playout of encrypted content for which the image and sound integrity pack metadata is not present per the requirements of Section 5.3.2.1.

3

100

Section
9.4.3.5

Erratum # 2 has been incorporated into Erratum # 9 (the replacement Chapter 9) and Erratum # 2 is therefore deprecated.

4

64

Section
7.5.4.1

The third and fourth paragraphs of this section shall be replaced with the following (the fourth paragraph remains between Figures 11 and 12):

The Image Media Block can be implemented in a server configuration, as shown in Figure 11. This is where the storage and the Image Media Block are closely coupled. In this configuration, the content data is then pushed to the projector. In this configuration, Link Encryption is required to protect the uncompressed content.

The Image Media Block can also be implemented as a component within the projection system. This provides the option of not requiring Link Encryption. In this configuration, the Image Media Block may use a push or pull method to process essence data from storage, as shown in Figure 12.

5

64

Section
7.5.4.1

In Figure 11, the "FM" with asterisk reference from the Projection System, and the associated " *optional " notation, are removed.

6

65

Section
7.5.4.1

The following paragraph is inserted above the "Note" at the top of page 65:

In addition to the two single Image Media Block (IMB), single projector configurations shown above, this specification provides for Multiple Media Block (MMB) configurations to support multiple projectors and/or the use of an Outboard Media Block (OMB) within the projection booth. See Chapter 9 "SECURITY" for details of MMB and OMB requirements and operation.

7

65

Section
7.5.4.2.1

The following shall replace the existing text of this section:

A Media Block is the device that converts, in real time, the packaged content data from storage into data for playback to downstream devices. The one or more Media Block(s) of the projection booth are required to playback the image, audio and other time-dependent content in a manner that presents a synchronized performance to the audience. Synchronization requirements are as follows:

  • Synchronization of audio and on-screen text to image shall be frame accurate.
  • Synchronization of audio objects shall be accurate to within 10 microseconds (sample accuracy at 96K).
  • The synchronization signal shall include information that represents the current position within the show timeline and shall be accurate to within 10 microseconds.
  • "Locate and play" shall be supported.
  • The synchronization signal shall be defined separately from any essence it may be asked to synchronize, and able to sync multiple media blocks regardless of the essence they are handling.

The sync signal shall be defined independently of an interface or transport mechanism.

8

65

Section
7.5.4.2.2

The following paragraph shall replace the first paragraph of this section:

The main function of a Media Block is to provide a secure environment within which to perform content essence decryption. In support of this Media Blocks shall contain a Security Manager, media decryptor(s) and (as applicable) associated forensic markers. Link Encryption shall be applied to image essence if the associated Media Block is not contained within the projection system.

9

79-148

Section
9.1-9.8
All of Chapter 9

The DCI document DCSS-replacement_Chapter_9--20140904.pdf replaces Chapter 9 in its entirety

10

105

Section
9.4.3.6.3

The last sentence of #5 is removed.

11

106

Section
9.4.3.6.4

The last sentence of #3 is removed.

12

117

Section
9.4.6.1.1

The last two bullets of this section are replaced with:

  • Each instance of a Forensic Marking application shall include a unique 19 bit minimum "location" Forensic Marking Identification (FMID), derived as follows:
    1. The FMID value shall be derived from an integrated unique parameter permanently associated with the Forensic Marking application. The FMID shall meet the following requirements:
      • It shall be manufactured such that it cannot be changed or reprogrammed by any means whatsoever without violation of the SPB's type-1 perimeter.
      • Manufacturers of SPBs containing Forensic Markers shall maintain and make available an accurate, timely database associating each integrated FMID with its associated SPB serial number and digital certificate.
      • Forensic Marking licensors shall ensure the uniqueness of FMIDs.
    2. [This item left blank intentionally.]
  • In multiple projection situations the optically combined Forensic Marks as projected shall meet the same "general" and "survivability" requirements as defined herein for single projector applications.

13

126

Section
9.5.1.1

All bullets of this section are replaced with:

  • Image Media Block (IMB) - SM
  • Image Media Block with Link Encryptor - SM LE
  • IMB with OBAE processor - SM OBAE
  • IMB with OBAE & LE - SM OBAE LE
  • Outboard Media Block (OMB) with OBAE processor - OBAE
  • Link Decryptor Block - LD
  • Image Processor - LD LE
  • Projector to be married - PR
  • Projector permanently married to an IMB - PR SM
  • Projector permanently married to an LDB - PR LD

Note:

  • The designation of other roles is optional.

14

130

Section
9.5.2.5

The following is added as a new first bullet:

  • Nr 1 - Cryptographic Module Specification shall only be required to meet Security Level 2 requirements.

15

45

5.3.6

The last sentence of this section is replaced with:

Extensions shall adhere to the requirements given in this specification and the Auxiliary Data requirements of [SMPTE ST429-14: "D-Cinema Packaging -- Aux Data File"].

16

97

9.4.3.3

The forth bullet of this section is replaced with:

  • Forensic Marking - Each MB shall apply Forensic Marking to image and audio essence and Aux Data (as applicable) during playback.

17

106

9.4.3.6.3

The second sentence of item 5 of this section is replaced with:

The IMB may optionally perform the functions required to process one or more of the essence types defined in Section 9.4.3.6.4 "Normative requirements: Outboard Media Block (OMB)", item 4. In such case the IMB shall implement all requirements of the OMB section for each such essence type (in addition to the IMB requirements of this section).

18

115

9.4.6.1

The opening sentence of this section is replaced with:

These specifications require that image, audio and Aux Data Forensic Marking (FM) capability be included (as applicable) in each Media Block.

19

119

9.4.6.2

Item #8 of this section is replaced with:
The SM and FM Security Entities shall log the presence or absence of image, audio and Aux Data (AD) Forensic Marking for each encrypted DCP.

20

126

9.5.1

The first two sentences of this section are replaced with:

A Digital Cinema Certificate is a declaration by a trusted organization, such as a manufacturer, that the security device is a particular make, model and serial number, and is certified (i.e., found to be compliant to this specification) to perform identified D-Cinema roles. Digital certificates are also the means by which the Security Manager (SM) identifies other Secure Processing Blocks (SPB), and they are additionally used to sign security log records and in establishing Transport Layer Security (TLS) connections.

Each SPB shall be given a D-Cinema identity certificate during the manufacturing process, which shall be (i) permanent to the device (subject to Section 9.5.2.3 "Repair and Renewal") and (ii) unique to the device, for the life of the SPB. See Section 9.5.2.2 "Physical Security of Sensitive Data" for related Secure Silicon SPB private key requirements.

21

126

9.5.1.1

The following sentence replaces the last sentence of the second paragraph:

The make, model and serial number of each certificated device shall be placed on the exterior of said device in a manner that is easily read by a human, and this information shall at all times match that in the device's digital certificate.

22

126

9.5.1.1

The first five bullets of this section are replaced with:

  • Image Media Block or Outboard Media Block - SM
  • Image Media Block with Link Encryptor - SM LE

23

138

9.6.2

The text in this section (including all subsections) is replaced with:

The information previously contained in this section has been deleted as redundant or relocated as needed to other sections of this specification.

24

126

9.5.1

The second paragraph of Erratum #20 is replaced with:

RSA private keys in a Type 1 SPB, which constitute the subject of any certificate having an SM or LS role, shall be generated within that device and shall not be accessible to any process external to the device. See Section 9.5.2.2 "Physical Security of Sensitive Data" for related Secure Silicon SPB private key requirements.

25

85

9.4.1

The following sentence is added to the end of item #3:

With exception of subtitle essence (see Section 9.7.3 "Subtitle Encryption"), encrypted essence files shall be decrypted in real-time during playout, and at all other times shall remain encrypted as received in the DCP.

26

93

9.4.2.7

A new section 9.4.2.7 is added as follows:

9.4.2.7 Auxiliary Data Processing

Aux Data (AD) shall be considered essence defined under [SMPTE ST429-14: "D-Cinema Packaging -- Aux Data File"], subject to the exceptions specified herein. Aux Data is treated as a generic essence type. This means the specific functional requirements for AD decryption and post-decryption processing (e.g., decoding, forensic marking, etc.) must be known for a given implementation, but are out of scope of this specification except as provided for in Section 9.4.3.6.4 "Normative requirements: Outboard Media Block (OMB)".

By way of example, image essence and audio essence (sometimes referred to as main image and main audio to avoid confusion with emerging types of AD), subtitle essence and Object-Based Audio Essence (OBAE) processing requirements are expressly addressed by this specification, and are thus distinguished from generic Aux Data essence types.

Encrypted Aux Data (AD) shall be decrypted only within a Media Block (MB) using the "MDX1" AD essence KeyType delivered by a KDM. (See [SMPTE ST430-1: "D-Cinema Operations - Key Delivery Message"].) The MDX2 KeyType shall be reserved for future use.

Aux Data that is not encrypted is not subject to the security constraints of this specification.

27

99

9.4.3.5

The first sentence of item #1 is replaced with:

Validate Key Delivery Messages per (a) the three validity checks of Section 6.1.2 of the KDM specification (SMPTE 430-1: D-Cinema Operations - Key Delivery Message), and (b) confirming the KDM's CipherData element matches the contents and format of the table of said Section 6.1.2, of the KDM specification.

28

100

9.4.3.5

Item #4 is replaced in its entirety with:

  1. Validate Composition Playlists (CPL), and log results as a prerequisite to the associated composition playback. For encrypted content, validation shall confirm that:
  1. The associated KDM's ContentAuthenticator element matches a certificate thumbprint of one of the certificates in the CPL's signer chain (see item 1 above), and that such certificate indicate only a "Content Signer" (CS) role per Section 5.3.4, "Naming and Roles" of the certificate specification (SMPTE 430-2 D-Cinema Operation - Digital Certificate).
  2. All the content essence keys carried in the AuthenticatedPrivate element of the associated KDM are reflected (i.e., must exactly match those listed) in the CPL.

29

100

9.4.3.5

Item #6 of this section is replaced with:

  1. As of January 1, 2016, Federal Information Processing Standards (FIPS) compliance requirements disallow use of the random number generator (RNG) as specified in [SMPTE ST429-6: "D-Cinema Packaging - MXF Track File Essence Encryption"]. Additionally, a KDM key type is needed to support encryption of generic Auxiliary Data (AD) essence per [SMPTE ST429-14: "D-Cinema Packaging - Aux Data File"]. These are addressed by the following requirements for support of KDMs carrying "MIC" and "Aux Data" key types:
  1. Media Block (MB) SMs shall support the receipt and processing of KDMs carrying the MIC and Aux Data (AD) key types. (See [SMPTE ST430-1: "D-Cinema Operations - Key Delivery Message"].)
  2. MB SMs shall perform the content hash (HMAC) integrity check of above item 5 using the KDM-borne MIC keys if present (and shall not derive the MIC key from KDM content keys).
  3. MB SMs capable of processing KDM-borne MIC keys shall indicate so by including "MIC" in their digital certificate roles (see role definitions of Section 9.5.1.1 "Single Certificate Implementations").
  4. MB SMs shall not implement the Random Number Generator (RNG) defined (for the purpose of MIC key derivation) in [SMPTE ST429-6: D-Cinema Packaging - MXF Track File Essence Encryption].
  5. When receiving a KDM type that does not contain a MIC key, MB SMs shall perform all the content integrity checks specified in above item 5 except the hash (HMAC) check.

30

106

9.4.3.6.4

Item number 1 of this section is replaced with:

Perform the following itemized SM functions as defined under Section 9.4.3.5 Functions of the Security Manager (SM): #1, #2, #3, #4, #5, #6, #9 (except for sub-items a and c), #12, #13, #14, #18.

31

106

9.4.3.6.3

The following is added as new number 8:

  1. An IMB intended for operation in Multiple Media Block (MMB) installations shall be capable of operating as either a "source" or "sink" of synchronization information per the requirements of Section 7.5.4.2.1 "Synchronization".

32

107

9.4.3.6.4

The following is added below the existing bullet of item number 4:

  • Auxiliary Data (AD) essence per [SMPTE ST429-14: D-Cinema Packaging - Aux Data Track File], subject to the constraints of Section 9.4.2.7 "Auxiliary Data Processing."

33

107

9.4.3.6.4

The following is added as new number 6:

  1. Operate as a "sink" of synchronization information per the requirements of Section 7.5.4.2.1 "Synchronization".

34

119

9.4.6.2

The following replaces the existing item #9:

  1. Notwithstanding the exceptions defined in Section 9.4.6.2, all decrypted audio shall be forensically-marked. A Forensic Mark is required to be inserted in real time into the audio content at the earliest point after decryption and prior to the audio content data being present on any data bus outside the Media Block (see Section 9.4.6.1 "Forensic Marking").

35

127

9.5.1.1

The following is added above the existing "note" at the bottom of Erratum 13:

The following role(s) shall be included for the IMB and OMB, as applicable:

  • KDM-borne MIC Key capable MB - MIC

36

131

9.5.2.5

The following paragraph is added below the last bullet of this section:

This specification requires all Media Blocks (MB) to be FIPS 140-2 certified per the requirements of this section. MB suppliers shall at all times ensure that their published FIPS Security Policy document(s) accurately reflect the current state of the MB design and functionality.

37

141

9.7.4

The second sentence of this section is replaced with:

"The above RSA asymmetric protection, or symmetric key wrapping per SP800-38F may be used to protect the storage of keys once decrypted from the KDM within a Media Block (e.g., where off-secure-silicon IC memory is used for key caching within a Media Decryptor)."

38

141

9.7.6

The entirety of this section is replaced with:

"Asymmetric keys (RSA keys) shall be generated as specified in FIPS 186-4. Symmetric keys shall be generated from the output of a SP800-90A DRBG as per SP800-133 or FIPS 140-2 IG 7.8.

RSA asymmetric keys shall be 2048 bits in length and be generated from two or three prime numbers, each of which must be at least 680 bits long. The mechanism used to generate RSA key pairs must have at least 128 bits of entropy. A vendor shall keep records of only the public keys, and shall not keep any record of the matching private keys.

See Section 9.5.1 "Digital Certificates" for additional requirements for the generation, storage and utility of keys."

39

128

9.5.2.2

The first sentence of "Secure Silicon" bullet item "b" is replaced as follows:

SPB private keys used for device identity (see section 9.5.1 "Digital Certificates") shall not exist outside of the Secure Silicon IC.

40

126

9.5.1.1

Errata 13, 22 and 35 (i.e., all bullets of this section) are replaced with (for clarity, "RES" is a new role):

  • Image Media Block or Outboard Media Block – SM
  • Image Media Block with Link Encryptor – SM LE
  • Link Decryptor Block - LD
  • Image Processor - LD LE
  • Projector to be married – PR
  • Projector permanently married to an IMB -PR SM
  • Projector permanently married to an LDB - PR LD

 

The following role(s) shall be included for the IMB and OMB, as applicable:

  • KDM-borne Message Integrity Code key capable MB - MIC
  • "Reserved" identity certificate (see Section 9.5.1.3 "Media Block Identity Certificates") - RES

Note:

  • The designation of other roles is optional

41

127

9.5.1.3

A new section 9.5.1.3 is added as follows:

9.5.1.3 Media Block Identity Certificates

Media Blocks shall contain a minimum of two RSA key pairs associated with the SM role, either pair of which can be used with an identity certificate (SM Certificate). In other words, the MB shall have a minimum of two identity certificates, and shall respond as normal to the receipt of a KDM targeted to either identity (as distinguished by the respective RSA key pairs).

One identity certificate shall be published, and the other shall not be published and be reserved for future use as designated by DCI. The reserved certificate shall carry the "RES" role in addition to the roles enumerated by the published certificate.

42

128

9.5.2.2

The first sentence of item (c) of the first bullet of this section is replaced with:

Decrypted (plain text) content keys may be moved from the Secure Silicon IC for purposes of decrypting essence during playout only.

43

126

Section
9.5.1

The following paragraph is added to the end of erratum #24:

FIPS requirements specify methods of RSA key pair generation, and such methods require an entropy source (i.e., seed). It is encouraged (but not required) that the entropy source be contained within the Secure Silicon IC. In any event, the entropy source:

  • Shall be fully contained within the Media Block's Type 1 SPB, and shall not be dependent on or influenced by any parameter or value external to the SPB,
  • Shall not enable the export of any information about the seed from the SPB.

44

101

Section
9.4.3.5

The opening text of item #9. "Prepare and issue KDM-borne content keys to Media Decryptors (MD) per the CPL. Constrain use of keys to:" is deleted and replaced with:

"The SM shall constrain playout of encrypted content to:"

45

106

Section
9.4.3.6.4

Item #1 is replaced with:

Perform the following itemized SM functions as defined under Section 9.4.3.5 Functions of the Security Manager (SM): #1, #2, #3, #4, #5, #6, #8 sub-item a. (only), #9 (except for sub-items a., b. and c.), #11, #12, #13, #14, #18.