首页> 中国专利> 一种用于发送和验证URL签名以进行自适应流中URL认证和基于URL的内容访问授权的系统和方法

一种用于发送和验证URL签名以进行自适应流中URL认证和基于URL的内容访问授权的系统和方法

摘要

本发明提供了一种用于发送和验证URL签名以访问自适应流中URL可寻址内容的系统和方法。提供了针对多个URL的多个URL认证描述符和URL授权描述符,其中,每个URL认证描述符包括获取验证密钥和访问认证标签以根据相关联的URL认证方案认证所述多个URL中给定URL的信息。每个URL授权描述符是为获取验证密钥和访问授权标签以根据相关联的URL认证方案授权访问所述多个URL中给定URL可寻址内容。传递针对所述多个URL的所述多个URL认证描述符和URL授权描述符,在所传递的所述多个URL认证描述符和URL授权描述符中,为每个描述符在所述多个URL中的给定URL,根据每个描述符的相关联方案验证每个描述符。

著录项

  • 公开/公告号CN105659240A

    专利类型发明专利

  • 公开/公告日2016-06-08

    原文格式PDF

  • 申请/专利权人 华为技术有限公司;

    申请/专利号CN201480058430.7

  • 发明设计人 刘永亮;王新;张少波;唐廷芳;

    申请日2014-10-28

  • 分类号G06F21/10;

  • 代理机构

  • 代理人

  • 地址 518129 广东省深圳市龙岗区坂田华为总部办公楼

  • 入库时间 2023-12-18 15:55:15

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2018-10-19

    授权

    授权

  • 2016-07-06

    实质审查的生效 IPC(主分类):G06F21/10 申请日:20141028

    实质审查的生效

  • 2016-06-08

    公开

    公开

说明书

技术领域

本发明大体针对统一资源定位符(uniformresourcelocator,URL)认证,尤其是 URL认证在自适应流中基于URL的内容访问授权的应用。

背景技术

媒体内容提供商或发布商可以采用适用于电视、笔记本电脑和手机等不同设备的 不同编码方案将各种媒体内容传送至订户或者用户。媒体内容提供商可以支持多个媒体编 码器和/或解码器(编解码器)、媒体播放器、视频帧率、空间分辨率、比特率、视频格式或其 组合。可以将媒体内容从源表示或原始表示转换为其它各种表示,以适用于不同的用户设 备。

媒体内容可包括媒体描述文件(mediapresentationdescription,MPD)和多个 分片。MPD可以是描述该媒体内容,例如媒体内容的各种表示、统一资源定位符(uniform resourcelocator,URL)地址(或者更通俗地,统一资源标识符(uniformresource identifier,URI))和其它特性等,的可扩展标记语言(ExtensibleMarkupLanguage,XML) 文件或文档。例如,媒体内容可包括若干种媒体成份(例如,音频、视频和文本),每种成份可 具有MPD中指定的不同特性。每种媒体成份包括多个包含一部分实际媒体内容的多个分片, 这些分片可共同存储在单个文件中或单独存储在多个文件中。每个分片可包含预定义的字 节大小(例如,1000字节)或该媒体内容的播放时间间隔(例如,2秒或5秒)。

取决于应用,媒体内容可划分为各种层级。例如,媒体内容可包括多个时段,其中, 时段是比分片相对较长的时间间隔。例如,电视节目可划分为若干个5分钟的节目时段,而 这些5分钟的节目时段被划分为若干个2分钟的商用时段。进一步地,时段可包括一个或多 个自适应集(adaptationset,AS)。AS可提供关于一种或多种媒体成份及其各种编码表示 的信息。例如,AS可以包含媒体内容的视频成份的不同比特率,而另一个AS可包含相同媒体 内容的音频成份的不同比特率。表示可以是媒体成份的编码替代物,通过比特率、分辨率、 信道数目、其他特性或其组合而与其他表示不同。每种表示包括多个分片,这些多个分片是 具有时间顺序的媒体内容块。此外,为了能够下载多个部分中的分片,有时可采用子分片, 每个子分片具有特定时长和/或字节大小。本领域的技术人员应理解,可采用各种层级传送 媒体内容。

在自适应流中,当媒体内容传送到用户设备时,用户设备可以基于各种因素,例 如,网络状况、设备能力和用户选择等,动态地选择合适的分片。自适应流可包括已实现的 或正在开发的各种技术或标准,例如,超文本传输协议(HypertextTransferProtocol, HTTP)动态自适应流媒体(DynamicAdaptiveStreamingoverHTTP,DASH)、HTTP直播流 (HTTPLiveStreaming,HLS)或因特网信息服务系统(HS)平滑流。例如,用户设备可尽可能 选择质量最优(例如,分辨率或比特率)的分片,以确保及时下载和播放该分片,且不会在播 放中造成暂停或重新缓冲事件。因此,用户设备可以将其媒体内容播放无缝地适应于不断 变化的网络状况。为了防止对媒体内容的篡改或攻击,需要通过认证方案来保护媒体内容 的分片。可能需要防止各种攻击(例如,来自非预期表示的分片的复制攻击),即使这些分片 的来源和调度/时间是正确的。

国际标准化组织(InternationalOrganizationforStandardization,ISO)/国 际电工技术委员会(InternationalElectrotechnicalCommission,IEC)发布了名为 《HTTP动态自适应流媒体(DynamicAdaptiveStreamingoverHTTP,DASH)-第四部分:分 片加密和认证》的文件,其编号为ISO/IEC23009-4,该文件描述了一些认证DASH分片的机 制,且该文件以引入的方式并入本文。然而,当MPD用于为待进行流传送的分片提供源URL信 息时,ISO/IEC23009-4并没有提供支持该给定MPD中分片URL认证的机制。分片URL认证在 许多情形中至关重要。

