CN104283885B

CN104283885B - 一种基于智能终端本地认证的多sp安全绑定的实现方法

Info

Publication number: CN104283885B
Application number: CN201410542730.4A
Authority: CN
Inventors: 王雅哲; 梁超; 寇睿明; 汪祖辉; 王瑜
Original assignee: Lenovo Mobile Communication Software Wuhan Co Ltd; Institute of Information Engineering of CAS
Priority date: 2014-10-14
Filing date: 2014-10-14
Publication date: 2017-07-28
Anticipated expiration: 2034-10-14
Also published as: CN104283885A

Abstract

本发明涉及一种基于智能终端本地认证的多SP安全绑定的实现方法，引入了“信任预置”思想，通过预置认证设备的公私钥证书，将认证设备和身份认证端绑定起来。通过用户向SP进行注册，产生标记认证设备的用户公私钥UAuth并将该UAuth与用户账户绑定。一个用户持有的安全认证设备可与该用户在同一SP中的多个账户或多个不同SP中的账户进行一对多的双向关联。通过本发明，用户可以通过唯一安全设备安全通过多个身份认证，并在很大程度上取代了传统的用户名密码身份验证方式。并且在保证用户身份认证操作便捷的情况下，大大的提高了认证过程中信息的安全性。

Description

一种基于智能终端本地认证的多SP安全绑定的实现方法

技术领域

本发明属于信息安全领域的身份认证领域，具体涉及到一种基于智能终端本地认证的多SP安全绑定的实现方法。

背景技术

随着网络的发展和互联网的普及(桌面服务的网络化)，互联网服务的多样化和用户定制的个性化使得几乎所有互联网服务提供商在提供相应服务之前都需要用户首先进行身份注册。而传统的身份注册和验证方式(即用户名密码的验证方式)即存在密码泄露或被窃听等诸多安全问题，又会因为数量众多记忆困难给用户造成困扰。随着生物识别技术和图形图像识别技术的发展，传统的用户名密码已不再是基于网络的用户身份认证的唯一选择。本专利将重点放在了用户拥有的信息(Something they have)和用户的自身信息(Something they are)上，使用指纹验证，面部验证或是手机二维码等方式对用户的身份进行鉴别。抛弃基于用户知晓信息的验证方式(something they know)。

这种转变也面临着一些较难解决的问题：第一、如何在不对现有的用户数据造成损害的前提下，使用户在短时间内使用新的身份验证方法登录其持有的账户。数以万计的互联网服务提供商已经形成了成熟且完备的传统身份认证机制，使服务提供商放弃已形成的用户群，并让用户通过新的身份认证方式重新注册账户显然不现实，且会给用户造成信息丢失等困扰。工作的重点应该放在如何将新的身份验证方式绑定到用户已有的账户上来。

第二，身份认证设备的爆发式发展造成了设备种类众多且标准不一的问题，目前尚没有统一的标准规定可用于身份认证的认证设备实体，用户只能参考由服务提供商(SP,Service Provider)提供的推荐设备列表来选择认证设备，不仅认证设备的安全性得不到保障，而且用户需要为其所需的每一个服务提供商准备一个认证设备，认证设备的对应和保存又给用户提出了一个新的难题。

因此，将传统身份认证方式和基于生物特征和图形识别的新型身份认证方式整合起来，将多个服务提供商的认证设备整合起来，就成了现在身份认证发展面临的主要问题。

发明内容

本发明技术解决问题：克服现有技术的不足，提供一种基于智能终端本地认证的多SP安全绑定的实现方法，通过非对称密钥机制将用户通过传统身份注册生成的用户账户UID和利用用户智能终端上安装的认证客户端以及内置或外接于用户智能终端的认证设备提取用户新的身份信息(指纹，面部识别，二维码等)绑定起来，在保证用户身份认证操作便捷的情况下，大大的提高了认证过程中信息的安全性。

本发明技术解决方案：首先通过“信任预置”，在认证设备投入使用前，为认证设备生成公私钥证书，将其公钥存储于身份绑定服务器端，私钥存储于认证设备中，用于双方信息交互过程中的签名和验证。其次，在保证用户身份认证高安全与操作便捷的前提下，在身份绑定过程中，将用户持有的已连接认证设备的智能终端与用户在SP中已申请的账号进行绑定，并且，用户持有的每一个智能终端，都可以同时和多个SP进行绑定，通过这种方式，借助智能终端上的如指纹扫描器、摄像头等认证设备，实现了一种新型的账号映射管理方法，从而实现借助同一用户设备登录多个SP，在简化操作的同时，也大大提高了身份注册绑定过程中的安全性。

