CN102510387B - 一种安全传输层协议tls握手方法和装置及ttp - Google Patents

Abstract

本发明公开了一种TLS握手方法和装置及TTP，该方法基于双方TLS握手过程，第一方将第一方的询问和第一方所支持的密码套件列表发送给TTP；TTP基于将TTP的询问、TTP的临时公钥、TTP-第一方密码套件通知第一方；第一方利用生成的与TTP间的会话密钥将第一方-TTP消息鉴别码通知TTP；TTP利用生成的与第一方间的会话密钥对第一方-TTP消息鉴别码验证；验证通过后，向第一方发送TTP-第一方消息鉴别码；第一方利用对TTP-第一方消息鉴别码验证，若验证通过，第一方完成与TTP间的安全隧道建立。本发明基于双方TLS握手方法与TTP间建立安全隧道，提高了安全性且具有很好的后向兼容性。

Description

一种安全传输层协议TLS握手方法和装置及TTP

技术领域

本发明涉及网络安全技术领域，尤其涉及一种安全传输层协议TLS握手方法和装置及TTP。

背景技术

TLS(Transport Layer Security，安全传输层协议)用于在两个通信应用程序之间提供保密性和数据完整性。TLS协议包括TLS记录协议和TLS握手协议，其中TLS握手协议包括改变密码规范协议、警告协议和握手过程。警告协议定义了相关警告消息，且可以根据应用需求不断被扩展。TLS握手过程定义了十种TLS握手消息：问候请求消息(HelloRequest)、客户端问候消息(ClientHello)、服务端问候消息(ServerHello)、证书消息(Certificate)、服务端密钥交换消息(ServerKeyExchange)、证书请求消息(CertificateRequest)、服务端问候结束消息(ServerHelloDone)、客户端密钥交换消息(ClientKeyExchange)、证书验证消息(CertificateVerify)、完成消息(Finished)，其中客户端问候消息、客户端密钥交换消息、证书验证消息仅可以由客户端(Client)发送，问候请求消息、服务端问候消息、服务端密钥交换消息、证书请求消息、服务端问候结束消息仅可以由服务端(Server)发送，而证书消息、完成消息可以由客户端和服务端发送。为了区别客户端和服务端发送的证书消息，将客户端发送的证书消息表示为客户端的证书消息，而将服务端发送的证书消息表示为服务端的证书消息。为了区别客户端和服务端发送的完成消息，将客户端发送的完成消息表示为客户端的完成消息，而将服务端发送的完成消息表示为服务端的完成消息。

当客户端和服务端都采用证书时，如图1所示，客户端和服务端的双方TLS握手过程的具体步骤如下：

步骤1)当服务端主动发起TLS握手过程时，服务端向客户端发送：①问候请求消息。

步骤2)当客户端收到服务端发送的问候请求消息、或客户端主动发起TLS握手过程时，向服务端发送：②客户端问候消息，包含客户端的询问、客户端所支持的密码套件列表，其中客户端的询问为客户端产生的一个随机数。

步骤3)服务端收到客户端发送的客户端问候消息后，依次向客户端发送如下消息：③服务端问候消息，包含服务端的询问，及服务端从客户端问候消息中选择的一种服务端所支持的密码套件，服务端的询问为服务端产生的一个随机数；④服务端的证书消息，包含服务端的证书；⑤服务端密钥交换消息，包含服务端的临时公钥、服务端利用服务端的证书所对应的私钥对服务端的临时公钥的签名；⑥证书请求消息，包含服务端的证书请求信息；⑦服务端问候结束消息，表示消息发送过程结束。

步骤4)客户端首先依次接收服务端发送的消息③～⑦，然后依次向服务端发送如下消息：④’客户端的证书消息，包含客户端的证书；⑧客户端密钥交换消息，包含客户端的临时公钥；⑨证书验证消息，包含客户端利用客户端的证书所对应的私钥对消息②、③～⑦、④’、⑧的签名；⑩’客户端的完成消息，包含客户端利用客户端所生成的客户端和服务端之间的会话密钥对消息②、③～⑦、④’、⑧、⑨计算的消息鉴别码，客户端所生成的客户端和服务端之间的会话密钥是客户端依据客户端的询问、服务端的询问(从③中获取)、客户端的临时私钥、服务端的临时公钥(从⑤中获取)所生成的客户端和服务端之间的会话密钥。其中，客户端会根据④中的服务端的证书对⑤中的签名进行验证，根据⑥证书请求消息发送④’客户端的证书消息。

步骤5)服务端首先依次接收客户端发送的④’、⑧、⑨、⑩’，然后向客户端发送⑩服务端的完成消息，该消息包含服务端利用服务端所生成的客户端和服务端之间的会话密钥对②、③～⑦、④’、⑧、⑨、⑩’计算的消息鉴别码，服务端所生成的客户端和服务端之间的会话密钥是服务端依据客户端的询问(从②中获取)、服务端的询问、客户端的临时公钥(从⑧中获取)、服务端的临时私钥生成客户端和服务端之间的会话密钥。其中，服务端会根据④’中客户端的证书对⑨中的签名进行验证。服务端会利用自身生成的会话密钥对⑩’的消息鉴别码验证；

步骤6)客户端收到服务端发送的服务端的完成消息后，利用客户端生成的会话密钥验证服务端的完成消息，若验证不通过，则丢弃该消息或向服务端发送警告消息，否则客户端和服务端成功建立了客户端和服务端之间的安全隧道，即完成密码套件和会话密钥的协商。

在以上所述的TLS握手过程中，当客户端接收一个由服务端发送的握手消息时，若对该握手消息的验证不通过，则丢弃该消息或向服务端发送警告消息，否则接收下一个由服务端发送的握手消息或开始依次向服务端发送客户端所生成的握手消息。

在以上所述的TLS握手过程中，当服务端接收一个由客户端发送的握手消息时，若对该握手消息的验证不通过，则丢弃该消息或向客户端发送警告消息，否则接收下一个由客户端发送的握手消息或开始依次向客户端发送服务端所生成的握手消息。

在以上所述的TLS握手过程中，客户端和服务端可以建立客户端和服务端之间的安全隧道。但是，上述TLS握手过程是一个点对点的协议过程，不适用于可信第三方在线的应用场景，也就是说不能利用可信第三方来增强TLS握手过程的安全性，包括利用可信第三方集中验证客户端的证书和服务端的证书的有效性、建立客户端与可信第三方之间的安全隧道和建立服务端与可信第三方之间的安全隧道。

发明内容

本发明提供一种安全传输层协议TLS握手方法和装置及TTP，用以解决现有技术中不能利用可信第三方来增强TLS握手过程的安全性的问题。

本发明提供一种安全传输层协议TLS握手方法，包括：

步骤(1)，在第一方与第二方的双方TLS握手过程中，第一方将第一方的询问和第一方所支持的密码套件列表发送给可信第三方TTP；

步骤(2)，TTP基于双方TLS握手过程，将TTP的询问、TTP的临时公钥、TTP-第一方密码套件通知第一方，所述TTP-第一方密码套件为TTP从第一方所支持的密码套件列表中选取的一种TTP所支持的密码套件；

步骤(3)，第一方利用第一方的询问、TTP的询问、第一方的临时私钥、TTP的临时公钥生成第一方与TTP间的会话密钥；在双方TLS握手过程中，第一方将第一方-TTP消息鉴别码通知TTP，所述第一方-TTP消息鉴别码为第一方利用生成的第一方与TTP间的会话密钥对从TTP接收及发给TTP的信息计算的消息鉴别码；

步骤(4)，TTP在双方TLS握手过程中，获取第一方的临时公钥及第一方-TTP消息鉴别码，根据TTP的询问、第一方的询问、TTP的临时私钥及第一方的临时公钥生成第一方与TTP间的会话密钥，利用生成的第一方与TTP间的会话密钥对第一方-TTP消息鉴别码验证；验证通过后，TTP在双方TLS握手过程中，向第一方发送TTP-第一方消息鉴别码，所述TTP-第一方消息鉴别码为TTP利用生成的第一方与TTP间的会话密钥对从第一方接收及发给第一方的信息计算的消息鉴别码；

步骤(5)，在双方TLS握手过程中，第一方利用自身生成的第一方与TTP间的会话密钥对TTP-第一方消息鉴别码验证，若验证通过，第一方完成与TTP间的安全隧道建立。

本发明还提供一种TLS握手装置，包括：

第一通知单元，用于在所述TLS握手装置作为第一方与第二方的双方TLS握手过程中，将第一方的询问和第一方所支持的密码套件列表发送给可信第三方TTP；

密钥生成单元，接收TTP通知的TTP的询问、TTP的临时公钥、TTP-第一方密码套件；利用第一方的询问、TTP的询问、第一方的临时私钥、TTP的临时公钥生成第一方与TTP间的会话密钥；

第二通知单元，用于在双方TLS握手过程中，将第一方-TTP消息鉴别码通知TTP，所述第一方-TTP消息鉴别码为利用密钥生成单元生成的第一方与TTP间的会话密钥对从TTP接收及发给TTP的信息计算的消息鉴别码；

