Overview of Motorola IP Rights Management (IPRM) System: … · Overview of Motorola IPRM System...

Overview of Motorola

IP Rights Management (IPRM) System:

Content Protection for Home Networks

(IPRM-HN)

Version 1.3

11 March 2010

MOTOROLA, the Stylized M Logo and all other trademarks indicated as such herein are trademarks of Motorola,

Inc. ® Reg. U.S. Pat. & Tm. Off. All other product or service names are the property of their respective owners.

Copyright © 2000-2010 Motorola, Inc. All rights reserved.

Overview of Motorola IPRM System (IPRM-HN)

Motorola, Inc. 2

Table of Contents

1. Introduction................................................................................................................. 4

1.1 Acronyms............................................................................................................ 4

1.2 References........................................................................................................... 6

2. IPRM Overview.......................................................................................................... 8

2.1 Security for Persistent Content ........................................................................... 8

2.2 In-Home Content Re-Distribution .................................................................... 10

2.2.1 Sharing Content in the Home Domain...................................................... 10

2.2.2 Domain Management................................................................................ 11

2.2.3 Remote Access to Content in the Home Domain ..................................... 11

3. IPRM Architecture.................................................................................................... 12

3.1 Local DVR Protection....................................................................................... 12

3.1.1 Secure Recording ...................................................................................... 12

3.1.2 Secure Playback ........................................................................................ 13

3.2 Home Network Content Sharing....................................................................... 14

3.2.1 Content Streaming in the Home Network................................................. 14

3.2.2 Content Copying in the Home Network ................................................... 15

3.2.3 Content Transcoding................................................................................. 16

3.2.4 Remote Streaming from the Home Network ............................................ 17

3.3 Security Algorithms .......................................................................................... 17

3.4 Rights Binding and Translation ........................................................................ 18

3.4.1 Supported Inputs ....................................................................................... 18

3.4.1.1 CableCARD Input................................................................................. 18

3.4.1.2 Conditional Access System Input ......................................................... 19

3.4.1.3 Free-to-Air Terrestrial Input ................................................................. 19

3.4.1.4 Analog Inputs........................................................................................ 19

3.4.1.5 DTCP Input........................................................................................... 20

3.4.2 Authorized Outputs................................................................................... 20

3.4.2.1 DTCP Output ........................................................................................ 20

3.4.2.2 DVI and HDMI/HDCP Output ............................................................. 20

3.4.2.3 Analog Output....................................................................................... 20

3.4.2.4 Persistent Bound Storage ...................................................................... 20

3.4.2.5 Persistent Portable Storage ................................................................... 21

3.4.3 IPRM Mapping of Copy Control Bits....................................................... 21

3.5 Content Protection Profiles ............................................................................... 21

3.5.1 Content Protection for MPEG-2 Transport Packet Payloads.................... 21

3.5.2 Content Protection for Generic RTP Payloads ......................................... 21

3.5.3 Content Protection for MP4 Files ............................................................. 21

3.5.4 Generic IPRM Message Encapsulation .................................................... 21

3.6 Key Management & Domain Control............................................................... 22

3.6.1 Support for Multiple DVRs ...................................................................... 23

3.6.2 Limits on an IPRM-Protected Domain ..................................................... 23

3.7 DLNA Support.................................................................................................. 23

3.8 Certificate Management.................................................................................... 24

3.9 Revocation ........................................................................................................ 24


Motorola, Inc. 3

4. IPRM Obligations ..................................................................................................... 24


Motorola, Inc. 4

1. Introduction Motorola provides a complete standards-based end-to-end scalable Digital Rights

Management (DRM) system for delivery, storage and in-home distribution of digital

content over IP networks using file-based delivery in MP4 file format or streaming

protocols such as Real-time Transport Protocol (RTP) and/or IP-encapsulated MPEG-2

Transport Streams.

The system has been developed based on Motorola’s long successful history of the

MediaCipher product line for cable and satellite conditional access systems (CAS) and

PacketCable security for Voice over IP (VoIP) of which Motorola was a leading author.

The IPRM system combines the strength and advantages of both systems applied

primarily to Video over IP distribution to achieve a flexible and secure end-to-end

content protection system.

IPRM has been designed to protect high-value content throughout its lifecycle. The

complete IPRM architecture enables protection of content starting with content authoring,

going through content management and distribution systems, edge streaming servers or

download servers, all the way to the consumer’s home network and the end device

intended for content consumption.

This document focuses on the subset of the IPRM architecture applicable to capturing,

persistently storing, outputting and displaying high-value content within a home

environment, including Digital Video Recorders (DVRs) and personal portable devices.

The details of the delivery of on-demand content to an in-home device and its eventual

consumption are described in [14].

IPRM has been approved by CableLabs for protection of high-value cable content on

Digital Video Recorders (DVR) and secure content redistribution in the home (see [10]

and [11] for details).

1.1 Acronyms

3DES Triple DES

AES Advanced Encryption Standard

API Application Programming Interface

APS Analog Protection System

ARIB Association of Radio Industries and Businesses

ATSC Advanced Television Systems Committee

AVC Advanced Video Coding (also known as H.264)

CA Conditional Access or Certificate Authority

CAS Conditional Access System

CBC Cipher Block Chaining

CCI Copy Control Information


Motorola, Inc. 5

