在下文中,术语“无线发送/接收单元”(WTRU)包括但不局限于用户 设备、移动站、固定或移动用户单元、寻呼机或者能够在有线或无线环境中 运行的任何其它类型的设备。当下文提及时,术语“基站”包括但不局限于 Node B、
站点控制器、接入点或者在无线环境中的任何其它类别的接口设备。
本发明公开了这些方法,因此关于信任状态或者DRM实体(例如设备、 RI或者CI)的完整性的信息是明确地、互相地请求并在任何两个DRM实体 之间作为对OMA DRM过程的预必备信息。
图7中示出了这个方法的普通结构700。该结构包括四个DRM实体: 设备702、RI 704、CI 706以及专用认证权威(PCA)708。平台完整性检查 假定PCA 708具有对用于其它DRM实体(例如设备702、RI 704以及CI 706) 的可信计算(例如TCG)证书的记录,并提供了对用于TCG证书的认证的 信任的根源。
想要在它们自己之间进行相互的平台完整性检查的任一对实体(例如设 备702与RI 704、设备702与CI 706、或者RI 704与CI 706)有可信计算能 力(例如配备TCG可信处理模块(TPM)710)。这暗示所述可信计算能力 DRM实体不仅具有TPM 710(或等同物),而且还具有相关TCG资源,诸 如AIK 712、SML 714以及使用二进制大对象716的受保护存储器。还给出 的是OS或者平台软件718以及DRM软件720。
当满足以上要求时,任何不同的DRM实体对可以使用PCA 708以及可 信计算能力互相检查它们的平台完整性或者平台可信状态。例如,对于在设 备702与RI 704之间相互完整性检查的过程如下。
设备702、RI 704以及CI 706都能够执行OS或者其它平台
软件组件的 自检查(步骤730),以及对DRM软件的自检查(步骤732)。自检查可以作 为大的验证处理的一部分而请求(如在以下详情论述的)或者可以独立的处 理。如果任何一个自检查失败,那可能指示实体已被损害并不应被信任。
设备702发送关于其平台TCG证书的信息到RI 704(步骤740)。平台 TCG证书的例子包括但不局限于签名的TCG平台证书或者签名的TPM证 书。作为证书的一部分,设备702还可以对RI 704发送自证明的已经检查了 可信状态或平台完整性的标记(flag)作为补充信息。如果设备702将要验 证RI 704的平台完整性,在步骤740中发送的证书信息还将包含设备702 的指示,其指示设备702需要RI 704启动用于验证自身平台完整性的过程。 注意到设备702只有在RI的平台完整性状态的验证是可选特性时才能作出 关于是否验证RI 704的平台完整性的决定;在一个实施方式中,验证RI的 平台完整性是强制特性。
在从设备702接收证书信息时,RI 704把所述证书信息中继转发到PCA 708(步骤742),并且还请求PCA 708验证关于设备702的证书,尤其是设 备的当前最大可信度。PCA 708然后发送关于设备702的当前最大可信度信 息到RI 704(步骤744)。一接收到来自PCA 708的设备平台可信度信息以 及可选择性地接收到来自设备702的补充信息,RI 704估计设备702的信任 等级。RI 704判断是否对所述设备平台的完整性给予充分信任,以进一步开 始DRM过程,诸如注册协议或者RO获取协议。
设备702,或者作为强制过程或者作为可选过程,可以用与步骤740-744 类似的可逆的方式估计RI 704的平台完整性。更具体地,RI 704发送关于其 平台TCG证书的信息到设备702(步骤750)。作为证书的一部分,RI 704 还可以对设备702发送自证明的已经检查了可信状态或平台完整性的标记作 为补充信息。
在从RI 704接收到有关TCG的信息时,设备702把所述信息中继转发 到PCA(步骤752),并且也请求PCA 708验证关于RI 704的证书,尤其是 RI的当前最大可信度。PCA 708然后发送关于RI 704的当前最大可信度信 息到设备702(步骤754)。一接收到来自PCA 708的关于RI 704的RI平台 可信度信息以及还可选择性地接收到来自RI本身的补充信息,设备702估 计RI 704的信任等级。设备702判断是否对RI平台的完整性上给予充分信 任,以开始进一步的DRM过程诸如注册协议或者RO获取协议。
设备702,或者作为强制过程或者作为可选过程,可以估计CI 706的平 台完整性。CI 706发送关于自己的平台TCG证书的信息到设备702(步骤 760)。作为证书的一部分,CI 706还可以对设备702发送自证明的已经检查 了可信状态或者平台完整性的标记作为补充信息。
在从CI 706接收有关TCG的信息时,设备702把该信息中继转发到PCA (步骤762),并且还请求PCA 708验证关于CI 706的证书,尤其是CI的当 前最大可信度。PCA 708然后发送关于RI 706的当前最大可信度信息到设备 702(步骤764)。一接收到来自PCA 708的关于RI 706的CI平台可信度信 息以及还可选地接收到来自CI本身的补充信息,设备702估计CI 706的信 任等级。设备702判断是否对CI平台的完整性给予充分信任,以开始进一 步的DRM过程。
设备702的平台完整性可以由CI 706进行如下验证。设备702发送关于 自身的平台TCG证书的信息到CI 706(步骤770)。作为证书的一部分,设 备702还可以对CI 706发送自证明的已经检查了可信状态或者平台完整性的 标记作为补充信息。如果设备702将要验证CI 706的平台完整性,在步骤 770中发送的证书信息还将包含设备702的指示,其指示设备702需要CI 706 启动验证CI 706的平台完整性的过程。注意到设备702只有在CI 706的平 台完整性状态的验证是可选特性时才能作出是否验证CI 706的平台完整性 的决定;在一个实施方式中,验证CI的平台完整性是强制特性。
在从设备702接收证书信息时,CI 706把所述证书信息中继转发到PCA 708(步骤772),并且还请求PCA 708验证关于设备702的证书,尤其是设 备的当前最大可信度。PCA 708然后发送关于设备702的当前最大可信度信 息到CI 706(步骤774)。一接收到来自PCA 708的设备平台可信度信息, 以及还可选地接收到来自设备702的补充信息,CI 706估计设备702的信任 等级。CI 706判断是否对设备平台的完整性给予充分信任,以开始进一步的 DRM过程。
注意到在上面的例子中,步骤740-744对于设备702向RI 704验证自身 的完整性状态是本发明的强制特征。然而,向设备702验证RI 704的平台完 整性(步骤750-754),或者向设备702验证CI 706的平台完整性(步骤 760-764),以及向CI 706验证设备702的平台完整性(步骤770-774)是DRM 系统中可选的、目前高度推荐的特征。
注意到这些过程不需要由需要验证的实体主动启动而开始。完整性验证 过程可以从希望验证对方完整性的实体的请求开始。在此情况下,步骤740、 750、760或者770每一个将被另一步骤领先,借此希望对对方平台完整性验 证的实体呼叫或者请求对方发送相关的涉及信任的信息。
在替换实施方式中,对于实际的OMA DRM系统实现,为了如上所述 建议的平台完整性验证过程的条件或者触发机制可以包括以下:
1.设备平台完整性验证过程(即步骤740-744),可以由以下的一个或 多个执行。
1A.在设备希望去启动新的4传ROAP注册协议之前。
1B.每个RI一次,在与特定RI的第一次注册发生之前。在这种情况下, RI在第一次注册之前将接收所述设备的TCG证书一次,然后RI通过绑定所 述证书信息与TPM密钥来保护所述设备的证书信息在其拥有的TPM下面。 所述RI稍后解开存储的TCG证书,并周期地或者基于一些事件验证其已经 接收的所述设备的TCG证书是否仍然是有效的,例如通过与OCSP CA协商。
1C.周期性地,每次规定的持续时间,例如,TDEV-PLATFORM-LAST-REG,为 从所述设备利用相同RI完成上一次注册协议时起耗费的时间。
1D.周期性地,每次规定的持续时间,例如,TDEV-PLATFORM-LAST-REPORT, 为所述设备上一次向相同RI验证了其平台完整性状态时起耗费的时间。
2.如果以及当实现所述RI平台完整性验证过程(即步骤750-754)时, 可以通过以下一个或多个来执行。
2A.每个设备一次,在与特定的设备进行第一次注册之前。在这种情况 下,所述设备在第一次注册之前将接收所述RI的TCG证书一次,然后所述 设备通过绑定所述证书信息与TPM密钥来保护所述RI的证书信息在其拥有 的TPM下面。所述设备稍后解开存储的TCG证书,并周期地或者基于一些 事件验证其已经接收的所述RI的TCG证书是否仍然是有效的,例如通过与 OCSP CA协商。
2B.在任何时候RI从所述设备接收指示,所述设备希望RI验证其对所 述设备的完整性状态,或者作为独立的消息或者作为修改的ROAP协议消息 的一部分。
2C.周期性地,每次规定的安全持续时间,例如,TRI-PLATFORM-LAST-REPORT, 为所述RI上一次对所述设备验证了其平台完整性状态时起耗费的时间。
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与RI 904之间使用分别来自ROAP协议的TCG技术 (即利用OCSP应答器/PCA 906)交换有关完整性的信息的方法900的流程 图。注意到在方法900中,相同实体906被描述为用于DRM处理的PCA以 及用于TCG处理的OCSP应答器。在方法900中,在ROAP 4传注册协议 之前执行平台完整性验证(由虚线矩形所示)。在注册协议之前执行平台完 整性验证是有用的,因为注册协议不是常常执行,并且平台完整性验证处理 花费一些时间才能完成;如果对每个消息执行平台完整性验证,系统的整个 操作可能不必要地减缓。所属技术领域的专业人员可以假定在执行平台完整 性验证之后,RI仅仅接收一个设备问候消息,由于其将指示可信设备。如果 由RI接收来自相同设备的多于一个设备问候消息,其可以是对DoS攻击的 指示。还可以结合认证协议与对象获取协议一起来执行平台完整性验证。
在用RI 904启动4传注册协议之前,设备902利用RI 904开始单独程 序组,以执行平台完整性的相互验证。设备902首先向RI 904发送其自己的 TCG证书(例如平台证书、TPM证书、一致性证书等等)或者包含或涉及 所述TCG证书的其它信息(步骤910)。可选地,设备902还发送请求到RI 904,以对设备902检查并报告其自己的平台完整性状态;这个请求是被包 含在设备证书中的。
RI 904请求PCA 906验证设备的TCG证书(步骤912)。PCA 906响应 于RI的请求,并发送有关设备的TCG证书的信息(步骤914)。
RI 904请求设备902报告设备902自己的平台完整性状态标志(步骤 916)。此外,如果设备902已经在步骤910中请求RI 904验证并报告其平台 完整性状态,并且如果RI 904希望并能够对所述请求表示感谢,在步骤916 中,RI 904对设备902发送其自己的TCG证书或者包含或涉及所述TCG证 书的其它信息。如果RI 904不能或不希望对对所述请求表示感谢,其发送“不 感谢”消息到所述设备。RI 904可以因为许多理由不响应所述请求,包括资 源受限的RI(即所述RI已经没有充分的可用资源去响应所述请求)或者设 备可信性检查失败。所述设备可以依据设备对所述RI具有的置信程度中断 所述协议;如果所述设备信任RI,其或许继续所述协议,即使RI拒绝响应 所述请求。在接收来自RI 904检查平台状态的请求下,设备902检查其自己 的平台完整性状态(步骤918)。
所述设备902请求PCA 906验证RI的TCG证书(步骤920)。在这种 接收来自设备902的请求的情况下,PCA 906返回有关RI的TCG证书的信 息(步骤922)。设备902发送其平台完整性状态标志到RI 904(步骤924)。 如果RI 904接收到来自设备902检查其完整性状态的请求,并且如果RI 904 希望并能够对所述请求表示感谢,RI 904检查其自己的平台完整性(步骤 926)。RI然后返回平台完整性状态标志到设备902(步骤928)。有关RI完 整性检查的可选步骤可以以任何次序执行;那些步骤不需要与如图9所示的 设备完整性检查有交叉。另外,RI可以启动其自己的完整性检查。此外,如 果RI由于任何可能的理由而拒绝完全地响应对其自己的TCG证书信息的请 求,其可以以合适的方式对设备指示这种事实,例如在步骤922中。
方法900使设备902与RI 904能实现相互的平台完整性验证。在这种验 证下,设备然后可以开始ROAP注册协议。在图9中示出的对注册协议的步 骤(步骤930-940)与如上所述的方法200的步骤210-220是相同的。注意 到可以在定期的间隔触发或者重复这些过程。
改变对ROAP注册协议的完整性验证
在另一个具体
实施例中,图10示出了一种方法1000,其中设备1002 与RI 1004交换有关完整性的信息,此外利用OCSP应答器/PCA 1006的业 务。在方法1000中,修改了ROAP注册协议的现有设备问候与RI问候消息, 以把TCG证书与请求二者传送到对方,用于平台完整性验证。
设备1002发送修改后设备问候消息到RI 1004(步骤1010),包含设备 TCG证书与可选请求以报告其平台完整性。RI 1004把设备证书转发到PCA 1006,以用于验证(步骤1012)。PCA 1006然后把设备TCG证书返回到RI 1004(步骤1014)。RI 1004用修改后的RI问候消息响应设备1002(步骤 1016),该消息选择性地包含RI的TCG证书。
其次,设备1002选择性地发送请求到PCA 1006,以检查RI的TCG证 书(步骤1018)。PCA 1006检查RI的证书,并把结果报告回到设备1002(步 骤1020)。设备1002检查其自己的完整性状态(步骤1022),并对RI 1004 报告完整性状态(步骤1024)。
如果设备1002已经请求RI 1004报告其完整性状态,RI 1004执行平台 完整性检查(步骤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 DRM 2.0规范假定,没有建议如何有根据地实现这种假定,可以 绝对信任DRM用户代理SW(或者在本发明中使用的术语,设备DRM SW) 以及RI(或者RI的DRM SW)。在OMA DRM 2.0规范中的认证协议仅仅 规定了在实体之间的实际的认证过程,也就是已经认为是可信的。由于明显 的理由,这种暗示的SW信任假定实际上不能被自动地假定,缺少实际的步 骤以实现并验证它们。在本节中描述的方法涉及这种具体的步骤。
图12是用于应用连同ROAP RO获取协议的DRM SW检查的方法1200 的流程图。该方法1200利用设备1202、RI 204以及OCSP应答器/PCA 1206。 首先,PCA 1206与设备1202和RI 1204通信,以执行平台完整性检查与 ROAP注册协议(步骤1210)。设备1202和RI 1204执行相互的平台完整性 检查、单向的DRM SW完整性检查或相互的DRM SW完整性检查(步骤 1212)。
RI 1204发送请求到设备1202,以检查并报告设备的DRM用户代理 (UA)SW完整性(步骤1214)。设备1202检查其最后的DRM UA SW完 整性(步骤1216)。设备1202选择性地发送请求到RI 1204,以检查并报告 RI的DRM SW完整性(步骤1218)。如果被请求,RI 1204检查其最后的 DRM SW完整性(步骤1220)。设备1202发送设备DRM SW完整性状态标 志到RI 1204(步骤1222)。如果预先地请求,RI 1204发送RI DRM SW完 整性状态标志到设备1202(步骤1224)。注意到对可选RI完整性检查的步 骤可以任何次序来执行,并且不需要与如图12所示的设备完整性检查有交 叉。
注意到方法1200可以改归为用于在设备与CI之间的相互的DRM SW 完整性验证,代替示出的设备/RI交互。在步骤1210-1224完成时,例如, 设备1202可以在步骤1226与1228中开始2传RO获取协议,如上述结合 图3的步骤310与312相同。还注意到尽管所述方法1200是结合RO获取 协议示出的,但是其可用于结合任何其它ROAP协议,但是为了最小化与方 法1200有关的开销,其可以仅仅用适当选择的ROAP协议子集在任何给定 时间来执行。对于实际的OMA DRM系统实现,如上用于建议的平台和/或 DRM SW完整性验证过程的一些条件或者触发机制可以包括:
1.设备DRM SW完整性验证过程可以由以下的一个或多个来触发。
1A.在设备希望启动新的2传ROAP注册协议、2传加入域协议、或者 2传离开域协议之前。
1B.周期性地,每次规定的持续时间,例如TDEV-DRM-LAST-ROAP,为设备 上一次用相同的RI完成了2传ROAP注册协议、2传加入域协议、或者2 传离开域协议经过的时间。
1C.周期性地,每次规定的持续时间,例如TDEV-DRM-LAST-REPORT,为设 备上一次向相同的RI验证并报告了其DRM SW完整性状态经过的时间。
1D.无论何时设备更新其DRM SW时。
1E.无论何时更新或者改变平台SW时。
2.可以由以下的一个或多个执行RI DRM完整性检查过程。
2A.在任何时候RI从设备接收指示,该指示为设备希望RI向设备验证 其DRM SW完整性状态,或者作为独立的消息或者作为修改后ROAP协议 消息的一部分。
2B.周期性地,每次规定的持续时间,例如TRI-DRM-LAST-REPORT,为RI 上一次向设备验证并报告了其DRM SW完整性状态经过的时间。
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 DRM 2.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密封的签名与绑定操作用来 保护在多个消息中的信息的保密性与完整性,其包括4传ROAP注册协议。 在方法1300中,设备1302与RI 1304每一个密封地签名选择的有关ROAP 的信息组,使用两组存储密钥绑定所述信息,每组存储密钥在4传注册协议 的过程中或者发送(到另一方)或者接收(从另一方)。
所述设备1302首先用加密密钥K_DEV_STO_SEAL与设备特定的 AIKK_DEV_AIK密封地签名设备ID信息元素(在OMA DRM范例中是OMA DRM公钥的SHA-1散列)(步骤1310)。这个信息被绑定(使用非对称加密) 到其它信息,以用于具有存储密钥K_DEV_BIND_A的设备问候消息(步骤 1310)。设备问候消息然后从设备1302被发送到RI 1304(步骤1312)。
通过密封地签名诸如设备ID的信息并绑定包括设备问候消息的其它信 息,设备1302可以建立策略,即只有当设备问候消息将被发送时以及如果 设备1302从它们的保护存储器恢复(即开封签名与解开)先前密封地签名 与绑定的信息,比较它们与所述DRM SW可以使用的这种信息元素的当前 值,并验证当前值的真实性与完整性。注意到仅仅作为例子给出了在这个方 案中密封地签名的比较绑定的信息元素的选择。其它信息元素可以被密封地 签名和绑定在不同的组合中,对本发明的操作不起影响。其它组合可以源自 于诸如系统时间、在消息中的任何信息元素、算法与现时的项。保护现时的 一个理由是确定所述特定现时是否是真随机的,如一些随机数发生器是特别 是被有害地损害的可以重复相同式样并产生相同号码作为在未接受的短时 间内的输出。
一接收到设备问候消息,RI 1304就用其绑定密钥、K_RI_BIND_A绑定 包含于设备问候消息中的信息。这个步骤允许对密钥信息的安全的、完整性 保护的存储,所述密钥信息是所述RI 1304从设备1302接收的。可选地,所 述RI 1304还可以从设备问候消息提取设备ID(或者其它信息元素),以及 使用所述AIKK_RI_AIK与加密密钥K_RI_STO_SEAL分别密封地签名信息 元素。
RI 1304用加密密钥K_RI_STO_SEAL与AIKK_RI_AIK密封地签名所 述RI ID与RI URL信息元素(步骤1316)。RI 1304还用存储密钥 K_RI_BIND_A绑定包含于其RI问候消息中的其它信息(步骤1316)。RI 1304 然后发送RI问候消息到设备1302(步骤1318)。
只有当如果RI 1304首先从保护的存储器恢复(即,开封地签名与解开) 先前密封地签名与绑定的信息时,RI 1304发送RI问候消息到所述设备1302, 把恢复后的签名和信息与RI DRM SW可能使用的这种信息元素真实的当前 值比较,并验证当前值的真实性与完整性。
一接收到RI问候消息,所述设备1302就用第二绑定密钥即 K_DEV_BIND_B绑定包含在RI问候消息中的信息(步骤1320)。这个步骤 允许对密钥信息的安全的、完整性保护的存储,所述密钥信息是所述设备从 所述RI 1304接收的。可选地,设备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然后发送所述注 册请求消息到RI 1304(步骤1324)。如果设备恢复(即开封签名与解开)先 前密封地签名与绑定的信息,设备1302仅仅发送注册请求消息,比较恢复 的值与在DRM SW存储器中使用的当前临时值,并验证当前值的真实性与 完整性。一接收到注册请求消息,RI 1304用绑定密钥K_RI_BIND_B绑定 来自注册请求消息的信息(步骤1326)。
RI 1304用K_RI_AIK与K_RI_STO_SEAL密封地签名所述密钥、证书 链与RO(步骤1328)。RI 1304然后用绑定密钥K_RI_BIND_A将上述绑定 到包括在注册应答消息中的其它信息(步骤1328)。RI 1304然后发送注册应 答消息到设备1302(步骤1330)。如果RI恢复(即开封签名并解开邦定) 先前密封地签名与绑定的信息,RI 1304仅仅发送注册应答消息,比较恢复 的值与在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参数的修改后设备问候消息格式
参数 强制或可 选 注释(基于OMA DRM 2.0ROAP设备问候消息的改 变) 设备TPM能 力指示符 (DTCI) 可选 新参数:1比特指示符(用于设备TPM的缺少或者 出现),或者指示关于所述设备TPM能力的更多信息 的更多比特。 版本 强制 未改变。 设备ID 强制 格式尚未改变,但是使用由设备TPM的EK证书或 者设备TPM的多个AIK证书之一的设备TPM计算 的SHA-1散列。 支持的算法 可选 未改变。 扩展 可选 未改变。 签名 强制 新参数:在设备问候消息上使用RSA-PSS算法的签 名,直到排除签名参数,由设备的多个AIK私钥之 一签名,对于其所述RI已经预先获得公钥。
表13.修改的设备问候消息格式,在扩展中具有DTCI。
参数 强制或可 选 注释(基于OMA DRM 2.0ROAP设备问候消息的 改变) 版本 强制 未改变。 设备ID 强制 格式中未改变,但是使用由设备TPM的EK证书 或者设备TPM的多个AIK证书之一的设备TPM 计算的SHA-1散列。 支持的算法 可选 未改变。 扩展 可选 所有OMA DRM 2.0ROAP设备问候扩展元素,加 上包括指示设备的TPM能力的一个或多个比特的 DTCI元素。 签名 强制 新参数:在设备问候消息上使用RSA-PSS算法的 签名,直到排除签名参数,由设备的多个AIK私 钥之一签名,对于其RI已经预先获得公钥。
RI问候消息的修改及其推导
第一修改是增加新的RI TPM能力指示(RTCI),其是RI的TPM能力 的指示符,或者作为RI问候消息的现有扩展参数的新元素,或者可替换地 并优选地添加所述RTCI作为在RI问候消息的报头中的新的第一参数。这个 修改的优点是,其允许所述设备使用所述RTCI信息来估计RI的可信度,并 且在其与剩余ROAP协议过程中的所述RI的进一步交互中利用这种信息。
第二修改是使用RI TPM来提供用于会话ID的伪随机数。这个修改的 优点是,TPM提供了安全级很高的基于硬件的伪随机数发生器。使用所述 TPM来产生用作会话ID的伪随机数增强了协议的安全性。
第三修改是使用属于RI的TPM的RI TCG EK证书或者TCG AIK证书 来导出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 DRM 2.0设备证书的替代或者是添加其他内容。包含TCG证 书(诸如所述EK证书、AIK证书、平台证书或者兼容性证书)的优点是增 加设备的可信度。
第三修改是在可信RI锚点元素中包含RI信任的TCG CA的列表。包含 RI信任的TCG CA可以是对现有的OMA DRM 2.0 RI可信锚点元素列表的 替代或是添加其他。包含由RI信任的TCG CA的列表的优点是增加设备的 可信度。
第四修改是在扩展参数的设备详细资料元素中包含关于所述设备TPM 的信息。包括这个信息的优点是,增强了设备对所述RI的可信度。
第五修改是使用用于签名修改后设备问候消息的设备AIK来签名所述 签名。这个修改的优点是由于很好地保护了所述设备AIK的特性,增加了所 述设备和注册请求消息的可信度。
表16示出了用于修改后注册请求消息的格式。
表16.修改后注册请求消息格式
参数 注册请求 注释(基于OMA DRM 2.0ROAP注册请 求消息的改变)) 会话ID 强制 未改变。 设备现时 强制 格式上未改变,但是由设备TPM提供。 请求时间 强制 未改变。 证书链 可选 格式上无变化,但是仅仅列出TCG证书, 或者在格式中改变,列出了OMA DRM证 书和TCG证书二者。 可信RI授权 可选 格式上无变化,但是列出了有关仅仅作为 RI信任锚点的TCG CA权威的信息,或者 在格式上有改变,列出了OMA DRM RI 信任锚点和作为附加的RI信任锚点的 TCG CA权威二者。 服务器信息 可选 未改变。 扩展 可选 所有的现有OMA DRM 2.0注册请求扩展 元素。然而,如果所述设备具有TPM,那 么有关设备的TPM的信息(诸如制造商名 称、版本等)应该被包含在设备详细资料 元素中。 签名 强制 格式上无变化,但是使用在签名所述修改 后设备问候消息中使用的设备TPM的 AIK。
注册应答消息的修改及其推导
第一修改是使用RI TPM来提供用于会话ID的伪随机数。这个修改的 优点是,TPM提供了很高安全级的基于硬件的伪随机数发生器。使用TPM 来产生用作会话ID的伪随机数增强了协议的安全性。
第二修改是使用属于RI的TPM的RI TCG EK证书或者TCG AIK证书 来导出所述RI ID。这个修改的优点是EK证书和/或AIK证书很好地由所述 设备内部的TPM保护,并且从这些证书的任何一个导出所述DRM设备ID 增强了DRM设备ID信息的完整性。
第三修改是使用RI TPM来提供RI现时。这个修改的优点是,RI TPM 提供了适合于该现时的安全且可靠的伪随机数。。
第四修改是在可信设备锚点元素中包含设备所信任的TCG CA的列表。 包含所述设备信任的TCG CA可以是对现有的OMA DRM 2.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 DRM 2.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应答消息格式
参数 2传 成功 2传 不成功 注释 状态 M M 未改变。 设备ID M - 未改变。 RI ID M - 未改变。 设备现 时 M - 未改变。 受保护 RO M - 未改变。 证书链 O - 未改变。 OCSP应 答 O - 未改变。 扩展 O - 未改变。 签名 M M 格式上无变化,但是使用RI TPM以在最近成功的注 册应答消息中使用的RI AIK来签名。无论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处理是从由2传注册、2 传加入域以及2传离开域组成的组中选择的。
21.根据实施例19或20所述的方法,其中所述方法在所述设备已经完 成关于RI的版权对象获取协议(ROAP)处理之后被周期性地执行。
22.根据实施例19-21中任一实施例所述的方法,其中ROAP处理是从 由2传注册、2传加入域以及2传离开域组成的组中选择的。
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中任一实施例所述的方法的集 成
电路。