OMA_DRM_Detailed

Documents Number:

Revision History

Version 01.00 Description Initial Version Author Chen Xueyao Email xychen@cienet.com.cn e7433c@motorola.com Date 15-Mar-2008 1．DRM (Digital Rights Management)

IT行业中一个很重要是收益模式的就是License的管理，根据license来收费(目前还存在的是根据服务来收费，根据广告来获取收益)。在现实生活中，这是通过知识产权法来维护的。鉴于法律的威严，盗版不会大规模发生。但是随着网络的巨大发展，数字产品的大规模被盗版成为可能而且很难控制。因此出现了DRM这样的需求，采用数字的方式来控制license的分发。

DRM这个概念有许多具体的实现方式，比如，数字电视领域中有数字电视的DRM，Apple 的Fairplay iTunes DRM, Microsoft Janus DRM, OMA DRM, 以及军队中使用的DRM系统等等都是这个概念在不同领域的具体实现。 对于DRM这个概念，主要的内容包括两个方面： 1） License的可信分发 2） 根据license消费内容

对于某个具体的DRM实现，所不同的就是license分发的协议不同和消费的控制不同。 在本文中，我们主要介绍的是OMA（Open Mobile Alliance）的DRM。

2．OMA DRM Concept Architecture

OMA DRM一直随着市场需求和手机行业的发展而迅速发展，目前主要有三个版本。V1, V2和新近出来的V2.1。而V1、V2是不兼容的。下面我们先看看V1的主要概念。

2.1 OMA DRMv1的概念

在V1中，有三个主要的概念需要介绍一下的。我们经常在跟同事交流中，好像经常提到这些概念。但是需要指出的是，这些在V2中有着决然不同的含义，甚至可以说在V2中，已经不需要这些概念了。

1) Forward Lock: prevents content from leaving device. Forward lock 是明文形式通过DRM Message（application/vnd.oma.drm.message）的形式传输的。当它下载到手机端的时候，是可以无限制使用，但是前提是不能传送出去。

2) Combined Delivery: adds rights definition。而对于Combined Delivery的来说，它也是以明文形式通过DRM Message传输的。但是它传输的内容不仅包括了明文的内容，也包括了明文的Right Object。该Right Object 规定了该Content的使用限制。

可以说，Forward Lock是Combined Delivery的一个特殊例子。它的只是增加了针对内容的使用限制，对于安全性来说，还是依然如此。

1． 3) Separate Delivery: provides content encryption and supports super-distribution。对于

Combined Delivery 和Forward Lock来说，虽然规定手机端保证内容不会传播出去（这个要想一下，为什么手机端能够保证呢？）content是以明文形式传输的，这就导致很容易发生安全问题，而达不到DRM的requirements。这样就出现了Separate Delivery的概念。在Separate Delivery 中，content是以加密的形式(application/vnd.oma.drm.content)来传

输的。而加密的密钥是通过另外的渠道以明文的Right Object形式(application/vnd.oma.drm.rights+xml, ---- XML形式) ( application/vnd.oma.drm. rights+wbxml --- Binary XML 形式)存在。

从上图我们可以看到，content经过了加密后传输，这可以保证内容不被泄漏，因此Separate Delivery的内容是可以传输给别人的，这就是所谓的Super-Distribution)。而明文的right object通过WAP Push在另外一个channel传给手机。这比Combined Delivery提高了安全性，但是由于明文right object，还同样存在隐患。这样就升级到OMA DRMv2.0。

2.2 OMA DRMv2的概念

2.2.1 OMA DRMv2概念架构图

从下图的OMA DRMv2 概念架构图中，我们可以看出其中的参与方：

1） DRM Agent: A DRM Agent embodies a trusted entity in a device. This trusted entity is

responsible for enforcing permissions and constraints associated with DRM Content 2） Content Issuer: The content issuer is an entity that delivers DRM Content. OMA DRM

