專利名稱：基于pki的vpn密鑰交換的實現(xiàn)方法
技術(shù)領(lǐng)域：
本發(fā)明涉及基于IP的網(wǎng)絡(luò)安全技術(shù)，尤其涉及基于PKI的VPN密鑰交換的實現(xiàn)方法。
背景技術(shù)：
Internet RFC2764，RFC2401，RFC2407-RFC2412詳細(xì)描述了基于IP的虛擬專用網(wǎng)絡(luò)體系結(jié)構(gòu)、IP安全協(xié)議結(jié)構(gòu)和IKE(The Internet Key Exchange)即Internet密鑰交換技術(shù)。IKE是IPsec目前唯一正式確定的密鑰交換協(xié)議，并作為ISAKMP的一部分使用，它給AH或ESP提供密鑰交換支持，同時也支持VPN密鑰協(xié)商機制。在ISAKMP中密鑰交換是獨立的，可以支持不同的密鑰交換方式。
IKE使用ISAKMP定義的“階段”概念。其中第一階段是指兩個ISAKMP對等端(peer)建立安全認(rèn)證的通信通道和ISAKMP安全關(guān)聯(lián)(SA)，運行在該階段下的有“主模式”(Main Mode)和“進取模式”(Aggressive Mode)，其中前者是必需的，后者是可選的。第二階段對安全關(guān)聯(lián)可提供的服務(wù)以及這些服務(wù)所需要的密鑰和(或)參數(shù)進行協(xié)商，該階段下運行的有必須實現(xiàn)的“快速模式”(Quick Mode)，它提供密鑰更新功能。此外還有必須在第一階段后運行的“新組模式”(New Group Mode)，它用于定義Diffie-Hellman專用組。
(1)IKE第一階段(Phase1)主模式(Main Mode)ISAKMP通過協(xié)商建立雙向的安全連接，其中必須協(xié)商的內(nèi)容有加密算法(必須包括CBC模式的DES，也應(yīng)該支持3DES)、散列算法(必須包括MD5和SHA)、認(rèn)證方式、Diffie-Hellman信息。
在階段1中，首先建立ISAKMP安全關(guān)聯(lián)(ISAKMP SA)。這樣，所有通信雙方的IKE通信可以被認(rèn)證加密并得到完整性校驗。IKE階段1建立的安全通道可以保證階段2的協(xié)商通信。在發(fā)送者I和接收者R之間共有6條消息交互。
消息1中，發(fā)送者I在ISAKMP報頭(Header)中產(chǎn)生Cookie_I(CI)和ISAKMP荷載(Payload)(ISAI)，ISAI包括安全關(guān)聯(lián)荷載(SA Payload)和一組建議(Proposals)及每個建議可選擇的一組變換(Transforms)；消息2中，接收者R在ISAKMP報頭中產(chǎn)生CR并響應(yīng)其中的一個建議和變換回應(yīng)發(fā)送者I；消息3和4分別包含了通信雙方各自產(chǎn)生的隨機數(shù)(Nonce)NI和NR，Nonce是一個64-2048bit的大隨機數(shù)，用來增加密鑰協(xié)商過程的熵(或隨機度)，它還可以保證每次會話的新鮮性(Liveliness)，即每次會話只用一個Nonce，從而避免了重發(fā)攻擊(Replay Attack)；消息5和6是用消息1和2中已協(xié)商的加密算法進行了加密(用*表示已加密)。加密消息中包含了雙方各自的身份IDI和IDR以及以消息認(rèn)證碼(MAC)形式出現(xiàn)的認(rèn)證數(shù)據(jù)AUTHI和AUTHR。其中身份IDI和IDR可以是預(yù)先唯一確定的用戶或主機名，如IP地址，合法的域名(FQDN，F(xiàn)ull Qualified Domain Name)，證書或Email地址等。
(2)密鑰材料的獲取在使用加密和散列算法時采用不同的密鑰，主密鑰SKEYID的值由不同的認(rèn)證方法確定。在IKE的主模式或進取模式中，共有四種認(rèn)證方法，分別是數(shù)字簽名認(rèn)證方式、兩種用公鑰加密的認(rèn)證方式和預(yù)共享密鑰認(rèn)證方式。SKEYID由所選的認(rèn)證方法獨立計算，具體是數(shù)字簽名認(rèn)證方式 SKEYID＝hashfunc(Ni|Nr，k)公鑰加密的認(rèn)證方式SKEYID＝hashfunc(hashfunc(Ni|Nr)，CI|CR)預(yù)共享密鑰認(rèn)證方式SKEYID＝hashfunc(PSKEY，Ni|Nr)(3)主模式中的數(shù)字簽名認(rèn)證方式IKE中最常用的是建立在公共密鑰基礎(chǔ)上的數(shù)字簽名認(rèn)證方式。數(shù)字簽名可采用DSA算法或RSA算法，公共密鑰通常是從證書中獲取的，而IKE允許證書的交換，而且也允許從一個遠(yuǎn)程通信方那里索取證書。通信雙方各自用自己的私鑰對HASHI和HASHR進行簽名。
圖中，數(shù)字簽名為SIGI＝PRVKEYI(HASHI)SIGR＝PRVKEYR(HASHR)由于采用了可選的載荷，所以我們既可以請求證書(Cert-Req載荷)，又可以交換證書(Cert載荷)，數(shù)字簽名是無法抵賴的，只要每一方都保留了同IKE會話對應(yīng)的狀態(tài)，它們就可以確定無疑地證明自己是在同一個特定的實體進行通信。
但是，現(xiàn)有的IKE未對證書如何獲取和驗證作進一步的說明，只給出了數(shù)字簽名認(rèn)證方式中證書作為可選項的定義，未詳細(xì)描述，也未給出具體的實現(xiàn)方法。

