The goal of a trust model is to minimize the number of entities that must be trusted to preserve business interests. The digital cinema trust model enables highly valued content to be distributed worldwide without encumbrance on fulfillment and exhibition entities.

The early stages of motion picture production are managed by rights owners where trust is inherent. Motion picture distribution, however, is normally conducted outside of a rights owner’s purview. Special consideration, therefore, is needed to ensure a trusted environment in distribution. The typical high level workflow model for motion pictures is illustrated below. The area of interest is that shared by Distribution and Exhibition.

Figure TM-1. Motion Picture Workflow

Trust is ensured through the encryption of digital cinema content and the management of security keys that enable the content to be played. For practical reasons, it’s useful to encrypt once and distribute to many, in a one-to-many fashion. But it’s also desirable to restrict where encrypted content is played, enabling playout in a site-by-site or screen-by-screen manner per the business requirements of the rights owner.

Cinema is unique in the digital media world in that it’s relatively small footprint of approximately 150,000 screens worldwide allows it to be managed as a closed ecosystem. Content encryption is managed such that the matter of trust is further narrowed, away from exhibitors, and towards an even smaller number of actors: the equipment manufacturers.

The security specification to which equipment must comply is jointly owned and managed by the six major Hollywood studios, whose content generates a substantial share of box office for cinemas. The joint specification is published by Digital Cinema Initiatives (DCI), a consortium of the six major studios. DCI maintains a website for its Digital Cinema System Specification (DCSS) and Compliance Test Plan (CTP) at dcimovies.com.

Digital cinema security utilizes a combination of symmetric key encryption and private key infrastructure, incorporating the principles of openness and autonomy. Openness ensures that the system can be built by anyone skilled in the art, based on royalty-free and license-free standards and specifications. Autonomy means that securely distributed content can be played without the need for active connection of the playback equipment to an outside network.

The principle of autonomy requires that the playback equipment manage its own trustworthiness. For this reason, DCI-compliant equipment is tamperproof by design, eliminating the need for active verification. Each certified playback device has at least one Digital Cinema Certificate, recognized by DCI as a declaration the device meets the DCI Specification.

The digital cinema trust model allows for closure of this open loop of trust by means of the Digital Cinema Security Log. The log establishes a “Circle of Trust” workflow model, as illustrated below.

Figure TM-2. The DCI Model of Control Lightly/Audit Tightly

Content owners publish the DCI Specification, which is the basis for DCI Compliance Testing of digital cinema equipment. Certified devices carry a digital public-key certificate, whose serial number and public key are recorded in a database commonly referred to as a “Trusted Device List,” or TDL. The TDL also records where the certified device has been installed. When content is encrypted, the encryption key is distributed in encrypted form as a Key Delivery Message, or KDM. The exhibitor receives both the encrypted content and the KDM, enabling the content to play. At the time of playout, a Security Log is generated by the DCI-compliant playback system, which can then be viewed by the content owner to validate that its content was played by DCI-compliant equipment. The DCI specification refers to this closed loop process of managing trust as “control lightly/audit tightly.” (See DCI, DCSS section 9.4.6.3 Logging System.)

In practice, it is often sufficient for rights owners to trust the public keys made available to them by equipment manufacturers. For an exhibitor to receive the proper keys that enables content to play, it must report the equipment in its possession, completing the TDL.

To summarize, the digital cinema trust model is managed within an ecosystem that does not require active verification of playback equipment. Equipment manufacturers establish trust in their equipment through the certification process established by DCI. Content owners express trust in an exhibitor’s playback equipment when creating Key Delivery Messages (KDMs) based on Trusted Device Lists (TDLs). In addition, content owners can close the trust loop through the examination of equipment Security Logs.

Digital cinema makes use of two types of common cryptography: symmetric-key cryptography, and asymmetric-key cryptography, also known as public-key cryptography. This section provides a review of encryption basics, leading to the application of encryption for digital cinema content and keys.

Encryption Basics

There are two classifications of cryptographic algorithms: symmetric and asymmetric. Symmetric-key cryptography uses the same key to lock and unlock data. This concept is illustrated below, where the red key represents a symmetric key.

