▼掃描下圖二維碼了解音視頻技術大會更多信息▼

翻譯、編輯：Alex

技術審校：劉姍、周亞橋

本文來自OTTVerse，作者為Krishna Rao Vijayanagar。

Easy-Tech#016#——DRM

任何想要理解DRM（Digital Rights Management，數字版權管理）的人都要遇到AES、CDM、CENC、EME等縮略詞。對于初學者來說，這些詞很容易混淆，但只有理解了它們，才能真正地理解DRM。我們將在本文中簡單介紹DRM的基本構成：EME、CDM、AES、CENC以及密鑰和密鑰服務器的使用。

DRM系統的簡化架構

在上一期文章中，我們已經知道DRM使用加密技術和商業規則控制數字內容訪問和消費。

簡單來說，DRM系統可以：

• 為內容供應商加密內容提供工具和基礎設施。

• 圍繞加密內容構建生態，從而使內容供應商能夠控制由誰來解密并消費內容。

在上一期文章中，我們看到Ram和Shyam將加密后的信息傳遞給對方。同時，Hari拿著密碼本，由他決定誰可以讀/寫信息，還記得嗎？

現在，讓我們采用這個簡單的系統，并把組件替換成保護和分發視頻內容的技術。看看我們得到了什么？

從上圖中可以看出，我們想要向認證用戶安全地發送一部電影。需要：

• 向DRM廠商的服務器請求密碼本

• 然后使用密碼本加密視頻

• 將電影視頻發送給用戶

• 用戶向DRM廠商的服務器請求密碼本解密視頻

• 現在用戶就可以觀看電影了

真棒！

這些就是關于DRM的所有知識嗎？

不！我們上文只是舉了一個簡單易懂的例子，說明如何使用DRM安全地傳送電影。這個例子很好地描述了DRM的本質，但在現實中無法正常運行。

接下來，我們將一步一步地重新思考、設計這個簡單的系統，看看它是如何通過DRM傳輸視頻的。一起來吧！

第1步：回到ABR技術

討論順序前，讓我們先來修改示例以適應視頻傳送中的ABR模型。

復習ABR： 通過使用ABR技術，電影可以被編碼成不同的碼率-分辨率組合（也稱為碼率階梯）并被分割成小的視頻塊或者切片。每個視頻切片包含幾秒鐘視頻，可以被單獨解碼。

打包是指將電影分割成小的視頻切片，并使用清單（manifest）或者播放列表對其進行描述。當用戶想要播放電影的時候，他需要按照播放列表的信息播放。

根據可用帶寬，播放器請求特定碼率版本的視頻切片，CDN響應后返回被請求切片。

MPEG DASH和HLS是使用ABR進行視頻傳輸的常用手段。想要深入理解這些技術，請閱讀：什么是HLS（HTTP Live Streaming）? 和Easy Tech：什么是MPEG-DASH協議。

讓我們修改圖片來表示ABR視頻傳送。

打包和基于CDN的視頻傳輸是其中唯一更改的步驟。

好了，現在讓我們進入加密環節。

第2步：視頻加密

視頻加密是指當有人截獲我們的數據時，確保他們無法讀取數據信息或者觀看視頻內容。

復習加密： 加密是一種用于保護數據機密并防止未經授權的人讀取數據的技術。加密技術使用密鑰將輸入數據（明文）轉化為一種替代形式——密文。沒有密鑰的情況下，幾乎不可能將密文轉換為明文。

然而實際上，沒有密鑰也有可能解密，但是通過逆向工程破解加密算法消耗巨大（包括時間、金錢以及所需計算資源）。

AES（Advanced Encryption Standard）是最流行的加密技術之一。AES也被稱為Rijndael（由發明者的名字命名），2001年由美國國家標準技術研究所（NIST）推出標準，用于加密電子數據。

AES的技術要點包括：

• 對稱密鑰加密算法：使用同一把密鑰進行加密和解密。

• 基于密鑰長度，有三種變體：128bit、192bit和256 bit。密鑰長度越長，越難破解。

• 如果沒有密鑰的話，破解AES-128需要10億x10億年，外加一臺超級計算機。

