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:
Digital
Cinema
Distribution
Master
(DCDM)
:
This
section
provides
specifications
for
the
image,
audio,
subtitle
(Timed
Text
and
subpictures)
Digital
Cinema
Distribution
Masters.
The
DCDM-Image
defines
a
common
set
of
image
structures
for
Digital
Cinema
by
specifying
an
image
containers
and
colorimetry
for
a
Digital
Cinema
Distribution
Master
(DCDM).
The
DCDM-Audio
specifies
the
following
characteristics:
bit
depth,
sample
rate,
minimum
channel
count,
channel
mapping
and
reference
levels.
The
DCDM-subtitles
specifies
the
format
of
a
Digital
Cinema
subtitle
track
file.
A
subtitle
track
file
contains
a
set
of
instructions
for
placing
rendered
text
or
graphical
overlays
at
precise
locations
on
distinct
groups
of
motion
picture
frames.
A
subtitle
track
file
is
an
integral
component
of
a
Digital
Cinema
composition
and
may
be
present
in
both
mastering
and
distribution
file
sets.
Compression
(Image)
:
Specifies
the
DCI
compliant
JPEG
2000
codestream
and
JPEG
2000
decoder.
Packaging
:
This
section
defines
the
requirements
for
packaging
the
DCDM
(image,
audio
and
subtitle)
files
using
(where
possible)
existing
Material
eXchange
Format
(MXF)
specifications
and
eXtensible
Mark
up
Language
(XML).
The
output
of
this
process
is
the
Digital
Cinema
Package
(DCP).
This
section
also
defines
the
requirements
for
encrypting
the
essence
(sound,
picture
and
subtitles)
of
the
DCP.
Transport
:
Defines
the
movement
from
distribution
centers
to
theater
locations
using
physical
media,
virtual
private
networks
or
satellite
communications.
Theater
Systems
:
Provides
requirements
for
all
equipment
necessary
for
theatrical
presentation
in
a
typical
theater
environment.
This
encompasses
digital
projectors,
media
blocks,
storage
systems,
sound
systems,
the
DCP
files
ingest,
theater
automation,
Screen
Management
System
(SMS)
and
Theater
Management
Systems
(TMS).
Projection
:
This
section
defines
the
projector
and
its
controlled
environment,
along
with
the
acceptable
tolerances
around
critical
image
parameters
for
Mastering
and
general
Exhibition
applications.
The
goal
is
to
provide
a
means
for
achieving
consistent
and
repeatable
color
image
quality.
Two
levels
of
tolerances
are
specified:
a
tighter
tolerance
for
mastering
rooms
where
critical
color
judgments
are
made,
and
a
wider
tolerance
for
satisfactory
reproduction
in
general
public
exhibition.
Security
:
The
security
chapter
provides
requirements
and
fundamental
specifications
for
persistent
content
protection
and
controlled
access
in
an
open
security
architecture.
These
objectives
are
achieved
with
high
security
in
a
multi-user
environment
via
the
application
of
well
respected
security
and
encryption
standards
in
primarily
three
areas:
1)
content
encryption,
2)
security
(key)
management
and
3)
high
integrity
event
logging
and
reporting.
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:
The
Digital
Cinema
system
shall
have
the
capability
to
present
a
theatrical
experience
that
is
better
than
what
one
could
achieve
now
with
a
traditional
35mm
Answer
Print.
This
system
should
be
based
around
global
standards,
or
DCI
specifications,
that
are
embraced
around
the
world
so
that
content
can
be
distributed
and
played
anywhere
in
the
world
as
can
be
done
today
with
a
35mm
film
print.
These
standards
should
be
open
published
industry
standards
that
are
widely
accepted
and
codified
by
national
and
international
standards
bodies
such
as:
ANSI,
SMPTE,
and
ISO/IEC.
To
the
extent
that
it
is
possible,
the
Digital
Cinema
system
shall
emulate
theater
operations
and
the
theater
business
model,
as
it
exists
today.
The
system
specification,
global
standards
and
formats
should
be
chosen
so
that
the
capital
equipment
and
operational
costs
are
reasonable
and
exploit,
as
much
as
possible,
the
economies
of
scale
associated
with
equipment
and
technology
in
use
in
other
industries.
The
hardware
and
software
used
in
the
system
should
be
easily
upgraded
as
advances
in
technology
are
made.
Upgrades
to
the
format
shall
be
designed
in
a
way
so
that
content
may
be
distributed
and
compatibly
played
on
both
the
latest
DCI-compliant
hardware
and
software,
as
well
as
earlier
adopted
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.
It
has
been
recognized
that
these
advances
may
most
likely
affect
the
mastering
and
projection
of
Digital
Cinema
content.
Therefore,
this
document
will
specify,
for
example,
a
resolution
and
color
space
that
may
not
be
obtained
in
a
present
day
mastering
or
projection
system.
However,
it
is
the
intent
that
the
rest
of
the
Digital
Cinema
system
be
capable
of
transporting
and
processing
up
to
the
technical
limits
of
the
specification.
This
document
specifies
a
baseline
for
the
implementation
of
a
Digital
Cinema
system.
The
goal
of
backwards
compatibility
in
this
context
is
to
allow,
for
example,
new
content
at
higher
resolution
and
color
space
to
be
played
out
on
a
projection
system
that
meets
the
baseline
implementation.
The
Digital
Cinema
system
shall
also
not
preclude
the
capability
for
alternative
content
presentations.
The
Digital
Cinema
system
shall
provide
a
reliability
and
availability
that
is
equal
to,
or
better
than,
current
film
presentation.
Protection
of
intellectual
property
is
a
critical
aspect
of
the
design
of
the
system.
This
security
system
should
be
designed
using
a
single
common
encryption
format
along
with
keys
to
decrypt
the
content.
The
method
should
provide
a
means
to
keep
the
content
encrypted
from
the
time
it
is
encoded
in
post-production
until
it
is
projected
on
a
theater
screen.
Only
trusted
entities,
deployed
in
secure
environments
or
implementing
physical
protection,
will
be
given
access
to
the
decrypted
content.
Content
will
be
decrypted
contingent
upon
usage
rules
agreed
on
by
content
owners,
Distributors
and
Exhibitors.
The
system
should
also
be
renewable
in
case
of
a
breach
of
security
in
any
part
of
the
system,
and
include
forensic
Marking
of
the
content
for
providing
traceable
forensic
evidence
in
the
case
of
a
theft
of
the
content.
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:
Digital
Cinema
Distribution
Master
(DCDM)
–
Contains
system
requirements
regarding
the
uncompressed,
unencrypted
file
or
set
of
files
containing
the
content
and
its
associated
data.
Compression
–
Contains
system
requirements
regarding
the
process
that
reduces
redundancy
in
source
essence
data
and
its
inverse,
decompression,
Packaging
–
Contains
system
requirements
for
the
process
of
encryption
and
decryption
of
compressed
image
and
audio
essence,
wrapping
and
unwrapping
of
compressed
and
encrypted
files
for
distribution
and
playback.
Transport
–
Contains
requirements
related
to
the
distribution
of
the
packaged
media.
Theater
System
–
Contains
system
requirements
for
the
equipment
installed
at
a
theater
for
control,
scheduling,
logging
and
diagnostics.
Projection
–
Contains
system
requirements
regarding
the
performance
characteristics
used
to
display
the
image
on
the
screen.
Security
–
Contains
system
requirements
that
bear
on
the
protection
of
content
intellectual
property
rights.
Processes
for
key
management,
Forensic
Marking
and
logging
are
constituent
elements
of
the
security
design.
A
functional
framework
of
a
Digital
Cinema
encoding
and
a
decoding
system
are
shown
below
in
Figure
1
and
Figure
2
.
Figure
1
:
System
Overview
Functional
Encode
Flow
🔗
Figure
2
:
System
Overview
Functional
Decode
Flow
🔗
The
Digital
Source
Master
(DSM)
is
created
in
post-production
and
can
be
used
to
convert
into
a
Digital
Cinema
Distribution
Master
(DCDM).
The
DSM
can
also
be
used
to
convert
to
a
film
duplication
master,
a
home
video
master,
and/or
a
master
for
archival
purposes.
It
is
not
the
intention
of
this
document
to,
in
any
way,
specify
the
DSM.
This
is
left
to
the
discretion
of
the
content
provider.
The
content
could
come
from
a
wide
range
of
sources
with
a
wide
range
of
technical
levels.
When
discussing
Digital
Cinema
content,
it
was
realized
that
other
content
besides
feature
films
would
make
use
of
the
same
digital
system.
Therefore,
a
new
term
was
created
to
refer
to
any
content
that
would
have
similar
requirements
to
feature
film
content.
The
term
“Composition”
refers
to
all
of
the
essence
and
metadata
required
for
a
single
presentation
of
a
feature,
or
a
trailer,
or
an
advertisement,
or
a
logo
to
create
a
presentation
using
a
digital
system.
This
term
will
be
used
throughout
this
document
and
is
intended
to
refer
to
a
single
element
such
as
one
and
only
one
feature,
trailer,
advertisement
or
logo.
2.1.1.3.
Digital
Cinema
Distribution
Master
(DCDM)
🔗
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.
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.
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.
)
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
.
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
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.
Media
Blocks
are
secure
entities
and
the
specific
nature
of
that
security
is
defined
in
Section
9.
.
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.
).
Alternatively,
it
can
be
sent
directly
to
a
playback
system
for
quality
control
tasks.
Standard
DCP
conforms
to
SMPTE
ST
429-2
"D-Cinema
Packaging
-
DCP
Operational
Constraints"
and
contains
one
or
more
ST
429-2
compositions.
A
standard
DCP
does
not
contain
OBAE
or
any
ST
429-19
compositions.
An
Immersive
Audio
Bitstream
(IAB)
DCP
contains
one
or
more
compositions
that
conform
to
SMPTE
ST
429-19
"D-Cinema
Packaging
–
DCP
Operational
Constraints
for
Immersive
Audio."
An
IAB
DCP
may
also
contain
ST
429-2
compositions.
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:
Image
–
The
image
specification
and
file
format
Audio
–
The
audio
specification
and
file
format
Subtitles
Subpicture
–
The
pre-rendered
open
text
specification
and
file
format
Timed
Text
–
The
Timed
Text
data
specification
and
file
format
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.
.
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.
for
requirements
specific
to
stereoscopic
presentations.
The
DCDM
Image
Structure
shall
be
mapped
into
the
TIFF
Rev
6.0
File
Format
and
further
constrained
as
follows:
16
bits
each
per
X',
Y',
and
Z'
channel,
stored
in
the
nominal
TIFF
R,
G
and
B
channels.
The
DCDM
gamma-encoded
X',
Y'
and
Z'
color
channels
are
represented
by
12-bit
unsigned
integer
code
values.
These
12
bits
are
placed
into
the
most
significant
bits
of
16-bit
words,
with
the
remaining
4
bits
filled
with
zeroes.
The
image
orientation
shall
place
the
first
pixel
in
the
upper
left
corner
of
the
image.
The
DCDM
picture
file
shall
contain
only
the
active
pixels
in
the
image.
In
other
words,
it
is
not
allowed
to
pad
the
picture
to
the
full
size
of
the
DCDM
container.
The
DCDM
file
format
is
required
to
contain
metadata
that
allows
for
synchronization
of
the
images
with
other
content:
Each
directory
shall
contain
only
one
contiguous
sequence
of
frames.
For
assembled
reels,
a
separate
directory
shall
be
used
for
each
reel
with
the
following
naming
convention:
CompositionName.Reel_#
For
inserts,
the
directory
naming
convention
shall
be:
FeatureName.Reel_#.Insert_#
Each
reel
shall
contain
sequentially
numbered
frames,
using
the
following
file
naming
convention.
All
names
when
sorted
alphabetically
shall
be
in
sequential
order
(leading
zeroes
required).
Therefore,
the
only
thing
that
changes
in
the
sequence
is
the
frame
numbers.
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.
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
3.3.
Audio
Specification:
Sound
Essence
and
Object-Based
Audio
Essence
🔗
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:
Sound
Essence
–
Up
to
16
channels
of
PCM
audio
essence
carried
as
interleaved
Broadcast
Wave
files
in
a
Sound
Track
File
as
defined
in
SMPTE
ST
429-3
and
wrapped
per
SMPTE
ST
382.
OBAE
–
Object-Based
Audio
Essence
(OBAE)
–
Audio
essence
that
is
comprised
of
both
PCM
audio
essence
and
associated
descriptive
metadata,
including
temporal
and
spatial
metadata.
OBAE
shall
conform
to
SMPTE
ST
2098-2
Immersive
Audio
Bitstream
Specification,
and
shall
be
carried
in
an
AuxData
track
of
the
DCP
as
defined
in
SMPTE
ST
429-18
D-Cinema
Packaging
–
Immersive
Audio
Track
File.
It
is
required
that
OBAE
be
interoperable
between
all
architectures
that
support
object-based
audio.
This
specification
refers
to
OBAE
in
lieu
of
Immersive
Audio.
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.
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.
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:
Pre-composited
into
the
Digital
Cinema
image
files
(burned-in)
Pre-rendered
PNG
bitmaps
(subpicture),
or
Documents
containing
text
and
attributes
for:
Rendering
in
a
specified
font
(Timed
Text)
and
overlaid
by
the
server,
an
in-line
processor
or
the
Digital
Cinema
projector
LED
displays
driven
by
a
captioning
processor
receiving
data
from
the
Digital
Cinema
server,
or
Separate
projection
systems
driven
by
a
captioning
processor
receiving
data
from
the
Digital
Cinema
server
Section
3.4.2.
below
defines
the
subpicture
specifications,
while
Section
3.4.3.
,
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.
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
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.
.
and
Section
7.
.
Some
of
the
fundamental
information
pertaining
to
encoding
is
covered
here,
with
the
detailed
information
for
its
use
covered
in
Section
7.
.
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.
First
frame
of
content
First
frame
of
intermission
First
frame
of
end
credits
First
frame
of
end
credits
on
black
Last
frame
of
content
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.
.
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.
A
2K
distribution
–
the
resolution
of
the
DCDM*
3
[3]
container
is
2048x1080.
A
4K
distribution
–
the
resolution
of
the
DCDM*
3
[3]
container
is
4096x2160.
A
2K
decoder
outputs
up
to
2048x1080
resolution
data.
A
4K
decoder
outputs
up
to
4096x2160
resolution
data
from
a
4K
compressed
file
and
outputs
up
to
2048x1080
resolution
data
from
a
2K
compressed
file.
All
decoders
shall
decode
both
2K
and
4K
distributions.
It
is
the
responsibility
of
the
4K
projector
to
upres
the
2K
file.
In
the
case
of
a
2K
decoder
and
a
4K
distribution,
the
2K
decoder
need
read
only
that
data
necessary
to
decode
a
2K
output
from
the
4K
distribution.
The
decoder
(be
it
a
2K
decoder
or
a
4K
decoder)
need
not
up-sample
a
2K
image
to
a
4K
projector
or
down-sample
a
4K
image
to
a
2K
projector.
Once
deployed,
the
decoder,
for
any
given
projector,
shall
not
be
required
to
be
upgraded.
The
output
of
the
decoder
shall
conform
to
Section
3.2.
.
These
images
are
basically:
4K
=
4096x2160
at
24
FPS
2K
=
2048x1080
at
24
or
48
FPS
Color:
12
bit,
X’Y’Z’
Enhanced
parameter
choices
shall
not
be
allowed
in
future
distribution
masters,
if
they
break
decodability
in
a
deployed
compliant
decoder.
All
decoders
shall
decode
each
color
component
at
12
bits
per
sample
with
equal
color/component
bandwidth.
Decoders
shall
not
subsample
chroma.
A
4K
decoder
shall
decode
all
data
for
every
frame
in
a
4K
distribution.
A
decoder
shall
not
discard
data
(including
resolution
levels
or
quality
layers)
to
keep
up
with
peak
decoding
rates.
A
2K
decoder
shall
decode
2K
data
for
every
frame
in
a
4K
distribution
and
it
shall
decode
a
2K
distribution.
It
may
discard
only
the
highest
resolution
level
of
a
4K
distribution.
It
shall
not
discard
other
data
such
as
further
resolution
levels
or
quality
layers.
All
decoders
shall
implement
the
9/7
inverse
wavelet
transform
with
at
least
16
bit
fixed
point
precision.
All
decoders
shall
implement
the
inverse
Irreversible
Color
Transform
(ICT)
using
at
least
16
bit
fixed
point
precision.
All
codestreams
shall
fully
conform
with
[ISO
15444-1:2006
Amendment
1],
as
more
fully
constrained
as
follows:
The
capability
parameter
for
a
2K
distribution
shall
be
Rsiz
=
3,
for
a
4K
distribution
it
shall
be
Rsiz
=
4.
All
image
frames
shall
be
untiled.
More
precisely,
the
entire
image
shall
be
encoded
as
a
single
tile.
The
image
and
tile
origins
shall
both
be
at
(0,
0).
There
shall
be
no
more
than
5
wavelet
transform
levels
for
2K
content
and
no
more
than
6
wavelet
transform
levels
for
4K
content.
There
shall
be
no
less
than
one
wavelet
transform
level
for
4K
content.
Additionally,
every
color
component
of
every
frame
of
a
distribution
shall
have
the
same
number
of
wavelet
transform
levels.
Codeblocks
shall
be
of
size
32x32.
The
codeblock
coding
style
shall
be
SPcod,
SPcoc
=
0b00000000.
All
precinct
sizes
at
all
resolutions
shall
be
256x256,
except
the
lowest
frequency
subband,
which
shall
have
a
precinct
size
of
128x128.
There
shall
be
no
region
of
interest,
i.e.,
Region
of
interest
(RGN)
marker
segments
are
disallowed.
Coding
style
Default
(COD),
Coding
style
Component
(COC),
Quantization
Default
(QCD),
and
Quantization
Component
(QCC)
marker
segments
shall
appear
only
in
the
main
header.
Packed
Packet
headers,
Main
header
(PPM)
and
Packed
Packet
headers,
Tile-part
header
(PPT)
marker
segments
are
forbidden.
The
progression
order
for
a
2K
distribution
shall
be
Component-Position-Resolution-Layer
(CPRL).
Progression
Order
Change
(POC)
marker
segments
are
forbidden
in
2K
distributions.
For
a
4K
distribution,
there
shall
be
exactly
one
POC
marker
segment
in
the
main
header.
Other
POC
marker
segments
are
forbidden.
The
POC
marker
segment
shall
specify
exactly
two
progressions
having
the
following
parameters:
In
the
above,
D
is
the
number
of
wavelet
transform
levels
and
L
is
the
number
of
quality
layers.
The
constant
3
specifies
the
number
of
color
components,
and
the
constant
4
specifies
CPRL
progression.
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.
Each
compressed
frame
of
a
2K
distribution
shall
have
exactly
3
tile
parts.
Each
tile
part
shall
contain
all
data
from
one
color
component.
Each
compressed
frame
of
a
4K
distribution
shall
have
exactly
6
tile
parts.
Each
of
the
first
3
tile
parts
shall
contain
all
data
necessary
to
decompress
one
2K
color
component.
Each
of
the
next
3
tile
parts
shall
contain
all
additional
data
necessary
to
decompress
one
4K
color
component.
The
resulting
compliant
codestream
structure
is
diagramed
in
Table
7
.
Assuming
D
wavelet
transform
levels
(D+1
resolutions),
the
box
labeled
2K_i
(i
=
0,
1,
2)
contains
all
JPEG
2000
packets
for
color
component
i,
resolutions
0
through
D-1
.
The
box
labeled
4K_i
(i
=
0,
1,
2)
contains
all
JPEG
2000
packets
for
color
component
i,
resolution
D.
Tile-part
Lengths,
Main
header
(TLM)
marker
segments
shall
be
required
in
all
frames
of
all
distributions.
Note:
This
facilitates
extraction
of
color
components
and
resolutions
(2K
vs.
4K).
Distribution
masters
shall
have
exactly
one
quality
layer.
For
a
frame
rate
of
24
FPS,
a
2K
distribution
shall
have
a
maximum
of
1,302,083
bytes
per
frame
(aggregate
of
all
three
color
components
including
headers).
Additionally,
it
shall
have
a
maximum
of
1,041,666
bytes
per
color
component
per
frame
including
all
relevant
tile-part
headers.
For
a
frame
rate
of
48
FPS,
a
2K
distribution
shall
have
a
maximum
of
651,041
bytes
per
frame
(aggregate
of
all
three
color
components
including
headers).
Additionally,
it
shall
have
a
maximum
of
520,833
bytes
per
color
component
per
frame
including
all
relevant
tile-part
headers.
A
4K
distribution
shall
have
a
maximum
of
1,302,083
bytes
per
frame
(aggregate
of
all
three
color
components
including
headers).
Additionally,
the
2K
portion
of
each
frame
shall
satisfy
the
24
FPS
2K
distribution
requirements
as
stated
above.
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.
.
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:
Composition
–
A
self-contained
representation
of
a
single
complete
Digital
Cinema
work,
such
as
a
motion
picture,
or
a
trailer,
or
an
advertisement,
etc.
Distribution
Package
–
The
physical
files
and
the
list
describing
the
files
and
providing
a
means
for
authentication
as
delivered
in
a
Distribution
Package
(from
Distributor
to
Exhibitor).
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
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.
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
.
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
.
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:
Required
metadata
for
unique
asset
identification
Required
metadata
for
decompression
(optional)
Required
metadata
for
decryption
(optional)
The
following
information
is
required
to
be
configured
in
a
human
readable
format:
Essence
physical
format
description
(e.g.,
4096
x
2160)
Essence
title
asset
information
(e.g.,
The_Perfect_Movie_English_R2)
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.
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:
The
essence
container
is
required
to
allow
encrypted
data,
while
the
rest
of
the
Track
File
metadata
is
left
unencrypted.
At
any
point
in
the
delivery
chain,
it
is
required
to
be
possible
to
detect
whether
any
accidental
or
intentional
alteration
has
occurred.
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:
It
is
encouraged
that
missing
or
corrupted
data
be
easily
identified.
Track
Files
are
encouraged
to
be
subdivided
into
smaller
segments,
which
have
individual
authenticity/error-check
codes.
This
facilitates
a
decision
as
to
whether
the
file
is
so
corrupt
it
cannot
be
played,
or
whether
it
is
safe
to
proceed
with
playback
while
requesting
a
replacement
Track
File.
Synchronization
with
other
Track
Files
is
encouraged
to
be
verifiable.
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.
Each
reel
shall
use
a
single
cryptographic
key
for
all
frames
within
the
sound
or
picture
Track
File.
The
integrity
of
each
frame
of
sound
and
picture
essence
shall
be
verifiable
using
the
HMAC-SHA1
algorithm.
The
optional
Message
Integrity
Code
(MIC)
element
of
SMPTE
429-6
shall
be
present.
There
shall
be
a
method
for
verifying
that
all
frames
within
a
sound
and
picture
track
are
played
in
correct
sequence.
The
optional
TrackFileID
and
SequenceNumber
elements
of
SMPTE
429-6
shall
be
present.
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.
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.
).
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.
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.
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.
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
contain
the
following
human
readable
information
in
English
(default)
but
can
be
provided
in
other
languages
as
well.
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
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:
UUID
Annotation
Text
parameter
(optional),
if
present,
is
a
free-form,
human
readable
annotation
associated
with
the
asset.
It
is
meant
strictly
as
a
displayable
guidance
for
the
user
File
Integrity
check
(hash)
for
each
file
in
the
distribution
package
Size
of
the
file
in
bytes
Type
(e.g.,
Packing
List,
Playlist,
Track
File,
opaque
security
data)
Original
File
Name
The
following
fields
are
required
to
be
included
in
the
digital
signature
section
of
the
Packing
List:
Signer
parameter
uniquely
identifies
the
entity,
and
hence
public
key
that
digitally
signs
the
Packing
List.
Signature
parameter
contains
a
digital
signature
authenticating
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.
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:
Screen
and
Theater
Management
Systems
–
The
human
interface
for
the
Digital
Cinema
System
Theater
Systems
Architecture
–
The
equipment
and
interconnect
within
the
Theater
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.
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
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
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.
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.
The
central
and/or
local
storage
system
is
required
encouraged
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.
.
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.
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
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.
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.
Projection
–
Required
to
be
able
to
perform
the
following
functions
Browse
and
activate
current
shows
Play
content,
including
starting
and
stopping
playback
Assemble
shows
Show
Manager
–
Required
to
have
access
to
the
following
functions
All
projection
functions
Assemble
or
Delete
Shows
to/from
storage
Import/Delete
Content
to/from
storage
Super-user
–
Required
to
have
access
to
the
following
functions
All
Show
Manager
functions
User
Management
Theater
System
Setup
Administrator
–
Required
to
have
access
to
the
following
functions
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:
Downloading
content
while
playback
of
presentations
are
in
progress
Movement
of
content
from
a
central
storage
to
local
storage
while
other
content
is
in
playback
Deleting
content
while
other
content
is
in
playback
The
SMS
or
TMS
is
required
to
warn
and
not
allow
deletion
if
the
content
is
in
use
or
part
of
a
current
Show
Playlist.
The
SMS
or
TMS
is
required
to
provide
a
deletion
process
that
removes
all
of
the
content,
key
information,
and
playlists
associated
with
the
composition.
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.
)
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:
A
method
of
building
shows
is
required
to
allow
only
authorized
personal
to
build,
save
and
transport
the
Show
Playlist.
A
method
is
required
to
use
the
validity/expiry
method,
so
that
one
can
check
that
one
has
the
security
devices
and
keying
parameters
required
for
playback.
A
method
is
required
to
make
it
possible
for
a
Show
Playlist
to
be
provided
via
an
external
source.
A
method
is
required
to
provide
a
means
for
inserting
a
black
screen
and
silence
between
content.
The
Media
Block
is
required
to
be
able
to
transition
modes
without
displaying
a
roll
or
similar
artifacts
during
a
transition
between
clips
in
a
playlist
or
between
playlists.
Show
Playlists
can
consist
of
both
encrypted
and
non-encrypted
content.
The
Show
Playlist
can
be
communicated
in
whole
to
the
Media
Block,
whereupon
it
is
then
stored
and
subsequently
executed
within
the
Media
Block
(Content
Data
Pull
Model).
The
Show
Playlist
can
be
executed
within
the
SMS
and
communicated
to
the
Storage
and
Media
Block
one
command
at
a
time
(Content
Data
Push
Model).
A
method
is
required
to
provide
for
the
insertion
of
cues.
These
cues
allow
the
automation
system
to
perform
its
tasks
at
event
boundaries,
such
as
start
of
feature
and
start
of
end
credits.
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
the
controller
and
which
is
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:
Have
full
content
play
functionality
(e.g.,
make
playlists
active,
stop,
start,
start
play)
at
any
reel
break
point
in
a
playlist.
Handle
power
interrupted
while
playing
content.
When
the
system
is
next
started,
it
is
required
to
inform
the
user
that
playback
was
abnormally
interrupted
during
the
last
play,
and
offer
the
user
the
ability
to
restart
playback
at
a
point
prior
to
the
failure
(
see
Section
5.3.1.11.
).
The
system
should
also
log
such
events.
Have
no
interruptions
during
playback
(glitch-free).
Adjust
the
delay
of
audio
±5
image
frames
in
10
msec
increments
of
all
presentation
content
to
the
image.
The
following
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.
Table
8
:
Examples
of
Theater
Management
System
Events
🔗
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
:
Satellite
receiver(s)
(with
cache
or
local
storage)
Terrestrial
fiber
network(s)
(with
cache
or
local
storage)
Once
a
complete
DCP
has
been
ingested,
the
TMS
or
SMS
is
encouraged
to
verify
that
a
KDM
is
available
and
displays
the
time
window
for
showing
the
content.
A
TMS
or
SMS
show
schedule
can
display
conflicts
between
the
KDM
and
the
scheduled
showings.
The
TMS
or
SMS
is
encouraged
to
alert
the
user
when
a
KDM
will
expire
within
48
hours.
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
security
communications.
The
content
ingest
interface
is
required
encouraged
to
be
at
a
minimum
Gigabit
Ethernet
[IEEE802.3ab
(copper)]
or
[IEEE802.3z
(fiber)]
interface.
Theater
facilities
are
encouraged
to
provide
a
connection
that
will
be
available
24/7
for
security
communications
(e.g.,
ETMs).
It
is
theater
management’s
decision
as
to
whether
this
connection
is
dedicated.
However
it
will
be
recognized
that
for
some
operational
situations
(e.g.,
receiving
new
KDMs),
it
may
be
important
to
have
priority
access
to
this
connection.
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.
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.
For
both
hard
disc
drives
(HDD)
and
solid
state
drives
(SSD)
there
are
a
number
of
established
RAID
configurations
that
provide
storage
redundancy
and
therefore
storage
reliability.
The
storage
system
is
required
to
provide
redundancy
such
that
should
a
single
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
compressed
image,
uncompressed
audio
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
encouraged
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
,
are
some
example
storage
requirements.
The
numbers
are
based
on:
One
three-hour
feature
20
minutes
of
pre-show
material
at
the
same
resolution
16
channels
of
uncompressed
audio
at
48
kHz
at
24
(AES3)
bits
3,000
sub
pictures
in
PNG
file
format
3,000
Timed
Text
lines
Table
9
:
Example
of
Storage
Capacity
for
one
3-Hour
Feature
(12
bits
@
24
FPS)
🔗
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
Image
size:
Calculated
by:
{Average
or
max
bit
rate
(Mbits/sec)
*
hours
*
60
min/hour
*
60
sec/min}
/
{8
bits/byte
*1000}
the
results
is
in
GBytes
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).
Detailed
security
requirements
of
Media
Blocks
are
discussed
in
Section
9.4.
.
Figure
11
:
[This
Figure
Left
Blank
Intentionally]
🔗
The
Image
Media
Block
is
implemented
as
a
component
within
the
projection
system,
as
shown
in
Figure
12
.
5
[5]
In
addition
to
the
single
Image
Media
Block,
single
projector
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.
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:
Synchronization
of
audio
and
on-screen
text
to
image
shall
be
frame
accurate.
Synchronization
of
audio
objects
shall
be
accurate
to
within
10
microseconds
(sample
accuracy
at
96
kHz).
The
synchronization
signal
shall
include
information
that
represents
the
current
position
within
the
show
timeline
and
shall
be
accurate
to
within
10
microseconds.
"Locate
and
play"
shall
be
supported.
The
synchronization
signal
shall
be
defined
separately
from
any
essence
it
may
be
asked
to
synchronize,
and
able
to
sync
multiple
media
blocks
regardless
of
the
essence
they
are
handling.
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.
All
Media
Blocks
are
required
to
provide
logging
functions
per
the
requirements
of
Section
9.4.6.3.1.
.
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.
The
subpicture
renderer,
a
module
that
converts
the
subpicture
file
into
the
DCDM*
image
file
with
an
alpha
channel
overlay,
can
be
located
in
the
projector
or
the
Media
Block.
The
Timed
Text
renderer,
a
module
that
converts
Timed
Text
data
into
the
image
file
with
an
alpha
channel
overlay,
can
be
located
in
the
projector
or
the
Media
Block.
The
Media
Block
is
required
to
interface
on
three
levels
with
the
rest
of
the
system.
One
level
deals
with
the
packaged
Digital
Cinema
content.
The
next
level
is
the
raw
essence
output
for
the
projector,
the
audio
processor
and
any
special
devices
for
the
automation
system.
The
third
level
is
the
control
and
status
of
the
Media
Block
playback
system.
These
interfaces
are
noted
below.
Packaged
Data
–
The
packaged
content
requires
a
standard
data
interface
that
could
handle
bandwidths
up
to
307
Mbits/sec
for
the
composition
data
if
96
kHz
audio
is
used
or
289
Mbits/sec
if
48
kHz
audio
is
used.
This
may
be
a
Gigabit
or
1000Base-T
Ethernet
[IEEE
802.3ab
(copper)]
or
[IEEE
802.3z
(fiber)]
interface.
Uncompressed
Essence
–
The
raw
essence
data
requires
a
real
time
data
interface
with
extremely
high
bandwidths.
The
interface
will
depend
on
the
physical
location
of
the
Media
Block
and
the
type
of
essence
that
the
interface
carries.
Main
Image
–
This
streaming
data
interface
is
required
to
handle
data
rates
up
to
10
Gbits/sec.
(
See
Section
8.
for
details.)
Subpicture
–
This
streaming
data
interface
is
required
to
handle
data
rates
up
to
20
Mbits/sec.
This
can
be
accomplished
by
the
use
of
a
standard
100Base-T
Ethernet
[IEEE
802.3]
interface.
Timed
Text
–
This
could
be
a
streaming
data
interface
depending
on
the
buffer
capability
of
the
projector.
It
is
expected
that
this
interface
can
also
use
a
standard
100Base-T
Ethernet
[IEEE
802.3]
interface
that
can
handle
data
rates
up
to
500
Kbits/sec.
It
is
encouraged
that
there
be
at
least
two
of
these
interfaces
from
the
Media
Block,
one
to
feed
the
projector
and
the
other
to
feed
off-screen
devices.
Sound
Essence
–
This
interface
is
required
to
stream
multiple
digital
audio
channels
to
the
Cinema
Audio
Processor.
This
is
required
to
be
in
an
AES3
format.
For
worst-case
audio
bandwidth,
19
Mbits/sec
is
required
(16
channels
*
24
bit
sample
*
48
kHz).
37
Mbits/sec
is
recommended
(16
channels
*
24
bits/sample
*
96
kHz).
OBAE
-
This
interface
is
required
to
stream
multiple
digital
audio
channels
to
the
Cinema
Audio
Processor.
The
interface
format
is
required
to
be
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.
The
audio
bandwidth
requirements
are
generally
more
rigorous
than
main
sound
and
will
vary
by
the
number
of
channels
the
system
is
capable
of
rendering.
For
example,
for
a
system
that
can
render
48
channels,
a
minimum
of
55.3
Mbits/sec
is
required
(48
channels
*
24
bits/sample
*
48
kHz).
110.6
Mbits/sec
is
recommended
(48
channels
*
24
bits/sample
*
96
kHz).
Multiple
audio
interfaces
can
be
used
as
necessary
to
obtain
the
required
bandwidth.
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
includes
the
Media
Block
(described
above)
installed
in
the
projector.
The
Projection
system
not
only
provides
the
main
image
on
the
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.
Digital
Audio
–
The
digital
audio
is
delivered
from
the
Media
Block
to
the
Cinema
Audio
Processor.
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.
Control
and
Status
–
The
Cinema
Audio
Processor
is
encouraged
to
also
provide
a
100Base-T
Ethernet
[IEEE
802.3]
interface
that
can
receive
control
information
and
send
status
to
Automation
and/or
SMS
depending
on
the
existing
Automation
in
the
theater.
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
10
depicts
situations
and
events
related
to
the
Screen
Management
System.
Table
10
:
Examples
of
Screen
Management
System
Events
🔗
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
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.
Figure
13
:
Multiplex
Theater
System
Architecture
🔗
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,
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,
38
Mbits/sec
for
16
channels
of
24-bit
samples
at
96
KHz
or
19
Mbits/sec
for
16
channels
of
24-bit
audio
samples
at
48
KHz,
and
20
MBits/sec
for
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:
Control
and
status
communications
–
The
sending
of
commands
and
data
to
the
Theater
System
devices
and
receiving
status
back
from
those
devices.
TCP/IP
is
required
to
be
the
protocol
to
send
commands
and
configuration.
SNMP/UDP/IP
(Simple
Network
Management
Protocol
over
User
Datagram
Protocol
over
Internet
Protocol)
can
be
used
for
status
of
the
equipment.
Operational
Message
communications
–
This
messaging
supports
pre-playback,
playback
and
post
playback
operations
and
thus
interfaces
with
the
security
subsystem(s).
Such
communications
may
take
place
over
the
same
networks
as
above.
However,
Operational
Message
communications
is
required
to
employ
Transport
Layer
Security
(TLS)
per
the
security
requirements
of
Section
9.
.
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.
.
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:
Colorimetry
–
The
method
for
color
conversion
(see:
Section
3.2.1.
)
Performance
Parameters
–
Performance
specifications
and
requirements
Interfaces
–
The
physical
connections
to
and
from
the
projector
(see:
Section
8.4.
)
Digital
Cinema
presents
a
challenge
to
create
a
versatile
projection
system.
Throughout
this
system,
some
basic
requirements
are
needed
and
are
stated
below.
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.
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.
).
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.
8.3.
Projected
Image
and
Viewing
Environment
for
Digital
Cinema
Content
🔗
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.
.
The
projector
can
support
other
image
structures,
aspect
ratios,
file
formats,
and
frame
rates
as
determined
by
the
individual
manufacturer.
8.3.3.
Environment,
Image
Parameters
and
Projected
Image
Tolerances
🔗
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.
Table
11
:
[This
Table
Left
Blank
Intentionally]
🔗
Table
12
:
[This
Table
Left
Blank
Intentionally]
🔗
Table
13
:
[This
Table
Left
Blank
Intentionally]
🔗
Table
14
:
[This
Table
Left
Blank
Intentionally]
🔗
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).
Security
aspects
of
the
use
of
these
interfaces
are
described
under
Section
9.
The
projector
includes
a
Media
Block
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
.
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.
)
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:
Enable
the
decryption
and
playback
of
feature
films,
based
upon
business
rules
agreed
upon
by
Exhibition
and
Distribution.
Provide
persistent
security
protection
against
unauthorized
access,
copying,
editing,
or
playback
of
feature
films.
Provide
records
of
security-related
events.
The
high
level
technical
requirements
for
security
are:
Meet
the
above
business
requirements.
Define
an
open
security
architecture.
Provide
a
minimum
set
of
standards
around
which
the
exhibition
security
infrastructure
can
be
implemented
by
multiple
equipment
suppliers.
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
recognition
that
the
digital
cinema
industry
is
no
longer
designing
new
equipment
implementing
Link
Encryption
(LE)
functionality,
this
specification
no
longer
includes
requirements
enabling
LE-based
architectures.
As
a
result,
requirements
for
the
following
functionalities
have
been
eliminated:
Remote
Secure
Processing
Blocks
(SPB)
and
associated
Trusted
Device
List
(TDL)
authentication
Standardized
Security
Messages
and
the
associated
security
network
Pre-show
and
post-show
LE
security
maintenance
functions
(e.g.,
TLS
setup,
LE
key
delivery
and
remote
SPB
log
collection)
Existing
designs
and
exhibition
implementations
that
use
Link
Encryption
remain
DCI
compliant.
For
details
concerning
LE
implementation
and
requirements,
please
refer
to
DCSS
version
1.4.2
(or
earlier).
Fundamental
Security
Requirements
(
Section
9.2.
)
–
System-level
goals,
which
security
implementations
are
required
to
meet.
Security
Architecture
Overview
(
Section
9.3.
)
–
Definitions
and
description
of
the
basic
security
architecture,
security
messaging,
and
role
of
the
Security
Manager.
Theater
Systems
Security
(
Section
9.4.
)
–
Security
and
equipment
functions,
behavior
requirements
and
security
operations
at
exhibition.
Implementation
Requirements
(
Section
9.5.
)
–
Requirements
for
equipment
implementation,
physical
and
logical
robustness
and
certification.
Security
Features
and
Trust
Management
(
Section
9.6.
)
–
The
requirements
and
implementation
of
security
policy
and
trust
infrastructures.
Essence
Encryption
and
Cryptography
(
Section
9.7.
)
–
Cryptographic
requirements
for
essence
encryption
and
related
cryptography.
Digital
Certificates,
Extra-Theater
Message
and
Key
Delivery
Message
Requirements
(
Section
9.8.
)
–
Detailed
requirements
for
Digital
Certificates,
Extra-Theater
Message
and
Key
Delivery
Message.
The
following
acronyms
are
introduced
and
used
extensively
in
Section
9.
SM
Security
Manager
KDM
Key
Delivery
Message
ETM
Extra-Theater
Message
ITM
Intra-Theater
Message
FM
Forensic
Marking
(Marker)
SE
Security
Entity
SPB
Secure
Processing
Block
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.
,
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
produce
records
of
the
access
to
secured
content
at
authorized
facilities.
The
security
system
shall
support
techniques
to
expose
security
attacks
in
process
prior
to
an
actual
loss.
The
security
system
shall
support
techniques
(e.g.,
Forensic
Marking)
to
implant
evidence
of
origin
of
the
content
for
use
in
tracing
unauthorized
copies
of
the
content
to
the
source.
The
security
system
shall
support
the
interface(s)
and
operation
of
anti-camcorder
devices.
This
may
include,
but
is
not
limited
to,
the
ability
to
log
the
results
of
an
anti-camcorder
(detection
of
a
camcorder
event)
or
a
non-functional
anti-camcorder-ing
system.
The
security
architecture
described
herein
distinguishes
security
management
from
content
management.
Once
content
is
encrypted,
it
is
“purpose
neutral
and
safe”
and
can
be
allowed
to
take
any
path
desired
at
any
time
to
any
destination.
Thus,
content
management
(physical
distribution)
can
be
implemented
along
lines
that
are
oriented
towards
business
needs,
commercial
cost
effectiveness,
and
convenience.
“Purpose
neutral
and
safe”
means
once
content
is
encrypted,
its
purpose
has
been
neutralized
(as
to
the
content
type,
information
contained,
etc.)
and
it
is
safe
(one
does
not
care
where
it
goes,
how
it
gets
there
or
who
has
access
to
it).
Access
to
encrypted
content
is
controlled
by
the
security
management
function.
That
is,
content
access
is
enabled
or
denied
through
control
of
Security
Data.
This
function
is
entrusted
to
a
Security
Manager
(SM),
a
logically
separable
and
functionally
unique
component
of
the
architecture.
At
exhibition,
the
SM
controls
Security
Data,
and
consequently,
access
to
content.
At
the
theater,
access
to
content
is
provided
via
one
or
more
Media
Blocks
(MB),
each
containing
an
SM.
For
each
playback,
each
SM
will
require,
and
be
delivered,
one
or
more
unique
keys
to
unlock
encrypted
content
files.
All
distributors
will
share
the
SM(s).
Each
key
is
delivered
in
a
Key
Delivery
Message
(KDM)
with
a
specified
play
period.
That
is
defined
as
the
time
window
when
the
key
is
authorized
to
unlock
the
content.
There
is
a
start
time/date
and
a
stop
time/date
associated
with
each
key.
The
authorized
window
for
each
key
will
be
part
of
the
normal
engagement
negotiation
between
Exhibition
and
Distribution.
The
security
system
described
herein
implements
a
standardized
open
architecture
in
which
equipment
used
at
exhibition
facilities
can
be
sourced
from
multiple,
competing
suppliers.
In
order
to
achieve
interoperable
operation,
the
security
system
design
for
exhibition
specifies
a
standard
message
set
for
interoperable
communications
between
standardized
security
devices.
There
are
two
classes
of
messages
in
the
security
system
architecture:
Extra-theater
Messages
(ETM)
–
These
are
self-contained
one-way
messages
that
move
Security
Data
and
information
outside
or
within
the
theater.
These
specifications
have
defined
a
fundamental
message
structure
for
a
generic
ETM,
the
requirements
for
which
are
normative
and
given
in
Section
9.8.
.
Intra-theater
Messages
(ITM)
–
Messaging
that
moves
Operational
Messages
within
the
auditorium
over
one
or
more
real-time
two-way
channel(s)
between
the
Screen
Management
System
(SMS)
and
Media
Blocks
(MB).
Requirements
for
ITM
Operational
Messages
are
provided
in
the
respective
SMS,
IMB,
IMBO
and
OMB
sections,
and
Section
9.4.5.
Intra-Theater
Message
(ITM)
Communications.
Figure
14
:
[This
Figure
Left
Blank
Intentionally]
🔗
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
five
defined
SE(s)
are
as
follows
(these
are
developed
more
fully
in
Section
9.4.
).
Screen
Management
System
(SMS)
–
The
SMS
is
not
a
secure
device
and
therefore
is
not
trusted
to
handle
Security
Data
(keys).
The
SMS
is
trusted
to
send/receive
commands
to/from
the
auditorium
SM,
such
as
those
required
to
prepare
Media
Blocks
(MB)
for
playback.
Security
Manager
(SM)
–
Responsible
for
Security
Data
(keys)
and
Digital
Rights
Management
within
a
defined
sphere
of
control
(see
Section
9.4.3.5.
,
items
7
and
9c).
Media
Decryptor
(MD)
–
Transforms
encrypted
(image,
sound,
etc.)
content
to
its
original
plaintext
form.
Forensic
Marker
(FM)
–
Inserts
markings
(data
indicating
time,
date
and
location
of
playback)
in
both
image
and
audio
essence
in
realtime
at
time
of
playback
(i.e.,
a
fingerprint
or
watermark
inserter).
Secure
Processing
Block
(SPB)
–
A
Security
Entity
(SE)
whose
security
function
is
to
provide
physical
protection
to
other
SEs
contained
within
it.
A
Media
Block
is
an
example
of
a
SPB.
These
specifications
define
two
types
of
SPB
physical
protection
perimeters
(see
Section
9.4.2.2.
).
Security
Entity
Notes:
The
term
Security
Entity
should
not
be
confused
with
secure
entity
.
The
term
secure
entity
is
not
normatively
defined
or
used
in
these
specifications,
as
the
SPB
function
serves
this
purpose,
and
is
normatively
defined.
The
SMS
is
not
a
secure
device,
and
is
sometimes
viewed
as
part
of
the
media
server,
or
as
part
of
the
TMS.
These
security
specifications
focus
on
the
SMS
as
the
auditorium
controlling
device,
independently
of
its
scope
or
totality
of
other
functions
it
may
provide
(see
Section
9.4.2.5.
).
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:
Each
auditorium
shall
have
one
or
more
Image
Media
Blocks
(IMB)
and/or
IMB
with
OMB
functions
(IMBO),
each
associated
with
one
projector.
Each
auditorium
may
have
Outboard
Media
Block(s)
(OMB)
as
further
defined
herein.
The
IMB
and
IMBO
SM
shall
have
knowledge
of
the
projector
it
enables,
by
being
able
to
authenticate
that
the
projector
has
been
certified
to
meet
content
protection
requirements.
Authentication
shall
be
assured
via
a
projector
certificate,
which
shall
be
associated
with
the
projector’s
SPB
type
2
(see
Section
9.5.1.
and
Section
9.5.2.
).
The
IMB
and
IMBO
shall
include
image,
audio
and
subtitle
decryption
capability.
An
OMB
shall
decrypt
only
the
content
essence
types
designated
by
this
specification
(see
Section
9.4.3.6.4.
).
With
exception
of
subtitle
essence
(see
Section
9.7.3.
),
encrypted
essence
files
shall
be
decrypted
in
real-time
during
playout,
and
at
all
other
times
shall
remain
encrypted
as
received
in
the
DCP.
The
IMB
and
IMBO
shall
include
image
and
audio
Forensic
Marking
(FM)
capability.
The
OMB
may
include
FM
for
the
content
essence
it
decrypts,
as
defined
by
the
requirements
of
the
OMB
normative
requirements
Section
9.4.3.6.4.
[This
Item
Left
Blank
Intentionally]
All
Media
Blocks
shall
be
of
the
SPB
type
1
(see
Section
9.4.2.2.
),
and
shall
be
field
replaceable,
but
non-field
serviceable.
8
[8]
Secure
Processing
Block
(SPB)
devices
(and
the
SEs
contained
within
them)
shall
have
normative
security
and
operational
behavior
requirements
specified.
Security
Managers
shall
monitor
the
functioning
of
all
SPB/SE
devices
and
invoke
controls
to
prevent
use
of
improperly
operating
security
equipment.
To
the
extent
possible,
all
security
devices
shall
be
designed
with
self-test
capability
to
announce
and
log
failures
and
take
themselves
out
of
service.
The
security
architecture
descriptions
and
requirements
revolve
around
two
embodiments:
the
SPB
and
the
SE.
As
defined
in
Section
9.3.3.
,
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
type
1
and
type
2
SPB
requirements
are
more
fully
defined
in
the
Media
Block
and
projector
SPB
functional
requirements
below
(see
Section
9.5.
).
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.
Figure
15
:
Exemplary
Security
System
Architecture
🔗
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.
(for
the
SMS)
and
Section
9.4.3.5.1.
(for
MB
SMs).
Requirements
of
log
collection
generally
are
provided
in
Section
9.4.6.3.
.
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.
and
Section
9.4.3.6.
).
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.
The
term
Equipment
Suite
was
used
in
connection
with
authentication
of
remote
SPBs
by
the
SM.
With
the
elimination
of
link
encryption
there
are
no
remote
SPBs
and
associated
equipment
suite,
so
neither
term
is
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
Block
type
1
–
An
SPB
type
1
provides
the
highest
level
of
physical
and
logical
protection.
All
Media
Blocks
(as
defined
below)
shall
be
contained
within
a
type
1
SPB.
Secure
Processing
Block
type
2
–
An
SPB
type
2
provides
a
lesser
perimeter
of
protection,
for
content
or
security
information
that
does
not
require
the
full
SPB
type
1
protection.
SPB
type
2
protection
shall
be
provided
by
projectors.
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.
.
The
term
Media
Block
11
[11]
(MB)
has
been
used
by
the
Digital
Cinema
industry
in
a
number
of
ways.
In
this
Section
9.
,
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:
Image
Media
Block
(IMB)
–
The
Image
Media
Block
(IMB)
is
a
type
1
Secure
Processing
Block
(SPB)
that
shall
contain
a
Security
Manager
(SM),
Image,
Audio
and
Subtitle
Media
Decryptors
(MD),
image
decoder,
Image
and
Audio
Forensic
Markers
(FM).
Image
Media
Block
with
OMB
Functions
(IMBO)
–
It
is
encouraged
that
the
IMB
perform
the
content
essence
processing
functions
of
the
Outboard
Media
Block
(OMB)
as
given
in
Section
9.4.3.6.4.
.
An
IMBO
is
an
IMB
that
implements
this
functionality.
Outboard
Media
Block
(OMB)
–
The
OMB
is
a
type
1
SPB
that
shall
contain
a
Security
Manager
(SM)
and
one
or
more
Media
Decryptors
(MD)
and
associated
Forensic
Markers
(FM)
to
process
(only)
those
content
essence
types
explicitly
designated
in
Section
9.4.3.6.4.
.
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.
and
Section
9.6.1.
.
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
a
type
1
SPB.
Security
Manager
software
changes
and
upgrade
requirements
are
given
in
Section
9.5.2.7.
.
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.
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).
SMS
functions
are
supported
by
the
Operational
Message
communications
of
Section
9.4.5.
.
The
SMS
shall
support
Operational
Message
communications
with
Media
Blocks
as
follows:
IMB
or
IMBO
–
Except
as
provided
for
below
in
Section
9.4.2.5.2.
,
the
command
protocol
is
not
normatively
specified,
but
is
encouraged
to
support
messaging
as
defined
by
SMPTE
430-17
SMS-OMB
Communications
Protocol
Specification.
OMB
–
The
command
protocol
shall
be
compliant
with
and
support
all
messaging
as
defined
by
SMPTE
430-17
SMS-OMB
Communications
Protocol
Specification.
SMS
Requirements:
The
SMS
shall
carry
a
DCI
compliant
digital
certificate
(see
Section
9.5.1.
)
to
identify
the
SMS
entity
to
the
SM.
The
SMS
certificate
shall
indicate
only
the
SMS
role
unless
the
SMS
is
contained
within
a
SPB
meeting
the
protection
requirements
for
any
other
designated
roles.
In
the
latter
case
the
SMS
shall
be
considered
permanently
integrated
within
said
SPB,
and
the
SPB
and
contained
SMS
shall
be
identified
by
a
single
certificate
that
is
permanent
to
both.
C
ommunications
between
the
SMS
and
Media
Block
SMs
shall
be
protected
using
Transport
Layer
Security
(TLS),
except
in
the
case
of
a
permanently
integrated
SMS.
(In
the
latter
case
the
SMS
and
SM
are
collocated
within
the
same
MB,
and
the
communications
are
protected
within
the
MB's
type
1
SPB.)
The
SMS
digital
certificate
may
be
permanent
to
the
SMS,
or
“operator
certificates”
may
be
assigned
to
designated
personnel
(e.g.,
using
a
dongle,
smart
card,
etc.)
for
association
with
the
SMS.
For
each
KDM
to
be
used
in
the
playout
of
a
CPL,
the
SMS
shall
confirm
that
all
the
content
essence
keys
referenced
by
the
KeyId
elements
within
the
AuthenticatedPublic
section
of
the
associated
KDM
are
reflected
(i.e.,
must
exactly
match
those
listed)
in
the
CPL.
In
the
event
that
Exhibition
command
and
control
designs
include
the
TMS
as
a
device
that
interfaces
with
the
SMs,
such
a
TMS
shall
be
viewed
by
the
security
system
as
an
SMS,
and
it
shall
carry
a
digital
certificate
and
follow
all
other
SMS
behavior,
Transport
Layer
Security
(TLS)
and
Operational
Message
communications
requirements.
Identification
of
the
SMS
operator
for
purposes
of
the
“AuthorityID”
field
(see
Section
9.4.6.3.8.
)
shall
be
by:
Certificate
thumbprint,
where
“operator
certificates”
are
used,
or
Username/password
or
the
like,
as
specified
by
exhibition
management.
SM
interaction
with
the
SMS
is
normatively
defined
(see
Section
9.4.3.5.
)
12
[12]
.
These
include
the
requirements
that:
The
SM
provides
log
records
identifying
the
SMS
for
which
it
operates,
as
well
as
the
AuthorityID
field.
In
the
case
where
“operator
certificates”
are
used,
this
information
is
the
same
(i.e.,
the
digital
certificate
thumbprint).
If
multiple
SMSs
are
present,
exhibition
shall
designate
one
to
TLS
connect
with,
and
be
used
for
identity
logging
by,
all
SMs
participating
in
any
given
showing.
Upon
request,
this
SMS
shall
be
responsible
for
collecting
and
aggregating
all
post-show
log
data
from
all
participating
SMs.
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:
Being
aware
of
the
complement
of
Media
Blocks
(IMB,
OMB
or
IMBO)
present
in
the
projection
booth,
and
the
essence
processing
capabilities
of
each.
Analyzing
composition
playlists
(CPLs)
and
show
playlists
(SPLs)
to
determine
which
Media
Blocks
(MB)
will
be
expected
to
play/render
each
essence
component
of
the
composition(s)
of
a
show,
and
confirm
the
complement
of
MBs
is
so
capable.
Delivering
all
SPL
KDMs
and
CPLs
to
the
complement
of
MBs
and
obtaining
confirmation
from
each
participating
SM
that
the
prerequisites
of
Section
9.4.3.
and
9.4.3.5
Functions
of
the
Security
Manager
(SM)
are
satisfied.
Where
applicable,
the
use
of
SMPTE
standards
in
support
of
the
above
is
normatively
defined
in
this
specification.
The
use
of
other
SMPTE
standards
is
encouraged
but
is
implementation-specific.
In
sum,
MMB
operation
places
important
responsibilities
and
additional
operational
expectations
onto
the
SMS
to
assure
security
requirements
are
satisfied
so
that
each
show
playout
is
successful.
The
pre-show,
show
playout
and
post-show
operation
of
MMB
architectures
mandates
the
implementation
of
additional
SMS
functionality
and
automated
processes.
Per
Section
9.4.1.2.
,
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:
getStatus
generateCplProcessedLogReport
getCplProcessedLogReport
cancelCplProcessedLogReport
A
permanently
integrated
SMS
(see
Section
9.4.2.5.
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.
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
Image
Media
Block
(IMB)
or
IMB
with
OMB
functions
(IMBO).
A
critical
security
issue
is
assuring
that
the
clear
text
image
output
of
the
companion
MB
goes
to
a
legitimate
projection
device.
Therefore
Section
9.4.3.6.1.
,
defines
a
“marriage”
process
with
the
companion
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.
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.
(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.
.
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
three
categories:
Pre-show
preparations
Playback
Post
playback
The
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:
Multiple
projectors
–
Multiple
IMBs
or
IMBOs
may
be
used,
one
for
each
projector.
Outboard
Media
Blocks
(OMB)
–
One
or
more
OMBs
may
be
present
to
enable
processing
of
DCP
essence
types
beyond
those
processed
by
the
IMB
or
IMBO.
MMB
is
operationally
supported
as
follows:
Each
participating
MB/SM
shall
be
provided
with
the
CPL
and
a
KDM
for
each
composition
of
the
Show
Playlist
(SPL).
Each
KDM
shall
be
created
(encrypted)
uniquely
for
the
MB/SM
it
is
targeted
for,
and
each
KDM
shall
carry
all
the
CPL
identified
essence
keys
required
for
the
composition.
Each
MB/SM
shall
be
provided
with
the
appropriate
DCP
track
files
for
the
media
essence
to
be
processed
by
the
respective
MB.
(This
could
be
the
entire
DCP
or
portions
of
it
according
to
where
DCP
track
file
parsing
takes
place.)
The
collective
functionality
of
the
Media
Blocks
within
the
projection
booth
to
be
used
for
any
given
DCP
will
be
driven
by
the
essence
types
in
the
DCP
(for
example,
some
DCPs
won’t
use
an
OMB).
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.
.
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.
Composition
Playlist
(CPL)
and
Key
Delivery
Message
(KDM)
check(s)
–
Composition
Playlists
(CPL)
and
Key
Delivery
Messages
(KDM)
shall
be
validated
by
the
Security
Manager(s)
participating
in
the
respective
composition
playback.
Composition
decryption
preparations
–
Each
encrypted
composition
will
have
associated
with
it
one
or
more
Key
Delivery
Messages
(KDM),
carrying
time
window
constraints,
decryption
keys,
and
the
projector's
authentication
data
(certificate
thumbprint).
The
SMS,
working
with
the
security
infrastructure,
shall
verify
that
all
the
KDMs
and
contained
content
keys
required
for
playback
are
available
and
valid
for
scheduled
exhibitions.
Show
playback
preparations
–
Exhibitors
will
assemble
Show
Playlists
specific
to
each
exhibition
event,
containing
various
compositions
(including
advertising,
trailers,
movies,
etc.).
Because
the
final
Show
Playlists
may
involve
many
content
keys
and/or
consist
of
content
from
different
Rights
Owners,
it
is
the
responsibility
of
the
SMS
to
confirm
that
show
preparations
ensure
the
auditorium
SM(s)
confirm
possession
of
all
necessary
Key
Delivery
Message(s)
(
KDMs)
for
each
composition
of
the
Show
Playlist.
The
flow
chart
in
Figure
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,
forensic
marking,
and
recording
of
log
data.
Equipment
preparations
–
The
SMS
and
SM(s)
shall
prepare
for
playback
prior
to
each
Show
Playlist
(SPL)
showing.
This
shall
include
validation
of
the
authenticity
and
trust
status
of
the
projector,
and
delivery
of
all
necessary
KDMs/keys
per
Section
9.4.3.5.
.
Streaming
media
decryption
–
Playback
of
a
show
consists
of
a
concatenation
of
compositions
that
require
serial
or
(separately)
parallel
decryption.
One
or
more
Media
Blocks
(i.e.,
for
single
IMB
or
Multiple
Media
Block
(MMB)
operation)
will
be
involved.
Forensic
Marking
-
Each
MB
shall
apply
Forensic
Marking
to
image
and
audio
essence
and
Aux
Data
(as
applicable)
during
playback
.
Log
data
recording
-
Media
Blocks
shall
capture
log
records
as
specified
in
Section
9.4.6.3.
.
The
flow
chart
in
Figure
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
collection
of
playback
event
log
data.
Collection
of
log
data:
SM
–
Each
IMB
and/or
IMBO
SM
shall
be
responsible
for
collection
of
all
playback
event
log
data
from
the
projector
it
supports
per
Section
9.4.6.3.
.
Collection
of
log
data:
SMS
–
The
SMS
shall
be
responsible
for
post
playout
log
collection
per
Section
9.4.2.5.2.
.
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
,
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:
Validate
Key
Delivery
Messages
per:
The
three
validity
checks
of
Section
6.1.2.
of
the
KDM
specification
[SMPTE
430-1
D-Cinema
Operations
--
Key
Delivery
Message],
and
Confirming
the
KDM's
CipherData
element
matches
the
contents
and
format
of
the
table
of
said
Section
6.1.2.
of
the
KDM
specification.
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.
Security
Manager
(SM)
KDM
usage
policy
is
specified
as
follows:
For
any
given
SM,
playout
within
the
associated
Media
Block
(MB)
shall
be
supported
by
a
single
KDM
(i.e.,
a
playout
shall
not
occur
that
requires
the
combination
of
two
or
more
KDMs).
(Note
that
Multiple
Media
Block
(MMB)
operation
will
require
multiple
KDMs
to
support
playout
across
multiple
SMs/MBs.
Since
all
KDMs
for
a
given
CPL
must
contain
all
the
content
keys
for
the
composition
(see
Section
9.4.3.
),
depending
upon
its
MB
configuration
the
SM
may
find
more
essence
keys
in
the
KDM
and
identified
in
the
CPL
than
it
will
use.)
For
any
given
composition,
playout
shall
be
enabled
for
any
start
time
that
is
within
the
KDM's
time
window.
To
avoid
end
of
engagement
issues,
a
show
time’s
playout
may
extend
beyond
the
end
of
the
KDM's
playout
time
window,
if
started
within
the
KDM
playout
time
window,
by
a
maximum
of
six
(6)
hours.
Excepting
the
requirements
of
item
2c
above,
the
SM
shall
delete
any
KDM
and
associated
keys
for
which
the
playback
time
window
has
expired
(passed).
Reject
ETM
messages
that
are
not
recognized
as
DCI
compliant
standardized
messages.
Validate
Composition
Playlists
(CPL),
and
log
results
as
a
prerequisite
to
the
associated
composition
playback.
For
encrypted
content,
validation
shall
confirm
that:
The
associated
KDM's
ContentAuthenticator
element
matches
a
certificate
thumbprint
of
one
of
the
certificates
in
the
CPL's
signer
chain
(see
item
1
above),
and
that
such
certificate
indicate
only
a
"Content
Signer"
(CS)
role
per
Section
5.3.4.
"Naming
and
Roles"
of
the
certificate
specification
[SMPTE
430-2
D-Cinema
Operation
-
Digital
Certificate].
[This
item
left
blank
intentionally.
The
KDM-CPL
content
essence
keys
match
test
has
been
reassigned
to
the
SMS.]
The
CPL
meets
the
two
validation
requirements
defined
in
Section
5.2.1.
of
SMPTE
430-5
D-Cinema
"D-Cinema
Operations
–
Security
Log
Event
Class
and
Constraints
for
D-Cinema.
D-Cinema"
with
the
following
caveat:
When
performing
Step
9
of
Section
6.2
in
SMPTE
ST
430-2,
the
desired
time
of
the
validation
context
shall
be
equal
to
the
IssueDate
field
of
the
target
CPL
(and
not
the
current
time).
This
behavior
permits
the
continued
playback
of
a
CPL
after
the
expiration
of
its
signing
certificate,
but
ensures
that
the
signing
took
place
during
the
certificate's
validity
period.
Process
essence
(i.e.,
Track
File
frame)
integrity
pack
metadata
for
image
and
sound
during
show
runtime.
Integrity
pack
deviations
(including
HMAC,
as
applicable)
detected
during
playback
shall
be
logged;
however,
per
Section
9.6.1.2.
Table
21
,
playback
should
not
be
prevented
or
interrupted.
For
clarity
purposes,
integrity
pack
metadata
is
defined
as
Track
File
ID,
Frame
Sequence
and
calculated
Message
Integrity
Code
(MIC)
information
to
be
compared
against
the
reference
data
contained
in
the
associated
CPL.
Log
information
necessary
to
detect
deviations
(including
restarts)
from
the
actual
playback
sequence
from
the
Track
File
ID
and
reel
sequence
specified
in
the
CPL
as
follows:
Image
–
Process
integrity
pack
information,
with
the
exception
that
the
frame
hash
(HMAC)
check
is
encouraged
but
optional.
Audio
–
Process
integrity
pack
information,
including
the
hash
(HMAC).
OBAE
–
Process
integrity
pack
information,
including
the
hash
(HMAC).
The
SM
shall
disallow
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.
-
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.
As
of
January
1,
2016,
Federal
Information
Processing
Standards
(FIPS)
compliance
requirements
disallow
use
of
the
random
number
generator
(RNG)
as
specified
in
[SMPTE
ST429-6
D-Cinema
Packaging
-
MXF
Track
File
Essence
Encryption].
Additionally,
a
KDM
key
type
is
needed
to
support
encryption
of
generic
Auxiliary
Data
(AD)
essence
per
[SMPTE
ST429-14
D-Cinema
Packaging
-
Aux
Data
File].
These
are
addressed
by
the
following
requirements
for
support
of
KDMs
carrying
"MIC"
and
"Aux
Data"
key
types:
Media
Block
(MB)
SMs
shall
support
the
receipt
and
processing
of
KDMs
carrying
the
MIC
and
Aux
Data
(AD)
key
types.
(See
[SMPTE
ST430-1
D-Cinema
Operations
-
Key
Delivery
Message].)
MB
SMs
shall
perform
the
content
hash
(HMAC)
integrity
check
of
above
item
5
using
the
KDM-borne
MIC
keys
if
present
(and
shall
not
derive
the
MIC
key
from
KDM
content
keys).
MB
SMs
capable
of
processing
KDM-borne
MIC
keys
shall
indicate
so
by
including
"MIC"
in
their
digital
certificate
roles
(see
role
definitions
of
Section
9.5.1.1.
).
MB
SMs
shall
not
implement
the
Random
Number
Generator
(RNG)
defined
(for
the
purpose
of
MIC
key
derivation)
in
[SMPTE
ST429-6:
D-Cinema
Packaging
-
MXF
Track
File
Essence
Encryption].
When
receiving
a
KDM
type
that
does
not
contain
a
MIC
key,
MB
SMs
shall
perform
all
the
content
integrity
checks
specified
in
above
item
5
except
the
hash
(HMAC)
check.
Authenticate
the
projector
by
confirming
the
projector
certificate
thumbprint
carried
in
the
KDM
matches
that
received
from
the
projector
via
the
marriage
connection.
Content
owners
may
optionally
allow
the
SM
to
automatically
assume
trust
in
the
projector
that
it's
married
to.
To
support
this
feature,
a
unique
"assume
trust"
certificate
thumbprint
is
specified
as
the
"SHA-1
of
the
empty
string".
The
Base64
value
of
this
string
shall
be
"2jmj7l5rSw0yVb/vlWAYkK/YBwk="
for
this
exclusive
use.
[This
Item
Left
Blank
Intentionally]
The
SM
shall
constrain
playout
of
encrypted
content
to:
Media
Decryptors
(MD)
within
the
SM’s
SPB
(i.e.,
under
no
circumstances
shall
an
SM
export
any
KDM-borne
essence
key
from
the
SM’s
SPB).
Specific
MDs
matching
the
KeyType
IDs
as
designated
by
the
KDM,
per
Section
5.2.8.
of
the
KDM
specification
[SMPTE430-1
D-Cinema
Operations
-
Key
Delivery
Message].
Receipt
by
the
SM
of
a
valid
KDM
and
CPL
for
the
composition
being
prepared
for
playback
per
items
1
and
4
above.
Perform
and
log
all
the
above
functions
under
the
operational
(not
security)
control
of
the
particular
SMS
designated
by
the
exhibition
operator
per
Section
9.4.2.5.
.
9.4.3.5.1.
Playout
Log
Record
Generation
and
Delivery
🔗
Per
Section
9.4.1.2.
,
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:
Upon
the
playout
of
an
encrypted
composition,
each
participating
MB
SM
shall
track
each
resulting
CPLStart
and
CPLEnd
log
record
(hereinafter
“CPLProcessed
event
record”),
and
disallow
or
terminate
playout
of
any
encrypted
composition
if
any
such
record
has
not
been
collected
by
the
SMS
within
24
hours
of
its
timestamp.
(See
Section
9.4.6.3.8.
for
CPLStart
and
CPLEnd
event
triggers.)
Post
playout
log
reports
shall
be
comprised
of
only
CPLProcessed
event
records,
and
only
previously
unreported
CPLProcessed
event
records
shall
be
subsequently
reported.
For
permanently
integrated
SMS
requirements
(see
Section
9.4.2.5.
at
"SMS
Requirements")
the
MB
shall
generate
CPLProcessed
security
log
report(s)
within
24
hours
of
any
given
playout.
The
reporting
of
CPLProcessed
event
records
via
general
log
collection
processes
may
take
place
at
any
time,
but
shall
not
affect
the
requirements
of
this
section.
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.
for
SMS
playout
log
collection
requirements.
9.4.3.6.
Functional
Requirements
for
Secure
Processing
Block
Systems
🔗
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.
).
This
section
defines
the
functions
and
operational
requirements
for
the
following
SPB
systems:
Projector
Secure
Processing
Block
(SPB)
Image
Media
Block
(IMB)
and
IMB
with
OMB
functions
(IMBO)
Secure
Processing
Block
(SPB)
Outboard
Media
Block
(OMB)
In
addition
to
the
specific
requirements
given
for
SPB
systems
in
this
section,
all
SPB
systems
shall
meet
the
behavior
requirements
of
Section
9.6.1.
Digital
Rights
Management.
From
a
security
perspective,
a
projection
system
consists
of
the
projector
Secure
Processing
Block
(SPB)
type
2
and
its
companion
SPB,
which
will
be
either
an
Image
Media
Block
(IMB)
or
IMB
with
OMB
functions
(IMBO).
The
following
are
the
normative
requirements
for
the
projector
Secure
Processing
Block
(SPB):
The
projector’s
companion
SPB
(IMB
or
IMBO)
shall
be
physically
inside
of,
or
otherwise
mechanically
connected
to,
the
projector
Secure
Processing
Block
(SPB).
The
integrity
of
the
above
projector/companion
MB
connection
shall
be
assurred
via
an
electronic
marriage
that
shall
take
place
upon
installation
of
the
companion
MB
and
projector
pair.
This
physical/electrical
connection
shall
be
battery-backed
and
monitored
24/7
by
the
companion
MB
and,
if
broken,
shall
require
a
re-installation
(re-marriage)
process.
Breaking
the
marriage
shall
not
zero
the
projector
SPB
long
term
identity
keys
(RSA
private),
see
item
7
below.
Projector
maintenance
may
involve
a
marriage
(or
re-marriage)
event,
or
access
to
the
projector
SPB
or
both.
To
support
projector
maintenance,
the
projector
SPB
may
be
serviceable,
but
access
is
security-sensitive
because
of
the
possibility
of
tampering
during
service
access.
A
security
access
opening
event
shall
be
electronically
detected,
and
projector
SPB
designs
shall
prevent
playout
unless
the
detector(s)
indicate
all
security
access
openings
are
closed.
(Projector
SPB
"maintenance"
and
"security"
servicing
is
defined
in
Section
9.5.2.4.
.)
Once
a
projector
is
installed,
projector
SPB
access
door
“open”,
access
door
“close”,
“marriage”
and
“marriage
break”
events
shall
be
logged,
and
the
“AuthID”
token
(see
Section
9.4.6.3.8.
)
shall
indicate
the
responsible
exhibition
party
that
executed
(or
supervised)
the
event(s).
Once
a
projector
is
installed,
all
relevant
projector
SPB
events
of
Section
9.4.6.3.
.
shall
be
logged
24/7
under
both
powered
and
un-powered
conditions.
To
avoid
the
complexity
of
retaining
its
own
log
records
(and
the
associated
need
for
a
clock
and
battery-backed
persistence),
the
projector
SPB
shall
send
projector
SBP
log
event
data
(i.e.,
SPBOpen
and
SPBClose
signals
per
Table
19
)
across
the
marriage
electrical
interface
for
retention
by
the
companion
MB.
Projector
SPB
designs
shall
not
allow
physical
access
to
signals
running
between
the
companion
MB
and
the
projector
SPB
without
breaking
the
marriage,
in
which
case
a
re-installation
shall
be
required
and
tampering
will
be
observed
by
the
authorized
installer
(see
Section
9.5.2.4.
).
The
projector
SPB
shall
accept
the
decrypted
streaming
image
signal
from
the
IMB
or
IMBO
and
process
accordingly.
The
projector
SPB
shall
provide
at
least
a
type
2
image
signal
path
and
tamper/access
protection
container.
The
physical
requirements
for
a
type
2
SPB
are
given
in
Section
9.5.2.4.
.
The
projector
SPB
shall
include
a
Secure
Silicon
host
device
(see
Section
9.5.2.
),
which
shall
contain
the
SPB's
digital
certificate.
Monitor
IMB
SPB
physical
security
protection
integrity
24/7.
In
the
event
of
intrusion
or
other
tamper
detection,
terminate
all
activity
and
zero
all
Critical
Security
Parameters
(see
Section
9.5.2.6.
).
If
communication
with
the
SMS
is
available,
issue
an
alert
message.
Do
not
purge
log
records.
At
the
time
of
installation
(mechanical
connection
to
the
projector
and
electrical
initiation)
the
IMB
shall
perform
and
thereafter
support
electrical
and
logical
marriage
with
the
projector
SPB
per
Section
9.4.3.6.1.
.
Electrical
connection
integrity
shall
be
monitored
24/7,
and
should
the
integrity
of
the
connection
be
broken
the
IMB
shall
log
the
event
and
require
a
re-installation
process
before
becoming
active
again.
Breaking
of
the
IMB/projector
SPB
marriage
shall
not
zero
the
IMBs
long-term
identity
keys
(RSA
private
keys).
An
IMB
shall
be
designed
such
that
it
does
not
perform
any
composition
decryption
functions
until
integrated
and
married
to
a
projector
SPB.
Perform
media
decryption
for
image,
audio
and
subtitle
essence.
Perform
forensic
marking
for
image
and
audio
essence.
The
IMB
may
optionally
perform
the
functions
required
to
process
one
or
more
of
the
essence
types
defined
in
Section
9.4.3.6.4.
,
item
4.
In
such
case
the
IMB
shall
implement
all
requirements
of
the
OMB
section
for
each
such
essence
type
(in
addition
to
the
IMB
requirements
of
this
section).
Per
Section
9.4.2.3.
,
such
an
IMB
is
referred
to
as
an
Image
Media
Block
with
OMB
Functions
(IMBO).
After
image
decryption
and
Forensic
Marking
(and
other
non-security
plain
text
functions
as
appropriate
by
design),
pass
the
image
signal
to
the
projector
SPB.
Record
security
event
data
for
logging
under
both
powered
and
un-powered
conditions.
Sign
and
assemble
logged
information
into
standardized
log
reports
per
Section
9.4.6.3.
.
Once
integrated
within
a
projector
as
the
projector's
companion
SPB,
the
IMB
shall
provide
24/7
log
recording
support
and
storage
of
all
log
records
associated
with
the
projector
SPB.
An
IMB
intended
for
operation
in
Multiple
Media
Block
(MMB)
installations
shall
be
capable
of
operating
as
either
a
"source"
or
"sink"
of
synchronization
information
per
the
requirements
of
Section
7.5.4.2.1.
.
Such
an
IMB
is
defined
as
"MMB-Capable,"
per
Glossary
Of
Terms
9.4.3.6.4.
Normative
Requirements:
Outboard
Media
Block
(OMB)
🔗
The
following
are
the
normative
requirements
for
the
Outboard
Media
Block:
Perform
the
following
itemized
SM
functions
as
defined
unde
r
Section
9.4.3.5.
:
#1,
#2,
#3,
#4,
#5,
#6,
#8
sub-item
a.
(only),
#9
(except
for
sub-items
a.,
b.
and
c.),
#11,
#12,
#13,
#14,
#18.
Monitor
OMB
SPB
physical
security
protection
integrity
24/7.
In
the
event
of
intrusion
or
other
tamper
detection,
terminate
all
activity
and
zero
all
Critical
Security
Parameters
(see
Section
9.5.2.6.
).
If
communication
with
the
SMS
is
available,
issue
an
alert
message.
Do
not
purge
log
records.
Perform
media
decryption
on
encrypted
essence,
and
forensic
marking
as
applicable
on
essence
prior
to
outputting
clear
text
content
from
the
SPB.
Content
essence
type(s)
are
limited
to
those
explicitly
listed
as
follows:
Auxiliary
Data
(AD)
essence
per
[SMPTE
ST429-14:
D-Cinema
Packaging
-
Aux
Data
Track
File],
subject
to
the
constraints
of
Section
9.4.2.7.
.
Record
security
event
data
for
logging
under
both
powered
and
un-powered
conditions.
Sign
and
assemble
logged
information
into
standardized
log
reports
per
Section
9.4.6.3.
.
Operate
as
a
“sink”
of
synchronization
information
per
the
requirements
of
Section
7.5.4.2.1.
.
Communications
with
the
SMS
shall
be
compliant
with
and
support
all
SMPTE
430-17
SMS-OMB
Communications
Protocol
Specification
commands.
Additional
commands
beyond
those
defined
in
said
SMPTE
standard
are
permitted.
This
section
assumes
that
the
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
either
MB
type
to
be
permanently
married
to
a
projector,
and
not
field
replaceable.
In
such
a
case
where
the
projector
and
its
companion
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
MB
from
marriage
monitoring
duties,
but
does
not
change
the
requirement
for
the
MB
and
the
projector
SPB
to
meet
the
respective
SPB
type
1
and
type
2
physical
and
logical
protection
requirements
of
Section
9.5.
,
and
the
normative
requirements
as
specified
above
(except
as
the
latter
requirements
relate
to
marriage
event
and
connection
monitoring).
In
the
case
where
the
Projector
and
companion
MB
are
inseparable,
a
single
Digital
Cinema
Certificate
shall
represent
both
the
Projector
and
its
companion
MB.
For
dual
certificate
implementations
this
shall
be
the
Security
Manager
Certificate
(see
Section
9.5.1.
).
Implementations
that
do
not
meet
the
marriage
functions,
per
the
normative
requirements
of
this
section,
shall
not
permit
field
replacement
of
the
IMB
or
IMBO,
and
shall
require
the
projector
and
companion
MB
system
to
be
replaced
in
the
event
of
failure.
Note:
For
permanently
married
implementations
the
KDM
need
not
carry
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.
9.4.3.7.
Theater
System
Clocks
and
Trustable
Date-Time
🔗
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
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”.
All
security
transactions
conferring
date-time
information
(e.g.,
KDM
time
window)
shall
be
UTC.
Image
Media
Block
(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:
Each
IMB,
IMBO
and
OMB
clock
shall
be
set
by
the
MB
vendor
to
within
one
second
of
UTC
using
a
reference
time
standard
(such
as
WWV).
The
clock
shall
be
tamper-proof
and
thereafter
may
not
be
offset
from
UTC
or
otherwise
reset
14
[14]
.
In
order
to
maintain
synchronism
between
auditoriums,
Exhibition
shall
be
able
to
adjust
a
Security
Manager’s
time
a
maximum
of
+/-
six
minutes
within
any
calendar
year.
Time
adjustments
shall
be
logged
events.
The
IMB,
IMBO
and
OMB
Security
Manager
(SM)
clocks
shall
have
the
following
capabilities:
Resolution
to
one
second
Stability
to
be
accurate
+/-
30
seconds/month
Date-Time
range
at
least
20
years
Battery
life
of
at
least
5
years
Battery
can
be
changed
without
losing
track
of
proper
time
Proper
time
stamping
of
log
events
shall
not
be
interrupted
during
a
clock
battery
change
process.
“Special
Auditorium
Situations”
(which
supported
multiple
projector
operation)
were
enabled
in
conjunction
with
Link
Encryption
(LE)
functionality,
which
is
no
longer
supported
by
this
specification.
Use
of
more
than
one
projector
in
an
auditorium
is
enabled
via
Multiple
Media
Block
(MMB)
operation.
This
specification
originally
defined
two
categories
of
Intra-Theater
Messages
(ITM):
Category
1
operational
messages
(for
SMS
to
MB
communications)
and
category
2
standardized
security
messages
(for
communicating
Auditorium
Security
Messages
between
the
IMB
and
remote
SPBs).
With
the
elimination
of
Link
Encryption
(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
Operational
Messages
in
this
specification.
Except
where
stated
otherwise,
Operational
Messages
and
message
requirements
shall
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.
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:
The
Forensic
Marking
data
payload
is
required
to
carry
time
stamp
and
location
information
as
follows:
Time
stamp
every
15
minutes
(four
per
hour),
24
hours
per
day,
366
days/year
the
stamp
will
repeat
annually.
There
are
35,136
time
stamps
needed,
therefore
allocate
a
16
bit
unsigned
number
(65,536).
Location
(serial
number)
information,
allocated
19
bits
(524,000
possible
locations/serial
numbers)
or
20
bits
(1,048,576
possible
locations/serial
numbers).
All
payload
bits
are
required
to
be
included
in
each
five
minute
segment.
Forensic
Marking
insertion
is
required
to
be
a
real-time
(i.e.,
show
playback
time),
in-
line
process
performed
in
the
associated
media
block,
and
is
required
to
have
a
reasonable
computational
process.
Recovery
can
take
up
to
a
30-minute
content
sample
for
positive
identification.
Support
of
a
single
distribution
inventory
is
required.
Terms
and
conditions
of
use
are
required
to
be
reasonable
and
non-discriminatory(RAND).
Detection
can
be
performed
by
the
vendor
or
the
Rights
Owner
at
the
Rights
Owner’s
premises.
DCI
will
entertain
development
of
a
generic
Forensic
Mark
inserter
architecture.
Any
FM
technology
utilizing
pre-processing
is
required
to
use
a
generic
inserter
architecture
that
meets
the
criteria
outlined
below.
Additionally,
a
full
understanding
of
the
intellectual
property
terms
and
conditions
will
need
to
be
reached.
Standardized
Metadata
Format
–
Any
pre-processing
solution
is
required
to
be
able
to
utilize
a
single,
industry
standardized
metadata
transport
format
and
a
generic
inserter
solution.
Title
(Composition)
Single
Inventory
–
For
each
composition,
the
system
is
required
to
support
the
use
of
a
single
image
or
audio
FM
technology
that
generates
one
set
of
metadata.
This
metadata
is
required
to
be
compatible
with
all
deployed
compliant
generic
inserters.
At
the
distributor’s
discretion,
multiple
sets
of
metadata
can
be
used
to
mark
the
same
composition.
Generic
Inserter
Compatibility
–
For
the
initial
generic
inserter
deployment,
the
generic
inserter
in
final
product
form
is
required
to
be
openly
demonstrated
and
independently
tested
to
demonstrate
compatibility
with
a
minimum
of
three
independent
metadata-based
forensic
marking
solutions.
Forensic
Mark
and
Generic
Inserter
Backwards
Compatibility
–
After
initial
deployment,
any
subsequent
metadata-based
FM
solutions
or
generic
inserters
are
required
to
function
correctly
with
all
deployed
compliant
systems.
Forensic
Mark
Pre-Processing
Speed
–
The
Forensic
Mark
processing
steps
needed
to
generate
and
insert
metadata
are
required
to
be
real
time
or
faster
and
are
required
to
occur
in
a
single
pass.
As
a
matter
of
implementation,
recognizing
business
and
post-production
constraints,
it
is
encouraged
that
a
generic
inserter
implementation
minimizes
the
metadata
payload
needed
to
provide
forensic
mark
data
to
the
generic
inserter.
A
reasonable
target
would
be
less
than
two
percent
of
the
compressed
image
and
sound
data
payload.
Each
instance
of
a
Forensic
Marking
application
shall
include
the
unique
location
Forensic
Marking
Identification
(FMID),
specified
above
and
derived
as
follows:
The
FMID
value
shall
be
derived
from
an
integrated
unique
parameter
permanently
associated
with
the
Forensic
Marking
application.
The
FMID
shall
meet
the
following
requirements:
It
shall
be
manufactured
such
that
it
cannot
be
changed
or
reprogrammed
by
any
means
whatsoever
without
violation
of
the
SPB's
type-1
perimeter.
Manufacturers
of
SPBs
containing
Forensic
Markers
shall
maintain
and
make
available
an
accurate,
timely
database
associating
each
integrated
FMID
with
its
associated
SPB
serial
number
and
digital
certificate.
Forensic
Marking
licensors
shall
ensure
the
uniqueness
of
FMIDs.
[This
Item
Left
Blank
Intentionally]
In
multiple
projection
situations
the
optically
combined
Forensic
Marks
as
projected
shall
meet
the
same
"general"
and
"survivability"
requirements
as
defined
herein
for
single
projector
applications.
Image
Forensic
Marking
is
required
to
be
visually
transparent
to
the
critical
viewer
in
butterfly
tests
for
motion
image
content.
Is
required
to
survive
video
processing
attacks,
such
as
digital-to-analog-digital
conversions
(including
multiple
D-A/A-D
conversions),
re-sampling
and
re-
quantization
(including
dithering
and
recompression)
and
common
signal
enhancements
to
image
contrast
and
color.
Is
required
to
survive
attacks,
including
resizing,
letterboxing,
aperture
control,
low-
pass
filtering
and
anti-aliasing,
brick
wall
filtering,
digital
video
noise
reduction
filtering,
frame-swapping,
compression,
scaling,
cropping,
overwriting,
the
addition
of
noise
and
other
transformations.
Is
required
to
survive
collusion,
the
combining
of
multiple
videos
in
the
attempt
to
make
a
different
fingerprint
or
to
remove
it.
Is
required
to
survive
format
conversion,
the
changing
of
frequencies
and
spatial
resolution
among,
for
example,
NTSC,
PAL
and
SECAM,
into
another
and
vice
versa.
Is
required
to
survive
horizontal
and
vertical
shifting.
Is
required
to
survive
arbitrary
scaling
(aspect
ratio
is
not
necessarily
constant).
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:
The
SM
shall
be
solely
responsible
for
control
of
FM
marking
processes
(i.e.,
“on/off”),
and,
subject
to
item
2
below,
command
and
control
of
this
function
shall
be
only
via
the
KDM
per
item
3
below.
Forensic
Marking
shall
not
be
applied
to
non-encrypted
audio
or
image
content.
If
portions
of
a
composition
are
encrypted
and
other
portions
are
not,
FM
shall
not
be
applied
to
those
Track
Files
that
are
not
encrypted.
Forensic
Marking
shall
otherwise
be
applied
to
all
encrypted
picture
and
audio
content,
except
as
follows:
The
"no
FM
mark"
and
"selective
audio
FM
mark"
state
shall
be
commanded
by
the
'ForensicMarkFlagList'
element
of
the
KDM.
When
the
KDM
'ForensicMarkFlagList'
indicates
the
"no
FM
mark"
command,
the
FM
device(s)
shall
enter
a
full
bypass
mode,
and
shall
not
alter
the
content
essence
for
the
associated
encrypted
DCP.
When
the
KDM
'ForensicMarkFlagList'
indicates
the
"selective
audio
FM
mark"
command,
the
audio
FM
device(s)
shall
not
impose,
in
the
associated
encrypted
DCP,
any
mark
onto
audio
channels
above
the
channel
indicated
in
the
command,
per
(d)
below.
This
paragraph
shall
override
(b)
above
if
both
the
"no
FM
mark"
and
"selective
audio
FM
mark"
commands
are
present.
The
"selective
audio
FM
mark"
command
shall
be
indicated
by
the
presence
of
a
ForensicMarkFlag
element
containing
a
URI
of
the
form:
http://www.dcimovies.com/430-1/2006/KDM#mrkflg-audio-disable-above-channel-XX
where
XX
is
a
value
in
the
set
{01,
02,
03,
04,
05,
06,
07,
08,
09,
10,
11,
12,
13,
14,
15,
16
.
99}
and
corresponds
to
a
channel
identifier
within
the
track,
per
382M-2007
table
E.1,
as
wrapped
in
a
Sound
Track
file
of
the
associated
encrypted
DCP.
URIs
of
this
form
shall
be
used
in
conjunction
with
keys
of
KeyType
"MDAK".
A
KDM
shall
carry
only
one
such
ForensicMarkFlag
element.
Forensic
Marking
for
OBAE
shall
not
be
“selective,”
it
is
applied
(or
not)
to
all
channels
and
objects.
When
applied,
the
forensic
mark
shall
be
recoverable
from
any
Media
Block
rendered
audio
output.
“No
FM
mark”
states
shall
be
capable
of
being
independently
commanded
for
audio
or
image
compositions.
When
commanded,
the
“no
FM
mark”
state
shall
apply
to
the
entire
encrypted
DCP.
The
“no
FM
mark”
state
shall
not
apply
to
any
other
DCP,
even
if
the
other
DCP
is
part
of
the
same
showing
(i.e.,
same
Show
Playlist).
[This
Item
Left
Blank
Intentionally]
[This
Item
Left
Blank
Intentionally]
The
SM
and
FM
Security
Entities
shall
log
the
presence
or
absence
of
image,
audio
and
Aux
Data
(AD)
Forensic
Marking
for
each
encrypted
DCP.
Notwithstanding
the
exceptions
defined
in
Section
9.4.6.2.
,
all
decrypted
audio
shall
be
forensically-marked.
A
Forensic
Mark
is
required
to
be
inserted
in
real
time
into
the
audio
content
at
the
earliest
point
after
decryption
and
prior
to
the
audio
content
data
being
present
on
any
data
bus
outside
the
Media
Block
(see
Section
9.4.6.1.
).
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,
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
D-Cinema
Operations
-
Log
Record
Format
Specification
for
D-Cinema
SMPTE
430-5
D-Cinema
Operations
-
Security
Log
Event
Class
and
Constraints
for
D-Cinema
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:
Log
Event
–
Any
event
that
has
security
implications
or
forensic
value.
Such
an
event
results
in
the
recording
of
log
data.
Log
Data
–
Security
event
information
that
is
recorded
and
stored
within
the
Media
Block
(MB),
where
such
an
event
took
place
or
was
observed.
Log
Record
–
Standardized
XML
structure
representing
a
discrete
logged
event.
Log
Report
–
Standardized
XML
structure
containing
one
or
more
log
records
spanning
a
continuous
sequence
in
time.
The
log
record
content
in
a
report
is
intended
to
be
organized
by
class,
and
may
be
filtered
prior
to
delivery
according
to
specified
criteria
(Rights
Owner,
CPL,
etc.).
Following
the
above
definitions,
a
basic
logging
process
is
described:
Surrounding
a
showing
will
be
a
number
of
security
events
that
result
in
logged
data.
Discrete
logged
event
data
shall
be
placed
in
an
XML
structure
called
a
record.
A
number
of
records
are
collected
in
sequence
and
by
class
to
make
up
log
reports.
A
complete
(unfiltered)
report
is
useful
for
transferring
entire
sets
of
log
data
for
archiving
or
post-processing
outside
of
the
security
system.
A
“filtered”
report
is
useful
for
responding
to
a
request
for
log
data
according
to
specified
bounds
(e.g.,
report
the
MB
key
usage
records
for
CPL(id)
for
specific
date(s)
and
time(s)).
Log
records
and
reports
shall
be
protected
from
undetected
alteration
(integrity
and
authentication)
or
deletion
(continuity).
Log
records
and
reports
shall
be
non-repudiable
and
traceable
back
to
the
source
MB
device
(i.e.,
where
the
logged
event
took
place).
Log
records
and
reports
shall
carry
proof
of
authenticity,
which
does
not
rely
on
the
trustworthiness
of
the
systems
and
channels
they
pass
through.
Systems
or
devices
which
communicate,
handle
or
store
log
messages
(or
records)
need
not
be
trusted
or
secure.
The
content
of
log
reports
shall
be
protected
from
exposure
to
parties
other
than
the
intended
recipient
(see
Section
9.4.6.3.6.
).
Each
Rights
Owner
shall
be
able
to
cryptographically
confirm
the
integrity
and
continuity
of
log
reports
and
their
log
data
independently
of
other
Rights
Owners
(see
Section
9.4.6.3.6.
).
[This
Item
Left
Blank
Intentionally]
MBs
shall
internally
store
at
least
twelve
(12)
months
of
typical
log
data
accumulation.
[This
Item
Left
Blank
Intentionally]
Log
records
shall
be
stored
in
non-volatile
memory
and
not
be
purgeable.
Data
shall
be
over-written
beginning
with
the
oldest
data
as
new
log
data
is
accumulated.
[This
Item
Left
Blank
Intentionally]
MBs
shall
have
an
asymmetric
identity
key
pair
and
Digital
Cinema
certificate
for
signing
log
records.
Log
records
shall
be
signed
only
by
the
Security
Manager
(SM)
providing
the
log
report(s).
MBs
shall
time
stamp
log
records,
with
date/time
synchronized
with
the
SM’s
secure
clock.
The
accuracy
of
the
time
stamp
relative
to
the
actual
event
shall
not
exceed
one
(1)
second.
Accuracy
shall
mean
the
latency
between
the
occurrence
of
the
event
and
the
indicated
time
stamp.
MBs
shall
sequence
log
records
with
a
secure
and
persistent
counter.
MB
Security
Managers
(SM)
shall
each
associate
(identify)
all
log
records
with
the
SMS
under
which
each
operates.
Log
record
and
report
formats
shall
be
compliant
with
SMPTE
430-5
D-Cinema
Operations
–
Security
Log
Event
Class
and
Constraints
for
D-Cinema.
9.4.6.3.3.
Log
Signatures
and
Integrity
Controls
🔗
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.
),
the
following
requirements
are
in
addition
to
those
in
SMPTE
430-5:
The
LogReport
element
shall
contain
the
reportingDevice
child
element
as
defined
in
SMPTE
430-4
"D-Cinema
Operations
-
Log
Record
Format
Specification".
The
reportingDevice
element
shall
be
completed
as
follows
(see
SMPTE
433
"D-Cinema
-
XML
Data
Types"):
In
the
case
that
the
DeviceIdentifier
element
contains
a
UUID,
the
DeviceCertID
element
shall
also
be
present
and
shall
contain
the
certificate
thumbprint
of
the
SM
Certificate.
In
the
case
that
the
DeviceIdentifier
element
is
a
certificate
thumbprint,
it
shall
contain
the
certificate
thumbprint
of
the
SM
Certificate.
In
either
case
the
certificate
thumbprint
of
the
Log
Signer
Certificate
shall
be
present
in
the
AdditionalID
element,
encoded
as
an
XML
Schema
ds:DigestValueType
type.
Log
records
shall
be
signed
per
the
requirements
of
SMPTE
430-5
Section
6.2.
using
the
device's
Log
Signer
Certificate.
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
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
.
Table
19
:
Security
Log
Event
Types
and
Subtypes
🔗
IMB
or
IMBO
OMB
Proj.
SPB
Playout
Event
Sub
Types
FrameSequencePlayed
X
X
CPLStart
X
X
CPLEnd
X
X
PlayoutComplete
X
X
Validation
Event
Sub
Types
CPLCheck
X
X
Key
Event
Sub
Types
KDMKeysReceived
X
X
KDMDeleted
X
X
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:
Media
Blocks
(MB)
shall
log
each
of
the
"Exception"
events
identified
in
the
EventSubType
Record
descriptions
for
the
applicable
Event
Sub
Type
records
per
Table
19
.
The
MB
shall
record
the
appropriate
Exception
record(s)
as
specified
in
the
SMPTE
430-5
EventSubType
definitions.
Recorded
Exception
token(s)
shall
include
those
that
prevent
an
EventSubType
from
occurring.
(For
example,
FrameSequencePlayed
EventSubTypes
define
Exceptions
that
prevent
playout
from
occurring.)
For
the
CPLCheck
and
KDMKeysReceived
EventSubTypes,
SMPTE
430-5
requires
certain
values
from
the
input
document
to
be
recorded
as
parameters
of
the
log
record.
In
the
case
that
an
exception
is
recorded
for
these
EventSubTypes,
syntactically
recognizable
data
items
in
the
input
document
shall
be
recorded.
(For
example,
when
a
KDMFormatError
is
recorded
because
the
KDM's
signing
certificate
has
expired
but
the
document
is
otherwise
valid,
the
KDM's
MessageId
shall
be
present
in
the
log
record.)
The
SPBSecurityAlert
Operations
EventSubType
shall
be
recorded
for
conditions
that
require
replacement
of
an
SPB
(i.e.,
equipment
tampering
or
failure)
per
Section
9.6.1.3.
.
The
AuthID
token
for
the
Playout
Event
Sub
Type
events
shall
carry
the
value
indicated
by
the
SMS
AuthorityID
per
Section
9.4.2.5.
.
Per
Section
9.4.2.6.
,
the
AuthID
token
for
the
Operations
Event
Sub
Type
events
shall
indicate
the
identity
of
the
authority
figure
responsible
for
the
event.
For
the
FrameSequencePlayed
Record
(SMPTE
ST
430-5
section
7.3.1.1),
if
the
track
file
is
an
OBAE
track
file,
the
Parameters
list
shall
contain
a
name/value
pair
whose
name
element
shall
contain
the
token
IABMark,
and
whose
Value
element
shall
contain
one
of
two
tokens,
either
"true"
or
"false",
indicating
that
a
forensic
mark
was
or
was
not
inserted
during
playout.
The
recording
of
CPLStart
and
CPLEnd
security
log
events
shall
be
triggered
by
the
first
and
last
edit
unit
of
the
CPL
representing
the
media
reproduced
by
a
given
Media
Block.
(For
an
OMB
the
first
and
last
edit
units
of
the
CPL
are
ones
representing
OBAE
media
edit
units,
since
picture
edit
units
are
not
reproduced
despite
Main
Picture
assets
being
present
in
the
CPL.)
The
secure
logging
requirements
of
this
Section
9.4.6.3.
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:
The
SMS
has
not
collected
post-show
playout
log
reports
per
Section
9.4.2.5.2.
,
There
is
any
indication
that
the
next
playback
will
not
record
and
report
log
records
as
required.
Behavior
of
SPBs
shall
be
specified
and
designed
to
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
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.
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:
Shall
be
fully
contained
within
the
Media
Block's
Type
1
SPB,
and
shall
not
be
dependent
on
or
influenced
by
any
parameter
or
value
external
to
the
SPB
Shall
not
enable
the
export
of
any
information
about
the
seed
from
the
SPB
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.
and
Section
9.8.
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.
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.
.
For
purposes
of
efficiency,
SE
types
shall
be
minimally
designated
according
the
following
roles:
IMB,
IMBO
or
OMB
-
SM
Projector
to
be
married
-
PR
Projector
permanently
married
to
an
IMB
or
IMBO
-
PR
SM
The
following
role(s)
shall
be
included
for
the
IMB,
IMBO
and
OMB,
as
applicable:
KDM-borne
Message
Integrity
Code
key
capable
MB
–
MIC
Dual
(two)
certificates
are
used
only
with
the
Image
Media
Block
(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:
Security
Manager
Certificate
(SM
Cert)
–
The
SM
Cert
shall
be
used
according
to
the
same
requirements
as
those
for
the
above
Section
9.5.1.1.
,
except
for
those
functions
specified
for
the
below
Log
Signer
Certificate.
The
SM
Cert
shall
be
the
certificate
associated
with
the
identity
of
the
Media
Block
and
shall
be
the
target
of
Key
Delivery
Messages
(KDM).
Log
Signer
Certificate
(LS
Cert)
–
The
LS
Cert
shall
be
used
to
sign
security
log
records
per
the
requirements
of
Section
9.4.6.3.3.
The
Log
Signer
Certificate
shall
enumerate
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
6.2.
.
For
dual
certificate
implementations
validation
rule
#
6
shall
be
as
stated
in
SMPTE
430-2
for
single
certificate
implementations,
except
as
follows:
SM
Cert
–
The
DigitalSignature
flag
shall
not
be
set.
LS
Cert
–
The
KeyEncipherment
flag
shall
not
be
set.
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.
.
Tamper
evident
–
Penetration
of
the
security
perimeter
results
in
permanent
alterations
to
the
equipment
that
are
apparent
upon
inspection.
This
is
the
least
robust
perimeter,
since
it
only
reveals
an
attack
after-the-fact,
and
depends
on
a
specific
inspection
activity.
Tamper
resistant
–
The
security
perimeter
is
difficult
to
penetrate
successfully.
Compromise
of
effective
tamper
resistant
designs
requires
the
attacker
to
use
extreme
care
and/or
expensive
tooling
to
expose
secrets
without
physically
destroying
them
and
the
surrounding
perimeter(s).
Tamper
detecting
and
responsive
–
The
security
perimeter
and/or
access
openings
are
actively
monitored.
Penetration
of
the
security
perimeter
triggers
erasure
of
the
protected
secrets.
Sensitive
data
critical
to
the
security
of
the
Secure
Processing
Block
(SPB)
(e.g.,
private
keys
or
content
keys)
is
generically
referred
to
as
a
Critical
Security
Parameter
(see
Section
9.5.2.6.
).
CSPs
and
plain
text
content
essence
shall
be
physically
protected
by
Secure
Silicon
and/or
Secure
Processing
Blocks
as
described
below:
Secure
Silicon
–
Sensitive
data
contained
within
a
Secure
Silicon
integrated
circuit
(IC)
can
only
be
compromised
by
a
physical
attack
on
the
IC.
All
type
1
and
type
2
Secure
Processing
Blocks
(SPB)
shall
contain
a
Secure
Silicon
IC
compliant
to
the
following
requirements:
Secure
integrated
circuits
used
for
Digital
Cinema
security
applications
shall
meet
FIPS
140-2
or
140-3
level
3
“Physical
Security”
area
requirements
as
defined
for
“single-chip
cryptographic
modules”.
(No
other
FIPS
area
requirements
are
mandated.)
SPB
private
keys
used
for
device
identity
(see
Section
9.5.1.
)
shall
not
exist
outside
of
the
Secure
Silicon
IC.
For
purposes
of
clarity,
this
means
that
(1)
private
keys
(whether
encrypted
or
not)
shall
not
be
moved
or
copied
from
Secure
Silicon,
and
(2)
the
CipherValue
element(s)
of
the
KDM’s
AuthenticatedPrivate
element
shall
be
decrypted
by
and
within
the
Secure
Silicon
IC.
Decrypted
(plain
text)
content
keys
may
be
moved
from
the
Secure
Silicon
IC
for
purposes
of
decrypting
essence
during
playout
only.
They
shall
at
all
other
times
be
contained
within
the
Secure
Silicon
IC,
or
be
stored
off-chip
in
an
encrypted
fashion
per
the
requirements
of
Section
9.7.4.
.
Secure
Processing
Block
(SPB)
Hardware
Module
–
Sensitive
data
will
only
be
exposed
by
penetration
of
a
physical
barrier,
which
surrounds
the
electronics.
All
Secure
Processing
Block
(SPB)
module
designs
shall
implement
hardware
module
perimeter
protection
that
prevents
access
to
internal
circuitry
and
detects
opening
of
the
module
perimeter.
Further
protection
of
keys
and
clear
text
content
should
use
techniques
such
as
burying
sensitive
traces,
applying
tamper
resistant
integrated
circuit
coverings,
and
tamper
responsive
circuitry.
Detailed
SPB
type
1
and
SPB
type
2
physical
protection
requirements
are
defined
below
in
Section
9.5.2.4.
and
Section
9.5.2.5.
.
Software
–
Protection
implemented
in
software
can
be
compromised
through
modifications
to
the
software,
inspection
of
memory,
or
monitoring
of
bus
signals.
Software
protection
methods
shall
not
be
used
to
protect
Critical
Security
Parameter
or
content
essence.
The
following
address
restrictions
on
repair
and
renewal
of
Secure
Processing
Blocks
(SPBs)
and
associated
cryptographic
parameters:
Type
1
SPBs
may
be
field
replaceable
(as
an
entire
SPB
module)
by
Exhibition,
but
shall
not
be
field
serviceable
(e.g.,
SPB
type
1
maintenance
access
doors
shall
not
be
open-able
in
the
field).
The
secure
silicon
device,
contained
within
a
SPB
type
2,
shall
not
be
field
serviceable,
but
may
be
field
replaceable.
It
shall
not
be
accessible
during
normal
SPB
type
2
operation
or
non-security-related
servicing.
Repair
and
renewal
processes
for
an
SPB
type
1
and
SPB
type
2
shall
be
performed
under
the
supervision
of
the
security
equipment
vendor.
Maintenance
of
the
SPB
type
2
(projector)
is
permitted
for
non-security
components
accessible
via
maintenance
openings.
All
type
1
SPBs
shall
be
issued
a
new
private/public
key
pair
and
certificate
upon
any
repair
or
renewal
process
that
requires
opening
of
the
SPB
perimeter.
(Note
that
Section
9.7.6.
precludes
maintaining
records
of
private
key
information.)
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.
requirements
are
met.
Requirements
for
firmware
changes
to
SPBs
are
given
in
Section
9.5.2.7.
.
9.5.2.4.
Specific
Requirements
for
Type
2
Secure
Processing
Blocks
🔗
The
SPB
type
2
container
has
been
defined
specifically
for
protection
of
image
essence
exiting
either
an
Image
Media
Block
(IMB)
or
IMB
with
OMB
functions
(IMBO)
(companion
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.
and
Section
9.5.2.2.
.
Specific
requirements
for
projection
systems
are
defined
in
Section
9.4.3.6.1.
.
As
explained
there,
the
type
2
SPB
–
also
referred
to
as
a
projector
SPB
-
is
permitted
to
be
opened
for
maintenance.
To
assure
adequate
protection
of
signals
and
circuits
within
the
projector
SPB,
the
following
address
physical
requirements,
and
are
in
addition
to
those
of
the
above
noted
sections:
The
projector
SPB
shall
be
designed
for
two
types
of
access:
"security
servicing"
and
"non-security
servicing."
Security
servicing
is
defined
as
having
access
to
Security-Sensitive
Signals,
which
are
the
companion
SPB's
output
image
essence
signals
or
image
signals
derived
from
said
output
signals,
or
the
projector
SPB
security
access
opening/detection
circuits
and
associated
signals.
For
non-security
servicing
(i.e.,
maintenance),
Security-Sensitive
Signals
shall
not
be
accessible
via
the
SPB's
maintenance
door
opening(s).
In
other
words,
there
shall
be
a
partition
that
separates
security-related
signals/circuits
from
non-security
related
maintenance
accessible
areas,
which
shall
serve
as
the
boundary
of
the
type
2
SPB
and
deny
access
to
Security-Sensitive
Signals,
without
causing
permanent
and
easily
visible
damage.
Security
servicing
shall
trigger
a
security
access
opening
event
per
Section
9.4.3.6.1.
,
and
be
performed
only
under
the
supervision
of
the
projector
manufacturer
per
Section
9.5.2.3.
.
The
triggering
and
clearing
(i.e.,
reset)
of
a
security
access
opening
event
shall
be
respectively
logged
as
an
"SPBOpen"
and
"SPBClose"
security
log,
per
Section
9.4.6.3.8.
.
Projector
SPB
access
doors
or
panels
shall
be
lockable
using
mechanical
locks
employing
physical
or
logical
keys,
and
shall
be
protected
with
tamper-evident
seals
(e.g.,
evidence
tape
or
holographic
seals).
Alternatively,
projector
SPB
access
doors
or
panels
shall
be
lockable
using
pick
resistant
locks
employing
physical
or
logical
keys.
Protection
from
external
probing
of
Security-Sensitive
Signals
shall
be
provided
by
assuring
barriers
exist
to
prevent
access
to
such
signals
via
ventilation
holes
or
other
openings.
In
summary,
the
projector
SPB
physical
perimeter
provides
for
unencumbered
maintenance
access,
and
security-critical
signals
are
protected
via
security
access
opening
door
locks
and
opening
detection.
Exhibition
visual
inspection
is
relied
upon
to
detect
physical
abuse
that
might
allow
compromise
of,
or
access
to,
decrypted
image
essence.
A
direct
view
display
system
is
defined
as
a
light
emission
display
comprised
of
a
combination
of
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:
Screen
:
The
complete
direct
view
cinema
display
system
including
all
Pixels
sufficient
to
display
the
entire
image,
and
typically
comprised
of
a
plurality
of
Cabinets
with
a
supporting
structure,
associated
electronics
and
cabling.
Cabinet
:
The
physical
structure
and
associated
electronics
which
contains
a
portion
of
the
image
area
of
a
Screen.
The
emissive
surface
area
of
a
Cabinet
is
typically
comprised
of
a
plurality
of
Modules.
Module
:
A
component
including
an
array
of
Pixels
physically
positioned
so
as
to
form
a
portion
of
the
front
display
surface
of
a
Cabinet.
The
Module
is
typically
the
smallest
field-serviceable
light-emitting
component
of
a
Screen.
Display
Pixel
:
The
smallest
grouping
of
light
emitting
elements
within
a
Module,
and
capable
of
broad-spectrum
(not
monochromatic)
light
emissions.
A
Display
Pixel
(or
Pixel
herein)
is
often
comprised
of
a
triplet
of
red,
green
and
blue
light
emitting
diodes.
The
physical
characteristics
of
a
direct
view
display
require
that
the
front
Screen
area
comprise
part
of
the
display's
type
2
SPB
physical
perimeter.
This
may
prevent
it
from
meeting
the
"hard,
opaque
physical
security
perimeter"
requirements
of
Section
9.4.2.2.
,
and/or
the
"SPB
hardware
module"
requirements
of
Section
9.5.2.2.
.
The
following
defines
type
2
SPB
accommodations
for
direct
view
displays.
Security
servicing
and
non-security
servicing
definitions
for
direct
view
display
systems
apply
as
follows
:
Security
servicing
-
Opening
or
removal
of
a
Cabinet
or
Module
that
compromises
the
type
2
SPB
security
perimeter
and
exposes
Security-Sensitive
Signals.
Such
opening
or
removal
shall
trigger
a
security
access
opening
event.
(It
is
permitted
for
one
security
access
opening
event
to
reflect
the
occurrence
of
simultaneous
opening
or
removal
of
a
plurality
of
Cabinets
and/or
Modules
as
part
of
a
single
servicing
event.)
Non-security
servicing
-
The
opening
of
a
Cabinet
or
Module
that
does
not
expose
Security-Sensitive
Signals.
For
Cabinets
having
front
removable
Modules:
The
removal
of
a
Module
shall
expose
only
those
Pixel
signals
accessible
via
the
electrical
connection(s)
associated
with
the
Module
removed,
but
shall
not
otherwise
expose
Security-Sensitive
Signals
or
compromise
the
type
2
SPB
perimeter.
The
removal
of
any
Module
shall
be
detected
and
prevent
playout
of
an
encrypted
composition.
The
removal
of
more
than
fifteen
(15)
Modules,
or
a
Module
quantity
that
exposes
Pixel
signals
constituting
more
than
5%
of
the
screen
area,
whichever
is
less,
within
any
eight
hour
period,
shall
trigger
a
security
access
opening
event.
Once
triggered,
to
clear
(i.e.,
reset)
a
security
access
opening
event
shall
require:
Remedy
of
the
cause
of
the
event
(i.e.,
closure
of
the
security
access
door
or
panel,
replacement/
reassembly
of
the
Cabinet(s)
and/or
Module(s),
etc.),
and
The
supervision
of
the
manufacturer
in
the
use
of
a
physical
key
and/or
logical
code.
For
purposes
of
clarity,
a
security
access
opening
event
shall
remain
active
pending
the
above
closure
requirements,
and
such
event
shall
be
bookended
by
SPBOpen
and
SPBClose
security
log
records.
The
following
requirements
apply
to
a
fully
assembled
direct
view
display
system:
The
physical
intrusion
barrier
presented
by
the
light
emitting
front
surface
of
Cabinets
or
Modules
shall
not
be
able
to
be
penetrated
without
permanently
destroying
the
proper
operation
of
a
Cabinet
and/or
Module
so
penetrated,
and
leaving
permanent
and
easily
visible
damage.
Cabinets
and/or
Modules
shall
be
mechanically
interlocked
to
each
other
directly
and/or
via
the
supporting
frame
structure
such
that
any
separation
that
would
enable
access
to
internal
signals
will
cause
permanent
and
easily
visible
damage.
Any
access
to
light
emitting
(Pixel
generating)
component
electrical
signals
from
the
surface
of
the
Screen
shall
be
limited
to
individual
component
pins,
and
there
shall
be
no
access
to
signals
that
would
constitute
a
portion
of
the
picture
image
beyond
the
Pixel
by
Pixel
level.
All
other
projector
and
projector
SPB
requirements
of
this
specification
shall
remain
in
place.
In
summary,
security
objectives
for
a
direct
view
display
Secure
Processing
Block
(SPB)
are
fundamentally
the
same
as
for
projectors.
To
avoid
influencing
electro-mechanical
designs,
the
requirements
of
this
specification
are
focused
on
access
to
Security-Sensitive
Signals
for
direct
view
display
systems,
rather
than
specific
requirements
for
the
type
2
SPB
physical
boundary
itself.
9.5.2.5.
FIPS
140
Requirements
for
Type
1
Secure
Processing
Blocks
🔗
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.
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:
Type
1
SPBs
shall
be
FIPS
140
certified
to
a
security
“Level
3,”
subject
to
the
additional
requirements
or
exceptions
as
noted
for
FIPS
140-3
and
FIPS
140-2
in
Section
9.5.2.5.1.
and
Section
9.5.2.5.2.
below.
Type
1
SPBs
shall
provide
physical
and
logical
protection
of
their
security
parameters
and
functions
24/7
and
shall
be
able
to
respond
to
attacks
under
both
powered
and
un-powered
conditions.
By
way
of
example,
if
a
type
1
SPB
is
in
storage
and
relying
upon
a
battery
for
tamper
detection
and
response,
it
shall
zeroize
its
Critical
Security
Parameters
(CSPs)
prior
to
a
battery
depletion
condition
which
would
not
support
proper
tamper
detection
and/or
response.
Type
1
SPB
suppliers
shall
at
all
times
ensure
that
their
published
FIPS
Security
Policy
document(s)
accurately
reflect
the
current
state
of
the
SPB
design
and
functionality.
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.
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.
Roles,
services
and
authentication
7.4.2
A
Maintenance
Role
shall
not
be
permitted.
7.4.3.3
An
SPB-1
may
support
“self-initiated
cryptographic
output
capability”
provided
that
a
User
Role
and/or
Crypto
Officer
Role
shall
be
required
to
support
the
AuthorityID
per
Section
9.4.2.5.
.
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.
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:
Area
1
–
Cryptographic
Module
Specification
shall
only
be
required
to
meet
Security
Level
2
requirements.
Area
6
–
The
software/firmware
operating
environment
of
Secure
Processing
Blocks
(SPBs)
shall
be
restricted
to
the
Limited
or
Non-Modifiable
Operational
Environment.
Area
8
–
Secure
Processing
Blocks
(SPBs)
shall
only
be
required
to
meet
Security
Level
2
business
use
A
FCC
class
requirements.
Area
10
–
Design
Assurance
requirements
may
meet
Security
Level
2
requirements.
Area
1
and
Area
11
–
Vendor-specified
Security
Policy
specifications
shall
be
in
alignment
with
and
fully
support
the
requirements
of
this
Digital
Cinema
specification,
in
addition
to
vendor-specific
policies.
9.5.2.6.
Critical
Security
Parameters
and
D-Cinema
Security
Parameters
🔗
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.
Device
Private
Keys
–
RSA
private
key
that
devices
use
to
prove
their
identity
and
facilitate
secure
Transport
Layer
Security
(TLS)
communications.
Content
Encryption
Keys
–
KDM
AES
keys
that
protect
content.
Content
Integrity
Keys
–
HMAC-SHA-1
keys
that
protect
the
integrity
of
compressed
content
(integrity
pack
check
parameters).
[This
Item
Left
Blank
Intentionally]
[This
Item
Left
Blank
Intentionally]
[This
Item
Left
Blank
Intentionally]
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.
).
Watermarking
or
Fingerprinting
command
and
control
–
Any
of
the
parameters
or
keys
used
in
a
particular
Forensic
Marking
process.
Logged
Data
–
All
log
event
data
and
associated
parameters
constituting
a
log
record
or
report.
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:
Be
designed
such
that
their
firmware
cannot
be
modified
without
the
knowledge
and
permission
of
the
original
manufacturer.
Require
a
Digital
Cinema
compliant
certificate
that
authenticates
and
confirms
the
identity
of
the
authority
figure
responsible
for
making
a
firmware
change,
and
shall
include
time/date
and
version
number
information
associated
with
any
firmware
change,
in
addition
to
the
authority
figure.
Not
undergo
firmware
changes
without
informing
potentially
affected
information
bases
that
support
Digital
Cinema
equipment
operations
(e.g.,
databases
used
by
stakeholders
for
facility
lists,
KDM
and
TDL
creation),
and
the
owner
of
the
device.
Follow
FIPS
140-2
certification
body
change
notification
requirements
regarding
modifications
to
security
devices.
Undergo
re-certification
if
required.
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:
Theater
networks
shall
protect
security
system(s)
from
the
threat
of
external
and
internal
network-borne
attacks
by
the
use
of
appropriate
firewalls.
At
a
minimum,
each
auditorium
shall
have
such
firewall
protection
for
any
communications
interface(s)
connecting
to
the
intra-auditorium
security
related
communications
network.
The
portions
of
the
theater
network
used
to
carry
content
or
Operational
Messages
shall
be
logically
or
physically
separated
from
any
wireless
network
device.
At
a
minimum,
a
properly
configured
firewall
shall
separate
the
wired
network
that
carries
content
or
Operational
Messages
from
any
wireless
network
operated
at
the
same
facility.
The
network
cabling
or
cabling
trough
should
not
be
publicly
accessible
on
the
premises.
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
two
types
of
components
involved
in
Digital
Rights
Management
(DRM):
Screen
Management
System
(SMS)
Security
Manager(s)
(SM)
contained
within
Media
Blocks
(MB)
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:
Wrong
date
and
time
(outside
the
engagement
window)
(see
Table
21
)
Unauthorized
device
(equipment
is
not
accepted
by
the
content
owner)
(see
Table
21
)
Failure
of
or
tampering
with
security
equipment
(see
Table
22
)
Compliance
to
security
system
logging
requirements
ensures
that
all
events
having
security
implications
will
generate
associated
log
records
that
are
stored
in
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.
Security
system
components
(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
and
Table
22
).
9.6.1.1.
Digital
Rights
Management:
Screen
Management
System
🔗
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.
9.6.1.2.
Digital
Rights
Management:
Security
Manager
(SM)
🔗
The
Security
Manager
is
the
executor
of
Digital
Rights
Management
for
the
Media
Block
that
contains
it.
Security
Managers
control
use
of
content
keys
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.
),
the
Security
Manager
exercises
no
control
over
playback,
other
than
use
of
content
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.
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
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.
9.6.1.3.
Digital
Rights
Management:
Security
Equipment
🔗
Security
equipment
(Media
Block
or
projector)
must
perform
to
specified
standards
and
function
as
designed.
The
Security
Manager
will
continuously
monitor
for
proper
security
equipment
operation
and
physical
integrity
(tampering).
Content
playback
is
restricted
to
passing
all
security
requirements
at
all
times
.
Table
22
:
Examples
of
Failure
or
Tampering
of
Security
Equipment
🔗
Item,
Observation
or
Issue
Approach
Security
equipment
tampering
or
failure
A
tampered
or
failed
device
is
non-functional
until
replaced
Broken
or
compromised
MB-projector
marriage
connection
Marriage
integrity
is
required
to
initiate
or
continue
playback
The
above
table
depicts
tampering
or
failure
of
security
equipment.
Security
equipment
that
has
been
tampered
with
or
is
malfunctioning
(row
1)
shall
not
continue
operation
and
must
be
replaced
before
playback
can
commence
(or
continue).
An
example
of
malfunctioning
security
equipment
is
a
Media
Block
that
no
longer
performs
one
of
its
security
functions
(e.g.,
decryption,
Forensic
Marking,
logging).
Similarly,
the
SM
shall
prohibit
playout
if
the
MB-projector
marriage
is
broken
or
become
compromised
(row
2).
9.6.2.
“Trust”
and
the
Trusted
Device
List
(TDL)
🔗
The
information
previously
contained
in
this
section
has
been
deleted
as
redundant
or
relocated
as
needed
to
other
sections
of
this
specification.
Table
23
:
[This
Table
Left
Blank
Intentionally]
🔗
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.
,
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.
,
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.
.
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.
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.
9.8.
Digital
Certificate,
Extra-Theater
Messages
(ETM),
and
Key
Delivery
Messages
(KDM)
Requirements
🔗
The
following
Society
of
Motion
Picture
and
Television
Engineers
(SMPTE)
published
standards
shall
be
utilized:
10.2.1.
Single
Inventory
of
Stereoscopic
Digital
Cinema
Packages
(DCP)
🔗
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.
10.2.3.
Dual
Link
Image
Format
for
Stereoscopic
DCPs
🔗
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.
Audio
Engineering
Society
-
Recommended
Practice
for
Digital
Audio
Engineering
Serial
transmission
format
for
two-channel
linearly
represented
digital
audio
data
ANSI
Acronym
for
American
National
Standards
Institute
Answer
Print
A
color-corrected
film
print
made
directly
from
the
cut
film
negative.
It
is
also
the
culmination
of
the
creative
color
timing
process,
where
final
creative
approval
is
granted
before
the
film
is
duplicated
for
release
API
Acronym
for
Application
Programming
Interface
BER
Acronym
for
Basic
Encoding
Rules
Broadcast
Wave
Digital
Audio
file
format
developed
and
standardized
by
the
EBU
(European
Broadcast
Union,
a
standardization
organization)
Burned-In
Where
visual
data
that
is
normally
supplemental
to
a
motion
picture
is
irrevocably
added
to
the
motion-picture
image
by
compositing
the
data
with
the
underlying
image
Captions
Text
that
is
a
representation,
often
in
the
same
language,
of
dialog
and
audio
events
occurring
during
scenes
of
a
motion
picture.
(Generally
associated
with
a
dialog
and
audio
event
translation
for
the
deaf
and
hard
of
hearing.)
CBC
Acronym
for
Cipher
Block
Chaining
mode
CBR
Acronym
for
Constant
Bit
Rate
for
image
compression
Central
Storage
A
central
location
where
the
packaged
Digital
Cinema
content
is
stored
for
a
multiple
screen
installation
Chunk
A
section
of
a
PNG
file.
Each
chunk
has
a
type
indicated
by
its
chunk
type
name.
Most
types
of
chunks
also
include
some
data.
The
format
and
meaning
of
the
data
within
the
chunk
are
determined
by
the
name.
CIE
Acronym
for
International
Commission
on
Illumination
(Commission
Internationale
de
l’Eclairage)
Closed
Referring
to
visual
data
that
is
supplemental
to
a
motion
picture
being
displayed
off-screen
COC
Acronym
for
Coding
style
Component
–
see
JPEG
2000
specification
[ISO/IEC
15444-1]
COD
Acronym
for
Coding
style
Default
–
see
JPEG
2000
specification
[ISO/IEC
15444-1]
Composition
A
motion
picture,
or
a
trailer,
or
an
advertisement,
etc.
Composition
consists
of
a
metadata
Composition
Playlist
along
with
the
essence
and
other
metadata
track
files
that
define
the
work.
Container
Level
Metadata
that
indicates
the
size
of
the
image/structure
container
and
the
frame
rate
of
the
images
–
this
does
not
indicate
the
image
structure
or
resolution
Content
The
digital
representation
of
a
visual,
audio
or
subtitled
program.
Content
exists
in
several
forms
(encrypted/plaintext,
compressed/uncompressed,
etc.)
at
various
stages
of
the
process
in
the
Digital
Cinema
system.
CPL
Acronym
for
Composition
Playlist,
the
definitive
Playlist
for
specifying
how
a
Composition
is
played
and
what
track
files
are
required
CPRL
Acronym
for
Component
Position
Resolution
Layer
–
see
JPEG
2000
specification
[ISO/IEC
15444-1]
CSP
Acronym
for
Critical
Security
Parameter
D/HOH
Acronym
for
Deaf
and
Hard
Of
Hearing
DCDM
Acronym
for
Digital
Cinema
Distribution
Master.
A
master
set
of
files
that
have
not
been
compressed,
encrypted,
or
packaged
for
Digital
Cinema
distribution.
The
DCDM
contains
essentially
all
of
the
elements
required
to
provide
a
Digital
Cinema
(DC)
presentation.
DCDM*
Acronym
for
Digital
Cinema
Distribution
Master*.
When
the
DCP
is
unpackaged,
decrypted
and
decompressed,
it
is
referred
to
as
the
DCDM*.
The
DCDM*
is
visually
indistinguishable
from
the
original
DCDM.
DCI
Acronym
for
Digital
Cinema
Initiatives,
LLC
DCP
Acronym
for
a
Digital
Cinema
Package.
The
standardized
form
of
content
files
intended
for
delivery
to
theatrical
exhibition
facilities.
DCP
content
components
are
selectively
encrypted
at
the
discretion
of
the
Rights
Owner.
DER
Acronym
for
Distinguished
Encoding
Rules
DES
Acronym
for
Data
Encryption
Standard.
DES
was
adopted
as
a
federal
standard
in
1976
[FIPS
(46-3)]
and
[ANSI
standard
X9.32]
Distribution
Package
The
collection
of
files
delivered
by
the
distributor
to
the
exhibitor.
A
Distribution
Package
may
contain
pieces
of
a
Composition
or
several
compositions,
a
complete
Composition,
replacement/update
files,
etc.
DM
Acronym
for
Descriptive
Metadata
DRM
Acronym
for
Digital
Rights
Management
DSM
Acronym
for
Digital
Source
Master,
a
digital
master
created
in
post-production
from
which
different
versions
and
duplication
masters
may
be
created.
e.g.
Abbreviation
for
the
Latin
phrase
exempli
gratia,
meaning
“for
example”
End
Credits
A
credit
sequence
generally
shown
at
the
end
of
a
motion
picture
Essence
Image,
audio,
subtitles,
or
any
content
that
is
presented
to
a
human
being
in
a
presentation
ETM
Acronym
for
Extra-Theater
Message.
One-way
information
packet
that
passes
into
or
out
of,
the
exhibition
facility.
The
ETM
is
a
generic
message
container.
Event
Playlist
A
playlist
of
Compositions,
describing
an
assembly
of
Compositions
in
sequence.
An
Event
Playlist
is
typically
created
by
a
content
distributor
and
transferred
to
exhibition.
Fingerprint
Dynamic
playback
or
distribution
watermark
FIPS
Acronym
for
Federal
Information
Processing
Standards
FM
Context-driven
acronym
for
Forensic
Mark,
Forensic
Marking,
Forensic
Marker.
FMID
Acronym
for
Forensic
Marking
Identification.
The
FMID
is
a
unique
fixed
identifier
of
the
specific
instance
of
the
Forensic
Marking
application.
Forensic
Mark
Data
embedded
in
essence
to
provide
forensic
tracking
information
in
the
event
of
content
theft.
Such
marking
can
be
visible
or
non-visible,
audible
or
non-audible.
FPS
Acronym
for
Frames
Per
Second
Generic
Forensic
Mark
Inserter
In
this
architecture,
metadata
is
first
created
at
authoring
that
contains:
1)
locations
within
the
title
where
forensic
marking
may
be
inserted,
and
2)
commands
that
set
the
type
of
steganographic
marking
to
be
used
to
encode
the
actual
forensic
information.
In
the
theater,
at
the
time
of
playback,
the
metadata
is
used
to
instruct
the
inserter
in
the
Media
Block
how,
where,
and
when
the
required
information
will
be
hidden
within
the
sound
and/or
picture.
GPIO
Acronym
for
General
Purpose
Input
or
Output
GUI
Acronym
for
Graphical
User
Interface
HMAC
Acronym
for
Hashing
Message
Authentication
Codes
HVS
Acronym
for
the
Human
Visual
System
Hz
Abbreviation
for
Hertz,
a
unit
of
frequency
expressed
in
cycles
per
second
IANA
Acronym
for
Internet
Assigned
Numbers
Authority
i.e.
Abbreviation
for
the
Latin
phrase
id
est,
meaning
“that
is”
ICT
Acronym
for
Irreversible
Color
Transformation
–
see
JPEG
2000
specification[ISO/IEC
15444-1]
IEC
Acronym
for
International
Electrotechnical
Commission
IETF
Acronym
for
Internet
Engineering
Task
Force
IMB
Acronym
for
Image
Media
Block
IMBO
Acronym
for
IMB
with
OMB
functions
IP
Acronym
for
Intellectual
Property
ISAN
Acronym
for
International
Standards
Audiovisual
Number
ISO
Acronym
for
International
Organization
for
Standardization
ITM
Acronym
for
Intra-Theater
Message.
ITMs
are
Operational
Messages
communicated
via
one
or
more
bidirectional
internal
theater
networks.
JPEG
Acronym
for
Joint
Photographic
Experts
Group,
the
international
body
that
developed
the
JPEG
2000
standard
KDM
Acronym
for
Key
Delivery
Message.
The
Extra
Theater
Message
(ETM)
for
delivering
content
keys
and
Trusted
Device
List
(TDL)
to
exhibition
locations.
KEK
Acronym
for
Key-Encrypting
Key
Key
Electronic
data
used
to
allow
data
encryption
and
decryption
Key
Epoch
The
period
of
time
during
which
a
given
decryption
key
is
valid.
The
key
epoch
defines
a
minimum
practical
time
period
for
use
of
encrypted
track
files.
kHz
Acronym
for
kilo
Hertz,
one
thousand
cycles
per
second,
a
measure
of
frequency
KLV
Acronym
for
Key
Length
Value
–
used
by
the
MXF
to
parse
binary
data
LED
Acronym
for
Light
Emitting
Diode
Local
Storage
A
storage
device
that
is
associated
with
an
individual
playback
device
Localizations
Text
on
screen
representing
either
non-source
language
dialog
or
information
pertinent
to
the
story
such
as
time
and
place.
This
is
specifically
the
text
that
is
absent
in
text-less
masters.
This
text
is
localized
or
translated
for
various
markets
either
through
subtitles
or
entire
image
replacement.
Log
Data
The
data
produced
and
stored
as
a
result
of
security
system
activity.
LTC
Acronym
for
Linear
Time
Code
Main
Titles
A
credit
sequence
generally
shown
near
the
beginning
of
a
motion
picture
MB
Acronym
for
Media
Block.
A
type
of
Secure
Processing
Block
that
contains
a
Security
Manager
and
performs
media
decryption.
This
specification
defines
the
Image
Media
Block
(IMB),
Image
Media
Block
with
OMB
Functions
(IMBO),
and
the
Outboard
Media
Block
(OMB).
MD
Acronym
for
Media
Decryptor,
the
device
located
in
the
Media
Block
that
decrypts
the
compressed
content.
ME
Acronym
for
Media
Encryptor
Metadata
Data
about
data
or
data
describing
other
data.
Information
that
is
considered
ancillary
to
or
otherwise
directly
complementary
to
essence.
Information
that
is
useful
or
of
value
when
associated
with
the
essence
being
provided.
MMB
Acronym
for
Multiple
Media
Block.
Refers
to
a
projection
booth
configuration
containing
more
than
one
Media
Block.
MMB-Capable
IMB
An
IMB
that
is
able
to
operate
as
a
“source”
or
“sink”
of
synchronization
signals.
An
MMB-Capable
IMB
is
further
distinguished
from
a
standard
IMB
by
its
capability
to
support
playout
of
a
subset
of
content
that
is
specified
in
the
CPL,
for
example,
image
and
subtitle
content,
but
not
OBAE.
MMB-Capable
IMBO
An
IMBO
that
is
able
to
operate
as
a
“source”
or
“sink”
of
synchronization
signals.
MMB-Capable
SMS
An
SMS
that
is
able
to
support
MMB
projection
booth
configurations.
MTBF
Acronym
for
Mean
Time
Between
Failure
MXF
Acronym
for
Material
eXchange
Format
NIST
Acronym
for
National
Institute
of
Standards
and
Technology
NSA
Acronym
for
National
Security
Agency
NTSC
Acronym
for
National
Television
System
Committee,
which
developed
the
NTSC
television
broadcasting
standard
OAEP
Acronym
for
Optimal
Asymmetric
Encryption
Padding
Open
Referring
to
visual
data
that
is
supplemental
to
a
motion
picture
being
displayed
on-screen
Operational
Message
The
class
of
ITM
messages
for
control
and
status
communications
between
the
SMS
and
Media
Blocks
Operational
Pattern
An
MXF
construct
to
define
file
structures
Packing
List
A
list
describing
the
files
and
providing
a
means
for
authentication
of
the
files
as
delivered
in
a
package
PAL
Acronym
for
Phase
Alternation
by
Line,
a
television
broadcasting
standard.
Perceptual
Coding
Exploiting
limitations
in
the
HVS
for
data
compression
Playlist
Conceptually,
the
format
and
structure
of
the
various
lists
used
to
define
the
playback
of
content
in
Digital
Cinema
PNG
Acronym
for
Portable
Network
Graphics,
an
extensible
file
format
for
the
lossless,
portable,
well-compressed
storage
of
raster
images
defined
by
the
PNG
Development
Group.
POC
Acronym
for
Progression
Order
Change
–
see
JPEG
2000
specification
[ISO/IEC
15444-1]
PPM
Acronym
for
Packed
Packet
headers,
Main
header
–
see
JPEG
2000
specification
[ISO/IEC
15444-1]
PPT
Acronym
for
Packed
Packet
headers,
Title-part
header
–
see
JPEG
2000
specification
[ISO/IEC
15444-1]
QCC
Acronym
for
Quantization
Component
–
see
JPEG
2000
specification
[ISO/IEC
15444-1]
QCD
Acronym
for
Quantization
Default
–
see
JPEG
2000
specification
[ISO/IEC
15444-1]
RAID
Acronym
for
Redundant
Array
of
Inexpensive
Disks
RAND
Acronym
for
reasonable
and
nondiscriminatory
Reel
A
conceptual
period
of
time
having
a
specific
duration.
A
Reel
is
associated
with
track
files.
From
a
temporal
view,
the
files
making
up
a
Reel
are
in
parallel
and
are
to
be
synchronized
in
their
playback.
Renewable
A
software
component
is
renewable
if
it
can
be
remotely,
smoothly
and
possibly
automatically
upgraded
or
replaced
without
significantly
disturbing
system
operations.
A
system
shutdown
and
normal
restart
is
acceptable,
provided
that
after
the
restart,
the
system
can
be
operated
as
before.
Replaceable
A
component
is
said
to
be
replaceable
if
it
can
be
upgraded
or
replaced
without
significantly
disturbing
system
operations.
A
system
shutdown
and
restart
is
acceptable,
provided
that
after
the
replacement,
the
system
can
be
operated
as
before.
RFC
Acronym
for
Request
For
Comments
RGN
Acronym
for
Region
of
Interest
–
see
JPEG
2000
specification
[ISO/IEC
15444-1]
Rights
Owner
The
generic
term
used
to
describe
the
party
having
authority
over
content
to
negotiate
terms
of
engagements
(e.g.,
a
studio
or
distributor).
ROM
Acronym
for
Read
Only
Memory
RRP
Acronym
for
Request
Response
Pairs
SE
Acronym
for
Security
Entity
(not
to
be
confused
with
secure
entity).
A
logical
processing
device
that
executes
a
distinct
security
process
or
function.
SEs
are
not
distinguished
from
other
theater
equipment
by
being
physically
secure,
but
by
the
specific
security
function
that
they
perform.
SECAM
Acronym
for
System
Electronique
Couleur
Avec
Memoire,
a
television
broadcasting
standard
Security
Data
The
keys
and
associated
parameters
required
for
access
to
content,
and
managed
by
Security
Managers.
Security
Interface
A
standardized
point
of
interoperability
for
security
messaging.
Security
Management
The
process
of
securely
distributing,
storing
and
utilizing
Security
Data
in
order
to
access
content.
Security
Manager
The
Security
Entity
(SE)
that
is
entrusted
to
control
Security
Data
according
to
the
policies
defined
in
this
specification.
There
is
one
SM
within
each
MB.
SHA1
Acronym
for
Secure
Hashing
Algorithm
1
Show
The
presentation
that
the
audience
sees
and
hears
in
the
theater
auditorium.
Show
Playlist
A
Playlist
of
Composition
Playlists
and
Event
Playlists,
describing
a
sequence
that
occurs
at
a
particular
screen.
A
Show
Playlist
is
typically
created
by
exhibition
and
transferred
to
the
equipment
controlling
a
particular
screen.
SM
Acronym
for
Security
Manager
SMD
Acronym
for
Subtitle
Media
Block
SMPTE
Acronym
for
Society
of
Motion
Picture
and
Television
Engineers
SMS
Acronym
for
Screen
Management
System.
A
(non-secure)
Security
Entity
(SE)
that
directs
security
functions
for
a
single
auditorium
on
behalf
of
exhibition
management.
SNMP/UDP/IP
Acronym
for
Simple
Network
Management
Protocol
Over
User
Datagram
Protocol
Over
Internet
Protocol
SPB
Acronym
for
Secure
Processing
Block.
A
Security
Entity
(SE)
which
provides
a
physical
and
logical
protection
perimeter
around
other
SEs.
SPL
Acronym
for
Show
Playlist
Stakeholder
A
party
involved
in
a
business
agreement
relating
to
distribution
and
exhibition
of
specific
Content.
Subpicture
A
multiple-image
file
format
for
the
transport
of
visual
data
supplemental
to
a
motion
picture
that
is
intended
only
for
graphic
overlay
with
the
main
image
output
of
a
digital
projector
Subtitle
Text
that
is
a
representation,
in
a
different
language,
of
dialog
occurring
during
scenes
of
a
motion
picture.
Generally
associated
with
dialog
translation
for
localization
of
a
motion
picture
in
a
particular
territory.
TCP/IP
Acronym
for
Transmission
Control
Protocol
/
Internet
Protocol
TDES
or
3DES
Acronym
for
Triple
Data
Encryption
Standard.
TDES
or
3DES
was
adopted
as
a
federal
standard
in
1998
[FIPS
(46-3)]
and
[ANSI
standard
X9.32]
TDL
Acronym
for
Trusted
Device
List.
Refers
to
the
list
within
a
KDM
that
enumerates
those
devices
under
the
control
of
an
auditorium's
Security
Manager
(SM)
that
are
trusted
by
the
issuer
of
the
KDM.
(TDL
is
sometimes
incorrectly
used
to
refer
to
those
items
within
a
database
that
enumerate
the
various
subsystems
of
a
given
auditorium's
installation.)
Timed
Text
Render
text
data
onto
a
graphics
overlay
with
the
main
image
output
of
a
digital
projector
TLM
Tile-part
Length,
Main
Header–
see
JPEG
2000
Specification
[ISO/IEC
15444-1]
TLS
Acronym
for
Transport
Layer
Security
TMS
Acronym
for
Theater
Management
System
Track
File
The
smallest
element
of
a
package
that
can
be
managed
or
replaced
as
a
distinct
asset.
A
track
file
may
contain
essence
and/or
metadata,
and
its
duration
matches
an
associated
Reel.
UDP
Acronym
for
User
Datagram
Protocol
UL
Acronym
for
Universal
Label
used
in
MXF
Unicode™
The
Universal
Multiple-Octet
Coded
Character
set,
the
[ISO/IEC
10646:2003]
standard
that
defines
a
single
code
for
representation,
interchange,
processing,
storage,
entry
and
presentation
of
the
written
form
of
the
world’s
major
languages
urn
Acronym
for
uniform
resource
name
USB
Acronym
for
Universal
Serial
Bus,
standardized
serial
communications
connection
found
on
computers
UTC
Acronym
for
Universal
Coordinated
Time
UUID
Acronym
for
Universal
Unique
IDentifier
Visually
Lossless
An
image
compression
method
is
considered
visually
lossless
when
the
processed
image
is
indistinguishable
from
the
unprocessed
image
under
normal
theatrical
viewing
conditions.
VPN
Acronym
for
Virtual
Private
Network.
VBR
Acronym
for
Variable
Bit
Rate
W3C
Acronym
for
The
World
Wide
Web
Consortium,
the
organization
responsible
for
the
development
of
Internet
protocols
WWV
Callsign
of
NIST’s
shortwave
radio
station
in
Fort
Collins,
Colorado.
WWV’s
main
function
is
the
continuous
dissemination
of
official
United
States
government
time
signals
XML
Acronym
for
eXtensible
Markup
Language
X’Y’Z’
Tristimulus
values
defined
by
CIE
in
1931
to
represent
colors.
Prime
indicates
gamma
corrected
coordinates.
1
Fox
withdrew
as
a
member
of
DCI
in
March
2019,
as
a
consequence
of
its
merger
with
Disney.
Metro-Goldwyn-Mayer
withdrew
as
a
Member
of
DCI
in
May
2005,
prior
to
the
completion
of
this
Specification.
2
The
specifications
and
performance
requirements
for
each
of
these
components
will
be
described
in
the
subsequent
sections.
3
The
DCP
arrives
at
the
theater,
it
is
unpackaged,
decrypted
and
decompressed
to
create
the
DCDM*,
where
DCDM*
is
visually
indistinguishable
from
the
original
DCDM
(where
the
original
DCDM
is
the
input
to
the
Digital
Cinema
Mastering
Process.
4
[This
Endnote
Left
Blank
Intentionally]
5
The
double-lined
boxes
of
Figure
12
show
those
processing
functions
required
to
take
place
within
physically
secure
SPB
type
1
perimeters.
6
[This
Endnote
Left
Blank
Intentionally]
7
[This
Endnote
Left
Blank
Intentionally]
8
“Non-field
serviceable”
means
not
serviceable
by
other
than
the
equipment
vendor
or
his
authorized
and
supervised
service
repair
depot
(see
Section
9.5.2.3.
).
9
[This
Endnote
Left
Blank
Intentionally]
10
[This
Endnote
Left
Blank
Intentionally]
11
In
Section
7.
Media
Blocks
are
also
discussed.
The
terminology
used
there
is
not
strictly
security
focused,
because
other
important
equipment
requirements
such
as
storage
and
server
functions
are
discussed.
Depending
upon
a
particular
design,
server
functions
may
well
be
part
of
what
is
in
a
MB,
when
viewed
in
its
entirety.
Since
other
such
functions
are
invisible
to
security,
they
need
not
be
discussed
within
the
security
arena,
and
are
not
addressed
in
this
security
chapter.
12
The
specific
operational
policies
used
at
exhibition
that
surround
operator
identification,
empowerment
or
enforcement
are
outside
the
scope
of
this
specification.
13
As
used
above
and
elsewhere
in
these
specifications,
the
term
purge
shall
mean
the
data
is
permanently
erased
or
overwritten
such
that
it
is
unusable
and
irrecoverable
(also
known
as
“zeroization”
in
FIPS
140-2).
14
A
limited-magnitude
adjustable
time
offset
to
this
clock
is
described
in
the
subsequent
point.
15
[This
Endnote
Left
Blank
Intentionally]
16
[This
Endnote
Left
Blank
Intentionally]
17
[This
Endnote
Left
Blank
Intentionally]
18
See
https://csrc.nist.gov/publications/
19
[This
Endnote
Left
Blank
Intentionally]
20
The
terms
software
or
firmware
shall
mean
all
operating
system
and/or
embedded
executable
code
within
an
SPB,
and
this
specification
does
not
otherwise
distinguish
between
software,
firmware
or
ROM
based
code.
