深度解析 3GPP TS 33.501：5.2 UE安全需求 (你手中的5G手机，一个沉默的安全哨兵)
本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“5.2 Requirements on the UE”的核心章节，旨在为读者深度剖析作为5G安全体系起点的终端设备（UE）必须具备的各项核心安全能力。
在上一篇文章中，我们共同学习了5G安全的“基本原则”——通用安全需求。这些原则如同宪法，为整个系统定下了基调。今天，我们将把目光从宏观的系统聚焦到我们每个人手中最熟悉的设备——5G手机（UE，User Equipment）上。
规范的5.2节，正是专门为UE量身定制的“安全能力说明书”。它详细规定了，一部合格的5G手机，在安全方面必须做到什么、支持什么、以及如何保护最核心的秘密。它告诉我们，手机并非一个被动的通信工具，而是一个主动参与并捍卫通信安全的前线哨兵。
我们的主角“安安”正坐在咖啡馆里，她的5G手机静静地放在桌上。这台设备看似沉睡，实则内部的安全模块时刻待命，准备应对各种潜在的威胁。现在，就让我们以安安的手机为例，深入探索它体内蕴含的强大安全基因。
1. 5.2.1 通用需求 (General) - 兼顾传统与未来的“多面手”
5G时代的一个重要特征是与4G网络的长期共存与互通。安安的手机可能连接的是一个新建的5G基站（gNB），也可能连接到一个经过升级、接入5G核心网的4G基站（ng-eNB）。这对手机的安全能力提出了兼容性的要求。
- The UE shall support the use of integrity protection with the ng-eNB over the Uu interface if it supports E-UTRA connected to 5GC.
- The UE shall indicate its support of integrity protection with the ng-eNB if it supports E-UTRA connected to 5GC.
这两条需求看似简单，实则明确了UE在混合组网场景下的安全责任。
- 支持与表明：如果安安的手机支持连接到“接入5G核心网的4G基站”（即E-UTRA connected to 5GC），那么它必须支持在这种连接下进行完整性保护，并且必须在与网络通信时，明确告知网络“我具备这个能力”。
这确保了即使在4G的无线环境下，只要核心网是5G的，UE依然能够利用5G的安全机制来保护信令的完整性，防止被篡改。
The PEI shall be securely stored in the UE to ensure the integrity of the PEI.
- PEI的安全存储：PEI（Permanent Equipment Identifier），通常指的就是我们熟知的手机IMEI号。它如同手机的“身份证号”，是设备的唯一标识。规范要求，这个“身份证号”必须被安全地存储在手机内部，确保其完整性，不能被轻易篡改。这对于设备追踪、失窃寻回以及防止设备伪造等都至关重要。
场景代入：安安的手机就像一辆“水陆两栖战车”，既能在5G的“高速公路”（gNB）上驰骋，也能在4G的“国道”（ng-eNB）上安全行驶，无论在哪条路上，它都能保证其通信的“封条”（完整性保护）完好无损。同时，它的“车架号”（PEI/IMEI）被牢牢地刻在核心部件上，无法被磨掉或修改。
2. 5.2.2 用户与信令数据机密性 (User data and signalling data confidentiality) - 通信的“加密保险箱”
机密性，通俗地讲就是加密，确保通信内容不被窃听者知晓。5.2.2节详细规定了UE在加密方面必须具备的能力。
The UE shall support ciphering of user data between the UE and the gNB. The UE shall activate ciphering of user data based on the indication sent by the gNB. The UE shall support ciphering of RRC and NAS-signalling.
这段话明确了UE加密能力的三个层面：
- 支持用户数据加密：安安用手机观看高清视频时，视频流就是用户数据（User Plane data）。她的手机必须具备加密这些视频流的能力。
- 按需激活：是否对视频流进行加密，并非由手机单方面决定，而是要听从基站（gNB）的指令。网络会根据业务类型、安全策略等因素，通过信令告知手机是否需要启动加密。
- 支持信令加密：除了用户数据，更重要的是控制信令的加密。RRC信令（无线资源控制）是手机和基站之间的“对话”，用于管理无线连接；NAS信令（非接入层）是手机和核心网AMF之间的“对话”，用于注册、认证等核心流程。这些“管理指令”的机密性至关重要，必须支持加密。
The UE shall implement the following ciphering algorithms: NEA0, 128-NEA1, 128-NEA2 as defined in Annex D of the present document. The UE may implement the following ciphering algorithm: 128-NEA3 as defined in Annex D of the present document.
规范没有止步于“要求加密”，而是进一步标准化了“用什么加密”。
- 强制实现的算法：UE必须实现
NEA0（空加密）、128-NEA1（基于SNOW 3G）和128-NEA2（基于AES-128）。这确保了无论网络选择哪种主流算法，手机都能支持，保障了全球的互联互通。128-NEA2是目前最常用、最受信任的算法。 - 可选实现的算法：UE可以选择性地实现
128-NEA3（基于ZUC）。ZUC是我国自主设计的加密算法，同样具有高强度。规范将其列为可选，体现了标准在吸纳新技术方面的开放性。
Confidentiality protection of the user data between the UE and the gNB is optional to use. Confidentiality protection of the RRC-signalling, and NAS-signalling is optional to use. Confidentiality protection should be used whenever regulations permit.
- 支持 vs 使用：这里有一个非常关键的区别。“Support”（支持）是强制的，意味着手机必须具备这个能力。而“Use”（使用）是可选的，意味着在实际通信中，网络可以根据策略决定是否开启加密。尽管对于信令来说，加密几乎总是开启的，但规范的这种表述保留了灵活性，以应对某些特殊情况（如紧急呼叫）。最后的“should be used”则是一个强烈的建议，即在法规允许的情况下，应当尽可能地使用加密。
3. 5.2.3 用户与信令数据完整性 (User data and signalling data integrity) - 通信的“防伪封条”
完整性保护，如同在加密的保险箱上再贴一个一次性的防伪封条。它无法防止别人看（那是加密的活），但能确保内容在传输过程中没有被篡改，并且确保消息是来自合法的发送方。
The UE shall support integrity protection and replay protection of user data between the UE and the gNB. … The UE shall support integrity protection and replay protection of RRC and NAS-signalling. Integrity protection of the RRC-signalling, and NAS-signalling is mandatory to use, except in the following cases: … All RRC signalling messages … shall be integrity-protected with an integrity protection algorithm different from NIA0, except for unauthenticated emergency calls.
与机密性类似，UE也必须支持对用户数据和信令的完整性保护。但这里有一个至关重要的区别：
- 信令的完整性保护是强制使用的（Mandatory to use）！
场景代入：网络给安安的手机发送了一条指令：“切换到B基站”。如果这条指令没有完整性保护，攻击者“小黑”就可以将其篡改- “切换到一个由我控制的C基站”。手机一旦执行，就会落入陷阱。因此，对于控制指令，防篡改的需求甚至高于防窃听。规范要求除了极少数例外（如初始接入的几条消息和紧急呼叫），所有RRC和NAS信令都必须进行完整性保护，且不能使用NIA0（空算法）。这就像一份机密文件，可以不加密，但必须有签名盖章，以辨真伪。
Integrity protection of the user data between the UE and the gNB is optional to use.
- 用户数据的完整性保护是可选使用的（Optional to use）。原因在于性能与安全的权衡。对每一个数据包都进行完整性计算会增加额外的处理开销和数据包头开销，对于视频、游戏等大流量、低时延业务可能会有影响。因此，网络可以根据业务需求，决定是否开启用户平面数据的完整性保护。
与加密算法类似，规范也定义了一套强制和可选的完整性算法，如128-NIA1 (SNOW 3G), 128-NIA2 (AES-CMAC), 和可选的 128-NIA3 (ZUC)。
4. 5.2.4 订阅凭证的安全存储与处理 (Secure storage and processing of subscription credentials) - UE的“数字保险库”
这是5.2节中最为核心、安全等级最高的部分。它定义了UE如何保护其最根本的秘密——用户的长期密钥K。
The subscription credential(s) shall be integrity protected within the UE using a tamper resistant secure hardware component. The long-term key(s) of the subscription credential(s) (i.e. K) shall be confidentiality protected within the UE using a tamper resistant secure hardware component. The long-term key(s) of the subscription credential(s) shall never be available in the clear outside of the tamper resistant secure hardware component. The authentication algorithm(s) that make use of the subscription credentials shall always be executed within the tamper resistant secure hardware component.
这段话为UE的安全凭证处理立下了“四条铁律”：
- 安全容器：凭证必须存储在防篡改的安全硬件中。这个硬件就是我们手机里的USIM卡、eSIM芯片或集成在SoC里的iSIM/iUICC。它们经过特殊设计，具有物理层面的防攻击能力。
- 机密存储：长期密钥K本身在这个安全硬件中必须是加密存储的，提供双重保护。
- 密钥不出库：最关键的一条——长期密钥K永远不能以明文形式离开这个安全硬件。它就像是银行金库里的核心模具，绝不允许拿出金库。
- 内部运算：所有需要使用密钥K的运算（例如，在AKA流程中计算响应RES），都必须在这个安全硬件内部完成。外部（如手机的通用CPU）只能将计算所需的“原材料”（如网络发来的随机数RAND）送进去，然后从里面取走计算结果，但永远无法触及密钥K本身。
场景代入：安安的USIM卡就是一个微型的“数字保险库”。里面存放着她最核心的秘密——密钥K的蓝图。当需要验证身份时，网络发来一个“谜题”（RAND），手机的通用处理器（ME）把这个谜题递给保险库。保险库内部的“密码专家”拿出蓝图，解答谜题，然后把“答案”（RES）递出来。整个过程中，蓝图从未离开过保险库，也无人能窥视。这确保了即使手机的操作系统被病毒攻破，也无法窃取到最根本的用户密钥。
5. 5.2.5 用户隐私 (Subscriber privacy) - 隐藏在人群中的能力
在确保了通信内容和凭证的安全后，规范进一步要求保护用户的身份隐私，即“你是谁”这个信息本身。
The UE shall support 5G-GUTI. The SUPI should not be transferred in clear text over NG-RAN except routing information, e.g. Mobile Country Code (MCC) and Mobile Network Code (MNC). The Home Network Public Key shall be stored in the USIM. The protection scheme identifier shall be stored in the USIM. The SUCI calculation indication, either USIM or ME calculating the SUCI, shall be stored in USIM.
这部分规定了UE为实现SUPI隐私保护（即SUCI机制）必须具备的能力：
- 支持临时身份：UE必须支持5G-GUTI。一旦完成初次注册，UE在后续的通信中就会使用网络分配的这个临时身份，避免频繁暴露永久身份。
- 支持SUCI生成：为了在初次注册时隐藏SUPI，UE必须具备生成SUCI的能力。这需要USIM卡中预先配置好几样关键“工具”：
- 归属网络公钥 (Home Network Public Key)：用于加密SUPI的核心工具。
- 保护方案标识符 (Protection scheme identifier)：告知网络使用的是哪种加密方案（如Profile A或Profile B）。
- SUCI计算指示：一个开关，由运营商决定加密SUPI的计算是在USIM卡内部完成，还是在手机的通用处理器（ME）上完成。
场景代入：安安的USIM卡不仅是个保险库，还是个“密码信封制作机”。当需要发送包含她真实身份（SUPI）的信件时，手机会根据卡上的指示，使用卡里存放的特殊“加密邮票”（公钥），将身份信息加密成一串无人能懂的“密文地址”（SUCI），然后才发送出去。只有拥有唯一“解密钥匙”（私钥）的运营商总部（UDM/SIDF）才能读懂。
6. 总结
本章深入剖析了5.2节，明确了作为5G安全体系中至关重要一环的UE，必须扮演好一个多重角色：
- 一个多能的通信者：必须支持多套加密和完整性算法，并能根据网络指令精确执行，同时兼顾4G/5G互通场景。
- 一个坚不可摧的保险库：必须通过防篡改硬件来保护用户的核心密钥，并遵循“密钥不出库、运算在内部”的铁律。
- 一个谨慎的隐私保护者：必须通过SUCI和GUTI机制，最大限度地减少用户永久身份在空口的暴露，保护用户免受追踪。
这些对UE的严格要求，从源头上保证了5G安全体系的强度和可靠性。一个安全的网络，始于一个安全的终端。
在下一篇文章中，我们将视角转换到网络的另一端——基站（gNB），解读规范的5.3节，看看这个矗立在我们身边的通信塔，又被赋予了哪些重要的安全职责。
FAQ
Q1：机密性（Confidentiality）和完整性（Integrity）有什么本质区别？为什么对信令来说，完整性更重要？ A1：机密性是通过加密来防止内容被窃听，解决的是“不让别人看”的问题。完整性是通过附加校验码（MAC）来防止内容被篡改，解决的是“防止假冒和修改”的问题。对于信令（控制指令）而言，指令被篡改的危害通常远大于被窃听。例如，一条“降低功率”的指令被窃听，问题不大；但如果被篡改成“关机”或“切换到恶意基站”，就会导致业务中断或被劫持。因此，保证指令的真实性和未被篡改，是保障网络正常运行的生命线，所以信令的完整性保护是强制使用的。
Q2：既然手机要支持那么多套加解密算法，实际通信时到底用哪一套呢？ A2：最终使用哪一套算法是由网络侧（AMF和gNB）根据双方能力的交集和网络自身的安全策略来决定的。流程是这样的：1) UE在注册时，会向网络上报自己支持的所有算法列表（UE Security Capabilities）。2) AMF和gNB各自也有一份配置好的、按优先级排序的算法列表。3) AMF/gNB会从UE上报的列表中，选择自己支持且优先级最高的算法。4) 最后，AMF/gNB通过加密和完整性保护的“安全模式命令”（SMC）消息，将最终选定的算法通知给UE。
Q3：什么是“防篡改的安全硬件”？我的手机里有这个东西吗？ A3：有。这个“防篡改的安全硬件”通常指的就是您手机里的SIM卡（实体卡或eSIM芯片），或者更先进的iSIM/iUICC（集成在主芯片内的安全单元）。这些硬件在设计和制造上就具备了物理安全特性，能抵抗各种物理攻击（如探针、能量分析等）手段来窃取内部数据。它们内部有自己独立的CPU和存储，形成一个与手机主操作系统隔离的“安全孤岛”，专门用于存储密钥和执行敏感的密码学运算。
Q4：我的手机是怎么知道运营商的公钥，从而能生成SUCI的？ A4：运营商的公钥是在USIM卡出厂或用户入网时，由运营商**预先配置（provisioning）**进去的。这张公钥以及对应的私钥由运营商在其核心网（UDM）中安全保管。这个预置的过程保证了UE拥有的是一个真实、合法的公钥，从而保证了SUCI加密体系的信任根基。
Q5：PEI（IMEI）和SUPI（IMSI）都是身份标识，为什么需要分开保护？ A5：因为它们标识的对象不同，代表的含义也不同。SUPI标识的是“订阅用户”，与您的手机号、套餐等绑定，是“人”的身份，可以更换手机但号码不变。PEI标识的是“物理设备”，是手机本身的唯一序列号，是“物”的身份。分开保护至关重要：保护SUPI是为了防止您的通信行为和位置被追踪，保护的是个人隐私。保护PEI是为了防止设备被克隆、伪造，用于追踪被盗设备，或者在某些物联网场景中对设备本身进行认证和管理。二者共同构成了完整的身份安全体系。