本申請涉及互聯(lián)網(wǎng)技術(shù)領(lǐng)域，尤其涉及一種英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證方法及裝置。

背景技術(shù)：

隨著遠(yuǎn)程訪問中心資源需求的增加，相應(yīng)地推出了遠(yuǎn)程訪問技術(shù)。

通常，在進(jìn)行遠(yuǎn)程訪問過程中，通信的雙方需要先進(jìn)行密鑰協(xié)商，從而保證通信過程中數(shù)據(jù)的安全。這一過程稱之為密鑰管理協(xié)議(Internet Key Exchange，IKE),并且協(xié)商出來的結(jié)果稱之為安全聯(lián)盟(Security Association，SA)。

具體地，所述IKE協(xié)商的過程可以分為兩次協(xié)商階段：第一次協(xié)商階段和第二次協(xié)商階段。所述第一次協(xié)商階段用于協(xié)商雙方公共的用于保護(hù)第二階段的第一密鑰，即IKE SA；所述第二次協(xié)商階段用于協(xié)商保護(hù)傳輸?shù)臄?shù)據(jù)的第二密鑰，即IPSec SA。也就是說，IKE協(xié)商出來的SA包括了兩個(gè)部分即IKE SA和IPSec SA。為了進(jìn)一步增加數(shù)據(jù)的安全，所述IKE提出了一種重協(xié)商機(jī)制，即對于所述第一次協(xié)商階段和第二次協(xié)商階段得出的密鑰都會存在一個(gè)生命周期(lifetime)，在所述生命周期到后，當(dāng)前密鑰就會失效，需要雙方重新協(xié)商新的密鑰。如此，即使原有的密鑰被破解，也無法解密用新的密鑰保護(hù)的數(shù)據(jù)。

現(xiàn)有技術(shù)中，在IKE初次協(xié)商時(shí)，客戶端會需要進(jìn)行擴(kuò)展認(rèn)證(Extended Authentication Protocol，EAP認(rèn)證)，如果所述客戶端通過了EAP認(rèn)證，則后續(xù)IKE重協(xié)商就無需新進(jìn)行EAP認(rèn)證。然而，由于IKE重協(xié)商和IKE初次協(xié)商無關(guān)聯(lián)，所以無法確保IKE重協(xié)商和IKE初次協(xié)商的客戶端是同一個(gè)客戶端。如此，就會存在安全的問題。

技術(shù)實(shí)現(xiàn)要素：

