安全協議的安全性分析范文

本站小編為你精心準備了安全協議的安全性分析參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

《計算機工程與科學雜志》2014年第六期

1ssl協議概述

ssl協議由HandsHakeProtocol、CHangeCi—pHerspeCProtocol、alertProtocol以及reCordProtocol組成。其中，HandsHakeProtocol、CHangeCipHerspeCProtocol和alertProtocol這三個協議位于tCp／ip協議棧的應用層。reCordProtocol介于應用層和傳輸控制層之間。ssl協議與tCp／ip協議的體系結構如圖2所示。ssl協議中，ssl會話和ssl連接是兩個重要的概念。ssl連接是指能夠提供一種服務的傳輸方式。對于ssl協議來說，這樣的連接是對等體之間的，即客戶端與服務器模式。ssl會話是存在于客戶端與服務器之間的一種聯系，它為ssl連接規定了一組密碼元件。相對于ssl會話，ssl連接是暫時的。每個ssl連接對應一個ssl會話。在ssl協議中，由于ssl會話的建立需要的計算量較大，為了使協議的運行效率提高，一個ssl會話通常對應多個不同的ssl連接。下面簡單地介紹一下HandsHakeProtocol、CHangeCipHerspeCProtocol、alertProtocol以及reCordProtocol四個協議的內容。（1）HandsHakeProtocol（握手協議）。sslHandsHakeProtocol是ssl協議中最復雜的部分，也是本文的攻擊重點，這里有必要詳述其流程。HandsHakeProtocol的流程如圖3所示。HandsHakeProtocol的流程大致可分為四個階段：構建安全參數；服務器認證及密鑰交換；客戶端認證及密鑰交換；結束。下面對其進行一一闡述。階段1構建安全參數。這一階段用于初始化一個邏輯上的連接，并在連接上定義安全參數。首先由客戶端發送Clien—tHello給服務器。其中，ClientHello包含下面五個參數：上述五個參數的詳細內容請參閱文獻［1］。服務器收到ClientHello后，發送serverHello給客戶端。serverHello的參數類似于ClientHello的五個參數。需要注意的是，serverHello中的CipHer—suite的選定取決于ClientHello中的CipHersuite提供的一組密碼及密鑰交換算法，且只能選定其中的一套密碼及密鑰交換算法。此外，3．0版本的ssl協議中的CompressionmetHod默認值為null。本文的攻擊對象為CipHersuite選定的密鑰交換算法，需對其詳述。客戶端支持的密鑰交換算法如下所述：①rsa：密鑰使用服務器的rsa公鑰加密。客戶端擁有服務器rsa公鑰的公鑰證書，公鑰證書由可信任的證書機構簽發。②固定的diffie—Hellman：這是diffie—Hell—man密鑰交換算法。服務器的證書包含diffie—Hellman密鑰交換算法中的服務器公鑰，該證書由可信任的證書機構簽發。如果服務器要求其發送證書，客戶端可在其證書中提供客戶端的diffie—Hellman公鑰；如果不發送證書，可在密鑰交換信息中發送客戶端公鑰。③短暫的diffie—Hellman：類似于固定的dif—fie—Hellman，服務器傳給客戶端證書的同時，還有服務器使用rsa的私鑰對diffie—Hellman公鑰的簽名。④匿名diffie—Hellman：這也是diffie—Hell—man密鑰交換算法。服務器和客戶端雙方通過密鑰交換信息將各自的diffie—Hellman公鑰發送給對方，不需要認證。⑤fortezza：fortezza方案的密鑰交換算法。階段2服務器認證及密鑰交換。如果上一階段需要服務器被認證，服務器將CertifiCate證書發送給客戶端。除了匿名diffie—Hellman密鑰交換，其余四種密鑰交換都需要認證證書。接著，服務器只在下列三種情況下發送serverkeyexCHange消息：①fortezza。②匿名diffie—Hellman：消息中包含一個大素數，一個關于該素數的原根以及服務器的diffie—Hellman公鑰。③短暫的diffie—Hellman：消息中除了匿名diffie—Hellman的三個元素外，還有關于該三個元素的簽名。需要被認證的服務器發送CertifiCaterequest給客戶端，要求客戶端的CertifiCate。最后，服務器發送serverHellodone給客戶端。階段3客戶端認證及密鑰交換。如果在階段2要求了客戶端的證書，此時，客戶端發送CertifiCate給服務器。接著，客戶端發送ClientkeyexCHange消息給服務器。該消息的內容取決于密鑰交換的方式：①rsa：客戶端生成48—byte的pre—masterkey，使用服務器的rsa公鑰證書中的公鑰對pre—masterkey加密。②短暫的或匿名diffie—Hellman：客戶端的diffie—Hellman公鑰。③固定的diffie—Hellman：客戶端的diffie—Hellman公鑰包含在客戶端CertifiCate中，因此內容是空的。④fortezza：客戶端的fortezza參數。最后，客戶端可能發送CertifiCateverify消息給服務器，用于服務器驗證客戶端CertifiCate。階段4結束。客戶端發送CHangeCipHerspeC消息給服務器，值得注意的是，該消息是客戶端利用CHangeCipHerspeCProtocol發送的，不屬于HandsHakeProtocol。之后，客戶端使用協商好的密碼算法及密鑰對finisHed消息加密，并將密文發送給服務器。服務器利用CHangeCipHerspeCProtocol發送CHangeCipHerspeC消息給客戶端，服務器同樣使用協商好的密碼算法及密鑰對finisHed消息加密，并將密文發送給客戶端。到此，客戶端與服務器的安全連接建立完畢，二者可利用協商好的密碼算法及密鑰進行保密通信了。（2）reCordProtocol（記錄層協議）。sslreCordProtocol為ssl連接提供了兩種服務：①機密性。sslHandsHakeProtocol定義了一個分組密碼或流密碼的加密共享密鑰，sslre—CordProtocol利用共享密鑰和常規的分組密碼或流密碼算法對ssl的有效載荷進行加密。②消息完整性。sslHandsHakeProtocol定義了一個maC（消息認證碼）共享密鑰，sslre—CordProtocol利用該maC共享密鑰和HasH函數生成了關于消息的消息認證碼。sslreCordProtocol對應用層的數據進行分段、壓縮（可選項）、計算maC、加密、添加sslre—CordProtocol的報頭，最后將結果加入tCp段中。（3）CHangeCipHerspeCProtocol（改變密碼規范協議）。CHangeCipHerspeCProtocol只包含一個字節的信息，該字節的值為1。該字節的信息利用sslreCordProtocol的當前密碼算法和密鑰加密。加了密的信息在客戶端和服務器之間傳輸，雙方解密之后獲得信息，之后的sslreCordproto—Col中的數據將由剛協商好的密碼算法及密鑰進行加密傳輸。（4）alertProtocol（警告協議）。在alertProtocol中，大多數的alert消息都是毀滅性的，它告訴接受者（客戶端或服務器）立即中斷會話。例如，Close＿notify消息表明發送者已完成在連接上發送應用程序的數據。詳述請參閱文獻。