验证单元，用于接收TTP通知的TTP-第一方消息鉴别码，在双方TLS握手过程中，利用密钥生成单元生成的第一方与TTP间的会话密钥对TTP-第一方消息鉴别码验证，若验证通过，完成与TTP间的安全隧道建立。

本发明还提供一种可信第三方TTP，包括：

第一接收单元，用于在第一方与第二方的双方TLS握手过程中，接收第一方通知的第一方将第一方的询问和第一方所支持的密码套件列表；

第一通知单元，用于基于双方TLS握手过程，将TTP的询问、TTP的临时公钥、TTP-第一方密码套件通知第一方，所述TTP-第一方密码套件为TTP从第一方所支持的密码套件列表中选取的一种TTP所支持的密码套件；

第二接收单元，用于接收第一方通知的第一方-TTP消息鉴别码；

密钥生成单元，用于在双方TLS握手过程中，获取第一方的临时公钥及第一方-TTP消息鉴别码，根据TTP的询问、第一方的询问、TTP的临时私钥及第一方的临时公钥生成第一方与TTP间的会话密钥；

鉴别单元，利用密钥生成单元生成的第一方与TTP间的会话密钥对第一方-TTP消息鉴别码验证；验证通过后，在双方TLS握手过程中，向第一方发送TTP-第一方消息鉴别码，所述TTP-第一方消息鉴别码为利用生成的第一方与TTP间的会话密钥对从第一方接收及发给第一方的信息计算的消息鉴别码。

利用本发明提供的安全传输层协议TLS握手方法和装置及TTP，具有以下有益效果：本发明应用到客户端与服务端的双方TLS握手方法场景时，除了建立客户端与服务端之间的安全隧道之外，还可以建立客户端与可信第三方之间的安全隧道，增强了安全性；除了建立客户端与服务端之间的安全隧道之外，还可以建立服务端与可信第三方之间的安全隧道，增强了安全性；基于双方TLS握手方法与TTP间建立安全隧道，具有很好的后向兼容性。

附图说明

图1为现有的双方TLS握手过程示意图；

图2a、图2b为本发明实施例1～2中TLS握手方法示意图；

图3a、图3b为本发明实施例3中TLS握手方法示意图。

具体实施方式

下面结合附图和实施例对本发明提供的TLS握手方法和装置及TTP进行更详细地说明。

现有的双方TLS握手过程是一个点对点的协议过程，不适用于可信第三方在线的应用场景，也就是说不能利用可信第三方来增强TLS握手过程的安全性，鉴于此，本发明实施例提供一种安全传输层协议TLS握手方法，包括：

步骤(1)，在第一方与第二方的双方TLS握手过程中，第一方将第一方的询问和第一方所支持的密码套件列表发送给可信第三方TTP；

第一方的询问为第一方产生的一个随机数。

步骤(2)，TTP基于双方TLS握手过程，将TTP的询问、TTP的临时公钥、TTP-第一方密码套件通知第一方，所述TTP-第一方密码套件为TTP从第一方所支持的密码套件列表中选取的一种TTP所支持的密码套件；

TTP的询问为TTP产生的一个随机数。

步骤(3)，第一方利用第一方的询问、TTP的询问、第一方的临时私钥、TTP的临时公钥生成第一方与TTP间的会话密钥；在双方TLS握手过程中，第一方将第一方-TTP消息鉴别码通知TTP，所述第一方-TTP消息鉴别码为第一方利用生成的第一方与TTP间的会话密钥对从TTP接收及发给TTP的信息计算的消息鉴别码；

这里的从TTP接收及发给TTP的信息，优选为之前发给TTP所有信息及之前从TTP接收的所有信息，及当前发给TTP的除第一方-TTP消息鉴别码外的所有信息。

步骤(4)，TTP在双方TLS握手过程中，获取第一方的临时公钥及第一方-TTP消息鉴别码，根据TTP的询问、第一方的询问、TTP的临时私钥及第一方的临时公钥生成第一方与TTP间的会话密钥，利用生成的第一方与TTP间的会话密钥对第一方-TTP消息鉴别码验证；验证通过后，TTP在双方TLS握手过程中，向第一方发送TTP-第一方消息鉴别码，所述TTP-第一方消息鉴别码为TTP利用生成的第一方与TTP间的会话密钥对从第一方接收及发给第一方的信息计算的消息鉴别码；

这里的从第一方接收及发给第一方的信息，优选为之前发给第一方的所有信息及之前从第一方接收的所有信息，及当前发给第一方的除TTP-第一方消息鉴别码外的所有信息。

步骤(5)，在双方TLS握手过程中，第一方利用自身生成的第一方与TTP间的会话密钥对TTP-第一方消息鉴别码验证，若验证通过，第一方完成与TTP间的安全隧道建立。

本发明实施例提供的TLS握手方法，基于双方TLS握手过程建立了其中一方与可信第三方之间的安全隧道，因此适用于可信第三方在线的应用场景，从而能够利用可信第三方来增强TLS握手过程的安全性，本发明实施例提供的方法由于是在双方TLS握手过程基础上实现的，因此具有很好的后向兼容性。

上述双方TLS握手过程为现有的TLS握手过程，具体握手过程这里不做限定。优选地，上述第一方为客户端，第二方为服务端，或者，上述第一方为服务端，第二方为客户端。

下面以本发明实施例在背景技术描述的TLS握手过程中实现的TLS握手方法，由于本发明实施例提供的TLS握手方法增强了安全性，本文称为增强安全性的TLS握手过程。

实施例1

本实施例中第一方为客户端，第二方为服务端，本实施例提供的TLS握手方法能够在现有双方TLS握手过程中，在客户端与TTP间建立安全隧道。

如图2a所示，本实施例中的TLS握手方法具体包括如下步骤：

步骤1)当服务端主动发起双方TLS握手过程时，服务端向客户端发送：①问候请求消息。

步骤2)客户端收到问候请求消息或主动发起双方TLS握手过程时，向服务端发送：②客户端问候消息，所述客户端问候消息包括客户端的询问、客户端所支持的密码套件列表，客户端的询问为客户端产生的一个随机数；

优选地，为了实现标识客户端是否需要建立与TTP间安全隧道，及是否需要验证服务端的证书有效性，客户端具体可以依次向服务端发送如下握手消息：②客户端问候消息；(11)客户端请求标识消息(ClientRequestFlag)，用于标识客户端是否需要利用TTP来验证服务端的证书的有效性，以及显示客户端是否需要建立与TTP之间的安全隧道；(12)客户端问候结束消息(ClientHelloDone)，用于指示客户端已发送消息，可以接收服务端发送的消息，即切换为“接收消息”的状态。

步骤3)服务端依次接收客户端发送的各握手消息，然后执行如下步骤：

步骤31)当客户端请求标识消息显示客户端不需要利用TTP来验证服务端的证书的有效性

服务端向TTP发送：(一)第一消息，所述第一消息包括客户端问候消息的内容，即包括客户端问候消息中的客户端的询问、客户端所支持的密码套件列表。

步骤32)当客户端请求标识消息显示客户端需要利用TTP来验证服务端的证书的有效性时

服务端向TTP发送：(一)第一消息，除了包括步骤31)中第一消息的内容外，还包括服务端的证书。

步骤4)TTP收到服务端发送的第一消息后，执行如下步骤：

步骤41)当客户端不需要利用TTP来验证服务端的证书的有效性

若第一消息中不包括服务端的证书，则说明不需要验证服务端证书的有效性，TTP向服务端发送：(二)第二消息，所述第二消息包括TTP的询问、TTP的临时公钥及TTP-客户端密码套件，其中TTP的询问是TTP产生的一个随机数，其中TTP-客户端密码套件是TTP从第一消息的客户端所支持的密码套件列表中选取的一种TTP所支持的密码套件。

为了提高信息的安全性，优选地，第二消息还包括对TTP的临时公钥的签名，所述对TTP的临时公钥的签名是TTP利用自己的私钥对TTP的临时公钥的签名。

步骤42)当客户端需要利用TTP来验证服务端的证书的有效性时

若第一消息中包括服务端的证书，则说明需要验证服务端证书的有效性，TTP向服务端发送：(二)第二消息，除了包括步骤41)中第二消息的内容外，还包括从第一消息获取的客户端的询问和服务端的证书、本地生成的服务端的证书的验证结果、对服务端证书验证结果的签名，其中对服务端证书验证结果的签名是TTP利用自己的私钥对客户端的询问、服务端的证书、服务端的证书的验证结果的签名。

步骤5)服务端收到TTP发送的第二消息后，执行如下步骤：

步骤51)当客户端不需要利用TTP来验证服务端的证书的有效性

依次向客户端发送如下握手消息：③服务端问候消息、④服务端的证书消息、⑤服务端密钥交换消息、⑥证书请求消息、(13)TTP-客户端密钥数据交换消息、⑦服务端问候结束消息，所述TTP-客户端密钥数据交换消息包含第二消息内容，即包含从第二消息中获取的TTP的询问、TTP-客户端密码套件、TTP的临时公钥，优选地，还包括对TTP的临时公钥的签名；