Figure EM-1. Symmetric Keys

Asymmetric cryptography requires two non-identical, but mathematically linked, keys, comprising a key pair. These are often referred to as public and private keys. The concept is illustrated below, where the public key is the green key, and the private key (in practice, hidden from prying eyes) is the blue key.

Figure EM-2. Asymmetric Keys

Digital cinema content uses a combination of symmetric-key and asymmetric-key cryptography, where the content is encrypted once, distributed widely, but only authorized equipment having the correct private key can decrypt the content key that enables playout. In the cinema application, playback devices contain a secure Media Block to play the content. The encryption scheme accomplishes several goals:

• Simple in concept
• Efficient, where large amounts of data are encrypted once (Track Files), and only small amounts of data are encrypted for each playback device (KDMs)
• Revocable at the device level (Note: this is further discussed in the section on Trusted Device List)

Figure EM-3. Public and Private Keys in Digital Cinema

Security Key Workflow

In the digital cinema workflow, content that the owner chooses to protect is encrypted using a symmetric key. To secure the symmetric key, it must also be encrypted. This is accomplished by encrypting the symmetric key using the public key of the target playback device (a Media Block). Of course, this method requires that the content distributor knows the target device’s public key. In practice, distributors build and maintain a Trusted Device List (TDL), matching device certificates containing public keys with the location of trusted devices. (See section on Trusted Device List).

(Note: The term Trusted Device List as used here is a database maintained by or for content owners, and is not the Trusted Device List element found in the KDM.)

A DCI-compliant digital cinema playback system never stores encrypted picture and sound content in unencrypted form for playback at a later time. By specification, the system always decrypts content in real-time at the time of play. Accordingly, the KDM carries a date-time window condition that dictates when the content can be decrypted and played. (See the KDM section for more details.)

The illustration below ties together the elements of the content encryption model. The key for decrypting content in the cinema is carried in encrypted form by a KDM. The KDM is created by a trusted party only for an authorized player, simultaneously authorizing and expressing trust in the player. At the player, the KDM enables the player to decrypt the content in real-time as it plays.

Figure EM-4. Digital Cinema Security Key Workflow

The Trusted Device List, or TDL, plays an important role in the management of content security, and the distribution of content. Not only does it track the location of trusted devices in the field, but it also tracks the databases of trusted devices from manufacturers. Notably, more than one TDL exists, with each TDL often managed by a private entity engaged in some stage of content distribution. In the distribution workflow, metadata from several sources must be gathered and matched to properly enable the exhibition of content per the booking commitments of the content owner. The TDL plays an important role in this process.

To best understand the purpose of a TDL, an illustration of metadata workflow in distribution is presented below.

Trusted Device List & Metadata Workflow

Trusted Device List (TDL). A TDL is a database of equipment and security-related information, collected from both equipment manufacturers and exhibitors. The database is maintained by studios and/or trusted fulfillment entities. At a minimum, the database marries manufacturer public-key certificates and serial numbers with serial number and location information received from exhibitors. TDLs are used by fulfillment entities when generating KDMs. If the TDL database is not up-to-date, the movie may not play.

Manufacturer Database. A database of product security-related information maintained by manufacturers, as required by Digital Cinema Initiatives (DCI). DCI requires the database to carry media block serial numbers, public-key certificates, and forensic mark identifiers. Manufacturer databases are utilized by TDLs.

Digital Readiness Form. An ad hoc form for collecting information regarding the DCI-compliant playback equipment operated at a site. Such forms can be quite detailed, designed to tailor content versions to the particular needs of each screen at the site. At a minimum, media block serial numbers, screen numbers, and the location of the cinema are sent by the exhibitor to the TDL owner. It is incumbent on exhibitors to keep the TDL up-to-date for movies to play.  [Note: modern systems replace the Digital Readiness Form with the machine-generated Extended Facility List Message (SMPTE ST 430-16) exchanged with the TDL operator using the FLM-x (SMPTE ST 430-15) protocol.]

