CN104012131A

CN104012131A - 用于执行空中身份配备的设备和方法

Info

Publication number: CN104012131A
Application number: CN201180076008.0A
Authority: CN
Inventors: N.M.史密斯; S.巴克施
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2011-12-30
Filing date: 2011-12-30
Publication date: 2014-08-27
Also published as: US20140013116A1; WO2013101164A1; JP5992535B2; JP2015508536A; EP2798869A1; EP2798869A4

Abstract

一种用于控制对信息的访问的方法包括通过空中(OTA)链路从身份请求方向身份提供方发送请求。响应该请求而从身份提供方所接收的数据包括用来对第一服务建立用户的第一身份的信息。第一身份信息在西格玛会话期间接收，以及用户的第二身份基于所接收的第一身份信息对第二服务被建立。用户可以是移动通信终端或其它装置的用户，其将接收第一和第二服务。

Description

用于执行空中身份配备的设备和方法

技术领域

本文的一个或多个实施例涉及电子信息管理。

背景技术

建立用户的身份是接收许多类型的网络服务的先决条件。这通过使用户填写表单上的信息、通过经由电话提供信息和/或通过使用网站输入信息来手动执行。这些技术已经证明是费用高并且低效的。

近来，努力使建立用户身份的过程自动化，作为对接收网络服务的要求。这些努力包括通过无线网络接收信息以建立用户身份。因为无线接收信息，所以这种技术常常称作空中(Over-the-Air, OTA)身份配备。

现有OTA身份配备技术在得到和认证用户证书的方式方面是低效的。此外，这些技术尝试与已经认证和建立用户的身份的其它源或域无关地建立身份。

附图说明

图1示出用于执行空中(OTA)身份配备的***。

图2示出用于基于对装置用户所建立的现有身份来建立OTA身份的方法的一实施例。

图3示出身份提供方中的第一身份证书的示例。

图4示出身份请求方的一个实施例。

图5至图8示出用于执行OTA身份配备的另一种方法。

图9示出用于执行OTA身份配备的***的另一个实施例，其中身份请求方位于电子装置中。

图10示出可进行以实现身份提供方与请求方之间的西格玛会话的消息的交换。

具体实施方式

图1示出按照一个实施例、其中执行OTA身份配备的***的示例。在这个实施例中，无线装置10的用户设法从提供方得到一个或多个服务、商品或信息。无线装置可以是移动或智能电话、笔记本或台式计算机、个人数字助理、pod类型或pad类型装置、平板或者装备有无线能力的多种其它电子装置的任一种。本文所述的实施例可涉及移动装置。但是，在其它实施例中，被认为是固定或便携式的装置也可遵从于本文所述方法和***。

身份提供方可提供金融服务、媒体或娱乐服务、通信服务、因特网相关服务和/或来自私有或公司/企业源的其它服务。按照一个示例，电子装置的用户可与源或服务保持预订或者其它提交的表单支付或隶属关系。在提供方能够提供服务之前，提供方必须建立用户的置信身份。为此原因，提供方在图1中描述为身份请求方20。

按照这个实施例，身份请求方基于由另一个提供方已经建立的身份来建立电子装置的用户的身份。因此，另一提供方提供指示其已经建立身份的信息以供身份请求方20使用。因此，另一提供方在图1的上下文中描述为身份提供方30，要理解请求方20和提供方30实际上均是提供方。

身份提供方30可向用户提供金融服务、媒体或娱乐服务、通信服务、因特网相关服务和/或多种其它服务。按照一个示例，身份提供方可以是零售商、公用事业、政府实体或者其它类型的私有、公司或企业源，其提供用户所寻求的并且对其要求身份的建立和认证的商品和/或服务和/或信息。

无线装置10可通过无线链路40(其例如可通过一个或多个移动网络或者连接到有线或无线网络、例如但不限于因特网的短程链路来建立)与身份请求方20进行通信。装置也可通过相同类型的链路与身份提供方30进行通信。

备选的是，身份提供方可以不是与装置10直接通信，而是可以只按照与装置的使用不相关的方式来保持这个装置的用户的身份。例如，身份提供方可以是***公司、银行、金融顾问、经纪人、保险公司或者其它金融机构。在这种情况下，身份提供方30可有权访问数据库，使其是身份请求方20可访问的，如下面更详细描述。

