用于安全性可更新性的分布式准许列表

摘要

本发明公开了用于安全性可更新性的分布式准许列表。为了在例如UHD视频之类的高价值视频内容的分发中提供安全性和鲁棒性，提供一个准许列表，其不像废止列表那样授予对于内容的默认访问，而是在潜在地被破解的设备上强制软件更新以将其带回到遵从拷贝保护的状态，从而消除了例如对于已被破解的特定输出的使用。在输出内容之前，源设备确定接收设备是否处在准许列表上，输出是否仍然有效，接收设备的版本号是否仍然有效，以及接收设备不具有其可以用来再输出内容的不安全的输出。

说明书

技术领域

本申请总体上涉及用于内容安全性可更新性的分布式准许列表。

背景技术

作为特征在于其可持续性、自我组织和可伸缩性的自适应和分布式社会技术系统的与本发明的原理相关的一种示例性计算机生态系统或数字生态系统是这样一个网络，其中向客户端设备分发例如所谓的“4K”或“8K”视频之类的超高清晰度(UHD)视频，同时提供针对UHD视频的未经授权的拷贝和散播的安全性。对于安全性系统可以使用废止消息。作为一个实例，数字传输拷贝保护(DTCP)协议使用被称作“系统可更新性(renewability)消息”(SRM)的废止消息。

在这里应当理解的是，当前的链接保护所存在的一个问题在于，一旦识别出漏洞攻击(breach)，校正来自源设备的下游的问题是具有挑战性的。举例来说，保护通过高清晰度多媒体接口(HDMI)链接传送的内容的高带宽数字内容保护(HDCP)内容保护协议的至少一个早前版本已被破解。本申请理解到，网关设备可以从付费电视提供商接收受到条件访问(CA)或数字权利管理(DRM)保护的已压缩内容。网关设备利用CA或DRM对内容进行解扰。网关设备随后可以通过使用DTCP-IP的家庭网络向另一设备(例如游戏控制台)重新传送已压缩内容。另一设备(例如游戏控制台)随后可以解压缩并且通过HDCP输出内容。但是黑客可以例如使用个人计算机利用假的HDCP凭证来创建冒充电视的假的HDMI信宿设备。在这种情形中，解码设备(例如游戏控制台)并不知晓其附接到假的电视。可能会通过受到HDCP的被破解版本保护的HDMI来输出内容，在这种情况下内容可能会被捕获并且通过盗版方式被递送到因特网。在利用DTCP-DP从网关设备向解码设备递送内容时，尚不可能从下游分发中排除HDCP的被破解版本。

在HDCP的情况下，密钥生成算法被黑客逆向工程，从而允许生成无限数目的虚假HDCP设备。但是不良的实现方式也可能会暴露密钥并且从而暴露内容。所述问题可能是无处不在的，从而使得对于潜在地数以千计(可能是数以百万计)的设备的现实废止是不切实际的。因此，正在尝试把优质服务带到家庭中的内容提供商和服务运营商所剩下的都是不具有吸引力的选项。其可以继续递送内容并且冒着失去对于内容的控制的风险，或者彻底放弃服务并且承受所导致的收益损失。

发明内容

在一个实施例中，在家庭网络中分发准许列表。准许列表带来与废止列表不同类型的对于家庭中的内容保护和分发的控制。准许列表可以仅被使用在网关处，其还可以从网关被分发到信宿，以便对于可以从信宿获得内容的分布式设备促进内容安全性。

相应地，在一个方面中，一种用于计算机化内容网关的设备包括至少一个计算机存储器，所述至少一个计算机存储器不是瞬时性信号并且包括指令，所述指令可由至少一个处理器执行来接收被授权从网关接收至少一些内容的信宿设备的准许列表。准许列表上的条目涉及对应的设备，至少一些条目与对应的设备标识(ID)相关联。所述指令可被执行来：接收针对从网关向被配置成播放视频内容的信宿发送内容的请求；把和信宿相关联并且由网关在数字证书中接收到的设备ID与设备列表的至少一部分进行比较；以及基于在证书中接收到的与信宿相关联的设备ID匹配列表上的设备ID，向信宿提供内容。所述指令可被执行来：至少部分地基于在证书中接收到的设备ID不匹配列表上的设备ID，不向信宿提供内容。

在一些实例中，所述指令可被执行来向信宿提供所述列表，从而使得至少部分地由信宿利用所述列表来控制第三设备针对信宿的内容请求。在一些实例中，所述列表受到版本控制，并且所述指令可被执行来至少在网关与信宿之间共享列表的最新版本。在一些实例中，所述指令可被执行来利用信任证书颁发机构的公根(common root)的公钥来验证列表的版本和真实性。在一些实例中，信任证书颁发机构的公根的公钥由信宿和第三设备二者持有。在一些实施例中，在网关与信宿之间的链接保护期间从信宿所使用的数字证书访问与准许列表进行比较的设备ID。在一些实例中，所述链接保护是数字传输拷贝保护(DTCP)、高带宽数字拷贝保护(HDCP)或者数字权利管理(DRM)。