上述消息③～⑦的内容定义同现有的消息内容定义，具体如下：

③服务端问候消息，包含服务端的询问、服务端从客户端问候消息的客户端支持的密码套件中选取的一种服务端所支持的密码套件；④服务端的证书消息，包含服务端的证书；⑤服务端密钥交换消息，包含服务端的临时公钥、服务端利用服务端的证书所对应的私钥对服务端的临时公钥的签名；⑥证书请求消息，包含服务端的证书请求信息；⑦服务端问候结束消息。

步骤52)当客户端需要利用TTP来验证服务端的证书的有效性时

如图2b所示，依次向客户端发送如下握手消息：③服务端问候消息；④服务端的证书消息；(14)证书验证结果消息，包含从第二消息中获取的客户端的询问、服务端的证书、服务端的证书的验证结果、对服务端证书验证结果的签名；⑤服务端密钥交换消息；⑥证书请求消息；(13)TTP-客户端密钥数据交换消息；⑦服务端问候结束消息。

除(14)外其它消息的内容同步骤51)中描述。

步骤6)客户端首先依次接收步骤5)中服务端向客户端所发送的各个握手消息，依据客户端的询问、客户端的临时私钥、TTP-客户端密钥数据交换消息中TTP的询问及TTP的临时公钥，生成客户端和TTP之间的会话密钥；

若接收到证书验证结果消息，客户端对证书验证结果消息中的对服务端证书验证结果的签名进行验证，若验证通过且服务端证书有效时，客户端依次向服务端发送如下握手消息：④’客户端的证书消息、⑧客户端密钥交换消息、(13)’客户端-TTP密钥交换消息、⑨证书验证消息、⑩’客户端的完成消息，所述客户端-TTP密钥交换消息包含客户端-TTP消息鉴别码，客户端-TTP消息鉴别码为客户端对之前发给TTP所有信息、之前从TTP接收所有信息、当前发给TTP的除客户端-TTP消息鉴别码外的所有信息计算的消息鉴别码。

优选地，若TTP-客户端密钥数据交换消息包括对TTP的临时公钥的签名，则首先对该签名进行验证，若验证通过，再生成客户端和TTP之间的会话密钥。上述消息④’、⑧、⑨、⑩’的内容同现有技术，具体如下：

④’客户端的证书消息，包含客户端的证书；

⑧客户端密钥交换消息，包含客户端的临时公钥；

⑨证书验证消息，包含客户端利用客户端的证书所对应的私钥对发给服务端及从服务端接收信息的签名，即对步骤2)中客户端向服务端所发送的各个握手消息、步骤5)中服务端向客户端所发送的各个握手消息、④’客户端的证书消息、⑧客户端密钥交换消息、(13)’客户端-TTP密钥交换消息的签名；

⑩’客户端的完成消息，包含客户端利用客户端所生成的客户端和服务端之间的会话密钥对发给服务端及从服务端接收的信息计算的消息鉴别码，即对步骤2)中客户端向服务端所发送的各个握手消息、步骤5)中服务端向客户端所发送的各个握手消息、④’客户端的证书消息、⑧客户端密钥交换消息、(13)’客户端-TTP密钥交换消息、⑨证书验证消息计算的消息鉴别码。

具体地，客户端依据客户端的询问、从服务端问候消息获取服务端的询问、客户端的临时私钥、从服务端密钥交换消息获取的服务端的临时公钥生成客户端与服务端间的会话密钥。

优选地，为了进一步增强安全性，上述(13)’客户端-TTP密钥交换消息，还包括：包含客户端利用客户端的证书所对应的私钥对客户端的密钥数据的签名；客户端-TTP消息鉴别码具体为：

客户端利用自身生成的客户端和TTP之间的会话密钥对客户端的询问、客户端所支持的密码套件列表、TTP的询问、TTP-客户端密码套件、TTP的临时公钥、对TTP的临时公钥的签名、客户端的证书、客户端的临时公钥、对客户端临时公钥的签名计算的消息鉴别码。

步骤7)服务端依次接收步骤6)中客户端发送的各个握手消息，然后执行如下步骤：

步骤71)当服务端不需要利用TTP来验证客户端的证书的有效性时

向TTP发送：(三)第三消息，包括从客户端密钥交换消息中获取的客户端的临时公钥、从客户端-TTP密钥交换消息中获取的客户端-TTP消息鉴别码。

优选地，第三消息还包括从客户端的证书消息中获取的客户端的证书、从客户端-TTP密钥交换消息中获取的对客户端的临时公钥的签名。

步骤72)当服务端需要利用TTP来验证客户端的证书的有效性

向TTP发送(三)第三消息，至少包括服务端的询问和从客户端的证书消息中获取的客户端的证书，还包括步骤71)中第三消息的内容。

步骤8)TTP收到服务端发送的第三消息后，执行如下步骤：

步骤81)当服务端不需要利用TTP来验证客户端的证书的有效性

利用TTP的询问、TTP的临时私钥、第一消息中客户端的询问、第三消息中客户端的临时公钥生成客户端与TTP间的会话密钥，TTP利用生成的客户端与TTP间的会话密钥验证第三消息中的客户端-TTP消息鉴别码，若验证通过，向服务端发送包含TTP-客户端消息鉴别码的第四消息。

为了进一步增强安全性，优选地，TTP利用第三消息中的客户端的证书验证第三消息中对客户端的临时公钥的签名，若验证通过再生成客户端与TTP间的会话密钥。

其中TTP-客户端消息鉴别码是TTP利用自身生成的客户端和TTP之间的会话密钥对之前从客户端接收的所有信息、之前发给客户端所有信息、当前发给客户端的除TTP-客户端消息鉴别码外所有信息的消息鉴别码，即对客户端的询问、客户端所支持的密码套件列表、TTP的询问、TTP-客户端密码套件、TTP的临时公钥、对TTP的临时公钥的签名、客户端的证书、客户端的临时公钥、对客户端临时公钥的签名、客户端-TTP消息鉴别码计算的消息鉴别码。

步骤82)若服务端需要利用TTP来验证客户端的证书的有效性，则验证客户端-TTP消息鉴别码通过后，在发送(四)第四消息之前，还包括：生成客户端的证书的验证结果和对客户端证书验证结果的签名，然后向服务端发送(四)第四消息，第四消息除了包括上述TTP-客户端消息鉴别码，还包括：

服务端的询问、客户端的证书、客户端的证书的验证结果、对客户端证书验证结果的签名，其中服务端的询问和客户端证书从第三消息中获取，对客户端证书验证结果的签名是TTP利用自己的私钥对服务端的询问、客户端的证书、客户端的证书的验证结果的签名。

步骤9)服务端收到TTP发送的第四消息后，执行如下步骤：

步骤91)若服务端不需要利用TTP来验证客户端的证书的有效性

依次向客户端发送(15)TTP确认消息、⑩服务端的完成消息，其中TTP确认消息包含第四消息中的TTP-客户端消息鉴别码，服务端的完成消息具体同现有技术，即包含服务端利用服务端所生成的客户端和服务端之间的会话密钥对步骤2)中客户端向服务端所发送的握手消息、步骤5)中服务端向客户端所发送的各个握手消息、步骤6)中客户端向服务端发送的各个握手消息、TTP确认消息计算的消息鉴别码。

服务端所生成的客户端和服务端之间的会话密钥，是服务端依据服务端的询问、服务端的临时私钥、客户端问候消息中的客户端的询问及客户端的临时公钥生成的客户端和服务端之间的会话密钥。

步骤92)若服务端需要利用TTP来验证客户端的证书的有效性，则在发送TTP确认消息之前，进一步包括：

验证第四消息中对客户端证书验证结果的签名，若验证不通过或客户端证书无效，则丢弃第四消息，否则依次向客户端发送TTP确认消息、服务端的完成消息。

步骤10)当客户端收到服务端发送的TTP确认消息后，利用自身生成的客户端与TTP间的会话密钥验证TTP确认消息中的TTP-客户端消息鉴别码，若验证不通过，则丢弃该消息或向服务端发送警告消息，否则继续接收服务端发送的服务端的完成消息，若利用自身生成的客户端与服务端间的会话密钥对服务端的完成消息的验证不通过，则丢弃该消息或向服务端发送警告消息，否则客户端和服务端成功建立了客户端和服务端之间的安全隧道，以及客户端和TTP成功建立了客户端和TTP之间的安全隧道。

实施例2

本实施例中第一方为客户端，第二方为服务端，本实施例提供的TLS握手方法，在实施例1实现客户端与TTP间安全隧道建立的基础上，还进一步建立服务端与TTP间的安全隧道。

本实施例中的TLS握手方法具体包括如下步骤：

步骤1)当服务端主动发起双方TLS握手过程时，服务端向客户端发送：①问候请求消息。

步骤2)客户端收到问候请求消息或主动发起双方TLS握手过程时，向服务端发送：②客户端问候消息，所述客户端问候消息包括客户端的询问、客户端所支持的密码套件列表，客户端的询问为客户端产生的一个随机数；