Booking Data. Business data that comprises the movie booking. Movie engagements are booked with exhibitors long before the movie itself has completed post production. As a result, booking data typically consists of movie titles, dates of engagement, and location, but not data-centric information such as a CPL identifier for the title.

KDM Generation. When generating KDMs, information from multiple sources must be collected and matched. Location and dates of engagement must be obtained from the Booking Data. The booking location is then used to pull the appropriate media block public-key certificates from the TDL. D-KDMs must be collected from Content Mastering for the title. When the appropriate information is collected and matched, KDMs for an exhibition site can be generated. Note that if TDL entries do not exist or are possibly out-of-date, the exhibitor may be requested to submit a new Digital Readiness Form to the TDL owner.

Content Mastering. Composition Track Files are encrypted at the content mastering stage, resulting in the creation of a D-KDM. The D-KDM is used by the KDM Generator to generate exhibition-directed KDMs. By nature of a KDM, the D-KDM carries the Composition Identifier (CPL ID) used to match a KDM with its Composition.

Digital certificates provide a secure and interoperable means for exchange of public keys while proving that the public key is from a trusted entity. The Digital Cinema Certificate is recognized by DCI as a declaration that the certified device meets the DCI Specification. (See DCI DCSS section 9.6.2.2.) A Digital Cinema Certificate, therefore, is a declaration from a trusted party that a particular device is to be trusted.

In cryptography, a digital certificate is typically accompanied by a chain of certificates, tightly linked by digital signature, and ultimately signed by a trusted root certificate. In many business applications, the trusted root certificate is provided by a trusted third party. In digital cinema, the need for a third party is eliminated. The root certificate can be provided by a trusted vendor, such as the manufacturer of a Media Block. Trust in in the vendor is established through the vendor’s relationship with content owners and the knowledge that its products are DCI-compliant, eliminating the need, expense, and complexity of a trusted third party.

In 2011, a change in rules from the US National Institute of Standards and Technology (NIST), the owner of the FIPS 140-2 specification, disallowed the shared use of a single public-private key pair for applications such as TLS, digital signature, and encryption/decryption of AES symmetric keys in the KDM. The result is that new Media Block designs now carry two key pairs, one shared among TLS and digital signature applications, and the other applied only for the protection of AES symmetric keys. For this reason, Media Blocks designed after 2011 have two digital certificates that share public keys.

Digital cinema certificates are a constrained version of the widely used X.509 v3 certificate defined in IETF RFC 5280. The Digital Cinema Certificate uses the following features of the X.509 v3 digital certificate:

The manner in which these elements are applied is defined in SMPTE ST 430-2 Digital Certificate.

KDM is the acronym for Key Delivery Message. A KDM is required to play an encrypted movie. Each KDM enables one version of the movie to play on a target playback device for a limited duration, which could be hours, weeks, or months.

The KDM is the vehicle for securely delivering symmetric content encryption keys to authorized playback equipment. A KDM targets only one playback device, and is an expression of trust in the targeted device. Further, the trust conveyed by a KDM is only expressed for one encrypted Composition.  Content versions, expressed as a separate Composition, require a different KDM to play it.

Symmetric keys carried by the KDM are encrypted, making the KDM intrinsically secure. It does not rely on a secure transport, such as TLS, to secure the keys it carries. For example, a KDM can be posted on a public web page, with the only possible outcome being that the single device authorized by the KDM will be capable of playing the associated content in accordance with the conditions carried in the KDM.

It follows that trust is expressed at the time of creation of the KDM, and not in the distribution of the KDM. This reduces the distribution of the KDM to a matter of pure logistics, without concern for the security of the transport mechanism. If a KDM arrives at the wrong destination, for example, the security of the Composition it addresses will not be compromised.

In performing its role as the communicator of trust, the KDM carries certain data:

• Encrypted symmetric content keys necessary to play an encrypted Composition
• Composition identifier associating the KDM with the Composition for which it was created
• Date/time validity period for use of the content keys
• Forensic marking instructions
• Identifier of the targeted media block (the “recipient”)

KDM Payload

Key Delivery Message (KDM) Payload

Composition Identifier. The Composition Identifier is that carried by the associated Composition Playlist, in the form of a Universally Unique Identifier (UUID), per RFC 4122.

