5G时代，与IMSI安全的梗概「建议收藏」

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全家桶1年46，售后保障稳定

作者：张婉桥

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攻击等。

讲到这，大家一定有疑问，这么重要的身份信息为何不能加密传输呢？因为在建立安全连接的过程中，一开始网络不知道手机是谁，要先知道它是谁，才开始交换密钥，换句话说，核心网在加密信息前要确定对方是自己人。

0x02 5G是如何解决IMSI-Catcher问题的呢？

5G决定引入公钥私钥的机制，公钥用来公开并加密，私钥用来保留并解密。将公钥存放在手机端，私钥存放在运营商手里，如此一来，只有运营商可以解密手机的真正的身份信息，攻击者只能拿到加密后的信息，没有私钥而无法解出IMSI。
此时，整个手机的鉴权流程是什么样的呢？
手机的真实身份在5G里称为SUPI（SUbscription Permanent Identifier）（类似IMSI），通过公钥加密后的密文称为SUCI（SUbscription Concealed Identifier），SUCI传送给基站后，基站直接上传至核心网[1]。
大概的流程如下图所示：

手机向基站gNB发起接入网络的请求，发送SUCI（即加密的SUPI）或是GUTI；（注：在4G和5G共存的时代，将存在两种无线接入与核心网，这里我们单讨论5G里通过NR-gNB作为接入核心网NGCN（NextGen Core）的方式）
基站gNB收到信息后，转发至核心网的SEAF（SEcurity Anchor Function）；
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）；
AUSF通过分析SEAF携带的网络信息SN-Name，确定手机是否在网络服务范围内，并保存手机需要的网络服务信息，接下来继续将SUCI或SUPI和服务网络信息SN-Name转发给UDM（Unified Data Management）；
在UDM中调用SIDF(Subscription identifier de-concealing function)将SUCI解密得到SUPI，然后通过SUPI来配置手机对应所需的鉴权算法。
接下来便会根据手机的鉴权方式一步步提取对应的鉴权秘钥与鉴权结果，直至最后将结果反馈给手机，手机端USIM会校验网络侧所发送鉴权结果的真伪。
小编总结的目前3GPP标准里已经确定的,与身份信息隐私保护相关的几个关键点：
手机端用来加密SUPI的公钥存放在UICC的USIM中；
SUCI的解密算法（SIDF）只会被执行一次，放置在核心网的UDM中；
当手机身份临时身份GUTI无法识别时，由AMF向手机发起Identity Request请求；若手机在注册Emergency Service时收到Identity Request可以发送Null-Scheme的SUCI，即不加密的SUPI；
由AMF负责配置发送手机的5G-GUTI；
SUCI的生成算法可以采用椭圆曲线集成加密方案（ECIES，elliptic curve integrate encrypt scheme）,运营商也可以根据自己需求单独采用个体方案，甚至可以采用Null-Scheme；
尚未确定的问题有：
GUTI更新的频率未做硬性标准规定。GUTI虽然是临时身份证，但如果长时间不变，也是可以在一段时间内用于追踪的。标准有要求GUTI要经常更新，并且有一些定时器设置，但什么时候更新是由网络决定的。
SUCI上报的频率未做硬性规定。手机在收到网络侧发送的Identity Request时，需要回复SUCI。手机要保证每次发送的SUCI都是新鲜的，随机的。但伪基站仍可以不断要求手机发送SUCI，会导致手机电力消耗或者发起一些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；低有效位对所有的有用信息，包含终端参数，进行一个完整性保护。所以最后终端发出的消息包括：终端生成的公钥、SUCI和终端参数等系列信息。

图1 终端侧SUCI的生成方案
下图2为网络侧对终端身份进行SUCI验证的方案。网络侧采用私钥（Private key of HN）与终端所发送的公钥（Eph.public key of UE）组合成秘钥Eph.shared key，随后派生出主密钥master key。不同于终端加密流程的是，网络侧会先通过秘钥的低有效位校验消息的完整性与否（步骤5），若消息经过中间人篡改，则该步骤的验证无法通过。若验证通过，才会进一步将信令转发至UDM中执行SIDF的过程，解密得到SUPI（Plain-text）。
该方案可以顺利通过验证并解密得到SUPI的关键也是利用椭圆加密算法的特性：终端私钥·网络公钥=网络私钥·终端公钥（注：密钥之间的乘法是椭圆曲线上的标量乘法，所以终端与网络侧均采用同一条曲线，即椭圆曲线的参数一致Curve25519 [2]或secp256r1 [3]）。

图2 网络侧对终端的验证方案
看完以上方案，大家可能有疑问：
1、网络侧的公钥为何要存放在USIM中，而不是通过网络下发更新？
2、网络侧公钥泄露会有影响吗？
问题1：答：为了防中间人攻击。设想网络侧的公钥也是放在网络中传播的，那么就可以有中间人先截获网络中所传送的公钥，替换后发送给终端。如此一来，终端发送过来的数据可以被中间人接收并解密，随后中间人对数据进行重新加密(在这个过程中还可以篡改数据)，将消息传回运营商网络中，完成鉴权过程。
问题2：答：不会。仅拿到公钥无法完成对信令的解密，更不会影响终端的正常鉴权过程。

0x04 使用IMSI进行paging的方法在5G网络中可能失效

前段时间在通信圈比较热门的一篇LTE曝光多个漏洞的论文赚足了眼球，可以参考我们之前发的博客：
对LTE INSPECTOR论文的一些解读
其中有一种攻击使用IMSI进行paging的攻击，在5G网络中可能会失效，小编在此与大家探讨一下。
作者采用目标受害者的IMSI来广播寻呼消息Paging，只有目标手机听到这个paging消息会返回一个Attach Request消息，并且携带相同的IMSI。这个思路扩展到5G中，就是之前捕捉到手机SUCI（无需解密）来Paging目标手机。如果手机的SUCI更新频率较低，则可能触发手机的Attach Request，通过捕捉该消息依旧有可能得知手机的位置。不过，3GPP SA3要求5G只采用GUTI做Paging来寻呼手机，如果最终相关的标准确定，就能保证在5G中这种攻击不会有效。
然而，如果决定只使用GUTI做paging的话，一旦手机与网络间的GUTI的同步关系丢失，基站就有可能寻呼不到目标手机，只有等待手机再次主动与网络同步。因此3GPP其他小组（非安全组）仍在讨论相关的方案。
不管怎么说，IMSI的加密传输实在是令人大快人心的决定，机智的小伙伴，你能在5G的SUPI/SUCI机制中发现什么纰漏吗？如果有，欢迎跟我们一起交流讨论，尽量在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.secg.org/sec2-v2.pdf
http://www.360doc31.net/wxarticlenew/767681374.html