李曉紅，劉福文，齊旻鵬，粟栗，楊星星

（1.天津大學(xué)智能與計(jì)算學(xué)部，天津 300072；2.中國移動(dòng)通信有限公司研究院，北京 100053）

1 引言

移動(dòng)智能通信設(shè)備的激增以及多媒體通信的不斷增長導(dǎo)致移動(dòng)流量的數(shù)量大幅增長，并且可能很快超過第四代（4G）移動(dòng)通信系統(tǒng)的容量，為了解決該挑戰(zhàn)，第五代移動(dòng)通信技術(shù)（5G）[1]應(yīng)運(yùn)而生，并成為了當(dāng)下的研究熱點(diǎn)。5G技術(shù)通過高度集成的設(shè)計(jì)手段，將任何新的5G空中接口和頻譜與長期演進(jìn)技術(shù)LTE（Long Term Evolution，LTE）和WiFi連接在了一起，并設(shè)計(jì)核心網(wǎng)絡(luò)達(dá)到了更加智能與靈活的水平[2]，這些高質(zhì)量服務(wù)為用戶帶來方便快捷體驗(yàn)的同時(shí)，保證了用戶的入網(wǎng)安全，同時(shí)確保網(wǎng)絡(luò)連接合法用戶，構(gòu)建安全合法的移動(dòng)通信網(wǎng)絡(luò)環(huán)境，也成為了現(xiàn)代通信技術(shù)中不可或缺的要求與挑戰(zhàn)。

5G-AKA協(xié)議是基于4G/LTE使用的認(rèn)證[3]與密鑰協(xié)商E P S-A K A[4]協(xié)議的基礎(chǔ)上提出的，該協(xié)議作為5G用戶認(rèn)證與密鑰協(xié)商過程以保證用戶的附著安全性。 然而，5G系統(tǒng)[5～7]囊括了核心網(wǎng)以及管理系統(tǒng)等網(wǎng)絡(luò)演變的所有內(nèi)容，其不足之處主要來自三個(gè)方面：（1）長期密鑰泄露導(dǎo)致通信內(nèi)容被竊聽；（2）攻擊者可以利用LTE中的EPS-AKA協(xié)議假定安全條件，竊聽、盜用和篡改用戶信息；（3）由于開放式網(wǎng)絡(luò)環(huán)境，導(dǎo)致攻擊者可以利用入網(wǎng)請(qǐng)求協(xié)議流程，對(duì)移動(dòng)通信網(wǎng)絡(luò)實(shí)體實(shí)施拒絕服務(wù)攻擊。

本文在EPS-AKA協(xié)議中，考慮使用PKI對(duì)附著流程安全性協(xié)議進(jìn)行增強(qiáng)，提出了基于PKI的5G-DHAKA協(xié)議，并對(duì)協(xié)議進(jìn)行了詳細(xì)地設(shè)計(jì)及安全性分析。首先，分析了EPS-AKA協(xié)議，為基于PKI的5G-DHAKA協(xié)議的提出奠定了理論與實(shí)踐基礎(chǔ)；其次，利用哈希挑戰(zhàn)響應(yīng)機(jī)制緩解DoS[8]攻擊，應(yīng)用PKI機(jī)制保護(hù)用戶附著流程中的身份管理流程，通過擴(kuò)展EPS-AKA協(xié)議實(shí)現(xiàn)相應(yīng)的安全服務(wù)，包括認(rèn)證、可用性、數(shù)據(jù)機(jī)密性、密鑰管理和隱私；接著，使用形式化驗(yàn)證工具Scyther對(duì)所提出的基于PKI的5G-DHAKA協(xié)議進(jìn)行形式化驗(yàn)證，驗(yàn)證所提協(xié)議的認(rèn)證性、機(jī)密性等安全特性以滿足防止分布式拒絕服務(wù)攻擊。

2 基于PKI的5G-DHAKA協(xié)議設(shè)計(jì)

2.1 EPS-AKA協(xié)議安全性分析

