張富強(qiáng)，陳 琳，吳冬冬

國防科學(xué)技術(shù)大學(xué) 計算機(jī)學(xué)院，長沙 410073

使用DK機(jī)制的動態(tài)地址分配安全認(rèn)證方法*

張富強(qiáng)，陳 琳+，吳冬冬

國防科學(xué)技術(shù)大學(xué) 計算機(jī)學(xué)院，長沙 410073

動態(tài)主機(jī)配置協(xié)議（dynamic host configuration protocol，DHCP）動態(tài)管理分配IP地址，提升地址的使用率，得到了廣泛的使用，但是由于該協(xié)議安全機(jī)制薄弱，致使其潛在的安全漏洞如非法DHCP服務(wù)器、Mac地址偽裝、重放攻擊、DoS攻擊等日益凸顯。提出了基于DK機(jī)制的安全認(rèn)證方法（security authentication model based on dynamic key，DK_SAM），該方法結(jié)合系統(tǒng)當(dāng)前時間計算一次性密鑰，并用該密鑰Hash計算消息認(rèn)證碼，最終DHCP實(shí)體通過驗證自定義Option180中的認(rèn)證碼達(dá)到安全認(rèn)證的目的。實(shí)驗表明，DK_SAM方法在保證安全特性的同時具有較高的性能。

動態(tài)主機(jī)配置協(xié)議（DHCP）；安全認(rèn)證；安全漏洞；DK_SAM

1 概述

動態(tài)主機(jī)配置協(xié)議（dynamic host configuration protocol，DHCP）作為最有用的、使用最廣泛的網(wǎng)絡(luò)協(xié)議之一，它的提出不但方便了網(wǎng)絡(luò)管理員對IP地址的分配管理和用戶對網(wǎng)絡(luò)IP地址的使用，而且還解決了IPv4網(wǎng)絡(luò)地址不足的一些問題（DHCP采用串行重用IP地址機(jī)制，提升IP地址的重用率）[1]。隨著互聯(lián)網(wǎng)的發(fā)展和網(wǎng)絡(luò)終端設(shè)備數(shù)量的增加，尤其是個人移動終端設(shè)備的廣泛使用，DHCP協(xié)議也得到了充分的應(yīng)用，但是由于該協(xié)議在被提出時并未考慮安全問題，使得DHCP安全缺陷越來越突顯。

DHCP主要作用是集中地管理、分配IP地址，使網(wǎng)絡(luò)環(huán)境中的主機(jī)動態(tài)獲得IP地址、Gateway地址、DNS（domain name system）服務(wù)器地址等配置信息，并能夠提升地址的使用率。DHCP設(shè)計之初網(wǎng)絡(luò)安全問題并不嚴(yán)重，因此協(xié)議安全沒有受到人們的關(guān)注。隨著互聯(lián)網(wǎng)的發(fā)展，各種網(wǎng)絡(luò)安全問題不斷發(fā)生，無安全機(jī)制的DHCP也成為攻擊的對象或者被用作攻擊的工具[2]。DHCP安全認(rèn)證包括實(shí)體認(rèn)證和消息認(rèn)證，如果沒有實(shí)體認(rèn)證，客戶端和服務(wù)器就不能驗證對方身份的真實(shí)性和有效性。這樣一方面可能會導(dǎo)致非法用戶獲得并使用IP地址及相關(guān)配置信息，從而使用網(wǎng)絡(luò)資源；另一方面也可能會使得偽DHCP服務(wù)器提供惡意IP地址和網(wǎng)絡(luò)配置參數(shù)，進(jìn)而達(dá)到網(wǎng)絡(luò)攻擊的目的。因為DHCP消息是明文傳輸?shù)?，而且沒有消息認(rèn)證，客戶端和服務(wù)器并不能識別被攻擊者篡改的或者重放的消息，攻擊者從而達(dá)到攻擊的目的。由于協(xié)議缺乏安全認(rèn)證機(jī)制而導(dǎo)致的安全問題包括Mac地址偽裝、重放攻擊、DoS（denial of service）攻擊和中間人攻擊等[3]。為了解決這些安全問題，有必要也必須對DHCP添加認(rèn)證技術(shù)。DK_ SAM（security authentication model based on dynamic key）方法通過采用OTP（one-time password）機(jī)制[4]，對每個DHCP報文消息添加自定義的包含消息認(rèn)證碼的認(rèn)證選項，其中消息認(rèn)證碼是通過一次性密鑰和消息體一起Hash產(chǎn)生；最后DHCP客戶端和DHCP服務(wù)器通過驗證消息認(rèn)證碼進(jìn)行消息認(rèn)證和實(shí)體認(rèn)證。DK_SAM方法實(shí)現(xiàn)了安全認(rèn)證，而且采用的是一次性動態(tài)密鑰，因此能有效地防止Mac地址偽裝、重放攻擊、DoS攻擊等。

