1.6 密碼協議

保障信息的安全不能單純依靠安全的密碼算法，還需要通過安全的密碼協議在實體之間安全地分配密鑰或其他秘密信息，以及進行實體之間的鑒別等。密碼協議是指兩個或兩個以上參與者使用密碼算法時，為達到加密保護或安全認證目的而約定的交互規則。

本節首先介紹密鑰交換協議，然后結合國家標準GB/T 15843介紹實體鑒別協議，最后，介紹兩個較為綜合的密碼協議實例——IPSec和SSL協議。

1.6.1 密鑰交換協議

在使用對稱密碼進行保密通信之前，必須向通信雙方分發密鑰使得雙方共享密鑰。然而在公鑰密碼出現之前通信雙方建立共享密鑰是一個困難問題。相對于對稱密碼，公鑰密碼的一個優點就是可以在不安全的信道上進行密鑰交換。密鑰交換協議旨在讓兩方或者多方在不安全的信道上協商會話密鑰，從而建立安全的通信信道。

1．Di?e-Hellman密鑰交換協議

1976年Di?e和Hellman提出公鑰密碼學概念，并提出了著名的Di?e-Hellman密鑰交換協議。經典的Di?e-Hellman密鑰交換協議運算在有限循環群上。該協議在初始化階段選擇大素數p，令g為模p乘法群的生成元，并公開參數p和g。用戶A和用戶B之間的Di?e-Hellman密鑰交換協議如圖1-21所示。

①用戶A隨機選擇，計算X=gxmod p，并將X發送給用戶B；

②用戶B隨機選擇，計算Y=gymod p，并將Y發送給用戶A；

③用戶A計算k=Yxmod p為會話密鑰；

④用戶B計算k=Xymod p為會話密鑰。

然而，Di?e-Hellman密鑰交換協議只能提供建立會話密鑰的功能，并不能抵抗中間人攻擊，同時也不能提供相互鑒別的安全保障。在具有鑒別功能的密鑰交換協議中，Menezes等人在1995年給出的MQV方案最具代表性。

2．MQV密鑰交換協議

在經典Di?e-Hellman密鑰交換協議的基礎上，MQV密鑰交換協議在協議交互過程中用到了雙方公鑰信息，只有擁有相應私鑰的用戶才能計算出與對方相同的會話密鑰，從而達到隱式鑒別的效果?；谛史矫娴目紤]，MQV選擇了橢圓曲線加法群作為基本的計算群。令點G為加法群的生成元，點G的階為n。用戶A的公鑰為點PA=dAG，私鑰為dA；用戶B的公鑰為點PB=dBG，私鑰為dB。每一個用戶選擇隨機數，計算并發送臨時的消息給對方（具體地，用戶A選擇隨機數rA計算rAG發送給對方，用戶B選擇隨機數rB計算rBG發送給對方）。協議的雙方在驗證公鑰合法性（點rAG、rBG是否在橢圓曲線上）的前提下通過計算PA、PB、rAG、rBG的組合得到會話密鑰。

令w為大于或等于（log2n+1）/2的最小整數，h為余因子（在標準中一般為1）。MQV密鑰交換協議的詳細過程如下所示：

①用戶A選擇，計算RA=rAG=（x1，y1），并將RA發送給用戶B；同時計算hx=x1mod 2w+2w，以及tA=hxdA+rAmod n。

②用戶B選擇，計算RB=rBG=（x2，y2），并將RB發送給用戶A；同時計算hy=x2mod 2w+2w，以及tB=hydB+rBmod n。

③用戶A接收到RB后驗證其是否在橢圓曲線上（驗證臨時消息的合法性）；計算hy=x2mod 2w+2w。

④用戶B接收到RA后驗證其是否在橢圓曲線上（驗證臨時消息的合法性）；計算hx=x1mod 2w+2w。

⑤用戶A計算k=htA（RB+hyPB）為共享密鑰。

⑥用戶B計算k=htB（RA+hxPA）為共享密鑰。

容易驗證，合法的用戶A和用戶B最終計算出共同的會話密鑰k。

3．SM2密鑰交換協議

SM2密鑰交換協議為MQV的一個變種，同樣具有鑒別通信雙方身份真實性的功能。該協議可滿足通信雙方經過兩次（或供選擇的三次）信息傳遞過程，計算并獲取一個由雙方共同決定的會話密鑰。SM2密鑰交換協議的具體交互流程已在本書1.4.2節中介紹。

