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]
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. Glossary Of Terms 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]
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
1
and
Figure
2:
System
Overview
Functional
Decode
Flow
2
.
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.
Note:
See
Section
10.2.1.
Single
Inventory
of
Stereoscopic
Digital
Cinema
Packages
(DCP)
for
requirements
specific
to
stereoscopic
presentations.
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 1: 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.
Note
2:
See
Section
10.2.
Stereoscopic
Digital
Cinema
Requirements
for
requirements
specific
to
stereoscopic
presentations.
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
3
.
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
discrete
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.
As referred to in this specification:
All requirements of this specification shall be applicable to both of the above DCP types, unless otherwise specified as directed to a Standard DCP or an IAB DCP.
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 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.
Note:
See
Section
10.2.2.
Form
of
Stereoscopic
DCPs
for
requirements
specific
to
stereoscopic
presentations.
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 |
The audio requirements of this specification were originally defined for a DCP that contains 16 channels of "Sound Essence" in a single track file as specified in SMPTE ST 429-2. With the development and introduction of Object-Based Audio Essence (OBAE), also referred to as Immersive Audio, on September 9, 2013, DCI published the Digital Cinema Object-Based Audio Addendum (subsequently updated on October 1, 2018). This provided a set of requirements for implementing OBAE in a DCP using an Immersive Audio Track File as specified in SMPTE ST 429-18 and SMPTE ST 429-19.
OBAE requirements are now included within the body of this specification, which refers to OBAE in lieu of Immersive Audio.
Digital Cinema audio requires standardized characteristics, channel mapping and a file format to successfully playback in a motion picture theater. This specification establishes requirements for two audio formats, as follows:
All audio requirements of this specification shall be applicable to both of the above formats, unless otherwise specified as directed to Sound Essence or to OBAE.
The SMPTE published standard "SMPTE 428-2: D-Cinema Distribution Master - Audio Characteristics" shall be utilized. For OBAE, "SMPTE 2098-1 Immersive Audio Metadata" and "SMPTE 2098-2 Immersive Audio Bitstream Specification" shall also 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.
For Sound Essence, the channel labels and schema in SMPTE ST 429-2 "D-Cinema Packaging-DCP Operational Constraints" shall be utilized. For OBAE, the channel labels and schema in SMPTE ST 2098-2 Immersive Audio Bitstream Specification 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.
OBAE shall be carried in the MXF file format conforming to SMPTE ST 429-18 D-Cinema Packaging - Immersive Audio Track File.
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.
DCP Packaging shall adhere to SMPTE standards so that equipment receiving a compliant DCP can process and interpret it unambiguously. This format is encouraged to be a license-free technology.
For a Standard DCP, essence shall be packaged with all provisions of SMPTE ST 429-2 "D-Cinema Packaging - DCP Operational Constraints."
For a DCP containing OBAE (an IAB DCP), essence shall be packaged consistent with all provisions of [SMPTE ST 429-19 D-Cinema Packaging – DCP Operational Constraints for Immersive Audio].
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.
Note:
See
Section
10.2.2.
Form
of
Stereoscopic
DCPs
for
requirements
specific
to
stereoscopic
presentations.
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
7
.
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
8
.
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.
Note:
See
Section
10.2.2.
Form
of
Stereoscopic
DCPs
for
requirements
specific
to
stereoscopic
presentations.
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:
A Sound Track File contains the Sound Essence data and its associated metadata. Sound Track Files shall be per SMPTE ST 429-3. The following are requirements for a Sound Track File.
Note:
See
Section
10.2.2.
Form
of
Stereoscopic
DCPs
for
requirements
specific
to
stereoscopic
presentations.
The Sound 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 Sound Track File shall be wrapped using KLV on an image frame boundary.
The Sound Track File is required to support uncompressed audio data.
The following metadata is required to be furnished with the Sound Track File:
OBAE shall be carried in an Immersive Audio Track File per SMPTE ST 429-18 D-Cinema Packaging – Immersive Audio Track File, which specifies all required metadata.
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 generic 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
the
controller
and
which
is
slave.
the
responder.
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
Table
8
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
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.
security
communications.
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
For
both
hard
disc
drives
(HDD)
and
solid
state
drives
(SSD)
there
are
a
number
of
established
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
HDD
or
SSD
module
fail,
the
system
will
continue
to
play
with
no
visible
or
audible
interruptions
or
artifacts.
The
storage
system
implementation
shall
be
field
serviceable.
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
(at
289
Mbits/sec
if
48
kHz
audio
is
used
or
307
Mbits/sec
if
96
kHz
audio
is
used)
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)
9
,
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
also
be
is
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,
system,
as
shown
in
Figure
12:
Media
Block
in
Projector
Configuration
12
.
[5]
5
In
addition
to
the
two
single
Image
Media
Block
(IMB),
Block,
single
projector
configurations
configuration
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.
In
connection
with
OMB
functionality,
the
"IMB
with
OMB
functions"
(IMBO)
is
defined,
and
may
be
used
alternatively
to
the
IMB
in
projection
systems.
See
Section
9.
Security
for
details
of
MMB
and
OMB
requirements
and
operation.
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
.
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.
OBAE shall be rendered within the type 1 SPB perimeter of 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
Projection
system
not
only
provides
the
Media
Block
is
present
inside
main
image
on
the
projector.
screen,
it
can
provide
subtitles,
open
captioning,
and
still
pictures.
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.
For Sound Essence: 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, Right, Center, 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.
For OBAE: A playback system designed to play OBAE is required to provide the capability to render multiple playback channels to the immersive sound system in the theater. The rendering of object-based audio into a specific sound reproduction format is proprietary to manufacturing companies and is not addressed in this specification.
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.
For Sound Essence: This is a real time digital audio link that shall have the capacity for delivering 16 channels of digital audio at 24-bit 48 kHz. It is encouraged that this link support 96 kHz. For purposes of clarity, the MB shall be capable of processing 16 channels of 24 bit audio at 48 kHz , and is encouraged to be capable of processing audio similarly at 96 kHz. This link is required to follow [AES3-2003] recommended practice for serial transmission format for two-channel linearly represented digital audio data.
For OBAE: Rendered OBAE shall be output from the Media Block to the theater audio system using an interoperable standard multichannel format that is capable of meeting the audio bandwidth requirements for the rendered channel count. The exact interface format is not specified. It is encouraged that this link support 96 kHz. The interface must be capable of delivering the maximum number of rendered channels to the cinema processor at 48 kHz. It is encouraged to be capable of processing OBAE at 96 kHz.
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
Table
10
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
13
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
support,
for
each
screen,
a
sustained
rate
of
289
Mbits/sec
if
48
kHz
audio
is
used
or
307
Mbits/sec
if
96
kHz
audio
is
used:
250
Mbits/sec
for
compressed
image
(250
Mbits/sec),
audio
(37.87
image,
38
Mbits/sec
-
for
16
channels,
24
bit
sample,
channels
of
24-bit
samples
at
96
KHz)
KHz
or
19
Mbits/sec
for
16
channels
of
24-bit
audio
samples
at
48
KHz,
and
subtitle
data
(subpicture
20
MBits/sec)
MBits/sec
for
each
screen.
subtitle
data
(subpicture).
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 networks that support two main categories of communications:
The
following
is
a
list
of
devices
and
examples
of
typical
communications:
Figure
13
depicts
an
exemplary
multiplex
theater
system
architecture
with
four
auditoriums.
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:
Uncompressed
image
interface
(with
Link
Encryption),
or
a
Media
Block
Interface
(if
the
Media
Block
is
installed
in
the
projector)
into
which
either
an
IMB
or
IMBO
will
be
installed.
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
).
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
Security
aspects
of
the
use
of
these
interfaces
is
are
described
under
Section
9.
Security
The
preferred
implementation
of
projector
includes
a
Digital
Cinema
system
would
locate
the
Media
Block
in
the
projector.
Interface
into
which
either
an
IMB
or
IMBO
is
installed.
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 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.
In
conjunction
with
enabling
MMB
auditorium
configurations,
and
in
recognition
that
the
digital
cinema
industry
is
no
longer
designing
new
equipment
implementing
Link
Encryption
(LE)
functionality,
this
specification
restricts
LE
implementations
to
non-MMB,
non-OBAE
processing
projection
booth
configurations
as
follows:
An
MMB-capable
IMB
or
an
IMBO
shall
be
integrated
with
no
longer
includes
requirements
enabling
LE-based
architectures.
As
a
projector
(using
result,
requirements
for
the
marriage
process),
following
functionalities
have
been
eliminated:
Existing
designs
and
exhibition
implementations
that
use
of
Link
Encryption
remain
DCI
compliant.
For
details
concerning
LE
implementation
and
its
inherent
complexities
and
security
risks.
requirements,
please
refer
to
DCSS
version
1.4.2
(or
earlier).
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 information previously contained in this section has been deleted as redundant or relocated as needed to other sections of this specification.
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,
exhibition
specifies
a
standard
message
set
for
interoperable
communications
between
standardized
security
devices.
There are two classes of messages in the security system architecture:
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
five
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:
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:
No
physical
protection
required
–
Screen
Management
System
(SMS)
SPB
type
1
protection
required
–
Image
Media
Block
(IMB),
Outboard
Media
Block
(OMB),
Link
Decryptor
Block
(LDB)
and
LD/LE
SPB
Devices
SPB
type
2
protection
required
–
Content
essence
entering
the
projector
from
an
IMB
or
LD
Block
These
requirements
are
more
fully
defined
in
the
SM
Media
Block
and
projector
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.
The architecture supports Multiple Media Block (MMB) operation, which refers to the use of the IMB (or IMBO) and one or more Outboard Media Blocks (OMB) to support playout. This enables flexibility to provide media processing beyond that specified for the IMB, including support for multiple projectors within the projection booth.
With MMB, each participating Media Block (e.g., IMB or IMBO and OMB) 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. .
Figure 15 presents an exemplary security system architecture, inclusive of basic data paths and message communications.
For playout of any given Show Playlist, evidence of such playout requires a set of security log records that includes logs from all participating Media Blocks (MB). Over time, the movement, replacement, etc., of IMBs, IMBOs and OMBs may make the recovery of full sets of security log records difficult for stakeholders. For example, an IMB and OMB in a Multiple Media Block (MMB) architecture may become disassociated should devices be changed out for maintenance or the projection booth configuration changed.
This specification requires that a specific subset of records shall be collected and stored by the SMS on a daily basis, assuring such logs will be readily available. To avoid confusion and harmonize SMS and MB Security Manager (SM) responsibilities, the collection requirements shall apply to both MMB and non-MMB projection booth configurations.
Detailed
requirements
of
this
log
collection
process,
including
definitions
of
the
specific
subset
of
security
log
records,
are
provided
in
Section
9.4.2.5.2.
Playout
Log
Record
Collection
(for
the
SMS)
and
Section
9.4.3.5.1.
Playout
Log
Record
Generation
and
Delivery
(for
MB
SMs).
Requirements
of
log
collection
generally
are
provided
in
Section
9.4.6.3.
Logging
Subsystem
.
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
term
Equipment
Suite
is
that
the
IMB
SM
is
responsible
for
authenticating
other
was
used
in
connection
with
authentication
of
remote
SPBs
comprising
by
the
suite.
(The
stand
alone
Outboard
MB
(OMB)
does
not
support
a
projector
or
authenticate
other
SPBs,
and
is
thus
not
part
SM.
With
the
elimination
of
a
suite.)
The
installation
link
encryption
there
are
no
remote
SPBs
and
configuration
of
associated
equipment
that
comprises
suites
suite,
so
neither
term
is
an
exhibition
management
function.
used
in
this
specification.
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]
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)
a
type
1
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
supported
by
the
Operational
Message
(ITM)
Request-Response
Pairs
(RRP)
communications
of
Section
9.4.5.
.
The
SMS
shall
support
category
1
operational
message
Operational
Message
communications
with
Media
Blocks
as
follows:
SMS Requirements:
SM
interaction
with
the
SMS
is
normatively
defined
(see
Section
9.4.3.5.
Functions
of
the
Security
Manager
(SM)
)
[12]
12
.
These
include
the
requirements
that:
For multiple media block (MMB) implementations, the MMB-Capable SMS shall operate as the central projection booth automated authority to assure all pre-show requirements have been confirmed. The following additional requirements shall apply to an MMB-Capable SMS:
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.
Per
Section
9.4.1.2.
Post
Playout
Log
Record
Collection
,
within
24
hours
of
the
playout
of
any
encrypted
composition
the
SMS
shall
collect
security
log
report(s)
identifying
the
composition(s)
and
each
Media
Block
(MB)
participating
in
the
playout.
Log data extraction from each MB shall be compliant to and implemented using the following commands as defined in SMPTE 430-17 SMS-OMB Communications Protocol Specification:
A
permanently
integrated
SMS
(see
Section
9.4.2.5.
Screen
Management
System
(SMS)
at
"SMS
Requirements")
shall
direct
the
generation
of
CPLProcessed
log
reports
equivalent
to
those
obtained
via
the
getCplProcessedLogReport
command
for
the
MB
within
which
it
is
contained.
The collected post playout log reports shall be available for a period of at least one year. For Multiple Media Block (MMB) situations the reports from each participating MB shall be stored together in a collocated fashion. Exhibition is free to use a storage location of their choice (i.e., the SMS may pass the collected reports to external storage).
The SMS may perform the above log record collection at any convenient time but shall not allow any such records to age more than 24 hours from the creation of said record before collection.
See
Section
9.4.3.5.1.
Playout
Log
Record
Generation
and
Delivery
and
Section
9.4.6.3.10.
Logging
Failures
for
associated
information
regarding
MB
Security
Manager
(SM)
behavior.
This requirement does not impact the collection of log information from MBs generally, and exhibition is free to extract these or any other log event records at any time using general log extraction methods.
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).
(IMB)
or
IMB
with
OMB
functions
(IMBO).
A
critical
security
issue
is
assuring
that
the
clear
text
image
output
of
the
LDB
or
IMB
companion
MB
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.
MB.
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.
SPBs.
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 electrically 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
three
categories:
The
four
three
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.
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
17
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,
decryption,
forensic
marking,
and
recording
of
log
data.
The
flow
chart
in
Figure
18:
Show
Playback
Overview
18
,
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
playback
event
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
19
,
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
or,
within
61
seconds,
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.
Per
Section
9.4.1.2.
Post
Playout
Log
Record
Collection
,
MB
SMs
shall
cooperate
with
the
SMS
in
the
collection
of
post
playout
security
log
information
that
identifies
each
decrypted
composition
played,
by
generating
a
CPLProcessed
security
log
report
as
defined
below
when
requested
by
the
SMS.
The log playout report generation and delivery method shall be compliant to and implemented using the getStatus, generateCplProcessedLogReport, getCplProcessedLogReport, and cancelCplProcessedLogReport commands as defined in SMPTE 430-17 SMS-OMB Communications Protocol Specification, detailed as follows:
In
sum,
the
SM
informs
the
SMS
that
playout
records
are
available
for
extraction
from
the
MB,
and
the
requirement
to
report
outstanding
CPLProcessed
event
records
can
be
satisfied
in
a
single
log
report
generation
and
collection
process.
See
Section
9.4.2.5.2.
Playout
Log
Record
Collection
for
SMS
playout
log
collection
requirements.
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
.
Management.
From
a
security
perspective,
a
projection
system
consists
of
the
projector
Secure
Processing
Blocks
Block
(SPB)
type
2
and
its
companion
SPB,
which
will
be
either
the
Link
Decryptor
Block
(LDB)
or
an
Image
Media
Block
(IMB).
(IMB)
or
IMB
with
OMB
functions
(IMBO).
The following are the normative requirements for the projector Secure Processing Block (SPB):
The following are normative requirements for the IMB, and per item #5 of this section, the IMBO:
For clarity, all references to an IMB and the associated requirements of this section also apply to the IMBO.
The following are the normative requirements for the Outboard Media Block:
This
section
assumes
that
the
LDB
and
projector's
companion
IMB
or
IMBO
are
implemented
as
field
replaceable
SPB
modules.
It
is
not
mandatory,
however,
that
they
be
implemented
in
this
fashion.
It
is
allowed,
for
example,
allowed
for
the
LDB
either
MB
type
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)
MB
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
MB
from
marriage
monitoring
duties,
but
does
not
change
the
requirement
for
IMB
or
LDB
equivalent
SPB
functions,
the
MB
and
the
projector
SPB,
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
above
(except
as
the
latter
requirements
relate
to
marriage
event
and
connection
monitoring.
monitoring).
In
the
case
where
the
Projector
and
companion
SPB
MB
are
inseparable,
a
single
Digital
Cinema
Certificate
shall
represent
both
the
Projector
and
its
companion
SPB
(Image
Media
Block
or
Link
Decryptor
Block).
MB.
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,
IMBO,
and
shall
require
the
projector
SPB
and
companion
SPB
MB
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
projector's
authentication
information
(certificate
thumbprint).
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)
(IMB),
IMB
with
OMB
funcitions
(IMBO)
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:
In
any
instance
where
content
is
not
encrypted
and
no
KDM
for
this
content
exists,
the
SM
shall
automatically
assume
“trust”
in
the
LDB
and
projector
SPBs
for
purposes
of
keying
the
LDB
and
enabling
playback
for
(only)
that
CPL.
All
logging
processes
shall
take
place
normally,
recognizing
that
some
logging
events
(e.g.,
This
specification
no
logging
of
content
key
use)
will
not
be
recorded.
In
instances
where
combinations
of
encrypted
and
non-encrypted
content
constitute
a
Show
Playlist,
the
SM
shall
require
the
LDB
and
projector
to
appear
on
the
TDL
prior
to
enabling
keying
Link
Encryption
functions
and
enabling
playback
for
any
CPL
having
encrypted
content.
Link
Encryption
shall
be
implemented
according
to
[RDD
20-2010
SMPTE
Registered
Disclosure
Document:
“CineLink
2
Specification.”]
Link
Encryption
keys
shall
be
generated
according
to
the
requirements
of
Section
9.7.6.
Key
Generation
and
Derivation
.
Link
Encryption
keys
shall
be
distributed
using
the
appropriate
Standardized
Security
Messages
of
Section
9.4.5.2.4.
Request-Response
Pairs
(RRP)
(and
shall
not
be
distributed
using
in-band
techniques).
The
individual
longer
includes
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
enable
Link
Encryption
keys
may
be
used
for
showings,
(LE)
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.
related
functions.
“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
with
Multiple
Link
Encryption
means
the
use
of
(i)
more
than
one
remote
LDB/projector
pair
with
a
single
IMB,
or
(ii)
an
LD/LE
image
processor
SPB
inserted
between
the
IMB
and
one
or
more
remote
LDB/projector
pair(s).
Integrated
IMB
with
Link
Encryption
means
the
use
of
an
integrated
and
married
IMB/projector
pair,
where
the
IMB
also
outputs
a
Link
Encrypted
image
signal
to
one
or
more
remote
LDB/projector
pair(s).
The
IMB
shall
simultaneously
meet
all
requirements
for
both
integrated
and
non-integrated
(which
supported
multiple
projector
system
implementations.
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
operation)
were
enabled
in
conjunction
with
Link
Encryption
this
additionally
includes
the
identity
of
the
projector
to
(LE)
functionality,
which
the
IMB
is
married.
This
matching
is
an
indication
to
the
SM
that
Special
Auditorium
Situations
operation
has
been
approved
no
longer
supported
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:
SM
behavior
shall
be
designed
to
identify
a
Special
Auditorium
Situation
during
the
auditorium
security
network
TLS
session
establishment.
The
digital
certificate
exchange
with
remote
SPBs
shall
return
the
associated
certificate
roles
for
each
SPB
in
the
auditorium.
The
SM
shall
independently
authenticate
each
remote
SPB
against
the
TDL
using
a
dedicated
TLS
session.
The
SM
shall
independently
key
each
remote
SPB
for
Link
Encryption
operation
using
standardized
Intra-Theater
(security)
Messaging
per
Section
9.4.5.
The
SM
shall
not
support
the
use
specification.
Use
of
more
than
one
LD/LE
image
processor
SPB
for
any
given
projector.
The
Link
Encryption
stages
of
the
LD/LE
image
processor
configuration
may
use
the
same
LE
key(s).
Similarly,
the
SM
may
key
the
multiple
LDB/projector
configuration
using
the
same
LE
key
for
each
LDB/projector
system.
projector
in
an
auditorium
is
enabled
via
Multiple
Media
Block
(MMB)
operation.
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
specification
originally
defined
two
categories
of
Intra-Theater
(security)
Messages
(ITM)
are
employed.
Intra-Theater
Message(s)
(ITMs)
are
described
for
communications
between
the
(ITM):
Category
1
operational
messages
(for
SMS
to
MB
communications)
and
SM(s),
and
category
2
standardized
security
messages
(for
communicating
Auditorium
Security
Messages
between
the
SM(s)
IMB
and
remote
Secure
Processing
Blocks
(SPBs).
IMBs
that
implement
SPBs).
With
the
elimination
of
Link
Encryption
shall
support
all
ITMs
(LE)
and
related
functionality
from
this
specification
only
category
1
operational
messages
are
used.
For
simplicity,
category
1
operational
messages
are
normatively
referred
to
as
defined
Operational
Messages
in
this
section.
The
OMB
and
IMBO
shall
only
support
ITMs
between
the
SMS
and
OMB,
and
SMS
and
IMBO
respectively
(the
OMB
and
IMBO
do
not
implement
Link
Encryption
specification.
Except
where
stated
otherwise,
Operational
Messages
and
thus
message
requirements
shall
not
support
Auditorium
Security
Messaging).
be
as
defined
in
SMPTE
430-17,
SMS-OMB
Communications
Protocol
Specification.
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.
subsystem,
which
is
executed
by
Media
Block
(MB)
Security
Managers
(SM).
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. All requirements shall apply equally to the IMB, IMBO and OMB, which are referred to in this section as Media Blocks (MB). References to Secure Processing Devices (SPB) are inclusive of MBs and display devices. 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 and report sequencing shall be 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)
a
MB
or
in
external
theater-controlled
devices
or
processes)
is
an
implementation
decision.
Media Block (MB) 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
19
.
IMB or IMBO | OMB |
|
|
---|---|---|---|
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 | |
Operations Event Sub Types | |||
SPBOpen |
X
|
||
SPBClose |
X
|
||
SPBMarriage |
X
|
||
SPBDivorce |
X
|
||
SPBShutdown | X | X |
|
SPBStartup | X | X |
|
SPBClockAdjust
|
X | X | |
SPBSoftware | X | X |
|
SPBSecurityAlert | X | X |
|
In addition to the requirements specified in SMPTE 430-5, the following shall be normative for DCI compliance:
The
secure
logging
requirements
of
this
Section
9.4.6.3.
Logging
Subsystem
are
required
to
be
functionally
executed
and
fully
operable
as
a
prerequisite
to
playback.
Security
Managers
(SM)
shall
prevent
the
playout
of
encrypted
content
if:
Behavior
of
SPBs
shall
be
specified
and
designed
to
immediately
terminate
operation
and
require
replacement
upon
any
failure
of
its
secure
logging
operation.
Resident
log
records
in
failed
SPBs
shall
not
be
purgeable
except
by
authorized
repair
centers,
which
shall
be
capable
of
securely
recovering
such
log
records.
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
authenticates
the
projector
it
supports,
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
Section
5.3.4.
.
For
purposes
of
efficiency,
SE
types
shall
be
minimally
designated
according
the
following
roles:
The
following
role(s)
shall
be
included
for
the
IMB
IMB,
IMBO
and
OMB,
as
applicable:
Note:
Dual
(two)
certificates
are
used
only
with
the
Image
Media
Block
(IMB)
(IMB),
IMB
with
OMB
functions
(IMBO)
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:
the
LS
(Log
Signer)
role.
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
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
keys
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
an
Image
Media
Block
(IMB)
or
IMB
with
OMB
functions
(IMBO)
(companion
SPBs
SPB
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
individual
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]
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.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.
|
|
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]
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.
The following are required for the exhibition of content and security related 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
two
types
of
components
involved
in
Digital
Rights
Management
(DRM):
The
last
two
components
Media
Block
SMs
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
Security
system
components
(Screen
Management
System,
Security
Manager,
security
equipment)
(SMS
and
SMs
within
MBs)
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
21
and
Table
22:
Examples
of
Failure
or
Tampering
of
Security
Equipment
22
).
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
use
of
such
content
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
use
of
content
key
delivery
keys
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
|
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
projector
(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
(Media
Block
or
projector)
must
perform
to
specified
standards
and
function
as
designed.
The
Security
Manager
will
continuously
test
monitor
for
proper
Security
Entity
identification
(authentication),
security
equipment
operation
and
physical
integrity
(tampering).
Content
playback
is
restricted
to
passing
all
security
tests
requirements
at
all
times
.
Item, Observation or Issue | Approach |
---|---|
Security equipment tampering or failure | A tampered or failed device is non-functional until replaced |
|
|
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
Similarly,
the
auditorium
security
network
SM
shall
prohibit
playout
if
the
MB-projector
marriage
is
inoperative
broken
or
become
compromised
(row
2),
playback
cannot
start.
However,
the
security
system
will
not
cause
playback
to
stop
upon
failure
of
the
network
during
a
show.
2).
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:
The requirements of this Chapter 10 are integral to this document. They are presented separately from other chapters for historical reasons.
Section
10.2.
Stereoscopic
Digital
Cinema
Requirements
was
previously
published
as
a
standalone
addendum
titled
DCI
Stereoscopic
Digital
Cinema
Addendum,
Version
1.0,
dated
July
11,
2007
.
A single stereoscopic DCP shall be able to be used for all stereoscopic implementations (e.g., no stereoscopic exhibition system shall require a unique color or density timing). It is not required or intended that the same image track file used for stereoscopic DCPs also be used for non-stereoscopic DCPs.
Additionally, no signal pre-processing unique to any single stereoscopic exhibition technology shall be required of a stereoscopic Digital Cinema Distribution Master (DCDM) or DCP.
DCPs for stereoscopic presentations shall interleave the left and right eye frames alternating at a 48 frames per second rate. The left and right eye material shall each be captured for 24 FPS presentation.
The first frame of each reel shall be left eye, and the last frame of each reel shall be right eye. Image and audio edit points of track files shall only be left eye based.
All edits to image and audio shall be performed at a 24 FPS edit rate and shall not disturb the left eye/right eye cadence
Audio track files for non-stereoscopic DCPs and stereoscopic DCPs shall be interchangeable.
A single KDM shall be required to decrypt a stereoscopic DCP.
In the case of 48 FPS stereoscopic exhibition, it is acceptable, but not recommended, to allow color subsampling over a dual link interface. Color subsampling shall only be allowed in the single combination of a DCDM* at 2K, 48 FPS being transported over a link encrypted [SMPTE 372M Dual Link HD-SDI] connection.
For stereoscopic content, exhibition systems using [SMPTE 372M Dual Link HD-SDI] as an interface shall transport images across this interface as 4:2:2 color subsampled, Y,Cx,Cz, twelve (12) bits per sample.