Digital Cinema Initiatives

DCI SYSTEM REQUIREMENTS AND SPECIFICATIONS FOR DIGITAL CINEMA

DCI Specification, Version 1.3

 

Digital Cinema Initiatives, LLC (DCI) has adopted Version 1.3 of its Digital Cinema System Specification as of 27 June 2018.

Future errata will modify the DCI Specification, Version 1.3 .

 

Two addenda remain supplements to the DCSS:

 


 

ERRATA TO DCI DIGITAL CINEMA SYSTEM SPECIFICATION VERSION 1.3 27 June 2018

 

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.3. Suggested Erratum issues may be emailed to image is not clickable to prevent spam Please include "Errata" in the subject line.

DCSS Errata 1-9, Approved: 01 OCTOBER 2018 for the Digital Cinema System Specification (DCSS), Version 1.3.
pdf DCI_DCSS_Errata_1-9_2018-1001.pdf

Note: Deprecated Errata are indicated by strike through text in table below.

DCSS Errata 10-12, Approved: 7 DECEMBER 2018 for the Digital Cinema System Specification (DCSS), Version 1.3. ↓ View ↓
pdf DCI_DCSS_Errata_10-12_2018-1207.pdf

DCSS Errata 13-17, Approved: 9 AUGUST 2019 for the Digital Cinema System Specification (DCSS), Version 1.3. ↓ View ↓
pdfDCI_DCSS_Errata_13-17_2019-0809.pdf

DCSS Errata 18-20, Approved: 19 December 2019 ↓ View ↓
pdfDCI_DCSS_Errata_18-20_2019-1219.pdf

DCSS Erratum 21, Approved: 6 February 2020 ↓ View ↓
pdfDCI_DCSS_Erratum_21_2020-0206.pdf

Erratum Spec 1.3 PageSections Affected Description

1

27 3.3.4.3

A new section 3.3.4.3 is added as follows:

3.3.4.3. Object-Based Audio Essence (OBAE)

Object-Based Audio Essence (OBAE) implementations shall meet all requirements as defined in the Digital Cinema Object-Based Audio Addendum approved by Digital Cinema Initiatives, LLC (DCI) on 23 August 2018.

This specification refers to OBAE in lieu of Immersive Audio.

2

94 9.4.2.5

The last bullet of this section is replaced with the following two bullets:

  • If multiple SMSs are present, exhibition shall designate one to TLS connect with, and be used for identity logging by, all SMs participating in any given showing.
  • Upon the completion of each show playback (i.e., execution of the show playlist) the SMS shall query each participating Media Bock SM for its flagged indication that a PlayoutComplete security log report has been prepared, upon which indication the SMS shall collect the report. For Multiple Media Block (MMB) show playback situations the reports from each MB shall be stored in a collocated fashion such that all the reports for any given playback are readily available, for a period of at least one year.Exhibition is free to use a storage location of their choice (i.e., the SMS may pass the collected reports to external storage). See Sections 9.4.6.3.1 Logging Requirements, item #18 and 9.4.6.3.10 Logging Failures for associated information regarding SM behavior.

3

107 9.4.3.6.1

The following is added as a new paragraph after the first paragraph of item #3:

A security access opening event shall be electronically detected, and projector SPB designs shall prevent playout unless the detector(s) indicate all security access openings are closed. (Projector SPB "maintenance" and "security" servicing is defined in Section 9.5.2.4 Specific requirements for Type 2 Secure Processing Blocks.)

4

128 9.4.6.3.1

New item #18 is added to this section as follows:

18. Upon the completion of each show playback (i.e., execution of the show playlist) a Media Block SM shall:

  1. Within 60 seconds, prepare a log report containing a "PlayoutComplete" log record (per SMPTE 430-5 D-Cinema Operation – Security Log Event Class and Constrains for D-Cinema) for each encrypted composition of the just executed show playlist.
  2. Set a flag indicating that the PlayoutComplete report(s) has been prepared, which will be notification for the SMS to collect the PlayoutComplete report(s) from the MB.
  3. Reset the flag once the PlayoutComplete report(s) has been collected by the SMS, and disallow the next playback event until the SMS has so collected the report(s) (and the flag has been reset).

For Multiple Media Block (MMB) show playback situations the SMS must collect a log report(s) from each participating MB. See the associated SMS requirements at Section 9.4.2.5 Screen Management System (SMS).

5

132 9.4.6.3.8

The following new bullet is added to the end of this section:

  • For the FrameSequencePlayed Record (SMPTE ST 430-5 section 7.3.1.1), if the track file is an OBAE track tile, the Parameters list shall contain a name/value pair whose name element shall contain the token OBAEMark, and whose Value element shall contain one of two tokens, either "true" or "false", indicating that a forensic mark was or was not inserted during playout.