当有效URL列表由经销商编写时,一种引入错误URL映射的情形可能会出现。此时, 经销商可以是因特网服务提供商或移动运营商,且原始DASH服务提供商提供例如包括一些 广告的DASH内容,但允许经销商向终端用户传送DASH内容。如果经销商期望将原始广告替 换为另一广告,则经销商可以只修改原始广告的分片URL,并将这些分片URL映射为其期望 进行流传送的广告。因此,将URL与其代表的内容结合是可取的,从而保证了原始内容得以 传送至用户,而且可以验证该预期内容实际由预期客户端访问。

另一种情形是原始内容服务提供商想要限制对其来自MPD的内容的访问,这些MPD 不是由提供商生成,而是以未授权的方式使用(重复使用)其分片URL,为了保护版权并防止 来自恶意方的热链接。

关于URL的真实性,MPEG中已经将URL签名方案详述为对URL认证正在进行中的 DASH核心实验(coreexperiment,CE)的一部分。其核心思想在于对各单个URL进行签名,并 创建另一个指向URL签名的URL。随后,客户端请求URL签名,并检查URL的真实性。如果签名 URL未被篡改,则该方案可保证URL的真实性、完整性和来源。然而,该方案易受到三种类型 的攻击:

对单个URL及其签名URL的篡改攻击。攻击者可将真实URL及其签名URL替换为另一 个真实URL和由两种签名的创建者生成的其对应的签名URL。

对全部或部分URL的重组攻击。攻击者可改变URL的顺序,而由于每个签名验证均 通过,所以客户端无法检测到该攻击。

对一个或多个URL的删除攻击。客户端无法通过URL认证检测该攻击。

URL认证的另一个目的在于验证分片的真实性,以确保所接收的分片为客户端期 望接收的分片。然而,如果技术方案中并未将URL与分片相关联,则可能会出现分片篡改攻 击。即,即使分片进行了签名,该预期分片可能在分片服务器中或在分片传送时被替换。例 如,攻击者可将分片A及其签名替换为分片B及其签名,而客户端无法检测到该攻击。

关于内容访问授权,3GPPTSG-SA4第74次会议上发表的编号为S4-130680的《对 DASH认证使用情形的缺口分析》和2013年7月发布的编号为RFC6983的《用于HTTP自适应流 感知内容分发网络互联的模型》中提出了基于URL的签名方案:对每个客户端进行每个分片 URL签名作为授权,且在将分片传送至客户端之前,内容分发网络(contentdelivery network,CDN)进行签名检查。该方案免于遭受攻击,然而,这可能会为签名服务器造成繁重 的工作量,因为服务器需要为每个授权用户对MPD中的每个URL进行签名。

发明内容

此处公开了一种用于验证URL签名以进行自适应流中URL认证和/或基于URL的内 容访问授权的系统、装置和方法。

在一个实施例中,本发明包括一种传输签名的方法,以实现自适应流中URL认证和 基于URL的内容访问授权。

在一个实施例中,本发明包括一种传输签名的方法,以实现内容访问授权。

在一个实施例中,本发明包括一种传输签名的方法,以实现URL认证和内容访问授 权。

在一个实施例中,第一描述符处理URL认证,第二描述符处理内容访问授权。

在一个实施例中,URL认证描述符提供了单个URL级别的签名。

在一个实施例中,URL认证描述符提供了群组URL级别的签名。

在一个实施例中,内容访问授权描述符提供了单个URL级别的签名。

在一个实施例中,内容访问授权描述符提供了群组URL级别的签名。

在一个实施例中,可在MPD的最高级别对URL认证或者内容访问授权之一进行签 名。

公开了一种用于发送和验证URL签名以访问自适应流中URL可寻址内容的系统、装 置和方法。提供了针对多个URL的多个URL认证描述符和URL授权描述符,其中,每个URL认证 描述符包括获取验证密钥和访问认证标签以根据相关联的URL认证方案认证所述多个URL 中给定URL的信息。每个URL授权描述符是为获取验证密钥和访问授权标签以根据相关联的 URL认证方案授权访问所述多个URL中给定URL可寻址内容。传递针对所述多个URL的所述多 个URL认证描述符和URL授权描述符,且在所传递的所述多个URL认证描述符和URL授权描述 符中,为每个描述符在所述多个URL中的给定URL,根据每个描述符的相关联方案验证每个 描述符。

结合以下附图和权利要求的详细描述,这些以及其他特征将会被清楚的理解。尽 管主要描述的是URL,但该描述同样适用于更通用的URI,即适用于发送和验证URI签名以进 行自适应流中URI认证和基于URI的内容访问授权。

附图说明

为了更透彻地理解本发明,现参阅结合附图和具体实施方式而描述的以下简要说 明,其中的相同参考标号表示相同部分。

图1为一种流媒体方案的实施例示意图;

图2为一种生成分片及其各自签名的方案的实施例示意图;

图3为一种签名验证方案的实施例的消息交互图;

图4为一种网络节点的实施例示意图。

具体实施方式

首先应理解,尽管下文提供了一个或多个实施例的说明性实施方案,但是所公开 的系统和/或方法可采用任何数目的技术来实现,无论该技术是当前已知还是现有的。本发 明决不应限于下文所说明的说明性实施方案、附图和技术,包括本文所说明并描述的示例 性设计和实施方案,而是可在所附权利要求书的范围以及其等效物的完整范围内修改。

此处公开了一种用于验证URL签名以进行自适应流中URL认证和基于URL的内容访 问授权的系统、装置和方法。在一种公开的认证方案中,计算或生成URL认证的签名不仅需 要当前URL签名的唯一标识,还需要MPD中包含的可信信息。该认证方案结合了当前URL签名 的唯一标识和可信信息,使得该URL认证的签名不会被伪造,且可以防止各种攻击。用于生 成该URL认证的签名的信息可以是:如果存在下一URL签名,下一URL签名的标识;媒体描述 文件的标识;URL进行签名的时段的标识;URL进行签名的自适应集的标识;URL进行签名的 表示的标识;签名后的URL所指向的分片;任何其他可信信息或其组合。

