1

DRM Interoperability

Sanjeev Verma

Contents

1. Introduction

2. What is DRM Interoperability?

3. Previous Approaches to DRM Interoperability

4. Current Approaches To DRM Interoperability

5. Related Technologies and Trends

6. Summary

Introduction

A Digital Rights Management mechanism consists of a set of security mechanisms that are used

to facilitate the controlled distribution and consumption of the digital content. In an ideal world,

a single technical system or solution should be able to achieve this purpose. However, the One

Size Fits All strategy does not work in the case of DRM technology due to business, patent and

scalability related issues. There are a number of business use cases that triggered the

development of numerous DRM solutions to address specific usage. Some of the example usage

models are-content rental, content subscription, and secure peer-to-peer content distribution.

DRM systems need to define and enforce complex business rights; they also need to track the

usage of rights and enable trading of rights within a multi-tier value chains.

Also, there are Intellectual Property (IP) related issues that have led to the development of

2

numerous DRM solutions. DRM systems are not only a way to protect Intellectual Property of

the content but they themselves contain Intellectual property. The Intellectual Property issue has

led to the development of a number of competing solutions in order to circumvent the cost of

licensing technologies. For instance, the lack of agreement on a standardized mechanism to

encode rights due to patent related issues led to a number of non-interoperable solutions. There

was a big battle between two rights languages, XrML (Extensible Rights Markup Language) and

ODRL (Open Digital Rights Language Initiative). There was a lot of politics behind this—

basically Microsoft owned XrML technology and rest of the world wanted to adopt an open

standard. Eventually there was no agreement and every DRM vendor adopted different

mechanisms to encode rights. There have also been standardized efforts to minimize the

licensing rights associated with the DRM technology. MPEG-LA [18] provides a one stop shop

to licensing of essential IPs related to DRM technology.

Scalability is another big issue that led to the development of numerous DRM solutions. It is not

possible to implement a single Trust Management entity that will be trusted by everyone in the

content distribution eco-system—Content Providers, Service Providers and Device

manufacturers. It will be an expensive proposition to have one Trust management entity that

could enforce compliance and robustness (C&R) rules across a large number of deployed

devices. This has led to the specification and implementations of a large number of DRM

systems—each having its own Trust Management Entity enforcing its own C&R rules.

What is DRM Interoperability?

As mentioned in previous paragraphs, the existence of multiple DRM solutions is a fact of life

due to a number of technical, political and business issues and there is not much we can do about

it. However, we can make an effort to make end user experience a pleasant one. The goal of

3

DRM Interoperability solution is to allow users to buy content from any retailer and consume the

acquired content on any one of the multitude devices owned by them without worrying about the

protection mechanism used.

Video Camera

Content Creation

Distribution/Transmission

Consumption/Storage

Internet Conditional Access (or DRM)

Internet Conditional Access (or DRM)

Protected Media(CPCM/CPRM/AACS)

Internet Gateway Device

Set Top Box

Media Player

Digital Home

Figure 1 Content Delivery to End User Using Various Distribution Channels.

An end user gets his content from various distribution channels (See Figure 1)—in the form of

pre-packaged media such as CDs/Blu-ray Discs, Flash memory based products; over the Internet

and over the broadcast networks (cable/satellite). There is wide-range of content protection

mechanisms available today to protect the content distributed through these diverse distribution

channels:

Pre-recorded/Recorded Content

o CPPM ( Prerecorded Audio)[15]

4

o CSS (Prerecorded DVD)[16]

o CPRM (Recordable Audio/Video)[15]

o AACS ( Blu-Ray Discs)[14]

Various Content Protection Delivery Mechanisms

o Various DRMs

PlayReady (Microsoft), Fairplay (Apple), Widevine DRM ( Google),

OMA DRM, Flash (Adobe) and many others

o Conditional Access Protection Systems

CableCARD (Cable Labs), DVB-CPCM (DVB), IrdetoAccess (Irdeto),

Broadcast Flag (ATSC) and many others.

o Short-range link protection (Home)

DTCP-IP ( Link Protection)

HDCP (HDMI/DVI)

Currently, there is no single interoperable protection mechanism for wide range of devices

