基于空中接口的LTE解密方法研究
加入技術(shù)交流群
掃碼加入
和技術(shù)大咖面對(duì)面交流
海量資料庫(kù)查詢(xún)
王嘉嘉，楊傳偉，吳?磊，宋加齊(中國(guó)電子科技集團(tuán)公司第四十一研究所，安徽?蚌埠?233000；中電科儀器儀表(安徽)有限公司，安徽?蚌埠?233010；電子信息測(cè)試技術(shù)安徽省重點(diǎn)實(shí)驗(yàn)室,安徽?蚌埠?233010)
本文引用地址：http://2s4d.com/article/201911/407666.htm摘?要：針對(duì)3GPP LTE標(biāo)準(zhǔn)，研究了LTE系統(tǒng)安全體系架構(gòu)。首先介紹了LTE系統(tǒng)中的密鑰層次架構(gòu)，針對(duì)加密和完整性保護(hù)過(guò)程分別進(jìn)行了詳細(xì)介紹，然后基于LTE空中接口對(duì)解密和完整性保護(hù)驗(yàn)證方法進(jìn)行了設(shè)計(jì)和詳細(xì)分析，最后對(duì)方法和適用場(chǎng)景作出總結(jié)。
*文章由安徽省重點(diǎn)研究和開(kāi)發(fā)計(jì)劃項(xiàng)目(1804a09020042)，國(guó)家科技重大專(zhuān)(2017ZX03001021) 資助
[作者簡(jiǎn)介] 王嘉嘉(1984—)，男，高級(jí)工程師，主要從事移動(dòng)通信測(cè)試技術(shù)研究。E-mail:251799120@qq.com
0 引言
隨著LTE移動(dòng)通信技術(shù)的飛速發(fā)展和普及，移動(dòng)通信越來(lái)越深入到人們的日常生活，因此，移動(dòng)通信安全也越來(lái)越受到人們的關(guān)注?；贚TE空中接口對(duì)無(wú)線(xiàn)信號(hào)的監(jiān)測(cè)，也成為安全部門(mén)、設(shè)備廠(chǎng)商、高校等機(jī)構(gòu)的研究方向。本文對(duì)基于LTE空中接口的解密和完整性保護(hù)驗(yàn)證方法進(jìn)行設(shè)計(jì)，為相關(guān)研究提供了方法和思路。
1 LTE系統(tǒng)密鑰層次
LTE系統(tǒng)采用兩層安全保護(hù)機(jī)制：第1層為E-UTRAN中的無(wú)線(xiàn)資源控制（RRC）層安全和用戶(hù)層安全，即接入層（AS）安全；第2層為演進(jìn)型分組核心網(wǎng)（EPC）中的安全，即非接入層（NAS）安全 [1] ，具體體現(xiàn)為L(zhǎng)TE系統(tǒng)密鑰層次架構(gòu) [2] ，如圖1所示。
圖1中，K是所有密鑰生成算法的基礎(chǔ)，即根密鑰；CK和IK是在鑒權(quán)過(guò)程中生成的密鑰對(duì)，即加密密鑰和完整性保護(hù)密鑰；K ASME 是根據(jù)CK和IK生成的中間密鑰，用于推演下層密鑰；K NASenc 是用于NAS層加密的密鑰；K NASint 是用于NAS層完整性保護(hù)的密鑰；K eNB 是根據(jù)K ASME 生成的中間密鑰，用于推演下層密鑰；K UPenc是用于AS層用戶(hù)面數(shù)據(jù)加密的密鑰；K RRCint 是用于AS層RRC信令完整性保護(hù)的密鑰；K RRCenc 是用于AS層RRC信令加密的密鑰 [3] 。
2 加密和完整性保護(hù)原理
2.1 加密過(guò)程
加密過(guò)程 [2] ，如圖2所示。發(fā)送端利用加密密鑰KEY、計(jì)數(shù)器COUNT、承載標(biāo)識(shí)BEARER ID、上下行方向DIRECTION和密鑰流長(zhǎng)度LENGTH作為加密算法輸入?yún)?shù)，根據(jù)選擇的加密算法計(jì)算出密鑰流，與明文進(jìn)行異或生成密文，發(fā)送給接收端 [1] 。
接收端利用與發(fā)送端相同的加密密鑰、計(jì)數(shù)器、承載標(biāo)識(shí)、上下行方向、密鑰流長(zhǎng)度和加密算法，計(jì)算出密鑰流，與接收到的密文進(jìn)行異或生成明文 [1] 。
2.2 完整性保護(hù)過(guò)程
完整性保護(hù)過(guò)程 [2] ，如圖3所示。發(fā)送端利用完整性密鑰KEY、計(jì)數(shù)器COUNT、承載標(biāo)識(shí)BEARER ID、上下行方向DIRECTION和消息本身作為完整性保護(hù)算法輸入?yún)?shù)，根據(jù)完整性保護(hù)算法計(jì)算出完整性校驗(yàn)碼MAC-I，發(fā)送端將消息本身和MAC-I一起發(fā)送給接收端 [1] 。
接收端利用與發(fā)送端相同的完整性保護(hù)密鑰、計(jì)數(shù)器、承載標(biāo)識(shí)、上下行方向、完整性保護(hù)算法和接收到的消息本身，計(jì)算出完整性校驗(yàn)碼XMAC-I，與接收到消息中的MAC-I進(jìn)行比較，若一致，則認(rèn)為接收到的消息是原始發(fā)送的消息 [1] 。
3 解密和完整性保護(hù)驗(yàn)證設(shè)計(jì)
3.1 解密方法設(shè)計(jì)
本文基于LTE空中接口，解密方法設(shè)計(jì)如下：
步驟1通過(guò)RRC連接建立消息 [4] ，獲取其中攜帶的參數(shù)rb-Identity，參數(shù)AS BEARERID=rb-Identity-1。
步驟2通過(guò)鑒權(quán)請(qǐng)求消息 [5] ，獲取其中攜帶的參數(shù)RAND，鑒權(quán)請(qǐng)求消息如圖4所示。
步驟3利用根密鑰K和RAND，計(jì)算出CK和IK；利用CK和IK，計(jì)算出K ASME ；利用K ASME ，計(jì)算出K NASenc 和K eNB ；利用K eNB ，計(jì)算出K UPenc 和K RRCenc ；當(dāng)對(duì)NAS消息解密時(shí)，參數(shù)NAS KEY=K NASenc ；當(dāng)對(duì)AS RRC消息解密時(shí)，參數(shù)AS KEY=K RRCenc ；當(dāng)對(duì)AS用戶(hù)數(shù)據(jù)解密時(shí)，參數(shù)AS KEY=K UPenc ；其中，密鑰推演算法為KDF [2] 算法。
步驟4通過(guò)NAS安全模式命令消息 [5] ，獲取其中攜帶的參數(shù)NAS加密算法，其值包括128-EEA1、128-EEA2和128-EEA3，NAS安全模式命令消息如圖5所示。
步驟5通過(guò)之后的NAS消息，獲取其中攜帶的參數(shù)NAS SN，參數(shù)NAS COUNT=0x00 || NAS OVERFLOW|| NAS SN，其中||表示比特級(jí)聯(lián)，NAS OVERFLOW為NAS SN的溢出計(jì)數(shù)器 [2] [5] ，對(duì)于上下行，NAS COUNT分別維護(hù)。
步驟6經(jīng)過(guò)以上步驟，已經(jīng)確定NAS KEY、NASCOUNT和NAS加密算法，另外，NAS BEARER ID=0，NAS DIRECTION上行時(shí)為 0 ， 下 行 時(shí) 為 1 ， N A SLENGTH=128，這樣便能夠計(jì)算出密鑰流，與密文異或，實(shí)現(xiàn)對(duì)NAS消息的解密。
步驟7通過(guò)RRC安全模式命令消息 [4] ，獲取其中攜帶的參數(shù)AS加密算法，其值包括EEA1、EEA2和EEA3，RRC安全模式命令消息如圖6所示。
步驟8通過(guò)之后的PDCP PDU，獲取其中攜帶的參數(shù)PDCP SN，參數(shù)AS COUNT=HFN || PDCP SN，其中HFN為超幀號(hào) [6] ，對(duì)于上下行，AS COUNT分別維護(hù)。
步驟9：經(jīng)過(guò)以上步驟，已經(jīng)確定AS BEARER ID、AS KEY、AS COUNT和AS加密算法，另外，AS DIRECTION上行時(shí)為0，下行時(shí)為1，ASLENGTH=128，這樣便能夠計(jì)算出密鑰流，與密文異或，實(shí)現(xiàn)對(duì)AS數(shù)據(jù)的解密。
步驟10之后的NAS消息解密，步驟同上；
步驟11之后的AS信令數(shù)據(jù)和用戶(hù)數(shù)據(jù)解密，需要先通過(guò)RRC連接重配消息 [4] 獲取其中攜帶的rb-Identity，用rb-Identity-1更新參數(shù)AS BEARER ID，其余步驟同上。
3.2 完整性保護(hù)驗(yàn)證方法設(shè)計(jì)
本文基于LTE空中接口，完整性保護(hù)驗(yàn)證方法設(shè)計(jì)如下：
步驟1~2同解密方法。
步驟3利用根密鑰K和RAND，計(jì)算出CK和IK；利用CK和IK，計(jì)算出K ASME ；利用K ASME ，計(jì)算出K NASint 和K eNB ；利用K eNB ，計(jì)算出K RRCint ；當(dāng)對(duì)NAS消息完整性保護(hù)驗(yàn)證時(shí)，參數(shù)NAS KEY=K NASint ；當(dāng)對(duì)AS RRC消息完整性保護(hù)驗(yàn)證時(shí)，參數(shù)AS KEY=K RRCint ；其中，密鑰推演算法為KDF算法。
步驟4通過(guò)NAS安全模式命令消息，獲取其中攜帶的參數(shù)NAS完整性保護(hù)算法，其值包括128-EIA1、128-EIA2和128-EIA3。
步驟5同解密方法。
步驟6經(jīng)過(guò)以上步驟，已經(jīng)確定NAS KEY、NASCOUNT和NAS完整性保護(hù)算法，另外，NAS BEARERID=0，NAS DIRECTION上行時(shí)為0，下行時(shí)為1，再加上需要完整性保護(hù)驗(yàn)證的消息本身，這樣便能計(jì)算出MAC-I，與消息本身所攜帶的MAC進(jìn)行對(duì)比，如果一致，則完整性保護(hù)驗(yàn)證通過(guò)，否則，說(shuō)明消息被篡改。
步驟7通過(guò)RRC安全模式命令消息，獲取其中攜帶的參數(shù)AS完整性保護(hù)算法，其值包括EIA1、EIA2和EIA3。
步驟8同解密方法。
步驟9經(jīng)過(guò)以上步驟，已經(jīng)確定AS BEARER ID、AS KEY、AS COUNT和AS完整性保護(hù)算法，另外，ASDIRECTION上行時(shí)為0，下行時(shí)為1，再加上需要完整性保護(hù)驗(yàn)證的消息本身，這樣便能計(jì)算出MAC-I，與消息本身所攜帶的MAC進(jìn)行對(duì)比，如果一致，則完整性保護(hù)驗(yàn)證通過(guò)，否則，說(shuō)明消息被篡改。
步驟10之后的NAS消息完整性保護(hù)驗(yàn)證，步驟同上；
步驟11之后的AS信令數(shù)據(jù)完整性保護(hù)驗(yàn)證，需先通過(guò)RRC連接重配消息獲取其中攜帶的rb-Identity，用rb-Identity-1更新參數(shù)AS BEARER ID，其余步驟同上。
5 結(jié)論
本文首先介紹了LTE系統(tǒng)中的密鑰層次，各種密鑰的作用，詳細(xì)介紹了加密和完整性保護(hù)原理，然后給出了基于LTE空中接口實(shí)現(xiàn)解密和完整性保護(hù)驗(yàn)證的設(shè)計(jì)方法，本文方法能用于LTE空中接口監(jiān)測(cè)類(lèi)設(shè)備的研發(fā)，并且能為基于空中接口的各種無(wú)線(xiàn)監(jiān)測(cè)類(lèi)設(shè)備的研發(fā)提供思路。
參考文獻(xiàn)
[1] 王映民，孫韶輝.TD-LTE技術(shù)原理與系統(tǒng)設(shè)計(jì)[M].北京：人民郵電出版社，2010.
[2] 3GPP TS 33.401 V14.6.0 3rd Generation PartnershipProject; Technical Specification Group Services and SystemAspects; 3GPP System Architecture Evolution (SAE); Securityarchitecture[S]. (2018-09).
[3] 王嘉嘉，楊傳偉.LTE鑒權(quán)機(jī)制及實(shí)現(xiàn)[J].電子產(chǎn)品世界，2015.22(11):27-28.
[4] 3GPP TS 36.331 V14.10.0 3rd Generation PartnershipProject; Technical Specification Group Radio Access Network;Evolved Universal Terrestrial Radio Access (E-UTRA); RadioResource Control (RRC) Protocol specification[S]. (2019-03).
[5] 3GPP TS 24.301 V14.10.0 3rd Generation PartnershipProject; Technical Specification Group Core Network andTerminals; Non-Access-Stratum (NAS) protocol for EvolvedPacket System (EPS); Stage 3[S].(2018-12).
[6] 3GPP TS 36.323 V14.5.0 3rd Generation Partnership Project;Technical Specification Group Radio AccessNetwork; Evolved Universal Terrestrial RadioAccess (E-UTRA); Packet Data ConvergenceProtocol (PDCP) specification [S].(2017-12).
本文來(lái)源于科技期刊《電子產(chǎn)品世界》2019年第12期第33頁(yè)，歡迎您寫(xiě)論文時(shí)引用，并注明出處。
評(píng)論