1.6.2 實體鑒別協議

實體鑒別機制用于證實某個實體就是他所聲稱的實體，待鑒別的實體通過表明它確實知道某個秘密來證明其身份。我國國家標準GB/T 15843規定了進行實體鑒別的機制，這些機制定義了實體間的信息交換，以及需要與可信第三方的信息交換。GB/T 15843系列標準已經發布了六個部分，分別為：

? GB/T 15843.1-2017《信息技術安全技術實體鑒別第1部分：總則》；

? GB/T 15843.2-2017《信息技術 安全技術 實體鑒別 第2部分：采用對稱加密算法的機制》；

? GB/T 15843.3-2016《信息技術 安全技術 實體鑒別 第3部分：采用數字簽名技術的機制》；

? GB/T 15843.4-2008《信息技術 安全技術 實體鑒別 第4部分：采用密碼校驗函數的機制》；

? GB/T 15843.5-2005《信息技術 安全技術 實體鑒別 第5部分：使用零知識技術的機制》；

? GB/T 15843.6-2018《信息技術 安全技術 實體鑒別 第6部分：采用人工數據傳遞的機制》。

實體鑒別應用機制包括單向鑒別和相互鑒別兩種。單向鑒別是指使用該機制時兩實體中只有一方被鑒別，相互鑒別是指兩個通信實體運用相應鑒別機制對彼此進行鑒別。其中單向鑒別按照消息傳遞的次數，又分為一次傳遞鑒別和兩次傳遞鑒別；相互鑒別根據消息傳遞的次數，分為兩次傳遞鑒別、三次傳遞鑒別或更多次傳遞鑒別。如果采用時間值或序號，則單向鑒別只需一次傳遞，而相互鑒別則需兩次傳遞；如果采用使用隨機數的“挑戰—響應”方法，單向鑒別需兩次傳遞，相互鑒別則需三次或四次傳遞（依賴于所采用的機制）。本小節主要對GB/T 15843規定的采用對稱加密算法、采用數字簽名技術和采用密碼校驗函數的無可信第三方單向鑒別機制進行介紹，關于其他鑒別機制可參閱該標準。

1．一次傳遞鑒別

一次傳遞鑒別只需要進行一次消息傳遞過程。一次傳遞的單向鑒別機制如圖1-22所示，身份聲稱者A向驗證者B發送能證明自己身份的TokenAB，由B來進行鑒別。為了防止重放攻擊，一次傳遞鑒別的Token中應當包含時間值TA或序列號NA。

1）采用對稱加密算法

在采用對稱加密算法的實體鑒別機制中，聲稱者A通過表明他知道某秘密鑒別密鑰來證實其身份。鑒別時，A使用秘密密鑰KAB加密特定數據，與A共享該密鑰的驗證者B將加密后的數據解密，從而驗證A的身份。

聲稱者A發送的Token的形式為：，其中eK（M）表示使用密鑰K對消息M進行加密。Token是否包含可區分標識符B是可選的，Token中的Text1內容可以與Text2相同，也可以是A、B預共享的，如預留信息。驗證時，B將加密部分解密并檢驗可區分標識符B（如果有）以及時間值或序號的正確性。

2）采用密碼校驗函數

HMAC等MAC產生機制是常用的密碼校驗函數，具體構造方法可參考GB/T 15852系列標準。鑒別時，A使用秘密密鑰KAB和密碼校驗函數對指定數據計算密碼校驗值，與A共享該密鑰的驗證者B重新計算密碼校驗值并與所收到的值進行比較，從而驗證A的身份。

聲稱者A發送的Token的形式為：，其中函數fK（M）表示使用密鑰K計算消息M的密碼校驗值。驗證時，B根據時間值或序號，重新計算校驗值，并與Token中的密碼校驗值進行比較。

3）采用數字簽名技術

在采用數字簽名技術的實體鑒別機制中，聲稱者A通過表明它擁有某個私有簽名密鑰來證明其身份。鑒別時，A使用其私鑰dA對特定數據進行簽名，任何實體都可以使用A的公鑰進行驗證。

