CN102763111A - 用于可信联合身份管理和数据接入授权的方法和设备 - Google Patents

Abstract

本发明公开了可以提供可信开放式ID（OpenID）（TOpenID）与OpenID的整合的系统、方法和手段。经由UE上的可信权证服务器与网络应用功能之间的通信部分完成认证。UE可以获取平台确认数据（例如从UE上的可信平台模块）。UE可以接收响应于平台确认数据的平台验证。平台验证可以指示网络应用功能已经对平台确认数据和用户进行验证。平台验证可以指示平台确认数据与之前生成的参考值相匹配。

Description

用于可信联合身份管理和数据接入授权的方法和设备

相关申请的交叉引用

本申请基于并要求享有2010年1月22日提交的US临时专利申请No.61/297,446的优先权，其全部内容通过引用而被视为结合与此。

背景技术

用于认证（authentication）的可信计算（TC）的基本使用可以是向受例如硬件可信平台模块（TPM）保护的可信系统（TS）提供用于认证的凭证（credential）。作为主要的安全性特征，这可以将凭证绑定到特定TS。这种认证在无线网络中的应用可以是经由可扩展授权程序-传输层安全（EAP-TLS）的。对TS使用单个签约（sign-on）（SSO）可能会展现出潜在的安全性问题。

发明内容

公开了可以提供可信开放式ID（TOpenID）（正如这里所公开的）与开放式ID（OpenID）的整合的系统、方法和手段。

无线设备（例如用户设备（UE））的用户可以被认证（例如响应于来自网络应用功能的认证请求而被认证）。UE上的可信权证（ticket）服务器（TTS）可以获取（retrieve）平台确认（validation）数据（例如从UE上的可信平台模块）。平台确认数据可以包括对无线设备的信任度的测量。TTS可以发送平台确认数据到网络应用功能。UE可以接收平台验证，该平台验证指示网络应用功能已经验证该平台确认数据和用户。从网络应用功能接收到的平台验证可以指示由平台确认数据指示的系统状态与之前生成的参考值相匹配。

UE可以接收包括平台验证的权证。该权证能够被重复使用以执行后续的授权，而不需要对无线设备进行重新确认。权证可以包含时间戳、寿命期限等。

UE可以从网络实体中接收权证参考。该权证参考能够被用于从网络应用功能获得权证。包括在权证中的平台验证能够被重复使用以执行后续的授权，而不需要对无线设备进行重新确认。

附图说明

从以下以示例方式给出的描述并结合附图可以获得更详细的理解，其中：

图1示出了示例认证和接入系统；

图1A示出了与可信Kerberos有关的示例呼叫流；

图2示出了与可信OpenID有关的示例呼叫流；

图3A和3B示出了与可信权证服务器质询-响应有关的示例呼叫流；

图4示出了与可信OpenID有关的示例方法；

图5示出了与绑定UICC和WTRU有关的示例呼叫流图；

图6示出了组件之间的示例关系；

图7示出了作为信任评估器的PVE的示例；

图8示出了示例TVT登录；

图9示出了另一个示例TVT登录；

图10示出了另一个示例TVT登录；

图11提供与TVT登录有关的示例可视指示；

图12提供基于可信计算概念的在平台上对TVT的示例实施；

图13示出了BONDI与TOpenID的示例使用；

图14示出了使用BONDI与TOpenID的示例呼叫流图；

图15是示例OpenID协议的图；

图16是示例OAuth协议的图；

图17是示例的组合的OpenID/OAuth协议的图；

图18是使用Google OpenID的示例OpenID协议的图；

图19是使用Google API的示例OAuth协议的图；

图20示出了示例长期演进（LTE）无线通信系统/接入网；以及

图21示出了示例LTE无线通信系统。

具体实施方式

图1-图21可以关于可以在其中实施公开的系统、方法以及手段的示例实施方式。但是，虽然本发明可以结合示例实施方式进行描述，但是其不限于此，且应当被理解为在不偏离本发明的情况下，可以使用其它的实施方式或可以对所描述的实施方式进行修改和添加来执行本发明的相同功能。此外，附图可以示出呼叫流，其用于示例的目的。可以理解可以使用其它实施方式。此外，流的顺序可以进行适当改变。另外，如果不需要，则可以省略流，且还可以增加另外的流。

下文提及的术语“无线发射/接收单元（WTRU）”包括但不限于用户设备（UE）、移动站、固定或移动用户单元、寻呼机、蜂窝电话、个人数字助理（PDA）、计算机或能够在无线环境中操作的任意其它类型的设备。下文提及的术语“基站”可以包括但不限于节点B、站点控制器、接入点（AP）或能够在无线环境中操作的任意其它类型的接口设备。

本文可以使用OpenID协议作为示例认证和接入系统，且可适用于其它认证和接入系统。出于解释目的，在第三代合作伙伴（3GPP）环境中描述了多种实施方式，但是这些实施方式可以在任意无线通信技术中被实施。一些示例类型的无线通信技术可以包括但不限于全球微波互联接入（WiMAX）、802.xx、全球移动通信系统（GSM）、码分多址（CDMA2000）、通用移动电信系统（UMTS）、长期演进（LTE）或任意未来的技术。

图1示出了示例认证和接入系统100，包括但不限于客户端/用户平台110、身份提供方120、隐私鉴证（certification）机构（PCA）130以及服务提供方140。客户端/用户平台110、身份提供方120以及服务提供方140可以通过有线和无线通信系统的任意组合彼此通信。客户端/用户平台110可以与PCA 130通信，PCA 130可以与存储介质160通信，该存储介质160可以存储例如证明。

客户端/用户平台110可以是WTRU、基站、计算平台或需要认证的任意设备。客户端/用户平台110可以包括但不限于可信平台模块（TPM）115，该TPM 115提供用于客户端/用户平台110的数据的远程证明（attestation）和密封（seal）及绑定的能力。TPM 115可以是微控制器，其存储密钥、密码、数字证书并能够生成加密密钥。其可以被固定在主板上，或集成到系统芯片组，其可以用于可能需要这些功能的任意计算设备中。TPM 115可以保护其信息不受例如外部软件攻击、物理损害、窃听等。如果在启动序列期间针对组件所获得的测量值没有达到期望的参考测量（该参考测量使应用和能力（例如安全电子邮件、安全网络访问以及数据的本地保护）更安全），则拒绝针对TPM 115或客户端/用户平台110中的数据和秘密的访问。虽然这里论述了可信平台模块，但是，可以使用其它信任中心，例如移动可信模块。

TPM 115可以使用签注（endorsement）密钥（EK），例如2048位Rivest-Shamir-Adelman（RSA）公钥（public key）和私钥（private key）对，其在制造时在芯片上随机生成且不可更改。私钥可以被限制在芯片，而公钥用于对发送到芯片的敏感数据的证明和加密。EK的公共部分一般可以经由EK证书为PCA 130所知，以用于证明。当TPM 115需要向验证方（例如身份提供方）对自身进行认证时，其可以生成第二RSA密钥对，称为证明身份密钥（AIK），将AIK公钥发送到PCA 130，并依据对应的EK认证该公钥。如果PCA 130发现该EK处于其列表中，则PCA 130发布关于TPM 115 AIK的证书。TPM 115然后可以将该证书提供给身份提供方120并对其自身进行认证。

AIK（至少嵌入到AIK中的身份）可以表示这里所描述的权证的至少一部分。权证中的AIK的使用可以由TPM 115来限制。间接方式，称为证实密钥操作，可以被使用，其中标记（signing）密钥由TPM 115生成并通过用AIK来标记该密钥而被证实（certify）。该密钥可以称为证实的标记密钥（CSK）。CSK和AIK与证明AIK有效性（validity）的PCA一起可以构建这里所述的权证的一部分。

客户端/用户平台110可以包括可信权证服务器TTS 150，其生成用于服务接入的凭证或权证。当提到与这里的可信OpenID有关的权证服务器时，该参考可以用于可信权证服务器。TTS 150可以认证用户。TTS 150可以例如使用平台证明的可信计算方法来向身份提供方120确认客户端/用户平台110以及自身。由于安全性信息和操作可能集中在TTS 150中，因此其需要是可信的以合适地处理AIK证书和CSK而并不将它们复制（proliferate）到其它平台；保护权证和凭证；保护在经用户授权的凭证上的安全性操作；提供整合到公共网络浏览器并由其访问的安全选项；以及收集、处理并发送平台确认数据。

用户可能需要选择PCA 130来证实在TPM 115中生成的AIK。PCA 130可以保持与身份相关的信息，并且需要采取契约性测量以确保不公开该与身份相关的信息。当在PCA 130处证实AIK之后，用户可以选择身份提供方120来掌管（host）所要求的身份。所要求的身份可以通过由用户选择的统一资源标识符（URI）来表示。为了注册这种要求的身份，可以需要用户向身份提供方120提供有效的AIK证书。

