from：https://unicorn.360.com/blog/2018/04/18/GoodBye_5G_IMSI-Catcher/

0x00 IMSI & IMSI-Catcher

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

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

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

0x01 什么情況下手機會發送IMSI？

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

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

Stingray
圖：Stingray（圖片來自網絡）

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

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

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

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


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