CDS Content Directory Service

CGMS Copy Generation Management System

CIT Constrained Image Trigger

CPRM Content Protection for Recordable Media

CRL Certificate Revocation List

CTR Counter

DES Data Encryption Standard

DH Diffie-Hellman

DLNA Digital Living Network Alliance

DOI Domain of Interpretation

DMP Digital Media Player

DMS Digital Media Server

DRM Digital Rights Management

DTCP Digital Transmission Copy Protection

DVB Digital Video Broadcasting

DVR Digital Video Recorder

ECB Electronic Code Book

ECC Elliptic Curve Cryptography

ECDSA Elliptic Curve Digital Signature Algorithm

EMI Encryption Mode Indicator

EPG Electronic Program Guide

ESB Electronic Security Broker protocol

EST Electronic Sell-Through

HD High Definition

HDC Home Domain Controller

HDD Hard Disk Drive

HDCP High-Bandwidth Digital Copy Protection

HMAC Hashed Message Authentication Code

IDE Integrated Drive Electronics

IANA Internet Assigned Numbers Authority

ICANN Internet Corporation for Assigned Names and Numbers

IP Internet Protocol

IPRM Internet Protocol Rights Management System

KDC Key Distribution Center

KMS Key Management Server

MIME Multipurpose Internet Mail Extensions

MoCA Multimedia over Coax Alliance

KS Key Store

MC MediaCipher (Motorola CAS)

MPEG Motion Picture Expert Group

OCAP OpenCable Application Platform

OCAP-HN OCAP Home Networking Extension

PID Packet Identifier

PKI Public Key Infrastructure

PMP Portable Media Player

POD Point of Deployment module [used interchangeably with CableCARD]


Motorola, Inc. 6

RFC Request for Comments

RSA Rivest-Shamir-Adelman

RTP Real-time Transport Protocol

SAP Session Announcement Protocol

SATA Serial Advanced Technology Attachment

SD Secure Digital or Standard Definition

SDP Session Description Protocol

SHA Secure Hash Algorithm

SMS Subscriber Management System

SRO Session Rights Object

SRM System Renewability Message

STB Set-Top Box

Sub-CA Subordinate Certificate Authority (subordinate to a Root CA)

TGT Ticket Granting Ticket

USB Universal Serial Bus

VOD Video on Demand

VoIP Voice over IP

1.2 References

[1] Public Key Cryptography for Initial Authentication in Kerberos [draft-ietf-cat-kerberos-pk-init-25]

[2] The Kerberos Network Authentication Service (V5) [RFC1510] [3] Federal Information Processing Standards Publication 197 – Announcing the

Advanced Encryption Standard (AES), November 26, 2001.

[4] HMAC: Keyed-Hashing for Message Authentication, IETF (Krawczyk, Bellare, and Canetti), Internet Proposed Standard, RFC 2104, March 1996.

[5] Secure Hash Algorithm, Department of Commerce, NIST, FIPS 180-1, April 1995.

[6] OpenCable™ CableCARD™ Copy Protection System Interface Specification, 2.0, OC-SP-CCCP2.0-I01-050331

[7] ATSC Standard: Program and System Information Protocol for Terrestrial Broadcast and Cable (Revision C), A/65C

[8] IETF RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Network Working Group, R. Housley,

W. Polk, W. Ford, D. Solo, April 2002.

[9] SEC1: Elliptic Curve Cryptography, Standards for Efficient Cryptography, Version 1.0, Certicom Research, September 20, 2000.

[10] DFAST Technology License Agreement For Unidirectional Digital Cable Products, www.cablelabs.com.

[11] tru2way™ Host Device License Agreement; CableLabs, May 2008 [12] DTLA Digital Transmission Protection License Agreement (Adopter

Agreement); www.dtcp.com.

[13] Overview of Motorola IPRM System: Electronic Security Broker (ESB) Protocol; Motorola, March 2009.


Motorola, Inc. 7

[14] Overview of Motorola IPRM System: Delivery of Multimedia on Demand (IPRM-VOD); Motorola, March 2009.

[15] ISO/IEC 14496-14:2008: Information technology ---- Coding of audio-visual objects ---- Part 14: MP4 file format.

[16] ARIB-TR-B14v2_8-2P3-E2: ARIB Specification. [17] Marlin IPTV End-point Service: v10, July 20, 2006. [18] Secure Media Encryptonite System; http://www.securemedia.com. [19] IPRM Adopter Agreement.


Motorola, Inc. 8

2. IPRM Overview

The IP Rights Management (IPRM) system allows content owners and service providers

to deliver content in a secure manner so that the content owner’s rights are protected, and

business models and contracts enforced, while simultaneously providing end-users with

seamless content consumption controls. Within the home, IPRM also provides a

mechanism for importing content from a different security system (e.g. conditional access

subsystem, such as MediaCipher, or CableCard [6], or ATSC broadcast, analog input,

digital input including DTCP-IP, or CPRM), re-encrypting that content uniquely for the

receiving device, persistently storing that content, and exporting that content at a later

time to another security system (e.g. HDCP, DTCP, CPRM or CSS). For content that is

explicitly or implicitly allowed to be shared within the user’s domain, IPRM provides the

ability to securely stream or copy persistently stored content from the initial receiving

device to another device that has been authenticated as part of that customer’s personal IP

