專利名稱：：基于IEEE802.1x安全認(rèn)證協(xié)議的改進(jìn)方法
技術(shù)領(lǐng)域：
：本發(fā)明屬于一種無線網(wǎng)絡(luò)中的安全認(rèn)證方法，特別是一種基于IEEE802.lx安全認(rèn)證協(xié)議的改進(jìn)方法。
背景技術(shù)：
：有線局域網(wǎng)通過固定線^^連接組建，計算^L終端通過網(wǎng)絡(luò)接入固定位置物理端口，實現(xiàn)局域網(wǎng)接入，數(shù)據(jù)傳輸直接送到目的地，這里沒有直接控制到端口的方法，也不需要控制到端口，這些固定位置的物理端口構(gòu)成有線局域網(wǎng)的封閉物理空間。但是，由于無線局域網(wǎng)的網(wǎng)絡(luò)空間具有開放性和終端可移動性，因此很難通過網(wǎng)絡(luò)物理空間來界定終端是否屬于該網(wǎng)絡(luò)。隨著無線局域網(wǎng)的廣泛應(yīng)用，如何通過端口認(rèn)證來實現(xiàn)用戶級的接入控制就成為一項非?，F(xiàn)實的問題。IEEE802.lx正是基于這一需求而出現(xiàn)的一種認(rèn)證技術(shù)。IEEE802.lx協(xié)+義，稱為基于端口的訪問控制切、議(PortBasedNetworkAccessControlProtocol),是由IEEE于2001年6月才是出的，符合IEEE802協(xié)議集的局域網(wǎng)接入控制協(xié)議，主要目的是為了解決無線局域網(wǎng)用戶的接入認(rèn)證問題，能夠在利用IEEE802局域網(wǎng)優(yōu)勢的基礎(chǔ)上提供一種對連接到局域網(wǎng)用戶的認(rèn)證和授權(quán)手段，達(dá)到接收合法用戶輸入，保護(hù)網(wǎng)絡(luò)安全的目的。IEEE802.lx協(xié)議的體系結(jié)構(gòu)包括3個重要部分客戶端、認(rèn)證系統(tǒng)和認(rèn)證服務(wù)器(圖1)。其中客戶端也就是申請者，一般是一個用戶移動終端，如安裝有網(wǎng)卡的PC機(jī)。該終端系統(tǒng)通常要安裝一個客戶端軟件，用戶通過啟動這個客戶端軟件發(fā)起IEEE802.lx認(rèn)證。為了支持基于端口的接入控制，客戶端系統(tǒng)需要支持EAP0L協(xié)議。客戶端的主要功能包括啟動認(rèn)證過程，并使用戶輸入的用戶名和密碼與認(rèn)證系統(tǒng)進(jìn)行認(rèn)證過程信息交互；認(rèn)證成功后，響應(yīng)認(rèn)證系統(tǒng)的重新認(rèn)證請求；下線時，通知認(rèn)證系統(tǒng)關(guān)閉相應(yīng)端口。完成客戶端功能的協(xié)議實體稱為客戶端PAE(PortAccessEntity,端口接入實體)，在具體的實現(xiàn)中，通常就是客戶端軟件?？蛻舳伺c認(rèn)證系統(tǒng)通過EAP0L協(xié)議進(jìn)行通信。認(rèn)證系統(tǒng)認(rèn)證系統(tǒng)在802.1網(wǎng)絡(luò)中就是接入點(diǎn)，在認(rèn)i正過程中只起到"透傳"的功能，所有的認(rèn)證工作在客戶端和認(rèn)證服務(wù)器上完成。認(rèn)證系統(tǒng)通常為支持802.1x協(xié)議的網(wǎng)絡(luò)設(shè)備(比如無線交換機(jī))，它為請求者提供服務(wù)端口，該端口可以是物理端口也可以是邏輯端口，一般在用戶接入設(shè)備(如LANSwitch和AP)上實現(xiàn)802.lx認(rèn)證。后文的認(rèn)證系統(tǒng)、認(rèn)證點(diǎn)和接入設(shè)備三者表達(dá)相同含義。接入點(diǎn)在認(rèn)證過程中雖然只起到"透傳，，的功能，但是在認(rèn)證之前，它可以把申請者的數(shù)據(jù)分到兩個邏輯端口中(圖2):控制端口和非控制端口。非控制端口始終處于連通狀態(tài)，它不需要授權(quán)，隨時可以與網(wǎng)絡(luò)中的其他機(jī)器進(jìn)行數(shù)據(jù)交換，主要用來傳遞EAPOL協(xié)議幀，保證可以隨時接收客戶端申請者發(fā)出的認(rèn)證請求?？刂贫丝谥挥性谡J(rèn)證通過的狀態(tài)下才打開，用于傳遞網(wǎng)絡(luò)資源和服務(wù)，有雙向受控和僅輸入受控兩種方式，以適應(yīng)不同的應(yīng)用環(huán)境。圖2中申請者1沒有通過身份認(rèn)證，控制端口不通，處于未授權(quán)狀態(tài)。申請者2通過身份認(rèn)證，控制端口連通，處于授權(quán)狀態(tài)。認(rèn)證系統(tǒng)主要功能有啟動認(rèn)證過程；在認(rèn)證狀態(tài)信息超時后，對客戶端進(jìn)行重新認(rèn)證；中繼或終結(jié)EAP(PPPExtensibleAuthenticationProtocol)幀；響應(yīng)客戶端下線消息，關(guān)閉端口。完成認(rèn)證系統(tǒng)功能的協(xié)議實體稱為認(rèn)證PAE，在具體的實現(xiàn)中，通常就是交換機(jī)中的802.1x協(xié)議軟件;漠塊。認(rèn)證服務(wù)器通常為RADIUS(RemoteAuthenticationDialInUserService,遠(yuǎn)程身份驗證撥入用戶服務(wù))服務(wù)器，該服務(wù)器存儲有關(guān)用戶的信息，比如用戶的身份標(biāo)識和密碼等等。當(dāng)用戶進(jìn)行認(rèn)證時，認(rèn)證系統(tǒng)需要通過認(rèn)證服務(wù)器來驗證用戶是否合法。如果用戶合法，認(rèn)證服務(wù)器通知認(rèn)證系統(tǒng)，用戶已經(jīng)通過認(rèn)證，把可控端口打開。此后，用戶就可以正常地通過端口訪問認(rèn)證系統(tǒng)所提供的服務(wù)。認(rèn)證系統(tǒng)和RADIUS服務(wù)器之間通過承載于RADIUS協(xié)議之上的EAP協(xié)議進(jìn)行通信。IEEE802.lx協(xié)議的i人證過程是在具有IEEE802.lx認(rèn)證功能的網(wǎng)絡(luò)系統(tǒng)中，當(dāng)一個用戶需要對網(wǎng)絡(luò)資源進(jìn)行訪問之前，必須完成以下認(rèn)證過程(圖3)。1)當(dāng)用戶有上網(wǎng)需求時，用戶使用8021.lx客戶端程序，輸入用戶名和口令，發(fā)起連接請求，此時，客戶端程序?qū)l(fā)出EAPOL-Start報文給認(rèn)證系統(tǒng)(交換機(jī))，開始一次認(rèn)證過程；2)認(rèn)i正系統(tǒng)收到請求i人i正的數(shù)據(jù)才艮文后，將發(fā)出一個EAP-Request/Identity請求報文給用戶的客戶端，要求客戶端程序發(fā)送用戶輸入的用戶名；3)客戶端程序響應(yīng)認(rèn)證系統(tǒng)發(fā)出的請求，將用戶名信息通過EAP-Response/Identity報文發(fā)給認(rèn)證系統(tǒng)，認(rèn)證系統(tǒng)將客戶端送上來的數(shù)據(jù)報文轉(zhuǎn)發(fā)給認(rèn)證服務(wù)器進(jìn)行處理；4)認(rèn)證服務(wù)器收到認(rèn)證系統(tǒng)轉(zhuǎn)發(fā)上來的用戶名信息后，用隨機(jī)生成的一個加密字對它進(jìn)行加密處理，同時也將此加密字封裝成數(shù)據(jù)報文傳送給認(rèn)證系統(tǒng)，由認(rèn)證系統(tǒng)將數(shù)據(jù)報文傳給客戶端程序；5)客戶端程序收到由認(rèn)證系統(tǒng)傳來的加密字后，用該加密字對口令部分進(jìn)行加密處理(如計算其hash值)，返回EAP-Responset艮文并通過認(rèn)證系統(tǒng)傳給認(rèn)證服務(wù)器。(說明參看圖3,認(rèn)證服務(wù)器和客戶端的這種挑戰(zhàn)信息幀可能會有多次交互)6)認(rèn)證服務(wù)器收到認(rèn)證系統(tǒng)轉(zhuǎn)發(fā)的加密后的口令信息后，將其和自己經(jīng)過加密運(yùn)算后的口令信息進(jìn)行比較，如果匹配，則認(rèn)為該用戶為合法用戶，反々赍EAP-SuccessiU正成功4言息，iU正系統(tǒng)打開端口，用戶可以訪問網(wǎng)絡(luò)。否則，反饋EAP-Failure認(rèn)證失敗的消息，并保持交換機(jī)端口的關(guān)閉狀態(tài)，只允許認(rèn)證信息數(shù)據(jù)通過而不允許業(yè)務(wù)數(shù)據(jù)通過。7)客戶端發(fā)送EAP0L-L0G0FF報文，表明用戶下線。IEEE802.lx采用EAP點(diǎn)對點(diǎn)協(xié)議認(rèn)證，它是一個通用協(xié)議，其特點(diǎn)是EAP在鏈路控制協(xié)議階段沒有選定一種認(rèn)證機(jī)制，而是推遲到認(rèn)證階段。EAP協(xié)議具有良好的可擴(kuò)展性。1998年，IETF對EAP進(jìn)行了標(biāo)準(zhǔn)化。EAP可以支持多種認(rèn)證機(jī)制，允許使用一個"后端"服務(wù)器來實現(xiàn)各種認(rèn)證機(jī)制，認(rèn)證者僅需要傳送認(rèn)證信息。EAP協(xié)議本身具有良好的可擴(kuò)展性，這使得在添加新的認(rèn)證機(jī)制時絲毫不會影響現(xiàn)有協(xié)議的繼續(xù)使用。1998年，IETF對EAP進(jìn)行了標(biāo)準(zhǔn)化,即RFC2284。EAP協(xié)議的認(rèn)證過程為1)在鏈路建立后，認(rèn)證系統(tǒng)發(fā)送一個或者多個請求數(shù)據(jù)包來對對方進(jìn)行認(rèn)證，該數(shù)據(jù)包有一個表明請求類型的類型域；2)對方發(fā)送一個響應(yīng)數(shù)據(jù)包，對每個請求做出回答。響應(yīng)包與請求包的類型域互相對應(yīng)；3)認(rèn)證系統(tǒng)發(fā)送一個成功或者失敗數(shù)據(jù)包結(jié)束認(rèn)證。通過使用EAP,可以支持智能卡、Kereros、公鑰、一次性口令(0ne-TimePassword,OTP)等多種認(rèn)證機(jī)制。請求/應(yīng)答包中的類型域規(guī)定了EAP的各種類型，最初有以下幾種類型。Identity:用來查詢對方身^f分；Notification:由iU正者用來向?qū)Ψ絺鬟f一條可顯示的消息；Nak:僅對應(yīng)答包有效，作為不接受請求認(rèn)證類型時的響應(yīng)；MD5-Challenge:類似于PPPCHAP協(xié)議，包含質(zhì)詢消息；One-TimePassword:請求包中含有一個OTP質(zhì)詢消息，應(yīng)答類型為0TP或Nak;GenericTokenCard:用于要求用戶輸入各種類型的令牌卡。除了以上的幾種基本類型，為了提供更高的級別安全，逐漸增加了更多的類型定義，比如EAP-TLS協(xié)議中請求/應(yīng)答包的類型域相應(yīng)為EAP-TLS。傳輸層安全(TLS)協(xié)議提供相互認(rèn)證、整體性保護(hù)加密套件協(xié)商及兩端的密鑰交換。<吏用EAP-TLS，可以允許一個PPP端點(diǎn)吸收TLS協(xié)議中的優(yōu)點(diǎn)來支持更多的認(rèn)證機(jī)制。EAP消息被封裝在IEEE802.lx消息中，稱做EAPOL。EAP協(xié)議在IEEE802.lx中的應(yīng)用層次結(jié)構(gòu)如4所示，可以看出EAP工作在網(wǎng)絡(luò)層，并不是真正意義上的鑒權(quán)認(rèn)證協(xié)議，但是EAP給真正的鑒權(quán)認(rèn)證協(xié)議，如TLS，CHAP,Kerberos等提供承載。由于是網(wǎng)絡(luò)層的協(xié)議，EAP可以方便得將EAP消息路由到認(rèn)證服務(wù)器。EAP消息有EAP請求，EAP響應(yīng)，EAP成功通知和EAP失敗通知四類。其中，只有EAP請求消息是可以在認(rèn)證系統(tǒng)和接入客戶端系統(tǒng)之間直接發(fā)送，其它的消息都是從認(rèn)證服務(wù)器發(fā)給客戶端系統(tǒng)，或者從客戶端系統(tǒng)發(fā)給鑒權(quán)服務(wù)器的，認(rèn)證系統(tǒng)只是完成中轉(zhuǎn)和協(xié)議轉(zhuǎn)換(認(rèn)證系統(tǒng)與客戶端系統(tǒng)之間用EAP0L承載，客戶端系統(tǒng)與認(rèn)證服務(wù)器之間用其它高層協(xié)議，如RADIUS)。圖5描述的是由客戶端系統(tǒng)發(fā)起認(rèn)證請求，一次口令交換下，鑒權(quán)成功的消息流。其中，實線代表EAP0L數(shù)據(jù)幀的交換，虛線代表認(rèn)證系統(tǒng)與認(rèn)證服務(wù)器間的高層協(xié)議，采用RADIUS協(xié)議?？梢钥闯?，認(rèn)證者完成EAP消息的重新封裝，來傳輸認(rèn)證消息。認(rèn)證服務(wù)器把認(rèn)證結(jié)果以RADIUS-ACCEPT或者RADIUS-REJECT的形式傳給認(rèn)證者，認(rèn)證者再重新封裝成EAP-Success或者EAP-Failure消息給申請者。當(dāng)申請者收到EAP-Success消息時，i兌明認(rèn)證成功，可以接入局J或網(wǎng)全備了。EAPOL數(shù)據(jù)包的格式如圖6所示，其中PAEEthernet類型取值范圍0x88-0x8e;協(xié)議版本現(xiàn)在取J直為0x01;類型EAPOL數(shù)據(jù)包共有5種類型(見表l)。表lEAPOL數(shù)據(jù)包類型名<table>tableseeoriginaldocumentpage10</column></row><table>其中長度后面數(shù)據(jù)體的字節(jié)數(shù)。數(shù)據(jù)體根據(jù)類型的不同，數(shù)據(jù)體有不同的格式。當(dāng)EAPOL數(shù)據(jù)包的類型為"EAP-Packet"時，數(shù)據(jù)體為EAP數(shù)據(jù)包,EAP數(shù)據(jù)包格式如圖7所示。其中的代碼EAP數(shù)據(jù)包的類型(表2)。表2EAP數(shù)據(jù)包的類型<table>tableseeoriginaldocumentpage11</column></row><table>其中標(biāo)識符輔助進(jìn)行Response和Request消息的匹配。長度整個EAP包的長度，包括代碼、標(biāo)識符和長度所占的4個字節(jié)，它的值就是N。數(shù)據(jù)體由代碼的取值決定，不同的代碼有不同的數(shù)據(jù)體。如果代碼的取值為Success或者Failure,則EAP數(shù)據(jù)包沒有數(shù)據(jù)體；如果取值為Response或者Request,則數(shù)據(jù)體的才各式如圖8。其中"類型"就是"EAP認(rèn)證類型，，，在這里用代碼表示。Indenty1;Notification2Nak3;MD5-Challenge4One-TimePassword5;GenericTokenCard6由于IEEE802.1x是一個不對稱協(xié)議，它只允許網(wǎng)絡(luò)鑒別用戶，而不允許用戶鑒別網(wǎng)絡(luò)。因而，攻擊者能夠竊聽用戶和訪問點(diǎn)之間的通信，扮演"中間人"的角色在移動用戶和合法訪問點(diǎn)之間傳遞虛假信息，實施中間人攻擊。EAP-Success消息是一條非常重要的管理消息，當(dāng)客戶端系統(tǒng)接到EAP-Success消息時，就意味著認(rèn)證成功，可以與網(wǎng)絡(luò)中的其它節(jié)點(diǎn)通信了。但是，因為EAP-Success消息是直接裝人EAP0L的數(shù)據(jù)幀發(fā)送給接人請求者的，此時在客戶端系統(tǒng)和認(rèn)證系統(tǒng)之間沒有建成可靠的通道，當(dāng)在WLAN環(huán)境中時，很容易受到中間人攻擊。中間人攻擊示意圖如圖9:在客戶端系統(tǒng)發(fā)出接入請求時，攻擊者在客戶端一方假冒認(rèn)證系統(tǒng)，在認(rèn)證系統(tǒng)一方有支冒客戶端系統(tǒng)，就可以繞過i人證機(jī)制。根據(jù)標(biāo)準(zhǔn)，i人證者的端口只有當(dāng)會話通過認(rèn)證后才打開。而對于申請者，端口始終是處于已認(rèn)證狀態(tài)。這種申請者與認(rèn)證者之間的單向認(rèn)證將使申請者遭到中間人攻擊。802.lx認(rèn)證者狀態(tài)機(jī)只4妄受EAP-response消息，并且只發(fā)送EAP-request消息。而申請者狀態(tài)機(jī)不發(fā)送EAP-request消息。顯然狀態(tài)機(jī)執(zhí)行的是單向認(rèn)證。如果上層協(xié)議采用的是單向認(rèn)證將使整個體系更加脆弱。EAP-TLS確實能提供強(qiáng)相互認(rèn)證但不是強(qiáng)制的而且也可以繞過EAP-TLS進(jìn)行中間人攻擊。下面是一個簡單的中間人攻擊的例子當(dāng)認(rèn)證者從RADIUS服務(wù)器收到RADUIS-Access-Accxpt消息后，就向申請者發(fā)送一個EAP-Success消息。這就提示狀態(tài)機(jī)認(rèn)證已經(jīng)成功。無論上層認(rèn)證方法采用EAP-TLS，EAP-MD5或者其他認(rèn)證，這條消息都沒有完整性保護(hù)。而且申請者的狀態(tài)機(jī)無條件的轉(zhuǎn)換到已認(rèn)證狀態(tài)，不管當(dāng)前的是什么。因此，攻擊者可以偽造這個數(shù)據(jù)包來冒充認(rèn)證者實現(xiàn)中間人攻擊。這樣被攻擊的申請者會認(rèn)為冒充的認(rèn)證者就是合法的認(rèn)證者，并把數(shù)據(jù)包發(fā)送到這個冒充的認(rèn)證者。圖IO是RSN網(wǎng)絡(luò)認(rèn)證的狀態(tài)機(jī)，共四種狀態(tài)。之后進(jìn)行IEEE802.lx認(rèn)證。因此共有兩種狀態(tài)機(jī)RSN和802.lx狀態(tài)機(jī)，它們共同指示認(rèn)證的狀態(tài)。但是它們?nèi)狈η逦耐ㄐ藕拖⒄鎸嵭?，所以很可能遭到會話劫持攻擊。圖ll顯示了會話劫持是如何實現(xiàn)的，攻擊的過程描述如下l)消息l、2、3和4:合法的申請者進(jìn)行認(rèn)證(假設(shè)EAP認(rèn)證只包含這4條消息，實際的EAPiU正多于4條消息)。2)消息5:攻擊者冒充AP的MAC地址發(fā)送一條Disassociate(未關(guān)聯(lián)通知)管理幀給申請者。這使得申請者的狀態(tài)為Disassociated(關(guān)聯(lián)不成功)。這條消息^f吏RSN狀態(tài)才幾凈皮i殳置為Unassociated(未關(guān)fl關(guān))，而802.lx一犬態(tài)才幾的纟犬態(tài)仍為Authenticated(已認(rèn)證)。3)消息6:這時攻擊者冒充申請者的MAC地址4妻入到網(wǎng)絡(luò)。DoS是DenialofService的簡稱,即拒絕服務(wù),造成DoS的攻擊行為被稱為DoS攻擊，其目的是使計算機(jī)或網(wǎng)絡(luò)無法提供正常的服務(wù)。最常見的DoS攻擊有計算機(jī)網(wǎng)絡(luò)帶寬攻擊和連通性攻擊。帶寬攻擊指以極大的通信量沖擊網(wǎng)絡(luò)，使得所有可用網(wǎng)絡(luò)資源都被消耗殆盡，最后導(dǎo)致合法的用戶請求就無法通過。連通性攻擊指用大量的連接請求沖擊計算機(jī)，使得所有可用的操作系統(tǒng)資源都被消耗殆盡，最終計算機(jī)無法再處理合法用戶的請求。IEEE802.lx沒有提供DoS保護(hù)，使得服務(wù)器容易耗盡計算資源以及存儲資源，而且可能導(dǎo)致合法用戶無法正常接入。比如攻擊者偽造一個合法用戶的MAC地址向i人證者發(fā)送EAP-Logoff消息，那么這個合法用戶將與認(rèn)證者中斷連接。綜上所述，IEEE802.lx認(rèn)證協(xié)議存在易使網(wǎng)絡(luò)遭中間人攻擊、會話劫持和DoS攻擊的缺陷。
發(fā)明內(nèi)容本發(fā)明的目的是提供一種保障無線網(wǎng)絡(luò)用戶安全的接入服務(wù)網(wǎng)絡(luò)，提供網(wǎng)絡(luò)用戶和網(wǎng)絡(luò)4妄入點(diǎn)(AP)的正確身份認(rèn)證，以確保雙方后續(xù)傳輸信息的安全性的基于IEEE802.lx安全認(rèn)證協(xié)議的改進(jìn)方法，以克服上述缺陷。為了實現(xiàn)上述目的，本發(fā)明所采用的方法是基于IEEE802.lx認(rèn)證的EAP(ExtensibleAuthenticationProtocol,可擴(kuò)展認(rèn)證協(xié)議)協(xié)議,在EAPOIv(ExtensibleAuthenticationProtocoloverLAN,局域網(wǎng)上的可擴(kuò)展認(rèn)證協(xié)議)包中增加了一個Protection字段；上述字l殳由兩部分組成第1部分為前5個字^史的MD5散列，第2部分為上一個EAPOL數(shù)據(jù)包中HMAC(HashedMessageAuthenticationCodes,雜湊消息認(rèn)證碼)的密鑰，每條消息的密鑰是隨機(jī)發(fā)送，在發(fā)送一個EAPOL數(shù)據(jù)包時并不攜帶這個散列函數(shù)的密鑰，相反，這個密鑰將在下一個數(shù)據(jù)包中攜帶；接收方在收到一個EAPOL包時首先進(jìn)行存儲，用接收到的下一個包的密鑰驗證上一個包的源真實性和完整性。這樣就確保非法用戶無法實現(xiàn)解析合法用戶和接入點(diǎn)(AP)的通信內(nèi)容，從而有效的保護(hù)了通信內(nèi)容的保密性。本發(fā)明從數(shù)據(jù)完整性保護(hù)角度出發(fā)，在EAPOL包中增加了一個Protection字段，提出了數(shù)據(jù)真實性和完整性認(rèn)證，本發(fā)明可以彌補(bǔ)IEEE802.lx認(rèn)證協(xié)議存在設(shè)計上的缺陷，有效的預(yù)防中間人、會話劫持和Dos攻擊。圖1為IEEE802.lx認(rèn)證協(xié)議的體系結(jié)構(gòu)圖。圖2為IEEE802.lxiU正協(xié)議中端口的結(jié)構(gòu)示意圖。圖3為IEEE802.lxiU正協(xié)議認(rèn)證過程圖。圖4為EAP在IEEE802.lx認(rèn)證協(xié)議中的應(yīng)用層次結(jié)構(gòu)圖。圖5為IEEE802.lx認(rèn)證協(xié)議中一次口令交換下鑒權(quán)成功的消息流示意圖。圖6為IEEE802.lx認(rèn)證協(xié)議中EAPOL數(shù)據(jù)包的格式。圖7為IEEE802.lx認(rèn)證協(xié)議中EAP數(shù)據(jù)包格式。圖8為IEEE802.lx認(rèn)證協(xié)議中Request和Response數(shù)據(jù)體格式。圖9為IEEE802.lx認(rèn)證協(xié)議的中間人攻擊示意圖。圖10為IEEE802.lx認(rèn)證協(xié)議的RSN網(wǎng)絡(luò)認(rèn)證的狀態(tài)機(jī)結(jié)構(gòu)示意圖。圖11為IEEE802.lx認(rèn)證協(xié)議的會話劫持攻擊示意圖。圖12為本發(fā)明的EAPOL數(shù)據(jù)包的格式。圖13為本發(fā)明的認(rèn)證過程圖。具體實施方式下面結(jié)合附圖對本發(fā)明作進(jìn)一步的詳細(xì)描述。IEEE802.lx認(rèn)證雖然不完善，但是在無線局域網(wǎng)中起著不可替代的作用。目前協(xié)議的缺陷主要原因是缺少數(shù)據(jù)包的源真實性和完整性保護(hù)，因此在充分考慮了源真實性和完整性的基礎(chǔ)上本發(fā)明提出了改進(jìn)的認(rèn)證方法。本發(fā)明在IEEE802.lx認(rèn)證中的EAP0L包中增加了一個Protection字,更(圖12)。這個Protection字,史由兩部分組成Protection=HMAC+Key第1部分為前5個字段的MD5散列，第2部分為上一個EAP0L數(shù)據(jù)包中麗AC的密鑰，每條消息的密鑰是隨機(jī)的，在發(fā)送一個EAPOL數(shù)據(jù)包時并不攜帶這個散列函數(shù)的密鑰，相反，這個密鑰將在下一個數(shù)據(jù)包中攜帶。接收方在收到一個EAP0L包時首先進(jìn)行存儲，用接收到的下一個包的密鑰驗證上一個包的源真實性和完整性。本發(fā)明的認(rèn)證過程(圖13)是1)客戶端向認(rèn)i正者發(fā)送EAPOL-Start發(fā)起認(rèn)證。認(rèn)證過程同樣可以由認(rèn)證者發(fā)起，^f旦是它直接發(fā)送EAP-Request/Identity而不是EAPOL-Start消息。在第1條消息封裝的最后一部分是Protection字段，其中應(yīng)AC是數(shù)據(jù)幀隨機(jī)用密鑰Ksl(Ks代表客戶端的散列函數(shù)密鑰)的散列值，因為是客戶端的第l條消息，所以Key字段為0。事實上，認(rèn)證者在4僉測到端口/人"disable"狀態(tài)轉(zhuǎn)移到"enable"狀態(tài)時就向客戶端發(fā)送認(rèn)證請求。如果客戶端沒有收到來自認(rèn)證者的iU正i貪求，那么它就會在適當(dāng)?shù)臅r候通過EAPOL-Start消息發(fā)起認(rèn)證過程；2)當(dāng)認(rèn)證者不知道用戶身份時就發(fā)送該消息(EAP-Request/Identity)。其中HMAC是數(shù)據(jù)幀隨機(jī)用密鑰Kal(Ka代表認(rèn)證者的散列函數(shù)密鑰)的散列值，因為是認(rèn)證者的第1條消息，所以Key字段為0;3)客戶端收到EAP-Request/Identity消息，就用其用戶名響應(yīng)，發(fā)送EAP-Response/Identity消息給認(rèn)證者，HMAC是數(shù)據(jù)巾貞隨機(jī)用密鑰Ks2的散列值，Key字段為Ksl;4)認(rèn)證者把包含有用戶身份的EAP響應(yīng)包重新以RADUIS協(xié)議格式封裝，并把重新封裝后的包由RADUIS客戶端發(fā)送至RADUIS服務(wù)器；5)RADIUS服務(wù)器在收到該包后將選擇具體的認(rèn)證機(jī)制，并發(fā)送相應(yīng)的EAP請求包到認(rèn)證者；6)認(rèn)證者并不解釋來自RADUIS的EAP包的具體內(nèi)容，而只是沖t查RADUIS協(xié)議包的類型，由于是質(zhì)詢包，因此iU正者將其毫不改變的轉(zhuǎn)發(fā)給客戶端，HMAC是數(shù)據(jù)幀隨機(jī)用密鑰Ka2的散列值，Key字段為Kal;7)客戶端收到上述請求包后，如果支持RADUIS服務(wù)器選擇的認(rèn)證機(jī)制，就根據(jù)認(rèn)證機(jī)制的要求作出響應(yīng)，并通過EAP封裝后發(fā)送給認(rèn)證者，腹AC是用客戶端私鑰對數(shù)據(jù)幀的簽名，Key字段為Ks2;如果不支持RADUIS服務(wù)器選擇的認(rèn)證機(jī)制，則發(fā)送NAK包，這樣RADUIS服務(wù)器將重新選纟奪認(rèn)i正機(jī)制，并/人第5步重新開始；8)認(rèn)證者把來自客戶端的EAP響應(yīng)包中繼到RADUIS服務(wù)器；9)如果RADUIS認(rèn)證服務(wù)器通過了對客戶端的認(rèn)證，則向認(rèn)證者發(fā)送RADUIS—Access—Accept消息；否貝寸t尤向其發(fā)送RADUIS—Access-Reject消息；10)i口果iU正者^l文到RADIUS—Access-Accept消息，貝'H人為iU正成功，于是打開受控端口，并向客戶端發(fā)送EAP-Success消息，此后客戶端就可以進(jìn)行授權(quán)的正常通信過程，如果認(rèn)證者收到RADUIS-Access-Reject消息，則認(rèn)為認(rèn)證失敗，于是關(guān)閉受控端口，并向客戶端發(fā)送EAP-Failure消息，HMAC是用認(rèn)證者的私鑰對數(shù)據(jù)幀的簽名，Key字段為Ka2;11)當(dāng)客戶端通過認(rèn)證(重認(rèn)證)之后，無線接入點(diǎn)AP將向客戶端發(fā)送用來加密廣播幀的廣播密鑰EAP0L-Key。廣播密鑰的發(fā)送保證了客戶端用于單播時會話密鑰的保密性。而會話密鑰的派生與發(fā)送與認(rèn)證服務(wù)器選擇的具體的認(rèn)證機(jī)制有關(guān)；12)當(dāng)客戶端離線時，向認(rèn)證者發(fā)送離線通知EAPOLLogoff,HMAC為客戶端私鑰對數(shù)據(jù)幀的簽名，Key字段為O,認(rèn)證者收到消息后重新關(guān)閉受控端口。認(rèn)證過程中EAP-Request和EAP-Response可能有多條消息構(gòu)成，這里本發(fā)明只用6和7兩條消息代表。本發(fā)明的協(xié)i義將彌補(bǔ)IEEE802.lx認(rèn)證協(xié)議中易受中間人攻擊和會話劫持的兩個缺陷，同時在很大程度上彌補(bǔ)IEEE802.lx認(rèn)證協(xié)議中缺乏DoS保護(hù)的缺陷。及完整性保護(hù)。這樣即保證了源真實性也保證了完整性，使得重放攻擊對于認(rèn)證過程以及認(rèn)證實體的影響降低到較小的程度。同時，如果攻擊者想偽造一個EAPOL包，那么他必須還要有前一個EAPOL包中散列函數(shù)的密鑰，這對于攻擊者幾乎是不可能的。由于在本發(fā)明中，接收者要存儲一個數(shù)據(jù)包，等下一個數(shù)據(jù)包到來時才進(jìn)行驗證，這里只要限制存儲的數(shù)據(jù)包只能為1，這樣即使攻擊者進(jìn)行DoS攻擊也不能耗盡服務(wù)器的計算資源和存儲資源。本說明書中未作詳細(xì)描述的內(nèi)容屬于本領(lǐng)域?qū)I(yè)技術(shù)人員公知的現(xiàn)有技術(shù)。權(quán)利要求1、一種基于IEEE802.1x安全認(rèn)證協(xié)議的改進(jìn)方法，所采用的方法是基于IEEE802.1x認(rèn)證的EAP協(xié)議，在EAPOL數(shù)據(jù)包中增加一個Protection字段。2、如權(quán)利要求1所述的基于IEEE802.lx安全認(rèn)證協(xié)議的改進(jìn)方法，其特征在于Protection字段由兩部分組成第1部分為IEEE802.lx認(rèn)證的EAP協(xié)議中前5個字段的MD5散列，第2部分為上一個EAPOL數(shù)據(jù)包中畫AC的密鑰。3、如權(quán)利要求1或2所述的基于IEEE802.lx安全iU正協(xié)議的改進(jìn)方法，其特征在于每條消息的EAPOL數(shù)據(jù)包中HMAC的密鑰是隨機(jī)發(fā)送，在發(fā)送一個EAPOL數(shù)據(jù)包時并不攜帶這個散列函數(shù)的密鑰，相反，這個密鑰將在下一個數(shù)據(jù)包中攜帶；接收方在收到一個EAPOL包時首先進(jìn)行存儲，用接收到的下一個包的密鑰驗證上一個包的源真實性和完整性。4、如權(quán)利要求1所述的基于IEEE802.lx安全iU正協(xié)議的改進(jìn)方法，其特征在于其具體認(rèn)證過程為第一步客戶端向認(rèn)證者發(fā)送EAPOL-Start發(fā)起認(rèn)證，在第1條消息封裝的最后一部分是Protection字段，其中EAPOL數(shù)據(jù)包中HMAC是數(shù)據(jù)幀隨機(jī)用密鑰Ksl的散列值，其中Ks代表客戶端的散列函數(shù)密鑰；第二步當(dāng)認(rèn)證者不知道用戶身份時就發(fā)送該消息，其中HMAC是數(shù)椐幀隨機(jī)用密鑰Kal的散列值，其中Ka代表認(rèn)證者的散列函數(shù)密鑰，因為是認(rèn)證者的第1條消息，所以Key字段為0;第三步客戶端收到EAP-Request/Identity消息，就用其用戶名響應(yīng)，發(fā)送EAP-Response/Identity消息給認(rèn)證者，HMAC是數(shù)據(jù)幀隨機(jī)用密鑰Ks2的散列值，Key字段為Ksl;第四步認(rèn)證者把包含有用戶身份的EAP響應(yīng)包重新以RADUIS協(xié)議格式封裝，并"te重新封裝后的包由RADUIS客戶端發(fā)送至RADUIS服務(wù)器；第五步RADIUS服務(wù)器在收到該包后將選擇具體的認(rèn)證機(jī)制，并發(fā)送相應(yīng)的EAP請求包到認(rèn)i正者；第六步iU正者4企查RADUIS協(xié)議包的類型，由于是質(zhì)詢包，因此認(rèn)證者將其毫不改變的轉(zhuǎn)發(fā)給客戶端，HMAC是數(shù)據(jù)幀隨機(jī)用密鑰Ka2的散列值，Key字段為Kal;第七步客戶端收到上述請求包后，如果支持RADUIS服務(wù)器選擇的認(rèn)證機(jī)制，就根據(jù)認(rèn)證機(jī)制的要求作出響應(yīng)，并通過EAP封裝后發(fā)送給認(rèn)證者，HMAC是用客戶端私鑰對數(shù)據(jù)幀的簽名，Key字段為Ks2;如果不支持RADUIS服務(wù)器選擇的認(rèn)證機(jī)制，則發(fā)送NAK包，這樣RADUIS服務(wù)器將重新選擇認(rèn)證機(jī)制，并從第5步重新開始；第八步認(rèn)證者把來自客戶端的EAP響應(yīng)包中繼到RADUIS服務(wù)器；第九步如果RADUIS認(rèn)證服務(wù)器通過了對客戶端的認(rèn)證，則向認(rèn)證者發(fā)送RADUIS-Access-Accept消息；否則就向其發(fā)送RADUIS-Access-Reject消息；第十步如果認(rèn)證者收到RADIUS-Access-Accept消息，則認(rèn)為認(rèn)證成功，于是打開受控端口，并向客戶端發(fā)送EAP-Success消息，此后客戶端就可以進(jìn)行4受權(quán)的正常通信過程；如果認(rèn)證者收到RADUIS-Access-Reject消息，則認(rèn)為認(rèn)證失敗，于是關(guān)閉受控端口，并向客戶端發(fā)送EAP-Failure消息，HMAC是用認(rèn)證者的私鑰對數(shù)據(jù)幀的簽名，Key字段為Ka2;第十一步當(dāng)客戶端通過認(rèn)證之后，無線接入點(diǎn)AP將向客戶端發(fā)送用來加密廣纟番幀的廣纟番密鑰EAP0L-Key;第十二步當(dāng)客戶端離線時，向認(rèn)證者發(fā)送離線通知EAP0L-Logoff,HMAC為客戶端私鑰對數(shù)據(jù)幀的簽名，Key字段為0,認(rèn)證者收到消息后重新關(guān)閉受控端口。全文摘要本發(fā)明涉及一種基于IEEE802.1x安全認(rèn)證協(xié)議的改進(jìn)方法，其方法是在IEEE802.1x認(rèn)證中的EAPOL數(shù)據(jù)包中增加了一個字段；該字段由兩部分組成第1部分為前5個字段的MD5散列，第2部分為上一個EAPOL數(shù)據(jù)包中HMAC的密鑰，在認(rèn)證過程中每條消息HMAC的密鑰是隨機(jī)發(fā)送，在發(fā)送一個EAPOL數(shù)據(jù)包時并不攜帶這個散列函數(shù)的密鑰，相反，這個密鑰將在下一個數(shù)據(jù)包中攜帶；接收方在收到一個EAPOL包時首先進(jìn)行存儲，用接收到的下一個包的密鑰驗證上一個包的源真實性和完整性。本發(fā)明能確保非法用戶無法實現(xiàn)解析合法用戶和接入點(diǎn)的通信內(nèi)容，有效的保護(hù)了通信內(nèi)容的保密性，從而克服了IEEE802.1x認(rèn)證中存在的易使網(wǎng)絡(luò)遭中間人攻擊、會話劫持和DoS攻擊的缺陷。文檔編號H04L9/08GK101272379SQ200810047689公開日2008年9月24日申請日期2008年5月13日優(yōu)先權(quán)日2008年5月13日發(fā)明者李臘元,王躍峰,蔡英華,琳郭申請人:武漢理工大學(xué)