本申請?zhí)峁┑挠⑻鼐W(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證方法及裝置，以解決現(xiàn)有技術(shù)中IKE重協(xié)商時(shí)存在的安全問題。

根據(jù)本申請實(shí)施例提供的一種英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證方法，所述方法包括：

在IKE重協(xié)商的第一次協(xié)商階段，本端設(shè)備通過上一次與對端設(shè)備IKE協(xié)商得到的SA將所述本地設(shè)備的ID進(jìn)行加密；

將所述加密后的ID發(fā)送至所述對端設(shè)備；

在收到對端設(shè)備發(fā)送的ID后，通過所述上一次與對端設(shè)備IKE協(xié)商得到的SA進(jìn)行解密；

判斷所述解密后的ID與上一次協(xié)商時(shí)得到的ID是否一致；

在所述解密后的ID與上一次協(xié)商時(shí)得到的ID一致的情況下，認(rèn)證通過。

可選的，所述英特網(wǎng)密鑰管理協(xié)議為IKEv1。

可選的，所述SA為IKE SA。

根據(jù)本申請實(shí)施例提供的一種英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證裝置，所述裝置包括：

加密單元，用于在IKE重協(xié)商的第一次協(xié)商階段，本端設(shè)備通過上一次與對端設(shè)備IKE協(xié)商得到的SA將所述本地設(shè)備的ID進(jìn)行加密；

發(fā)送單元，用于將所述加密后的ID發(fā)送至所述對端設(shè)備；

解密單元，用于在收到對端設(shè)備發(fā)送的ID后，通過所述上一次與對端設(shè)備IKE協(xié)商得到的SA進(jìn)行解密；

判斷單元，用于判斷所述解密后的ID與上一次協(xié)商時(shí)得到的ID是否一致；

確定單元，用于在所述解密后的ID與上一次協(xié)商時(shí)得到的ID一致的情況下，認(rèn)證通過。

可選的，所述英特網(wǎng)密鑰管理協(xié)議為IKEv1。

可選的，所述SA為IKE SA。

本申請實(shí)施例中，在進(jìn)行重協(xié)商的第一次協(xié)商階段，本端設(shè)備可以通過上一次IKE協(xié)商得到的SA將所述本端設(shè)備的ID進(jìn)行加密，并向?qū)Χ嗽O(shè)備發(fā)送該加密后的ID；由于重協(xié)商是兩端同時(shí)進(jìn)行的，所以對端設(shè)備也會發(fā)送一個(gè)加密后的ID；所以，本地在收到所述對端設(shè)備發(fā)送的ID后，可以通過所述上一次IKE協(xié)商得到的SA進(jìn)行解密；解密后再判斷ID是否一致，只有ID一致的情況下，才可以認(rèn)證通過。也就是說只有具有上一次SA的對端設(shè)備才能保證重協(xié)商的成功，如果重協(xié)商的對端設(shè)備與上一次協(xié)商的對端設(shè)備不是同一臺設(shè)備，那么本次協(xié)商的對端設(shè)備也就不具有上一次協(xié)商的SA，那么即使在盜用ID的情況下也會由于沒有上一次的SA無法實(shí)現(xiàn)正確加密，而本端設(shè)備也就無法解密得到ID。這就將本次協(xié)商與上一次協(xié)商相關(guān)聯(lián)，從而保證了其它設(shè)備在重協(xié)商時(shí)無法認(rèn)證通過，這樣即使不進(jìn)行EAP認(rèn)證也可以確保重協(xié)商的安全。避免了現(xiàn)有技術(shù)中重協(xié)商時(shí)不進(jìn)行EAP認(rèn)證所出現(xiàn)的安全問題；還可以避免重協(xié)商時(shí)進(jìn)行EAP認(rèn)證造成交互報(bào)文增多所導(dǎo)致的效率較低的問題。

附圖說明

圖1是本申請?zhí)峁┑姆荖AT穿越的應(yīng)用場景示意圖；

圖2是本申請?zhí)峁┑腘AT穿越的應(yīng)用場景示意圖；

圖3是本申請一實(shí)施例提供的一種英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證方法的流程圖；

圖4是本申請一實(shí)施例提供的英特網(wǎng)密鑰管理協(xié)議中ID負(fù)載格式的示意圖；

圖5是本申請一實(shí)施例提供的一種英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖；

圖6是本申請一實(shí)施例提供的一種英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證裝置的模塊圖。

具體實(shí)施方式

這里將詳細(xì)地對示例性實(shí)施例進(jìn)行說明，其示例表示在附圖中。下面的描述涉及附圖時(shí)，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實(shí)施例中所描述的實(shí)施方式并不代表與本申請相一致的所有實(shí)施方式。相反，它們僅是與如所附權(quán)利要求書中所詳述的、本申請的一些方面相一致的裝置和方法的例子。

在本申請使用的術(shù)語是僅僅出于描述特定實(shí)施例的目的，而非旨在限制本申請。在本申請和所附權(quán)利要求書中所使用的單數(shù)形式的“一種”、“所述”和“該”也旨在包括多數(shù)形式，除非上下文清楚地表示其他含義。還應(yīng)當(dāng)理解，本文中使用的術(shù)語“和/或”是指并包含一個(gè)或多個(gè)相關(guān)聯(lián)的列出項(xiàng)目的任何或所有可能組合。

應(yīng)當(dāng)理解，盡管在本申請可能采用術(shù)語第一、第二、第三等來描述各種信息，但這些信息不應(yīng)限于這些術(shù)語。這些術(shù)語僅用來將同一類型的信息彼此區(qū)分開。例如，在不脫離本申請范圍的情況下，第一信息也可以被稱為第二信息，類似地，第二信息也可以被稱為第一信息。取決于語境，如在此所使用的詞語“如果”可以被解釋成為“在……時(shí)”或“當(dāng)……時(shí)”或“響應(yīng)于確定”。