可以给身份提供方120展示最少量的身份相关信息。用户可以决定在PCA 130处掌管的哪些信息可以被展现给身份提供方120。可以需要采取契约性测量来确保双方之间的协调，否则，无赖（rogue）PCA能够证实属于不同用户的凭证。由于PCA 130可能不会将用户的真实身份展现给身份提供方120，因此身份提供方120可能不能将不同的请求关联到单个身份。

将所要求的身份解决（resolve）为真实身份的能力可以被限制在PCA130。这可以通过保持将EK证书映射（唯一的）到AIK的安全数据库来实现。在AIK证实期间使用的EK证书允许TPM 115的标识，以及进而允许客户端/用户平台110（例如，假定一个用户具有到平台110的物理接入，这可以由用户来确定）。

服务提供方140可以使身份提供方能够登录站点。例如，服务提供方140可以在扉页（front page）上具有OpenID登录标识。可以需要由用户/客户端使用的身份提供方120处于服务提供方140的已知以及可接受的身份提供方的列表中。

联合身份或单个签约（SSO）方案可以提供用户友好型方法，以使用户能够使用单个凭证登录到一些安全站点。虽然实施联合身份方案的一些形式是可行的，但是本文提供使用OpenID的可信概念的概要作为示例。其它方法，例如使用可信计算技术和在用户、设备和网络间的绑定认证的对应用和基于互联网服务的单个签约（SSO）接入可以被应用。

OpenID可以允许使用不同的认证码法来对用户进行认证。为了在OpenID提供方处要求身份，可以使用若干方法。一种方法可以是使用登录形式，其中用户提供密码。

该登录可以由基于TPM的登录过程来替代。用户可以注册紧密绑定到他/她的特定平台（例如TPM）的身份。如果用户决定使用该身份来登录，则OpenID提供方可以通过质询来让他提供正确的凭证。在这种情况中，该凭证可以包括TPM生成的权证，例如凭证链。这可以允许用户不需要OpenID提供方处的密码就能登录。用户计算机处的本地密码可以用于保护身份不受本地攻击。

登录可以与特定平台的完整性验证相结合。通过使用对系统配置值的TPM标记陈述，OpenID提供方可以将被报告的系统状态与之前生成的参考值进行比较。该过程可以允许信赖的客户端登录并要求身份。通过将认证数据绑定到特定平台以及预定义系统状态（可以认为是可信赖的），相结合的认证和证明可以允许进行精细（fine grained）的接入控制。这可以允许实现可以需要系统的增强的安全性（security）和安全（safety）的OpenID的新使用情况，且因此不允许导致不信赖系统的修改。虽然这里描述的实施方式基于TPM，但是其它可信系统的变形也是可能的，例如移动对移动（MTM）或可信环境。

可信Kerberos（TKerberos）概念可以依靠两种服务器，例如认证服务器（AS）和/或权证许可服务器（TGS）。这些服务器的每一个可以发布权证。每个权证可以包括两个部分。例如，一个部分可以针对下一个目标服务器而被加密，且由此不可以由客户端进行解密。该部分可以包括会话密钥，且可以通过下一个通信步骤被使用。该会话密钥可以在权证的第二部分中针对客户端而被加密。如果客户端能够解密该第二部分，则客户端可以获得该会话密钥以请求下一个权证。

举例来讲，TKerberos可以在以下阶段被执行。例如，权证许可权证（TGT）可以被请求和/或从AS被接收并被存储以供将来使用。会话密钥可以被解密，以对用于服务权证（ST）请求的认证数据进行加密。TGT可以与加密后的认证码（authenticator）一起被发送到TGS。ST可以从TGS中被接收。会话密钥可以被解密，以对用于服务请求的认证数据进行加密。ST可以与加密后的认证码一起被发送到服务提供方。

TKerberos协议可以使用TC。这种设计可以具有目标，例如用于通过提供例如将权证经由TPM紧密绑定到用户权证服务器（TS）的方式来增强安全性，和/或保护用户接入服务的隐私。

AS可以执行PCA的任务和/或TGT可以用作AIK证书。TKerberos中，权证获取过程可以包括两个部分，以允许平台预先缓存权证并针对服务接入对权证进行个性化。

包含在服务器侧的安全性中的是用户系统的证明。当用户想要获取ST来接入服务时，TGS可以质询用户以远程证明系统一致性（conformity）。因此，处于证实的系统状态中的客户端能够接入服务。图1A示出了与可信Kerberos有关的示例呼叫流。TGT可以通过具有要求的TGT身份和服务请求的TCTicket而被增加，其可以由TPM标记。

如图1A所示，客户端30、AS 40、TGS 50以及服务提供方60被配置用于彼此间的通信。在10，客户端30可以获取TGT。例如，客户端30可以从本地缓存载入TGT和/或从AS 40获得TGT。客户端30可以向AS 40做出TGT请求13。因为可以使用AS 40公钥对客户端的真实身份信息进行加密，因此其可以被保护。在15，AS 40可以将TGT响应返回到客户端30。可以使用TPM的公共EK对来自AS的TGT响应进行加密。

在17，客户端30可以获取ST。在17，客户端30可以从用户获得身份（AIK）密码，使用TPM创建TCTicket，和/或引用（quote）系统状态。在18，客户端30可以使用ST请求来获取ST。当客户端30使用TGT来从TGS50请求ST时，可以通过来自TGT的会话密钥对该通信进行加密。TGS 50可以在19检查TGT，在20检查系统状态的完整性，在21检查TCT和/或在22对用于客户端TPM的ST进行加密。通过展示会话密钥和/或允许TGS对客户端提供的数据进行解密，TGT可以由TGS 50来进行解密。通过使用一次性密钥对会话密钥进行加密，可以以加密的方式将响应绑定到TPM，该一次性密钥被绑定到来自TCTicket的证实的标记密钥（CSK）并由TPM保证其安全性。

拥有TPM和针对TPM中的密钥使用的凭证的用户可以对ST进行解密由此使用该ST来接入服务。例如，如图1A所示，在25，客户端30可以请求服务。在26，如果被加密，则客户端30可以解密该ST，并将该ST提供给服务提供方60。在27，服务提供方60可以检查ST，且在28，如果ST有效，则提供被请求的服务。

可信权证的概念的可以包括对在权证获取过程中的客户端的证明。向TGS的证明可以被描述为安全性的增加。这可以以特定应用的形式来提供改变。该改变可以应用到可信OpenID概念。例如，一种这样的改变可以是经由证明和/或潜在纠正（remediation）对TGS发布的ST和/或客户端状态进行个性化（individualize）。也就是说，可以使TGS能够执行可以允许特定状态中的客户端接入特定服务的策略。另一种这样的示例可以是允许TGS在客户端接入之前自己确认该服务，例如通过针对服务器状态的证明来质询该服务器。由此，TGS，或可信OpenID情况中的OpenID提供方，可以用作调解方（mediator），其确保相互接受和/或信赖状态中的客户端和服务器进入通信关系。如果存在多个客户端，则这可能导致在服务上的过多的负载，这在一些情况中可能适用。通过例如偶尔确认服务等方式，可以减轻负载。在3GPP中的机器对机器（M2M）通信中可能存在类似的问题。例如，半自发确认M2ME而不改变已有网络的基础结构可能存在问题。展现的可信身份管理（IdM）的概念可以是用来使运营商的常规认证授权记账（AAA）基础结构能够用于该目的的构造块。远程认证拨号用户服务（RADIUS）等的可信版本可以被应用。

可以提供用于可信开放式ID（TOpenID）的系统和方法。可信OpenID实体可以包括：1）例如接入服务的用户；2）OpenID提供方；3）用于证实来自用户的TPM的AIK的PCA；和/或4）使用OpenID认证的服务提供方。

图2示出了与可信OpenID有关的示例呼叫流200。呼叫流200可以是可在使用例如可信OpenID接入服务时执行的协议。如这里所述，客户端/用户或用户平台210、服务提供方215以及身份提供方220（显示为示例OpenID提供方）被配置用于彼此间的通信。当使用可信OpenID时，客户端/用户平台210可以建立与服务提供方215的初始连接。客户端/用户平台210可以使用其网络浏览器225经由访问网页消息227来访问服务提供方的网页（标识为索引.jsp 235）。如果客户端/用户210想要使用例如用户的OpenIDURI来登录，则服务提供方215可以连接到给定URI并由此获取掌管要求的身份的OpenID提供方220的地址。在服务提供方215处的索引.jsp页235可以经由OpenID登录形式消息229请求URI，并经由OpenID身份消息231获取掌管要求的身份的OpenID提供方220的地址。

