▼掃描下圖二維碼或點選閱讀原文▼
了解音視訊技術大會更多資訊
翻譯、編輯：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/