Digital Cinema Initiatives

Specification Errata

«Previous Page

ERRATA 34 TO 76 DCI DIGITAL CINEMA SYSTEM SPECIFICATION, VERSION 1.2

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.

Suggested erratum items may be emailed to
not clickable to prevent spam
Please include "Errata" in the subject line.

« SEE ALL V1.2 ERRATA
 

pdf DOWNLOAD: ERRATA #34- #76, 20 APRIL 2011


Erratum Spec 1.2 Page Sections Affected Description

34

54 Section 5.4.3.4

Remove the words "Digitally Certified".

35

68 Section 7.5.2.2

The phrase "a dial-up modem with" is removed from the first sentence of the second bullet, which then reads:

"Theater facilities are required to provide a connection that will be available 24/7 for security communications (all ETM and log data reporting)."

36

68 Section 7.5.2.3

The following sentence is added to the end of this section:

"See section 9.5.6 (Communications Robustness) for additional exhibition communications and networking requirements."

37

92 Section 9.1

The definition of SPB is corrected to "Secure Processing Block".

38

92 Section 9.2.2

The word "inoperability" in the last sentence of this section is changed to "interoperability".

39

98 Section 9.4.1.1

The last sentence of the second paragraph is changed to:

"This figure shows that there shall be only three permitted physical protection scenarios:"

40

101 Section 9.4.2.2

The last paragraph of this section is replaced with:

"Secure Processing Blocks (SPBs) shall provide a hard, opaque physical security perimeter that meets minimum security requirements as defined in Section 9.5.2 Robustness and Physical Implementations. Both SPB types are considered a Security Entity (SE), and shall be assigned a digital certificate per Section 9.5.1 Digital Certificates."

41

107 Section 9.4.3.3

The sentence describing "log data recording" (last bullet) is replaced with:

"Remote SPBs shall capture and transfer log records to the Image Media Block (IMB) SMs as specified in Section 9.4.6.3 Logging Subsystem."

42

109 Section 9.4.3.5

The first sentence of item # 1 is replaced with:

"Receive, store, decrypt and validate Key Delivery Message(s) (KDMs) per the three validity checks of Section 6.1.2 of the KDM specification (SMPTE430-1: D-Cinema Operations - Key Delivery Message)."

43

110 Section 9.4.3.5

In item 7.b., the following sentence is added after the existing sentence:

Perform proxy mode of authentication for projection systems per Section 9.4.3.6.5.

44

111 Section 9.4.3.5

Item # 9 d of this section is replaced with:

[This item left blank intentionally.]

45

113 Section 9.4.3.6.1

The last paragraph of item # 3 of this section is replaced with:

To avoid the complexity of retaining its own log records (and the associated need for a clock and battery-backed persistence), the projector SPB shall send projector SBP log event data across the marriage electrical interface for retention by the companion SPB.

46

114 Section 9.4.3.6.1

Item # 7 of this section is replaced with:

The projector SPB shall include a secure silicon host device (see Section 9.5.2 Robustness and Physical Implementations) which shall contain the SPB's digital certificate.

47

114 Section 9.4.3.6.2

The following sentence is added after the existing sentence of item # 2 of this section:

Link Decryptor Blocks shall be designed so as to not to perform link decryption functions unless married to a projector SPB.

48

115 Section 9.4.3.6.2

The last sentence of item # 9 of this section is replaced with:

The LDB shall support all logging functions of the projection system, by providing 24/7 log recording support, and storage of all log records associated with the projection system.

49

116 Section 9.4.3.6.3

Item # 4 of this section is replaced with:

Since IMBs intended to support fully integrated projection system architectures (i.e., "Auditorium 1" configuration of Figure 15: Digital Cinema Auditorium Security Implementations) do not use link encryption, it shall be assured that such IMBs do not operate unless integrated within an approved projector. Similarly, IMBs intended for link encryption architectures shall not operate outside of a link encryption environment.
 
IMBs intended to operate within a fully integrated projection system architecture shall be designed such that they do not perform any composition decryption functions until integrated with a projector SPB.
 
IMBs intended to support link encryption architectures (i.e., "Auditorium 2" configuration of Figure 15) shall not support, or be reconfigurable to support (by other than the IMB manufacturer), fully integrated projection system architectures.

50

116 Section 9.4.3.6.3

Item # 5 of this section is replaced with:

Perform media decryption for image, audio and subtitle essence. Perform forensic marking for image and audio essence.

51

116 Section 9.4.3.6.3

The last sentence of item # 7 of this section is replaced with:

When integrated within a projector as the projector's companion SPB, the IMB shall provide 24/7 log recording support, and storage of all log records associated with the projector SPB.

