在RE和TE间执行平台完整性和DRM软件完整性检查的方法

摘要

公开了一种在请求实体RE和目标实体TE之间执行平台完整性检查的方法和一种在RE和TE之间执行数字版权管理DRM软件完整性检查的方法，执行平台完整性检查的方法包括以下由RE执行的步骤：（a）请求TE报告TE的可信证书和TE自身的平台完整性状态；（b）接收TE的可信证书和关于TE的平台完整性状态的信息；（c）将TE的可信证书和关于TE的平台完整性状态的信息转发到应答器以用于完整性验证；（d）接收来自应答器的TE的可信证书和TE的平台完整性状态的完整性验证的指示；及（e）基于来自应答器的TE的可信证书和TE的平台完整性状态的完整性验证的指示，确定是否给予TE充分信任，以开始关于TE的注册协议或关于TE的使设备能够获取受保护内容的另一协议。

说明书

本申请是申请日为2007年5月4日、申请号为200780016271.4、名称 为“使用可信处理技术的数字版权管理”的发明专利申请的分案申请。

技术领域

本发明通常涉及在无线通信网络中的数字版权管理（DRM）方法。更 具体地，本发明提供了用于提高根据开放移动联盟（OMA）DRM规范运行 的系统中的安全性、完整性与可信性的方法。

背景技术

所述OMA DRM是由OMA规定的一种DRM系统，OMA是移动电话 与设备制造商和移动业务供应商的协会。该方案在许多移动电话上实现，以 及由移动内容供应商使用于把DRM增加到他们的产品和业务中。已经发行 了OMA DRM的两个版本：OMA DRM1.0和OMA DRM2.0。

OMA DRM1.0解决方案用于对内容对象的数字版权的基本管理。因而， 其不提供对内容对象或者版权对象的有力保护。OMA DRM1.0规定了传递 的三种方法：转发锁定（其防止用户从将内容转发到其它用户或装置）、组 合传递（组合的版权对象与媒体对象）以及单独传递（单独的版权对象与媒 体对象）。OMA DRM1.0被设计成能处理诸如用于电话的铃音或者壁纸 （wallpapers）的小型媒体对象。

OMA DRM2.0改进并扩展了所述OMA DRM1.0传递机制。适应于 OMA DRM2.0的设备具有基于DRM公钥基础结构（PKI）的单独的证书， 即，每个设备具有公钥、相应的私钥与验证这个事实的证书。每个版权对象 （RO）被保护以用于机密性（通过加密）与完整性（通过数字签名）。与所 述OMA DRM1.0系统的安全性相比，利用PKI、加密与完整性检查增强了 OMADRM2.0系统的安全性。

OMA DRM2.0还规定了一组协议，共同称作版权对象获取协议 （ROAP），包括不同的子协议，其关于在设备与版权发行方（RI）之间的相 互验证和注册、请求RO、对RO的传递应答或者拒绝传递方RO以及加入 并离开设备的域。

以下是在OMA DRM中定义的一些主要实体：

参与者——参与者是执行使用事件的外部实体。

备份/远程存储器——将RO与内容对象（CO）转移到另一位置，以打 算把它们转移回原始设备。

组合传递——用于传递受保护内容与RO的OMA DRM1.0方法。所述 RO与受保护内容是在一个实体也就是DRM消息中被一起传递的。

机密性——信息不可利用或者对未授权的个人、实体或者处理公开的属 性。

合成对象——通过包含的方式而包含一个或多个媒体对象的CO。

连接设备——能够使用合适的协议通过合适的广域传输/网络层接口而 直接连接到RI的设备。

内容——一个或多个媒体对象。

内容发行方（CI）——制作对DRM代理可用的内容的实体。

内容供应商——为CI或RI的实体。

设备——具有DRM代理的用户设备。其可以是连接设备，或者是未连 接设备，但是这种区别取决于上下文并且本质上是可变的，因为连接设备在 其失去直接连接到RI的能力时可以变为未连接设备。

设备撤销——指示一设备对于获取RO来说不再是可信赖的RI的处理。

设备RO——借助于设备的公钥的方式而专用于特定设备的RO。

域——一组设备，其能够共享域RO。在域中的设备共享域密钥。域是 由RI定义并管理的。

域标识符——域密钥的唯一串标识符。

域密钥——128比特对称加密密钥。

DRM代理——在设备中管理对在该设备上的媒体对象的许可的实体。

DRM内容——根据RO中的一组许可而消费的媒体对象。

DRM时间——安全的、非用户可变的时间源。所述DRM时间是UTC 时间格式。

完整性——数据没有以未授权的方式改变或者毁坏的属性。

加入域——在域中包括一设备的RI的处理。

离开（去加入）域——从域中除去一非撤消的设备的RI的处理。

媒体对象——数字作品或者合成对象。

网络服务供应商——对移动设备提供网络连接的实体。

许可——由RI通过DRM内容允许的实际的使用或动作。

播放——创建资源的短暂的、可见的再现。

受保护内容——根据RO中的一组许可而消费的媒体对象。

恢复——将受保护内容和/或RO从外部位置转移回到其曾被备份的设 备。

撤消——宣布设备或者RI证书无效的处理。

版权发行方（RI）——将RO发行到OMA DRM一致性设备的实体。

RI上下文——在四传（4-pass）注册协议期间与给定的RI协商的信息， 诸如RI ID、RI证书链、版本、算法和其它信息。除注册协议之外，RI上下 文是设备成功参与所述ROAP组的所有协议所必需的。

版权对象（RO）——链接到受保护内容的许可和其它属性的集合。

版权对象获取协议（ROAP）——使设备能够从RI请求并获取RO的协 议。

ROAP触发——可扩展标注语言（XML）文档，包括当被设备接收时启 动所述ROAP的URL。

无状态版权——所述设备不必对其保护状态信息的RO。

有状态版权——所述设备必须对其明确保护状态信息的RO，以便可以 正确地加强在RO中表示出的限制条件和许可。包含以下限制条件或者许可 之一的RO被认为是有状态版权：<interval>、<count>、<timed-count>、 <datetime>、<accumulated>或<export>。

超分配——一种机制，（1）允许用户把受保护内容通过潜在地非保密信 道分配到其它设备，和（2）对于超分配的受保护内容，使该设备的用户去 获得RO。

未连接设备——能够经由连接设备使用合适的协议通过本地连接技术 例如通过IrDA的OBEX（通过红外的对象交换）、蓝牙或通用串行总线（USB） 连接到RI的设备。未连接设备可以支持DRM时间。

用户——设备的人类用户。用户不必拥有该设备。

图1是现有OMADRM2.0功能结构100的概述。该结构100包括DRM 系统102、内容供应商104和用户106。DRM系统102包括CI110、RI112、 DRM代理114、网络存储器116和可移动媒质118。CI110分配受保护内容 122，RI112分配RO124。DRM代理114重新分配受保护内容122。

所述CI110是传递DRM内容122的实体。所述OMA DRM定义要传 送到DRM代理114的DRM内容122的格式以及所述DRM内容122使用不 同的传送机制从CI110传递到DRM代理114的方式。CI110可以自己执行 所述DRM内容122的实际封装，或者其可以从其它的信源接收预封装的内 容。

所述RI112是对DRM内容122分配许可和限制条件、以及产生RO124 的实体。RO124是表达与DRM内容122相关的许可与限制条件的XML文 档。RO124管理如何可以使用DRM内容122；缺少相关的RO124是不能 使用所述DRM内容122的，仅仅可以按照与RO124相关的RO所规定的 而使用RO124。DRM内容可以相关于一个以上的RO，例如如果RO具有 时间期限（例如10天），以及在时间期限之后，新的RO将需要访问内容。

DRM代理114是负责管理DRM内容122的消费实施的逻辑实体。DRM 代理114具体化为设备的可信部件，并且其负责对设备上的DRM内容122 增强许可和约束条件、控制对设备上的DRM内容的访问（仅仅可以通过 DRM代理114来访问）等等。

封装所述DRM内容122以防止其在被传递之前被未授权的访问。所述 CI110传递DRM内容122，并且RI112产生RO124。在所述系统102中， CI110与RI112具体化逻辑任务，而不是物理实体。例如，在一个应用中， 内容拥有者可以预封装DRM内容，其然后由作为CI与RI二者的内容分配 者来分配。

RO124管理如何可以使用DRM内容122。缺少相关的RO124是不能 使用DRM内容122的，并且仅仅根据在RO124中规定的许可与限制条件 而使用DRM内容122。OMA DRM进行将DRM内容从RO的逻辑分离。可 以分别地或一起请求DRM内容与RO，并且可以分别地或者同时传送它们。 在DRM内容与RO被同时传递时，它们典型地都是由CI110提供，以RO 与内容嵌入在DRM内容格式（DCF）的形式。

RO124是由一组密钥密码地（cryptographically）绑定到特定的DRM代 理114的，因此仅仅特定的DRM代理114可以访问RO124。DRM内容122 只能利用有效的RO124被访问，因此可以自由地分配或者超分配所述内容 122。

OMA DRM2.0允许一个RO绑定到一组DRM代理。这种组被称作域。 分配到域的DRM内容和RO可以由属于该域的所有DRM代理共享并访问。 例如，用户可以购买DRM内容以在她的电话和她的PDA上使用。

OMADRM规范定义了DRM内容（或者DCF）的格式与保护机制、RO 的格式（版权表达语言（REL））与保护机制以及加密密钥的管理的安全模 型。OMA DRM规范还定义了如何使用传送机制的范围把DRM内容与RO 传送到设备，传送机制包括拉出（pull）（HTTP拉出、OMA下载）、推入（push） （WAP推入、MMS）以及流动。然而，OMA DRM规范不能解决在网络实 体之间的任何交互，例如在CI110与RI112之间。

以下是由OMA DRM2.0规范覆盖的使用情况的非详尽列表。

1．基本拉出模型

用户通过浏览到网站来选择内容以下载，并且确认购买的项。所述CI 110标识并保护内容122，即对其进行封装。内容122是使用内容加密密钥 （CEK）加密的。该设备能力可以使用通告的MIME类型支持等来检测。 RI112产生对于内容122的RO124和目标DRM代理114。RO124包括对 于内容事务的许可和CEK。最后，RO124是通过加密（使用RO加密密钥 或REK）和数字签名而密码地保护的，以及仅仅被绑定到目标DRM代理114。 所述DRM内容122和受保护的RO124然后被传递到DRM代理114。

2．DRM内容的推入

可替换的分配模型是在没有预先发现处理之前，使用多媒体消息业务 （MMS）、WAP推入或者类似方法把所述内容直接地推入到设备。在这种使 用情形中有两个变化。

2A．内容推入

CI110和/或RI112可以具有对用户和特定的DRM代理114的某些先验 知识，这样所述内容122和RO124可以被格式化和封装，以用于传递。

2B．推入启动的拉出

在这种情况下，CI110和/或RI112可以没有关于用户或者他们的DRM 代理114的先验知识，但是仍然可以希望传送内容，例如，允许用户预览内 容122，以吸引他们购买所述内容。代替将DRM内容122直接地推进到用 户，可以发送链接到到所述内容的链路或者链接到所述内容的预览的链路。 之后，所述链路将带用户到特定的位置，然后这个过程以基本拉出模型的方 式继续。

3．DRM内容的流动

基本的拉出和推入使用情况二者都假定全面封装和传送所述内容。可替 换地，所述内容可以作为数据流而被打包并传送。在这种情况下，该数据流 本身是受保护的（加密的）。所述加密的确切格式已经不在OMA DRM的范 围中，但可以从现有加密标准中选择的。所述数据流可以是用不同于由OMA 对于下载所规定的加密方案的加密方案所保护的，以解决可能的数据包丢失 等等。在加密所述数据流之后，可以通过先前描述的用于分离内容的相同过 程来控制所述数据流。产生RO，所述数据流加密密钥就像CEK一样被放入 到RO中，然后所述RO被密码地绑定到DRM代理。

