CN104283886B - 一种基于智能终端本地认证的web安全访问的实现方法 - Google Patents

Abstract

一种基于智能终端本地认证的web安全访问的实现方法，用户在使用该系统进行认证登录时，在保证用户使用便捷的前提下，为用户提供基于公私钥挑战响应式认证方法。首先，将用户的本地身份和RP上身份绑定；其次，用户在认证登录RP的时候，不需提交在RP上的身份证明，只需在智能终端完成本地用户身份验证；最后，本地用户身份验证通过后，利用智能终端生成的签名提交到RP认证服务器进行验证登录。本发明这种基于智能终端本地认证的WEB安全访问方法，简化增强认证时用户手动过程，提高了系统的安全性及用户体验性。

Description

一种基于智能终端本地认证的web安全访问的实现方法

技术领域

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

背景技术

在大多数计算机连入网络之前，各个系统中像身份验证和授权这类安全服务的实现完全是独立的。因此，执行身份验证所需的全部代码，以及密钥、口令，供授权决策所用的用户信息，以及授权策略本身均存放于使用这些信息的系统上。每个系统都是一个孤岛，各系统都要求用户拥有一个账户才能访问该系统。

随着互联网的出现，一个用户往往会访问许多服务，包括一种服务可能会由多台机器提供，如果这些服务都使用各自的一套口令，对于用户这是一个难以控制的问题，他们必须记住大量的口令。于是单点登录(Single Sign-on，SSO)出现了。

单点登录是一种用于方便用户访问网络的技术。无论多么复杂的网络结构，用户只需进行一次登录，即可获得访问系统和应用软件的授权，以后便可以在网络中自由穿梭，不必多次输入用户名和口令来确定身份。在此条件下，管理员无需修改或干涉用户登录就能方便地实施希望得到的安全控制，用户也无需为记忆大量的口令付出代价。

然而，在传统的单点登录里，用户仍然要记住在RP上的帐号和口令，而且由于一套帐号可以登录很多服务，所以，一旦RP上的帐号被泄露，与这个帐号绑定的所有服务都会暴露在攻击者面前，在某一方面来说会让用户账号变得更加不安全，同时由于不同的设备支持的协议，加密标准都不太一样，服务器要为每一套设备准备一套认证方案，很不方便。

因此，更好的身份认证的方法应该在保留传统的单点登录的特性之下，在不增加用户使用难度的前提下，提升用户资料的安全性，现有的身份认证方式主要是通过验证用户知晓的信息(something know)、用户拥有的信息(something have)、用户自身信息(something are)进行核实用户身份，然而传统的验证方法仍然要上传用户自身信息，也存在着泄露的风险，本发明创新性的提出基于智能终端本地认证的web安全访问的实现方法，将用户本地的身份和在线身份绑定起来，使用本地身份和公私钥签名验证来检验用户的身份，用户不需要反复提交身份证明，大大降低了身份信息泄露的可能性。

发明内容

本发明技术解决问题：克服现有技术的不足，提供基于智能终端本地认证的web安全访问的实现方法，将用户本地的身份和在线身份绑定起来，使用本地身份和公私钥签名验证来检验用户的身份，将本地的多种认证方法和在线的公私钥的挑战响应式结合起来，用户不需要反复提交身份证明，大大降低了身份信息泄露的可能性。同时，本发明也为多种智能终端提供统一的在线认证服务，具有安全性高、用户体验效果好、使用方便快捷等优点。

本发明的技术方案为：基于智能终端本地认证的web安全访问的实现方法，实现步骤如下：

(1)在智能终端上安装用户代理(比如RP的客户端,打开了RP网页的浏览器)，智能终端需要拥有网络连接功能；

(2)用户在RP上注册用户账号UID，然后将新注册的用户账户绑定至智能终端上；

(3)用户请求认证时首先打开安装在智能终端上的用户代理，然后访问到RP的页面，该访问和之后的访问全程使用TLS进行保护；