(mobile, PC and CE) to share content obtained through various distribution channels.

Existing content distribution systems provide close ecosystems resulting in a number of non-

interoperable silos. Each eco-system uses a certain protection system to distribute content

through a single retail portal carrying a limited set of content. This leads to an unpleasant end

user experience. Ideally, an end user should be able to obtain content from any retailer and enjoy

content on anyone of the several devices owned by him/her.

5

Trust Managementof DRM

Rights Encoding Mechanism

( Rights Expression Language or Virtual Machine)

Key ManagementSystem

Content Packaging Formatand Encryption

Figure 2 Building Blocks of a Typical DRM System [9].

However, it is not an easy task since different DRM systems uses different mechanisms to

protect the content and encode the usage rules associated with the content. A DRM system

consists broadly of the following elements:

1. Content Encryption and Packaging;

2. Encoding of Usage Rules and Content Encryption Key in a License;

3. Distribution of License to a legitimate End User;

4. Enforcing of Compliance and Robustness Rules by the corresponding Trust Management

Organization.

There are several challenges to overcome before we can render the content protected using one

DRM system in the device implementing client of a different DRM system. First, the

Compliance and Robustness rules of the source DRM system should allow the import and

rendering of the content in the destination DRM system. Secondly, the protected content and

6

license needs to be encoded from the source DRM system to the destination DRM system as

shown in Figure 3. As shown in the diagram, rights need to be transcribed securely and

consistently between two DRM systems. It is not an easy thing to accomplish due to different

mechanisms (Rights Expression Language or Virtual Machine) used by various DRM systems to

encode rights.

Secrets

Content

Rights

Source DRM Agent Destination DRM Agent

Secrets

Content

Rights

Should be transcribedSecurely & consistently

Should be transferredsecurely

Figure 3 Exporting of Content from source DRM system to destination DRM system.

The mapping of content packaged using the content format of one DRM system to that of

another DRM is another incompatibility issue.

Previous Approaches to DRM Interoperability

Content Interoperability has been an important issue for a number of years and as such has been

addressed by players involved through a number of standardization efforts. The earlier efforts

7

can be classified into two:

1. Bridge Model

2. Monolithic Model

The bridge model is based on using transcription to map licenses between different DRM

systems. A challenge with this approach is to convince all players involved to open their DRM

systems for DRM transcription. Also, the scalability is another issue since it is not possible to

define transcription mechanisms between all the available DRM systems. Instead, an approach

was developed where every available DRM systems would allow export to and import from a

common protection mechanism. DTCP-IP [12] emerged as the common link or bridge to link a

number of DRM systems. It has been adopted as such by DLNA [17] to support DRM

interoperability solution in the home. DTCP-IP scheme was initially adopted for streaming but

later was extended to support DRM interoperability use cases of DLNA.

The monolithic model is another approach that was initially considered. This approach is even

more daunting since it aims to have one unified end-to-end DRM model. Moreover, this means

addressing the DRM interoperability issue across various content distribution channels

(broadcast, internet and packaged content) and building an end-to-end value chain for a new

DRM implementation across the entire ecosystem. For instance, MPEG21 [11] tried

unsuccessfully to standardize “Rights Expression Language” to communicate DRM license

information in a “ubiquitous, unambiguous and secure” manner. Industry finally realized that it

is impossible to have end-to-end monolithic model but it is possible to have at least one

standardized common element across all the DRM systems.

Currently there has been a broad agreement in industry to use common file format [9] and

common encryption mechanism to package protected content. The Common File Format (CFF)

8

[2] and common encryption mechanism has been adopted by multi DRM eco-system like DECE

(Digital Entertainment Ecosystem) [1] with brand name UV (Ultra Violet) [3]. Industry also has

come to terms that there would not be any agreement on the Key management System and

License (or Rights Encoding Mechanism) controlled by different Trust Management systems.

Video Card

IP Stack

DRM, DVD orOther content

applicationDTCP client

Protected link to a number of devicesin home.

Content sharing of content from a home deviceto other devices in home.

Figure 4 DTCP-IP enabled DRM interoperability.

The other interesting DRM interoperability solution came from Coral Consortium [13] which

was formed in 2004 by Samsung Electronics co., Hewlett-Packard Corporation, Philips

