CN105991622A - 一种报文验证方法及设备 - Google Patents

Abstract

本申请公开了一种报文验证方法，私钥服务器从业务服务器接收加密参数以及加密后的预置主密钥，根据与预置主密钥对应的私钥对预置主密钥进行解密处理，并根据解密后的预置主密钥及加密参数生成主密钥以及根据主密钥生成对称加密密钥，在利用主密钥对客户端进行完整性验证处理后通过业务服务器向客户端返回完整性响应报文，或将对称加密密钥发送至业务服务器。从而在减少现有服务器的负荷的前提下，进一步提高了报文验证过程的安全性。

Description

一种报文验证方法及设备

技术领域

本申请涉及通信技术领域，特别涉及一种报文验证方法。本申请同时还涉及一种报文验证设备。

背景技术

SSL(Secure Sockets Layer安全套接层)/TLS(Transport Layer Security，传输层安全)协议的主要目的是建立起一条安全连接，使得在其上交换的数据无法被除了通信双方之外的第三方获取。安全连接的建立是通过握手完成的，在SSL/TLS的握手过程中，会首先使用非对称加密的方式进行密钥协商，目的是使通信的双方最终协商出相同的“对称加密”的密钥，之后在安全连接上交换的数据会使用此对称密钥进行加密和解密操作，从而保证数据的安全。

在SSL/TLS协议中，不同类型的密钥交换算法会导致握手流程存在一定的区别。如图1所示，为现有技术中一种最常用密钥交换算法，该RSA密钥交换算法对SSL/TLS的握手流程如下：

i.客户端向服务器端(通常由一个或多个前端服务器组成)发起建立安全连接的请求，这是通过一个ClientHello(客户问候)报文完成的，在此报文中含有由客户端生成的Client Random(客户随机数)；

ii.服务器端在接收到客户端发的建立安全连接的请求后，在确定协议版本、加密套件等内容后，将一个Server Random(服务器随机数)和上述信息使用Server Hello(服务器问候)报文发回给客户端

iii.服务器端向客户端发送证书，证书中记录了服务器端提供的服务的相关信息，例如域名、电子邮件、证书过期时间等。证书中还带有一个PublicKey(公钥)，此公钥对应的私钥是保存在服务器端。

iv.服务器发送ServerHelloDone(服务器问候完成)报文。

v.客户端在接收到上述3个报文后，校验证书的合法性，然后生成一个PreMaster Secret(预置主密钥)，并使用证书中的公钥对此PreMaster Secret进行加密后，向服务器端发送ClientKeyExchange(客户密钥交换)报文，其中带有加密后的PreMaster Secret。客户端此时使用此PreMaster Secret和ClientRandom(客户端侧随机数)以及Server Random(服务器侧随机数)生成MasterSecret(主密钥)。

vi.服务器在接收到客户端的ClientKeyExchange之后，用和证书中对应的私钥，对其中的加密过的PreMaster Secret进行解密，并将其和Client Random以及Server Random一起进行运算得到Master Secret。后续会基于Master Secret导出多种Key，在对称加密、解密以及验证消息完整性时使用。

vii.客户端向服务器发送ChangeCipherSpec(修改密文规约)报文，声明后续发送的数据会使用协商出的加密算法加密并继续发送一个Finished(完结)报文，此报文包含了经过对称算法加密过的一段数据，这段数据是针对之前报文的摘要信息，用于服务器端进行数据完整性验证。

viii.服务器端接收到ChangeCipherSpec报文后，基于Master Secret生成对称密钥，并对客户端发送的Finished报文中的数据进行解密进而根据解密后的摘要信息验证已有数据的完整性。

ix.最后服务器端以同样的方式向客户端发送ChangeCipherSpec和Finished报文，客户端使用同样的方法进行验证。如果验证通过，则至此握手阶段结束，流程进入数据传输阶段。

x.在数据传输阶段，服务器端和客户端使用由握手过程协商出的对称密钥对数据进行加密和解密操作，由于生成对称密钥的元素之一PreMaster Secret是加密传输的，所以攻击者无法生成对称密钥，确保了数据的安全。

在实现本申请的过程中，发明人发现现有技术至少存在着以下缺点：

(1)目前各种SSL/TLS库实现的握手流程，是基于标准SSL/TLS协议实现的，这就要求程序需要预先加载私钥然后在解密PreMaster的时候使用私钥。也就是说私钥需要存留在服务器的存储设备上(内存/磁盘等)。对于大规模服务器集群中大量处于网络边缘的服务器/设备(例如CDN的边缘节点中的服务器、SLB对外提供负载均衡的服务器等)，由于存留了私钥，会导致私钥副本数量的大量上升，并且这些服务器/设备直接对外提供服务，安全风险较高，使得其中任何一个服务器出现安全问题，都可能会导致私钥泄漏从而影响整体的数据安全。

