一种以用户为中心的移动互联网身份管理及认证方法.pdf

《一种以用户为中心的移动互联网身份管理及认证方法.pdf》由会员分享，可在线阅读，更多相关《一种以用户为中心的移动互联网身份管理及认证方法.pdf（14页完整版）》请在专利查询网上搜索。

1、(10)申请公布号 CN 102984127 A (43)申请公布日 2013.03.20 C N 1 0 2 9 8 4 1 2 7 A *CN102984127A* (21)申请号 201210435503.2 (22)申请日 2012.11.05 H04L 29/06(2006.01) H04L 9/32(2006.01) (71)申请人武汉大学 地址 430072 湖北省武汉市武昌区珞珈山武 汉大学 (72)发明人王鹃 谢旭晖 周斯珺 宋蕊霞 杨明 何琪 蒋万伟 余茗婧 唐西铭 王勇 (74)专利代理机构武汉科皓知识产权代理事务 所(特殊普通合伙) 42222 代理人严彦 (54) 发。

2、明名称 一种以用户为中心的移动互联网身份管理及 认证方法 (57) 摘要 一种以用户为中心的移动互联网身份管理及 认证方法，该方法在移动平台上设置用户身份代 理负责管理用户身份信息，用户可以通过身份代 理创建自己的身份信息卡，也可以通过身份代理 请求和管理可信第三方颁发身份信息。用户的身 份信息以虚拟卡的形式表示。用户的身份信息由 用户自己管理，仅将Web站点需要的必要身份信 息提交给Web站点。用户身份信息的提交需要得 到用户的授权，从而在身份管理中体现以用户为 中心以及身份信息用户可控的特点。用户在Web 站点注册或登录时主要通过公私钥进行身份认 证，不再依赖于用户名/密码的身份认证方式。。

3、如 果RP具有合法的数字证书，则该系统可通过身份 管理代理验证RP的数字证书，防止钓鱼攻击。 (51)Int.Cl. 权利要求书2页 说明书9页 附图2页 (19)中华人民共和国国家知识产权局 (12)发明专利申请 权利要求书 2 页 说明书 9 页 附图 2 页 1/2页 2 1.一种以用户为中心的移动互联网身份管理及认证方法，用于用户通过用户端上的用 户端应用程序连接到Web站点时进行认证，其特征在于：在用户端设置负责管理用户公私 钥对和身份信息的用户身份代理，记为IdA；用户的身份信息采用虚拟卡向用户预登录的 Web站点提供，所述虚拟卡为用户提供的自建卡或第三方身份提供者提供的托管卡； 。

4、采用自建卡的注册过程包括以下步骤， 第一步，用户端应用程序访问支持虚拟卡登录的某Web站点，该Web站点记为RP； 第二步，RP将所需要的身份信息发送给用户端应用程序； 第三步，用户端应用程序调用IdA；IdA向用户提供选卡界面，并在选卡后向用户提示 要提交给RP的身份信息，用户授权提交后进入第四步； 第四步，IdA请求与RP建立SSL安全连接； 第五步，RP与IdA建立SSL安全连接，RP产生一个随机数nonce1，发送给IdA；在建立 SSL安全连接的协商过程中，通信双方交换各自的公钥； 第六步，IdA生成一个随机数nonce2和会话密钥K，并用RP的公钥加密会话密钥K；随 后，将用户端和。

