朱詩兵,周 赤,李長青
(1.裝備學院 信息裝備系,北京 101416;2.陸軍航空兵學院 指揮系,北京 101100)
LTE網絡切換密鑰更新方案分析與改進
朱詩兵1,周 赤2,李長青1
(1.裝備學院 信息裝備系,北京 101416;2.陸軍航空兵學院 指揮系,北京 101100)
LTE用戶切換時的密鑰管理在很大程度上關系著用戶安全,切換密鑰管理包括密鑰的生成、分發、更新和撤銷。對現有長期演進(Long Term Evolution,LTE)網絡切換密鑰管理更新機制進行簡要介紹,包括X2和S1切換密鑰更新方案。針對X1切換僅有兩跳前向密鑰隔離的安全缺陷,借鑒S1切換方案設計思想,提出一跳前向密鑰隔離的X2切換密鑰更新方案(OFKS-X2),并對OFKS-X2密鑰更新方案進行了安全性和實用性分析。結果表明,OFKS-X2密鑰更新方案能夠提供一跳前向密鑰隔離,對協議有效性影響不大,且用戶的消息工作量沒有變化,網絡側的消息處理復雜度略有增加,用戶側計算量基本不變,網絡側計算量略有增加。
LTE;切換密鑰管理;X1切換;S1切換;一跳前向密鑰隔離
LTE技術是我國主推的第4代移動通信技術,尤其是其中的TDD部分(即TD-LTE[1-2])。一方面是由于我國擁有自主研發知識產權,另一方面是由于TD-LTE可以與TD-SCDMA很好地兼容,具有廣闊的市場前景,得到我國政府和主要通信廠商的大力支持[3-4]。盡管LTE的安全機制相對前3代移動通信技術有所改善,但仍然無法完全滿足某些對安全性有較高要求的使用場合,需要進行適應性改進。其中用戶切換機制常常成為攻擊者的目標,而LTE切換密鑰管理與切換的安全性密切相關。
本文首先介紹LTE的切換密鑰管理[5-6],包括X2切換密鑰更新方案和S1切換密鑰更新方案,對LTE切換密鑰更新方案進行安全性分析;針對X2切換密鑰更新方案只能提供兩跳前向密鑰隔離這一安全缺陷,借鑒S1切換密鑰更新方案的思想,提前MME參與協議的時間,使得MME在UE接到源基站發送來的切換到目標基站的命令之前,就為目標基站提供新鮮的密鑰材料。在此基礎上提出一跳前向密鑰分離OFKS-X2(One-hop Forward Key Separation,OFKS)密鑰更新方案;最后針對2類攻擊模型對OFKS-X2密鑰更新方案的安全性、有效性進行分析。
1.1 LTE切換中的密鑰推演
LTE中有2種切換類型:X2切換[7]和S1切換[8],這是以切換時主要切換信令傳輸時經由的接口命名的,LTE密鑰管理[9]如圖1所示。當用戶移動時,可能會從一個eNB(源eNB)移動到同一個MME管理下的另一個eNB(目標eNB),這種移動會導致用戶在2個eNB之間進行切換,該切換是通過X2接口實現的,因此這種切換被稱為X2切換。當源eNB和目標eNB之間不存在X2接口連接,或者源eNB發起的X2切換沒有成功時,或者源eNB通過一些動態信息會做出基于S1接口發起的切換決定,這種切換稱為S1切換。

