RM，英文全稱為Digital Rights Management，譯為數(shù)字版權(quán)管理。它是目前業(yè)界使用非常廣泛的一種數(shù)字內(nèi)容版權(quán)保護(hù)技術(shù)。隨著知識(shí)產(chǎn)權(quán)保護(hù)受重視的程度日益提高，快速攻城略地得Android智能手機(jī)是如何利用DRM來(lái)有效保護(hù)數(shù)字版權(quán)的呢？本文將通過(guò)剖析Android中的DRM框架以及相關(guān)工作流程來(lái)向讀者揭示DRM的神秘面紗。

一  DRM架構(gòu)介紹

嚴(yán)格來(lái)講，DRM不是一項(xiàng)技術(shù)，而是一類技術(shù)。很多機(jī)構(gòu)和聯(lián)盟都提出過(guò)相應(yīng)的DRM標(biāo)準(zhǔn)。例如Open Mobile Alliance推出的OMA DRM、Marlin Developer Community提出的Marlin DRM，而Google則通過(guò)收購(gòu)Widevine公司推出了Widevine DRM。

從Android智能終端來(lái)看，Google的原生Android（Android Open Source Project，簡(jiǎn)稱AOSP）系統(tǒng)僅僅集成了OMA DRM V1的一部分功能，它遠(yuǎn)未構(gòu)成一個(gè)完整的DRM解決方案。在這種情況下，設(shè)備廠商只能根據(jù)情況選擇合適的DRM解決方案并集成到Android平臺(tái)中來(lái)。例如，手機(jī)廠商可以通過(guò)Google的授權(quán)以獲取Widevine DRM對(duì)應(yīng)的軟件包從而將Widevine DRM集成到自己的產(chǎn)品中。

為了方便設(shè)備廠商的集成，Android設(shè)計(jì)了一個(gè)通用的DRM軟件框架，不同的DRM解決方案可通過(guò)Plugin的方式集成到Android系統(tǒng)中。圖1所示為Android中的DRM軟件架構(gòu)。

圖1  Android中DRM軟件架構(gòu)

由圖1可知:

• DRM Framework API模塊是Framework層暴露給App的接口。該模塊中最主要的類是DrmManagerClient。
• DRM Framework API模塊通過(guò)Binder機(jī)制和位于drmserver進(jìn)程（以Android 4.1為例，drmserver的代碼位于framework/av/drm/drmserver）中的DRM Manager模塊通信。DRM Manager加載并管理系統(tǒng)中所有的DRM插件。
• DRM Plugins是真正實(shí)現(xiàn)權(quán)限管理、數(shù)字內(nèi)容解密等工作的模塊。根據(jù)DRM標(biāo)準(zhǔn)的不同，這些Plugins的實(shí)現(xiàn)亦不相同。另外，一個(gè)手機(jī)可能會(huì)集成多個(gè)DRM Plugin。這是因?yàn)槊襟w文件如果采用不同的DRM解決方案進(jìn)行加密的話，手機(jī)在播放它們時(shí)，DRM Manager需找到對(duì)應(yīng)的DRM Plugin以進(jìn)行解密。

圖2所示為DRM架構(gòu)中幾個(gè)重要的類及其關(guān)系。

圖2  Android中DRM架構(gòu)中重要類圖

由圖2可知:

• FileSource代表一個(gè)媒體文件。如果媒體文件中有DRM信息，它將創(chuàng)建一個(gè)DrmManagerClient對(duì)象。該對(duì)象用于處理媒體文件中和DRM相關(guān)的操作。DrmManagerClient內(nèi)部通過(guò)DrmManagerClientImpl和位于drmserver進(jìn)程中的DrmManagerService進(jìn)行跨Binder通信。
• MediaExtractor類封裝了用于解析媒體文件中元數(shù)據(jù)的相關(guān)函數(shù)。對(duì)于DRM來(lái)說(shuō)，系統(tǒng)會(huì)根據(jù)的DRM種類創(chuàng)建不同的MediaExtractor子類。和FileSource類似，MediaExtractor也通過(guò)DrmManagerClient和drmserver通信。
• DrmManagerService運(yùn)行于drmserver進(jìn)程中，它是整個(gè)DRM框架的核心。DrmManagerService借助DrmManager管理系統(tǒng)中的DRM插件。
• DRM插件必須實(shí)現(xiàn)IDrmEngine接口。為了方便開(kāi)發(fā)者，Android提供了DrmEngineBase類，該類繼承了IDrmEngine接口并實(shí)現(xiàn)了一些通用的接口函數(shù)。這樣，DRM Plugin只需要從DrmEngineBase派生即可。
• 如前文所述，DRM框架中真正完成DRM處理工作的是DRMPlugins，這些Plugins大都需要得到相關(guān)機(jī)構(gòu)的授權(quán)后才能得到相應(yīng)的專利代碼包。圖1中列出了三個(gè)DRM Plugin。其中FwdLockEngine（OMA-V1的Forward Lock）由AOSP提供。Marlin Plugin和WidevinePlugin則需要相關(guān)DRM機(jī)構(gòu)提供專利代碼包。