在一种公开的授权方案中,计算或生成基于URL的内容访问授权的签名不仅需要 客户端的唯一标识,还需要MPD中包含的可信信息。该认证方案结合了客户端的唯一标识和 可信信息,使得该URL认证的签名不会被伪造,且可以防止各种攻击。用于生成基于URL的内 容访问授权的签名的信息可以是:媒体描述文件的标识;URL进行签名的时段的标识;URL进 行签名的自适应集的标识;URL进行签名的表示的标识;授权到期的时间;任何其他可信信 息或其组合。

由于可信信息的完整性或真实性可以通过对一部分或全部MPD进行签名以创建 MPD签名得到保证,所以可以检测到可信信息的任何篡改。相较于现有方案,所公开的认证 方案可提供更强的安全性,同时避免增加存储和通信成本。

图1示出了一种流媒体方案100的实施例,该方案可以实现从HTTP服务器120传送 媒体内容到流媒体客户端110。例如,流媒体方案100可以是DASH或者其他类型的流媒体方 案。流媒体客户端110可以是在用户设备的操作系统中实现的程序或应用,或者流媒体客户 端可以是在web平台上访问的web客户端。可以由流媒体准备单元130生成或准备HTTP服务 器120中存储的媒体内容。媒体准备单元130可以位于HTTP服务器120中或其他位置(例如, 内容提供商中)。HTTP服务器120可以是内容提供商的一部分,也可以是内容分发网络 (contentdistributionnetwork,CDN)中的节点。媒体内容可以由所述内容提供商生成, 然后发送到CDN节点。HTTP服务器120中的媒体内容可以包括MPD和多个分片。请注意,如果 需要的话,所述MPD和分片可以存储在不同的服务器中,并从不同的服务器发送到流媒体客 户端110。另外,此处所述的HTTP服务器仅仅作为服务器的一个示例。应当理解的是,此处所 公开的此类实施例也可以在任何其他合适类型的服务器中实现。

在流媒体方案100中,流媒体客户端110可以向HTTP服务器120发送媒体内容的请 求。作为响应,HTTP服务器120可以首先采用MPD传送功能140向流媒体客户端110传送MPD。 可通过HTTP、电子邮件、拇指驱动器、广播或者其他任何传输方式传送MPD。通过解析MPD,流 媒体客户端110可以获知关于媒体内容的信息,例如,程序的定时、媒体内容的可用性、媒体 类型、分辨率、最大和最小带宽、多媒体成份的各种编码替代物的存在性、可访问性特征和 所需的数字版权管理(digitalrightsmanagement,DRM)、每种媒体成份在网络中的位置, 以及媒体内容的其他特征。采用该信息,流媒体客户端110可以选择合适的编码表示或其替 代物,并通过采用HTTPGET请求来获取分片以开始流传送媒体内容。HTTP服务器120可以采 用分片传送功能向流媒体客户端110传送分片。请注意,流媒体客户端110可以从多个HTTP 服务器下载分片,例如,以最大化网络带宽的利用率。流媒体客户端110可以适当地渲染所 下载的媒体,以向流媒体客户端110的用户提供流媒体服务。尽管流媒体客户端110可以基 于MPD中包含的URL所指定的位置获得分片,但有时分片可能存储在HTTP缓存150中(例如, HTTP服务器120或CDN节点中),使得流媒体客户端110可以更高效地接收分片。

在适当缓冲以允许网络吞吐量变化后,流媒体客户端110可以继续下载后续分片, 并同时监控网络的带宽波动。取决于流媒体客户端的测量,流媒体客户端110可以适应性地 通过下载不同表示的分片将流媒体调整到可用带宽(例如,采用更低或更高比特率),以保 持足够的缓冲。

图2示出了一种生成分片及其各自签名的方案200的实施例示意图。方案200可以 由HTTP服务器(例如,HTTP服务器120)或媒体内容提供商实现。分片单元或模块210可以用 于将媒体内容202划分为多个分片。如上所述,取决于应用,可以采用各种层级来表示媒体 内容。如果采用了子分片,则与可应用于分片一样,此处所述的方案可以应用于子分片。

每种表示包括多个分片,包括初始化分片(IS)和至少一个媒体分片(MS)。例如,如 图2所示,表示n,其中,n为指示表示索引的整数,包括一个初始化分片(记为ISn)和m个媒体 分片(记为MSn1,MSn2,,……,MSnm),其中,m为指示分片索引的整数。每种表示可以包括相同 或不同数目的分片。例如,在图2中,表示1包括k个分片,而表示n包括m个分片,其中,k和n可 以相同或不同。

为了防止篡改或未经授权操控分片,可以为每个分片或子分片(如果采用了子分 片)分配分片签名(有时称为私钥)。通过分片URL,记为SegmentURL,可以检索每个分片;通 过分片签名URL,记为SegmentSignatureURL,可以检索该分片对应的签名。segmentURL和 SegmentSignatureURL均可以作为MPD的元素或属性进行存储。MPD可以直接包含URL,而不 是分片签名,以减小MPD的文件大小。

签名模块220可以用于为每个分片生成分片签名。例如,如图2所示,为分片ISn生 成签名ISn,为分片MSn1生成签名MSn1,……,为分片MSnm生成签名MSnm。考虑将分片ISn作为示 例,前提是其他分片也进行了类似地签名。在一个实施例中,计算ISn的分片签名不仅将ISn本身考虑在内,还考虑到MPD中包含的与ISn相关的信息,例如segmentURL、 SegmentSignatureURL、内容ID、时间戳或其组合。如图2所示,可以基于ISn、分片签名URL 232和CID234计算出签名ISn。还可以基于无签名MPD236和签名密钥计算出签名ISn。通过 将分片签名与MPD结合,可以保证每个分片的真实性。