服务提供方215然后可以尝试形成与OpenID提供方220的关联。根据OpenID协议，服务提供方215可以经由关联消息241与OpenID提供方220相关联。这可以包括经由关联消息243的对请求、要求的身份和/或返回URL的安全交换，如果认证成功，服务提供方215和/或OpenID提供方220可以发送重定向消息247到客户端/用户平台210。这在服务提供方215处（例如通过消费方-重定向.jsp 240）来执行，和/或在OpenID提供方220处（例如通过提供方.jsp 245）来执行。在关联之后，客户端/用户平台210可以被重定向到OpenID提供方220的提供方.jsp网页245（例如经由到OpenID提供方的重定向消息249）。重定向地址可以从用户提供的标识符中获取，这可以确保被重定向到OP页的客户端/用户平台210与提供标识符的是同一个实体。可以经由HTTP重定向来执行该重定向，HTTP重定向可以直接将浏览器重定向到OP登录页。

客户端/用户平台210然后可以被认证。OpenID提供方220可以从提供方.jsp网页245转换到提供方-授权.jsp网页255以对客户端/用户平台210进行认证。可以给客户端/用户平台210提供提供方-授权.jsp网页255，请求认证。用户可以通过点击提供方-授权.jsp网页255上的链接而发起请求。这启动新的后台线程，例如TT验证方258，其经由质询消息252质询权证服务器250。提供方-授权.jsp网页255将客户端/用户平台210重定向回到提供方.jsp网页245。提供方.jsp网页245等待TT验证方258完成并评估质询答复消息254中提供的质询的结果。如这里所述，可信权证服务器（TTS）（例如权证服务器250）可以使用TPM功能来生成包含权证的合适答复，和/或可以与TPM 270、PCA 275和/或可以保存例如鉴证的存储介质280进行交互。协议的其它部分可以使用OpenID协议。由于认证令牌可以被修改，OpenID提供方220和/或客户端/用户平台210可以使用由TPM生成的TCTicket。

假定认证成功，客户端/用户平台210可以被重定向到服务提供方。提供方.jsp网页245可以发送重定向消息262给客户端/用户平台210。重定向消息262可以经由到服务消息264的重定向将客户端/用户平台210重定向到在服务器提供方215处的消费方返回url.jsp页265。消费方返回url.jsp页265可以检查重定向来自相关联的OpenID提供方220，并经由服务消息267许可对客户端/用户平台210的接入。

图3A和3B示出了与权证服务器305和权证质询方310之间的可信权证服务器质询-响应有关的示例呼叫流300。存储介质320和TPM 325可以被使用。权证服务器305可以作为客户端上的服务应用来运行。权证服务器305可以在预定义端口上侦听并等待质询。一旦接收到质询消息327（包括用户想要在例如OpenID中使用的身份，和在服务提供方处发出的服务请求），则需要用户允许使用答复消息329进行质询。用户可以有拒绝质询的选项。如果拒绝，则OpenID认证失败。

如果质询被接受，则提示用户输入用于对应于给定身份的AIK的密码，以及通过在权证服务器305处输入存储根密钥（SRK）密码来认证TPM 325的使用。SRK然后可以被包含在能够接入TPM安全密钥的TPM命令中。权证服务器305然后可以尝试从证书存储介质320中获取用于该身份的之前获得的证书，例如AIK证书（总体示为335），其可以用于这里所述的系统状态信息获取345和/或TCTicket生成350。证书可以来自与PCA（例如PCA315）的之前的AIK鉴证，且可以从系统上的本地证书存储（例如鉴证存储介质320）获取。如果在本地存储中证书不可用（或本地存储中用于AIK的证书已经期满或无效），则可以从PCA 315请求由AIK表示的用于身份的另一个证书。如果在证书存储介质320中不能找到证书，则用户可以选择连接到PCA 315，以经历AIK鉴证过程和/或获得用于AIK的证书。用户可以提供TPM 325的正确的拥有者密码。这可以防止TPM 325拥有者以外的人创建无赖身份。权证服务器305可以将用户输入转发到评估密码的TPM 325。

响应于接受质询，权证质询方310可以创建随机现时（nonce）337。权证服务器305可以经由现时消息339从权证质询方310接收随机现时337。描述系统配置（包括现时）的平台配置注册（PCR）值的AIK标记的引用Q可以从TPM 325中被获取，做出关于系统状态的陈述（总体示为345）。

权证服务器305然后可以创建TCTicket（总体示为350）。TCTicket创建350可以包括TPM的密钥创建（例如RSA密钥对），其可以用于标记请求和/或身份。如这里所述，该密钥可以使用证实密钥操作用AIK来证实。也就是说，TPM可以使用用于该创建的密钥对的证实密钥功能来生成鉴证陈述和绑定，其中绑定指的是给AIK和/或来自PCA的AIK证书建造信任链。当创建的密钥被成功证实时，其可以被称为证实的标记密钥（CSK）。TPM中可以存在多个CSK和/或多个AIK（或在由TPM保护的安全存储中由TPM确保安全）。

验证TCTicket 350所需的信息可以被包含在TCTicket 350中，使得接收方（例如图3A和3B中的权证质询方310）可以轻松地验证TCTicket 350。与明文测量日志ML和/或引用Q一起，包含TCTicket 350的响应可以经由例如TCT、Q、ML消息352被发回权证质询方310。CH-RESPONSE和ACK（应答）消息（统称为351）可以是这样的协议：发送消息以通知接收方（例如权证质询方310）下一个消息可以包含TCTicket 350、所述引用和/或ML。

图3A和3B可以表示图2中的TT验证方线程258的内部操作。由于OpenID提供方可以同时处理多个请求，因此其可以是每个请求客户端获得新的、新近（fresh）和/或唯一的质询，以免重放攻击。

一旦经由消息355对TCTicket 350进行应答，权证质询方310可以具有以下数据：来自TPM 325的AIK标记的引用，包括作为防重放保护的现时337；明文测量文件；TCTicket 350，包含标记的身份串、标记的请求串、CSK的公钥部分、CSK的公钥部分上的AIK签名、和/或PCA 315发布的AIK证书。为了对客户端进行认证，权证质询方310可以不以特定顺序执行以下（总体示为360）：1）确定AIK证书（的时间戳）（有效性信息也可以被获取为例如使用计数器的值）；2）验证AIK证书上的PCA签名；3）验证TCTicket350中的CSK公钥散列（hash）上的AIK签名；4）验证TCTicket 350中的身份和服务请求上的签名；5）确认测量列表中的项；和/或6）验证实际（引用）（PCR）值对应于测量列表ML。在对AIK证书的确认中，验证的是本地客户端自身的受保护的计数器值是否没有达到在AIK证书中指示的“最大”数目。本地客户端的受保护的计数器值可以指示例如证书和/或openID客户端软件的安装数目。

如果在验证过程中的一项失效，则客户端不被认证。权证服务器305和PCA 315可以建立特定的凭证链，例如AIK证书-证实的CSK-标记的请求。验证状态消息365可以被发送给用户。这也可以通过例如图2中的重定向消息262来示出。在该示例中，消息262可以将用户的浏览器重定向到服务提供方的返回url，或者用户可以在服务提供方处被认证。如果上述认证失败（证书失效和/或系统完整性失效），则所述重定向可以将用户发送到OpenID提供方处的认证失败页。在认证失败的情况中，定制结果页可以在OpenID提供方处被创建。定制结果页可以显示失败原因。这可以包括向用户显示哪些模块或软件没有通过完整性检查和/或可以被补充（leverage）到向用户建议将他的系统带回到可信赖状态的下一个步骤的系统。

根据这里所公开的，针对与特定服务提供方215使用的每个不完全（partial）身份，可以调用一次PCA 275。在初始注册中，客户端/用户平台210可以将其平台身份与匿名的不完全身份相关联。PCA 275可以提供用于该匿名身份的证书和/或存储该匿名身份与平台身份的关联。该数据可以是高度隐私的，因此必须得到保护。与当前权证系统相比，PCA 275的定位可以允许附加选项。这里公开的信任模式和方法可以允许将PCA 275放置在身份提供方220以外的位置以及用户选择的位置。这可能不够隐私友好（privacy-friendly），因为用户必须信任身份提供方（IdP）选择的PCA。

明文测量文件可以被其它类型的文件替换，该其它类型的文件可以具有关于由本地客户端设备执行的测量的信息，例如为了机密保护而被加密的测量值（例如使用绑定到平台的密钥）；和/或概括个体测量文件的值。一个示例可以是多个个体测量文件，其指示例如一组组件的完整性（而不是单个组件的完整性）。这些组件可以例如属于可以一起体现本地客户端平台的特定功能和/或特性的群组。

依据权证服务器305与权证质询方310之间所使用的认证协议（例如OpenID IdP协议），可能将该协议缩小至质询响应协议。质询响应协议可以包括1）权证质询方310可以发送质询（id，req）和/或现时到权证服务器305，和/或2）权证服务器305可以用TCT、引用Q和/或测量列表ML来做出响应。这样的协议可以允许对在其它协议中通信的权证质询方310（例如在OP处）和权证服务器305（例如在客户端/用户机处）进行更容易的整合。例如，该整合可以使用HTTP协议来执行，该HTTP协议例如可以使用简单的质询/响应方案。