4．域

域是可选特征，并且不可以由所有RI支持。域扩展所述OMA DRM2.0 的基本模型，其中RO和CEK被绑定到特定的DRM代理114，以及允许RI 112把版权和CEK绑定到一组DRM代理，而不是仅仅一个单个的DRM代 理。用户然后可以共享在属于相同域的所有DRM代理之间脱机的DRM内 容122。RI112可以使用所述域概念来提供新服务，诸如使用户能从他们拥 有的若干设备访问DRM内容122，或者对未连接设备提供支持，其中用户 经由一个设备（例如PC）购买DRM内容和版权，用于稍后在另一个设备（例 如便携式播放器）上使用。

5．备份

DRM内容122可以被存储在可移动媒质118上、在网络存储器116中、 或者在一些其它形式的存储器中。所述DRM内容122是以加密形式存储的， 并且仅仅只能由特定的目标DRM代理114使用相关的RO124来访问。如 果RO仅仅包含无状态许可，RO124可以为了备份目的而存储。安全模型保 证所述RO124是受保护的，并且只能由预定的DRM代理114访问，即使 所述RO124是离开设备而存储的。某些许可需要由DRM代理114的状态 维护，例如有限次数的播放。这样的RO不能离开设备而存储，这是因为这 可能导致状态信息的丢失。

6．超分配

DRM内容122可以被复制并且传送到其它DRM代理114，例如用户发 送DRM内容122到朋友。为了访问所述内容122，该朋友经由在DRM内 容封装中的链接被带到RI112以获取RO124。

7．出口（到非OMA DRM系统）

DRM内容122可以被输出到其它DRM系统，用于在不兼容OMADRM 但是支持某些其它的DRM机制的设备上使用。如果希望，所述OMA DRM 结构允许RI112表示对于DRM代理114的许可，以执行到特定的其它DRM 系统的转换，可能是由其它DRM系统规定的。所述RI112可以限制所述输 出仅仅到特定的外部DRM系统。

8．未连接设备的支持

OMA DRM使得连接设备能够作为中介，以帮助未连接设备去购买并下 载内容122与RO124。例如，用户可以具有无网络连接性的兼容OMA DRM 的便携式设备（未连接设备）、具有网络连接性的兼容OMA DRM的移动设 备（连接设备）。在使用连接设备来浏览并购买DRM内容122、以及下载 DRM内容122到连接设备之后，用户可能希望在未连接设备上播放所述 DRM内容122。在这种情况下，在连接设备上的DRM代理114从RI112 请求并下载域RO124。在连接设备上的DRM代理114然后在DCF中嵌入 域RO124。然后可以使用合适的协议通过本地连接技术例如蓝牙或USB将 DCF传送到未连接设备。连接设备与未连接设备二者必须是兼容OMA DRM 以支持这个功能。未连接设备也必须属于与连接设备相同的域。

安全性与信任

以下是OMA DRM2.0安全性与信任测量的概述。通常，任一DRM解 决办法需要满足两个安全性要求：（1）受保护内容必须仅仅由正确认证并授 权的DRM代理来访问；以及（2）对受保护内容的许可必须是由所有DRM 代理认可。与DRM内容相关的许可与限制条件的实施是任何DRM方案的 安全性与信任测量的主要问题。对DRM内容的未授权访问超出了由相关的 RO规定的内容，以及DRM内容的非法备份与重新分配组成了任何DRM系 统的主要问题。

所述OMA DRM系统提供了用于在OMA环境中受保护内容的安全分配 与管理的装置，并满足了上面规定的要求。OMA DRM通过使用DRM代理 来执行内容与RO在消费时的使用与保护，DRM代理依靠所述RO的限制 条件确保内容的受保护使用。

用于分配DRM内容的基本步骤可以概述如下：

1．内容封装。内容被封装在安全内容贮存器（DCF）中。DRM内容被 利用对称内容加密密钥（CEK）加密。所述内容可以是预封装的，即内容封 装不必即时地发生。对于一个内容的所有情况不使用相同的CEK，尽管这在 OMADRM中是不要求的。

2．DRM代理认证。所有DRM代理具有唯一的私/公钥对与证书。所述 证书包括诸如设备制造商、设备类型、软件版本、序列号等等的附加信息。 这允许CI与RI安全认证DRM代理。

3．RO生成。所述RO包含CEK，CEK保证缺少相关的RO是不能使 用DRM内容。RO由许可（例如播放、显示与执行）与限制条件（例如播 放持续一个月、显示十次）组成。RO还可以包括限制条件，其在内容被访 问时需要特定用户在场（例如由用户身份确定的）。这些许可与限制条件与 其它信息（例如版权信息）一起具体化在RO中，可以呈现在用户面前。

4．RO保护。在传送RO之前，所述RO的灵敏部分（诸如CEK）是用 版权加密密钥（REK）加密的，并且所述RO然后被密码地绑定到目标DRM 代理。这保证了仅仅目标DRM代理可以访问所述RO、所述CEK和所述 DRM内容。另外，RI数字地签名所述RO。RO还通过包含CEK来管理对 DRM内容的访问。OMADRM版权表达语言（REL）规定了管理DRM内容 的使用的语法（XML）与许可与限制条件的语义。RO具有其自己的MIME 内容类型。

5．传递。RO与DCF现在可以被传递到目标DRM代理。由于两个项 是内在安全，所以可以使用任何传送机制（例如HTTP/WSP、WAP推入、 MMS）传送它们。RO与DCF可以被一起传递，例如在MIME多部分消息 中，或者可以被单独地传递。

对于RO的OMA DRM可信模型是基于公钥基础结构（PKI），借此存 在多组负责人、证明人和由二者识别并信任的一个或多个认证权威。单个实 体可以依据所选择的环境与解决办法的需要来充当负责人和证明人。PKI在 证明人和负责人通过开放、不安全网络通信时使得证明人以认证负责人的身 份与其它属性。在这种系统中，典型地，为了认证的目的，证明人不必保持 关于与其交互的负责人的任何敏感信息。另外，鉴定权威（CA）不直接地 包含在负责人与证明人之间的事务中。如果DRM代理的证书是由RI认证的 并且还没有被撤消，那么RI信任DRM代理，以使得正确地运转。类似地， 如果RI的证书是由DRM代理认证的并且还没有被撤消，那么DRM代理信 任RI，以使得正确地运转。

应用于OMA DRM的PKI的主要实体是CA、设备以及RI。OMA DRM 的认证与密钥传送协议需要所述RI能够认证所述设备，并且所述设备能够 认证所述RI。这种相互验证是由所述ROAP实现的。

另外，假定设备被提供（在制造时或者之后）有具有设备公钥与私钥以 及由适当的CA签名的相关证书。根据由所述RI表示的证书首选项，所述 设备必须提供合适的证书。要求设备在具有完整性与保密性保护的本地存储 器中存储私钥。

RI还具有公钥、私钥与由CA签名的证书。所述证书链（一系列的多个 证书，包括由一个CA签名的公钥拥有者的证书，以及由其它CA签名的零 个或者多个附加的CA证书）在用于对可信的证书链验证的认证协议时出现 在所述设备面前。

要注意到在所述DRM系统中可以存在多个CA。所述ROAP协议要求 签名RI证书的CA运行在线认证状态协议（OCSP）应答器，用于在所述协 议的执行期间使用。所述CA还要求定义合适的证书策略以管理所发行的证 书的使用。

以下描述OMADRM安全性的主要方面。

1．机密性，其保证数据对未授权方是不可访问的。如上所述，受保护 内容仅仅是由正确认证并授权的DRM代理访问。为了实现这个目的，加密 受保护内容。加密密钥对每个媒体对象是唯一的，并且RO携带隐藏在密钥 中的仅仅由预期的接收方访问的加密密钥。

2．认证，其是用于一方向另一方标识自己的方法。在OMADRM中， 以四传注册协议、二传（2-pass）RO获取协议与二传加入（join）域协议来 实现相互的DRM代理与RI认证。依据使用的协议与发送的消息，通过或者 在当时、或者在时间戳上的数字签名来实现认证。一传（1-pass）RO获取协 议通过在时间戳上的数字签名实现RI认证。其不对所述RI认证DRM代理， 但是由于受保护内容是用接收方公钥隐藏的，可以通过密钥绑定来间接地执 行认证。二传离开域协议通过在时间戳上的数字签名对RI认证DRM代理。 其不对DRM代理认证RI。要求RI在RO的传递期间对DRM代理自行认证。 这提供了关于所述RI真实性的一些保证等级。

3．数据完整性保护确保用于检测对数据未授权的修改的能力。在OMA  DRM中，在适当的时候，数据完整性保护是通过在ROAP消息和RO上数 字签名来实现的。

4．密钥确认确保包含受保护密钥的消息的接收方，所述密钥值是消息 发送方知道的。在所述DRM环境中，这个属性防止由一个RI被另一个RI 对RO的未授权的再发行。在OMA DRM系统中，密钥确认是由经受保护密 钥的媒体接入控制（MAC）和通过使用受保护密钥的一部分作为MAC密钥 的发送方身份而实现的。

根据正确的性能与安全的实现二者，DRM代理必须被RI所信任的。在 OMA DRM中，每个DRM代理是用唯一的密钥对与关联的证书所提供的， 以标识所述DRM代理并证明在所述代理与这个密钥对之间的绑定。这允许 RI使用标准PKI过程安全地认证DRM代理。

在所述证书中的信息使RI能够根据其商业规则、其内容的值等应用策 略。例如，RI可以信任某些制造商，或者其可以保持DRM代理的更新列表， 该列表根据由RI定义的一些标准知道可信任或不可信任。

所述DRM内容格式（DCF）是对于加密内容的以其自己的MIME内容 类型的安全内容封装。除加密内容之外，其包含附加信息，诸如内容说明（原 始内容类型、厂家、版本等等）、RI统一的资源标识符（URI）（可以获得 RO的位置）等等。这个附加信息是不加密的，并且可以在检索到RO之前 出现在用户面前。解锁在DCF内部的DRM内容需要的CEK被包含在所述 RO内。由此，缺少RO不可能访问DRM内容，并且DRM内容只能以在所 述RO中规定的形式而使用。OMA DRM包括允许DRM代理去验证DCF的 完整性、防止由未授权实体对所述内容的修改的机制。

OMA DRM系统假定DRM时间在所述DRM代理中出现。由于用户不 能改变所述DRM时间，其定义了一个机制，所述DRM时间可以与由OCSP 应答器保持的时间同步。一些限制条件（例如绝对时间限制条件），以及RO 的传递协议的一些方面，依赖于具有安全时间源的DRM代理。在OMADRM 规范的上下文中的DRM时间意味着不可由用户改变的精确时间以及时间 值。在需要时，例如如果在长时间的电源故障之后丢失DRM时间，OMA DRM规范提供用于同时发生电源故障DRM时间的机制。一些能力受限的 未连接设备可以不支持实时时钟，由此可以不支持DRM时间。然而，连接 设备必须支持DRM时间。

OMA DRM防止RO重放保护攻击。RO重放攻击的例子是其中中间物 截取RO在对DRM代理的传递期间的有限次数的播放。当在所述DRM代 理上的版权期满时，可以再次从中间物传送（重放）所截取的RO。OMA DRM 防止这种以及类似的攻击发生。

OMA DRM系统通过使用上面列出的安全性机制提供应用程序层安全 性。因此，其不依赖或假定传输层安全性。

ROAP在OMA DRM2.0中的允许安全、基于认证的关于RO的信息的 交换方面处于中心地位。ROAP是在RI与设备中的DRM代理之间的一组 DRM安全性协议的通用名称。该协议组包含若干子协议：

