本模擬的重點在MPEG-21 IPMP 與 REL 的整合，系統架構參考 MPEG-4 IPMPX，
並且設計符合 MPEG-21 IPMP 與 REL 功能之 IPMP Tool，最後整合至擁有 MPEG-4
6
IPMPX 子系統之 MPEG-21 Test Bed 平台上[10] 。
IPMP Tool Design
MPEG-21 IPMP 主要的目的為保護 Digital Item 及處理 IPMP DIDL element。另一方 面，Test Bed 提供影像和聲音兩種 Digital Item。加密為其中一種有效保護資料的方式。
因此，我們專注在具有加密功能的IPMP Tool 以展現 MPEG-21 IPMP 的功能。Test Bed 採用MPEG-4 Initial Object Descriptor (IOD)來傳輸與 IPMPX 相關的資料。所以，我們也 將IPMP DIDL element 放到相對應的 Tool Descriptor 內，並且等到初始階段時，再取出 並處理IPMP DIDL element。
MPEG-21 REL 相關之功能是產生認證的證明。根據認證的要求，相關的引擎會產 生驗證故事以及驗證內容，再決定使否允許要求的事項。任何包含 REL 功能的應用都 能夠控制特定的內容唯有在滿足指定條件之前提下才能被使用。
為 了 在 Test Bed 上 實 現 所 描 述 的 功 能 ， 我 們 設 計 一 個 IPMP 工 具 ( 稱 為 IPMP_Info_Engine)。從 IPMPX 子系統的觀點而言，這個 IPMP_Info_Engine 工具擔任控 制其他IPMP 工具的中控角色。它不但是 IPMP 訊息的管理工具，還是能處理認證工作 的 REL 工具。在整個系統中，IPMP_Info_Engine 工具並不直接處理任何影音資料，因 此不會連結至任何的控制點。換句話說，其控制點為CONTROL_POINT_NO (0x00)
Communication between IPMP Tools
當使用者想要播放一個影音檔案時，必須先取得相關的播放權利。在本研究提到 的議題中，驗證使用者的動作如同對解密工具進行驗證。換句話說，當一個IPMP 工具 開始處理資料時，必須先聯繫 REL 工具以取得驗證的證明。解密工具(DES Tool)與 IPMP_Info_Engine 工具的互動描繪在圖 6：
1. DES Tool 產生要求驗證結果之訊息。
2. 訊息迴路器傳送訊息至 IPMP_Info_Engine 工具。
3. IPMP_Info_Engine 工具辨別此要求，並產生對應的驗證結果。
DES Tool
IPMP_Info_Engine Tool
1. Send an message for request the right to decrypt
.
2. Perform REL verification 3. Send an
message with the result of verification
DES Tool
IPMP_Info_Engine Tool
1. Send an message for request the right to decrypt
.
2. Perform REL verification 3. Send an
message with the result of verification
圖 6 與 IPMP_Info_Engine Tool 之間的互動
7
4. IPMP_Info_Engine 工具產生包含驗證結果的訊息。
5. 訊息迴路器傳送證明結果至 DES Tool。
根據驗證結果，DES Tool 將決定是否繼續處理資料。
Content Protection Schema
為了保護透過廣播串流的內容，本研究提出整合上述 MPEG-21 的工具。權利管理 可經由辨別 license 來達成。圖 7 上展現整個保護的架構，包含雙層的加密資料。資料 內容由第一層的保護機制傳輸，此處採用對稱性的 DES block Cipher 加密演算法。此 處延伸出兩個議題：第一個是客戶端如何安全的接收解密金鑰以正確的還原資料、第 二個是這樣簡單的 block cipher 加密演算法相較於更為複雜的演算法是比較不安全的。
將解密金鑰透過一個被信任的安全通道即可解決第一個議題。第二個議題則要看整體 系統設計的考量，到底要增加複雜度以獲得較高的安全性，或是降低複雜度但用較低 的安全性。因此，這是複雜度與安全性的權衡。一個比較簡單的方式為利用週期性更 新的金鑰，則可以在不增加系統的複雜度的前提下也可以擁有較的傳輸安全性。結合 以上兩個解決方案，將傳輸模式演化為一個擁有兩層保護機制的系統設計。
第二層保護為值得信賴且安全的金鑰傳輸通道，較第一層安全的原因是第二層傳 輸使用非對稱性加密演算法(RSA)保護第一層金鑰。在這裡我們架設金鑰伺服器以傳輸 金鑰至客戶端，這個服務可以整合至伺服器端(Server side)或單獨成立一個遠端的服 務。同時，在伺服器端的金鑰資料庫與金鑰伺服器存放的金鑰是完全相同的。客戶端 與金鑰伺服器的互動流程如下：
1. 客戶端傳送包含身份資料的請求解密金鑰之訊息。
2. 金鑰伺服器搜尋資料庫以驗證使用者之身分與其他必須的條件。
3. 當請求為有效的，解密金鑰會被加密透過使用客戶的公開金鑰。
4. 金鑰伺服器把受保護的解密金鑰回傳至客戶端。
5. 客戶端則利用本身的私密金鑰取出正確的解密金鑰，再解碼以接收的資料。
使用上述的機制，可以確保受保護的資料內容只能被擁有正確身份的使用者播放。
Key*
(Server) DES Tool
(Client) DES Tool
Key Key Key
Server
Encrypt with Client’s Public Key Store without
any encryption
Decrypt with Client’s Private Key
Encrypted content Layer 1
Layer 2
圖 7 Content protection scheme
8
Implementation of IPMP_Info_Engine
我們使用由Content Guard[11] 提供的 REL 參考軟體實現 IPMP_Infor_Engine 工具。
參考圖 8，利用 GUI 介面產生驗證的要求，再透過內部的 API 進行驗證。在本研究 中，為了快速確認系統架構的可行性，接收端收到REL License 會存放至本地的儲存裝
置。一旦 IPMP_Info_Engine 被存取，將讀取 XML 形式的 Query(來自 request message 或已儲存的檔案)與 REL License 以產生驗證要求。其餘的步驟則與前面描述的驗證流 程相同。
Experiments
為了展示本研究中所設計的系統之特點與功能，這裡提供了三個實驗範例：(1) Online playback (2) Playback with free preview (3) Super distribution – online and offline playback
Online Playback
此範例展現如何在即時串流系統上驗證播放(play)的權利。當存取設定完成，客戶 端從伺服器端接受License。在這個基本型式的 REL License 中，主體是客戶端的身分，
權 利 為 播 放 ， 資 源 則 是 此 影 像 檔 案 。 比 較 複 雜 的 地 方 是 條 件 ， 我 們 選 取”exerciseMechanism”條件(內含相關服務的參數)，讓客戶端連線到授權的遠端服務進 行驗證。
圖 8 REL 參考軟體的資料流程
9
一 旦 播 放 開 始 ，DES Tool 就要求 IPMP_Info_Engine 執行驗證證明的工作。
IPMP_Info_Engine 根據 License 的內容來聯繫遠端伺服器並且傳送含有使用者身份資料 的要求。在此系統中，此遠端伺服器不儘是驗證伺服器也是金鑰管理伺服器。如果使 用者有資格播放該影像內容，遠端伺服器將會回傳受保護的解密金鑰。反之，回傳空 白的解密金鑰。因為記載於License 中的主體、權利、資源都與 REL request 相符，此驗 證內容的可行性取決於條件是否吻合。如圖 9 所示，如果接收到錯誤的條件(空白金鑰) - 驗證證明為假，則 DES Tool 將拒絕繼續處理資料；反之，DES Tool 能夠運用回傳的
圖 9 範例(一)之執行過程
圖 10 範例(二)之執行過程
10
解密金鑰處理資料。
Preview
在典型的線上影音消費議題上，消費者常被允許可以預先觀賞部分的片段(如：影 片的前30 秒)以決定是否要購買。此範例展現運用 MPEG-21 REL 與其他 DRM 相關概 念完成控制”Preview”的行為。
透過使用 DES Tool 內的計數器，我們允許使用者可以預視數秒短片不需任何的 license。計數器的內容代表剩餘可播放的 macro-block 數目，直到內容變為 0，才進行驗 證證明。如圖 10 的上半部所示，IPMP_Info_Engine 將跳出對話視窗，要求使用者輸入 正 確 的 license 與 query file 。 當 使 用 者 於 對 話 視 窗 中 輸 入 對 應 資 料 後 ， IPMP_Info_Engine 執行驗證程序。只要輸入無效的 License 或 query file，將會讓播放的 程序中斷，在圖 10 的下半部展示播放過程停止的情況。
Super-Distribution
此範例展現一個在可攜式行動環境下的”Super Distribution”議題該如何進行線上與 離線驗證。” Super Distribution”描述內容和使用權利的物件可以分開傳送的狀況，在現 行的行動裝置上是非常實用的一個議題。內容的傳遞是以加密的方式儲存，權利物件 則是指定給特定的用戶。在第一個範例中，使用者只能在網路連線存在的情況下播放 影像，在離線的狀況下，完全無法播放。但對於一個行動裝置而言，不可能永遠都處 於可連上網路的環境。因此，我們想要設計一種能提供線上與離線驗證的License。
一個簡單的 License 範例顯示在圖 11，包含兩個驗證內容(Grant)。其中 Grant-1 適 用 連 線 存 在 的 狀 況 ，Grant-2 則 適 用 於 離 線 狀 況 。 這 兩 個 驗 證 內 容 都 含 有 一 個”allConditions”來包含一個以上以邏輯運算子”AND”連結在一起的條件元件，表示必 須同時發生，此”allConditions”的條件才成立。在 Grant-1 中，”exerciseMechanism”指明
一 個 遠 端 的 伺 服 器 ， 而”validicityInterval” 指 明 有 效 的 時 間 範 圍 。 在 Grant-2 中，”exerciseMechanism”指明一個本地的驗證機制，”validicityInterval”指明有效的時間 範圍，而”exerciseLimit”指明有效的離線播放次數。全部的驗證流程表現圖 12 上。
License License
<John>
<play>
<foreman.m4v>
<allConditions>
<exerciseMechanism>
<validicityInterval>
</allConditions>
Grant 1 (online)
<John>
<play>
<foreman.m4v>
<allConditions>
<exerciseMechanism>
<validicityInterval>
<exerciseLimit>
<sx:count>3</sx:count>
</exerciseLimit>
</allConditions>
Grant 2 (offline)
圖 11 為範例(三)所設計的 license 架構
11
因為驗證的流程，Grant-1 的驗證順序永遠優先於 Grant-2。而且，在本範例的設計 上，線上驗證的優先權必定為最高。換句話說，只要線上驗證的結果是假，則必定無 法繼續播放。這個驗證的程序由不同的”validator”完成。第一個 validator 檢查網路連 線，如果連線不存在，validator 回傳錯誤的條件。如果遠端伺服器回傳空的解密金鑰 (代表驗證失敗)，之前得到的解密金鑰將被刪除。相反地，舊的解密金鑰將被取代。當
需要驗證Grant-2 時，第二個 validator 先確認解碼金鑰是否存在。如果不存在，則不允 許播放；如果存在，檢驗播放次數。當播放次數達到所允許的數字後，驗證結果為錯 誤且刪除存在的解密金鑰。兩個執行狀況的螢幕擷取圖如圖 13 所示，上面的部分是在 本地驗證成功且合法播放的狀況，下面的部分則為超過可播放次數，並顯示警告訊息 於視窗內。