优选地，为了实现标识客户端是否需要建立与TTP间安全隧道，及是否需要验证服务端的证书有效性，客户端具体可以依次向服务端发送如下握手消息：②客户端问候消息；(11)客户端请求标识消息(ClientRequestFlag)，用于标识客户端是否需要利用TTP来验证服务端的证书的有效性，以及显示客户端是否需要建立与TTP之间的安全隧道；(12)客户端问候结束消息(ClientHelloDone)

步骤3)服务端依次接收客户端发送的各握手消息，然后执行如下步骤：

步骤31)当客户端请求标识消息显示客户端不需要利用TTP来验证服务端的证书的有效性

服务端向TTP发送：(一)第一消息，与实施例1相比，还包括服务端的询问和服务端所支持的密码套件列表，即具体包括：

客户端的询问、客户端所支持的密码套件列表、服务端的询问、服务端所支持的密码套件列表，其中服务端的询问为服务端产生的一个随机数。

步骤32)客户端请求标识消息显示客户端需要利用TTP来验证服务端的证书的有效性

服务端向TTP发送：(一)第一消息，除了包括步骤31)中第一消息的内容外，还包括服务端的证书。

步骤4)TTP收到服务端发送的第一消息后，执行如下步骤：

步骤41)当客户端不需要利用TTP来验证服务端的证书的有效性

TTP向服务端发送：(二)第二消息，与实施1相比，第二消息还包括TTP-服务端密码套件，所述TTP-服务端密码套件为TTP从第一消息的服务端所支持的密码套件列表中选择的一种TTP所支持的密码套件，即第二消息包括：

TTP的询问、TTP-客户端密码套件、TTP-服务端密码套件、TTP的临时公钥、对TTP的临时公钥的签名。

步骤42)当客户端需要利用TTP来验证服务端的证书的有效性

TTP向服务端发送：(二)第二消息，除了包括步骤41)中第二消息的内容外，还包括从第一消息获取的客户端的询问和服务端的证书、本地生成的服务端的证书的验证结果、对服务端证书验证结果的签名，其中对服务端证书验证结果的签名是TTP利用自己的私钥对客户端的询问、服务端的证书、服务端的证书的验证结果的签名。

步骤5)服务端收到TTP发送的第二消息后的处理同实施例1，优选地，为进一步增强安全性，服务端收到第二消息后，还包括：

对第二消息中对TTP的临时公钥的签名进行验证，若验证通过再向客户端发送各个握手消息。即执行：

步骤51)当客户端不需要利用TTP来验证服务端的证书的有效性

对第二消息中对TTP的临时公钥的签名进行验证，若验证通过，依次向客户端发送如下握手消息：③服务端问候消息、④服务端的证书消息、⑤服务端密钥交换消息、⑥证书请求消息、(13)TTP-客户端密钥数据交换消息、⑦服务端问候结束消息，所述TTP-客户端密钥数据交换消息包含第二消息内容，即包含从第二消息中获取的TTP的询问、TTP-客户端密码套件、TTP的临时公钥，优选地，还包括对TTP的临时公钥的签名。

步骤52)当客户端需要利用TTP来验证服务端的证书的有效性时

对第二消息中对TTP的临时公钥的签名进行验证，若验证通过，依次向客户端发送如下握手消息：③服务端问候消息；④服务端的证书消息；(14)证书验证结果消息，包含从第二消息中获取的客户端的询问、服务端的证书、服务端的证书的验证结果、对服务端证书验证结果的签名；⑤服务端密钥交换消息；⑥证书请求消息；(13)TTP-客户端密钥数据交换消息；⑦服务端问候结束消息。

除(14)外其它消息的内容同步骤51)中描述。

步骤6)客户端首先依次接收步骤5)中服务端向客户端所发送的各个握手消息，之后的处理同实施例1，即依据客户端的询问、客户端的临时私钥、TTP-客户端密钥数据交换消息中TTP的询问及TTP的临时公钥，生成客户端和TTP之间的会话密钥；

若接收到证书验证结果消息，客户端对证书验证结果消息中的对服务端证书验证结果的签名进行验证，若验证通过且服务端证书有效时，客户端依次向服务端发送如下握手消息：④’客户端的证书消息、⑧客户端密钥交换消息、(13)’客户端-TTP密钥交换消息、⑨证书验证消息、⑩’客户端的完成消息，所述客户端-TTP密钥交换消息包含客户端-TTP消息鉴别码，客户端-TTP消息鉴别码为客户端对之前发给TTP所有信息、之前从TTP接收所有信息、当前发给TTP的除客户端-TTP消息鉴别码外的所有信息计算的消息鉴别码。

优选地，若TTP-客户端密钥数据交换消息包括对TTP的临时公钥的签名，则首先对该签名进行验证，若验证通过，再生成客户端和TTP之间的会话密钥。上述消息④’、⑧、⑨、⑩’的内容见实施例1的描述。

优选地，为进一步增强安全性，(13)’客户端-TTP密钥交换消息，还包括：包含客户端利用客户端的证书所对应的私钥对客户端的密钥数据的签名；客户端-TTP消息鉴别码具体为：客户端利用自身生成的客户端和TTP之间的会话密钥对客户端的询问、客户端所支持的密码套件列表、TTP的询问、TTP-客户端密码套件、TTP的临时公钥、对TTP的临时公钥的签名、客户端的证书、客户端的临时公钥、对客户端临时公钥的签名计算的消息鉴别码。

步骤7)，服务端首先依次接收客户端发送的各个握手消息，与实施例1相比，还包括：服务端利用服务端的询问、服务端的临时私钥、从第二消息获取的TTP的询问及TTP的临时公钥生成服务端与TTP间的会话密钥；服务端向TTP发送的第三消息还包括服务端的临时公钥、服务端-TTP消息鉴别码，服务端-TTP消息鉴别码为服务端利用自身生成的服务端与TTP间的会话密钥对从TTP接收及发给TTP的信息计算的消息鉴别码。

优选地，服务端向TTP发送的第三消息，还包括服务端利用服务端证书所对应的私钥对服务端的临时公钥的签名。

即具体执行如下步骤：

步骤71)当服务端不需要利用TTP来验证客户端的证书的有效性时

服务端向TTP发送：(三)第三消息，包括客户端的证书、客户端的临时公钥、对客户端的临时公钥的签名、客户端-TTP消息鉴别码、服务端的临时公钥、对服务端的临时公钥的签名、服务端-TTP消息鉴别码。

具体地，服务端-TTP消息鉴别码是服务端利用服务端所生成的服务端和TTP之间的会话密钥对第一消息、第二消息、第三消息中除服务端-TTP消息鉴别码外所有信息计算的消息鉴别码。

当客户端不需要利用TTP来验证服务端的证书的有效性时，第三消息中服务端-TTP消息鉴别码之前还包括服务端的证书。

步骤72)服务端需要利用TTP来验证客户端的证书的有效性

向TTP发送(三)第三消息，至少包括服务端的询问和从客户端问候消息获取的客户端的证书，还包括步骤71)中第三消息其它内容。

步骤8)TTP收到服务端发送的第三消息后，所执行的处理与实施例1相比，还包括：TTP利用TTP的询问、TTP的临时私钥、第一消息中服务端的询问、第三消息中服务端的临时公钥生成服务端与TTP间的会话密钥，TTP利用自身生成的服务端与TTP间的会话密钥验证第三消息中的服务端-TTP消息鉴别码，若验证通过，再验证客户端-TTP消息鉴别码；

TTP向服务端发送的第四消息还包括TTP-服务端消息鉴别码，所述TTP-服务端消息鉴别码为TTP利用自身生成的服务端与TTP间的会话密钥对从服务端接收及发给服务端的信息计算的消息鉴别码。

进一步优选地，TTP对所述第三消息中的对服务端的临时公钥的签名进行验证，验证通过后再生成服务端与TTP间的会话密钥。

即具体执行如下步骤：

步骤81)当服务端不需要利用TTP来验证客户端的证书的有效性

TTP对第三消息中对服务端的临时公钥的签名验证，验证通过，则生成服务端与TTP间的会话密钥，利用生成的会话密钥验证第三消息中验证服务端-TTP消息鉴别码，若验证不通过，则丢弃第三消息，否则，执行：

TTP利用第三消息中的客户端的证书验证第三消息中对客户端的临时公钥的签名，若验证通过，再生成客户端与TTP间的会话密钥，利用生成的客户端与TTP间的会话密钥验证客户端-TTP消息鉴别码，若验证不通过，则丢弃第三消息，否则向服务端发送：(四)第四消息，包括TTP-客户端消息鉴别码、TTP-服务端消息鉴别码。

具体地，TTP-服务端消息鉴别码是TTP利用TTP所生成的服务端和TTP之间的会话密钥对第一消息、第二消息、第三消息、第四消息中除TTP-服务端消息鉴别码外所有信息计算的消息鉴别码。

