Digital Rights Management

Ensuring Secure Content Protection Solutions for Next Generation Consumer Devices

Contents

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

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.

Introduction

OS Applications

Trustlet

Content Protection

Enterprise Security

Mobile Financial Services

Rich OS

MobiCore Device Security Internet Mobile Payment

Todays connected devices including smartphones, tablets, web TVs, and hybrid STBs embody a new era in consumer electronics, allowing unparalleled access to valuable content and numerous new services to consumers. In this new age of overthe-top TV (OTT TV) and mobile TV, device manufacturers and service providers require robust content protection 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 requirements for highly secure DRM implementations on mobile platforms. Content owners will not allow distribution

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 implementation, as defined by content owners, is mandatory in order to enable premium content licensing by the service provider. Such robust implementation requires an in-depth understanding of the security vulnerabilities of todays connected devices. This white paper explains what is required to build a secure DRM solution 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 demanding 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 MobiCore 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.

G&D MobiCore and ARM TrustZone

Is a Trusted Execution Environment (TEE) and is based on the principle of isolation for ARM TrustZone Is based on approved G&D microkernel technology Executes securely downloaded native code Supports secure containers for multiple third parties with enhanced process isolation Provides lightweight API for Trustlet (service) development Can be combined with several other security technologies from G&D, e.g. Service Manager and Secure Elements

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. DRM Flow Figure 1 illustrates a typical DRM flow.

1 2 3

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.

Encrypted, compressed content

Storage License file

DRM client

Decrypted, compressed content

Codec

Decrypted, uncompressed content

SOC Mobile Device

4 5 6
Figure 1: DRM flow

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. 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 assets 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 expensive to mount than the value of the assets that may be obtained, 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 attacks mounted by software techniques, including attacks mounted by an attacker that has root privileges 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 protected and the list of attacks against which they must be protected, we can summarize the mechanisms used to protect the assets, as shown in the following table. Although decrypted, compressed content must be protected, its protection has normally been considered out of scope for DRM requirements, or at most, has been considered a soft requirement. However, as noted above in the introduction, we have recently seen a push for high-

security DRM implementations. 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-protected database that is stored on the devices permanent storage. Access to database items is controlled by some form of authentication, 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 device, i.e. programs running in the host OS cannot access the code and data memory spaces of the protected execution environment. 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 software 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 implementation. However, the discussion has focused on DRMspecific details without considering 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
DRM keys and license files Temporary keys Decrypted, compressed content

Protection Mechanism
Secure storage Protected execution Secure content path

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 device manufacturer. Secure Boot should support authorized 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 memory card. In order to protect the secure boot code itself from modification, this module 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 capabilities. Debug must be supported in the field as well as during the software development 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 debuggers. Before a standard debug session can be started, the secure debug module authenticates the debugger to verify that it is allowed to enter the debug session. ARM TrustZone technology also enables further possibilities 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 number 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 determines 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 mechanism. The cryptographic engines must run in a secure

environment and provide sufficient performance. More details about cryptographic engines are provided in the following section. The secure storage mechanism 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 information on the device before it is released to the field. In the context of DRM, this includes system-wide keys and DRM private keys. The goal of

a provisioning solution is to send the device-specific information 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 provision the DRM agents and personalize the device in the field, in a similar manner to provisioning a payment application. Further information can be found in a separate white paper available from G&D.

Life Cycle State Chip manufacture

Associated Functionality Full debug capability allowed. Enable secure provisioning of chip vendor secrets. Most debug capability allowed. Enable secure provisioning of device manufacturer secrets. Only authorized debug sessions allowed. Add user secrets via security protocols. Full debug capability allowed. All secret information is wiped from the device.

Device manufacture

Secure (in field)

Failure analysis

Hardware-assisted DRM Solution

Figure 2 presents a diagram of a high-security, hardwareassisted 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 dedicated to the TEE and cannot observe the program flow of the TEE CPU. One example of a hardware-based TEE is G&Ds MobiCore running on ARM TrustZone technology.

The DRM client is partitioned into security-critical and noncritical parts. The securitycritical 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.

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.

The link protection client can also transmit the uncompressed content from the HW codec output.

Encrypted, compressed content

OS / SW level

DRM client
Codec control DRM rule enforcement Key management Content decryption Decrypted, compressed content Crypto engines Secure storage Codec data engine Decrypted, uncompressed content

HW level
Figure 2: Hardware-assisted DRM

This solution addresses all of the DRM requirements. 1. All DRM keys and license files are stored in the secure 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 running in the host OS. CEKs are extracted from the license file and only exist in the clear in the TEE secure memory space. 3. The decryption of the DRM content is done by hardware 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 alternate solution is to transfer the decrypted, compressed content from the DRM client to a link protection client 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.

Encrypted, compressed content

OS / SW level

DRM client
DRM rule enforcement Key management Content decryption Decrypted, compressed content Crypto engines Secure storage Link protection Link protection encrypted, compressed content