下面來(lái)看看Android中DRM的工作流程。

二  DRM工作流程介紹

2.1  DrmManagerService的初始化

DRM的工作流程和多媒體播放密切相關(guān)。首先來(lái)了解一下DrmManagerService的創(chuàng)建過(guò)程，相關(guān)流程如圖3所示：

圖3  DrmManagerService啟動(dòng)流程

由圖3可知：

• DrmManagerService實(shí)例對(duì)象由drmserver進(jìn)程在main函數(shù)中調(diào)用instantiate創(chuàng)建。
• DrmManagerService內(nèi)部會(huì)創(chuàng)建一個(gè)DrmManager實(shí)例對(duì)象并調(diào)用loadPlugins來(lái)加載設(shè)備可能提供的DRM Plugin。DRM Plugin通過(guò)動(dòng)態(tài)庫(kù)的方式集成到設(shè)置中去。Android 4.1中有兩個(gè)目錄可存放DRM Plugin。一個(gè)是/vendor/lib/drm/，例如Widevine對(duì)應(yīng)的libdrmwvmplugin.so一般放在這個(gè)目錄中。另一個(gè)目錄是/system/lib/drm/。每一個(gè)DRM Plugin對(duì)應(yīng)為一個(gè)IDrmManager實(shí)例。所有被加載的DRM Plugin由DrmManager來(lái)統(tǒng)一管理。
• DrmManagerService最后將通過(guò)addService把自己注冊(cè)到Binder系統(tǒng)中以為廣大客戶端服務(wù)。

下面來(lái)介紹DRM的工作流程。Android支持的DRM播放方式分為兩種：

• 一種是基于基本碼流的（Elementary Stream Based，簡(jiǎn)稱ES Based）播放方式。目前Widevine DRM、Marline DRM都屬于這一種類型。
• 另一種是基于容器的（Container Base）播放方式，目前OMA DRM支持這種方法。

這兩種不同的方式在播放流程上不盡相同。下文將以一個(gè)播放具有DRM保護(hù)的MP4文件為例，介紹DRM的工作流程。首先來(lái)看ES BasedDRM媒體播放工作流程

2.2  ES BasedDRM播放流程

ES Based DRM意味著每一個(gè)數(shù)據(jù)基元在播放時(shí)都需要解密。這種DRM的媒體文件或流可以使用普通方式正常讀取，但讀取出來(lái)的數(shù)據(jù)是經(jīng)過(guò)加密的。如果不能對(duì)數(shù)據(jù)正確解密，那么該數(shù)據(jù)將無(wú)法正常播放。

在播放媒體文件之前，播放器首先要識(shí)別該文件是否被DRM保護(hù)。如果受DRM保護(hù)的話，還行初始化對(duì)應(yīng)的DRM插件。這部分工作所涉及的流程如圖4所示：

圖4  ES BasedDRM插件初始化

#p#

由圖4可知：

• MediaExtractor首先通過(guò)sniff函數(shù)檢查媒體內(nèi)容的類型，然后創(chuàng)建相應(yīng)的Extractor來(lái)分析數(shù)據(jù)。在DRM檢查開(kāi)啟的情況下，SniffDRM函數(shù)就會(huì)被用來(lái)檢查文件是否有DRM控制。
• SniffDRM將調(diào)用DataSource中的DrmInitialization函數(shù)，從而在DataSource中創(chuàng)建一個(gè)DrmManagerClient實(shí)例。如此，MediaExtractor就將DataSource與DrmManagerService聯(lián)系起來(lái)。
• DrmInitialization函數(shù)非常重要，其主要工作包括：