52

116-117 Section 9.4.3.6.5

The existing title and text for this section is deleted and replaced with the following title and text:

9.4.3.6.5. Projector Authentication

Where link encryption is used, authentication of the projection system to the SM is required. The "proxy mode" of authentication is herein defined as the use of the companion LDB and its TLS session to proxy for the projector SPB.
 
Proxy mode authentication of the projection system is accomplished as follows: LDB certificate information is delivered to the SM during the LDB's TLS session initiation handshake. The projector's certificate information is subsequently delivered to the SM using the GetProjCert Standardized Security Message (see Section 9.4.5.2.4 "Request Response Pairs").
 
For married projection systems that use link encryption, projection system authentication shall be according to proxy mode. The SM shall ensure that both the LDB and projector SPB certificate thumbprints are on the TDL prior to enabling playout.
 
When the SM is the companion SPB (i.e., architectures with no link encryption), the projector's certificate information shall be obtained by the SM directly over the marriage connection. The SM shall ensure that the projector certificate thumbprint is on the TDL prior to enabling playout.

53

117 SectiSection 9.4.3.6.6

Last line, delete the words, "and Certification".

54

118 Section 9.4.4

The second sentence of the first paragraph is replaced with:

"The Security Manager (SM) shall enforce link encryption operations per the requirements of this section in all applications except for fully integrated architectures (i.e., "Auditorium 1" configuration of Figure 15: Digital Cinema Auditorium Security Implementations)."

55

119 Section 9.4.4

The second to the last paragraph (below the two bullets) is replaced with:

"Link Encryption shall be implemented according to RDD 20-2010 SMPTE Registered Disclosure Document: 'CineLink 2 Specification.' Link Encryption keys shall be generated according to the requirements of Section 9.7.6 'Key Generation and Derivation.' Link Encryption keys shall be distributed using the appropriate Standardized Security Messages of Section 9.4.5.2.4 'Request-Response Pairs' (and shall not be distributed using in-band techniques). The individual requirements of this specification shall take precedence over RDD 20-2010 as a whole."

56

120 Section 9.4.5.1 The opening paragraph of this section is deleted.

57

120 Section 9.4.5.2

The first sentence of this section is replaced with:

"This section identifies the set of Intra-Theater Messages standardized by this specification."

58

123 Section 9.4.5.2.4

The following command is added at the bottom of the category 2 (IMB SM to SPB) commands in Table 15:

GetProjCert - Requests the LDB to deliver a copy of the projector certificate

59

123 Section 9.4.5.3.2

The title of this section is changed to:

Image Media Block Security Messaging

60

124 Section 9.4.5.3.2
Note errata 26 added fifth bullet.

The following is added as a sixth bulleted item:

  • The GetProjCert RRP command of Table 15 shall be implemented as follows:
[GetProjCert command (see below) placed here.]

Errata 60, Page 124, Section 9.4.5.3.2

GetProjCert Command
The GetProjCert command returns the projector SPB certificate from the Link Decryptor Block (LDB) over the LDB's TLS connection with the Security Manager. The certificate returned shall be from the projector (SPB) to which the LDB is currently married. This command shall fail if the LDB is not in an actively married state. (The references to SMPTE 430-6-2008 are informative.)
 
GetProjCert Request

Item Name

Type

Length

UL

Description

GetProjCert Request

Pack Key

16

 

Identifies the GetProjCert Request *

Request Length

BER Length

4

 

Pack Length

Request ID

Uint32

4

 

ID of this request

* Bytes 12 and 13 shall be 02 and 18. (See SMPTE 430-6-2008, Tables A-1, A-2)

GetProjCert Response

Item Name

Type

Length

UL

Description

GetProjCert Response

Pack Key

16

 

Identifies
GetProjCert Response *

Response Length

BER Length

4

 

Pack Length

Request ID

Uint32

4

 

ID of the request for which this is the response

Projector Certificate Data

Byte Array

Variable

 

DER encoded certificate

Response

Uint8

1

 

Response Info **

The length of the certificate is determined from the length of the response.
* Bytes 12 and 13 shall be 02 and 19. (See SMPTE 430-6-2008, Tables A-1, A-2)
** Response (see SMPTE 430-6-2008 Section 6.3):
0 - RRP successful
1 - RRP failed
2 - RRP Invalid
3 - ResponderBusy

61

124 Section 9.4.5.3.2