如表1所示為本文在描述協(xié)議時(shí)所使用的縮寫與專有名詞解釋。

3GPP組把EPS-AKA協(xié)議定義為LTE網(wǎng)絡(luò)中的認(rèn)證協(xié)議，主要用于用戶進(jìn)行網(wǎng)絡(luò)附著過程中的認(rèn)證流程，以到達(dá)促進(jìn)UE和EPC之間的安全分組交換，防御LTE網(wǎng)絡(luò)免受各種攻擊的目的。通過對(duì)3G網(wǎng)絡(luò)中使用的UMTS-AKA協(xié)議進(jìn)行改進(jìn)，EPS-AKA協(xié)議具有了強(qiáng)認(rèn)證性。LTE協(xié)議主要包括三個(gè)實(shí)體：用戶設(shè)備UE、移動(dòng)管理實(shí)體MME以及歸屬用戶服務(wù)器HSS，其具體認(rèn)證過程如圖1所示。

本節(jié)詳細(xì)描述了E P S-A K A協(xié)議的交互流程，具體描述如下。

（1）UE→MME：用戶設(shè)備UE通過發(fā)起附著請(qǐng)求啟動(dòng)認(rèn)證流程，并將其永久身份IMSI加入附著請(qǐng)求信息中，將該附著請(qǐng)求信息發(fā)送給移動(dòng)管理實(shí)體MME；

（2）MME→HSS：MME向歸屬用戶服務(wù)器HSS發(fā)送認(rèn)證信息請(qǐng)求，該認(rèn)證信息請(qǐng)求包括MME接收到的IMSI以及其網(wǎng)絡(luò)標(biāo)識(shí)SNID。

（3）H S S→M M E：H S S檢查I M S I和SNID，根據(jù)用戶長期密鑰值Ki計(jì)算n個(gè)認(rèn)證向量AV（Authentication Vector，AV）。AV計(jì)算定義如公式1至公式8所示。

其中，RAND（Random Challenge，RAND）表示隨機(jī)數(shù)；XRES（Expected Response，XRES）表示預(yù)期響應(yīng)；KASME表示根密鑰；AUTN（Authentication Token，AUTN） 表示認(rèn)證令牌。CK和IK[18]用于數(shù)據(jù)加密和完整性檢驗(yàn)，以增強(qiáng)LTE傳輸?shù)臋C(jī)密性和完整性。f1～f5為哈希函數(shù)，分別用于生成消息認(rèn)證碼MAC、RES和XRES、加密密鑰CK、完整性密鑰IK、匿名密鑰AK，KDF為密鑰生成函數(shù)（Key Derivation Functions，KDF），用于生成根密鑰KASME。 如果用戶的長期密鑰K泄露，攻擊者通過在空口獲取的RAND，使用上述公式進(jìn)行推導(dǎo)能夠得到根密鑰KASME，從而能夠竊聽用戶的通信。

表1 協(xié)議所涉及的實(shí)體及其長度一覽表

圖1 EPS-AKA協(xié)議交互過程

HSS向MME發(fā)送認(rèn)證信息響應(yīng)，包含認(rèn)證向量AV。

（4）MME→UE：MME接收到認(rèn)證信息響應(yīng)后，將其中的認(rèn)證向量存儲(chǔ)到數(shù)據(jù)庫中，并選擇一個(gè)之前未使用過的認(rèn)證向量來應(yīng)答UE的附著請(qǐng)求。MME向UE發(fā)送一個(gè)認(rèn)證請(qǐng)求信息，包括RAND和AUTN。

