好的，遵照您的指令，我们继续踏上3GPP TS 33.401的深度探索之旅。在上一篇对规范的整体鸟瞰之后，我们将正式开始逐章逐节的精读。
本文将从规范的第五章 安全特性开始，首先聚焦于5.1节 用户-网络安全。这是整个安全体系中与用户体验最息息相关、也是攻防对抗最激烈的前沿阵地。
深度解析 3GPP TS 33.401：5.1 User-to-Network security (用户-网络安全)
本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中，关于“5.1 User-to-Network security”的核心章节，旨在为读者提供一个从用户身份保密到空口通信加固的全方位解析。
在上一篇的宏观架构概述中，我们了解了EPS安全大厦的五大支柱。现在，我们将走进这座大厦的第一层，也是最重要的一层——“用户-网络安全”。这一层直接关系到我们每个人的通信隐私和数据安全。
为了生动地理解这些机制，我们将继续跟随主角“小明”。清晨，小明的闹钟响起，他拿起手机，解锁屏幕，准备开始新的一天。从他的手指触碰到屏幕的那一刻起，一场由TS 33.401定义的、复杂而精密的“用户-网络安全”大戏便已拉开帷幕。
1. 总体原则与适用范围 (5.1.0 General)
规范在5.1节的开头，首先用简短的篇幅明确了本节内容的一个重要适用范围扩展。
The statements relating to eNBs in clause 5.1 apply also to RNs regarding the security between a UE and a relay node.
The statements relating to UEs in clause 5.1 apply also to RNs regarding the security between a relay node and a Donor eNB and between a relay node and its MME unless stated otherwise.
这段话的核心思想是一致性原则。它告诉我们，本章讨论的所有适用于普通基站（eNB）和用户终端（UE）之间的安全规则，同样适用于一个更特殊的网络元素——中继节点（Relay Node, RN）。
什么是中继节点（RN）？
你可以把它想象成一个官方的“信号放大器”或“信号中继站”。当某个区域（如大型商场深处或偏远山区）4G信号覆盖不佳时，运营商可以部署一个RN。这个RN通过无线方式连接到一个信号强劲的“施主基站”（Donor eNB），然后再为周边的用户提供无线覆盖。
从安全角度看，RN扮演着双重角色：
-
对于小明这样的普通用户（UE）来说，RN看起来就是一个普通的基站。因此，小明的手机与RN之间的通信，必须应用与手机和eNB之间完全相同的安全机制。
-
对于施主基站（DeNB）来说，RN又像一个特殊的用户终端。因此，RN与DeNB（及其背后的核心网MME）之间的无线回传链路，也必须遵循UE与网络之间的安全规则。
这个通用性原则为后续的讨论奠定了基础：无论网络拓扑如何变化，用户到其直接无线接入点之间的安全保障级别是统一的。
2. 你的身份，我来守护：用户身份与设备机密性 (5.1.1 User identity and device confidentiality)
小明解锁手机后，屏幕顶部的信号栏显示已连接到网络。这个连接的建立过程，首先要解决一个核心的隐私问题：如何隐藏小明的真实身份？
在移动通信网络中，每个用户都有一个全球唯一的永久身份标识——IMSI (International Mobile Subscriber Identity)。如果手机在每次连接时都在空中广播自己的IMSI，那就好比小明走到哪里都举着一个写着自己身份证号的牌子，任何人都可以轻易地追踪他的位置和行踪。这在隐私至上的今天，是绝对无法接受的。
因此，5.1.1节的核心使命就是保护用户身份的机密性。
From subscriber’s privacy point of view, the MSIN, the IMEI, and the IMEISV should be confidentiality protected.
这里提到了三个需要被保护的关键标识：
-
MSIN (Mobile Subscriber Identification Number): 这是IMSI中除国家码（MCC）和网络码（MNC）之外的部分，直接关联到具体用户。保护了MSIN，就保护了IMSI。
-
IMEI (International Mobile Station Equipment Identity): 手机的唯一设备序列号，相当于手机的“身份证号”。
-
IMEISV (IMEI and Software Version Number): 包含了IMEI和手机的软件版本号。
为了保护这些身份标识，网络并不会频繁使用它们，而是采用临时身份标识的策略。在第一次成功入网（AKA认证）后，核心网的MME会分配给手机一个临时的、在网络内部唯一的身份标识——GUTI (Globally Unique Temporary Identity)。在后续的位置更新、发起业务等绝大多数场景下，小明的手机都将使用GUTI来向网络表明身份。由于GUTI是会周期性更新的，攻击者即使监听到一次GUTI，也无法将其与小明的真实身份长期绑定，从而实现了隐私保护。
设备身份（IMEI）的特殊处理
除了用户身份，设备身份IMEI同样敏感。规范对IMEI的请求和上报流程做了严格规定。
The UE shall provide its equipment identifier IMEI or IMEISV to the network, if the network asks for it in an integrity-protected request.
The UE shall not send IMEI or IMEISV to the network on a network request before the NAS security has been activated.
这两句话蕴含了深刻的安全考量：
-
“先建信任，再问身份”：网络必须在一个已经建立了安全上下文（即NAS安全已激活）的环境下，才能向手机索要IMEI。这意味着，一个随机的、未经认证的网络（如伪基站）发起的IMEI查询请求，手机是必须拒绝的。
-
“请求本身需防伪”：即使NAS安全已激活，网络发来的IMEI索要请求（
Identity Request消息）也必须是经过完整性保护的。这可以防止在合法的网络中，攻击者通过中间人攻击篡改信令，插入一个非法的IMEI索要请求。
场景串联： 小明的手机在开机完成AKA认证后，MME就给他分配了一个GUTI。此后，当地铁穿过不同区域，手机需要进行位置更新（TAU）时，它向网络发送的消息中包含的就是这个GUTI，而不是他的IMSI。网络通过GUTI就能找到他的上下文信息。某天，运营商需要进行网络设备核查，MME决定查询小明手机的IMEI。此时，MME会构建一条Identity Request信令，用KNASint密钥为其生成完整性保护“签名”，然后发送给小明的手机。手机收到后，首先用自己保存的KNASint密钥验证“签名”的真伪，确认指令确实来自合法的MME，然后才会将自己的IMEI上报。
无法回避的“第一次”：规范中的例外与注解
理论是完美的，但现实总有例外。规范的NOTE对一些特殊场景进行了解释。
NOTE 1: When the UE has no IMSI, no valid GUTI, or no valid P-TMSI during emergency attach, the IMEI is included before the NAS security has been activated.
解读：这是“生命高于一切”原则的体现。当小明在没有SIM卡的情况下拨打紧急电话（如112、911）时，手机没有任何合法的用户身份（IMSI、GUTI）。为了让网络能够识别并回拨这个设备，规范允许此时手机在安全激活前就上报自己的IMEI。
NOTE 2: In some cases, e.g., the very first attach procedure, MSIN has to be sent to network in cleartext. When NAS confidentiality protection is beyond an operator option, IMEI and IMEISV can not be confidentiality protected.
解读：这是一个经典的“鸡生蛋还是蛋生鸡”的问题。为了用GUTI来保护IMSI，前提是网络得先认识你，给你分配一个GUTI。那么在小明第一次使用这张SIM卡开机，手机和网络都还没有任何关于对方的临时身份信息时，手机别无选择，只能将完整的IMSI以明文形式发送给网络，以启动AKA认证流程。这就像小明第一次去一个需要门禁卡的办公楼，他必须先在前台出示身份证（IMSI），保安核实后给他办一张临时门卡（GUTI），之后他在这栋楼里就可以一直刷这张临时门卡了。
3. 信任的基石：实体认证 (5.1.2 Entity authentication)
本节内容极其简洁，它直接指向了3G安全架构规范。
Entity authentication is as defined by TS 33.102 clause 5.1.2
解读：这是一个引用性条款，它重申了4G EPS的实体认证机制继承自3G UMTS的**AKA（Authentication and Key Agreement）**机制，并在此基础上进行了增强。这意味着，我们在纲要篇和前文场景中描述的双向认证流程，是用户-网络安全后续所有环节（加密、完整性保护）得以建立的绝对前提。没有成功的实体认证，就没有后续的一切安全保障。
4. 听我说，谢谢你：信令与数据机密性 (5.1.3 User data and signalling data confidentiality)
认证完成，密钥就位，接下来就要为小明的通信数据拉上“保密窗帘”。这就是机密性保护，也就是我们常说的加密（Ciphering）。
4.1 加密的需求与范围 (5.1.3.1 Ciphering requirements)
加密并非一个笼统的概念，规范明确了哪些信息流可以或应该被加密。
Ciphering may be provided to RRC-signalling to prevent UE tracking based on cell level measurement reports, handover message mapping, or cell level identity chaining. RRC signalling confidentiality is an operator option.
All S1 and X2 messages carried between RN and DeNB shall be confidentiality-protected.
The NAS signalling may be confidentiality protected. NAS signalling confidentiality is an operator option.
解读：
-
RRC信令加密：这是运营商的可选项。为什么要加密RRC信令？因为RRC信令中包含了手机上报的周边小区信号强度等测量报告。攻击者如果能持续解密这些报告，就能非常精确地推算出手机的移动轨迹，实现对小明的跟踪。加密RRC信令可以有效防止这类基于信令分析的物理位置追踪。
-
RN链路加密：对于中继节点（RN）的无线回传链路，规范要求必须进行加密保护。这是因为该链路承载了大量用户的汇聚数据，其安全价值和风险远高于单个UE。
-
NAS信令加密：这也是运营商的可选项。加密NAS信令可以保护小明的移动性状态、会话信息等核心网层面的隐私。
规范的附注给出了重要的建议和说明：
NOTE 1: RRC and NAS signalling confidentiality protection is recommended to be used.
解读：虽然是“可选项”，但3GPP强烈推荐运营商开启RRC和NAS信令的加密功能，以提供更强的隐私保护。
User plane confidentiality protection over the access stratum shall be done at PDCP layer and is an operator option.
NOTE 2: User plane confidentiality protection is recommended to be used.
解读：对于小明观看视频、浏览网页所产生的用户数据（User Plane），在空口进行加密同样是运营商的可选项，但同样也是被强烈推荐的。加密发生在PDCP（Packet Data Convergence Protocol）层。在今天的全球商用网络中，空口用户数据加密基本上已成为标准配置。
4.2 加密算法的“菜单” (5.1.3.2 Algorithm Identifier Values)
网络和手机需要“对上暗号”，才能使用相同的加密算法。这个“暗号”就是算法标识符。规范为EPS加密算法（EEA, EPS Encryption Algorithm）定义了一套编码。
Each EPS Encryption Algorithm (EEA) will be assigned a 4-bit identifier. Currently, the following values have been defined for NAS, RRC and UP ciphering:
| 算法标识符 (二进制) | 算法名称 | 核心技术 |
| :---------------------- | :------------ | :--------------------------- |
| “0000” | EEA0 | Null ciphering algorithm |
| “0001” | 128-EEA1 | SNOW 3G based algorithm |
| “0010” | 128-EEA2 | AES based algorithm |
| “0011” | 128-EEA3 | ZUC based algorithm |
算法解析：
-
EEA0 (空加密)：这并非一种加密算法，而是“不加密”的明确指示。它主要用于紧急呼叫等特殊场景，或在某些（理论上存在的）运营商策略下不开启加密。
-
128-EEA1 (SNOW 3G)：一种源自3G时代并为LTE优化的流密码算法。SNOW 3G以其在软件和硬件上高效的实现而著称。
-
128-EEA2 (AES)：基于大名鼎鼎的高级加密标准（AES）。它工作在CTR（计数器）模式下，是目前业界应用最广泛、公认安全强度非常高的对称加密算法。
-
128-EEA3 (ZUC)：祖冲之算法，由中国自主设计的流密码算法，以中国古代数学家祖冲之命名。它也是3GPP标准中的三大加密算法之一，具有优秀的性能和安全性。
规范接着定义了手机和网络设备对这些算法的支持义务：
UEs and eNBs shall implement EEA0, 128-EEA1 and 128-EEA2 for both RRC signalling ciphering and UP ciphering. UEs and eNBs may implement 128-EEA3…
UEs and MMEs shall implement EEA0, 128-EEA1 and 128-EEA2 for NAS signalling ciphering. UEs and MMEs may implement 128-EEA3…
解读：
-
shall表示强制要求。所有4G手机和基站、核心网MME都必须支持EEA0, EEA1, EEA2。这保证了无论小明使用什么品牌的手机，漫游到哪个支持4G的运营商网络，基本的加密互通性都能得到保障。 -
may表示可选支持。对ZUC算法的支持是可选的，这为不同地区和厂商提供了灵活性。
5. 防止“指鹿为马”：信令与数据完整性 (5.1.4 User data and signalling data integrity)
如果说机密性是为小明的数据拉上了“窗帘”，那么完整性保护就是给他的数据贴上了“防伪封条”。它要解决的问题是：如何确保小明收到的指令就是网络发出的原始指令，没有在半路被攻击者篡改？
5.1 完整性保护的需求与范围 (5.1.4.1 Integrity requirements)
Integrity protection, and replay protection, shall be provided to NAS and RRC-signalling.
解读：规范在这里使用了最强硬的措辞shall。对于NAS和RRC这两种关乎网络控制和无线资源管理的信令，必须提供完整性保护和抗重放攻击保护。
-
完整性保护 (Integrity Protection)：通过一个密钥（如
KNASint,KRRCint）和一个完整性算法（如EIA1），为每一条信令计算出一个简短的“消息认证码”（MAC-I）。接收方会用同样的密钥和算法独立计算一遍，并与收到的MAC-I比对。任何对信令内容的哪怕一个比特的改动，都会导致计算出的MAC-I完全不同，从而让篡改行为暴露无遗。 -
抗重放保护 (Replay Protection)：通过在计算MAC-I时引入一个递增的序列号（
COUNT），可以防止攻击者将之前合法截获的信令重新发送给手机或网络。例如，攻击者不能把小明几分钟前收到的“断开连接”指令在现在重放给他，因为COUNT值已经对不上了。
场景串联： 假设小明的手机正在从A基站向B基站切换，A基站给他发送了一条包含B基站频率和ID的RRC切换指令。一个攻击者在空中截获了这条指令，并将其中的B基站ID篡改为一个由他控制的恶意基站C的ID。如果没有完整性保护，小明的手机就会毫不知情地连接到恶意基站。但是，在TS 33.401的保护下，原始的切换指令附加了一个由KRRCint计算出的MAC-I。攻击者篡改了指令内容，但他没有KRRCint密钥，无法生成一个新的、与之匹配的MAC-I。小明的手机收到被篡改的指令后，会发现自己计算出的MAC-I与指令附带的MAC-I完全不同，于是它会立即判定该指令无效并丢弃，从而避免了一次危险的连接。
对于用户数据的完整性保护，规范则给出了更灵活的规定：
User plane packets between the eNB and the UE may be integrity protected on the Uu interface.
解读：在空口（Uu接口），是否对用户数据（如视频流）进行完整性保护是可选的。这主要是出于性能和开销的考虑。对海量的用户数据包逐一计算和验证MAC会消耗大量的计算资源和无线带宽。通常认为，对用户数据的篡改所造成的危害（如视频画面出现花屏）远小于对信令篡改的危害（如网络掉线、连接被劫持），因此规范在此做了权衡。
5.2 完整性算法的“菜单” (5.1.4.2 Algorithm Identifier Values)
与加密算法类似，EPS完整性算法（EIA, EPS Integrity Algorithm）也有一套4比特的标识符。
| 算法标识符 (二进制) | 算法名称 | 核心技术 |
| :---------------------- | :------------ | :---------------------------- |
| “0000” | EIA0 | Null Integrity Protection algorithm |
| “0001” | 128-EIA1 | SNOW 3G based algorithm |
| “0010” | 128-EIA2 | AES based algorithm |
| “0011” | 128-EIA3 | ZUC based algorithm |
算法解析：
-
EIA0 (空完整性)：不提供完整性保护。同样用于经过认证失败后的紧急呼叫等极特殊场景。
EIA0 shall only be used for unauthenticated emergency calls. -
128-EIA1 (SNOW 3G)：基于SNOW 3G的完整性保护算法。
-
128-EIA2 (AES)：基于AES的完整性保护算法，工作在CMAC模式下。
-
128-EIA3 (ZUC)：基于祖冲之算法的完整性保护算法。
支持义务同样是强制+可选的组合：
UEs and eNBs shall implement 128-EIA1 and 128-EIA2 for RRC signalling integrity protection. UEs and eNBs may implement 128-EIA3…
UEs and MMEs shall implement 128-EIA1 and 128-EIA2 for NAS signalling integrity protection. UEs and MMEs may implement 128-EIA3…
UEs shall implement EIA0 for integrity protection of NAS and RRC signalling.
解读：与加密算法类似，SNOW 3G和AES的完整性算法是所有设备必须支持的，保证了互通性。ZUC算法是可选的。值得注意的是，规范还强制要求UE必须支持EIA0，这是为了确保在需要建立非认证紧急呼叫时，UE能够正确处理网络下发的“不保护”指令。
6. 总结
5.1节“用户-网络安全”为我们描绘了一幅详尽的空口及用户-核心网信令链路的安全防护图景。它从身份隐私、实体认证、数据机密性、数据完整性四个维度，构建了一套完整的、层层递进的防御机制。
-
身份机密性是预防，通过使用GUTI等临时标识，从源头上减少了用户的隐私暴露风险。
-
实体认证是基石，通过AKA机制建立起UE与网络之间的相互信任，并安全地协商出会话密钥的“始祖”。
-
机密性保护是“隐身衣”，通过EEA系列算法，确保空中的电波即使被捕获也无法被解读。
-
完整性保护是“验真章”，通过EIA系列算法，确保传输的指令不会被篡- 喂，不会被篡改，保证了网络控制的权威性和准确性。
这些机制的协同工作，共同确保了小明——以及全球亿万4G用户——在享受高速移动网络的同时，其通信自由和隐私安全得到了坚实的保障。
在下一篇文章中，我们将继续深入第五章，探讨5.2节“安全的可视性与可配置性”和5.3节“对eNodeB的安全要求”，看看规范是如何赋予用户知情权，以及对网络基础设施本身提出了哪些严格的“固若金汤”的要求。
FAQ 环节
Q1：为什么规范中很多安全特性（如RRC/NAS/UP加密）都是“运营商可选”的？这是否意味着我的通信可能不安全？
A1：规范设定为“可选”主要是为了提供部署灵活性，并向后兼容一些早期或特定场景。然而，规范的NOTE中也明确“推荐使用”。在当今全球主流运营商的实际网络部署中，出于竞争、法规和用户隐私保护的需要，空口的用户数据（UP）和信令（RRC/NAS）加密基本上都已成为默认开启的标配。因此，作为普通用户，您基本可以认为您的4G通信在空口是受到加密保护的。
Q2：加密算法128-EEA1/2/3中的“128”代表什么？这个强度足够吗？
A2：“128”代表这些算法使用的密钥长度是128比特。128位密钥意味着存在2的128次方种可能的密钥组合，这是一个天文数字。以目前的计算能力，暴力破解128位AES密钥被认为是不可行的。因此，对于当前和可预见的未来，128位对称加密的强度对于保护商用移动通信是足够安全的。
Q3：既然对信令的完整性保护是强制的，为什么对用户数据的完整性保护却是可选的？
A3：这是一个在安全性、性能和资源开销之间的权衡。信令是网络的“神经系统”，其准确性至关重要，一旦被篡改可能导致连接中断、被劫持到恶意网络等严重后果，因此必须强制保护。而用户数据（如网页、视频）量极大，逐包进行完整性计算和校验会消耗大量的终端CPU、基带处理能力以及额外的无线带宽（用于传输MAC），可能影响用户体验到的最高速率。同时，用户数据被篡改的后果通常没有信令被篡改那么严重（例如视频出现一个花屏的帧），因此规范将其设为可选，由运营商根据业务需求和网络能力来决定是否开启。
Q4：如果我的手机不支持128-EEA3（ZUC算法），而网络选择使用ZUC算法，会发生什么？
A4：这种情况不会发生。在安全激活（SMC）之前，手机会先向网络上报自己支持的安全能力列表，其中就包含了它支持的所有加密和完整性算法。网络（MME或eNB）在选择算法时，必须从手机上报的能力集和网络自身配置的优先策略列表中取一个交集，并从中选择优先级最高的算法。因此，网络绝不会选择一个手机不支持的算法。
Q5：为什么在没有SIM卡的紧急呼叫场景下，规范允许上报IMEI，甚至不进行加密和完整性保护？
A5：这是基于“生命安全优先于通信安全”的普适原则。在紧急情况下，最首要的目标是尽快建立与紧急救援中心的通信。1) 上报IMEI：在没有SIM卡（即没有用户身份IMSI）时，IMEI是唯一能标识这台设备的ID，它对于紧急中心回拨电话或定位设备至关重要。2) 使用空算法（EEA0/EIA0）：如果因为认证失败或其他原因无法建立安全的信道，强行要求安全可能会导致紧急呼叫本身失败。此时，放弃加密和完整性保护，优先确保信令能够送达、语音能够建立，是更合理的选择。这种安全上的妥协，是为了保障更高级别的人身安全。