network, also called the secure home domain. For example, this allows sharing of

content between a DVR and a STB, or a DVR and a mobile handset, a Portable Media

Player (PMP) or Personal Computers (PCs) that are all registered as part of the same user

domain.

When two end points want to securely stream or copy content between them, a secure

session is established which includes a set of symmetric keys that both end points share

and use to encrypt, decrypt and authenticate individual packets or messages. This portion

of the IPRM system employs symmetric cryptography, so that latency and loading are

minimized during session set-up. The secure session is used to communicate control and

rights information, as well as key exchange. Content is transmitted over a separate

encrypted channel which supports multiple file-based and streaming formats.

2.1 Security for Persistent Content

IPRM supports robust security mechanisms for persistent storage of high-value content.

In general, IPRM enables an authorized device to capture streamed content or to

download file-based content, and save it for future playbacks. Such storage media can be

hard drives (internal or external), memory cards, DVD-R, and other forms. Persistently

saved content is protected and never available in a clear-text form all at once but rather

when it is played back, it is decrypted one small unit at a time, while preserving the

ability to fast forward, rewind, pause, and seek into the middle of the content. As an

alternative, content may be pre-positioned (typically protected under a conditional access

system) with the capability to purchase such cached unpaid-for content later and then

stream it from local storage.

In the home, IPRM may accept content from a variety of secured sources. For example, a

home gateway might receive content from an IP delivery system, protected via a

conditional access system, or from an over-the-air broadcast such as ATSC, from IEEE


Motorola, Inc. 9

1394 under DTCP, from the home IP network protected by DTCP-IP, or from an analog

input. Each source typically presents a set of copy controls or other control information

that IPRM imports, and acts upon.

During a local playback, IPRM allows streaming to approved consumer electronics

industry output interfaces (e.g. IEEE 1394, HDMI, home IP network, and analog

composite or component) while passing copy control related information to any external

interface that supports it. For example, for IEEE 1394/DTCP the copy control

information (CCI) and Encryption Mode Indicator (EMI) is sent along with the content,

similar to DTCP-IP as used by DLNA. For an analog output interface that supports copy

protection, IPRM specifies the type of analog protection system (e.g. Macrovision) to

invoke and includes CGMS-A and other related information with the output where

appropriate. When content is sent over an external unprotected analog interface, IPRM

controls the resolution of the output according to the Constrained Image Trigger. For

MPEG-2 transport content marked with the Redistribution Control descriptor (a.k.a.

Broadcast Flag) in the PMT [7], IPRM prevents unauthorized redistribution of such

content. For content marked as copy never with time-shifting allowed, IPRM limits the

lifetime of the pause buffer to prevent permanent recordings.

Additional controls to support the multitude of business models include specifying the

number of times that content can be played back, and support for a rental model by

controlling the period during which a consumer is allowed to play back a particular piece

of content. A “subscription” rental, as common in the music industry, is also supported.

Figure 2-1: Multi-room DVR and Client Example

IPRM supports enforcement of content access rules, such as copy control. At each input

domain boundary, (see Figure 2-1) rules information (e.g. CCI) is imported and securely


Motorola, Inc. 10

linked with the received media. Similarly, at each output boundary rules information is

exported to the appropriate output control mechanism.

2.2 In-Home Content Re-Distribution

In addition to content distribution and persistent storage, and its output on industry

defined interfaces, IPRM also supports the concept of the home domain, a collection of

IPRM devices identified specifically with the home or the user’s household, where

content may be shared. The content usage rules determine the circumstances under

which the consumer may make one or more copies of such content or render it on such

multiple in-home devices. In order to fully enforce content usage rules, IPRM requires

authentication of all devices within the home network.

The same content rights that apply to the content stored on a persistent storage device

(e.g. DVR, handset, etc.) also apply to the other devices in the DRM domain. For

example, if the content is to expire after some period of time, the rule has to be enforced

on each device that is a member of the home domain. In the case that a device is not able

to maintain secure time, then that device would be given a one-time rendering of the

content without an ability to store a local copy. In general, if a device is not capable of

enforcing all of the relevant DRM rules, its access to stored content will be more

restricted. There are also additional rules defined specifically for the DRM domains.

In order to fully enforce content usage rules, IPRM protection needs to be applied within

the home network. If the content provider is not aware of all of the devices on the home

network, these devices need to register with the Home Domain Controller (HDC), the

point of domain control, and comply with the domain policy (e.g. maximum number of

devices in a domain, proximity test, etc.).

IPRM inside a home network securely translates content usage rules between the security

systems used to deliver the content to the home, and any non-IPRM security systems

used to protect the content within the home (e.g., outputs like IEEE 1394/DTCP,

DLNA/DTCP-IP). The translation and interpretation of different types of persistent

controls and sometimes the same persistent controls, essentially forms an “IPRM Policy,”

and is definitely delivery system dependent, and often governed by signed legal licenses

permitting such access. Thus an IPRM client may receive ATSC content protected using

the Broadcast Flag (Redistribution Descriptor), Conditional Access-protected content

with CCI controls, DLNA/DTCP-IP or IEEE 1394/DTCP content, etc., behave

appropriately, and output that content subsequently to other IPRM devices in the home,

HDCP/HDMI connections, or analog outputs with Macrovision protection and/or CGMS-

A, etc.