媒体内容202的MPD可以包括经过编程以描述关于媒体内容的信息的元素和属性。 在XML编程中,元素可以包括三个部分:<elementname>指示的开始标签、元素内容和</ elementname>指示的结束标签。进一步地,元素可以包含一个或多个属性和/或子元素。属 性可以包括属性名称和属性值,表示为attributename=attributevalue。

对于每个分片,可以创建SegmentSignatureURL作为MPD中的属性。 SegmentSignatureURL规定了验证实体(例如,流媒体客户端110)可以从哪里获得针对给定 分片的分片签名。例如,分片签名可以位于签名存储服务器中,因此,验证实体可以在签名 存储服务器中检索到分片签名。在一个实施例中,签名模块220可以采用下述等式生成签名 对象:

SegmentSignature=Sign(Hash(segment,SegmentSignatureURL),SignatureSig nKey)(1)

其中,Hash()表示分片和该分片的SegmentSignatureURL的哈希函数; SignatureSignKey表示签名密钥;Sign()表示采用变量Hash()和SignatureSignKey的签名 算法。

通过计算哈希函数,即Hash(),为分片生成了摘要或哈希值。随后,采用Sign()函 数生成对应的分片签名。在一个实施例中,采用哈希函数计算摘要也可将分片的CID考虑在 内。此时,可以按照以下等式生成分片签名:

SegmentSignature=Sign(Hash(segment,SegmentSignatureURL,CID),Signatu reSignKey)(2)

在等式(1)或(2)中,可以通过MPD中存储的分片的SegmentURL检索该分片。请注 意,MPD可以在表示或自适应集的开头采用模板(记为SegmentURLTemplate)以规定每个 SegmentURL是如何通过模板得到的,而不是指定每个SegmentURL。例如,该模板可以指定每 个分片的时间范围和/或比特范围,因此,当DASH客户端请求特定的时间范围时,HTTP服务 器可以采用该模板确定向DASH客户端提供哪一个分片。类似地,每个SegmentSignatureURL 可以存储在MPD中,或者可以从记为SignatureURLTemplate的URL模板中得到每个 SegmentSignatureURL。签名密钥(即SignatureSignKey)可以是签名实体(例如,HTTP服务 器120或内容提供商)生成的私钥。签名密钥由签名实体进行保护,不向任何第三方或用户 透露。

可以基于签名密钥生成对应的签名验证密钥,记为SignatureVeriKey。签名验证 密钥可以公开,例如,分发给第三方和用户,并存储在签名存储服务器中。通过记为 SignatureVeriKeyURL的签名验证密钥URL可检索或寻址到SignatureVeriKey。 SignatureVeriKeyURL可以作为属性存储在MPD中,以指示验证实体可定位 SignatureVeriKey的地方。在一个实施例中,SignatureVeriKeyURL和 SegmentSignatureURLTemplate均可以作为记为SegmentSignature的元素的属性被包含。 元素SegmentSignature的语义如表1所示,其中,symbol表示属性,O表示相关属性为可选 属性。

表1

应当注意的是,媒体内容202中的多个分片可以共享公共签名验证密钥。因此,可 能没有必要为每个分片创建属性SignatureVeriKeyURL。相反,可以根据媒体内容202的层 级在更高层级创建SignatureVeriKeyURL。例如,可能自适应集、时段、表示或整个媒体内容 仅需要一个SignatureVeriKeyURL。或者,媒体内容202所需的一个或多个签名验证密钥可 以直接存储在MPD中,在此情况下,可以移除属性SignatureVeriKeyURL。由于签名验证密钥 的数目可以相对较小(例如,1),所以MPD文件大小可以不用受到直接包括的签名验证密钥 的太大影响。

签名模块220还可以用于生成MPD签名242,以保证计算分片签名中所考虑到的信 息的完整性和真实性。可以采用任何合适的函数或算法计算MPD签名242。随后,可以将MPD 签名插入MPD中,以生成包含MPD签名242和分片签名URL232的MPD244。在一个实施例中, MPD签名242可以作为元素进行存储(例如,记为Signature)。例如,MPD签名可以确保元素 SegmentSignature中的某些信息(例如,属性SegmentSignatureURLTemplate)不被篡改。一 旦接收到MPD244,验证实体可以检测分片是否被替换、修改或移除。

表2示出了包含时段元素和MPD签名的另一个元素的示例性MPD。该示例性MPD写编 写成XML码。本领域的技术人员应认识到该表示法和示例性元素/属性名称和值,因此,出于 简洁的目的,这些细节将不会在进一步进行描述。

表2

图3示出了一种签名验证方案300的实施例中的消息交互。为了开始流传送媒体内 容,流媒体客户端310,可以是DASH客户端或者其他类型的流媒体客户端,首先向web服务器 320发送MPD的请求,web服务器可以和HTTP服务器120相同或相似。随后,web服务器320可以 通过返回MPD进行响应。在接收到MPD后,客户端310可以解析MPD以解读该MPD中包含的信 息。客户端310可以根据资源统计、网络环境或状况、客户端310的设备能力以及使用客户端 310的订户的选择来确定合适的表示或自适应集。

接下来,客户端310可以发送包括初始化分片和媒体分片的分片的请求,web服务 器320可以通过发送分片进行响应。客户端310发送的请求可以包括SegmentURL,用于检索 web服务器320中的分片。尽管MPD和分片均发自相同的web服务器320,本领域的技术人员应 意识到,在替代性实施例中,描述媒体内容的MPD和媒体内容的分片可以存储在不同的服务 器中,并发自不同的服务器。例如,MPD可以发自内容发布商,而分片来自第三方CDN节点。