步骤82)若服务端需要利用TTP来验证客户端的证书的有效性，则验证客户端-TTP消息鉴别码通过后，发送(四)的第四消息还包括：

服务端的询问、客户端的证书、客户端的证书的验证结果、对客户端证书验证结果的签名。

步骤9)服务端收到TTP发送的第四消息后，与实施例1相比，服务端在向客户端发送TTP确认消息之前，还包括：服务端利用自身生成的服务端与TTP间的会话密钥，验证第四消息中的TTP-服务端消息鉴别码，若验证通过，再发送TTP确认消息。即具体执行如下步骤：

步骤91)若服务端不需要利用TTP来验证客户端的证书的有效性

服务端利用自身生成的服务端与TTP间的会话密钥，验证第四消息中的TTP-服务端消息鉴别码，若验证不通过，则丢弃第四消息，否则依次向客户端发送TTP确认消息、服务端的完成消息。TTP确认消息、服务端的完成消息的描述同实施例1，这里不再重述。

步骤92)若服务端需要利用TTP来验证客户端的证书的有效性，则在发送TTP确认消息、服务端的完成消息之前，进一步包括：

验证第四消息中对客户端证书验证结果的签名，若验证不通过或客户端证书无效，则丢弃第四消息，否则验证TTP-服务端消息鉴别码，验证通过，依次向客户端发送TTP确认消息、服务端的完成消息。

步骤10)当客户端收到服务端发送的TTP确认消息后，具体处理过程同实施例1，这里不再重述。

实施例3

本实施例中第一方为服务端，第二方为客户端，本实施例提供的TLS握手方法能够在现有双方TLS握手过程中，在服务端与TTP间建立安全隧道。

如图3a所示，本实施例中的TLS握手方法具体包括如下步骤：

步骤1)当服务端主动发起双方TLS握手过程时，服务端向客户端发送：①问候请求消息。

步骤2)客户端收到问候请求消息或主动发起双方TLS握手过程时，向服务端发送：②客户端问候消息，所述客户端问候消息包括客户端的询问、客户端所支持的密码套件列表，客户端的询问为客户端产生的一个随机数；

优选地，为实现标识客户端是否需要建立与TTP间安全隧道，及是否需要验证服务端的证书有效性，客户端具体可以依次向服务端发送如下握手消息：②客户端问候消息；(11)客户端请求标识消息(ClientRequestFlag)，用于标识客户端是否需要利用TTP来验证服务端的证书的有效性，以及显示客户端是否需要建立与TTP之间的安全隧道；(12)客户端问候结束消息(ClientHelloDone)。

步骤3)服务端依次接收客户端发送的各握手消息，然后执行如下步骤：

步骤31)当客户端请求标识消息显示客户端不需要利用TTP来验证服务端的证书的有效性

服务端向TTP发送：(一)第一消息，所述第一消息包括服务端的询问和服务端所支持的密码套件列表，其中服务端的询问为服务端产生的一个随机数。

步骤32)当客户端请求标识消息显示客户端需要利用TTP来验证服务端的证书的有效性时

服务端向TTP发送(一)第一消息，除了包括步骤31)中第一消息的内容外，还包括：从客户端问候消息中获取的客户端的询问、服务端的证书。

步骤4)TTP收到服务端发送的第一消息后，执行如下步骤：

步骤41)客户端不需要利用TTP来验证服务端的证书的有效性

若第一消息中不包括服务端的证书，则说明不需要验证服务端证书的有效性，TTP向服务端发送：(二)第二消息，包括TTP的询问、TTP-服务端密码套件、TTP的临时公钥，其中TTP的询问是TTP产生的一个随机数，TTP-服务端密码套件为TTP从第一消息的服务端所支持的密码套件列表中选择的一种TTP所支持的密码套件，对TTP的密钥数据的签名是TTP利用自己的私钥对TTP的密钥数据的签名。

为了提高信息的安全性，优选地，第二消息还包括对TTP的临时公钥的签名，所述对TTP的临时公钥的签名是TTP利用自己的私钥对TTP的临时公钥的签名。

步骤42)当客户端需要利用TTP来验证服务端的证书的有效性

若第一消息中包括服务端的证书，则说明需要验证服务端证书的有效性，TTP向服务端发送：(二)第二消息，除了包括步骤41)中第二消息的内容外，还包括从第一消息获取的客户端的询问和服务端的证书、本地生成的服务端的证书的验证结果、对服务端证书验证结果的签名，其中对服务端证书验证结果的签名是TTP利用自己的私钥对客户端的询问、服务端的证书、服务端的证书的验证结果的签名。

步骤5)服务端收到TTP的第二消息后，执行如下步骤：

步骤51)若客户端不需要利用TTP来验证服务端的证书的有效性

依次向客户端发送如下握手消息：③服务端问候消息、④服务端的证书消息、⑤服务端密钥交换消息、⑥证书请求消息、⑦服务端问候结束消息。

上述消息③～⑦的内容定义同现有的消息内容定义，具体见实施例1的描述，这里不再重述。

优选地，服务端收到第二消息后，首先对第二消息中对TTP的临时公钥的签名进行验证，若验证不通过，则丢弃第二消息，若验证通过再向客户端发送各个握手消息。

步骤52)若客户端需要利用TTP来验证服务端的证书的有效性

如图3b，依次向客户端发送如下握手消息：③服务端问候消息；④服务端的证书消息；(14)证书验证结果消息，包含从第二消息中获取的客户端的询问、服务端的证书、服务端的证书的验证结果、对服务端证书验证结果的签名；⑤服务端密钥交换消息；⑥证书请求消息；⑦服务端问候结束消息。

除(14)外其它消息的内容同步骤51)中描述

优选地，服务端收到第二消息后，首先对第二消息中对TTP的临时公钥的签名进行验证，若验证不通过，则丢弃第二消息，若验证通过再向客户端发送各个握手消息。

步骤6)客户端首先依次接收步骤5)中服务端向客户端所发送的各个握手消息，若接收到证书验证结果消息，客户端对证书验证结果消息中的对服务端证书验证结果的签名进行验证，若验证通过且服务端证书有效时，依次向服务端发送如下握手消息：④’客户端的证书消息、⑧客户端密钥交换消息、⑨证书验证消息、⑩’客户端的完成消息，上述消息④’、⑧、⑨、⑩’的内容同现有技术，具体如下：

④’客户端的证书消息，包含客户端的证书；

⑧客户端密钥交换消息，包含客户端的临时公钥；

⑨证书验证消息，包含客户端利用客户端的证书所对应的私钥对步骤2)中客户端向服务端所发送的各个握手消息、步骤5)中服务端向客户端所发送的各个握手消息、客户端的证书消息、客户端密钥交换消息的签名；

⑩’客户端的完成消息，包含客户端利用客户端所生成的客户端和服务端之间的会话密钥对步骤2)中客户端向服务端所发送的各个握手消息、步骤5)中服务端向客户端所发送的各个握手消息、客户端的证书消息、客户端密钥交换消息、证书验证消息计算的消息鉴别码。

客户端所生成的客户端和服务端之间的会话密钥，客户端依据客户端的询问、从服务端问候消息获取服务端的询问、客户端的临时私钥、从服务端密钥交换消息获取的服务端的临时公钥生成客户端与服务端间的会话密钥。

步骤7)服务端首先依次接收步骤6)中客户端发送的各个握手消息，然后执行如下步骤：

步骤71)当服务端不需要利用TTP来验证客户端的证书的有效性

服务端利用服务端的询问、服务端的临时私钥、从第二消息获取的TTP的询问及TTP的临时公钥生成服务端与TTP间的会话密钥，服务端向TTP发送：(三)第三消息，第三消息包括服务端的临时公钥、服务端-TTP消息鉴别码，所述服务端-TTP消息鉴别码为服务端利用自身所生成的服务端和TTP之间的会话密钥对从TTP接收及发给TTP的信息计算的消息鉴别码。

优选地，为进一步提高安全性，服务端向TTP发送的第三消息，还包括服务端利用服务端的证书所对应的私钥对服务端的临时公钥的签名。

上述服务端-TTP消息鉴别码，具体是服务端利用服务端所生成的服务端和TTP之间的会话密钥对第一消息、第二消息、第三消息中除服务端-TTP消息鉴别码外所有信息计算的消息鉴别码。

当客户端不需要利用TTP来验证服务端的证书的有效性时，第三消息中服务端-TTP消息鉴别码之前还包括服务端的证书。

步骤72)服务端需要利用TTP来验证客户端的证书的有效性

向TTP发送(三)第三消息，至少包括服务端的询问和从客户端问候消息获取的客户端的证书，还包括步骤71)中第三消息其它内容。

步骤8)TTP收到服务端发送的第三消息后，执行如下步骤：

步骤81)服务端不需要利用TTP来验证客户端的证书的有效性

TTP利用TTP的询问、TTP的临时私钥、第一消息中服务端的询问、第三消息中服务端的临时公钥生成服务端与TTP间的会话密钥，TTP利用自身生成的服务端与TTP间的会话密钥验证第三消息中的服务端-TTP消息鉴别码；若验证不通过，则丢弃第三消息，若验证通过，向服务端发送：(四)第四消息，包括TTP-服务端消息鉴别码。

