TShopping

 找回密碼
 註冊
搜索
查看: 4570|回復: 0

[教學] DRM in Android

  [複製鏈接]
發表於 2013-12-11 00:28:48 | 顯示全部樓層 |閱讀模式
 
Push to Facebook Push to Plurk Push to Twitter 
DRM,英文全稱為Digital Rights Management,譯為數字版權管理。它是目前業界使用非常廣泛的一種數字內容版權保護技術。隨著知識產權保護受重視的程度日益提高,快速攻城略地得Android智能手機是如何利用DRM來有效保護數字版權的呢?本文將通過剖析Android中的DRM框架以及相關工作流程來向讀者揭示DRM的神秘面紗。
  DRM架構介紹嚴格來講,DRM不是一項技術,而是一類技術。很多機構和聯盟都提出過相應的DRM標準[1]。例如Open Mobile Alliance推出的OMA DRM、Marlin Developer Community提出的Marlin DRM,而Google則通過收購Widevine公司推出了Widevine DRM。
從Android智能終端來看,Google的原生Android(Android Open Source Project,簡稱AOSP)系統僅僅集成了OMA DRM V1的一部分功能,它遠未構成一個完整的DRM解決方案。在這種情況下,設備廠商只能根據情況選擇合適的DRM解決方案並集成到Android平台中來。例如,手機廠商可以通過Google的授權以獲取Widevine DRM對應的軟件包從而將Widevine DRM集成到自己的產品中。
為了方便設備廠商的集成,Android設計了一個通用的DRM軟件框架,不同的DRM解決方案可通過Plugin的方式集成到Android系統中。圖1所示為Android中的DRM軟件架構。
圖1  Android中DRM軟件架構
由圖1可知:
  • DRM Framework API模塊是Framework層暴露給App的接口。該模塊中最主要的類是DrmManagerClient。
  • DRM Framework API模塊通過Binder機制和位於drmserver進程(以Android 4.1為例,drmserver的代碼位於framework/av/drm/drmserver)中的DRM Manager模塊通信。DRM Manager加載並管理系統中所有的DRM插件。
  • DRM Plugins是真正實現權限管理、數字內容解密等工作的模塊。根據DRM標準的不同,這些Plugins的實現亦不相同。另外,一個手機可能會集成多個DRM Plugin。這是因為媒體文件如果採用不同的DRM解決方案進行加密的話,手機在播放它們時,DRM Manager需找到對應的DRM Plugin以進行解密。
圖2所示為DRM架構中幾個重要的類及其關係。
圖2  Android中DRM架構中重要類圖
由圖2可知:
  • 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機構提供專利代碼包。
下面來看看Android中DRM的工作流程。
  DRM工作流程介紹2.1  DrmManagerService的初始化DRM的工作流程和多媒體播放密切相關。首先來瞭解一下DrmManagerService的創建過程,相關流程如圖3所示:
圖3  DrmManagerService啟動流程
由圖3可知:
  • DrmManagerService實例對像由drmserver進程在main函數中調用instantiate創建。
  • DrmManagerService內部會創建一個DrmManager實例對象並調用loadPlugins來加載設備可能提供的DRM Plugin。DRM Plugin通過動態庫的方式集成到設置中去。Android 4.1中有兩個目錄可存放DRM Plugin。一個是/vendor/lib/drm/,例如Widevine對應的libdrmwvmplugin.so一般放在這個目錄中。另一個目錄是/system/lib/drm/。每一個DRM Plugin對應為一個IDrmManager實例。所有被加載的DRM Plugin由DrmManager來統一管理。
  • DrmManagerService最後將通過addService把自己註冊到Binder系統中以為廣大客戶端服務。
下面來介紹DRM的工作流程。Android支持的DRM播放方式分為兩種:
  • 一種是基於基本碼流的(Elementary Stream Based,簡稱ES Based)播放方式。目前Widevine DRM、Marline DRM都屬於這一種類型。
  • 另一種是基於容器的(Container Base)播放方式,目前OMA DRM支持這種方法。
這兩種不同的方式在播放流程上不盡相同。下文將以一個播放具有DRM保護的MP4文件為例,介紹DRM的工作流程。首先來看ES BasedDRM媒體播放工作流程
2.2  ES BasedDRM播放流程ES Based DRM意味著每一個數據基元在播放時都需要解密。這種DRM的媒體文件或流可以使用普通方式正常讀取,但讀取出來的數據是經過加密的。如果不能對數據正確解密,那麼該數據將無法正常播放。
在播放媒體文件之前,播放器首先要識別該文件是否被DRM保護。如果受DRM保護的話,還行初始化對應的DRM插件。這部分工作所涉及的流程如圖4所示:
圖4  ES BasedDRM插件初始化
由圖4可知:
  • 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創建完後,播放器即可開始播放。ES Based DRM播放相關流程如圖5所示:
圖5  ES Based的DRM媒體文件播放流程
圖5所示的流程圖可分為三個階段:
  • 第一個階段是資源初始化過程。該過程中,媒體播放器將通過getTrack以後獲取一個媒體文件中代表媒體數據的DRMSource實例,DRMSource只負責DRM的控制和解密,而實際媒體數據的分析仍交給MPEG4Extractor來完成。對於播放器來說,它只和DRMExtrator和DRMSource交互。另外,在這一階段中,initializeDecryptUnit函數將初始化解密相關的資源。
  • 第二階段就是媒體數據讀取,針對每一個數據基元,DRMExtrator都會先通過MPEG4Extractor取得未解密的原始數據,然後通過decrypt函數來請求DRM Plugin進行解密。解密後的數據會被放到另外一處緩存中供Codec使用。如果解密失敗,decrypt將會返回錯誤,故播放器將無法解析這些數據。
  • 媒體播放完畢後將釋放播放資源。和DRM相關的資源將由finalizeDecryptUnit來釋放。