The following is added as a seventh bulleted item:

  • For mutual authentication during TLS session establishment in dual certificate Image Media Block (IMB) implementations (see Section 9.5.1.2 "Dual Certificate Implementations") the SM shall present IMB certificates as follows:
      1. SM establishes the TLS session with a remote SPB (SM is the "TLS client") - The Log Signer Certificate (LS Cert) shall be presented.
      2. SMS establishes the TLS session with SM (SM is the "TLS server") - The SM Certificate (SM Cert) shall be presented.

62

128 Section 9.4.6.2
Subsection 1

Delete the word "indicator".

63

128-129 Section 9.4.6.2
Subsection 3

Replace with:

3. Forensic Marking shall otherwise be applied to all encrypted picture and audio content, except as follows:
a. The "no FM mark" and "selective audio FM mark" state shall be commanded by the 'ForensicMarkFlagList' element of the KDM.
b. When the KDM 'ForensicMarkFlagList' indicates the "no FM mark" command, the FM device(s) shall enter a full bypass mode, and not impose any mark onto the content essence for the associated encrypted DCP.
c. When the KDM 'ForensicMarkFlagList' indicates the "selective audio FM mark" command, the audio FM device(s) shall not impose, in the associated encrypted DCP, any mark onto audio channels above the channel indicated in the command, per (d) below. This paragraph shall override (b) above if both the "no FM mark" and "selective audio FM mark" commands are present.
d. The "selective audio FM mark" command shall be indicated by the presence of a ForensicMarkFlag element containing a URI of the form: https://www.dcimovies.com/430-1/2006/KDM#mrkflg-audio-disable-above-channel-XX where XX is a value in the set {01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16 ... 99} and corresponds to a channel identifier within the track, per 382M-2007 table E.1, as wrapped in a Sound Track file of the associated encrypted DCP. URIs of this form shall be used in conjunction with keys of KeyType "MDAK". A KDM shall carry only one such ForensicMarkFlag element.

64

129 Section 9.4.6.2
Subsection 9

Replace with:

Notwithstanding the exceptions defined in §9.4.6.2.3, all audio essence shall be forensically marked, up to sixteen channels.

65

131 Section 9.4.6.3.1

The following sentence is added after the existing sentence of item #13:

Log records shall be signed only by a Security Manager (SM).

66

131 Section 9.4.6.3.3

The entire section (including the title) is replaced with:

9.4.6.3.3 Log Signatures and Integrity Controls
 
Log signatures and integrity controls shall be compliant with SMPTE 430-5-2008 D-Cinema Operations - Security Log Event Class and Constraints for D-Cinema.
 
For dual certificate Image Media Block (IMB) implementations (see Section 9.5.1.2 "Dual Certificate Implementations"), the following requirements are in addition to those in SMPTE 430-5-2008:
 
  • The LogReport element shall contain the reportingDevice child element as defined in SMPTE 430-4-2008 "D-Cinema Operations - Log Record Format Specification". The reportingDevice element shall be completed as follows (see SMPTE 433-2008 "D-Cinema - XML Data Types"): In the case that the DeviceIdentifier element contains a UUID, the DeviceCertID element shall also be present and shall contain the certificate thumbprint of the SM Certificate. In the case that the DeviceIdentifier element is a certificate thumbprint, it shall contain the certificate thumbprint of the SM Certificate. In either case the certificate thumbprint of the Log Signer Certificate shall be present in the AdditionalID element, encoded as an XML Schema ds:DigesValueType type.
  • Log records shall be signed per the requirements of SMPTE 430-5-2008 section 6.2 "Log Record Authentication and Chaining" using the device's Log Signer Certificate.

67

132 Section 9.4.6.3.7

The entire section (including the title) is replaced with:

9.4.6.3.7 Security Log Reports
 
The Image Media Block (IMB) SM shall provide (export) log event information in the form of log reports (not log records) as defined in SMPTE 430-5-2008 D-Cinema Operation - Security Log Event Class and Constraints for D-Cinema.
 
The EventID (see SMPTE 430-4-2008 D-Cinema Operations - Log Record Format Specifications) shall be a single, invariant value that uniquely identifies each logged event. For avoidance of doubt, for a given event the EventID shall be the same value each time it appears in a log report.

68

133 Section 9.4.6.3.8 Erratum # 29 is deprecated, and the existing Table 19 (Security Log Event Types and Subtypes) and associated footnotes are replaced with the following table: [ See Table 19 below .]
Table19

Errata 68, page 133, Section 9.4.6.3.8

 

IMB

LDB

LD/LE SPB

Proj. SPB

Playout Event Sub Types

FrameSequencePlayed

X

 

 

 

CPLStart

X

 

 

 

CPLEnd

X

 

 

 

PlayoutComplete