用户认证可以使用质询响应中的OpenID来进行（图3A和3B中所示）。用户可以输入用户密码。之前已经向OpenID注册了该用户密码，由此，相同的密码（如果包含在质询响应中）可以指示该用户是在第一次的情况中注册密码的同一个个体。用户密码可以指示一些种类的其它事实，例如从预先共享的秘密中导出的数据。

在TOpenID中，如这里所述可以实现用户认证和设备信任证明。用户认证可以被实现，是因为用户可以已经向OpenID提供方注册了用于用户设备的AIK和/或CSK的证书和/或硬绑定到用户设备的TPM。在质询响应步骤，用户可以发送用这些AIK和/或CSK的私钥标记的数据。因此，一旦这些密钥的公共部分被验证，和/或一旦验证用户使用已经预注册的相同的AIK和/或相同的CSK，则OpenID提供方可以知道使用设备发送质询响应的用户与向该OpenID提供方注册的用户是同一个用户。例如，用户设备在其上可以具有相同的硬绑定TPM。

可以实现设备信任证明。例如，设备信任证明可以被实现，是因为OpenID提供方可以验证PCR的TPM_Quote、测量日志、和/或权证的一部分（例如用户ID或请求）是否使用目前验证的AIK CSK来标记。设备信任证明还可以被实现是因为OpenID提供方可以验证PCR的TPM-Quote、测量日志和/或权证的一部分实际是否产生期望的比较结果。如果两者匹配，则OpenID提供方可以验证用户用于发送OpenID请求的设备实际上是可信赖的。根据一个示例，如果对用户和请求的验证被实现，但是PCR值和测量日志的比较失败，则OpenID提供方在指示设备可能被攻击且处于不同于期望的配置状态中之前，可以知道从预注册的相同设备中发送的信任相关数据。

TOpenID可以不违反OpenID规范，和/或TOpenID可以被整合到OpenID中而不改变OpenID规范。用于OpenID身份的一些认证选项是可能的且可以被实施。协议流可以被分成标准化流。协议流可以描述信赖方（RP）和IdP的交互，这可以通过间接通信进行。例如，RP和IdP的交互可以通过将用户的浏览器重定向到不同的网页和/或在消息的HTTP字段中传输必要数据来进行。

图4示出了与可信OpenID有关的示例方法。在401，403，405，407，410，411，413，414，415以及416，可以示出客户端的浏览器、OpenID IdP和/或RP的交互工作。在409，进行用户认证，但是可以故意不指定用户认证。OpenID可以不指定身份服务器验证用户拥有其URL所使用的方法。在一些情况中，该验证可以经由cookie来执行。服务器可以向用户提示用户是否希望验证消费方（consumer）的用户身份。

如图4所示，在401，协议流可以包括用户输入其身份URL。消费方可以取得身份URL。在403。消费方可以处理针对openid.server（openid.服务器）和openid.delegate（openid.代表）链接关系的文档。如果代表（delegate），则取得被代表的文档并将其解析（parse）以用于openid.server。在405，消费方可以生成与用户身份服务器共享的秘密，并对其进行缓存。在407，消费方可以建立用于检查的URL并将用户浏览器重定向到该URL。在409，可以确定服务器是否可以断定用户拥有URL。在410，如果服务器不能断定用户拥有URL，则如果消费方请求checkid_immediate（立即检查id），则服务器返回用于checkid_setup（设置检查id）模式的URL。在410，如果消费方请求了checkid_setup，则服务器可以返回取消。在409，如果服务器可以断定用户拥有URL，则在411，服务器可以将用户浏览器重定向到在具有标记的参数的消费方请求中指定的return_to（返回至）URL。在413，可以确定消费方是否为服务器对共享秘密进行了环城。如果消费方对共享秘密进行了缓存，则在414可以使用该秘密来验证标记的参数。如果在413消费方没有对共享秘密进行缓存，则在415消费方可以生成具有association_handle（关联处理）和服务器返回的签名的检查-认证请求。在416，服务器可以返回签名是否有效。

TOpenID可以在认证步骤中包括由IdP进行的平台确认数据和/或完整性检查。TOpenID中的认证可以被绑定到特定TPM（或例如单个平台），因为可以使用TPM绑定AIK来注册OpenID标识符。TPM和/或AIK证明过程的安全性特性可以保证标识符在另一个平台上不被使用。IdP进行的完整性确认可以确保正确的平台（或如果指定可信子系统，则包括可信权证服务器）在正确配置中运行。

上述方法可以应用于图2所示的TOpenID协议流。OpenID身份提供方（IdP）和/或用户系统可以包括使用TPM及其完整性确认协议执行认证步骤的能力。这些能力可以实施为客户端和/或服务器上的软件模块和/或库。例如，这些能力可以在客户端/用户平台210处和/或OpenID提供方220（例如TT验证方258、质询消息252、质询答复消息259、TPM 270、PCA 275和/或存储介质280）处被实施。OpenID的开放式的概念可以产生很多种不同的OpenID IdP实施。因此，OpenID IdP可以开发在它们中间进行区分的概念。OpenID IDP可以使用以对其进行区分的一个功能可以例如是对增强的安全性特征的断定。该断定可以向用户保证它们的（OpenID）身份被保护（例如如果其为HW绑定的话）。可以向用户保证该IdP可以使RP信赖从IdP接收到的信息。例如，使存储库（bank）或其它要求安全性的应用使用具有知晓安全性且被证实的OpenID IdP的白名单（whitelist）的OpenID。

用于实施TOpenID的一种方法可以使用第二种基于非HTTP的协议来执行平台确认。例如，使用第二种协议，质询消息可以从OpenID提供方220被发送到客户端/用户平台210，且响应可以被发回OpenID提供方220。这可以经由后台过程来执行，该后台过程可以将控制返回到OpenID提供方220的主认证过程。主认证过程可以开始于从客户端/用户平台210重定向到OpenID提供方220（如图2所示）。然后可以从OpenID提供方220到客户端/用户平台210执行HTTP重定向（如图2所示）。

依据服务器和/或用户设备的能力，不同的协议可以用于传输数据。

产生用于服务接入的凭证或权证的实体可以被整合在客户端中。这可以通过客户端中的可信功能实体（例如图2所示的权证服务器250）来执行而不需要降低TKerberos的安全性。权证服务器可以向OpenID提供方确认客户端及其自身。由于安全性信息和操作可能集中在权证服务器组件中，因此可以信任该组件合适地处理AIK证书和/或CSK。可以信任权证服务器来：不将AIK证书和/或CSK复制到其它平台，保护权证和凭证，保护用户授权的安全性操作凭证，提供将被集成到公共网络浏览器并由其访问的安全选项，收集、处理并发送平台确认数据，和/或基于用于标识重放攻击的现时的有效性来提供接入控制。

如这里所述，特定凭证链可以由权证服务器和PCA来建立。TOpenID中的凭证链可以是AIK证书-证实的CSK-标记的请求。

在TKerberos系统中放置PCA的实施可以包括以下内容。在OpenID提供方中包括PCA可以降低复杂度。这可以是经由网络形式的对向OpenID提供方进行注册的无缝替换。在TOpenID中，用户可以1）选择任意外部PCA，其AIK证书可以被TOpenID提供方接受，和/或2）使用由TOpenID提供方直接或间接提供的PCA功能。

由于其安全性架构，TOpenID可以减小对基于OpenID的系统的特定的威胁。在TKerberos中，AIK证书在客户端可能是不可见的而是在TGT中被加密，且可以由TGS解密。客户端可以知道AIK证书且AIK证书不具有例如可能威胁隐私的隐藏信息。OpenID实施可以向用户展现OpenID提供方登录形式。用户可以输入其凭证且OpenID提供方可以向客户端发送cookie。该cookie然后可以用于每个后续的启用OpenID的服务接入。这可能导致对OpenID协议的攻击的可能性，例如：1）对用于登录到它们的OpenID提供方的用户凭证的直接攻击（使用假OpenID提供方页进行钓鱼（phishing）可以暴露大量的用户凭证，允许身份偷窃），或2）涉及在认证后对客户端计算机的cookie进行重复使用、复制和/或偷窃的攻击，其可以导致身份失窃。通过使用可信OpenID可以减少攻击。由于用户密码可以是本地的和/或被提供给本地可信权证服务器，因此可以阻止凭证钓鱼。匿名身份可以被绑定到平台。也就是说，这些匿名身份不可以被复制到另一个设备。

在客户端平台上可能没有存储cookie。这可以阻止本地重复使用的威胁，例如在计算机由多人共享时。在一个示例中，如果用户A登入到其OpenID账户，并忘记退出，则用户B可以尝试使用存储的cookie来假扮用户A。通过将可信OpenID认证无缝整合到网络浏览器中可以防止该重复使用。当用户想要使用可信OpenID接入服务时，OpenID提供方可以针对权证服务器创建新的质询。用户可以从其可信权证服务器应用中看到提示，例如要求用户输入本地AIK密码的提示，这对答复质询是必须的。权证服务器不会存储该AIK认证秘密。如果在同一个平台的另一个用户B想要接入服务，则OpenID提供方可以再次质询权证服务器和/或用户B必须提供用户A的本地AIK密码（这不为用户B所知）。这可以需要使用一次性cookie，该cookie不会被存储在客户端平台上。