在另一个方面中，一种方法包括：在计算机化网关处接收被授权从网关接收至少一些内容的设备的准许列表。所述列表上的条目涉及对应的设备，并且至少一些条目与对应的设备标识(ID)以及至少一条预期标准相关联。所述方法包括：接收针对从网关向被配置成播放视频内容的信宿发送内容的请求，以及把由网关在数字证书中从信宿接收到的信宿的设备ID和至少一项设备属性与设备列表的至少一部分进行比较。至少部分地基于从信宿接收到的设备ID和设备属性匹配列表上的设备ID和相关联的预期标准，所述方法包括向信宿提供内容。另一方面，至少部分地基于从信宿接收到的设备ID和/或至少一项设备属性不匹配列表上的设备ID和/或列表上的对应的预期标准，所述方法包括不向信宿提供内容。

在一些实例中，所述方法包括向信宿提供所述列表，从而使得至少部分地由信宿利用所述列表来控制第三设备针对信宿的内容请求。在一些实例中，所述方法包括：基于从信宿接收到的设备属性不匹配列表上的预期标准，向信宿发送消息以便向用户输出OSD。

示例性的预期标准可以包括以下各项当中的一项或多项：软件版本号，距离上一次软件更新的时间，HDCP协议的最低版本，DRM协议的最低版本，DTCP协议的最低版本，包括安全执行环境，包括存储能力，最低鲁棒性水平，最低硬件鲁棒性水平，制造商，型号，下游连接设备的最大数目。举例来说，如果作为设备属性从信宿设备发送的设备的软件版本号不匹配最低软件版本水平，则可以向用户显示OSD从而提示更新该设备的软件。

示例性的设备属性可以包括以下各项当中的一项或多项：软件版本号，距离上一次软件更新的时间，HDCP协议的版本，HDCP设备ID，DRM协议的版本，DRM设备ID，DTCP协议的版本，DTCP设备ID，包括安全执行环境，存储能力，鲁棒性水平，硬件鲁棒性水平，制造商，型号，设备序列号，下游连接设备的数目，去到因特网的连接状态，解码能力，屏幕分辨率，屏幕尺寸。

在一些实例中，所述方法包括利用信宿设备验证来自数字证书的设备ID，这是通过证明信宿设备具有对应于数字证书中的公钥的私钥实现的。在一些实例中，所述方法包括利用涉及公钥和私钥的防篡改协议从信宿设备向网关递送信宿设备属性。在一些实例中，所述方法包括向信宿提供所述列表，从而使得至少部分地由信宿利用所述列表来控制第三设备针对信宿的内容请求。所述列表可以受到版本控制，并且所述方法可以包括至少在网关与信宿之间共享列表的最新版本。在一些实例中，所述方法包括利用信任证书颁发机构的公根的公钥来验证列表的版本和真实性。

在另一个方面中，一种用于计算机化信宿的设备包括至少一个计算机存储器，所述至少一个计算机存储器不是瞬时性信号并且包括指令，所述指令可由至少一个处理器执行来从网关接收被授权接收通过该网关接收到的至少一些内容的设备的准许列表。准许列表上的条目涉及对应的设备，至少一些条目与对应的设备标识(ID)相关联。所述指令可被执行来：接收针对从信宿向被配置成处理视频内容的第三设备发送内容的请求；把和第三设备相关联并且由信宿在数字证书中接收到的设备ID与设备列表的至少一部分进行比较；以及基于在证书中接收到的与第三设备相关联的设备ID匹配列表上的设备ID，向第三设备提供内容。所述指令还可被执行来：至少部分地基于在证书中接收到的设备ID不匹配列表上的设备ID，不向第三设备提供内容。

可以参照附图最佳地理解本申请在其结构和操作两方面的细节，其中相同的附图标记指代相同的部分，并且其中：

附图说明

图1是包括根据本发明的原理的一个实例的示例性系统的方块图；

图2是可以使用图1的组件的另一个系统的方块图；

图3是根据一个实施例的认证消息的示意图；

图4是与图5一致的示出了DTCP废止列表和消息流程的网关和信宿的示意图，其中示出了示例性的认证处理；

图6是示例性两次握手认证处理的示意图；以及

图7和8是示例性逻辑的流程图。

具体实施方式