(2)在SSL/TLS协议的握手流程中，使用私钥解密数据或签名，以及后续的计算Master Secret、数据完整性校验都需要消耗大量的计算资源，使得服务器的处理能力变差，容易在握手的过程中遭受DDoS(Distributed Denial ofService，分布式拒绝服务)攻击。

发明内容

本申请提供了一种报文验证方法，用以在保证报文验证过程中的安全性的同时减轻服务器的负荷，该方法应用于包括客户端、业务服务器以及私钥服务器的***中，包括：

所述私钥服务器从所述业务服务器接收加密参数以及加密后的预置主密钥，所述预置主密钥为所述业务服务器从所述客户端发送的客户密钥交换报文中获取的；

所述私钥服务器根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

所述私钥服务器根据所述主密钥生成对称加密密钥；

所述私钥服务器在利用所述主密钥对所述客户端进行完整性验证处理后通过所述业务服务器向所述客户端返回完整性响应报文，或将所述对称加密密钥发送至所述业务服务器，以使所述业务服务器在根据所述对称加密密钥对所述客户端进行完整性验证处理后向所述客户端返回完整性响应报文。

本申请还提出了一种报文验证方法，所述方法应用于包括客户端、业务服务器以及私钥服务器的***中，该方法包括：

所述业务服务器接收所述客户端发送的客户密钥交换报文，并获取所述客户密钥交换报文中携带的预置主密钥；

所述业务服务器将所述预置主密钥以及加密参数发送至所述私钥服务器，以使所述私钥服务器根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

所述业务服务器根据所述私钥服务器返回的服务器侧完结Finished报文或加密后的对称密钥，向所述客户端返回完整性响应报文；

其中，所述服务器侧Finished报文为所述私钥服务器在利用所述主密钥对所述客户端发送的Finished报文进行完整性验证通过后生成的；所述对称加密密钥为所述私钥服务器根据所述主密钥生成。

相应地，本申请还提出了一种报文验证设备，所述设备作为私钥服务器应用于包括客户端、业务服务器以及所述私钥服务器的***中，该设备包括：

接收模块，用于从所述业务服务器接收加密参数以及加密后的预置主密钥，所述预置主密钥为所述业务服务器从所述客户端发送的客户密钥交换报文中获取的；

解密模块，用于根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

生成模块，用于根据所述主密钥生成对称加密密钥；

验证模块，用于在利用所述主密钥对所述客户端进行完整性验证处理后通过所述业务服务器向所述客户端返回完整性响应报文，或将所述对称加密密钥发送至所述业务服务器，以使所述业务服务器在根据所述对称加密密钥对所述客户端进行完整性验证处理后向所述客户端返回完整性响应报文。

本申请还提出了一种报文验证设备，其特征在于，所述设备作为业务服务器应用于包括客户端、所述业务服务器以及私钥服务器的***中，该方法包括：

接收模块，用于接收所述客户端发送的客户密钥交换报文，并获取所述客户密钥交换报文中携带的预置主密钥；

发送模块，用于将所述预置主密钥以及加密参数发送至所述私钥服务器，以使所述私钥服务器根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

响应模块，用于根据所述私钥服务器返回的服务器侧完结Finished报文或加密后的对称密钥，向所述客户端返回完整性响应报文；

其中，所述服务器侧Finished报文为所述私钥服务器在利用所述主密钥对所述客户端发送的Finished报文进行完整性验证通过后生成的；所述对称加密密钥为所述私钥服务器根据所述主密钥生成。

由此可见，通过应用以上技术方案，私钥服务器从业务服务器接收加密参数以及加密后的预置主密钥，根据与预置主密钥对应的私钥对预置主密钥进行解密处理，并根据解密后的预置主密钥及加密参数生成主密钥以及根据主密钥生成对称加密密钥，在利用主密钥对客户端进行完整性验证处理后通过业务服务器向客户端返回完整性响应报文，或将对称加密密钥发送至业务服务器。从而在减少现有服务器的负荷的前提下，进一步提高了报文验证过程的安全性。

附图说明

图1为现有技术中基于RSA密钥交换算法的SSL/TLS流程示意图；

图2为本申请提出的一种报文验证方法的流程示意图；