（1）調(diào)用openDecryptSession，該函數(shù)內(nèi)部會(huì)根據(jù)文件中的DRM信息來(lái)初始化正確的DRM Plugin（Widevine、OMV，還是其他DRM類型）。

（2）創(chuàng)建DecryptSession，并將DRM信息封裝在DecryptHandler實(shí)例中傳給FileSource。

• DrmInitialization之后，SniffDRM會(huì)通過(guò)DecryptHandler來(lái)判斷該文件是否有DRM控制，并分析出該DRM是ES Based，還是Container Based。如果屬于ES Based DRM，MediaExtractor會(huì)創(chuàng)建一個(gè)DRMExtrator，而在DRMExtrator中，會(huì)創(chuàng)建一個(gè)MPEG4Extractor。

MediaExtrator創(chuàng)建完后，播放器即可開(kāi)始播放。ES Based DRM播放相關(guān)流程如圖5所示：

圖5  ES Based的DRM媒體文件播放流程

圖5所示的流程圖可分為三個(gè)階段：

• 第一個(gè)階段是資源初始化過(guò)程。該過(guò)程中，媒體播放器將通過(guò)getTrack以后獲取一個(gè)媒體文件中代表媒體數(shù)據(jù)的DRMSource實(shí)例，DRMSource只負(fù)責(zé)DRM的控制和解密，而實(shí)際媒體數(shù)據(jù)的分析仍交給MPEG4Extractor來(lái)完成。對(duì)于播放器來(lái)說(shuō)，它只和DRMExtrator和DRMSource交互。另外，在這一階段中，initializeDecryptUnit函數(shù)將初始化解密相關(guān)的資源。
• 第二階段就是媒體數(shù)據(jù)讀取，針對(duì)每一個(gè)數(shù)據(jù)基元，DRMExtrator都會(huì)先通過(guò)MPEG4Extractor取得未解密的原始數(shù)據(jù)，然后通過(guò)decrypt函數(shù)來(lái)請(qǐng)求DRM Plugin進(jìn)行解密。解密后的數(shù)據(jù)會(huì)被放到另外一處緩存中供Codec使用。如果解密失敗，decrypt將會(huì)返回錯(cuò)誤，故播放器將無(wú)法解析這些數(shù)據(jù)。
• 媒體播放完畢后將釋放播放資源。和DRM相關(guān)的資源將由finalizeDecryptUnit來(lái)釋放。

回顧上述流程，對(duì)ES Based DRM的特點(diǎn)是，不論用戶是否有權(quán)限，播放器都能讀取到媒體數(shù)據(jù)。

下面來(lái)看看Container Based DRM的播放流程。

2.3  Container Based DRM播放流程

和ES Based DRM截然不同的是Container Based DRM。受控于這種DRM管理的媒體文件在被讀取時(shí)就會(huì)進(jìn)行DRM的權(quán)限驗(yàn)證，如果驗(yàn)證失敗，則無(wú)法從中讀取到數(shù)據(jù)。故Container Based DRM最關(guān)鍵的是其pread接口，相關(guān)流程如圖6所示：

圖6  ContainerBasedDRM播放流程圖

如圖6可知：

• 首先要進(jìn)行的工作仍是判別數(shù)據(jù)格式和DRM類型并創(chuàng)建DrmManagerClient。這一過(guò)程和ES Based DRM流程相同，此處不擬贅述。
• 接下來(lái)需創(chuàng)建MediaExtractor實(shí)例。與ES Based DRM不同的是，Container Based DRM在播放時(shí)無(wú)需創(chuàng)建DRMExtractor，而是直接創(chuàng)建MPEG4Extractor，并在該MediaExtractor中設(shè)定DRM的標(biāo)識(shí)。
• Container Based DRM關(guān)鍵在于pread函數(shù)。當(dāng)MediaExtractor從FileSource中提取數(shù)據(jù)時(shí)，readAt最終通過(guò)DrmManagerClient的pread函數(shù)來(lái)訪問(wèn)DrmManager以從中讀取數(shù)據(jù)。DrmManager將調(diào)用具體的DRMPlugin實(shí)現(xiàn)的pread。數(shù)據(jù)的權(quán)限檢查和解密的工作都在該DRMPlugin完成。如果DRM解密失敗，pread將不會(huì)得到數(shù)據(jù)。