发布的cookie可以被加密，由此目标平台和/或用户可以对其进行解密并将其用作认证令牌。OpenID提供方可以使用公共CSK对cookie进行加密和/或将其发送到客户端侧的权证服务器。使用TPM，在需要时可以对cookie进行解密。该解密可以需要用户例如使用（本地）CSK秘密对CSK的使用进行认证。权证服务器可以确保cookie被加密存储并在需要时被解密。对加密的cookie的存储和/或使用的另一种实施可以是使用命令TPM-Seal（TPM密封）来存储cookie，由此在进行密封操作时将该cookie绑定到平台的完整性。在下一次获取之前密封的cookie值时，平台完整性可以被验证为与其在进行密封操作时的值相同。在该示例中，当平台完整性与其之前的值匹配时，可以获取密封的cookie值。

可信OpenID可以被扩展至可信Google API。组合OpenID与OAuth可以依赖OpenID认证过程，由此除了例如在OpenID提供方处的传统“登录”之外，不需要进一步的用户交互。

用户的TPM可以通过网络应用请求来标记由OpenID提供方提供的组合的OpenID/OAuth质询，而不是由TPM来标记OpenID质询。用户标识和授权，以及对数据接入的接受，可以由TPM安全地标记。如在可信OpenID环境中，用户的安全性可以通过以下来改进：1）将登录和授权绑定到硬件TPM，和/或2）包括OpenID/OAuth提供方进行的可选平台完整性验证，以防止在客户端上运行的恶意软件偷取敏感数据。完整性验证可以增加网络应用的安全性等级。对服务的接入可以被限制在处于已证明的完整性证实状态中的客户端。这可以允许建立用于安全性和隐私应用的新网络服务。该过程可以提供非抛弃（non-repudiation），例如OAuth接入令牌可以由TPM标记，这可以是被唯一标识的。这可以促进由网络应用的提供方执行的收费过程。签名可以允许网络应用提供方来证明用户请求并接入了该服务。

基于TPM的用户认证可以允许平台身份关联到OpenID身份。可以需要OpenID提供方保存针对给定平台的已注册身份的数据库。OpenID提供方可以通过给定平台凭证从攻击者中区分合法用户。当检测到来自另一个平台的登录尝试时，OpenID提供方可以：1）拒绝认证，和/或2）在合法拥有者下一次登录时通知其该身份。

TOpenID与OpenID/GBA认证方案的可能整合可以是给NAF/IdP配备TOpenID IdP的能力，以验证平台完整性值。来自NAF/IdP的GBA授权报头可以包括以串行化（serialize）形式的来自TOpenID协议的质询（例如id，req，现时）。一旦进行接收，ME/UE然后可以对该执行进行解串行化，并将其复用到可信权证服务器和GBA密钥导出功能，该功能可以用于计算授权摘要。随后，两者的返回值，例如来自可信权证服务器的标记的引用和ML以及来自GBA过程的摘要值，可以在HTTP响应消息中返回到NAF/IdP。

可以对认证和信任评估进行组合。该组合可以将特定UICC（例如GBA客户端）的使用绑定到单个平台。如果平台处于完整性证明状态，如果平台可以被认证（例如通过AIK），以及如果用户可以被认证（例如通过拥有UICC/GBA），则NAF可以授权OpenID标识符。这样的协议可以允许锁定用户，使用户与具有单个UICC的单个配置中的单个平台使用其OpenID标识符。

图5和图6是用于绑定UICC（例如与用户相关联）和WTRU以供OpenID使用的示例图。图5示出了示例呼叫流图。图6示出了组件之间的示例关系。实施可以确保与不可信WTRU元件（例如浏览器）的安全通信。参照图5，示例协议步骤可以包括以下中的一个或多个：1）用户可以建立到RP的连接；2）RP可以发起与OP/NAF的关联；3）RP可以将WTRU的浏览器重定向到OP/NAF；4）WTRU与OP/NAF之间的通信可以经由TTS，该TTS可用于认证（例如，TTS可以一起接收TOpenID质询与GBA质询）；5）TTS可以建立到UICC的安全信道；6）TTS可以将GBA质询转发到UICC；7）UICC可以如OpenID/GBA协议中一样计算摘要；7a）UICC可以将GBA响应发送到TSS（例如具有OpenID/GBA摘要）；8）TTS可以获取用于TOpenID协议的平台确认数据/证明数据，其中平台确认数据/证明数据可以包括对WTRU的信赖度的测量（例如用AIK标记的SML和PCR引用）；9）TTS可以以整理的响应对OP/NAF做出响应，该整理的响应包括UICC GBA响应和平台确认数据/证明数据；10）OP/NAF可以验证GBA响应并用平台确认数据/证明数据验证完整性（例如验证SML PCR引用与由OP/NAF之前接收的之前生成的参考值相匹配，这可以指示WTRU的当前系统状态与之前状态相匹配）；以及11）OP/NAF可以经由WTRU的浏览器将肯定断定发送到RP（例如，作为ME浏览器的到RP的重定向操作的一部分）。也就是说，NAF可以发送平台验证，该平台验证指示NAF已经验证了平台确认数据和/或用户。平台验证可以被直接或间接传送（例如平台验证可以包括WTRU/用户被授权接入信赖方（RP））。

TTS不必必须建立与UICC的安全信道。可以执行两个独立会话，UICC与OP/NAF之间的一个GBA会话和TTS与OP/NAF之间的证明会话。如果两个协议都成功，则OP/NAF可以发布肯定断定。在该并行的会话情形中，OP必须链接这两个会话（至少在内部），以将证明结果绑定到GBA协议的认证结果。

确认任务可能需要执行网络和设备上的大量资源。被确认的设备可以针对后续的认证过程或与网络组件的交互重复使用确认信息，例如不必经历新的确认过程。例如，从与网络的较早的确认会话中生成的确认信息可以被重复使用。可信权证服务器可以如下提供确认权证（或证书）。在设备向网络成功确认之后，MNO网络内的OP/NAF实体可以发布权证，其可以被传送到该设备，以用于经要求重新递送到其它网络实体，或其可以被参考，从而网络实体可以从OP/NAF实体中间接获得该权证。OP/NAF实体可以包括具有权证的信息，使得权证包括权证/设备信赖度的指示。例如，OP/NAF实体可以提供时间戳、起点时间戳、权证的寿命期限、权证的结束日期、使用参数限制等。时间信息可以使网络组件能够确定设备的信赖状态以及何时执行评估。接收权证的实体可以认为该信息符合与设备进行安全事务（transaction）的要求或可以依据设备中特定应用的信任要求执行重新确认。

这样的权证可以用于平台确认和管理。可以对权证进行完整性保护和/或机密保护，使得该权证被绑定到OP/NAF实体和设备，且使得该权证不可以由数据被绑定到的不同于设备或OP/NAF的实体所更改。设备中的可信环境（TrE）可以安全存储权证并在与网络的后续交互中使用该权证，而不需要执行重新确认。设备可以分配权证以向其它网络组件提供确认状态数据。设备可以传播权证的参考，其它网络实体可以从该参考中咨询OP/NAF实体以获得确认信息。

对于组合的TOpenID/GBA情况，可信评估器的位置可以改变，其中该可信评估器可以是例如从TTS接收测量并能够将该测量与参考度量进行比较以基于该评估得出对平台确认或信赖度的陈述的实体。

图7示出了在TOpenID/GBA情况中作为信任评估器的平台确认实体（PVE）的示例。图7包括平台确认实体（PVE 705）、BSF 710、UE 720、OP/NAF 730以及RP 740。有可能重新使用已经拥有信任评估的参考完整性度量的已有的网络实体，而不是在MNO网络内的OP/NAF实体中整合信任确认过程。这种示例可以称为平台确认实体，例如PVE 705。PVE 705可以被装配有参考度量且能够将接收到的确认数据与参考度量进行比较并发布关于设备信赖度的陈述。在该情形中，OP/NAF 730可以将内部网络中的确认数据转发到PVE 705，而该PVE 705可以执行信任确认。

可以通过可信第三方（TTP）来执行信任评估。如果MNO内部实体不可用于执行对接收到的确认数据的确认，则OP/NAF可以将该确认数据通过安全信道转发到外部可信第三方。TTP然后可以执行验证和确认并将关于平台信赖度的陈述发回OP/NAF。

在用户平台的成功认证和验证后，服务提供方（SP）可以发送标记的javaapplet到WTRU，其可以在WTRU的可信环境（TrE）中被安装。TrE可以，在在可信环境中安装java applet并答复针对安全UI的SP质询之前，例如经由来自SP的签名和/或证书或由IdP或可信第三方（TTP）提供的RIM证书来验证applet完整性。TrE可以使用安全UI来载入applet，向用户指示当前应用可以在安全环境中运行。该方案可以被保护不受假SP的侵害，例如SP可以被要求认证并向IdP证明完整性。该方案也可以被保护不受假TrE的侵害，例如通过IdP验证TrE完整性和功能并且如果检查成功则发布权证。