1．用于利用RI注册设备的四传协议，如图2所示。

2．包含对RO的请求和传递的二传RO获取协议，如图3所示。

3．涉及RO从RI到设备的传递（例如发消息/推入）的一传RO获取协 议，如图4所示。

4．用于设备加入域的二传加入域协议，如图5所示。

5．用于设备离开域的二传离开域协议，如图6所示。

图2是四传注册协议200的流程图。所述协议200利用设备202、RI204 与OCSP应答器206。所述设备202通过发送设备问候消息（Device Hello  message）来启动（可能在接收ROAP触发后）与RI204的联系（步骤210）， 设备问候消息包含诸如设备ID（RI204可以稍后检查OCSP应答器206的 设备证书的散列）以及其它信息的信息。表1示出了在设备问候消息中的主 要组成。在设备问候消息中的信息都没有被完整性保护的，即，对于该消息 没有签名。

表1.设备问候消息的格式

响应于设备问候消息（步骤210），RI204发送RI问候消息到设备202 （步骤212），其包含诸如RI的证书凭证（以RI ID的形式）、一些会话相关 的（应答目的）现时与会话数量的信息，以及诸如有关RI204可识别的设备 的信任链的信息的其它可选信息。表2示出了RI问候消息的格式。注意到 在RI问候消息中的信息都没有被完整性保护。

表2.RI问候消息的格式

在包含在RI问候消息的信息的成功验证下，所述设备202发送注册请 求消息（步骤214），该注册请求消息包括强制信息，诸如请求时间、会话 ID以及签名和诸如证书链、可信RI授权锚点、扩展等的可选信息。表3示 出了注册请求消息的格式。所述注册请求消息在其结尾包含了在设备202和 RI204之间交换且直至在注册请求消息中的签名字段的所有消息的数字签 名，即整个设备问候消息、整个RI问候消息以及直至（并排除）签名字段 的注册请求消息的字段。这个数字签名是使用设备的私钥形成的。包括数字 签名提供对关联的ROAP消息的一些完整性保护。

表3.注册请求消息的格式

除非设备202经由在扩展中的信息指示：不需要或者不支持OCSP验证， 否则RI204发送OCSP请求消息到所述OCSP应答器206（步骤216），以请 求对由设备202提供给RI204的信息的验证。所述OCSP应答器206在请求 消息中查找信息以试图验证所述信息，并返回包含请求结果的OCSP应答消 息（步骤218）。

RI204发送注册应答消息到设备202（步骤220），该消息包含对注册是 成功还是不成功的指示和其它信息。表4示出了注册应答消息的格式。所述 注册应答消息在其结尾包含注册请求消息和注册应答消息的SHA-1散列（直 到以及排除所述签名域）。这个数字签名是使用RI的私钥形成的。包括数字 签名可提供对关联的ROAP消息的一些完整性保护。注意到在所述SHA-1 散列被用于数字签名时，可以使用用于应用数字签名的任何适当的算法。

表4.注册应答消息的格式

图3是二传RO获取协议300的流程图。该协议300使用设备202和 RI204，并且在已经完成四传注册协议200以及设备202已经接收关于所述 RI204的有效证书链之后进行操作。协议300是由设备202使用以从所述 RI204请求RO。设备202发送RO请求消息到RI204，以请求RO（步骤 310）。表5示出了RO请求消息的格式。RO请求消息包含对消息的数字签 名（排除签名域）。

表5.RO请求消息的格式

响应于请求消息，RI204发送RO应答消息到设备202（步骤312）。RO 应答消息包括RO或者包括不发送RO的指示。

表6示出RO应答消息的格式。在成功的状态范例中，RO应答消息包 含数字签名，也就是除签名字段外的RO请求消息和RO应答消息的SHA-1 散列。

表6.RO应答消息的格式

图4是一传RO获取协议400的流程图。所述协议400利用设备202与 RI204。在协议400中，缺少设备202的请求，RI204单方面地发送包含RO 的RO应答消息到设备202（步骤410）。例如，协议400应用于推入使用的 范例。表7示出了RO应答消息的格式。

表7.RO应答消息的格式

图5是二传RO加入域协议500的流程图。所述协议500利用设备202 与RI204。当设备202想要加入域时，设备202发送加入域请求消息到RI204 （步骤510）。RI204估计该请求并发送加入域应答消息到设备202（步骤 512）。表8示出了加入域请求消息的格式，表9示出了加入域应答消息的格 式。

表8.加入域请求消息的格式

表9.加入域应答消息的格式

图6是二传RO离开域协议600的流程图。所述协议600利用设备202 和RI204。当设备202想要离开域时，设备202发送离开域请求消息到RI204 （步骤610）。RI204估计所述请求，并发送离开域应答消息到设备202（步 骤612）。表10示出了离开域请求消息的格式，而表11示出了离开域应答消 息的格式。

表10离开域请求消息的格式

表11.离开域应答消息的格式

除一传RO获取协议之外，可以使用ROAP触发启动包括在所述ROAP 组中的所有协议。作为用户交互的结果，设备202还可以单方面地启动协议。 RI204也可以产生并发送ROAP触发到设备202，以触发ROAP协议交换。 可替换地，RI204可以通过提供必要的信息（诸如RO标识符和域标识符） 来授权对这些系统的ROAP触发产生。ROAP触发（不论由RI204直接地 或者间接地产生）还可以由其它系统（例如由CI）发送到设备202。

当设备202接收ROAP触发时，其尽快启动ROAP协议交换。作为接 收ROAP触发的结果，必须已经在启动任何ROAP协议前获得合适的用户 允许。由于所述ROAP包括几个协议，ROAP触发包括待由设备202开始的 实际协议（例如注册、RO获取、加入域或者离开域）的指示。

ROAP消息以及如何由所述协议处理所述消息，不仅提供所述RO和它 们的相关处理，而且还提供围绕在OMA DRM2.0中的RO的安全性功能。 更具体地，由ROAP协议解决以下安全性与信任方面：

1．在所述RI与所述设备之间的相互验证；

2．通过使用在多个消息中的现时来计数重放攻击；

3．保护所述ROAP消息或者部分所述ROAP消息的完整性；以及

4．在ROAP消息或者部分ROAP消息中的安全DRM时间的验证。

可信计算技术

近来，可信计算技术已经出现在文学与产品中，主要是在可信计算组 （TCG）的技术伞下。所述TCG技术提供了方法，借此计算实体可以通过 信任链的使用而为自己并为其它设备建立可信度，这样在这种设备上的处理 或计算可以为：

1．对平台与多个硬件（HW）以及软件（SW）组件的可信度被评定；

2．只有当建立合适的信任等级时有效，并且可以基于外界请求对本身 以及对于其它设备有效；和

3．外部方可以执行对信息交换的评定与判定，用其它设备处理，以及 基于这种目标设备的明显的信任等级。

所述TCG定义核心处理模块，称作可信处理模块（TPM），其具有以下 特征：

1．对模块及其接口进行物理保护；

2．受保护的易失与非易失性存储空间；

3．在模块内部的受保护的加密函数，其可以执行加密与数字签名；

4．平台配置寄存器（PCR）的使用，PCR通过散烈扩展连续地获得平 台及其SW组分的“状态（state）”；

5．设备指定与安全认可密钥（EK）的存在，根据充当所述设备的认证 根但不是以直接方式的PKI。所述EK从不暴露在外，但是其别名称作认证 身份密钥（AIK），被用来标记平台的完整性测量值；和

6．使用在存储器“二进制大对象（blobs）”中的数据“隐藏”连同由 AIK签字的PCR值，以便只有当验证平台或者SW完整性（由来自TPM和 来自密封的存储器blob的匹配PCR值测量和验证）时才可以访问或者提取 数据。

特别是在移动电话设备的环境中，对于在保护这种移动设备上的DRM 应用中的可能应用，检查可信计算技术。先前的方法通过利用包括在某些方 法中的TCG技术来保护所述DRM应用，所述的某些方法使用TPM密封的 过程，并且在所述TPM与具有密钥保护的存储区中，所述存储器二进制大 对象为在ROAP协议处理之后使用TCG密钥安全地存储涉及DRM的数据。

然而，现有技术既没有明确地解决也不没有顺序地解决如何在平台和/ 或DRM软件上建立和使用“信任”。现有技术也没解决特定的技术以保护 ROAP消息中的完整性，以增强在OMA DRM2.0系统中的完整性处理。本 发明包括用了这些目的的新技术。

当前的OMA DRM2.0规范根据涉及的CA、RI与所述设备的PKI提供 了有力的安全性方法。然而，存在具有与平台、SW、代理和消息的安全性 与完整性相关的易损坏性，这是在OMA DRM2.0规范本身和涉及设备与RI 的适应OMA DRM2.0的非规定的实现二者内。

所述OMA DRM规范已经应答了任何设备或者RI可能面对的各种恶兆 和易损坏性，即使它们是兼容OMA DRM2.0规范的。这些易损坏性包括：

1．实体损害，其中攻击者可以试图在物理上或其它方面损害DRM系 统的实体。实体损害攻击的类型包括对所述设备上的DRM代理的损害和对 所述RI中的DRM SW的损害。对实体损害的结果包括私钥、域密钥、RO 加密密钥、内容加密密钥和受保护内容的公开，与对DRM代理的重放高速 缓存的完整性保护的丢失一样，例如，和/或对内部存储在DRM代理中的保 护的损失。而且，还可能发生DRM时间的丢失。诸如参照IETF RFC3280 论述了对受损害的CA或者OCSP应答器的PKI的影响。

所述OMA DRM系统解除了证书撤销，以最小化由受损害的实体引起 的损害。DRM代理和RI必须总是通过检查实体的证书状态来验证与其通信 的实体没有受到损害。实体损害攻击可能发生在“前向”和“反向”路径二 者中。前向损害攻击是在所述DRM实体（RI、DRM代理、CI、CA或OCSP 应答器）上导致未授权的行为。反向损害攻击压制或者减弱DRM代理的安 全性、完整性设置以及配置。

2．消息消除，借此攻击者可以删除在DRM代理与RI之间发送的消息， 典型地引起拒绝服务（DoS）攻击。消息消除攻击可以包括：在注册协议或 者RO获取协议期间的消息消除、重放特定现时消除、对ROAP触发的消除 等等。

3．消息修改，借此攻击者可以修改在DRM代理与RI之间发送的任何 消息，典型地引起DoS攻击。消息修改攻击可以包括在注册协议期间、在加 入域与离开域协议期间以及各种ROAP触发的修改。

4．消息插入，借此攻击者可以在RI与DRM代理之间的任一点把消息 插入到通信信道中。攻击者还可以记录消息，并设法在稍后的时间点重放它 们。消息插入攻击可以包括在注册协议时、在二传与一传RO获取协议时以 及在各种ROAP触发时的消息插入。

5．其它攻击诸如普通DoS攻击，被动的攻击诸如业务分析与秘密公开。

确定对当前OMA DRM规范与实现的以下问题。定义了“完整性”的 扩展概念，如应用于所述OMA DRM方案。传统上意义上，OMA DRM规 范仅仅解决小范围的ROAP消息完整性。在本发明定义的完整性的扩展概念 中，注意到在下文中可以考虑何处以及何种类型的完整性。

1．DRM平台完整性。这涉及在平台实体上或者内部的完整性，即在包 括所述设备、RI与内容功能的物理实体。不同的实体包括操作系统（OS）、 引导码（例如在PC范例中的BIOS）、用于存储器存取的HW/固件（FW）/SW、 各种HW/FW/SW实体（其处理涉及安全性的功能（诸如密码学与密钥管理， 以及诸如策略、证书等的保密数据的特权存储）以及网络与本地连接性 HW/FW/SW。平台完整性是确定平台是否是有效、真实的、除了合理的处理 之外没有被修改并且仅如预期操作。