客户端310用于支持分片签名验证。为了验证所接收到的分片是否真实,客户端310 可以向签名存储服务器330发送请求,签名存储服务器中存储有原始SegmentSignature。请 注意,HTTP服务器320可能已经生成原始SegmentSignature。客户端310可以通过 SegmentSignatureURL或者接收到的MPD中包含的SegmentSignatureURLTemplate获得原始 SegmentSignature。因此,只需要为一个分片存储一个SegmentSignature,这会带来高存储 效率,且只需要向客户端310传送一个SegmentSignature,这会使通信数据达到最小。进一 步地,为了使签名验证过程可能带来的任何延迟达到最小,客户端310可以在接收对应的分 片之前或同时获得原始分片签名。

另外,在接收到分片后,客户端310可以采用分片签名、分片、可信信息,以及基于 MPD获得的签名验证密钥来确定分片的真实性。在一个实施例中,客户端310可以按照以下 接收到的分片的哈希函数计算摘要:

Hash(receivedsegment,SegmentSignatureURL)(3)

在替代性实施例中,采用哈希函数计算摘要也可将分片的CID考虑在内。此时,可 以按照以下哈希函数生成摘要:

Hash(receivedsegment,SegmentSignatureURL,CID)(4)

可以看出等式(3)对应于等式(1),等式(4)对应于等式(2)。因此,在客户端310中生成 摘要应当采用和生成原始SegmentSignature所使用的相同Hash()函数。在公式(3)或(4)中, 可以从接收到的MPD中提取或者从接收到的MPD中包含的SegmentSignatureURLTemplate得 到SegmentSignatureURL。

在确定接收到的分片真实性时,客户端310也可以采用签名验证密钥(即 SignatureVeriKey)计算SegmentSignature的值,以得到结果。随后,客户端310可以将结果 与摘要或哈希值进行比较。如果结果与摘要或哈希值相等,则真实性验证通过,表示接收到 的分片为真实分片;反之,验证失败,表示分片和/或分片签名可能已经被篡改。随后,客户 端310可以根据验证结果和预定义的规则采取行动。

可以通过接收到的MPD中的SignatureVeriKeyURL获得SignatureVeriKey。例如, 客户端310可以采用SignatureVeriKeyURL来检索签名存储服务器330中存储的 SignatureVeriKey。或者,如果接收到的MPD包括SignatureVeriKey,而不是 SignatureVeriKeyURL,则可以直接提取SignatureVeriKey。如上所述,媒体内容中的多个 分片可以共享公共签名验证密钥。因此,不需要为每个分片重复获取SignatureVeriKey。如 果所有分片共享相同的SignatureVeriKey,只需要通过SignatureVeriKeyURL获取 SignatureVeriKey一次。

在使用中,为了节省处理时间和/或功率,客户端310可以选择只为流媒体中包含 的一部分分片验证签名。例如,客户端310可以决定随机选择一些分片来验证其分片签名。

如果分片的验证通过,则客户端310可以开始播放该分片。当客户端310播放验证 后的分片时,客户端也可以更新资源统计(例如,网络状况、订户选择和设备能力)。如果根 据更新的资源统计应当采用不同的表示,则客户端310可以开始请求不同表示中的分片。进 一步地,MPD可以更新到包含更新的信息。如有必要,客户端310可以再次请求更新的MPD。

当分析所公开的签名验证方案的安全性时,应当理解的是,这些方案的安全性取 决于签名函数/算法(例如,等式(1)-(2))的安全性以及生成原始SegmentSignature所采用 的签名密钥的机密性。因此,可以假设攻击者不能访问原始分片签名,且在不知道所有输入 信息(例如,分片、SegmentSignatureURL、SignatureSignKey以及可选的CID)时不能正确地 生成原始签名。另外,如果哈希函数对碰撞攻击具有鲁棒性,则攻击者将难以找到两个具有 相同哈希摘要(即签名摘要)的不同分片。因此,攻击者可能无法找到另一个和合法签名者 所签名的分片的摘要具有相同哈希摘要的分片。换句话说,攻击者可能无法伪造分片签名。

在使用中,客户端310可以从segmentURL和SegmentSignatureURL分别指定的位置 中获得分片和分片签名。为了提高效率,客户端310有时可以从CDN缓存或HTTP缓存中获得 分片和分片签名。由于CDN节点或者HTTP服务器可以篡改分片和/或分片签名,所以客户端 310接收到的分片和/或分片签名可能由于篡改不同于原始的分片和/或分片签名。因此,有 必要保证分片和分片签名均来自可信实体(例如,合法的媒体内容提供商)。在本发明中,可 以基于分片本身生成分片签名,还可以基于MPD中的可信信息,例如分片签名的 SegmentSignatureURL。进一步地,可以由MPD签名验证SignatureURL的真实性。因此,客户 端310可以确认每个分片的真实性和完整性,并可以检测到分片篡改攻击。可以通过任何技 术保证MPD的真实性,例如,万维网联盟(WorldWideWebConsortium,W3C)标准规定的技 术。

如果MPD没有进行签名,例如,没有MPD签名,则MPD中的某些信息,例如 SegmentSignatureURL,可在DASH客户端没有检测到情况下就被篡改。例如,假设合法媒体 内容是可口可乐广告,攻击者试图用百事广告替换该广告。可口可乐广告和百事广告都可 以由相同媒体内容提供商服务。在MPD中,攻击者可以将可口可乐分片对应的 SegmentSignatureURL替换为百事分片对应的SegmentSignatureURL。进一步地,在HTTP服 务器或缓存中,攻击者可以将可口可乐分片替换为百事分片。由于攻击者可以和DASH客户 端一样访问哈希函数,所以攻击者可以基于百事分片和签名验证密钥为百事分片生成哈希 值。随后,攻击者可以在百事分片所对应的SegmentSignatureURL可寻址到的任何位置存储 SegmentSignature。此时,在DASH客户端接收到百事分片后,可以基于百事分片及其 SegmentSignatureURL计算出哈希值。DASH客户端也可以采用接收到的分片和签名验证密 钥计算另一个值。这两个值会匹配,因此,DASH客户端不能检测到对篡改攻击有用的篡改。