(4)RP将用户访问重定向到认证服务器，认证服务器首先返回AppID，认证的Policy，以及服务器端生成的挑战值Chl给认证客户端，该挑战值Chl使用伪随机数算法生成；

(5)认证客户端根据AppID，服务器挑战Chl等生成FCH传递给认证设备；

(6)利用注册的时候存储的用户本地身份信息，认证设备对用户进行本地身份认证，认证成功以后，使用注册的时候生成的私钥UAuth.priv和FCH签名生成SignedData，并且发送到认证服务器端；

(7)认证服务器端根据用户名查找对应的公钥，并使用公钥验证签名，如果验证通过，则用户登录成功，至此完成了基于公私钥的挑战响应式身份认证。

所述步骤(1)中，网络连接功能是指通过以太网、Wi-Fi模块或者蓝牙等模块连上网络并且能访问到RP。

所述步骤(2)中，用户UID是指用户使用传统手段在RP上进行注册，如使用账户名和密码进注册后，RP分配给用户的一个唯一的身份ID，不同的用户在同一个RP上获取的UID不一样，同一个用户在不同的RP上获取的UID相互不关联，不同的用户在不同的RP上活的的UID可能相同，在本权利书所述的认证过程中，假设用户已经成功绑定了一个本地身份和在线身份。

所述步骤(3)、(4)等中，所有的数据通信均使用TLS进行加密保护。

所述步骤(5)中，AppID是依赖方RP的唯一标识，服务器挑战Chl是由认证服务器产生的一组随机标记，用于防止恶意攻击者的重放攻击。认证策略Policy指明了哪些认证方式是合法的而那些认证方式是不被允许的(认证客户端将据此通过用户代理将可选的认证方式呈现给用户)。

所述步骤(5)中，FCH(Final Challenge Params)是认证客户端在接收到服务器发来的数据时，通过挑战值Chl、AppID等参数生成的。

所述步骤(6)中，认证设备对用户的本地身份验证是指对于用户所持有的，或者是用户本身特征，如IC卡、指纹等。

下面简要介绍本方案的基本思想，本发明在吸取已有解决方案的优点的基础之上，提出了自己的设计思想，具体来说，本发明原理包括下列几个方面：

方面一，服务器挑战值Chl和随机数，为了防止中间人猜测和重放攻击，每次认证之前比如由服务器产生一个挑战值，挑战值使用随机数算法生成，并且，生成挑战码的算法必须通过伪随机算法标准化测试。一个挑战值只能用于一次身份认证，使用完毕应立即销毁，不得重复利用。

方面二，用户帐号UID。用户UID为用户在RP上提交注册以后生成的一个唯一的用户身份，用于在RP范围内唯一标识一个用户。而一个用户可以绑定到多个智能终端，UID在这中间起到连接的作用。一个智能终端也可以绑定多个用户，UID用于区分各个用户，同时智能终端为每个UID生成一对公私钥对，从而实现智能终端和RP一对多的绑定。

方面三，服务帐号AppID及服务策略Policy。AppID用于唯一标识一个RP，同时也是认证设备生成公私钥对的依据，AppID和UID组合唯一标识了一个RP下的一个用户。在认证的时候，不同的服务提供者可能对认证有不同的要求。使用Policy来标识当前认证所支持的设备和认证方式，认证方式会被用户代理解析并且提供给用户选择。

方面四，TLS保护。为了保护认证设备、客户端、RP、SP之间的信道，所有的数据都是用TLS进行加密。TLS版本至少支持v1.1，推荐使用v1.2版本的TLS。任何一方必须拒绝没有经过TLS加密传输过来的数据。TLS加密中不安全的算法，如MD5、RC4、SHA1应该被拒绝。TLS加密传输时，客户端必须预先信任服务器端提供的证书链，如发现证书错误，应该立即停止下一步动作以免错误被放大。

