基于IPSec VPN數(shù)據(jù)安全性的混合加密算法研究

陳 娟 ，魏義亮

（1.山西大學(xué)商務(wù)學(xué)院， 太原030000；2.中鐵太原勘察設(shè)計咨詢院有限公司， 太原030013）

VPN技術(shù)利用Internet等公用通信設(shè)施，通過隧道和加密技術(shù)建立了一個安全的、虛擬的專用通道，從而確保局域網(wǎng)絡(luò)內(nèi)部數(shù)據(jù)的保密性。VPN技術(shù)不僅能提供用戶數(shù)據(jù)傳輸?shù)陌踩?，且?jié)約成本。IPSec是VPN結(jié)構(gòu)中應(yīng)用最多的協(xié)議族，但其強制要求的加密算法不能滿足需求。本文提出基于IPSec VPN數(shù)據(jù)安全性的混合加密算法。該算法是由對稱算法中的高級加密算法（AES）和非對稱算法中的橢圓曲線加密算法（ECC）結(jié)合而成。AES算法簡潔、高效、安全性高且具有良好的代數(shù)結(jié)構(gòu)。ECC算法速度快、密鑰短、所占資源空間少。

1 混合加密算法的提出

在混合加密算法提出前，可以通過表1對2種算法的優(yōu)缺點進行分析比較。

對稱加密算法和非對稱加密算法都有局限性，而彼此的局限性正好可以互相彌補。將二者結(jié)合，形成一種新的加密算法即混合加密算法。

表1 對稱與非對稱加密算法性能對比

2 混合加密算法的實現(xiàn)

為滿足系統(tǒng)對數(shù)據(jù)快速高效加解密處理的要求，需要傳輸?shù)臄?shù)據(jù)采用AES加密，其中AES加密采用一次一密的模式，每次密鑰均不同，數(shù)據(jù)通過VPN傳輸時，發(fā)送方先以隨機生成的密鑰加密，再用ECC加密AES算法的密鑰，簡化對密鑰的交換與管理，并實現(xiàn)數(shù)字簽名。最后，將經(jīng)過加密處理的數(shù)據(jù)通過VPN傳送給接收方。

2.1 混合密碼算法的組成部分

2.1.1 生成密鑰

在橢圓曲線Ep（a，b）上選一點G（x，y），G的階數(shù)為n（n為一個大素數(shù)），G公開。在[1，n－1] 之間隨機地確定一個整數(shù)Ks，計算Kp=KsG，且Kp為橢圓曲線Ep（a，b）上的一點，由此就確定了密鑰對（Ks，Kp）。Ks私鑰，Kp公鑰。

加密AES密鑰：設(shè)KA為AES算法密鑰，發(fā)送方取隨機數(shù)r，r∈{1，2，…，n－1}，計算u=rKBP（KBP為B的公鑰），R1=rG=（x1，y1），v=x1KA。由此產(chǎn)生二元組（u，v）傳送給接收方B。

解密AES密鑰：用KBS（KBS為B的私鑰）計算（x1，y1）=KBS-1u，從而得KA=x1-1v。

2.1.2 簽名及認證

（1）公開消息摘要函數(shù)（md5函數(shù)），計算消息明文的摘要H（m）。

（2）簽名生成：發(fā)送方A取隨機數(shù)s，s∈{1，2，…，n－1}，計算R2=sG=（x2，y2），e=x2H（m），k=s+eKAS，w=KG，由此產(chǎn)生二元組（w，e）作為發(fā)送方A對消息的簽名。

（3）身份認證：計算R=w－eKAP=（xr，yr），如e=xrH（m）成立則簽名有效，否則無效。

2.2 系統(tǒng)仿真實現(xiàn)

2.2.1 硬件及網(wǎng)絡(luò)環(huán)境

（1）服務(wù)器端： CPU頻率Intel P4 2.7 GHz，Windows 2003 Server操作系統(tǒng)，網(wǎng)卡帶寬100 Mbit/s。

（2）客戶端：CPU頻率Intel P4 2.4 GHz，Windows XP Professional操作系統(tǒng)，網(wǎng)卡帶寬100 Mbit/s。

（3）支持TCP/IP協(xié)議。

（4）服務(wù)器端有真實的IP地址。

（5）服務(wù)器所在網(wǎng)絡(luò)的防火墻設(shè)置特定監(jiān)聽端口。

（6）在該系統(tǒng)中是客戶端向服務(wù)器端發(fā)起連接請求信號，所以服務(wù)器端要與Internet保持暢通。保證服務(wù)器端與客戶端之間加密安全通道建立成功。

2.2.2 服務(wù)器端和客戶端流程

