作者：張婉橋

0x00 IMSI & IMSI-Catcher

我們以前擔心的手機泄漏個人位置隱私的問題，也就是在2G/3G/4G一直存在的IMSI Catcher問題，終于有望在5G標準里得到徹底解決啦！ 這個問題在每次制定新一代網絡標準的時候，都要爭論一回。這是網絡功能性、成本與安全性之間的斗爭。在5G的第一版標準，Release15，關于安全的標準[1]中，IMSI加密是最大的亮點。

在2/3/4G網絡中，攻擊者能通過十分廉價的設備獲取你的位置。這是由于手機每次需要聯(lián)網的時候都要大聲喊著，“我是誰誰誰”，攻擊者就可以通過手機報告的信息確定手機的大概位置了。專業(yè)一點的說，手機所廣播的那條“我是誰誰誰”就是手機的IMSI碼，全球唯一，就如同你的身份證號。設想，如果滿大街都在喊著每個人的身份證號，那么追蹤某一個人就變得容易了。

當然實際上，IMSI這么關鍵的信息不會在你發(fā)送的每條信息中都帶著。手機還會有一個臨時身份證（GUTI/TMSI），平時傳遞數據都是使用這個臨時身份證，手機只有在特殊的場景下會發(fā)送自己的IMSI。手機會在哪些場合會發(fā)送自己的IMSI呢？

0x01 什么情況下手機會發(fā)送IMSI？

情景一：手機接入正常的網絡時
手機開機后，先從USIM中讀取之前運營商分配的臨時身份信息GUTI/TMSI，發(fā)送攜帶該身份信息的信令給基站，請求接入運營商網絡?；臼盏皆撓⒑蟊戕D發(fā)給核心網的MME，若MME中可以查詢到對應的GUTI/TMSI對應的真實身份，則允許手機接入。若MME查詢不到，則需要重新對手機發(fā)起真實身份核驗的請求“Identity Request”，即要求手機提供真實身份IMSI。
通常觸發(fā)手機真實身份驗證的合理情況有：手機首次入網或手機移動到其它MME覆蓋范圍后，MME中無法從網絡中查詢到手機的GUTI/TMSI，故而需要手機上報自己的真實身份。
在這種情景下，攻擊者只需采取被動監(jiān)聽就可以捕捉到手機的IMSI。

情景二：手機接入到偽基站網絡時
偽基站通過高信號強度壓制真實基站把手機吸進來（手機會自動選擇信號強度最強的基站），之后強行給連接過來的手機發(fā)送身份驗證請求消息——“Identity Request”，手機就會乖乖的把自己真實身份報上來。
在該情境下，攻擊者采取的是主動攻擊，需要打開偽基站，不停的發(fā)送“Identity Request”就可以獲取周圍手機的真實身份。
這種獲取IMSI的工具，就稱為IMSI Catcher，其中比較出名的一款工具叫Stingray（黃貂魚），目前被一些執(zhí)法部門使用。Stingray是一款同時具有被動監(jiān)聽（監(jiān)聽+數據分析）和主動攻擊（偽造基站）的IMSI Catcher。通過獲取IMSI，TMSI，IMEI可以更好地獲取移動終端的數據信息。并且設備非常便攜，可以裝在飛機、汽車、無人機等交通工具適用以上兩種情景，并且該設備還可以測繪基站的分布情況，自行進行數據分析，追蹤目標手機位置，監(jiān)聽通信內容，進行DDoS攻擊等。

圖：Stingray（圖片來自網絡）

講到這，大家一定有疑問，這么重要的身份信息為何不能加密傳輸呢？因為在建立安全連接的過程中，一開始網絡不知道手機是誰，要先知道它是誰，才開始交換密鑰，換句話說，核心網在加密信息前要確定對方是自己人。

0x02 5G是如何解決IMSI-Catcher問題的呢？

5G決定引入公鑰私鑰的機制，公鑰用來公開并加密，私鑰用來保留并解密。將公鑰存放在手機端，私鑰存放在運營商手里，如此一來，只有運營商可以解密手機的真正的身份信息，攻擊者只能拿到加密后的信息，沒有私鑰而無法解出IMSI。