本文組織結(jié)構(gòu)如下：第2章概述相關(guān)研究；第3章介紹基于OTP機(jī)制的DHCP安全認(rèn)證方法；第4章是實(shí)驗驗證與結(jié)果分析；第5章是總結(jié)與展望。

2 相關(guān)工作

目前廣泛使用的DHCP協(xié)議其前身是BOOTP（Bootstrap protocol），最早定義在RFC1531中，其后又在RFC2131[5]中做了更詳細(xì)的定義并一直使用至今。DHCP協(xié)議是采用客戶端/服務(wù)器模型，服務(wù)器負(fù)責(zé)分配IP地址和網(wǎng)絡(luò)配置參數(shù)信息給客戶端，客戶端請求IP地址，然后使用服務(wù)器分配的IP地址和相關(guān)參數(shù)進(jìn)行網(wǎng)絡(luò)活動。其中網(wǎng)絡(luò)配置參數(shù)包括子網(wǎng)掩碼、默認(rèn)網(wǎng)關(guān)、DNS服務(wù)器和租約時間等，也正是因為包含這些重要信息，可能導(dǎo)致攻擊者捕獲、修改、重放DHCP報文給DHCP客戶端，從而進(jìn)行中間人攻擊、流量分析、網(wǎng)絡(luò)釣魚等。由于協(xié)議設(shè)計之初只是為了解決IP地址分配問題，并未考慮安全問題，但是后來隨著其安全漏洞的出現(xiàn)，也就有了RFC3118[6]的定義和其他相關(guān)安全研究。

RFC3118中定義了令牌認(rèn)證和延遲認(rèn)證兩種認(rèn)證方法，并且定義了認(rèn)證選項的格式。令牌認(rèn)證只是提供簡單基本的實(shí)體認(rèn)證，沒有消息認(rèn)證，令牌泄露或者報文被攔截分析可能會使非法客戶端或服務(wù)器偽裝成合法者。延遲認(rèn)證是基于消息認(rèn)證機(jī)制來實(shí)現(xiàn)消息認(rèn)證和實(shí)體認(rèn)證，該方法雖然保證了安全認(rèn)證機(jī)制，但是存在密鑰管理問題、域間認(rèn)證問題和拒絕服務(wù)攻擊問題。

文獻(xiàn)[7-8]提出了兩種方法SDDC（secure DHCPwith digital certificates）和SDSS（secure DHCP with shared secrets）。這兩種方法都要求服務(wù)器發(fā)送其數(shù)字證書，但是作者并沒有提到怎么傳輸數(shù)字證書。如果證書作為DHCP消息選項傳輸，則會超過選項的長度，因為選項的最大長度是255 Byte。并且作者只是使用C#語言在Visual C#2010平臺上模擬這兩種方法，并沒有真正實(shí)現(xiàn)基于這兩種方法的DHCP協(xié)議。

文獻(xiàn)[9]提出了基于RFC3118認(rèn)證思想和數(shù)字證書的認(rèn)證方法，可以實(shí)現(xiàn)消息認(rèn)證和實(shí)體認(rèn)證。該方法中DHCP客戶端和服務(wù)器必須要與可信的第三方服務(wù)器通信。額外的通信消耗會大大降低DHCP的使用效率和靈活性，用戶的上網(wǎng)體驗質(zhì)量也會下降。由于網(wǎng)絡(luò)最大傳輸單元的限制，作者還提出要分片傳輸數(shù)字證書。相比延遲認(rèn)證，該方法采用了非對稱加密算法，雖然密鑰長度比較長，但其安全性卻比對稱加密要好。