Electronics N.V., Panasonic, Sony Corporation, Intertrust and Twentieth Century Fox Film

Corporation to develop a DRM Interoperability framework. The Coral solution defines a set of

roles (logical entities) with standardized interfaces that could be integrated with DRM elements

9

to achieve DRM Interoperability solution. One important logical entity defined by the

consortium is the Rights Mediator (RM) role that orchestrates the sharing of the content among

devices supporting different DRM systems. It adopts two mechanisms to achieve the end

objective. First mechanism is based on the bridging model involving transcription. Second

mechanism is the most interesting one. In this mechanism, Coral adopts a license derivation

strategy, in which DRM licenses are not directly inspected and translated but rather derived from

a standardized policy artifact known as Rights Token. The DRM interoperability works as

follows under Coral Interoperability framework:

1. Client sends a request for license to the Rights Mediator (RM).

2. RM checks the transaction database to make sure that the user has already purchased the

content.

3. RM now checks whether there is a Rights Token (RT) for the purchased content in the

RT database (Called Rights Locker). RM also makes sure that the device is authorized to

receive the license by making sure that the device belongs to the eco-system domain.

4. RM now sends the RT to the Rights Instantiator (RI) role that is integrated with the native

DRM License Server.

5. RI initiates the rights acquisition process of the native DRM License server.

6. The License is then delivered to the native DRM client using the native DRM specific

process.

10

Protected License Database

DRM Client

Web Browser

Coral Client

Rights Mediator Rights Instantiator

Transaction Database

Domain Manager

Rights Locker

Coral Enabled Device

Native DRM LicenseServer1

32

4

5

6

Figure 5 DRM Interoperability using Coral interoperability solutions.

Coral solution was selected along with DTCP-IP by DLNA Content protection Working Group

as two mechanisms to achieve DRM interoperability in digital home. There has not been any

commercial implementation of Coral solution. However, the approach based on common RT and

Rights Locker was adopted in cloud based UV ecosystem. More details to follow in the next

section.

Approaches to DRM Interoperability

Currently two approaches are being considered by various standardization bodies to enable

consumption of protected content in the presence of multiple DRM solutions.

11

Multi-DRM Approach

First approach (and currently the most popular) is an eco-system or service provider centric,

where an eco-system (or a service provider) supports multi DRM solutions that work across a

large number of devices implementing one or more DRM mechanisms approved in the eco-

system. This approach is based on using a common file format (CFF) and a common encryption

mechanism for digital content. The details of CFF and common encryption mechanisms have

been described in the last Section of this chapter. Also, the rights (usage models) associated with

the digital content are defined by a generic policy artifact called Rights Token, which is also

considered as a proof of purchase. Note that this concept was originally introduced in the Coral

interoperability model (See Previous Section). The adoption of this concept implies that all the

DRM systems joining the eco-system will support common usage models supported in the eco-

system. This allows a device to consume the protected content using anyone of the approved

DRM protection systems by obtaining rights and content decryption key in the native DRM

specific License format.

12

“Smith Family DECE A/C”

Family TVFamily PC Family PVR

“Al ice Smith”“Carol Smith”“Bob Smith”

Shared devices

Tablet Smartphone

Individually owned devices

Figure 6 Relationships between a Household DECE A/C, Household Members and Devices owned by

them.

DECE (Ultra Violet) [1][3] is an eco-system that uses multi-DRM approach and is being

supported by various device manufacturers and content providers (studios). The DECE

architecture has been designed to give a user with the best possible digital content viewing

experience. A user can purchase, share and play content on anyone of the devices owned by

him/her in a manner similar to the physical media such as Blu-ray and DVD. The eco-system is

based on the following three concepts:

1. A user can obtain his/her content from any retailer that complies with the eco-system

specifications.

2. All the members of a household can be clubbed into a single user account—enabling the sharing

of the content among the members belonging to a household.

3. A member of the household can render the content across all the devices associated with the

account.

A number of architectural decisions were taken to incorporate aforementioned concepts in the

13

eco-system design. The DECE (Ultra Violet) eco-system has been defined with the following

architectural goals:

To define a single well branded eco-system with a well-defined usage model that is enforced