本申請實(shí)施例中所述的本端和對端是一種相互對應(yīng)的稱呼。例如，在客戶端側(cè)，可以認(rèn)為客戶端為本端，而VPN網(wǎng)關(guān)設(shè)備則為對端。類似的，在VPN網(wǎng)關(guān)設(shè)備側(cè)，可以認(rèn)為VPN網(wǎng)關(guān)設(shè)備為本端，而客戶端則為對端。

在相關(guān)技術(shù)中，遠(yuǎn)程訪問技術(shù)例如VPN(Virtual Private Network虛擬專用網(wǎng))，可以利用共用網(wǎng)絡(luò)架設(shè)專用網(wǎng)絡(luò)，即可以實(shí)現(xiàn)遠(yuǎn)程客戶端訪問中心資源服務(wù)器。例如位于北京的總公司和位于上海的分公司之間，一般中心資源服務(wù)器是位于總公司內(nèi)的，如果分公司想要訪問總公司的中心資源服務(wù)器，就可以使用VPN。

一般，廣泛使用的為IPSec VPN網(wǎng)絡(luò)。所述IPSec(Internet Protocol Security，Internet協(xié)議安全性)是一種開放標(biāo)準(zhǔn)的框架結(jié)構(gòu)，通過使用加密的安全服務(wù)以確保在Internet協(xié)議(IP)網(wǎng)絡(luò)上進(jìn)行保密而安全的通信。所述IPSec協(xié)議并不是一個(gè)單獨(dú)的協(xié)議，它給出了應(yīng)用于IP層上網(wǎng)絡(luò)數(shù)據(jù)安全的一整套體型結(jié)構(gòu)，包括了網(wǎng)絡(luò)認(rèn)證協(xié)議(Authentication Header，AH)、封裝安全載荷協(xié)議(Encapsulating Security Payload，ESP)、密鑰管理協(xié)議(Internet Key Exchange，IKE)和用于網(wǎng)絡(luò)認(rèn)證及加密的一些算法等。所述IPSec規(guī)定了如何在對等層之間選擇安全協(xié)議、確定安全算法和密鑰交換，向上提供了訪問控制、數(shù)據(jù)源認(rèn)證、數(shù)據(jù)加密等網(wǎng)絡(luò)安全服務(wù)。

在部署所述IPSec VPN時(shí)，網(wǎng)管人員通?？梢栽O(shè)置允許多個(gè)客戶端連接到VPN網(wǎng)關(guān)設(shè)備，在實(shí)現(xiàn)時(shí)，一般需要為每一個(gè)客戶端配置不同的VPN策略和預(yù)設(shè)密碼，從而用以區(qū)別不同的用戶。然而，在客戶端上數(shù)量較多時(shí)，進(jìn)行配置的工作量就會很大，費(fèi)時(shí)費(fèi)力，效率也較低，管理也會不方便。所以，現(xiàn)如今主流的IPSec VPN網(wǎng)關(guān)設(shè)備優(yōu)化了配置，只需配置一條VPN策略，就可以允許大量客戶端同時(shí)接入。如此，只要對接入的客戶端分法一個(gè)同一個(gè)VPN策略即可，但是這樣由于所有客戶端具有的VPN策略相同，對每個(gè)客戶端無法單獨(dú)區(qū)分，相應(yīng)地降低了網(wǎng)絡(luò)的安全性(例如在出現(xiàn)網(wǎng)絡(luò)攻擊時(shí)，無法確定攻擊者具體是哪一臺客戶端)。為了解決一條VPN策略所造成的網(wǎng)絡(luò)安全問題，所以提出了一種融合在IPSec VPN里的EAP認(rèn)證機(jī)制。該EAP認(rèn)證，用于要求客戶端在接入VPN網(wǎng)關(guān)設(shè)備時(shí)需要提供身份認(rèn)證信息，VPN網(wǎng)關(guān)設(shè)備可以集中管理客戶端合法的身份認(rèn)證信息。