图3为本申请提出的另一种报文验证方法的流程示意图；

图4为本申请提出的一种报文验证设备的结构示意图；

图5为本申请提出的另一种报文验证设备的结构示意图。

具体实施方式

有鉴于背景技术中的技术问题，本申请提出了一种SSL/TLS握手中将公钥和私钥分离的方法，该方法的主要思路是将私钥处理的相关功能从现有技术中与客户端直接通信的前端服务器上分离出来，设置单独的放置私钥的私钥服务器并赋予其私钥处理相关的功能)，将不再放置私钥以及分离了私钥功能的前端服务器作为业务服务器，其中只保留证书(含公钥)。当业务服务器和客户端进行SSL/TLS握手时需要使用私钥时，远程连接私钥服务器，将预置主密钥等发送到私钥服务器进行处理，处理后生成特定数据返回前端服务器，业务服务器恢复握手流程并完成握手。

如图2所示，该方法具体包括以下流程：

S201，所述私钥服务器从所述业务服务器接收加密参数以及加密后的预置主密钥，所述预置主密钥为所述业务服务器从所述客户端发送的客户密钥交换报文中获取的。

为了保障报文验证过程中的安全性，本申请将公钥和私钥分开部署到不同的服务器设备上，其中存放公钥的服务器称为业务服务器，而私钥的服务器称为私钥服务器，存放公钥的设备无法直接从存放私钥的设备上读取到私钥的内容。当需要使用私钥时，私钥的使用方(业务服务器)需要将要处理的数据发送给存放私钥的设备(私钥服务器)，并由私钥服务器返回在业务服务器与客户端在后续的数据交互阶段所需要使用的对称密钥和主密钥，分别用于私钥的使用方使用这些数据进行加密/解密/校验等。

需要说明的是，根据实际使用情况的不同(例如设备性能或安全阈值)，技术人员可以为实现本申请技术方案的过程中为多个业务服务器设置同一个私钥服务器，也可以为单个业务服务器设置一个私钥服务器，这些都属于本申请的保护范围。

由于公钥和私钥分开部署到不同的服务器设备上，因此本申请优选实施例中可直接将私钥服务器与业务服务器通过非加密通道连接，而加密参数可采用客户端与业务服务器在正式验证前续步骤中所产生的客户端侧随机数以及服务器侧随机数，其中服务器侧随机数为所述服务器在接收到所述客户端发送的建立安全连接请求后生成的，建立安全连接请求中携带有客户端侧随机数。

基于上述设置，公钥和私钥以分离的方式对外提供SSL/TLS服务。由于私钥没有存放在对外提供服务的业务服务器上，而是远程部署到单独的私钥服务器上。在此基础上可以针对业务服务器和私钥服务器进行独立的安全级别设计。例如对私钥服务器设置更高的安全级别，而对业务服务器设计较低的安全级别。这样一来，即使安全级别较低的业务服务器被入侵，私钥内容也不会泄漏。

S202，所述私钥服务器根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

S203，所述私钥服务器根据所述主密钥生成对称加密密钥；

S204，所述私钥服务器在利用所述主密钥对所述客户端进行完整性验证处理后通过所述业务服务器向所述客户端返回完整性响应报文，或将所述对称加密密钥发送至所述业务服务器，以使所述业务服务器在根据所述对称加密密钥对所述客户端进行完整性验证处理后向所述客户端返回完整性响应报文。

基于S202中所生成的主密钥以及S203中所生成的对称加密密钥，本申请优选的实施例提出了两种不同的具体验证方式，分别如下：

(1)所述私钥服务器将加密后的所述对称密钥发送至所述业务服务器，以使所述业务服务器在对所述加密后的所述对称密钥进行解密后，利用所述对称密钥对所述客户端发送的Finished报文中的数据进行完整性数据验证，以及在验证通过后向所述客户端返回完整性响应报文。

具体地，在该方式中，私钥的使用方(业务服务器)和私钥的存放方(私钥服务器)之间的通信是非加密的通道，但是私钥服务器返回的数据本身是加密的。因此私钥服务器首先将根据自身的额外对称密钥对所述对称密钥进行加密处理，并将所述加密后的所述对称密钥发送至所述业务服务器。同时，私钥的使用方(业务服务器)和私钥的存放方(私钥服务器)之间需要拥有相同的一个对称密钥用于对私钥服务器返回的数据进行加密或解密(私钥服务器与业务服务器中预置有相同的额外对称密钥)，此密钥通过另外的手段下发给两个使用者，并做定期更新。