聲稱者A發送的Token的形式為：，其中函數Sd（M）表示使用私鑰d對消息M進行簽名。作為可選項，A還可以將自己的公鑰證書與Token一同發送給B。驗證時，B根據時間值或序號，利用A的公鑰對簽名結果進行驗證。

2．兩次傳遞鑒別

為了防止重放攻擊，一次傳遞鑒別需要雙方保持時間同步，或者鑒別方驗證序列號沒有重復，這在一些情況下可能是難以實現的。采用“挑戰—響應”機制可以有效克服這種困難，即如圖1-23所示的兩次傳遞單向鑒別機制。鑒別時，由B發起鑒別過程，將隨機數RB作為挑戰發送給A（并可選的發送一個文本字段Text1），A通過對稱加密、計算密碼校驗值或者私鑰簽名的方法計算Token，并發送給B作為自己身份的證明，B通過對稱解密、重新計算密碼校驗值或者簽名驗證的方法驗證Token的有效性，從而對A的身份進行鑒別。Token的計算和驗證的具體過程與一次傳遞過程類似，主要變化是將一次傳遞過程中用于防重放攻擊的因子TA或NA換為RB，在此不再贅述。

1.6.3 綜合密碼協議舉例

IPSec協議和SSL協議是兩個較為綜合的密碼協議，支持采用多種密碼技術為通信交互中的數據提供全面安全保護，包括數據保密性、完整性校驗、數據源身份鑒別和抗重放攻擊等。不同的是，IPSec工作在網絡層，而SSL工作在應用層和傳輸層之間。IPSec一般用于兩個子網之間的通信，稱為站到站的通信；SSL一般用于終端到子網之間的通信，稱為端到站的通信。

1．IPSec

IPSec協議是國際組織IETF以RFC（Request For Comments）形式公布的一組IP密碼協議集，其基本思想是將基于密碼技術的安全機制引入IP協議中，實現網絡層的通信安全。IPSec最初是針對IPv6網絡環境開發的，卻首先在IPv4網絡中廣泛部署?？紤]到當前網絡設備對IPSec協議實現的兼容性，目前IPSec在IPv4和IPv6是一項建議的可選服務。

IETF于1994年成立IPSec工作組專門制定和推動IPSec協議標準。1995年8月，IETF首次公布關于IPSec的RFC建議標準；而后在1998年發布更新后的標準，并新增了一個用于相互身份鑒別的機制和互聯網密鑰交換（Internet Key Exchange，IKE）協議。2005年12月，RFC 4301、RFC 4309等作為IPSec的新標準發布，其中，RFC 4301規定了IPSec的標準架構，RFC 4309提出了IKE的第二版標準IKEv2。當前，IETF仍在持續開展對IPSec規范文檔的制定和修訂工作。我國于2014年發布了密碼行業標準GM/T 0022-2014《IPSec VPN技術規范》，其對IPSec協議技術進行了規范。該標準主要參考了RFC 4301等文檔，并增加了對商用密碼算法和雙證書（簽名證書和加密證書）的支持等內容。

IPSec協議實際上是一套協議集合，而不是一個單獨的協議。它為網絡層上的通信數據提供一整套的安全體系結構，包括IKE協議、認證頭（Authentication Header，AH）協議、封裝安全載荷（Encapsulating Security Payload，ESP）協議和用于網絡身份鑒別及加密的一些算法等。從工作流程上看，IPSec協議可分為兩個環節：IKE是第一個環節，完成通信雙方的身份鑒別、確定通信時使用的IPSec安全策略和密鑰；第二個環節是使用數據報文封裝協議和IKE中協定的IPSec安全策略和密鑰，實現對通信數據的安全傳輸。

AH和ESP協議可以工作在傳輸模式或隧道模式下。傳輸模式一般用于端到端的應用場景，只有IP載荷部分被保護，對IP頭不做改動；隧道模式對整個IP數據報文提供加密和認證功能，并在此基礎上添加新的IP頭，一般用于創建虛擬專用網（Virtual Private Networks，VPN）隧道鏈路。

下面簡要對IPSec中IKE、AH和ESP三個安全機制進行介紹，這部分內容主要參考GM/T 0022-2014對IPSec協議實現的描述。

1）IKE協議