2.2.1 Sharing Content in the Home Domain

A single device in an IPRM-protected domain is designated as the domain control point,

called the Home Domain Controller (HDC), and is responsible for device registration into


Motorola, Inc. 11

the domain, and also for obtaining Certificate Revocation Lists (CRLs), processing them

and making them available to other devices in the home network.

There are several possible options to share content within an IPRM-protected domain:

1. Stream content from a DVR to another device that is in the proximity of the transmitter (see Section 3.6.2 on proximity controls).

2. Copy content marked as Copy-Free from a DVR to another storage device which is in the proximity of the transmitter. When the use of redistribution control is

indicated, Copy-Free content must be encrypted and protected by IPRM. For

Copy-Free content, proximity controls prevent the content from being distributed

over the Internet.

3. Move content that was originally received as Copy-One-Generation (and stored as Copy-No-More) from a DVR to another storage device in the proximity of the

transmitter.

4. Copy content marked as Copy-One-Generation to one or more devices within the domain if the Source Policy allows it (a.k.a. domain copy privilege).

IPRM controls copying or moving content between storage devices by controlling the

copying or moving of content decryption keys between the storage devices and by

binding these keys to each device.

There may also be devices in the IPRM-protected domain that are capable of only playing

streamed content, without any support for persistent storage. Such a device would not

persistently save the encrypted content or any of the associated information (e.g. keys,

persistence rules and metadata). These devices may still have additional digital or analog

output ports that must be enabled or disabled, depending on the copy protection rules

associated with the content.

2.2.2 Domain Management

IPRM domains are governed by a domain policy. There are several different mechanisms

to control this policy:

• Stand-alone autonomous domains are controlled by a default policy which may specify a maximum number of domain members and proximity controls;

• A service provider may extend the default policy by downloading a service-provider-specific policy;

• A service provider may also control admission to the domain be explicitly listing the allowed devices and by assigning additional capabilities to these devices, such

as a permission to allow remote access.

2.2.3 Remote Access to Content in the Home Domain

Domain control policy may allow one or more devices in the home to access the domain

content remotely while they are out of the home (e.g. outside of the immediate proximity

of the content server device).


Motorola, Inc. 12

3. IPRM Architecture

IPRM supports several different deployment and application models. It can be used in:

1. A stand-alone environment to protect content stored on a Digital Video Recorder (DVR) or other storage device;

2. Home networking environment to securely distribute content within the user’s IPRM-protected domain;

3. A home network environment with limited control/assist by infrastructure. If available, infrastructure can be employed to deliver CRLs and secure time to the

home devices, and optionally override or assist in domain registration.

4. End-to-end content distribution protecting content at the Service Provider site and during its distribution to the end user. This aspect of IPRM is covered by IPRM-

VOD (see [14] for details).

The above configurations may be combined to satisfy different use cases. This document

focuses on persistent in-home storage and in-home content sharing aspect of the IPRM

system also called IPRM-HN.

IPRM employs a combination of asymmetric (Public Key Infrastructure (PKI) using

elliptic curve (ECC) or RSA) and symmetric cryptography using standard algorithms

such as AES and 3DES. IPRM key management protocol called Electronic Security

Broker (ESB) is based on Kerberos (RFC 1510) ([1] and [2]) and the use of X.509

certificates (RFC 3280) [8]. An overview of the ESB protocol can be found in [13].

3.1 Local DVR Protection

There are two main use cases that are applicable for local content protection: (1) secure

recording of content and (2) secure playback of content. The detailed steps of these

scenarios are described in the following sections.

3.1.1 Secure Recording

The detailed steps of the content recording scenario are described below and depicted in

Figure 3-1:

1. The content is received from an external source; 2. Such content, if protected, is associated with access rights, in the form of Copy

Control Information (CCI) or related metadata;

3. If the content is allowed to be recorded, a rights manager derives a unique key bound to the content rights and to this device.

4. For protected digital content, each content packet is first decrypted using the original protection mechanism (e.g. conditional access encryption) and

5. Immediately re-encrypted using the content encryption key, such that the content is never available all in the clear; (Analog content would be digitized, and then

encrypted, while ATSC content would be encrypted.)


Motorola, Inc. 13

6. The content rights are protected against unauthorized modifications by the binding mechanism, and stored in persistent storage (e.g. internal or external hard

drive, Flash memory, Recordable DVD, etc.);

7. Content is stored in its protected format, also in persistent storage.

DVR

Persistent

Storage

CA Interface

Decrypt Encrypt

Rights Manager

Protected Rights

Protected Content

Digital Output (DTCP, HDCP)

Analog Output (CGMS & Macrovision)

1

23

4 5

6

7

Figure 3-1: Content Recording

Since persistently stored content is cryptographically bound to the device, it cannot be

played on another device just by copying the encrypted content and the associated rights

data without properly exercising the IPRM key management protocols and enforcing the

copy protection rules.

3.1.2 Secure Playback

The detailed steps of the content playback scenario are described below and depicted in

Figure 3-2:

1. Before a stored protected content can be played back, the associated rights must be checked for integrity by deriving the content key under the rights binding.

Then all applicable content access rules (e.g. rental period, playback count) must

be enforced including analog and digital output control;

2. If the rules permit the consumption of the content, the content decryption key will be loaded to the content decryptor;

