背景
内容所有者和多频道视频节目分销商(MVPD)之间的传输协议可能包含要求MVPD提供充分保护以防止内容盗窃的条款。在传统的基于qam的有线电视网络传输模式中，由于运营商控制着生态系统的所有部分，因此所需的保护级别相对容易实现和管理。机头、网络和客户端机顶盒与现成或自制的条件访问系统(CAS)紧密集成，提供了所需的保护。

在互联网视频时代，客户端播放设备通常由消费者拥有，并使用各种操作系统和硬件配置。一开始，像Adobe和微软这样的公司开发了本地应用程序来支持解密和渲染优质视频内容。这些原生应用后来被转换为网络浏览器扩展，从而支持嵌入html的加密内容。随着自适应比特率(ABR)流媒体模式(如苹果的HTTP Live streaming、微软的Smooth streaming和MPEG-DASH)的出现，这些“黑盒子”媒体播放器让许多内容发行商想要更多地控制播放体验。对此，万维网联盟W3C开发了媒体源扩展API，允许JavaScript应用程序向浏览器提供单独的音频、视频和数据媒体样本。有了这个强大的新工具，web应用程序可以决定何时以及如何在各种比特率之间切换。虽然这解决了将自适应比特率控制置于应用程序手中的问题，但它没有提供播放加密内容的安全方法。

2012年，W3C开始致力于标准化加密媒体扩展(电磁辐射)。这些新的JavaScript api允许web应用程序在嵌入在web浏览器中的数字版权管理(DRM)系统(内容解密模块或CDM)和位于网络某处的密钥源或许可服务器之间方便地交换解密密钥。亚博yabo888vip网页版CableLabs在W3C工作组中发挥了积极的作用，以确保电缆行业的需求在EME规范的开发中得到满足。EME api在其三年的历史中经历了几次重大的转变，但我们现在看到了架构的一些稳定性，浏览器供应商开始产生一些完整而健壮的实现。

高速的工作流程

JavaScript web应用程序利用EME api的过程是这样的:

1. (可选)浏览器媒体引擎通知应用程序，它遇到了加密的媒体样本，它没有适当的解密密钥。
2. 应用程序请求访问浏览器中可用的DRM系统，该系统支持与内容相关的特定操作和技术需求。
3. 应用程序将选择的DRM系统分配给一个HTMLMediaElement．
4. App创建一个或多个重要会议与选定的DRM系统相关联，每个系统将管理一个或多个解密密钥(许可证)。
   1. 应用程序指示密钥会话生成许可请求消息，为其提供初始化数据．浏览器可以通过步骤1中的事件提供该数据，也可以由应用程序通过其他方式获取(即在ABR清单文件中)。
   2. 选定DRM系统的CDM将生成一个数据blob(许可请求)并将其交付给应用程序。
   3. 应用程序将许可证请求发送到许可证服务器。
   4. 在收到对其许可请求的响应后，应用程序将响应消息传递回CDM。CDM将响应中包含的任何解密密钥添加到密钥会话。
5. CDM和/或浏览器媒体引擎将使用存储在密钥会话中的密钥来解密遇到的媒体样本。

初始化数据

用于在支持eme的web浏览器中播放的受保护内容必须与指示特定DRM实现如何获取解密所需许可的数据一起提供。这可能包括密钥id、许可服务器url和分配给内容的数字版权等信息。在大多数情况下，初始化数据包的内容不会被应用程序解析。但是，有必要指定在各种媒体容器中携带初始化数据的方法，以便允许浏览器媒体引擎从流中提取数据以交付给应用程序。W3C维护一个当前定义的流和初始化数据格式的注册表．

系统关键属性

EME过程的第一步是找到一个满足内容和应用需求的关键系统。下一节将描述应用程序可使用的标准，这些标准允许它从浏览器中通过Navigator.requestMediaKeySystemAccess() API实现的一组多个drm中进行选择。

数字版权管理系统

EME的设计是基于一个浏览器可以支持一个或多个DRM系统的理解。此外，使用ISO CommonEncryption，单个内容可以使用多个DRM系统进行保护。在EME中，每个DRM都与一个识别密钥系统字符串相关联(例如“com. microsoft.com”)。playready "， " org.w3.clearkey ")和一个通用唯一标识符(UUID)。虽然关键系统字符串在特定的浏览器实现中是唯一的，但UUID在所有浏览器实现中应该是唯一的。的DASH产业论坛创建了一个uuid注册表在DRM供应商之间保持这种独特性。应用程序必须选择内容和浏览器都支持的DRM系统。

