一种安全传输层协议 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、 光学存储器等 ) 上实施的计算机程序产 品的形式。
本发明是参照根据本发明实施例的方法、 设备 ( 系统 )、 和计算机程序产品的流程 图和 / 或方框图来描述的。应理解可由计算机程序指令实现流程图和 / 或方框图中的每一 流程和 / 或方框、 以及流程图和 / 或方框图中的流程和 / 或方框的结合。可提供这些计算 机程序指令到通用计算机、 专用计算机、 嵌入式处理机或其他可编程数据处理设备的处理 器以产生一个机器， 使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生 用于实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能 的装置。 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特 定方式工作的计算机可读存储器中， 使得存储在该计算机可读存储器中的指令产生包括指 令装置的制造品， 该指令装置实现在流程图一个流程或多个流程和 / 或方框图一个方框或 多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上， 使得在计 算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理， 从而在计算机或 其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和 / 或方框图 一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例， 但本领域内的技术人员一旦得知了基本创造 性概念， 则可对这些实施例作出另外的变更和修改。 所以， 所附权利要求意欲解释为包括优 选实施例以及落入本发明范围的所有变更和修改。
显然， 本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精 神和范围。这样， 倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围 之内， 则本发明也意图包含这些改动和变型在内。