IKE協議用于鑒別通信雙方身份、創建安全聯盟（Security Association，SA）、協商加密算法以及生成共享會話密鑰等，其中ISAKMP是IKE的核心協議，定義了建立、協商、修改和刪除SA的過程和報文格式，并定義了密鑰交換數據和身份鑒別數據的載荷格式。ISAKMP的一個核心功能就是創建和維護SA。SA作為通信雙方之間對某些要素的一種協定，是IPSec的基礎，協定的內容包括數據報文封裝協議、IPSec工作模式、密碼算法等安全策略和密鑰。IPSec的兩種封裝協議（AH和ESP）均使用SA中協定的內容保護通信安全。另外，SA是單向的，一個SA為單一通信方向上傳輸的數據提供一種安全服務，通信雙方需要產生屬于自己的SA。若使用多個安全服務保護數據流，例如，同時提供認證和加密服務，那么應該創建多個SA來分別實現不同安全服務對數據的保護，即每個SA對應一個安全服務。

ISAKMP分為兩個階段：第一階段是主模式，通信雙方建立一個ISAKMP SA，并實現雙方的身份鑒別和密鑰交換，得到工作密鑰，該工作密鑰用于保護第二階段的協商過程；第二階段是快速模式，使用已建立的ISAKMP SA提供保護，實現通信雙方IPSec SA的協商，確定通信雙方IPSec安全策略和會話密鑰。其中，IPSec安全策略定義了哪些服務以何種形式提供給IP數據報文，如數據加密服務以SM4的CBC模式實現。

（1）第一階段：主模式。主模式是一個身份保護的交換，其交換過程由6個消息組成。雙方身份的鑒別采用數字證書的方式實現。ISAKMP的主模式工作流程如圖1-24所示。

①消息1：發起方向響應方發送一個封裝有建議載荷的ISAKMP SA載荷，告知響應方它優先選擇的密碼協議（如ISAKMP、AH或ESP）以及希望協商中的SA采用的密碼算法。

②消息2：響應方發送一個SA載荷及響應方的簽名證書和加密證書（雙證書），該載荷表明它所接受的發起方發送的SA提議。雙證書則用于隨后密鑰交換時的數據加密和身份鑒別。

③消息3和4：雙方完成基于數字簽名的身份鑒別，并通過交換數據得到為第二階段（快速模式）提供保護的工作密鑰。密鑰交換的數據內容包括Nonce載荷（Ni和Nr）、身份標識載荷（IDi和IDr）等，其中Nonce載荷是生成工作密鑰所必需的參數。這些數據使用雙方各自隨機生成的臨時密鑰SK進行對稱加密保護，SK用對方的加密證書中的公鑰進行加密保護。雙方各自對交換數據進行數字簽名，這一過程使用簽名證書對應的私鑰來完成，并將簽名結果發給對方。同時，發起方的雙證書也在消息3中發給響應方。

消息3和4完成后，參與通信的雙方利用Nonce載荷等交換數據經偽隨機函數（Pseudo-Random Function，PRF）派生出基本密鑰參數，并通過PRF用基本密鑰參數派生出三個對稱密鑰，分別是用于產生會話密鑰的密鑰參數、用于驗證完整性和數據源身份的工作密鑰及用于加密的工作密鑰。

④消息5和6：發送方和響應方對前面的協商過程內容進行鑒別確認。這兩個消息中傳遞的信息使用用于加密的工作密鑰進行對稱加密保護。對稱密碼算法由消息1和2確定，如使用SM4算法的CBC模式。為了檢查交換內容，雙方通過計算HMAC驗證身份和協定的SA信息。

（2）第二階段：快速模式。在主模式建立了ISAKMP SA后，通信雙方就可以使用快速模式了。快速模式用于協商建立通信時使用的IPSec SA，包括IPSec安全策略和會話密鑰。會話密鑰有兩個，均為對稱密鑰，分別用于通信數據加密，以及完整性校驗和數據源身份鑒別。快速模式交換的數據由主模式協定的ISAKMP SA提供保護，即除了ISAKMP頭外所有的載荷都是加密的，加密密鑰選用用于加密的工作密鑰。同時，在ISAKMP頭之后會緊跟一個HMAC載荷，用于驗證交換數據的完整性和數據源身份。ISAKMP的快速模式工作流程如圖1-25所示。