本发明具体实现步骤如下：

(1)基于智能终端本地认证的多SP安全绑定的模块化实现方法

本发明的功能实现主要分为三个部分，为了将功能实现之间进行解耦，方便设计以及今后拓展，将本专利划分为了三个模块：Web服务提供商模块、身份绑定服务器模块和绑定服务用户设备模块。下面对这三个模块进行简要功能介绍：

(I)身份绑定模块：该模块在收到Web服务提供商发送的请求后生成身份绑定请求进行身份绑定，并在身份绑定客户端返回身份绑定相应后，验证认证设备签名并存储UID—用户公钥UAuth.pub供后续用户身份验证。除此以外，该模块还会在“信任预置”部分负责提前存储可使用的认证设备公钥。

(II)Web服务提供商模块：该模块的主要功能就是为用户提供Web网络服务并提供注册功能使用户获取在该Web服务上的用户名UID。UID是后续身份绑定过程的必要元素。另外，该模块还会根据所提供服务的安全需要制定自己的安全策略(主要是支持认证设备的列表)。

(III)绑定服务认证设备模块：该模块主要是使用内置或外接与用户智能终端的认证设备收集用户信息(如指纹等生物信息)并为该信息生成用户公私钥，之后安装在智能终端上的身份绑定客户端将用户公钥和用户UID打包为KRD并用设备私钥EAuth.priv进行签名。

(2)基于智能终端本地认证的多SP安全绑定的数据信息交互体系

本专利在功能实现方面通过模块化进行解耦，在每个模块内也有多个层次结构，通过层次内和层次以及模块和模块间的数据交互从而达到用户身份绑定和安全认证的目的。

基于模块内层次结构，通过AppID，FCH，EAuth，UID，Chl，KRD和Policy等数据交互最终实现了身份注册及绑定。其中，AppID主要用于标记请求身份绑定的服务提供商SP，UID用于标记在服务提供商SP上用户的为唯一账户名，而EAuth作为一个认证设备的唯一标记通过公私钥对签名验证机制被身份绑定服务器识别，EAuth在身份验证过程之前已经在认证设备和身份绑定服务器之间沟通好。针对每一个(appID，UID)二元组，认证设备会生成一个全新的公私钥对，公钥由认证设备私钥EAuth.priv签名后发给身份绑定服务器，身份绑定服务器接收到后与用户名一起存入记录。

Chl是由身份绑定服务器产生的一组随机标记，用于防止恶意攻击者的重放攻击。认证策略Policy指明了哪些认证方式是合法的而那些认证方式是不被允许的(身份绑定客户端将据此通过用户代理将可选的认证方式呈现给用户)。

FCH(Final Challenge Params)身份绑定客户端在接收到服务器发来的数据时，通过挑战值、appID等参数生成FCH并将其发送给认证设备。KRD(KeyRegistration)是由FCH、认证设备新生成的用户公钥等数据组成，并由认证设备的EAuth.priv签名。

(3)基于智能终端本地认证的多SP的身份绑定过程

(31)认证设备的“信任预置”

认证设备在出厂后正式投入商用前，首先要对认证设备的安全性等问题进行检测，以对其安全等级等问题进行评估。并且，在正式投入使用前，应为每个型号的安全设备生成公钥证书，并将其对应公钥注册至身份绑定服务器端，私钥保存于设备本身。当身份绑定服务器接收到由认证设备发送并用其私钥签名的数据包时，用其对应的公钥进行验证。

(32)认证设备及身份绑定客户端的安装

认证设备根据智能终端生产商设计的不同，可以内置于智能终端内或是由用户在使用时连接至智能终端，用户通常还应将对应的身份绑定客户端安装至智能设备并通过客户端中的认证设备抽象层为认证设备提供驱动和接口。

(33)身份绑定服务器和SP服务器的配置

身份绑定服务器或可作为SP web服务器的一个子模块，或者可作为一个独立的存在，负责多个SP的身份绑定和验证功能。

