安全協(xié)議的安全性分析范文

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

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

1ssl協(xié)議概述

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

2ssl協(xié)議的安全性分析

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

3ssl協(xié)議漏洞分析

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

4結(jié)束語

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

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