SlideShare a Scribd company logo
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 Management
of DRM
Rights Encoding
Mechanism
( Rights Expression Language or Virtual Machine)
Key Management
System
Content Packaging Format
and 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 transcribed
Securely & consistently
Should be transferred
securely
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 or
Other content
application
DTCP client
Protected link to a
number of devices
in home.
Content sharing of content from a home device
to 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 License
Server1
3
2
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 FamilyDECE A/C”
FamilyTV
FamilyPC Family PVR
“Alice Smith”
“Carol Smith”“Bob Smith”
Shareddevices
Tablet Smartphone
Individuallyowneddevices
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 downloads
the License in native DRM format
of the DRM scheme supported in the
Device from the retailer.
Media Player
Smart Phone
Tablet
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 Server
Hosting DRM protected Content and
Downloadable DRM agent.
Secure Area with
Anti-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
Secure
UI
Secure
Clock
Secure
Crypto
Trusted Platform Architecture
Based on Global Platform’s TEE
Client API specifications
Distribution
Server
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 World
Privileged Mode
Secure World
User Mode
Normal World
User Mode
Normal World
Privileged 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/.

More Related Content

Similar to DRM_Interoperability_Final

12 - Sanjeev Verma_mod2
12 - Sanjeev Verma_mod212 - Sanjeev Verma_mod2
12 - Sanjeev Verma_mod2
Sanjeev Verma, PhD
 
Digital Rights Management
Digital Rights Management Digital Rights Management
Digital Rights Management
Muruli N. Tarikere
 
Digital Rights Management PPT
Digital Rights Management PPTDigital Rights Management PPT
Digital Rights Management PPT
Suresh Khutale
 
digital rights management for multimedia files
digital rights management for multimedia filesdigital rights management for multimedia files
digital rights management for multimedia files
Apurva Vyas
 
DRM Basics With Irdeto and Bitmovin
DRM Basics With Irdeto and BitmovinDRM Basics With Irdeto and Bitmovin
DRM Basics With Irdeto and Bitmovin
Bitmovin Inc
 
What is Digital Rights Management System and How does it work : Ameva Tech
What is Digital Rights Management System and How does it work : Ameva TechWhat is Digital Rights Management System and How does it work : Ameva Tech
What is Digital Rights Management System and How does it work : Ameva Tech
Ameva Tech
 
What is DRM, Types of DRM
What is DRM, Types of DRMWhat is DRM, Types of DRM
What is DRM, Types of DRM
Jarom Joseph
 
Digital Right Management
Digital Right ManagementDigital Right Management
Digital Right Management
Ratul Alahy
 
What is DRM?
What is DRM? What is DRM?
Paper id 2120145
Paper id 2120145Paper id 2120145
Paper id 2120145
IJRAT
 
Movie labs enhanced content protection
Movie labs enhanced content protectionMovie labs enhanced content protection
Movie labs enhanced content protection
Karthikeyan Logantha Chandramohan
 
Digital Libraries
Digital LibrariesDigital Libraries
Digital Libraries
Himanshu Chandra
 
2021091518365700015701 mdia6055 digital auvi streaming session 17_18 (1)
2021091518365700015701 mdia6055 digital auvi streaming   session 17_18 (1)2021091518365700015701 mdia6055 digital auvi streaming   session 17_18 (1)
2021091518365700015701 mdia6055 digital auvi streaming session 17_18 (1)
IhzaNugroho
 
Video Streaming across wide area networks
Video Streaming across wide area networksVideo Streaming across wide area networks
Video Streaming across wide area networks
Videoguy
 
Federated DRM for Arkib Negara Malaysia
Federated DRM for Arkib Negara MalaysiaFederated DRM for Arkib Negara Malaysia
Federated DRM for Arkib Negara Malaysia
Azri Jamil
 
Wibu systems-code metersoftwareprotection
Wibu systems-code metersoftwareprotectionWibu systems-code metersoftwareprotection
Wibu systems-code metersoftwareprotection
Himanshu Arora
 
Vdrm presentation
Vdrm   presentationVdrm   presentation
Vdrm presentation
RanjithaS25
 
