Drm Ensuring Secure Content Protection Solutions for Next Generation Consumer Devices Final

Introduction �� 2

G&D MobiCore® and ARM® TrustZone® �� 3

DRM Threat Model �� 4

DRM Flow �� 4

DRM Assets �� 5

Threat Model �� 5

Protection of Assets �� 5

Security Infrastructure �� 6

Secure Boot �� 6

Secure Debug �� 6

Life Cycle State Management �� 6

Cryptography and Secure Storage �� 6

Provisioning �� 6

Hardware-assisted DRM Solution �� 7

Discretix and G&D Secure DRM Solution �� 9

Summary �� 12

Glossary �� 12

Digital Rights ManagementEnsuring Secure Content Protection Solutions for Next Generation Consumer Devices

Contents

The material in this document is proprietary to Discretix Technologies Ltd. and Giesecke & Devrient GmbH. Any unauthorized

reproduction of any part thereof is strictly prohibited. The contents of this document are believed to be accurate at the time

of distribution. Discretix as well as Giesecke & Devrient reserve the right to alter this information at any time without notice.

Today’s connected devices –

including smartphones, tab-

lets, web TVs, and hybrid

STBs – embody a new era in

consumer electronics, allow-

ing unparalleled access to

valuable content and numer-

ous new services to consum-

ers. In this new age of over-

the-top TV (OTT TV) and

mobile TV, device manufac-

turers and service providers

require robust content pro-

tection schemes that are

approved by studios, yet are

flexible enough to support

multiple business models and

new use cases. Companies

such as Netflix are driving re-

quirements for highly secure

DRM implementations on mo-

bile platforms. Content own-

ers will not allow distri bution

of their content via devices /

distribution systems which are

potentially corrupted.

The need for secure DRM

implementations is real, and

it is happening now. Secure

and robust DRM implementa-

tion, as defined by content

owners, is mandatory in order

to enable premium content

licensing by the service provid-

er. Such robust implementa-

tion requires an in-depth un-

derstanding of the security

vulnerabilities of today’s con-

nected devices. This white pa-

per explains what is required

to build a secure DRM solu-

tion and describes the joint

Discretix and G&D secure DRM

solution, based on ARM®

TrustZone® technology.

When building DRM agents

secured by MobiCore®, it is

also possible to fulfill the

needs of other security de-

manding stakeholders such

as payment service providers,

utilizing the same shared

resources. This white paper

describes a technical solution

to DRM using Discretix DRM

agents running on G&D Mobi-

Core® on ARM® TrustZone®

technology. A separate white

paper from G&D addresses

payment scheme technology

running on MobiCore® and

also describes the isolation

mechanisms in MobiCore®

that separate both security

schemes.

Introduction

Trustlet®

MobiCore®Rich OS

OS Applications

InternetDevice Security

Content Protection

Enterprise Security

Mobile Financial Services

Mobile Payment

2

• IsaTrustedExecutionEnvironment(TEE)andisbased

on the principle of isolation for ARM® TrustZone®

• IsbasedonapprovedG&Dmicrokerneltechnology

• Executessecurelydownloadednativecode

• Supportssecurecontainersformultiplethirdparties

with enhanced process isolation

• ProvideslightweightAPIforTrustlet® (service)

development

• Canbecombinedwithseveralothersecurity

technologies from G&D, e.g. Service Manager and

Secure Elements

G&D MobiCore® and ARM® TrustZone®

3

DRM Threat Model

In order to develop a DRM threat model, we start by reviewing a typical DRM flow. From this,

we identify the assets in a DRM system. Finally, we define against what attacks the DRM assets

should be protected.

Figure 1: DRM flow

Get DRM-protected content. The content is compressed content that is also encrypted as defined

by the specific DRM scheme used. The content may be streamed online, or may be stored on the

device storage.

Get the DRM license file associated with the content. The DRM license file is obtained from a DRM

server prior to consuming the content. The license file may be stored on the device storage. If the

license file is not found, the DRM client will try to get it online from a DRM server.

Process the DRM rules from the license file. An example of a DRM rule is that the content may be

played only five times, as in the case of content that has been loaded for rental.

Extract the content encryption key (CEK) from the license file. This is the key that is

used to decrypt the content.

Decrypt the content with the CEK. The output of this step is the compressed content

