DRM标准学习笔记1
1. 缘起
- 旱就听说过DRM,但一直不知道具体的详细内容及实现,现在终于要用到它了,所以做了一个系统的了解及学习。
2. 技术方案(标准)
- 数字版权管理DRM技术是通过一定的安全算法/协议与安全管理手段实现对数字内容(电子书、视频、音频和图片等)的保护,使数字内容在未经授权和允许的条件下不能使用、复制和分发等。DRM不仅处理内容的物理传送,还对内容的整个生命期进行管理和控制。将DRM技术引入移动通信业务,可以确保数字内容在移动网内的传播,保证内容提供商的利益。
-
现有的DRM技术方案很多,标准化方案主要包括:
- OMA DRM 1.0、
- OMA DRM 2.0、
- Marlin,
- 以及微软DRM等私有方案。
3. OMA DRM
3.1. OMA DRM介绍
- OMA(Open Mobile Alliance,开放式移动体系结构)正式成立于2002年6月初,其前身为:Open Mobile Architecture Initiative supporters和WAP Forum。后续有一些组织加入了OMA,包括Wireless Village,MGIF(Mobile Gaming Interoperability Forum),Sync ML Initiative,MWIF(Mobile Wireless Internet Forum),MMSIOP和LIF(Location Interoperability Forum)。OMA的主要任务是收集市场需求并制定规范,清除互操作性发展的障碍,并加速各种全新的增强型移动信息、通信和娱乐服务及应用的开发和应用。OMA代表了无线通信业的革新趋势,它鼓励价值链上所有的成员通过更大程度地参与行业标准的制定,建立更为完整的、端到端的解决方案。
- 目前OMA已经超过400多个来自全球的成员单位,构成了完整的移动业务价值链,包括移动运营商、无线设备提供商、信息技术公司和内容提供商等主要的4大类成员单位。
- OMA组织于2002年9月发布了OMA DRM V1.0,于2006年3月发布了OMA DRM V2.0。OMA DRM标准是完全开放的,目前大部分运营商都已经采用或计划采用OMA DRM标准。
- DRM v1.0标准定义的是一个初级的DRM系统,基本能够满足Forward Lock、Combined Delivery、Separate Delivery方式的商用需求;
- 而其它版本是一个更加复杂和安全的DRM系统,如OMADRM2.0增强支持Combined Delivery、Separate Delivery等方式和流媒体业务,满足规模商用的需求;
- OMA DRM2.1在2.0版本的基础上进行了进一步增强。
3.2. OMA DRM 1.0
3.2.1. 概述
-
OMA DRM 1.0是OMA组织推出的最早的版本,其内容保护方式主要有:转发锁定、组合分发、分离发送和超级分发。分别阐述如下:
- 禁止转发。一个媒体对象被封装在一个DRM消息中传输给设备,允许设备使用内容,但是内容不能转发到其他设备,且设备不能修改此媒体对象。
- 组合发送。一个权限对象和一个媒体对象被封装在一个DRM消息中发送给设备,设备可以根据权限对象的规定向用户提供内容,但不能修改、转发权限对象和媒体对象。
- 分别发送。内容对象打包成一种特殊的DRM内容格式(DRM Content Format,DCF),采用对称加密技术,必须使用内容密钥(Content Encryption Key,CEK)才能够访问媒体内容,CEK存储在版权对象中。这样,内容可以经过非安全的传输途径传送,而版权对象的传送则需要更高安全性的传输通道。
- 超级分发。超级发送是分别发送的一种特殊应用方式。在这种模式下,终端之间可以通过任何可能的途径传送媒体对象,而版权对象只能通过WAP Push从版权发布服务器获得。这样就在不危及任何版权维护的商业模式的条件下,极大地鼓励了用户之间更加方便地共享媒体对象。
-
OMA DRM 1.0的基本特点如下:
- 内容保护方式:转发锁定、组合分发、分离发送、超级分发
- 下载方式:内容下载采用HTTP下载或OMA下载。RO下载采用WAP PUSH。组合发送与分离发送,RO都不加密。RO存在延时问题
- 媒体格式:除流媒体外,对媒体格式没有限制,依赖于终端的播放器支持
-
功能方面:
- 由于不支持分断加密,因此不支持片断预览模式。
- 只能在手机之间共享,不支持域共享
- 支持音乐、视频、软件、游戏、图片等多种业务模式。只适用于下载业务领域,如:OMA下载和HTTP下载。不支持广告模式。使用Wap Push获取权限,用户感受差
- 方全问题:无安全时钟、RO不加密、RO无完整性保护等
- 商用成熟度:终端支持程序高,已经有大量的运营商商用案例
- 总体上,OMA DRM 1.0保护方式较少,用户体验一般,不支持域及分段预览,流媒体,业务模式少;安全性较弱;商用成熟度高。由于OMA DRM 1.0的安全性问题,使得OMA DRM 1.0主要应用于低价值内容的保护。OMA DRM 1.0仅被推荐应用于图片、铃声等小附加值内容保护。目前Vadafone,Orange(MusicWave),T-Mobile Europe,Cingular,T-Mobile USA等运营商已经有商用案例。
3.2.2. 详细流程
3.2.2.1. 应用
- OMA中关于DRM的定义主要是为了给内容提供商提供一种控制媒体对象使用的方式,包括对DRM Message的预览、保护文件、防止非法拷贝、超级传送(一种合法的拷贝方式)。
- 在DRM的范畴内,为了保证媒体对象的合法使用,一旦对象被下载,就被DRM Agent(通常是运行在移动终端上,实现DRM控制)接管了。
- DRM系统允许内容提供商给不同的媒体对象添加不同的版权对象,同一媒体对象也允许添加不同的版权对象,由此,内容提供商就可以根据不同的版权对象来定价,客户们根据定价进行消费,于是,一套合理的电子消费系统就产生了。内容提供商会提供用户预览DRM Message的版权对象,一些精彩的预览画面往往会吸引更多的消费者。
- 应该这么来理解,版权对象和媒体对象都可以看作实体,受保护的媒体对象可以较容易获得,但是版权对象则需要单独购买。有了版权对象才能播放受保护的媒体对象。
3.2.2.2. 获得的四种方式
-
关于版权对象和媒体对象的获得主要是以下三种方式:
- Forward-lock
- Combined delivery
- Separate delivery
- 前两种方式是:Forward-lock,即转发锁定;Combined delivery,即组合发送。这两种方式都需要将媒体文件打包,如果是使用第二种方式,还需要将版权对象和媒体文件打包在一个文件中。DRM Agent根据版权对象来播放媒体对象,如果未包含版权对象,则根据DRM Agent中设置的默认版权进行播放。
- 第三种方式是Separate delivery,即分组发送。将媒体对象打包成OMA DRM V1.0中规定的DCF(DRM Content Format)格式,使用对称密钥加密。若要播放媒体文件,只有获得CEK(Content Encryption Key),进行解密。因此,在传送DCF文件时,可以使用安全性较低的通信方式,在传送版权对象以及CEK时,则需要一种安全性高的方式。在1.0版本中,使用短信推送的方式,将版权对象发送给移动终端。
- 根据分组发送,OMA DRM V1.0中提出了超级分发的概念。允许在多个移动终端之间传递DCF文件,但是并不能传递版权对象。当未包含版权对象的移动终端接收到DCF文件后,会根据文件中的定义,访问对应的版权对象服务器,提示用户购买相应的版权对象并下载。
-
支持转发锁定方式的移动终端需要支持的媒体对象格式为:
- application/vnd.oma.drm.message。
-
支持组合发送方式的移动终端需要支持的媒体对象格式为:
- application/vnd.oma.drm.message
- application/vnd.oma.drm.rights+xml
-
支持分组发送方式的移动终端需要支持的媒体对象格式为:
- application/vnd.oma.drm.content
- application/vnd.oma.drm.rights+xml
- application/vnd.oma.drm.rights+wbxml
3.2.2.3. 传送对象的不同
-
转发锁定:
- 在转发锁定方式中,移动终端是禁止转发DRM Message的(DRM Message是讲媒体对象打包后生成的文件,但是没有加密,明文存储)。必须支持DRM Message文件格式。如果移动终端接收到一个包含版权对象的DRM Message(在组合发送方式中,处理的对象是包含版权对象的DRM Message),则需要在提示用户后,将该DRM Message抛弃。移动终端可以播放媒体对象,但是不能对其修改。
-
组合发送:
- 支持组合发送方式的移动终端必须支持转发锁定方式,在该方式中,移动终端根据版权对象来播放媒体对象。版权对象和媒体对象通过被包装在同一个DRM Message中。对于这两个对象本身来说,其关联是外部的,因此移动终端必须保证在收到DRM Message并可能拆包后丢弃的情况下,永久保存版权对象。移动终端不得将组合发送方式中的媒体对象转发。当移动终端使用下载内容时,必须遵循用版权对象描述语言“Rights Expression Language”描述的规定。REL控制下载内容的使用,例如下载媒体对象是否仅被允许打开一次等。
-
分组发送:
- 支持分组发送的DRM Agent必须支持组合发送和转发锁定,在分组发送中,媒体对象通常是通过加密的,并转换为DCF格式。DCF文件通过OMA Download方式下载到设备上,版权对象则通过其他的途径送达(WAP Push)。在分组发送中,允许设备将DCF文件转发,但是版权对象是不允许转发的,接收到DCF文件的其他设备需要从Right Issuer获取版权对象。移动终端必须同时支持版权和DRM内容格式(DCF)媒体类型。
3.2.2.4. 举例
-
转发锁定方式中,服务器端返回的DRM Message
Content-type: application/vnd.oma.drm.message; boundary=boundary-1 Content-Length: 574 --boundary-1 Content-type: image/jpeg Content-Transfer-Encoding: binary ...jpeg image in binary format... --boundary-1—
-
在组合方式中,服务器端返回的DRM Message
HTTP/1.1 200 OK Content-type: application/vnd.oma.drm.message; boundary=boundary-1 Content-Length: 893 --boundary-1 Content-type: application/vnd.oma.drm.rights+xml Content-Transfer-Encoding: binary <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD" > <o-ex:context> <o-dd:version>1.0</o-dd:version> </o-ex:context> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid>cid:4567829547@foo.bar</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:display/> </o-ex:permission> </o-ex:agreement> </o-ex:rights> --boundary-1 Content-type: image/jpeg Content-ID: <45678929547@foo.bar> Content-Transfer-Encoding: binary ...jpeg image in binary format... --boundary-1—
-
分组发送方式中,服务器端返回的DRM Message
HTTP/1.1 200 OK Content-type: application/vnd.oma.drm.content; Content-Length: 1234 X-Oma-Drm-Separate-Delivery: 12 ...DRM content in DCF format...