2．DRM SW完整性。DRM SW是指在所述设备、RI或者CI中驻留的 软件实体与组件，其执行对OMA DRM规范以及它们的过程所特定的功能。 在所述设备处，DRM代理由DRM SW组成。在RI与CI处，DRM SW合 起来指执行诸如RO封装、DCF格式化、内容加密、内容或者RO传递、验 证、ROAP处理等等的DRM特定的功能的SW组。如果DRM SW是有效、 真实、除了合理的处理之外没有被修改并且仅如预期操作，这样就保持DRM SW完整性。

3．ROAP消息和信息的完整性。如果信息是有效的、真实的并且除了 合理的处理之外没有被修改，这样就保持所述ROAP消息与其组成信息的完 整性。在OMADRM2.0规范中，通过利用数字签名完整保护了ROAP消息 与其组成信息的某些子集。

4．媒体对象和DRM内容的完整性。媒体对象与DRM内容也必须被完 整性保护的，即必须不能被修改、删除或者错误地插入，不论它们是存储在 所述设备、RI、或者CI、或者是在任何两方之间的传送或者传递中。特定的 兴趣是内容的通过空中（OTA）的传递，如适用于对移动设备的内容的传送， 其中所述DRM内容实质上是使用开放信道传送的。

5．有关DRM信息的完整性。必须安全地保护诸如实体ID（设备ID、 RI ID等等）、加密密钥（CEK、REK）以及签名密钥、RO自身、上下文信 息、证书以及有关其它信任链的信息的有关DRM信息，这意味着应该不仅 为了机密性而且还为了完整性而保护它们。

注意到当前OMA DRM2.0规范、现有技术都不具有对实体损害或者完 整性问题的提议的解决办法。解决办法的缺乏由于以下问题：即使根据OM A  DRM2.0规范正确地实现所有ROAP过程，例如设备如何能够真实地知道 RI的平台是否是可信？换句话说，所述设备如何能够知道RI的平台是否不 滥用所述设备以ROAP协议的一部分发送的数据或者滥用DRM处理本身？ 例如，所述设备不知道RI是否因为RI的平台SW受到损害而将任意且不正 确地限制设备的使用版权，以及其限制对所述设备的其他有效使用版权。类 似的问题在DRM软件的完整性的问题上也存在。更具体地，以下是从如上 所述的完整性扩展概念的角度看的当前OMA DRM2.0系统的一些问题。

1．缺乏对平台和DRM SW的完整性的检查和报告的方法。作为有关上 面标识的实体损害恶兆，在现有技术中没有方法用于明确并架构所述设备与 RI之间的平台完整性验证与SW代理完整性验证，不论是由OMA DRM2.0 规范所规定或者作为所述TCG1.2使用范例的一部分。对于平台完整性验证 这是特别真实的，而不是仅仅对DRM代理。

2．会有意地损害平台（诸如PC或者PDA，如与所述设备或服务器相 关的，如对于RI），其可以导致阻止正确地执行DRM代理与RI代理SW， 甚至阻止给定的受保护的正确与保密性和受完整性保护的信息。例如，另外 的较好保护的DRM代理SW可以用纯文本把一些信息在处理期间或者之后 存储在共享的存储器中。在此情况下，受损害的平台过份地访问共享存储器 并删除信息、改变信息或者插入新的假信息，然后这些信息可能随后由可以 感知这种假信息为真实的DRM代理SW处理。这可以导致DoS攻击、对保 密信息的非法泄密、或者未授权的传递、分配、或者DRM RO或DRM内容 的消耗。

3．是处理有关DRM的信息的SW部件的DRM代理SW和RI SW可 以由于种种理由而变为受损的。例如，这种SW可能由病毒或者其它恶意的 SW实体改变。在平台或DRM SW中的这种损害的一个结果将是对OMA  DRM2.0考虑的消息和信息的完整性的后续损害，尤其是对ROAP协议消 息。因为仅仅一些而不是所有的ROAP消息是受完整性保护的，它们理论上 可以在损害的设备与欺诈或受损的RI之间以同步的方式被处理。可以在设 备和RI二者上同时修改消息，并且消息仍旧展现成“完整性验证”，这是由 于以同样的方法修改所述消息。

4．ROAP消息的不充分完整性保护。由于涉及消息完整性，由多个消 息字段携带的ROAP消息和信息是易损坏的，也就是不由所述OMA DRM 2.0规范解决。例如，在OMA DRM2.0规范中现在规定的ROAP消息完整 性保护留下这样的漏洞，如：

4A．不是所有ROAP消息是受完整性保护的。在某些情况下，在所有 消息中包括数字签名不可以形成易损坏性。

4B．即使当ROAP消息或者信息的某些字段是由数字签名进行完整保 护的，一旦这种信息被解密、完整性检查，并且然后被以纯文本“使用”， 恶意的实体可以访问明文信息以及删除、改变或者重新分配先前的完整性检 查过的信息。由此，需要增强的完整性保护。

5．易损坏性涉及所述DRM内容与其传递的完整性。更具体地，存在 以下问题：

5A．内容完整性检查机制是没完成的。例如，当所述内容是在运送中或 者传递（例如OTA下载）中时，内容的完整性是未规定的。例如对于DCF 的签名仅仅产生用于ROAP过程。直到并在所述ROAP过程发生之前，当 存储在CI中时，没有管理内容完整性的完整性检查机制。

5B．内容加密、甚至是在ROAP协议中使用是强制的，但是完整性检 查仅仅是可选的。

5C．尤其对于用于流动业务的分组内容，PDCF格式具有时间问题。在 可以检查整个数据流的完整性之前，可以下载甚至可以消耗（即在媒体播放 器上播放）已被非法修改的数据包。

中心问题变为：多方（设备、RI与CI）如何可以确信平台完整性与DRM  SW完整性？由此，需要去增强并验证平台（例如OS、BIOS、驱动器、媒 体播放器、通信软件、共享存储器等等）的完整性的方法，基于其可以信任 DRM代理SW或者RI SW。本发明解决了现有技术的缺点。

发明内容

本发明公开了一种用于在请求实体RE和目标实体TE之间执行平台完 整性检查的方法，该方法包括以下由RE执行的步骤：（a）请求所述TE报 告所述TE的可信证书和所述TE自身的平台完整性状态；（b）接收所述TE 的可信证书和关于所述TE的平台完整性状态的信息；（c）将所述TE的可 信证书和关于所述TE的平台完整性状态的信息转发到应答器以用于完整性 验证；（d）接收来自所述应答器的所述TE的可信证书和所述TE的平台完 整性状态的完整性验证的指示；以及（e）基于来自所述应答器的所述TE的 可信证书和所述TE的平台完整性状态的完整性验证的指示，确定是否给予 所述TE充分信任，以开始关于所述TE的注册协议或关于所述TE的使设备 能够获取受保护内容的另一协议。

本发明还公开了一种用于在请求实体RE和目标实体TE之间执行数字 版权管理DRM软件完整性检查的方法，该方法包括以下由所述TE执行的 步骤：接收来自所述RE的请求以使所述TE执行DRM软件完整性检查；在 所述TE执行所述DRM软件完整性检查；以及发送DRM软件完整性状态指 示符到所述RE，其中所述DRM软件完整性状态指示符被配置成指示是否 给予所述TE的完整性状态充分信任以开始关于所述TE的注册协议或关于 所述TE的使设备能够获取受保护内容的另一协议。

本发明公开了几种方法，用于增强与OMA DRM规范v2.0有关的实体、 消息以及处理的完整性。所述方法使用通常称为可信计算技术的技术，其由 工业论坛可信计算组（TCG）规定。在本发明第一实施方式中，公开了一种 用于验证平台与DRM SW完整性或者可信度的技术，可以修改以及不修改 DRM ROAP与DCF规范。在第二实施方式中，不改变现有ROAP协议的前 提下，公开了一种用于增强OMA DRM ROAP消息、组成信息以及处理的完 整性的技术。在第三实施方式中，对现有ROAP协议进行一些改变的前提下， 公开了一种用于增强ROAP消息、信息以及处理的完整性的技术。

附图说明

从以下关于优选实施方式的描述中可以更详细地了解本发明，这些优选 实施方式是作为实例给出的，并且是结合附图而被理解的，其中：

图1是现有OMADRM2.0功能结构的方框图；

图2是现有OMA DRM2.0ROAP四传注册协议的流程图；

图3是现有OMA DRM2.0ROAP二传RO获取协议的流程图；

图4是现有OMA DRM2.0ROAP一传RO获取协议的流程图；

图5是现有OMA DRM2.0ROAP二传加入域协议的流程图；

图6是现有OMA DRM2.0ROAP一传离开域协议的流程图；

图7是在OMA DRM2.0实体之间的多方平台完整性检查的方框图；

图8是用于在两个实体之间执行平台完整性验证的方法的流程图，其中 两个实体可以是设备与RI或者设备与CI；

图9是用于在使用在前信任检查的设备与RI之间执行相互的平台完整 性检查的四传ROAP注册协议的流程图；

图10是用于在使用修改的设备问候与RI问候消息的设备与RI之间执 行相互的平台完整性检查的四传ROAP注册协议的流程图；

图11是用于在两个实体之间执行DRM软件完整性检查的方法的流程 图，其中两个实体可以是设备与RI或者设备与CI；

图12是用于在设备与RI之间执行相互的DRM软件完整性检查的二传 ROAP RO获取协议的流程图；

图13是用于改进ROAP消息的完整性和使用包括密封绑定与存储器分 区的TCG技术处理的方法的流程图。

具体实施方式

在下文中，术语“无线发送/接收单元”（WTRU）包括但不局限于用户 设备、移动站、固定或移动用户单元、寻呼机或者能够在有线或无线环境中 运行的任何其它类型的设备。当下文提及时，术语“基站”包括但不局限于 Node B、站点控制器、接入点或者在无线环境中的任何其它类别的接口设备。

本发明公开了这些方法，因此关于信任状态或者DRM实体（例如设备、 RI或者CI）的完整性的信息是明确地、互相地请求并在任何两个DRM实体 之间作为对OMA DRM过程的预必备信息。

图7中示出了这个方法的普通结构700。该结构包括四个DRM实体： 设备702、RI704、CI706以及专用认证权威（PCA）708。平台完整性检查 假定PCA708具有对用于其它DRM实体（例如设备702、RI704以及CI706） 的可信计算（例如TCG）证书的记录，并提供了对用于TCG证书的认证的 信任的根源。

想要在它们自己之间进行相互的平台完整性检查的任一对实体（例如设 备702与RI704、设备702与CI706、或者RI704与CI706）有可信计算能 力（例如配备TCG可信处理模块（TPM）710）。这暗示所述可信计算能力 DRM实体不仅具有TPM710（或等同物），而且还具有相关TCG资源，诸 如AIK712、SML714以及使用二进制大对象716的受保护存储器。还给出 的是OS或者平台软件718以及DRM软件720。

当满足以上要求时，任何不同的DRM实体对可以使用PCA708以及可 信计算能力互相检查它们的平台完整性或者平台可信状态。例如，对于在设 备702与RI704之间相互完整性检查的过程如下。

设备702、RI704以及CI706都能够执行OS或者其它平台软件组件的 自检查（步骤730），以及对DRM软件的自检查（步骤732）。自检查可以作 为大的验证处理的一部分而请求（如在以下详情论述的）或者可以独立的处 理。如果任何一个自检查失败，那可能指示实体已被损害并不应被信任。