(34)用户注册用户账号

用户在SP上注册用户账号UID。

(35)将新注册的用户账户绑定至认证设备上

之前的步骤只是使用了传统的身份注册方法为用户分配了唯一的UID，若要把这个用户绑定到连接至智能终端的认证设备上，智能终端首先要获知与其通信的SP支持何种认证设备。根据不同SP安全等级的不同，并不是所有类型的认证设备都可以被SP接受，故还需要Policy参数指定可用的认证设备，如果连接至智能终端的认证设备不在Policy列表中，则身份绑定失败。

(36)登记已绑定的UID和用户设备

用户完成步骤(35)时，即完成了账号的基本绑定过程；认证设备为用户生成了一个新的公私钥对，将其中的公钥发回身份绑定服务器，身份绑定服务器将公钥和对应的用户存入数据库，当该用户下次登录时，身份绑定服务器用记录的公钥验证登录时认证设备发来的由私钥签名的数据，若验证成功，则用户成功登录。

所述步骤(31)中，身份绑定服务器支持的认证设备对应的EAuth的公钥及相应信息应在认证设备发售前便已登记，身份绑定服务器一旦接收到没有登记过的认证设备发来的绑定请求，将会无视这一请求。

所述步骤(34)中，用户的首次账号注册可以传统的用户名密码表单提交的形式，以尊重用户的传统操作习惯，并其，一旦用户将绑定的认证设备丢失，也可通过用户名密码的方式进行登录操作，传统的用户名密码方式登录后，用户的操作权限是否会受限制或者会受多大限制，可按照SP相应的安全等级进行个性定制。

所述步骤(35)中，如果验证不通过则绑定失败，回滚到UID注册前，防止出现单独的UID无相应认证设备绑定的情况，带来潜在威胁。

所述步骤(36)中，可能因为挑战值对应失败，签名验证失败等造成身份绑定服务器登记失败，则进程回滚到UID注册前，防止出现身份绑定服务器中无对应(UID，认证公钥)对的情况。

用户身份绑定后的身份认证：本发明基于公私钥和服务器端挑战进行身份绑定，可以使得多个SP上的多个用户账户绑定到一个验证设备上。当用户在SP上进行身份注册后并按上述步骤绑定后，用户便可通过持有的认证设备通过认证登录相关SP。用户登录请求激活身份绑定服务器首先发送AppID、policy、Chl和用户名至身份绑定客户端。身份绑定客户端包装AppID，Chl等信息组成FCH传递给认证设备，认证设备认证用户并用对应用户之前生成的私钥对FCH签名生成SignedData，SignedData随即传递给身份绑定服务器，身份绑定服务器根据用户名查找相应的公钥，并使用公钥验证签名，验证通过后，用户即登录成功。由此完成通过公私钥和挑战的用户身份验证过程。用户可以通过个人持有的认证设备登录所有已经完成绑定的SP。

本发明提出的一种基于智能终端本地认证的多SP安全绑定的实现方法，用户应当首先在支持本专利声明的方法的服务提供商(或是该服务提供商集成了实现所述身份绑定方法的身份绑定服务器，或是该服务提供商在提供身份认证及绑定服务的其他身份绑定服务器上注册)注册一个属于自己的用户账号UID，然后参考服务提供商相应的安全策略将相关认证设备连接到智能终端进行身份绑定。这次绑定成功后，用户之后只需通过连接至智能终端激活认证设备并通过认证即可登录相应的SP。无需再使用用户名密码等信息。

本发明与现有技术相比有优点在于：本发明在通过公私钥挑战式进行身份绑定并借助外部认证设备提高用户登录安全性的同时，提出一种便捷账号映射管理方法。用户首先在SP端进行传统的注册，通过身份绑定服务器、身份绑定客户端和认证设备之间的交互为每个新注册的用户生成唯一的公私钥对，公钥保存在身份绑定服务器上，私钥则保存在认证设备上，一台身份绑定服务器可以为多个用户甚至多个SP保存公钥，一个认证设备也可以保存该用户在多个SP上的私钥，故可实现一对多的服务架构。在数据交互过程中全部通过TLS信道加密并使用身份绑定服务器生成挑战值的方法，防止重放等攻击，安全性较传统用户名密码登录方式有较大提高。