為了確保通信過程中數(shù)據(jù)的安全，通信的雙方(即客戶端和VPN網(wǎng)關(guān)設(shè)備)需要先進(jìn)行密鑰協(xié)商。這一過程稱之為密鑰管理協(xié)議(Internet Key Exchange，IKE),并且協(xié)商出來的結(jié)果稱之為安全聯(lián)盟(Security Association，SA)。

具體地，所述IKE協(xié)商的過程可以分為兩次協(xié)商階段：第一次協(xié)商階段和第二次協(xié)商階段。其中，所述第一次協(xié)商階段用于協(xié)商雙方公共的用于保護(hù)第二次協(xié)商階段的第一密鑰，即IKE SA。所述第二次協(xié)商階段用于協(xié)商保護(hù)傳輸?shù)臄?shù)據(jù)的第二密鑰，即IPSec SA。

需要說明的是，在IKE的第一次協(xié)商階段，雙方還會交換自身的ID，并且驗(yàn)證對端的合法性也是協(xié)商成功的條件之一。

為了進(jìn)一步增加數(shù)據(jù)的安全，所述IKE提出了一種重協(xié)商機(jī)制，即對于所述SA(包括IKE SA和IPSec SA)會存在一個(gè)生命周期(lifetime)，在所述生命周期到后，當(dāng)前SA就會失效，需要雙方重新協(xié)商新的SA。如此，即使原有的SA被破解，也無法解密用新的SA保護(hù)的數(shù)據(jù)。

值得一提的是，生命周期(lifetime)可以具有兩個(gè)維度，包括時(shí)間(time)和數(shù)據(jù)量(volume limit)。一般的，IKE SA的生命周期的time默認(rèn)為86400秒，即1天，并且沒有volume limit；IPSec SA的生命周期的t ime默認(rèn)為3600秒，即1小時(shí)，并且volume limit默認(rèn)為4608000K字節(jié)(bytes)，即4608G字節(jié)。

通常，生命周期的時(shí)間先過期，在要過期的120秒之前，會自動進(jìn)行重協(xié)商，從而得到新的SA。

在客戶端初次接入VPN網(wǎng)關(guān)設(shè)備時(shí)，需要IKE初次協(xié)商和擴(kuò)展認(rèn)證(Extended Authentication Protocol，EAP認(rèn)證)。具體地，進(jìn)行EAP認(rèn)證時(shí)，IKE的第一次協(xié)商階段正常進(jìn)行，在完成第一次協(xié)商階段后，VPN網(wǎng)關(guān)設(shè)備可以強(qiáng)制中斷第二次協(xié)商階段并發(fā)起EAP認(rèn)證，如果客戶端通過EAP認(rèn)證，則所述VPN網(wǎng)關(guān)設(shè)備允許進(jìn)行第二次協(xié)商階段；反之，如果客戶端沒通過EAP認(rèn)證，則所述VPN網(wǎng)關(guān)設(shè)備不允許進(jìn)行第二次協(xié)商階段。

在所述客戶端通過EAP認(rèn)證后，后續(xù)IKE重協(xié)商就無需新進(jìn)行EAP認(rèn)證。然而，由于IKE重協(xié)商和IKE初次協(xié)商無關(guān)聯(lián)，所以VPN網(wǎng)關(guān)設(shè)備無法確保IKE重協(xié)商和IKE初次協(xié)商的客戶端是同一個(gè)客戶端。也就是說IKE重協(xié)商后，存在客戶端被冒用的風(fēng)險(xiǎn)，而從導(dǎo)致安全的問題。

如圖1所示的非NAT(Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換)穿越的應(yīng)用場景示意圖中，用戶A(IP為172.3.3.1)通過IKE協(xié)商及EAP認(rèn)證后就可以經(jīng)VPN網(wǎng)關(guān)設(shè)備訪問服務(wù)器。如果用戶B(IP為192.3.3.2)盜用用戶A的IP和ID，那么用戶B就可以以用戶A的身份向VPN網(wǎng)關(guān)設(shè)備發(fā)起協(xié)商，進(jìn)而以用戶A的身份訪問服務(wù)器了。如此，就會出現(xiàn)了安全問題。

