DCI Specs - Digital Cinema Initiatives

Figure 15 presents the two fundamental auditorium security system architectures, with andwithout Link Encryption, and the security message types ETM and ITM. This diagram doesnot attempt to detail functions that are unrelated to security (e.g., decoding), but doesanticipate such functions by noting where plain text content exists.Though not shown in Figure 15: Digital Cinema Auditorium Security Implementations, but asindicated in the requirements above, every auditorium shall support image, audio, andsubtitle decryption 17 , and image and audio Forensic Marking.9.4.1.1. Architecture Description and CommentsThe security architecture descriptions and requirements revolve around twoembodiments: the SPB and the SE. As defined in Section 9.3.3 Security Messaging andSecurity Entities, SEs are logical devices that perform specific security functions. Theyare logical because these specifications do not dictate how SEs are actually designed,and more than one type of SE may be implemented within a single circuit.All functional Security Entities (SEs) (except the SMS) shall be contained within SPBs,which provide physical protection for the Security Entities (SEs). The SPB is itself aliteral SE Type – its security function is physical protection. The Security Entities (SEs)and SPB type 1 and type 2 containers are depicted in Figure 15: Digital CinemaAuditorium Security Implementations. This figure shows that there are only threepermitted physical protection scenarios:• No physical protection required – Screen Management System (SMS)• SPB type 1 protection required – Image Media Blocks and Link Decryptor Blocks• SPB type 2 protection required – Content essence entering the projector from anIMB or LD Block.These requirements are more fully defined in the SM and SPB functional requirementsbelow (see Section 9.5 Implementation Requirements).Note: The security network is shown (in red) in Figure 15: Digital Cinema AuditoriumSecurity Implementations. This is described below as operating under Transport LayerSecurity (TLS), a readily available and well known protocol standard for providingprotection between application layer processes that must communicate betweendevices, in this case between auditorium devices (Secure Processing Blocks) performingsecurity functions. 18As part of TLS session establishment, each party to the session presents its digitalcertificate to the other. In this fashion, the IMB Security Manager identifies the otherSPBs in the auditorium, and mutual authentication is accomplished (see Section 9.4.3.1Transport Layer Security (TLS) Establishment and Secure Processing Block (SPB)Authentication and Section 9.4.5.1 Transport Layer Security Sessions, End Points andIntra-Theater Messaging). Although the SM may establish secure TLS communicationswith an SPB, it will not “trust” (approve) that SPB for content playback functions until theidentity of such SPB appears on the appropriate Trusted Device List (TDL) for theparticular composition (see Section 9.6.2 “Trust” and the Trusted Device List (TDL)).17 Subtitle encryption is directed primarily against interception during transport, and cryptographic protection within thetheater is not required. For example, plaintext subtitle content may be transmitted from a server device to a projection unit.It is preferred, but not required, that subtitle content be maintained in encrypted form except during playback.18 Transport Layer Security (TLS) can be viewed as an extension of the SPB physical protection container, but forcommunications, a “steel pipe” that surrounds the wire between devices. Thus, these specifications define both physicaland logical protection mechanisms for all security and playback processes.DCI Digital Cinema System Specification v.1.2 Page 98