设备702发送关于其平台TCG证书的信息到RI704（步骤740）。平台 TCG证书的例子包括但不局限于签名的TCG平台证书或者签名的TPM证 书。作为证书的一部分，设备702还可以对RI704发送自证明的已经检查了 可信状态或平台完整性的标记（flag）作为补充信息。如果设备702将要验 证RI704的平台完整性，在步骤740中发送的证书信息还将包含设备702 的指示，其指示设备702需要RI704启动用于验证自身平台完整性的过程。 注意到设备702只有在RI的平台完整性状态的验证是可选特性时才能作出 关于是否验证RI704的平台完整性的决定；在一个实施方式中，验证RI的 平台完整性是强制特性。

在从设备702接收证书信息时，RI704把所述证书信息中继转发到PCA 708（步骤742），并且还请求PCA708验证关于设备702的证书，尤其是设 备的当前最大可信度。PCA708然后发送关于设备702的当前最大可信度信 息到RI704（步骤744）。一接收到来自PCA708的设备平台可信度信息以 及可选择性地接收到来自设备702的补充信息，RI704估计设备702的信任 等级。RI704判断是否对所述设备平台的完整性给予充分信任，以进一步开 始DRM过程，诸如注册协议或者RO获取协议。

设备702，或者作为强制过程或者作为可选过程，可以用与步骤740-744 类似的可逆的方式估计RI704的平台完整性。更具体地，RI704发送关于其 平台TCG证书的信息到设备702（步骤750）。作为证书的一部分，RI704 还可以对设备702发送自证明的已经检查了可信状态或平台完整性的标记作 为补充信息。

在从RI704接收到有关TCG的信息时，设备702把所述信息中继转发 到PCA（步骤752），并且也请求PCA708验证关于RI704的证书，尤其是 RI的当前最大可信度。PCA708然后发送关于RI704的当前最大可信度信 息到设备702（步骤754）。一接收到来自PCA708的关于RI704的RI平台 可信度信息以及还可选择性地接收到来自RI本身的补充信息，设备702估 计RI704的信任等级。设备702判断是否对RI平台的完整性上给予充分信 任，以开始进一步的DRM过程诸如注册协议或者RO获取协议。

设备702，或者作为强制过程或者作为可选过程，可以估计CI706的平 台完整性。CI706发送关于自己的平台TCG证书的信息到设备702（步骤 760）。作为证书的一部分，CI706还可以对设备702发送自证明的已经检查 了可信状态或者平台完整性的标记作为补充信息。

在从CI706接收有关TCG的信息时，设备702把该信息中继转发到PCA （步骤762），并且还请求PCA708验证关于CI706的证书，尤其是CI的当 前最大可信度。PCA708然后发送关于RI706的当前最大可信度信息到设备 702（步骤764）。一接收到来自PCA708的关于RI706的CI平台可信度信 息以及还可选地接收到来自CI本身的补充信息，设备702估计CI706的信 任等级。设备702判断是否对CI平台的完整性给予充分信任，以开始进一 步的DRM过程。

设备702的平台完整性可以由CI706进行如下验证。设备702发送关于 自身的平台TCG证书的信息到CI706（步骤770）。作为证书的一部分，设 备702还可以对CI706发送自证明的已经检查了可信状态或者平台完整性的 标记作为补充信息。如果设备702将要验证CI706的平台完整性，在步骤 770中发送的证书信息还将包含设备702的指示，其指示设备702需要CI706 启动验证CI706的平台完整性的过程。注意到设备702只有在CI706的平 台完整性状态的验证是可选特性时才能作出是否验证CI706的平台完整性 的决定；在一个实施方式中，验证CI的平台完整性是强制特性。

在从设备702接收证书信息时，CI706把所述证书信息中继转发到PCA 708（步骤772），并且还请求PCA708验证关于设备702的证书，尤其是设 备的当前最大可信度。PCA708然后发送关于设备702的当前最大可信度信 息到CI706（步骤774）。一接收到来自PCA708的设备平台可信度信息， 以及还可选地接收到来自设备702的补充信息，CI706估计设备702的信任 等级。CI706判断是否对设备平台的完整性给予充分信任，以开始进一步的 DRM过程。

注意到在上面的例子中，步骤740-744对于设备702向RI704验证自身 的完整性状态是本发明的强制特征。然而，向设备702验证RI704的平台完 整性（步骤750-754），或者向设备702验证CI706的平台完整性（步骤 760-764），以及向CI706验证设备702的平台完整性（步骤770-774）是DRM 系统中可选的、目前高度推荐的特征。

注意到这些过程不需要由需要验证的实体主动启动而开始。完整性验证 过程可以从希望验证对方完整性的实体的请求开始。在此情况下，步骤740、 750、760或者770每一个将被另一步骤领先，借此希望对对方平台完整性验 证的实体呼叫或者请求对方发送相关的涉及信任的信息。

在替换实施方式中，对于实际的OMA DRM系统实现，为了如上所述 建议的平台完整性验证过程的条件或者触发机制可以包括以下：

1．设备平台完整性验证过程（即步骤740-744），可以由以下的一个或 多个执行。

1A．在设备希望去启动新的四传ROAP注册协议之前。

1B．每个RI一次，在与特定RI的第一次注册发生之前。在这种情况下， RI在第一次注册之前将接收所述设备的TCG证书一次，然后RI通过绑定所 述证书信息与TPM密钥来保护所述设备的证书信息在其拥有的TPM下面。 所述RI稍后解开存储的TCG证书，并周期地或者基于一些事件验证其已经 接收的所述设备的TCG证书是否仍然是有效的，例如通过与OCSP CA协商。

1C．周期性地，自所述设备上一次完成到相同RI的注册协议起每当逝 去一规定的持续时间，例如，T_{DEV-PLATFORM-LAST-REG}，执行一次设备平台完整 性验证过程。

1D．周期性地，自上一次所述设备向相同RI验证了其平台完整性状态 起每当逝去一规定的持续时间，例如，T_{DEV-PLATFORM-LAST-REPORT}，执行一次设 备平台完整性验证过程。

2．如果以及当实现所述RI平台完整性验证过程（即步骤750-754）时， 可以通过以下一个或多个来执行。

2A．每个设备一次，在与特定的设备进行第一次注册之前。在这种情况 下，所述设备在第一次注册之前将接收所述RI的TCG证书一次，然后所述 设备通过绑定所述证书信息与TPM密钥来保护所述RI的证书信息在其拥有 的TPM下面。所述设备稍后解开存储的TCG证书，并周期地或者基于一些 事件验证其已经接收的所述RI的TCG证书是否仍然是有效的，例如通过与 OCSP CA协商。

2B．在任何时候RI从所述设备接收指示，所述设备希望RI验证其对所 述设备的完整性状态，或者作为独立的消息或者作为修改的ROAP协议消息 的一部分。

2C．周期性地，自上一次所述RI向所述设备验证了其平台完整性状态 起每当逝去一规定的安全持续时间，例如，T_{RI-PLATFORM-LAST-REPORT}，执行一次 设备平台完整性验证过程。

3．由于用于在设备与CI之间的平台完整性验证，对于完整性验证处理 的和/或事件驱动的发生，可以考虑类似于以上的机制。此外，在所述设备对 所述CI的平台完整性验证的情况下，还可以每次在必须购买或者下载内容 之前执行，也可能反之亦然（即必须对所述CI验证所述设备的平台完整性）。

现有技术已经考虑联同坚固DRM的应用程序的使用了TCG技术的“安 全的引导程序”。在这种方案中，每当设备被引导，所述平台的OS与其它启 动相关的代码是完整性检查的，隐含地在可以运行任何DRM应用程序之前 执行平台完整性检查。本发明提供了对引导时间平台完整性检查的更系统化 且明确的使用，以及平时根据预定时段和某些时间的发生的平台完整性检 查。本发明此外归纳了从所述设备到RI以及到CI的平台完整性检查。因为 正是由于设备已经正确地接收了特定的有效CO，连续平台完整性检查是有 益的，这不意味着应该从那时到将来认为RI或CI是不明确可信的。周期性 和/或事件驱动的连续的对可信度的验证提供了好的保护机制。

此外，由于对在所述设备与CI之间的完整性检查的需要，即使所述内 容在RO之前到达，当所述CI的平台或者所述CI的DRM SW被损害时， 所述内容可能是损害的。例如，假定用户已经下载了文件。即使当还没有获 得所述RO，用户可能无意中点击所述内容、或者可能在所述内容上执行有 效性检查。如果所述内容是被损害的（例如已经附加了病毒），即使没有RO， 所述内容也能破坏设备。此外，在设备与CI之间的预下载交互中（例如在 发现步骤期间），损害的设备能伤害CI，例如通过把附加到内容的病毒增加 到为所述CI设计的消息上。另外，从商业观点，CI不想要发送内容到损害 的设备；例如，损害的设备可能对未授权的接收方免费再分配内容。由此， 在设备与CI之间的相互的平台（与SW）完整性验证具有保护整个系统的优 点。

还注意到可以有对包含在以上结构的论述中列出的中心思想的几个不 同的方式。以下论述两个这种例子，但是注意到这些仅仅是根据以上段落描 述的结构对主要原理的说明性例子。

平台完整性验证

图8是在两个实体之间执行平台完整性验证的方法800的流程图。两个 实体可以是设备与RI，设备与CI，或者RI与CI。所述方法800利用请求实 体（RE）与目标实体（TE）；注意到所述对的任何一个实体（设备、RI或者 CI）都可以是RE。所述方法800以同样的方式操作，无论哪个实体是RE 以及哪个实体是TE。

所述方法800从RE对TE发送请求以请求TE报告其平台完整性状态开 始（步骤802）。响应于所述请求，TE发送其TCG证书到所述RE（步骤804）。 例如，所述TCG证书可以包括平台证书、TPM证书或者一致性证书。RE 然后发送所述TE的证书到OCSP应答器，用于对所述证书的验证（步骤 806）。所述OCSP应答器检查TE的TCG证书，并对所述RE报告所述验证 状态（步骤808）。

RE发送请求到所述TE，以报告其拥有的平台完整性状态（步骤810）。 所述TE检查其平台完整性状态（步骤812），发送平台完整性状态标志到所 述RE（步骤814），并且所述方法终止（步骤816）。

所述方法800可以不加任何修改应用到ROAP协议（以下结合图9论 述），或者稍加改变应用到ROAP协议（以下结合图10论述）。

不作改变对ROAP协议的完整性验证

图9是在设备902与RI904之间使用分别来自ROAP协议的TCG技术 （即利用OCSP应答器/PCA906）交换有关完整性的信息的方法900的流程 图。注意到在方法900中，相同实体906被描述为用于DRM处理的PCA以 及用于TCG处理的OCSP应答器。在方法900中，在ROAP四传注册协议 之前执行平台完整性验证（由虚线矩形所示）。在注册协议之前执行平台完 整性验证是有用的，因为注册协议不是常常执行，并且平台完整性验证处理 花费一些时间才能完成；如果对每个消息执行平台完整性验证，系统的整个 操作可能不必要地减缓。所属技术领域的专业人员可以假定在执行平台完整 性验证之后，RI仅仅接收一个设备问候消息，由于其将指示可信设备。如果 由RI接收来自相同设备的多于一个设备问候消息，其可以是对DoS攻击的 指示。还可以结合认证协议与对象获取协议一起来执行平台完整性验证。

在用RI904启动四传注册协议之前，设备902利用RI904开始单独程 序组，以执行平台完整性的相互验证。设备902首先向RI904发送其自己的 TCG证书（例如平台证书、TPM证书、一致性证书等等）或者包含或涉及 所述TCG证书的其它信息（步骤910）。可选地，设备902还发送请求到RI 904，以对设备902检查并报告其自己的平台完整性状态；这个请求是被包 含在设备证书中的。

RI904请求PCA906验证设备的TCG证书（步骤912）。PCA906响应 于RI的请求，并发送有关设备的TCG证书的信息（步骤914）。