(2)所述私钥服务器利用所述主密钥对所述客户端发送的Fnished报文进行完整性验证；若所述完整性验证通过，所述私钥服务器根据所述主报文生成用于响应所述Fnished报文的的服务器侧Fnished报文，并将所述服务器侧Fnished报文发送至所述业务服务器，以使所述业务服务器根据所述服务器侧Fnished报文向所述客户端返回完整性响应报文。

由于该方案中将验证的工作交予私钥服务器来完成，因此不但私钥的使用方(业务服务器)不需要接收任何经过私钥处理后的数据(对称密钥、主密钥等)以外，同时私钥的使用方(业务服务器)和私钥的存放方(私钥服务器)之间的通信是非加密的通道，其中传递的数据也都是非加密的。

此外，由于私钥被部署到了私钥服务器上，就使得大量的计算资源的消耗从业务服务器转移到了私钥服务器上，极大的减轻了业务服务器的计算压力。在发生DDoS攻击时，如果私钥服务器瘫痪，也不会影响业务服务器对其他业务的处理(例如HTTP服务)，同时还能够进行针对业务服务器进行降级处理，将其从HTTPS切换回HTTP。避免因为业务服务器瘫痪而影响HTTP业务的处理。

相应地，以上优选实施例以私钥服务器侧的角度说明了报文验证的流程，以下为本申请提出的另一种报文验证方法，该方法以业务服务器的角度进行说明，如图3所示，包括以下步骤：

S301，所述业务服务器接收所述客户端发送的客户密钥交换报文，并获取所述客户密钥交换报文中携带的预置主密钥。

由于公钥和私钥分开部署到不同的设备上，因此本申请优选实施例中可直接将私钥服务器与业务服务器通过非加密通道连接，而加密参数可采用客户端与业务服务器在正式验证前续步骤中所产生的客户端侧随机数以及服务器侧随机数，其中服务器侧随机数为所述业务服务器在接收到所述客户端发送的建立安全连接请求后生成的，建立安全连接请求中携带有客户端侧随机数。此外，私钥服务器与业务服务器中预置有相同的额外对称密钥

S302，所述业务服务器将所述预置主密钥以及加密参数发送至所述私钥服务器，以使所述私钥服务器根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥。

S303，所述业务服务器根据所述私钥服务器返回的服务器侧完结Finished报文或加密后的对称密钥，向所述客户端返回完整性响应报文。

需要说明的是，该步骤中服务器侧Finished报文为所述私钥服务器在利用所述主密钥对所述客户端发送的Finished报文进行完整性验证通过后生成的；对称加密密钥为所述私钥服务器根据所述主密钥生成。除了直接根据私钥服务器返回的服务器侧Finished报文向客户端返回完整性响应报文之外，本申请优选实施例对于“根据所述私钥服务器返回的服务器侧Finished报文或加密后的对称密钥向所述客户端返回完整性响应报文”提出了如下具体步骤：

步骤a)所述业务服务器接收所述私钥服务器发送的加密后的对称密钥，所述对称密钥由所述私钥服务器根据自身的额外对称密钥进行加密处理；

步骤b)所述业务服务器根据自身预置的额外对称密钥对加密后的所述对称密钥进行解密处理；

步骤c)所述业务服务器根据解密后的所述对称密钥对所述客户端发送的Finished报文中的数据进行完整性数据验证，并在验证通过后向所述客户端返回所述完整性响应报文。

为了进一步阐述本申请的技术思想，现结合具体的应用场景，对本申请的技术方案进行说明。特别的，本申请提出了以下两种具体实施例：

具体实施例一：该方案除了将公钥保存到前端提供SSL服务的业务服务器之外，在安全等级更高的地方另行部署服务器存放私钥(此为私钥服务器)。当业务服务器需要使用私钥时，发送请求到到达私钥服务器，由私钥服务器在本地使用私钥对数据进行处理，将处理结果返回给业务服务器。具体步骤解释如下：

i.客户端向服务器端(业务服务器)发起建立安全连接的请求，这是通过一个ClientHello报文完成的，在此报文中含有由客户端生成的随机数ClientRandom。

ii.服务器端在接收到客户端发的建立安全连接的请求后，在确定协议版本、加密套件等内容后，将一个Server Random随机数和上述信息使用ServerHello报文发回给客户端。

iii.服务器端向客户端发送证书，证书中记录了服务器端提供的服务的相关信息，例如域名、电子邮件、证书过期时间等。证书中还带有一个公钥(Public Key)，此公钥对应的私钥是保存在服务器端。