發(fā)明內(nèi)容
本發(fā)明的目的是針對IKE的不足，提出利用PKI(Public Key Infrastructure)即公共密鑰基礎(chǔ)設(shè)施基礎(chǔ)平臺來實現(xiàn)IKE密鑰交換中設(shè)備的身份認(rèn)證。以PKI為基礎(chǔ)的數(shù)字簽名提供了認(rèn)證和完整性，以PKI為基礎(chǔ)的加密術(shù)提供了機密性。PKI能支持控制訪問敏感信息的權(quán)限的努力和提供交易信息的認(rèn)證證據(jù)，或記錄其發(fā)起者，PKI能對VPN通信的安全提供一種可靠的技術(shù)和法律基礎(chǔ)。
本發(fā)明的目的是這樣實現(xiàn)的，一種基于PKI的VPN密鑰交換的實現(xiàn)方法利用PKI基礎(chǔ)設(shè)施平臺來實現(xiàn)IKE密鑰交換中設(shè)備的身份認(rèn)證，其具體步驟如下a.第一階段為主模式，數(shù)字簽名認(rèn)證方式，在發(fā)送者和接收者之間共有6條消息交互，包括，①消息1和消息2用來協(xié)商安全關(guān)聯(lián)的特性，所述消息1和消息2以明文方式傳輸，且沒有身份認(rèn)證，所述消息1中，發(fā)起者有提出好幾條建議，每條建議給出一個協(xié)議，且每個協(xié)議中可以定義幾種轉(zhuǎn)換，消息2中響應(yīng)者只能選擇一條建議，如圖1所示；消息3和消息4交換現(xiàn)時值nonce，同時用響應(yīng)方的Diffie-Hellman基本的密鑰交換方法交換建立一個主密鑰，如圖2所示；③消息5和消息6交換通信雙方互相認(rèn)證所需的信息，其中包含了證書和發(fā)送者的數(shù)字簽名，如圖3所示；④消息5和消息6的內(nèi)容由所述消息1到消息4建立的密碼算法和密鑰來保護，其中身份IDI和IDR可以是預(yù)先唯一確定的用戶或主機名；第二階段，快速模式，該模式目的是產(chǎn)生一個非ISAKMP SA(如ESP SA或AH SA)。包括，①消息1的IPSec安全關(guān)聯(lián)(SA)荷載中可以包含一組建議，消息2只能選擇一條建議，密鑰交換荷載在系統(tǒng)要求完美前向保密時才存在，且散列(Hash)荷載必須緊接在ISAKMP報頭之后，如圖4所示；即先是ISAKMP荷載，然后是Hash荷載，接下去是SA荷載等等。
②消息3將散列(Hash)結(jié)果傳送給接收者，如圖5所示。
上述的消息5和消息6用于交換通信雙方互相認(rèn)證所需的信息。消息5和消息6的內(nèi)容由消息1到消息4建立的密碼算法和密鑰來保護。其中身份IDI和IDR可以是預(yù)先唯一確定的用戶或主機名，如IP地址，合法的域名(FQDN，F(xiàn)ull Qualified Domain Name)或Email地址等。證書可以有多種選擇，但應(yīng)用最為廣泛的是X.509證書，X.509方案的核心是與每個用戶聯(lián)系的公開密鑰證書。這些用戶證書采取由某些可信證書授權(quán)機構(gòu)(CA)創(chuàng)建，由CA或用戶放在目錄中。目錄服務(wù)其本身不負(fù)責(zé)公開密鑰的生成或證書函數(shù)，它僅提供一個易于訪問的位置以便用戶獲得證書。
X.509也包括三個可選的認(rèn)證過程——單向認(rèn)證，雙向認(rèn)證，三向認(rèn)證以供不同的應(yīng)用使用。所有這些過程都使用公開密鑰簽名。它假定雙方都知道對方的公開密鑰，或者通過從目錄獲得對方的證書，或者證書被包含在每方的初始報文中。
本發(fā)明采用X.509證書來確保身份(Identity)的正確性，同時也向接收消息者提供發(fā)送消息者的公共密鑰，用來驗證數(shù)字簽名。從而保證使IKE階段1建立的安全通道可以保證階段2的協(xié)商通信。
在圖6中，VPN網(wǎng)關(guān)1發(fā)送自己的X.509證書給VPN網(wǎng)關(guān)2，VPN網(wǎng)關(guān)2收到含VPN網(wǎng)關(guān)1公鑰(由CA簽發(fā))的證書后，便到目錄服務(wù)器去查詢和驗證證書是否有效，以認(rèn)證中心的公共密鑰驗證此證書，若是驗證正確，則相信認(rèn)證中心的公正性，進而相信此證書是正確的，也相信了證書中所含公鑰的正確性。這樣將網(wǎng)絡(luò)上需要對每個實體都必須認(rèn)證的問題，收斂到對認(rèn)證中心的認(rèn)證，只要取得認(rèn)證中心正確的公鑰，就可以驗證證書進而驗證發(fā)送者數(shù)字簽名的有效性。
本發(fā)明完成了基于LINUX操作系統(tǒng)的客戶機/服務(wù)器IKE密鑰交換缺省認(rèn)證的方法，提出將PKI與VPN緊密集成，彌補了IKE中未對證書如何獲取和驗證作詳細(xì)描述的不足，充分保證基于IPSec的VPN網(wǎng)絡(luò)密鑰交換的安全性。