文獻(xiàn)[10]提出使用Kerberos V和RFC3118定義的認(rèn)證選項的格式對DHCP消息進(jìn)行認(rèn)證。為了實(shí)現(xiàn)消息認(rèn)證和實(shí)體認(rèn)證，DHCP客戶端和DHCP服務(wù)器必須提前從Kerberos服務(wù)器得到會話密鑰，然后使用該密鑰對DHCP消息計算其校驗和，計算結(jié)果作為消息認(rèn)證選項的消息認(rèn)證碼。該方法的主要缺點(diǎn)是客戶端必須提前從Kerberos系統(tǒng)中申請服務(wù)，服務(wù)器也必須與Kerberos服務(wù)器交互并獲得客戶端的密鑰，這樣就產(chǎn)生了大量的通信消耗。

還有一些研究者從密鑰管理方面入手提高協(xié)議的安全性能。文獻(xiàn)[11-13]提出使用隨機(jī)數(shù)和客戶端與服務(wù)器共享密鑰，或者隨機(jī)數(shù)和前一個會話密鑰，來為每一個DHCP消息產(chǎn)生會話密鑰，這種方法可以有效地降低重放攻擊的幾率。作者并沒有通過實(shí)驗驗證進(jìn)行性能分析。文獻(xiàn)[14-15]采用公鑰認(rèn)證和預(yù)共享密鑰認(rèn)證，來解決無線網(wǎng)認(rèn)證問題和密鑰更新問題。但是作者都沒對提出的方法進(jìn)行實(shí)現(xiàn)和驗證。

3 基于OTP機(jī)制的DHCP安全認(rèn)證方法DK_ SAM

3.1 相關(guān)定義

定義1 DHCPDiscover報文：用于發(fā)現(xiàn)DHCP服務(wù)器并請求IP地址。DHCP客戶端發(fā)送DHCPDiscover廣播報文以發(fā)現(xiàn)DHCP服務(wù)器，并請求其分配IP地址和網(wǎng)絡(luò)配置參數(shù)。

定義2 DHCPOffer報文：用于響應(yīng)客戶端請求，并提供IP地址和網(wǎng)絡(luò)配置參數(shù)。DHCP服務(wù)器收到DHCPDiscover請求報文，會選擇一個未被分配的IP地址分配給請求客戶端使用，服務(wù)器將IP地址和相關(guān)配置信息存儲到DHCPOffer報文中，并發(fā)送給客戶端。

定義3 DHCPRequest報文：用于請求DHCP服務(wù)器提供的IP地址。DHCP客戶端選擇第一個DHCPOffer報文，并使用報文提供的IP地址和配置信息，然后發(fā)送DHCPRequest廣播報文宣告其所選擇使用的IP地址。

定義4 DHCPAck報文：用于回應(yīng)DHCP客戶端的請求消息，確認(rèn)其可以使用分配的IP地址。DHCP服務(wù)器收到DHCPRequest報文，判斷是否是自己分配的IP地址，如果是，并且允許DHCP客戶端使用該IP地址，就發(fā)送DHCPAck報文給客戶端，否則發(fā)送DHCPNak報文。

定義5消息認(rèn)證碼（message authentication code，MAC）：用于驗證客戶端和服務(wù)器的身份和報文消息的完整性。

定義6服務(wù)器的密鑰Ks：用于計算產(chǎn)生客戶端密鑰，服務(wù)器為客戶端分配的密鑰為Key。

定義7系統(tǒng)當(dāng)前時間currentTime：一次性密鑰的計算參數(shù)之一，單位為秒；誤差時間ΔT，單位為秒，其中ΔT∈{0,1}。

定義8服務(wù)器與客戶端之間進(jìn)行認(rèn)證的密鑰Kcs：客戶端計算Kcs為Hash（currentTime+Key）；服務(wù)器計算Kcs為Hash（currentTime+ΔT+Key）。其中Key根據(jù)Hash（client_id+Ks）計算得到，client_id是客戶端唯一標(biāo)識。計算Kcs使用的Hash算法是Option中Algorithm字段中的值。

定義9 DHCP報文頭字段：chaddr記錄客戶端Mac地址；hops記錄DHCP報文經(jīng)過的DHCP中繼代理的個數(shù)；giaddr（gateway ip address）記錄第一個DHCP中繼代理的IP地址。

3.2 DK_SAM方法

3.2.1 DK_SAM方法安全策略

如果要解決DHCP協(xié)議的漏洞，就必須對協(xié)議添加認(rèn)證選項，也可以使用RFC3118定義的認(rèn)證選項，從而實(shí)現(xiàn)消息認(rèn)證和實(shí)體認(rèn)證。從現(xiàn)有的研究和DHCP協(xié)議本身的限制考慮，本文設(shè)計的安全認(rèn)證方法采用以下設(shè)計原則：