iv.服务器发送ServerHelloDone报文。

v.客户端在接收到上述3个报文后，校验证书的合法性，然后生成一个PreMaster Secret，并使用证书中的公钥对此PreMaster Secret进行加密后，向服务器端发送ClientKeyExchange报文，其中带有加密后的PreMaster Secret。客户端此时使用此PreMaster Secret和Client Random以及Server Random生成Master Secret。

vi.客户端向服务器发送ChangeCipherSpec报文，声明后续发送的数据会使用协商出的加密算法加密并继续发送一个Fnished报文，此报文包含了经过对称算法加密过的一段数据，这段数据是针对之前报文的摘要信息，用于服务器端进行数据完整性验证。

vii.服务器在接收到客户端的ClientKeyExchange之后，由于本地没有保存和证书对应的私钥，因此需要将加密后的PreMaster Secret、Client Random和Server Random发送到远程的私钥服务器进行处理。为了防止数据在中途被篡改，需要对上述数据做数字签名。

viii.私钥服务器在接收到上述数据后，用和证书中对应的私钥，对其中的加密过的PreMaster Secret进行解密，并将其和Client Random以及ServerRandom一起进行运算得到Master Secret。在基于Master Secret得出对称加密密钥。

ix.私钥服务器将生成的Master Secret和对称加密密钥，使用另外一个对称密钥对他们进行加密，然后发送给服务器端，服务器端在收到此加密数据后，使用同样的对称密钥对其解密，获得MasterSecret和对称加密密钥。用于对数据加密的额外的对称密钥，需要预先部署到服务器端和私钥服务器端，并定时更新。

x.服务器端接收到私钥服务器应答回来的数据后，使用对称密钥对客户端发送的Finished报文中的数据进行解密进而根据解密后的摘要信息验证已有数据的完整性。

xi.最后服务器端以同样的方式向客户端发送ChangeCipherSpec和Finished报文，客户端使用同样的方法进行验证。如果验证通过，则至此握手阶段结束，流程进入数据传输阶段。

xii.在数据传输阶段，服务器端和客户端使用由握手过程协商出的对称密钥对数据进行加密和解密操作，由于生成对称密钥的元素之一PreMasterSecret是加密传输的，所以攻击者无法生成对称密钥，确保了数据的安全。

具体实施例二：该方案进一步分离了对称密钥，使得握手之后的数据通信部分的加密解密，也转移到了私钥服务器上。具体步骤如下：

i.客户端向服务器端(业务服务器)发起建立安全连接的请求，这是通过一个ClientHello报文完成的，在此报文中含有由客户端生成的随机数ClientRandom。

ii.服务器端在接收到客户端发的建立安全连接的请求后，在确定协议版本、加密套件等内容后，将一个Server Random随机数和上述信息使用ServerHello报文发回给客户端。

iii.服务器端向客户端发送证书，证书中记录了服务器端提供的服务的相关信息，例如域名、电子邮件、证书过期时间等。证书中还带有一个公钥(Public Key)，此公钥对应的私钥是保存在服务器端。

iv.服务器发送ServerHelloDone报文。

v.客户端在接收到上述3个报文后，校验证书的合法性，然后生成一个PreMaster Secret，并使用证书中的公钥对此PreMaster Secret进行加密后，向服务器端发送ClientKeyExchange报文，其中带有加密后的PreMaster Secret。客户端此时使用此PreMaster Secret和Client Random以及Server Random生成Master Secret。

vi.客户端向服务器发送ChangeCipherSpec报文，声明后续发送的数据会使用协商出的加密算法加密并继续发送一个Fnished报文，此报文包含了经过对称算法加密过的一段数据，这段数据是针对之前报文的摘要信息，用于服务器端进行数据完整性验证。

vii.服务器在接收到客户端的ClientKeyExchange之后，由于本地没有保存和证书对应的私钥，因此需要将加密后的PreMaster Secret、Client Random和Server Random，以及客户端发送的Finshed报文和待处理的服务器端Finished报文，发送到远程的私钥服务器进行处理。为了防止数据在中途被篡改，需要对上述数据做数字签名。

viii.私钥服务器在接收到上述数据后，用和证书中对应的私钥，对其中的加密过的PreMaster Secret进行解密，并将其和Client Random以及ServerRandom一起进行运算得到Master Secret。在基于Master Secret得出对称加密密钥。私钥服务器然后使用Master Secret验证客户端的Fnished报文，并使用Master Secret生成最终的服务器端Finished报文。