附图说明

图1本发明的整体实施示意图；

图2本发明的身份绑定方法中模块架构示意图；

图3本发明身份绑定方法中的数据绑定关系示意图；

图4本身份绑定方法中身份绑定流程图。

具体实施方式

为使本发明的目的、优点以及技术方案更加清楚明白，以下通过具体实施，并结合附图，对本发明进一步详细说明。

对于图1从整体上描述了基于智能终端本地认证的多SP安全绑定过程中数据管理实施的总体架构，主要包括下面三部分的内容。

一、基于智能终端本地认证的多SP安全绑定的模块化实现方法

如图2，本发明的体系设计主要分为三个模块：Web服务提供商模块、身份绑定服务器模块和绑定服务认证设备模块，这种分模块设计主要是为了保证身份绑定过程中，信息的保密、多身份间的便捷管理以及今后的功能及设备扩展。

身份绑定服务器模块：该模块主要负责以下三个功能：

(1)触发身份绑定进程：该模块接收到Web服务提供商的激励后生成身份绑定请求(Identity Binding Request,IB.req)触发身份绑定进程，服务器端会独立为此进程产生一个唯一的挑战值Chl，该挑战值存在于整个绑定过程，用于将针对同一用户的身份绑定请求和应答捆绑起来，并且有效阻止了重放等网络攻击，之后，该模块将生成的身份绑定请求通过Web服务提供商传递发送给绑定服务用户设备模块。

(2)存储绑定UID及用户公钥：在身份绑定进程的最后部分，该模块收到由身份绑定客户端生成并通过Web服务器传递的身份绑定响应(Identity Binding Response,IB.res)，通过之前存储的认证设备公钥EAuth.pub认证身份绑定响应的签名。验证成功后，将其中用户UID和该由用户使用的认证设备产生的用户公钥进行提取对应和独立存储。在之后的身份认证部分，身份绑定服务器中的用户公钥可以用来验证用户数据的签名，以此对用户身份进行认证。

(3)存储并检验设备公钥：在认证设备投入使用之前，设备生产商会和身份绑定服务器进行协商，将该设备的设备公钥存储于该身份绑定服务器的元数据验证部分，表示支持该认证设备。即进行“信任预置”。在该模块接收到由认证设备签名的IB.res时，可通过元数据验证中存储的设备公钥检验该响应是否合法，并最终得出身份绑定结果。

Web服务提供商模块：该模块主要负责以下两个功能：

(1)提供网络服务即用户UID：Web服务提供商模块是整个身份绑定系统的基础模块，没有其提供的网络服务，身份绑定无从谈起。该模块的主要任务是为用户提供其丰富的网络服务。该模块通过传统的表单提交用户名密码的方式为用户产生其UID，随后激励认证服务服务器端开始本专利描述的身份绑定服务。该模块产生的UID是连接服务器端和用户设备端的桥梁，也是用户身份的重要说明。

(2)提供身份绑定策略：Web服务模块会根据自身对安全的需求，为身份绑定过程提供绑定策略，这个策略主要包括可支持的认证设备列表。该模块将此列表通过智能终端上的用户代理展现给用户，用户通过智能终端选择支持的认证设备，并使用此认证设备进行身份绑定。进行接下来的身份绑定流程。

绑定服务认证设备模块：该模块主要负责以下两个功能：

(1)采集用户信息进行绑定：认证设备抽象层为多样的认证设备提供了统一的接口使上层的身份绑定客户端无需在意底层的认证设备具体是什么。智能终端上的认证设备只需根据其特征采集用户的指纹等信息并为该信息生成专属该用户的用户公私钥即可。

(2)生成KRD数据信息：该模块为用户产生用户公私钥UAuth后，智能终端上的身份绑定客户端将用户UID和UAuth.pub等信息打包并使用该设备私钥EAuth.priv进行签名并将其传递至身份绑定服务器实现身份绑定并为之后的身份验证和事务确认做准备。

该模块是整个身份绑定过程的核心部分。也是整个系统可变性可拓展性最丰富的部分。因为认证设备种类就十分繁多，并且随着技术的发展出现了将认证设备和用户设备进行整合的趋势。

