OMA DRM V1.0學習筆記

OMA中關於DRM的定義主要是為了給內容供應商提供一種控制媒體對象使用的方式，包括對DRM Message的預覽、保護檔案、防止非法拷貝、超級傳送（一種合法的拷貝方式）。

 

 

 

 

在DRM的範疇內，為了保證媒體對象的合法使用，一旦對象被下載，就被DRM Agent（通常是運行在移動終端上，實現DRM控制）接管了。

DRM系統允許內容供應商給不同的媒體對象添加不同的著作權對象，同一媒體對象也允許添加不同的著作權對象，由此，內容供應商就可以根據不同的著作權對象來定價，客戶們根據定價進行消費，於是，一套合理的電子消費系統就產生了。內容供應商會提供使用者預覽DRM Message的著作權對象，一些精彩的預覽畫面往往會吸引更多的消費者。

應該這麼來理解，著作權對象和媒體對象都可以看作實體，受保護的媒體對象可以較容易獲得，但是著作權對象則需要單獨購買。有了著作權對象才能播放受保護的媒體對象。

關於著作權對象和媒體對象的獲得主要是以下三種方式：

 

前兩種方式是：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

轉寄鎖定：
在轉寄鎖定方式中，移動終端是禁止轉寄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）媒體類型。

OMA DRM 1.0中關於對流媒體的支援規定得很簡單，幾乎等於沒說，所以也就不介紹了。

在轉寄鎖定方式中，伺服器端返回的DRM Message

HTTP/1.1 200 OK
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...

原文:http://blog.csdn.net/jiyucn/archive/2007/06/29/1671656.aspx