上文介紹了Android平臺(tái)中DRM播放的大體流程。下面來(lái)看看Google主推的Widevine DRM。

三  Widevine DRM介紹

2010年12月，Google不惜重金將視頻數(shù)字版權(quán)管理軟件公司W(wǎng)idevine招安。現(xiàn)在看來(lái)，Google的這一招為Android陣營(yíng)增添了一員上將，有Widevine坐陣中軍，Android就有實(shí)力在數(shù)字內(nèi)容這片戰(zhàn)場(chǎng)上與已故喬幫主的蘋果一較高下。

在收購(gòu)Widevine之前，Android沒(méi)有系統(tǒng)的數(shù)字版權(quán)保護(hù)機(jī)制，而蘋果則在iTunes、iPod時(shí)代就建立了完善的版權(quán)體系，這讓很多內(nèi)容提供商更愿意在iOS上發(fā)布自己的數(shù)字內(nèi)容，從而使得iOS的生態(tài)系統(tǒng)更加豐富和成熟。Widevine的引入彌補(bǔ)了Android在這方面的短板，它是幫助Android成為當(dāng)今移動(dòng)OS霸主的功臣之一。

Android從3.0開(kāi)始就支持Widevine，這距離Google收購(gòu)Widevine僅僅過(guò)去了三個(gè)月，可見(jiàn)Google對(duì)于數(shù)字版權(quán)保護(hù)的迫切性。現(xiàn)在Widevine已經(jīng)成為GMS（Google Mobile Service）中必備的內(nèi)容，所有想要得到GMS的手機(jī)廠商，都需要根據(jù)GMS的要求搭載Widevine。

作為Google帳下的愛(ài)將，Google為支持Widevine也煞費(fèi)苦心。目前Android平臺(tái)中播放Widevine DRM媒體有兩種方法：

• 第一種方法和前文介紹的一樣。Widevine DRM按照ES Based的流程進(jìn)行播放。但和一般DRM不同的是，Widevine使用的Extractor是WVMExtractor，而不是DRMExtractor。
• 第二種方法是MediaCodec模式，相關(guān)結(jié)構(gòu)如圖7所示。

圖7  Widevine Crypto Plugin

由圖7可知：

• MediaCodec、MediaCrypto以Java API的形式直接暴露給應(yīng)用層。這樣，應(yīng)用層能夠控制解碼、解密的過(guò)程。
• Crypto Plugin是實(shí)際完成解密的模塊，其結(jié)構(gòu)和前文提到的DRM Plugin有所不同。

需要特別指出的是，Android目前對(duì)MediaCodec模式支持還不是很完善。根據(jù)筆者的試驗(yàn)，一些市面上流行的高端Android 4.1手機(jī)還不支持這種播放方式。

另外，Widevine的代碼結(jié)構(gòu)大體可分為三部分：

• 第一部分是Android中的基本框架，包括WVMExtractor等。這部分代碼在AOSP中都可以看到，屬于Open Source的內(nèi)容。這部分代碼大多沒(méi)有實(shí)質(zhì)性內(nèi)容，相關(guān)功能的實(shí)現(xiàn)封裝在第二部分的專利代碼包中。
• 第二部分是Widevine的專利代碼包。這部分代碼需要得到Google授權(quán)后才能得到。該包提供了很多Widevine專用庫(kù)用于完成Widevine DRM權(quán)限檢查和解密。同時(shí)，它還提供了一些Sample App用于測(cè)試。
• 第三部分是手機(jī)廠商自身的安全認(rèn)證。Widevine是一個(gè)很強(qiáng)的版權(quán)控制體系，它甚至可在硬件層與廠商的安全機(jī)制綁定。很多知名的手機(jī)廠商都在boot等底層中加入自己的安全機(jī)制，只有通過(guò)可信賴的boot loader進(jìn)行刷機(jī)才能得到具有正常權(quán)限的手機(jī)軟件，并可以使用Widevine。這也是為什么很多破解的手機(jī)無(wú)法使用Widevine的原因。

