SPEKE API v2-对 DASH-IF 规范的自定义和限制 - 安全包装程序和编码器密钥交换 API 规范

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

SPEKE API v2-对 DASH-IF 规范的自定义和限制

DASH 行业论坛 CPIX 2.3 规范支持多种用例和拓扑。SPEKE API v2.0 规范定义了 CPIX 配置文件和 CPIX 的 API。为了实现这两个目标，它遵守 CPIX 规范，但有以下自定义和限制：

CPIX 简介

  • SPEKE 遵循加密器使用者工作流程。

  • 对于加密的内容密钥，SPEKE 适用以下限制：

    • SPEKE 不支持请求或响应有效负载的数字签名验证 (XMLDSIG)。

    • SPEKE 需要 2048 个基于 RSA 的证书。

  • SPEKE 仅利用 CPIX 功能的子集：

    • SPEKE 省略了该UpdateHistoryItemList功能。如果列表存在于响应中，SPEKE 会将其忽略。

    • SPEKE 省略了根/叶键功能。如果响应中存在该ContentKey@dependsOnKey属性，SPEKE 会将其忽略。

    • SPEKE 省略了BitrateFilter元素和VideoFilter@wcg属性。如果这些元素或属性存在于 CPIX 有效负载中，SPEKE 会将其忽略。

  • 在与 SPEKE v2 交换的 CPIX 文档中，只能使用标准有效载荷组件页面或加密合同页面上以 “支持” 形式引用的元素或属性。

  • 当加密器包含在 CPIX 请求中时，所有元素和属性都应在密钥提供商 CPIX 响应中具有有效值。否则，加密器将停止并抛出错误。

  • SPEKE 支持使用KeyPeriodFilter元素进行密钥轮换。SPEKE 仅使用ContentKeyPeriod@index来跟踪关键时段。

  • 对于 HLS 信令，必须使用多个DRMSystem.HLSSignalingData元素：一个的DRMSystem.HLSSignalingData@playlist属性值为 “媒体”，另一个元素的DRMSystem.HLSSignalingData@playlist属性值为 “master”。

  • 当请求密钥时，加密程序可能会在 ContentKey 元素上使用可选的 @explicitIV 属性。密钥提供程序可以使用 @explicitIV 来响应 IV，即使该属性未包含在请求中。

  • 加密程序创建密钥标识符 (KID)，这对于任何给定的内容 ID 和密钥周期保持不变。密钥提供程序在其对请求文档的响应中包含 KID。

  • 加密器应包含该CPIX@contentId属性的值。当收到此属性的空值时，密钥提供者应返回错误并附有 “缺少 CPIX @contentId” 的描述。 CPIX@contentId值不能被密钥提供者覆盖。

    CPIX@id如果值不为 null，则密钥提供者应忽略该值。

  • 加密器应包含该CPIX@version属性的值。当收到此属性的空值时，密钥提供者应返回错误并附有 “缺少 CPIX @version” 的描述。当收到不支持版本的请求时，密钥提供者返回的错误描述应为 “不支持的 CPIX @version”。

    CPIX@version值不能被密钥提供者覆盖。

  • 加密器应包括每个请求密钥的ContentKey@commonEncryptionScheme属性值。当收到此属性的空值时，密钥提供者应返回一个错误，描述为 “缺少 ContentKey @ focommonEncryptionScheme r KIDid”。

    唯一的 CPIX 文档不能混合不同ContentKey@commonEncryptionScheme属性的多个值。收到此类组合时，密钥提供者应返回错误消息，描述为 “不合规 ContentKey @commonEncryptionScheme 组合”。

    并非所有ContentKey@commonEncryptionScheme值都与所有 DRM 技术兼容。收到此类组合时，密钥提供者应返回错误描述 “ContentKey@ 与 DRMSystemcommonEncryptionScheme 不兼容id”。

    ContentKey@commonEncryptionScheme值不能被密钥提供者覆盖。

  • 当在 CPIX 响应正文中接收DRMSystem.ContentProtectionData innerXML<pssh> 元素的不同值时，加密器应停止并抛出错误。DRMSystem@PSSH

CPIX 的 API

  • 密钥提供者应包含X-Speke-User-Agent HTTP 响应标头的值。

  • 兼容 Speke 的加密器充当客户端，将 POST 操作发送到密钥提供者端点。

  • 加密器应包含X-Speke-Version HTTP 请求标头的值，请求中使用的 SPEKE 版本的格式为 MajorVersion。 MinorVersion，比如 SPEKE v2.0 的 “2.0”。如果密钥提供者不支持加密器用于当前请求的 SPEKE 版本，则密钥提供者应返回错误并附有 “不支持的 SPEKE 版本” 的描述，并且不会尽最大努力处理 CPIX 文档。

    密钥提供者无法在响应请求时修改加密器定义的X-Speke-Version标头值。

  • 当在响应正文中收到错误时，加密器应抛出错误，并且不会使用 SPEKE v1.0 版本重试请求。

    如果密钥提供者没有返回错误但未能返回包含强制性信息的 CPIX 文档，则加密器应停止并抛出错误。

下表汇总了密钥提供者必须在消息正文中返回的标准消息。错误情况下的 HTTP 响应码应为 4XX 或 5XX，而不是 200。422 错误代码可用于所有与 SPEKE/CPIX 相关的错误。

错误案例 错误消息

CPIX @contentId 未定义

缺少CPIX @contentId

CPIX @version 未定义

缺少CPIX @version

不支持 CPIX @version

不支持的 CPIX @version

ContentKey@commonEncryptionScheme 未定义

KIDcommonEncryptionScheme 缺少 ContentKey @id（其中id等于 ContentKey @kid 值）

在单个 CPIX 文档中使用多个 ContentKey @commonEncryptionScheme 值

不兼容 ContentKey @commonEncryptionScheme 组合

ContentKey@commonEncryptionScheme 与 DRM 技术不兼容

ContentKey@ 与 DRMSystemcommonEncryptionScheme 不兼容id（其中id等于 drmSystem @systemId 值）

X-Speke-Version 标头值不支持的 SPEKE 版本

不支持的 SPEKE 版本

加密合约格式不正确

格式不正的加密合约

加密合约与 DRM 安全级别限制相矛盾

不支持请求的 CPIX 加密合约

加密合约不包含任何 VideoFilter 或 AudioFilter 元素

缺少 CPIX 加密合约