可以实施经过隔离/沙箱（sandbox）处理的网络浏览器。与典型的浏览器解决方案相比，该方案旨在网络应用（例如在线银行、网络邮件、视频流等）的发行方，并为他们的网络应用定义特定清单（manifest）。该数字标记的清单可以包括允许网络应用连接到的网站的列表以及应该运行网络应用的浏览器。该浏览器的可视化实体（例如到vm图像的URL）可以被定义在该清单中，且可以被实施为将网络应用与其它网络应用和/或主操作系统（OS）隔离。可以通过使用图形边界显示例如信任状态来表现（render）每个经过沙箱处理的网络应用。该概念可以使用XEN可视化来实现。WTRU可以使用TTS来执行平台证明，然后使用设备上的TrE（运行小的可信经过沙箱处理的Java applet的环境）来执行应用证明。注意TTS和TrE可以被建立于WTRU设备中的一些公共可信硬件组件之上，并使用这些公共可信硬件组件的功能。

安全用户界面（安全UI）可以需要TOpenID和OpenID以增加安全性。基础TOpenID协议可以从可信权证服务器中得到该协议的增加的安全性，该可信权证服务器可以收集设备完整性信息。OpenID IdP可以评估该设备完整性信息。如果在设备上运行的软件处于公知和可信状态，则认证可以成功。该认证可以绑定到由TPM存储并由PCA证实的AIK。AIK可以用于标记用于证明的PCR引用。认证可以被限制为在给定状态中使用给定平台（例如具有TPM的设备）的实施。

证明和完整性检查可以被限制在某些组件，例如TOpenID的安全操作所需的组件。在该方法中，设备可以被分成可信/安全部分和不可信部分。可信权证服务器可以运行为可信世界内的可信的且经过完整性检查的应用。对硬件（包括驱动器）的接入可以通过可信世界中的服务实例来保护。对设备能力的接入可以通过可以向不可信世界提供必要的API的这种服务实例来限制。这些API可以提供对设备能力的接入，并可以被配备有可以允许执行接入限制的安全性策略框架。

如果IdP进行的完整性检查和验证被限制在设备的某些部分，则用户可能需要与可信权证服务器确认OpenID ID的使用，以及确认该输入不可以由中间人或设备中的人/浏览器攻击中的人截取或重放。可信部分可以提供可信用户界面（UI），该UI可以保护输入并向用户指示他可以在安全模式中使用设备。示例的指示器可以是发光二极管（LED），其可以在设备（处理器）在可信模式中运行时被点亮。LED可以由可信或安全元件来控制。当用户将要输入用于OpenID权证的使用的凭证时，安全UI可以指示设备在安全模式中操作。设备（例如LED）可以处于连接到外部处理器接口的可映射地址空间，其可经由安全硬件接口被保护，其中接入可以被限制在安全和可信环境。

图形设备的受保护帧缓冲器的某些部分可以被使用。其它驱动器可以不被允许从设备存储器的该部分中写或读。安全/可信驱动器然后可以通过直接写入到显示帧缓冲器的方式来使用该帧缓冲存储器通过在设备的显示器上显示图形信息来指示安全UI的使用，从而阻止恶意软件显示“安全图标”。

可以用作用于OpenID认证的UI的浏览器可以被检查完整性并被整合到可信世界中。如果浏览器没有被包含在可信部分中，则每次使用用户OpenID登录就需要用户通过安全UI提供同意。如果用户想要使用OpenID标识符登录站点，则浏览器可以将质询转发到可信权证服务器。可信权证服务器可以将UI转换到安全UI并向用户显示同意界面，该同意界面可以要求用户与安全UI交互以完成认证。可信权证服务器可以生成响应并将其转发到OpenID IdP，绕过可能被攻击的浏览器。在可信OpenID过程中，可以保证WTRU的浏览器和用户界面的安全。

可信可视令牌（TVT）可以被使用。可信可视令牌可以包括以下技术特征的一个或多个的组合。

可视证明可以包括向用户显示一些可视信息，这些可视信息证明用户平台（用户交互的设备）处于可信赖状态。该可视信息可以包括秘密图像（例如为用户所知但不为其他人所知），其以加密形式存在于平台上，其中如果平台处于预定义状态，则允许解密。这可以称为密封。

可视证明可以通过额外的可视化方法而被扩大。例如，关于发生特定事务的数据（例如用户认证、支付数据等）可以被包含在该可视化中。这可以使获取和重放攻击变得更困难。

特许指示器（PI）可以是用于平台的安全输入路径（例如，密钥），其中平台内的端点是可信环境或安全元件，例如一些执行空间，其用于期望的事务时是可信赖的。

用户可以在其权限下通过质询-响应机制来控制平台的可视证明。用户可以在事务（例如认证、在线支付等）过程期间的某个点向其平台提出质询，平台可以使用可视证明对该执行做出响应。这可以使用特许指示器来实现。

特许指示器质询可以在事务期间被程序性使用，并可以与该事务相结合，由此不能回避该质询。

上述特征可以在平台中被结合以在在线事务中用作可信可视令牌（TVT）。TVT可以是例如可在软件可信环境中实现的或在硬件安全执行环境（例如智能卡）中实现的用户平台上的可信赖实体，其以预定义方式使用可视证明对经由PI提出的用户质询做出响应。TVT可以具有一个或多个以下特征。

向用户证明TVT可信赖状态的TVT可视证明可以在平台的主显示器上或另一个专用显示器上被显示给用户。

TVT可以为可视证明使用硬件保护（例如智能卡、TPM密封）的秘密。

TVT可以具有用于认证用户的接入方法，例如生物测定输入。

远程方可以确认TVT的可信赖状态，例如通过使用远程证明。

TVT可以确认平台的其它组件，例如浏览器或在线银行应用，并在可视证明中整合关于这些组件的信赖度的信息。

TVT可以访问专用于特定事务的数据，并能够以有意义且唯一的方式将这些数据加入到可视证明中。

由TVT在可视证明中显示的事物的基本形态可以包括以下中一个或多个，其在特定用途情况中根据需要可以被组合。

TVT可以显示与用户相关联的信息，例如用户登记的秘密、个人信息等。TVT可以显示TVT特定秘密，其可以是时间相关的。TVT可以显示事务特定数据，例如事务编号、事务数量、当前类型等。TVT可以显示用户通知，可以提示用户例如以保持特许指示器被按压的方式使用指纹读取器来授权事务。

事务中的TVT的基本用途可以是本地或到远程方的用户认证。该过程可以被称为“登录”，可以包括以下特征的一个或多个。

当用户希望登录到平台或远程服务时，用户可以打开登录应用或浏览到网络上的服务的登录页。用户可以按下PI并获得关于登录的可视证明。图8提供一种示例。

可视化的这种形式可以通过包括证明TVT状态的秘密图像而被加强。图9提供一种示例。

TVT可视证明的进一步安全性增强可以通过包括附加信息（例如随机出现的、难以删除的、新的、机器相关的、人可读的信息）来实现。图10提供一种示例。

用于用户登录的TVT的活动可以由远程方来触发，例如请求用户认证的网络服务。远程服务可以用信号向平台上的TVT通知其需要用户认证（例如经由相互认证的信道），在认证后TVT显示一般性登录通知。例如，用户可以按下PI，TVT执行其可视证明。用户可以例如使用生物测定输入（如在这里所述的直接登录变量中）进行本地认证。图11提供示例的可视指示。

图12以及下面的描述提供基于可信计算概念的平台上的TVT示例实施。以下可以包括作为示例的微软视窗（Microsoft Windows）网络域，但不限于这些实施。

以下的首字母缩写可以用于图12中以及以下描述。

TCB：可信计算基础

BIO：生物测定认证功能

RoT：信任根

MOD LSASS：修改的本地安全性权限子系统-用于本地和网络用户登录的Microsoft Windows组件

REQ：‘请求’

DEC：用于ENC的解密密钥

ENC：用于对TVT秘密数据进行加密的密钥

在系统启动时的安全或认证的起动进程中，平台的RoT可以测量和/或存储TVT应用的状态（1a），例如在平台的PCR（平台配置注册）中（1b）。TVT应用可以被包含在包括在运行时刻对TVT进行保护的可信环境中。测量工具以及RoT被包含在平台的TCB中（例如在被认为在系统操作期间是无条件安全的组件的集合中）。

当用户想要登录到使用该平台的网络域时，则域控制器可以从平台请求用户凭证（2）。TVT激活可以如这里所述在该时刻发生并且可以发起远程请求的TVT用户登录。用户可以被通知使用PI，例如在（3）处了解使用（seeuse）。PI信号可以被传输到包含在TCB中的某些PI功能。

