一種輕量級(jí)地址自動(dòng)分配協(xié)議安全認(rèn)證方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明屬于網(wǎng)絡(luò)安全技術(shù)領(lǐng)域，特指一種輕量級(jí)地址自動(dòng)分配協(xié)議安全認(rèn)證方法。
【背景技術(shù)】
[0002]DHCP協(xié)議(Dynamic Host Configurat1n Protocol)作為最有用的網(wǎng)絡(luò)協(xié)議之一，它的提出不但方便了網(wǎng)絡(luò)管理員對(duì)IP地址的分配管理和用戶對(duì)網(wǎng)絡(luò)IP地址的使用，而且還解決了 IPv4網(wǎng)絡(luò)地址不足的一些問題。但是，此協(xié)議在提出時(shí)并未考慮安全認(rèn)證問題。隨著網(wǎng)絡(luò)的發(fā)展和移動(dòng)設(shè)備的廣泛使用，DHCP安全缺陷越來越突顯。DHCP協(xié)議安全漏洞主要包括以下幾個(gè)方面:
[0003](I)由于協(xié)議自身沒有訪問控制和實(shí)體認(rèn)證，所以任何一個(gè)用戶不管是否有使用網(wǎng)絡(luò)資源的權(quán)限都可以從DHCP服務(wù)器獲得IP地址及相關(guān)的配置信息從而使用網(wǎng)絡(luò)。如果說網(wǎng)絡(luò)攻擊者對(duì)DHCP服務(wù)器進(jìn)行攻擊完全可以把有效的IP地址資源耗盡，導(dǎo)致合法的用戶不能申請(qǐng)到IP地址而造成Dos攻擊。
[0004](2)由于DHCP協(xié)議發(fā)送報(bào)文完全使用的是明文而且也沒有消息認(rèn)證，這就存在很大的消息篡改的風(fēng)險(xiǎn)。攻擊者可以攔截DHCP報(bào)文然后對(duì)其進(jìn)行修改，這就可能造成DHCP客戶端申請(qǐng)的IP地址不可用或者說會(huì)有地址沖突。如果攻擊者修改了服務(wù)器提供配置信息中的網(wǎng)關(guān)和DNS信息就可能造成更大的危險(xiǎn)比如:①用戶的訪問網(wǎng)絡(luò)必須會(huì)經(jīng)過攻擊者修改的網(wǎng)關(guān)，這樣就可以對(duì)其進(jìn)行流量分析;②攻擊者惡意DNS服務(wù)器可以誘導(dǎo)用戶訪問釣魚網(wǎng)站從而獲取用戶重要的信息。
[0005](3)如果說網(wǎng)絡(luò)中存在流氓DHCP服務(wù)器同樣會(huì)給用戶很大的安全威脅。流氓服務(wù)器采用一定的方式消耗盡DHCP服務(wù)器的有效的IP地址資源，然后就會(huì)對(duì)用戶的DHCP請(qǐng)求進(jìn)行應(yīng)答。由于DHCP客戶端不會(huì)對(duì)服務(wù)器進(jìn)行認(rèn)證所以客戶端就會(huì)配置非法服務(wù)器提供的IP地址和網(wǎng)絡(luò)配置信息。進(jìn)而會(huì)對(duì)網(wǎng)絡(luò)造成更大的危害。
[0006]總的概括來說，DHCP安全漏洞主要是由于協(xié)議本身缺少安全認(rèn)證機(jī)制(消息認(rèn)證和實(shí)體認(rèn)證)。
[0007]目前，為了解決上述問題，傳統(tǒng)的解決方案主要包括:
[0008](I)簡(jiǎn)單的實(shí)體認(rèn)證，比如采用檢測(cè)客戶Mac地址或令牌認(rèn)證等都是提供弱的實(shí)體認(rèn)證沒有消息認(rèn)證。這種認(rèn)證方式很容易受攻擊，攻擊者會(huì)偽裝能通過認(rèn)證的Mac地址或者令牌。
[0009](2)需要與第三方服務(wù)器交互，比如RAIDUS、Kerber0S V服務(wù)器，就會(huì)產(chǎn)生額外的通信消耗，這就造成DHCP靈活性和高效性大大的下降。
[0010](3)修改了原DHCP協(xié)議，比如提出對(duì)報(bào)文加密或引入新的狀態(tài)(DHCP協(xié)議采用狀態(tài)機(jī)驅(qū)動(dòng)的)。這樣就會(huì)造成與原協(xié)議兼容性問題，產(chǎn)生使用的局限性。
[0011](4)數(shù)字證書作為認(rèn)證手段，由于證書一般比較大，所以不能添加到DHCP報(bào)文中進(jìn)行傳輸，因?yàn)镈HCP報(bào)文不能分割并且長(zhǎng)度最大只能1236個(gè)字節(jié)(IP頭20個(gè)字節(jié)，UDP頭8個(gè)字節(jié)，DHCP消息頭236個(gè)字節(jié))，可以作為Opt 1n使用，這樣就存在證書分發(fā)的問題。