鑒于本人并不是密碼學專家，如果你想深入了解AES標準，可以查看AES的維基頁面。

注意： 在視頻領域，加密不是編碼，解密也不同于解碼。對于視頻而言，編碼和解碼常常分別指壓縮和解壓縮。想要對編、解碼和視頻編解碼器有更多了解，請閱讀我們的文章：視頻編碼完全指南。

加密技術只有AES-128嗎？

不，還有其他類型的加密技術，讓我們用1分鐘思考一下這句話的含義。

如果內容供應商決定和三家不同的DRM公司合作，并且它們都使用不同的加密技術，這意味著內容提供商需要加密視頻三次，而這么做無疑是對存儲空間和其他資源的浪費。

這就是CENC加密格式產生的原因——降低加密市場的碎片化趨勢以及減少存儲需求。

下文中我們會講到。

通用加密CENC

在我們深入了解CENC之前，讓我們先來看下OTT流媒體協議，尤其是CMAF。

MPEG-DASH和HLS是目前最常用的兩個協議。其他協議還有MSS（Microsoft Smooth Streaming）等，但我們今天暫不討論。

在視頻傳輸中，MPEG-DASH通常使用mp4容器格式，HLS通常使用MPEG-TS (ts)格式。如果某個內容供應商同時使用MPEG-DASH和HLS，那么它需要存儲一份mp4和ts文件格式的副本。

現在，我們加上DRM加密問題。假設三個DRM廠商使用三種不同的加密標準，那么內容提供商就需要為每個視頻存儲2x3=6種副本。這對存儲空間是多么大的浪費！

為了解決視頻流媒體協議所帶來的第一個問題，CMAF標準應運而生，該標準規定可以以分段mp4容器格式（fmp4） 存儲視頻。在MPEG-DASH 和HLS的支持下，你現在只用創建一組視頻，以fmp4格式存儲，兩種協議使用同一組文件即可。

只要確保你創建了兩個視頻清單（嘆氣）。

統一加密如何？

如果不同DRM技術使用不同標準，我們仍然需要為每份文件存儲不同的副本，對吧？

為此，MPEG開發了CENC（Common Encryption specification），規定視頻既可以使用cenc（AES-128 CTR），也可以使用cbcs（AES-128 CBC）加密。CTR代表計數器模式；CBC代表密文分組鏈接模式。CENC意味著內容提供商僅需加密視頻一次，并且任何解密模塊都可以解密它。

注意： 只要密鑰絕對安全，即使加密算法暴露也不會出問題。

CENC也許聽起來像是統一DRM的簡單方法，但事實并非如此。

目前市場中有三種主要的DRM技術：Apple FairPlay、Google Widevine和Microsoft PlayReady:

• Apple FairPlay僅支持AES-CBC cbcs模式。

• HLS僅支持AES-CBC cbcs模式（與CMAF無關）。

• Widevine和PlayReady支持AES-128 CTR cenc和AES-128 CBC cbcs 模式。

• 使用CMAF的MPEG-DASH支持AES-128 CTR cenc 和AES-128 CBC cbcs 模式。

• 不使用CMAF的MPEG-DASH僅支持AES-128 CTR cenc模式。

如你所見，CMAF和CENC標準引發了流媒體領域的混亂局面和碎片化。

CMAF和AES-CBC cbcs模式的普遍使用可能能夠結束混亂的現象，但是它們將如何影響僅支持CTR或者僅支持MPEG-TS的傳統設備？

我們下次再討論。

第3步：密鑰、密鑰ID和許可證服務器

到目前為止，我們已經確定將使用 AES-128bit對視頻進行加密。在這個階段，出現的幾個問題是：

• 我們在哪里獲得AES-128bit的加密密鑰？

• 如何將加密密鑰和電影聯系起來？

• 在哪里存儲加密密鑰？

讓我們來一一回答。

從哪里獲得AES-128bit的加密密鑰？

任何內容供應商都可以使用專業軟件手動生成加密密鑰。或者，由幾個DRM廠商提供生成密鑰的必需工具和軟件。

如何將加密密鑰和電影聯系在一起？