本发明与现有技术相比，具有以下优点：本发明使用公私钥挑战响应式进行身份绑定并且使用本地用户身份验证进行用户登录，在方便用户使用的同时，极大的提高了用户账户的安全性。用户在登录的时候，不使用在RP上注册的用户账户，而是在智能终端端进行本地身份验证，智能终端再通过注册绑定的时候生成的公私钥，在RP端进行用户身份验证；另外，在数据交互的时候全程使用TLS加密技术并使用认证服务器生成挑战值的方法，避免了重放、伪造等攻击，相比较传统的用户名密码的登录方式，极大的提高了安全性。

附图说明

图1本发明系统的整体框架示意图；

图2本发明的身份认证方法中数据流程示意图；

图3本发明的身份认证方法详细流程图。

具体实施方式

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

如图1所示，本发明认证系统。

借助认证设备的身份认证体系本发明是基于智能终端本地认证的web安全访问的实现方法，即通过预先将用户的本地身份(如指纹，IC卡等)与用户在相关RP上的账号进行绑定，从而在认证的时候使用用户的本地身份进行验证的，使用注册绑定的时候生成的公私钥对生成的签名进行在线验证，使用服务器挑战值保证验证安全，避免了传统用户名密码方式存在的种种安全弊端的同时，也避免了传统的用户本地身份验证仍然需要上传用户身份到服务器端的弊端。同时本发明的三大模块(用户、智能终端、服务依赖方)相互独立，一个用户可以对应多个智能终端或者服务依赖方，一个智能终端也可以认证多个用户等，这种低耦和的设计方法可以保证整个系统的扩展空间(比如建立独立的认证服务器，专职负责对已注册的RP的用户的身份认证工作)同时也可以保护各个模块的数据的隐私和安全。

本发明通过公私钥和挑战响应提供了一种身份认证方法，通过认证客户端和认证服务器以及认证设备的数据流和信息流交互，最终使用用户在本地认证器上的身份进行在线身份验证。完成这一身份认证过程的主要功能部件有：用户代理(UA)、认证客户端(AC)、认证服务器(AS)、服务依赖方(RP)、认证设备(AE)、认证设备抽象层(AA)以及元数据认证服务器(AMV)

用户代理(UA)是安装在用户智能终端上，为了保证整个系统的各部分顺利工作所定制的一个重要功能部件。用户代理可以是浏览器，也可以是一个应用程序。它主要提供与用户的信息交互，转发在整个身份认证过程中的数据信息流的功能。用户在认证时，需要该插件将需要用户输入或选择的信息以表单的方式呈现给用户(例如对可用的用户设备的选择，对可用的认证策略的选择等)，该部件负责用户设备与RP服务器间的所有数据交互，并且使用TLS保护信道安全。

认证客户端(AC)是安装在用户设备上的整个身份认证方法的一个重要组成模块，它在整个身份认证系统中起到了连接认证设备和认证服务器的桥梁作用，它的主要作用有通过认证设备抽象层使用相应的认证设备API与用户提供的用户器进行数据交互，同时，认证客户端借助用户设备上的用户代理与认证服务器建立连接，之后，认证客户端就开始负责与认证服务器的信息交互。

认证服务器(AS)可以作为依赖方RP的一个身份认证组成模块，也可作为一个独立的存在。认证服务器的主要功能有如下四点：(1)通过用户浏览器与位于用户设备上的认证客户端进行身份认证协议的信息交互；(2)通过查验用户认证设备元数据验证用户提供的认证设备的合法性；(3)管理注册的认证设备和用户账户之间的关系；(4)实现注册和身份绑定之后的用户认证和事务信息确认等功能。

服务依赖方(RP)主要用于给用户提供用户需求的网络服务，并在用户首次使用时，通过传统的身份注册方式为用户生成UID，之后RP会根据用户的认证请求，联系相应的认证服务器，从而开始本权利所述的身份认证请求。

认证设备(AE)是一个安全实体，可以内置在用户设备中也可在需要的时候连接至用户设备。认证设备具有认证用户身份的功能(比如密码扫描器通过检测用户的指纹获取用户身份，或者判断用户持有的IC卡等)，认证器被认为是安全可信的，即通过认证设备检测的用户即为合法的安全用户。