回顧上述流程,對ES Based DRM的特點是,不論用戶是否有權限,播放器都能讀取到媒體數據。
下面來看看Container Based DRM的播放流程。
2.3  Container Based DRM播放流程和ES Based DRM截然不同的是Container Based DRM。受控於這種DRM管理的媒體文件在被讀取時就會進行DRM的權限驗證,如果驗證失敗,則無法從中讀取到數據。故Container Based DRM最關鍵的是其pread接口,相關流程如圖6所示:
圖6  ContainerBasedDRM播放流程圖
如圖6可知:
  • 首先要進行的工作仍是判別數據格式和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將不會得到數據。
上文介紹了Android平台中DRM播放的大體流程。下面來看看Google主推的Widevine DRM。
  Widevine DRM介紹2010年12月,Google不惜重金將視頻數字版權管理軟件公司Widevine招安。現在看來,Google的這一招為Android陣營增添了一員上將,有Widevine坐陣中軍,Android就有實力在數字內容這片戰場上與已故喬幫主的蘋果一較高下。
在收購Widevine之前,Android沒有系統的數字版權保護機制,而蘋果則在iTunes、iPod時代就建立了完善的版權體系,這讓很多內容提供商更願意在iOS上發佈自己的數字內容,從而使得iOS的生態系統更加豐富和成熟。Widevine的引入彌補了Android在這方面的短板,它是幫助Android成為當今移動OS霸主的功臣之一。
Android從3.0開始就支持Widevine,這距離Google收購Widevine僅僅過去了三個月,可見Google對於數字版權保護的迫切性。現在Widevine已經成為GMS(Google Mobile Service)中必備的內容,所有想要得到GMS的手機廠商,都需要根據GMS的要求搭載Widevine。
作為Google帳下的愛將,Google為支持Widevine也煞費苦心。目前Android平台中播放Widevine DRM媒體有兩種方法:
  • 第一種方法和前文介紹的一樣。Widevine DRM按照ES Based的流程進行播放。但和一般DRM不同的是,Widevine使用的Extractor是WVMExtractor,而不是DRMExtractor。
  • 第二種方法是MediaCodec模式,相關結構如圖7所示。
圖7  Widevine Crypto Plugin
由圖7可知:
  • 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的專業培訓。
  總結本文主要講述了Android中DRM的運行機制。事實上,DRM是一個不易觸及的領域。由於其安全性高,保密性強,世界上真正掌握DRM核心技術的公司並不多。根據筆者的調查,DRM產業鏈中的相關者大概可分為如下三類:
  • 第一類是制定DRM標準的公司或機構,他們掌握DRM的核心技術,對外推廣自己的DRM標準,為需要搭載DRM的公司提供支持。
  • 第二類是數字內容提供商,他們是最迫切應用DRM來保護自己數字版權的人,他們會向提供標準的公司夠買DRM技術,在服務器端加密,並制定數字內容的買賣租賃機制以及相應的密鑰配發原則。
  • 第三類是終端設備製造商,為了讓自己的設備具有更廣泛的應用性,他們需要搭載主流的DRM以適應市場需求,在搭載過程中,他們也需要標準公司的支持,拿到一些有專利的代碼包,有時還會與內容提供商合作。當然,還有的時候,一家公司會擔當其中的兩個或全部角色,比如亞馬遜,他即是內容提供商,提供電子書籍等內容,又是終端設備商,出品Kindle Fire這樣的終端設備,這樣做可以讓他把內容和終端更好地整合在一起。
然而,國內DRM並不非常受歡迎。筆者對於國內的版權保護並無批評之意。只是由於國內數字內容發展的過程比較特殊,最終形成了當下這種以免費內容占主流的市場氛圍和消費習慣。對於國內市場,任何一種強行主推DRM的收費模式的方法目前看起來還不合適。相信很多互聯網巨頭已經在其長期的摸索中體會了這一點。
當然這並不是說DRM在國內沒有市場。目前很多公司在免費業務之上都加入了基於更高質量的收費業務,從而豐富了盈利的方式。更為重要的是,現在很多中國公司都在向國外擴張,而中國公司走到外面,就必須入鄉隨俗,遵從國外的遊戲規則。這時,數字版權保護以及建立在其之上的DRM技術就成了一個必須要重視的問題。在此,筆者真心希望有一天國內能有更多優秀的公司走出國門,在中國模式和世界模式間找到平衡點,將我們自己的數字內容和終端產品推向世界。


 

臉書網友討論
您需要登錄後才可以回帖 登錄 | 註冊 |

本版積分規則



Archiver|手機版|小黑屋|免責聲明|TShopping

GMT+8, 2016-12-9 17:46 , Processed in 0.056547 second(s), 22 queries .

本論壇言論純屬發表者個人意見,與 TShopping綜合論壇 立場無關 如有意見侵犯了您的權益 請寫信聯絡我們。

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回復 返回頂部 返回列表