最后，將主模式消息3和4中派生出的用于產生會話密鑰的密鑰參數經PRF計算得到會話密鑰。PRF的輸入還包括雙方的Nonce載荷、從主模式建立的ISAKMP SA中獲得的協議值和安全參數索引（SPI），其中SPI用于唯一標識一個數據報文對應的SA。用于加密的會話密鑰與用于驗證完整性和數據源身份的會話密鑰則按照密碼算法要求的長度，從會話密鑰素材中依次選取。

2）AH協議

AH協議提供數據源身份鑒別、完整性和抗重放等安全功能。不過，AH不提供任何保密性服務。標準GM/T 0022-2014規定，AH不得單獨用于封裝IP數據報文，應和封裝安全載荷協議ESP嵌套使用。

AH協議的主要作用是為整個IP數據報文（IP頭和IP載荷）提供高強度完整性校驗，以確保被篡改過的數據包可以被檢查出來。AH使用MAC對IP數據報文進行認證，最常用的MAC是HMAC，而HMAC對IP數據報文處理所用的密鑰就是IKE協定的用于驗證完整性和數據源身份的會話密鑰。

AH在傳輸模式和隧道模式中分別有不同的放置位置，保護的范圍有所不同，如圖1-26所示。使用傳輸模式時，AH放在原IP頭之后，上層（傳輸層）協議之前，為整個IP數據報文（原IP頭和IP載荷）提供認證保護；使用隧道模式時，AH放在新建外部IP頭之后，原IP數據報文之前，為整個原IP數據報文及新建外部IP頭提供認證保護。需要注意的是，由于AH不提供加密服務，因此圖1-26中的AH和ESP嵌套使用，共同保護IP數據報文。

3）ESP協議

和AH協議相比，ESP協議增加了對數據報文的加密功能，它可同時使用用于加密的會話密鑰及用于驗證完整性和數據源身份的會話密鑰，來為數據提供全面保護。由于ESP提供的安全功能更為全面，在標準GM/T 0022-2014中規定，ESP可單獨使用，并同時選擇保密性和數據源身份鑒別服務；當ESP和AH結合使用時，無須ESP提供數據源身份鑒別服務，而由AH提供該項安全服務。由于單獨使用ESP封裝方式時，不會對數據報文的IP頭進行認證，因此這種情況支持網絡地址轉換（NAT）穿越。

ESP頭在傳輸模式和隧道模式中分別有不同的放置位置，保護范圍也有所不同，如圖1-27所示。使用傳輸模式時，ESP頭放在原IP頭之后，上層協議之前，為ESP頭后的載荷提供保密性保護，為原IP頭后的內容提供認證保護；使用隧道模式時，ESP頭放在新建外部IP頭之后，原IP數據報文之前，為整個原IP報文提供保密性保護，為新建外部IP頭后的內容提供認證保護。

2．SSL

SSL協議是網絡上實現數據安全傳輸的一種通用協議，采用瀏覽器/服務端（B/S）結構是SSL協議的一種典型實現方式。該協議是由網景（Netscape）通信公司在推出Web瀏覽器時提出的，旨在保證經Web傳輸的重要或敏感數據的安全性。SSL協議的安全功能和IPSec類似，有數據加密、完整性保護、數據源鑒別和抗重放攻擊等功能。SSL的3個版本（SSL 1.0/2.0/3.0）都由網景通信公司設計開發。1999年，IETF開展SSL標準化工作，將SSL 3.0改版為傳輸層安全（Transport Layer Secure，TLS）協議，即TLS 1.0。經歷了TLS 1.1和TLS 1.2版本后，2018年8月，TLS 1.3正式版本通過RFC 8446發布。相比于TLS 1.2，TLS 1.3在安全性和效率上都有重要提升。

我國于2014年發布了密碼行業標準GM/T 0024-2014《SSL VPN技術規范》，對SSL協議技術進行規范。標準GM/T 0024-2014參考了RFC 4346（TLS 1.1版本），并在TLS 1.1握手協議中增加了ECC、IBC身份鑒別模式和密鑰交換模式，取消了DH密鑰交換方式，修改了密碼套件的定義以使其支持商用密碼算法。