TTP-服务端消息鉴别码是TTP利用TTP所生成的服务端和TTP之间的会话密钥对之前从服务端接收及发给服务端的信息计算的消息鉴别码，具体地，是对第一消息、第二消息、第三消息、第四消息中除TTP-服务端消息鉴别码外所有信息计算的消息鉴别码。

优选地，进一步包括：TTP对第三消息中的对服务端的临时公钥的签名进行验证，验证通过后再生成服务端与TTP间的会话密钥。

步骤82)若服务端需要利用TTP来验证客户端的证书的有效性，则验证客户端-TTP消息鉴别码通过后，在发送(四)第四消息之前，还包括：生成客户端的证书的验证结果和对客户端证书验证结果的签名，然后向服务端发送(四)第四消息，第四消息除了包括上述TTP-客户端消息鉴别码，还包括：

服务端的询问、客户端的证书、客户端的证书的验证结果、对客户端证书验证结果的签名，其中对客户端证书验证结果的签名是TTP利用自己的私钥对服务端的询问、客户端的证书、客户端的证书的验证结果的签名。

具体地，TTP-服务端消息鉴别码是TTP利用TTP所生成的服务端和TTP之间的会话密钥对第一消息、第二消息、第三消息、第四消息中除TTP-服务端消息鉴别码外所有信息计算的消息鉴别码。

步骤9)服务端收到TTP发送的第四消息后，执行如下步骤：

步骤91)服务端不需要利用TTP来验证客户端的证书的有效性

服务端利用自身生成的服务端与TTP间的会话密钥，验证第四消息中的TTP-服务端消息鉴别码，若验证不通过，则丢弃第四消息，否则向客户端发送：⑩服务端的完成消息，服务端的完成消息具体同现有技术，即包含服务端利用服务端所生成的客户端和服务端之间的会话密钥对步骤2)中客户端向服务端所发送的各个握手消息、步骤5)中服务端向客户端所发送的各个握手消息、步骤6)中客户端向服务端发送的各个握手消息计算的消息鉴别码。

服务端所生成的客户端和服务端之间的会话密钥，是服务端依据服务端的询问、服务端的临时私钥、客户端问候消息中的客户端的询问及客户端的临时公钥生成的客户端和服务端之间的会话密钥。

步骤92)服务端需要利用TTP来验证客户端的证书的有效性

服务端验证对客户端证书验证结果的签名，若验证不通过或客户端证书无效，则丢弃第四消息，否则再验证TTP-服务端消息鉴别码。

步骤10)当客户端收到服务端发送的服务端的完成消息后，对服务端的完成消息进行验证，若对服务端的完成消息的验证不通过，则丢弃该消息或向服务端发送警告消息，否则客户端和服务端成功建立了客户端和服务端之间的安全隧道，以及服务端和TTP成功建立了服务端和TTP之间的安全隧道。

在以上实施例1～3的增强安全性的TLS握手过程中，当客户端接收一个由服务端发送的握手消息时，若对该握手消息的验证不通过，则丢弃该消息或向服务端发送警告消息，否则接收下一个由服务端发送的握手消息或开始依次向服务端发送客户端所生成的握手消息。

在以上实施例1～3的增强安全性的TLS握手过程中，当服务端接收一个由客户端发送的握手消息时，若对该握手消息的验证不通过，则丢弃该消息或向客户端发送警告消息，否则接收下一个由客户端发送的握手消息或开始依次向客户端发送服务端所生成的握手消息。

在以上实施例1～3的增强安全性的TLS握手过程中，当客户端不需要利用TTP来验证服务端的证书的有效性时，客户端本地验证服务端的证书，若服务端的证书为无效，则客户端丢弃客户端所接收到的服务端的证书消息或向服务端发送警告消息；当客户端需要利用TTP来验证服务端的证书的有效性时，客户端利用证书验证结果消息来验证服务端的证书，若服务端的证书为无效，则客户端丢弃客户端所接收到的服务端的证书消息或向服务端发送警告消息。

在以上实施例1～3的增强安全性的TLS握手过程中，当服务端不需要利用TTP来验证客户端的证书的有效性时，服务端本地验证客户端的证书，若客户端的证书为无效，则服务端丢弃服务端所接收到的客户端的证书或向客户端发送警告消息；当服务端需要利用TTP来验证客户端的证书的有效性时，服务端利用第四消息中客户端的证书的验证结果来验证客户端的证书，若客户端的证书为无效，则中止该增强安全性的TLS握手过程或向客户端发送警告消息。

利用本发明实施例提供的TLS握手方法，具有以下优点：

除了建立客户端与服务端之间的安全隧道之外，增强安全性的TLS握手过程还可以实现客户端的证书和服务端的证书的集中验证，增强了安全性。

除了建立客户端与服务端之间的安全隧道之外，增强安全性的TLS握手过程还可以建立客户端与TTP之间的安全隧道，增强了安全性。

除了建立客户端与服务端之间的安全隧道之外，增强安全性的TLS握手过程还可以建立服务端与TTP之间的安全隧道，增强了安全性

客户端的证书和服务端的证书的集中验证、建立客户端与TTP间的安全隧道、建立服务端与TTP之间的安全隧道都是可选择的，具有很好的后向兼容性。

基于同一发明构思，本发明实施例中还提供了一种TLS握手装置及可信第三方TTP，由于这些设备解决问题的原理与一种TLS握手方法相似，因此这些设备的实施可以参见方法的实施，重复之处不再赘述。

本发明实施例提供的TLS握手装置，具体包括：

第一通知单元，用于在所述TLS握手装置作为第一方与第二方的双方TLS握手过程中，将第一方的询问和第一方所支持的密码套件列表发送给可信第三方TTP；

密钥生成单元，接收TTP通知的TTP的询问、TTP的临时公钥、TTP-第一方密码套件；利用第一方的询问、TTP的询问、第一方的临时私钥、TTP的临时公钥生成第一方与TTP间的会话密钥；

第二通知单元，用于在双方TLS握手过程中，将第一方-TTP消息鉴别码通知TTP，所述第一方-TTP消息鉴别码为利用密钥生成单元生成的第一方与TTP间的会话密钥对从TTP接收及发给TTP的信息计算的消息鉴别码；

验证单元，用于接收TTP通知的TTP-第一方消息鉴别码，在双方TLS握手过程中，利用密钥生成单元生成的第一方与TTP间的会话密钥对TTP-第一方消息鉴别码验证，若验证通过，完成与TTP间的安全隧道建立。

优选地，所述作为第一方的TLS握手装置为客户端，所述第二方为服务端；或者所述作为第一方的TLS握手装置为服务端，所述第二方为客户端。则具体的握手过程见实施例1～3的描述，这里不再重述。

本发明实施例提供的一种可信第三方TTP，包括：

第一接收单元，用于在第一方与第二方的双方TLS握手过程中，接收第一方通知的第一方将第一方的询问和第一方所支持的密码套件列表；

第一通知单元，用于基于双方TLS握手过程，将TTP的询问、TTP的临时公钥、TTP-第一方密码套件通知第一方，所述TTP-第一方密码套件为TTP从第一方所支持的密码套件列表中选取的一种TTP所支持的密码套件；

第二接收单元，用于接收第一方通知的第一方-TTP消息鉴别码；

密钥生成单元，用于在双方TLS握手过程中，获取第一方的临时公钥及第一方-TTP消息鉴别码，根据TTP的询问、第一方的询问、TTP的临时私钥及第一方的临时公钥生成第一方与TTP间的会话密钥；

鉴别单元，利用密钥生成单元生成的第一方与TTP间的会话密钥对第一方-TTP消息鉴别码验证；验证通过后，在双方TLS握手过程中，向第一方发送TTP-第一方消息鉴别码，所述TTP-第一方消息鉴别码为利用生成的第一方与TTP间的会话密钥对从第一方接收及发给第一方的信息计算的消息鉴别码。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (18)

1.一种安全传输层协议TLS握手方法，其特征在于，包括：

步骤⑴，在第一方与第二方的双方TLS握手过程中，第一方将第一方的询问和第一方所支持的密码套件列表发送给可信第三方TTP；

步骤⑵，TTP基于双方TLS握手过程，将TTP的询问、TTP的临时公钥、TTP-第一方密码套件通知第一方，所述TTP-第一方密码套件为TTP从第一方所支持的密码套件列表中选取的一种TTP所支持的密码套件；

步骤⑶，第一方利用第一方的询问、TTP的询问、第一方的临时私钥、TTP的临时公钥生成第一方与TTP间的会话密钥；在双方TLS握手过程中，第一方将第一方-TTP消息鉴别码通知TTP，所述第一方-TTP消息鉴别码为第一方利用生成的第一方与TTP间的会话密钥对从TTP接收及发给TTP的信息计算的消息鉴别码；

