PlayReady 內容加密模式

本主題提供 PlayReady 系統中內容加密模式的概觀。 如需 PlayReady 和內容加密的概觀，請參閱 PlayReady 內容加密。 如需加密相關詞彙，請參閱 詞彙表。

PlayReady 1.0 版引進了 AES-128 CTR 內容加密模式，除了先前用於 WMDRM （Windows Media Digital Rights Management） 的Microsoft特定 COCKTAIL 加密模式之外。 AES-128 CTR 內容加密模式使用 AES 金鑰，在計數器模式中的內容檔案上使用的長度為 128 位。

從 4.0 版開始，PlayReady 系統同時支援計數器模式 （CTR） 和加密區塊鏈結模式 （CBC） 中的 AES 128 位密鑰。

這項變更可確保使用 PlayReady 的服務可以充分利用所有裝置上唯一的數據流和檔格式。 此外，Microsoft支援 CMAF（通用媒體應用格式）標準，如 ISO/IEC FDIS 23000-19 中所定義。

一般加密模式

ISO 標準 ISO/IEC 23001-7 定義四種常見加密模式。

PlayReady 用戶端從 4.0 版開始支援 AES CBC 金鑰，除了一般加密模式 'cenc' 的 AES CTR 密鑰之外，還允許支援通用加密模式 'cbcs'。 在 4.0 版之前，AES CTR 是 PlayReady 用戶端主要支援的模式，可支援通用加密模式 'cenc'。 請注意，一般加密模式 'cens' 和 'cbc1' 在 PlayReady 生態系統中是允許且技術上可行的，但不受支援。

支援 「cbcs」AES-CBC 加密配置

所有建置在 PlayReady PK 4.0 版或之後的用戶端都可能支援 CBC 密鑰。 不過，用戶端支援是選擇性的，並透過授權取得通訊協定中的其他屬性向授權伺服器發出訊號。

在 PlayReady 標頭中發出 ALGID 的訊號

PlayReady 標頭是 XML 檔，通常包含在內容檔或數據流的標頭中。 它描述用戶端解密此內容所需的 PlayReady 屬性。 PlayReady 標頭有自己的規格和版本設定。 如需詳細資訊，請參閱 PlayReady 標頭規格。

以下是 PlayReady Header v4.2 的範例。

<WRMHEADER
          version="4.2.0.0"
          xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID ALGID="AESCTR" CHECKSUM="xNvWVxoWk04=" VALUE="0IbHou/5s0yzM80yOkKEpQ=="></KID>
        <KID ALGID="AESCTR" CHECKSUM="GnKaQIRacPU=" VALUE="/qgG2xbs4k2SKCxx6bhWqw=="></KID>
       </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
    <DECRYPTORSETUP>ONDEMAND</DECRYPTORSETUP>
  </DATA>
</WRMHEADER>

ALGID （演算法識別碼） 是 KID 元素的屬性，並指定用來加密內容的加密演算法。 從 PlayReady 標頭 4.2 版開始，ALGID 是必要的，而且必須設定為 “AESCTR” 或 “COCKTAIL”。 不過，從 4.3 版開始，ALGID 也可以設定為值 “AESCBC”。 下列範例顯示 PlayReady Header 4.3 版，並將 ALGID 值設定為 “AESCBC”。

<WRMHEADER
          version="4.3.0.0"
          xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID VALUE="PV1LM/VEVk+kEOB8qqcWDg==" ALGID="AESCBC"/>
        <KID VALUE="tuhDoKUN7EyxDPtMRNmhyA==" ALGID="AESCBC"/>
      </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
    <DECRYPTORSETUP>ONDEMAND</DECRYPTORSETUP>
  </DATA>
</WRMHEADER>

下圖顯示內容流程，其中授權要求是以 PlayReady 標頭為基礎，並指定 ALGID。

遺漏 ALGID

從 PlayReady 標頭 4.3 版開始，ALGID 可能會遺失。 下列範例顯示遺漏 ALGID 值的 PlayReady Header 4.3 版。

<WRMHEADER
          version="4.3.0.0"
          xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID VALUE="PV1LM/VEVk+kEOB8qqcWDg=="/>
      </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
    <DECRYPTORSETUP>ONDEMAND</DECRYPTORSETUP>
  </DATA>
</WRMHEADER>

下圖顯示內容流程，其中授權要求使用CDMi模組，而ALGID遺失。

為何遺漏 ALGID 值

Microsoft建議加密程式一律在 PlayReady 標頭中包含與處理內容時所包含的相同 ALGID 值。

在標準案例中，加密程式會加密內容，並在內容中產生 PlayReady 標頭。 加密程式知道用於加密的 AES 模式;因此，它會在 PlayReady Header 的 ALGID 屬性中包含這項資訊。 用戶端會根據從實際內容剖析的 PlayReady 標頭起始授權要求，因此 ALGID 值存在且有效。

在某些情況下，用戶端會根據簡單的 KID 值來起始授權要求（128 位 GUID）。 在此情況下，插入授權要求之 PlayReady 標頭中的 ALGID 值將會遺失（也稱為未指定）。 其中一個範例是用戶端使用 HTML5 EME API 提出授權要求時。

用戶端如何處理遺漏的 ALGID

如果客户端基於接收到的 PlayReady 標頭發起授權請求，則授權請求中的 ALGID 值會反映標頭中的值，因為授權取得挑戰包含了 PlayReady 標頭的一份副本。 在此案例中：

• 對於所有 PlayReady Headers v4.2 或更低版本，ALGID 值是必要的，而且必須有效。
• 對於 PlayReady Headers v4.3 或更高版本，ALGID 值可以存在且有效或遺失。

伺服器 SDK 如何處理 ALGID 缺失的情況

透過授權回應傳遞的所有授權都必須包含有效的 ALGID 值。

如果傳入授權要求中未指定 ALGID，授權伺服器必須從服務的後端取得這項資訊，並將正確的值放在授權回應中。

初始化向量 （IV）

在 PlayReady 3.3 版和更早版本中，CTR 模式僅支援 64 位 IV（8 位元組的 IV）。 從 PlayReady 4.0 版開始，CTR 和 CBC 模式都支援 64 位和 128 位 IV（8 位元組和 16 位元組的 IV）。

範例：

• 現在支援符合HLS標準的數據流，這些數據流經常在CBC模式中使用128位初始化向量（IV）。
• 現在已經支持符合 HbbTV 標準的流，這些流在 CTR 模式中使用 128 位 IV。

局限性

• PlayReady 標頭必須針對所有 KID 元素只使用一個 ALGID 值。 換句話說，用來加密資產不同軌道和品質的所有密鑰都必須是 AES CTR 或 AES CBC。 如果 ALGID 在任何 KID 元素上遺失，則必須從所有 KID 元素中遺漏它。
• 在 PlayReady 4.4 版之前，當傳入的用戶端憑證為 Windows 且 SL2000 擲回例外狀況時，會產生具有 CBC 密鑰的授權。 這是因為 Windows 用戶端僅支援 SL3000 單位上的 CBC。 不過，如果此用戶端是 PlayReady 4.0 版的最低版本，並宣告支援 CBC 模式，則有可能將具有 CBC 金鑰的授權傳遞給 SL2000 用戶端。
• 當傳入的用戶端憑證屬於使用 4.0 之前版本 Porting Kit 的裝置時，若生成具 CBC 金鑰的授權，將會拋出錯誤。
• 當收到的授權請求未顯示支援 AES CBC 時，使用 CBC 金鑰生成授權將會拋出例外錯誤。