which is sent to the video decoder, i.e. the decrypted, compressed content.

The decoder renders the content, which is to say, uncompresses the content and plays

the video on the device display and the audio on the device speakers.

Mobile Device

SOC

DRM client

Encrypted, compressed

content

License file

Storage

Decrypted, compressed content

Decrypted, uncompressed content

Codec

1

4

2

5

3

6

Figure 1 illustrates a typical DRM flow.

DRM Flow

4

DRM Assets

The DRM flow described

above illustrates the elements

of the system that must be

protected in a secure DRM

system, i.e. the DRM assets.

1. The first set of assets that

must be protected contains

all the DRM private keys

and license files that are

permanently stored on the

device storage.

2. The second set of DRM as-

sets contains the temporary

keys. The CEKs that are

extracted from license files

during run-time are the

most common example of

temporary keys.

3. The third set of DRM assets

contains the decrypted

compressed content data

that is passed from the

DRM client to the codec.

This is actually the “native”

form of the content.

Note that DRM-protected

content files are not included

in the list of DRM assets. They

are protected by means of the

encryption as defined by the

DRM scheme.

Threat Model

The threat model defines

what kinds of attacks are

considered relevant and which

should be defeated or at least

hindered by the protection

mechanisms employed in a

solution. Thus, the threat

model defines the attacks that

are considered in the scope

of the solution. In general,

the threat model will exclude

attacks that are more expen-

sive to mount than the value

of the assets that may be ob-

tained, while also considering

potential attack scalability.

There may be other reasons

to exclude specific attacks

from the threat model.

In a DRM system, there are

two types of attacks that are

considered in the scope of

the threat model.

1. Software attacks.

This encompasses all at-

tacks mounted by software

techniques, including

attacks mounted by an

attacker that has root pri-

vileges in the system.

2. Hardware attacks.

This includes attacks

mounted by monitoring the

device hardware ports. In

some cases, this may also

include probing inter-chip

signals on the device PCB.

Protection of Assets

Having defined the list of

DRM assets that must be pro-

tected and the list of attacks

against which they must be

protected, we can summarize

the mechanisms used to pro-

tect the assets, as shown in

the following table.

Although decrypted, com-

pressed content must be pro-

tected, its protection has nor-

mally been considered out of

scope for DRM requirements,

or at most, has been consid-

ered a “soft” requirement.

However, as noted above in

the introduction, we have

recently seen a push for high-

security DRM implementa-

tions. The meaning of high

security is exactly the added

focus to protect decrypted,

compressed content as a strict

requirement.

It is important to understand

some details of the protection

mechanisms listed in the

table.

1. Secure storage. This is an

encrypted, integrity-pro-

tected database that is

stored on the device’s per-

manent storage. Access to

database items is controlled

by some form of authenti-

cation, which in the case of

DRM is the authentication

of the calling application.

2. Protected execution. This is

an execution environment

that is protected from the

host OS running on the de-

vice, i.e. programs running

in the host OS cannot

access the code and data

memory spaces of the pro-

tected execution environ-

ment.

3. Secure content path. This is

a data path from the DRM

client to the codec that

cannot be accessed by the

host OS.

Each of these mechanisms can

be implemented using soft-

ware or hardware techniques.

The implementation details

are described following the

next section which presents

some security infrastructure

requirements.

Our discussion to this point

has used a standard security

methodology to derive the

required mechanisms for a

highly-secure DRM implemen-

tation. However, the discus-

sion has focused on DRM-

specific details without consid-

ering general system security

aspects. In addition to the

requirements discussed above,

there are some fundamental

security modules that must be

present in any secure system.

These security modules are

required for the protection

of the entire system including

all of the DRM assets listed

above.

The following section provides

an overview of these security

infrastructure modules.

Asset Protection Mechanism

DRM keys and license files Secure storage

Temporary keys Protected execution

Decrypted, compressed content Secure content path

5

environment and provide

sufficient performance. More

details about cryptographic

engines are provided in the

following section.

The secure storage mecha-

nism is described above and

is further described in the

following section.

Provisioning

Provisioning refers to the

“personalization” of a device.

A device is personalized by

storing device-specific infor-

mation on the device before

it is released to the field. In

the context of DRM, this in-

cludes system-wide keys and

DRM private keys. The goal of

Security Infrastructure

Secure Boot