如圖2所示的NAT穿越的應(yīng)用場景示意圖中，用戶A(IP為1.1.1.1)通過IKE協(xié)商及EAP認(rèn)證后就可以經(jīng)VPN網(wǎng)關(guān)設(shè)備訪問服務(wù)器。如果用戶B(IP為1.1.1.2)盜用用戶A的IP和ID，那么用戶B就可以以用戶A的身份向VPN網(wǎng)關(guān)設(shè)備發(fā)起協(xié)商，進(jìn)而以用戶A的身份訪問服務(wù)器了。如此，就會出現(xiàn)了安全問題。

在另一種方式中，VPN網(wǎng)關(guān)設(shè)備在每次重協(xié)商時(shí)，都會要求客戶端進(jìn)行EAP認(rèn)證，如此來確保每次重協(xié)商時(shí)的客戶端都是同一客戶端。這種方式雖然避免了出現(xiàn)安全問題，但是由于需要每次進(jìn)行EAP認(rèn)證，所以交換報(bào)文就會大量增加，導(dǎo)致重協(xié)商效率較低。

為了解決上述問題，請參見圖3，為本申請一實(shí)施例提供的的一種英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證方法的流程圖。本實(shí)施例即可以應(yīng)用在客戶端，也可以應(yīng)用在VPN網(wǎng)關(guān)設(shè)備。所述方法包括以下步驟：

步驟110：在IKE重協(xié)商的第一次協(xié)商階段，本端設(shè)備通過上一次與對端設(shè)備IKE協(xié)商得到的SA將所述本地設(shè)備的ID進(jìn)行加密。

本實(shí)施例中，如前所述，協(xié)商得到的SA具有一個(gè)生命周期(lifetime)，由于在所述生命周期到后，當(dāng)前SA就會失效，所以需要雙方重新協(xié)商新的SA。生命周期在要過期的120秒之前，會自動進(jìn)行重協(xié)商，從而得到新的SA。所以，可以看出在當(dāng)前SA過期失效之前，客戶端和VPN網(wǎng)關(guān)設(shè)備之間會進(jìn)行重協(xié)商，而在所述重協(xié)商過程中，當(dāng)前SA還沒有過期失效。

本實(shí)施例中，就是利用了所述當(dāng)前SA，而當(dāng)前SA相對于本次IKE重協(xié)商來說，就是上一次IKE協(xié)商時(shí)得到的SA。

本實(shí)施例中，在IKE重協(xié)商的第一次協(xié)商階段，本端設(shè)備通過上一次與對端設(shè)備IKE協(xié)商得到的SA將所述本地設(shè)備的ID進(jìn)行加密。

例如，在IKE重協(xié)商的第一次協(xié)商階段，客戶端通過上一次與VPN網(wǎng)關(guān)設(shè)備IKE協(xié)商得到的SA將所述客戶端的ID進(jìn)行加密；VPN網(wǎng)關(guān)設(shè)備通過上一次與客戶端IKE協(xié)商得到的SA將所述VPN網(wǎng)關(guān)設(shè)備的ID進(jìn)行加密。

本申請實(shí)施例中所述的英特網(wǎng)密鑰管理協(xié)議為IKEv1。

本申請實(shí)施例中的SA為IKE SA。

步驟120：將所述加密后的ID發(fā)送至所述對端設(shè)備。

本實(shí)施例中，本端設(shè)備可以將所述加密后的ID發(fā)送至所述對端設(shè)備。

如圖4所示，為本申請?zhí)峁┑挠⑻鼐W(wǎng)密鑰管理協(xié)議中ID負(fù)載格式的示意圖。其中，所述Next Payload表示下一個(gè)有效載荷；所述RESERVED表示是否保留；所述Payload Length表示有效載荷的長度；所述ID Type表示ID類型；所述DOI Specific ID Data表示指定ID的數(shù)據(jù)；所述Identification Data表示識別數(shù)據(jù)。

步驟130：在收到對端設(shè)備發(fā)送的ID后，通過所述上一次與對端設(shè)備IKE協(xié)商得到的SA進(jìn)行解密。