认证设备抽象层(AA)实际上是认证客户端中的一个抽象层，由于随着整个安全认证领域的不断发展，认证设备的种类的型号会不断更迭，认证设备抽象层为已注册的合法认证设备提供了一个统一的API以应对这些变化。认证设备抽象层为认证客户端提供了多设备支持以及相关认证设备的驱动程序。

元数据认证服务器(AMV)与认证服务器直接建立联系，其主要用于存储各类认证设备的公钥证书，这些公钥证书用于验证由不同认证设备生成的并由该设备私钥签名的数据信息流。

上述完成基于公私钥的挑战响应式身份认证方法中的功能部件，服务依赖方、认证服务器和元数据认证服务器组成认证服务器端，用于进行在线身份验证和事务确认。认证设备、认证客户端和认证设备抽象层作为认证用户设备端，获取用户的身份认证请求，并通过认证设备本身功能认证用户身份。

对于图1从整体上描述了基于智能终端本地认证的web安全访问过程中数据管理实施的总体架构，下面介绍在认证过程中安全性考虑的数据走向和详细过程。

一、基于智能终端本地认证的web安全访问的数据走向，如图2所示。

1.认证服务器生成挑战值，并且将挑战值与AppID、认证策略Policy传输给认证客户端。该挑战值使用通过验证的伪随机生成算法或者是伪随机生成器来进行生成，是本权利书中认证安全性的保证，一个挑战值只能用于一次认证，不得重复使用。

2.认证客户端收到请求以后根据相应的策略选择认证方式，同时根据服务器挑战Chl计算最终挑战参数FCH，与AppID打包发送给认证设备。

3.认证设备对用户进行本地身份认证，若认证通过，则认证设备读取本地存储的在注册的时候生成绑定的私钥，对FCH进行签名，并且发送给认证客户端。

4.认证客户端收到认证设备发来的签名数据以后，提交给认证服务器。同时，在此处，由于一个认证客户端可以同时对应多个认证设备，而且会有多个用户同时请求身份认证，此时，认证客户端需将每个签名数据分开发送给认证服务器端。

通过这种使用服务器产生挑战值，客户端根据挑战值计算并且认证设备进行签名的过程，保证了认证过程中的安全性，可以有效抵御中间人攻击和重放攻击，也可以防止用户使用过期的数据进行再次验证。

二、基于智能终端本地认证的web安全访问的实现方法详细过程，如图3所示。

用户在使用该方案进行身份认证之前，需要对用户设备(如智能手机、平板电脑、PC、云电视等)等进行初始化操作，并且将用户身份绑定到本地设备，以便正确完成后续的身份认证过程，在绑定成功以后的身份认证步骤如下所示：

1-2.用户在用户代理上打开认证的URL，用户代理将用户重定向到RP应用上，该页面必须使用TLS加密，同时RP的TLS证书必须被用户代理所信任。

3-4.RP向认证服务器获取UAF认证请求，认证请求包括认证的策略Policy和使用伪随机算法生成的服务器挑战值Chl。

5.RP将收到的UAF认证请求响应返回给用户代理。

6.用户代理将收到的UAF请求以及RP的AppID并且验证TLS完整性和证书有效性以后，将UAF请求和AppID返回给认证客户端。

7-8.认证客户端使用AppID向RP服务器获取FacetID，该FacetID会由RP服务器根据认证客户端的平台生成，一个FacetID代表了一个RP和认证客户端平台的二元组。

9.根据收到的认证策略Policy，认证客户端解析认证策略并且呈现给用户，由用户选择最终认证方法。

10.根据收到的服务器挑战值Chl，认证客户端计算最终挑战参数FCH，并且根据相应的认证策略，调用认证设备对用户进行验证，同时把FCH和AppID传递给认证器。

11-12.认证设备根据对于的策略，开始验证用户的身份，比如指纹、IC卡等方式。

