S)。这些服务器的每一个可以发布权证。每个权证可以包括两个部 分。例如，一个部分可以针对下一个目标服务器而被加密，且由此不可以由客户端进行解 密。该部分可以包括会话密钥，且可以通过下一个通信步骤被使用。该会话密钥可以在权 证的第二部分中针对客户端而被加密。如果客户端能够解密该第二部分，则客户端可以获 得该会话密钥以请求下一个权证。
[0049] 举例来讲，TKerberos可以在以下阶段被执行。例如，权证许可权证（TGT)可以被 请求和/或从AS被接收并被存储以供将来使用。会话密钥可以被解密，以对用于服务权证 (ST)请求的认证数据进行加密。TGT可以与加密后的认证码（authenticator) -起被发送 到TGS。ST可以从TGS中被接收。会话密钥可以被解密，以对用于服务请求的认证数据进 行加密。ST可以与加密后的认证码一起被发送到服务提供方。
[0050] TKerberos协议可以使用TC。这种设计可以具有目标，例如用于通过提供例如将 权证经由TPM紧密绑定到用户权证服务器（TS)的方式来增强安全性，和/或保护用户接入 服务的隐私。
[0051] AS可以执行PCA的任务和/或TGT可以用作AIK证书。TKerberos中，权证获取 过程可以包括两个部分，以允许平台预先缓存权证并针对服务接入对权证进行个性化。
[0052] 包含在服务器侧的安全性中的是用户系统的证明。当用户想要获取ST来接入服 务时，TGS可以质询用户以远程证明系统一致性（conformity)。因此，处于证实的系统状态 中的客户端能够接入服务。图1A示出了与可信Kerberos有关的示例呼叫流。TGT可以通 过具有要求的TGT身份和服务请求的TCTicket而被增加，其可以由TPM标记。
[0053] 如图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响应进行加密。
[0054] 在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保证其安全性。
[0055] 拥有TPM和针对TPM中的密钥使用的凭证的用户可以对ST进行解密由此使用该 ST来接入服务。例如，如图1A所示，在25,客户端30可以请求服务。在26,如果被加密，则 客户端30可以解密该ST，并将该ST提供给服务提供方60。在27,服务提供方60可以检查 ST，且在28,如果ST有效，则提供被请求的服务。
[0056] 可信权证的概念的可以包括对在权证获取过程中的客户端的证明。向TGS的证明 可以被描述为安全性的增加。这可以以特定应用的形式来提供改变。该改变可以应用到可 信OpenID概念。例如，一种这样的改变可以是经由证明和/或潜在纠正（remediation)对 TGS发布的ST和/或客户端状态进行个性化（individualize)。也就是说，可以使TGS能 够执行可以允许特定状态中的客户端接入特定服务的策略。另一种这样的示例可以是允许 TGS在客户端接入之前自己确认该服务，例如通过针对服务器状态的证明来质询该服务器。 由此，TGS，或可信OpenID情况中的OpenID提供方，可以用作调解方（mediator)，其确保相 互接受和/或信赖状态中的客户端和服务器进入通信关系。如果存在多个客户端，则这可 能导致在服务上的过多的负载，这在一些情况中可能适用。通过例如偶尔确认服务等方式， 可以减轻负载。在3GPP中的机器对机器（M2M)通信中可能存在类似的问题。例如，半自发 确认M2ME而不改变已有网络的基础结构可能存在问题。展现的可信身份管理（IdM)的概 念可以是用来使运营商的常规认证授权记账（AAA)基础结构能够用于该目的的构造块。远 程认证拨号用户服务（RADIUS)等的可信版本可以被应用。
[0057] 可以提供用于可信开放式ID(TOpenID)的系统和方法。可信OpenID实体可以包 括：1)例如接入服务的用户；2)(^ 61110提供方；3)用于证实来自用户的1?11的厶11(的？〇八； 和/或4)使用OpenID认证的服务提供方。
[0058] 图2示出了与可信OpenID有关的示例呼叫流200。呼叫流200可以是可在使用例 如可信OpenID接入服务时执行的协议。如这里所述，客户端/用户或用户平台210、服务提 供方215以及身份提供方220 (显示为示例OpenID提供方）被配置用于彼此间的通信。当 使用可信OpenID时，客户端/用户平台210可以建立与服务提供方215的初始连接。客户 端/用户平台210可以使用其网络浏览器225经由访问网页消息227来访问服务提供方的 网页（标识为索引.jsp 235)。如果客户端/用户210想要使用例如用户的OpenID URI来 登录，则服务提供方215可以连接到给定URI并由此获取掌管要求的身份的OpenID提供方 220的地址。在服务提供方215处的索引.jsp页235可以经由OpenID登录形式消息229 请求URI，并经由OpenID身份消息231获取掌管要求的身份的OpenID提供方220的地址。
[0059] 服务提供方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)。重定向地址可以从用户提供的标识符中获取，这可以确保被重定向到0P页的 客户端/用户平台210与提供标识符的是同一个实体。可以经由HTTP重定向来执行该重 定向，HTTP重定向可以直接将浏览器重定向到0P登录页。
[0060] 客户端/用户平台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。
[0061] 假定认证成功，客户端/用户平台210可以被重定向到服务提供方。提供方.jsp 网页245可以发送重定向消息262给客户端/用户平台210。重定向消息262可以经由到 服务消息264的重定向将客户端/用户平台210重定向到在服务器提供方215处的消费方 返回url. jsp页265。消费方返回url. jsp页265可以检查重定向来自相关联的OpenID提 供方220,并经由服务消息267许可对客户端/用户平台210的接入。
[0062] 图3A和3B不出了与权证服务器305和权证质询方310之间的可信权证服务器质 询-响应有关的示例呼叫流300。存储介质320和TPM 325可以被使用。权证服务器305 可以作为客户端上的服务应用来运行。权证服务器305可以在预定义端口上侦听并等待质 询。一旦接收到质询消息327(包括用户想要在其中使用的身份（例如OpenID)，和在服务 提供方处发出的服务请求），则需要用户允许使用答复消息329进行质询。用户可以有拒绝 质询的选项。如果拒绝，则OpenID认证失败。
[0063] 如果质询被接受，则提示用户输入用于对应于给定身份的AIK的密码，以及通过 在权证服务器305处输入存储根密钥（SRK)密码来认证TPM 325的使用。SRK然后可以被 包含在能够接入TPM安全密钥的TPM命令中。权证服务器305然后可以尝试从证书存储介 质320中获取用于该身份的之前获得的证书，例如AIK证书（总体示为335)，其可以用于 这里所述的系统状态信息获取345和/或TCTicket生成350。证书可以来自与PCA(例如 PCA 315)的之前的AIK鉴证，且可以从系统上的本地证书存储（例如鉴证存储介质320)获 取。如果在本地存储中证书不可用（或本地存储中用于AIK的证书已经期满或无效），则可 以从PCA 315请求由AIK表示的用于身份的另一个证书。如果在证书存储介质320中不能 找到证书，则用户可以选择连接到PCA 315,以经历AIK鉴证过程和/或获得用于AIK的证 书。用户可以提供TPM 325的正确的拥有者密码。这可以防止TPM 325拥有者以外的人创 建无赖身份。权证服务器305可以将用户输入转发到评估密码的TPM 325。
[0064] 响应于接受质询，权证质询方310可以创建随机现时（nonce) 337。权证服务器305 可以经由现时消息339从权证质询方310接收随机现时337。描述系统配置（包括现时） 的平台配置注册（PCR)值的AIK标记的引用Q可以从TPM 325中被获取，做出关于系统状 态的陈述（总体示为345)。
[0065] 权证服务器305然后可以创建TCTicket (总体示为350)。TCTicket创建350可 以包括TPM的密钥创建（例如RSA密钥对），其可以用于标记请求和/或身份。如这里所 述，该密钥可以使用证实密钥操作用AIK来证实。也就是说，TPM可以使用用于该创建的密 钥对的证实密钥功能来生成鉴证陈述和绑定，其中绑定指的是给AIK和/或来自PCA的AIK 证书建造信任链。当创建的密钥被成功证实时，其可以被称为证实的标记密钥（CSK)。TPM 中可以存在多个CSK和/或多个AIK(或在由TPM保护的安全存储中由TPM确保安全）。
[0066] 验证TCTicket 350所需的信息可以被包含在TCTicket 350中，使得接收方（例 如图3A和3B中的权证质询方310)可以轻松地验证TCTicket 350。与明文测量日志ML和 /或引用Q -起，包含TCTicket 350的响应可以经由例如TCT、Q、ML消息352被发回权证 质询方310。CH-RESP0NSE和ACK (应答）消息（统称为351)可以是这样的协议：发送消息 以通知接收方（例如权证质询方310)下一个消息可以包含TCTicket 350、所述引用和/或 ML〇
[0067] 图3A和3B可以表示图2中的TT验证方线程258的内部操作。由于OpenID提供 方可以同时处理多个请求，因此其可以是每个请求客户端获得新的、新近（fresh)和/或唯 一的质询，以免重放攻击。
[0068] -旦经由消息355对TCTicket 350进行应答，权证质询方310可以具有以下数 据：来自TPM 325的AIK标记的引用，包括作为防重放保护的现时337 ;明文测量文件； TCTicket 350,包含标记的身份串、标记的请求串、CSK的公钥部分、CSK的公钥部分上的 AIK签名、和/或PCA 315发布的AIK证书。为了对客户端进行认证，权证质询方310可以 不以特定顺序执行以下（总体示为360)