RI904请求设备902报告设备902自己的平台完整性状态标志（步骤 916）。此外，如果设备902已经在步骤910中请求RI904验证并报告其平台 完整性状态，并且如果RI904希望并能够对所述请求表示感谢，在步骤916 中，RI904对设备902发送其自己的TCG证书或者包含或涉及所述TCG证 书的其它信息。如果RI904不能或不希望对对所述请求表示感谢，其发送“不 感谢”消息到所述设备。RI904可以因为许多理由不响应所述请求，包括资 源受限的RI（即所述RI已经没有充分的可用资源去响应所述请求）或者设 备可信性检查失败。所述设备可以依据设备对所述RI具有的置信程度中断 所述协议；如果所述设备信任RI，其或许继续所述协议，即使RI拒绝响应 所述请求。在接收来自RI904检查平台状态的请求下，设备902检查其自己 的平台完整性状态（步骤918）。

所述设备902请求PCA906验证RI的TCG证书（步骤920）。在这种 接收来自设备902的请求的情况下，PCA906返回有关RI的TCG证书的信 息（步骤922）。设备902发送其平台完整性状态标志到RI904（步骤924）。 如果RI904接收到来自设备902检查其完整性状态的请求，并且如果RI904 希望并能够对所述请求表示感谢，RI904检查其自己的平台完整性（步骤 926）。RI然后返回平台完整性状态标志到设备902（步骤928）。有关RI完 整性检查的可选步骤可以以任何次序执行；那些步骤不需要与如图9所示的 设备完整性检查有交叉。另外，RI可以启动其自己的完整性检查。此外，如 果RI由于任何可能的理由而拒绝完全地响应对其自己的TCG证书信息的请 求，其可以以合适的方式对设备指示这种事实，例如在步骤922中。

方法900使设备902与RI904能实现相互的平台完整性验证。在这种验 证下，设备然后可以开始ROAP注册协议。在图9中示出的对注册协议的步 骤（步骤930-940）与如上所述的方法200的步骤210-220是相同的。注意 到可以在定期的间隔触发或者重复这些过程。

改变对ROAP注册协议的完整性验证

在另一个具体实施例中，图10示出了一种方法1000，其中设备1002 与RI1004交换有关完整性的信息，此外利用OCSP应答器/PCA1006的业 务。在方法1000中，修改了ROAP注册协议的现有设备问候与RI问候消息， 以把TCG证书与请求二者传送到对方，用于平台完整性验证。

设备1002发送修改后设备问候消息到RI1004（步骤1010），包含设备 TCG证书与可选请求以报告其平台完整性。RI1004把设备证书转发到PCA 1006，以用于验证（步骤1012）。PCA1006然后把设备TCG证书返回到RI 1004（步骤1014）。RI1004用修改后的RI问候消息响应设备1002（步骤 1016），该消息选择性地包含RI的TCG证书。

其次，设备1002选择性地发送请求到PCA1006，以检查RI的TCG证 书（步骤1018）。PCA1006检查RI的证书，并把结果报告回到设备1002（步 骤1020）。设备1002检查其自己的完整性状态（步骤1022），并对RI1004 报告完整性状态（步骤1024）。

如果设备1002已经请求RI1004报告其完整性状态，RI1004执行平台 完整性检查（步骤1026），并把完整性状态例如其信任的状态标记报告回到 设备1002（步骤1028）。所述步骤1030-1036与如图2所示的ROAP注册协 议的步骤214-220是相同的。

检查DRM软件的完整性

图11是用于检查在任何DRM实体对中的DRM SW（例如在设备处的 DRM用户代理SW、在RI或者CI处的DRM SW）的完整性的方法1100的 流程图。请求实体（RE）发送请求到目标实体（TE），以执行DRM SW完 整性检查（步骤1102）。TE检查自己的DRM SW完整性（步骤1104），发 送DRM SW完整性标志到RE（步骤1106），并且所述方法终止（步骤1108）。 注意到当TE是设备时，如果设备驱动器和媒体播放器SW这两个部件分别 存在于所述设备上，那么可以分别地从DRM SW的完整性检查这两个部件 的完整性。

方法1100仅仅涉及RE从TE获得DRM SW完整性检查。为了执行相 互的DRM SW完整性检查，将需要对方法1100执行两次，一次从RE到TE， 然后从TE到RE（用RE与TE交换角色）。在相互的DRM SW完整性检查 期间，所述请求可以是交叉的（如图12所示）或者可以是如图11所示分离 的。如果正在执行相互的DRM SW完整性检查，不改变所述方法的操作。

OMA DRM2.0规范假定，没有建议如何有根据地实现这种假定，可以 绝对信任DRM用户代理SW（或者在本发明中使用的术语，设备DRM SW） 以及RI（或者RI的DRM SW）。在OMA DRM2.0规范中的认证协议仅仅 规定了在实体之间的实际的认证过程，也就是已经认为是可信的。由于明显 的理由，这种暗示的SW信任假定实际上不能被自动地假定，缺少实际的步 骤以实现并验证它们。在本节中描述的方法涉及这种具体的步骤。

图12是用于应用连同ROAP RO获取协议的DRM SW检查的方法1200 的流程图。该方法1200利用设备1202、RI204以及OCSP应答器/PCA1206。 首先，PCA1206与设备1202和RI1204通信，以执行平台完整性检查与 ROAP注册协议（步骤1210）。设备1202和RI1204执行相互的平台完整性 检查、单向的DRM SW完整性检查或相互的DRM SW完整性检查（步骤 1212）。

RI1204发送请求到设备1202，以检查并报告设备的DRM用户代理 （UA）SW完整性（步骤1214）。设备1202检查其最后的DRM UA SW完 整性（步骤1216）。设备1202选择性地发送请求到RI1204，以检查并报告 RI的DRM SW完整性（步骤1218）。如果被请求，RI1204检查其最后的 DRM SW完整性（步骤1220）。设备1202发送设备DRM SW完整性状态标 志到RI1204（步骤1222）。如果预先地请求，RI1204发送RI DRM SW完 整性状态标志到设备1202（步骤1224）。注意到对可选RI完整性检查的步 骤可以任何次序来执行，并且不需要与如图12所示的设备完整性检查有交 叉。

注意到方法1200可以改归为用于在设备与CI之间的相互的DRM SW 完整性验证，代替示出的设备/RI交互。在步骤1210-1224完成时，例如， 设备1202可以在步骤1226与1228中开始二传RO获取协议，如上述结合 图3的步骤310与312相同。还注意到尽管所述方法1200是结合RO获取 协议示出的，但是其可用于结合任何其它ROAP协议，但是为了最小化与方 法1200有关的开销，其可以仅仅用适当选择的ROAP协议子集在任何给定 时间来执行。对于实际的OMA DRM系统实现，如上用于建议的平台和/或 DRM SW完整性验证过程的一些条件或者触发机制可以包括：

1．设备DRM SW完整性验证过程可以由以下的一个或多个来触发。

1A．在设备希望启动新的二传ROAP注册协议、二传加入域协议、或 者二传离开域协议之前。

1B．周期性地，自设备上一次完成至相同的RI的二传ROAP注册协议、 二传加入域协议、或者二传离开域协议起每当逝去一规定的持续时间经过的 时间，例如T_{DEV-DRM-LAST-ROAP}，执行一次设备DRM SW完整性验证过程。

1C．周期性地，自上一次设备向相同的RI验证并报告了其DRM SW完 整性状态起每当逝去一规定的持续时间，例如T_{DEV-DRM-LAST-REPORT}，执行一次 设备DRM SW完整性验证过程。

1D．无论何时设备更新其DRM SW时。

1E．无论何时更新或者改变平台SW时。

2．可以由以下的一个或多个执行RI DRM完整性检查过程。

2A．在任何时候RI从设备接收指示，该指示为设备希望RI向设备验证 其DRM SW完整性状态，或者作为独立的消息或者作为修改后ROAP协议 消息的一部分。

2B．周期性地，自上一次RI向设备验证并报告了其DRM SW完整性状 态起每逝去一规定的持续时间，例如T_{RI-DRM-LAST-REPORT}，执行一次RI DRM 完整性检查过程。

2C．无论何时RI已经更新其DRM SW时。

2D．每次在设备发送RO请求之前时，在用户在频繁的基础上获得内容 的过程中，诸如流动内容。

由于用于在设备与CI之间的平台完整性验证，对于DRM SW完整性验 证处理周期性和/或事件驱动的出现，可以考虑类似于以上的机制。

可以相互独立地执行用于DRM平台验证与DRM SW验证的建议的方 法，但是还期待这些验证过程可以组合为一组过程的一部分。在这种实施方 式中，对于DRM SW验证步骤必须考虑DRM平台验证步骤。例如，对于 在设备与RI之间的完整性验证，设备与RI首先通过执行如上所述的平台验 证过程在相互的整个平台上建立信任。所述触发机制包括通用平台验证触发 条件。然后，对于DRM SW验证触发的条件一出现，则进行DRM SW验证 过程。注意到当满足它们的各自的触发条件时，将执行验证过程的两个类型。 然而，DRM SW验证步骤将控制对DRM平台验证步骤的成功完成，即，如 果在设备与RI之间的DRM平台验证失败，那么在DRM SW验证中的进一 步处理和实际的DRM ROAP处理及关于使用的处理将失败。

密封的签名与绑定

为保护ROAP协议完整性的OMA DRM2.0规范的现有机制被限制以包 含一些、但不是全部的ROAP消息的数字签名（或者消息完整性检查）。给 定了ROAP协议是在安全的DRM进程实现中的中心环节，重要的是去保护 并不断地验证在ROAP协议中使用并交换的信息的完整性。

因此，在本发明的替换实施方式中，公开了用于增强ROAP协议完整性 的方法，借此以DRM设备与RI之间的可靠认证和完整性验证为中心的信息 可以：（1）使用TCG技术被安全存储，和（2）在发送对另一方之前、或者 在存储信息的侧在处理中使用之前被预验证。

这种方法涉及两个基本程序，其使用密封签名（即，对称地加密目标信 息，然后不对称地签上对称密钥加上一组PCR值，PCR值指示对平台或者 特定的SW组件的当前完整性状态）和绑定（用密钥不对称地加密目标信息， 其专用解密密钥保持在诸如TPM的受保护模块中）的TCG技术。密封签名 给予通过由受保护的PCR值指示的非对称加密、数字签名和绑定到设备 DRM用户代理SW的信任状态而提供的信息安全性的最高等级。绑定对使 用非对称加密的保护（其中解密密钥是在TPM内部保护的）给予最高等级。

以下系统的原理使用密封的签名与绑定来保护在ROAP消息中使用的 信息的机密性和完整性，由此间接地提高ROAP协议本身的完整性的强度。 在下面论述中，设备和RI二者（或者RI的处理这种特定设备的部分）假定 为配备有TPM，并支持全面的TPM功能。

设备与RI每一个可以留出与使用一组的两个存储密钥，去密码地把涉 及ROAP处理的特定信息密码地绑定与安全地存储到信任的平台，在该平台 上具有设备或者RI。对于所述设备，这些密钥是K_DEV_BIND_A与 K_DEV_BIND_B。对于所述RI，这些密钥是K_RI_BIND_A与 K_RI_BIND_B。这些是TPM保持的不对称密钥（即，加密是用公钥执行， 解密是用在TPM内部的私钥执行）。

所述设备与所述RI每一个使用一个PCR或者一组PCR，用于DRM处 理。所述设备与所述RI还留出与使用认证身份密钥（AIK），去把有关ROAP 处理的信息密封地签名到所述信任的平台以及其特定的PCR值。注意到所 述TCG AIK密钥仅仅使用为用于签名PCR值。对于所述设备，其AIK是 K_DEV_AIK，以及对于所述RI，其AIK是K_RI_AIK。此外，所述密封的 签名需要用于目标数据的加密运算的不对称存储密钥。由此，每个设备与所 述RI留出与使用对于这个目的的存储密钥。对于所述设备的存储密钥是 K_DEV_STO_SEAL，对于所述RI的存储密钥是K_RI_STO_SEAL。