此時，整個手機的鑒權流程是什么樣的呢？
手機的真實身份在5G里稱為SUPI（SUbscription Permanent Identifier）（類似IMSI），通過公鑰加密后的密文稱為SUCI（SUbscription Concealed Identifier），SUCI傳送給基站后，基站直接上傳至核心網[1]。
大概的流程如下圖所示：

1. 手機向基站gNB發(fā)起接入網絡的請求，發(fā)送SUCI（即加密的SUPI）或是GUTI；（注：在4G和5G共存的時代，將存在兩種無線接入與核心網，這里我們單討論5G里通過NR-gNB作為接入核心網NGCN（NextGen Core）的方式）
2. 基站gNB收到信息后，轉發(fā)至核心網的SEAF（SEcurity Anchor Function）；
3. SEAF收到信令后解析后看是GUTI還是SUCI，若是GUTI就匹配到對應的SUPI，若為SUCI則不解密，繼續(xù)向AUSF（Authentication Server Function）發(fā)起鑒權申請Nausf_UEAuthentication_Authenticate Request，并攜帶對應的網絡服務信息SN-Name，方便AUSF調用對應鑒權算法AV（Authentication Vector，包含RAND, AUTN, HXRES*和 K_seaf）；
4. AUSF通過分析SEAF攜帶的網絡信息SN-Name，確定手機是否在網絡服務范圍內，并保存手機需要的網絡服務信息，接下來繼續(xù)將SUCI或SUPI和服務網絡信息SN-Name轉發(fā)給UDM（Unified Data Management）；
5. 在UDM中調用SIDF(Subscription identifier de-concealing function)將SUCI解密得到SUPI，然后通過SUPI來配置手機對應所需的鑒權算法。
6. 接下來便會根據手機的鑒權方式一步步提取對應的鑒權秘鑰與鑒權結果，直至最后將結果反饋給手機，手機端USIM會校驗網絡側所發(fā)送鑒權結果的真?zhèn)巍?/li>

小編總結的目前3GPP標準里已經確定的,與身份信息隱私保護相關的幾個關鍵點：

1. 手機端用來加密SUPI的公鑰存放在UICC的USIM中；
2. SUCI的解密算法（SIDF）只會被執(zhí)行一次，放置在核心網的UDM中；
3. 當手機身份臨時身份GUTI無法識別時，由AMF向手機發(fā)起Identity Request請求；若手機在注冊Emergency Service時收到Identity Request可以發(fā)送Null-Scheme的SUCI，即不加密的SUPI；
4. 由AMF負責配置發(fā)送手機的5G-GUTI；
5. SUCI的生成算法可以采用橢圓曲線集成加密方案（ECIES，elliptic curve integrate encrypt scheme）,運營商也可以根據自己需求單獨采用個體方案，甚至可以采用Null-Scheme；

尚未確定的問題有：

1. GUTI更新的頻率未做硬性標準規(guī)定。GUTI雖然是臨時身份證，但如果長時間不變，也是可以在一段時間內用于追蹤的。標準有要求GUTI要經常更新，并且有一些定時器設置，但什么時候更新是由網絡決定的。
2. SUCI上報的頻率未做硬性規(guī)定。手機在收到網絡側發(fā)送的Identity Request時，需要回復SUCI。手機要保證每次發(fā)送的SUCI都是新鮮的，隨機的。但偽基站仍可以不斷要求手機發(fā)送SUCI，會導致手機電力消耗或者發(fā)起一些DoS攻擊等等。

0x03 如何把SUPI加密為SUCI

下圖1所示中我們可以看到兩對秘鑰對，一對是終端側Eph.key pair generation，產生Eph. public key和Eph. private key。另外一對來自運營商網絡, 終端側有Public key of HN（固定存放在USIM中）。這兩對秘鑰均采用橢圓曲線加密算法ECC生成。私鑰可以衍生出唯一的公鑰，但是從公鑰不能反推出私鑰。