圖1 LTE密鑰管理
密鑰更新材料是由移動性管理實體[10](Mobility Management Entity,MME)和用戶設備[11](User Equipment,UE)基于下一跳密鑰(Next-Hop key,NH)和本地主密鑰KASME生成的。密鑰更新步驟如下:
NH0=KeNB-0=KDF(KASME,NASuplinkCOUNT),
(1)
NH1=KDF(KASME,KeNB-0),
(2)
NHNCC+1=KDF(KASME,NHNCC)。
(3)
首先AS安全建立,MME和UE利用KASME推算出KeNB和臨時參數NH。并且每個NH參數都有一個NH鏈計數器(NCC)與其相對應。初始的KeNB-0由KASME和NASuplinkCOUNT(上行NAS COUNT)推演出來,對應的NCC設為0。同時MME和UE也利用KASME和KeNB-0將NH1推算出來,對應的NCC值為1。
NCC是一個3位的NH的密鑰索引(其值為0~7),通過切換命令信令發送到UE。從UE的角度,NCC的值不會減小,因為UE在推演NH值時不能倒退,而且沒有存儲舊的NH值。所以,如果UE在切換命令中收到的NCC值比當前使用的KeNB的NCC值要大,UE會在同步{NH,NCC}參數值之后,進行垂直推演(式(5))。否則,UE會進行水平推演(式(4))。
KeNB*=KDF(NHNCC,PCI,EARFCN-DL),
(4)
KeNB*=KDF(KeNB,PCI,EARFCN-DL)。
(5)
式中,PCI(Physical Cell ID)為目標小區的物理小區標識;EARFCN-DL(EUTRAN Absolute Radio Frequency Channel Number-Down Link)為E-UTRAN絕對頻率信道值—下行鏈路。
式(4)表示水平推演過程,在源基站不存在可用的{NH,NCC}對時運行。式(5)表示垂直推演過程,此時源基站(X2切換)或目標基站(S1切換)中存在可用的{NH,NCC}對,并可以利用它推演出新鮮的KeNB*。
1.2 LTE中的切換密鑰更新方案
LTE的X2切換密鑰更新方案流程[12]如圖2所示。

圖2 LTE中X2切換密鑰更新方案流程
具體的流程描述如下:
(0a)~(0e) UE和HSS初始化下一跳密鑰NH,在UE建立初始化AS上下文時運行。MME通過S1AP(S1:S1接口;AP:Application Protocol,應用協議)將NH和NCC通初始化上下文請求傳送給eNB。
(1~5) UE向源eNB發送測量報告消息;源eNB做出進行切換判決并做出切換決定;源eNB向目標eNB發送包含NCC的切換請求消息;目標eNB向源eNB返回包含目標PCI的切換請求應答消息。在收到切換請求應答消息之后,源eNB由NH,目標PCI和EARFCN-DL計算出KeNB*。計算KeNB*子過程如圖3所示。

圖3 KeNB*計算子過程
(6~10) 源eNB將計算出的KeNB*發送給目標eNB,此消息還包含當前的RRC/UP算法標識。目標eNB更新KeNB,并推算出用戶平面(User Plane,UP)和無線資源控制(Radio Resource Control,RRC)密鑰。KeNB更新過程如圖4所示。
目標eNB向源eNB發送切換命令消息,包含目標eNB為用戶生成的新的小區無線網絡的臨時標識符(Cell Radio Network Temporary Identifier,C-RNTI)及選定的RRC/UP算法。收到切換命令消息后,源eNB向用戶發送切換命令,包含NCC值,目標PCI,EARFCN-DL和目標eNB選定的算法標識。UE進行NH同步,計算KeNB*,更新KeNB并推導UE、RRC密鑰。NH同步子過程如圖5所示。

圖4 KeNB更新過程

圖5 NH同步子過程
(11~15) UE存儲新的NH值,即NH=NH*;NCC=Temp-NCC,并釋放臨時變量NH*和Temp-NCC。UE向目標eNB發送切換確認消息。目標eNB向MME發送路徑切換消息,以更新數據路由,此消息包含NCC值。MME向服務網關(S-GW)發送用戶面更新請求。MME計算NCC[+1]=NCC+1,并進行NH同步。
(16~19) 服務網關向MME返回用戶面更新應答消息。MME向目標eNB發送路徑切換應答消息,以提供NH*[+1]和NCC[+1]值用于下一次切換。MME存儲新的NH值,即令NH=NH*[+1];NCC=NCC[+1]。目標eNB向源eNB發送資源釋放消息,以使源eNB釋放相應資源。
LTE的S1切換密鑰更新方案流程如圖6所示。NH=KDF(KASME,最新NCC)。