如上所述,在为分片生成签名时,所公开的方案将MPD中的可信信息考虑在内,从 而保证了分片的真实性。每个分片的可信信息可以多样和独有。例如,可信信息可以是 SegmentSignatureURL、SegmentURL或CID。所公开的方案可以防止各种攻击场景。在第一种 示例性情况下,原始分片被替换为未授权分片,随后由DASH接收到该分片。此时,DASH可以 检测授权分片。具体地,DASH客户端可以采用SegmentSignatureURL(可信信息)为原始签名 定位原始SegmentSignature,原始SegmentSignature可按照以下等式生成:

OriginalSegmentSignature=Sign(Hash(originalsegment, SegmentSignatureURL),SignatureSignKey)(5)

出于验证目的,DASH客户端还可以采用任何合适的函数将原始分片签名转换为另 一个值。如上所述,SignatureSignKey确定了对应的SignatureVeriKey。因此,DASH客户端 可以按照以下哈希函数计算哈希值:

Hash(unauthorizedsegment,SegmentSignatureURL)(6)

通过将基于原始分片签名的值和基于接收的分片的另一值进行比较,DASH客户端 将检测到验证失败,因为原始分片和未授权分片不同。

在第二种示例性情况下,原始SegmentSignature被替换为未授权 SegmentSignature,未授权SegmentSignature可以存储在签名存储服务器中。此时,在接收 到原始分片后,DASH客户端可以采用SegmentSignatureURL(可信信息)定位未授权 SegmentSignature(由于该未授权SegmentSignature替换了原始SegmentSignature)。必要 时,客户端还可以将未授权SegmentSignature转换为另一个值。进一步地,DASH客户端可以 按照以下哈希函数计算哈希值:

Hash(originalsegment,SegmentSignatureURL)(7)

通过将哈希值和基于未授权SegmentSignature的另一值进行比较,DASH客户端将 检测到验证失败。

在第三种示例性情况下,原始分片被替换为未授权分片,原始SegmentSignature 被替换为未授权SegmentSignature。请注意,由于MPD中的SegmentSignatureURL是可信信 息,且签名密钥受到保护,所以攻击者无法采用签名函数计算未授权SegmentSignature。此 时,在接收到未授权分片后,DASH客户端可以采用等式(6)生成哈希值。进一步地,DASH客户 端可以采用SegmentSignatureURL(可信信息)定位未授权SegmentSignature(由于该未授 权SegmentSignature替换了原始SegmentSignature)。必要时,DASH客户端还可以将未授权 SegmentSignature转换为另一个值。通过比较基于接收到的分片和未授权 SegmentSignature的值,DASH客户端将检测到验证失败。随后,DASH客户端可以根据验证结 果和预定义的规则采取行动。

如果在生成分片签名时没有考虑MPD中的可信信息,一些攻击是可能的,所以,所 公开的签名方案比传统签名方案具有更强的安全性。考虑传统方案中的第三种示例性情 况。由于生成SegmentSignature时没有考虑MPD中的任何信息,所以攻击者将能够基于未授 权分片采用签名函数计算出未授权SegmentSignature。因此,当DASH客户端仅基于接收到 的未授权分片生成检索到的SegmentSignature,检索到的SegmentSignature可以匹配未授 权SegmentSignature。

在传统方案中,由于攻击者可以重排序或者略过一些分片以发起攻击,所以在分 片签名中添加CID不能防止该攻击。类似地,由于攻击者可以将原始分片替换为属于并发未 授权媒体内容的并发未授权分片,所以在分片签名中添加时间戳也不能防止攻击。此外,由 于时间戳为时间窗,且攻击者可以将原始分片替换为相邻分片(例如,在相同表示中的前一 个分片或下一个分片),所以在分片签名中添加CID和时间戳都不能防止攻击。另外,攻击者 也可以将原始分片替换为另一种表示或自适应集中的对应分片。此外,由于时间戳可以仅 为直播流工作,其中的一个分片包含一个时间戳,所以在分片签名中包含时间戳可能并不 可取。如果分片不是直播流媒体的一部分,由于不同DASH客户端可以在不同时间访问相同 分片,则可以为该分片生成多个时间戳。此时,如果分片签名中包含时间戳,则可能需要多 个分片签名和多个SegmentSignatureURL,这将给DASH系统造成额外负担。

事实上,尽管采用安全信道可以实现传送URL,例如,采用HTTP安全(Hypertext TransferProtocolSecure,HTTPS)通信协议,安全信道也可能带来缺点。例如,由于在安 全信道中发送时URL可能需要进行加密,例如CDN节点的接收端可能没有正确的缓存它们。 又例如,由于信息需要进行加密并随后进行解密,通过HTTPS传送该信息可能更昂贵且效率 不高。所公开的认证方案可不需要URL通过安全信道进行传送,这将在实践中证明是有利 的。

URL认证的签名