X

 

 

 

 

Validation Event Sub Types

CPLCheck

X

 

 

 

 

Key Event Sub Types

KDMKeysReceived

X

 

 

 

KDMDeleted

X

 

 

 

 

ASM Event Sub Types

LinkOpened

X

X

X

 

LinkClosed

X

X

X

 

LinkException

X

X

X

 

LogTransfer

X

X

X

 

KeyTransfer

X

X

X

 

 

Operations Event Sub Types

SPBOpen

 

 

 

X 1

SPBClose

 

 

 

X 1

SPBMarriage

X2

X

 

 

SPBDivorce

X2

X

 

 

SPBShutdown

X

X

X

 

SPBStartup

X

X

X

 

SPBClockAdjust 3

X

X

X

 

SPBSoftware

X

X

X

 

SPBSecurityAlert

X

X

X

 

Table 19: Security Log Event Types and Subtypes

1The SPBOpen and SPBClosed event types shall be detected by the projector SPB, and logged and reported by the projector's companion SPB. back to ref 1

2Applicable when no Link Encryption is used. back to ref 2

3 Applicable if the SPB has a clock that is adjustable. back to ref 3

69

133 Section 9.4.6.3.8

The following two sub-bullets are added to the first bulleted item of this section:

  • Recorded Exception token(s) shall include those that prevent an EventSubType from occurring. (For example, LinkOpened and FrameSequencePlayed EventSubTypes define Exceptions that prevent the link from opening or playout from occurring.)
     
  • For the CPLCheck and KDMKeysReceived EventSubTypes, SMPTE 430-5 requires certain values from the input document to be recorded as parameters of the log record. In the case that an exception is recorded for these EventSubTypes, syntactically recognizable data items in the input document shall be recorded. (For example, when a KDMFormatError is recorded because the KDM's signing certificate has expired but the document is otherwise valid, the KDM's MessageId shall be present in the log record.)

70

134-135 Section 9.5.1

The text of this section shall be replaced in its entirety with:

Digital certificates are the means by which the Security Manager (SM) identifies other security devices. They are also used to sign security log records and in establishing Transport Layer Security (TLS) connections. This specification originally required each Secure Processing Block (SPB) to carry a single digital certificate to support each of these requirements. However, in some circumstances (e.g., new equipment designs and/or upgrades) evolving Federal Information Processing Standards (FIPS) have imposed the need for use of a second digital certificate within the Image Media Block (IMB). (FIPS requirements are addressed in Sections 9.5.2 "Robustness and Physical Implementations" and 9.7 "Essence Encryption and Cryptography.")
 
To maintain compliance with FIPS requirements, this specification now includes requirements for both single and dual IMB certificate use. Equipment vendors shall solicit FIPS expertise for guidance as to which approach is required for their implementation.
 
All Digital Cinema certificates shall use the X.509, Version 3 ITU standard (see [ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997, and RFC3280]). Detailed specifications for Digital Cinema digital certificates are given in Section 9.8. Except as otherwise specified below, the requirements for all digital certificates (i.e. both single and dual use implementations) shall be the same.
 
9.5.1.1 Single Certificate Implementations
 
Single certificate implementations shall employ one Digital Cinema certificate in each Secure Processing Block (SPB). The requirements for use of a single SPB certificate are provided in the appropriate sections of this specification.
 
The identity of a device shall be represented by its certificate. The make, model and serial number of each certificated device shall be carried in the Common Name (CN) of the assigned certificate. This information (or information uniquely traceable by the manufacturer to the certificate CN) shall be placed on the exterior of each device in a manner that is easily read by a human.
 
Each SPB shall enumerate the security functions of the SPB according to SMPTE 430-2 D-Cinema Operations - Digital Certificate, section 5.3.4 Naming and Roles. For purposes of efficiency, SE types shall be minimally designated according the following roles (the designation of other roles is optional):
 
  • Image 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
9.5.1.2 Dual Certificate Implementations
 

Dual (two) certificates are used only with the Image Media Block (IMB), and no other SPB types are affected. Dual certificate implementations split the utility of digital certificates between the two certificates. Dual certificate utility shall be as follows:
  • Security Manager Certificate (SM Cert) - The SM Cert shall be used according to the same requirements as those for the above Section 9.5.1.1 Single Certificate Implementation, except for those functions specified for the below Log Signer Certificate. The SM Cert shall be the certificate associated with the identity of the IMB and shall be the target of Key Delivery Messages (KDM).
     
  • Log Signer Certificate (LS Cert) - The LS Cert shall be used to 1) sign security log records per the requirements of Section 9.4.6.3.3. "Log Signatures and Integrity Controls" and 2) perform TLS session establishment functions per the requirements of 9.4.5.3.2 "Image Media Block Security Messaging." Details of these requirements are provided in the noted sections.

 