13.根据注册的时候保存在认证设备里的用户本地身份，认证设备检验用户身份是否合法，若用户身份不合法，则认证设备立即停止下一步步骤并且通知认证客户端终止本次认证，防止错误信息被放大。

14.认证设备根据存储的私钥计算签名，在签名里必须包含FCH信息，并且将签名传递给认证客户端。

15-16.认证客户端收到认证签名以后，将认证签名包装成认证响应，通过用户代理提交给RP。

17.RP把接收到的认证响应包装成UAF认证响应，并且提交给认证服务器。

18.认证服务器根据实现存储的公钥列表，校验响应的合法性，若认证响应合法，则该用户登录有效，认证服务器返回登录成功。

19.认证服务器返回结果，若认证合法，则用户有效，否则，用户无效，此时应该终止下一步步骤并且逐级通知到用户。

20.RP告诉用户代理用户成功登录，并且将维护一个用户的在线凭据session，用户可以使用该凭据访问对应的服务，此时，整个身份认证过程结束。

Claims (3)

1.一种基于智能终端本地认证的web安全访问的实现方法，其特征在于完成这一身份认证过程的功能部件有：用户代理(UA)、认证客户端(AC)、认证服务器(AS)、服务依赖方(RP)、认证设备(AE)、认证设备抽象层(AA)是为认证客户端提供了多设备支持以及相关认证设备的驱动程序，元数据认证服务器(AMV)是与认证服务器直接建立联系，其主要用于存储公钥证书；

具体实现步骤如下：

(1)在智能终端上安装用户代理，智能终端需要拥有网络连接功能；

(2)用户在服务依赖方RP上注册用户账号UID，然后将新注册的用户账号绑定至智能终端上；

(3)用户请求认证时首先打开安装在智能终端上的用户代理，然后访问到服务依赖方RP的页面，该访问过程使用传输层安全协议TLS进行保护；

(4)服务依赖方RP将用户访问重定向到认证服务器AS，认证服务器AS首先返回服务帐号AppID，认证服务策略Policy，以及认证服务器端生成的挑战值Chl给认证客户端，该挑战值Chl使用伪随机数算法生成；所述AppID是依赖方RP的唯一标识，服务器挑战值Chl是由认证服务器产生的一组随机标记，用于防止恶意攻击者的重放攻击；所述认证策略Policy指明了哪些认证方式是合法的而哪些认证方式是不被允许的；

(5)认证客户端根据服务器挑战值Chl生成最终挑战参数FCH，并与AppID打包传递给认证设备；利用注册的时候存储的用户本地身份信息，认证设备对用户进行本地身份信息认证，认证成功以后，使用注册的时候生成的私钥UAuth.priv和FCH签名生成签名数据SignedData，并且发送到认证客户端后再转发给认证服务器端；

(6)认证服务器端根据用户账号查找对应的公钥，并使用公钥验证签名，如果验证通过，则用户登录成功，至此完成了基于智能终端本地认证的web安全访问的实现方法；

所述步骤(2)中，用户在服务依赖方RP上注册用户账号UID是指用户使用传统手段在RP上进行注册，即使用用户账号和密码进行注册后，RP分配给用户的一个唯一的身份ID，不同的用户在同一个RP上获取的UID不一样，同一个用户在不同的RP上获取的UID相互不关联，不同的用户在不同的RP上获得的UID可能相同；

所述步骤(5)中，所述用户本地身份信息是指对于用户所持有的，或者是用户本身特征，包括IC卡或指纹。

2.根据权利要求1所述的基于智能终端本地认证的web安全访问的实现方法，其特征在于：所述步骤(1)中，网络连接功能是指通过以太网、Wi-Fi模块或者蓝牙模块连上网络并且能访问到RP。

3.根据权利要求1所述的基于智能终端本地认证的web安全访问的实现方法，其特征在于：为了保护认证设备、客户端、RP、SP之间的信道，所述各步骤中的所有的数据均使用TLS进行加密。