該系統(tǒng)的服務(wù)器端有通信握手和數(shù)據(jù)傳輸2個部分。通信握手需要建立與客戶端的TCP連接，與客戶端同步AES密鑰和建立數(shù)據(jù)安全傳輸通道；數(shù)據(jù)傳輸從客戶端接收數(shù)據(jù)包、解密系統(tǒng)數(shù)據(jù)包、判斷數(shù)據(jù)包有效性、處理數(shù)據(jù)包，并向客戶端發(fā)送確認數(shù)據(jù)包和系統(tǒng)控制信息。服務(wù)器端是一對多的模式，服務(wù)器處理多個客戶端的連接請求和數(shù)據(jù)傳輸，所以服務(wù)器端需要一個單獨的線程來執(zhí)行數(shù)據(jù)傳輸，而主線程可以繼續(xù)接收下一個客戶端發(fā)來的請求，直到接收完數(shù)據(jù)包，關(guān)閉服務(wù)器端口，如圖1。

圖1 服務(wù)器端流程圖

同樣，客戶端的處理流程和服務(wù)器端很相似，也分為通信握手和數(shù)據(jù)傳輸2部分。服務(wù)器端解密數(shù)據(jù)包，發(fā)現(xiàn)錯誤信息并反饋給客戶端后，客戶端要重發(fā)數(shù)據(jù)包，保證系統(tǒng)的完整性，如圖2。

圖2 客戶端流程圖

服務(wù)器測試運行時可接收多個客戶的多次請求，也可以接收多個客戶的同時請求，直到測試結(jié)束。

系統(tǒng)客戶端程序在運行時必須輸入兩個參數(shù)，服務(wù)器端的IP地址和需要加密的文件傳輸路徑。根據(jù)不同的測試請求，可單一客戶端運行，也可多個客戶端運行。

2.3 系統(tǒng)性能測試

2.3.1 單個客戶端用戶性能檢測

通過檢測6個數(shù)據(jù)文件，得到系統(tǒng)傳輸時間和數(shù)據(jù)大小的關(guān)系，如圖3。

圖3 單個客戶端數(shù)據(jù)大小與傳輸時間的曲線圖

從圖3可知，文件在混合加密系統(tǒng)中的傳輸時間與數(shù)據(jù)文件的大小呈近似線形增長。

單客戶端數(shù)據(jù)大小與傳輸速率的關(guān)系如圖4。

圖4 單個客戶端數(shù)據(jù)大小與傳輸速率的曲線圖

從圖4可知，數(shù)據(jù)傳輸?shù)乃俣入S著文件的增大而增長，但并不是線性增長。隨著數(shù)據(jù)的增大，傳輸速率保持在170 kbit/s左右。

2.3.2 多個客戶端性能檢測

在系統(tǒng)測試中，混合加密系統(tǒng)的服務(wù)器接收多個客戶端的連接請求和數(shù)據(jù)傳輸。通過對測試的6個文件得出6組數(shù)據(jù)，描繪出在多用戶狀態(tài)下，數(shù)據(jù)大小與傳輸速度之間的關(guān)系，如圖5。

圖5 多個客戶端數(shù)據(jù)大小與傳輸速度的曲線圖

通過圖5，可以發(fā)現(xiàn)，隨著客戶端增多，每個客戶端的傳輸速率要比單個傳輸時的速率有所下降，但是系統(tǒng)總速率要比單客戶有較大增長。在本系統(tǒng)中，服務(wù)器端從安全通道中接收數(shù)據(jù)，在數(shù)據(jù)傳輸過程中，服務(wù)器端主要將時間消耗在對加密數(shù)據(jù)進行解密。而Borzio算法庫中AES算法的加密時間比解密時間長很多。

對系統(tǒng)的總速率與客戶端個數(shù)的分析如圖6。

圖6 客戶端個數(shù)與系統(tǒng)速度的曲線圖

由圖6可知，隨著客戶端個數(shù)的增加，系統(tǒng)的速率也逐漸增加，并且速率穩(wěn)定在600 kbit/s。

3 結(jié)束語

本文在C++平臺下實現(xiàn)了混合加密算法的仿真系統(tǒng)。研究結(jié)果表明：在IPSec VPN的數(shù)據(jù)通信中，混合加密算法具有更高的安全性和可執(zhí)行性，有效地增強了VPN的數(shù)據(jù)安全性。

目前，本文提出的混合加密算法的仿真系統(tǒng)還不夠完善，對它的研究、分析、測試和應(yīng)用尚處于初級階段，有待進一步提高。

[1] 董尼. 基于AES與ECC的混合密碼[D] . 合肥：合肥工業(yè)大學(xué)，2006，4.

[2] 涂志強. VPN技術(shù)研究及在油田的應(yīng)用[D] . 北京：中國地質(zhì)大學(xué)，2006，4.

[3] 鄺獻濤. IPSec協(xié)議分析研究[D] . 長沙：湖南師范大學(xué)，2004，4.

[4] 馮娟娟. 加速ECC算法的相關(guān)算法研究[D] .北京：信息工程大學(xué)，2006，4.

[5] 楊成威. 基于AES和ECC的混合密碼系統(tǒng)研究[J/OL] . 河南科學(xué)， 2006， 24（2）.

[6] 侯整風(fēng)，李嵐.橢圓曲線密碼系統(tǒng)(ECC)整體算法設(shè)計及優(yōu)化研究[J/OL] .電子學(xué)報，2004（11）：145-147.

[7] 潘茜. 基于IPSec VPN的安全策略研究[D] . 西安：西安電子科技大學(xué)，2007，1.