本實(shí)施例中，由于兩端設(shè)備都會向?qū)Χ税l(fā)送加密的ID，所以本端設(shè)備相應(yīng)地也會收到對端設(shè)備發(fā)送的ID，并且該ID也是加密的。

本端設(shè)備在收到對端設(shè)備發(fā)送的ID后，可以通過所述上一次與對端設(shè)備IKE協(xié)商得到的SA進(jìn)行解密。

步驟140：判斷所述解密后的ID與上一次協(xié)商時(shí)得到的ID是否一致。

本實(shí)施例中，由于每一次協(xié)商都會交換ID，所以可以判斷本次重協(xié)商所解密的ID與上一次協(xié)商得到的ID是否一致。

步驟150：在所述解密后的ID與上一次協(xié)商時(shí)得到的ID一致的情況下，認(rèn)證通過。

通過本申請實(shí)施例中，在進(jìn)行重協(xié)商的第一次協(xié)商階段，本端設(shè)備可以通過上一次IKE協(xié)商得到的SA將所述本端設(shè)備的ID進(jìn)行加密，并向?qū)Χ嗽O(shè)備發(fā)送該加密后的ID；由于重協(xié)商是兩端同時(shí)進(jìn)行的，所以對端設(shè)備也會發(fā)送一個(gè)加密后的ID；所以，本地在收到所述對端設(shè)備發(fā)送的ID后，可以通過所述上一次IKE協(xié)商得到的SA進(jìn)行解密；解密后再判斷ID是否一致，只有ID一致的情況下，才可以認(rèn)證通過。也就是說只有具有上一次SA的對端設(shè)備才能保證重協(xié)商的成功，如果重協(xié)商的對端設(shè)備與上一次協(xié)商的對端設(shè)備不是同一臺設(shè)備，那么本次協(xié)商的對端設(shè)備也就不具有上一次協(xié)商的SA，那么即使在盜用ID的情況下也會由于沒有上一次的SA無法實(shí)現(xiàn)正確加密，而本端設(shè)備也就無法解密得到ID。這就將本次協(xié)商與上一次協(xié)商相關(guān)聯(lián)，從而保證了其它設(shè)備在重協(xié)商時(shí)無法認(rèn)證通過，這樣即使不進(jìn)行EAP認(rèn)證也可以確保重協(xié)商的安全。避免了現(xiàn)有技術(shù)中重協(xié)商時(shí)不進(jìn)行EAP認(rèn)證所出現(xiàn)的安全問題；還可以避免重協(xié)商時(shí)進(jìn)行EAP認(rèn)證造成交互報(bào)文增多所導(dǎo)致的效率較低的問題。

與前述英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證方法實(shí)施例相對應(yīng)，本申請還提供了英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證裝置的實(shí)施例。

本申請英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證裝置的實(shí)施例可以分別應(yīng)用在客戶端設(shè)備、VPN網(wǎng)關(guān)設(shè)備上。裝置實(shí)施例可以通過軟件實(shí)現(xiàn)，也可以通過硬件或者軟硬件結(jié)合的方式實(shí)現(xiàn)。以軟件實(shí)現(xiàn)為例，作為一個(gè)邏輯意義上的裝置，是通過其所在設(shè)備的處理器將非易失性存儲器中對應(yīng)的計(jì)算機(jī)程序指令讀取到內(nèi)存中運(yùn)行形成的。從硬件層面而言，如圖5所示，為本申請英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖，除了圖5所示的處理器、網(wǎng)絡(luò)接口、內(nèi)存以及非易失性存儲器之外，實(shí)施例中裝置所在的設(shè)備通常根據(jù)該英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證的實(shí)際功能，還可以包括其他硬件。

請參見圖6，為本申請一實(shí)施例提供的一種英特網(wǎng)密鑰管理協(xié)議(IKE)重協(xié)商的認(rèn)證裝置的模塊圖，所述裝置可以包括：加密單元210、發(fā)送單元220、解密單元230、判斷單元240及確定單元250。

其中，所述加密單元210，用于在IKE重協(xié)商的第一次協(xié)商階段，本端設(shè)備通過上一次與對端設(shè)備IKE協(xié)商得到的SA將所述本地設(shè)備的ID進(jìn)行加密；