步骤⑷，TTP在双方TLS握手过程中，获取第一方的临时公钥及第一方-TTP消息鉴别码，根据TTP的询问、第一方的询问、TTP的临时私钥及第一方的临时公钥生成第一方与TTP间的会话密钥，利用生成的第一方与TTP间的会话密钥对第一方-TTP消息鉴别码验证；验证通过后，TTP在双方TLS握手过程中，向第一方发送TTP-第一方消息鉴别码，所述TTP-第一方消息鉴别码为TTP利用生成的第一方与TTP间的会话密钥对从第一方接收及发给第一方的信息计算的消息鉴别码；

步骤⑸，在双方TLS握手过程中，第一方利用自身生成的第一方与TTP间的会话密钥对TTP-第一方消息鉴别码验证，若验证通过，第一方完成与TTP间的安全隧道建立。

2.如权利要求1所述的方法，其特征在于，所述第一方为客户端，所述第二方为服务端，则步骤⑴具体包括：

步骤1）服务端主动发起双方TLS握手过程时，向客户端发送问候请求消息；

步骤2）客户端收到问候请求消息或主动发起双方TLS握手过程时，向服务端发送客户端问候消息，所述客户端问候消息包括客户端的询问、客户端所支持的密码套件列表；

步骤3）服务端接收客户端问候消息，向TTP发送第一消息，所述第一消息包括客户端问候消息的内容；

步骤⑵具体包括：

步骤4）TTP接收第一消息，向服务端发送第二消息，所述第二消息包括TTP的询问、TTP的临时公钥及TTP-客户端密码套件；

步骤5）服务端接收第二消息，依次向客户端发送如下握手消息：服务端问候消息、服务端的证书消息、服务端密钥交换消息、证书请求消息、TTP-客户端密钥数据交换消息、服务端问候结束消息，所述TTP-客户端密钥数据交换消息包含第二消息内容；

步骤⑶具体包括：

步骤6）客户端依次接收步骤5）中服务端发送的握手消息，依据客户端的询问、客户端的临时私钥、TTP-客户端密钥数据交换消息中TTP的询问及TTP的临时公钥，生成客户端和TTP之间的会话密钥；

客户端依次向服务端发送如下握手消息：客户端的证书消息、客户端密钥交换消息、客户端-TTP密钥交换消息、证书验证消息、客户端的完成消息，所述客户端-TTP密钥交换消息包含客户端-TTP消息鉴别码；

步骤7）服务端依次接收步骤6）中客户端发送的握手消息，向TTP发送第三消息，所述第三消息包括从客户端密钥交换消息中获取的客户端的临时公钥、从客户端-TTP密钥交换消息中获取的客户端-TTP消息鉴别码；

步骤⑷具体包括：

步骤8）TTP接收第三消息，利用TTP的询问、TTP的临时私钥、第一消息中客户端的询问、第三消息中客户端的临时公钥生成客户端与TTP间的会话密钥，TTP利用生成的客户端与TTP间的会话密钥验证第三消息中的客户端-TTP消息鉴别码，若验证通过，向服务端发送包含TTP-客户端消息鉴别码的第四消息；

步骤9）服务端接收第四消息，向客户端依次发送TTP确认消息、服务端的完成消息，所述TTP确认消息包含第四消息中的TTP-客户端消息鉴别码；

步骤⑸具体包括：

步骤10）客户端接收TTP确认消息，利用自身生成的客户端与TTP间的会话密钥验证TTP确认消息中的TTP-客户端消息鉴别码，若验证通过，接收服务端的完成消息并验证，若验证通过，完成客户端分别与TTP间和服务端间的安全隧道建立。

3.如权利要求2所述的方法，其特征在于，若服务端还需与TTP间建立安全隧道，则

步骤3）中，服务端向TTP发送的第一消息还包括服务端的询问和服务端所支持的密码套件列表；

步骤4）中，TTP向服务端发送的第二消息还包括TTP-服务端密码套件，所述TTP-服务端密码套件为TTP从第一消息的服务端所支持的密码套件列表中选择的一种TTP所支持的密码套件；

步骤7）中还包括：服务端利用服务端的询问、服务端的临时私钥、从第二消息获取的TTP的询问及TTP的临时公钥生成服务端与TTP间的会话密钥，服务端向TTP发送的第三消息还包括服务端的临时公钥、服务端-TTP消息鉴别码，所述服务端-TTP消息鉴别码为服务端利用自身生成的服务端与TTP间的会话密钥对从TTP接收及发给TTP的信息计算的消息鉴别码；

步骤8）中还包括：TTP利用TTP的询问、TTP的临时私钥、第一消息中服务端的询问、第三消息中服务端的临时公钥生成服务端与TTP间的会话密钥，TTP利用自身生成的服务端与TTP间的会话密钥验证第三消息中的服务端-TTP消息鉴别码，若验证通过，再验证客户端-TTP消息鉴别码；

TTP向服务端发送的第四消息还包括TTP-服务端消息鉴别码，所述TTP-服务端消息鉴别码为TTP利用自身生成的服务端与TTP间的会话密钥对从服务端接收及发给服务端的信息计算的消息鉴别码；

步骤9）中，服务端在向客户端发送TTP确认消息之前，还包括：服务端利用自身生成的服务端与TTP间的会话密钥，验证第四消息中的TTP-服务端消息鉴别码，若验证通过，再发送TTP确认消息。

4.如权利要求2所述的方法，其特征在于，

步骤4）中，TTP向服务端发送的第二消息，还包括对TTP利用自身的私钥对TTP的临时公钥的签名；

步骤5）中，服务端向客户端发送的TTP-客户端密钥数据交换消息，还包括所述第一消息中对TTP的临时公钥的签名；

步骤6）中还包括：客户端对TTP-客户端密钥数据交换消息中的对TTP的临时公钥的签名进行验证，若验证通过，再生成客户端与TTP间的会话密钥；

客户端向服务端发送的客户端-TTP密钥交换消息还包括：客户端利用客户端的证书所对应的私钥对客户端的临时公钥的签名；

步骤7）中，服务端向TTP发送的第三消息，还包括从客户端的证书消息中获取的客户端的证书、从客户端-TTP密钥交换消息中获取的对客户端的临时公钥的签名；

步骤8）中还包括：TTP利用第三消息中的证书，验证第三消息中对客户端的临时公钥的签名，若验证通过，再生成客户端与TTP间的会话密钥。

5.如权利要求4所述的方法，其特征在于，若服务端还需与TTP间建立安全隧道，则

步骤5）中，服务端收到第二消息后，首先对第二消息中对TTP的临时公钥的签名进行验证，若验证通过再向客户端发送各个握手消息；

步骤7）中，服务端向TTP发送的第三消息，还包括服务端利用服务端证书所对应的私钥对服务端的临时公钥的签名；

步骤8）中还包括：TTP对所述第三消息中的对服务端的临时公钥的签名进行验证，验证通过后再生成服务端与TTP间的会话密钥。

6.如权利要求3所述的方法，其特征在于，

步骤4）中，TTP向服务端发送的第二消息，还包括对TTP利用自身的私钥对TTP的临时公钥的签名；

步骤5）中，服务端向客户端发送的TTP-客户端密钥数据交换消息，还包括所述第一消息中对TTP的临时公钥的签名；

步骤6）中还包括：客户端对TTP-客户端密钥数据交换消息中的对TTP的临时公钥的签名进行验证，若验证通过，再生成客户端与TTP间的会话密钥；

客户端向服务端发送的客户端-TTP密钥交换消息还包括：客户端利用客户端的证书所对应的私钥对客户端的临时公钥的签名；

步骤7）中，服务端向TTP发送的第三消息，还包括从客户端的证书消息中获取的客户端的证书、从客户端-TTP密钥交换消息中获取的对客户端的临时公钥的签名；

步骤8）中还包括：TTP利用第三消息中的证书，验证第三消息中对客户端的临时公钥的签名，若验证通过，再生成客户端与TTP间的会话密钥。

7.如权利要求6所述的方法，其特征在于，若服务端还需与TTP间建立安全隧道，则

步骤5）中，服务端收到第二消息后，首先对第二消息中对TTP的临时公钥的签名进行验证，若验证通过再向客户端发送各个握手消息；

步骤7）中，服务端向TTP发送的第三消息，还包括服务端利用服务端证书所对应的私钥对服务端的临时公钥的签名；

步骤8）中还包括：TTP对所述第三消息中的对服务端的临时公钥的签名进行验证，验证通过后再生成服务端与TTP间的会话密钥。

8.如权利要求1所述的方法，其特征在于，所述第一方为服务端，所述第二方为客户端，则步骤⑴具体包括：

步骤1）服务端主动发起双方TLS握手过程时，向客户端发送问候请求消息；

步骤2）客户端收到问候请求消息或主动发起双发TLS握手过程时，向服务端发送客户端问候消息；

步骤3）服务端接收客户端问候消息，向TTP发送第一消息，所述第一消息包括服务端的询问和服务端所支持的密码套件列表；

步骤⑵具体包括：