The first security infrastructure

module is secure boot. Secure

boot verifies the integrity and

authenticity of the system

code. It checks that the code

has not been modified since

device manufacture and also

that the code is a valid version

that originated from the de-

vice manufacturer. Secure

Boot should support autho-

rized software updates from

the device manufacturer.

Secure boot is essential for

any secure system to ensure

that the security mechanisms

embodied in the code are not

modified by an attacker. In

our context, one such attack

could be to modify the DRM

code to copy all decrypted

content to a removable mem-

ory card. In order to protect

the secure boot code itself

from modification, this mod-

ule is normally stored in ROM

in the SOC. This forms a Root

of Trust for the system.

Secure Debug

The complexity of devices

such as smartphones and

tablets requires debug capa-

bilities. Debug must be sup-

ported in the field as well as

during the software develop-

ment phase. However, since

debuggers enable the reading

of all memory locations as

well as CPU registers, this

capability can be used to ex-

tract secret information from

the system. An attacker can

start a DRM operation and

then initiate a debug session

to read out keys or content.

Secure debug prevents this

attack by restricting in-field

debug to authorized debug-

gers. Before a standard debug

session can be started, the

secure debug module authen-

ticates the debugger to verify

that it is allowed to enter the

debug session.

ARM® TrustZone® technology

also enables further possibili-

ties to partition access control

by allowing separate debug

controls for security sensitive

software running in a TEE.

Life Cycle State

Management

A device goes through a num-

ber of life cycle states before

being released to the field.

The following table presents a

simplified life cycle state flow.

Since the life cycle state deter-

mines the security level of the

device, it must be kept secure.

The life cycle state is encoded

in an on-chip NVM.

Cryptography and Secure

Storage

A secure system must include

cryptographic engines as well

as a secure storage mecha-

nism. The cryptographic

engines must run in a secure

a provisioning solution is to

send the device-specific infor-

mation securely to the device.

A provisioning server protects

the information by encrypting

it and sending it to the device.

The provisioning client in the

device receives the encrypted

device-specific information,

decrypts it, and stores it in the

secure storage database.

G&D may also securely pro-

vision the DRM agents and

personalize the device in the

field, in a similar manner to

provisioning a payment appli-

cation. Further information

can be found in a separate

white paper available from

G&D.

Life Cycle State Associated Functionality

Chip manufacture Full debug capability allowed.

Enable secure provisioning of chip

vendor secrets.

Device manufacture Most debug capability allowed.

Enable secure provisioning of

device manufacturer secrets.

Secure (in field) Only authorized debug sessions

allowed. Add user secrets via

security protocols.

Failure analysis Full debug capability allowed. All

secret information is wiped from

the device.

6

Figure 2 presents a diagram

of a high-security, hardware-

assisted DRM solution. The

hardware-assisted solution is

based on a Trusted Execution

Environment (TEE). The TEE is

separated from the host OS

by means of hardware. This

ensures that the host OS, and

malicious applications running

in it, cannot read from the

secure memory, which is dedi-

cated to the TEE and cannot

observe the program flow of

the TEE CPU. One example

of a hardware-based TEE is

G&D’s MobiCore® running on

ARM® TrustZone® technology.

The DRM client is partitioned

into security-critical and non-

critical parts. The security-

critical part of the DRM client

is executed in the TEE and the

non-critical part is executed

by the host OS.

For premium content that

requires high bandwidth, a

hardware codec is normally

used in the solution. The

hardware data engine of the

codec is secured by placing

it in the secure environment,

thus forming a secure content

path. The codec control code

may run in the host OS.

Figure 2: Hardware-assisted DRM

The decrypted, uncompressed

content is rendered on the

device display and speakers.

Alternately, the decrypted,

compressed content can be

passed to a link protection

client such as DTCP-IP or

HDCP 2.0 for transfer to

another device for rendering1.

1 The link protection client can also trans-

mit the uncompressed content from the

HW codec output.

Hardware-assisted DRM Solution

DRM client

OS / SW level

HW level

DRM rule enforcement

Key management

Content decryption Codec data engine

Codec control

Crypto engines Secure storage


Decrypted, uncompressed content


content

7

1. All DRM keys and license

files are stored in the se-

cure storage database. The

database is encrypted and

integrity-protected with

hardware keys that are