所述發(fā)送單元220，用于將所述加密后的ID發(fā)送至所述對端設(shè)備；

所述解密單元230，用于在收到對端設(shè)備發(fā)送的ID后，通過所述上一次與對端設(shè)備IKE協(xié)商得到的SA進(jìn)行解密；

所述判斷單元240，用于判斷所述解密后的ID與上一次協(xié)商時(shí)得到的ID是否一致；

所述確定單元250，用于在所述解密后的ID與上一次協(xié)商時(shí)得到的ID一致的情況下，認(rèn)證通過。

在一個(gè)可選的實(shí)現(xiàn)方式中：

所述英特網(wǎng)密鑰管理協(xié)議為IKEv1。

在一個(gè)可選的實(shí)現(xiàn)方式中：

所述SA為IKE SA。

綜上所述，通過本申請實(shí)施例中，在進(jìn)行重協(xié)商的第一次協(xié)商階段，本端設(shè)備可以通過上一次IKE協(xié)商得到的SA將所述本端設(shè)備的ID進(jìn)行加密，并向?qū)Χ嗽O(shè)備發(fā)送該加密后的ID；由于重協(xié)商是兩端同時(shí)進(jìn)行的，所以對端設(shè)備也會發(fā)送一個(gè)加密后的ID；所以，本地在收到所述對端設(shè)備發(fā)送的ID后，可以通過所述上一次IKE協(xié)商得到的SA進(jìn)行解密；解密后再判斷ID是否一致，只有ID一致的情況下，才可以認(rèn)證通過。也就是說只有具有上一次SA的對端設(shè)備才能保證重協(xié)商的成功，如果重協(xié)商的對端設(shè)備與上一次協(xié)商的對端設(shè)備不是同一臺設(shè)備，那么本次協(xié)商的對端設(shè)備也就不具有上一次協(xié)商的SA，那么即使在盜用ID的情況下也會由于沒有上一次的SA無法實(shí)現(xiàn)正確加密，而本端設(shè)備也就無法解密得到ID。這就將本次協(xié)商與上一次協(xié)商相關(guān)聯(lián)，從而保證了其它設(shè)備在重協(xié)商時(shí)無法認(rèn)證通過，這樣即使不進(jìn)行EAP認(rèn)證也可以確保重協(xié)商的安全。避免了現(xiàn)有技術(shù)中重協(xié)商時(shí)不進(jìn)行EAP認(rèn)證所出現(xiàn)的安全問題；還可以避免重協(xié)商時(shí)進(jìn)行EAP認(rèn)證造成交互報(bào)文增多所導(dǎo)致的效率較低的問題。

上述裝置中各個(gè)單元的功能和作用的實(shí)現(xiàn)過程具體詳見上述方法中對應(yīng)步驟的實(shí)現(xiàn)過程，在此不再贅述。

對于裝置實(shí)施例而言，由于其基本對應(yīng)于方法實(shí)施例，所以相關(guān)之處參見方法實(shí)施例的部分說明即可。以上所描述的裝置實(shí)施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個(gè)地方，或者也可以分布到多個(gè)網(wǎng)絡(luò)單元上。可以根據(jù)實(shí)際的需要選擇其中的部分或者全部模塊來實(shí)現(xiàn)本申請方案的目的。本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實(shí)施。

本領(lǐng)域技術(shù)人員在考慮說明書及實(shí)踐這里公開的發(fā)明后，將容易想到本申請的其它實(shí)施方案。本申請旨在涵蓋本申請的任何變型、用途或者適應(yīng)性變化，這些變型、用途或者適應(yīng)性變化遵循本申請的一般性原理并包括本申請未公開的本技術(shù)領(lǐng)域中的公知常識或慣用技術(shù)手段。說明書和實(shí)施例僅被視為示例性的，本申請的真正范圍和精神由下面的權(quán)利要求指出。

應(yīng)當(dāng)理解的是，本申請并不局限于上面已經(jīng)描述并在附圖中示出的精確結(jié)構(gòu)，并且可以在不脫離其范圍進(jìn)行各種修改和改變。本申請的范圍僅由所附的權(quán)利要求來限制。