为了防止如上述背景技术部分中所述的对URL的篡改、重组和删除类型的攻击,引 入了新的元素和属性作为签名参数。新参数可以包括元素SignatureInfo、该元素的子元素 SignatureIdInfo、Path和Range,以及其子属性segmentInfo。元素SignatureIdInfo包括 三个属性:Id、FirstSignDeclaration和nextId。元素Path包括属性MPDId、PeriodId、 AdaptationSetId和RepresentationId。元素Range包括属性startOffset和属性 numUrls。元素SignatureIdInfo的属性CurrentId、FirstSignDeclaration和nextId可 共同用于防止篡改、重组和删除攻击。如果属性nextId并不作为签名参数,则攻击者可成 功发起一些攻击。例如,攻击者可删除一些URL和对应的签名URL,且客户端无法检测到该类 型的攻击。元素Path的属性指示URL签名的路径,且可用于防止替换攻击。如果参数列表中 没有元素Path,则攻击者可将URL和对应签名替换为另一个MPD或表示中的URL和对应签名。 元素Range的属性表示URL签名的范围,且可以和元素SignatureIdInfo与元素Path的属性 一起用以防止一些攻击。

四个属性,即IsWholeMPDSignedOnce、IsWholePeriodOnce、 IsWholeAdapSetOnce和IsWholeRepreOnce,指示全部URL是否一次进行签名。如果这些属 性之一出现在MPD中,则不需要元素Range。属性segmentInfo将URL和对应的分片进行关 联。

在一个实施例中,签名模块220可以用于按照以下等式生成如下URL认证:

UrlAuthentication=Sign(Hash(CurrentId,nextId,MPDId,PeriodId, AdaptationSetId,RepresentationId,URL1,URL2,URLk,segmentInfo))

其中,Hash()表示关于CurrentId、nextId、MPDId、PeriodId、AdaptationSet Id、RepresentationId、URL1、URL2和URLk的哈希函数,segmentInfo表示签名密钥,Sign ()表示采用变量Hash()的签名算法。

通过计算哈希函数,即Hash(),为分片生成了摘要或哈希值。随后,采用Sign()函 数生成对应的UrlAuthentication。

元素UrlAuthentication为获取验证密钥提供了URL,并为构建URL提供了模板,这 将进一步用于为给定URL下载认证标签。

元素UrlAuthentication的语义如表3所示。

表3

元素SignatureIdInfo可以进行简化,使得属性FirstSignDeclaration和 NextId不是必需的,然而,所有按序排列的Id的列表和列表上的签名均必需。

内容访问授权的签名

为了提高内容访问授权的URL签名的方案的效率,公开了一个新元素 UrlAuthorization,以携带关于哪些URL进行了签名、授权了哪一个客户端,以及客户端或 验证方可在哪里检索基于URL的内容访问授权的信令信息。除了上述URL认证方案中所引入 的一些相同属性,所提出的元素中引入了两个属性ClientUniqueId和validityPeriod, 以支持个性化用户授权和内容授权过期。

在一个实施例中,签名模块220可以用于按照以下等式生成UrlAuthorization:

UrlAuthorization=Sign(Hash(MPDId,PeriodId,AdaptationSetId, RepresentationId,URL1,URL2,URLk,ClientUniqueId,validityPeriod))

签名验证需要上述的签名对象、验证密钥和签名值。所以,客户端需要向授权验证 方提供信息或者检索必要信息的相关URL。

元素UrlAuthorization为获取密钥提供了URL,并为构建URL提供了模板,这将进 一步用于为给定分片下载授权标签。元素UrlAuthorization的语义如表4所示。

表4

请注意,在元素UrlAuthorization中,子元素Path不是必需的。然而,当元素Path 出现时,元素UrlAuthorization可在MPD中任何位置。

可以看出,上述的两种方案均基于相似的URL签名,但出于不同的目的。在另一个 实施例中,上述方案可合并为一个方案,以进一步提高效率。

元素UrlSignature

元素UrlSignature为获取验证密钥提供了URL,并为构建URL提供了模板,这将进 一步用于下载签名标记。元素UrlSignature的语义如表5所示。

表5

上述方案可在网络部件或节点中实现,例如,具有足够的处理能力、存储器资源和 网络吞吐能力以处理其负载的必要工作量的网络节点。图4示出了适用于实现所公开的方 法/方案,例如,流媒体方案100、方案200和签名验证方案300,的一个或多个实施例的网络 节点1300的实施例。进一步地,网络节点1300可以用于实现此处所述的任何装置,例如,流 媒体客户端110或320、HTTP/web服务器120或320、媒体内容提供商,或者签名存储服务器 330。

网络节点1300包括处理器1302,所述处理器与包含以下项的存储器设备进行通 信:辅助存储器1304,只读存储器(readonlymemory,ROM)1306,随机存取存储器(random accessmemory,RAM)1308,输入/输出(input/output,I/O)设备1310,以及发送器/接收器 1312。尽管作为单个处理器进行描述,但处理器1302并不限于此而是可以包括多个处理器。 处理器1302可以实施为一个或多个中央处理器(centralprocessingunit,CPU)芯片、核 (例如,多核处理器)、现场可编程门阵列(fieldprogrammablegatearray,FPGA)、专用集 成电路(application-specificintegratedcircuit,ASIC)、和/或数字信号处理器 (digitalsignalprocessor,DSP),和/或可以是一个或多个ASIC的一部分。处理器1302可 以用于实现此处所述的任何方案,包括流媒体方案100、方案200,以及签名验证方案300。处 理器1302可通过硬件或硬件和软件的结合来实现。

辅助存储器1304通常包括一个或多个磁盘驱动器或磁带驱动器,用于数据的非易 失性存储,而且如果RAM1308的容量不足以存储所有工作数据,辅助存储器则用作溢流数 据存储设备。辅助存储器1304可以用于存储程序,当选择执行这些程序时,所述程序将加载 到RAM1308中。ROM1306可用于存储在程序执行期间读取的指令以及可能读取的数据。ROM 1306为非易失性存储设备,其存储容量相对于辅助存储器1304的较大存储容量而言通常较 小。RAM1308用于存储易失性数据,还可能用于存储指令。对ROM1306和RAM1308二者的存 取通常比对辅助存储器1304的存取快。