across all participating entities in the eco-system.

To use a single media format that can be used across all types of devices

To allow use of a number of DRM mechanisms in the eco-system so that content can be

obtained from a number of retailers and rendered on a wide range of devices.

To specify usage rules or business logic through a generic policy artifact, namely Rights Token,

that can be enforced by all the DRMs schemes supported in the eco-system.

To use common encryption mechanism to encrypt the content and obtain decryption key using

native DRM specific mechanisms.

To use a cloud-based approach to keep record of consumer’s proof of purchase in Rights Locker.

A Rights Locker stores all proof of purchases (Rights Tokens) for all purchases made against an

associated user account.

The DECE architecture [1] allows a competitive market place, where a user is able to consume

content in DRM systems and Media Formats agnostic manner.

An important concept in DECE architecture is the concept of domain that groups all the users

associated with a certain user account and devices owned by them into a single logical domain

(See Figure 6). There is an account associated entry in the cloud (Rights Locker) that contains

the record of all the purchases by members of a household. All the users associated with the

household have access to the Rights Tokens in the Account’s Rights Locker including those that

were purchased individually by other users in the account. Thus, A DECE domain represents a

group of devices and native DRM information. Each device needs to register with the DECE

domain providing device specific metadata such as “DRM supported” and “audio/video

capabilities”. The DECE domain also manages native DRM information associated with each

DECE approved DRM scheme. The collection of DRM information is managed by a native

14

DRM client and is presented to the DECE eco-system along with the DRM domain credentials.

Thus DECE architecture [1] achieves the DRM interoperability across various classes of devices

in a household as follows:

1. A household member browses and selects the content from the distribution server hosted by a

retailer (belonging to DECE eco-system) of his/her choice.

2. DECE operator authenticates the user and the user pays for the content. User then downloads

the purchased content from the distribution server.

3. DECE client now obtains the location of the native DRM license server hosted by the retailer and

sends a request for the DRM license.

4. The native DRM license server in conjunction with the DECE operator checks the business logic

and obtains the Rights Token from the Rights Locker for the purchased content. It then

generates the License in the native DRM format. The requesting device now obtains the DRM

License using the native DRM specific Rights Management protocol.

5. The downloaded content can be shared and rendered in any household devices provided they

implement one of the DRM systems supported in the DECE eco-system. The corresponding

license can be obtained from the native DRM license server using the native DRM defined

mechanisms.

DECE/Ultra Violet

Up to 12 registered devices for download for a household of 6 members

Rights Locker Rights Token

(Native DRM License Servers)

Rendering device downloadsthe License in native DRM formatof the DRM scheme supported in theDevice from the retailer.

Media Player

Smart PhoneTablet

TV

Figure 7 DRM Interoperability in DECE eco-system.

15

Downloadable DRM Approach

Alternative approach is device centric, where a device implements a generic secure trusted

platform. The device then downloads a DRM module supported by the service provider to run

on the secure trusted platform. This is less costly alternative for the device manufacturers since

they only need to support a single secure platform in their devices instead of implementing

specific DRM solutions for different eco-systems and markets. It is also attractive to an end user

who could simply buy a device from a retailer and use it with any service provider of his/her

choice. Moreover, the platform can be updated with the latest version of DRM software if there

is a security breach. An example of this approach is Downloadable CAS proposal advanced by

Cable Labs [19] for secure software download of a specific conditional access client which

controls DRM in a consumer media device. This technology did not get commercial success

primarily because it mandated the adoption of a specific operating system OCAP by consumer

electronics companies in their devices.

However, there are numbers of challenges—technical as well as legal- for a downloadable DRM

mechanism to work in real life. The DRM provides end-to-end security solutions and manages

the content for its whole life-cycle and hence a download DRM solution needs to specify a

comprehensive security framework. It is not just about securely downloading a DRM agent on a

platform.

The challenges are as follows:

1. The downloaded DRM agent needs to run in a secure trusted platform. The platform

needs to meet the compliance and robustness rules specified by the trust management

organization of the downloaded DRM agent.

2. The secure trusted platform needs a comprehensive specification of compliance and

robustness (C&R) rules to meet the requirements of wide-range of DRM vendors. A