ix.私钥服务器将生成的服务器端Finished报文发送给服务器端。

x.最后服务器端以同样的方式向客户端发送ChangeCipherSpec和Finished报文，客户端使用同样的方法进行验证。如果验证通过，则至此握手阶段结束，流程进入数据传输阶段。

xi.在数据传输阶段，由于服务器端并不保存在握手阶段协商而成的对称密钥，因此加密数据在到达服务器端之后，需要进一步发送到私钥服务器进行解密，或者对于服务器端要发送的数据，也需要首先发送到私钥服务器进行加密。这样所以涉及到加密/解密操作的步骤均转移到了私钥服务器上。

为达到以上技术目的，本申请还提出了一种报文验证设备，如图4所示，所述设备作为私钥服务器应用于包括客户端、业务服务器以及所述私钥服务器的***中，4包括：

接收模块410，用于从所述业务服务器接收加密参数以及加密后的预置主密钥，所述预置主密钥为所述业务服务器从所述客户端发送的客户密钥交换报文中获取的；

解密模块420，用于根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

生成模块430，用于根据所述主密钥生成对称加密密钥；

验证模块440，用于在利用所述主密钥对所述客户端进行完整性验证处理后通过所述业务服务器向所述客户端返回完整性响应报文，或将所述对称加密密钥发送至所述业务服务器，以使所述业务服务器在根据所述对称加密密钥对所述客户端进行完整性验证处理后向所述客户端返回完整性响应报文。

在具体的应用场景中，所述验证模块具体用于：

将加密后的所述对称密钥发送至所述业务服务器，以使所述业务服务器在对所述加密后的所述对称密钥进行解密后，利用所述对称密钥对所述客户端发送的完结Finished报文中的数据进行完整性数据验证，以及在验证通过后向所述客户端返回完整性响应报文。

在具体的应用场景中，所述验证模块将加密后的所述对称密钥发送至所述业务服务器，具体为：

所述验证模块根据自身的额外对称密钥对所述对称密钥进行加密处理，并将所述加密后的所述对称密钥发送至所述业务服务器；

其中，所述私钥服务器与所述业务服务器中预置有相同的额外对称密钥。

在具体的应用场景中，所述验证模块具体包括：

验证子模块，用于利用所述主密钥对所述客户端发送的Fnished报文进行完整性验证；

生成子模块，用于在所述验证子模块确认所述完整性验证通过后，根据所述主报文生成用于响应所述Finished报文的的服务器侧Finished报文，并将所述服务器侧Finished报文发送至所述业务服务器，以使所述业务服务器根据所述服务器侧Finished报文向所述客户端返回完整性响应报文。

在具体的应用场景中，所述私钥服务器与所述业务服务器通过非加密通道连接，所述加密参数至少包括：

客户端侧随机数、服务器侧随机数；

其中，所述服务器侧随机数为所述业务服务器在接收到所述客户端发送的建立安全连接请求后生成的，所述建立安全连接请求中携带所述客户端侧随机数。

本申请还提出了一种报文验证设备，如图5所示，所述设备作为业务服务器应用于包括客户端、所述业务服务器以及私钥服务器的***中，该设备包括：

接收模块510，用于接收所述客户端发送的客户密钥交换报文，并获取所述客户密钥交换报文中携带的预置主密钥；

发送模块520，用于将所述预置主密钥以及加密参数发送至所述私钥服务器，以使所述私钥服务器根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

响应模块530，用于根据所述私钥服务器返回的服务器侧完结Finished报文或加密后的对称密钥，向所述客户端返回完整性响应报文；

其中，所述服务器侧Finished报文为所述私钥服务器在利用所述主密钥对所述客户端发送的Finished报文进行完整性验证通过后生成的；所述对称加密密钥为所述私钥服务器根据所述主密钥生成。

在具体的应用场景中，所述响应模块具体包括：

接收子模块，用于接收所述私钥服务器发送的加密后的对称密钥，所述对称密钥由所述私钥服务器根据自身的额外对称密钥进行加密处理；

解密子模块，用于根据自身预置的额外对称密钥对加密后的所述对称密钥进行解密处理；

验证子模块，用于根据解密后的所述对称密钥对所述客户端发送的Finished报文中的数据进行完整性数据验证，并在验证通过后向所述客户端返回所述完整性响应报文；

其中，所述私钥服务器与所述业务服务器中预置有相同的额外对称密钥。

在具体的应用场景中，所述私钥服务器与所述业务服务器通过非加密通道连接，所述加密参数至少包括：

客户端侧随机数、服务器侧随机数；