身份请求方20和提供方30通过空中链路60相互通信。按照一个实施例，在身份请求方与提供方之间交换的信息可基于所存储的控制软件对用户是透明的方式发生。使用所交换信息，身份请求方在其自己的域中认证和建立用户的身份，由此缓和对手动或者其它高费用和低效数据输入的需要。因为链路60对用户透明地被建立，所以它对某些应用可描述为“后台（back）信道”。

图2示出用于基于对移动装置用户所建立的现有身份来建立OTA身份的方法的一个实施例。这种方法可在如图1所示的***或者不同的***中实现。至少部分位于身份提供方和请求方中的控制软件可用来实现该方法。

建立第一身份

初始操作包括接收来自移动装置的用户、从身份提供方接收服务的请求210。为了说明的目的，对这个实施例将假定服务基于预订。但是，在其它实施例中，可涵盖其它商品和/或服务。该请求可例如通过电话、亲自、通过因特网上做出的请求或者在商店中以及包括从装置无线进行请求的其它方式来接收。

一旦进行了请求，身份提供方为了建立预订而建立用户的身份220(称作第一身份)。该身份可使用常规技术来建立。例如，如所示，用户的身份可基于手动或其它方式所输入的用户信息，并且可包括出生日期、地址、社保号、***或帐号以及构成可确证用户身份的可靠基础的其它信息。这些技术可称作“带外”预订或身份确定技术。

一旦已经认证用户并且建立其身份，则第一身份凭证230存储在电子可访问数据库或其它存储装置中。这些凭证基于上述用户信息，并且被依靠作为用于建立用户的第二身份的基础。

建立第二身份

在存储第一身份凭证之后，用户请求从身份请求方接收服务250的预订。该请求可例如通过无线网络从移动装置10直接进行。备选的是，该请求可通过在用户的移动装置上访问的因特网网站进行。按照一个示例，该请求按照对服务的预订、网站的隶属关系、在线购物或者在另一个上下文中进行。

按照一个具体示例，在进行请求中，用户可访问身份提供方的网页，其包括用于创建用户帐户的可选择选项。帐户可基于用户名、密码和对安全问题的回答以及其它信息来创建。在另一个示例中，用户可提供发起例如基于公有密钥基础设施(PKI)密钥所加密的信息的传递。该信息可例如基于证书请求消息的传送来传递，其可由证书机构用来构成用户和/或其装置的数字证书。

一旦进行请求，身份请求方执行一个过程，其包括自动建立用于从存储装置接收包含用户的第一身份凭证的信息的链路(例如OTA后台信道连接)。因为第一身份凭证存储在身份提供方的数据库或存储装置中，所以上述过程可要求与身份提供方建立链路。

为了建立链路，身份请求方基于例如实用工具来确定身份提供方30的联络信息和存在。更具体来说，用户可使用实用工具、例如密码管理器(其具有万维网综合特征，其中提示输入用户名/密码的通用资源定位符(URL)重定向到密码管理器以用于自动完成/表单填写)来管理其身份。

按照一个实施例，管理器工具可检测要创建新用户身份。不是提示用户创建新用户名和密码，而是可向用户给予基于与第一用户身份(其例如可包括用户名、数字证书和/或用于识别用户的其它信息)对应的信息来构成新身份(例如用户名和密码)的备选选择。

在用户名和密码的情况下，密码管理器可存储信息以回忆网站URL(例如用于自动填写目的)。这个URL则可用来构成身份再使用请求。如果身份是或者包括证书，则证书可包含发行人联络信息、例如发行人RDN和发行人URL，其中发行人对应于身份提供方30。基于这个信息，身份请求方可建立用于接收第一身份凭证的链路。

一旦建立链路，将第一身份凭证发送给身份请求方，以供建立用户的第二身份260中使用，以便允许用户接收身份请求方所提供的预订。为了接收第一身份凭证，身份请求方可通过先前所述的后台信息来联络身份提供方。如所示，这可自动地(例如响应对预订的用户请求)并且按照对用户是透明的方式进行。

一旦被接收，身份提供方基于第一身份凭证来认证用户，并且然后基于这个信息来建立第二身份。按照一个示例，第一身份可包括用户名、密码和/或数字证书。另外，第一和第二身份可以相同，或者可以相互不同，例如不同的用户名和密码。在第一身份是数字证书的情况下，要建立的第二身份、不同证书可基于例如向不同证书机构的注册过程的执行来创建。