所述方法然后使用密封的签名与绑定与和完整一样的保护的保密性的 增加的测量，去提高存储包含在所述ROAP处理中的多个信息元素的强度。 例如，图13是方法1300的流程图，其中TPM密封的签名与绑定操作用来 保护在多个消息中的信息的保密性与完整性，其包括四传ROAP注册协议。 在方法1300中，设备1302与RI1304每一个密封地签名选择的有关ROAP 的信息组，使用两组存储密钥绑定所述信息，每组存储密钥在四传注册协议 的过程中或者发送（到另一方）或者接收（从另一方）。

所述设备1302首先用加密密钥K_DEV_STO_SEAL与设备特定的 AIKK_DEV_AIK密封地签名设备ID信息元素（在OMA DRM范例中是OMA  DRM公钥的SHA-1散列）（步骤1310）。这个信息被绑定（使用非对称加密） 到其它信息，以用于具有存储密钥K_DEV_BIND_A的设备问候消息（步骤 1310）。设备问候消息然后从设备1302被发送到RI1304（步骤1312）。

通过密封地签名诸如设备ID的信息并绑定包括设备问候消息的其它信 息，设备1302可以建立策略，即只有当设备问候消息将被发送时以及如果 设备1302从它们的保护存储器恢复（即开封签名与解开）先前密封地签名 与绑定的信息，比较它们与所述DRM SW可以使用的这种信息元素的当前 值，并验证当前值的真实性与完整性。注意到仅仅作为例子给出了在这个方 案中密封地签名的比较绑定的信息元素的选择。其它信息元素可以被密封地 签名和绑定在不同的组合中，对本发明的操作不起影响。其它组合可以源自 于诸如系统时间、在消息中的任何信息元素、算法与现时的项。保护现时的 一个理由是确定所述特定现时是否是真随机的，如一些随机数发生器是特别 是被有害地损害的可以重复相同式样并产生相同号码作为在未接受的短时 间内的输出。

一接收到设备问候消息，RI1304就用其绑定密钥、K_RI_BIND_A绑定 包含于设备问候消息中的信息。这个步骤允许对密钥信息的安全的、完整性 保护的存储，所述密钥信息是所述RI1304从设备1302接收的。可选地，所 述RI1304还可以从设备问候消息提取设备ID（或者其它信息元素），以及 使用所述AIKK_RI_AIK与加密密钥K_RI_STO_SEAL分别密封地签名信息 元素。

RI1304用加密密钥K_RI_STO_SEAL与AIKK_RI_AIK密封地签名所 述RIID与RIURL信息元素（步骤1316）。RI1304还用存储密钥 K_RI_BIND_A绑定包含于其RI问候消息中的其它信息（步骤1316）。RI1304 然后发送RI问候消息到设备1302（步骤1318）。

只有当如果RI1304首先从保护的存储器恢复（即，开封地签名与解开） 先前密封地签名与绑定的信息时，RI1304发送RI问候消息到所述设备1302， 把恢复后的签名和信息与RI DRM SW可能使用的这种信息元素真实的当前 值比较，并验证当前值的真实性与完整性。

一接收到RI问候消息，所述设备1302就用第二绑定密钥即 K_DEV_BIND_B绑定包含在RI问候消息中的信息（步骤1320）。这个步骤 允许对密钥信息的安全的、完整性保护的存储，所述密钥信息是所述设备从 所述RI1304接收的。可选地，设备1302还可以从接收的RI问候消息（诸 如RI ID和/或RI URL）提取选择的信息元素，并当使用K_DEV_BIND_B 简单地绑定在RI问候消息中接收的其余信息时，使用AIKK_DEV_AIK与 加密密钥K_DEV_STO_SEAL密封地签名它们。

设备1302用K_DEV_AIK与K_DEV_STO_SEAL密封地签名证书链、 DCF散列与请求时间（步骤1322）。设备1302然后用K_DEV_BIND_A绑 定要用于注册请求消息的其它信息（步骤1322）。设备1302然后发送所述注 册请求消息到RI1304（步骤1324）。如果设备恢复（即开封签名与解开）先 前密封地签名与绑定的信息，设备1302仅仅发送注册请求消息，比较恢复 的值与在DRM SW存储器中使用的当前临时值，并验证当前值的真实性与 完整性。一接收到注册请求消息，RI1304用绑定密钥K_RI_BIND_B绑定 来自注册请求消息的信息（步骤1326）。

RI1304用K_RI_AIK与K_RI_STO_SEAL密封地签名所述密钥、证书 链与RO（步骤1328）。RI1304然后用绑定密钥K_RI_BIND_A将上述绑定 到包括在注册应答消息中的其它信息（步骤1328）。RI1304然后发送注册应 答消息到设备1302（步骤1330）。如果RI恢复（即开封签名并解开邦定） 先前密封地签名与绑定的信息，RI1304仅仅发送注册应答消息，比较恢复 的值与在DRM SW存储器中使用的当前临时值，以及验证当前值的真实性 与完整性。一接收到注册应答消息，设备1302用绑定密钥K_DEV_BIND_B 绑定来自注册应答消息的RI产生的信息（步骤1332）。

注意到密封的签名与绑定可以用于任何其它ROAP协议。如上所述的方 法1300是示例的，其原理可以同样应用于任何其它ROAP协议。

如果密封的或者密封地签名数据的实体已经更新了其平台OS或者 DRM SW，在OMA DRM ROAP消息交换期间获得的数据将需要被解密封和 重新密封到新的配置PCR值。当这种事件发生时，已经密封或者密封地签 名到特定状态（或者，相当于到PCR值当前状态特定组）的涉及DRM ROAP 的数据将必须被首先解密封并然后重新密封到更新的平台OS的更当前状 态。在现有技术中处理这个程序要求并且假定这种过程的现有技术将产生， 以保护对任何涉及DRM ROAP的数据的恰当的解密封与重新密封，也就是 使用在这里建议的密封或者密封地签名来存储。

一个附加的改进是增加字段到现有ROAP消息格式中，以指示发送设备 的TCG能力。所述TCG能力字段可以通过形成早期的确定来帮助增加与传 统设备的互用性，所述确定是有关于所述接收实体是否支持TCG有关的信 息与过程。

设备问候消息的修改及其推导

第一修改是增加新的设备TPM能力指示（DTCI），其是设备的TPM能 力的指示符，或者在设备问候消息的现有扩展参数的新元素中，或者可替换 地且优选地，增加所述DTCI作为在设备问候消息的报头中的新的第一个参 数。所述DTCI可以是一个比特（指示设备TPM的缺少或者出现）或者一 些比特（指示有关设备的TPM能力的更多信息）。如果所述DTCI是作为新 的参数而插入，优选地应该是作为第一个参数而插入在设备ID参数之前， 以便RI可以提前知道设备具有一定的TPM能力的其它参数，以及利用所述 DTCI处理来自后面参数（例如设备ID）的信息。所述DTCI信息的优点是， 其允许RI估计在与剩余ROAP协议中的设备的进一步交互中的设备的可信 度。

第二修改是使用设备特定的TCG EK证书或者TCG AIK证书来散列并 导出所述DRM设备ID。这个修改的优点是EK证书和/或AIK证书很好地 由所述设备内部的TPM保护，由此，从这些证书的任何一个导出所述DRM 设备ID增强了所述DRM设备ID信息的完整性。

第三修改是增加其中有设备问候消息的新的签名参数，直到除所述签名 之外，其用所述设备的AIK私钥签名，由RI验证。这个修改的优点是保护 了在设备与所述RI之间第一交互的所述设备TPM能力的完整性。设备的 AIK私钥的利用增强了签名操作的完整性，所述私钥是很好地由所述TPM 安全地保护的。

表12与表13示出了对于修改后设备问候消息的两个可能的格式。表12 示出了用DTCI比特作为第一参数的消息格式。表13示出了其中DTCI是现 有扩展参数的新元素的设备问候消息的格式。

表12.具有单独的DTCI参数的修改后设备问候消息格式

表13.修改的设备问候消息格式，在扩展中具有DTCI。

RI问候消息的修改及其推导

第一修改是增加新的RI TPM能力指示（RTCI），其是RI的TPM能力 的指示符，或者作为RI问候消息的现有扩展参数的新元素，或者可替换地 并优选地添加所述RTCI作为在RI问候消息的报头中的新的第一参数。这个 修改的优点是，其允许所述设备使用所述RTCI信息来估计RI的可信度，并 且在其与剩余ROAP协议过程中的所述RI的进一步交互中利用这种信息。

第二修改是使用RI TPM来提供用于会话ID的伪随机数。这个修改的 优点是，TPM提供了安全级很高的基于硬件的伪随机数发生器。使用所述 TPM来产生用作会话ID的伪随机数增强了协议的安全性。

第三修改是使用属于RI的TPM的RI TCG EK证书或者TCGAIK证书 来导出RI ID。这个修改的优点是EK证书和/或AIK证书很好地由所述设备 内部的TPM保护，并且从这些证书的任何一个导出DRM设备ID增强了 DRM设备ID信息的完整性。

第四修改是使用RI TPM来提供RI现时。这个修改的优点是，TPM提 供了很好的安全的基于硬件的伪随机数发生器。使用TPM来产生RI现时增 强了在RI问候消息中使用的该现时的完整性。

第五修改是在设备可信RI锚点中包含设备TCG证书。设备的TCG证 书包含EK证书、AIK证书、平台证书以及RI已经从可信TCG CA预先获 得的兼容性证书。这个修改的优点是，增强了设备可以具有RI问候消息的 信任。

第六修改是添加RI问候消息的签名，直到且排除用RI的AIK私钥签 名的所述签名，其中RI的AIK公钥已经预先地分配给所述设备作为RI问候 消息的一部分。这个修改的优点是保护了在设备与RI之间第一次交互的 RTCI的完整性。RI的AIK私钥的利用，增强了签名操作的完整性，所述私 钥是很好地由所述RI的TPM安全地保护的。

表14与表15示出了用于修改后RI问候消息的两个可能的格式。表14 示出了用RTCI比特作为第一参数的RI问候消息的格式。表15示出了其中 RTCI是现有扩展参数的新元素的RI问候消息的格式。

表14.修改后RI问候消息格式

表15.修改后RI问候消息格式

注册请求消息的修改及其推导

第一修改是使用设备TPM来提供设备现时。这个修改的优点是，TPM 提供了适合于该现时使用的安全且可靠的伪随机数。

第二修改是在证书链中包含设备TCG证书。包含设备TCG证书可以是 对现有OMA DRM2.0设备证书的替代或者是添加其他内容。包含TCG证 书（诸如所述EK证书、AIK证书、平台证书或者兼容性证书）的优点是增 加设备的可信度。

第三修改是在可信RI锚点元素中包含RI信任的TCG CA的列表。包含 RI信任的TCG CA可以是对现有的OMA DRM2.0RI可信锚点元素列表的 替代或是添加其他。包含由RI信任的TCG CA的列表的优点是增加设备的 可信度。

第四修改是在扩展参数的设备详细资料元素中包含关于所述设备TPM 的信息。包括这个信息的优点是，增强了设备对所述RI的可信度。

第五修改是使用用于签名修改后设备问候消息的设备AIK来签名所述 签名。这个修改的优点是由于很好地保护了所述设备AIK的特性，增加了所 述设备和注册请求消息的可信度。

表16示出了用于修改后注册请求消息的格式。

表16.修改后注册请求消息格式