其中，所述服务器侧随机数为所述业务服务器在接收到所述客户端发送的建立安全连接请求后生成的，所述建立安全连接请求中携带所述客户端侧随机数。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (16)

1.一种报文验证方法，其特征在于，所述方法应用于包括客户端、业务服务器以及私钥服务器的***中，该方法包括：

所述私钥服务器从所述业务服务器接收加密参数以及加密后的预置主密钥，所述预置主密钥为所述业务服务器从所述客户端发送的客户密钥交换报文中获取的；

所述私钥服务器根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

所述私钥服务器根据所述主密钥生成对称加密密钥；

所述私钥服务器在利用所述主密钥对所述客户端进行完整性验证处理后通过所述业务服务器向所述客户端返回完整性响应报文，或将所述对称加密密钥发送至所述业务服务器，以使所述业务服务器在根据所述对称加密密钥对所述客户端进行完整性验证处理后向所述客户端返回完整性响应报文。

2.如权利要求1所述的方法，其特征在于，所述私钥服务器将所述对称加密密钥发送至所述业务服务器，具体为：

所述私钥服务器将加密后的所述对称密钥发送至所述业务服务器，以使所述业务服务器在对所述加密后的所述对称密钥进行解密后，利用所述对称密钥对所述客户端发送的完结Finished报文中的数据进行完整性数据验证，以及在验证通过后向所述客户端返回完整性响应报文。

3.如权利要求2所述的方法，其特征在于，所述私钥服务器将加密后的所述对称密钥发送至所述业务服务器，具体为：

所述私钥服务器根据自身的额外对称密钥对所述对称密钥进行加密处理，并将所述加密后的所述对称密钥发送至所述业务服务器；

其中，所述私钥服务器与所述业务服务器中预置有相同的额外对称密钥。

4.如权利要求1所述的方法，其特征在于，所述私钥服务器在利用所述主密钥对所述客户端进行完整性验证处理后通过所述业务服务器向所述客户端返回完整性响应报文，具体为：

所述私钥服务器利用所述主密钥对所述客户端发送的Finished报文进行完整性验证；

若所述完整性验证通过，所述私钥服务器根据所述主报文生成用于响应所述Finished报文的的服务器侧Finished报文，并将所述服务器侧Finished报文发送至所述业务服务器，以使所述业务服务器根据所述服务器侧Finished报文向所述客户端返回完整性响应报文。

5.如权利要求1-4任一项所述的方法，其特征在于，所述私钥服务器与所述业务服务器通过非加密通道连接，所述加密参数至少包括：

客户端侧随机数、服务器侧随机数；

其中，所述服务器侧随机数为所述业务服务器在接收到所述客户端发送的建立安全连接请求后生成的，所述建立安全连接请求中携带所述客户端侧随机数。

6.一种报文验证方法，其特征在于，所述方法应用于包括客户端、业务服务器以及私钥服务器的***中，该方法包括：

所述业务服务器接收所述客户端发送的客户密钥交换报文，并获取所述客户密钥交换报文中携带的预置主密钥；

所述业务服务器将所述预置主密钥以及加密参数发送至所述私钥服务器，以使所述私钥服务器根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

所述业务服务器根据所述私钥服务器返回的服务器侧完结Finished报文或加密后的对称密钥，向所述客户端返回完整性响应报文；

其中，所述服务器侧Finished报文为所述私钥服务器在利用所述主密钥对所述客户端发送的Finished报文进行完整性验证通过后生成的；所述对称加密密钥为所述私钥服务器根据所述主密钥生成。

7.如权利要求6所述的方法，其特征在于，所述业务服务器根据所述私钥服务器返回的服务器侧Finished报文或加密后的对称密钥向所述客户端返回完整性响应报文，具体为：

所述业务服务器接收所述私钥服务器发送的加密后的对称密钥，所述对称密钥由所述私钥服务器根据自身的额外对称密钥进行加密处理；

所述业务服务器根据自身预置的额外对称密钥对加密后的所述对称密钥进行解密处理；

所述业务服务器根据解密后的所述对称密钥对所述客户端发送的Finished报文中的数据进行完整性数据验证，并在验证通过后向所述客户端返回所述完整性响应报文；

其中，所述私钥服务器与所述业务服务器中预置有相同的额外对称密钥。

8.如权利要求6或7任一项所述的方法，其特征在于，所述私钥服务器与所述业务服务器通过非加密通道连接，所述加密参数至少包括：

客户端侧随机数、服务器侧随机数；