因为来自身份请求方的对预订(或其它服务)的请求无线进行和/或从身份提供方所得到的信息通过链路(其包括移动网络)无线得到，所以用于建立第二身份的过程可描述为空中(OTA)身份配备。(因此，身份请求方与提供方之间的后台信道可称作OTA连接。)一旦已经建立第二身份，服务270可基于第二身份在用户的移动装置上向其提供。

图3示出可如何分类第一身份凭证并且那些凭证可如何传递给身份请求方的示例。为了传递这些凭证，身份请求方20建立到身份提供方30的OTA后台信道240。链路可基于例如从身份请求方传送给身份提供方的请求信息(RFI)信号自动建立。

为了发送RFI信号，身份请求方必须首先识别身份提供方和对应地址信息。这可例如基于要在移动装置中运载的下载应用或者通过移动装置中存储的可执行文件、例如在从紧致盘(CD)或数字多功能盘(DVD)读取时来实现。在被运行时，应用或文件可自动建立到身份提供方的连接，以用于得到建立第二用户身份所必需的凭证之目的。

一旦通过接口330接收RFI信号，由身份提供方30中的控制软件340所指导的处理器控制一个或多个第一身份凭证从存储装置310(其例如可以是订户数据库、存储器或其它存储区)的输出。按照一个实施例，只有一个或多个所选凭证可提供给身份请求方。

例如，考虑将第一身份凭证分类成包括公有凭证320和私有凭证330的情况。公有凭证可对应于例如地址、电话号码、电子邮件地址和/或与用户相关的其它公共已知信息。私有凭证可包括***信息、社保号、密码和/或用户名和/或其它私有信息。

为了认证用户并且因而建立第二身份，私有凭证可以不是必要的。此外，用户可希望逐项阻止其它实体在没有明确准许的情况下对这个信息的访问。在这些情况下，公有凭证320可通过后台信道传送给身份请求方，以及可基于管理私有凭证的传递的身份提供方的控制软件来阻止私有凭证被传送。

备选或附加的是，阻止私有凭证的传递的判定可基于身份提供方中存储的一个或多个用户设定和/或基于RFI信号中的信息进行。

阻止私有凭证的传递可用于两个目的。

首先，阻止私有凭证的传递防止用户的身份被盗，这对于通过网络进行的通信变得越来越重要。

其次，阻止私有凭证允许第二身份的真实性要基于用户身份先前由身份提供方确证的事实来确证。如果身份提供方是声誉好的，则可以不需要用户身份的第二独立确证。这又将使建立第二身份的过程在处理速度和用户便利方面更为有效。

在一个备选实施例中，私有凭证可采取加密形式和/或使用信息保护的另外某种安全方法来传送给身份请求方。同样的操作可对公有凭证来执行，即使这个信息可被认为不如私有凭证那么敏感。

图4示出装备成实现置信客户端小应用程序以建立到身份提供方的安全OTA连接的身份请求方的一个实施例。如所示，身份请求方包括：OTA代理接口410；处理器415，包括用于执行建立OTA连接和第二用户身份的操作以及执行其它处理和管理功能的管理引擎420；以及存储装置430，存储用于建立第二用户身份的凭证。

OTA代理410可进行操作以提供网络连通性，并且可用于管理引擎没有直接网络访问的事件中。按照一个实施例，OTA代理作为用于在移动通信***中基于预定标准协议来转发信号的接口进行操作。在这个实施例中，代理可控制身份请求方与身份提供方之间通过OTA后台连接的通信。代理可实现为要由管理引擎/控制器来运行的芯片组固件，并且可以或者可以不驻留在引擎的信任边界外部。

在其它实施例中，管理引擎可具有对通信网络和/或通信集线器的直接访问。在这种情况下，代理可被认为是可选特征，因为除了代理之外，管理引擎还可建立OTA后台信道连接。

管理引擎420运行OTA小应用程序(或者另一类型的应用)，其建立到身份提供方的OTA后台信道连接。这个连接可在西格玛会话期间、在身份提供方和请求方中建立。更具体来说，OTA连接可使用具有证明的西格玛协议来建立。管理凭证从身份提供方传递给身份请求方的预定身份属性公开策略可由身份提供方实现。这种策略(通过软件所实现)可允许公有凭证被传递，并且允许私有(或更敏感分级结构)凭证被传递给身份请求方。