3. If the content is consumed on an external device (e.g. Digital TV), the corresponding analog and/or digital output must be configured to protect the

content according to the relevant copy protection information in the rights data.

This includes DTCP, HDCP, APS, Constrained Image, etc.;

4. Rights data stored on disk must be updated as required (for example, play count decremented);

5. Finally, the content can be read off the disk, decrypted, and optionally decoded; 6. If the content is output on a secure interface, the content is protected using the

corresponding copy protection technology (e.g. DTCP, HDCP, APS, etc.).


Motorola, Inc. 14

Similarly, content may be separately output to a digital removable medium (e.g.

Recordable DVD, SD Card, etc.), protected under another approved output

protection technology, such as CSS or CPRM.

DVR

Persistent Storage

CA

Interface

Decrypt Decrypt

Rights Manager

Protected

Rights

Protected

Content

Digital Output (DTCP, HDCP)

Analog Output (Macrovision)

1

2

3

3

4

5

66

Figure 3-2: Secure Playback

3.2 Home Network Content Sharing

IPRM protects content distributed over in-home IP networks (e.g. Ethernet, HomePLUG,

MOCA, WiFi, USB/IP, etc.) to authorized devices in the IPRM-protected domain. The

following sections describe two main content sharing scenarios: streaming and copying.

3.2.1 Content Streaming in the Home Network

The detailed steps of a secure content streaming in the home network are described below

and depicted in Figure 3-3:

1. Before content can be streamed or copied to another authorized device, the source and destination devices must be members of the home domain, and authenticate

each other. Domain registration and authentication is based on the Electronic

Security Broker (ESB) protocol that is described in Section 3.6.

2. Next, the destination device will request the playback of a specified piece of content;

3. The source device checks the rights data to verify that the requested access can be granted (e.g. copy protection has not been violated, rental period has not expired,

etc.);

4. Then the content decryption key is derived under the rights binding and, together with the rights, is securely communicated back to the destination device;


Motorola, Inc. 15

5. In some cases, the original rights data must be updated accordingly (e.g., as in the case of counted playback or counted copies, or disabled, as in the case of a secure

move);

6. If the content is going to be output on an approved protected interface, the corresponding parameters (e.g. CCI) are communicated to that interface module

for subsequent content protection;

7. Once the destination device obtains the decryption key, it configures the decryption engine;

8. Content transfer process may proceed; 9. Output interfaces apply the relevant content protection and output content.

Figure 3-3: Home Network Streaming Scenario

3.2.2 Content Copying in the Home Network

If the content is going to be stored directly on the destination device (for example, if it is

a portable device) as shown in Figure 3-4, a corresponding protected rights object with

the acquired rights and the decryption key is created and stored, under a unique device

key. The first 5 steps are the same as in the streaming scenario described in Section

3.2.1:

6. Device stores the acquired rights and the content decryption key in the Protected Rights data object;

7. The content is stored in its encrypted delivered form.


Motorola, Inc. 16

Figure 3-4: Home Network Copying Scenario

Once the content has been copied or moved from a DVR to a portable device, that device

will retain the ability to play back the content (as described in the Secure Playback

scenario in Section 3.1.2), even when it is no longer in proximity to the Home network or

to the DVR from which the content was shared.

Note that if the original content stored on the DVR is marked as copy-one-generation and

the “domain copy” policy is not allowed, the content must be moved rather than copied to

the portable device rather than making a second copy.

3.2.3 Content Transcoding

Not all devices in the home may be capable of playing content in the format, encoding

and resolution used by the DVR. For example, a DVR may store MPEG-2 encoded, high

definition content in an MPEG-2 transport stream format while a PMP may require

Advanced Video Coding (AVC) in a MPEG-4 file format at a standard or lower

resolution. An external transcoding device may be required to convert the content from

one format to another.

Since this process also requires decryption of the original content and re-encryption of

the newly transcoded content, the transcoding device must include an IPRM module that

authenticates the device to the DVR and performs key exchange with the DVR in order to

decrypt the original content. There are several alternatives for handling the transcoded

content.


Motorola, Inc. 17

One option is to return the transcoded copy back to the DVR such that it can be

subsequently redistributed to one or more PMPs that are members of the home domain.

The DVR will maintain the DRM and copy protection rules for both the original and the

transcoded content.

Another option allows the transcoding device to further redistribute the transcoded

content to other devices that are members of the same home domain directly. In this case,

the transcoding device manages the associated DRM rules and performs key exchange

with the PMP without the assistance of the DVR.

IPRM guarantees that content is kept protected even during the transcoding process.

3.2.4 Remote Streaming from the Home Network

Additionally, IPRM also supports remote access to the content stored in the home for

content that permits such access. Remote access requires:

• The remote device must be an active member of the home domain (see Section 3.6 for details);

• The device must be approved for remote access;

• Access is via streaming only of the single requested content;

• Access to such content may be delayed if the content rights specify such restriction.

• This mechanism allows users to enjoy their content while they are traveling without any additional risk of unauthorized content redistribution to the content

owners.

3.3 Security Algorithms

The following cryptographic algorithms are used in the IPRM system to protect content,

control messages and other secrets for privacy, authenticity and integrity reasons as

appropriate. The ESB protocol used by IPRM also allows the negotiation of these

algorithms, where several are supported, to achieve the highest level of protection.