本公开内容总体上涉及包括消费电子装置(CE)设备网格网络的各方面的计算机生态系统。这里的系统可以包括通过网络连接的服务器和客户端组件，从而使得可以在客户端和服务器组件之间交换数据。客户端组件可以包括一个或多个计算设备，其中包括便携式电视(例如智能电视、具有因特网功能的电视)、例如膝上型和平板计算机之类的便携式计算机以及包括智能电话和后面讨论的附加实例的其他移动设备。这些客户端设备可以在多种操作环境中操作。举例来说，其中一些客户端计算机作为实例可以采用来自Microsoft的操作系统，或者Unix操作系统，或者由Apple Computer或Google生产的操作系统。这些操作环境可以被用来执行一个或多个浏览程序，比如由Microsoft或Google或Mozilla制作的浏览器或者可以访问由后面讨论的因特网服务器托管的web应用的其他浏览器程序。

服务器和/或网关可以包括执行指令的一个或多个处理器，所述指令配置服务器通过例如因特网之类的网络接收和传送数据。或者，客户端和服务器可以通过本地内联网或虚拟私有网络连接。服务器或控制器可以由例如Sony PlayStation(注册商标)之类的游戏控制台、个人计算机等等实例化。

可以通过网络在客户端和服务器之间交换信息。为此目的并且出于安全性，服务器和/或客户端可以包括防火墙、负载平衡器、临时存储装置和代理以及用于可靠性和安全性的其他网络基础设施。一个或多个服务器可以形成一个装置，其实施向网络成员提供例如线上社交网站之类的安全社区的方法。

这里所使用的指令指的是用于在系统中处理信息的计算机实施的步骤。指令可以通过软件、固件或硬件来实施，并且包括由系统的组件采取的任何类型的编程步骤。

处理器可以是任何传统的通用单芯片或多芯片处理器，其可以通过例如地址线、数据线和控制线之类的各种线路以及寄存器和移位寄存器来执行逻辑。

在这里通过流程图和用户接口描述的软件模块可以包括各种子例程、规程等等。在不限制本公开内容的情况下，被描述成由特定模块执行的逻辑可以被重新分配到其他软件模块以及/或者一起组合在单一模块中以及/或者在可共享的库中可用。

这里所描述的本发明的原理可以被实施成硬件、软件、固件或者其组合；因此在其功能方面阐述了说明性的组件、块、模块、电路和步骤。

此外关于前面所提及的内容，后面所描述的逻辑块、模块和电路可以利用通用处理器、数字信号处理器(DSP)、现场可编程门阵列(FPGA)或者其他可编程逻辑设备来实现或实施，所述其他可编程逻辑设备比如有被设计成实施这里所描述的功能的专用集成电路(ASIC)、分立门或晶体管逻辑、分立硬件组件或者其任意组合。可以通过控制器或状态机或者计算设备的组合来实施处理器。