2ssl協議的安全性分析

客戶端和服務器利用ssl協議在不安全的鏈路中建立一條安全的連接通道。通過本文對ssl協議的闡述可知，影響ssl協議安全實施的關鍵在于HandsHakeProtocol。下面對于HandsHakeProtocol做進一步的安全分析。由文中的第2節可知，HandsHakeProtocol中的認證及密鑰交換部分是影響安全的主要因素。認證完成，密鑰建立之后，客戶端和服務器就能安全地進行保密通信。在這種情況下，攻擊者的攻擊就是針對已知分組密碼或流密碼的攻擊，即對算法本身的攻擊。而這種攻擊通常采用暴力攻擊，針對某一特定的密文，采用窮搜索密鑰空間，找尋合適的明文。暴力攻擊對攻擊者的計算資源的要求非常高。在HandsHakeProtocol中，對于不同的認證方式，有與之相對應的密鑰交換方式。HandsHakeProtocol支持三種認證方式：客戶端和服務器的雙方認證；服務器的單方認證；客戶端和服務器的完全匿名認證。對于rsa公鑰證書，采取第一種方式認證，認證通過后，接收方（客戶端或服務器）利用發送方（客戶端或服務器）證書中的rsa公鑰對密鑰進行加密后傳給發送方，發送方利用對應的rsa私鑰解密獲得密鑰；采取第二種方式，客戶端在驗證服務器的身份后，利用服務器證書中的rsa公鑰對密鑰進行加密，密文通過消息ClientkeyexCHange發送給服務器，服務器利用對應的rsa私鑰解密密文獲得密鑰。在這種情況下，攻擊者想獲得解密私鑰的難度等同于大數分解，因此密鑰是安全的。對于固定的diffie—Hellman公鑰證書，采用第一種認證方式。服務器和客戶端分別向對方發送包含diffie—Hellman公鑰的證書，認證結束后，各自利用自己的私鑰與對方的diffie—Hellman公鑰計算出密鑰。在這種情況下，攻擊者想獲得私鑰的難度等同于計算離散對數，因此密鑰是安全的。對于短暫的diffie—Hellman密鑰交換，采用第二種認證方式。服務器生成rsa公鑰／私鑰對，利用私鑰對服務器diffie—Hellman公鑰簽名，服務器生成關于rsa公鑰的公鑰證書，服務器將公鑰證書、diffie—Hellman公鑰以及關于diffie—Hellman公鑰的簽名發送給客戶端。客戶端驗證完服務器的身份后，利用證書中的公鑰就能驗證簽名的合法性，從而知道diffie—Hellman公鑰是由服務器發送過來的。客戶端利用自己的私鑰與服務器diffie—Hellman公鑰生成密鑰。在這種情況下，攻擊者想獲得簽名私鑰的難度等同于大數分解，因此攻擊者無法偽造關于diffie—Hellman公鑰的合法簽名。對于匿名diffie—Hellman密鑰交換，采用第三種認證方式。服務器和客戶端在不認證對方身份的情況下，直接將各自的diffie—Hellman公鑰傳給對方，之后，各自利用自己的私鑰與對方的diffie—Hellman公鑰計算出密鑰。在這種情況下，攻擊者想獲得私鑰的難度等同于計算離散對數，因此密鑰是安全的。綜上所述，ssl協議總體上是安全的，協議的不安全是由于實現者在配置和實現ssl協議于客戶端和服務器時，實現者考慮不周或工業化制定標準過時等因素造成的。