圖6 LTE中S1切換密鑰更新方案流程
具體流程描述如下:
1.UE向源eNB發送測量報告消息;
2. 源eNB進行切換判決并作出切換決定;
3. 源eNB向MME發送切換需求消息;
4a.、4b. 收到切換需求消息后,MME利用本地存儲數據計算新的{NH,NCC}并存儲;
5. MME向目標eNB發送S1切換請求消息,包含{NH,NCC}對;
6. 在收到切換請求消息之后,目標eNB通過切換請求消息中的NH,目標PCI和EARFCN-DL計算出KeNB*,并推導出UP、RRC密鑰,其中KeNB*計算過程與X1切換中的相同;
7. 目標eNB向MME發送切換請求應答消息,包含目標PCI;
8. MME向源eNB發送切換命令消息,包含NCC和目標PCI;
9. 收到切換命令消息后,源eNB向用戶發送切換命令消息,包含NCC值,目標PCI,EARFCN-DL和目標eNB選定的算法標識;
10a.~10c. UE進行NH同步,計算KeNB*,更新KeNB并推導UE、RRC密鑰。
NH同步子過程和KeNB*計算子過程與X1切換中相同。步驟11~19與X2切換中的步驟11~19相同。
LTE中,源基站在計算目標基站密鑰KeNB*時使用單向函數作為KDF,這樣目標基站就無法推演出UE在源基站中使用的密鑰KeNB。因此LTE可以提供一跳后向密鑰隔離。
值得注意的是,在S1切換中MME推演出新鮮的{NH,NCC}對,并將其直接提供給目標基站,這樣源基站就無法得知KeNB*,即S1切換可以提供一跳前向密鑰隔離。而X2切換只能提供兩跳前向密鑰隔離,這是由于X2切換中,源基站知道{NH,NCC}對和KeNB*,但是在兩跳之后,由于源基站無法獲知X2切換之后路徑轉換信令中提供的{NH,NCC}對,源基站將無法獲知下一個KeNB*,即KeNB**。
LTE推薦的S1切換密鑰更新方案可以提供一跳前向隔離,而X2切換只能提供兩跳前向隔離,這將為LTE網絡安全[13-14]埋下隱患,需對X1切換密鑰更新方案進行相應改進。
OFKS-X2密鑰更新方案設計構想:源eNB無法獲知目標eNB推導新密鑰時所需的全部密鑰材料;MME在UE接到源基站發送的切換到目標基站的命令之前,為目標基站提供新鮮的密鑰材料;直接在目標eNB中完成KeNB*的計算并更新,而不再通過源eNB傳送。
借鑒S1切換密鑰更新方案,在LTE建議的X2切換密鑰更新方案的基礎上,從設計思路出發,本文設計的OFKS-X2密鑰更新方案的實現過程如圖7所示。
由圖7可以看出,OFKS-X2密鑰更新方案實現了最初的設計思路想,相比原方案,OFKS-X2密鑰更新方案的實現過程做出了以下改變:
① 增加了以下步驟:
步驟4*在收到源eNB發來的切換請求消息后,目標eNB向MME發送密鑰更新請求消息,包含NCC。這樣就如S1密鑰更新方案一樣,MME在切換之前就收到了路徑切換的通知。
步驟5*在收到目標eNB發來的密鑰更新請求消息后,MME將收到的NCC加1,進行一次NH同步,并儲存新鮮的{NH,NCC}對。
此步驟使得本方案中計算KeNB*的輸入與LTE方案中的不同,LTE方案計算KeNB*的輸入是源eNB存儲的NH值,而本方案的輸入是原NCC+1,這是實現一跳前向密鑰隔離的關鍵。
步驟6*MME將新鮮的{NH,NCC}對通過密鑰更新請求應答消息返回給目標eNB。
通過步驟5和步驟6,MME就在UE接到源基站發送來的切換到目標基站的命令之前,為目標基站提供新鮮的密鑰材料。
步驟7*在收到MME發來的密鑰更新請求應答消息后,目標eNB由收到的NH,目標PCI和EARFCN-DL計算出KeNB*,更新KeNB并推算出UP和RRC密鑰。更新KeNB的過程跟EPS-AKA相同。
這樣就直接在目標eNB中完成了KeNB**的計算,而不再通過源eNB傳送。