The Log Signer Certificate shall enumerate roles only as follows:
  • LS - Log Signer; all implementations
  • LS LE - Log Signer for IMB with Link Encryptor

71

135 Section 9.5.2.1

The entire section (including the title) is replaced with:

9.5.2.1 Device Perimeter Definitions
 
Security equipment designs must provide physical perimeters around secrets not cryptographically protected. The following definitions explain terminology used for tamper protection of physical perimeters. Specific tamper requirements for SPB types 1 and 2 are given in subsequent sections of 9.5.2.
Tamper evident - Penetration of the security perimeter results in 
  permanent alterations to the equipment that are apparent upon 
  inspection. This is the least robust perimeter, since it only 
  reveals an attack after-the-fact, and depends on a specific 
  inspection activity.

Tamper resistant - The security perimeter is difficult to penetrate 
  successfully. Compromise of effective tamper resistant designs 
  requires the attacker to use extreme care and/or expensive tooling 
  to expose secrets without physically destroying them and the 
  surrounding perimeter(s).

Tamper detecting and responsive - The security perimeter and/or access 
  openings are actively monitored. Penetration of the security perimeter 
  triggers erasure of the protected secrets.

72

137-138 Section 9.5.2.4

The following replaces all text following the first paragraph of this section:

Requirements for projection systems were 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 section 9.4.3.6.1:
  • 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 the companion SPB's output image essence signal and/or the projector SPB access opening detection circuits and associated signals.
     
    For non-security servicing (i.e. maintenance), the above signals / circuits 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 the non-security related maintenance accessible areas, and access to security related areas shall not be possible without causing permanent and easily visible damage.
     
    Security servicing shall be performed only under the supervision of the projector manufacturer per Section 9.5.2.3 "Repair and Renewal."

     
  • Projector SPB access doors or panels shall be lockable using pick-resistant mechanical locks employing physical or logical keys, or shall be protected with tamper-evident seals (e.g., evidence tape or holographic seals).
     
  • Protection from external probing of security-sensitive signals (i.e., image essence and access opening / detecting circuits and 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 maintenance access and access door opening detection, and the internal design enables access for non-security related servicing. Exhibition visual inspection is relied upon to detect physical abuse that might allow compromise of, or access to, decrypted image essence.

73

141 Section 9.5.5

Delete the words "and Certification" from the title.

74

142 Section 9.5.5

Delete the following sentence from the penultimate paragraph:

"Such issuance enables the devices to become certified."

75

148 Section 9.7.5

The following is added as a new opening paragraph to this section:

"FIPS requirements may obsolete or replace certain older cryptographic technologies or standards, rendering them unacceptable for use. The requirements of this section shall be superseded by the FIPS 140-2 or FIPS 140-3 requirements in effect as of the date of FIPS compliance testing and certification per Section 9.5.5 "Compliance Testing and Certification." Equipment suppliers are cautioned to take into consideration NIST and FIPS transition timing and FIPS validation lead times."

76

148 Section 9.7.6

The following sentences are appended to the end of the opening paragraph of this section:

"FIPS requirements may obsolete or replace certain older cryptographic technologies or standards, rendering them unacceptable for use. The requirements of this paragraph shall be superseded by the FIPS 140-2 or FIPS 140-3 requirements in effect as of the date of FIPS compliance testing and certification per Section 9.5.5 "Compliance Testing and Certification." Equipment suppliers are cautioned to take into consideration NIST and FIPS transition timing and FIPS validation lead times."

ERRATA

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. March 07 2008



ERRATA 1-15 TO DCI DIGITAL CINEMA SYSTEM SPECIFICATION, VERSION 1.2



ERRATA 16-20 TO DCI DIGITAL CINEMA SYSTEM SPECIFICATION, VERSION 1.2



ERRATA 21-33 TO DCI DIGITAL CINEMA SYSTEM SPECIFICATION, VERSION 1.2



ERRATA 34-76 TO DCI DIGITAL CINEMA SYSTEM SPECIFICATION, VERSION 1.2



ERRATA 77 TO 87 DCI DIGITAL CINEMA SYSTEM SPECIFICATION, VERSION 1.2



ERRATA 88 TO 89 DCI DIGITAL CINEMA SYSTEM SPECIFICATION, VERSION 1.2


ERRATA 90 TO 96 DCI DIGITAL CINEMA SYSTEM SPECIFICATION, VERSION 1.2