JongWeon Kim, Ph.D.

1

2

• Open Mobile Alliance• Founded in June 2002• OMA is designed to be a center for mobile service

specification work, stimulating and contributing to the creation of interoperable services

• Members in Korea– Sponsors : SKT, Samsung Electronics– Full members : LGT, KTF, LG Electronics– Associate members : ETRI, KISA, MarkAny, Nextreaming,

WiseGram, Intromobile, …

3

• Deliver high quality, open technical specifications based upon market requirements that drive modularity, extensibility, and consistency amongst enablers to reduce industry implementation efforts.

• Ensure OMA service enabler specifications provide interoperability across different devices, geographies, service providers, operators, and networks; facilitate interoperability of the resulting product implementations.

• OMA DRM work started in 2001 in response to market demand– Content sales to mobile devices becoming lucrative

• Phones coming to market able to support downloadable ringtones, wallpapers, screensavers, applications

• Content and service providers wanted to protect their investment in these types of content

– Various levels of protection needed commensurate with the value of the content being protected

– Service providers and vendors wanted a solution that was timely and inexpensive to deploy

• Can be implemented in mass market mobile devices (not just high-end)

• Must not require costly infrastructure to be rolled out

4

5

• Established Dec. 1998• DRM class(stage 1 architecture)

– Class 1 : “Forward lock”• Not permit forwarding : lower value content

– Class 2 : “Comprehensive DRM”• Packaging for higher value content• Use rights expression language

• 2002.9 : stop the work– Work was transferred to OMA

6

• Based on the 3GPP DRM requirement• Current Status(2008.6)

– DRM V2_0_1: Candidate Release, Feb. 2008– DRM V2_1: Candidate Release, Aug. 2007– Secure Removable Media (SRM) V1_0

• Candidate approve, 28/01/2008• Candidate release, 4Q 2008

– Secure Content Exchange (SCE) V1_0• Still progressing Consistency Review comments

(about 50% done)• Candidate release, 4Q 2008

7

RDRD

ADAD

TS(bcast)TS(bcast)

DRM*DRM*

REL*REL*

DCF*DCF*

otherother

RDRD

ADAD

TS(srm)TS(srm)

DRM*DRM*

REL*REL*

DCF*DCF*

RDRD

ADAD

TS(sce)TS(sce)DRM*(impDRM*(imp

))REL*(imp)REL*(imp)

DCF*(imp)DCF*(imp)

DRM*DRM*

REL*REL*

DCF*DCF*

DRM***DRM***

REL***REL***

DCF***DCF***

RDRD

ADAD

DRM***DRM***

REL***REL***

DCF***DCF***

RDRD

ADAD

BCASTBCAST SRMSRM SCESCE

DRM 2.1DRM 2.1

DRM 2.2DRM 2.2

9

• DRM solution evolving with mobile industry– High bandwidth 3rd Generation cellular networks available– Proliferation of wireless Internet “hotspots”– Mobile devices with removable media and larger color screens support

downloading and streaming rich media– Content and service providers eager to release rich audio/video

content and applications into the marketplace • Greater security and trust management required to protect high

value content– Need to ensure target device can be

trusted to keep content and secrets safe– Need greater security to prevent content

from leaking out during distribution

10

• Security– Rights object and content encryption key encrypted using

device’s public key to bind to target device– Integrity protection for content and rights object added to reduce

risk of tampering

• Trust– Mutual authentication between device and rights issuer– Rights issuer can accurately identify device to determine

revocation status

• Support for a wide variety of distribution and payment use cases

Device RI

1Device Hello

RI Hello2

3Registration Request

4

OCSP Request

OCSP Responsea

bRegistration Response

4-Pass Registration Protocol

CA Device RI

1RO Request

RO Response2

2-Pass RO Acquisition Protocol

1-Pass RO Acquisition Protocol

Device RI

1

Device RI

1Domain Join/Leave Request

2

2-Pass Domain Join/Leave Protocol

Domain Join/Leave Response

ROAP Trigger

12

• DCF– First profile is used to package and protect discrete

Media(i.e. ring tones, applications, images, etc.)– based on the ISO Base Media File Format data types

and conventions as defined in [ISO14496-12]• PDCF

– The second profile is used to protect Continuous (packetized) Media (i.e. Audio and Video.)

– also based on the ISO base media file format, but is defined in a separate specification, in the 3GPP [TS26.244]

OM

A DR

M

Container

20

OMA DRM headers

DR

M

Content

Content Object

Content Object container

2nd OM

A

DR

M

Container

(multipart) other content