WDSI 2015-Design and Implementation of a Policy-based Service-oriented DRM Sy...
WDSI 2015-Design and Implementation of a Policy-based Service-oriented DRM Sy...WDSI 2015-Design and Implementation of a Policy-based Service-oriented DRM Sy...
WDSI 2015-Design and Implementation of a Policy-based Service-oriented DRM Sy...
育弘 林
 
journal in research
journal in research journal in research
journal in research
graphicdesigner79
 
journal published
journal publishedjournal published
journal published
graphicdesigner79
 

Similar to DRM_Interoperability_Final (20)

12 - Sanjeev Verma_mod2
12 - Sanjeev Verma_mod212 - Sanjeev Verma_mod2
12 - Sanjeev Verma_mod2
 
Digital Rights Management
Digital Rights Management Digital Rights Management
Digital Rights Management
 
Digital Rights Management PPT
Digital Rights Management PPTDigital Rights Management PPT
Digital Rights Management PPT
 
digital rights management for multimedia files
digital rights management for multimedia filesdigital rights management for multimedia files
digital rights management for multimedia files
 
DRM Basics With Irdeto and Bitmovin
DRM Basics With Irdeto and BitmovinDRM Basics With Irdeto and Bitmovin
DRM Basics With Irdeto and Bitmovin
 
What is Digital Rights Management System and How does it work : Ameva Tech
What is Digital Rights Management System and How does it work : Ameva TechWhat is Digital Rights Management System and How does it work : Ameva Tech
What is Digital Rights Management System and How does it work : Ameva Tech
 
What is DRM, Types of DRM
What is DRM, Types of DRMWhat is DRM, Types of DRM
What is DRM, Types of DRM
 
Digital Right Management
Digital Right ManagementDigital Right Management
Digital Right Management
 
What is DRM?
What is DRM? What is DRM?
What is DRM?
 
Paper id 2120145
Paper id 2120145Paper id 2120145
Paper id 2120145
 
Movie labs enhanced content protection
Movie labs enhanced content protectionMovie labs enhanced content protection
Movie labs enhanced content protection
 
Digital Libraries
Digital LibrariesDigital Libraries
Digital Libraries
 
2021091518365700015701 mdia6055 digital auvi streaming session 17_18 (1)
2021091518365700015701 mdia6055 digital auvi streaming   session 17_18 (1)2021091518365700015701 mdia6055 digital auvi streaming   session 17_18 (1)
2021091518365700015701 mdia6055 digital auvi streaming session 17_18 (1)
 
Video Streaming across wide area networks
Video Streaming across wide area networksVideo Streaming across wide area networks
Video Streaming across wide area networks
 
Federated DRM for Arkib Negara Malaysia
Federated DRM for Arkib Negara MalaysiaFederated DRM for Arkib Negara Malaysia
Federated DRM for Arkib Negara Malaysia
 
Wibu systems-code metersoftwareprotection
Wibu systems-code metersoftwareprotectionWibu systems-code metersoftwareprotection
Wibu systems-code metersoftwareprotection
 
Vdrm presentation
Vdrm   presentationVdrm   presentation
Vdrm presentation
 
WDSI 2015-Design and Implementation of a Policy-based Service-oriented DRM Sy...
WDSI 2015-Design and Implementation of a Policy-based Service-oriented DRM Sy...WDSI 2015-Design and Implementation of a Policy-based Service-oriented DRM Sy...
WDSI 2015-Design and Implementation of a Policy-based Service-oriented DRM Sy...
 
journal in research
journal in research journal in research
journal in research
 
journal published
journal publishedjournal published
journal published
 

More from Sanjeev Verma, PhD

Blockchain Technology: Adoption Challenges, Platform and Applications
Blockchain Technology: Adoption Challenges, Platform and ApplicationsBlockchain Technology: Adoption Challenges, Platform and Applications
Blockchain Technology: Adoption Challenges, Platform and Applications
Sanjeev Verma, PhD
 
Blockchain Technology: Adoption Challenges, Platform and Applications
Blockchain Technology: Adoption Challenges, Platform and ApplicationsBlockchain Technology: Adoption Challenges, Platform and Applications
Blockchain Technology: Adoption Challenges, Platform and Applications
Sanjeev Verma, PhD
 
Evolution Of The Web Platform & Browser Security
Evolution Of The Web Platform & Browser SecurityEvolution Of The Web Platform & Browser Security
Evolution Of The Web Platform & Browser Security
Sanjeev Verma, PhD
 