Date/Time Validity Period. The Date/Time Validity Period is carried in multiple ways. The information is described in clear-text (unencrypted) XML parameters as “not valid before” and “not valid after” UTC date-times, enabling the receiving equipment to readily read it. However, the actual  UTC date-times to which playback equipment respond are encrypted along with each symmetric content key, where the information cannot be tampered with. The Validity Period clear-text date-time values of a valid KDM must match the encrypted date-time values.

Forensic Marking Instructions. By default, encrypted picture and sound content will be forensically marked in real-time when played by a DCI-compliant media block. A flag may be set in the KDM to command the playback system to not forensically mark the content, or to selectively mark the content. Possible reasons for taking such action include honoring a director’s wish to not modify in any manner picture or sound for a premier. A more common reason for exercising this flag is to selectively mark audio channels so that associated non-audio information carried in the audio track file, such as motion seat data, is not modified by the forensic marking engine.

Recipient Identifier. A KDM identifies the recipient (its target media block) by carrying the thumbprint (hash) of the public key of the media block’s Digital Cinema Certificate. In DCI-compliant equipment, the certificate meets the requirements of SMPTE ST 430-2 Digital Cinema Certificate, which constrains the widely used X.509v3 certificate for digital cinema applications. ST 430-2 dictates that the dnQualifier attribute of the certificate’s Subject Name contain the public key thumbprint of the recipient, serving as an identifier. This thumbprint is also carried in the KDM, as the KDM must carry the Subject Name of the certificate.

The thumbprint is a computed hash, using the SHA-1 hashing algorithm, of the media block’s public key. The computed hash is computationally unique, irreversible, and repeatable. It is unique in that a change of a single bit in the public key will cause a change in the hash value. It is irreversible in that one cannot reconstruct the public key from the thumbprint. In practice, a Theater Management System can use the thumbprint to efficiently push KDMs to the right target devices. Alternatively, a media block can use the thumbprint to identify and pull KDMs intended for it from a large collection of KDMs.

Encrypted Keys. The primary payloads of the KDM are the encrypted symmetric keys used to secure the associated Composition. Each Composition is comprised of at least two track files: a picture track file and a sound track file. Each track file may be divided into multiple files of essence along temporal boundaries. Each essence file that results must be encrypted with a unique symmetric key. From this, it should be apparent that a large number of symmetric content keys could be employed with a long Composition. Each content key is encrypted with the public key of the recipient (the target media block), and included in the KDM. The KDM specification requires that the key identifier and validity dates be encrypted along with each key. The key identifier is defined in SMPTE ST429-6 MXF Track File Essence Encryption, and is used by the media block to match each key with its associated track file.

Digital Signature. The KDM is digitally signed following the XML signature specification of W3C.  Details of the signature are described in SMPTE ST430-3 Extra-Theater Message and SMPTE 430-2 Digital Cinema Certificate.

D-KDM and KDM Standards

In practice, when a Composition is encrypted, the encrypting device simultaneously creates a KDM for secure storage of the symmetric content keys used during the encryption process. This KDM, and similar KDMs created for use in pre-distribution applications, are called Distribution KDMs, or D-KDMs. For example, the Composition may be encrypted by a studio, and then sent to a fulfillment entity for re-distribution to exhibitors. At the time of encryption, the studio will also create a D-KDM targeted to a trusted device owned by the fulfillment entity. The fulfillment entity will then use the D-KDM to create exhibition KDMs for distribution, using the symmetric keys carried by the D-KDM, along with the associated booking information and playback equipment public keys found in the fulfillment entity’s Trusted Device List. It’s important to note that a D-KDM and an exhibition KDM are identical in structure, and only different in name and application.

Structurally, the KDM is a form of a generic message type called Extra-Theater Message (ETM).   The designers of the ETM envisioned a class of security messages that would require the common set of features defined by this message type. However, in practice, only the KDM utilizes the ETM. For this reason, two SMPTE standards, SMPTE ST430-1 KDM and SMPTE ST430-3 ETM, are required for a complete definition of the KDM.