讓我們先來理解這么做的原因。當你去住酒店的時候，你要向酒店前臺報房間號，才能申領房間鑰匙，對吧？你做的正是通過告知房間號來為鑰匙和房間建立聯系。

類似地，當你用一把密鑰加密某部電影時，我們就需要建立這種聯系，并將它提供給DRM許可證服務器（也就是酒店前臺）。

在DRM中，密鑰ID提供了加密密鑰與電影之間的聯系，它是一串獨特的字符串，在為特定電影創建加密密鑰時生成。

最后，在哪里存儲加密密鑰和它的密鑰ID？

加密密鑰和密鑰ID存儲在和DRM許可證服務器一起工作的KMS（密鑰庫）中。

當客戶端需要播放加密電影時，它通過提供此電影的密鑰ID向DRM許可證服務器請求解密密鑰。如果DRM許可證服務器對請求（認證請求）認可，它將要求密鑰庫提供與該密鑰ID對應的解密密鑰。

審校者注：一般向DRM許可證服務器申請的不是“解密密鑰”，而是“許可證”， 許可證服務器會根據密鑰ID申請解密密鑰，然后生成許可證下發給客戶端。

加贈一問： 密鑰ID是如何傳送到播放器的？

基本原理：沒有密鑰ID，許可證服務器無法查看電影的解密密鑰。

答案： 密鑰ID與DASH或者HLS清單一起被發送到視頻播放器。播放器解析清單，找到密鑰ID，然后向DRM許可證服務器請求密鑰ID對應的解密密鑰。

現在，我們來總結一下圍繞加密密鑰、密鑰ID和許可證服務器的討論。

• 加密密鑰具有保密性，需要和對應密鑰ID存儲在一個安全的密鑰庫。

• 密鑰ID可以“公開”。

• 任何擁有密鑰ID的人都能向許可證服務器請求私密密鑰（解密密鑰）。由DRM廠商對請求者進行身份驗證，然后再提供（或拒絕提供）解密密鑰。

下面這張圖描繪了我們剛剛所學的密鑰、加密和許可證服務器知識。

第4步：在播放器和密鑰服務器上解密視頻

在客戶端（播放器應用），用戶按下播放鍵，開始播放他想觀看的電影。現在視頻播放器需要一種方法來識別電影是否被加密。否則，播放器將試圖播放加密電影，繼而崩潰，最終導致糟糕的用戶體驗。

可以通過以下方式發出電影已加密的信號：

• 可以在清單中添加注釋，說明該電影已加密，且提供密鑰ID。

• 另外一種方法：在視頻碼流中插入一些包含獨特信息的字節。當播放器在播放前檢查視頻碼流時，它就會采集到該獨特信息，并確定這部電影已加密。

播放器中接下來幾個步驟更為直觀：

• 播放器發現密鑰ID并向許可證服務器請求解密密鑰。

• 許可證服務器通過預定義的機制來識別播放器請求是否經過驗證。

• 如果許可證服務器通過了播放器的驗證，它將返回帶有解密密鑰信息的許可證。

我們剛剛描繪了一個簡單的方案，但無論在技術上還是商業上，都存在很多問題。讓我們來看看最開始出現的一些問題：

1、我們已經描述了一個原型“播放器”，它向 DRM許可證服務器發送解密密鑰請求。但是：

• 許可證服務器如何知道播放器是否可信賴？

• 如果播放器中的解密軟件泄露出密鑰和解密內容該怎么辦？

2、如果你是一個視頻播放器開發者，你必須為每個DRM技術開發解密模塊嗎？當它們更改界面時，你也必須每次都要跟著更新嗎？

此外，播放器（客戶端）中的事件序列如下所示：

• 從CDN獲取電影及其清單

• 在清單中提取出密鑰ID

• 生成許可證請求

• 將請求發送給許可證服務器

• 靜待許可證服務器的響應

• 使用來自服務器的解密許可證解密內容

• 解碼解密內容

• 顯示解碼后的電影

一個單一程序或者公司無法完成上面所有步驟。

它將形成一個緊密耦合的架構，并無法實現任何具有開放性、即插即用的生態系統。讓我們看看可以做些什么。

播放端架構

在播放器層面，前文描述的職責被劃分為不同的模塊，如下所示：