Blockchain: Bitcoin and Beyond
Blockchain: Bitcoin and BeyondBlockchain: Bitcoin and Beyond
Blockchain: Bitcoin and Beyond
Sanjeev Verma, PhD
 
BlockchainIntro.com
BlockchainIntro.comBlockchainIntro.com
BlockchainIntro.com
Sanjeev Verma, PhD
 
FIDOAlliance
FIDOAllianceFIDOAlliance
FIDOAlliance
Sanjeev Verma, PhD
 
Basics of the Web Platform
Basics of the Web PlatformBasics of the Web Platform
Basics of the Web Platform
Sanjeev Verma, PhD
 
BlockchainPaper
BlockchainPaperBlockchainPaper
BlockchainPaper
Sanjeev Verma, PhD
 
GlobalPlatform_Premium_Content_WhitePaper2015
GlobalPlatform_Premium_Content_WhitePaper2015GlobalPlatform_Premium_Content_WhitePaper2015
GlobalPlatform_Premium_Content_WhitePaper2015
Sanjeev Verma, PhD
 

More from Sanjeev Verma, PhD (9)

Blockchain Technology: Adoption Challenges, Platform and Applications
Blockchain Technology: Adoption Challenges, Platform and ApplicationsBlockchain Technology: Adoption Challenges, Platform and Applications
Blockchain Technology: Adoption Challenges, Platform and Applications
 
Blockchain Technology: Adoption Challenges, Platform and Applications
Blockchain Technology: Adoption Challenges, Platform and ApplicationsBlockchain Technology: Adoption Challenges, Platform and Applications
Blockchain Technology: Adoption Challenges, Platform and Applications
 
Evolution Of The Web Platform & Browser Security
Evolution Of The Web Platform & Browser SecurityEvolution Of The Web Platform & Browser Security
Evolution Of The Web Platform & Browser Security
 
Blockchain: Bitcoin and Beyond
Blockchain: Bitcoin and BeyondBlockchain: Bitcoin and Beyond
Blockchain: Bitcoin and Beyond
 
BlockchainIntro.com
BlockchainIntro.comBlockchainIntro.com
BlockchainIntro.com
 
FIDOAlliance
FIDOAllianceFIDOAlliance
FIDOAlliance
 
Basics of the Web Platform
Basics of the Web PlatformBasics of the Web Platform
Basics of the Web Platform
 
BlockchainPaper
BlockchainPaperBlockchainPaper
BlockchainPaper
 
GlobalPlatform_Premium_Content_WhitePaper2015
GlobalPlatform_Premium_Content_WhitePaper2015GlobalPlatform_Premium_Content_WhitePaper2015
GlobalPlatform_Premium_Content_WhitePaper2015
 

DRM_Interoperability_Final

  • 1. 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. 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. 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. 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. 5 Trust Management of DRM Rights Encoding Mechanism ( Rights Expression Language or Virtual Machine) Key Management System Content Packaging Format and 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. 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 transcribed Securely & consistently Should be transferred securely 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. 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. 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 or Other content application DTCP client Protected link to a number of devices in home. Content sharing of content from a home device to 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. 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. 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 License Server1 3 2 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. 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. 12 “Smith FamilyDECE A/C” FamilyTV FamilyPC Family PVR “Alice Smith” “Carol Smith”“Bob Smith” Shareddevices Tablet Smartphone Individuallyowneddevices 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. 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. 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 downloads the License in native DRM format of the DRM scheme supported in the Device from the retailer. Media Player Smart Phone Tablet TV Figure 7 DRM Interoperability in DECE eco-system.
  • 15. 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. 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. 17 Graphics CPU Applications (Browser) DRM Agent Media Player Secure Trusted Platform HDCP Display Distribution Server Hosting DRM protected Content and Downloadable DRM agent. Secure Area with Anti-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. 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. 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 Secure UI Secure Clock Secure Crypto Trusted Platform Architecture Based on Global Platform’s TEE Client API specifications Distribution Server 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. 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. 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 World Privileged Mode Secure World User Mode Normal World User Mode Normal World Privileged Mode Secure Monitor Normal World Secure World Figure 10 Trust Zone Architecture [6].
  • 22. 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. 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. 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. 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/.