only accessible from within

the TEE.

2. When the DRM keys and

license files are loaded by

the DRM client into the TEE

secure memory space, they

are protected from being

read by any processes run-

ning in the host OS. CEKs

are extracted from the li-

cense file and only exist in

the clear in the TEE secure

memory space.

Figure 3: Hardware-assisted DRM with link protection

3. The decryption of the DRM

content is done by hard-

ware crypto engines that

are located in the TEE. The

CEK is loaded by the DRM

client directly from the TEE

secure memory space

into the crypto engine

and cannot be read from

the host OS.

4. The decrypted, compressed

content is sent from the

hardware crypto engines in

the TEE to the codec data

engine in the TEE. This data

transfer is protected from

the host OS by the TEE

hardware protection. As

mentioned above, an alter-

nate solution is to transfer

the decrypted, compressed

content from the DRM cli-

ent to a link protection cli-

ent such as DTCP-IP which

is also running in the TEE.

The link protection client

transfers the decrypted

content to another device

for rendering. Figure 3

shows a solution with link

protection.

DRM client

OS / SW level

HW level

DRM rule enforcement

Key management

Content decryption Link protection

Crypto engines Secure storage


Link protection encrypted, compressed content


content

This solution addresses all of the DRM requirements.

8

Discretix and G&D are cooper-

ating to provide a joint solu-

tion for a secure DRM imple-

mentation based on ARM®

TrustZone® technology. This

white paper shows an imple-

mentation of the Microsoft

PlayReady DRM scheme, but

the solution can be extended

to other DRM schemes as

well.

1. Secure boot.

Secure boot verifies the in-

tegrity and authenticity of

the system code.

2. Cryptographic services.

The cryptographic services

module accesses the

platform’s cryptographic

engines via a hardware

abstraction layer.

3. Key management.

The Key management

module generates crypto-

graphic keys, stores them

securely, and enforces their

proper usage.

4. Certificate handling.

Certi ficate handling in-

cludes parsing digital certif-

icates and verifying their

authenticity.

5. Provisioning client.

Provisioning is described

above in the Security

Infrastructure section. In

PlayReady, provisioned in-

formation includes private

keys such as model private

keys and certificates such

as device certificates.

6. Secure keypad / Secure

touchpad.

MobiCore® can exclusively

access the keypad or the

touchpad respectively to

control all user inputs. This

ensures that no malware

can get access to a PIN or

password, for example,

for authentication of a

payment.

7. TEE.

As mentioned above,

MobiCore® is a secure OS

in which security appli-

cations, called Trustlets®,

Discretix and G&D Secure DRM Solution

Figure 4: Secure PlayReady DRM solution

Normal World – NWd Secure World – SWd

Discretix PlayReady Application

MobiCore® Driver

Discretix PlayReady (Security-critical) (Trustlet®)

Certificate Handling

Cryptographic Services

Key Management

Provisioning Client

Hardware Abstraction Layer

Cryptographic Engines

HW Codec

Touchpad Driver

MobiCore® TEE

Secure Storage (Trustlet®)

Secure UI (Trustlet®)

Figure 4 presents a block

diagram of the secure DRM

solution. The G&D MobiCore®

is a TEE that runs over ARM®


MobiCore® provides the basic

security services required for

security applications. In addi-

tion, MobiCore® is a secure OS

in which secure applications,

called Trustlets®, can run.

can run in a non-blocking

manner. The Trustlets® have

access to their own memo-

ry space, not accessible

from the Normal World

(NWd).

8. Container-based separation

ensures that Trustlets®

owned by each stakeholder

in the MobiCore® environ-

ment remain separated

from other Trustlets® placed

in other containers owned

by payment service provid-

ers

The MobiCore® security functions include:

9

Discretix adds two Trustlets®

in a container to MobiCore®

to complete the secure

PlayReady implementation.

First is the secure storage,

which implements the secure

storage functionality described

above.

The second Trustlet® is

the security-critical part of

the PlayReady client. The

PlayReady Trustlet® includes

the Blackbox and certificate-

generation functionality. The

PlayReady client that runs in

the Normal World includes

Figure 5. Content encryption key preparation

the non security-critical

functionality.

The secure PlayReady solution

is completed with a secure

content path to the codec.

This is shown in figure 4 by

the HW codec in the Secure

World.