SSL不是單個協議，而是由多個協議組成的兩層協議集合，如圖1-28所示。SSL協議工作于應用層和傳輸層之間，協議的上層有握手協議等四個協議，下層是記錄層協議（Record Protocol）。記錄層協議用于封裝不同的更高層協議的數據，為數據提供保密性、完整性和數據分段等服務，特別是它可為B/S的交互提供傳輸服務的超文本傳輸協議（HTTP）提供安全服務。SSL協議中定義了三個更高層協議：握手協議、密碼規格變更協議和報警協議。其中，握手協議實現了服務端和客戶端之間相互的身份鑒別、交互過程中密碼套件（公鑰密碼算法、對稱密碼算法和密碼雜湊算法的集合）與密鑰的協商；密碼規格變更協議則是用于通知對方其后的通信消息將用剛剛協商的密碼規格及相關聯的密鑰來保護；報警協議用于關閉連接的通知，以及對整個連接過程中出現的錯誤進行報警，其中關閉通知由發起者發送，錯誤報警由錯誤的發現者發送，報警消息中包含報警級別和報警內容。

下面對SSL中的兩個主要部分——握手協議和記錄層協議進行介紹。之所以選取這兩個子協議，是因為記錄層協議發揮了SSL“承上啟下”的作用，它對從上層應用接收到的待傳輸數據進行分塊、壓縮、封裝等處理，而后將處理后的數據傳輸給下層，再傳輸給通信的另一方；而握手協議是通信雙方準備建立SSL連接通信時，用到的第一個子協議，它是SSL協議中最復雜、涉及密碼技術最多的協議。這部分內容參考GM/T 0024-2014對SSL協議實現的描述。

1）握手協議

握手協議的主要作用有兩點：一是通信雙方對彼此進行身份鑒別；二是協商連接會話所需的密碼參數（如密碼算法、密鑰），其中各類密碼算法組成的集合稱為密碼套件。握手協議工作流程如圖1-29所示，分為四個主要的階段。

階段一：客戶端向服務端發送Client Hello消息，服務端回應Server Hello消息。若服務端未回應，則產生一個致命錯誤并且斷開連接。Client Hello和Server Hello消息用于在客戶端和服務端之間進行密碼套件協商及確定安全傳輸能力（包括協議版本、會話標識等屬性），并且產生和交換隨機數。

階段二：在客戶端和服務端Hello消息之后是身份鑒別和密鑰交換過程。在服務端發送完Hello消息之后，服務端將發送證書Server Certificate（簽名證書和加密證書）和服務端密鑰交換消息Server Key Exchange（用于生成預主密鑰）。如果服務端需要驗證客戶端身份，則向客戶端發送證書請求消息Certificate Request，之后發送服務端Hello完成消息Server Hello Done，表示Hello消息階段已經結束，服務端等待客戶端的返回消息。

階段三：若服務端發送了一個證書請求消息Certificate Request，客戶端必須返回一個證書消息Client Certificate。然后，客戶端發送密鑰交換消息Client Key Exchange，消息內容取決于雙方Hello消息協商出的密鑰交換算法，如交換算法為ECC，則客戶端應產生46字節隨機數與版本號一起構成預主密鑰，并采用服務端的加密公鑰進行加密并放在ClientKey Exchange消息中發送給服務端；如交換算法為ECDHE，則ClientKey Exchange消息包含計算預主密鑰的客戶端密鑰交換參數。同時，客戶端根據雙方的密鑰交換消息生成預主密鑰。如果客戶端發送了證書消息Client Certificate，那么也應發送一個帶數字簽名的消息Certificate Verify供服務端驗證客戶端的身份。在對交換數據進行加密和簽名計算時，交換數據的加密運算采用對方加密證書中的公鑰來完成；交換數據的簽名運算采用本方簽名私鑰來完成，而且簽名計算的輸入應包括加密證書。

階段四：客戶端發送密碼規格變更消息，并立即使用剛協商的算法和密鑰，發送加密的握手結束消息。服務端則回應密碼規格變更消息，使用剛協商的算法和密鑰，發送加密的握手結束消息。至此，握手過程結束，服務端和客戶端可以開始進行數據安全傳輸。

（1）密鑰計算。主密鑰為48字節對稱密鑰，由預主密鑰、客戶端隨機數、服務端隨機數、常量字符串，經PRF計算生成。

