基于PKI的5G-DHAKA協(xié)議安全性分析

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

（1.天津大學智能與計算學部，天津 300072；2.中國移動通信有限公司研究院，北京 100053）

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HSS向MME發(fā)送認證信息響應，包含認證向量AV。

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

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

（6）MME：MME接收到UE的認證請求信息后，通過比較RES和XRES的值是否相等來驗證UE。

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

2.2 協(xié)議功能框架

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

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

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

（1）身份管理階段

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

（2）認證與密鑰管理階段

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

（3）安全模式命令階段

利用會話密鑰KS計算安全模式命令及響應消息的MAC值，目的是確認會話密鑰的正確性。

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

2.3 協(xié)議詳細設計

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

身份管理階段：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（5）身份響應處理

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

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

認證與密鑰管理（AKA）階段：

（6）數(shù)據(jù)請求認證

認證數(shù)據(jù)請求包括UE的真實身份。

（7）生成認證向量AV

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

（8）認證向量處理

CP-AU收到認證向量AV后，首先進行AV的存儲，之后選擇一個之前未使用過的認證向量AV(i)，向UE發(fā)送RAND(i)、AUTN(i)及KSIASME(i)，其中KSIASME(i)為KASME(i)的密鑰標識，作為認證請求信息，為UE與CP-AU進行相互認證做準備。

（9）UE與CP-AU相互認證

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

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

在UE與CP-AU進行相互認證的過程中，UE與CP-AU推導計算兩個實體的會話密鑰KS，定義為：

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

安全模式命令階段：

（10）安全模式命令

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

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

（11）安全模式完成

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

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

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

3.1 形式化建模

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

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

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

3.2 安全屬性驗證設置

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

表2 身份管理形式化建模

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

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

表5 三種實體的安全屬性

3.3 形式化驗證

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

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

4 結束語

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

圖6 實體AAA端的安全屬性驗證結果