defines the format of DRM Content delivered to DRM Agents, and the way DRM Content can be transported from a content issuer to a DRM Agent using different transport mechanisms, for example HTTP. MMS, WAP Push, IrDa, Bluetooth, USB cable etc. 3） Right Issuer: The rights issuer is an entity that assigns permissions and constraints to DRM

Content, and generates Rights Objects. A Rights Object is an XML document expressing permissions and constraints associated with a piece of DRM Content. Rights Objects govern how DRM Content may be used. Right Objects are downloaded using the ROAP protocols. 4） User: A user is the human user of DRM Content. Users can only access DRM Content

through a DRM Agent.

5） Content Provider: 内容提供商。这个是DRM系统之外的一个角色。

6） Off-device Storage: DRM content is inherently secure, and may be stored by users off-device

–for example in a network store, a PC, on removable media or similar. This may be used for backup purposes, to free memory in a device, and so on. Similar, rights objects that only contain stateless permission may be stored off-device.

Fig.1 OMA DRM Concept Architecture

这些角色之间的交互主要有二种情况：

a) 内容的分发：OMADRMv2 内容以DCF（ DRM Content Format，

application/vnd.oma.drm.dcf ）的文件传递，由于DCF文件是以加密的形式存在的，因此，对于DCF文件，可以以任意的方式转播，比如，通过Http, Bluetooth, MMS, SD, you name it. 在上述的概念架构图中，包含了三种方式，第一种是由Content Issuer 分发到DRM Agent, 第二种是由DRM Agent 分发到Other DRM Agent， 第三种是由DRM Agent 备份到off-device store。

b) Rights Object (License)的分发。OMA DRM Right Object (license) 是以 DRM Right

Expression Language描述。它通过ROAP （Rights Object Acquisition Protocol）在DRM Agent 和Rights Issuer之间传递Rights object。

2.2.2 OMA DRM Protection

要实现DRM 的功能，一个直接的问题就是如何保护内容？OMA DRM Protection 的内容包括两个部分的工作，一个是加密，另外一个就是完整性。在DRMV1.0中，这些

保护的内容完全由手机端来实现的（对于Forward Lock / Combined Delivery），而且这些内容在网络上是以明文的形式传输的。DRMV2.0则做了很大的改进。内容都是以加密的方式进行传输（不过有点加密过头的嫌疑，后面会介绍到）。但其中的问题是，加密的密钥如何派发？这是通过PKI来完成的。所以支持OMADRMV2.0的手机一定要进行正确的provisioning（忘记provisioning或者provisioning 不正确是在测试中经常出现的问题）。

Plaint Content Server End KEK CEK Public Key Wrap C Encrypted Content Encrypted -CEK In ROAP PDU Through DCF In RO Through ROAP DRM Agent Plain Content CEK Encrypted Content Encrypted -CEK KEK C DCF RO Mobile End Fig.2 OMA DRM Encryption/Decryption Protection Private Key DRM同样对数据完整性有很严格的要求。首先是内容的完整性需要保证。其次是RO的完整性需要保证，不允许去更改RO（RO是以明文形式存在的）。另外，在ROAP的过程中也需要完整性的保证。这些要求在PKI的帮助下，得到完整的解决。

RO response ProtectedRO RO Rights Digest DCF XXXXXXXXXX MAC Digest Signature Signature Fig.3 OMADRM Integration Protection

3. OMA DRM Implementation Architecture in

Linux-Java Platform

对于Linux-Java上OMADRM的架构，LJ6.1 and LJ6.3 以后的版本采用不同设计。对于设计上的考量，请参考另外一篇《OMADRM Fuse Detailed.doc》。在这篇文档中，介绍了LJ6.1和LJ6.3以后的平台中设计采用各自设计的pros and cons.

目前的设计中，LJ-OMADRM 把上层的应用分为两种类型的，一种称之为Acquisition APP， 另外一种称之为Consumption APP。这个是跟前面提到的OMADRM主要解决的两个问题是对应的。Acquisition APP主要对应的RO的分发的问题，而Consumption APP对应的根据RO进行内容消费的问题。我们知道每种DRM的实现对于这两个问题处理都是不同的，因此LJ-OMADRM采用engine的概念来抽象这些不同。每个engine需要