• 播放器負責獲取電影，解析清單，提取密鑰ID，向DRM許可證服務器發送請求等。

• 一個單獨的模塊（稱為 CDM 或內容解密模塊）負責創建許可證請求、解密和解碼內容。

現在，讓我們來看下CDM。

內容解密模塊CDM

每個DRM廠商都會提供：

• 自己的機制創建許可證請求（通過密鑰ID、設備標識符、簽署請求等）。

• 自己的機制來理解從DRM許可證服務器接收到的許可響應（該響應也被加密）并提取解密密鑰。

• 在客戶端本地存儲許可證，許可證更新以及過期等規則。

通過上文這些細節，CDM模塊便能夠嵌入如Chrome、Firefox、Microsoft Edge和Safari這樣的瀏覽器中。

DRM廠商測試和驗證這些CDM來確保：

• 許可證請求格式正確且符合規范。

• 它們不會泄露解密密鑰。

• 它們不會泄露解密和解碼電影。

• 它們能夠根據許可證規范安全地存儲解密密鑰（比如存儲密鑰時長）。

• 安全地將視頻傳輸到屏幕，不會泄露。

由于以上原因，瀏覽器中的CDM都是閉源的，這也是行業和外界爭議的根源。因為外界無法看到CDM中的源代碼，所以人們無法信任它。

注意： 少數幾個瀏覽器提供關閉CDM的選項，但是如果你這樣做了，將無法觀看受到DRM保護的內容。這就是行業的權衡。

下面是一張Firefox插件頁面中Widevine插件的一張截圖（來自我的Ubuntu 20.04計算機）。

等等，另外一個技術細節我們還沒有討論。

加密媒體擴展EME

我們在前文已經知道，播放器應用需要與瀏覽器中的CDM“對話”，并與許可證服務器交換許可證信息，對吧？

為什么說這既是一個技術問題，也是一個商業問題？

• 播放器廠商需要集成所有不同的許可證服務器和CDM，并跟蹤其界面的更改以保持最新狀態。

• 一家播放器公司說他們不會支持一些廣受歡迎的平臺，因為這些平臺頻繁更換界面，就會導致最后極有可能沒有人來購買播放器，那就糟糕了！

這就產生了介于播放器和CDM之間的EME（加密媒體擴展）。EME 為播放器（應用程序）提供了一套標準化的 API 來與 CDM 進行通信。

現在讓我們來了解EME和CDM是如何一起工作的：

• EME是一個JavaScript API。

• CDM是解密視頻、解碼和顯示視頻（可選）的軟件。

• 視頻播放器是一個JavaScript程序，它使用EME API在CDM和許可證服務器之間傳輸信息。

EME的優勢是： 由于EME帶來的互操作性，供應商和播放器廠商可以開發能在不同瀏覽器觀看視頻的流媒體服務。你可以開發一個使用EME標準與許可證服務器和CDM通信的App，而不用考慮使用哪個DRM平臺和瀏覽器。

視頻解碼和顯示

視頻被解密后，需要進行解碼并顯示給用戶，這個過程是不能暴露解碼、解密信息或者原始幀的。CDM是解密數據的第一個接觸點，它在阻止數據泄露方面發揮了重要作用。

當播放視頻時，CDM分別可以：

• 解密電影并將碼流傳送給應用程序（不太安全，因為有人會破解應用并轉儲視頻）。

• 解密、解碼并將解碼后的視頻幀發送到平臺顯示引擎。

• 自己解密、解碼和顯示視頻（最安全）。

這個過程在軟件和設備硬件（更安全）中也會發生。

將所有技術集成在播放器（客戶端），我們得到了下面的圖。

我們的DRM系統原型已經就位。

但是還缺少一些能夠吸引內容供應商的重要特性。

第5步：身份驗證、證書輪換和支持離線播放

在此階段，我想將頭部DRM技術供應商（比如Apple、谷歌和微軟）和圍繞這些技術提供服務的DRM廠商區分開來。在這一部分，讓我們一起來了解一下行業中對DRM技術（可能由DRM技術供應商或DRM廠商直接提供）所提出的一些商業規則。

用戶身份驗證