管理引擎如先前所述通过OTA后台信道连接从身份提供方的存储装置来接收凭证(其可以或者可以没有加密)，并且然后将这些凭证存储在存储装置430中。然后，管理引擎基于所存储凭证来建立第二用户身份，并且基于所建立的第二身份向用户装置提供预订和/或服务450。这样，管理引擎可被认为作为安全环境中的置信服务管理器进行操作。按照一个实施例，OTA代理、管理引擎和/或存储装置可位于身份请求方的服务器中。

按照一个示例，管理引擎可由身份请求方所包含的芯片组中的控制器来实现。这个引擎可作为安全元件进行操作，其中具有运行置信代码的坚固安全边界。在运行这个代码中，身份提供方和请求方均可依靠用于按照例如先前所述RFI信号的传送来将第一身份从身份提供方传递给身份请求方的目的。

来自身份请求方的RFI信号可由管理引擎小应用程序来生成，所述管理引擎小应用程序进行操作以识别对其已经建立身份的提供方，并且存储提供用于将身份请求方链接到这个身份提供方的信息的信息。在执行这个功能时，小应用程序可指导控制器选择已经建立现有身份(其近似(若可能的话)建立身份请求方的第二身份所要求的身份凭证)的提供方。身份请求方还可按照本文所述的方式来检验身份提供方已经授权与第一身份对应的凭证的公开。

例如考虑身份提供方是Amazon.com(其保持第一用户身份凭证的数据库)以及身份请求方是视频点播(VOD)网站的情况。在这种情况下，管理引擎执行置信第三方的作用，其允许Amazon.com和VOD实体使用实用工具相互连接。该工具可访问Amazon.com的连接信息(例如URL)(例如存储在耦合到管理引擎的存储器中)，其允许OTA后台信道链路被建立。然后，基于管理引擎所执行的操作，第一身份凭证可从Amazon.com发送给VOD实体，以用于建立VOD实体的第二身份。

图5至图8示出用于执行OTA身份配备的方法的更详细实施例中包含的操作。这种方法包括建立身份请求方与身份提供方之间的OTA连接(框510)。身份请求方和提供方可以是先前所述的那些身份请求方和提供方，以及OTA连接可被认为是先前所述类型连接的任一个，包括但不限于后台信道连接。

OTA连接可由身份请求方例如响应从图1所示的电子装置10所接收的信号或者在以其它方式被通知时而发起。信号或其它通知可基于运行于电子装置的应用的控制来接收，或者可在稍后时间基于通过有线或无线链路从用户所接收的信息来发起。

在连接已经建立之后，身份提供方从身份请求方接收对一个或多个特定凭证的请求(框520)。凭证可以是先前所述的那些凭证的任一个。响应该请求，身份提供方从与用户对应的存储区来检索凭证。凭证可以是请求中所识别的特定凭证的全部或者一部分。存储区可位于身份提供方的服务器中或者与其远程耦合(框530)。

一旦被检索，则做出关于请求中所识别的所有凭证是否在检索的凭证中被发现的确定(框540)。如果是的话，则要检查各凭证(框550)。这个操作集中于在向身份请求方提供凭证中要遵守的准许或公开策略。

例如，各凭证(例如姓名、电话号码、帐号、通过身份提供方的一个或多个密钥所签署的签名位等)可具有不同的唯一性和敏感性质。因此，给定用户在身份提供中的信任，一些凭证的公开可以是可接受的，而其它凭证是不可接受的。为了保护不希望信息的公开，身份提供方可在控制要公开的凭证的协商中遵守用户的准许(例如基于存储信息)。可准许被公开的凭证的传递在西格玛会话期间被发送，这提供针对不希望或非预计公开的增加安全措施。

如果不是的话，则断定身份提供方不能用于建立请求方的第二用户身份的目的。在这种情况下，由身份请求方做出关于另一个身份提供方是否可被使用或者可用于建立第二用户身份的确定。由这个另一提供方所建立的身份可以是先前建立的身份(框570)。

如果确定另一个身份提供方存在，框530，并且对那个另一身份提供方重复进行后续框。否则，该方法可结束，例如，用户的身份必须按照常规方法来建立。