内容类型

评估内容类型支持跨越了CDM和浏览器中的媒体引擎之间的界限。内容的容器类型当然必须得到浏览器的支持，因为它需要解析容器来了解内容(即它是加密的吗?轨道是怎样的?等等)。音频和视频编解码器信息也很重要，需要浏览器和/或CDM的支持。在某些DRM健壮性模型中，解密的媒体样本可能不允许在CDM或图形驱动程序的受保护内存之外。在这种情况下，CDM将负责协调媒体的解码和显示。

关键会话持久性

在创建密钥会话时，应用程序能够指示与该会话关联的许可证将跨应用程序的多个负载持久保存。为了确保可以创建这些类型的会话，应用程序可以只请求访问支持持久性的cdm。

独特的标识符

反对在开源软件世界中包含“黑盒”CDM的一个主要论点是，CDM可能会使用用户或设备的唯一或近乎唯一的属性“跟踪”个人:个人或一小群人为了解决这个与隐私相关的问题，EME规范的一部分专门用于定义这些独特的标识符而且指明清洁发展机制可能在何时何地使用它们．当请求访问特定的密钥系统时，应用程序可以选择只从浏览器中不使用独特标识符的cdm中进行选择。显式依赖于使用独特标识符的cdm可能无法被应用程序选择(因此，可能会阻止某些内容的播放)，如果应用程序将其指示为禁区。

MediaKeySession

密钥会话提供了启动许可证检索过程和在接收到密钥时存储密钥的方法。应用程序通过向CDM提供初始化数据(MediaKeySession.generateRequest ())．CDM解析数据并以自己的安全、专有格式生成许可请求，并通知应用程序(MediaKeyMessageEvent)．在收到许可请求后，应用程序将其转发到它知道可以处理该请求的许可服务器。在生产环境中，许可证请求可能会与其他特定于业务的数据打包，例如用户身份验证和/或授权请求。当成功时，DRM服务器将响应一条许可消息，应用程序将把该消息转发给CDM (MediaKeySession.update ())．

在媒体播放的正常过程中，CDM可能需要向DRM服务器发出未经请求的请求(例如，验证给定的许可证是否仍然有效)。应用程序只是继续充当代理，将消息发送到许可服务器并使用响应更新CDM。

关键会话持久性

如前所述，关键会话可以建立为“持久的”。在这种情况下，CDM将与会话关联的所有密钥(和其他数据)存储到设备上的私有存储中。存储的会话与创建它们的web应用程序惟一关联。每个键会话都被分配了一个唯一的标识符，应用程序可以在以后使用该标识符来收回会话数据。MediaKeySession提供了几个api来允许应用程序管理关键会话的持久性。

• MediaKeySession.close ()-关闭密钥会话并使其密钥对解密媒体不可用，但不影响会话的任何持久存储。
• MediaKeySession.load ()-获取一个sessionID，并将与该ID相关的数据加载到一个空MediaKeySession对象中。与该会话一起持久化的密钥再次可用来解密内容。
• MediaKeySession.remove ()—关闭密钥会话并从CDM中删除该密钥会话的任何持久存储。关联的会话ID现在不再有效。

MediaKeys

一旦应用程序找到了满足其需求和内容需求的关键系统，就可以进行创建MediaKeys．MediaKeys是一个或多个关键会话的容器。MediaKeys方法方便将解密密钥与HTMLMediaElement用于查看加密的内容。即使已经从许可服务器获取了密钥并存储在CDM中，在这些密钥与媒体元素关联之前，媒体也不会被解密。

ClearKey

EME规范中还包括测试DRM系统ClearKey的详细信息。ClearKey就像它的名字所暗示的那样:在这个系统中，解密密钥在通往CDM的旅程中的某个时刻是“透明的”。浏览器对ClearKey的支持是由EME规范强制要求的。当“真正的”DRM系统的内容或CDM不可用时，它的预期用途主要是作为在浏览器中评估EME实现的一种手段。ClearKey的格式许可证要求而且响应消息在规范中有详细说明。应用程序获得给定内容块的ClearKey键的机制由开发人员决定。

格雷格Rutz他是CableLabs的首席架构师，从事多个与亚博yabo888vip网页版数字视频编码/转码和在线视频数字版权管理相关的项目。

这篇文章是技术博客系列的一部分。基于标准的现代Web优质内容"．