发送器/接收器1312可用作网络节点1300的输出和/或输入设备。例如,如果发送 器/接收器1312用作发送器,则其可将数据传出网络节点1300。如果发送器/接收器1312用 作接收器,其可将数据接入网络节点1300。发送器/接收器1312可采用以下形式:调制解调 器、调制解调器组、以太网卡、通用串行总线(UniversalSerialBus,USB)接口卡、串行接 口、令牌环卡、光纤分布式数据接口(fiberdistributeddatainterface,FDDI)卡、无线 局域网(wirelesslocalareanetwork,WLAN)卡、无线收发器卡例如码分多址(Code DivisionMultipleAccess,CDMA)、全球移动通信系统(GlobalSystemforMobile Communications,GSM)、长期演进(LongTermEvolution,LTE)、全球微波接入互操作性 (WorldwideInteroperabilityforMicrowaveAccess,WiMAX),和/或其他空中接口协议 无线收发器卡,以及其他熟知的网络设备。发送器/接收器1312可使得处理器1302与因特网 或一个或更多企业内部网进行通信。I/O设备1310可包括视频监控器、液晶显示器(liquid crystaldisplay,LCD)、触屏显示器,或其它类型的用于显示视频的视频显示器,也可包含 采集视频的视频录像设备。I/O设备1310也可以包括一个或多个键盘、鼠标、轨迹球或其他 熟知的输入设备。

可以理解的是,通过编程和/或加载可执行指令至网络节点1300,处理器1302、辅 助存储器1304、RAM1308和ROM1306中至少有一个会发生改变,从而将网络节点1300部分 转变为特定机器或装置(例如,具有本发明所述新颖功能的HTTP服务器或DASH客户端)。可 执行指令可存储于辅助存储器1304、ROM1306,和/或RAM1308上,并加载至处理器1302中 用于执行。对于电气工程及软件工程技术来说基本的是,可通过将可执行软件加载到计算 机中而实现的功能可通过熟知设计规则而转换为硬件实施方案。在软件还是硬件中实现概 念的判断通常取决于设计的稳定性及待生成单元的数目的考量,而与从软件域转译到硬件 域所涉及的任何问题无关。通常,仍在经受频繁改变的设计可优先在软件中实现,因为重新 设计硬件实现方案比重改软件设计更为昂贵。通常,稳定及大规模生产的设计更适于在如 专用集成电路(application-specificintegratedcircuit,ASIC)这样的硬件中实现,因 为运行硬件实现方案的大规模生产比软件实现方案更为便宜。通常,一个设计可以软件形 式进行开发及测试,且随后通过熟知设计规则变换为对软件的指令进行硬连线的专用集成 电路中的等效硬件实现。同样地,正如由新ASIC控制的机器是特定的机器或装置,已编程 和/或加载有可执行指令的计算机可视为特定的机器或装置。

本发明公开了至少一项实施例,且所属领域的普通技术人员对所述实施例和/或 所述实施例的特征作出的变化、组合和/或修改均在本发明的范围内。因组合、合并和/或省 略所述实施例的特征而得到的替代性实施例也在本发明的范围内。在明确说明数字范围或 限制的情况下,此类表达范围或限制应被理解成包括在明确说明的范围或限制内具有相同 大小的迭代范围或限制(例如,从约为1到约为10包括2、3、4等;大于0.10包括0.11、0.12、 0.13等)。例如,只要公开具有下限Rl和上限Ru的数字范围,则明确公开了此范围内的任何数 字。具体而言,在所述范围内的以下数字是明确公开的:R=Rl+k*(Ru-Rl),其中k是从1%到 100%以1%增量递增的变量,即,k是1%、2%、3%、4%、5%……70%、71%、72%……95%、 96%、97%、98%、99%或100%。此外,由上文所定义的两个数字R定义的任何数字范围也是 明确公开的。除非另有陈述,否则术语“约”的使用意味着随后数字±10%。相对于权利要求 的任一元素使用术语“任选地”意味着所述元素是需要的,或者所述元素是不需要的,两种 替代方案均在所述权利要求的范围内。使用如“包括”、“包含”和“具有”等较广术语应被理 解为提供对如“由……组成”、“基本上由……组成”以及“大体上由……组成”等较窄术语的 支持。因此,保护范围不受上文所陈述的说明限制,而是由所附权利要求书界定,所述范围 包含所附权利要求书的标的物的所有等效物。每一和每条权利要求作为进一步揭示内容并 入说明书中,且所附权利要求书是本发明的实施例。对所述揭示内容中的参考进行的论述 并非承认其为现有技术,尤其是具有在本申请案的在先申请优先权日期之后的公开日期的 任何参考。本发明中所引用的所有专利、专利申请案和公开案的揭示内容特此以引用的方 式并入本文本中,其提供补充本发明的示例性、程序性或其它细节。

虽然本发明多个具体实施例,但应当理解,所公开的系统和方法也可通过其它多 种具体形式体现,而不会脱离本发明的精神或范围。本发明的实例应被视为说明性而非限 制性的,且本发明并不限于本文本所给出的细节。例如,各种元件或部件可以在另一系统中 组合或合并,或者某些特征可以省略或不实施。

此外,在不脱离本发明的范围的情况下,各种实施例中描述和说明为离散或单独 的技术、系统、子系统和方法可以与其它系统、模块、技术或方法进行组合或合并。展示或论 述为彼此耦合或直接耦合或通信的其它项也可以采用电方式、机械方式或其它方式通过某 一接口、设备或中间部件间接地耦合或通信。其它变更、替换、更替示例对本领域技术人员 而言是显而易见的,均不脱离此处公开的精神和范围。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号