【發(fā)明內(nèi)容】

[0012]本發(fā)明要解決的技術(shù)問題就在于:針對(duì)現(xiàn)有技術(shù)存在的技術(shù)問題，本發(fā)明提供一種原理簡(jiǎn)單、易實(shí)現(xiàn)、兼容性好、安全性更高的輕量級(jí)地址自動(dòng)分配協(xié)議安全認(rèn)證方法。
[0013]為解決上述技術(shù)問題，本發(fā)明采用以下技術(shù)方案:
[0014]一種輕量級(jí)地址自動(dòng)分配協(xié)議安全認(rèn)證方法，其步驟為:
[0015]S1:服務(wù)器使用Hash(MaC+Ks)為每個(gè)客戶端計(jì)算Key，其中Mac是每個(gè)客戶端的唯一標(biāo)示即鏈路層地址，客戶端私密保存Key以備認(rèn)證模塊使用；
[0016]S2:客戶端認(rèn)證模塊使用Hash( currentTime+Key)算法并利用系統(tǒng)當(dāng)前時(shí)間計(jì)算得Kcs，其中Hash法在Opt1n格式的算法一項(xiàng)中設(shè)定，然后消息報(bào)文結(jié)合Kcs使用Hash(DHCPD i s c ο V e r+K c s)產(chǎn)生MAC，將MAC添加到Op t i on的認(rèn)證消息字段，將客戶端產(chǎn)生的DHCPDiscover消息發(fā)送到DHCP服務(wù)端；
[0017]S3:DHCroisC0Ver消息發(fā)送到服務(wù)端，首先會(huì)被服務(wù)端的認(rèn)證模塊接收，對(duì)其消息進(jìn)行認(rèn)證，從DHCPDi scover報(bào)文中取出客戶端的Mac地址和消息認(rèn)證碼，通過Hash (Mac+Ks)計(jì)算得到Key ;認(rèn)證模塊根據(jù)Opt 1n的算法字段獲得客戶端使用的Hash算法，通過Hash(currentTime+Key)得到Kcs;最后將計(jì)算Hash(DHCPDiscover+Kcs)的值與報(bào)文中取出的消息認(rèn)證碼對(duì)比，如果相等則認(rèn)證模塊發(fā)送報(bào)文給服務(wù)器，服務(wù)器分配IP地址和網(wǎng)絡(luò)配置參數(shù)進(jìn)入步驟S4，如果不相等說明報(bào)文消息被修改或者是重放的DHCFOiscover消息，直接丟棄；
[0018]S4: DHCP服務(wù)器收到通過認(rèn)證模塊報(bào)文后，直接分配IP地址；
[0019]S5:客戶端認(rèn)證模塊接收到DHCPOf fer消息之后，首先取出消息中的MAC，使用發(fā)送DHCPDiscover報(bào)文時(shí)計(jì)算的Kcs與MAC對(duì)比；如果不相等直接丟棄，如相等就發(fā)送給客戶端處理；
[0020]S6:客戶端將DHCPRequest報(bào)文發(fā)給認(rèn)證模塊，認(rèn)證模塊將添加含有MAC的Opt1n并將消息發(fā)送給服務(wù)端；
[0021 ] S7:服務(wù)端認(rèn)證模塊對(duì)DHCPRequest報(bào)文進(jìn)行認(rèn)證，認(rèn)證通過直接發(fā)送給服務(wù)器，不通過則直接丟棄。
[0022]作為本發(fā)明的進(jìn)一步改進(jìn):所述步驟S4中，將產(chǎn)生的DHCPOffer報(bào)文發(fā)給服務(wù)端的認(rèn)證模塊，認(rèn)證模塊會(huì)使用步驟S3計(jì)算保存下的Kcs產(chǎn)生Hash (DHCPOf fer+Kcs)將這一MAC加入Opt1n的認(rèn)證消息字段，最后發(fā)送出去。
[0023]作為本發(fā)明的進(jìn)一步改進(jìn):所述步驟S6中，MAC通過Hash(DHCPRequest+Kcs)計(jì)算得出的。
[0024]作為本發(fā)明的進(jìn)一步改進(jìn):所述步驟S7中，如果通過認(rèn)證服務(wù)器會(huì)發(fā)確認(rèn)報(bào)文DHCPAck給客戶端，同樣也會(huì)加入MAC讓客戶端認(rèn)證模塊去認(rèn)證。
[0025]作為本發(fā)明的進(jìn)一步改進(jìn):對(duì)于DHCP報(bào)文中不存在自定義Opt1n的報(bào)文的處理根據(jù)需求而定義模塊，如果報(bào)文中不存在該Opt 1n讓認(rèn)證模塊選擇丟棄，也可以不處理直接通過。
[0026]作為本發(fā)明的進(jìn)一步改進(jìn):在上述步驟中，客戶端和服務(wù)器保持時(shí)鐘同步，在用戶采用DHCP協(xié)議申請(qǐng)IP地址之前進(jìn)行設(shè)置。
[0027]作為本發(fā)明的進(jìn)一步改進(jìn):在上述步驟中，客戶端提前得到服務(wù)器為自己計(jì)算Key，服務(wù)器使用特定的哈希算法和密鑰Ks計(jì)算得到。
[0028]與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點(diǎn)在于:
[0029]1、本發(fā)明的輕量級(jí)地址自動(dòng)分配協(xié)議安全認(rèn)證方法，是針對(duì)DHCP協(xié)議存在的安全問題提出一種基于OTP(One Time Password)認(rèn)證的輕量級(jí)解決方法，該方法不但可以對(duì)DHCP客戶端和服務(wù)器進(jìn)行實(shí)體認(rèn)證，還可以對(duì)DHCP消息進(jìn)行認(rèn)證。
[0030]2、本發(fā)明的輕量級(jí)地址自動(dòng)分配協(xié)議安全認(rèn)證方法，是基于OTP安全DHCP認(rèn)證方法，從安全性考慮，不但能實(shí)現(xiàn)實(shí)體和消息認(rèn)證而且能阻止常見的攻擊，比如重放攻擊，中間人攻擊等。從實(shí)現(xiàn)的難易程度來說，實(shí)現(xiàn)起來比較容易，而且不需要與第三方服務(wù)器交互，效率不會(huì)受到大的影響。從兼容性考慮，由于沒有更改原協(xié)議的狀態(tài)和和協(xié)議格式，所以可以與使用原協(xié)議的客戶端服務(wù)器交互。
【附圖說明】
[0031 ]圖1是本發(fā)明方法的流程示意圖。
[0032]圖2是本發(fā)明在具體應(yīng)用實(shí)例中自定義認(rèn)證Opt1n的格式示意圖。
[0033]圖3是本發(fā)明在一個(gè)具體應(yīng)用實(shí)例中客戶端與多個(gè)服務(wù)器報(bào)文交互流程的示意圖。
[0034]圖4是本發(fā)明在另一個(gè)具體應(yīng)用實(shí)例中多個(gè)客戶端與一個(gè)服務(wù)器報(bào)文交互流程的示意圖。
【具體實(shí)施方式】
[0035]以下將結(jié)合說明書附圖和具體實(shí)施例對(duì)本發(fā)明做進(jìn)一步詳細(xì)說明。
[0036]DHCP安全認(rèn)證是近幾年來隨著DHCP安全問題凸顯而越來越受重視的網(wǎng)絡(luò)安全問題。一次性密碼解決使用者在密碼的記憶與保存上的困難性，并且由于密碼只能使用一次，而且因?yàn)槊艽a是一分鐘隨機(jī)變化一次的，所以不可預(yù)測(cè)，也只有一次的使用有效性，從而阻止了攻擊者的重放攻擊和對(duì)密碼的攻擊，提高了安全性。本發(fā)明根據(jù)OTP的優(yōu)點(diǎn)對(duì)傳統(tǒng)的共享密鑰認(rèn)證方式進(jìn)行了修改，不但提高了 DHCP協(xié)議的安全性而且對(duì)DHCP協(xié)議的靈活性和高效性沒有太大的影響。
[0037]本發(fā)明需要使用到相關(guān)的描述信息，具體包括:
[0038]DHCPDiscover:客戶端向DHCP服務(wù)器發(fā)送廣播報(bào)文，用于發(fā)現(xiàn)DHCP服務(wù)器。
[0039]DHCPOffer = DHCP服務(wù)器應(yīng)答客戶端的DHCPDiscover消息，并攜帶自己的IP地址和網(wǎng)絡(luò)配置參數(shù)。
[0040]DHCPRequest:客戶端選擇第一個(gè)到達(dá)的DHCPOffer報(bào)文，向該DHCP服務(wù)器請(qǐng)求網(wǎng)絡(luò)配置參數(shù)，同時(shí)拒絕其他服務(wù)器提供的參數(shù)。
[0041]DHCPAck = DHCP服務(wù)器發(fā)給客戶端的報(bào)文，包括配置參數(shù)和網(wǎng)絡(luò)地址，客戶端接收到該報(bào)文之后，可以正式使用提供的IP地址和相關(guān)配置信息。
[0042]本發(fā)明用到DHCP報(bào)文頭的三個(gè)字段包括hops、giaddr和xid。
[0043]chaddr:客戶端 Mac 地址。
[0044]hops:記錄DHCP報(bào)文經(jīng)過的DHCP中繼代理