一種安全傳輸層協議tls握手方法和裝置及ttp的製作方法

2023-05-30 01:39:11

專利名稱：一種安全傳輸層協議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握手過程時，服務端向客戶端發送①問候請求消肩、ο步驟i)當客戶端收到服務端發送的問候請求消息、或客戶端主動發起TLS握手過程時，向服務端發送②客戶端問候消息，包含客戶端的詢問、客戶端所支持的密碼套件列表，其中客戶端的詢問為客戶端產生的一個隨機數。步驟3)服務端收到客戶端發送的客戶端問候消息後，依次向客戶端發送如下消息③服務端問候消息，包含服務端的詢問，及服務端從客戶端問候消息中選擇的一種服務端所支持的密碼套件，服務端的詢問為服務端產生的一個隨機數；④服務端的證書消息，包含服務端的證書；⑤服務端密鑰交換消息，包含服務端的臨時公鑰、服務端利用服務端的證書所對應的私鑰對服務端的臨時公鑰的籤名；⑥證書請求消息，包含服務端的證書請求信息；⑦服務端問候結束消息，表示消息發送過程結束。步驟4)客戶端首先依次接收服務端發送的消息③ ⑦，然後依次向服務端發送如下消息④』客戶端的證書消息，包含客戶端的證書；⑧客戶端密鑰交換消息，包含客戶端的臨時公鑰；⑨證書驗證消息，包含客戶端利用客戶端的證書所對應的私鑰對消息②、③ ⑦、④』、⑧的籤名；⑩』客戶端的完成消息，包含客戶端利用客戶端所生成的客戶端和服務端之間的會話密鑰對消息②、③ ⑦、④』、⑧、⑨計算的消息鑑別碼，客戶端所生成的客戶端和服務端之間的會話密鑰是客戶端依據客戶端的詢問、服務端的詢問(從③中獲取)、客戶端的臨時私鑰、服務端的臨時公鑰(從⑤中獲取)所生成的客戶端和服務端之間的會話密鑰。其中，客戶端會根據④中的服務端的證書對⑤中的籤名進行驗證，根據⑥證書請求消息發送④』客戶端的證書消息。步驟幻服務端首先依次接收客戶端發送的④』、⑧、⑨、⑩』，然後向客戶端發送⑩ 服務端的完成消息，該消息包含服務端利用服務端所生成的客戶端和服務端之間的會話密鑰對②、③ ⑦、④』、⑧、⑨、⑩』計算的消息鑑別碼，服務端所生成的客戶端和服務端之間的會話密鑰是服務端依據客戶端的詢問(從②中獲取)、服務端的詢問、客戶端的臨時公鑰 (從⑧中獲取)、服務端的臨時私鑰生成客戶端和服務端之間的會話密鑰。其中，服務端會根據④』中客戶端的證書對⑨中的籤名進行驗證。服務端會利用自身生成的會話密鑰對⑩』 的消息鑑別碼驗證；步驟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 間的會話密鑰；第二通知單元，用於在雙方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、圖北為本發明實施例3中TLS握手方法示意圖。
具體實施例方式下面結合附圖和實施例對本發明提供的TLS握手方法和裝置及TTP進行更詳細地說明。現有的雙方TLS握手過程是一個點對點的協議過程，不適用於可信第三方在線的應用場景，也就是說不能利用可信第三方來增強TLS握手過程的安全性，鑑於此，本發明實施例提供一種安全傳輸層協議TLS握手方法，包括步驟(1)，在第一方與第二方的雙方TLS握手過程中，第一方將第一方的詢問和第一方所支持的密碼套件列表發送給可信第三方TTP ；第一方的詢問為第一方產生的一個隨機數。步驟⑵，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-第一方消息鑑別碼外的所有 fn息ο步驟(5)，在雙方TLS握手過程中，第一方利用自身生成的第一方與TTP間的會話密鑰對TTP-第一方消息鑑別碼驗證，若驗證通過，第一方完成與TTP間的安全隧道建立。本發明實施例提供的TLS握手方法，基於雙方TLS握手過程建立了其中一方與可信第三方之間的安全隧道，因此適用於可信第三方在線的應用場景，從而能夠利用可信第三方來增強TLS握手過程的安全性，本發明實施例提供的方法由於是在雙方TLS握手過程基礎上實現的，因此具有很好的後向兼容性。上述雙方TLS握手過程為現有的TLS握手過程，具體握手過程這裡不做限定。優選地，上述第一方為客戶端，第二方為服務端，或者，上述第一方為服務端，第二方為客戶端。下面以本發明實施例在背景技術描述的TLS握手過程中實現的TLS握手方法，由於本發明實施例提供的TLS握手方法增強了安全性，本文稱為增強安全性的TLS握手過程。實施例1本實施例中第一方為客戶端，第二方為服務端，本實施例提供的TLS握手方法能夠在現有雙方TLS握手過程中，在客戶端與TTP間建立安全隧道。如圖加所示，本實施例中的TLS握手方法具體包括如下步驟步驟1)當服務端主動發起雙方TLS握手過程時，服務端向客戶端發送①問候請求消息。步驟2、客戶端收到問候請求消息或主動發起雙方TLS握手過程時，向服務端發送②客戶端問候消息，所述客戶端問候消息包括客戶端的詢問、客戶端所支持的密碼套件列表，客戶端的詢問為客戶端產生的一個隨機數；優選地，為了實現標識客戶端是否需要建立與TTP間安全隧道，及是否需要驗證服務端的證書有效性，客戶端具體可以依次向服務端發送如下握手消息②客戶端問候消息；(11)客戶端請求標識消息(ClientRequestFlag)，用於標識客戶端是否需要利用TTP來驗證服務端的證書的有效性，以及顯示客戶端是否需要建立與TTP之間的安全隧道；(12) 客戶端問候結束消息(ClientHelloDone)，用於指示客戶端已發送消息，可以接收服務端發送的消息，即切換為「接收消息」的狀態。步驟幻服務端依次接收客戶端發送的各握手消息，然後執行如下步驟步驟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)客戶端首先依次接收步驟幻中服務端向客戶端所發送的各個握手消息， 依據客戶端的詢問、客戶端的臨時私鑰、TTP-客戶端密鑰數據交換消息中TTP的詢問及TTP 的臨時公鑰，生成客戶端和TTP之間的會話密鑰；若接收到證書驗證結果消息，客戶端對證書驗證結果消息中的對服務端證書驗證結果的籤名進行驗證，若驗證通過且服務端證書有效時，客戶端依次向服務端發送如下握手消息④』客戶端的證書消息、⑧客戶端密鑰交換消息、(13)，客戶端-TTP密鑰交換消息、 ⑨證書驗證消息、⑩』客戶端的完成消息，所述客戶端-TTP密鑰交換消息包含客戶端-TTP 消息鑑別碼，客戶端-TTP消息鑑別碼為客戶端對之前發給TTP所有信息、之前從TTP接收所有信息、當前發給TTP的除客戶端-TTP消息鑑別碼外的所有信息計算的消息鑑別碼。優選地，若TTP-客戶端密鑰數據交換消息包括對TTP的臨時公鑰的籤名，則首先對該籤名進行驗證，若驗證通過，再生成客戶端和TTP之間的會話密鑰。上述消息④』、⑧、 ⑨、⑩』的內容同現有技術，具體如下
④』客戶端的證書消息，包含客戶端的證書；⑧客戶端密鑰交換消息，包含客戶端的臨時公鑰；⑨證書驗證消息，包含客戶端利用客戶端的證書所對應的私鑰對發給服務端及從服務端接收信息的籤名，即對步驟2)中客戶端向服務端所發送的各個握手消息、步驟5)中服務端向客戶端所發送的各個握手消息、④』客戶端的證書消息、⑧客戶端密鑰交換消息、 (13)，客戶端-TTP密鑰交換消息的籤名；⑩』客戶端的完成消息，包含客戶端利用客戶端所生成的客戶端和服務端之間的會話密鑰對發給服務端及從服務端接收的信息計算的消息鑑別碼，即對步驟2、中客戶端向服務端所發送的各個握手消息、步驟幻中服務端向客戶端所發送的各個握手消息、④』客戶端的證書消息、⑧客戶端密鑰交換消息、(13)，客戶端-TTP密鑰交換消息、⑨證書驗證消息計算的消息鑑別碼。具體地，客戶端依據客戶端的詢問、從服務端問候消息獲取服務端的詢問、客戶端的臨時私鑰、從服務端密鑰交換消息獲取的服務端的臨時公鑰生成客戶端與服務端間的會話S朗ο優選地，為了進一步增強安全性，上述(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-客戶端消息鑑別碼，服務端的完成消息具體同現有技術，即包含服務端利用服務端所生成的客戶端和服務端之間的會話密鑰對步驟幻中客戶端向服務端所發送的握手消息、步驟幻中服務端向客戶端所發送的各個握手消息、步驟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) 客戶端問候結束消息(Cl ientHe 11 oDone)步驟；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利用自己的私鑰對客戶端的詢問、服務端的證書、服務端的證書的驗證結果的籤名。步驟幻服務端收到TTP發送的第二消息後的處理同實施例1，優選地，為進一步增強安全性，服務端收到第二消息後，還包括對第二消息中對TTP的臨時公鑰的籤名進行驗證，若驗證通過再向客戶端發送各個握手消息。即執行步驟51)當客戶端不需要利用TTP來驗證服務端的證書的有效性對第二消息中對TTP的臨時公鑰的籤名進行驗證，若驗證通過，依次向客戶端發送如下握手消息③服務端問候消息、④服務端的證書消息、⑤服務端密鑰交換消息、⑥證書請求消息、(13)TTP-客戶端密鑰數據交換消息、⑦服務端問候結束消息，所述TTP-客戶端密鑰數據交換消息包含第二消息內容，即包含從第二消息中獲取的TTP的詢問、TTP-客戶端密碼套件、TTP的臨時公鑰，優選地，還包括對TTP的臨時公鑰的籤名。步驟52)當客戶端需要利用TTP來驗證服務端的證書的有效性時對第二消息中對TTP的臨時公鑰的籤名進行驗證，若驗證通過，依次向客戶端發送如下握手消息③服務端問候消息；④服務端的證書消息；(14)證書驗證結果消息，包含從第二消息中獲取的客戶端的詢問、服務端的證書、服務端的證書的驗證結果、對服務端證書驗證結果的籤名；⑤服務端密鑰交換消息；⑥證書請求消息；(13)TTP-客戶端密鑰數據交換消息；⑦服務端問候結束消息。除(14)外其它消息的內容同步驟51)中描述。步驟6)客戶端首先依次接收步驟幻中服務端向客戶端所發送的各個握手消息， 之後的處理同實施例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間的會話密鑰。即具體執行如下步驟步驟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)。步驟幻服務端依次接收客戶端發送的各握手消息，然後執行如下步驟步驟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利用自己的私鑰對客戶端的詢問、服務端的證書、服務端的證書的驗證結果的籤名。步驟幻服務端收到TTP的第二消息後，執行如下步驟步驟51)若客戶端不需要利用TTP來驗證服務端的證書的有效性依次向客戶端發送如下握手消息③服務端問候消息、④服務端的證書消息、⑤服務端密鑰交換消息、⑥證書請求消息、⑦服務端問候結束消息。上述消息③ ⑦的內容定義同現有的消息內容定義，具體見實施例1的描述，這裡不再重述。優選地，服務端收到第二消息後，首先對第二消息中對TTP的臨時公鑰的籤名進行驗證，若驗證不通過，則丟棄第二消息，若驗證通過再向客戶端發送各個握手消息。步驟52)若客戶端需要利用TTP來驗證服務端的證書的有效性如圖3b，依次向客戶端發送如下握手消息③服務端問候消息；④服務端的證書消息；(14)證書驗證結果消息，包含從第二消息中獲取的客戶端的詢問、服務端的證書、月艮務端的證書的驗證結果、對服務端證書驗證結果的籤名；⑤服務端密鑰交換消息；⑥證書請求消息；⑦服務端問候結束消息。除(14)外其它消息的內容同步驟51)中描述優選地，服務端收到第二消息後，首先對第二消息中對TTP的臨時公鑰的籤名進行驗證，若驗證不通過，則丟棄第二消息，若驗證通過再向客戶端發送各個握手消息。步驟6)客戶端首先依次接收步驟幻中服務端向客戶端所發送的各個握手消息， 若接收到證書驗證結果消息，客戶端對證書驗證結果消息中的對服務端證書驗證結果的籤名進行驗證，若驗證通過且服務端證書有效時，依次向服務端發送如下握手消息④』客戶端的證書消息、⑧客戶端密鑰交換消息、⑨證書驗證消息、⑩』客戶端的完成消息，上述消息 ④』、⑧、⑨、⑩』的內容同現有技術，具體如下④』客戶端的證書消息，包含客戶端的證書；⑧客戶端密鑰交換消息，包含客戶端的臨時公鑰；⑨證書驗證消息，包含客戶端利用客戶端的證書所對應的私鑰對步驟2)中客戶端向服務端所發送的各個握手消息、步驟幻中服務端向客戶端所發送的各個握手消息、客戶端的證書消息、客戶端密鑰交換消息的籤名；⑩』客戶端的完成消息，包含客戶端利用客戶端所生成的客戶端和服務端之間的會話密鑰對步驟幻中客戶端向服務端所發送的各個握手消息、步驟幻中服務端向客戶端所發送的各個握手消息、客戶端的證書消息、客戶端密鑰交換消息、證書驗證消息計算的消息鑑別碼。客戶端所生成的客戶端和服務端之間的會話密鑰，客戶端依據客戶端的詢問、從服務端問候消息獲取服務端的詢問、客戶端的臨時私鑰、從服務端密鑰交換消息獲取的服務端的臨時公鑰生成客戶端與服務端間的會話密鑰。步驟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間的會話密鑰。步驟82)若服務端需要利用TTP來驗證客戶端的證書的有效性，則驗證客戶端-TTP消息鑑別碼通過後，在發送(四)第四消息之前，還包括生成客戶端的證書的驗證結果和對客戶端證書驗證結果的籤名，然後向服務端發送(四)第四消息，第四消息除了包括上述TTP-客戶端消息鑑別碼，還包括服務端的詢問、客戶端的證書、客戶端的證書的驗證結果、對客戶端證書驗證結果的籤名，其中對客戶端證書驗證結果的籤名是TTP利用自己的私鑰對服務端的詢問、客戶端的證書、客戶端的證書的驗證結果的籤名。具體地，TTP-服務端消息鑑別碼是TTP利用TTP所生成的服務端和TTP之間的會話密鑰對第一消息、第二消息、第三消息、第四消息中除TTP-服務端消息鑑別碼外所有信息計算的消息鑑別碼。步驟9)服務端收到TTP發送的第四消息後，執行如下步驟步驟91)服務端不需要利用TTP來驗證客戶端的證書的有效性服務端利用自身生成的服務端與TTP間的會話密鑰，驗證第四消息中的TTP-服務端消息鑑別碼，若驗證不通過，則丟棄第四消息，否則向客戶端發送⑩服務端的完成消息， 服務端的完成消息具體同現有技術，即包含服務端利用服務端所生成的客戶端和服務端之間的會話密鑰對步驟幻中客戶端向服務端所發送的各個握手消息、步驟幻中服務端向客戶端所發送的各個握手消息、步驟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、光學存儲器等)上實施的電腦程式產品的形式。本發明是參照根據本發明實施例的方法、設備(系統)、和電腦程式產品的流程圖和/或方框圖來描述的。應理解可由電腦程式指令實現流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合。可提供這些電腦程式指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數據處理設備的處理器以產生一個機器，使得通過計算機或其他可編程數據處理設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。這些電腦程式指令也可存儲在能引導計算機或其他可編程數據處理設備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產生包括指令裝置的製造品，該指令裝置實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。這些電腦程式指令也可裝載到計算機或其他可編程數據處理設備上，使得在計算機或其他可編程設備上執行一系列操作步驟以產生計算機實現的處理，從而在計算機或其他可編程設備上執行的指令提供用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。儘管已描述了本發明的優選實施例，但本領域內的技術人員一旦得知了基本創造性概念，則可對這些實施例作出另外的變更和修改。所以，所附權利要求意欲解釋為包括優選實施例以及落入本發明範圍的所有變更和修改。顯然，本領域的技術人員可以對本發明進行各種改動和變型而不脫離本發明的精神和範圍。這樣，倘若本發明的這些修改和變型屬於本發明權利要求及其等同技術的範圍之內，則本發明也意圖包含這些改動和變型在內。
權利要求
1.一種安全傳輸層協議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間的安全隧道建立。
2.如權利要求1所述的方法，其特徵在於，所述第一方為客戶端，所述第二方為服務端，則步驟(1)具體包括步驟1)服務端主動發起雙方TLS握手過程時，向客戶端發送問候請求消息； 步驟幻客戶端收到問候請求消息或主動發起雙方TLS握手過程時，向服務端發送客戶端問候消息，所述客戶端問候消息包括客戶端的詢問、客戶端所支持的密碼套件列表；步驟3)服務端接收客戶端問候消息，向TTP發送第一消息，所述第一消息包括客戶端問候消息的內容；步驟( 具體包括步驟4)TTP接收第一消息，向服務端發送第二消息，所述第二消息包括TTP的詢問、TTP 的臨時公鑰及TTP-客戶端密碼套件；步驟5)服務端接收第二消息，依次向客戶端發送如下握手消息服務端問候消息、服務端的證書消息、服務端密鑰交換消息、證書請求消息、TTP-客戶端密鑰數據交換消息、服務端問候結束消息，所述TTP-客戶端密鑰數據交換消息包含第二消息內容； 步驟( 具體包括步驟6)客戶端依次接收步驟幻中服務端發送的握手消息，依據客戶端的詢問、客戶端的臨時私鑰、TTP-客戶端密鑰數據交換消息中TTP的詢問及TTP的臨時公鑰，生成客戶端和TTP之間的會話密鑰；客戶端依次向服務端發送如下握手消息客戶端的證書消息、客戶端密鑰交換消息、客戶端-TTP密鑰交換消息、證書驗證消息、客戶端的完成消息，所述客戶端-TTP密鑰交換消息包含客戶端-TTP消息鑑別碼；步驟7)服務端依次接收步驟6)中客戶端發送的握手消息，向TTP發送第三消息，所述第三消息包括從客戶端密鑰交換消息中獲取的客戶端的臨時公鑰、從客戶端-TTP密鑰交換消息中獲取的客戶端-TTP消息鑑別碼；步驟(4)具體包括步驟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或3所述的方法，其特徵在於，步驟4)中，TTP向服務端發送的第二消息，還包括對TTP利用自身的私鑰對TTP的臨時公鑰的籤名；步驟幻中，服務端向客戶端發送的TTP-客戶端密鑰數據交換消息，還包括所述第一消息中對TTP的臨時公鑰的籤名；步驟6)中還包括客戶端對TTP-客戶端密鑰數據交換消息中的對TTP的臨時公鑰的籤名進行驗證，若驗證通過，再生成客戶端與TTP間的會話密鑰；客戶端向服務端發送的客戶端-TTP密鑰交換消息還包括客戶端利用客戶端的證書所對應的私鑰對客戶端的臨時公鑰的籤名；步驟7)中，服務端向TTP發送的第三消息，還包括從客戶端的證書消息中獲取的客戶端的證書、從客戶端-TTP密鑰交換消息中獲取的對客戶端的臨時公鑰的籤名；步驟8)中還包括TTP利用第三消息中的證書，驗證第三消息中對客戶端的臨時公鑰的籤名，若驗證通過，再生成客戶端與TTP間的會話密鑰。
5.如權利要求4所述的方法，其特徵在於，若服務端還需與TTP間建立安全隧道，則步驟5)中，服務端收到第二消息後，首先對第二消息中對TTP的臨時公鑰的籤名進行驗證，若驗證通過再向客戶端發送各個握手消息；步驟7)中，服務端向TTP發送的第三消息，還包括服務端利用服務端證書所對應的私鑰對服務端的臨時公鑰的籤名；步驟8)中還包括ΤΤΡ對所述第三消息中的對服務端的臨時公鑰的籤名進行驗證，驗證通過後再生成服務端與TTP間的會話密鑰。
6.如權利要求1所述的方法，其特徵在於，所述第一方為服務端，所述第二方為客戶端，則步驟(1)具體包括步驟1)服務端主動發起雙方TLS握手過程時，向客戶端發送問候請求消息； 步驟幻客戶端收到問候請求消息或主動發起雙發TLS握手過程時，向服務端發送客戶端問候消息；步驟3)服務端接收客戶端問候消息，向TTP發送第一消息，所述第一消息包括服務端的詢問和服務端所支持的密碼套件列表； 步驟( 具體包括步驟4)TTP接收第一消息，向服務端發送第二消息，所述第二消息包括TTP的詢問、TTP 的臨時公鑰、TTP-服務端密碼套件，所述TTP-服務端密碼套件為TTP從第一消息的服務端所支持的密碼套件列表中選擇的一種TTP所支持的密碼套件； 步驟( 具體包括步驟5)服務端接收第二消息，依次向客戶端發送如下握手消息服務端問候消息、服務端的證書消息、服務端密鑰交換消息、證書請求消息、服務端問候結束消息；步驟6)客戶端依次接收步驟幻中服務端發送的握手消息，依次向服務端發送如下握手消息客戶端的證書消息、客戶端密鑰交換消息、證書驗證消息、客戶端的完成消息；步驟7)服務端依次接收步驟6)中客戶端發送的各握手消息，利用服務端的詢問、服務端的臨時私鑰、從第二消息獲取的TTP的詢問及TTP的臨時公鑰生成服務端與TTP間的會話密鑰；服務端向TTP發送第三消息，第三消息包括服務端的臨時公鑰、服務端-TTP消息鑑別碼；步驟(4)具體包括步驟8)TTP接收第三消息，利用TTP的詢問、TTP的臨時私鑰、第一消息中服務端的詢問、第三消息中服務端的臨時公鑰生成服務端與TTP間的會話密鑰，TTP利用自身生成的服務端與TTP間的會話密鑰驗證第三消息中的服務端-TTP消息鑑別碼；若驗證通過，向服務端發送包括TTP-服務端消息鑑別碼的第四消息；步驟9)服務端接收第四消息，利用自身生成的服務端與TTP間的會話密鑰，驗證第四消息中的TTP-服務端消息鑑別碼，若驗證通過，向客戶端發送服務端的完成消息。
7.如權利要求6所述的方法，其特徵在於，步驟4)中，TTP向服務端發送的第二消息，還包括對TTP利用自身的私鑰對TTP的臨時公鑰的籤名；步驟5)中，服務端收到第二消息後，首先對第二消息中對TTP的臨時公鑰的籤名進行驗證，若驗證通過再向客戶端發送各個握手消息；步驟7)中，服務端向TTP發送的第三消息，還包括服務端利用服務端的證書所對應的私鑰對服務端的臨時公鑰的籤名；步驟8)中還包括TTP對第三消息中的對服務端的臨時公鑰的籤名進行驗證，驗證通過後再生成服務端與TTP間的會話密鑰。
8.如權利要求2或3或5所述的方法，其特徵在於，若客戶端需要利用TTP驗證服務端的證書有效性，則步驟3)中，服務端向TTP發送的第一消息至少包括客戶端的詢問及服務端的證書； 步驟4)中，TTP向服務端發送的第二消息還包括從第一消息中獲取的服務端的證書和客戶端的詢問、服務端的證書的驗證結果、對服務端證書驗證結果的籤名，所述對服務端證書驗證結果的籤名為TTP利用自身的私鑰對服務端的證書和客戶端的詢問、服務端的證書的驗證結果的籤名；步驟5)中，服務端向客戶端發送服務端密鑰交換消息之前，還發送證書驗證結果消息，所述證書驗證結果消息包括第二消息中的服務端的證書、客戶端的詢問、服務端的證書的驗證結果、對服務端證書驗證結果的籤名。
9.如權利要求2或3或5或8所述的方法，其特徵在於，若服務端需要利用TTP驗證客戶端的證書有效性，則步驟7)中，服務端向TTP發送的第三消息至少包括服務端的詢問及客戶端的證書； 步驟8)中，TTP發送的第四消息還包括從第三消息中獲取的服務端的詢問和客戶端的證書、客戶端的證書的驗證結果、對客戶端證書驗證結果的籤名，所述對客戶端證書驗證結果的籤名為TTP利用自身的私鑰對服務端的詢問和客戶端的證書、客戶端的證書的驗證結果的籤名；步驟9)中還包括對第四消息中的對客戶端證書驗證結果的籤名進行驗證，若驗證通過且客戶端證書有效，再發送TTP確認消息、服務端的完成消息。
10.如權利要求8所述的方法，其特徵在於，步驟2、中，客戶端在發送客戶端問候消息後，還依次發送客戶端請求標識消息和客戶端問候結束消息，所述客戶端請求標識消息用於標識客戶端是否需要利用TTP驗證服務端的證書有效性，及客戶端是否需要與TTP間建立安全隧道；步驟3)中，服務端具體根據客戶端請求標識消息，確定客戶端是否需要利用TTP驗證服務端的證書有效性，及客戶端是否需要與TTP間建立安全隧道。
11.一種TLS握手裝置，其特徵在於，包括第一通知單元，用於在所述TLS握手裝置作為第一方與第二方的雙方TLS握手過程中， 將第一方的詢問和第一方所支持的密碼套件列表發送給可信第三方TTP ；密鑰生成單元，接收TTP通知的TTP的詢問、TTP的臨時公鑰、TTP-第一方密碼套件； 利用第一方的詢問、TTP的詢問、第一方的臨時私鑰、TTP的臨時公鑰生成第一方與TTP間的會話密鑰；第二通知單元，用於在雙方TLS握手過程中，將第一方-TTP消息鑑別碼通知TTP，所述第一方-TTP消息鑑別碼為利用密鑰生成單元生成的第一方與TTP間的會話密鑰對從TTP 接收及發給TTP的信息計算的消息鑑別碼；驗證單元，用於接收TTP通知的TTP-第一方消息鑑別碼，在雙方TLS握手過程中，利用密鑰生成單元生成的第一方與TTP間的會話密鑰對TTP-第一方消息鑑別碼驗證，若驗證通過，完成與TTP間的安全隧道建立。
12.如權利要求11所述的裝置，其特徵在於，所述作為第一方的TLS握手裝置為客戶端，所述第二方為服務端；或者所述作為第一方的TLS握手裝置為服務端，所述第二方為客戶端。
13.一種可信第三方TTP，其特徵在於，包括第一接收單元，用於在第一方與第二方的雙方TLS握手過程中，接收第一方通知的第一方將第一方的詢問和第一方所支持的密碼套件列表；第一通知單元，用於基於雙方TLS握手過程，將TTP的詢問、TTP的臨時公鑰、TTP-第一方密碼套件通知第一方，所述TTP-第一方密碼套件為TTP從第一方所支持的密碼套件列表中選取的一種TTP所支持的密碼套件；第二接收單元，用於接收第一方通知的第一方-TTP消息鑑別碼； 密鑰生成單元，用於在雙方TLS握手過程中，獲取第一方的臨時公鑰及第一方-TTP消息鑑別碼，根據TTP的詢問、第一方的詢問、TTP的臨時私鑰及第一方的臨時公鑰生成第一方與TTP間的會話密鑰；鑑別單元，利用密鑰生成單元生成的第一方與TTP間的會話密鑰對第一方-TTP消息鑑別碼驗證；驗證通過後，在雙方TLS握手過程中，向第一方發送TTP-第一方消息鑑別碼，所述TTP-第一方消息鑑別碼為利用生成的第一方與TTP間的會話密鑰對從第一方接收及發給第一方的信息計算的消息鑑別碼。
全文摘要
本發明公開了一種TLS握手方法和裝置及TTP，該方法基於雙方TLS握手過程，第一方將第一方的詢問和第一方所支持的密碼套件列表發送給TTP；TTP基於將TTP的詢問、TTP的臨時公鑰、TTP-第一方密碼套件通知第一方；第一方利用生成的與TTP間的會話密鑰將第一方-TTP消息鑑別碼通知TTP；TTP利用生成的與第一方間的會話密鑰對第一方-TTP消息鑑別碼驗證；驗證通過後，向第一方發送TTP-第一方消息鑑別碼；第一方利用對TTP-第一方消息鑑別碼驗證，若驗證通過，第一方完成與TTP間的安全隧道建立。本發明基於雙方TLS握手方法與TTP間建立安全隧道，提高了安全性且具有很好的後向兼容性。
文檔編號H04L29/06GK102510387SQ20111045205
公開日2012年6月20日 申請日期2011年12月29日 優先權日2011年12月29日
發明者侯宇, 張國強, 曹軍, 肖躍雷, 鐵滿霞 申請人:西安西電捷通無線網絡通信股份有限公司