PI功能可以解封TVT主解密密钥Dec（4）并发送Dec的解封请求到平台RoT，其引述TVT的状态。RoT可以检查该状态，并对Dec进行解密（5）（例如如果该状态是正确的（解封））。

Dec密钥可以是指被限制为在TCB内部使用的密钥层次（hierarchy）的部分的密钥，例如TPM密钥层次的密钥。Dec可被用于对使用对应加密密钥Enc进行加密的TVT可视证明种子（seed）进行解密。

PI功能可以命令TVT应用向用户进行可视证明（6）。TVT应用可以请求对TVT种子进行解密（7），这可以使用Dec来执行（8），且TVT种子可以被提供给TVT应用（9）。使用这些种子，TVT应用可以执行可视证明（例如使用生物测定输入BIO）（10），包括用于本地用户认证的请求。

用户可以认证BIO（11），且BIO工具可以向TVT通知认证成功（12）。

TVT可以从其用户账户数据存储装置中请求用户凭证，例如用于网络登录的用户名和密码（13）。该数据可以被解密并被发送到TVT，而TVT可以将该数据提供给登录应用LSASS（14），而LSASS可以将数据转发到网络域控制器。

TVT使用的秘密可以包括两种类别。

TVT种子可以包括秘密，TVT使用该秘密来向用户进行可视化并与远程方进行安全通信，该秘密可以包括以下中的一个或多个：用于可视化的种子；TVT个人秘密（例如专用于平台）；用于与其它实体进行安全通信的TVT凭证；用户定义的参数；每个应用的秘密；用户登记的秘密等。

用户账户数据可以表示与密码保险库类似的TVT功能。其包括但不限于以下中的一个或多个：生物测定用户参考数据；域远程服务和用户名列表以及关联性；用户凭证，例如密码或密码的散列值；用于对远程服务或域控制器进行认证的凭证等。

可以在RP和TTS之间进行相互认证。OpenID协议可以被定义为包括如何保证RP-用户界面的安全以及如何保护用户不受恶意RP的损害。当用户在RP将其身份（例如OpenID标识符）输入到登录区域时，恶意RP可以对OpenID协议施加威胁。虽然用户可以不知道正进行什么下层进程，但是用户可以被重定向到IdP页，其中用户的身份可以针对他使用OpenID访问的站点而被管理。在IdP，用户可以输入其凭证（例如密码）并可以被重定向。但是，当用户访问同样启用OpenID的另一页时，IdP可以不再次要求密码而是可以使用存储的cookie。恶意站点RP能够将用户重定向到外表令人信服的IdP，其可以是假的站点，目的是偷窃用户凭证（密码）。假IdP然后可以使用真实的IdP将用户登录到OpenID，用户不会感受到异常。攻击影响可以通过以下事实而被增强：IdP可以用作用户使用OpenID登录的站点的SSO点，因此攻击方可以从用户偷窃许多账户。单个恶意RP网站可以用于欺骗用户访问密码收集的假IdP页。

可以使用TTS进行RP认证。通过使用以下中的一个或多个可以减轻密码钓鱼攻击。

Microsoft信息卡可以用作凭证，例如，因此用户可以不需要输入可能被偷的密码。信息卡是Microsoft技术，其可以在屏幕上向用户显示可从中进行选择的一些‘卡’。用户可以选择卡来向服务进行认证。信息卡可以使用密码证据来提供拥有身份的证明。这些证据不可以重复使用，且不能够被重放，因此密码猎取站点进行的获取不可以产生对OpenID身份的接入。

每个RP可以在用户侧被认证。该认证可以以安全方式被执行，该安全方式不会干扰用户从OpenID中期望的SSO体验。在TOpenID中，TTS可以是用于验证来自RP的给定凭证的实体。当使用到RP的HTTPS连接时，TTS可以用作浏览器代理且可以截取从浏览器到启用OpenID的站点的呼叫。该截取机制可以识别在HTTP获取请求之后从RP发送到浏览器的页面中的登录形式。TTS然后可以请求域证书并检查其有效性。如果证书有效，则用户至少可以确保其访问的站点使用加密连接。安全插入层（SSL）证书的另外的特征（例如断定的身份）可以由TTS建立并检查。断定的身份可以是TTP保存公知页面的数据库或已知钓鱼、坏件等站点的黑名单，并给TTS提供这些站点使用的已知的所有证书的撤销清单。

TTS可以具有在模块化方式中被扩展的能力。例如，可以存在评估Google网页排名、信任网络分数的模块，还可以存在考虑了信誉系统的另一种模块等。这些模块可以给TTS提供分数，而TTS能够例如通过使用用户定义的权重策略来计算模块输入的汇总分数，并向用户展示对站点的评估。该特征可以避免现有的问题，例如在Firefox或Internet Explorer浏览器中要求用户检查证书以防误匹配或遗漏发布CA的信任关系。这些模块还可以用于到RP的非HTTPS连接，其中SSL证书是不可用的。总的来说模块可以在安全环境中运行，例如与TTS使用的环境相同的安全环境，且它们能够与TTS进行安全通信。

维持已有页面的散列值的小型参考数据库是可能的。必须为新的页面定义登记过程，但是假定针对网页/服务器已经存在一组参考度量，TTS可以利用这些度量来验证被访问的RP的完整性和真实性。在远程证明协议之后，与TTS和OpenID IdP协议类似，RP可以向TTS证明其完整性，TTS然后在成功证明的情况下可以允许进一步行动。

TTS与RP之间的示例相互认证可以包括以下中的一个或多个。相互认证不仅限于对RP网站和服务器的身份和信赖度进行检查。该过程可以包括由RP来进行在设备上运行的TTS的完整性和真实性检查。这对于TOpenID的团体（corporate）或政府（government）登记是很有用的，其中可以向RP确保用户确实使用TOpenID作为认证机制。RP可能会希望被保证在IdP与用户TTS之间使用了特定类型的认证机制（例如TOpenID）。但是，RP可以仍然需要信任IdP实际上使用TTS。否则，用户在其使用另一种机制向其OpenID IdP进行认证时可以要求使用TOpenID。

该认证可以包括对协议的一些修改。RP可以（例如在验证用户设备上的TTS的真实性以及可能的完整性之后）向TTS发送一种现时。该现时可以是唯一的，并用作来自该特定客户端TTS的该请求的标识符。TTS可以将该现时安全地存储到受保护的存储装置中，其与登录请求相关联。在RP将用户重定向到IdP后，IdP可以如在TOpenID中一样执行认证协议。TTS可以将该现时释放（例如，该释放可以被限制为在TOpenID协议中使用）到之前认证的OP。从IdP到RP的断定可以需要包括该现时，其可以向RP保证TOpenID确实用于认证。

在该情形中使用的术语现时可以用于描述RP传递给TTS的令牌，其用于验证对IdP使用了TOpenID认证。

为了定义现时的安全性特性，可以考虑不同的攻击类型。用户可以尝试在执行完非TOpenID认证后在通信中注入该现时。这可以需要用户截取IdP与RP之间的通信，这被假定为很难（尽管是可能的）。用户还可以从TTS或来自TTS的与RP的初始通信中提取该现时。如果现时存储在安全的存储装置中，且如果TTS是未被攻击（compromise）的，则该提取是很难的。可以假定被攻击的TTS不可以从RP接收该现时，因为RP首先可以验证TTS完整性，然后发送现时。该已知安全性的RP可以被配备有在用户设备上运行的TTS实例的完整性度量。如果从RP接收现时的TTS实例是安全的，则可以假定这些TTS安全地保护现时不受恶意用户侵害。

另一种攻击模式可以包括恶意IdP，其可以尝试伪造认证机制因此可以从TTS获取现时。在该情形中，可以假定TTS有效地保证现时的安全。更复杂的攻击模式可以包括串通的IdP和用户。如果用户能够获得现时，则其可以将现时转发到IdP而不执行TOpenID认证。IdP然后可以将消息中的现时用于要求使用TOpenID认证用户的RP。

在所考虑的攻击模型中，可以看出安全性可以依赖的事实为：如果RP检查TTS的完整性，则TTS可以接收现时，以及该TTS可以充分保护该现时并被限制为在TOpenID认证协议中释放该现时。由于现时针对每个服务接入可以是唯一的，因此恶意IdP不可以向RP重放该现时。

协议可以包括证明机制。OpenID提供方可以质询用户，以使用户提供关于系统状态的信息。如果系统处于可信赖状态，则可许可接入。这可以影响网络应用的安全性，因为对服务的接入可以被限制到“可信赖”系统。

可以提供无缝浏览器整合，而不是使用户侧上的服务应用侦听接收的OpenID认证请求并将请求转发到TPM。这可以通过使用采用该功能的浏览器扩展来实现。OpenID提供方可以在签到的页面的HTML码中发送质询。浏览器扩展可以读取该信息并将必要数据转发到TPM。而TPM可以创建标记的权证并将该权证返回浏览器扩展。该扩展然后可以将包含标记的权证的正确的HTTPS响应发送到OpenID提供方。