由于專利代碼包和廠商安全機(jī)制都涉及到版權(quán)問(wèn)題，故本文就不擬對(duì)Widevine做進(jìn)一步討論了。如果廠商希望在自己的產(chǎn)品上也搭載Widevine，那么首先需要與Google聯(lián)系。Google會(huì)提供Widevine的專業(yè)培訓(xùn)。

四  總結(jié)

本文主要講述了Android中DRM的運(yùn)行機(jī)制。事實(shí)上，DRM是一個(gè)不易觸及的領(lǐng)域。由于其安全性高，保密性強(qiáng)，世界上真正掌握DRM核心技術(shù)的公司并不多。根據(jù)筆者的調(diào)查，DRM產(chǎn)業(yè)鏈中的相關(guān)者大概可分為如下三類：

• 第一類是制定DRM標(biāo)準(zhǔn)的公司或機(jī)構(gòu)，他們掌握DRM的核心技術(shù)，對(duì)外推廣自己的DRM標(biāo)準(zhǔn)，為需要搭載DRM的公司提供支持。
• 第二類是數(shù)字內(nèi)容提供商，他們是最迫切應(yīng)用DRM來(lái)保護(hù)自己數(shù)字版權(quán)的人，他們會(huì)向提供標(biāo)準(zhǔn)的公司夠買DRM技術(shù)，在服務(wù)器端加密，并制定數(shù)字內(nèi)容的買賣租賃機(jī)制以及相應(yīng)的密鑰配發(fā)原則。
• 第三類是終端設(shè)備制造商，為了讓自己的設(shè)備具有更廣泛的應(yīng)用性，他們需要搭載主流的DRM以適應(yīng)市場(chǎng)需求，在搭載過(guò)程中，他們也需要標(biāo)準(zhǔn)公司的支持，拿到一些有專利的代碼包，有時(shí)還會(huì)與內(nèi)容提供商合作。當(dāng)然，還有的時(shí)候，一家公司會(huì)擔(dān)當(dāng)其中的兩個(gè)或全部角色，比如亞馬遜，他即是內(nèi)容提供商，提供電子書籍等內(nèi)容，又是終端設(shè)備商，出品Kindle Fire這樣的終端設(shè)備，這樣做可以讓他把內(nèi)容和終端更好地整合在一起。

然而，國(guó)內(nèi)DRM并不非常受歡迎。筆者對(duì)于國(guó)內(nèi)的版權(quán)保護(hù)并無(wú)批評(píng)之意。只是由于國(guó)內(nèi)數(shù)字內(nèi)容發(fā)展的過(guò)程比較特殊，最終形成了當(dāng)下這種以免費(fèi)內(nèi)容占主流的市場(chǎng)氛圍和消費(fèi)習(xí)慣。對(duì)于國(guó)內(nèi)市場(chǎng)，任何一種強(qiáng)行主推DRM的收費(fèi)模式的方法目前看起來(lái)還不合適。相信很多互聯(lián)網(wǎng)巨頭已經(jīng)在其長(zhǎng)期的摸索中體會(huì)了這一點(diǎn)。

當(dāng)然這并不是說(shuō)DRM在國(guó)內(nèi)沒(méi)有市場(chǎng)。目前很多公司在免費(fèi)業(yè)務(wù)之上都加入了基于更高質(zhì)量的收費(fèi)業(yè)務(wù)，從而豐富了盈利的方式。更為重要的是，現(xiàn)在很多中國(guó)公司都在向國(guó)外擴(kuò)張，而中國(guó)公司走到外面，就必須入鄉(xiāng)隨俗，遵從國(guó)外的游戲規(guī)則。這時(shí)，數(shù)字版權(quán)保護(hù)以及建立在其之上的DRM技術(shù)就成了一個(gè)必須要重視的問(wèn)題。在此，筆者真心希望有一天國(guó)內(nèi)能有更多優(yōu)秀的公司走出國(guó)門，在中國(guó)模式和世界模式間找到平衡點(diǎn)，將我們自己的數(shù)字內(nèi)容和終端產(chǎn)品推向世界。