三个主要设计模块的结合与使用由于三个设计模块是相互关联而又独立的，可以实现一个认证设备映射绑定到多个UID，而UID同时又可以属于不同的SP，只要这些SP都支持本专利上述的身份绑定方法即可。用户首先在SP端获取到注册的UID，随即SP激励身份绑定服务器开始身份绑定进程，服务器通过安全信道将服务器产生的挑战，表明SP的AppID等数据传递给位于智能终端上的身份绑定客户端，身份绑定客户端与连接到或内置于智能终端的认证设备进行交互，认证设备通过其本身功能根据用户拥有、知晓或者自身的信息验证用户身份，随即为该用户生成全新的用户公私钥对，并将其中的公钥传回身份绑定服务器，至此完成身份绑定过程。

二、基于智能终端本地认证的多SP安全绑定的数据信息交互体系

如图3所示，用户的身份绑定过程实际是标示用户身份信息的数据相互绑定的过程，设备公私钥EAuth、用户公私钥UAuth、用户账户名UID以及应用描述符AppID，Policy之间的相互关系是身份绑定的核心逻辑。

(1)认证设备信息EAuth。EAuth是与一种认证设备绑定的公私钥对。在设备注册到身份绑定服务器后，该设备的公钥将存储在身份绑定服务器的数据仓库中，实现认证设备和身份绑定服务器之间的信任预置。当智能终端上的认证设备为新用户生成该用户的公私钥对UAuth时，用户公钥UAuth.pub使用认证设备的私钥EAuth.priv进行签名后发至身份绑定服务器，身份绑定服务器使用EAuth.pub验证签名后登记用户公钥UAuth.pub。

(2)用户账号UID。用户帐号UID由用户在SP Web服务器上提交表单申请注册，UID在SP的Web服务器上与用户的相关信息和权限绑定，而在身份绑定服务器上和与认证设备约定的用户公钥UAuth.pub绑定，起到了不同功能模块上间连接桥梁的作用。一个认证设备可以绑定多个SP上的多个用户UID，每一个UID有唯一的一对公私钥UAuth对与之对应，以此实现了认证设备和SP一对多的绑定模式。

(3)服务帐号AppID及服务策略Policy。AppID用于指明参与整个基于智能终端本地认证的多SP安全绑定方法的SP，AppID与UID组合唯一标明了参与身份绑定的一个用户。并且根据SP服务安全等级的不同，对用户的安全认证策略及可使用的认证设备也有所不同，比如对于有些涉及较多用户隐私的SP可能要求只能使用如指纹扫描器等安全系数较高的设备。使用了Policy数据来标识当前SP所支持的所有认证设备，Policy会被身份绑定客户端解析并呈现给用户选择用户想要使用的设备。

三、基于智能终端本地认证的多SP的身份绑定过程

初始化：用户在使用该方案进行身份绑定之前，需要对用户智能终端(如智能手机、Pad、电脑、智能云电视等)等进行初始化操作，以便正确完成后续的身份绑定过程。

用户设备的“信任预置”：整个多SP安全绑定方法必须建立在一套严格安全标准上，在新的认证设备设计生产后，根据不同的认证型号，应该对其安全特性进行评估和检测，淘汰不符合基本安全标准的设备，为通过检测的设备进行安全评级，以供SP和用户选配。在认证设备投入市场前，该认证设备首先应在目标身份绑定服务器上进行注册，即将属于该认证设备的公钥登记到对应的身份绑定服务器上。至此，该认证设备和对应身份绑定服务器之间建立起了信任关系，实现了信任预置。

用户设备的初始化：用户首先应在进行身份注册并在用户智能终端上安装对应的身份绑定客户端(该身份绑定客户端可根据用户设备的不同分为独立app和浏览器插件两种形式)。若使用外接智能终端的认证设备，则将该认证设备连接至智能终端上。身份绑定客户端为身份绑定服务器和认证设备建立了有效连接并为认证设备提供了统一API和驱动以保证其正常工作。

如图4所示，一次完整的身份绑定过程需要这些步骤。假设位于智能终端的身份绑定客户端已经成功安装并且认证设备已经成功连接并可正确使用，下面结合附图4，说明具体的身份绑定实施过程：