如果设备具有UICC，则可以在设备内的UICC上实施浏览器。在UICC上实施浏览器可以给予设备内在的安全环境，以供浏览器从该环境中操作。还可以通过使用基于GBA的安全信道来保证UICC中的浏览器与设备其它部分（包括TPM）之间的接口的安全。

OMTP BONDI框架是API套件，其可以允许微件（widget）或网络应用经由HTML页面中的javascript（Java描述语言）来接入设备能力。BONDI可以通过附加的API进行扩展以允许接入进一步的设备能力。BONDI安全性框架可以被限制为提供设备能力接入控制机制，由此其可以独立于尝试接入特定下层设备能力的JavaScript API而执行对该能力的接入。BONDI不可以防护设备能力。BONDI可以不是设备资源和能力的排他接入提供方。如果存在除了BONDI以外的其它框架或功能，则这些非BONDI所有的JavaScript API或BONDI框架以外的插件（Plugin）不可以被控制或管理，且它们可以破坏BONDI安全性框架。

图13是与TOpenID使用的BONDI的示例图。在1，用户可以访问RP并发送用于ID的XRI。在2，可以在RP与OP之间创建关联。在3，OP可以表示HTTP（S）认证页面。在3b，可信权证服务器可以提供用于证明的被标记的SML PCR。在4，OP可以确认SML PCR。在5，OP可以在用户登录时重定向到RP的URL。

如果BONDI在可信执行环境的顶部被执行，例如，由此策略管理和加强可以被安全存储，且设备能力的接入提供方被限制到BONDI框架，可能建立安全接入设备能力的网络应用。该功能可以包括从网页到设备中的安全的功能的直接接入。执行可信BONDI并添加特殊API（其允许网页接入在设备上运行的可信权证服务器的服务）可以开辟用于将TOpenID无缝整合到浏览器的新方式。

图14示出了与TOpenID使用的BONDI的示例呼叫流图。OpenID OP可以包括用于启用TOpenID的账户的认证页面中的BONDI javascript命令。页面内的该javascript可以由客户端的浏览器来执行并可以首先载入BONDI库和API。javascript可以从HTML页面询问可信权证服务器。该询问可以包括来自OpenID OP的ID、REQ以及现时。通过BONDIAPI，该询问可以被转发到设备上的权证服务器。BONDI安全性策略可被用于将接入限制到可信权证服务器，例如单个OpenID OP。可以向用户做出请求以准许或要求用户同意对可信权证服务器的每次接入尝试。可信权证服务器可以获取标记的PCR引用Q和测量日志ML并使用HTTP POST消息将这些值传送到OpenID OP。OP然后可以评估所接收到的数据并继续进行如在基础TOpenID情况中一样的协议。这种整合的优点可以是需要较少的用户交互且OP可以通过HTTP协议直接与可信权证服务器进行通信而不需要发起用于传输权证的第二通信信道（例如引用和ML）。

图15是示例OpenID协议的图。

图16是示例OAuth协议的图。

图17是示例的组合OpenID/OAuth协议的图。

图18是具有Google OpenID的示例OpenID协议的图。

图19是使用Google API的示例OAuth协议的图。

如这里所公开的，用户客户端/平台可以是WTRU或基站，其可以用于例如无线通信系统中。在一个示例中（但是也可以应用于其它无线通信系统中），图20示出了示例长期演进（LTE）无线通信系统/接入网400，其包括演进型通用陆地无线电接入网（E-UTRAN）405。该E-UTRAN 405包括一些演进型节点B（eNB）420。WTRU 410与eNB 420通信。eNB 420使用X2接口彼此连接。每个eNB 420通过S1接口与移动性管理实体（MME）/服务网关（S-GW）430连接。虽然在图20中示出了一个WTRU 410和三个eNB 420，但是应当理解，在无线通信系统接入网400中可以包括无线和有线设备的任意组合。

图21是LTE无线通信系统500的示例框图，包括WTRU 410、eNB 420以及MME/SGW 430。如图21所示，WTRU 410、eNB 420与MME/S-GW 430被配置成执行使用链接进行盲解码（BD）复杂性降低的方法。

除了可以在典型WTRU中找到的组件外，WTRU 410还包括具有可选链接的存储器522的处理器516、至少一个收发信机514、可选电池520以及天线518。处理器516可以被配置成执行这里公开的方法。收发信机514与处理器516通信，并与天线518通信以促进无线通信的传输和接收。在WTRU 410中使用电池520的情况下，电池520给收发信机514和处理器516供电。

除了可以在典型eNB中找到的组件外，eNB 420还包括具有可选链接的存储器515的处理器517、收发信机519以及天线521。处理器517可以被配置成执行这里公开的方法。收发信机519与处理器517通信，并与天线521通信以促进无线通信的传输和接收。eNB 420被连接到移动性管理实体/服务网关（MME/S-GW）430，其包括具有可选链接的存储器534的处理器533。

虽然本发明的特征和元素以特定的结合在以上进行了描述，但每个特征或元素可以在没有其他特征和元素的情况下单独使用，或在与或不与本发明的其他特征和元素结合的各种情况下使用。本发明提供的方法或流程图可以在由通用计算机或处理器执行的计算机程序、软件或固件中实施，其中所述计算机程序、软件或固件是以有形的方式包含在计算机可读介质中的。计算机可读介质的实例包括电子信号（通过有线或无线连接传输）和计算机可读存储介质。计算机可读存储介质的实例包括但不限于只读存储器（ROM）、随机存取存储器（RAM）、寄存器、缓冲存储器、半导体存储设备、内部硬盘和可移动磁盘之类的磁介质、磁光介质以及CD-ROM碟片和数字多功能光盘（DVD）之类的光介质。与软件相关的处理器可用于实现射频收发信机，以便在WTRU、UE、终端、基站、RNC或是任意主机计算机中加以使用。

举例来说，恰当的处理器包括：通用处理器、专用处理器、常规处理器、数字信号处理器（DSP）、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路（ASIC）、现场可编程门阵列（FPGA）电路、其他任何类型的集成电路（IC）和/或状态机。

与软件相关的处理器可用于实现射频收发信机，以便在无线发射接收单元（WTRU）、用户设备（UE）、终端、基站、无线电网络控制器（RNC）或任何主机计算机中加以使用。WTRU可以与采用硬件和/或软件形式实施的模块结合使用，这些模块例如是相机、摄像机模块、视频电话、扬声器电话、振动设备、扬声器、麦克风、电视收发信机、免提耳机、键盘、蓝牙

模块、调频（FM）无线电单元、液晶显示器（LCD）显示单元、有机发光二极管（OLED）显示单元、数字音乐播放器、媒体播放器、视频游戏机模块、因特网浏览器和/或任何一种无线局域网（WLAN）模块或无线超宽带(UWB)模块。

Claims (16)

1.一种用于对无线设备的用户进行认证的方法，该方法包括：

从网络应用功能接收认证请求；

由可信权证服务器获取平台确认数据，其中该平台确认数据包括对所述无线设备的信赖度的测量；

将所述平台确认数据发送到所述网络应用功能；以及

接收平台验证，该平台验证指示所述网络应用功能已经对所述平台确认数据和所述用户进行了验证。

2.根据权利要求1所述的方法，其中，所述平台验证指示由所述平台确认数据指示的系统状态与之前生成的参考值相匹配。

3.根据权利要求1所述的方法，其中，所述平台确认数据被标记。

4.根据权利要求1所述的方法，其中，所述平台确认数据包括用户标识参数。

5.根据权利要求1所述的方法，其中，所述平台确认数据包括证明数据。

6.根据权利要求5所述的方法，其中，所述证明数据包括用AIK标记的SML和PCR引用。

7.根据权利要求1所述的方法，该方法还包括接收包括所述平台验证的权证，其中该权证能够被重复使用，以执行后续授权，而不需要对所述无线设备进行重新确认。

8.根据权利要求7所述的方法，其中，所述权证包括时间戳。

9.根据权利要求7所述的方法，其中，所述权证包括起点时间戳。

10.根据权利要求7所述的方法，其中，所述权证包括寿命期限。

11.根据权利要求7所述的方法，其中，所述权证包括结束日期。

12.根据权利要求7所述的方法，其中，所述权证包括使用参数限制。

13.根据权利要求7所述的方法，该方法还包括从网络实体接收权证参考。

14.根据权利要求13所述的方法，其中，所述权证参考能够被用于从网络应用功能获得所述权证，且其中所述平台验证能够被重复使用，以执行后续授权，而不需要对所述无线设备进行重新确认。

15.根据权利要求1所述的方法，该方法还包括：

建立到信赖方的连接；

接收到所述网络应用功能的浏览器重定向；以及

向所述网络应用功能发送认证请求。

16.根据权利要求1所述的方法，其中，所述平台验证包括被许可接入到信赖方。

Images