在执行框550的操作之后，做出关于请求中所识别的所有凭证是否被用户授权公开的确定(框560)。这个确定由身份提供方例如基于先前由用户所提供并且这时存储在身份提供方中的设定或准许信息进行。如果所有请求的凭证未被用户授权向身份请求方公开(例如因为其中一些是没有被授权传递给另一个实体的私有凭证，如先前所述)，则过程流程继续进行到框570，以定位(若可能的话)另一个身份提供方。

如果所有请求的凭证被用户授权公开(例如，是所有公有凭证或者包括用户先前授权公开的私有凭证)，则确认信号通过OTA连接从身份提供方发送给身份请求方，以确证凭证的可用性(框610)。这个信号可由管理引擎来生成，以用于沿OTA连接的传送。

在接收确认信号之后，身份请求方中的管理引擎开启西格玛会话，为了创建第二用户身份(框620)。按照一个示范实施例，西格玛会话可基于西格玛密钥交换协议来执行。在实现这个协议中，可使用两个会话密钥MK和SK。这些密钥之一(MK)用来保护保密性，以及另一密钥(SK)保护要在身份提供方与请求方之间交换的消息的完整性。

在会话期间，身份请求方可向身份提供方证明身份请求方是可信安全元件。这可例如基于TASKINFO信号来实现，TASKINFO信号准确描述安全元件的固件配置，而EPID提供链路的客户端侧是特定(例如Intel Corporation)硬件。图10示出可在实现西格玛会话中交换的消息的示例。

在西格玛会话已经开启之后，身份请求方中的管理引擎执行认证用户的过程(框630)。在执行这个过程中，要理解，凭证可描述用户，并且被偏斜从用户的安全元件始发，如在身份提供方中或者由身份提供方保持。因此，认证可基于由身份提供方对用户的身份的建立，并且还按照在西格玛会话期间所交换的消息，如先前所述。

在已经认证用户之后，做出关于凭证是否被身份提供方授权公开的确定(框640)。这可基于身份提供方中的控制器(例如，其可以或者可以不是与管理引擎420相似)所实现的策略来执行。这个策略可指导控制器标记哪些凭证是敏感的(例如具有较高优先级和/或哪些被授权公开)。附加或备选的是，西格玛会话和OTA后台信道连接可用来执行基于每个属性的查询。实现授权的伪代码的样本可被给出如下，其中域B对应于身份请求方：

给定User-1，断言：

OK 以向域B公开Attr-A(是/否)

OK 以向域B公开Attr-B(是/否)

如果凭证没有被身份提供方授权公开，则执行框570的操作，以确定另一个身份提供方是否可用于建立第二身份的目的。另一方面，如果凭证被身份提供方授权公开，则做出关于身份提供方是否支持西格玛注册的确定(框710)。这可例如基于发送图10中的S1消息来实现。

如果身份提供方不支持西格玛注册，则控制转到框570。另一方面，如果身份提供方被确定为支持西格玛注册，则西格玛会话在身份提供方中开启(框720)。西格玛会话的开启可涉及传送图10中的S1消息。按照一个实施例，第一消息基于所签署Diffie-Hellman密钥交换协议(又称作西格玛)被发送。

另外，图10中，检验器、证明器和在线证书状态协议(OSCP)应答器可对应于身份提供方、身份请求方和电子装置的任何组合。另外，按照一个示例，提供方可被看作对应于西格玛协议的客户端侧，以及检验器可被看作对应于西格玛协议的服务器侧。使用西格玛协议允许证明器检验该检验器身份(客户端知道它与哪个域进行交互)。服务器能够检验客户端(例如证明器)是可信环境(例如安全元件)。

另外，在一个实施例中，OSCP应答器可作为提供撤消列表信息的第三实体进行操作。第三实体可以是例如证书机构，其使它的公有密钥被嵌入证明器硬件中，以允许检验器的证书和证书机构的撤消列表的检验。S2和S3消息在证明器与检验器之间交换，以在从OCSP应答器接收响应消息之后允许身份检验。

在西格玛会话已经开启之后，身份提供方的服务器(或者其它位置)中存储的所请求证书使用预定密钥来加密(框730)。加密可例如基于西格玛会话密钥(SK)、使用对称密钥密码、例如高级加密标准(AES)或三重数据加密标准(3DES)来执行。西格玛密钥可以是与用户对应的私有密钥或者另一种类型的密钥。