a)–g)主要描述了传统的身份注册流程，用户通过其智能终端上的用户代理访问Web服务提供商的网站并进行身份注册，该Web服务网站将其跳转至身份注册页面并提供身份注册表单，用户按照格式填写并提交表单，web服务器验证用户提交的信息后向身份绑定服务器IBS发送请求开始身份绑定进程；

h)身份绑定服务器IBS到激发请求信息后向SP发送身份绑定请求，该请求包含由身份绑定服务器生成的一个随机且唯一的挑战值Chl，该挑战值用于标明这次绑定进程，通过检验收到的身份绑定响应中的挑战值来确定是否属于之前发出的请求；

i)Web服务器收到身份绑定服务器IBS发出的身份绑定请求后，在请求中添加之前与用户间的session回话信息，之后转发至用户代理，用户代理在请求中添加AppID之后交付给智能终端上的身份绑定客户端IBC；

j)身份绑定客户端接收到身份绑定请求后，提取其中由i)添加的AppID，并将其会送至SP的Web服务器，Web服务器根据AppID获取该网络应用可使用的认证设备种类并将列表存储于Policy返回给身份绑定客户端IBC；

k)智能终端上的身份绑定客户端通过用户界面将可使用的认证设备AE列表呈现给用户，用户选择将要在接下来身份绑定进程中使用的认证设备AE；

l)用户正确选择后，身份绑定客户端IBC检查被选择的认证设备AE是否正确安装和驱动，如果测试成功，则激发认证设备AE请求用户根据认证设备功能进行身份认证并向认证设备发送AppID、Chl、UID等数据；

m)认证设备AE成功录入用户信息后，为该用户生成用户公私钥对UAuth，并将该公私钥对和录入的用户信息以及该用户的UID、所属Web服务提供商应用AppID绑定起来。之后再次接收到相同的用户信息就可以知道是哪个网络应用(AppID)中的哪个用户(UID)请求进行身份验证；

n)认证设备AE在生成UAuth后，将用户公钥UAuth.pub、挑战值Chl组成新的数据结构KRD(Key Registration Data)并将此数据结构用该认证设备本身的私钥EAuth.priv签名，之后传递给身份绑定客户端IBC；

o)IBC将KRD打包为身份绑定响应经用户代理和位于SP上的网络应用转发最终到达身份绑定服务器IBS；

p)身份绑定服务器IBS接收到身份绑定响应后，用之前已经存储的认证设备公钥EAuth.pub验证签名，验证通过后将UID和收到的UAuth.pub一并存储用于以后对该用户进行身份验证或者事务确认。将身份绑定结果发送给SP的web应用；

q)SP的web应用收到绑定成功信息，完成整个身份注册和绑定进程。

Claims

1.一种基于智能终端本地认证的多服务提供商SP安全绑定的实现方法，其特征在于实现步骤如下：

(1)基于智能终端本地认证的多服务提供商SP安全绑定的数据信息交互体系构建

基于模块内层次结构，通过AppID，FCH，EAuth，UID，Chl，KRD和Policy数据交互最终实现身份注册及绑定；其中，AppID用于标记请求身份绑定的服务提供商SP，UID用于标记在服务提供商SP上用户的唯一账户名，而EAuth作为一个认证设备的唯一标记通过公私钥对签名验证机制被身份绑定服务器识别，EAuth在身份验证过程之前已经在认证设备和身份绑定服务器之间沟通好；针对每一个(appID，UID)二元组，认证设备会生成一个全新的公私钥对，公钥由认证设备私钥EAuth.priv签名后发给身份绑定服务器，身份绑定服务器接收到后与用户名一起存入记录；Chl是由身份绑定服务器产生的一组随机标记，用于防止恶意攻击者的重放攻击；认证策略Policy指明了哪些认证方式是合法的而那些认证方式是不被允许的；FCH身份绑定客户端在接收到服务器发来的数据时，通过挑战值、appID参数生成FCH并将其发送给认证设备；KRD是由FCH、认证设备新生成的用户公钥数据组成，并由认证设备的EAuth.priv签名；

(2)基于智能终端本地认证的多服务提供商SP安全绑定的模块化实现

划分为了三个模块：Web服务提供商模块、身份绑定服务器模块和绑定服务用户设备模块；