圖1消息1和消息2報文格式圖2消息3和消息4報文格式圖3消息5和消息6報文格式圖4快速模式消息1和消息2報文格式圖5快速模式消息3報文格式圖6基于PKI的企業(yè)Intranet VPN方案圖7實施例編程框圖
具體實施例方式
下面結(jié)合附圖以及實施例對本發(fā)明作進一步說明。
圖6為基于PKI的企業(yè)Intranet VPN的構(gòu)建方案，PKI管理中心14包含證書授權(quán)機構(gòu)CA(Certificate Authority)和證書注冊機構(gòu)RA(Registration Authority)，它提供產(chǎn)生、分發(fā)、撤消、認(rèn)證等服務(wù)，以及不同CA之間的交叉認(rèn)證。PKI管理中心14將證書信息和證書撤消信息CRL(Certificate Revocation List)放在證書庫中，通常證書庫采用X.500目錄服務(wù)或輕量級目錄訪問協(xié)議LDAP來實現(xiàn)，即將證書及其相關(guān)信息放在目錄服務(wù)器中供用戶訪問。VPN網(wǎng)關(guān)1發(fā)送自己的X.509證書給VPN網(wǎng)關(guān)2，VPN網(wǎng)關(guān)2收到含VPN網(wǎng)關(guān)1公鑰(由CA簽發(fā))的證書后，便到目錄服務(wù)器12去查詢和驗證證書是否有效，以認(rèn)證中心的公共密鑰驗證此證書，若是驗證正確，則相信認(rèn)證中心的公正性，進而相信此證書是正確的，也相信了證書中所含公鑰的正確性。這樣將網(wǎng)絡(luò)上需要對每個實體都必須認(rèn)證的問題，收斂到對認(rèn)證中心的認(rèn)證，只要取得認(rèn)證中心正確的公鑰，就可以驗證證書進而驗證發(fā)送者數(shù)字簽名的有效性。
編程框圖如圖7所示，右邊的兩個模塊，包括套接字層21、傳輸層協(xié)議22、IP24、鏈路層協(xié)議25、應(yīng)用層進程17和應(yīng)用層協(xié)議19為TCP/IP協(xié)議棧，上方的ISAKMP為應(yīng)用層協(xié)議，通過應(yīng)用程序編程接口API20為安全協(xié)議模塊23(如認(rèn)證協(xié)議AH、安全負(fù)載封裝協(xié)議ESP)提供安全關(guān)聯(lián)和密鑰管理，而密鑰交換定義模塊18此處為Internet密鑰交換協(xié)議IKE，解釋域模塊DOI(Domain Of Interpretation)15則用來說明IPSec中的交換類型、荷載格式和處理方法等。本方法的演示程序利用套接口(sockets)API20在Linux操作系統(tǒng)下開發(fā)，演示了IKE兩個階段的密鑰交換過程，在第一階段，選用主模式(Main mode)，一共六條消息；第二階段，采用快速模式(Quick mode)，共三條消息。
第一階段如圖1所示，消息1提出一個或幾個關(guān)于“保護套件”的題案，“保護套件”是一組參數(shù)，包括加密算法，散列算法，驗證方法，以及Diffe-Helllman組，作為轉(zhuǎn)換載荷(transformpayload)。例如，我們可以選用DES CBC或3DES CBC作為加密算法，SHA-1或MD5作為散列算法，驗證方法選用DSS算法或預(yù)共享密鑰，Diffe-Helllman組選用一個含768位模數(shù)的MODP組，模數(shù)為FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF格式如下例消息2根據(jù)消息1中的題案，選取一組合適的參數(shù)，作為“保護套件”。例如，加密算法采用DES CBC，散列算法采用SHA-1，驗證方法采用預(yù)共享密鑰，Diffe-Helllman組選用768位模數(shù)的MODP組。
以下各項數(shù)據(jù)從同一次密鑰交換過程中得到。
<pre listing-type="program-listing"><![CDATA
]></pre>如圖2所示，消息3交換兩個消息，其一為發(fā)起方的Diffe-Helllman公共密鑰，假設(shè)xi為發(fā)起方的私鑰，則g^xi(在MODP768組中，g取2)就是其Diffe-Helllman公共密鑰，私鑰是隨機產(chǎn)生的，只有發(fā)送方知道，接收方或截獲者很難通過g^xi求出xi來。另一個為發(fā)起方的nonce，它是個偽隨機序列。消息3格式如下例<pre listing-type="program-listing"><![CDATA
]></pre>某次演示中得出的g^xi為cc8f 80d2 ccab ca21 3c20 3c98 a69c 882e b70a 86c6 78ae bfcc cd72 a21f cdd2e8be 9b6f e9a2 5245 ff54 8e78 c73a 14ea 6217 6722 c747 51bd 6f71 6658 b2a9 af3dd9a5 9ba2 4828 08f3 8a03 b811 838b fa8f 429c 86b5 5b62 551f 948e ef5f 7bbb 6cd8f063得出的發(fā)起方nonce為a946f020699f27ba13d4980cbba80aef消息4與消息3類似，即交換響應(yīng)方的Diffe-Helllman公共密鑰和nonce，假設(shè)g^xr表示響應(yīng)方的Diffe-Helllman公共密鑰，某次演示中得出的g^xr值為
d1f9 1f74 6b16 0e7e 14b6 8856 be78 ecc2 faed de04 ef9c da96 85ba e348 d0e18d26 84fd 88a1 43ba 65bf e089 3f5e 763d d741 4bc8 625d 176f fd32 c70f 71cd c8efbe03 fcdb 5dcc 97fc 6e02 9152 baef 70d9 970e dfd6 411e 94f5 8dc3 8262 8257 f1cd691b響應(yīng)方nonce為f106115c9b6325c426c3eeef1e9124e8根據(jù)前四條消息提供的信息，求出一組密鑰如果采用簽名驗證，SKEYID＝prf(Ni_b|Nr_b，g^xy)如果采用公鑰加密，SKEYID＝prf(hash(Ni_b|Nr_b)，CKY-I|CKY-R)如果采用預(yù)共享密鑰，SKEYID＝prf(pre-shared-key，Ni_b|Nr_b)SKEYID_d＝prf(SKEYID，g^xy|CKY-I|CKY-R|0)SKEYID_a＝prf(SKEYID，SKEYID_d|g^xy|CKY-I|CKY-R|1)SKEYID_e＝prf(SKEYID，SKEYID_a|g^xy|CKY-I|CKY-R|2)SKEYID_d用于生成IPSec的密鑰，SKEYID_a用來保障IKE消息的完整性并對數(shù)據(jù)源身份進行驗證，SKEYID_e用于對IKE消息進行加密。
這次演示得到的這組密鑰如下SKEYID＝ccff491b8075c2d6351cf99f3895c4fe3c941cdeSKEYID_d＝475cd7edec45f582d98295ada94b4c085c22b881SKEYID_a＝d23c6e33503e2c8ebc2dbb68cbf0bcde561cff4bSKEYID_e＝191c1a3a77163ecce87aec4fe0711d65515f9f81如圖3所示，消息5和6用來對本次密鑰交換進行驗證，方法是通信雙方各計算出一個散列結(jié)果，對發(fā)起方HASH_I＝prf(SKEYID，g^xi|g^xr|CKY-I|CKY-R|SAi_b|IDii_b)對響應(yīng)方HASH_R＝prf(SKEYID，g^xr|g^xi|CKY-R|CKY-I|SAi_b|IDir_b)IDii_b及IDir_b分別代表發(fā)起方和響應(yīng)方的身份。如果采用預(yù)共享密鑰驗證，只需根據(jù)已知信息，計算出與接收到的散列相對應(yīng)的結(jié)果，如果相符，即驗證通過。如果采用簽名驗證，還需要對散列結(jié)果用公鑰進行簽名，雙方驗證簽名后的結(jié)果。這兩條消息需要用SKEYID_e進行加密。
快速模式本身不是一個完整的交換過程，它只是SA協(xié)商過程中的第二階段中的一種模式?？炷Ｊ奖仨氃诘谝浑A段完成之后進行，受到第一階段得到的ISAKMP SA的保護，為其他的非ISAKMP SA協(xié)商安全策略及交換相應(yīng)的密鑰。所以快模式中的交換數(shù)據(jù)除了ISAKMP頭之外，都是加密傳輸?shù)摹?br> 如圖4所示，消息1中，ISAKMP頭與第一階段的基本相同。但isa_xchg應(yīng)設(shè)為ISAKMP_XCHG_QUICK，并把加密比特位置位為1，而在第一階段中是不加密的，相應(yīng)位為0。Icookie和rcookie對應(yīng)于第一階段相應(yīng)的cookie，以表示此快模式是在該ISAKMPSA的保護下進行的。而message ID是此快模式獨有的，用來標(biāo)示同一個，當(dāng)然也可能不同的ISAKMP SA保護下的不同的快模式交換。這樣有了不同的message ID，就可以并發(fā)進行多個快模式交換了。ISAKMP頭中的載荷長度應(yīng)包括加密填充后的整體長度。
對于HASH載荷，由于在作散列運算時要涉及到下面的載荷，所以放在所有的載荷處理完之后進行處理。
下面就是SA載荷，包括若干個建議，以及一個建議中相應(yīng)的若干個轉(zhuǎn)換。在這里我們只提一個建議，就是AH，當(dāng)然也可以提ESP，或者兩者都提。在AH建議中，我們又提供了兩個轉(zhuǎn)換，其一為AH_SHA；其二為AH_MD5，相應(yīng)于提供的AH的兩種建議算法，供給相應(yīng)端選擇。對于每一個建議都對應(yīng)于一個唯一的SPI(4字節(jié))再下來是Nonce載荷，用隨即數(shù)得到。然后是兩個ID載荷，分別對應(yīng)于發(fā)起端和相應(yīng)端。這里，我們把發(fā)起端及相應(yīng)端的IP地址最為其標(biāo)識數(shù)據(jù)。
接下來，就是遺留下來的HASH載荷了。散列數(shù)據(jù)按以下公式得到HASH＝prf(SKEYID_a，M_ID|SA|Nonce_I|ID_I|ID_r)其中，prf是第一階段協(xié)商好的單向散列函數(shù)，SKEYID_a是第一階段得到的認(rèn)證密鑰，下面的就是當(dāng)前消息中的數(shù)據(jù)。
這樣整個消息就完成了，為了安全期間，要用第一階段協(xié)商好的加密算法和相應(yīng)的密鑰對這個消息加密。當(dāng)然為了加密，可能會產(chǎn)生填充數(shù)據(jù)，這也應(yīng)該算在消息長度中。
最后就是把加密了的第一條消息發(fā)送出去。
消息2對消息1提供的建議做出選擇，并把結(jié)果告訴發(fā)起端。
消息2的構(gòu)成與消息1類似，區(qū)別在于SA載荷，相應(yīng)端要根據(jù)自己的安全策略選擇發(fā)起端提供的安全建議。所以對于多個建議可能選其中的一個，或者一些，而對于轉(zhuǎn)換，對應(yīng)一個建議只能選一個轉(zhuǎn)換。在這里，我們的建議是AH，選擇MD5算法。
接受到第一條消息后，首先要進行的是解密，解密的算法和密鑰是從第一階段的交換中得到的。通過加密傳輸消息，消息的安全性得到了保證。解密成功后可以得到原始消息，相應(yīng)端按照原始消息重新計算HASH，公式同上，并把計算結(jié)果與隨消息傳送過來的HASH結(jié)果相比較，如果不同，說明傳輸過程中出錯了，或者有人惡意修改了消息中的某些數(shù)據(jù)。這樣消息的完整性得到了保證。
首先通過cookie和message ID可以唯一的確定一次交換，這樣如果收到了不同交換的第一條消息，就可以丟棄。如果一切正常，那么相應(yīng)端加入自己的Nonce，即Nonce_r，這樣對應(yīng)于不同的建議，就有了相應(yīng)唯一確定的SPI，算法和相應(yīng)的密鑰，其中得到密鑰的算法如下KEYMAT＝prf(SKEYID_d，protocao|SPI|Nonce_i|Nonce_r)其中的SKEYID_d也是第一階段得到的，Nonce是確定的，但SPI是不同的，這樣得到的密鑰也是不一樣的。
對應(yīng)于消息2的HASH算法如下HASH＝prf(SKEYID_a，M-ID|Nonce_i|SA|Nonce_r|ID_I|ID_r)這樣第二條消息就處理好了，下面就是對其加密，發(fā)送。
如圖5所示，消息3要簡單很多，主要是接受相應(yīng)端的選擇，并向相應(yīng)端發(fā)送確認(rèn)消息。
消息3只由兩部分構(gòu)成，ISAKMP頭和消息摘要。
同樣地，先是解密和驗證消息完整性的過程。通過以后，是讀取響應(yīng)端的選擇結(jié)果，并根據(jù)相應(yīng)端的Nonce計算出相應(yīng)SPI的密鑰，計算公式同上。
這樣就得到了保護數(shù)據(jù)傳輸?shù)陌踩惴跋鄳?yīng)的密鑰，安全的數(shù)據(jù)傳輸通道建立起來了。下面就是給相應(yīng)端發(fā)送一個確認(rèn)消息。
確認(rèn)消息中的HASH算法如下HASH＝prf(SKEYID_a，0|M-ID|Nonce_i|Nonce_r)在進行散列運算前，首先是要填充1字節(jié)的0。
最后就是加密，發(fā)送。
最后，響應(yīng)端接受到發(fā)起端的確認(rèn)信息，經(jīng)過解密和完整性驗證，整個快模式交換過程就結(jié)束了。下面就可以在建立起來的IPsec安全通道上進行安全的通信了。
權(quán)利要求
1.一種基于PKI的VPN密鑰交換的實現(xiàn)方法，其特征在于，所述實現(xiàn)方法利用PKI基礎(chǔ)設(shè)施平臺來實現(xiàn)IKE密鑰交換中設(shè)備的身份認(rèn)證，其具體步驟如下a.第一階段，主模式數(shù)字簽名認(rèn)證方式，在發(fā)送者和接收者之間共有6條消息交互，包括，①消息1和消息2用來協(xié)商安全關(guān)聯(lián)的特性，所述消息1和消息2以明文方式傳輸，且沒有身份認(rèn)證，所述消息1中，發(fā)起者有提出好幾條建議，每條建議給出一個協(xié)議，且每個協(xié)議中可以定義幾種轉(zhuǎn)換，消息2中響應(yīng)者只能選擇一條建議；②消息3和消息4交換nonce，同時用響應(yīng)方的Diffie-Hellman交換建立一個主密鑰③消息5和消息6交換通信雙方互相認(rèn)證所需的信息，其中包含了證書和發(fā)送者的數(shù)字簽名；④消息5和消息6的內(nèi)容由所述消息1到消息4建立的密碼算法和密鑰來保護，其中身份IDI和IDR可以是預(yù)先唯一確定的用戶或主機名；b.第二階段，快速模式，包括，①消息1的IPSec安全關(guān)聯(lián)(SA)荷載中包含一組建議，消息2只能選擇一條建議，密鑰交換荷載在系統(tǒng)要求完美前向保密時才存在，且散列(Hash)荷載必須緊接在ISAKMP報頭之后；②消息3將散列(Hash)結(jié)果傳送給接收者。
2.如權(quán)利要求1所述的實現(xiàn)方法，其特征在于，所述認(rèn)證選用的證書是X.509證書，所述用戶證書由可信證書授權(quán)機構(gòu)(CA)創(chuàng)建，由CA或用戶放在目錄中，所述目錄服務(wù)本身不負(fù)責(zé)公開密鑰的生成或證書函數(shù)，它僅提供一個易于訪問的位置使用戶獲得證書。
3.如權(quán)利要求2所述的實現(xiàn)方法，其特征在于，所述X.509證書包括三個可選的認(rèn)證過程，單向認(rèn)證，雙向認(rèn)證，三向認(rèn)證，所述認(rèn)證過程都使用公開密鑰簽名，設(shè)定發(fā)送者和接收者都知道對方的公開密鑰，或者通過從目錄獲得對方的證書，或者證書被包含在每方的初始報文中。
4.如權(quán)利要求2所述的實現(xiàn)方法，其特征在于，所述X.509證書向接收消息者提供發(fā)送消息者的公共密鑰。
全文摘要
本發(fā)明提出基于PKI的VPN密鑰交換的實現(xiàn)方法。該方法是針對IKE的不足,提出利用PKI(Public Key Infrastructure)即公共密鑰基礎(chǔ)設(shè)施基礎(chǔ)平臺來實現(xiàn)IKE密鑰交換中設(shè)備的身份認(rèn)證。以PKI為基礎(chǔ)的數(shù)字簽名提供了認(rèn)證和完整性,以PKI為基礎(chǔ)的加密術(shù)提供了機密性。PKI能支持控制訪問敏感信息的權(quán)限的努力和提供交易信息的認(rèn)證證據(jù),或記錄其發(fā)起者,PKI能對VPN通信的安全提供一種可靠的技術(shù)和法律基礎(chǔ)。
文檔編號H04L9/14GK1350382SQ01132348
公開日2002年5月22日 申請日期2001年11月29日 優(yōu)先權(quán)日2001年11月29日
發(fā)明者胡愛群, 曹秀英, 吳越, 疏朝明, 卜勇華, 宋宇波, 王興建 申請人:東南大學(xué)