（5）UE→MME：UE接收到認(rèn)證請(qǐng)求信息后，首先進(jìn)行歸屬HSS的驗(yàn)證：計(jì)算UE的AUTN`，并與接收到的AUTN進(jìn)行比較，若相等，則UE對(duì)HSS認(rèn)證成功。UE繼續(xù)計(jì)算RES的值，然后將其作為認(rèn)證請(qǐng)求信息發(fā)送給服務(wù)MME。

（6）MME：MME接收到UE的認(rèn)證請(qǐng)求信息后，通過比較RES和XRES的值是否相等來驗(yàn)證UE。

在該協(xié)議中，攻擊者可以竊取大量合法用戶的真實(shí)身份IMSI對(duì)網(wǎng)絡(luò)發(fā)起大量的附著請(qǐng)求，使得網(wǎng)絡(luò)不得不使用大量的計(jì)算資源對(duì)攻擊者的附著請(qǐng)求進(jìn)行處理，生成認(rèn)證向量，導(dǎo)致正常用戶的服務(wù)請(qǐng)求可能不會(huì)被及時(shí)處理。5G網(wǎng)絡(luò)將存在大規(guī)模的物聯(lián)網(wǎng)UE，攻擊者通過直接或間接控制物聯(lián)網(wǎng)UE，反復(fù)對(duì)網(wǎng)絡(luò)發(fā)起認(rèn)證請(qǐng)求，使得網(wǎng)絡(luò)運(yùn)營商在對(duì)UE的認(rèn)證過程中產(chǎn)生大量的信令開銷，造成網(wǎng)絡(luò)資源的惡意占用，從而達(dá)到拒絕服務(wù)攻擊。

2.2 協(xié)議功能框架

協(xié)議框架分為三個(gè)階段：身份管理階段、認(rèn)證與密鑰管理（AKA）階段以及安全模式命令（SMC）階段。其中，身份管理階段網(wǎng)絡(luò)側(cè)得到用戶UE的身份認(rèn)證；認(rèn)證與密鑰管理階段實(shí)現(xiàn)UE和網(wǎng)絡(luò)之間的相互認(rèn)證，同時(shí)導(dǎo)出會(huì)話密鑰；安全模式命令階段實(shí)現(xiàn)對(duì)密碼算法的協(xié)商以及激活消息的保護(hù)，主要用于激活用戶UE和網(wǎng)絡(luò)側(cè)CP-AU之間的信息安全交互。其功能框架圖如圖2所示。

圖2 基于PKI的5G-DHAKA協(xié)議功能框

根據(jù)圖1對(duì)協(xié)議過程的劃分，分別介紹每一個(gè)階段的具體功能設(shè)計(jì)。

（1）身份管理階段

利用DHIES加密用戶設(shè)備的真實(shí)身份，避免了主動(dòng)攻擊者獲得UE的真實(shí)身份；網(wǎng)絡(luò)的DH公鑰的真實(shí)性由第三方信任機(jī)構(gòu)（CA）提供的證書確定；用戶在使用網(wǎng)絡(luò)的DH公鑰計(jì)算共享密鑰KDH時(shí)，利用公鑰基礎(chǔ)設(shè)施PKI來驗(yàn)證證書的有效性。

（2）認(rèn)證與密鑰管理階段

UE和網(wǎng)絡(luò)利用共享根密鑰Ki（即用戶的長期密鑰）生成相同的中間密鑰Kmid；網(wǎng)絡(luò)和用戶設(shè)備利用中間密鑰Kmid和共享密鑰KDH共同計(jì)算會(huì)話密鑰KS。

（3）安全模式命令階段

利用會(huì)話密鑰KS計(jì)算安全模式命令及響應(yīng)消息的MAC值，目的是確認(rèn)會(huì)話密鑰的正確性。

表1給出基于該協(xié)議涉及到的試題縮寫描述信息。

2.3 協(xié)議詳細(xì)設(shè)計(jì)

協(xié)議的詳細(xì)交互過程如圖3所示，其中步驟1～5為身份管理階段；步驟6～9為認(rèn)證與密鑰管理（AKA）階段；步驟10～11為安全模式命令（SMC）階段。

身份管理階段：

（1）發(fā)送附著請(qǐng)求

如果該次附著請(qǐng)求是U E的第一次入網(wǎng)請(qǐng)求，則不包含UE的臨時(shí)身份GUTI；否則包含其臨時(shí)身份GUTI。

（2）發(fā)送身份請(qǐng)求

若UE不是第一次進(jìn)行入網(wǎng)請(qǐng)求，即附著請(qǐng)求消息中含有UE的臨時(shí)身份，則CP-AU判斷其數(shù)據(jù)庫中是否存在和該臨時(shí)身份對(duì)應(yīng)的真實(shí)身份，CP-AU是否和UE建立了共享DH密鑰KDH，若同時(shí)滿足，則直接向AAA發(fā)送認(rèn)證數(shù)據(jù)請(qǐng)求。否則，CP-AU向UE發(fā)送身份請(qǐng)求信息。該身份請(qǐng)求信息中包括CP-AU的證書（包含CP-AU的DH公鑰KCpub）；同時(shí)，CP-AU判斷其是否受到拒絕服務(wù)攻擊，如果受到拒絕服務(wù)攻擊，則啟動(dòng)哈希挑戰(zhàn)響應(yīng)機(jī)制，即將哈希挑戰(zhàn)嵌入到身份請(qǐng)求信息中。哈希挑戰(zhàn)定義為：

其中，nonce`為二進(jìn)制長度為n的正整數(shù)，由CP-AU隨機(jī)生成，該正整數(shù)的長度（即n值）與CP-AU資源使用程度成正比；message1為附著請(qǐng)求。x和n構(gòu)成哈希挑戰(zhàn)。