身份绑定服务器模块：在收到Web服务提供商发送的请求后生成身份绑定请求进行身份绑定，并在身份绑定客户端返回身份绑定响应后，验证认证设备签名并存储用户名UID以及用户公钥UAuth.pub供后续用户身份验证；该模块还会在“信任预置”部分负责提前存储可使用的认证设备公钥；

Web服务提供商模块：为用户提供Web网络服务并提供注册功能使用户获取在该Web服务上的用户名UID，UID是后续身份绑定过程的必要元素；该模块还会根据所提供服务的安全需要制定自己的安全策略；

绑定服务用户设备模块：使用内置或外接与用户智能终端的认证设备收集用户信息，并为该信息生成用户公私钥，之后安装在智能终端上的身份绑定客户端将用户公钥和用户名UID打包为KRD并用设备私钥EAuth.priv进行签名；

(3)基于智能终端本地认证的多服务提供商SP的身份绑定过程

(31)认证设备的“信任预置”

认证设备在出厂后正式投入商用前，首先要对认证设备的安全性问题进行检测，以对其安全等级问题进行评估；并且在正式投入使用前，应为每个型号的安全设备生成公钥证书，并将其对应公钥注册至身份绑定服务器端，私钥保存于设备本身；当身份绑定服务器接收到由认证设备发送并用其私钥签名的数据包时，用其对应的公钥进行验证；

(32)认证设备及身份绑定客户端的安装

认证设备根据智能终端生产商设计的不同，内置于智能终端内或是由用户在使用时连接至智能终端，用户应将对应的身份绑定客户端安装至智能设备，并通过客户端中的认证设备抽象层为认证设备提供驱动和接口；

(33)身份绑定服务器和服务提供商SP服务器的配置

身份绑定服务器或作为服务提供商SP web服务器的一个子模块，或者作为一个独立的存在，负责多个服务提供商SP的身份绑定和验证功能；

(34)用户注册用户账号

用户在服务提供商SP上注册用户账号UID；

(35)将新注册的用户账户绑定至认证设备上

之前的步骤只是使用了传统的身份注册方法为用户分配了唯一的UID，若要把这个用户绑定到连接至智能终端的认证设备上，智能终端首先要获知与其通信的服务提供商SP支持何种认证设备；根据不同服务提供商SP安全等级的不同，并不是所有类型的认证设备都可以被服务提供商SP接受，故还需要Policy参数指定可用的认证设备，如果连接至智能终端的认证设备不在Policy列表中，则身份绑定失败；

(36)登记已绑定的UID和用户设备

用户完成步骤(35)时，即完成了账号的绑定过程；认证设备为用户生成了一个新的公私钥对，将其中的公钥发回身份绑定服务器，身份绑定服务器将公钥和对应的用户存入数据库，当该用户下次登录时，身份绑定服务器用记录的公钥验证登录时认证设备发来的由私钥签名的数据，若验证成功，则用户成功登录。

2.根据权利要求1所述的一种基于智能终端本地认证的多服务提供商SP安全绑定的实现方法，其特征在于：所述步骤(31)中，身份绑定服务器支持的认证设备对应的EAuth的公钥及相应信息应在认证设备发售前便已登记，身份绑定服务器一旦接收到没有登记过的认证设备发来的绑定请求，将会无视这一请求。

3.根据权利要求1所述的一种基于智能终端本地认证的多服务提供商SP安全绑定的实现方法，其特征在于：所述步骤(34)中，用户的首次账号注册以用户名密码表单提交的形式，以尊重用户的操作习惯，而且一旦用户将绑定的认证设备丢失，也可通过用户名密码的方式进行登录操作，用户名密码方式登录后，用户的操作权限是否会受限制或者会受多大限制，可按照多服务提供商SP相应的安全等级进行个性定制。

4.根据权利要求1所述的一种基于智能终端本地认证的多服务提供商SP安全绑定的实现方法，其特征在于：所述步骤(35)中，如果验证不通过则绑定失败，回滚到UID注册前，防止出现单独的UID无相应认证设备绑定的情况，带来潜在威胁。

5.根据权利要求1所述的一种基于智能终端本地认证的多服务提供商SP安全绑定的实现方法，其特征在于：所述步骤(36)中，如果因为挑战值对应失败，或者签名验证失败造成身份绑定服务器登记失败，则进程回滚到UID注册前，防止出现身份绑定服务器中无对应UID及认证公钥对的情况。