IPRM supports the following industry standards:

• AES is used in a 128-bit block cipher mode that must be implemented according to FIPS 197 [3]

• 3DES is an alternative to AES and can be used with either 168-bit keys or 112-bit keys.

• The keyed hash employed by the HMAC-Digest Attribute must use the HMAC message authentication method [4] with the SHA-1 hash algorithm [5]. HMAC-

SHA1 is used to authenticate messages. The key is 160 bits long.

• IPRM normally uses RSA signatures and Diffie-Hellman key agreement for public key algorithms. Key sizes of 1024 bits or higher are used. Certificate

Authority RSA modulus is at least 2048 bits.


Motorola, Inc. 18

• In some key storage sensitive environments, Elliptic Curve Cryptography (ECC) Public Key Operations [9] with the Home Domain Controller (HDC) is used to

distribute session keys. ECDSA algorithm is used for digital signatures and

ECDH (Elliptic Curve Diffie-Hellman) is used as a key agreement algorithm.

ECC curves are used with key sizes between 163 and 256 bits. The combination

of X.509 certificates and ECDSA signatures are used to authenticate a host (an

IPRM entity), while ECDH is used to derive a shared secret that is then used to

encrypt a symmetric session key.

3.4 Rights Binding and Translation

IPRM processes incoming CCI and/or EMI information, DRM rules and other related

metadata, determines whether the associated content can be recorded, and if recording is

permitted, translates the relevant copy control data into the internal rights data format.

This data is bound to the content key to prevent unauthorized rules modifications. The

rules stored in the rights data are checked before a playback of recorded content is

allowed. The information stored in the rights data is also used to set protection

technologies on all relevant output interfaces, including DTCP, HDCP and Macrovision.

The rights are securely bound to the recorded content using encryption. The IPRM

system derives a unique encryption key for each recorded piece of content through the

binding process, and based upon a unique device key. This prevents end-users from

taking an unauthorized copy of the protected content and the associated rights to another

device.

3.4.1 Supported Inputs

IPRM accepts content from several different interfaces. The details of integration with

the protection systems associated with each example input are described in the following

sections.

3.4.1.1 CableCARD Input

The IPRM system can interface with the CableCARD-Host Interface Module in order to

perform two functions: (1) Interpret the incoming CCI and translate it to the IPRM

internal rights data format and (2) re-encrypt the incoming content for local storage. This

is performed according to the relevant SCTE and OpenCable specifications.

For the cases where CCI does not allow a permanent copy to be made, a temporary copy

of the content can still be made in order to support trick modes such as PAUSE and

REWIND. In this case, a temporary copy is limited to 90 minutes and the settings of

Macrovision, APS and CGMS-A controls on the analog input are translated to

appropriate copy protection settings on analog and digital outputs to a display device.

For OCAP cable STBs, this 90 minute number can be overridden by an application.


Motorola, Inc. 19

3.4.1.2 Conditional Access System Input

The IPRM system can interface with any embedded or smart card based CA system. As

with the CableCard interface, IPRM must interpret the incoming CCI and related

metadata, translate it to the IPRM internal rights data format and (2) re-encrypt the

incoming content for local storage.

For the case where the conditional access system indicates that no permanent copy can be

made, a temporary copy of the content is allowed in order to support trick modes such as

PAUSE and REWIND. Retention time defaults to 90 minutes unless the CA system

specifies some other value. Appropriate output copy protection settings are applied.

The IPRM-HN system may also ingest and protect content delivered to the home using

IPRM protection. See IPRM-VOD Overview [14] for details.

Marlin IPTV is another example of CA system delivery. Its specification defines digital

copy control in a Digital Copy Control Descriptor with additional fields in its Content

Availability Descriptor. IPRM supports parsing of these descriptors to extract the relevant

copy protection information. See section 4.2.1.4.1 of [17] for more information.

Secure Media IP CA [18] is another example of a supported ingest format.

3.4.1.3 Free-to-Air Terrestrial Input

The IPRM system can accept unencrypted free-to-air digital streams from a

tuner/demodulator. In this case, IPRM translates the redistribution control information

and other copy control information into the IPRM internal rights data format and encrypts

the incoming content for local storage.

ATSC, DVB-T, and ARIB (Association of Radio Industries and Businesses) represent

different types of over-the-air or free-to-air content distribution systems. ATSC copy

control is described in Amendment 3 to [7]. For the details of ARIB copy control, see

table 30-21 of [16].

3.4.1.4 Analog Inputs

If an analog input from the cable plant is accompanied by CGMS-A and APS information

which allows a copy of the content to be made, the content may be digitized, compressed,

encrypted and recorded. IPRM creates content rights data corresponding to this recorded

content where it keeps track of the values of the CCI bits.

For the cases when CGMS-A and APS information does not allow a permanent copy to

be made, or when the analog input is already Macrovision-protected, a temporary copy of

the content can still be made in order to support trick modes such as PAUSE and

REWIND. In this case, a temporary copy is limited to 90 minutes and the settings of

Macrovision, APS and CGMS-A controls on the analog input are translated to

appropriate copy protection settings on analog and digital outputs to a display device.


Motorola, Inc. 20

3.4.1.5 DTCP Input

IPRM-HN may also ingest content originated on another device in the home, for instance

