Digital Cinema Initiatives, LLC (DCI) is the author and creator of this specification for the purpose of copyright and other laws in all countries throughout the world. The DCI copyright notice must be included in all reproductions, whether in whole or in part, and may not be deleted or attributed to others. DCI hereby grants to its members and their suppliers a limited license to reproduce this specification for their own use, provided it is not sold. Others should obtain permission to reproduce this specification from Digital Cinema Initiatives, LLC.
This document is a specification developed and adopted by Digital Cinema Initiatives, LLC. This document may be revised by DCI. It is intended solely as a guide for companies interested in developing products, which can be compatible with other products, developed using this document. Each DCI member company shall decide independently the extent to which it will utilize, or require adherence to, these specifications. DCI shall not be liable for any exemplary, incidental, proximate or consequential damages or expenses arising from the use of this document. This document defines only one approach to compatibility, and other approaches may be available to the industry.
This document is an authorized and approved publication of DCI. Only DCI has the right and authority to revise or change the material contained in this document, and any revisions by any party other than DCI are unauthorized and prohibited.
Compliance with this document may require use of one or more features covered by proprietary rights (such as features which are the subject of a patent, patent application, copyright, mask work right or trade secret right). By publication of this document, no position is taken by DCI with respect to the validity or infringement of any patent or other proprietary right. DCI hereby expressly disclaims any liability for infringement of intellectual property rights of others by virtue of the use of this document. DCI has not and does not investigate any notices or allegations of infringement prompted by publication of any DCI document, nor does DCI undertake a duty to advise users or potential users of DCI documents of such notices or allegations. DCI hereby expressly advises all users or potential users of this document to investigate and analyze any potential infringement situation, seek the advice of intellectual property counsel, and, if indicated, obtain a license under any applicable intellectual property right or take the necessary steps to avoid infringement of any intellectual property right. DCI expressly disclaims any intent to promote infringement of any intellectual property right by virtue of the evolution, adoption, or publication of this document.
A number of significant technology developments have occurred in the past few years that have enabled the digital playback and display of feature films at a level of quality commensurate with that of 35mm film release prints. These technology developments include the introduction of: high-resolution film scanners, digital image compression, high-speed data networking and storage, and advanced digital projection. The combination of these digital technologies has allowed many impressive demonstrations of what is now called “Digital Cinema.” These demonstrations, however, have not incorporated all of the components necessary for a broad-based commercially viable Digital Cinema system. These demonstrations have created a great deal of discussion and confusion around defining the quality levels, system specifications, and the engineering standards necessary for implementing a comprehensive Digital Cinema system.
Digital Cinema Initiatives, LLC (DCI) is the entity created by seven motion picture studios: Disney, Fox, Metro-Goldwyn-Mayer[1], Paramount Pictures, Sony Pictures Entertainment, Universal Studios, and Warner Bros. Studios. The primary purpose of DCI is to establish uniform specifications for Digital Cinema. These DCI member companies believe that the introduction of Digital Cinema has the potential for providing real benefits to theater audiences, theater owners, filmmakers and distributors. DCI was created with recognition that these benefits could not be fully realized without industry-wide specifications. All parties involved in the practice of Digital Cinema must be confident that their products and services are interoperable and compatible with the products and services of all industry participants. The DCI member companies further believe that Digital Cinema exhibition will significantly improve the movie-going experience for the public.
The document defines technical specifications and requirements for the mastering of, distribution of, and theatrical playback of Digital Cinema content. The details are in the following sections:
This document consists of normative text and, optional informative text. Normative text is text that describes the 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 the document is, by default, normative except: any section titled “Introduction”, any section explicitly labeled as “Informative”, or individual paragraphs that start with the word “Note.” Normative references are those external documents referenced in normative text and are indispensable to the user. Informative, or bibliographic, references are those references made from informative text or are otherwise not indispensable to the user.
The keywords “shall” and “shall not” indicate requirements that must be strictly 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. In the negative form, a certain possibility or course of action is deprecated but not prohibited.
The keywords “may” and “need not” indicate a course of action permissible within the limits of the document.
The keyword “reserved” indicates that a condition is not defined and shall have no meaning. However, it may be defined in the future. The keyword “forbidden” is the same as reserved, except that the condition shall never be defined in the future.
A compliant implementation is one that includes all mandatory provisions (“shall”) and, if implemented, all recommended provisions (“should”) as described. A compliant implementation need not implement optional provisions (“may”).
Requirements are indicated with the key phrases “is required to”, “is encouraged to” and “can” which represent “shall,” “should” and “may” (had the text been in a separate requirements document). This is necessary in order to distinguish requirements from the specification conformance language.
Sentences with the following keywords are italics: shall, shall not, should not, is required, is not required, is not encouraged and is encouraged.
The names of standards publications and protocols are placed in [bracketed text]. International and industry standards contain provisions, which, through reference in this text, constitute provisions of this specification. The most recent editions of the referenced standards shall be valid unless otherwise exempted in this specification. These referenced standards are subject to revision, and parties to agreements based upon this specification are encouraged to investigate the possibility of applying the most recent editions of the referenced standards. Section 10. is a glossary of technical terms and acronyms used throughout this specification. The reader is encouraged to refer to the glossary for any unfamiliar terms and acronyms.
Trademarked names are the property of their respective owners.
Portions of SMPTE standards are incomplete with respect to many behavior requirements, the subjects of which are typically addressed by SMPTE as "Informative" text and informative "Notes." Sections of this DCI Specification identify normative requirements that shall take precedence over such SMPTE "Informative" text and informative "Notes."
At the onset of writing a specification for a Digital Cinema system, DCI acknowledged certain fundamental requirements, which are:
For the purpose of documenting the specific requirements and specifications for a Digital Cinema system, it is helpful to divide the system into a set of components[2] , which are:
A functional framework of a Digital Cinema encoding and a decoding system are shown below in Figure 1: System Overview Functional Encode Flow and Figure 2: System Overview Functional Decode Flow.
The Digital Source Master (DSM) is created in post-production and can be used to convert into a Digital Cinema Distribution Master (DCDM). The DSM can also be used to convert to a film duplication master, a home video master, and/or a master for archival purposes. It is not the intention of this document to, in any way, specify the DSM. This is left to the discretion of the content provider. The content could come from a wide range of sources with a wide range of technical levels.
When discussing Digital Cinema content, it was realized that other content besides feature films would make use of the same digital system. Therefore, a new term was created to refer to any content that would have similar requirements to feature film content. The term “Composition” refers to all of the essence and metadata required for a single presentation of a feature, or a trailer, or an advertisement, or a logo to create a presentation using a digital system. This term will be used throughout this document and is intended to refer to a single element such as one and only one feature, trailer, advertisement or logo.
This document specifies a DCDM for the purpose of exchanging the image, audio and subtitles to encoding systems and to the Digital Cinema playback system. The DCDM is the output of the Digital Cinema post-production process (not to be confused with the feature post-production process, which creates the DSM) and is the image structure, audio structure, subtitle structure. These structures are mapped into data file formats that make up the DCDM. This master set of files can then be given a quality control check to verify items like synchronization and that the composition is complete. This requires the DCDM files to be played back directly to the final devices (e.g., projector and sound system) in their native decrypted, uncompressed, unpackaged form.
Once the DCDM is compressed, encrypted and packaged for distribution, it is considered to be the Digital Cinema Package or DCP. This term is used to distinguish the package from the raw collection of files known as the DCDM. Shown below is a typical flow for Digital Cinema. When the DCP arrives at the theater, it is eventually unpackaged, decrypted and decompressed to create the DCDM*, where DCDM* image is visually indistinguishable from the original DCDM image.
DSM → DCDM → DCP → DCDM* → Image and Sound
Note: Integrated projector and Media Blocks are strongly recommended. However in the exclusive case to accommodate a 2K, 48 FPS, 12 bit DCDM to use [SMPTE 372M Dual Link HD-SDI] as an interface, it is acceptable, but not recommended, to allow 10 bit color sub-sampling to create the DCDM* at the output of the Image Media Block decoder. This bit depth reduction and color subsampling is only allowed in the single combination of a DCDM at 2K, 48 FPS being transported over a link encrypted SMPTE 372M connection.
The DCDM shall use a hierarchical image structure that supports both 2K and 4K resolution files (See Section 3.2.1. Image Concepts and Requirements) so that studios can choose to deliver either 2K or 4K masters and both 2K and 4K projectors can be deployed and supported. The supported mastering and projecting combinations are illustrated in Figure 3: Hierarchical Image Structure.
Media Blocks (MB) for 2K projectors are required to be able to extract and display the 2K-resolution component from the 2K/4K DCP file(s). Media Blocks for 4K projectors are required to be able to output and display the full 4K DCDM. In the case of a 2K DCDM, the output of the Media Block is a 2K image. It is the responsibility of the 4K projectors to up-sample the image.
This Digital Cinema system is built upon a data file-based design, i.e., all of the content is made up of data stored in files. These files are organized around the image frames. The file is the most basic component of the system.
This Digital Cinema system uses a store-and-forward method for distribution. This allows the files to be managed, processed and transported in non-real time. Non-real time could be interpreted as slower than real time, or faster than real time. After being transported to the theater, the files are stored on a file server until playback. However, during playback and projection, the Digital Cinema content plays out in real time.
Feature films have been sub-divided for some time into discreet temporal units for film systems called reels. This concept and practice will continue in use for the Digital Cinema system. In Digital Cinema, a reel represents a conceptual period of time having a specific duration chosen by the content provider. Digital Cinema reels can then be electronically spliced together to create a feature presentation.
For the purpose of interoperability, the hardware and software used in the Digital Cinema system shall be easily upgraded as advances in technology are made. Upgrades to the format shall be designed in a way so that content can be distributed and played on the latest hardware and software, as well as earlier DCI-compliant equipment installations.
The Digital Cinema system shall provide a reasonable path for upgrading to future technologies. It shall be based upon a component architecture (e.g., Mastering, Compression, Encryption, Transport, Storage, Playback, Projection), that allows for the components to be replaced or upgraded in the future without the replacement of the complete system. It is the intention of this Digital Cinema specification to allow for advances in technology and the economics of technology advancement.
Storage and Media Block are components of the theater playback system. Storage is the file server that holds the packaged content for eventual playback. The Media Block is the hardware device (or devices) that converts the packaged content into the streaming data that ultimately turns into the pictures and sound in the theater. These two components can be physically contained together or they can be physically separate from each other. Media Blocks are secure entities and the specific nature of that security is defined in Section 9. Security.
The Digital Cinema Distribution Master, or DCDM, is a collection of data file formats, whose function is to provide an interchange standard for Digital Cinema presentations. It is a representation of images, audio and other information, whose goal is to provide a complete and standardized way to communicate movies (compositions) between studio, post-production and exhibition. A specific instance of a DCDM is derived from a Digital Source Master (DSM) that is created as a result of a post-production assembly of the elements of a movie (composition). A DCDM can be transformed into a Digital Cinema Package for distribution to exhibition sites (see Section 5. Packaging). Alternatively, it can be sent directly to a playback system for quality control tasks.
For the purpose of documenting the specific requirements and specifications for the DCDM, it is helpful to divide the system into a set of components. The specifications and requirements for each of these components will be described in the following sections:
The Digital Cinema Distribution Master (DCDM) is the fundamental interchange element in the system. Since digital mastering technology will continue to change and develop with time, the DCDM is designed to accommodate growth. There are several areas that will be affected by the progression of the mastering technology, such as color space, resolution, sampling frequencies, quantizing bit depths and interfaces.
In the process of creating feature films, a Digital Source Master, or DSM, is produced. The DSM creates many elements (e.g., Film Distribution Masters, DCDM, Home Video Masters and Broadcast Masters). It is not the goal of this specification to define the DSM. Instead, it is recognized that the DSM can be made of any color space, resolution, sampling frequency, color component bit depths and many other metrics.
If the content does not meet this DCDM specification, it is the content provider’s responsibility to convert the DSM into the DCDM specification, defined in this section, before it can be used in the Digital Cinema system.
A set of DCDM files (image, audio, subtitles, etc.) contains all of the content required to provide a Digital Cinema presentation. The DCDM provides two functions, an interchange file format, and a playback format that is directly sent from the Media Block to the projector (this is referred to as DCDM*). For use in interchange, the encoding process can be performed in real time or non-real time. For use in playback, the DCDM* is logically required to playback in real time.
Metadata within the DCDM provides a method to synchronize image, audio and subtitles. This method is used to synchronize the tracks in order to maintain frame-based lip sync from the beginning to the end of a presentation. This is different from the requirement to synchronize the system clocks of different pieces of equipment to run at consistent frequencies. The first part addresses the packaging of the picture, sound and subtitles in such a way as to establish and maintain a timing relationship between these tracks of essence. The second part addresses the inter-operability of equipment in a theater system and is therefore discussed in Section 7. Theater Systems.
The DCDM is required to use a common standardized file format for each element (image, audio, subtitles, etc.). The DCDM image file format is required to be an MXF-conformant file, based on existing SMPTE standards. The DCDM audio file format is required to be based on Broadcast Wave.
The DCDM image structure is required to support a frame rate of 24.000 Hz. The DCDM image structure can also support a frame rate of 48.000 Hz for 2K image content only. The frame rate of any individual DCDM master is required to remain constant. Metadata is carried in the image data file format to indicate the frame rate.
Files within the DCDM set are required to carry information to provide for frame-based synchronization between each file. At a minimum, they are required to include a “start of file” and a continuous frame count.
This section defines a common interchange for Digital Cinema uncompressed image structures and files. This includes an image structure, aspect ratios, common color space, bit depth, transfer function, and the file format required to present content properly to a Digital Cinema projector.
The SMPTE published standard "SMPTE 428-1: D-Cinema Distribution Master - Image Characteristics" shall be utilized.
The DCDM image file format is mapped into TIFF.
The DCDM Image Structure shall be mapped into the TIFF Rev 6.0 File Format and further constrained as follows:
The DCDM file format is required to contain metadata that allows for synchronization of the images with other content:
Image information and parameters, required to successfully interchange the DCDM Image Structure, shall be provided to the mechanism that will ingest the DCDM.
Each frame in the reel shall contain accurate and complete metadata, but it is permissible to read and extract the reel-based metadata from the first frame of a reel to use as a metadata “slate” for the rest of the frames in the reel.
The information, as shown in Table 4 below, is the minimum required information to successfully interchange files.
Data Element Name | Data Element Definition |
---|---|
Active Horizontal Pixels (Ph) | Total number of active horizontal pixels in the image container |
Active Vertical Pixels (Pv) | Total number of active vertical pixels in the image container |
Frame Rate | The rate that images are to be projected, expressed in frames per second |
Frame Count | The integer number of frames in a sequence |
Digital Cinema audio requires standardized characteristics, channel mapping and a file format to successfully playback in a motion picture theater.
The SMPTE published standard "SMPTE 428-2: D-Cinema Distribution Master - Audio Characteristics" shall be utilized.
If a media block supports 96 kHz audio, it shall be able to perform sample rate conversion to 48 kHz or 96 kHz at the output when necessary.
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.
The audio file format shall comply with the Broadcast Wave file format (.wav), per [ITU Tech 3285 version 1 (PCM WAVE coding)], is extended and constrained as further described here.
The audio file shall remain uncompressed throughout the Digital Cinema system. This shall include packaging, distribution and storage.
The Broadcast Wave (.wav) file is required to contain metadata that indicates the first sample of audio data. The metadata is also required to contain a continuous frame count relative to the image as well as the sample rate.
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.
Digital Cinema has a subtitling system that can convey multiple languages. Along with subtitling, there are text localizations, titling and captioning that may also be a part of the new Digital Cinema experience. However, captioning and subtitling are identified as two separate systems having different roles in the presentation of content and may have different methods of rendering.
Traditionally, the audience for captioning is the deaf and hard of hearing (D/HOH). The delivery can be done in different ways. These include closed systems that are optional-to-the-viewer delivery and are usually displayed on a personal device (such as a wireless receiver), or delivery to an obscured device that is viewable with an appliance (such as a rear-wall display viewed through a mirror).
Subtitling is generally associated with a foreign language translation for localizing a movie in a particular geographic territory. Subtitles are typically open or displayed on the screen as part of the movie, without option. Subtitling and localizations are generally designed for a particular look with creatively chosen fonts and drop shadows.
With captioning, the source language (what is spoken in the movie) and the target language (what appears as captions) are most often, as in the case of English, the same. For subtitling, the source language and target language are different because the goal of subtitling is to translate the movie.
Subtitles and captions, if supplied, may be one or more of the following:
Section 3.4.2. below defines the subpicture specifications, while Section 3.4.3. Timed Text Concepts and Requirements, defines the specification for Timed Text streams, which can be used for either subtitles or captions or both. Burned-in subtitles are not addressed since they are something that would occur in the mastering of the content and would be inherent in the image.
A subpicture data stream is a multiple-image data stream intended for the transport of visual data supplemental to a motion picture. The data is designed for graphic overlay with the main image of a Digital Cinema motion picture. It is designed only for an open display and not for a closed display. It is envisioned that the subpicture data stream, when employed, will typically be used for the transport of subtitle data.
Subpicture data is required to be encoded as a standardized, XML-based document. Such a standard is required to define both Timed Text and subpicture encoding methods allowing mixed-media rendering. Subpicture frames are required to be encoded as [ISO/IEC 15948:2004] PNG files.
The PNG file is required to be rendered with knowledge of color space and pixel matrix of the DCDM. The PNG file is required to be mastered at the same resolution as the DCDM.
For example, a DCP containing a 4K master will require 4K PNG files and no other resolution PNG files. When played on a 2K projector, it is the responsibility of the 2K projection system to downsample the 4K PNG files such that they display with the correct size with respect to the image data. And, a DCP containing a 2K master will require 2K PNG files and no other resolution PNG files. When played on a 4K projector, it is the responsibility of the 4K projection system to upsample the 2K PNG files appropriately.
The XML navigation file specifies the temporal resolution of the subpicture file. A Frame count, Time In, Time Out, Fade Up Time and Fade Down Time, which correspond to the image, shall be included. The subpicture frame rate shall be equal to the frame rate of the associated DCDM image file.
The equipment or system that encodes or decodes the subpicture file is required to ensure that temporal transitions within the subpicture file are correctly synchronized with other associated DCDM files. The Digital Cinema equipment and subpicture file is required to re-synchronize after a restart of the system.
Timed Text (e.g., captions and/or subtitles) is text information that may be presented at definite times during a Digital Cinema presentation.
Timed Text data is required to be encoded as a standardized, XML-based document.
Note: This provides for presentation via:
The Digital Cinema equipment and Timed Text file is required to re-synchronize after a restart of the system.
Font files are required to be used to render Timed Text for subtitle applications. Font files can be used to render Timed Text for caption applications. When used, font files are required to conform to [ISO/IEC 14496-22:2007(E) Information technology - Coding of audio-visual objects - Part 22: Open Font Format].Timed Text files are required to be accompanied by all font files required for reproduction of the Timed Text.
The Timed Text file format is required to support a default character set. It is required that there be a default Unicode™ character set and a default font for that character set.
In event that an external font file is missing or damaged, the subtitle rendering device is required to use a default font supplied by the manufacturer. The default character set is required to be a Unicode™ ISO Latin-1 character set. The default font is required to conform to [ISO/IEC 14496-22:2007(E) Information technology - Coding of audio-visual objects - Part 22: Open Font Format] and support the ISO Latin-1 character set.
The Timed Text format requires the cardinal language of the text to be identified.
A pure text stream is encouraged to isolate content from rendering markup for searchability.
The Timed Text format shall allow the display of multiple captions simultaneously. There shall be a maximum number of 3 lines of text allowed for simultaneous display.
Note: This allows for spatial representation for captions when two people are talking simultaneously.
The equipment or system that encodes or decodes the Timed Text file is required to ensure that temporal transitions within the data stream are correctly synchronized with other associated DCDM data streams.
Current day control systems, usually called automation systems, orchestrate theater sub-systems such as curtains, masking and lights. Digital Cinema control methods are expected to differ significantly from those found in theaters today. Supervisory types of control will be much broader in application than in today’s systems, allowing interface to specialized controls for theatrical events.
Many of these concepts and requirements are covered in Section 5. Packaging. and Section 7. Theater Systems. Some of the fundamental information pertaining to encoding is covered here, with the detailed information for its use covered in Section 7. Theater Systems.
Many of today’s automation controls are driven by a time-based event list such as the system's Show Playlist, and can be classified by their show control functions, as in the partial list below.
Show control events or cues are required for the theater system operator to pre-program the timing of show control events. Such events or cues may indicate events such as the beginning of the title, beginning of the intermission, beginning of the credits, and the end of the feature. The events or cues will normally be placed into the Digital Cinema Composition Playlist, as defined in Section 5. Packaging.
Image Compression for Digital Cinema uses data reduction techniques to decrease the size of the data for economical delivery and storage. The system uses perceptual coding techniques to achieve an image compression that is visually lossless. It is important to note that image compression is typically used to ensure meeting transmission bandwidth or media storage limitations. This results in image quality being dependent on scene content and delivered bit rate. Digital Cinema image compression is much less dependent upon bandwidth or storage requirements, thereby making bit rate dependent on desired image quality rather than the reverse.
The compression standard shall be JPEG 2000 (see [ISO/IEC 15444-1]).
All codestreams shall fully conform with [ISO 15444-1:2006 Amendment 1], as more fully constrained as follows:
Note: This POC marker segment ensures that all 2K data precede all 4K data. Within each portion (2K, 4K), all data for color component 0 precede all data for color component 1, which in turn precede all data for color component 2.
Main
Header |
Tile-part
Header |
2K_0 | Tile-part
Header |
2K_1 | Tile-part
Header |
4K_1 | Tile-part
Header |
4K_0 | Tile-part
Header |
4K_1 | Tile-part
Header |
4K_2 |
Note: This facilitates extraction of color components and resolutions (2K vs. 4K).
Note: For information purposes only, this yields a maximum of 250 Mbits/sec total and a maximum of 200 Mbits/sec for the 2K portion of each color component.
The DCDM, as stated in the System Overview, is a collection of files, such as picture essence files and audio essence files. These files, as they stand by themselves, do not represent a complete presentation. Synchronization tools, asset management tools, metadata, content protection and other information are required for a complete presentation to be understood and played back as it was intended. This is especially important when the files become compressed and/or encrypted and are no longer recognizable as image essence or audio essence in this state. Packaging is a way to organize and wrap this material in such a way as to make it suitable for storage and transmission to its destination, where it can be stored and then easily unwrapped for a coherent playback. In seeking a common interchange standard for Digital Cinema between post-production and exhibition, it is understood that there may be multiple sources of content, distributed by more than one distributor, shown in a single show. This will require special consideration to achieve DCP interchange. Thus, an interchange packaging structure is needed that operates across several domains. The section also provides a set of requirements for the Material eXchange Format (MXF) track file encryption. These requirements are complementary to the requirements in Section 9.7. Essence Encryption and Cryptography.
For the purpose of documenting the specific requirements for a Digital Cinema Packaging system, it is helpful to divide the system into a set of components. The performance requirements for each of these components will be described in the following sections:
Digital Cinema presents a challenge to create a versatile packaging system. Throughout this system, some basic requirements are needed and are stated below.
The Packaging standard is required to be based upon an open worldwide standard. This format is encouraged to be a license-free technology. It is required to be a complete standard that equipment receiving a compliant package can process and interpret unambiguously.
The Packaging format is required to have an open framework that accommodates compressed, encrypted files as well as all other files used in Digital Cinema.
The Packaging format is required to accommodate any number of essence or metadata components. There is no limit on the number of files included in the package or the size of the files.
The Packaging format is required to support content structure as needed during booking, fulfillment, show preparation, booking updates, secure licensed playback and logging.
The Packaging format is required to support integrity and security at two levels: (1) a basic level which can provide reasonable assurance of file integrity without reference to licenses or a Security Manager (SM), and (2) an engagement-specific level representing a particular business-to-business relationship.
The Packaging format is required to allow for new Digital Cinema features (compositions) to be contained within the package.
The Packaging format is required to provide support for synchronization of the essence and metadata elements.
Human readable metadata is required to be in English (default) but can be provided in other languages as well.
The packaging format is required to support unique and durable identification of assets and metadata using embedded unique identifiers. Throughout this document, the acronym “UUID“ shall mean a type 4 (pseudo-random) Universally Unique Identifier (UUID) as defined in [IETF RFC 4122].
It is common practice to divide a feature film into reels of between 10 and 20 minutes in length for post-production, and distribution. These reels are then assembled, together with other content, to create the modern platters that are used in exhibition today. This concept of reels is required to be supported with Digital Cinema content.
The Digital Cinema Packaging System is built on a hierarchal structure. The most basic element of the packaging system begins with track files. These are the smallest elements of a package that can be managed or replaced as a distinct asset. A track file can contain essence and/or metadata. Its duration is set to be convenient to the processes and systems that utilize it. These can be image tracks, audio tracks, subtitle tracks or any other essence and/or metadata tracks. A Composition Playlist specifies the sequence of track files that create sequence conceptual reels into a composition. This is illustrated in Figure 5. A Composition Playlist is created in the Digital Cinema mastering process to assemble a complete Composition.
This Composition consists of all of the essence and metadata required for a single presentation of a feature, or a trailer, or an advertisement, or a logo. A single Composition Playlist contains all of the information on how the files are to be played, at the time of a presentation, along with the information required to synchronize the track files. A Composition Playlist could consist of one reel or many reels. For encrypted essence, the Composition Playlist shall be digitally signed such that modifications to the Composition Playlist (and/or the associated composition) can be detected. There is a separate Composition Playlist for each version or language audio track of a motion picture/feature (composition). For example, a DCP of a feature film for the European market with French, Italian, German and Spanish audio tracks would contain four separate Composition Playlists, one for each sound track.
At the exhibition site, the Theater Management System (TMS) or Screen Management System (SMS) assembles the Show Playlist. A Show Playlist is created from individual Composition Playlists. The Show Playlist can also be created either on-site or off-site and interchanged as a file to one or more Screen Management Systems. One could have multiple Playlists as well. Figure 6 is an example of a Show Playlist consisting of multiple Composition Playlists.
The final element in the Packaging system is a Packing List for the distribution package. The Packing List contains information and identification about each of the individual files that will be delivered in a Digital Cinema Package (DCP). This allows for asset management and validation, including cryptographic integrity checking, for the received DCP. A feature can be sent in a single DCP or multiple DCPs and therefore could be listed in one or more Packing Lists. The Packing List can be sent ahead of the DCP, for asset management purposes. A diagram of a Packing List structure is shown in Figure 7: Example Distribution Package.
The Sound and Picture Track File is the fundamental element in the Digital Cinema packaging system. The Sound and Picture Track File structure and requirements are defined by the essence or metadata that they contain. Each of these essence or metadata containers could be image, sound, subtitle (Timed Text and/or subpicture) or caption data. However, each track file follows the same basic file structure. A track file consists of three logical parts: the File Header, the File Body and the File Footer as shown in Figure 8: Example Track File Structure.
The file structure is further broken down into logical data items as defined in [SMPTE 336M Data Encoding Protocol using Key-Length-Value]. The KLV Coding Protocol is composed of Universal Label (UL) identification Key (UL Key), followed by a numeric Length (Value Length), followed by the data Value as shown below in Figure 9. One or more of these data items are combined to form the logical parts shown above.
Each track file is required to be a self-contained element, such that its essence or metadata can be understood and presented as it was packaged by a compliant decoder. The information is required to be located in the predetermined specified area. The Track File is required to contain the following minimum information:
The following information is required to be configured in a human readable format:
A Reel is a conceptual period of time having a specific duration, as defined below:
A Track File is the smallest unit that can be managed or replaced as a discrete file in the field.
Each Track File is required to contain the following synchronization information:
Track Files of the same essence type and playback devices are required to support artifact-free splicing at any frame boundary, allowing the assembly of a continuous data stream from multiple Track Files. The playback device is required to perform sample accurate splicing of Sound Track Files.
A Key Epoch is the period of time during which a given Decryption Key is effective. The Key Epoch shall minimally be one Reel.
Each Track File is required to provide for encryption and methods to authenticate the data, if the content provider chooses to use such methods. In addition:
Each Track File is required to provide a method for verification of file integrity that can be easily determined at any step of the delivery process. In addition:
The Operational Pattern is required to accommodate future extensions within its original scope.
The Operational Pattern is required to support random access to the nearest integer minute. Random access to individual frames is neither required nor desired.
A restart occurs as a result of a stop or pause in the system while executing a Composition Playlist. The system may be restarted at any frame prior to the frame at which it was stopped or paused. It is required that a restart be logged by the Security Manager, provided that the essence (either image, audio or subtitle) is encrypted.
A track file is required to contain essence of a single essence type (e.g., audio, image, subtitles). While a Track File can, for instance, contain all audio channels for a given language, additional languages are required to be stored in separate track file. The Composition Playlist will select the correct Track Files to play a requested version of the movie (composition).
MXF Track File Encryption shall be compliant with SMPTE 429-6 D-Cinema Packaging – MXF Track File Essence Encryption. The following requirements clarify the use of SMPTE 429-6 with this specification. For the purpose of this section, a frame is defined as an image frame time, for example 24 FPS or 48 FPS.
MXF Track File Encryption shall be compliant with [SMPTE 429-6 D-Cinema Packaging – MXF Track File Essence Encryption].
An Image Track File contains the image essence data and its associated metadata. Each Image Track File contains compressed image data and, optionally, may be encrypted. The following are requirements for an Image Track File.
The Image Track File is required to begin and end with complete frames that allow for splicing. Frames are defined to be image frames such as 24 FPS (1/24 sec) or 48 FPS (1/48 sec). The image data within the Track File shall be wrapped using KLV on an image frame boundary.
The Track File is required to support Constant Bit Rate (CBR) compression and Variable Bit Rate (VBR) compression, within the constraints of the specified code stream for the reference decoder (see Section 4. Compression).
The following metadata is required to be furnished with the Image Track File:
An Audio Track File contains the audio essence data and its associated metadata. The following are requirements for an Audio Track File.
The Audio Track File is required to begin and end with complete frames that are associated with its Image Track File to allow for a clean transition between reels. The audio data within the Track File shall be wrapped using KLV on an image frame boundary.
The Audio Track File is required to support uncompressed audio data.
The following metadata is required to be furnished with the Audio Track File:
A Subtitle Track File contains, for example, the Subtitling essence data and its associated metadata. Each Subtitle Track File may contain any combination of text, font references, and image references.
The Subtitle Track File is required to have the same duration as the playable region of its associated Image Track File.
Any Timed Text element is required to use an Open Type font.
Subpicture elements are required to use the PNG file format.
The following metadata is required to be furnished with the subpicture Track File:
It may be necessary to package auxiliary data or nonstandard essence for a specific use case. In these cases the extension shall not interfere with the proper handling of the DCP by an otherwise compliant system. 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"].
Composition Playlists (CPL) are textual lists that define how elements of Digital Cinema Compositions are played back in a presentation. The content owner creates the Composition Playlist in a post-production environment. For encrypted essence, the Composition Playlist shall be digitally signed such that modifications to the Composition Playlist (and/or the associated composition) can be detected.
The Composition Playlist is required to use the secure (digitally signed) text-based XML file format.
The Composition Playlist is required to contain the following human readable information in English (default) but can be provided in other languages as well.
Any given Image Track File shall have one or more Entry Points within a given composition playlist.
Any given Audio Track File shall have one or more Entry Points within a given composition playlist.
Any given Subtitle Track File shall have one or more Entry Points within a given composition playlist.
For encrypted essence, the Composition Playlist shall be digitally signed such that modifications to the Composition Playlist (and/or the associated composition) can be detected. In support of this, the CPL assets "KeyID" and "Hash" elements shall be present in the CPL track file asset structure.
The Distribution Package has two major components. One is the Package itself, which includes all of the Track Files and the other is the Packing List. These are all of the elements required for a complete delivery to the theater Digital Cinema system. It is technically possible to include engagement-specific licenses and keying information in a Package in the form of opaque metadata, but this is not recommended for general usage.
A Distribution Package can contain a complete feature composition or a set of compositions. Alternatively, it can carry as little as a single file to update one reel’s subtitle or sound track.
The Distribution Package is required to contain a Packing List and one or more Digital Cinema Track Files.
The distribution method is required to allow a DCP to be transported via physical media, satellite or network.
The distribution method is required to provide digital signatures to allow the recipient to verify integrity of the Packing List and the enclosed files. In particular, where the DCP contains encrypted essence files, the Packing List shall be digitally signed.
Preparation of Packing Lists is a distribution fulfillment or transport function. Therefore, the digital signatures come from these entities, not the content-owner who mastered the files. Packing List security functions do not verify the authenticity of the content, only the intent of the delivery agent. Content authenticity is verified through signed Composition Playlists and validated Key Delivery Messages.
The Packing List is required to use XML data format with XML signature (digital signature). It should be in English (default) but can be provided in other languages as well.
The following data fields are required to be included in the Packing List for each file in the Package:
The following fields are required to be included in the digital signature section of the Packing List:
Transport refers to the movement of the packaged Digital Cinema content. This can be accomplished in many ways, such as physical media, Virtual Private Network (VPN), or satellite. This section will describe any requirements for the transport of packaged content.
Digital Cinema presents unique opportunities for the transport of theatrical content. Some basic requirements are stated below.
The content owner’s encryption is required to not be removed during transport.
The files are required to retain all of the data of the original files upon completion of transport of the Digital Cinema content.
The transport of Digital Cinema content can be accomplished in many different ways. The Distributors will select the method that is both economical and technically robust to ship their content to the theaters. This can include the use of physical media or through transmission (e.g., satellite, fiber, copper). Any selected method is required to provide for a secure environment for the content as well as no corruption of the data. Segmenting of the packaged content can occur to accommodate fixed media or bandwidth constraints.
Independent of the transport method, the output interface of the transport system is required to be ingested into the Digital Cinema Storage in the theater.
The ingest interface shall comply with either Clause 34 or Clause 44 of [IEEE 802.3-2005] for either 1000 Mb/s or 10 Gb/s operation, respectively.
Theater Systems for Digital Cinema incorporates all of the equipment required to make a theatrical presentation within an auditorium located within a Theater complex. This encompasses projectors, Media Blocks, Security Managers, storage, sound systems, DCP ingest, theater automation, Screen Management System (SMS) and Theater Management System (TMS). The Screen Management System (SMS) provides the theater manager a user interface for local control of the auditorium such as start, stop, select a Show Playlist and edit a Show Playlist. At a higher level is the Theater Management System (TMS). The TMS can control, supervise and report status on all of the equipment in the Theater as well as perform all the duties of the SMS. This section will define the requirements and interconnectivity of a TMS and multiple SMSs within a theater complex.
For the purpose of documenting the specific requirements and specifications for a Digital Cinema Theater System, it is helpful to divide the system into a set of components. The specifications and performance requirements for each of these components will be described in the following sections:
Theater Systems can have a wide range of responsibilities. They are required to provide a theatrical presentation in a timely manner along with controlling the environment in which it is presented. To simplify this complex system, each major component of a Digital Cinema Theater System is reviewed and shown how they interconnect. The human interface of the single screen system is the Screen Management System (SMS). It is required that there be one SMS for each auditorium. The Screen Management System (SMS) provides user interface to control (start, stop, pause, load playlist, etc.) a single auditorium. The Theater Management System (TMS) allows a theater manager to control many or all auditoriums within a theater complex from a central location. This is the interface that allows for control, show programming, troubleshooting, asset management and status of the Digital Cinema equipment. There are many different scenarios for the implementation of the SMS and the TMS.
Digital Cinema Theater Systems have some basic requirements that are stated below.
A key part of the Digital Cinema system is reliability. In the realm of Digital Cinema, the presentation should not be interrupted, except in the event of a catastrophic failure of the Digital Cinema system (e.g., loss of power) or a natural disaster. There will be cases where equipment will fail (such as happens now with traditional 35mm film equipment). However, the time between failures, and the speed at which it is repaired, is encouraged to be no worse than those for traditional 35mm film equipment.
Each individual theater system is required to have a Mean Time Between Failure (MTBF) of at least 10,000 hours.
A failed or malfunctioning unit/component is required to be capable of being diagnosed and replaced within 2 hours, exclusive of the time needed to order and to deliver the replacement component(s). Design of a system is required to allow repair of any failed unit/component within two hours.
The system is required to allow the content to be played back for validation and verification prior to exhibition.
The system is required to provide monitoring and diagnostic checks and provide for status, monitoring, alignment and calibration. This can be done locally or through remote control.
The system is required to provide a graphical user interface (GUI) interface for the assembly of content with relative ease in a timely matter.
The system is required to provide for intra-theater movement of content within a multiplex facility. Emergency moves (e.g., equipment failure) between auditoriums are required to allow playback to start within 15 minutes or less after the start of the movement.
The Digital Cinema Theater System is encouraged to require only a reasonable level of computer operation knowledge or training for the basic operation of the system. The computer-based user interfaces are required to be simple and intuitive.
There can be one Theater Management System communicating to one or more Screen Management Systems.
The theater is required to provide an adequate environment for the equipment, with an operating temperature range of 10-35°C and operating Humidity of 10% to 85% Non-Condensing.
All equipment is required to comply with applicable safety regulations.
The central and/or local storage system is required to have the capacity to hold at least 1 TByte of usable storage per screen, where a TByte equals 1,000,000,000,000 bytes.
Theater systems equipment is required to implement all the security requirements as specified in Section 9. Security. These requirements enable the necessary functions and features for a reliable and persistent environment to protect content and Security Data, and support the required forensic processes that stakeholders require.
In the case of a power interruption, the Digital Cinema Theater System is required to be restored into a stable stop/idle condition.
Every auditorium is required to provide the means of local control by the Screen Management System (SMS) at each projection booth.
The Show Playlist is the list that the Exhibitor assembles to complete a presentation in the theater. The Show Playlist has the following requirements.
The Show Playlist is required to use XML file format.
The Show Playlist is designed to be edited in the field. The requirements for editing are listed below:
The Screen Management System (SMS) is required to allow the theater staff to function similar to traditional theater operations. The workflow does not need to radically change to support Digital Cinema presentations. Digital Cinema content will arrive at the theater via fixed media, or through other means of transport, and will be loaded into central or local storage. The staff will then assemble a Show Playlist using a computer Graphical User Interface. This Show Playlist could include advertisements, logos, previews and a main feature. The staff will then direct the show to the screen and let the SMS begin the show by local or remote control.
The Screen Management System provides a user interface to control (start, stop, pause, load playlist, etc.) a single auditorium. The Theater Management System (TMS) allows a theater manager to control many or all auditoriums within a theater complex from a central location.
At the beginning of this section, fundamental requirements were listed that would allow theaters to operate as they have been for some time. This section will elaborate on some of these and other requirements, as they affect the SMS and TMS.
Each auditorium in a theater complex is required to allow for local control at each screen via the SMS. This will provide for at a minimum:
The SMS and TMS are required to support multiple levels of user accounts. The following is an example of multiple accounts: Projection, Show Manager, Super-user, and Administrator with password-protected appropriate log-ons.
Content can be received by physical media or via a network. The theater systems are required to allow multiple motion pictures and related content to be delivered to a theater in a timely matter. The theater systems are also required to provide a method to verify that the data is complete and whether or not it has not been corrupted.
The SMS and TMS are required to allow an authorized user to search for content and provide a method for the movement and deletion of content, within a screen or multiplex facility, while the system is in operation. As an example, this would include simultaneous content load-in and playback. This movement could consist of many different examples of operation such as:
An electronic method is required to assemble trailers, feature presentations and other content in the creation of shows. At a minimum, a standard method is required to electronically identify the content to the SMS, TMS and the Security Manager (SM) to allow the show to be assembled and played back. This method of identification is embedded within the packaging format as metadata. (See Section 5. Packaging)
Operationally, the SMS and TMS are required to provide the user with a method of creating a Show Playlist. This method provides for the following:
The Automation System is required to communicate events to and from the screen equipment. These can be light dimmers, curtains, or other systems within an auditorium. These events or cues are programmed within the TMS or the SMS, and initiated by either the SMS or the Automation depending on which unit is master and which is slave. All of the event types are pre-programmed to have certain effects on the system. These events, at a minimum, are required to be recognized by all systems and are listed below:
The system is required to provide a method to:
The following table depicts situations and events related to the Theater Management System (TMS). These events do not affect the security system and are known only to the Theater Management System. In addition, the Theater Management System has the ability to have pre-showtime knowledge of events in the security system by directing the Screen Management System to query the Security Manager.
Item, Observation or Issue | Approach |
---|---|
Log data collected from auditoriums | TMS controls and can check collection status |
Equipment installation and locations | TMS knows about and controls installations |
Auditorium scheduling | TMS knows scheduling information |
The examples in Table 8 are outside of the knowledge or control of the security system. The Theater Management System may have the capacity to execute such functions or make records of various activities under its control. Under a private agreement between the Exhibitor and the Distributor, data collected by the Theater Management System could be made available.
A Digital Cinema Theater System includes several component systems: ingest, storage, Media Block, security, projection, audio system, Theater Management System, Screen Management System and automation. An example of a single screen installation is shown in Figure 10.
Ingest is the process of receiving content and security information at the theater level. These are the devices that connect to and from the outside world. The following is an example list of such devices split into two groups. The first group has to do with content while the second group is for security and control.
Content:
Security and Control:
Except for security messaging, the interfaces to the outside world can use any method or physical connection. Inside the theater structure, the architecture is encouraged to break down into two types of interfaces, one for the content and one for control/status and key exchange.
Theater networks are required to protect the security system from the threat of external and internal network-born attacks by the installation of appropriate firewalls. Because there will be many variations in network designs, it is impossible to define specific solutions as part of this specification. Exhibition operators are encouraged to solicit competent network security engineering assistance as part of their facility network design efforts.
See Section 9.5.6. Communications Robustness for additional exhibition communications and networking requirements.
Content storage can be arranged into two basic configurations or a combination of the two. One is known as local storage and the other is central storage. Local storage is a configuration where the storage is located at each screen. Central storage is a configuration that has all of the storage of content in a central location for all of the screens in a multiplex. There can also be combinations of central and local storage.
The most important aspect of the storage system is reliability. There are a number of RAID configurations that will provide storage redundancy and therefore storage reliability. The storage system is required to provide redundancy such that should a single hard disc drive fail, the system will continue to play with no visible or audible interruptions or artifacts.
Central Storage implies that packaged content for a multiplex may be stored in one location. Central Storage may allow for multicasting of the content.
If only Central Storage architecture is used, careful planning is required to be done to ensure that it does not have a single point of failure, including the network. In this type of implementation, the Central Storage is required to also provide the capability to sustain the peak bit rate of all screens being fed simultaneously, along with ingest.
Local storage implies a single storage system for each screen. Local storage is required to be able to sustain the bit rate required for the playback of all content for that screen.
A combination of central and local storage for a multiplex can be the best solution. The central storage can be used for ingest of material and redundancy of content, while the local storage is encouraged to hold just the content required for the immediate presentation(s).
The storage system is required to provide enough output to support a continuous stream of 307 Mbits/sec for compressed image, uncompressed audio (16 channels, 24 bit sample, 96 kHz) and subtitle data to allow for non-interrupted Digital Cinema playback.
Excluding storage necessary for redundancy, the storage system is required to provide for, at a minimum, the storage of three features (including pre-show content) per screen (one feature currently showing and a second or upcoming feature). Shown in Table 9: Example of Storage Capacity for one 3-Hour Feature (12 bits @ 24 FPS), are some example storage requirements. The numbers are based on:
Average Bit
Rate (Mbits/sec) |
3 Hour
Image (GBytes) |
3 Hour
Audio (GBytes) |
20 min.
pre-show (Gbytes) |
Sub
Picture (GBytes) |
Timed
Text (GBytes) |
3 Hour
Total (GBytes) |
---|---|---|---|---|---|---|
250 | 337.500 | 2.074 | 37.500 | 0.300 | 0.001 | 377.374 |
200 | 270.000 | 2.074 | 30.000 | 0.300 | 0.001 | 302.374 |
125 | 168.750 | 2.074 | 18.750 | 0.400 | 0.001 | 189.974 |
100 | 135.000 | 2.074 | 15.000 | 0.600 | 0.001 | 152.674 |
80 | 108.000 | 2.074 | 12.000 | 0.800 | 0.001 | 122.874 |
It is required that image and audio essence on storage devices retains the original AES encryption, if present during ingest. It is required that decrypted plaintext (image or audio) essence is never stored on the storage system.
Another key component in the playback chain is the Media Block. One or more Media Blocks are responsible for converting the packaged, compressed and encrypted data into raw image, sound and subtitles.
Depending upon implementation, both security and non-security functions take place within Media Blocks. Security functions of Media Blocks (those functions which process plain text essence or Security Data such as decryption keys) may take place only within physically secure perimeters called Secure Processing Blocks (SPB). The more general functions of the Media Block and variations on implementation are described here. Not all such functions are required to be within an SPB. Detailed security requirements of Media Blocks are discussed in Section 9.4. Theater System Security.
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: Media Block in Projector Configuration. [5]
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 Section 9. Security for details of MMB and OMB requirements and operation.
Note: Due to the dynamic nature of security technology, DCI reserves the right, at some future time, to update requirements and may require changes to Digital Cinema systems as situations warrant.
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:
The synchronization signal shall be compliant with SMPTE ST 430-14 D-Cinema Operations -- Digital Sync Signal and Aux Data Transfer Protocol.
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.
All Media Blocks are required to provide logging functions per the requirements of Section 9.4.6.3.1. Logging Requirements.
If the Image Media Block is not physically located in the same secure container as the projector, then the Image Media Block is required to provide link encryption to the projection system to protect image essence per Section 9.4.4. Link Encryption. At the projector, a Link Decryptor Block is required to decrypt the image essence. The Link Decryptor Block is required to provide SPB type 1 physical protection for link decryption, the associated security keys and logging functions.
Any packaged content that comes from storage is required to contain all of the content data required for the presentation and file integrity. The first job of the Media Block is to arrange the track files into their appropriate modules and to provide a timely supply of data to the next process. The content can arrive completely unpacked or partially unpacked depending upon the system’s storage method.
An alpha channel overlay module, to key subtitles or open captions into the Main Image, can be located in the projector or in the Media Block.
The subpicture renderer, a module that converts the subpicture file into the DCDM* image file with an alpha channel overlay, can be located in the projector or the Media Block.
The Timed Text renderer, a module that converts Timed Text data into the image file with an alpha channel overlay, can be located in the projector or the Media Block.
The Media Block is required to interface on three levels with the rest of the system. One level deals with the packaged Digital Cinema content. The next level is the raw essence output for the projector, the audio processor and any special devices for the automation system. The third level is the control and status of the Media Block playback system. These interfaces are noted below.
The Projection System is required to change digital image data into the light that appears on the screen. The projection system is required to support many interfaces and different Digital Cinema system architectures. One of these architectures includes the Media Block (described above) installed in the projector. In this type of architecture, all of the content is ported through a single data interface. When the Media Block is external to the Projector, Link Encryption is required. The corresponding Link Decryption Block is required at the projector interface.
Alternative content can come from an external interface, even when the Media Block is present inside the projector.
The Projection System is required to change digital image data into the light that appears on the screen. The projection system is required to support many interfaces and different Digital Cinema system architectures. One of these architectures includes the Media Block (described above) installed in the projector. In this type of architecture, all of the content is ported through a single data interface. When the Media Block is external to the Projector, Link Encryption is required. The corresponding Link Decryption Block is required at the projector interface.
Alternative content can come from an external interface, even when the Media Block is present inside the projector.
The Projection System not only provides the main image on the screen, it can provide subtitles, open captioning, and still pictures. This requires extra interfaces from the Media Block, if the Media Block is not installed in the projector. These interfaces are noted below. (For the complete interface specification refer to Section 8. Projection.)
The Audio System delivers the sound of the theatrical presentation to the audience. It is responsible for receiving the uncompressed digital audio from the Media Block, converting it to analog and directing it to the proper speakers for translation to acoustic energy. The system is required to provide the capability for 16 channels of audio playback. The presentation is required to provide, at a minimum, a 5.1 audio format, (Left, Center, Right, Low Frequency Effects, Left Surround and Right Surround). An audio format of 7.1 can also be provided. The undefined channels can include a Hearing Impaired and/or a Visually Impaired channels as well.
The Cinema Audio Processor can provide the digital audio conversion and the channel mapping. Its other duties can include playing the intermission program or music (often called non-sync) and allowing for monitoring in the projection booth.
The Audio System requires several interfaces. The main interface deals with the digital audio and the other interfaces deal with status and control. These interfaces are noted below.
A Screen Automation System can interface with life safety, motor controlled curtains, motor controlled masking, the dimmers for the lighting, existing 35mm film projectors and possibly to other devices such as the Cinema Audio Processor, and/or special effects devices. One of the challenges of Digital Cinema is to interface with the many different Automation devices installed presently in the theaters.
The automation interface is a variable that is different depending on the manufacturer of the installed system. This could range from contact closures to proprietary interfaces. The Theater System is required to translate Digital Cinema cues into something that the automation system understands, and reciprocally, is required to translate the automation information into something the SMS understands.
Each auditorium is required to have a single dedicated Screen Management System (SMS). The Screen Management System provides a user interface to theater management for local control of the auditorium, such as start, stop, select a Show Playlist and edit a Show Playlist. In addition to control, the Screen Management System can monitor and run diagnostics on equipment within the auditorium and provide such status information to the exhibitor. The Screen Management System is required to operate in one of two modes, local or remote.
The following table depicts situations and events related to the Screen Management System.
Item, Observation or Issue | Approach |
---|---|
Corrupted Movie Received | SMS can validate received DCP |
Valid Composition Playlist Received | SMS can validate received CPL |
Movie prepped for playback is modified | SMS can check prepped movie against CPL |
Playback time associations of Trailers-Movie | SMS knows show playlists and execution statistics |
The examples in Table 10 are outside of the knowledge or control of the security system. Under a private agreement between the exhibitor and the distributor, the Screen Management System may be required to execute functions or make records of such activities under its control.
Many Theater Systems will be part of a larger multi-screen facility. A single TMS for Digital Cinema operations is expected to support all multiplex configurations.
Figure 13: Multiplex Theater System Architecture below demonstrates an example architecture of one of these systems from an interface prospective. This section will consider the requirements and interfaces of a large networked system. There are two main interface components of this larger system. The first is the Media Network and the second is the Theater Management Network.
The Media Network is a high bandwidth, switched interface, made up of media interfaces, Disc Arrays and Media Blocks. The Media Network is required to support sustained rate of 307 Mbits/sec for compressed image (250 Mbits/sec), audio (37.87 Mbits/sec - 16 channels, 24 bit sample, 96 KHz) and subtitle data (subpicture 20 MBits/sec) for each screen. Additional data bandwidth is needed for ingesting new content and control/monitoring.
Not all multi-screen complexes will have Theater Management Networks. When present, the Theater Management Network is a low bandwidth, shared interface, made up of Theater System devices and an Ethernet distribution system. This is required to be accomplished using 100Base-T Ethernet [IEEE 802.3]. This network is required to support all of the control, configuration, security, software upgrades, testing and status of the Theater Systems.
The Theater Management Network can be sub-divided into two main categories of communications:
The following is a list of devices and examples of typical communications:
The Projection System is an essential part of the Digital Cinema System. Its job is to change digital image data into light that appears on the screen. This section is broken into parts to help define the requirements, interfaces and performance specifications. Bearing in mind that a core goal is to have the mastering room image seen by the public, it is intended that the projection system should faithfully replicate the DCDM as is described in Section 3. Digital Cinema Distribution Master.
For the purpose of documenting the specific requirements and standards for a Digital Cinema Projection system, it is helpful to divide the system into a set of components. The specifications and performance requirements for each of these components will be described in the following sections:
Digital Cinema presents a challenge to create a versatile projection system. Throughout this system, some basic requirements are needed and are stated below.
The projector is required to have the following interfaces:
The projector can have:
The projector is required to have either an:
The projector is required to not have any test, utility or output interface that provides unencrypted content in the clear.
The projector is required to not preclude the ability to present alternative content. The projector can also provide an auxiliary content input.
The projection system is required to provide either a single lens solution or an unattended changeover if more than one lens is required.
The projection system is required to convert the incoming DCDM* color space to its native color space.
The sampling structure of the displayed picture array (pixel count of the projector) is required to be equal to or greater than that of the specified image containers (either 4096 x 2160 or 2048 x 1080).
The projector is required to display either a native resolution of 4096x2160 or 2048x1080. If the projector's native resolution is 4096x2160, and the incoming spatial resolution of the content is 2048x1080, then the projection system is required to perform the up-conversion of 2048x1080 content to 4096x2160. All spatial conversions are required to be done at an exact ratio of 2:1 in each axis, i.e., a projector with a horizontal pixel count of slightly higher than the image container is required to not convert the projected image beyond the image container to fill the array, nor is an image to be converted to something less than the 4096x2160 or 2048x1080 image container size.
Should electronic image resizing or scaling be used to support a constant height projection or constant width projection theater environment, then it is required that the image resizing or scaling does not introduce visible image artifacts. It is intended that the projector project the full horizontal pixel count or the full vertical pixel count of the image container.
If the incoming frame rate is not the projection system native refresh rate, then the projector is required to convert it to its native refresh rate.
A Forensic Mark is required to be inserted in real time into the content at the earliest point after decryption and prior to the content data being present on any data bus outside the Media Block (see Section 9.4.6.2. Forensic Marking Operations).
In the preferred implementation, the projector is required to provide an area for a Media Block to be installed. If the Media Block is installed external to the projector, then a link encrypted interface is required to ensure that no Digital Cinema content is in the clear.
The Digital Cinema projector is one of the principal elements in the system. It is perceived that projector technology will continue to change and develop with time. There are several items affecting the projection system: color space, resolution, brightness, contrast and interfaces. The projector is required to convert from the incoming X’Y’Z’ color space to its native color space. The projector is required to support more than one spatial resolution and frame rate.
A Reference Projector is used in the mastering process for creating the Digital Cinema Distribution Master (DCDM), with the target performance parameters and tolerances included in this chapter described below. Test patterns and measurement procedures are defined for measuring these performance parameters. It also describes a controlled environment for the mastering of projected images. The goal is to provide a means for achieving consistent and repeatable color quality.
This section provides requirements defining the reference input to a Digital Cinema projector, the viewing environment, and output display characteristics for mastering and theatrical environments. These requirements are provided to ensure a single inventory distribution will be input compatible with any brand projector and that the projector output will be predictable, based on the standard format input. Nominal reference points plus tolerances are provided.
The projector is required to support the image structures, aspect ratios, file formats, and frame rates as specified in Section 3.2. Image Specification. The projector can support other image structures, aspect ratios, file formats, and frame rates as determined by the individual manufacturer.
The SMPTE published recommended practice [SMPTE RP 431-2: D-Cinema Quality - Reference Projector and Environment] shall be utilized and shall be normative in its entirety for this specification.
Projection systems will likely have many input/output interfaces to support the various signals that are required to send and receive data between projector, Media Block (MB) and Screen Management System (SMS). Any security aspect of the use of these interfaces is described under Section 9. Security
The preferred implementation of a Digital Cinema system would locate the Media Block in the projector. At a minimum, the Media Block is required to decrypt, decompress and forensically mark the image and provide this to the internal projector interface. The Security Manager is required to be notified in the event of tampering or removal of any Media Block. If the Media Block is external to the projector, then a secure interface, utilizing Link Encryption, is required between the Media Block and the projector.
For the mastering environments, an uncompressed image interface is required. Since mastering environments are considered trusted environments, it is not required that these interfaces support link encryption.
For theatrical environments, the preferred solution is for the Media Block to be located inside the projector. The Forensic Mark is required to be inserted at the point of the internal interface between the Media Block and the projector. In the case where the Media Block is external to the projector, it is required that the projector uncompressed interface provide a robust Link Decryption. In this case, the Forensic Mark is required to be inserted within the Media Block at the output of decoding and prior to Link Encryption. (See Section 9.4.4. Link Encryption)
For mastering environments, the interface can be a dual-Dual Link HD-SDI [SMPTE 372M Link 1.5 Gb/s Digital Interface for 1920x1080 and 2048x1080 Picture Formats].
When used in theatrical environments, it is required that the dual-Dual Link HD-SDI [SMPTE 372M Link 1.5 Gb/s Digital Interface for 1920x1080 and 2048x1080 Picture Formats] be encrypted. The encryption specification is required to be an open international standard. The encryption is required to use AES with a 128-bit key. (See Section 9.4.4. Link Encryption)
Note: dual-Dual Link HD-SDI is to accommodate 2K 48 FPS, 12-bit.
The interface can be Dual Link HD-SDI [SMPTE 372M Link 1.5 Gb/s Digital Interface for 1920x1080 and 2048x1080 Picture Formats]. However, this interface is only compliant if provisions are made for 2K 48 FPS support. (See Section 2.1.1.4. Digital Cinema Package (DCP))
When used in theatrical environments, it is required that the Dual Link HD-SDI be encrypted. The encryption specification is required to be an open international standard. The encryption is required to use AES with a 128 bit key. (See Section 9.4.4. Link Encryption)
For mastering environments, 10 Gigabit fiber, also known as [IEEE 802.3ae], may be adapted for a point-to-point interface. The goal for this interface would be to use the same physical layer and adopt a protocol for streaming image data. Listed below are some of the requirements:
Timed Text and subpicture interfaces are required to use a 100Base-T Ethernet [IEEE 802.3] interface. This may be the same interface that is used for control and status.
These signals allow the SMS, TMS, the projector and the theater automation system to communicate. The physical implementation is required to be 100Base-T Ethernet [IEEE 802.3]. The protocol used is required to be the same as the Theater Management Network. (See Section 7. Theater Systems)
The following is an example list of control messages that can be sent to the projector:
The following is an example list of status messages that can be sent from the projector:
This section defines the requirements for Digital Cinema security. Though security is an end-to-end process, these specifications are focused on the exhibition environment. The high level business requirements for security are:
The high level technical requirements for security are:
Security is provided primarily through the application of encryption technology and the management of content key access. When content is transported and received in an encrypted fashion, it is necessary to establish standardized methods of delivering and utilizing decryption keys to unlock the content. This is known as key management. Associated with key exchange is DRM (Digital Rights Management), which establishes the rules for using content. The management of DRM is known as security management. DRM requirements include logging of content access and other security event information.
In the security architecture defined herein, security management functions are entrusted to a Security Manager (SM), a logically separable and functionally unique component of the architecture. The security system is referred to as the infrastructure that provides security features, and the Security Manager is at the heart of this infrastructure. The security system architecture is defined to provide open and standardized security operation and enable interoperability between an exhibition SM and the rest of the exhibition security infrastructure.
This specification originally required that a single SM be assigned to an auditorium projection booth. The requirement for a single SM is eliminated. Multiple SM’s per auditorium (each contained within a Media Block as further specified herein) is permitted by this specification, which enables Multiple Media Block (MMB) auditorium equipment configurations.
Section 9. Security is organized as follows:
The following acronyms are introduced and used extensively in Section 9.
This specification originally referenced only Federal Information Standards Publication (FIPS) 140-2 “Security Requirements for Cryptographic Modules.” As NIST has now released FIPS 140-3, this specification now references both standards. Except as expressly stated in Section 9.5.2.5. FIPS 140 Requirements for Type 1 Secure Processing Blocks, all appearances of “FIPS 140-2” are replaced with “FIPS 140.”
This section describes the goals for the security system. Cryptographic security requires communications connectivity between Distribution and Exhibition, above what is required for 35mm film. However, at no time do security requirements mandate continuous on-line connectivity to an exhibition facility.
Note: Due to the dynamic nature of security technology, DCI reserves the right, at some future time, to update requirements and may require changes to Digital Cinema systems as situations warrant.
The security system shall provide a means for the securing of content against unauthorized access, copying, editing, and playback. Protection shall be standardized primarily through the application of encryption technology, management of content key access and robust logging.
The security system shall support a single inventory Digital Cinema Package (DCP) delivered to every compliant theater installation. The security system architecture shall support file interoperability for both the Digital Cinema Package (DCP) and the Key Delivery Message (KDM). The security system architecture shall require system interoperability between Security Manager (SM) and Screen Management System (SMS).
The security system shall recognize that “the show must go on” except in extreme circumstances. The model shall support intelligent means to locate failures expeditiously, and support field replaceable security devices.
The security system shall support prevention and detection of the following threats:
This section describes the architectural elements and fundamental operation of the Digital Cinema security system.
The security architecture described herein distinguishes security management from content management. Once content is encrypted, it is “purpose neutral and safe” and can be allowed to take any path desired at any time to any destination. Thus, content management (physical distribution) can be implemented along lines that are oriented towards business needs, commercial cost effectiveness, and convenience. “Purpose neutral and safe” means once content is encrypted, its purpose has been neutralized (as to the content type, information contained, etc.) and it is safe (one does not care where it goes, how it gets there or who has access to it).
Access to encrypted content is controlled by the security management function. That is, content access is enabled or denied through control of Security Data. This function is entrusted to a Security Manager (SM), a logically separable and functionally unique component of the architecture. At exhibition, the SM controls Security Data, and consequently, access to content.
At the theater, access to content is provided via one or more Media Blocks (MB), each containing an SM. For each playback, each SM will require, and be delivered, one or more unique keys to unlock encrypted content files. All distributors will share the SM(s).
Each key is delivered in a Key Delivery Message (KDM) with a specified play period. That is defined as the time window when the key is authorized to unlock the content. There is a start time/date and a stop time/date associated with each key. The authorized window for each key will be part of the normal engagement negotiation between Exhibition and Distribution.
The security system described herein implements a standardized open architecture in which equipment used at exhibition facilities can be sourced from multiple, competing suppliers. In order to achieve interoperable security operation, the security system design for Exhibition, specifies a standard message set for interoperable communications between standardized security devices.
There are two classes of messages in the architecture:
Figure 14 shows typical locations of SM functions[6], ETM[7] and ITM message interfaces. ETM message types are labeled with a black 1 and ITM messages with a red 2.
Security Entities (SE) are characterized by executing a narrowly defined security function, and having a role defined for them in a digital certificate with which they are associated. The seven defined SE(s) are as follows (these are developed more fully in Section 9.4. Theater System Security).
Security Entity Notes:
The Theater System is comprised of those components, at an Exhibition location, that are required by the security system to support playback of a show. Once in possession of the complete DCP and its associated KDMs, the theater security system can independently enable playback of the composition.
Theater System Security requirements are:
Figure 15 presents the two fundamental auditorium security system architectures, with and without Link Encryption, and the security message types ETM and ITM. This diagram does not attempt to detail functions that are unrelated to security (e.g., decoding), but does anticipate such functions by noting where plain text content exists.
Though not shown in Figure 15: Digital Cinema Auditorium Security Implementation, but as indicated in the requirements above, every auditorium shall support image, audio, and subtitle decryption[9], and image and audio Forensic Marking.
This specification also includes requirements for projection booth operation with equipment configurations beyond those shown in Figure 15 as follows:
The Special Auditorium Situation expands the utility of a single IMB to support multiple projectors, while MMB expands the use of Media Blocks (MB). An important point is that with MMB each MB (IMB(s) and/or OMB(s)) contains a Security Manager (SM) and Security Entities (SE) which process Digital Cinema Package (DCP) media essence simultaneously with, but independently of, other MBs during playout within a single auditorium. In addition to the appropriate DCP content essence, each MB must be supplied with the Composition Playlist(s) (CPL) and matching KDM(s) to support the entire show (which may consist of multiple compositions). MMB operational requirements are described in Section 9.4.3. Theater Security Operations.
The security architecture descriptions and requirements revolve around two embodiments: the SPB and the SE. As defined in Section 9.3.3. Security Messaging and Security Entities, SEs are logical devices that perform specific security functions. They are 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 a literal 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 Cinema Auditorium Security Implementation. This figure shows that there shall be only three permitted physical protection scenarios:
These requirements are more fully defined in the SM and SPB functional requirements below (see Section 9.5. Implementation Requirements).
The security network is shown (in red) in Figure 15: Digital Cinema Auditorium Security Implementation. This is described below as operating under Transport Layer Security (TLS), a readily available and well known protocol standard for providing protection between application layer processes that must communicate between devices, in this case between Secure Processing Blocks (SPB) performing security functions.[10]
As part of TLS session establishment, each party to the session presents its digital certificate to the other. In this fashion, the IMB Security Manager identifies the other SPBs in the auditorium, and mutual authentication is accomplished (see Section 9.4.3.1. Transport Layer Security (TLS) Establishment and Secure Processing Block (SPB) Authentication and Section 9.4.5.1. Transport Layer Security Sessions, End Points and Intra-Theater Messaging). Although the SM may establish secure TLS communications with an SPB, it will not “trust” (approve) that SPB for content playback functions until the identity of such SPB appears on the appropriate Trusted Device List (TDL) for the particular composition (see Section 9.4.3.5 Functions of the Security Manager (SM), items 7 and 9c).
The playback processes begins and ends with the SMS, under the control of Exhibition. Thus, the SMS is viewed as the initiator of security functions, and the window into the exhibition security system. Protection over cryptographic processes begins by requiring the SMS to communicate, in a secure fashion (i.e., under TLS), with the Security Managers (SM) under its control. The security system takes advantage of these secure command and control features to protect itself, as well as the exhibition operator, from several forms of attacks, including SMS imposters and Denial of Service.
While it is true that the security system places no physical protection requirements on the SMS, the extent to which the SMS is vulnerable to being tampered with, or its functions subverted, is a result of exhibition implementation and policy (e.g., who gets access to the SMS, how it is physically protected by room locks, operator access). The security system requires the SMS and SMS operator to identity itself to the Security Manager. The extent to which this information is reliable is subject to issues outside the scope of the security system and this specification. But the security system structure and standards requirements are appropriately specified to enable policies to regiment these aspects according to any particular security needs, without needing to change or enhance SE device operations or features.
Although SEs are not distinctly visible outside of the SPB that contains them, SEs exist logically, and their normative behavior is specified in conjunction with the requirements defined below for SPB systems (see Section 9.4.3.5. Functions of the Security Manager (SM) and Section 9.4.3.6. Functional Requirements for Secure Processing Block Systems). This is accomplished using a traditional Applications Programming Interface (API) approach, where the focus of the interoperability point is the SPB (logical) interface, and associated messaging and operational behavior at the interface.
Security requirements refer to the collection of equipment in a display chain under control of one IMB SM that supports a projector as an Equipment Suite. An Equipment Suite minimally consists of an IMB and projector, but may additionally include, for example, LDB and/or LD/LE SPB types. The key characteristic of an Equipment Suite is that the IMB SM is responsible for authenticating other SPBs comprising the suite. (The stand alone Outboard MB (OMB) does not support a projector or authenticate other SPBs, and is thus not part of a suite.)
The installation and configuration of equipment that comprises suites is an exhibition management function.
The SPB is defined as a container that has a specified physical perimeter, within which one or more SE and/or other plaintext processing functions are placed (e.g., decryptor, decoder, Forensic Marker). The SPB exists to enclose SEs and other devices in the content path, impede attacks on those SEs, and to protect signal paths between the SEs.
There are two normatively defined SPB types:
Secure Processing Blocks (SPBs) shall provide a hard, opaque physical security perimeter that meets minimum security requirements as defined in 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.
The term Media Block[11] (MB) has been used by the Digital Cinema industry in a number of ways. In this Section 9. Security, it has a very narrow scope: An MB is an SPB that contains a Security Manager (SM) and performs essence decryption, i.e., it contains at least one MD. Other SE functions may also be present within a MB SPB, as described below:
The SM controls Security Data and content access in a manner consistent with the policies agreed upon by the Stakeholders who rely upon it. There is one SM for each Media Block, and Rights Owners (Distribution) shall share the SM(s) for their security needs.
Security Manager functions shall conform to the requirements as given in Section 9.4.3.5. Functions of the Security Manager (SM) and Section 9.6.1. Digital Rights Management. The Security Manager is a self-contained system with an embedded processor and real-time operating system. SM functions shall not be implemented outside of the secure environment of the Image Media Block (IMB) or Outboard Media Block (OMB) SPB.
Security Manager software changes and upgrade requirements are given in Section 9.5.2.7. SPB Firmware Modifications.
Theater management controls auditorium security operations through the Screen Management System (SMS). Because the SMS interacts and communicates directly with the security system, per Section 9.3.3.2. Security Entities item 1, it is also considered to be a Security Entity (SE). The SM responds to the directives that Theater Management System (TMS) issues via the SMS. For purposes of simplicity, and subject to the TMS constraint below, this specification uses the term SMS to mean either/both Theater Management System (TMS) or Screen Management System (SMS). From the security system perspective, SMS functions are those associated with “category 1” Intra-Theater Messages of Table 15: Intra-theater Message (ITM) Request-Response Pairs (RRP).
SMS Requirements:
SM interaction with the SMS is normatively defined (see Section 9.4.3.5. Functions of the Security Manager (SM))[12]. These include the requirements that:
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:
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.
From the security perspective, a projection system consists of the projector type 2 Secure Processing Block (SPB) and its “companion” SPB, which will be either the Link Decryptor Block (LDB) or Image Media Block (IMB). A critical security issue is assuring that the clear text image output of the LDB or IMB goes to a legitimate projection device.
Therefore Section 9.4.3.6.1. Normative Requirements: Projector Secure Processing Block, defines a “marriage” process with the companion SPB. The marriage, in conjunction with the Trusted Device List (TDL) and TLS-based authentication of the companion and projector SPBs, addresses the legitimate projector security issue.
The purpose of the marriage is to have a human authority figure supervise the installation of a projection system to assure the physical connection of the two SPBs, which TLS-based authentication alone cannot do. At the time of installation the authority figure can provide visual inspection of the projector to assure it has not been tampered with.
Once a projector is installed, the state of marriage is permanent (and monitored) until the authority figure decides to separate the two SPBs (for whatever reason). In addition, this specification establishes logging requirements surrounding projector installation and maintenance functions that record security-critical event information.
It is mandatory that a projection system installation includes the marriage function per Section 9.4.3.6. Functional Requirements for Secure Processing Block Systems (noting the permanently married exception provided for in that section). The marriage process shall require the supervision of a human authority figure, who shall examine projectors as part of the marriage process to assure the associated SPB has not been tampered with.
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.
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.
This section describes how equipment conforming to the security system is used in normal theater operations. The show, expressed in a Show Playlist, consists of exhibition-arranged sequences of compositions, each of which is expressed by a Composition Playlist (CPL), any of which may be encrypted. One or more Rights Owners may supply Key Delivery Message(s) (KDMs) to provide all the content keys required for the Show Playlist.
With respect to security, theater operations break down into four categories:
The SMS is generally responsible for initiating activity within each category, except the last, which is managed by the Security Manager (SM). The four scenarios are described and flow charted below for the single SM (one IMB and projector) and Multiple Media Block (MMB) configurations. For MMB situations multiple SMs are present, requiring the SMS to perform the described functions with each SM independently.
MMB operation provides for expanded auditorium configuration flexibility. It supports:
MMB is operationally supported as follows:
MMB functionality requires the collection of MBs to playback the image, audio and other time- dependent content in a manner that presents a synchronized performance to the audience. The requirements for synchronization are defined in Section 7.5.4.2.1. Synchronization.
The above summaries are driven generally by a) the decisions of exhibition as to what the mixture of equipment is for their projection booths, b) the intentions of content creators with respect to DCP playout, and c) the engagement agreements between these parties.
Exhibition has the liberty to power their equipment up and down as desired. However, the Security Managers (SM) must establish secure Transport Layer Security (TLS) sessions with the SMS and each remote SPB, and authenticate the equipment within its Equipment Suite (if applicable) with each power-on. As previously described, the SM communicates securely with the SMS via TLS and records (logs) the SMS identity, but does not require SMS authentication. However, authentication is required of the Equipment Suite SPBs, as described below.
Note that the establishment of each TLS session enables the SM to authenticate the other party (remote SPBs) to the session and provides for secure ITM communications within the Equipment Suite. The SM does not “trust” such party for security functions related to content playback, unless the identity of the party appears on the Trusted Device List (TDL) delivered in the Key Delivery Message (KDM) for that particular Composition Playlist (CPL) (see Section 9.4.3.5. Functions of the Security Manager (SM) and Section 9.8. Digital Certificate, Extra-Theater Messages (ETM), and Key Delivery Messages (KDM) Requirements. Thus, device authentication and secure communications occurs independently of “trust”; the former being an exhibition equipment/infrastructure security issue, the latter being specific to a Rights Owner and a composition. Where content is not encrypted and no KDM/TDL exists, the SM does not invoke trust control.
The flow chart in Figure 16: System Start-Up Overview, is an example of how a system start-up may occur. This flow chart is informative. There are other designs that may have different steps or different sequences that will accomplish the same result and meet the requirements of this specification.
Pre-show preparations include tasks to be performed (well) in advance of show time to ensure adequate lead-time to resolve any issues that might impact the composition showing. These preparations do not prepare an auditorium for a showing, but are designed to provide assurance that all prerequisites for a specific showing have been satisfied.
The flow chart in Figure 17: Pre-Show Overview is an example of how a system may prepare to execute a Show Playlist. This flow chart is informative. There are other designs that may have different steps or different sequences that will accomplish the same result and meet the requirements of this specification.
Show playback processes include auditorium preparations for the playback of a specific Show Playlist, and the actual run-time security functions that include content decryption at the Media Decryptor(s), link encryption/decryption, forensic marking, and recording of log data.
The flow chart in Figure 18: Show Playback Overview, is an example of how a system may execute a Show Playlist. This flow chart is informative. There are other designs that may have different steps or different sequences that will accomplish the same result and meet the requirements of this specification.
Post playback activity primarily includes cleansing SPBs of sensitive data and collection of log data.
There are no end of engagement requirements placed on the security system. Exhibition may cleanse Screen Management System (SMS) or Theater Management System (TMS) devices, content storage devices, Key Delivery Message(s) (KDMs), etc. according to their own operational needs. Defined security system behavior places controls on Security Data, keys, etc. such that security interests are maintained.
The flow chart in Figure 19: Post Playback Overview, is an example of those items a system performs following a completed Show Playlist. This flow chart is informative. There are other designs that may have different steps or different sequences that will accomplish the same result and meet the requirements of the specification.
Auditorium Security Managers (SMs) are responsible for overseeing the security aspects of the auditorium they are assigned to (installed in), inclusive of the Secure Processing Blocks they are responsible for and according to the content essence types they are provided to process. For Multiple Media Block (MMB) situations multiple SMs will be present within an auditorium, and each SM operates independently from other SMs in responding to the auditorium’s Screen Management System (SMS) to enable playback of content. The required SM functions are described below, from the perspective of each SM (i.e., not from the perspective of the auditorium). Depending upon the requirements for any given DCP, it will be recognized that for Multiple Media Block (MMB) auditorium situations the services of any single MB may not completely support playout of the DCP. However, individual compliance to these SM functions will assure playout is securely accomplished by the collective services of the auditorium MBs/SMs.
In listing these functions the approach is that of a reference model for SM behavior, meaning that these specifications do not define required implementation methods. A standards-compliant implementation must, however, have the same input/output behavior as the reference model.
Security Manager (SM) Functions:
Constrain use of KDM content keys per items 4 and 9 below to the SM's confirmation that one of the certificates in the signer chain of the associated Composition Play List (CPL) has a thumbprint that matches the ContentAuthenticator element of the KDM, per Section 5.2.4. of said KDM specification.
The SM shall disallow or terminate playout of encrypted content when any of the image and sound integrity pack metadata is not present per the requirements of Section 5.3.2.1. MXF Track file Encryption - Introduction.
For purposes of clarity, while detected deviations in integrity pack metadata does not impact playout, the SM shall disallow or terminate playout should it detect any missing integrity pack metadata for the encrypted frame currently being processed. The SMS may direct the SM to resume playout from a subsequent track file frame location. However, playout shall be subject to the same requirement.
Each type 1 Secure Processing Block (SPB) can be considered an SPB system, since it operates as a collection of SEs. Similarly, the projector also has its associated type 2 SPB, which does not contain SEs, but fulfills security functions as described below. (Secure Processing Block types are defined in Section 9.4.2.2. The Secure Processing Block (SPB)).
This section defines the functions and operational requirements for the following SPB systems:
In addition to the specific requirements given for SPB systems in this section, all SPB systems shall meet the behavior requirements of Section 9.6.1. Digital Rights Management.
From a security perspective, a projection system consists of the projector Secure Processing Blocks (SPB) type 2 and its companion SPB, which will be either the Link Decryptor Block (LDB) or Image Media Block (IMB).
The following are the normative requirements for the projector Secure Processing Block (SPB):
The following requirements are normative where Link Encryption is used:
The following requirements are normative where an SPB that performs link decryption followed by link encryption is used (see Section 9.4.4.1. Special Auditorium Situations):
The following are normative requirements for the Image Media Block:
The following are the normative requirements for the Outboard Media Block:
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 (RRP)).
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.
This section assumes that the LDB and IMB are implemented as field replaceable SPB modules. It is not mandatory, however, that they be implemented in this fashion. It is allowed, for example, for the LDB to be permanently married to a projector, and not field replaceable. In such a case where the projector and its companion SPB (LDB or IMB) are not field separable, there is no marriage event, and thus no reason to monitor whether the marriage connection is broken. This relieves the companion SPB from marriage monitoring duties, but does not change the requirement for IMB or LDB equivalent SPB functions, and the projector SPB, to meet the respective SPB type 1 and type 2 physical and logical protection requirements of Section 9.5. Implementation Requirements, and the normative requirements as specified above, except as the latter requirements relate to marriage event and connection monitoring.
In the case where the Projector and companion SPB are inseparable, a single Digital Cinema Certificate shall represent both the Projector and its companion SPB (Image Media Block or Link Decryptor Block). For dual certificate implementations this shall be the Security Manager Certificate (see Section 9.5.1. Digital Certificates).
Implementations that do not meet the marriage functions, per the normative requirements of this section, shall not permit field replacement of the IMB or LDB security function as appropriate according to which function is the companion SPB to the projector, and shall require the projector SPB and companion SPB system to be replaced in the event of an SPB failure.
A deviation from these requirements shall be considered non-compliant and a “Security Function Failure” (see Section 9.5.5. Compliance Testing).
Note: For permanently married implementations where there are no remote SPBs the KDM need not carry Trusted Device List (TDL) information. The KDM syntax requirement that the associated “DeviceList” element not be empty can be satisfied by placing any Digital Cinema certificate thumbprint in this field.
Note: Nothing in this section shall require that the user interfaces of the SMS or TMS use UTC. It is envisioned that these will use local time.
To ensure playback times and event log time stamps are time-accurate, means must exist to distribute and maintain proper security system time. Time shall mean UTC (Coordinated Universal Time). See ASN.1 standard syntax for transferring time and date data “GeneralizedTime” and “UTCTime”.
Image Media Block (IMB) and Outboard Media Block (OMB) Security Managers shall each be responsible for maintaining secure and trusted time for their respective MBs. Additional security system clock requirements are:
Link Encryption shall be used at all times (i.e., for encrypted and clear text content) where image content is carried on interconnecting cables, which are exposed (i.e., outside of an SPB) downstream from image media decryption. 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 Implementation).
Where Link Encryption is used (i.e., Auditorium 2 Figure 15: Digital Cinema Auditorium Security Implementation), the Image Media Block (IMB) SM shall provide link encryption keys for use with the Link Encryptor (LE) and Link Decryptor (LD) Security Entities (SE) located within the IMB and Link Decryptor Block (LDB) SPBs respectively. Authentication of the LDB by the IMB SM (see Security Manager and LDB requirements of Section 9.4.3.5. Functions of the Security Manager (SM) and Section 9.4.3.6.2.1. Normative Requirements for LD/LE SPB Devices) shall be performed to ensure that link keys are provided only to legitimate devices which appear on the KDM Trusted Device List (see Section 9.4.3.5. Functions of the Security Manager (SM), items 7 and 9c)). Link Encryption keys shall be delivered to the LDB using the appropriate category 2 standardized security messages of Table 15: Intra-theater Message (ITM) Request-Response Pairs (RRP).
In the case of playback of clear text content (as indicated by the CPL), no KDM is required, and in such a case no TDL will exist. Recognizing that combinations of clear text and encrypted content must be accommodated, the following rules define normative Link Encryption functionality:
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 9.4.5.2.4 Request-Response Pairs (RRP) (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.
It is mandatory that a fresh Link Encryption key be used for each movie showing (i.e., each playout of an encrypted composition requires a new LE key.) Multiple Link Encryption keys may be used for showings, and in such cases, it is encouraged that different LE keys be distinguished by (used according to) the CPL (where different Composition Playlists constitute a showing). In the case where multiple LE keys are used, it will be necessary for the industry to standardize on a single technique to identify which LE key is to be used for which portion(s) of any given showing.
“Special Auditorium Situations” are defined to allow the Image Media Block (IMB) to operate with more than a single projector. Special Auditorium Situations shall be enabled by the following methods:
IMB SMs shall enable Special Auditorium Situations to operate only when the SM receives a KDM whose Trusted Device List (TDL) contains only the identities of the SPBs it is enabling for playback. For IMB with Multiple Link Encryption operation these shall be the remote SPBs identified during TLS authentication (see details below). For Integrated IMB with Link Encryption this additionally includes the identity of the projector to which the IMB is married. This matching is an indication to the SM that Special Auditorium Situations operation has been approved by the content owner.
IMB with Multiple Link Encryption operation or Integrated IMB with Link Encryption operation shall follow all normal (single) Link Encryption requirements of this section, with the following additional requirements:
This Section discusses requirements for communications necessary to support security functions in each auditorium. Depending upon facility communications network designs, there may be both intra-auditorium as well as theater-wide networks and these may be physically one network. The security system requires and addresses only the intra-auditorium network, over which Intra-Theater (security) Messages (ITM) are employed.
Intra-Theater Message(s) (ITMs) are described for communications between the SMS and SM(s), and between the SM(s) and remote Secure Processing Blocks (SPBs). The Image Media Block (IMB) shall support all ITMs as defined in this section. The Outboard Media Block (OMB) shall only support ITMs between the SMS and OMB (the OMB does not support Link Encryption or authenticate remote SPBs and thus shall not support Auditorium Security Messaging).
The SM and (non-integrated) SMS shall both conduct their intra-theater messaging under TLS protection. TLS version 1.3 as defined in IETF RFC 8446 should be used. For purposes of interoperability, TLS version 1.0 as defined in IETF RFC 2246 shall be supported. TLS version 1.2 as defined in IETF RFC 5246 may be supported.
Note: TLS versions higher than 1.0 include handshakes that determine the supported TLS version(s) of both end points.
All TLS end points shall be within the physical protection perimeter of the associated SPB. No SPB requirements are placed on the SMS.
This section identifies the set of Intra-Theater Messages standardized by this specification. These are required to support interoperability and normative operational and security behavior of SPB systems.
The following hierarchy for Intra-Theater Messaging (ITM) is defined:
A transaction consists of sequences of RRPs, and RRPs are pairings of messages. A transaction is an interaction, or series of interactions (RRPs) that change the state in one or more participating SEs in a consistent manner. Transactions need not be standardized. In assembling transactions, the sequences of RRPs used may vary according to the equipment vendor or facility configuration. Transactions shall be “idempotent” (such a transaction may be repeated without changing its outcome). Thus, if the initiator of a transaction does not receive evidence of satisfactory completion, it may safely initiate the transaction again without fear of unexpected consequences.
RRP standards do not apply inside of Secure Processing Blocks (SPBs), however RRP concepts are developed assuming that a Security Entity (SE) will exist logically within a SPB, even if not distinctly in hardware. The SPB is allowed to proxy for any SE (within it) in the support of security messaging.
The following abbreviations and terms are used in this ITM section:
Table 15: Intra-theater Message (ITM) Request-Response Pairs (RRP) lists "standardized security messages" (category 2) and suggested "operational messages" (category 1). The following establishes the implementation requirements for these message types:
The term "Auditorium Security Messages" (ASMs) in SMPTE 430-6 corresponds to the term "standardized security messages" in this specification. The combination of the terms "standardized security messages" and "operational messages" are referred to in this specification as Intra-Theater Messages (ITMs).
Message Category | Function |
---|---|
1.SMS to SM
StartSuite StopSuite CPLValidate KDMValidate TimeAdj |
Suggested operational messages
Commands SM to establish TLS sessions with remote SPBs Commands SM to terminate TLS sessions withremote SPBs Requests that the SM perform a CPL validation check Requests that the SM perform aKDM validation check Adjusts time at SM (within annual limits) |
2.IMB SM to SPB
BadRequest GetTime GetEventList GetEventID QuerySPB LEKeyLoad LEKeyQueryID LEKeyQueryAll LEKeyPurgeID LEKeyPurgeAll GetProjCert |
Standardized security messages
Special "Response" indicating failure to process a "Request" Requests a snapshot of a remote SPBs absolute (UTC) time Requests a list of logged event IDs for a specified time window Requests the return of a specified logged event by ID Interrogates a remote SPB as to health and status Delivers one or more LE keys to a Link Decryptor Block (LDB) Interrogates the LDB for the presence of a specified LE key Requests a report of all active LE keys by key ID Commands the LDB to purge a specified LE key Commands the LDB to purge all active LE keys Requests the LDB to deliver a copy of the projector certificate |
This section provides particular requirements for specific messages.
Image Media Block to remote SPB messages are category 2 Intra-Theater Messages of Table 15: Intra-theater Message (ITM) Request-Response Pairs (RRP) Standardized security messages are defined in SMPTE 430-6 D-Cinema Operations - Auditorium Security Messages. The following requirements are in addition to those in SMPTE 430-6:
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 are informative.)
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, Tables A-1, A-2) |
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, Tables A-1, A-2) ** Response (see SMPTE 430-6 Section 6.3.): 0 - RRP successful 1 - RRP failed 2 - RRP Invalid 3 - ResponderBusy |
Forensics do not prevent content theft or other compromises, but rather, it provides methods for their detection and investigation. Forensic features deter attackers who are aware that their actions would be logged and/or reported in considerable detail.
Forensic features fall into two classes: Forensic Marking (FM) and logging. Forensic Marking embeds tracking information into content itself, to be carried into subsequent legitimate or stolen copies. Logging creates records of both normal and abnormal events in the Distribution and Exhibition process. During a content theft investigation, both FM and logging information may be combined to establish the details of the security compromise.
Industry terminology for watermarking and Forensic Marking is not consistent. For these security specification purposes, stakeholders have agreed to use the term Forensic Marking for all content marks.
These specifications require that image, audio and Aux Data Forensic Marking (FM) capability be included (as applicable) in each Media Block. The security system identifies content marking devices (e.g., Forensic Marking embedders) as the “FM” Security Entity (SE) type. To support FM processes, standardized Intra-Theater Messaging (ITM) may be used where needed for communications between such SEs and Security Managers (SMs). Such communications and associated FM behavior is outside of this specification. However the requirements of ITM Section 9.4.5. Intra-Theater Communications shall be mandatory where such theater messaging employs the intra- auditorium security network. Forensic Marking does not require interoperability between detection systems, as the detection operation is usually performed “off line” as part of a security investigation.
Multiple solutions may be qualified and will allow Media Block solutions providers to select the solution of their choice. Candidate providers should meet with individual studios to discuss RAND and technical suitability of their approach.
Note: DCI reserves the right, at some future time, to require a specific Forensic Marking insertion solution for Digital Cinema systems.
At a minimum, Forensic Marking systems are required to meet the following:
There may be differing circumstances surrounding the desire by a Rights Owner to forensically mark content. To accommodate these variations, it is necessary to be able to independently control the activation of both the audio and the image Forensic Marking (FM). The following rules shall be normative for Forensic Marking operations:
In the Exhibition environment, the preparations for and execution of a movie showing creates information that has security and forensic implications. The capturing and storage of such information is the responsibility of the logging subsystem. In order to realize a “control lightly/audit tightly” end-to-end security environment, the security system includes a secure logging subsystem.
Cryptographic technology as applied to essence and key delivery, together with agreed upon usage rules provides the “control lightly” characteristics. The function of a logging subsystem is to respond to the “audit tightly” requirement. Logging is therefore observed as a critical component of security, and secure logging information and surrounding processes are subject to the same fundamental cryptographic requirements as the front end control components: cryptographic protection of critical functions and data components related to integrity, data loss, confidentiality and movement.
This section sets the logging subsystem requirements for security log data recording and reporting. The log information data formats and structures to be used in conjunction with these requirements are defined in two SMPTE standards:
SMPTE 430-4 defines the general format for log classes for digital cinema. SMPTE 430-5 defines the specific requirements for the security log class. All log requirements and terminology of this section are with respect to the SMPTE 430-5 security events class constraints specification.
Definitions related to logging:
Following the above definitions, a basic logging process is described:
Log record and report formats shall be compliant with SMPTE 430-5 D-Cinema Operations – Security Log Event Class and Constraints for D-Cinema.
Log signatures and integrity controls shall be compliant with SMPTE 430-5 D-Cinema Operations - Security Log Event Class and Constraints for D-Cinema.
For dual certificate implementations (see Section 9.5.1.2. Dual Certificate Implementations), the following requirements are in addition to those in SMPTE 430-5:
Log record sequencing shall be compliant with SMPTE 430-5 D-Cinema Operations – Security Log Event Class and Constraints for D-Cinema.
Auditorium suites using Link Encryption shall transfer log records from remote Secure Processing Blocks (SPB) to that auditorium's Image Media Block (IMB) SM using the GetEventList and GetEventID standardized security messages of Table 15: Intra-theater Message (ITM) Request-Response Pairs (RRP)
Per Section 9.4.3.7. Theater System Clocks and Trustable Date-Time, the Security Manager collects UTC time-stamped reports from remote SPBs via the GetTime standardized security message. The SM shall use the GetTime information to calculate the difference between true time (the SM's time) and time in the remote SPB, and remove the difference in reporting remote SPB event data. The reporting (export) of log information from the IMB shall be by XML structure that is compliant with SMPTE 430-5 D-Cinema Operations - Security Log Event Class and Constraints for D-Cinema.
Log record and/or report filtering processes shall be compliant with SMPTE 430-5 D-Cinema Operations - Security Log Event Class and Constraints for D-Cinema.
For distribution of log information, it may be necessary to filter log content so that log reports can be generated that supply log record content selectively to the appropriate recipients. The location(s) where log data filtering takes place (e.g., in the Image Media Block (IMB), Outboard Media Block (OMB) or in external theater-controlled devices or processes) is an implementation decision.
Media Block Security Managers shall provide (export) log event information in the form of log reports (not log records) as defined in SMPTE 430-5 D-Cinema Operation - Security Log Event Class and Constraints for D-Cinema.
The EventID (see SMPTE 430-4 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.
The logging subsystem shall follow the requirements for specific log data to be recorded as defined in SMPTE 430-5 D-Cinema Operations - Security Log Event Class and Constraints for D-Cinema. SMPTE 430-5 defines the following data types for the "Security Class" category of log information:
EventType - Identifies a log record as being associated with one of a Playout, Validation, Key, ASM or Operations event.
EventSubType - Specifies what information is to be logged for each Event Sub Type record.
Each Secure Processing Block (SPB) type shall log the Event Sub Type records as shown in Table 19: Security Log Event Types and Subtypes.
IMB or IMBO | OMB | LDB | LD/LE SPB | Proj. SPB | |
---|---|---|---|---|---|
Playout Event Sub Types | |||||
FrameSequencePlayed | X | X | |||
CPLStart | X | X | |||
CPLEnd | X | X | |||
PlayoutComplete | X | X | |||
Validation Event Sub Types | |||||
CPLCheck | X | X | |||
Key Event Sub Types | |||||
KDMKeysReceived | X | X | |||
KDMDeleted | X | 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[15] | ||||
SPBClose | X[15] | ||||
SPBMarriage | X[16] | X | |||
SPBDivorce | X[16] | X | |||
SPBShutdown | X | X | X | X | |
SPBStartup | X | X | X | X | |
SPBClockAdjust[17] | X | X | X | X | |
SPBSoftware | X | X | X | X | |
SPBSecurityAlert | X | X | X | X |
In addition to the requirements specified in SMPTE 430-5, the following shall be normative for DCI compliance:
The secure logging subsystem is required to be operable as a prerequisite to playback. Security Managers (SMs) shall not enable for playback (i.e., key) any suite for which it has not collected log records from Secure Processing Blocks (SPBs) per Section 9.4.6.3.1 Logging Requirements item (8), or if there is any indication that a next playback will not record and report log records as required. Behavior of security devices (SPB or SE) 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 and SEs shall not be purgeable except by authorized repair centers, which are capable of securely recovering such log records.
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.
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.)
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:
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 Media Blocks. (FIPS requirements are addressed in Section 9.5.2. Robustness and Physical Implementations and Section 9.8. Digital Certificate, Extra-Theater Messages (ETM), and Key Delivery Messages (KDM) Requirements.)
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 digital 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 shall be as given in Section 9.8. Digital Certificate, Extra-Theater Messages (ETM), and Key Delivery Messages (KDM) Requirements. Except as otherwise specified below, the requirements for all digital certificates (i.e. both single and dual use implementations) shall be the same.
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 and model of each certificated device shall be carried in the assigned certificate, and the serial number and device role(s) (see below) shall in particular be carried in the Common Name (CN) field of the assigned certificate. 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.
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 following role(s) shall be included for the IMB and OMB, as applicable:
Note:
Dual (two) certificates are used only with the Image Media Block (IMB) and Outboard Media Block (OMB), 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:
The Log Signer Certificate shall enumerate roles only as follows:
In addition to the above, dual certificate implementations require Digital Cinema certificate validation rules that may not be reflected in the current SMPTE digital cinema specification (see DCSS Section 9.8., SMPTE 430-2: “D-Cinema Operations – Digital Certificate”). The affected validation rule is driven by the “Key Usage” constraints as given in Table 2 of SMPTE 430-2 (“Field Constraints for Digital Cinema Certificates”), which is then reflected in validation rule # 6 of section 6.2. “Validation Rules”. For dual certificate implementations validation rule # 6 shall be as stated in SMPTE 430-2 for single certificate implementations, except as follows:
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.
This security system protects Digital Cinema content during transport and storage through the use of secret keys. Key secrecy is maintained in normal operations by cryptographic techniques dependent upon other secret keys. The physical protection afforded secret keys, and the content itself once decrypted, determine the robustness of the security implementation.
Robustness is required for all modes of operation, both normal and abnormal. Robustness is a function of the quality of the implementation of security devices, Exhibition operational procedures, and the security system itself.
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 Section 9.5.2. Robustness and Physical Implementations.
Sensitive data critical to the security of the Secure Processing Block (SPB) or SE (e.g., private keys, LE/LD or content keys) is generically referred to as a Critical Security Parameter (see Section 9.5.2.6. Critical Security Parameters and D-Cinema Security Parameters). CSPs and plain text content essence shall be physically protected by Secure Silicon and/or Secure Processing Blocks as described below:
The following address restrictions on repair and renewal of Secure Processing Blocks (SPBs) and associated cryptographic parameters:
Repair and renewal is limited to failed devices, or devices which have lost or zeroed their secrets (e.g., private keys or digital certificates). Such maintenance does not effect the device’s FIPS 140-2 certification or compliance, as long as Section 9.5.2.5. FIPS 140-2 Requirements for Type 1 Secure Processing Blocks requirements are met. Requirements for firmware changes to SPBs are given in Section 9.5.2.7. SPB Firmware Modifications.
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: Projector Secure Processing Block. 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:
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.
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:
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:
Once triggered, to clear (i.e., reset) a security access opening event shall require:
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:
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.
Robustness requirements for type 1 Digital Cinema Secure Processing Blocks (SPBs) shall meet the requirements of Federal Information Processing Standards 140 (FIPS 140), which specifies the security requirements for a cryptographic module utilized within a security system protecting sensitive information in computer and telecommunications systems.[18] There have been several iterations of FIPS 140, referred to as FIPS 140-1, FIPS 140-2 and FIPS 140-3 respectively. To become FIPS certified, type 1 SPB cryptographic modules shall be evaluated by a FIPS accredited laboratory against a then-active FIPS 140 version.[18]
Once an SPB has received FIPS 140 certification, this specification considers its certificate valid for subsequent production of that model, independently of whether or not FIPS 140 certification processes have changed. However, FIPS guidelines mandate that design changes made to an SPB may require recertification of the device. In such event the then-active FIPS 140 certification requirements shall be used in obtaining a valid FIPS certificate to meet the requirements of this specification.
Suppliers are advised that a FIPS certified cryptographic module that has not been reviewed by an accredited FIPS laboratory within five years of its certification date will be automatically moved from the FIPS 140 “active” module status list to the “historical” list until such time as it is reviewed. Though a historical listing does not impact a module’s status with respect to its approval for Digital Cinema applications, suppliers are encouraged to maintain their SPB type 1 devices on the FIPS 140 active list.
General FIPS 140 requirements:
Specific requirements for type 1 SPBs certified to FIPS 140-3 are provided in Table 20.
Table 20 references “areas” related to the design and implementation of a cryptographic module as specified in FIPS 140-3 and ISO/IEC 19790:2012(E) “Information technology – Security techniques – Security requirements for cryptographic modules,” and references “sections” found therein.
Area | ISO 19790 Section | DCI requirements are per FIPS 140-3 Level 3 unless otherwise noted, inclusive of the following specific requirements: |
---|---|---|
Cryptographic module specification | 7.2.3 | The “cryptographic boundary” shall be the SPB-1 physical perimeter. |
7.2.4.3 | Degraded mode(s) of operation shall not be permitted. | |
Cryptographic module interfaces | 7.3.3 | An SPB-1 shall inhibit its control output interface during each error state. |
7.3.4 | Logical data port separation requirements shall be supported by the use of TLS protection on well-known port 1173 as defined in Section 9.4.5.2.3. General RRP Requirements. | |
Roles, services and authentication | 7.4.2 | A Maintenance Role shall not be permitted. |
7.4.3.3 | An SPB-1 may support “self-initiated cryptographic output capability” provided that a User Role and/or Crypto Officer Role shall be required to support the AuthorityID per Section 9.4.2.5. “Screen Management System”. | |
Software / Firmware | 7.5 | No DCI specific requirements. |
Operational environment | 7.6.1 | The operational environment shall be constrained to the limited or non-modifiable operational environment. |
Physical security | 7.7.1 | Environmental Failure Protection (EFP) and Environmental Failure Testing (EFT) requirements are recommended but not required. |
7.7.2 | The strength and hardness of SPB-1 physical security enclosure material(s) over the
SPB-1’s range of operation, storage, and distribution shall be verified by review
of design documentation. Additionally, destructive physical attacks shall be performed
on SPB-1 at nominal temperature(s) to verify the strength and hardness of SPB-1 physical
security enclosure material(s). Destructive physical attacks on SPB-1 at additional temperatures
is recommended but
not required.
If tamper-evident seals are employed, it is recommended but not required that they be uniquely numbered or independently identifiable. EFP/EFT requirements are recommended but not required. |
|
Non-invasive security | 7.8 | No DCI specific requirements. |
SSP management | 7.9 | No DCI specific requirements. |
Self-tests | 7.10.3.8 | The specified Security Policy maximum time between periodic self-tests shall not be more than one week. SPB-1 designs should ensure that automatic periodic self-tests do not occur during playback of a DCP. |
Life-cycle assurance | 7.11.8 | End of life procedures for the secure destruction of SPB-1 are deferred to the equipment owner and/or equipment manufacturer. |
Mitigation of other attacks | 7.12 | No DCI specific requirements. |
Type 1 SPBs certified to FIPS 140-2 shall meet the requirements of FIPS 140-2 Level 3 in all areas, subject to the following exceptions or additional notes:
A requirement of FIPS-140-2 is to list the Critical Security Parameters (CSP) that are important for the security of Digital Cinema cryptographic module(s) (Secure Processing Block) and its functions. The following CSPs shall receive Secure Processing Block (SPB) type 1 protection, whenever they exist outside of their originally encrypted state.
The following items are not considered FIPS 140-2 CSPs, but are considered D-Cinema Security Parameters, and shall at all times be protected by a type 1 SPB perimeter (except where log data is extracted per Section 9.4.6.3.).
In addition to the “limited” or “non-modifiable” Operational Environment requirements of FIPS 140, the following defines additional requirements for making software or firmware changes to type 1 Secure Processing Blocks (SPB)[20].
The following defines the requirements for making firmware changes to these security devices. FIPS 140-2 constrained devices shall:
There are no physical constraints or requirements imposed on the SMS by the security system (i.e., no SPB requirements); however, the SMS implementation shall not otherwise weaken or effect the security operations of other Security Entities or SPBs.
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:
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.
The following are required for the exhibition of content and security communications, and communications networks:
This section describes the standardized Digital Cinema security operational features, and how “trust” is communicated and enforced to ensure security features are reliably executed. A security policy is what results once the variables that develop, from the overall security system design and implementation, are constrained according to desired operational characteristics. An open architecture security system should not dictate any specific policy, but enable stakeholders to agree on one more policies that support business needs. Once policy has been decided, it can be described operationally as the security feature set.
This section identifies various features and functions that describe the operation of the security system. For each auditorium, the security system consists of three types of components involved in Digital Rights Management (DRM):
The last two components have access to, and process, Digital Cinema security information (secrets), such as content keys or plain text content. They are the primary subject of these security specifications. The Screen Management System does not have access to such secrets. But because the Screen Management System initiates security-related activity, it is considered a participant in security events.
The basic business philosophy is to “control lightly, audit tightly.” Per this philosophy, a movie will fail to playback only under four circumstances:
Compliance to security system logging requirements ensures that all events having security implications will generate associated log records that are stored in the Media Block(s). These log records can be accessed by the exhibitor’s Screen Management System, and reports can be provided to appropriate distributors under contractual obligations.
All three types of security system components (Screen Management System, Security Manager, security equipment) have defined roles and responsibilities (e.g., to perform their security functions and generate log records), and overall security depends upon their proper operation. The descriptions below detail the three types of security system components. Included in the Security Manager and security equipment description are tables showing possible security system operational scenarios and how the system responds to a particular issue.
The tables are also designed to be informative to parties interested in understanding business issues in relation to the Digital Cinema security system. It shows that the security system’s reach is limited to only those areas necessary for ensuring persistent protection of content and security data (keys), enabling content to play within a designated time window, and the provisioning of reliable log data (see Table 21: Examples of Security Manager Events and Table 22: Examples of Failure or Tampering of Security Equipment).
The Screen Management System is responsible for managing Exhibition functions such as showtime movie playback, and is under the control of the Exhibitor. The Screen Management System manages playback functions via the Security Manager(s), however the Security Manager is at all times in control of and responsible for security functions and events. The full complement of Exhibition operational events therefore consists of those under the control of the Security Manager(s) and those under the control of the Screen Management System.
The Security Manager is the executor of Digital Rights Management for the Media Block that contains it. In addition, the Image Media Block (IMB) is also responsible for each Secure Processing Block (SPB) in the associated Equipment Suite. Security Managers control content keys and the delivery of such keys to the appropriate Security Entities (SE) to enable playback of encrypted content. Keys are considered active for the business defined play period. Subject to security equipment authentication, proper operation, and integrity checks (see Section 9.4.3. Theater Security Operations), the Security Manager exercises no control over playback, other than content key delivery during the valid play period. Under private business negotiations, a Distributor may provide keys for selected or all Security Managers (i.e., projectors) in a complex.
Item, Observation or Issue | Approach |
---|---|
Authorized auditorium | KDM (keys) is sent to authorized auditorium SM |
Engagement Play-out Window | KDM contains designated key use time/date window |
Only known & trusted devices are enabled | SM authenticates equipment prior to key delivery |
Modified Movie File | At playback, SM checks and logs movie against CPL |
The above table depicts events related to the Security Manager and the system’s behavior. A film will not play-out if there is a failure in any of the items in rows 1, 2 and 3 due to wrong location (row 1), wrong date/time (row 2), or the attempted use of an unauthorized device (row 3). In the event of modification in a movie file (row 4), the file should be replaced, but there are no Security System controls preventing an Exhibitor from playing-out a modified file. This event, like all security events, will be logged.
Security Entity equipment must perform to specified standards and function as designed. The Security Manager will continuously test for proper Security Entity identification (authentication), operation and physical integrity (tampering). Content playback is restricted to passing all security tests at all times.
Item, Observation or Issue | Approach |
---|---|
Security equipment tampering or failure | A tampered or failed device is non-functional until replaced |
Auditorium (intra-suite) Security Network | Network must be operative to initiate playback |
The above table depicts tampering or failure of security equipment. Security equipment that has been tampered with or is malfunctioning (row 1) shall not continue operation and must be replaced before playback can commence (or continue). An example of malfunctioning security equipment is a Media Block that no longer performs one of its security functions (e.g., decryption, Forensic Marking, logging). If the auditorium security network is inoperative (row 2), playback cannot start. However, the security system will not cause playback to stop upon failure of the network during a show.
The information previously contained in this section has been deleted as redundant or relocated as needed to other sections of this specification.
The security system employs widely used and rigorously tested ciphers for use in Digital Cinema. The following are requirements pertaining to Digital Cinema applications for ciphers and associated security parameters.
Content security is transport agnostic, and can be accomplished by either electronic or physical means. Other than as authorized and intended by Rights Owners (e.g., to support Distribution practices or requirements), content shall only be decrypted at playback time at the exhibition site under the policy of the SM.
The AES cipher, operating in CBC mode with a 128 bit key, shall be used for Digital Cinema content encryption. See [FIPS-197 “Advanced Encryption Standard (AES)” November 26, 2001. FIPS-197] and Section 5.3.2. MXF Track File Encryption, for MXF track file encryption details.
The content Rights Owner shall determine which, if any, of the essence types in the composition are encrypted for distribution.
Subtitle encryption shall comply with the SMPTE published standard "SMPTE 429-5 D-Cinema
Packaging - Timed Text Track File".
Subtitle encryption is directed primarily against interception during transport, and cryptographic protection within the theater 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.
The RSA Public Key Cipher (with 2048-bit key) shall be used to protect keys for distribution. This is accomplished by the requirements of the Key Delivery Message.
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.
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. Equipment suppliers are cautioned to take into consideration NIST and FIPS transition timing and FIPS validation lead times.
Data integrity signatures (hash values) shall be generated/calculated according to the PKCS-1 Digital Signature Standard, as specified in [IETF RFC 3447 (RSA and SHA-256)]. All signatures shall use SHA-256. Digital Certificates in X.509v3 format as constrained according to Section 9.8., shall be used to authenticate signatures. Signature element definitions and other signature details are available in the specification for each signed data structure.
Cryptographic data integrity checksums shall be ensured according to the HMAC-SHA-1 algorithm, as specified in [FIPS PUB 198a “The Keyed-Hash Message Authentication Code.”]
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.
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.
No more than 256 keys shall be used to encrypt the essence of a single composition (i.e., Composition Playlist). To support multiple shows, the Media Decryptor shall be capable of securely caching at least 512 keys. The Show Playlists may be comprised of multiple compositions.
The following Society of Motion Picture and Television Engineers (SMPTE) published
standards shall be utilized: