CN114003892A - 可信认证方法、安全认证设备及用户终端 - Google Patents

Abstract

本申请提供可信认证方法、安全认证设备及用户终端。所述可信认证方法应用于安全认证设备，所述安全认证设备可安装在用户终端上，所述安全认证设备上存储有所述安全认证设备的公钥和私钥，所述方法包括：向所述用户终端发送第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密；接收所述用户终端发送的经所述TLS秘钥加密的所述网页数据；生成认证数据包，所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

Description

可信认证方法、安全认证设备及用户终端

技术领域

本申请涉及可信认证领域，具体涉及一种可信认证方法、安全认证设备及用户终端。

背景技术

网页数据的可信认证具有广泛的应用场景。例如，在描绘用户信息，进行用户相关风险评估以及提供授信时，第三方(例如银行)需要用户提供经过可信认证的网页数据以供评估。

现有技术可以基于TLSNotary对网页数据进行可信认证。但是，基于TLSNotary的网页数据的认证方式需要认证服务器参与到TLS握手过程，并在线对网页数据进行认证，导致认证过程的可靠性低、灵活性差。例如，如果认证服务器的响应速度可能达不到要求，可能导致认证过程失败。又如，用户可能由于环境隔离(例如用户的网络防火墙会屏蔽部分网站)导致无法访问认证服务器，则无法实现认证。

发明内容

有鉴于此，本申请提供一种可信认证方法、安全认证设备及用户终端，以解决上述问题。

第一方面，提供一种可信认证方法，所述认证方法应用于安全认证设备，所述安全认证设备可安装在用户终端上，所述安全认证设备上存储有所述安全认证设备的公钥和私钥，所述方法包括：向所述用户终端发送第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密；接收所述用户终端发送的经所述TLS秘钥加密的所述网页数据；生成认证数据包，所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

第二方面，提供一种可信认证方法，所述可信认证方法应用于用户终端，所述用户终端可安装安全认证设备，所述安全认证设备上存储有所述安全认证设备的公钥和私钥，所述方法包括：接收所述安全认证设备发送的第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密；从所述目标网站接收经所述TLS秘钥加密的所述网页数据；将所述经所述TLS秘钥加密的网页数据发送至所述安全认证设备，以便所述安全认证设备生成认证数据包，所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，且所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

第三方面，提供一种安全认证设备，所述安全认证设备可安装在用户终端上，所述安全认证设备上存储有所述安全认证设备的公钥和私钥，所述安全认证设备包括：发送单元，用于向所述用户终端发送第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密；接收单元，用于接收所述用户终端发送的经所述TLS秘钥加密的所述网页数据；生成单元，用于生成认证数据包，所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

第四方面，提供一种用户终端，所述用户终端可安装安全认证设备，所述安全认证设备上存储有所述安全认证设备的公钥和私钥，所述用户终端包括：第一接收单元，用于接收所述安全认证设备发送的第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密；第二接收单元，用于从所述目标网站接收经所述TLS秘钥加密的所述网页数据；发送单元，用于将所述经所述TLS秘钥加密的网页数据发送至所述安全认证设备，以便所述安全认证设备生成认证数据包，所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，且所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

第五方面，提供一种可信认证设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器被配置为执行所述可执行代码，以实现如第一方面和第二方面中任一方面所述的方法。

第六方面，提供一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被执行时，能够实现如第一方面和第二方面中任一方面所述的方法。

第七方面，提供一种计算机程序产品，包括可执行代码，当所述可执行代码被执行时，能够实现如第一方面和第二方面中任一方面所述的方法。

本申请实施例采用本地的安全认证设备代替认证服务器参与到TLS的握手过程，并以认证数据包的形式存储需要认证的网页数据。这样一来，用户终端无需实时地与认证服务器进行交互即可完成TLS握手，此外，用户可以在希望对网页数据进行认证时再将该网页数据提交至认证服务器，提高了认证过程的可靠性和灵活性。

附图说明

图1是TLS交互流程示意图。

图2是本申请一实施例提供的可信认证方法的流程示意图。

图3是本申请一实施例提供的可信认证系统的结构示意图。

图4是本申请一实施例提供的安全认证设备的认证流程示意图。

图5是本申请一实施例提供的可信认证方法流程示意图。

图6是本申请一实施例提供的安全认证设备的结构示意图。

图7是本申请一实施例提供的用户终端的结构示意图。

图8是本申请一实施例提供的可信认证装置的结构示意图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

为了提高网络数据传输的可靠性，防止被恶意攻击，目前大部分网站使用HTTPS协议进行通信。用户终端需要从网站获取网页信息时，可以向网站发起HTTPS流程，请求网站发送所需的网页数据。

本申请实施例中的用户终端指可以为用户提供数据连通性的设备，可以用于连接人、物、机，例如可以通过网络与其他设备连接的手持式设备、车载设备等。本申请实施例中的用户终端可以是手机(mobile phone)、平板电脑(Pad)、笔记本电脑、掌上电脑、台式电脑等。用户终端可以通过应用程序(例如浏览器)与网站交互，获取网站提供的网页数据。

在本申请实施例中，网站可以向用户终端提供服务，例如向用户终端提供网页数据等。在一些实施例中，网站可以指支持HTTPS的网站，例如github、淘宝等。

HTTPS协议通过在HTTP协议中加入TLS流程，提高了用户终端和网站之间网页数据传输的保密性和安全性，防止数据传输的过程被攻击。然而，HTTPS协议只能保证通信过程不被攻击，无法保证用户获取到网页数据后，该网页数据为可信数据。即，无法证明该网页数据未被窜改。

为了便于理解，下面首先以图1为例，对TLS握手流程进行简要介绍。

图1是TLS交互流程示意图。在一些实施例中，该TLS交互流程可以在用户终端发起HTTPS请求消息，与网站完成TCP握手之后进行。

如图1所示，在步骤S110，用户终端首先发送第一消息，启动TLS流程。第一消息可以包括用户终端支持的协议版本、加密算法、用户终端生成的第一随机数等。

在步骤S120，目标网站向用户终端发送第二消息。第二消息可以包括网站确定的协议版本、加密算法、网站生成的第二随机数等。

在步骤S130，用户终端根据获取的目标网站的信息，生成第三随机数并发送给目标网站。在一些实施例中，第三随机数可以称为pre-master secret或pre-master key。在一些实施例中，用户终端发送的第三随机数为使用目标网站的公钥加密后的数据。

目标网站接收到第三随机数后，可以生成本次TLS流程所需的TLS秘钥。在一些实施例中，TLS秘钥可以通过使用在步骤S120约定的加密算法，结合步骤S110生成的第一随机数、步骤S120生成的第二随机数以及第三随机数生成。

在步骤S140，目标网站使用生成的TLS秘钥对用户终端请求的网页数据进行加密，并传输给用户终端。

在一些实施例中，TLS流程还可以包括步骤S150，用户终端根据收到的网页数据，计算哈希值发送给目标网站。

目标网站收到用户终端发送的哈希值，与目标网站通过计算得到的哈希值进行对比，以确定用户终端接收到正确的数据，并结束本次TLS流程。

根据以上分析可知，TLS流程虽然对发送的目标网页数据使用TLS秘钥进行了加密，但是该加密过程只能提升用户终端与目标网站通信过程的安全性，防止该通信过程被攻击。但是，TLS流程并未对用户终端与目标网站通信过程或最终获取的网页数据进行认证。因此，用户无法证明提交给第三方(例如银行)的，用于第三方描绘用户信息或进行用户风险评估等处理的网页数据是可信的数据，即用户无法证明通过用户终端获取的网页数据未被窜改。

当第三方需要评估用户的信息时(例如银行根据用户的银行流水数据确定是否发放贷款)，需要确保获得的用户的网页数据(例如银行流水)是可信的。在一些场景中，第三方可以使用工具(例如爬虫工具)自动地从目标网站获取所需的网页数据。第三方相信自己通过工具获取的网页数据为可信数据。然而，工具不能适配所有的场景(例如，对于需要用户登录才能够显示的页面，无法通过工具获取)。对于工具无法获取的数据，第三方需要用户主动上传该网页数据(例如网页的截图或html文本)，以供评估。

然而，用户主动上传的网页数据存在如下问题：

首先，用户主动上传的网页数据存在被窜改的可能。例如，用户可以方便地在浏览器上通过修改html的内容渲染出不同的页面内容，达到篡改数据的目的。

其次，第三方通常无法实时导出用户上传的信息，在第三方导出网页数据前，该网页数据也存在被窜改的可能。例如，经用户上传并存储在中心化服务器上的，用于存证的网页数据可能被管理者窜改，导致用户再次下载时获得的网页数据与提交时的网页数据不一致。

上述问题导致用户无法证明自己上传的网页数据是可信数据。即用户无法证明自己上传的网页数据未被自己或管理者窜改。

目前，一些服务商提供一种基于TLS的在线可信认证的方法，该可信认证方法也可以称为TLSnotary。在该方法中，服务商作为审核者的角色，对用户终端请求的网页数据进行认证，确保网页数据可信。

上述可信认证方法无法适用所有的场景。原因在于：一方面，该认证方法需要用户终端在线实时地与认证服务器(审核者)通信。认证服务器的响应速度可能达不到要求，导致认证过程失败。另一方面，用户可能由于环境隔离(例如用户的网络防火墙会屏蔽部分网站)导致无法访问认证服务器，从而无法实现认证。此外，用户可能对网页访问有隐私方面的要求，不希望访问的所有页面都被认证服务器监听。而且事实上，通常并不需要用户实时进行网页数据的认证。用户可以先在本地生成认证信息，在需要的时候将经过认证的数据上传至认证服务器上进行认证。

有鉴于此，本申请提供了一种可信认证方法、安全认证设备及用户终端，以解决由于使用认证服务器实时地进行在线可信认证而产生的认证失败的问题，从而提高认证过程的可靠性。

下面结合图2至图5对本申请实施例提供的认证方法进行详细描述。图2是本申请一实施例提供的认证方法的流程示意图。图2的方法站在用户终端和安全认证设备交互的角度进行描述。

参见图2，在步骤S210，安全认证设备向用户终端发送第一秘钥。

本申请实施例中的安全认证设备为可安装在用户终端上的设备。在一些实施例中，安全认证设备可以包含安全的存储设备。安全认证设备中可以存储有安全认证设备的公钥、私钥。在一些实施例中，安全认证设备还可以存储认证证书。该认证证书可以是认证服务器颁发的证书。例如，认证服务器可以对安全认证设备的公钥进行认证，如果公钥的认证通过，则向安全认证设备颁发该认证证书。

在一些实施例中，安全认证设备可以是usbkey。usbkey是一种具有usb接口的硬件设备。它内置单片机或智能卡芯片，有一定的存储空间，可以存储私钥以及数字证书。usbkey可以通过公钥算法实现身份认证。由于安全认证设备的私钥保存在密码锁中，理论上使用任何方式都无法读取，因此使用usbkey作为安全认证设备能够保证数据认证的安全性。

在一些实施例中，认证服务器可以指权威公证的第三方机构(例如CA中心)提供的服务器。在一些实施例中，认证服务器颁发的认证证书可以是通过特殊的加密技术生成的，不可伪造或窜改的文本。

第一秘钥为安全认证设备生成的秘钥。第一秘钥可以用来构造TLS秘钥，TLS秘钥用于对用户终端访问的目标网站的网页数据进行加密。在一些实施例中，为了提高数据传输过程的安全性，每次TLS流程中会重新生成一个第一秘钥。

可以根据需要使用不同的加密算法利用第一秘钥构造TLS秘钥。在一些实施例中，可以直接使用第一秘钥生成TLS秘钥。在另一些实施例中，也可以利用第一秘钥首先生成pre-master secret，再利用pre-master secret生成TLS秘钥。

TLS秘钥为后续网站用于加密待传输的网页数据的秘钥。在一些实施例中，TLS秘钥在每次TLS握手时都会重新生成。在一些实施例中，为了提高数据传输的速度，降低数据传输过程的复杂度，TLS秘钥可以是对称秘钥。即，网站和用户终端使用相同秘钥作为TLS秘钥，对传输的数据进行加密。

在步骤S220，用户终端从目标网站接收经所述TLS秘钥加密的网页数据。

在一些实施例中，目标网站为能向用户终端提供所需的网页数据的网站。目标网站接收到用户终端发送的请求发送网页数据的请求后，使用与用户终端协商得到的TLS秘钥，对网页数据进行加密，并将加密后的数据传输给用户终端。网页数据为包含用户所需数据的网页信息，例如可以是html文本。

在步骤S230，用户终端将所述经TLS秘钥加密的网页数据发送至安全认证设备。

在步骤S240，安全认证设备生成认证数据包。在一些实施例中，认证数据包包含网页数据以及针对网页数据的数字签名。数字签名是基于安全认证设备的私钥生成的。数字签名用于存储有安全认证设备的公钥的认证服务器对网页数据进行可信认证。

在一些实施例中，安全认证设备针对网页数据的数字签名可以是安全认证设备使用自己的私钥对使用TLS秘钥加密后的网页数据的数字签名。为了进一步提高安全认证设备认证数据的可靠性，在另一些实施例中，安全认证设备针对网页数据的数字签名也可以是安全认证设备对整个TLS传输流程的数据进行的数字签名。

在一些实施例中，认证数据包可以包含TLS握手信息(例如TLS秘钥)、安全认证设备针对网页数据的数字签名以及使用TLS秘钥加密后的网页数据。

在另一些实施例中，认证数据包也可以包含解密的网页数据以及安全认证设备使用自己的私钥对该解密的网页数据的数字签名。

由于认证数据包中包含安全认证设备使用自己的私钥生成的数字签名。一旦认证数据包被窜改，认证服务器将认证失败。因此，认证数据包是可信数据。可以理解，基于认证数据包的可信性，认证数据包的存储位置可以根据需要任意选择。例如，可以将认证数据包存储在安全认证设备中。为了降低安全认证设备的成本，也可以将认证数据包存储在用户终端中。

本申请实施例提供的认证方法，通过在TLS流程中使用安全认证设备对获取网页数据的进行数字签名，保证认证数据包为可信的未被窜改的数据包。此外，由于用户在获取网页数据的过程中，能够实现在线访问，离线认证，因此，使用该可信认证方法进行网页数据的认证，还能够满足用户对数据隐私方面的需求。

在一些实施例中，在步骤S210之前，该认证方法还可以包括：生成安全认证设备的公钥和私钥，以及向所述认证服务器发送所述公钥，以便所述认证服务器对所述公钥进行认证，得到认证证书，存储所述认证服务器发送的所述认证证书。

安全认证设备的公钥和私钥为使用一定的密码学规则生成的一对秘钥对。可以使用该秘钥对进行数据的加密和解密。其中，私钥存储在安全认证设备本地，任何第三方无法获取。安全认证设备可以使用私钥对要传输的数据进行加密。接收端通过安全认证设备的公钥即可解密该数据。

为了提高私钥的安全性，在一些实施例中，安全认证设备可以包括密码锁。私钥可以存储在密码锁中。

认证服务器接收到安全认证设备的公钥后，可以保存该安全认证设备的公钥，并使用该公钥生成该安全认证设备的证书，颁发给该安全认证设备。

在一些实施例中，认证服务器可以是基于区块链的认证服务器。安全认证设备的公钥和认证证书可以存储在该区块链中。认证服务器颁发证书的过程可以使用例如区块链智能合约完成。基于区块链的认证服务器能够进一步防止认证服务器的管理者对数据进行窜改，提升认证的可信度。

为了进一步保证用户隐私的安全性，防止恶意攻击，在一些实施例中，在步骤S210之前，该可信认证方法还可以包括：用户终端验证安全认证设备的合法性。

在一些实施例中，安全认证设备可以在安装到用户终端上时，主动向用户终端发送证书。在另一些实施例中，安全认证设备也可以在用户终端请求证书时，被动地向用户终端发送证书。用户终端接收到安全认证设备的证书后，可以对证书进行验证，以确保该安全认证设备不是攻击者。为了进一步提升对安全认证设备认证过程的可靠性，在一些实施例中，可以使用区块链智能合约进行安全认证设备的认证。

在本实施例中，通过增加对安全认证设备的认证，保证与用户终端通信的安全认证设备是权威机构(例如CA中心)颁发的，不是攻击者。因此能够有效地保障用户的使用安全。

下面结合具体例子以及图3-5，更加详细地描述本申请实施例。应注意，图3-5的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将本申请实施例限于所例示的具体数值或具体场景。本领域技术人员根据所给出的图3-5的例子，显然可以进行各种等价的修改或变化，这样的修改或变化也落入本申请实施例的范围内。

图3是本申请一实施例提供的认证系统的结构示意图。如图3所示，本申请实施例提供的认证系统包括目标网站1、用户终端2、安全认证设备3以及认证服务器4。

图4是本申请一实施例提供的安全认证设备的认证流程示意图。如图4所示，安全认证设备3在使用前，可以先通过认证服务器4进行认证，以生成认证证书。

具体地，参见图4，在步骤S410，安全认证设备3生成公钥、私钥对。该公钥、私钥对例如可以使用RSA2048非对称秘钥对。

在步骤S420，安全认证设备3将生成的公钥上传至认证服务器4进行认证。

在步骤S430，认证服务器4收到安全认证设备3的认证请求后，对安全认证设备3的公钥进行认证并生成认证证书。认证服务器4将生成的认证证书发送给安全认证设备3并存储安全认证设备3的公钥。

经过认证服务器4的认证，安全认证设备3即可代替认证服务器4对用户终端获取的网页数据进行认证。只要安全认证设备3申请认证的认证服务器4是可信的认证服务器，就能保证安全认证设备3提供的认证服务也是可信的。即，使用经过认证服务器4认证的安全认证设备3对网页数据进行数字签名后生成的认证数据包为可信数据。

在一些实施例中，用户可以通过用户终端2上安装的浏览器与目标网站进行通信。用户终端2与安全认证设备3之间的数据交换，可以通过浏览器的插件进行。当用户请求需要认证的网页数据时，首先将安全认证设备3安装到用户终端2上，接着打开浏览器的插件请求认证。插件的功能为管理用户当前的HTTPS请求，并通过调用安装于用户终端2上的安全认证设备3进行TLS认证。

为了保证安装到用户终端2的安全认证设备3确实是权威机构颁发的，每次当插件连接到安全认证设备3时，需要验证安全认证设备3的证书信息。验证方式例如可以使用区块链的智能合约完成。

图5是本申请一实施例提供的认证方法流程示意图。

如图5所示，在步骤S502，用户终端向目标网站发送TLS请求消息。在一些实施例中，该TLS请求消息也可以是HTTPS请求消息。

在步骤S504，目标网站响应该TLS请求消息。

在步骤S506，用户终端向安全认证设备请求第一秘钥。

在步骤S508，安全认证设备生成第一秘钥并发送给用户终端。发送第一秘钥可以通过将第一秘钥返回给浏览器插件完成。需要说明的是，每次TLS握手时生成的第一秘钥都不同。

在步骤S510，用户终端根据第一秘钥生成TLS握手信息并发送给目标网站1。浏览器插件可以使用第一秘钥构造TLS认证过程中所需的pre-master secret。浏览器将该pre-master secret以及TLS握手过程中创建的2个随机数作为相关网络请求发送给目标网站。

在步骤S512，浏览器插件将握手确认信息转发给目标网站。目标网站验证无误后，完成TLS握手流程，并用当前TLS协商出来的TLS秘钥作为后续加密网页数据的秘钥。该TLS秘钥为对称秘钥。此时，当前协商得到的TLS秘钥还保留在安全认证设备中，浏览器、插件还无法获取。

在步骤S514，目标网站使用TLS秘钥对需要展示的网页数据(例如html文本)进行加密，并向用户终端发送该加密的网页数据。

在步骤S516，用户终端将接收到的网页数据发送给安全认证设备。

在步骤S518，安全认证设备打包生成该次请求对应的认证数据包。认证数据包包括本次生成的TLS握手信息(例如可以包括TLS秘钥，用于对网页数据进行解密)、使用自己的私钥对该内容做的签名以及加密后的网页数据(例如加密后的html文本)。

在步骤S520，安全认证设备返回给插件/浏览器当前操作的TLS秘钥。

在步骤S522，浏览器使用该TLS秘钥对html返回文本进行加密后发送给目标网站。目标网站通过TLS解密后验证该返回值无误，结束本次TLS传输。

当用户需要对之前某个网页数据进行可信性认证时，只需提交在图5的步骤S518中生成的认证数据包。

认证服务器收到该认证数据包后，先通过标识找到该认证数据包是哪个安全认证设备生成的。确认具体的安全认证设备后，找到之前存储的，该安全认证设备的公钥。使用公钥验证数据包中的签名是否一致。如果签名验证无误，说明该认证数据包确实是经过安全认证设备认证过的。即该数据未被窜改。

确认数据为可信数据后，使用数据包中的TLS秘钥对该次html加密文本进行解密，得到原始的文本。第三方可以基于解密后的文本内容，进行用户信息评估等操作，无需担心数据是被窜改的数据。

上面结合图2至图5，详细描述了本申请的方法实施例，下面结合图6至图8，详细描述本申请的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

图6是本申请一实施例提供的安全认证设备的结构示意图。图6所示的装置可以用于上述的认证方法。图6所示的安全认证设备600存储有安全认证设备600的公钥和私钥，安全认证设备600可以包括发送单元610、接收单元620以及生成单元630。下面对这些单元进行详细介绍。

发送单元610可以用于向所述用户终端发送第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密。

接收单元620可以用于接收所述用户终端发送的经所述TLS秘钥加密的网页数据。

生成单元630可以用于生成认证数据包。认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

可选地，在一些实施例中，所述认证数据包中的所述网页数据为经所述TLS秘钥加密的网页数据，且所述认证数据包还包含所述TLS秘钥；或者，所述认证数据包中的所述网页数据为利用所述TLS秘钥解密后的网页数据。

可选地，在一些实施例中，所述生成单元630还可以用于生成所述安全认证设备的公钥和私钥。安全认证设备600还可以包括认证单元640。认证单元640用于向所述认证服务器发送所述公钥，以便所述认证服务器对所述公钥进行认证，得到认证证书，并存储所述认证服务器发送的所述认证证书。

可选地，在一些实施例中，所述认证服务器为基于区块链的认证服务器，所述公钥和所述认证证书存储在所述区块链中，且所述公钥的认证是通过调用所述区块链的智能合约完成的。

可选地，在一些实施例中，所述安全认证设备为USBkey。

图7是本申请一实施例提供的用户终端的结构示意图。图7中的虚线表示该单元或模块为可选的。该用户终端700可以用于上述方法实施例中描述的方法。用户终端700包括第一接收单元710、第二接收单元720、发送单元730。

第一接收单元710可以用于接收所述安全认证设备发送的第一秘钥，所述第一秘钥用于构造TLS秘钥。

第二接收单元720可以用于从目标网站接收经所述TLS秘钥加密的网页数据。

发送单元730可以用于将所述经所述TLS秘钥加密的网页数据发送至所述安全认证设备，以便所述安全认证设备生成认证数据包。所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，且所述数字签名用于所述认证服务器对所述网页数据进行认证。

可选地，在一些实施例中，所述认证数据包中的所述网页数据为经所述TLS秘钥加密的网页数据，且所述认证数据包还包括所述TLS秘钥；或者，所述认证数据包中的所述网页数据为利用所述TLS秘钥解密后的网页数据。

可选地，在一些实施例中，安全认证设备600中存储有所述认证服务器对所述公钥进行认证后生成的认证证书，用户终端700还包括验证单元740。验证单元740用于当所述安全认证设备600安装在所述用户终端700上时，对所述认证证书的可靠性进行验证。

可选地，在一些实施例中，所述安全认证设备为USBkey。

图8是本申请一实施例提供的可信认证设备的结构示意图。该可信认证设备800例如可以是用户终端或安全认证设备。可信认证设备800可以包括存储器810和处理器820。存储器810可用于存储可执行代码。处理器820可用于执行所述存储器810中存储的可执行代码，以实现前文描述的各个方法中的步骤。在一些实施例中，该可信认证设备800还可以包括网络接口830，处理器820与外部设备的数据交换可以通过该网络接口830实现。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其他任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如数字视频光盘(Digital Video Disc，DVD))、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

本领域普通技术人员可以意识到，结合本公开实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims (18)

1.一种可信认证方法，所述可信认证方法应用于安全认证设备，所述安全认证设备可安装在用户终端上，所述安全认证设备上存储有所述安全认证设备的公钥和私钥，

所述方法包括：

向所述用户终端发送第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密；

接收所述用户终端发送的经所述TLS秘钥加密的所述网页数据；

生成认证数据包，所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

2.根据权利要求1所述的可信认证方法，所述认证数据包中的所述网页数据为经所述TLS秘钥加密的网页数据，且所述认证数据包还包含所述TLS秘钥；或者，所述认证数据包中的所述网页数据为利用所述TLS秘钥解密后的网页数据。

3.根据权利要求1所述的可信认证方法，在所述向所述用户终端发送第一秘钥之前，所述认证方法还包括：

生成所述安全认证设备的公钥和私钥；

向所述认证服务器发送所述公钥，以便所述认证服务器对所述公钥进行认证，得到认证证书，

存储所述认证服务器发送的所述认证证书。

4.根据权利要求3所述的可信认证方法，所述认证服务器为基于区块链的认证服务器，所述公钥和所述认证证书存储在所述区块链中，且所述公钥的认证是通过调用所述区块链的智能合约完成的。

5.根据权利要求4所述的可信认证方法，所述安全认证设备为USBkey。

6.一种可信认证方法，所述认证方法应用于用户终端，所述用户终端可安装安全认证设备，所述安全认证设备上存储有所述安全认证设备的公钥和私钥，

所述方法包括：

接收所述安全认证设备发送的第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密；

从所述目标网站接收经所述TLS秘钥加密的所述网页数据；

将经所述TLS秘钥加密的网页数据发送至所述安全认证设备，以便所述安全认证设备生成认证数据包，所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，且所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

7.根据权利要求6所述的可信认证方法，所述认证数据包中的所述网页数据为经所述TLS秘钥加密的网页数据，且所述认证数据包还包括所述TLS秘钥；或者，所述认证数据包中的所述网页数据为利用所述TLS秘钥解密后的网页数据。

8.根据权利要求6所述的可信认证方法，所述安全认证设备中存储有所述认证服务器对所述公钥进行认证后生成的认证证书，

在所述接收所述安全认证设备发送的第一秘钥之前，所述方法还包括：

当所述安全认证设备安装在所述用户终端上时，对所述认证证书的可靠性进行验证。

9.根据权利要求6所述的可信认证方法，所述安全认证设备为USBkey。

10.一种安全认证设备，所述安全认证设备可安装在用户终端上，所述安全认证设备上存储有所述安全认证设备的公钥和私钥，所述安全认证设备包括：

发送单元，用于向所述用户终端发送第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密；

接收单元，用于接收所述用户终端发送的经所述TLS秘钥加密的所述网页数据；

生成单元，用于生成认证数据包，所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

11.根据权利要求10所述的安全认证设备，所述认证数据包中的所述网页数据为经所述TLS秘钥加密的网页数据，且所述认证数据包还包含所述TLS秘钥；或者，所述认证数据包中的所述网页数据为利用所述TLS秘钥解密后的网页数据。

12.根据权利要求10所述的安全认证设备，所述生成单元还用于生成所述安全认证设备的公钥和私钥；

所述安全认证设备还包括：

认证单元，用于向所述认证服务器发送所述公钥，以便所述认证服务器对所述公钥进行认证，得到认证证书，

存储所述认证服务器发送的所述认证证书。

13.根据权利要求10所述的安全认证设备，所述认证服务器为基于区块链的认证服务器，所述公钥和所述认证证书存储在所述区块链中，且所述公钥的认证是通过调用所述区块链的智能合约完成的。

14.根据权利要求10所述的安全认证设备，所述安全认证设备为USBkey。

15.一种用户终端，所述用户终端可安装安全认证设备，所述安全认证设备上存储有所述安全认证设备的公钥和私钥，所述用户终端包括：

第一接收单元，用于接收所述安全认证设备发送的第一秘钥，所述第一秘钥用于构造TLS秘钥，所述TLS秘钥用于对所述用户终端访问的目标网站的网页数据进行加密；

第二接收单元，用于从所述目标网站接收经所述TLS秘钥加密的所述网页数据；

发送单元，用于将经所述TLS秘钥加密的网页数据发送至所述安全认证设备，以便所述安全认证设备生成认证数据包，所述认证数据包包含所述网页数据以及针对所述网页数据的数字签名，所述数字签名是基于所述私钥生成的，且所述数字签名用于存储有所述公钥的认证服务器对所述网页数据进行可信认证。

16.根据权利要求15所述的用户终端，所述认证数据包中的所述网页数据为经所述TLS秘钥加密的网页数据，且所述认证数据包还包括所述TLS秘钥；或者，所述认证数据包中的所述网页数据为利用所述TLS秘钥解密后的网页数据。

17.根据权利要求15所述的用户终端，所述安全认证设备中存储有所述认证服务器对所述公钥进行认证后生成的认证证书，所述用户终端还包括：

验证单元，用于当所述安全认证设备安装在所述用户终端上时，对所述认证证书的可靠性进行验证。

18.根据权利要求15所述的用户终端，所述安全认证设备为USBkey。

Images