trusted management organization is needed to specify and enforce C&R across wide-

range of platforms.

16

a. Every instance of the trusted platform needs to be certified as conformant and

compliant.

b. Rules need to be specified regarding the downloaded code that specifies where it

can run.

3. It should be possible to remotely attest the integrity of the platform that is going to host

the downloaded DRM agent. Also, it should be possible to remotely monitor and attest

the dynamic run-time behavior of the DRM agent.

The concept of downloadable DRM is not new and is being used by a number of commercially

available DRM solutions. For example, PlayReady DRM is tightly integrated with Silverlight

player application and downloaded as a browser plugin. Currently most of these software-based

solutions are protected with code obfuscation and validation as well as other code based anti-

tampering mechanisms. However, the studios are wary of distributing high-value content to the

insecure platforms. Figure 8 indicates the pure software based implementation of downloadable

DRM solution on a secure platform. The DRM module, downloaded as a browser plugin or by

using other secure delivery mechanisms, is securely installed in the secure area of the platform.

The DRM module is responsible for the decryption of the protected content. The entire rendering

path including DRM agent, Media Player, Graphics card and Display is protected as per the

C&R rules of the DRM vendor.

17

Graphics

CPU

Applications(Browser)

DRM Agent

Media Player

Secure Trusted Platform

HDCP

Display

Distribution ServerHosting DRM protected Content and Downloadable DRM agent.

Secure Area withAnti-Tampering Mechanisms

Figure 8 Secure Tamper-Resistant Implementation of Downloadable DRM.

The design of Secure Trusted Platform (STP) needs to accommodate the C&R requirements of a

number of DRM systems and also requires standardization efforts to interface with the

downloaded DRM modules. For example, the STP needs a standardized interface with well-

defined APIs to the downloaded DRM software module. This interface offers an abstraction that

makes no assumptions regarding the underlying hardware and software to realize the secure

platform.

The other issue is the need for the STP platform to meet the C&R requirements of a number of

systems. If a particular DRM has more strict robustness requirements then those that can be

realized by STP then that particular DRM module can’t be supported—the DRM vendor and its

corresponding Trust Management Organization would not allow the DRM module to be

downloaded on such a STP.

However, this approach is likely to get popularity in future due to the adoption of cloud

18

computing (Virtualization) and Trusted Computing based technologies by device manufacturers

in the next generation of devices.

Related Technologies and Trends

Both Multi DRM and downloadable DRM mechanisms are two emerging approaches to solve

the intricate issue of DRM Interoperability. They are likely to co-exist and probably be used

together to present an enriching user experience, where a user would not have to worry about

the source of their content and at the same time content providers would be rest assured that

their content is safe.

As previously mentioned, meeting C&R requirements of a wide-range of DRM vendors are a

daunting task. However, the most likely emerging scenario is one where the C&R rules are

going to be specified at a high-level of abstraction by the service and content providers since

they are the one who would like protect and control the distribution of the premium content

owned by them. This would lead to a scenario where a standardized platform could be specified

which could then be used to support wide range of DRM mechanisms supported by the service

providers.

There are already some commercial and standardization efforts in this direction. For example,

Global Platform’s *8+ Trusted Execution Environment (TEE) Client Application Programming

Interface (API) specifications define a standard that makes it easier to use secure environments

within the various smartphone OS. Trusted Logic [4][5], the leader in providing secure

solutions, is probably the first vendor to align with the latest TEE specifications from the Global

Platform Standardization body. For example, Trusted Show from Trusted Logic provides a multi-

19

scheme DRM client solution that can be used on any device. Trusted Foundations provide an

isolated environment to secure sensitive applications on the platform itself. Trusted logic

provides a secure solution by integrating the Trusted Show APIs with the multimedia

framework and leveraging the HW security (provided by Trusted Foundations) to meet the

security requirements of wide-range of DRM vendors and content providers (see Figure 9).

Media Player

TrustedShow API

TrustedShow Services

Trusted Foundations

SecureUI

SecureClock

SecureCrypto

Trusted Platform ArchitectureBased on Global Platform’s TEE Client API specifications

DistributionServer

License Server

Encrypted Content DRM License

Content Provider