一旦经过加密，则证书沿OTA连接从身份提供方传递给身份请求方(框740)。这个操作可基于与所开启西格玛会话对应的一个或多个预定注册协议来执行。向身份请求方公开凭证的过程可被认为构成注册协议。在这点上，身份提供方的管理引擎(或者另一安全元件)(或者备选地是身份请求方中的管理引擎)可执行担保凭证的真实性的置信机构的作用。在PKI术语中，管理引擎在这种情况下可被认为是登记（registration）机构。

加密凭证由管理引擎来解密，并且然后这个引擎基于凭证来建立第二用户身份(框750)。解码基于预定密钥以及用于加密的技术来执行，其信息可在西格玛会话期间被通知身份请求方，其中MK(主密钥)和SK密钥在例如图10所示的所交换消息的一个或多个中发送。

第二用户身份可通过具有唯一识别用户的高概率的一个或多个凭证(包括先前所述凭证的任一个，例如姓名、帐号等)来建立。建立第二身份所执行的操作的示例包括：

1. 得到用户的凭证

2. 审查对用户的正确性和/或相干性，这例如由置信机构（例如登记机构）来执行。在这样做时，身份请求方的管理引擎利用从另一个服务提供方先前发出的身份，以获得正确性和相干性

3. 将凭证提供给域机构，其关联由域命令机构来控制的域特定凭证或其它属性(例如姓名、号码、作用、特权)。例如，.com域由因特网属性和命名机构(IANA)来控制。

域机构可通过签署证书，或者通过创建由相干域、例如身份请求方的域所控制的数据库中的条目，来发出与第二用户身份对应的(一个或多个)凭证。在这个示例中，身份提供方的管理引擎可执行用户的域的作用。因为管理引擎是由其它域(例如身份请求方)正确协调属性所信任的，所以它自动实现凭证的空中构成，而无需手动干预。

基本上，这个身份向身份提供方提供关于用户所寻求的预订或服务对用户被授权、以便在用户的移动或其它装置上接收的指示。如图1所示，移动装置可通过空中链路或者另一种类型的链路来耦合到身份提供方。通过按照对用户是透明的方式、基于另一个实体/身份提供方对用户已经建立的身份以建立第二用户身份，使认证和授权预订/服务的接收的过程与其它基于手动的方法相比是有效的。

作为对图7中的框720、730和740的操作的一个备选方案，可执行图8中的操作。这些操作包括构成通过预定密钥所签署的公有密钥密码标准(PKCS)请求(框820)。PKCS请求可对应于PCKS 10标准，其构成证明请求。更具体来说，PCKS 10对应于发送给证明机构以请求密钥的证明的消息的格式。密钥可以是公有或私有密钥，以及在后一种情况下可对应于移动装置10的用户的私有密钥。

一旦PCKS请求已经构成，则请求可采用增强隐私身份(EPID)密钥来加密或签署(框830)。EPID是按照匿名方式来提供身份的证据的密码协议。按照这个协议，发出EEPID的实体没有将用户的私有密钥存储在数据库中，以及如果用户的私有密钥被暴露，则EPID密钥是可撤消的。

更具体来说，EPID采用具有增强撤消能力的直接匿名证明方案，其为用户提供增强的保护措施。与其它方法不同，在EPID中，没人能够开启组签名以确定签名人。此外，EPID能够用于认证以及证明，同时保存用户的隐私。

一旦PCKS请求采用EPID密钥来加密，则被发送给身份请求方(框840)。该请求可沿OTA连接或者不同的连接被发送。由于EPID所提供的增强保护，所以请求的安全性保持不变。身份请求方则可如同框750中那样建立第二用户身份。

图9示出用于执行OTA身份配备的***的另一个实施例，其中身份请求方位于电子装置中。在这个实施例中，身份请求方915位于用户的电子装置910中，其例如可以是移动装置或者先前所述的其它装置的任一个。身份请求方可按照与先前为了得到身份凭证以及与身份提供方920交互执行的其它操作所述的身份请求方相似的方式进行操作。身份提供方和身份请求方/装置可通过OTA连接930相互通信。