HW level
Figure 3: Hardware-assisted DRM with link protection

Discretix and G&D Secure DRM Solution

Discretix and G&D are cooperating to provide a joint solution for a secure DRM implementation based on ARM TrustZone technology. This white paper shows an implementation of the Microsoft PlayReady DRM scheme, but the solution can be extended to other DRM schemes as well.

Figure 4 presents a block diagram of the secure DRM solution. The G&D MobiCore is a TEE that runs over ARM TrustZone technology. MobiCore provides the basic security services required for security applications. In addition, MobiCore is a secure OS in which secure applications, called Trustlets, can run.

Normal World NWd

Discretix PlayReady Application

Secure World SWd

Discretix PlayReady (Security-critical) (Trustlet)

Secure Storage (Trustlet) Touchpad Driver Secure UI (Trustlet) MobiCore TEE

Certificate Handling Cryptographic Services Key Management Provisioning Client

MobiCore Driver

Hardware Abstraction Layer Cryptographic Engines HW Codec

Figure 4: Secure PlayReady DRM solution

The MobiCore security functions include: 1. Secure boot. Secure boot verifies the integrity and authenticity of the system code. 2. Cryptographic services. The cryptographic services module accesses the platforms cryptographic engines via a hardware abstraction layer. 3. Key management. The Key management module generates cryptographic keys, stores them securely, and enforces their proper usage. 4. Certificate handling. Certificate handling includes parsing digital certificates and verifying their authenticity. 5. Provisioning client. Provisioning is described above in the Security Infrastructure section. In PlayReady, provisioned information 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 applications, called Trustlets, can run in a non-blocking manner. The Trustlets have access to their own memory space, not accessible from the Normal World (NWd). 8. Container-based separation ensures that Trustlets owned by each stakeholder in the MobiCore environment remain separated from other Trustlets placed in other containers owned by payment service providers

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 certificategeneration functionality. The PlayReady client that runs in the Normal World includes

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. Figure 5 is a flow diagram that shows the sequence followed when the PlayReady client prepares a content encryption key in the TEE.

The following operations are executed in preparing the content encryption key: 1. This flow is triggered by some user action requesting the consumption of protected content. 2. The PlayReady application checks if the domain private 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 external flash memory. It calls the MobiCore cryptographic 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 cryptographic services to decrypt the license file with domain private key. 6. The PlayReady Trustlet extracts the content encryption key from the license file and calls MobiCore to store it in the TEE secure memory.

Ex

te

l na

fla

sh yR ea dy

e cli

nt

a Pl

re cu se lets d st an ru dy ge T ea a yR or la st P

ob

iC

e or

TE

Prepare private key Read encrypted key from secure storage Secure storage database Decrypt and authenticate secure storage AES-CBC, AES-MAC

Store private key Private key kept in secure RAM

Private key ready Prepare private key Process license using the private key

General filesystem

HASH, ECC

Store content key Content key kept in secure RAM Content key ready

Figure 5. Content encryption key preparation

10

Figure 6 is a flow diagram that shows the sequence followed for content rendering once the content encryption key has been prepared.

The following operations are executed in content rendering. 1. The content file is loaded from the general filesystem. Note that PlayReady supports other content rendering scenarios such as streaming and content decryption while downloading the content. 2. The PlayReady Trustlet calls the MobiCore cryptographic services to decrypt the content with the content 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 encryption scheme2. 4. The HW codec uncompresses 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.

Ex

te

l na

fla

sh yR ea dy

e cli

nt

a Pl

re cu se lets d st an ru dy ge T ea a yR or la st P

ob

iC

e or

TE

Render content Load content file

General filesystem

Decrypt content file

Crypto services

Decrypted content in secure RAM Output content to codec HW codec

Uncompress content Render content

Figure 6. Content rendering

11

Summary

The world of content is experiencing exciting new developments with the availability of premium content on multiple, high-performance devices. In order to enjoy this premium content, there is a strong requirement from the content owners for high-security implementations of DRM

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 TrustZone technology. The joint solution is a highly secure PlayReady client that

meets the most stringent security requirements for a DRM solution, while addressing new business models such as easy pay-as-you-go premium content delivery.

Glossary

Giesecke & Devrient GmbH Prinzregentenstrasse 159 P.O. Box 80 07 29 81677 Munich GERMANY www.gi-de.com mobicore@gi-de.com Discretix Technologies Ltd. marketing-dx@discretix.com www.discretix.com ARM Ltd - TrustZone@arm.com
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.

CEK DRM NVM OTT Delivery OS PCB ROM SOC TEE

Content encryption key Digital rights management Non-volatile memory Over-the-top delivery refers to direct streaming of content over the Internet Operating system Printed circuit board Read-only memory System on chip Trusted Execution Environment

288 6233 BR_MobiCore DRM_jul11_E ZDC PDF