完成自己不同的acquisition and consumption. 而这些engine的区分主要有两个方面： 对于Acquisition: (根据传输的MIME type的不同而区分) a) application/vnd.oma.drm.message b) application/vnd.oma.drm. rights+xml c) application/vnd.oma.drm. rights+wbxml d) application/vnd.oma.drm.content

以上是OMA DRMv1特有的MIME type。 a) application/vnd.oma.drm.roap-trigger+xml b) application/vnd.oma.drm.roap-pdu+xml c) application/vnd.oma.drm.dcf

以上是OMA DRMv2特有的MIME type。

Acquisition AppsMMS/EmailWAP PushConsumption AppsCallingAppMMS/EMailUser AppsMIDPMedia PlayerBrowserOBEXDL AgentBrowserFUSEDRMfsUnified OMA DRM APIOMA v1 Engine OMA DRM v2 EngineLinux + Java OS Fig.4 Linux-Java OMA DRM Architecture Diagram (LJ6.3+)

对于Consumption (根据文件的后缀名称区分) OMADRMv1’s right: *.drc OMADRMv1’s content: *.dcf OMADRMv2’s right: *.ort OMADRMv2’s content: *.odf

在Engines之上，构建了一层Unified DRM API (DRMFW: DRM Framework)。这层在LJ6.1上是没有的。构建的目的，就是想要让上层的应用能够统一的对应DRM处理（将来会把Janus DRM和其他的DRM合并进来）。下图是LJ-UDA (Unified DRM API)的设计：

OMA DRM-Aware Apps UDA Client APIs SPEF Client UDA Server DEPI udadaemon DEPI Config File DEPI Routing Engine DEPI Library Engine DEPI Adaptor DEPI Adaptor Consumption Acquisition Consumption Acquisition DRM FS Library Library Library Library Library DRM FS Library Fig.5 UDA Daemon Architecture Diagram

DEPI (DRM Engine Plug-in) 就是对于Engine的抽象，这些engine的区分由config文件来完成，使得UDA成为可能，并可以动态plug in。

OMADRMv1是比较简单的协议，它跟OMADRMv2是不兼容的。当然，它的安全性和完整性的保护是非常弱的。在这里先不介绍。下面是关于DRMv2 engine方面的设计。 从上面的描述，我们知道，DEPI对engine进行了抽象，而每个具体的engine通过Adaptor具体实现这些engine的抽象。下图是在Adaptor层之下针对DRMv2的设计架构。 对于OMADRMv2.0的设计，是在Adaptor之下，包括两个主要的库：API and SPI (Service Provider Interface). SPI 封装了底层的依赖细节，而API 负责DRM 逻辑界面，也是跟DRMv2 Adaptor的逻辑界面。这样做的好处就是，能够屏蔽底层的细节，比如，Browser 从Opera 迁移到 OSB， 不会影响到上层的，只要在SPI中的Adaptation Layer 进行修

改就行。再如，Database的改变也同样不会影响上层的逻辑。 API中具体的Sub-Component如下：

a) ProtectedRO: Server端分发的License都是以ProtectedRO (XML)格式存在的，这

个模块主要完成的是ProtectedRO的分析。

b) DCF: OMA DRM的内容是以DCF的格式存在的，这个模块完成DCF的parse。 c) ROAP: 这个模块完成Roap协议的分析处理和状态机的转化。

d) RO: 这个模块完成RO的逻辑处理，比如，RO的检索，消费和保护等。 e) Domain Context: 这个模块完成的是Domain Context的处理。对于每个Domain的处

理，都需要相关的Domain Context，而这个通过ROAP完成创建、更新和删除等。 f) RI Context: 这个模块完成的是RI Context的处理。DRMV2处理的一切出发点都是

基于RI Context，它其实是Server端在手机端的抽象表示。它是通过ROAP完成创建、更新和删除等。