6

132 9.4.6.3.10

The text of this section is replaced with:

The secure logging requirements of this Section 9.4.6.3 Logging Subsystem are required to be functionally executed and fully operable as a prerequisite to playback. Per Section 9.4.6.3.1 Logging Requirements, Security Managers (SM) shall prevent the playout of encrypted content for which:

  • It has not collected log records from remote Secure processing Blocks (SPBs) per item #8,
  • The SMS has not collected the PlayoutComplete report per item #18,
  • There is any indication that the next playback will not record and report log records as required.

Behavior of SPBs shall be specified and designed to immediately terminate operation and require replacement upon any failure of its secure logging operation. Resident log records in failed SPBs shall not be purgeable except by authorized repair centers, which shall be capable of securely recovering such log records.

7

137 9.5.2.4

Section 9.5.2.4 is replaced in its entirety with:

9.5.2.4. Specific Requirements for Type 2 Secure Processing Blocks

The SPB type 2 container has been defined specifically for protection of image essence exiting either a Link Decryptor Block or Image Media Block (companion SPBs to the projector SPB) and entering the projector. The purpose of this SPB is to protect the image essence signal as far as practical, recognizing that "all the way to light" production is not possible. It is also preferable not to impose formal FIPS 140-2 requirements on this SPB, as the security and signal flow functions are relatively simple.

General requirements for SPBs are defined in Section 9.4.2.2 "The Secure Processing Block (SPB)," and Section 9.5.2.2 "Physical Security of Sensitive Data." Specific requirements for projection systems are defined in Section 9.4.3.6.1 "Normative Requirements: Projection Systems." As explained there, the type 2 SPB – also referred to as a projector SPB - is permitted to be opened for maintenance. To assure adequate protection of signals and circuits within the projector SPB, the following address physical requirements, and are in addition to those of the above noted sections:

  • The projector SPB shall be designed for two types of access: "security servicing" and "non-security servicing." Security servicing is defined as having access to Security-Sensitive Signals, which are the companion SPB's output image essence signals or image signals derived from said output signals, or the projector SPB security access opening/detection circuits and associated signals.
  • For non-security servicing (i.e., maintenance), Security-Sensitive Signals shall not be accessible via the SPB's maintenance door opening(s). In other words, there shall be a partition that separates security-related signals/circuits from non-security related maintenance accessible areas, which shall serve as the boundary of the type 2 SPB and deny access to Security-Sensitive Signals, without causing permanent and easily visible damage.
  • Security servicing shall trigger a security access opening event per Section 9.4.3.6.1 "Normative Requirements: Projection Systems", and be performed only under the supervision of the projector manufacturer per Section 9.5.2.3 "Repair and Renewal". The triggering and clearing (i.e., reset) of a security access opening event shall be respectively logged as an "SPBOpen" and "SPBClose" security log, per Section 9.4.6.3.8 "Log Record Information".
  • Projector SPB security access openings (i.e., doors or panels that enable access for security servicing) shall be lockable using pick-resistant mechanical locks employing physical or logical keys.
  • Protection from external probing of Security-Sensitive Signals shall be provided by assuring barriers exist to prevent access to such signals via ventilation holes or other openings.

In summary, the projector SPB physical perimeter provides for unencumbered maintenance access, and security-critical signals are protected via security access opening door locks and opening detection. Exhibition visual inspection is relied upon to detect physical abuse that might allow compromise of, or access to, decrypted image essence.

8

138 9.5.2.4

New section 9.5.2.4.1 is added as follows:

9.5.2.4.1. Direct View Display Systems

A direct view display system is defined as a light emission display comprised of a combination of flat panel display cabinets conjoined so as to form a single large display. LED-based panels are typical, but the requirements herein shall apply to any image-forming display technology so comprised.

Industry design approaches and terminology varies. This specification defines the component parts as follows:

  1. ) Screen: The complete direct view cinema display system including all Pixels sufficient to display the entire image, and typically comprised of a plurality of Cabinets with a supporting structure, associated electronics and cabling.
  2. ) Cabinet: The physical structure and associated electronics which contains a portion of the image area of a Screen. The emissive surface area of a Cabinet is typically comprised of a plurality of Modules.
  3. ) Module: A component including an array of Pixels physically positioned so as to form a portion of the front display surface of a Cabinet. The Module is typically the smallest field-serviceable light-emitting component of a Screen.
  4. ) Display Pixel:The smallest grouping of light emitting elements within a Module, and capable of broad-spectrum (not monochromatic) light emissions. A Display Pixel (or Pixel herein) is often comprised of a triplet of red, green and blue light emitting diodes.