圖7 OFKS-X2密鑰更新方案
② 減去了LTE原有X2密鑰更新方案中的步驟4、步驟5、步驟6和步驟7。其中步驟5~7由步驟7*取代。這樣源eNB只能通過目標eNB發來的切換請求應答消息得知最新的NCC值,但由上述公式知道,推導NH值需要KASME,而只有UE和MME知道KASME,其他實體無法獲知,包括源eNB,這樣源eNB無法獲知目標eNB推導新密鑰時所需的全部密鑰材料(即無法獲知最新的NH值)。
除上述改變外,OFKS-X2密鑰更新方案保持LTE原有X2密鑰更新方案的其他步驟不變,最大限度地繼承了原有方案的密鑰和命令消息。
4.1 安全性分析
針對2類攻擊模型對本方案的安全性進行分析。
① 攻擊者只能獲取空口信號。在這種情況下,攻擊者可以得到所有的空口信號,并獲取其中的密鑰材料,包括C-RNTI、PCI、最新的NCC以及目標eNB選定的接入層密碼算法標識。新密鑰的推導綁定了最新NH、C-RNTI、PCI等參數,即KeNB**=KDF(KeNB*,C-RNTI)=KDF(KDF(最新NH,PCI),C-RNTI),最新NH=KDF(KASME,最新NCC),其中的KASME只為UE和MME所知,并且不會在空口傳輸,因此只能獲取空口信號的攻擊者是無法獲知最新NH的,也就無法推導出新的KeNB**。因此本方案可以有效對抗此類攻擊。
② 攻擊者除能獲取空口信號,還能完全控制源eNB。此種情況下,攻擊者不僅能夠獲得空口信號中的所有密鑰材料,還能夠獲取存儲在源eNB中的密鑰材料,包括當前的KeNB、NH、PCI和C-RNTI。跟模型一中情況一樣攻擊者仍不能得到KASME,攻擊者是無法獲知最新NH的,也就無法推導出新的KeNB**。因此本方案可以有效對抗此類攻擊。
4.2 有效性分析
下面以協議的執行效率作為標準,對OFKS-X2密鑰更新方案性能進行分析。相比于現有LTE方案:
① 用戶的消息工作量沒有變化,網絡側的消息處理復雜度略有增加。
和現有的LTE方案相比,本方案在目標eNB和MME之間增加了2條消息:一條是目標eNB向MME發送的密鑰更新請求消息(圖7中消息4*),為MME提供NCC,以供其進行NH同步,產生新鮮的密鑰材料;另一條是MME向目標eNB發送的密鑰更新請求應答消息(圖7中消息6*),為目標eNB提供新鮮密鑰材料,以供其生成的新的KeNB。增加了網絡域消息處理復雜度。但是,本方案沒有變動用戶和eNB之間交互的消息流,從用戶角度來看,本方案消息工作量沒有變化,并且獲得了更強的安全保護。
② 用戶側的計算量基本不變,網絡側的計算量略有增加。
和現有的LTE方案相比,本方案用戶側的密鑰推導過程依然經歷了4個子過程:NH同步、存儲新的NH值、計算KeNB*、更新KeNB并推導UP、RRC密鑰,因此本方案中用戶側的計算量與LTE方案相比基本沒變。目標eNB的計算量略有增加,這是因為本方案中目標eNB中增加了計算KeNB*的過程(圖7中消息7*)。MME的計算量比LTE方案略有增加,這是由于為了實現一跳前向密鑰隔離,相對原方案,本方案中MME在協議開始時增加了一次NH同步的過程(圖7中步驟5)。
綜上所述,雖然為實現一跳前向密鑰隔離,OFKS-X2密鑰更新方案增加了網絡域的消息處理復雜度,但是從用戶角度看,本方案在消息工作量沒有變化的情況下,提供了更強的安全保護。而且,增加2條消息傳輸對于網絡域來說是可以承受的。
本文介紹了LTE的切換密鑰管理機制,對LTE切換密鑰更新方案進行了安全性分析。經分析可知X2切換密鑰更新方案只能提供兩跳前向密鑰隔離。借鑒S1切換密鑰更新方案的設計思想,提前了MME參與協議的時間,提出了能夠提供一條前向密鑰隔離的X2密鑰更新方案——OFKS-X2密鑰更新方案。通過2類攻擊模型對所提方案的安全性進行了分析,證明OFKS-X2密鑰更新方案能夠提供一跳前向密鑰隔離。以協議的執行效率作為標準,對所提方案的有效性進行分析,分析結果表明:① 用戶的消息工作量沒有變化,網絡側的消息處理復雜度略有增加;② 用戶側計算量基本不變,網絡側計算量略有增加。
[1] 沈 嘉,索士強,全海洋,等.3GPP長期演進(LTE)技術原理與系統設計[M].北京:人民郵電出版社,2008.
[2] SESIA S,TOUFIK I,BAKER M.LTE:The UMTS Long Term Evolution[M].New York:John Wiley & Sons,2009.
[3] 杜金宇,程 鋒,蔣 群,等.LTE全球主流運營商及產業鏈發展動態[J].電信工程技術與標準化,2012,25(7):17-22.
[4] 李進良.加速TD-LTE全國4G網建設共同促進全民信息消費[J].移動通信,2014,38(1):17-20.
[5] 曾 勇.LTE/SAE密鑰管理技術研究[J].通信技術,2009(7):97-100.
[6] 胡國華,袁樹杰,譚 敏.4G移動通信技術與安全缺陷分析[J].通信技術,2008,41(7):155-157.
[7] 李泰成,何 莉,吳 檳.具有一跳前向安全性的X2切換密鑰更新協議[J].計算機系統應用,2011,20(8):67-71.
[8] 趙 倫.LTE系統中的S1切換技術研究與設計[D].武漢:武漢郵電科學研究院,2012.
[9] 3GPP TS33.401 V9.0.0 (2009-06).Security Architecture(Release 9) [S],2009.
[10] 許盛宏,李力卡,陳慶年.LTE網絡MME的安全容災方案研究[J].移動通信,2015,39(22):9-13.
[11] 楚佩佳.基于LTE系統的UE隨機接入過程研究[D].杭州:杭州電子科技大學,2011.
[12] FORSBERG D,HORN G,MOELLER W D,et al.LTE Security[M].New York:John Wiley & Sons,2012.
[13] 汪良辰.LTE安全接入機制研究[D].西安:西安電子科技大學,2012.
[14] 高 楓,李一喆,馬 錚,等.LTE網絡安全部署研究[J].移動通信,2014,38(23):25-28.
朱詩兵 男,(1969—),博士,教授。主要研究方向:信息與通信系統。
周 赤 女,(1989—),碩士研究生。主要研究方向:信息與通信系統。
The Improvement of LTE Handover Key Refresh Scheme
ZHU Shi-bing1,ZHOU Chi2,LI Chang-qing1
(1.DepartmentofInformationEquipment,AcademyofEquipment,Beijing101416,China;2.DepartmentofCommand,ChinesePeople’sLiberationArmyAviationSchool,Beijing101100,China)
Key management has a big impact on LTE user security in handover process.Handover key management includes handover key generation,distribution,refresh and revocation.In this paper, we will introduce the handover key refresh mechanism in detail,including X2 handover key refresh scheme and S1 handover key refresh scheme.Finally,with reference to the S1 handover scheme,an enhanced X2 handover key refresh scheme OFKS(One-hop Forward Key Separation)X2 handover key refresh scheme is put forward to over come the disadvantage of the original one in LTE which can only provide two-jump forward security by advancing the time when MME is involved in the agreement.Analysis results show that the OFKS-X2 key update scheme can provide a jump forward to the key and has little effect on the protocol.No changes happen in the user’s message workload and side calculation.However the complexity of message processing and calculation in the network side is slightly increased.
LTE;handover key management;X1 handover;S1 handover;OFKS
10.3969/j.issn.1003-3106.2017.01.03
朱詩兵,周 赤,李長青.LTE網絡切換密鑰更新方案分析與改進[J].無線電工程,2017,47(1):10-15.
2016-10-26
文獻標志碼 A 文章編號 1003-3106(2017)01-0010-06