（1）不修改原DHCP協(xié)議，比如對報文加密或引入新的狀態(tài)（DHCP協(xié)議采用狀態(tài)機(jī)驅(qū)動）。這樣就不會造成與原協(xié)議兼容性問題，產(chǎn)生使用的局限性。

（2）不需要與第三方服務(wù)器交互，比如RAIDUS、Kerberos V服務(wù)器。這樣就不會產(chǎn)生額外的通信消耗，并且不會降低DHCP協(xié)議的靈活性和高效性。

（3）認(rèn)證方法采用比較靈活的模塊形式，認(rèn)證模塊可以很方便地開啟和關(guān)閉。認(rèn)證模塊必須能驗證請求，并添加認(rèn)證消息回應(yīng)請求，沒有通過認(rèn)證的消息不予回應(yīng)，而通過認(rèn)證的消息才會進(jìn)行處理，然后回應(yīng)。

（4）自定義的選項必須采用CLV（code length value）格式，以保證和原DHCP協(xié)議Option格式相同，并保證不會超過255 Byte的選項長度，而且DHCP報文不能分割，并且長度最大只能1 236 Byte（IP頭20Byte，UDP頭8 Byte，DHCP消息頭236 Byte）。

3.2.2 DK_SAM方法設(shè)計

DHCP協(xié)議Option字段Code碼的長度為1 Byte，可以表示255個不同的Option。本文采用自定義的Option格式，使用未被使用的Code碼180，其格式如圖1所示。

Fig.1 Format of custom Option圖1 自定義Option格式

Algorithm字段表示消息認(rèn)證碼具體采用的是哪種Hash算法，1表示是MD5算法，2表示是SHA-1算法，該字段還可以擴(kuò)展一些其他Hash算法。Authentication字段表示消息認(rèn)證碼MAC，用于消息認(rèn)證和實(shí)體認(rèn)證。

采用DK_SAM方法客戶端和服務(wù)器之間的報文交互流程如圖2所示。對于客戶端密鑰Key的處理有兩種方式可以選擇：（1）將Key保存到服務(wù)器端的數(shù)據(jù)庫中，主鍵可以為客戶端的唯一標(biāo)識，比如Mac地址，客戶端私密保存該密鑰；（2）服務(wù)器采用一定的算法，比如Hash（client_id+Ks），client_id為客戶端唯一標(biāo)識（客戶端Mac地址或者組合標(biāo)識，通過報文頭chaddr字段得到Mac地址值以及flag字段得到客戶端標(biāo)識），最后為客戶端分配Key。采用第二種方式，服務(wù)器就不需要記錄客戶端Key，服務(wù)器直接根據(jù)請求報文中客戶端的唯一標(biāo)識計算Key值?？蛻舳薑ey的兩種分發(fā)方法，本文都采用帶外管理機(jī)制進(jìn)行處理。對于DK_SAM方法的實(shí)現(xiàn)是采用第二種方式進(jìn)行設(shè)計。

Fig.2 Interaction process between client and server圖2 客戶端和服務(wù)器之間的交互流程

消息認(rèn)證碼MAC是通過Hash（DHCP消息+Kcs）計算得到的，Hash算法是自定義Option180中Algorithm字段所使用的算法，而Kcs是通過Hash（currentTime+Key）計算得到的。因為客戶端在計算MAC時hops和giaddr字段的值均為0，所以服務(wù)器計算MAC時必須將DHCP報文頭hops字段和giaddr字段的值設(shè)為0。服務(wù)器收到消息時的系統(tǒng)時間和客戶端發(fā)送時的時間有誤差（網(wǎng)絡(luò)傳輸時間或者網(wǎng)絡(luò)延遲），因此服務(wù)器驗證DHCPDiscover的Option 180中MAC時計算Kcs=Hash（currentTime+ΔT+Key），其中Kcs為一次完整請求或者更新租約所使用的密鑰。因為DHCP客戶端在發(fā)出IP租用請求的DHCPDiscover廣播包之后，將花費(fèi)1 s的時間等待DHCP服務(wù)器的回應(yīng)，如果1 s沒有收到服務(wù)器的回應(yīng)，它會將這一廣播包重新廣播4次[5]以2、4、8和16 s為間隔，加上1～1 000 ms之間隨機(jī)長度的時間），所以客戶端與服務(wù)器時間誤差ΔT應(yīng)設(shè)置為1 000 ms之內(nèi)，即取值為{0,1}?？蛻舳撕头?wù)器系統(tǒng)必須保持時間同步，因此在進(jìn)行客戶端程序安裝時進(jìn)行系統(tǒng)時間設(shè)定，而后通過時間同步機(jī)制進(jìn)行時間同步。DK_SAM方法必須保證客戶端和服務(wù)器秒級的時間同步，因此用戶入網(wǎng)后不應(yīng)修改系統(tǒng)時間，否則不能通過服務(wù)器認(rèn)證，或者手動修改為標(biāo)準(zhǔn)時間。