步骤4）TTP接收第一消息，向服务端发送第二消息，所述第二消息包括TTP的询问、TTP的临时公钥、TTP-服务端密码套件，所述TTP-服务端密码套件为TTP从第一消息的服务端所支持的密码套件列表中选择的一种TTP所支持的密码套件；

步骤⑶具体包括：

步骤5）服务端接收第二消息，依次向客户端发送如下握手消息：服务端问候消息、服务端的证书消息、服务端密钥交换消息、证书请求消息、服务端问候结束消息；

步骤6）客户端依次接收步骤5）中服务端发送的握手消息，依次向服务端发送如下握手消息：客户端的证书消息、客户端密钥交换消息、证书验证消息、客户端的完成消息；

步骤7）服务端依次接收步骤6）中客户端发送的各握手消息，利用服务端的询问、服务端的临时私钥、从第二消息获取的TTP的询问及TTP的临时公钥生成服务端与TTP间的会话密钥；

服务端向TTP发送第三消息，第三消息包括服务端的临时公钥、服务端-TTP消息鉴别码；

步骤⑷具体包括：

步骤8）TTP接收第三消息，利用TTP的询问、TTP的临时私钥、第一消息中服务端的询问、第三消息中服务端的临时公钥生成服务端与TTP间的会话密钥，TTP利用自身生成的服务端与TTP间的会话密钥验证第三消息中的服务端-TTP消息鉴别码；若验证通过，向服务端发送包括TTP-服务端消息鉴别码的第四消息；

步骤9）服务端接收第四消息，利用自身生成的服务端与TTP间的会话密钥，验证第四消息中的TTP-服务端消息鉴别码，若验证通过，向客户端发送服务端的完成消息。

9.如权利要求8所述的方法，其特征在于，

步骤4）中，TTP向服务端发送的第二消息，还包括对TTP利用自身的私钥对TTP的临时公钥的签名；

步骤5）中，服务端收到第二消息后，首先对第二消息中对TTP的临时公钥的签名进行验证，若验证通过再向客户端发送各个握手消息；

步骤7）中，服务端向TTP发送的第三消息，还包括服务端利用服务端的证书所对应的私钥对服务端的临时公钥的签名；

步骤8）中还包括：TTP对第三消息中的对服务端的临时公钥的签名进行验证，验证通过后再生成服务端与TTP间的会话密钥。

10.如权利要求2所述的方法，其特征在于，若客户端需要利用TTP验证服务端的证书有效性，则

步骤3）中，服务端向TTP发送的第一消息至少包括客户端的询问及服务端的证书；

步骤4）中，TTP向服务端发送的第二消息还包括：从第一消息中获取的服务端的证书和客户端的询问、服务端的证书的验证结果、对服务端证书验证结果的签名，所述对服务端证书验证结果的签名为TTP利用自身的私钥对服务端的证书和客户端的询问、服务端的证书的验证结果的签名；

步骤5）中，服务端向客户端发送服务端密钥交换消息之前，还发送证书验证结果消息，所述证书验证结果消息包括第二消息中的服务端的证书、客户端的询问、服务端的证书的验证结果、对服务端证书验证结果的签名。

11.如权利要求3所述的方法，其特征在于，若客户端需要利用TTP验证服务端的证书有效性，则

步骤3）中，服务端向TTP发送的第一消息至少包括客户端的询问及服务端的证书；

步骤4）中，TTP向服务端发送的第二消息还包括：从第一消息中获取的服务端的证书和客户端的询问、服务端的证书的验证结果、对服务端证书验证结果的签名，所述对服务端证书验证结果的签名为TTP利用自身的私钥对服务端的证书和客户端的询问、服务端的证书的验证结果的签名；

步骤5）中，服务端向客户端发送服务端密钥交换消息之前，还发送证书验证结果消息，所述证书验证结果消息包括第二消息中的服务端的证书、客户端的询问、服务端的证书的验证结果、对服务端证书验证结果的签名。

12.如权利要求5所述的方法，其特征在于，若客户端需要利用TTP验证服务端的证书有效性，则

步骤3）中，服务端向TTP发送的第一消息至少包括客户端的询问及服务端的证书；

步骤4）中，TTP向服务端发送的第二消息还包括：从第一消息中获取的服务端的证书和客户端的询问、服务端的证书的验证结果、对服务端证书验证结果的签名，所述对服务端证书验证结果的签名为TTP利用自身的私钥对服务端的证书和客户端的询问、服务端的证书的验证结果的签名；

步骤5）中，服务端向客户端发送服务端密钥交换消息之前，还发送证书验证结果消息，所述证书验证结果消息包括第二消息中的服务端的证书、客户端的询问、服务端的证书的验证结果、对服务端证书验证结果的签名。

13.如权利要求7所述的方法，其特征在于，若客户端需要利用TTP验证服务端的证书有效性，则

步骤3）中，服务端向TTP发送的第一消息至少包括客户端的询问及服务端的证书；

步骤4）中，TTP向服务端发送的第二消息还包括：从第一消息中获取的服务端的证书和客户端的询问、服务端的证书的验证结果、对服务端证书验证结果的签名，所述对服务端证书验证结果的签名为TTP利用自身的私钥对服务端的证书和客户端的询问、服务端的证书的验证结果的签名；

步骤5）中，服务端向客户端发送服务端密钥交换消息之前，还发送证书验证结果消息，所述证书验证结果消息包括第二消息中的服务端的证书、客户端的询问、服务端的证书的验证结果、对服务端证书验证结果的签名。

14.如权利要求2、3、5、7、10～13任一所述的方法，其特征在于，若服务端需要利用TTP验证客户端的证书有效性，则

步骤7）中，服务端向TTP发送的第三消息至少包括服务端的询问及客户端的证书；

步骤8）中，TTP发送的第四消息还包括：从第三消息中获取的服务端的询问和客户端的证书、客户端的证书的验证结果、对客户端证书验证结果的签名，所述对客户端证书验证结果的签名为TTP利用自身的私钥对服务端的询问和客户端的证书、客户端的证书的验证结果的签名；

步骤9）中还包括：对第四消息中的对客户端证书验证结果的签名进行验证，若验证通过且客户端证书有效，再发送TTP确认消息、服务端的完成消息。

15.如权利要求10～13任一所述的方法，其特征在于，

步骤2）中，客户端在发送客户端问候消息后，还依次发送客户端请求标识消息和客户端问候结束消息，所述客户端请求标识消息用于标识客户端是否需要利用TTP验证服务端的证书有效性，及客户端是否需要与TTP间建立安全隧道；

步骤3）中，服务端具体根据客户端请求标识消息，确定客户端是否需要利用TTP验证服务端的证书有效性，及客户端是否需要与TTP间建立安全隧道。

16.一种TLS握手装置，其特征在于，包括：

第一通知单元，用于在所述TLS握手装置作为第一方与第二方的双方TLS握手过程中，将第一方的询问和第一方所支持的密码套件列表发送给可信第三方TTP；

密钥生成单元，接收TTP通知的TTP的询问、TTP的临时公钥、TTP-第一方密码套件；利用第一方的询问、TTP的询问、第一方的临时私钥、TTP的临时公钥生成第一方与TTP间的会话密钥；

第二通知单元，用于在双方TLS握手过程中，将第一方-TTP消息鉴别码通知TTP，所述第一方-TTP消息鉴别码为利用密钥生成单元生成的第一方与TTP间的会话密钥对从TTP接收及发给TTP的信息计算的消息鉴别码；

验证单元，用于接收TTP通知的TTP-第一方消息鉴别码，在双方TLS握手过程中，利用密钥生成单元生成的第一方与TTP间的会话密钥对TTP-第一方消息鉴别码验证，若验证通过，完成与TTP间的安全隧道建立。

17.如权利要求16所述的装置，其特征在于，所述作为第一方的TLS握手装置为客户端，所述第二方为服务端；或者

所述作为第一方的TLS握手装置为服务端，所述第二方为客户端。

18.一种可信第三方TTP，其特征在于，包括：

第一接收单元，用于在第一方与第二方的双方TLS握手过程中，接收第一方通知的第一方将第一方的询问和第一方所支持的密码套件列表；

第一通知单元，用于基于双方TLS握手过程，将TTP的询问、TTP的临时公钥、TTP-第一方密码套件通知第一方，所述TTP-第一方密码套件为TTP从第一方所支持的密码套件列表中选取的一种TTP所支持的密码套件；

第二接收单元，用于接收第一方通知的第一方-TTP消息鉴别码；

密钥生成单元，用于在双方TLS握手过程中，获取第一方的临时公钥及第一方-TTP消息鉴别码，根据TTP的询问、第一方的询问、TTP的临时私钥及第一方的临时公钥生成第一方与TTP间的会话密钥；

鉴别单元，利用密钥生成单元生成的第一方与TTP间的会话密钥对第一方-TTP消息鉴别码验证；验证通过后，在双方TLS握手过程中，向第一方发送TTP-第一方消息鉴别码，所述TTP-第一方消息鉴别码为利用生成的第一方与TTP间的会话密钥对从第一方接收及发给第一方的信息计算的消息鉴别码。

Images