The Media Block is unique to digital cinema. It contains all of the necessary processing elements within a secure boundary to present picture and sound, as well as interface elements outside of the secure boundary.

The Media Block concept is illustrated below, followed by a discussion of each element.
 
 

Figure MB-1. The Media Block

Screen Management System (SMS). The Screen Management System provides the interface to the Media Block, both user-interface and machine-interface. The SMS also manages user-related properties, such as login functions.

Secure Processing Boundary (SPB). DCI specifies secure processing boundaries for security-related processes. For picture and sound processing, the SPB must meet US Federal Information Processing Standards (FIPS) 140-2 Level 3, as well as comply with DCI requirements. (The DCI Specification and Compliance Test Plan can be found at dcimovies.com. Per the specification, the SPB for picture and sound processing must be tamperproof, such that physical tampering will erase the keys.

Security Manager (SM). The element of the Media Block responsible for security data and security policies. It is a self-contained sub-system, having its own processor and secure operating system.

Media Decryptor. The media decryptor decrypts the encrypted essence of the Track File, using the Private Key of the Media Block.

Signal Processor. Picture processing includes JPEG 2000 decompression. Audio processing, in the case of immersive sound, may include a rendering engine.

Forensic Marker. Forensic marking capability is required of the media block by the DCI Specification, but its use is optional to content owners. The information in the forensic mark is defined by DCI, and includes location information and time of day.

Secure Clock. Not shown in the diagram, the secure clock is an important feature of the media block. The secure clock is tamper-proof and battery backed. It is the reference for evaluating the date/time validity period of the KDM, and for time stamping security logs.

When the Media Block concept was first introduced, it was envisioned that several types of media block could exist, such as separate media blocks for picture and sound. DCI, for example, frequently refers to the Image Media Block (IMB) in its specification. In practice, however, manufacturers prefer to process as many essence types as possible within a single media block. As a result, the IMB, as defined by DCI, is generally the only Media Block found in most digital cinema systems. Please note that the DCI IMB should not be confused with the marketing use of the IMB acronym for Integrated Media Block.

Content may be encrypted when entering the Media Block, but it may not be encrypted when leaving it. When a Media Block is installed internally to the projector (an Integrated Media Block), it undergoes a marriage process with the projector.  If the marriage between such IMBs and projectors is tampered with to gain signal access to the unencrypted picture, it will trigger a tamperproof response within the Media Block.  This behavior exists to secure the unencrypted picture signal.

The Media Block is a complex device, whose security behaviors are well-defined by DCI. Some processes described have been generalized for simplicity. As such, the description presented above provides only a high-level understanding of the Media Block’s operation and its several forms, and is by no means exhaustive. For a complete understanding of the Media Block, one should refer to the DCI Specification and the DCI Compliance Test Plan at dcimovies.com.

The Digital Cinema Security Log documents the usage and behavior of a digital cinema system. It supports the logging of both secure and non-secure information by accommodating authenticated as well as non-authenticated log records.

Each record of the Security Log consists of a Header, Body, and optional Signature sections. The log record signature provides authentication of the log record header, or optionally, authentication over a number of log records recorded in a sequence.  A sequence is created using a system of shared hashes and digital signature, such that the integrity of the sequence can be readily validated. The sequence structure allows for the filtering (removal) of a log record while preserving the fact of the record’s existence.

Security logs are shared with business partners for numerous reasons, including the establishment of trust.  As a log may contain business information that pertains to multiple business partners, the ability to remove sensitive information when sharing is an important structural feature of the Security Log.

Security Logs are generated within a Secure Processing Boundary (see Media Block) for purposes of integrity. It is desireable that one log records all events of a digital cinema system. Where a Media Block is connected to other “remote” secure devices, such as a projector (separare from the Media Block), provision is made for the communication of log data over a TLS link to the Media Block for its logging activity. (See SMPTE 430-6 Auditorium Security Message for Intra-Theater Communications.)

Several record classes are supported, comprised of:

Detailed information about the Security Log is available in SMPTE ST 430-4 Log Record Format Specification and SMPTE ST 430-5 Security Log Event Class and Constraints.