a DLNA Digital Media Server (DMS), using DTCP or DTCP-IP link protection. IPRM

will process and obey the EMI and other relevant copy protection information as

specified in the DTLA compliance rules for sink devices [12].

3.4.2 Authorized Outputs

IPRM allows content to be exported from the IPRM-protected domain to other approved

outputs with an alternate copy protection system, such as DTCP, DVI and HDMI/HDCP,

and analog outputs protected by Macrovision and CGMS-A.

3.4.2.1 DTCP Output

IPRM integrates with DTCP over IEEE 1394 such that it passes EMI information

received from the content source and enforces the proper CCI conversion. A DTCP

descriptor is also passed through or newly created into the MPEG-2 PMT.

DTCP-IP is also supported as an approved IP output, typically used to stream content to

DLNA or OCAP-HN devices.

3.4.2.2 DVI and HDMI/HDCP Output

IPRM integrates with HDCP for DVI and HDMI outputs for protected content.

3.4.2.3 Analog Output

For the case of analog input content, IPRM turns on Macrovision for the analog output as

controlled by CEA-608-C, using APS control bits and CGMS-A information. CGMS,

APS and Redistribution Control are also included appropriately. For the case of digital

input content, IPRM applies Macrovision, CGMS-A and APS and Redistribution Control

as required by the specific security system involved. IPRM also triggers the lowering of

video resolution of content as specified by the CIT control when outputting HD content

over an analog output.

3.4.2.4 Persistent Bound Storage

IPRM can encrypt content for storage (e.g. hard drive, etc) in a STB or other home device

as directed by incoming DRM or CP (Copy Protection) rules (e.g. CCI) irrespective of

the storage technology type or a specific interface to the storage element (e.g. IDE,

SATA, USB). Since the storage encryption keys (or the rights data protection) are unique

to the device, such content cannot be consumed by any other device simply by moving

the storage element. This unique binding approach works equally well whether the

storage element is internal to the STB, or external.


Motorola, Inc. 21

3.4.2.5 Persistent Portable Storage

Currently, IPRM includes DTCP among its approved outputs. Since DTCP permits

CPRM protection for export to SD cards, IPRM also permits SD cards to be approved

forms of output. As DTCP only allows this for standard definition content and lower

resolution, this requirement is also enforced for IPRM.

Additional portable storage support such as DVD/CSS is anticipated after discussion with

content owners, although additional rights data control may be required.

3.4.3 IPRM Mapping of Copy Control Bits

Specific IPRM mapping for each input interface and output interface are often dependent

on service provider policies; therefore, specific input-output copy control mappings are

available on request.

3.5 Content Protection Profiles

3.5.1 Content Protection for MPEG-2 Transport Packet Payloads In this mode, each MPEG-2 transport packet payload is encrypted in-place with the 4-

byte transport headers and adaptation fields left in the clear. The typically used

encryption algorithms are AES-ECB, AES-CBC with 128-bit keys, and 2-key 3-DES

ECB encryption that must be implemented according to FIPS 197 [3].

These protected MPEG-2 packets can be encapsulated into UDP, TCP, HTTP or RTP for

transmission over the home IP network, typically 7 MPEG-2 packets per IP packet.

3.5.2 Content Protection for Generic RTP Payloads Generic RTP payloads can be protected using SRTP, using AES in counter mode and an

optional SHA1-HMAC (truncated to 10 bytes) for packet authentication.

3.5.3 Content Protection for MP4 Files The MP4 file encryption follows the content protection mechanism specified by the MP4

file format standard [15]. The Media Data box shall be encrypted using 128-bit AES

counter mode, while the content protection scheme information shall be added into each

sample entry box. The key management information and digital rights information are

managed by IPRM system.

3.5.4 Generic IPRM Message Encapsulation In addition to the use of in-place encryption for MPEG-2 transport packet payloads, and

SRTP, there are other types of information transfers that require protection. Each such

transfer is encrypted using a symmetric encryption algorithm, where AES with 128-bit

key is defined but other encryption algorithms could also be negotiated – as long as the

effective strength of such algorithm is equal or better than 112-bit 3-DES.


Motorola, Inc. 22

Typically, encryption utilizes CBC (Ciphertext Block Chaining Mode) which requires an

Initialization Vector (IV). After such IPRM encryption is applied, it adds a clear header

that includes the information needed to derive an IV.

Optionally, Generic IPRM message encapsulation can also provide message integrity and

replay protection. Each encrypted message would include a Message Authentication

Code (MAC), where the defined algorithm is HMAC-SHA1, but other algorithms may be

negotiated as well. Replay protection is provided by including a sequence number in the

clear IPRM header, where this sequence number is authenticated along with the rest of

the IPRM header and the encrypted content using the MAC.

The keys used to encrypt such information are derived from a key that is established

using ESBroker key management.

3.6 Key Management & Domain Control

The ESBroker protocol serves two main purposes for IPRM. First, via the single Home

Domain Controller (HDC) all home devices are securely registered. Second, ESBroker

provides key management for the content keys that flow in the home network.

The HDC fundamentally keeps track of all the provisioned (registered) clients and servers

(e.g., DVRs) in a system and the cryptographic data associated with them. Additionally,

the HDC authenticates clients, and issues tickets for those clients to use as trusted tokens

during client server communications. The HDC assigns expiration time to tickets,