当通过软件来实施时，后面所描述的功能和方法可以用适当的语言(比如C#或C++但是不限于此)来编写，并且可以被存储在计算机可读存储介质上或者通过计算机可读存储介质来传送，所述计算机可读存储介质比如有随机存取存储器(RAM)、只读存储器(ROM)、电可擦写可编程只读存储器(EEPROM)、紧致盘只读存储器(CD-ROM)或者例如数字通用盘(DVD)之类的其他光盘存储装置、磁盘存储装置或者包括可移除拇指驱动器在内的其他磁性存储设备等等。连接可以建立计算机可读介质。这样的连接例如可以包括硬连线的线缆，其中包括光纤和同轴线以及数字订户线(DSL)和双绞线。这样的连接可以包括无线通信连接，其中包括红外和无线电。

在一个实施例中所包括的组件可以按照任何适当的组合被使用在其他实施例中。举例来说，这里所描述以及/或者在附图中描绘的各个组件当中的任一个可以与其他实施例组合、互换或者从其他实施例排除。

“具有A、B和C的至少其中之一的系统”(同样地还有“具有A、B或C的至少其中之一的系统”以及“具有A、B、C的至少其中之一的系统”)包括只具有A、只具有B、只具有C、同时具有A和B、同时具有A和C、同时具有B和C以及/或者同时具有A、B和C等等的系统。

现在具体参照图1，其中示出了示例性生态系统10，其可以包括前面所提到并且在后面根据本发明的原理进一步描述的其中一个或多个示例性设备。包括在系统10中的第一个示例性设备是被配置成示例性的主显示设备的消费电子装置(CE)设备，并且在所示出的实施例中是音频视频显示设备(AVDD)12，比如(而不限于)带有电视调谐器(等效地是控制电视的机顶盒)的具有因特网功能的电视。但是AVDD 12替换地可以是电器或者家用电器项目，例如具有因特网功能的计算机化冰箱、洗衣机或烘干机。AVDD 12替换地还可以是具有因特网功能的计算机化(“智能”)电话、平板计算机、笔记本计算机、可穿戴计算机化设备(例如具有因特网功能的计算机化手表、具有因特网功能的计算机化手镯、其他具有因特网功能的计算机化设备)、具有因特网功能的计算机化音乐播放器、具有因特网功能的计算机化头戴式耳机、具有因特网功能的计算机化可植入设备(比如可植入皮肤设备)等等。然而应当理解的是，AVDD 12被配置成采用本发明的原理(例如与其他CE设备通信以采用本发明的原理，执行这里所描述的逻辑，以及实施这里所描述的任何其他功能和/或操作)。

相应地，为了采用这样的原理，AVDD 12可以通过图1中示出的其中一些或所有组件来建立。举例来说，AVDD 12可以包括一个或多个显示器14，其可以通过高清晰度或超高清晰度“4K”或更高清晰度平面屏幕来实施，并且可以具有触摸功能以用于通过显示器上的触摸来接收用户输入信号。AVDD 12可以包括一个或多个扬声器16，以用于根据本发明的原理输出音频，以及例如音频接收器/麦克风之类的至少一个附加输入设备18，以用于例如向AVDD 12输入可听命令以便控制AVDD 12。示例性的AVDD 12还可以包括一个或多个网络接口20，以便在一个或多个处理器24的控制下通过至少一个网络22(比如因特网、WAN、LAN等等)进行通信。因此，接口20可以是(而不限于)作为无线计算机网络接口的一个实例的Wi-Fi收发器，比如(而不限于)网格网络收发器。应当理解的是，处理器24控制AVDD 12采用本发明的原理，其中包括这里所描述的AVDD 12的其他元件，比如控制显示器14在其上呈现图像以及从该处接收输入。此外还应当提到的是，网络接口20例如可以是有线或无线调制解调器或路由器或者其他适当的接口，比如无线电话收发器或者前面提到的Wi-Fi收发器等等。

除了前述内容之外，AVDD 12还可以包括一个或多个输入端口26，比如高清晰度多媒体接口(HDMI)端口或USB端口，以便(例如使用有线连接)物理地连接到另一个CE设备，以及/或者头戴式耳机端口，以便把头戴式耳机连接到AVDD 12以用于通过头戴式耳机从AVDD12向用户呈现音频。举例来说，输入端口26可以通过连线或者通过无线方式连接到音频视频内容的有线电视(cable)或卫星源26a。因此，源26a例如可以是单独的或集成的机顶盒或者卫星接收器。或者，源26a可以是包含内容的游戏控制台或盘播放器，出于后面进一步描述的信道指派目的，其可能被用户视为最喜爱的。

AVDD 12还可以包括一个或多个有形计算机可读存储介质28，比如基于盘的或者固态存储装置，其在某些情况下被具体实现在AVDD的机架中以作为独立设备或者作为AVDD的机架内部或外部的个人视频记录设备(PVR)或视频盘播放器，以用于重放AV节目。此外，在一些实施例中，AVDD 12可以包括方位或位置接收器，比如(而不限于)蜂窝电话接收器、GPS接收器和/或高度计30，其被配置成例如接收来自至少一个卫星或蜂窝电话塔的地理方位信息，并且将所述信息提供到处理器24并且/或者结合处理器24确定AVDD 12的部署高度。但是应当理解的是，根据本发明的原理可以使用除了蜂窝电话接收器、GPS接收器和/或高度计之外的另一种适当的方位接收器，以便例如确定AVDD 12在例如全部三个维度中的位置。

继续AVDD 12的描述，在一些实施例中，AVDD 12可以包括一个或多个摄影机32，其例如可以是热成像摄影机、网络摄像头之类的数字摄影机以及/或者被集成到AVDD 12中并且可由处理器24控制来根据本发明的原理收集图片/图像和/或视频的摄影机。在AVDD 12上还可以包括蓝牙(Bluetooth)收发器34和其他近场通信(NFC)元件36，以用于分别利用Bluetooth和/或NFC技术与其他设备进行通信。示例性的NFC元件可以是射频标识(RFID)元件。

此外，AVDD 12可以包括向处理器24提供输入的一个或多个辅助传感器37(例如加速度计、陀螺仪、记转器之类的运动传感器，或者磁性传感器、红外(IR)传感器、光学传感器、速度和/或节奏传感器、手势传感器(其例如用于感测手势命令)等等)。AVDD 12可以包括空中电视广播端口38，其用于接收OTH TV广播并且向处理器24提供输入。除了前述内容之外还应当提到的是，AVDD 12还可以包括红外(IR)传送器和/或IR接收器和/或IR收发器42，比如IR数据关联(IRDA)设备。可以提供电池(未示出)以用于为AVDD 12供电。

仍然参照图1，除了AVDD 12之外，系统10还可以包括一个或多个其他CE设备类型。在一个实例中，第一CE设备44可以被用来经由通过后面描述的服务器发送的命令来控制显示器，第二CE设备46可以包括与第一CE设备44类似的组件，因此将不作详细讨论。在所示出的实例中仅仅示出了两个CE设备44、46，应当理解的是，可以使用更少或更多的设备。

在所示出的实例中，为了说明本发明的原理，假设所有三个设备12、44、46都是例如家庭中的娱乐网络的成员，或者至少在例如住宅之类的位置处彼此邻近地存在。但是除非明确地另行声明，否则本发明的原理不限于通过虚线48示出的特定位置。

示例性的非限制性第一CE设备44可以通过任一个前面所提到的设备来建立，比如便携式无线膝上型计算机或笔记本计算机，并且相应地可以具有后面所描述的其中一个或多个组件。在不作限制的情况下，第二CE设备46可以通过例如Blu-ray播放器、游戏控制台等视频盘播放器来建立。第一CE设备44可以是例如用于向AVDD 12发出AV播放和暂停命令的遥控器(RC)，或者其可以是更加复杂的设备，比如平板计算机、游戏控制台、个人计算机、无线电话等等。

相应地，第一CE设备44可以包括一个或多个显示器50，其可以具有触摸功能以用于通过显示器上的触摸来接收用户输入信号。第一CE设备44可以包括一个或多个扬声器52，以用于根据本发明的原理输出音频，以及例如音频接收器/麦克风之类的至少一个附加输入设备54，以用于例如向第一CE设备44输入可听命令以便控制设备44。示例性的第一CE设备44还可以包括一个或多个网络接口56，以便在一个或多个CE设备处理器58的控制下通过网络22进行通信。因此，接口56可以是(而不限于)作为无线计算机网络接口的一个实例的Wi-Fi收发器，其中包括网格网络接口。应当理解的是，处理器58控制第一CE设备44采用本发明的原理，其中包括这里所描述的第一CE设备44的其他元件，比如控制显示器50在其上呈现图像以及从该处接收输入。此外还应当提到的是，网络接口56例如可以是有线或无线调制解调器或路由器或者其他适当的接口，比如无线电话收发器或者前面提到的Wi-Fi收发器等等。

除了前述内容之外，第一CE设备44还可以包括一个或多个输入端口60，比如HDMI端口或USB端口，以便(例如使用有线连接)物理地连接到另一个CE设备，以及/或者头戴式耳机端口，以便把头戴式耳机连接到第一CE设备44以用于通过头戴式耳机从第一CE设备44向用户呈现音频。第一CE设备44还可以包括一个或多个有形计算机可读存储介质62，比如基于盘的或者固态存储装置。此外，在一些实施例中，第一CE设备44可以包括方位或位置接收器，比如(而不限于)蜂窝电话和/或GPS接收器和/或高度计64，其被配置成例如使用三角定位接收来自至少一个卫星和/或蜂窝塔的地理方位信息，并且将所述信息提供到CE设备处理器58并且/或者结合CE设备处理器58确定第一CE设备44的部署高度。但是应当理解的是，根据本发明的原理可以使用除了蜂窝电话和/或GPS接收器和/或高度计之外的另一种适当的方位接收器，以便例如确定第一CE设备44在例如全部三个维度中的位置。

继续第一CE设备44的描述，在一些实施例中，第一CE设备44可以包括一个或多个摄影机66，其例如可以是热成像摄影机、网络摄像头之类的数字摄影机以及/或者被集成到第一CE设备44中并且可由CE设备处理器58控制来根据本发明的原理收集图片/图像和/或视频的摄影机。在第一CE设备44上还可以包括Bluetooth收发器68和其他近场通信(NFC)元件70，以用于分别利用Bluetooth和/或NFC技术与其他设备进行通信。示例性的NFC元件可以是射频标识(RFID)元件。

此外，第一CE设备44可以包括向CE设备处理器58提供输入的一个或多个辅助传感器72(例如加速度计、陀螺仪、记转器之类的运动传感器，或者磁性传感器、红外(IR)传感器、光学传感器、速度和/或节奏传感器、手势传感器(其例如用于感测手势命令)等等)。第一CE设备44还可以包括向CE设备处理器58提供输入的其他传感器，例如一个或多个气候传感器74(例如气压计、湿度传感器、风速传感器(wind sensor)、光传感器、温度传感器等等)以及/或者一个或多个生物测定传感器76。除了前述内容之外还应当提到的是，在一些实施例中，第一CE设备44还可以包括红外(IR)传送器和/或IR接收器和/或IR收发器42，比如IR数据关联(IRDA)设备。可以提供电池(未示出)以用于为第一CE设备44供电。CE设备44可以通过任何前面描述的通信模式和有关组件与AVDD 12进行通信。

第二CE设备46可以包括对于CE设备44所示出的其中一些或所有组件。

现在参照前面提到的至少一个服务器80，其包括至少一个服务器处理器82、至少一个有形计算机可读存储介质84(比如基于盘的或者固态存储装置)以及至少一个网络接口86，其在服务器处理器82的控制下允许通过网络22与图1的其他设备进行通信，并且实际上可以促进根据本发明的原理的服务器与客户端设备之间的通信。应当提到的是，网络接口86例如可以是有线或无线调制解调器或路由器、Wi-Fi收发器或者其他适当的接口，比如无线电话收发器。

相应地，在一些实施例中，服务器80可以是因特网服务器，并且可以包括并且实施“云端”功能，从而使得在示例性实施例中系统10的设备可以经由服务器80访问“云端”环境。或者，服务器80可以通过与图1中示出的其他设备处在相同房间内或处在附近的游戏控制台或其他计算机来实施。

现在参照图2，可以合并图1中的AVDD 12的其中一些或所有组件的AVDD 200连接到至少一个网关以便从网关接收内容，例如4K或8K内容之类的UHD内容。在所示出的实例中，AVDD 200连接到第一和第二卫星网关202、204，其中的每一个可以被配置成卫星电视机顶盒，以用于接收来自对应的卫星电视提供商的对应的卫星系统206、208的卫星电视信号。

作为对于卫星网关的补充或替代，AVDD 200可以从一个或多个有线电视机顶盒类型的网关210、212接收内容，其中每一个网关从对应的有线电视头端214、216接收内容。

同样地，取代机顶盒类的网关，AVDD 200可以从基于云端的网关220接收内容。基于云端的网关220可以驻留在AVDD 200本地的网络接口设备中(例如AVDD 200的调制解调器)，或者其可以驻留在向AVDD 200发送来源于因特网的内容的远程因特网服务器中。在任何情况下，AVDD 200都可以通过基于云端的网关220从因特网接收例如UHD内容之类的多媒体内容。所述网关被计算机化，并且从而可以包括图1中示出的任何CE设备的适当组件。

在一些实施例中，例如利用本发明的受让人的远程查看用户接口(RVU)技术，可以仅提供单个机顶盒类型的网关。

第三设备可以例如通过以太网或通用串行总线(USB)或WiFi或者其他有线或无线协议连接到家庭网络(其可以是网格类型的网络)中的AVDD 200，以便根据这里的原理从AVDD 200接收内容。在所示出的非限制性实例中，第二台电视222连接到AVDD 200以从该处接收内容，视频游戏控制台224也是如此。附加的设备可以连接到一个或多个第三设备以便扩展所述网络。第三设备可以包括图1中示出的任何CE设备的适当组件。

在一个初始的基本实例中，图2中示出的AVDD 200或其中一个网关可以接收用户输入以播放UHD内容。通常来说，用户将必须具有针对此类内容的订购，这是因为此类内容通常被视为具有高价值。在任何情况下，网关调谐到所选择的UHD节目，从而在该说明性实施例中与AVDD 200建立数字传输内容协议(DTCP)连接(如果尚未建立的话)。AVDD 200和网关都具有DTCP证书，其被相对的组件检查(AVDD检查网关证书，网关检查AVDD证书)以进行废止。假设任一份证书都没有被废止，则网关向AVDD发送内容，其中充当内容信宿的AVDD播放内容。

在一些实施例中，根据协议AVDD 200被编程为不重传或记录内容，并且没有高清晰度多媒体接口(HDMI)可以从AVDD 200允许输出。可能没有被提供来从外部访问来自AVDD200的已压缩或已解码内容的部件，并且对于来自AVDD 200的音频-视频内容输出可以通过编程方式禁用任何以太网或USB接口(但是可以提供其他输出)。

但是在这里所讨论的其他实施例中，AVDD 200被允许向第三设备发送内容。但是在这里应当理解的是，AVDD 200可以向其发送内容的其他设备可能不符合内容保护鲁棒性要求，从而导致有价值内容的未经授权的散播。在这里还应当理解的是，这一问题仅被DTCP部分地解决，这部分地是因为在DTCP认证中使用的数字传输许可管理机构(DTLA)证书不包含设备的制造商的身份或型号信息。相应地应当理解的是，简单地使用现有的DTLA证书无法提供被许可设备的“准许列表”的实现方式以管理被许可信宿下游的内容分发。

鉴于前述内容，本发明的原理提供了通过安全的方式发送设备属性和/或设备ID以用于认证目的。在一个实例中，这里所修改的数字生活网络联盟(DLNA)商务视频简档(CVP)-2认证机制可以被用来实施表明遵循相关的鲁棒性标准的比特，其中通过寻求认证的设备的私有加密密钥保护数据有效载荷的安全。应当提到的是，本发明的原理可以适用于向例如网关之类的上游组件寻求认证的AVDD 200，并且/或者适用于寻求认证以便从信宿获得内容的第三设备。因此，例如在图3-6中，寻求认证的客户端可以是信宿，其可以是AVDD 200，并且认证服务器可以是网关202；或者，寻求认证的客户端可以是其中一个第三设备222、224，并且授予认证的组件可以是单独动作或者与上游的网关协同动作的AVDD200。

可以使用的设备属性包括：软件版本号(例如设备当前采用的HDCP软件的版本号)，距离上一次软件更新的时间，HDCP协议的版本，HDCP设备ID，数字权利管理(DRM)协议的版本，DRM设备ID，DTCP协议的版本，DTCP设备ID，包括安全执行环境，存储能力，鲁棒性水平，硬件鲁棒性水平，制造商，型号，设备序列号，下游连接设备的数目，去到因特网的连接状态，解码能力，屏幕分辨率，屏幕尺寸。可以通过去到认证服务器的超文本传输协议安全(https)链接来触发认证，并且可以在“protocollnfo”消息中传达认证要求。

在图3所提供的图示中，附加字段300被添加到例如补充或载送DTCP证书的传输层安全(TLS)消息302。在公钥/私钥加密方案中，可以利用设备的私钥提供和加密不透明的随机字节304和随机不重数(nonce)306。根据本发明的原理，字段300可以包括例如16字节的无符号字符串，其可以与在通用即插即用(UPnP)消息中发送的字符串完全相同，并且可以是唯一地标识寻求认证的设备的通用唯一标识符(UUID)。所述字符串可以由发送dtcp认证消息的遵循DTCP的发送器生成，并且由服务器(比如图2中的网关)使用来唯一地标识发出请求的设备，而不管也被使用的DTCP证书的类型如何。字段300中的UUID可以表明设备的制造商、型号和设备ID。TLS消息302还可以包括一份或多份DTCP证书308。

图4和5被一起示出，以便说明图3中的数据的使用。如图4的非限制性实例中所示，网关400经由以太网或WiFi与信宿402通信。每一个组件可以访问DTCP废止列表的对应的数据结构404、406，该列表列出了已被废止的DTCP证书。如408处所示，在网关400和信宿402之间还交换图3的消息302。同样如图4中所示，网关400可以访问准许列表数据结构410，其是被授权接收内容的各个单独设备的列表。准许列表410中的每一个条目可以包括设备制造商、型号和设备ID。

在图5中的500处，消息302被表明为是从信宿发送到网关。在502处，网关访问准许列表410以便基于图3中的字段300确定信宿是否处在准许列表上。如果是的话，则信宿通过第一检查；否则，信宿不被允许访问所请求的内容。

网关还可以在504处确定在DTCP认证协议中接收到的信宿的DTCP证书是否与在TLS消息302中接收到的证书相同。如果全部两项测试(502和504处)都通过，则网关确定信宿被授权接收内容。如果任一项测试失败，则信宿不可被允许访问内容。

在图6中更加详细地示出了前面的处理。在图6中，“UI客户端”、“DTCP库(DTCPLib)”和“认证客户端(AuthClient)”是由寻求认证的客户端设备(例如信宿或者连接到信宿的第三设备)执行的本地软件例程，“认证服务器(AuthServer)”则是由授予访问的组件(例如网关)执行的例程。

在600处，用户通过呈现在客户端上的用户接口(UI)可以选择用于播放的内容，从而发起认证请求。在602处，客户端和服务器可以向彼此通告其对于前面所描述的TLS补充数据消息传送扩展的相互支持，这是通过为此目的交换消息而实现的。

在604处，服务器可以发送补充数据消息，其可以是DTCP签名的并且可以包括随机数(不重数1)、服务器的DTCP证书(可以假定其存在，但是其是可选的)、服务器的公钥(其可以通过发送服务器的所谓的X.509证书来发送，所述X.509证书在DTCP证书被使用的情况下可以是自我签名的)。

在606处，客户端利用服务器的DTCP证书的公钥确认(确证)服务器的签名。通过这种方式，客户端知道其正在与真实的服务器通信。此外，如果期望的话，在608处服务器向客户端发送TLS消息，其包括DTCP证书、会话密钥交换(SKE)字段、证书请求(CR)以及“serverhello done(服务器打招呼完成)”(SHD)指示。

在610处，仅仅表明客户端是否未能认证服务器，可以在客户端的显示器上呈现表达该意思的出错消息。在612处，表明已经确定服务器的DTCP验证已成功通过。

在614处，客户端向服务器发送通过客户端的DTCP签名所签名的补充数据消息。补充数据消息包括在604处发送的原始随机数(不重数1)、客户端的DTCP证书(具有所设定的一致性比特和/或图3中的字段300的牌子/型号)、设备制造商ID、设备型号以及所期望的其他数据。在615处，服务器利用在614处发送的数据验证客户端DTCP证书没有被废止，客户端DTCP证书包含“一致性比特”(并且如果使用的话还有制造商/型号)，并且制造商/型号处在准许列表中。所述签名确证客户端的DTCP证书的公钥。如前所述，对于认证所使用的DTCP证书也是被用于链接保护的相同的DTCP证书。为了防止中间人攻击，在616处在客户端与服务器之间建立TLS隧道，并且随后在618-629处在TLS隧道内重复前面描述的序列(使用不同的不重数，也就是使用“不重数2”以取代“不重数1”)，在630处在客户端上表明认证成功。

在图7和8中示出了另外的方面。在图7中的方块700处开始，网关向信宿提供前面描述的被许可设备的准许列表。在方块702处，信宿接收来自第三设备的针对内容的请求。所述请求可以包含制造商ID、型号和设备ID以及一项或多项设备属性。在判定菱形704处，利用制造商ID与型号和/或设备ID相组合，信宿访问准许列表以便确定第三设备是否处在列表上。如果不是的话，所述逻辑可以继续到图8。

但是如果第三设备处在准许列表上，则所述逻辑可以移动到判定菱形706，以便确定在方块702处接收到的一项或多项设备属性是否匹配由准许列表或其他相关联的数据结构中的用于该设备的条目所表明的该设备的一条或多条对应的预期标准。在一种实现方式中，当使用多项设备属性时，为了返回肯定的测试结果并且在方块708处向第三设备提供对于信宿上的内容的访问，所有设备属性都必须与对应的预期标准相匹配。在另一种实现方式中，当使用多项设备属性时，为了返回肯定的测试结果并且在方块708处向第三设备提供对于信宿上的内容的访问，少于所有的设备属性必须与对应的预期标准相匹配。

在不作限制的情况下，所述预期标准可以被选择成以下各项当中的一项或多项：软件版本号(例如正由第三设备使用的HDCP版本)，距离上一次软件更新的时间，HDCP协议的最低版本，DRM协议的最低版本，DTCP协议的最低版本，包括安全执行环境，包括存储能力，最低鲁棒性水平，最低硬件鲁棒性水平，制造商，型号，下游连接设备的最大数目。

如果在判定菱形706处设备属性不匹配与设备相关联的相关预期标准，则所述逻辑可以移动到方块710。在方块710处，信宿可以命令第三设备在第三设备上呈现UI，从而提示用户采取适当的动作。举例来说，如果所述设备属性是不匹配如在准许列表中表明的用于设备的预期HDCP版本(例如HDCP 2.2)的HDCP的软件版本(例如HDCP 1.0)，则所述提示可以是升级第三设备的软件并且因此是HDCP版本。或者，在方块710处，信宿可以使得将更新后的软件版本自动推送到第三设备。应当提到的是，图7和8的逻辑可以被网关采用来确证信宿，其中网关在图7和8中扮演“信宿”的角色，并且信宿在图7和8中扮演“第三设备”的角色。

在图8的示例性实现方式中，给出了一种用于动态地更新准许列表的算法，从而使得图2的网格网络通过把经过适当地审查的设备添加到准许列表而自愈。在判定菱形800处开始，信宿确定第三设备是否来自受信任的源，例如第三设备是否由已知是受信任的制造商制造。这一确定可以基于把在图7中的方块702处接收到的制造商ID或其他信息与受信任来源的列表进行比较而作出。如果设备不是来自受信任的来源，则所述逻辑可以在状态802处结束，但是如果设备是来自受信任的来源，则所述逻辑可以继续到方块804以便从设备收集信息，例如其设备ID、型号和设备属性。

继续到方块806，信宿把在方块804处收集的设备信息作为新的条目添加到准许列表。在方块808处，向上游推送准许列表，在所示出的实例中是推送到网关，该网关又可以把更新后的准许列表推送到因特网以用于散播到其他网关。在方块810处，可以在信宿处接收来自上游(也就是来自网关)的更新后的准许列表版本，其是由网关从处在网关上游的准许列表来源接收到的。

如果例如游戏控制台之类的第三设备同时支持用于传统电视的HDCP 1.0和用于新型电视的新的HDCP 2.0，则在游戏控制台中可以使得永久禁用分布式准许列表或者通过其他方式关闭HDCP 1.0，或者仅仅对于特定内容这样做。在任何情况下，具有最新的或者最近的准许列表的设备都把准许列表分发到其他设备。

前面的方法可以被实施成软件指令，所述软件指令由处理器、适当地配置的专用集成电路(ASIC)或现场可编程门阵列(FPGA)模块或者通过本领域技术人员将认识到的任何其他便利的方式来执行。在被采用的情况下，软件指令可以被具体实现在例如CD Rom或闪存驱动器之类的非瞬时性设备中。软件代码指令可以替换地被具体实现在例如无线电或光学信号之类的瞬时性设置中，或者通过互联网下载。

应当认识到，虽然前面参照一些示例性实施例描述了本发明的原理，但是这些示例性实施例不意图作出限制，并且可以使用多种替换设置来实施这里所要求保护的主题内容。