工作密鑰的具體密鑰長度由選用的密碼算法決定，由主密鑰、客戶端隨機數、服務端隨機數、常量字符串經PRF計算生成。工作密鑰包括兩個對稱密鑰：用于加密的工作密鑰，用于驗證完整性和數據源身份的工作密鑰。

（2）會話重用。如果客戶端和服務端決定重用之前的會話，可不必重新協商安全參數?？蛻舳税l送Client Hello消息，并且帶上要重用的會話標識。服務端在會話緩存中檢查該標識，如果服務端有匹配的會話存在，服務端則使用相應的會話狀態接受連接，發送一個具有相同會話標識的服務端Hello消息。然后通信雙方根據從重用會話中提取的主密鑰進行后續操作，以及發送密碼規格變更消息和握手結束消息。如果服務端沒有匹配的會話標識，服務端會生成一個新的會話標識進行一個新的完整的握手過程。

2）記錄層協議

當客戶端和服務端握手成功后，待傳輸的應用數據通過記錄層協議封裝，并得到保密性和完整性保護，具體過程如圖1-30所示。接收到這些信息的實體要將該過程逆向執行一遍，從而獲取原始數據。

第1步：數據分段。當記錄層從上面的應用層接收到不間斷的數據流時，將對數據進行分段，每一個記錄塊的長度為214字節或者更小。

第2步：數據壓縮。所有的記錄塊使用當前會話狀態指定的壓縮算法進行壓縮。壓縮應采用無損壓縮方法，并且增加長度不超過1024字節。在標準GM/T 0024-2014中沒有指定壓縮算法，默認的壓縮算法為空。

第3步：數據添加MAC。使用握手協議的密碼套件中協定的密碼雜湊算法和用于校驗的工作密鑰，對每塊明文記錄計算MAC。

第4步：對數據和MAC加密。使用握手協議的密碼套件中協定的對稱密碼算法和用于加密的工作密鑰，對壓縮的數據及與之相關聯的MAC進行加密。

第5步：附加SSL記錄報頭。增加由內容類型、主要版本、次要版本和壓縮長度組成的首部。

1.6.4 密碼協議分析概要

對密碼協議的分析和設計是相互交織并且相輔相成、共同發展的。在早期研究中，研究人員根據具體應用需求設計了大量密碼協議，并基于經驗和單純的軟件測試等分析其安全特性。多數協議是通過和已有協議進行對比或者分析對已知攻擊的抵抗等經驗來說明協議的安全性。然而，事實證明，根據經驗設計的密碼協議是非常脆弱和危險的，各種未知的攻擊會不斷涌現。以密鑰交換協議為例，其前期分析工作只進行啟發式的安全說明，缺乏嚴格的安全性證明，針對其未曾預料的攻擊層出不窮。

針對上述缺點，研究人員在近幾年提出了一系列密碼協議設計原則，并且給出了一套形式化的分析方法，從而從理論上保證了密碼協議的安全性。

設計原則有助于在協議設計階段通過充分考慮一些不恰當的結構來避免不必要的錯誤，具體包括消息獨立完整性原則、消息前提準確原則、主體身份鑒別標識原則、加密目的原則、簽名原則、隨機數使用原則、時間戳使用原則及編碼原則。

形式化方法采用正規的標準化方法，借助可證明安全的方法對協議進行分析以檢查協議是否滿足其安全目標。密碼協議的形式化分析技術可以使設計者將注意力集中于接口、系統環境的假設、系統的不同狀態與不變屬性等，通過系統驗證提供必要的保證。形式化分析有助于界定密碼協議的邊界、準確地描述密碼協議的行為和特性、更準確地衡量敵手的能力，以及準確地分析其滿足安全目標或者在什么條件下不滿足安全目標。

對一個具體的密碼協議進行分析時，研究人員的一個基本共識是對協議進行形式化抽象與刻畫，并采用可證明安全的手段進行說明，將協議安全保證歸約到底層的數學問題的困難性或者密碼組件的安全屬性上，從而保證協議安全性。例如，針對密鑰交換協議，研究人員已經提出了一些嚴格的安全模型，并采用可證明安全的方法證明所設計的方案符合某個安全模型的安全定義，這其中具有代表性的就是HMQV、NAXOS等方案；針對TLS 1.3協議，研究人員用形式化的方法定義合適的安全模型，并從理論證明的角度分析其不同版本之間的可組合性及對稱密鑰協議的可組合性。