按照另一个实施例，省略电子装置，以及身份请求方基于身份提供方先前建立的身份来建立用户的身份。这种实施例可涵盖例如其中身份请求方是销售点(POS)终端、售票终端或自动柜员机、加油站泵的控制***、办公室、大楼或家庭的安全***、停车验证或缴费机或者要求用户认证和身份确证的其它***或装置的情况。

另一个实施例对应于存储包括用于执行先前所述方法的操作的代码段的程序的计算机可读媒体。第一计算机可读媒体可位于身份请求方中，存储用于执行管理引擎及其关联特征的操作的代码。第二计算机可读媒体可位于身份提供方中，用于存储执行如先前所述的身份提供方的操作的代码。第三计算机可读媒体可位于用于执行如本文所述的请求和/或接收服务的操作的装置中。

本说明中提到一“实施例”表示结合该实施例所述的具体特征、结构或特性包含在本发明的至少一个实施例中。这类措辞在本说明的各个位置中的出现不一定都表示相同实施例。此外，在结合任何实施例来描述某个具体特征、结构或特性时，认为结合实施例的其它特征、结构或特性来实现这种特征、结构或特性处于本领域的技术人员的知识范围之内。另外，本文所述的任一个实施例的特征可与一个或多个其它实施例的特征相结合，以形成附加实施例。

此外，为了便于理解，某些功能块可能描绘为分开的块；但是，这些分开描绘的块不应一定理解为按照对它们进行论述或者本文提供的顺序。例如，某些块可以能够以交替顺序、同时等方式来执行。

虽然参照许多说明性实施例描述了本发明，但是应当理解，能够由本领域的技术人员设计将落入本发明的原理的精神和范围之内的其它许多修改和实施例。更具体来说，在不背离本发明的精神时，合理的变更和修改在上述公开、附图和所附权利要求的范围之内的主题组合布置的组件部分和/或布置方面是可能的。除了组件部分和/或布置方面的变更和修改之外，备选使用也是本领域的技术人员显而易见的。

Claims

1. 一种设备，包括：

接口，被耦合到空中(OTA)链路；

存储区，存储与用户的第一身份对应的数据；以及

处理器，基于要存储在所述存储区中与所述第一身份对应的所述数据来建立所述用户的第二身份，其中与所述第一身份对应的所述数据要在安全协议会话期间通过所述接口被接收，并且其中所述第一身份要对第一服务被建立，以及所述第二身份要对第二服务被建立，所述第一和第二服务由所述用户的电子装置来接收。

2. 如权利要求1所述的装置，其中，所述设备被包含在所述装置中。

3. 如权利要求1所述的装置，其中，所述设备和装置通过无线链路进行通信。

4. 如权利要求1所述的设备，其中，所述装置是移动通信装置。

5. 如权利要求1所述的设备，其中，与所述用户的所述第一身份对应的所述数据要在加密信号中被接收。

6. 如权利要求5所述的设备，其中，所述加密信号采用增强隐私标识(EPID)密钥来加密。

7. 如权利要求1所述的设备，其中，与所述第一身份对应的所述数据包括所述用户的多个凭证。

8. 如权利要求7所述的设备，其中，所述处理器要：

接收对一个或多个要求凭证的请求，

将要在所述存储区中存储的所述多个凭证与所述一个或多个要求凭证进行比较，以及

如果所述一个或多个要求凭证被包含于要在所述存储区中存储的所述多个凭证中，则建立所述用户的所述第二身份。

9. 如权利要求8所述的设备，其中，所述处理器要：

如果所述一个或多个要求凭证没有全部被包含于要在所述存储区中存储的所述多个凭证中，则从另一个源得到与所述用户的身份对应的数据。

10. 如权利要求1所述的设备，其中，与所述用户的所述第一身份对应的所述数据要基于公有密钥密码标准(PKCS)信号被接收。

11. 一种设备，包括：

接口，被耦合到空中(OTA)链路；

存储区，存储与用户的身份对应的数据；以及

控制器，接收来自OTA链路的请求信号，将身份数据的所述请求信号中的信息与所述存储区中与所述身份对应的所述数据进行比较，以及基于所述比较将与所述用户的所述身份对应的所述数据从所述存储区发送给所述OTA链路，其中与所述用户的所述身份对应的所述数据要在对所述设备所执行的安全协议会话期间通过所述OTA链路被发送。