圖3 基于PKI的5G-DHAKA協(xié)議交互過

（3）哈希挑戰(zhàn)

哈希函數(shù)的定義為：

其中，nonce``由公式2-1計(jì)算得出，message2為附著請(qǐng)求。哈希響應(yīng)生成后，UE利用PKI驗(yàn)證CP-AU證書的有效性，讀取CP-AU的DH公鑰KCpub，生成UE的DH私鑰KUpri，利用KCpub和KUpri推導(dǎo)出UE和CP-AU之間的DH共享密鑰KDH，定義為：

隨后，UE生成隨機(jī)數(shù)nonce，并利用DH共享密鑰KDH推導(dǎo)加密密鑰KE和完整性密鑰KM，定義為：

其中，KDF 為密鑰推導(dǎo)函數(shù)，“number1”和“number2”用于區(qū)分加密密鑰KE和完整性密鑰KM。KE和KM用來加密用戶UE的身份、計(jì)算消息認(rèn)證碼MAC（Message Authentication Code）值。

其中，hash為消息認(rèn)證碼算法，message3為UE向CP-AU發(fā)送的除MAC之外的身份請(qǐng)求信息。消息認(rèn)證碼MAC可以驗(yàn)證消息message的完整性。

（4）發(fā)送身份響應(yīng)

UE處理完身份請(qǐng)求信息后，向CP-AU發(fā)送身份響應(yīng)信息，其中包括：隨機(jī)數(shù)nonce、UE的公鑰KUpub、{UE的身份}KE、消息認(rèn)證碼MAC、哈希響應(yīng)nonce``。

（5）身份響應(yīng)處理