Figure 9 Trusted Logic’s DRM solution based on the Global Platform specification.

There has been a number of enabling technologies that makes it possible to implement DRM

operability solution across wide range of platforms. Brief descriptions of enabling technologies

are as follows:

Trusted Computing

Trusted Computing (TC) is a technology developed and promoted by Trusted Computing Group

[7]. It ensures a system, e.g., a mobile device or a server platform, consistently behaves in a

trusted way by utilizing the hardware and software based enforcement mechanisms. In TC

20

model, each platform has a (typically hardware) module. In current model for PCs and mobile

devices, these chips are called TPM (Trusted Platform Module) and MTM (Mobile Trusted

Module), respectively, and the enforcement mechanisms rely on these chips.

TPM provides a unique ID and some security mechanisms for PC/server platforms. Through the

use of TPM, remote parties can securely detect the software configuration running on a

server/PC via a method called remote attestation. This enables software vendors to detect and

prevent users from tampering with installed software components in order to circumvent

technological protection measures. Remote attestation works by having TPM measure what

software is currently running and securely report it to remote parties via the use of cryptographic

operations. The remote parties can easily verify whether the report is legitimate or fake. MTM is

similar to TPM, except that it is designed to be light-weight and suitable for mobile devices.

TrustZone is an integrated security technology designed by ARM [6] and available in a set of

ARM processors. The primary security objective of the architecture is to enable the construction

of a programmable environment that allows the confidentiality and integrity of assets to be

protected from specific attacks. A platform with these characteristics can be used to build a wide

ranging set of security solutions.

The security of the system is achieved by partitioning all of the SoC hardware and software

resources so that they exist in one of two worlds - the Secure world for the security subsystem,

and the Normal world for the general OS stack. The hardware logic in TrustZone enabled

architectures ensures that no secure world resources can be accessed by the Normal world

components, enabling a strong perimeter boundary to be built between the two. A design that

places the sensitive resources in the Secure world and implements robust software running on the

secure processor cores, can protect assets against many possible threats, including those which

21

are normally difficult to secure, such as credentials, certificates, passwords, credit card

information, etc.

TrustZone hardware enables a single physical processor core to safely and efficiently execute

code from both the Normal world and the Secure world in a time-sliced fashion. This may

remove the need for a dedicated security processor core such as a TPM in a carefully designed

platform. Functionalities similar to those of TPMs/MTMs can be realized through the use of

TrustZone technology. Moreover, security critical applications such as downloaded DRM

module can be developed to run in Trust Zone’s secure domain isolated from the general OS s/w

stack and all the related software threats associated with it.

The two virtual processors context switch via a new processor mode called monitor mode when

changing the currently running virtual processor. The logical view of TrustZone Worlds and

modes are illustrated below.

Secure WorldPrivileged Mode

Secure WorldUser Mode

Normal WorldUser Mode

Normal WorldPrivileged Mode

Secure Monitor

Normal World Secure World

Figure 10 Trust Zone Architecture [6].

22

Common File Format (CFF)

The Common File Format and Media Formats Specifications [2] have been developed by DECE

members and are being used in Ultra Violet eco-system. This format allows the rendering of

media in all UV players and work with all DECE approved DRMs. This format is based on the

existing standards of MPEG and was originally proposed by Microsoft as Protected Interoperable

File Format (PIFF) specifications [9]. The idea is to use common encryption mechanism and to

package the protected content along with the related metadata to signal multi-DRM and common

encryption parameters. This basically allows a media player to download the encrypted media

file and use the protection related metadata information embedded in the media file to contact the

appropriate license server to obtain the DRM license. This scheme is very similar to the

SimulCrypt feature in DVB which allows the simultaneous use of several Conditional Access

Systems to decrypt broadcast content encrypted using traffic encryption keys.

Common File Format supports multiple DRM mechanisms using a standard encryption method

and adds protection signaling information by adding three “uuid” boxes in the ISO Based FF:

1. Protection System Specific Header (“pssh”) Box

a. The protection system specific box contains the information required by the

content protection system to obtain the necessary information to play the content.

This an opaque box containing the information specified by the content protection

vendor. There can any number of these boxes depending upon the number of

