外链论坛

 找回密码
 立即注册
搜索
查看: 16|回复: 0

构建DRM系统的重要基石——EME、CDM、AES、CENC和密钥

[复制链接]

3050

主题

119

回帖

9915万

积分

论坛元老

Rank: 8Rank: 8

积分
99159052
发表于 2024-10-3 07:18:59 | 显示全部楼层 |阅读模式

▼扫描下图二维码或点击阅读原文

认识音视频技术大会更加多信息

翻译、编辑: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种副本。这对存储空间是多么大的浪费!

认识决视频流媒介协议所带来的第1个问题,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与DASHHLS名单一块被发送到视频播放器。播放器解析名单,找到密钥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是解密数据的第1个接触点,它在阻止数据泄密方面发挥了重要作用。

当播放视频时,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/





上一篇:Intel“谎言”终被戳穿?100/200系主板或完美支持八代酷睿
下一篇:ME软件下载 2024最新软件Encoder下载 破解版软件附带安装教程
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

站点统计|Archiver|手机版|小黑屋|外链论坛 ( 非经营性网站 )|网站地图

GMT+8, 2024-11-24 23:26 , Processed in 0.420399 second(s), 22 queries .

Powered by Discuz! X3.4

Copyright © 2001-2023, Tencent Cloud.