其中，所述服务器侧随机数为所述业务服务器在接收到所述客户端发送的建立安全连接请求后生成的，所述建立安全连接请求中携带所述客户端侧随机数。

9.一种报文验证设备，其特征在于，所述设备作为私钥服务器应用于包括客户端、业务服务器以及所述私钥服务器的***中，该设备包括：

接收模块，用于从所述业务服务器接收加密参数以及加密后的预置主密钥，所述预置主密钥为所述业务服务器从所述客户端发送的客户密钥交换报文中获取的；

解密模块，用于根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

生成模块，用于根据所述主密钥生成对称加密密钥；

验证模块，用于在利用所述主密钥对所述客户端进行完整性验证处理后通过所述业务服务器向所述客户端返回完整性响应报文，或将所述对称加密密钥发送至所述业务服务器，以使所述业务服务器在根据所述对称加密密钥对所述客户端进行完整性验证处理后向所述客户端返回完整性响应报文。

10.如权利要求9所述的设备，其特征在于，所述验证模块具体用于：

将加密后的所述对称密钥发送至所述业务服务器，以使所述业务服务器在对所述加密后的所述对称密钥进行解密后，利用所述对称密钥对所述客户端发送的完结Finished报文中的数据进行完整性数据验证，以及在验证通过后向所述客户端返回完整性响应报文。

11.如权利要求10所述的设备，其特征在于，所述验证模块将加密后的所述对称密钥发送至所述业务服务器，具体为：

所述验证模块根据自身的额外对称密钥对所述对称密钥进行加密处理，并将所述加密后的所述对称密钥发送至所述业务服务器；

其中，所述私钥服务器与所述业务服务器中预置有相同的额外对称密钥。

12.如权利要求9所述的设备，其特征在于，所述验证模块具体包括：

验证子模块，用于利用所述主密钥对所述客户端发送的Fnished报文进行完整性验证；

生成子模块，用于在所述验证子模块确认所述完整性验证通过后，根据所述主报文生成用于响应所述Finished报文的的服务器侧Finished报文，并将所述服务器侧Finished报文发送至所述业务服务器，以使所述业务服务器根据所述服务器侧Finished报文向所述客户端返回完整性响应报文。

13.如权利要求9-12任一项所述的设备，其特征在于，所述私钥服务器与所述业务服务器通过非加密通道连接，所述加密参数至少包括：

客户端侧随机数、服务器侧随机数；

其中，所述服务器侧随机数为所述业务服务器在接收到所述客户端发送的建立安全连接请求后生成的，所述建立安全连接请求中携带所述客户端侧随机数。

14.一种报文验证设备，其特征在于，所述设备作为业务服务器应用于包括客户端、所述业务服务器以及私钥服务器的***中，该设备包括：

接收模块，用于接收所述客户端发送的客户密钥交换报文，并获取所述客户密钥交换报文中携带的预置主密钥；

发送模块，用于将所述预置主密钥以及加密参数发送至所述私钥服务器，以使所述私钥服务器根据与所述预置主密钥对应的私钥对所述预置主密钥进行解密处理，并根据解密后的预置主密钥及所述加密参数生成主密钥；

响应模块，用于根据所述私钥服务器返回的服务器侧完结Finished报文或加密后的对称密钥，向所述客户端返回完整性响应报文；

其中，所述服务器侧Finished报文为所述私钥服务器在利用所述主密钥对所述客户端发送的Finished报文进行完整性验证通过后生成的；所述对称加密密钥为所述私钥服务器根据所述主密钥生成。

15.如权利要求14所述的设备，其特征在于，所述响应模块具体包括：

接收子模块，用于接收所述私钥服务器发送的加密后的对称密钥，所述对称密钥由所述私钥服务器根据自身的额外对称密钥进行加密处理；

解密子模块，用于根据自身预置的额外对称密钥对加密后的所述对称密钥进行解密处理；

验证子模块，用于根据解密后的所述对称密钥对所述客户端发送的Finished报文中的数据进行完整性数据验证，并在验证通过后向所述客户端返回所述完整性响应报文；

其中，所述私钥服务器与所述业务服务器中预置有相同的额外对称密钥。

16.如权利要求14或15任一项所述的设备，其特征在于，所述私钥服务器与所述业务服务器通过非加密通道连接，所述加密参数至少包括：

客户端侧随机数、服务器侧随机数；

其中，所述服务器侧随机数为所述业务服务器在接收到所述客户端发送的建立安全连接请求后生成的，所述建立安全连接请求中携带所述客户端侧随机数。