containers

20

DC

F H

eaders

Common headers

OMA DRM Container Length - 20

Complete File Size2nd OMA DRM

Container Length

Fixed DCF header

UserData

Mutable D

RM

Info

Rights O

bject

(Editable space) RO,

TransactionID

DCF structure

Box(‘odrm’)Box(‘odhe’) Box(‘ohdr’)

Box(‘udta’)Defined in [ISO14496-12]

Box(‘odda’) Box(‘ccid’)- ContentID- Content-Location header

odcf File data

4 4 file size - 20

2

VersionBrand

ftyp20

44

Fixed File Type header

odcf

4

Compatible brand

Example PDCF structure

SchemeInformationBox(‘schi’)

is indicated, then the file is a PDCF and must contain at least one OMADRMKMSBox

Common headers OMADRMAUFormatBoxindicate the format of the OMADRMAUHeader which is placed on media access units

15

Version 1.0 2.0

File Type WAP Based ISO Based

MIME Type •application/vnd.oma.drm.content •application/vnd.oma.drm.dcf(DCF)•video/3gpp or audio/3gpp(PDCF)

Content Fields •Version•ContentTypeLen•ContentURILen•ContentType•ContentURI•HeaderLen•DataLen•Headers

•Encryption-Method header•Encryption-Method parameter•Rights-Issuer header•Content-Name header•Content-Description header•Content-Vender header•Icon-URI header•Unsupported header

•Data

•Common Box•Common Headers Box

•Common Header Version•EncryptionMethod•PaddingScheme•PlaintextLength•ContentIDLength•RightsIssureURLLength•TextualHeadersLength•ContentID•RightsIssureURL

•Extended Headers•Group ID

•Textual Headers Box•Silent header•Preview header•ContentURL header•ContentVersion header•Content-Location header•Custom header

•Free Space Box•Transaction Tracking box•Rights Object box

EncryptionAlgorithm

•AES_128_CBC •AES_128_CBC•AES_128_CTR

16

• ODRL(Open Digital Rights Language) base• Goal

– Light-weight and simple way of expressing rights– Lowering the entrance barrier for content providers and other players

to adopt DRM technologies– Suitable for specifying rights independently of the content type– Suitable for specifying rights independently of the transport mechanism– Enable specification of right to preview, i.e., test-drive, DRM Content

enabling users to experience the Content first hand, possibly prior to purchasing it

– Enable specification of constraints to restrict permissions to the number of times Content can be accessed, and time limits and intervals during which Content can be accessed

17

• Foundation model• Agreement model• Context model• Permission model• Constraint model• Inheritance model• Security model

18

OMA DRM REL 2.0 Model (2 of 2)

Rights Context

Agreement

Version

uid

asset

permission

(RO’s id)

Context uid (Content id - URI)

inherit

digest DigestMethod

DigestValue

KeyInfo EncryptedKey

RetrievalMethod

play

display

execute

print

export

(id, idref)

(mode – move,copy)

constraint count

Timed count

datetime

interval

accumulated

individual

system

(timer)

(URI)

(algorithm:SHA-1)

EncryptedMethod ReferenceList

CipherData

KeyInfo

(algorithm)

CipherValue

start

end

19

Version 1.0 2.0

REL Type XML, WBXML XML

MIME Type •application/vnd.oma.drm.rights+xml•application/vnd.oma.drm.rights+wbxml

•application/vnd.oma.drm.pro+xml

Structure •Foundation model•Element<rights>

•Agreement model•Element<agreement>•Element<asset>

•Context model•Element<context>•Element<version>•Element<uid>

•Permission model•Element<permission>•Element<play>•Element<display>•Element<execute>•Element<print>

•Constraint model•Element<constraint>•Element<count>•Element<datetime>

•Element<start>•Element<end>

•Element<interval>•Security model

•Element<KeyInfo>•Element<KeyValue>

•Foundation model : 동일•Agreement model

•Element<asset>•Attribute “id”•Attribute “idref”

•Context model : 동일•Permission model : 추가

•Element<export>•Attribute “mode”

•Constraint model : 추가•Element<timedcount>

•Attribute “timer”•Element<interval>•Element<accumulated>•Element<individual>•Element<system>

•Inheritance model : 신규•Element<inherit>

•Security model : 추가•Element<enc:EncryptedKey>•Element<enc:EncryptionMethod>

•Attribute “Algorithm”•Element<enc:CipherData>•Element<enc:CipherValue>•Element<ds:RetrievalMethod>

•Attribute “URI”•Element<o-ex:digest>•Element<ds:DigestMethod>