非法客戶端或偽裝合法DHCP客戶端Mac地址的客戶端沒有DHCP服務(wù)器分配的Key，其認(rèn)證Option180中的MAC根本就不會通過開啟認(rèn)證模塊的DHCP服務(wù)器的認(rèn)證。偽DHCP服務(wù)器因為不能正確計算產(chǎn)生客戶端Key，所以同樣其回復(fù)的消息不能通過客戶端認(rèn)證模塊的認(rèn)證。因為攻擊者很難在有效的時間內(nèi)對一次性密鑰破譯，并且其參數(shù)的隨機(jī)性保證了密碼的不可預(yù)測性，所以具有一次性密鑰安全特性的DK_SAM可以有效地阻止密碼分析攻擊。除此之外，使用OTP機(jī)制的DK_SAM方法可以有效地阻止重放攻擊（每次客戶端發(fā)送DHCPDiscover報文都會使用結(jié)合系統(tǒng)當(dāng)前時間計算的Kcs生成消息認(rèn)證碼MAC）。為了防止因為攻擊者發(fā)送大量DHCP報文消耗DHCP服務(wù)器的計算資源而造成的DoS攻擊，DHCP服務(wù)器程序采用一定策略限制DHCP客戶端在一定時間內(nèi)請求IP地址的次數(shù)。

DK_SAM認(rèn)證方法的DHCP服務(wù)器認(rèn)證模塊包括兩方面的功能：（1）對到來的DHCP請求消息進(jìn)行驗證；（2）對DHCP服務(wù)器給予客戶端的回應(yīng)，添加含有MAC的自定義Option180。對DHCP消息驗證的核心代碼如下所示。

其中verify函數(shù)主要對packet中Option180字段的Mac值和Hash（packet+Kcs）的值進(jìn)行對比，如果相等則認(rèn)證通過。服務(wù)器發(fā)送回應(yīng)報文之前首先通過認(rèn)證模塊對報文添加Option180，其對應(yīng)的偽代碼如下所示。

4 實(shí)驗驗證

本文設(shè)計并實(shí)現(xiàn)了DHCP協(xié)議的客戶端和服務(wù)器，測試環(huán)境使用的是國防科技大學(xué)網(wǎng)絡(luò)與網(wǎng)絡(luò)安全實(shí)驗室，具體的實(shí)驗拓?fù)淙鐖D3所示。

作者將開發(fā)的DHCP服務(wù)器程序運(yùn)行在實(shí)驗室的一臺電腦上作為S_DHCP服務(wù)器，將客戶端程序分別部署在不同的計算機(jī)上進(jìn)行測試。實(shí)驗室的計算機(jī)系統(tǒng)都自帶標(biāo)準(zhǔn)DHCP客戶端程序，并且將進(jìn)行實(shí)驗的PC1和PC4等計算機(jī)的系統(tǒng)設(shè)置為自動獲取IP地址。

首先，測試了S_DHCP服務(wù)器性能和DHCP服務(wù)器程序與普通DHCP客戶端通信效果。當(dāng)DHCP服務(wù)器程序不開啟認(rèn)證模塊時，PC1和PC4等計算機(jī)都能得到S_DHCP服務(wù)器的回應(yīng)，進(jìn)而使用服務(wù)器分配的IP地址進(jìn)行相互通信。

Fig.3 Experiment's network topology圖3 模擬實(shí)驗拓?fù)鋱D