FairPlay、Widevine和PlayReady這樣的DRM技術供應商不提供用戶身份驗證服務。但DRM廠商可以！當用戶按下播放鍵，一個單獨的服務器來驗證用戶資格（比如用戶ID）。它根據訂閱級別、促銷優惠碼等信息檢查用戶是否有權播放該內容。在服務器驗證用戶權限后，App可以向許可證服務器發出許可證申請。

注意： 以上只是用戶身份驗證的簡化版本，專業的DRM廠商需要更復雜的驗證流程。

地域封鎖

當內容供應商想要阻止一部電影在某些地區的播放，就會使用地域封鎖。和用戶身份驗證類似，這是大多數DRM廠商的附加服務。當用戶按下播放鍵播放某部特定電影時，DRM廠商的服務器就可以檢查這部電影是否可以在用戶所在地區觀看。根據內容供應商設定的規則，許可證和加密密鑰被傳送（或者拒接傳送）給客戶端。

永久和非永久許可證

顧名思義，許可證服務器在接收永久許可證后，可以將其存儲在客戶端設備上。它可以一直用來播放電影，直到許可證過期。在許可證過期之前，CDM需要生成一個許可證更新請求。

非永久許可證用于立即播放電影。它們并不能長期存儲，一般在當前播放會話過期后（或者在會話中間，當設置了短期過期時間時）棄用。

密鑰輪換

密鑰輪換是指為了減少攻擊，使用不同密鑰加密視頻的不同部分（切片）。假如一個黑客獲得了某部電影的密鑰，在密鑰輪換的情況下，他就只能觀看這部電影的一小部分，因為其他部分使用了不同的密鑰。除此之外，通過使用多重密鑰，你可以將不同的許可規則對應視頻內容的不同部分。比如，某部電影的“幕后獨家部分”只向Premium會員開放，其他免費訂閱用戶只能觀看余下的電影內容。

離線播放

當網絡連接不可用時，某些服務會提供離線播放視頻。當我知道我將要長途飛行時，我就會在Netflix上下載幾部電影。在這種情況下，播放器無需與許可證服務器通信獲取DRM密鑰。

同時，DRM供應商需要提供一個能夠將密鑰安全存儲在設備上的選項，這樣內容才能被解鎖，并在不聯網的情況下播放。需要高度安全的CDM實現防止密鑰泄露。

視頻的優化加密

加密和解密電影有可能會非常昂貴，尤其是在UHD和4K電影中，這個時候就需要優化加密。其中一種優化方法是僅加密每個視頻切片的幀內容（關鍵幀或I幀或IDR幀）。這種方法有幾個優勢：

• 因為幀內容只占據電影中全部幀的一小部分，所以加密速度很快。

• 只有在解碼幀內容之后，它的相關幀（既依賴于I幀的幀）才能被解碼。

因此，如果沒有可解碼的幀內容，電影就會變得毫無用處。

Apple FairPlay中的SAMPLE-AES 就是一個例子，它僅加密每個媒體切片的部分內容。

安全級別和阻止播放某些分辨率視頻

內容解密可以在軟件或硬件中進行，一般情況下，硬件解密被認為更安全，因為解密操作發生在可信執行環境中（TEE，Trusted Execution Environment）。維基百科對TEE的定義是：主處理器的安全區域，能夠確保加載代碼和數據的私密性和完整性。

然而，一些設備（一般是低端設備）不能進行硬件解密和解碼。

內容供應商需要一種機制來有條件地允許/阻止在各種設備上播放視頻。一種直接的方法是生成DRM許可證，指定允許哪些設備播放電影碼率階梯中的某些分辨率。

結 語

我希望你現在已經了解 AES、EME、CDM、CENC、密鑰和密鑰服務器是如何構成 DRM 系統的。

感謝閱讀，我們下期文章見！

致謝：

本文已獲得作者Krishna Rao Vijayanagar授權翻譯和發布，特此感謝。

原文鏈接：https://ottverse.com/eme-cenc-cdm-aes-keys-drm-digital-rights-management/

總結

以上是生活随笔為你收集整理的构建DRM系统的重要基石——EME、CDM、AES、CENC和密钥的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。