如果身份響應(yīng)信息中存在哈希響應(yīng)，則進(jìn)行哈希響應(yīng)的驗(yàn)證，即判斷nonce``==nonce`是否恒成立。若成立，則哈希挑戰(zhàn)響應(yīng)成功，允許UE的入網(wǎng)請(qǐng)求，否則拒絕該UE的入網(wǎng)請(qǐng)求。若哈希挑戰(zhàn)響應(yīng)驗(yàn)證成功，CP-AU推導(dǎo)UE和CP-AU之間的DH共享密鑰KDH，定義為：

并利用公式12、13計(jì)算加密密鑰KE和完整性密鑰KM；驗(yàn)證消息認(rèn)證碼MAC，即判斷hash（KM，message3）是否和收到的MAC值相等。若不等，則拒絕用戶入網(wǎng)申請(qǐng)，附著請(qǐng)求流程終止；若相等，則保證了消息的完整性，利用加密密鑰KE得到用戶真實(shí)身份。

認(rèn)證與密鑰管理（AKA）階段：

（6）數(shù)據(jù)請(qǐng)求認(rèn)證

認(rèn)證數(shù)據(jù)請(qǐng)求包括UE的真實(shí)身份。

（7）生成認(rèn)證向量AV

AAA根據(jù)認(rèn)證數(shù)據(jù)請(qǐng)求中的UE的真實(shí)身份找到UE的根密鑰Ki，利用Ki計(jì)算AV，由隨機(jī)數(shù)RAND、預(yù)期響應(yīng) XRES、KASME和認(rèn)證令牌AUTN 組成的認(rèn)證向量AV，其中AV的定義如公式9～16，計(jì)算完后，AAA將認(rèn)證向量AV發(fā)送給CP-AU。

（8）認(rèn)證向量處理

CP-AU收到認(rèn)證向量AV后，首先進(jìn)行AV的存儲(chǔ)，之后選擇一個(gè)之前未使用過的認(rèn)證向量AV(i)，向UE發(fā)送RAND(i)、AUTN(i)及KSIASME(i)，其中KSIASME(i)為KASME(i)的密鑰標(biāo)識(shí)，作為認(rèn)證請(qǐng)求信息，為UE與CP-AU進(jìn)行相互認(rèn)證做準(zhǔn)備。

（9）UE與CP-AU相互認(rèn)證

UE首先驗(yàn)證消息驗(yàn)證碼XMAC與MAC是否相等。若不等，則拒絕本次附著請(qǐng)求，終止附著流程；若相等，則UE繼續(xù)計(jì)算RES(i)，并將RES(i)作為認(rèn)證請(qǐng)求信息發(fā)送給CP-AU。

CP-AU收到RES(i)后，判斷RES(i)和預(yù)期響應(yīng)XRES(i)是否相等。若相等，則對(duì)于UE的認(rèn)證成功，若不等，則拒絕本次附著請(qǐng)求，終止附著流程。

在UE與CP-AU進(jìn)行相互認(rèn)證的過程中，UE與CP-AU推導(dǎo)計(jì)算兩個(gè)實(shí)體的會(huì)話密鑰KS，定義為：

其中，KDH為UE和CP-AU的DH共享密鑰，Kmid類似于LTE中的密鑰KASME。

安全模式命令階段：

（10）安全模式命令

UE與CP-AU相互認(rèn)證成功后，CP-AU向用戶UE發(fā)送安全模式命令，同時(shí)包含消息認(rèn)證碼MAC1，MAC1由會(huì)話密鑰KS推導(dǎo)得到，其定義為：

其中，message4為CP-AU向UE發(fā)送的消息。

（11）安全模式完成

UE收到CP-AU發(fā)送的安全模式命令以及消息認(rèn)證碼MAC1后，利用會(huì)話密鑰KS驗(yàn)證其所接收到的消息認(rèn)證碼是否正確，即hash(KS,message4)== MAC1是否恒成立。若不成立，UE終止本次附著流程；否則計(jì)算消息認(rèn)證碼MAC2，定義為：

其中，message5為UE向CP-AU發(fā)送的消息。U E向C P-A U發(fā)送安全模式完成信息以及消息認(rèn)證碼MAC2。CP-AU收到UE發(fā)送的安全模式完成以及MAC2后，驗(yàn)證hash（KS,message5）== MAC2是否恒成立。若成立，則UE和CP-AU完成本次安全的附著連接；否則，CP-AU終止本次附著流程。MAC1和MAC2完成驗(yàn)證后，CP-AU和UE將擁有相同的會(huì)話密鑰KS，同時(shí)保證了CP-AU和UE擁有相同的DH共享密鑰KDH，并且分別保存在CP-AU和UE內(nèi)，在之后的附著流程中可以利用保存的DH共享密鑰KDH計(jì)算新的會(huì)話密鑰KS。

3 基于PKI的5G-DHAKA協(xié)議的形式化驗(yàn)證

3.1 形式化建模

本節(jié)使用形式化仿真工具Scyther對(duì)5G-DHAKA協(xié)議的機(jī)密性與認(rèn)證性進(jìn)行驗(yàn)證。根據(jù)圖1劃分的三個(gè)階段與圖2對(duì)應(yīng)每個(gè)階段的具體交互過程，分別對(duì)每個(gè)階段進(jìn)行形式化建模，在建模后統(tǒng)一聲明驗(yàn)證事件進(jìn)行驗(yàn)證。如表2至表3所示分別對(duì)應(yīng)身份管理、認(rèn)證與密鑰管理、安全模式命令的形式化建模。每一個(gè)步驟編號(hào)嚴(yán)格對(duì)應(yīng)2.2小節(jié)中關(guān)于協(xié)議詳細(xì)設(shè)計(jì)的步驟編號(hào)。

步驟1 的Nonce1為一次性隨機(jī)數(shù)；MMC為歸屬網(wǎng)絡(luò)國家號(hào)碼；MNC為網(wǎng)絡(luò)號(hào)碼移動(dòng)網(wǎng)絡(luò)碼。步驟5中的IMSI為國際移動(dòng)用戶識(shí)別碼，表示和臨時(shí)身份GUTI對(duì)應(yīng)的用戶UE的真實(shí)身份。

步驟6中的I M S I為用戶U E的真實(shí)身份；SNID為服務(wù)網(wǎng)標(biāo)識(shí)；NT為服務(wù)網(wǎng)類型。

3.2 安全屬性驗(yàn)證設(shè)置

完成建模后，對(duì)U E進(jìn)行安全屬性驗(yàn)證，如表5所示為驗(yàn)證的所有事件。Claim函數(shù)為Scyther指定用于驗(yàn)證某種屬性的函數(shù)，該函數(shù)的第一個(gè)參數(shù)為驗(yàn)證實(shí)體，第二個(gè)參數(shù)為實(shí)體狀態(tài)，第三個(gè)參數(shù)為驗(yàn)證屬性，其中Alive、Weakagree、Niagree、Nisynch分別為實(shí)體的激活、休眠、同步與異步同步狀態(tài)，不需要指定驗(yàn)證屬性。

表2 身份管理形式化建模

表3 認(rèn)證與密鑰協(xié)商形式化建模

表4 安全模式命令階段形式化建模

表5 三種實(shí)體的安全屬性

3.3 形式化驗(yàn)證

如表6所示，為本文用于仿真實(shí)驗(yàn)的實(shí)驗(yàn)環(huán)境配置信息。如圖4～6所示為Scyther進(jìn)行驗(yàn)證后的結(jié)果。三種實(shí)體的驗(yàn)證結(jié)果表明，全部事件均未檢測出攻擊路徑，三種實(shí)體在交互過程中的所有實(shí)體變量均具備保密性與認(rèn)證性。

表6 仿真環(huán)境設(shè)置

4 結(jié)束語

為了增強(qiáng)5 G用戶在移動(dòng)通信網(wǎng)絡(luò)中附著請(qǐng)求流程的安全性，本文首先對(duì)EPSAKA協(xié)議流程進(jìn)行詳細(xì)分析，發(fā)現(xiàn)了其可能存在的安全漏洞，由此提出了基于PKI的5G-DHAKA協(xié)議，并對(duì)協(xié)議交互過程進(jìn)行了詳細(xì)設(shè)計(jì)；然后利用形式化驗(yàn)證工具Scyther對(duì)基于PKI的5G-DHAKA協(xié)議進(jìn)行了形式化建模及安全屬性分析，實(shí)驗(yàn)結(jié)果表明了所提協(xié)議滿足機(jī)密性以及存在性、非單射一致性、非單射同步性等安全屬性，通過理論協(xié)議表明本文的工作可以有效地緩解分布式拒絕服務(wù)攻擊。

圖6 實(shí)體AAA端的安全屬性驗(yàn)證結(jié)果