5、RP的标识、nonce1、用户端的公钥以及RP需要的身份信息进行摘要运算， 并通过用户端的私钥进行签名，生成身份令牌Token；最后将身份令牌Token、IdA自己的公 钥、以及RP需要的身份信息通过会话密钥加密后作为自签名的身份信息一起发送给RP； 自签名的身份信息表示为SSLE PubkRP K,rp,c,nonce1,nonce2,E K Pubk C ,claims,Si g PrikC (SHA1(rp,c,nonce1,Pubk C ,claims) ，其中rp和c分别表示RP和用户端的标识， claims表示发送给RP的身份信息， Pubk RP 表示RP的公钥，K 表示会话密钥。

6、，Pubk C 表示用 户端的公钥，E PubkRP K表示用RP的公钥Pubk RP 加密密钥K，E K 表示用密钥K对消息加密， nonce1是RP发送的随机数，nonce2是IdA产生的随机数， SHA1表示所采用的hash算法， Sig PrikC 表示利用用户端的私钥对消息进行签名，SSL表示以SSL方式发送； 第七步，RP收到IdA所发送自签名的身份信息之后，利用用户端的公钥验证数字签名， 如果签名验证成功，则获得用户端的IdA发送的身份信息，并为该用户生成一个User ID， 同时利用会话密钥将User ID和nonce2加密，通过SSL方式发给IdA；IdA解密信息后，比 较n。

7、once2值是否与自己创建的nonce2一致，如果是，则记录UserID，将UserID与CardID 建立关联，允许用户端应用程序访问RP的授权资源； 采用托管卡的注册过程包括以下步骤， 第一步，用户端应用程序访问支持虚拟卡登录的某Web站点，该Web站点记为RP； 第二步，RP将所需要的身份信息发送给用户端应用程序； 第三步，用户端应用程序调用IdA；IdA向用户提供选卡界面，并在选卡后进入第四步； 第四步，IdA将用户端定向到IdP，用户在IdP进行身份认证； 第五步，身份认证成功后，IdP给IdA发送一个用IdP私钥签名的身份令牌Token，以及 IdP的公钥和RP需要的身份信息；身份。

8、令牌Token中包括RP需要的身份信息，IdP产生的 随机数nonce及IdP和RP的标识，并用IdP的私钥签名； 第六步，IdA将IdP发送给RP的身份信息显示给用户，在用户授权提交后，请求与RP建 立SSL安全连接； 第七步，RP与IdA建立SSL连接，并产生一个随机数nonce1发送给IdA； 第八步，IdA产生一个会话密钥，将IdP签发的身份令牌Token、IdP的公钥以及产生的 权 利 要 求 书CN 102984127 A 2/2页 3 随机数nonce2，以会话密钥加密后将信息发送给RP； 具体发送的信息格式为SSLE PubkRP K,rp，c, nonce1, nonce2,。

9、E K nonce1,nonce2, idp，c, nonce, claims,PubK IdP ,Sig privkIdP (SHA1(idp，rp, nonce, claims) )，其中，rp和 c、idp分别表示RP和用户端、IdP的标识，claims表示发送给RP的身份信息，Pubk RP 表示 RP的公钥，K表示IdA生成的会话密钥，E PubkRP K表示用RP的公钥Pubk RP 加密密钥K，E K 表示用密钥K对消息加密，nonce是IdP产生的随机数，nonce1是RP发送的随机数，nonce2 是IdA产生的随机数， PubK IdP 表示IdP的公钥；SHA1表示所采用。

10、的hash算法，Sig privkIdP 表 示利用IdP的私钥对消息进行签名，SSL表示以SSL方式发送； 第九步，RP收到用户端的IdA发送的信息之后，利用IdP的公钥验证数字签名，如果签 名验证成功，则获得用户端发送的身份信息，允许用户访问RP的授权资源，并为该用户生 成一个UserID，同时利用会话密钥将UserID和nonce2加密发给IdA；IdA解密信息后，比 较nonce2值是否与自己创建的nonce2一致，如果是则记录UserID，将UserID与CardID建 立关联，允许用户端应用程序访问RP的授权资源。 2.如权利要求1所述以用户为中心的移动互联网身份管理及认证方法，其。

11、特征在于： 采用自建卡注册后，再次登录RP时，IdA无需再取得RP所需要的身份信息，仅需产生一个 随机数，并将RP分配给用户的User ID、随机数和RP的标识通过用户的私钥进行签名，生成 认证令牌，并产生会话密钥进行加密，通过SSL的方式发送给RP。 3.如权利要求1所述以用户为中心的移动互联网身份管理及认证方法，其特征在于： 采用托管卡注册后，再次登录RP时，IdA自动显示用户首次进行身份认证的卡，并在用户确 认后与IdP通信，获得IdP颁发的认证令牌；RP通过该认证令牌鉴别用户的身份。 权 利 要 求 书CN 102984127 A 1/9页 4 一种以用户为中心的移动互联网身份管理及认。

12、证方法 技术领域 0001 本发明属于互联网技术领域，特别是涉及一种新的基于虚拟卡的以用户为中心的 移动互联网身份管理及认证。 背景技术 0002 从身份管理的发展历程看，大概经历了三个发展阶段：集中式的身份管理，联合式 身份管理和分布式身份管理。 0003 集中式的身份管理的特点是用户的身份信息由域内的身份提供方（Identity Provider，IdP）进行管理，并且只在该域内使用，如Kerberos, 微软的Cardspace。用户在 该域内有一个唯一的身份标识，通过这个数字标识，可以使用该域内所有的服务。集中式的 身份管理便于在一个特定的范围内使用，无法满足跨域环境下身份认证的需求，。

13、于是便出 现了联合式的身份认证。 0004 联邦式身份认证的特点是存在多个身份提供方，每个身份提供方负责一个域内用 户身份信息的管理。为使用户能够利用本域的唯一身份访问其它域的服务，而不用在各个 域内的IdP都进行注册，各IP必须事先建立信任关系， 然后通过事先建立的信任关系及 用户身份信息映射，实现跨域的身份认证。联邦式身份管理方式的典型代表，如OpenSSO、 Shibboleth。联邦式身份管理方式要求用户在身份认证前，各IP必须建立信任关系，这对 于开放、分布式的互联网来说，是难于实现的，于是以Web站点中心的分布式身份管理方式 开始被采用。 0005 以Web站点中心的分布式身份管理。

14、中，用户在各个Web服务提供方注册，然后通过 用户名/密码访问该Web服务提供方的服务。这种方式，简单灵活，却造成了目前用户身份 信息隐私泄露、一个用户多个身份标识，以及由于用户名/密码登录方式而造成的网络钓 鱼攻击等日益严重的身份管理问题。 0006 为解决日益严峻的互联网身份泄露问题，近年来以用户为中心的分布式身份管理 模式（见有关文献）被提出。以用户为中心(User-Centric)的身份管理包含了两层含义： 一、用户的一些身份隐私信息不再由 Web站点（Relying Party，RP）保存，而是由用户自己 保存或者保存在可信的第三方身份提供者（Identity Provider, I。

15、dP） ，从而避免了存储 在Web 站点的用户身份信息的泄露。此外，这些分布式的 IdP 之间不需要事先建立信任关 系，用户可以自己选择任何一个信任的 IdP 存储身份信息。二、用户身份信息的揭漏必须 经过用户的授权，并满足用户的策略，即用户身份信息的使用是用户可控的。 0007 有关文献：K. Cameron and M. B. Jones. 2006. Design Rationale behind the Identity Metasystem Architecture, Microsoft Corporation, Redmond, Wash. K. Bhargavan, C. Fou。

16、rnet, A. D. Gordon, and N. Swamy. 2008.Verified implementations of the information card federated identity-management protocol. In ASIACCS 08, pages 123-135. ACM. Gail-Joon Ahn, Moonam Ko, Mohamed Shehab. Privacy-enhanced User-Centric Identity Management. IEEE international 说 明 书CN 102984127 A 2/9页 。

17、5 Conference on Communication, 2009. PP 40-48。 0008 目前，美国和欧盟已经启动了多个身份管理的项目，如SWIFT，PRIME等，研究互联 网中以用户为中心的身份信息管理技术。比较有代表性的以用户为中心的身份管理技术是 以URI作为身份标识OpenID。 0009 OpenID是一个分布式的Internet身份认证技术。OpenID利用一个带有IP地址的 URI作为身份标识。当用户需要在其它Web站点认证时，只需要提供URI表示的身份标识, 该Web站点便可直接重定向到URI指示的IP服务器进行身份认证。一旦用户通过了该IP 的身份认证,那么用户。

18、就可以直接访问Web站点了。OpenID是去中心化的，任何网站都可 以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。 0010 我国对于身份管理的研究工作（见有关文献），主要集中在联邦式身份管理技术方 面。此外，2008年，刘润达等对OpenID技术进行了介绍。2010年，信息网络安全公安部重 点实验室（公安部第三研究所），对英国的电子身份证制度进行了研究。从现状看，尚缺乏对 以用户为中心的分布式身份管理技术的深入研究。 0011 有关文献：刘润达; 王卷乐; 杜佳. OpenID:一种开放的数字身份标识管理及其 认证框架. 计算机应用与软件,2008(。

19、12):41-46.Cardspace在校园网身份认证系统中的 应用研究，电子科技大学硕士论文，2011李建； 沈昌祥； 韩臻； 何永忠； 刘毅；身份管 理研究综述. 计算机工程与设计 ,2009(7):1365-1370.黄道丽. 国家网络空间可信身份 制度研究 以英国电子身份管理(eIDM)制度为个案. Proceedings of 2010 Asia-Pacific Conference on Information Network and Digital Content Security（2010APCID）. 信 息网络安全公安部重点实验室（公安部第三研究所）。 0012 经过前期的。

20、研究，我们发现以用户为中心的身份管理机制尚存在一些问题。 OpenID是互联网分布式身份管理的典型代表，虽然OpenID通过URI的形式表示用户身份， 简单易用，但是由于缺乏对IdP的身份确认，使得任何人都可以建立一个网站提供OpenID 验证服务，导致其信任度不高。此外，OpenID系统中，用户的身份信息全部交给IdP管理和 存储，使得IdP容易成为身份认证系统的瓶颈。最后，利用OpenID在第三方站点认证时，需 要在表单中输入自己的用户名和IdP域名，这也在一定程度上泄露了用户的隐私。 0013 综上所述，以用户为中心的身份管理作为一种新技术，国内外对于这种新的身份 管理技术的研究刚刚起步。

21、，在体系结构、身份信息的隐私保护以及互操作性等方面缺乏足 够的理论研究和技术支持，导致目前互联网用户身份信息泄漏的问题仍然难以解决，为此， 必须进一步研究以用户为中心的身份管理技术，从理论和技术上解决互联网用户身份信息 泄漏、密码疲劳及钓鱼攻击等的问题。 发明内容 0014 针对上述问题，本发明提出一种基于虚拟卡的以用户为中心的移动互联网身份管 理及认证方法。该方法可用于移动互联网的身份管理及认证，解决移动平台在访问Web站 点时采用用户名/密码方式带来的密码输入低效、密码疲劳、钓鱼攻击等问题。 0015 本发明的技术方案为一种以用户为中心的移动互联网身份认证方法，用于用户通 过用户端上的用户。

22、端应用程序连接到Web站点时进行认证，在用户端设置负责管理用户公 私钥对和身份信息的用户身份代理，记为IdA；用户的身份信息采用虚拟卡向用户预登录 说 明 书CN 102984127 A 3/9页 6 的Web站点提供，所述虚拟卡为用户提供的自建卡或第三方身份提供者提供的托管卡； 采用自建卡的注册过程包括以下步骤， 第一步，用户端应用程序访问支持虚拟卡登录的某Web站点，该Web站点记为RP； 第二步，RP将所需要的身份信息发送给用户端应用程序； 第三步，用户端应用程序调用IdA；IdA向用户提供选卡界面，并在选卡后向用户提示 要提交给RP的身份信息，用户授权提交后进入第四步； 第四步，IdA。

23、请求与RP建立SSL安全连接； 第五步，RP与IdA建立SSL安全连接，RP产生一个随机数nonce1，发送给IdA；在建立 SSL安全连接的协商过程中，通信双方交换各自的公钥； 第六步，IdA生成一个随机数nonce2和会话密钥K，并用RP的公钥加密会话密钥K；随 后，将用户端和RP的标识、nonce1、用户端的公钥以及RP需要的身份信息进行摘要运算， 并通过用户端的私钥进行签名，生成身份令牌Token；最后将身份令牌Token、IdA自己的公 钥、以及RP需要的身份信息通过会话密钥加密后作为自签名的身份信息一起发送给RP； 自签名的身份信息表示为SSLE PubkRP K,rp,c,non。

24、ce1,nonce2,E K Pubk C ,claims,Si g PrikC (SHA1(rp,c,nonce1,Pubk C ,claims) ，其中rp和c分别表示RP和用户端的标识， claims表示发送给RP的身份信息， Pubk RP 表示RP的公钥，K 表示会话密钥，Pubk C 表示用 户端的公钥，E PubkRP K表示用RP的公钥Pubk RP 加密密钥K，E K 表示用密钥K对消息加密， nonce1是RP发送的随机数，nonce2是IdA产生的随机数， SHA1表示所采用的hash算法， Sig PrikC 表示利用用户端的私钥对消息进行签名，SSL表示以SSL方式发。

25、送； 第七步，RP收到IdA所发送自签名的身份信息之后，利用用户端的公钥验证数字签名， 如果签名验证成功，则获得用户端的IdA发送的身份信息，并为该用户生成一个User ID， 同时利用会话密钥将User ID和nonce2加密，通过SSL方式发给IdA；IdA解密信息后，比 较nonce2值是否与自己创建的nonce2一致，如果是，则记录UserID，将UserID与CardID 建立关联，允许用户端应用程序访问RP的授权资源； 采用托管卡的注册过程包括以下步骤， 第一步，用户端应用程序访问支持虚拟卡登录的某Web站点，该Web站点记为RP； 第二步，RP将所需要的身份信息发送给用户端应用程。

26、序； 第三步，用户端应用程序调用IdA；IdA向用户提供选卡界面，并在选卡后进入第四步； 第四步，IdA将用户端定向到IdP，用户在IdP进行身份认证； 第五步，身份认证成功后，IdP给IdA发送一个用IdP私钥签名的身份令牌Token，以及 IdP的公钥和RP需要的身份信息；身份令牌Token中包括RP需要的身份信息，IdP产生的 随机数nonce及IdP和RP的标识，并用IdP的私钥签名； 第六步，IdA将IdP发送给RP的身份信息显示给用户，在用户授权提交后，请求与RP建 立SSL安全连接； 第七步，RP与IdA建立SSL连接，并产生一个随机数nonce1发送给IdA； 第八步，IdA产。

27、生一个会话密钥，将IdP签发的身份令牌Token、IdP的公钥以及产生的 随机数nonce2，以会话密钥加密后将信息发送给RP； 具体发送的信息格式为SSLE PubkRP K,rp，c, nonce1, nonce2,E K nonce1,nonce2, idp，c, nonce, claims,PubK IdP ,Sig privkIdP (SHA1(idp，rp, nonce, claims) )，其中，rp和 说 明 书CN 102984127 A 4/9页 7 c、idp分别表示RP和用户端、IdP的标识，claims表示发送给RP的身份信息，Pubk RP 表示 RP的公钥，K表示。

28、IdA生成的会话密钥，E PubkRP K表示用RP的公钥Pubk RP 加密密钥K，E K 表示用密钥K对消息加密，nonce是IdP产生的随机数，nonce1是RP发送的随机数，nonce2 是IdA产生的随机数， PubK IdP 表示IdP的公钥；SHA1表示所采用的hash算法，Sig privkIdP 表 示利用IdP的私钥对消息进行签名，SSL表示以SSL方式发送； 第九步，RP收到用户端的IdA发送的信息之后，利用IdP的公钥验证数字签名，如果签 名验证成功，则获得用户端发送的身份信息，允许用户访问RP的授权资源，并为该用户生 成一个UserID，同时利用会话密钥将UserID。

29、和nonce2加密发给IdA；IdA解密信息后，比 较nonce2值是否与自己创建的nonce2一致，如果是则记录UserID，将UserID与CardID建 立关联，允许用户端应用程序访问RP的授权资源。 0016 而且，采用自建卡注册后，再次登录RP时，IdA无需再取得RP所需要的身份信息， 仅需产生一个随机数，并将RP分配给用户的User ID、随机数和RP的标识通过用户的私钥 进行签名，生成认证令牌，并产生会话密钥进行加密，通过SSL的方式发送给RP。 0017 而且，采用托管卡注册后，再次登录RP时，IdA自动显示用户首次进行身份认证的 卡，并在用户确认后与IdP通信，获得IdP颁发。

30、的认证令牌；RP通过该认证令牌鉴别用户的 身份。 本发明的特点： （1） 用户通过身份管理代理来管理和使用自己的身份信息，而不是像OpenID将 所有的身份信息交给第三方身份管理机构管理。此外，用户身份信息的提交需要得到用户 的授权，从而真正体现了身份管理中以用户为中心以及身份信息用户可控的特点。 0018 （2） 用户通过公私钥对或数字证书证明其身份，不再依赖于用户名/密码 的身份认证方式。 0019 （3） 如果RP具有合法的数字证书，则可通过身份管理代理验证RP的数字证 书，防止钓鱼攻击。 附图说明 0020 图1是本发明实施例的原理示意图。 0021 图2是本发明实施例的为用户自创建卡。

31、身份认证过程图。 0022 图3是本发明实施例的托管卡（第三方卡）身份认证过程图。 0023 具体实施方式 以下结合附图和实施例详细说明本发明技术方案。 0024 如图1所示，实施例的运行涉及三方，具体运行系统由用户（User）、用户端应用程 序（Client Application，通常指浏览器）、身份代理（IdA，Identity Agent）、身份提供者 （Identity Provider, IdP）和用户预登录的Web站点(Relying Party, RP)组成。用户、用 户端应用程序、身份代理属于用户端一方，用户端应用程序和身份代理设置在用户所使用 的用户端设备（如计算机、移动智。

32、能设备Mobie Platform等）上。浏览器可以使用任意一款 浏览器，IdA是本发明独创设置，具体实施时可采用计算机软件技术实现，例如在Android 系统上实现。RP与IdP通常是一个网站，可以采用接入互联网的服务器提供，但需支持虚拟 卡身份认证方式。用户端设备与RP、IdP分别通过互联网建立通信连接。 说 明 书CN 102984127 A 5/9页 8 0025 其中关键部分的具体实现说明如下： 1、 用户身份代理 用户身份代理（IdA）负责管理用户公私钥对和身份信息，包括用户身份信息的建立、获 取、授权、使用和维护。用户可以通过身份管理代理创建自己的身份信息卡（自创建卡），也 可以。

33、通过虚拟卡（Vcard）的形式管理IdP颁发的身份信息（可称为第三方卡或托管卡）。 0026 通过IdA，用户可以以虚拟卡的形式创建、删除、导入、导出及发送身份信息。用户 可以预先创建多张含有不同身份信息内容的虚拟卡。当用户利用RP认证时，选择虚拟卡方 式后，浏览器将自动触发IdA，此时用户可选择一张合适的虚拟卡在RP进行身份认证，可以 是自创建卡，也可以是托管卡。如果是自建卡，则IdA直接与RP进行通信；如果是托管卡， IdA将与该卡的身份信息提供方（IdP）通信，取得RP需要的身份信息及IdP用其私钥签名 的身份令牌，并转发给RP进行身份认证。 0027 2、 用户预登录的Web站点 用户。

34、预登录的Web站点(Relying Party, RP) 代表用户要进行身份认证的网站，该网 站需要支持Vcard身份认证方式。 0028 实施例中，RP采用JSP/Servlet技术，以Tomcat为应用服务器，使用JDK6的 Keytool工具生成密钥库。除了用户名/密码登录外，将支持自建卡注册、登录，托管卡注 册、登录，已有账户和虚拟卡(自建卡或托管卡)建立关联三种注册使用虚拟卡的方式。 0029 3、身份提供者 身份提供者（Identity Provider, IdP）的主要功能是给用户颁发托管卡以及在用户 利用托管卡登录RP的过程中，为用户生成身份令牌。托管卡中主要包含了卡ID和Id。

35、P的 URL，IdA根据卡中的URL去IdP取得身份令牌。身份令牌采用1024位的RSA非对称算法 签名，并通过HTTPS协议进行传输。IdA收到回复消息之后，将解析HTTP报文正文部分取得 IdP颁发的身份令牌。 0030 虚拟卡为用户提供的自建卡或第三方提供的托管卡。具体实施时，认证过程可采 用计算机软件技术实现自动运行。 0031 用户自创建卡：由用户自己创建，可以包含用户的各种身份信息，可以有很多张， 每张卡有一个ID号（CardID），用来登录不同的网站。身份认证的方式主要利用公钥/私钥 的方式。用户在安装IdA时， IdA会根据用户的口令自动为用户产生一对公私钥对，用于以 后的身份。

36、认证。具体自建卡身份认证过程见附图2，其通信流程如下： 第一步：用户端应用程序（浏览器）访问某Web站点。该站点支持虚拟卡(Vcard) 登 录,用户选择Vcard方式登录。 0032 第二步：RP将所需要的身份信息发送给浏览器。具体实施时可以Policy的形式 发送，Policy表示RP需要的信息，一般包括多个用户属性，如用户名，用户邮箱等等，通常 网站的Policy还对信息的格式进行了要求。 0033 第三步：浏览器调用IdA。IdA弹出选卡界面，用户根据RP需要的身份信息选择一 张合适的卡（系统也可以根据上述RP需要的身份信息，将满足需要的卡提示给用户）。选卡 后，IdA向用户提示要提交。

37、给RP的身份信息，用户授权后，身份信息才可提交给RP。当RP 需要的身份信息只是所选卡中的部分信息时，从中提取相应信息进行提交即可，不必发送 整张卡的所有信息。如果找不到合适的卡，用户也可以相应创建一张。 说 明 书CN 102984127 A 6/9页 9 0034 第四步：IdA请求与RP建立SSL安全连接，其后的通讯过程都将通过SSL方式安 全通信。 0035 第五步：RP与IdA建立SSL连接。RP产生一个随机数nonce1，通过SSL发送给 IdA。在建立连接协商的过程中，通信双方将交换各自的公钥。 0036 第六步：IdA生成一个随机数nonce2和会话密钥K，并用RP的公钥加密该。

38、会话密 钥K。随后，将用户端和RP的标识、nonce1、用户端的公钥以及RP需要的身份信息进行摘要 运算，并通过用户端的私钥进行签名，生成身份令牌（Token），同时将Token、自己的公钥、 以及RP需要的身份信息通过会话密钥加密后一起发送给RP。 0037 自签名的身份信息表示为SSLE PubkRP K,rp,c,nonce1,nonce2,E K Pubk C ,claims, Sig PrikC (SHA1(rp,c,nonce1,Pubk C ,claims) ，其中rp和c分别表示RP和用户端的标识， claims表示发送给RP的身份信息， Pubk RP 表示RP的公钥，K 表。

39、示会话密钥，Pubk C 表示用 户端的公钥，E PubkRP K表示用RP的公钥Pubk RP 加密密钥K，E K 表示用密钥K对消息加密， nonce1是RP发送的随机数，nonce2是IdA产生的随机数， SHA1表示所采用的hash算法， Sig PrikC 表示利用用户端的私钥对消息进行签名，SSL表示以SSL方式发送。 0038 第七步：RP收到用户端的IdA所发送自签名的身份信息之后，利用用户端的公钥 验证数字签名，如果签名验证成功，则获得用户端的IdA发送的身份信息，并为该用户生成 一个User ID，同时利用会话密钥将User ID和nonce2加密，通过SSL方式发给IdA。

40、。IdA 解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果是，则记录UserID，将 UserID与CardID建立关联。此时用户端的浏览器即可访问RP的授权资源。 0039 成功登陆完成后，可以由IdA记录日志，包括登陆的CardID和相应网站。此后，用 户再登录该网站，IdA将自动显示用户首次进行身份认证的卡，用户确认后即可登录RP。此 时，用户发送给RP的认证信息与用户首次注册登录有所不同。由于在首次登录该RP之后， RP已经为该用户分配了一个ID（User ID），并保存了该用户的ID和公钥，因此再次登录该 RP时，IdA无需再取得RP的policy。此时，IdA仅。

41、需产生一个随机数，并将RP分配给用户 的User ID、随机数和RP的标识通过用户的私钥进行签名，生成认证令牌，并产生会话密钥 进行加密，通过SSL的方式发送给RP。由于该RP已经保存了用户的公钥及ID，因此可以直 接通过用户的公钥验证用户的签名信息，以鉴别用户的身份。 0040 具体通信步骤如下： 第一步：用户端应用程序（浏览器）访问某Web站点。 0041 第二步：浏览器调用IdA。IdA在选卡界面中自动显示首次进行身份认证的卡，用 户确认此卡。IdA向用户提示要提交给RP的身份信息。用户授权后，IdA将身份信息提交 给RP。 0042 第三步：IdA请求与RP建立SSL安全连接，其后的通。

42、讯过程都将通过SSL方式安 全通信。 0043 第四步：RP与IdA建立SSL连接。RP产生一个随机数nonce1，通过SSL发送给 IdA。 0044 第五步：IdA生成一个随机数nonce2和会话密钥K，并用RP的公钥加密该会话密 钥。随后，将用户端和RP的标识、nonce1、UserID进行摘要运算，并通过用户端的私钥进行 签名，生成认证令牌（Token），同时将Token、UserID通过会话密钥加密后一起发送给RP。 说 明 书CN 102984127 A 7/9页 10 0045 具体传送信息表示为SSLE PubkRP K,rp,c,nonce1,nonce2,E K UserI。

43、D,Sig PrikC (SHA1(rp,c,nonce1,UserID ) ) ，其中rp和c分别表示RP和用户端（client）的标识， E K m表示用密钥K对消息m加密，Pubk RP 表示RP的公钥，K 表示会话密钥，SHA1表示所采 用的hash算法，Sig PrikC 表示利用client的私钥进行签名。SSL 表示通过安全套接层协 议传送信息。 0046 第六步：RP收到用户端的IdA所发送自签名的认证信息之后，利用用户端的公钥 验证数字签名，如果签名验证成功，则从发送的信息中取得UserID，与RP端存储的UserID 进行比较。如果相同，则可确认用户的身份。同时利用会话密钥。

44、将User ID和nonce2加密， 通过SSL方式发给IdA 。IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致， 如果是，则用户浏览器可访问RP的授权资源。 0047 托管卡：身份信息由第三方（IdP）认证后颁发，非用户自己创建颁发。例如电子身 份证等。卡中除了用户信息，还需提供认证方的信息，因此具有更高的可信度。用户可利用 这些第三方颁发的身份信息登录RP。 0048 托管卡身份认证过程见附图3，其通信流程如下： 第一步：用户端（浏览器）访问某Web站点。该站点支持虚拟卡(Vcard) 登陆，用户选 择Vcard方式登陆。 0049 第二步：RP将所需要的身份信息以P。

45、olicy的形式发送给浏览器。 0050 第三步：浏览器调用IdA。IdA弹出选卡界面，用户根据RP需要的身份信息选择一 张合适的卡（系统也可以根据上述RP需要的身份信息，将满足需要的卡提示给用户）。如果 找不到合适的卡，用户也可以创建一张。 0051 第四步：IdA将用户端定向到IdP，用户在IdP进行身份认证。 0052 第五步：身份认证成功后，IdP给用户端发送一个用IdP私钥签名的Token，以及 IdP的公钥和RP需要的身份信息。Token中包括RP需要的身份信息，IdP产生的随机数 nonce及IdP和RP的标识，并用IdP的私钥签名。 0053 第六步：IdA将IdP发送给RP的。

46、身份信息显示给用户，用户授权提交该身份信息。 IdA请求与RP建立SSL安全连接。 0054 第七步：RP与IdA建立SSL连接。RP产生一个随机数nonce1，通过SSL通道发送 给IdA。 0055 第八步：IdA产生一个会话密钥，将IdP签发的身份令牌、IdP的公钥以及产生的随 机数，以会话密钥加密，发送给RP。 0056 具体发送的信息格式为SSLE PubkRP K,rp，c, nonce1, nonce2,E K nonce1,nonce2, idp，c, nonce, claims,PubK IdP ,Sig privkIdP (SHA1(idp，rp, nonce, claim。

47、s) )，其中，rp和c、idp分别表示RP和用户端、IdP的标识，claims表示发 送给RP的身份信息，Pubk RP 表示RP的公钥，K表示IdA生成的会话密钥，E PubkRP K表示用 RP的公钥Pubk RP 加密密钥K，E K 表示用密钥K对消息加密，nonce是IdP产生的随机数， nonce1是RP发送的随机数，nonce2是IdA产生的随机数， PubK IdP 表示IdP的公钥；SHA1 表示所采用的hash算法，Sig privkIdP 表示利用IdP的私钥对消息进行签名，SSL表示以SSL 方式发送。 0057 第九步：RP收到用户端的IdA发送的信息之后，利用IdP。

48、的公钥验证数字签名，如 说 明 书CN 102984127 A 10 8/9页 11 果签名验证成功，则获得用户端发送的身份信息。用户即可通过用户端应用程序访问RP的 授权资源，并为该用户生成一个UserID，同时利用会话密钥将UserID和nonce2加密，通过 SSL方式发给IdA。IdA解密信息后，比较nonce2值是否与自己创建的nonce2一致，如果 是， 则记录UserID，将UserID与CardID建立关联。此时用户浏览器即可访问RP的授权资 源。 0058 成功登陆完成后，可以由IdA记录日志，包括登陆的CardID和相应网站。这是用 户第一次利用第三方卡登录某网站的过程，以。

49、后用户再登录该网站，IdA将自动显示用户首 次进行身份认证的卡，用户确认后，与IdP通信，获得IdP颁发的认证令牌。RP通过该认证 令牌鉴别用户的身份。实现时，可以为Token设置生存期，在生存期内，用户可直接利用IdA 保存的认证Token登录RP。只在认证Token过期后，IdA才需与IdP通信，再次获得新的认 证Token。 0059 IdA需要缓存IdP颁发的认证Token、时间戳及nonce值，如果当前请求时间在 Token的有效期内，则IdA与RP建立SSL连接，生成会话密钥及随机数nonce1, nonce2， 直接将Token发送给RP。RP收到后，需验证Token的来源，并检查Token的有效期。如果 Token已经过了有效期，则IdA需要与IdP建立连接，重新获取认证Token。 0060 具体通信流程如下： 第一步：用户端应用程序。