The physical characteristics of a direct view display require that the front Screen area comprise part of the display's type 2 SPB physical perimeter. This may prevent it from meeting the "hard, opaque physical security perimeter" requirements of Section 9.4.2.2 "The Secure Processing Block (SPB)", and/or the "SPB hardware module" requirements of Section 9.5.2.2 "Physical Security of Sensitive Data". The following defines type 2 SPB accommodations for direct view displays.

Security servicing and non-security servicing definitions for direct view display systems apply as follows:

Security servicing - Opening or removal of a Cabinet or Module that compromises the type 2 SPB security perimeter and exposes Security-Sensitive Signals. Such opening or removal shall trigger a security access opening event. (It is permitted for one security access opening event to reflect the occurrence of simultaneous opening or removal of a plurality of Cabinets and/or Modules as part of a single servicing event.)

Non-security servicing - The opening of a Cabinet or Module that does not expose Security-Sensitive Signals.

For Cabinets having front removable Modules:

  • The removal of a Module shall expose only those Pixel signals accessible via the electrical connection(s) associated with the Module removed, but shall not otherwise expose Security-Sensitive Signals or compromise the type 2 SPB perimeter.
  • The removal of any Module shall be detected and prevent playout of an encrypted composition.
  • The removal of more than fifteen (15) Modules, or a Module quantity that exposes Pixel signals constituting more than 5% of the screen area, whichever is less, within any eight hour period, shall trigger a security access opening event.

Once triggered, to clear (i.e., reset) a security access opening event shall require:

  1. Remedy of the cause of the event (i.e., closure of the security access door or panel, replacement/ reassembly of the Cabinet(s) and/or Module(s), etc.), and
  2. The supervision of the manufacturer in the use of a physical key and/or logical code.

For purposes of clarity, a security access opening event shall remain active pending the above closure requirements, and such event shall be bookended by SPBOpen and SPBClose security log records.

The following requirements apply to a fully assembled direct view display system:

  1. The physical intrusion barrier presented by the light emitting front surface of Cabinets or Modules shall not be able to be penetrated without permanently destroying the proper operation of a Cabinet and/or Module so penetrated, and leaving permanent and easily visible damage.
  2. Cabinets and/or Modules shall be mechanically interlocked to each other directly and/or via the supporting frame structure such that any separation that would enable access to internal signals will cause permanent and easily visible damage.
  3. Any access to light emitting (Pixel generating) component electrical signals from the surface of the Screen shall be limited to individual component pins, and there shall be no access to signals that would constitute a portion of the picture image beyond the Pixel by Pixel level.

All other projector and projector SPB requirements of this specification shall remain in place.

In summary, security objectives for a direct view display Secure Processing Block (SPB) are fundamentally the same as for projectors. To avoid influencing electro-mechanical designs, the requirements of this specification are focused on access to Security-Sensitive Signals for direct view display systems, rather than specific requirements for the type 2 SPB physical boundary itself.

9

146 9.7.4

The second paragraph of this section is replaced with:

Per the requirements of Section 9.5.2.2 "Physical Security of Sensitive Data", item c, once decrypted from the KDM, content keys shall be protected at all times (except while being used during playback) by being stored within the Secure Silicon integrated circuit, or by AES key wrapping per NIST SP800-38F if stored external to the Secure Silicon IC.


 

  V1.3 DCSS Errata 10-12, Approved: 01 OCTOBER 2018 ↑ top of page  ↑

Erratum Spec 1.3 PageSections Affected Description

10

94,
128
and
132
9.4.2.5.,
9.4.6.3.1.
and
9.4.6.3.10

Erratum 2, 4 and 6, issued 1 October 2018, are deprecated and withdrawn.

11

103 9.4.3.5.

A new item (c) is added to item #4 as follows:

(c) The CPL meets the two validation requirements defined in Section 5.2.1 of SMPTE 430-5 D-Cinema Operations – Security Log Event Class and Constraints for D-Cinema.

12

111 9.4.3.6.4

The first bullet of item #4 is replaced with:

  • Object-Based Audio Essence (OBAE) as defined in the Digital Cinema Object-Based Audio Addendum published by Digital Cinema Initiatives, LLC (DCI) on October 1, 2018.

 

V1.3 DCSS Errata 13-17, Approved: 9 AUGUST 2019 ↑ top of page ↑

Erratum Spec 1.3 PageSections Affected Description

13

65 7.5.4.2.1

The last sentence of this section is replaced with:

The synchronization signal shall be compliant with SMPTE ST 430-14 D-Cinema Operations -- Digital Sync Signal and Aux Data Transfer Protocol.

14