•Attribute “ds:Algorithm”•Element<ds:DigestValue>

21

While the OMA DRM defines an end-to-end system for DRM Content and Rights Object distribution among the Device, the Rights Issuer and the Content Issuer,

this specification defines mechanisms and protocols to extend OMA DRM version 2.0 to allow Users to Move Rights between the Device and the SRM and to consume Rights stored in the SRM.

A removable media that implements means to protect against unauthorized access to its internal data and includes an SRM Agent. (e.g. secure memory card, smart card)

Secure Removable Media (SRM)

This entity is responsible for storing and removing Rights Objects in SRM, for delivering Rights Objects from/to a DRM Agent in a secure manner, and for enforcing permissions and constraints, including securely maintaining state information for stateful rights. The SRM Agent is a part of SRM.

SRM Agent

Concept of this specification

22

1.Only the SRM Agent can access the secure storage2.DRM Agent MUST requests the action to the SRM Agent. After that, SRM Agent passes the result to DRM Agent

The completeness of the security

DRM Agent SRM Agent

AuthenticationRequest

KeyExchangeRequest

AuthenticationResponse

KeyExchangeResponse

① Request Device information and preferences② SRM checks the request message

• Check if it supports the Trust Anchor• Verify the Device Certificate Chain• Select the algorithms to use

① Generate a random N (RND)② Encrypts the hash of the SRM Random Number (RNS) received

H(RNS)③ E (PuKeyS , KeyExData) where

KeyExData = RND | H(RNS) | Selected Version- PuKey : SRM’s public key- Selected Version : the version in the SrmHelloResponse

① Decrypts Encrypted KeyExData with the SRM’s private key ② Compares the decrypted H(RNS) to the RNS that the SRM Agent sent &

the decrypted Selected Version to the Selected Version sent in the SrmHelloResponse

23

DRM Agent SRM Agent

AuthenticationRequest

KeyExchangeRequest

AuthenticationResponse

KeyExchangeResponse

25

• SCE (Secure Content Exchange)– OMA DRM이아닌콘텐츠를 OMA DRM으로사용할수있게하거나안전한콘텐츠의교환을가능하게해주는것

• OMA DRM SCE의목적– 모바일기기와일반가전기기간의콘텐츠및 RO(Rights Object)의교환

– 홈네트워크에서의콘텐츠공유

– 여러개의장치들사이에서구입한콘텐츠를끊김없이사용

– 일시적으로콘텐츠를공유지원

– OMA DRM을지원하는시스템과 OMA DRM을지원하지않는시스템사이에서컨텐츠를상호사용할수있도록함

26

• OMA DRM SCE의주요 Working Items– 도메인(Domain) 개념을좀더확장하는노력과 RO를좀더융통성있게전달하고관리하는작업

– Non-OMA DRM을사용한콘텐츠를일정한 Gateway를통해서 OMA 도메인으로들어오게할수있는Import 기능

27

RightsIssuer DEA

DRMAgent LRM

DRMRequestor

DRMRequestor

SCE-3-RDP

SCE-6-LRMPSCE-7-A2AP

SCE-1-ROAP SCE-5-LRMP

SCE-4-LRMP

SCE-2-DMP

Entity Entity Interface InterfaceInterfacespecified bythis enabler

Interface NOTspecified bythis enabler

Entityspecified bythis enabler

Entity NOTspecified bythis enabler

DEA (Domain Enforcement Agent)manage a User Domain based on a given User Domain Policy that has been assigned to the DEA by a DA

LRM (Local Rights Management)create RO’s and (P)DCF’s from Import-ready data

• SCE-1-ROAP– an extended version of the ROAP 1.0 protocol as specified in OMA DRM 2.0

• SCE-2-DMP– Domain Management Protocol– used by the DEA to manage a User Domain– using this protocol, the DEA will add and remove Devices to/from the User Domain

• SCE-3-RDP– RI-DEA Protocol– used by the DEA and RI to enable a Rights Issuer to issue RO for a User Domain managed

by the DEA• SCE-4-LRMP

– used to enable an LRM to import Rights to an OMA DRM V2.x-only Device or into an OMA DRM V2.x Domain

• SCE-5-LRMP– used to enable an LRM to import Rights into a User Domain

• SCE-6-LRMP– used to transfer Imported-Rights-Objects to a DRM Agent

• SCE-7-A2AP– Agent to Agent Protocol– used to exchange Rights and corresponding information to a DRM Agent

• SCE-8– used to exchange Rights to a DRM Agent