requiring clients to periodically renew them. By allowing clients to temporarily cache

these tickets, the system eliminates transactions to the HDC that would otherwise occur

before each request of content decryption keys from Key Management Servers. (Tickets

are symmetric key constructs defined in the Kerberos documentation [2].)

The client device (e.g. Media Hub, DVR, STB, PMP, and Handset) registers with the

HDC using its digital certificate (factory provisioned) and the HDC stores the client’s

unique identity and public key in its database.

Once a device is provisioned into the home network and receives a ticket for some media

hub (i.e. DVR), it can request content to be streamed from the media hub. A secure key

management message is sent from the client device to the media hub using the Ticket to

authenticate itself and to establish a secure session. Once the media hub has

authenticated the device and has verified the rights associated with the requested content,

it will send the content decryption key and content access rules (copy protection, DRM

rules, etc.) to the device in a secure manner such that only the receiving device can verify

the integrity of the message and decrypt the cryptographic data.

Details of the IPRM key management protocol called ESBroker can be found in [13].


Motorola, Inc. 23

3.6.1 Support for Multiple DVRs

Each DVR and other content storage source (e.g. Home Media Gateway, network

accessed storage) in an IPRM-protected domain corresponds to a content server that must

be registered to the HDC in order for content on that DVR to be transferable to another

device within the same domain. Registration includes generation of a unique (typically

AES) service key assigned to that server for the purpose of encrypting ESBroker tickets.

If there is just a single DVR in the domain, typically it will include the HDC functionality

on the same device and thus the management of a Service Key can be done through a

local application that does not need to make use of a secure protocol. However, when

multiple content source devices are added to the same domain, the additional units have

to be registered securely to the HDC.

3.6.2 Limits on an IPRM-Protected Domain

The HDC controls the size of the IPRM-HN-protected domain by limiting the maximum

number of devices that can be provisioned to the domain at the same time. This limit is

currently set to 16 devices and may be adjusted by a service provider.

To limit the geographical size of the IPRM-protected domain, and prevent connections

across a wide area network such as the Internet, IPRM employs a proximity control

during domain registration and renewal similar to other copy protection technologies,

utilizing industry accepted upper limits of RTT=7ms and TTL=3. Proximity is checked

during client provisioning with the HDC. Optionally for content that is limited by the

delayed distribution restriction, the proximity test is also performed right before the

content transfer session is established in the IPRM-protected domain.

A Service Provider may also provide an explicit domain control by specifying an exact

list of devices that are allowed to join the domain.

3.7 DLNA Support

IPRM may be integrated into a DLNA network by using existing UPnP constructs or by

extending them:

1. IPRM-protected content stored on a DVR which may act as a Digital Media server (DMS) will be advertised in the Content Directory Service (CDS) using an

IANA-registered MIME type “vnd.motorola.iprm”. This allows client devices,

or Digital Media Players (DMPs) to determine whether they can consume such

content.

2. IPRM also defines an IPRM Service which may be used during device discovery to indicate which device may act as a HDC. Other devices will use this

information to start the domain registration process.


Motorola, Inc. 24

3.8 Certificate Management

The IPRM system makes use of standard X.509 certificates (compliant with RFC 3280)

when authenticating IPRM clients to a HDC and vice versa. The use of digital certificates

[8] and public key cryptography means that the HDC keeps a database of only the client

public keys – and not their private or secret keys. The use of digital certificates and

public key cryptography makes the overall system more secure and easier to administer.

The overhead of public key cryptography is in this case minimal because it is used only

during the client’s initial authentication to the HDC and is only repeated after a period of

multiple weeks for the purpose of ticket renewal.

An entity that is responsible for issuing digital certificates to clients is generally known as

a Certificate Authority (CA). For Motorola’s IPRM-enabled devices, public/private key

pairs and the corresponding digital certificates are generated by the Motorola PKI Center

and installed into each device during a manufacturing process.

3.9 Revocation

When a certificate is revoked, its serial number will be added to a CRL (Certificate

Revocation List) that is generated by the same Certificate Authority that previously

issued the corresponding certificate. The format of a CRL is defined by the X.509

standard and its ASN.1 encoding.

If an infrastructure connection is present, the HDC can check the infrastructure CRL

server periodically, and revoked clients no longer permitted to access stored content.

For the case of primarily one-way content delivery and control, or when no infrastructure

access is present, the IPRM system in the home is required to support any broadcast

CRLs carried within the incoming content flows as part of the MPEG-2 transport stream

delivery or IP network equivalent. Thus the IPRM device must examine the broadcast

CRL streams to check for revocation.

4. IPRM Obligations

As with all DRM implementations, a major issue is the proper implementation of the

security subsystem on each home device. Motorola has a long history of successful

security implementation, and recognizes that this typically involves both hardware and

software design. These aspects have been quantified in the industry in the form of

“compliance and robustness rules”, a.k.a. C&R regime.

The IPRM Compliance and Robustness Rules must of course address the parameters of

the corresponding agreements for each supported input type. IPRM Compliance and

Robustness Rules are defined in the IPRM Adopter Agreement [19].

Overview of Motorola IP Rights Management (IPRM) System: … · Overview of Motorola IPRM System...

Documents

Transcript of Overview of Motorola IP Rights Management (IPRM) System: … · Overview of Motorola IPRM System...