其次，將開發(fā)的客戶端程序分別運(yùn)行在PC1和PC4計算機(jī)上進(jìn)行測試，PC1和PC4都能得到S_ DHCP服務(wù)器的回應(yīng)。從PC1上收集了客戶端程序與S_DHCP服務(wù)器交互的報文消息，其中的消息包括DHCPDiscover、DHCPOffer、DHCPRequest和DHCPAck。記錄客戶端從發(fā)送DHCPDiscover報文到接收到DHCPAck報文之間的時間，并且對開啟認(rèn)證模塊和關(guān)閉認(rèn)證模塊不同情況分別進(jìn)行了分析和對比，結(jié)果如圖4所示。

Fig.4 Authentication performance comparison圖4 認(rèn)證性能對比

從圖4中可以看出，DK_SAM方法在使用效率上性能是較高的。在客戶端程序中使用了一個定時器，每隔10 s客戶端就會發(fā)送一次請求，最后收集了30次的數(shù)據(jù)并取平均值，對比結(jié)果如表1所示。

從實(shí)驗結(jié)果分析，DK_SAM方法效率上并沒有因為加了認(rèn)證而受到很大的影響。在用戶的實(shí)際使用過程中，相對于幾毫秒的時間損耗，協(xié)議的安全性得到較大提高是非常值得的。

最后，將S_DHCP服務(wù)器的認(rèn)證模塊開啟，驗證使用認(rèn)證模塊的DHCP服務(wù)器與不使用認(rèn)證模塊的客戶端的通信表現(xiàn)。當(dāng)服務(wù)器開啟認(rèn)證模塊時，實(shí)驗室使用系統(tǒng)自帶DHCP客戶端程序的計算機(jī)都不能接收任何S_DHCP服務(wù)器的回應(yīng)。因為使用系統(tǒng)自帶的DHCP客戶端程序，并沒有添加認(rèn)證Option180，服務(wù)器接收到的請求消息是不能通過認(rèn)證的，只有作者自己開發(fā)的DHCP客戶端程序才能接收到消息。

Table 1 Average time of 30 experiments表1 實(shí)驗30次的平均時間

5 結(jié)束語

本文分析了DHCP協(xié)議的安全漏洞，并討論了現(xiàn)有的一些安全DHCP協(xié)議和它們的不足，在此基礎(chǔ)上提出并實(shí)現(xiàn)了基于OTP機(jī)制的DHCP安全認(rèn)證方法DK_SAM，并通過實(shí)驗驗證了方法的性能和效率。通過對實(shí)驗結(jié)果分析，DK_SAM方法不但能保證DHCP協(xié)議的安全，而且具有較高的性能。后續(xù)研究工作是對DHCP中繼功能的安全增強(qiáng)。

[1]Li Lin.Research of DHCP security mechanism[D].Lanzhou: Lanzhou University,2011.

[2]He Zhiyong,Shen Subin,Mao Yanqin.DHCP protocol optimization research[J].Computer Technology and Development,2010,20(9):125-132.

[3]Qu Yongying.On the DHCP network protocol security problems and solutions[J].Computer Knowledge and Technology, 2009,5(15):84-92.

[4]OTP[EB/OL].[2015-12-10].http://baike.baidu.com/link?url=H-sZe-uruIeYYh-NBB2I17IPrN0Sg0Vp_1tKRFY3J4xGB6-uM-bALZuffXJLRpkUBiSug4ZP_DGSQukcY4DeggWq.

[5]Droms R.RFC 2131 Dynamic host configuration protocol[S].1997.

[6]Droms R,Arbaug W.RFC 3118 Authentication for DHCP messages[S].2001.

[7]Duangphasuk S,Kungpisdan S,Hankla S.Design and implementation of improved security protocols for DHCP using digital certificates[C]//Proceedings of the 17th IEEE International Conference on Networks,Singapore,Dec 14-16, 2011.Washington:IEEE Computer Society,2011:287-292.

[8]Kathryn D G,Liddy J,Raison P,et al.Dynamic host configuration protocol(DHCP)authentication using challenge handshake authentication protocol(CHAP)challenge:USA, 8555347[P].United States Patent Application Publication, 2013.

[9]Wong M,Xu Yixian,Manning S.An authentication method based on certificate for DHCP[S].DHCP Internet Draft, 2011.

[10]Hornstein K,Lemon T,Adoba B,et al.DHCP authentication via Kerberos V[S].IETF DHC Working Group,2001.

[11]Ju H I,Han J W.DHCP message authentication with an effective key management[C]//Proceedings of the 2015 World Academy of Science,Engineering and Technology,Aug 2005:132-135.