Figures 5 and 6 present some

example data flows to show

how the solution works. Fig-

ure 5 is a flow diagram that

shows the sequence followed

when the PlayReady client

prepares a content encryption

key in the TEE.

1. This flow is triggered by

some user action request-

ing the consumption of

protected content.

2. The PlayReady application

checks if the domain pri-

vate key has already been

extracted. If not, it calls the

PlayReady Trustlet® to get

the domain private key.

3. The secure storage

Trustlet® gets the domain

private key from the secure

storage database in exter-

nal flash memory. It calls

the MobiCore® crypto-

graphic services to decrypt

and authenticate the key

object.

4. MobiCore® stores the

domain private key in the

TEE secure memory.

5. The license file is retrieved

from the general filesystem.

The PlayReady Trustlet®

calls the MobiCore® crypto-


the license file with domain

private key.

6. The PlayReady Trustlet® ex-

tracts the content encryp-

tion key from the license

file and calls MobiCore® to

store it in the TEE secure

memory.

Extern

al flash

PlayReady client

PlayReady and secu

re

stora

ge Trustl

ets®

MobiCore

® TEE

Secure storage database

General filesystem

Decrypt and authenticate secure storage

Process license using the private key

Read encrypted key from secure storage

AES-CBC, AES-MAC

HASH, ECC

Prepare private key

Store private key

Store content key

Private key ready

Content key ready

Prepare private key

Private key kept in secure RAM

Content key kept in secure RAM

The following operations are executed in preparing the content encryption key:

10

Figure 6 is a flow diagram that shows the sequence followed

for content rendering once the content encryption key has

been prepared.

Figure 6. Content rendering

1. The content file is loaded

from the general filesystem.

Note that PlayReady sup-

ports other content ren-

dering scenarios such as

streaming and content de-

cryption while downloading

the content.

2. The PlayReady Trustlet®

calls the MobiCore® crypto-


the content with the con-

tent encryption key.

3. The decrypted content is

copied directly to the HW

Codec in the Secure World

using the secure content

path. Note that in the link

protection use case, the

decrypted content is copied

to the link protection client

for re-encryption according

to the link protection en-

cryption scheme2.

4. The HW codec uncom-

presses the content and

outputs it to the device

display.

2 The link protection client can also transmit the uncompressed content

from the HW codec output.

Extern

al flash

PlayReady client

PlayReady and secu

re

stora

ge Trustl

ets®

MobiCore

® TEE

General filesystem Decrypt content file

Load content file

Crypto services

Uncompress content

Render content

Render content

Output content to codec

Decrypted content in secure RAM

HW codec

The following operations are executed in content rendering.

11

288

6233

BR

_Mob

iCor

e D

RM_j

ul11

_E

ZD

C

PDF

Giesecke & Devrient GmbH

Prinzregentenstrasse 159

P.O. Box 80 07 29

81677 Munich

GERMANY

www.gi-de.com

[email protected]

Discretix Technologies Ltd.

[email protected]

www.discretix.com

ARM Ltd - [email protected]

© Giesecke & Devrient GmbH, 2011. MobiCore® and Trustlet® are registered trademarks of Giesecke & Devrient. ARM® and Discretix are coauthors of this white paper. All other trademarks and service marks are the property of their respective owners. All technical data subject to change without notice. G&D patents.

The world of content is expe-

riencing exciting new develop-

ments with the availability of

premium content on multiple,

high-performance devices. In

order to enjoy this premium

content, there is a strong re-

quirement from the content

owners for high-security im-

plementations of DRM

CEK Content encryption key

DRM Digital rights management

NVM Non-volatile memory

OTT Delivery Over-the-top delivery – refers to direct streaming of content over the Internet

OS Operating system

PCB Printed circuit board

ROM Read-only memory

SOC System on chip

TEE Trusted Execution Environment

schemes on these devices.

This white paper develops

the threat model for a DRM

solution. We presented an

HW-based solution based

on Discretix PlayReady DRM,

G&D MobiCore® and ARM®


The joint solution is a highly

secure PlayReady client that

meets the most stringent

security requirements for a

DRM solution, while address-

ing new business models

such as easy pay-as-you-go

premium content delivery.

Summary

Glossary

Documents

Drm Ensuring Secure Content Protection Solutions for Next Generation Consumer Devices Final