注册应答消息的修改及其推导

第一修改是使用RI TPM来提供用于会话ID的伪随机数。这个修改的 优点是，TPM提供了很高安全级的基于硬件的伪随机数发生器。使用TPM 来产生用作会话ID的伪随机数增强了协议的安全性。

第二修改是使用属于RI的TPM的RI TCG EK证书或者TCGAIK证书 来导出所述RI ID。这个修改的优点是EK证书和/或AIK证书很好地由所述 设备内部的TPM保护，并且从这些证书的任何一个导出所述DRM设备ID 增强了DRM设备ID信息的完整性。

第三修改是使用RI TPM来提供RI现时。这个修改的优点是，RI TPM 提供了适合于该现时的安全且可靠的伪随机数。。

第四修改是在可信设备锚点元素中包含设备所信任的TCG CA的列表。 包含所述设备信任的TCG CA可以是对现有的OMA DRM2.0可信设备锚 点元素列表的替换或是添加。包含由所述设备信任的TCG CA的列表的优点 是增加RI的可信度。

第五修改是使用用于签名修改后RI问候消息的RIAIK签名所述签名。 这个修改的优点是由于很好地保护了RI AIK的特性，增加了RI和注册应答 消息的可信度。

表17示出了用于修改后注册应答消息的格式。

表17.修改的注册应答消息格式

RO请求消息的修改及其推导

第一修改是使用TPM来创建用作设备ID的选择的TCG证书（EK证书、 AIK证书、平台证书或者兼容性证书）的SHA-1散列。这个修改的优点是 所述证书很好地由TPM保护，并且由此，从这些证书之一导出设备ID增强 了所述设备ID信息的完整性。

第二修改是使用设备TPM来产生设备现时。这个修改的好处是由所述 TPM产生的现时是安全的，这是由于TPM的受保护的伪随机数生成能力。

第三修改是在证书链中包含设备TCG证书。包含设备TCG证书可以是 对现有OMA DRM2.0设备证书的代替或者附加。包含TCG证书的优点是 增加设备的可信度。

第四修改是用扩展参数中的设备AIK来签名可选DCF散列（Hash）。 这个修改的优点是很好地保护设备AIK，由此使得所述DCF签名更安全。

第五修改是使用用于标记最近成功地响应注册请求消息的设备AIK来 签名所述RO请求消息。这个修改的优点是由于很好地保护了所述RI AIK 的特性，增加了RI和RO请求消息的可信度。

表18描述了修改后RO请求消息的格式。

表18.修改后RO请求消息格式

RO应答消息的修改及其推导

一个修改是使用RI的TPM以在签最近成功的注册应答消息中使用的相 同RI TPM AIK来签名RO应答消息。这个修改的优点是由于很好地保护了 所述RI AIK的特性，增加了RI和RO应答消息的可信度。

表19描述出了修改后RO请求消息的格式。

表19.修改后RO应答消息格式

虽然本发明的特征和元素在优选的实施方式中以特定的结合进行了描 述，但每个特征或元素可以（在没有所述优选实施方式的其他特征和元素的 情况下）单独使用，或在与或不与本发明的其他特征和元素结合的各种情况 下使用。

实施例

1．一种用于在请求实体（RE）和目标实体（TE）之间执行平台完整性 检查的方法，包括以下步骤：从RE发送请求到TE，以请求TE报告其自己 的可信计算组（TCG）证书；从TE发送TE的TCG证书到RE；从RE转发 TE的TCG证书到在线认证状态协议（OCSP）应答器以用于验证；将来自 OCSP应答器的TE的TCG证书的验证状态报告给RE；从RE发送请求到 TE，以请求TE报告自己的平台完整性状态；检查TE的平台完整性状态； 以及从TE发送平台完整性状态指示符到RE。

2．根据实施例1所述的方法，其中RE是版权发行方（RI），而TE是 设备。

3．根据实施例2所述的方法，其中该方法通过设备发送触发到RI而开 始，并在所述设备启动关于RI的版权对象获取协议（ROAP）注册协议之前 被执行。

4．根据实施例2或3所述的方法，其中所述方法自所述设备最近注册 到RI起以一段逝去时间为基础被周期性地执行。

5．根据实施例2-4中任一实施例所述的方法，其中所述方法自所述设 备最近对RI验证其平台完整性状态起以一段逝去时间为基础被周期性地执 行。

6．根据实施例1所述的方法，其中RE是设备，而TE是版权发行方（RI）。

7．根据实施例6所述的方法，其中所述方法自RI最近向所述设备验证 其平台完整性状态起以一段逝去时间为基础被周期性地执行。

8．根据实施例1所述的方法，其中RE是内容发行方（CI），而TE是 设备。

9．根据实施例8所述的方法，其中所述方法自所述设备最近向CI验证 其平台完整性状态起以一段逝去时间为基础被周期性地执行。

10．根据实施例8或9所述的方法，其中所述方法在所述设备从CI购 买内容时被执行。

11．根据实施例1所述的方法，其中RE是设备，而TE是内容发行方 （CI）。

12．根据实施例11所述的方法，其中所述方法自CI最近向所述设备验 证其平台完整性状态起以一段逝去时间为基础被周期性地执行。

13．根据实施例11或12所述的方法，其中所述方法在所述设备从CI 购买内容时被执行。

14．根据实施例1所述的方法，其中所述方法作为版权对象获取协议 （ROAP）处理的一部分而被执行的。

15．根据实施例14所述的方法，其中所述方法在所述ROAP处理之前 被执行。

16．根据实施例14或15所述的方法，其中修改所述ROAP处理，以合 并该方法作为ROAP处理的一部分。

17．一种用于在请求实体（RE）和目标实体（TE）之间执行数字版权 管理（DRM）软件完整性检查的方法，包括以下步骤：从RE发送请求到 TE，请求TE执行DRM软件完整性检查；由所述TE检查DRM软件完整性； 以及从TE发送DRM软件完整性状态指示符到RE。

18．根据实施例17所述的方法，其中RE是版权发行方（RI），而TE 是设备。

19．根据实施例18所述的方法，其中所述设备发送触发到RI，以在所 述设备启动版权对象获取协议（ROAP）处理之前开始该方法。

20．根据实施例19所述的方法，其中ROAP处理是从由二传注册、二 传加入域以及二传离开域组成的组中选择的。

21．根据实施例19或20所述的方法，其中所述方法在所述设备已经完 成关于RI的版权对象获取协议（ROAP）处理之后被周期性地执行。

22．根据实施例19-21中任一实施例所述的方法，其中ROAP处理是从 由二传注册、二传加入域以及二传离开域组成的组中选择的。

23．根据实施例18-22中任一实施例所述的方法，其中所述方法在所述 设备已经对RI验证并报告其DRM软件完整性状态之后被周期性地执行。

24．根据实施例18-23中任一实施例所述的方法，其中所述方法在所述 设备更新其DRM软件之后被执行。

25．根据实施例18-24中任一实施例所述的方法，其中RI请求所述设 备对该设备上的媒体播放器执行DRM软件完整性检查。

26．根据实施例17所述的方法，其中RE是设备，而TE是版权发行方 （RI）。

27．根据实施例26所述的方法，其中所述方法由所述设备在启动时执 行。

28．根据实施例26或27所述的方法，其中所述方法是独立的处理。

29．根据实施例26-28中任一实施例所述的方法，其中所述方法是修改 的版权对象获取协议处理的一部分。

30．根据实施例26-29中任一实施例所述的方法，其中所述方法在RI 已经对所述设备验证并报告其DRM软件完整性状态之后被周期性地执行。

31．根据实施例26-30中任一实施例所述的方法，其中所述方法在RI 更新其DRM软件之后被执行。

32．根据实施例26-31中任一实施例所述的方法，其中所述方法在所述 设备发送版权对象请求到RI之前被执行。

33．根据实施例26-32中任一实施例所述的方法，其中所述方法在用于 流动内容的请求从所述设备到RI的期间被周期性地执行。

34．根据实施例17所述的方法，其中RE是内容发行方（CI），而TE 是设备。

35．根据实施例34所述的方法，其中所述设备发送触发到CI，以在所 述设备启动版权对象获取协议（ROAP）处理之前开始所述方法。

36．根据实施例34或35所述的方法，其中所述方法在所述设备已经完 成关于CI的版权对象获取协议（ROAP）处理之后被周期性地执行。

37．根据实施例34-36中任一实施例所述的方法，其中所述方法在所述 设备已经对CI验证并报告其DRM软件完整性状态之后被周期性地执行。

38．根据实施例34-37中任一实施例所述的方法，其中所述方法在所述 设备更新其DRM软件之后被执行。

39．根据实施例34-38中任一实施例所述的方法，其中CI请求所述设 备对该设备上的媒体播放器执行DRM软件完整性检查。

40．根据实施例17所述的方法，其中RE是设备，而TE是内容发行方 （CI）。

41．根据实施例40所述的方法，其中所述方法由所述设备在启动时执 行。

42．根据实施例40或41所述的方法，其中所述方法是独立的处理。

43．根据实施例40-42中任一实施例所述的方法，其中所述方法是修改 的版权对象获取协议处理的一部分。

44．根据实施例40-43中任一实施例所述的方法，其中所述方法在CI 已经对所述设备验证并报告其DRM软件完整性状态之后被周期性地执行。

45．根据实施例40-44中任一实施例所述的方法，其中所述方法在CI 更新其DRM软件之后被执行。

46．根据实施例40-45中任一实施例所述的方法，其中所述方法在所述 设备发送版权对象请求到CI之前被执行。

47．根据实施例40-46中任一实施例所述的方法，其中所述方法在用于 流动内容的请求从所述设备到CI的期间被周期性地执行。

48．一种用于增强在两个实体之间交换的版权对象获取协议（ROAP） 消息的完整性的方法，包括以下步骤：使用可信计算技术在每个实体安全地 存储将在所述ROAP消息中使用的信息；以及在该消息被用于连接ROAP 消息，预先验证该将在所述ROAP消息中使用的信息。

49．根据实施例48所述的方法，其中所述存储步骤包括密封地签名所 述信息并绑定所述信息。

50．根据实施例49所述的方法，其中所述密封地签名步骤包括用对称 加密密钥对称地加密所述信息，以及不对称地签名所述对称加密密钥和指示 对象的当前完整性状态的一组值。

51．根据实施例50所述的方法，其中所述签名步骤包括使用所述实体 操作的平台的完整性状态。

52．根据实施例50或51所述的方法，其中所述签名步骤包括使用所述 实体的软件组件的完整性状态。

53．根据实施例49-52中任一实施例所述的方法，其中所述绑定步骤包 括用密钥不对称地加密所述信息，所述密钥的解密私钥被存储在所述实体的 受保护模块中。

54．根据实施例53所述的方法，其中受保护模块是可信处理模块 （TPM）。

55．根据实施例54所述的方法，其中TPM被用于推导出在ROAP消息 中使用的参数。

56．根据实施例48-55中任一实施例所述的方法，其中所述信息是从由 设备标识、版权发行方标识、证书、证书链、数字版权管理相关的时间值、 版权对象、算法和现时组成的组中选择的。

57．根据实施例48-56中任一实施例所述的方法，其中所述方法被应用 于所有ROAP消息。

58．根据实施例48-56中任一实施例所述的方法，其中所述方法被单独 地从ROAP消息应用。

59．根据实施例48-56中任一实施例所述的方法，其中所述方法被集成 到ROAP消息的产生和传送中。

60．根据实施例48-56中任一实施例所述的方法，还包括步骤：对现有 ROAP消息增加字段，以指示发送实体的可信计算能力。

61．一种被配置以执行根据实施例1-60中任一实施例所述的方法的系 统。

62．一种被配置以执行根据实施例1-60中任一实施例所述的方法的集 成电路。