g) TransportMgr: 这是一个Utility的模块，它主要是在HTTP之上封装一层的跟

OMADRM协议交互相关的操作。 SPI中的Sub-Component如下：

1. OADB:这是OMA DRM的数据库模块（Object Association Data Base），有关DRM

所有有关的信息都是在这里保存。它需要特别的处理，不能被出了DRM之外的模块访问，这需要有底层的机制进行控制。

2. Crypto: 这个是DRM 针对加密需求的一个接口层，它真正的内容是由TPAPI/和第

三方库来完成的。

3. XMLSec: 这个是XMLSec相关的内容处理。

4. Certificate / OCSP: 该子模块封装跟证书处理、OCSP验证相关的问题 5. SecureAccess: 处理跟安全访问相关的问题，比如安全时钟等。

6. Adaptation Layer for the Platform: 这一层封装了跟系统相关的接口。SPI就是base

在这层之上，这样可以hook一些内容，使底层可更换。比如，对于Memory的接口层，使得调试内存管理成为可能。GUI模块则是封装了跟drmengineui (UI Server)的处理。

7. 3rd-party libraries: 遵循motorola的惯例，DRM使用了很多的3rd-party的libraries.

当然这些库经过了DRM的封装，可使这些3rd-party libraries可替换。

ConsumptionAcquisitionExposed ModulesL-J Dependency ComponentProtectedRORODCFDomain ContextROAPRI ContextTransportMgrInternal Moduleslibxml2Certificate/OCSPOADBCryptoXMLSecSecureAcessxmlsecPlatform Dependent Modules Certicom Security BuilderOMA DRM EngineSecureClockHTTPFile IOMemory MgmtGUILoggingMIMEParserUser IdentityCerticom SSLPlusAdaptation layer3rd party libraries Fig.6 OMADRM Engine v2 Architecture Diagram

4. Process Deployment of Linux-Java Implemetation

上述的介绍是OMA DRM的静态结构，这节我们介绍一下OMA DRM Linux-Java实现的进程模型。

OMADRM的进程模型包括，udadaemon, drmengineui, drm。另外， udadaemon还有2个线程， 一个是drmfs，负责content的解密，而另外一个现在在需要进行silent RO acquistion的时候启动。

drmengineui: 这个是OMA DRM的UI Server, 负责所有drm的UI。它的client包括，udadaemon, 也包括其他的任意的DRM-aware的applications。

drm: 负责DRM WAP Push事件的处理，在DRMv1的Separate Delivery中的right object就是通过WAP Push获得的。在DRM v2.1中，ROAP Trigger也会通过WAP Push传输到手机。当系统得到WAP Push的消息后，Event System会启动drm，而drm作为udadaemon的client， 通过IPC把得到的数据交由udadaemon去处理。

udadaemon: udadaemon是OMADRM的核心。它是负责right object相关处理的唯一进程。同时，它还负责启动一个fuse的daemon (drmfs)， 负责解密content。同时，当需要获取Slient

RO的时候，udadaemon会启动一个单独的线程来完成。（目前只是在异步获取的时候会启动，而在同步获取的时候，则是由udadaemon完成的。

Drmengineui (UI Server) Acquisition applications, e.g. Browser WAP Push Event System drm Consumption applications， e.g. Media-player IPC IPC IPC IPC Silent-url processing udadaemon drmfs Linux Java OS Fig.7 Processes Deployment of OMA DRM fuse 5. Interfaces Design on Linux-Java Platform

主要的设计接口如下（省略了参数和返回值的信息，主要为了介绍下面的Use case铺垫）：

5.1 Consumption相关的接口

1. DRM_IsDRMFile(file_path);

确定给定的文件是否是DRM文件，如果不是，按照正常的逻辑处理，否则，以DRM的方式处理。

2. DRM_GetContentMetaDataInFile(file_path, **meta_data, *num);

获取给定的文件的DRM Meta Data。以后的处理都是在meta的的基础上进行的。 3. DRM_StartRightsMeter(**session, file_path, action, ….);