12. 如权利要求11所述的设备，其中，当所述比较指示所述请求信号中的身份数据的所述信息没有全部被包含在所述存储区中的所述数据中时，所述控制器要阻止发送所述存储区中的所述数据。

13. 如权利要求11所述的设备，其中，当所述比较指示所述请求信号中的身份数据的所述信息全部被包含在所述存储区的所述数据中时，所述控制器要发送所述存储区中的所述数据。

14. 如权利要求11所述的设备，其中，要存储在所述存储区中的所述数据包括：

第一优先级的一个或多个身份凭证，以及

与所述第一优先级不同的第二优先级的一个或多个身份凭证。

15. 如权利要求14所述的设备，其中：

所述第一优先级对应于公共可用凭证，以及

所述第二优先级对应于所述用户的私有凭证。

16. 如权利要求14所述的设备，其中，所述请求消息中的身份数据的所述信息要包括所述用户的一个或多个身份凭证，并且所述控制器要：

将所述请求信号中的所述一个或多个身份凭证与存储器中存储的授权数据进行比较，所述授权数据指示所述用户已经给予对公开所述第一优先级的凭证但是不公开所述第二优先级的凭证的准许，以及

当所述比较指示所述请求信号中的所述身份凭证的至少一个具有所述第二优先级时，阻止发送所述存储区中存储的、与所述用户的所述身份对应的所述数据。

17. 如权利要求11所述的设备，其中，所述控制器要基于增强隐私标识(EPID)密钥、采取加密形式将与所述用户的所述身份对应的所述数据从所述存储区发送给所述OTA链路。

18. 一种用于控制对信息的访问的方法，包括：

通过空中(OTA)链路向身份提供方发送请求；

在发送所述请求之后从所述身份提供方接收数据，来自所述身份提供方的所述数据对应于用户的第一身份；以及

基于从所述身份提供方所接收的所述数据来建立所述用户的第二身份，其中与所述第一身份对应的所述数据要在安全协议会话期间被接收，其中所述第一身份由所述身份提供方对第一服务来建立，以及其中建立所述第二身份以接收第二服务，所述第一和第二服务由所述用户的电子装置来接收。

19. 如权利要求18所述的方法，其中，至少所述接收和建立由身份请求方来执行，以及其中所述身份请求方要提供所述第二服务。

20. 如权利要求18所述的方法，其中，至少所述接收和建立由身份请求方来执行，以及其中所述身份请求方被包含在所述电子装置中。

21. 如权利要求20所述的方法，其中，所述装置是移动通信装置。

22. 如权利要求18所述的方法，其中，来自所述身份提供方的所述数据在加密信号中被接收。

23. 如权利要求22所述的方法，其中，所述加密信号采用增强隐私标识(EPID)密钥来加密。

24. 如权利要求18所述的方法，其中，所述请求包括识别要从所述身份提供方所接收的、用于基于所述第一身份来建立所述第二身份的一个或多个身份凭证的信息。

25. 如权利要求18所述的方法，其中，所述第一服务或者所述第二服务中的至少一个基于预订。

26. 一种用于控制对信息的访问的方法，包括：

存储与用户对应的身份数据；

接收对所述用户的身份数据的请求；

将所述请求中的身份数据与所存储的身份数据进行比较；以及

基于所述比较将所存储的身份数据发送给身份请求方，

其中所述请求从所述身份请求方被接收，以及所存储的数据经过空中(OTA)链路被发送给所述身份请求方，以及其中所存储的数据在安全协议会话期间通过所述OTA链路被发送。

27. 如权利要求26所述的方法，其中，当所述请求中的所述身份数据全部被包含在所存储的身份数据中时，向所述身份请求方发送所存储的身份数据。

28. 如权利要求26所述的方法，其中，当所述请求中的所述身份数据没有全部被包含在所存储的身份数据中时，不向所述身份请求方发送所存储的身份数据。

29. 如权利要求26所述的方法，其中，所存储的数据包括第一优先级的第一身份凭证和第二优先级的第二身份凭证，以及其中尚未由所述用户给予公开第二优先级凭证的授权时，不向所述身份请求方发送所存储的身份数据。

30. 如权利要求26所述的方法，其中，所存储的身份数据在采用增强隐私标识(EPID)密钥所加密的信号中被发送。