protection systems supported by an eco-system. This box typically contains the

URL information so that protection system client in the device can obtain the

decryption key or DRM license. This box can also be used to store DRM license

after the content is downloaded by the client.

23

2. Track Encryption (“tenc”) Box

a. The Track Encryption box contains the default values for the decryption key id

and encryption parameters for the entire media track. These parameters are same

for all the content protection systems.

3. Sample Encryption (“senc”) Box

a. The Sample Encryption Box (“senc”) contains the sample specific encryption

information (one or more samples), including whether the sample is encrypted or

not.

This facilitates the DRM interoperability since the application downloading the content

can determine the content protection systems being used to protect the content.

Application can then use this to download the decryption key and associated rights by

looking at the protection system related metadata boxes.

Security and DRM support in HTML 5

There has been growing interest to integrate DRM technology with HTML5 streaming using

standard tools. This is not directly related to DRM interoperability but it would facilitate the

DRM interoperability by incorporating support of related technologies in HTML5.

Recently, there has been draft proposal [10] by Google, Microsoft and Netflix to W3C that

extends HTML MediaElement to enable playback of the protected content. This proposal

supports simple key decryption and DRM mechanisms to protect high-value content. In this

proposal, the DRM License acquisition is controlled by the application, facilitating the

development of robust playback applications that can work with a wide range of content

protection mechanisms. For example, an application can download the initialization segment

(meta-data of the content file) of the protected media file to determine the container type,

24

protection mechanisms supported and the codec types. Application can then use the proposed

APIs to determine if the underlying platform supports the protection mechanism, container type

and codecs of the content to be streamed. For example, if the media container type is CFF [2],

then application can first determine whether the underlying platform implements any one of the

multiple DRM systems specified in the DECE eco-system by extracting relevant information

from the downloaded initialization header. The application can abort the download if the

platform does not support any of DRM mechanisms approved by the eco-system.

Summary

DRM is an important technology to protect high-value content of the content providers.

Unfortunately, a number of DRM mechanisms have been developed due to business, patent and

scalability related issues. This has led to unpleasant experience for an end user who would like to

obtain his content from various distribution channels and still able to enjoy his content on a

number of devices owned by him without worrying about underlying technologies. The related

players in this space have made different approaches to address this intricate problem of DRM

interoperability. Finally these efforts have led to a number of plausible solutions like Ultra

Violet and many more possibilities in future. This Chapter has tried to give an overview of the

issues, history of the solutions and window to the future in addressing the intricate issue of DRM

interoperability.

References

[1] DECE, System Specifications, Version 1.0.3, 3rd

January 2012.

[2] DECE, Common File Format and Media Formats Specifications, Version 1.0.3, 3rd

January

2012.

[3] Ultra Violet, http://www.uvvu.com/.

25

[4] Trusted Logic, Trusted Foundations, http://www.tl-

mobility.com/spip.php?rubrique6&from=252.

[5] Trusted Logic, Trusted Show, http://www.tl-mobility.com/spip.php?rubrique48.

[6] ARM, http://www.arm.com/products/secure-services/index.php.

[7] Trusted Computing Group, http://www.trustedcomputinggroup.org/.

[8] Global Platform Standard, http://www.globalplatform.org/.

[9] Protected Interoperable File Format (PIFF) Specifications,

http://learn.iis.net/page.aspx/685/protected-interoperable-file-format/.

[10] W3C, Encrypted Media Extensions draft proposal, http://dvcs.w3.org/hg/html-media/raw-

file/tip/encrypted-media/encrypted-media.html.

[11] ISO/IECTR21000-1:2001, Information technology -- Multimedia framework (MPEG-21) --

Part 1: Vision, Technologies and Strategy".

[12] DTCP, http://www.dtcp.com/.

[13] Coral Consortium, http://www.coral-interop.org/.

[14] AACS, http://www.aacsla.com/home.

[15] CPRM/CPPM, http://www.4centity.com/.

[16] Content Scramble System, http://www.dvdcca.org/css.aspx

[17] DLNA, http://www.dlna.org/.

[18] MPEG-LA, http://www.mpegla.com/main/default.aspx.

[19] Cable Labs, http://www.cablelabs.com/.