创建以action（play, print, display, …）消费的会话。当调用该接口后，如果存在right object能够消费，则会返回ACTION_ALLOWED, 同时，right object也被消费了。 4. char * DRM_CreateConsumptionFilePath(*session, *file_path, …);

根据会话，创建虚拟的消费文件名。这有点类似买票看电影似的。先花钱（right object），然后得到一张电影票(virtual path)，最后用买来的电影票进入电影院(open, read)。如果没有电影票，使用原先的文件名，得到的仅仅是一个密文。而使用虚拟的文件,用正常的文件系统调用（open/read）得到就是明文的内容。 5. DRM_StopRightsMeter(*session);

当消费完事后，需要Stop一下，释放相应的资源。

5.2 Acquisition相关的接口

1. DRM_StartDownload(**context, ….);

创建download的context, 类似于下载的会话。 2. DRM_HandleNextPart(*context, …);

DRM的消息往往有类似于muti-part的格式，当开始一个part的时候，调用这个接口。 3. DRM_WriteContent(*context, buffer, size);

在完成创建好part的信息后，就可以往其中写数据了。 4. DRM_FinishCurrentPart(*context, *request);

在往常当前的part的内容后，调用该接口最后接口。Request是用于Browser的DLA的信息交互的。

5. DRM_FinishDownload(*context);

当完成download之后，调用该接口释放资源，并对下载的内容进行DRM的处理。

以上就是目前DRM设计的主要对外接口。正如前面所述，主要包括Consumption / Acquisition的内容。

6. Main Use Cases of Linux-Java Implementation

1) DRM文件的存在right object时的消费：

consumption appsudadaemonkernel fusedrmfs1 : DRM_IsDRMFile()2 : DRM_GetMetaDataInFile()3 : DRM_StartRightsMeter()4 : DRM_CreateVirtualFilePath()5 : open()7 : read()9 : read()11 : close()13 : DRM_StopRightsMeter()6 : drm_open()8 : drm_read()10 : drm_read()12 : drm_close()

2）

7. Problems:

1）在OMA DRMv2 spec中，存在一个问题。那就是“加密过头”。我们知道知道content是经过加密之后传输的，这个加密的内容需要用right object中的CEK才能加密。尽管在DCF的meta data中以明文的方式记录了很多有用的信息，比如， Author, type, title等等，而在实际的应用中，content中的很多元数据是需要提示给用户的，比如，artist, composer, rating等等，这些信息是存在content的meta data中的，没有right object无法解密 . 这个问题在Media Finder中存在。

2）在目前的OMADRM实现中，DLA跟DRM是耦合的很紧。但DLA发现一个DRM的MIME Type时，它把接收到的数据传递给DRM，DRM负责解析，然后会生成相应的response，而这个response buffer又通过IPC传回给DLA, 由DLA负责把相应的response发送回给server。这样做的结果DLA需要首先了解DRM的协议包（这个不应该是他们要做的）。另外通过IPC传递这些buffer也是一个不小的代价。

3）对于DCF的下载、parse也要通过udadaemon也是一个不好的设计。我们知道DCF是以加密的形式存在，没有right object它是无法解密的。而要获取DCF的元数据应该是任意的app都可进行的。我认为，对于DCF除了解密之外的处理都不应该通过udadaemon的IPC进行，只要提供一个库即可。也就是对于DCF的下载相关和parse相关的处理要独立于udadaemon。

4）对于后台获取ro的信息，应该以单独的线程来进行。在目前的实现中，如果存在一个同步获取right object的时候，而此时网络很慢，会导致udadaemon一直在等待回应的状态。若此时来一个call，设计的铃声是DRM 文件，那么会导致call的丢失。在目前的设计无法解决这个问题。因此这个可以通过多线程来解决。也就是说，udadaemon来完成的仅仅是消息的转发的功能，其他的功能需要通过线程来完成。

8. Suggestions:

根据上述描述的问题，refactor目前的设计如下：