[12]Krawczyk H,Bellare M,Canetti R.HMAC:RFC 2104 Keyed-hashing for message authentication[S].1997.

[13]Kobayashi K,Yamaguchi S.Network access control for DHCP environment[J].IEICE Transactions on Communications,1998,96(9):1718-1723.

[14]Shankar N,Arbaugh W A,Zhang Kan.A transparent key management scheme for wireless LANs using DHCP,HPL-2001-227[R].HP Laboratories PaloAlto,2001.

[15]Fluhrer S R,Mantin I,Shamir A.Weaknesses in the key scheduling algorithm of RC4[C]//LNCS 2259:Proceedings of the 8th Annual International Workshop on Selected Areas in Cryptography,Toronto,Canada,Aug 16-17,2001.London, UK:Springer-Verlag,2001:1-24.

附中文參考文獻(xiàn)：

[1]李林.DHCP安全機(jī)制研究[D].蘭州:蘭州大學(xué),2011.

[2]何智勇,沈蘇彬,毛燕琴.DHCP協(xié)議優(yōu)化方案研究[J].計算機(jī)技術(shù)與發(fā)展,2010,20(9):125-132.

[3]區(qū)詠瑩.論DHCP網(wǎng)絡(luò)協(xié)議的安全性問題與解決[J].電腦知識與技術(shù),2009,5(15):84-92.

ZHANG Fuqiang was born in 1990.He is an M.S.candidate at School of Computer Science,National University of Defense Technology.His research interests include computer network and wireless communication,etc.

張富強(qiáng)（1990—），男，河南周口人，國防科學(xué)技術(shù)大學(xué)計算機(jī)學(xué)院碩士研究生，主要研究領(lǐng)域為計算機(jī)網(wǎng)絡(luò)，無線通信等。

CHEN Lin was born in 1976.She received the Ph.D.degree from National University of Defense Technology in 2005.Now she is an associate professor at National University of Defense Technology.Her research interests include network management and data center network resource management,etc.

陳琳（1976—），女，福建隴海人，2005年于國防科學(xué)技術(shù)大學(xué)獲得博士學(xué)位，現(xiàn)為國防科學(xué)技術(shù)大學(xué)副教授，主要研究領(lǐng)域為網(wǎng)絡(luò)管理，數(shù)據(jù)中心網(wǎng)絡(luò)資源管理等。

WU Dongdong was born in 1987.He is an M.S.candidate at School of Computer Science,National University of Defense Technology.His research interest is computer network.

吳冬冬（1987—），男，山東泰安人，國防科學(xué)技術(shù)大學(xué)計算機(jī)學(xué)院碩士研究生，主要研究領(lǐng)域為計算機(jī)網(wǎng)絡(luò)。

SecurityAuthentication Method of DHCPUsing DK Mechanism*

ZHANG Fuqiang,CHEN Lin+,WU Dongdong
School of Computer Science,National University of Defense Technology,Changsha 410073,China
+Corresponding author:E-mail:agnes_nudt@qq.com

The DHCP(dynamic host configuration protocol)allocates and manages IP address dynamically,and promotes address utilization,so the protocol has been widely used.However,due to the protocol without security mechanism,the potential security vulnerabilities such as illegal DHCP,Mac address disguise,replay attack and DoS attack are becoming more and more prominent.This paper proposes a security authentication model based on dynamic key(DK_SAM).The model combines with the current system time to compute the one-time key and uses the key to generate the message authentication code by Hash algorithm.Finally,the model achieves the objective of the security authentication through verifying the authentication code in Option180.Experimentation indicates that DK_SAM ensures the security characteristics,as well it has higher efficiency.

dynamic host configuration protocol(DHCP);security authentication;security vulnerability;DK_SAM

10.3778/j.issn.1673-9418.1602038

A

：TP393

*The National Natural Science Foundation of China under Grant No.61379148(國家自然科學(xué)基金).

Received 2016-02,Accepted 2016-06.

CNKI網(wǎng)絡(luò)優(yōu)先出版:2016-06-23,http://www.cnki.net/kcms/detail/11.5602.TP.20160623.1401.014.html

ZHANG Fuqiang,CHEN Lin,WU Dongdong.Security authentication method of DHCP using DK mechanism.Journal of Frontiers of Computer Science and Technology,2017,11(3)：382-388.