Android-DRM详解
DRM简介:
DRM: Digital Rights Management(数字版权管理)。
日常生活中，我们经常听到“版权“这两个字，到底是什么版权的呢？你大概可以理解: 版权就是别人拥有的东西你需要按照所有者的条款才能对这个东西进行观看，转发或者存储等。例如: 爱奇艺视频最近热播的电视剧《在远方》，你需要会员才可观看最新的剧集，这就是爱奇艺拥有的版权。
但是如果没有版权保护，你可以下载会员才可观看的视频，然后分享到网络上，别人只需要访问你的链接就可以不用会员也能观看。这对版权拥有者来说是一个重要的损失。综上: 数字版权保护特别重要！！！那安卓手机中对数字版权保护的视频是怎么处理的呢？本文将带大家来一起了解~
DRM工作原理:
DRM技术的工作原理是，首先建立数字节目授权中心。编码压缩后的数字节目内容，可以利用密钥（Key）进行加密保护（lock），加密的数字节目头部存放着KeyID和节目授权中心的URL。用户在点播时，根据节目头部的KeyID和URL信息，就可以通过数字节目授权中心的验证授权后送出相关的密钥解密（unlock），节目方可播放。
DRM标准:
严格来讲，DRM是一类技术，而不是一项技术，很多机构也曾提出了关于DRM的标准，例如：Open Mobile Alliance推出的OMA DRM、Marlin Developer Community提出的Marlin DRM，而Google則通過收購Widevine公司推出了Widevine DRM。
目前安卓终端应用的大多数都是google原生的Widevine DRM。
DRM框架和集成:
和codec一样，为了方便厂商集成自己的DRM方案，DRM提供了一个通用的软件框架，厂商可以通过Plugin的方式把自己的DRM解决方案整合到安卓系统中。具体的软件框架如下:
如上图:
- DRM Framework API从Framework层暴露给App。(framework层的实现详见DrmManagerClient)
- DRM Framework通过binder的方式和DRM manger通信，获取服务。(具体代码: framework/av/drm/drmserver)
- 各个不同的DRM解决方案通过plugin的方式注册到DRM manger中。
- 解密工作的具体实现都在plugin中。
Android中DRM架构中重要类图：
如上图:
- FileSource代表一个媒体文件。如果媒体文件中有DRM信息，它将创建一个DrmManagerClient对象。该对象用于处理媒体文件中和DRM相关的操作。DrmManagerClient内部通过DrmManagerClientImpl和位于drmserver进程中的DrmManagerService进行跨Binder通信。
- MediaExtractor类封装了用于解析媒体文件中元数据的相关函数。对于DRM来说，系统会根据的DRM种类创建不同的MediaExtractor子类。和FileSource类似，MediaExtractor也通过DrmManagerClient和drmserver通信。
- DrmManagerService运行于drmserver进程中，它是整个DRM框架的核心。DrmManagerService借助DrmManager管理系统中的DRM插件。
- DRM插件必须实现IDrmEngine接口。为了方便开发者，Android提供了DrmEngineBase类，该类继承了IDrmEngine接口并实现了一些通用的接口函数。这样，DRM Plugin只需要从DrmEngineBase派生即可。
- 如前文所述，DRM框架中真正完成DRM处理工作的是DRMPlugins，这些Plugins大都需要得到相关机构的授权后才能得到相应的专利代码包。图1中列出了三个DRM Plugin。其中FwdLockEngine（OMA-V1的Forward Lock）由AOSP提供。Marlin Plugin和WidevinePlugin则需要相关DRM机构提供专利代码包。
DRM在Android中的应用:
如上图:
- DrmServer 启动流程：在init进程启起来之后，会启动各种服务，其中就有drmserver服务。在init.rc 文档里：service drm /system/bin/drmserver
- DrmManagerService实例对象由drmserver进程在main函数中调用instantiate创建。
-
DrmManagerService内部会创建一个DrmManager实例对象并调用loadPlugins来加载设备可能提供的DRM Plugin。
-
DRM Plugin通过动态库的方式集成到设置中去。Android 中有两个目录可存放DRM Plugin。一个是/vendor/lib/drm/，例如Widevine对应的libdrmwvmplugin.so一般放在这个目录中。另一个目录是/system/lib/drm/。每一个DRM Plugin对应为一个IDrmManager实例。所有被加载的DRM Plugin由DrmManager来统一管理。
-
DrmManagerService最后将通过addService把自己注册到Binder系统中以为广大客户端服务。
OMA DRM调用流程:
DRM 媒体文件播放：
Android支持的DRM播放方式分为两种：
1. 基于基本码流的（Elementary Stream Based，简称ES Based）播放方式。ES Based DRM意味着每一个数据基元在播放时都需要解密。这种DRM的媒体文件或流可以使用普通方式正常读取，但读取出来的数据是经过加密的。如果不能对数据正确解密，那么该数据将无法正常播放。目前Widevine DRM、Marline DRM都属于这一种类型。
2. 基于容器的（Container Base）播放方式，目前OMA DRM支持这种方法。（目前Android5.0默认使用）
DRM媒体文件播放 - 初始化DRM插件:
如上图：
MediaExtractor首先通过sniff函数检查媒体内容的类型，然后创建相应的Extractor来分析数据。在DRM检查开启的情况下，SniffDRM函数就会被用来检查文件是否有DRM控制。 SniffDRM将调用DataSource中的DrmInitialization函数，从而在DataSource中创建一个DrmManagerClient实例。如此，MediaExtractor就将DataSource与DrmManagerService联系起来。 DrmInitialization函数非常重要，其 主要工作包括：
（1）调用openDecryptSession，该函数内部会根据文件中的DRM信息来初始化正确的DRM Plugin（Widevine、OMV，还是其他DRM类型）。
（2）创建DecryptSession，并将DRM信息封装在DecryptHandler实例中传给FileSource。 DrmInitialization之后，SniffDRM会通过DecryptHandler来判断该文件是否有DRM控制，并分析出该DRM是ES Based，还是Container Based。如果属于ES Based DRM，MediaExtractor会创建一个DRMExtrator，而在DRMExtrator中，会创建一个MPEG4Extractor。 MediaExtrator创建完后，播放器即可开始播放。
DRM 媒体文件播放 - ES Based DRM播放流程:
如上图:
第一个阶段是资源初始化过程。该过程中，媒体播放器将通过getTrack以后获取一个媒体文件中代表媒体数据的DRMSource实例，DRMSource只负责DRM的控制和解密，而实际媒体数据的分析仍交给MPEG4Extractor来完成。对于播放器来说，它只和DRMExtrator和DRMSource交互。另外，在这一阶段中，initializeDecryptUnit函数将初始化解密相关的资源。 第二阶段就是媒体数据读取，针对每一个数据基元，DRMExtrator都会先通过MPEG4Extractor取得未解密的原始数据，然后通过decrypt函数来请求DRM Plugin进行解密。解密后的数据会被放到另外一处缓存中供Codec使用。如果解密失败，decrypt将会返回错误，故播放器将无法解析这些数据。 媒体播放完毕后将释放播放资源。和DRM相关的资源将由finalizeDecryptUnit来释放。 回顾上述流程，对ES Based DRM的特点是，不论用户是否有权限，播放器都能读取到媒体数据。
DRM 媒体文件播放 - Container Based DRM播放流程:
和ES Based DRM截然不同的是Container Based DRM。受控于这种DRM管理的媒体文件在被读取时就会进行DRM的权限验证，如果验证失败，则无法从中读取到数据。故Container Based DRM最关键的是其pread接口，相关流程如下图所示：
如上图:
首先要进行的工作仍是判别数据格式和DRM类型并创建DrmManagerClient。这一过程和ES Based DRM流程相同，此处不拟赘述。 接下来需创建MediaExtractor实例。与ES Based DRM不同的是，Container Based DRM在播放时无需创建DRMExtractor，而是直接创建MPEG4Extractor，并在该MediaExtractor中设定DRM的标识。 Container Based DRM关键在于pread函数。当MediaExtractor从FileSource中提取数据时，readAt最终通过DrmManagerClient的pread函数来访问DrmManager以从中读取数据。DrmManager将调用具体的DRMPlugin实现的pread。数据的权限检查和解密的工作都在该DRMPlugin完成。如果DRM解密失败，pread将不会得到数据。
DRM媒体文件播放 - DRM文件的读取:
DRM 媒体文件播放 - DRM文件的播放:
Android平台中播放Widevine DRM媒体：
有两种播放方法：
第一种方法和前文介绍的一样。Widevine DRM按照ES Based的流程进行播放。但和一般DRM不同的是，Widevine使用的Extractor是WVMExtractor，而不是DRMExtractor。
第二种方法是MediaCodec模式，相关结构如下图。
MediaCodec、MediaCrypto以Java API的形式直接暴露给应用层。这样，应用层能够控制解码、解密的过程。 Crypto Plugin是实际完成解密的模块，其结构和前文提到的DRM Plugin有所不同。 需要特别指出的是，Android目前对MediaCodec模式支持还不是很完善。根据笔者的试验，一些市面上流行的高端Android 4.1手机还不支持这种播放方式。 另外，Widevine的代码结构大体可分为三部分： 第一部分是Android中的基本框架，包括WVMExtractor等。这部分代码在AOSP中都可以看到，属于Open Source的内容。这部分代码大多没有实质性内容，相关功能的实现封装在第二部分的专利代码包中。 第二部分是Widevine的专利代码包。这部分代码需要得到Google授权后才能得到。该包提供了很多Widevine专用库用于完成Widevine DRM权限检查和解密。同时，它还提供了一些Sample App用于测试。 第三部分是手机厂商自身的安全认证。Widevine是一个很强的版权控制体系，它甚至可在硬件层与厂商的安全机制绑定。很多知名的手机厂商都在boot等底层中加入自己的安全机制，只有通过可信赖的boot loader进行刷机才能得到具有正常权限的手机软件，并可以使用Widevine。这也是为什么很多破解的手机无法使用Widevine的原因。 由于专利代码包和厂商安全机制都涉及到版权问题，故本文就不拟对Widevine做进一步讨论了。如果厂商希望在自己的产品上也搭载Widevine，那么首先需要与Google联系。Google会提供Widevine的专业培训。
OMA DRM文件分为以下三种类型：
- forward lock 类型: 后缀为.dm 文件。文件由文件头和媒体内容组成，媒体内容是二进制明码。文件头部分，记录了媒体内容编码方式，媒体内容类型等。该类型不允许通过设备应用转发给其他设备。针对手机举例，不允许作为 Mms，Email 附件，不允许通过蓝牙共享。可以在本机上无限制使用，一般为铃声。（forward lock只加密头信息，不加密媒体内容？？？加密算法不管数据类型，只对二进制数据进行加密）
- Combined delivery类型: 后缀为.dm 文件。文件有两部分组成，第一部分是权限信息，第二部分为媒体信息, 文件内容也是明码形式。权限信息为 info结构,并包含有一个 content-id 元素，媒体信息部分也包含有一个文件头有 content-id,这两个 id 完全相同,并且这两个不同 id 一定是对应到 DRM 服务器上不同的媒体文件。 该类型文件的使用由其中包含的权限文件进行约束。
- Seperate delivery类型: 后缀为.dcf 文件。它的文件由文件头与媒体信息组成，文件头有 content-id， 媒体信息是加密的。它的权限文件是通过 wap push 或者其他形式单独传送的，后缀为.drc 形式。权限文件会包括 id 以及 key这两个节点。
forward lock 类型:
forward lock 类型的识别：
1) 以 46 57 4C 4B 四个字符开始
2) 第五个字符为00
满足以上两个标准就是orward lock类型的文件。
用特定工具，或者是手动编写，将一个普通的视频文件（例如mp4) 生成一个符合标准的DRM文件，放到服务器上；用户付费后，用下载工具将此DRM文件下载到本地；下载工具必须支持这种DRM文件，下载的时候，其内部实际上是把此DRM文件进行了加密，加密算法可以采用AES等算法。密钥应该是每台机器生成一个唯一的密钥，加密和解密密钥是相同的。这样，在本地端就有了一个加密的媒体文件，用户可以在本机上进行播放，但如果COPY到另外的机器上，由于密钥不同，所以不以成功解密，这样就达到了ForwardLock的目的。
Combined delivery类型:
combined delivery类型的识别：
1) 以 46 57 4C 4B 四个字符开始
2) 第五个字符为01满足以上两个标准就是combined delivery类型的文件。
文件有两部分组成，第一部分是权限信息，第二部分为媒体信息, 文件内容也是明码形式。权限信息为xml结构,并包含有一个content-id元素，媒体信息部分也包含有一个content-id,这两个id完全相同。不同id一定是对应到DRM服务器上不同的媒体文件。该类型文件的使用由其中包含的权限文件进行约束。
目前的CD文件有RO权限.RO+Content绑定在一起，大致包括下列几种类型：
有次数限制的，如count 5 times，只允许播放5次
有期限限制的，如2013年7月8日12点—2013年7月10日18点
期限截止的， 如2013年9月5日之前.
次数和期限结合的,,如2013年7月10日—-2013年7月13日,count 5,,就是在这期间只能播放5次
且用户不可以手动更改时间来把已过期的CD文件变为有效的文件。
Seperate Delivery：
SD的文件和CD文件类似,只是用户需要去服务业者的网络上先去下载内容文件.当下载内容文件后.还得花钱去购买权限RO。只有获得有效的RO，才可以播放SD文件,同CD一样,SD文件也是无法通过更改手机时间来把已过期的SD文件变为有效的文件。SD文件可以通过MMS进行发送.但是发送之前,用户必须购买SD的RO权限才可以经过MMS,BT,EMAIL等发送。如果用户只是用SD的内容文件去发送,可以发送出去,但是接收端的用户也是无法使用该SD文件的。对于.dcf内容文件，它的文件由文件头与媒体信息组成，文件头有content-id， 媒体信息是加密的。