3ssl協議漏洞分析

通過對ssl協議本身的深入研究與分析，該協議從理論上來說存在四個漏洞，并且通過測試驗證了＊＊＊模式漏洞的實際存在性。下面對這四個漏洞分別闡述。（1）＊＊＊模式漏洞。＊＊＊模式漏洞是指配置有ssl協議的客戶端和服務器都支持＊＊＊密碼套件。通過搭建實驗環境驗證了＊＊＊模式漏洞的存在性，并通過編制的工具sslClient測試了國內的某些安全郵箱服務器存在＊＊＊模式漏洞。因而對于具備一定硬件條件的攻擊者而言，攻擊者利用＊＊＊模式漏洞，可以實施針對ssl協議的攻擊，或者實施針對利用ssl協議構建的安全郵箱服務器的攻擊。下面簡單介紹實現＊＊＊模式漏洞挖掘的主要思路、實驗環境以及攻擊過程。①技術實現的主要思路。攻擊主要采用中間者攻擊技術（man—in—tHe—middleattaCk），其思路如圖4所示。這里，對圖4簡單地描述一下：在有網關的局域網中，a發往s的數據包必然要先發到網關g，再通過g進行轉發；同樣，s發往a的數據包也要先發到網關g，再通過g發送到a。我們需要實現的就是中間者m攔截從a發往g的數據包。注意這里攔截和截獲的意思是不同的：中間者m截獲數據包只是對傳輸的數據包進行復制；中間者m攔截數據包不但能獲得數據包的復制，而且能決定是否繼續數據包1080Computerengineering＆sCienCe計算機工程與科學2014，36（6）的傳輸，或對數據包修改后再進行傳輸。②技術實現的實驗環境。a電腦一臺，宿主機安裝WindowsXp操作系統。宿主機中安裝一個Windows2000虛擬機作為ssl的客戶端，安裝一個Windows2000虛擬機作為ssl的服務器。b搭建局域網環境。將宿主機WindowsXp的ip地址設為192．168．19．1，ssl客戶端的ip地址設為192．168．19．5，ssl服務器的ip地址設為192．168．19．4，三臺機器構成一個局域網絡。C宿主機中運行開發的mim＿ssl中間者工具，WiresHark網絡數據包分析器；ssl客戶端使用微軟的ie瀏覽器；ssl服務器安裝apaCHe2．2服務器。使用openssl—0．9．8m開發庫開發。實驗環境如圖5所示。通過截獲并篡改客戶端與服務器之間的ssl數據包，使得客戶端與服務器同時支持＊＊＊模式，從而中間者截獲客戶端發給服務器的Client—keyexCHange消息，該消息中包含ssl通聯中的預主密鑰，由于中間者具備破解＊＊＊的能力，中間者能夠獲得預主密鑰，因此中間者具備了掌控ssl通聯過程的條件，由此獲得有用的信息。（2）dHe密鑰交換的漏洞［8］。攻擊者通過改變服務器密鑰交換部分的keyexCHangealgoritHm參數迫使客戶端相信服務器是對短暫的rsa密鑰參數簽的名，而實際上，服務器是對短暫的diffie—Hellman密鑰參數簽的名。協議的初始階段，即在客戶端與服務器的握手信息中，客戶端首先向服務器發送rsa信息，該信息被攻擊者截獲篡改成包含短暫diffie—Hellman的rsa信息，并發往服務器。這樣，服務器就會接收到含有短暫diffie—Hellman的rsa信息。在服務器發給客戶端的應答中包含對短暫diffie—Hell—man的rsa信息的確認。同理，該確認被攻擊者截獲并被篡改成對rsa信息的確認，篡改后的確認被攻擊者發往客戶端。此時，攻擊者就完成了對客戶端和服務器握手信息的篡改。在協議的服務器密鑰交換階段，服務器按照先前協商好的向客戶端發送含有生成diffie—Hellman密鑰的參數，這些參數被攻擊者截獲并將其中的diffie—Hellman替換成rsa，再將之發給客戶端。在協議的客戶端密鑰交換期間，客戶端利用服務器發給它的公共密鑰g對其產生的預主密鑰k進行加密，即kgmodp，并將之發往服務器。該加密信息被攻擊者截獲并篡改成gxmodp發給服務器。在此情況下，攻擊者利用歐幾里得擴展算法可以求得公共密鑰g的逆元g—1，由此通過模指數運算（kg）g—1modp求得預主密鑰k；同樣，由于攻擊者擁有服務器發給它的參數Y，它自己生成的gx，因此可以計算出預主密鑰Y×gxmodp，即gy×gxmodp＝gxymodp。這樣，攻擊者就同時擁有了預主密鑰k和gxy。到此，攻擊者就可以分別利用k和gxy生成協議下一階段所需的對稱加密算法的密鑰，換言之，客戶端與服務器的加密通信對于攻擊者來說就是透明的了。（3）版本回退漏洞［8］。在ssl3．0協議中，本文只針對rsa的密鑰交換算法進行了防版本回退攻擊，但對于非rsa密鑰交換算法的版本回退攻擊沒有考慮。攻擊者利用ClientHello＿2．0恢復一個由Cli—entHello＿3．0創建的會話。這樣，攻擊者就可以利用ssl2．0中的漏洞進行攻擊了。攻擊過程如下所示：在圖6中，客戶端和服務器分別用自己的私鑰x、y生成公鑰gx、gy，并將各自的公鑰傳給對方。攻擊者將兩者的公鑰截獲，并利用自己的私鑰x′、y′偽造公鑰gx′、gy′。攻擊者將gy′傳給客戶端，將gx′傳給服務器。對于客戶端來說，由于不認證攻擊者的身份，誤以為gy′是服務器傳來的；同理，對于服務器來說，誤以為gx′是客戶端傳來的。接著，客戶端和服務器分別生成密鑰gxy′和gx′y，攻擊者同樣生成密鑰gxy′和gx′y。這樣，客戶端和服務器在不知道攻擊者擁有各自的密鑰的情況下，利用協商好的HasH函數md5和sHa—1生成主密鑰，同樣攻擊者也生成相應的主密鑰。由此，客戶端和服務器相互交換的信息對于攻擊者來說就是透明的了，不具備機密性了。

4結束語

互聯網存在近二十年了，已成為居家度日的必需品。Web安全協議ssl為使用互聯網的用戶進行安全郵箱通信提供了重要而可靠的保障。本文針對ssl協議的握手協議部分進行了詳盡的闡述，對其安全性作了一定的分析，給出了理論上在的三個邏輯漏洞的詳盡描述，并且經過測試驗證，指出了ssl協議存在＊＊＊模式漏洞。

作者：鐘軍吳雪陽江一民段光明單位：78046部隊