終端生成的私鑰與網絡提供的公鑰結合，派生出一對加密秘鑰Eph.shared key（用來加密的原始秘鑰），隨后派生出加密的主密鑰，取高有效位對SUPI進行對稱加密，得到SUCI，即Ciphertext；低有效位對所有的有用信息，包含終端參數，進行一個完整性保護。所以最后終端發(fā)出的消息包括：終端生成的公鑰、SUCI和終端參數等系列信息。

圖1 終端側SUCI的生成方案

下圖2為網絡側對終端身份進行SUCI驗證的方案。網絡側采用私鑰（Private key of HN）與終端所發(fā)送的公鑰（Eph.public key of UE）組合成秘鑰Eph.shared key，隨后派生出主密鑰master key。不同于終端加密流程的是，網絡側會先通過秘鑰的低有效位校驗消息的完整性與否（步驟5），若消息經過中間人篡改，則該步驟的驗證無法通過。若驗證通過，才會進一步將信令轉發(fā)至UDM中執(zhí)行SIDF的過程，解密得到SUPI（Plain-text）。
該方案可以順利通過驗證并解密得到SUPI的關鍵也是利用橢圓加密算法的特性：終端私鑰·網絡公鑰=網絡私鑰·終端公鑰（注：密鑰之間的乘法是橢圓曲線上的標量乘法，所以終端與網絡側均采用同一條曲線，即橢圓曲線的參數一致Curve25519 [2]或secp256r1 [3]）。

圖2 網絡側對終端的驗證方案

看完以上方案，大家可能有疑問：
1、網絡側的公鑰為何要存放在USIM中，而不是通過網絡下發(fā)更新？
2、網絡側公鑰泄露會有影響嗎？

問題1：答：為了防中間人攻擊。設想網絡側的公鑰也是放在網絡中傳播的，那么就可以有中間人先截獲網絡中所傳送的公鑰，替換后發(fā)送給終端。如此一來，終端發(fā)送過來的數據可以被中間人接收并解密，隨后中間人對數據進行重新加密(在這個過程中還可以篡改數據)，將消息傳回運營商網絡中，完成鑒權過程。

問題2：答：不會。僅拿到公鑰無法完成對信令的解密，更不會影響終端的正常鑒權過程。

0x04 使用IMSI進行paging的方法在5G網絡中可能失效

前段時間在通信圈比較熱門的一篇LTE曝光多個漏洞的論文賺足了眼球，可以參考我們之前發(fā)的博客：
對LTE INSPECTOR論文的一些解讀

其中有一種攻擊使用IMSI進行paging的攻擊，在5G網絡中可能會失效，小編在此與大家探討一下。

作者采用目標受害者的IMSI來廣播尋呼消息Paging，只有目標手機聽到這個paging消息會返回一個Attach Request消息，并且攜帶相同的IMSI。這個思路擴展到5G中，就是之前捕捉到手機SUCI（無需解密）來Paging目標手機。如果手機的SUCI更新頻率較低，則可能觸發(fā)手機的Attach Request，通過捕捉該消息依舊有可能得知手機的位置。不過，3GPP SA3要求5G只采用GUTI做Paging來尋呼手機，如果最終相關的標準確定，就能保證在5G中這種攻擊不會有效。

然而，如果決定只使用GUTI做paging的話，一旦手機與網絡間的GUTI的同步關系丟失，基站就有可能尋呼不到目標手機，只有等待手機再次主動與網絡同步。因此3GPP其他小組（非安全組）仍在討論相關的方案。

不管怎么說，IMSI的加密傳輸實在是令人大快人心的決定，機智的小伙伴，你能在5G的SUPI/SUCI機制中發(fā)現(xiàn)什么紕漏嗎？如果有，歡迎跟我們一起交流討論，盡量在5G網絡商用之前及時補救，讓下一代的移動通信更有力的保護我們每個人的隱私。

[1] 3GPP TS 33.501 Security architecture and procedures for 5G system(Release 15)
[2] IETF RFC 7748: “Elliptic Curves for Security”.
[3] SECG SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0, 2010. Available at http://www./sec2-v2.pdf