93 9.4.2.3

The first bullet of this section is replaced with the following two bullets:

  • Image Media Block (IMB) - The Image Media Block (IMB) is a type 1 Secure Processing Block (SPB) that shall contain a Security Manager (SM), Image, Audio and Subtitle Media Decryptors (MD), image decoder, Image and Audio Forensic Marking (FM) and optionally the Link Encryptor (LE) function. The IMB SM is responsible for security for a single Equipment Suite (SPBs that drive a projector), and it authenticates other SPBs that comprise the suite. Other such SPBs are referred to as remote SPBs.
  • Image Media Block with OMB Functions (IMBO) - It is encouraged that the IMB perform the content essence processing functions of the Outboard Media Block (OMB) as given in Section 9.4.3.6.4. Normative Requirements: Outboard Media Block (OMB). An IMB that implements this functionality is an IMBO.

15

93 9.4.2.4

The first sentence of the third paragraph is deleted.

16

94 9.4.2.5

New section 9.4.2.5.1 is added at the end of section 9.4.2.5 as follows:

9.4.2.5.1 Multiple Media Block Operation

For multiple media block (MMB) implementations, the SMS shall operate as the central projection booth automated authority to assure all pre-show requirements have been confirmed. Requirements include:

  • Being aware of the complement of Media Blocks (IMB, OMB or IMBO) present in the projection booth, and the essence processing capabilities of each.
  • Analyzing composition playlists (CPLs) and show playlists (SPLs) to determine which Media Blocks (MB) will be expected to play/render each essence component of the composition(s) of a show, and confirm the complement of MBs is so capable.
  • Delivering all SPL KDMs and CPLs to the complement of MBs and obtaining confirmation from each participating SM that the prerequisites of Sections 9.4.3 Theater Security Operations and 9.4.3.5 Functions of the Security Manager (SM) are satisfied.

Where applicable, the use of SMPTE standards in support of the above is normatively defined in this specification. The use of other SMPTE standards is encouraged but is implementation-specific.

In sum, MMB operation places important responsibilities and additional operational expectations onto the SMS to assure security requirements are satisfied so that each show playout is successful. The pre-show, show playout and post-show operation of MMB architectures mandates the implementation of additional SMS functionality and automated processes.

17

110 9.4.3.6.3

In item #4 the term "Integrated Media Block" is replaced with "Image Media Block".


 

V1.3 DCSS Errata 18-20, Approved: 19 DECEMBER 2019 ↑ top of page  ↑

Erratum Spec 1.3 PageSections Affected Description

18

94 Section 9.4.2.5 The following sentence is added to the end of the first bullet of this section:

In the latter case the SMS shall be considered permanently integrated within said SPB, and the SPB and contained SMS shall be identified by a single certificate that is permanent to both.

19

137 Section 9.5.2.2 Item "b" of the second bullet of this section is deleted.

20

142 Section 9.5.5

The text of this section is replaced in its entirety with:

Compliance testing is the process of qualifying a certificated device for use in Digital Cinema systems. A "DCI compliant" certificated device is a device that has been issued a Digital Cinema Certificate per Section 9.5.1 "Digital Certificates," and has passed the compliance qualifying criteria of this specification, as verified by the DCI Digital Cinema System Specification Compliance Test Plan (CTP) tests designated for the device, and in effect at the time of verification.

Via the CTP, each certificated device shall be singularly verified as being compliant to the applicable requirements of this specification, and said device shall be uniquely identified per the make, model and serial number identity requirements of section 9.5.1.1 "Single Certificate Implementations."

Certificated devices are:

  • Screen Management System (SMS)
  • A type 1 or type 2 Secure Processing Block (SPB)
  • Permanently married projector (per section 9.4.3.6.6 "Permanently Married Implementations"
  • Permanently integrated SMS (per section 9.4.2.5 "Screen Management System (SMS))"

A certificated device that has not successfully passed the appropriate CTP qualifying criteria shall not be installed in a DCI compliant Digital Cinema system. Once installed, a certificated device that does not continue to meet the compliance qualifying criteria shall be declared a Security Function Failure, and shall be taken out of service until repaired.


 

V1.3 DCSS Errata 18-20, Approved: 19 DECEMBER 2019 ↑ top of page ↑

ErratumSpec 1.3 PageSections Affected Description

21

94 Section 9.4.2.5 The following is added as a new second bullet to this section, under "SMS Requirements":
  • Communications between the SMS and Media Block SMs shall be protected using Transport Layer Security (TLS), except in the case of a permanently integrated SMS. (In the latter case the SMS and SM are collocated within the same MB, and the communications are protected within the MB's type 1 SPB.)

  ↑ top of page ↑