好的，我们继续对3-GPP TS 33.401的深度探索之旅。在完成了对第七章——UE与接入网之间复杂而精细的安全交互的解读之后，我们将视角重新拉回到一个更宏观但同样至关重要的层面：非接入层（NAS）。
虽然我们在之前的章节中已多次提及NAS安全，但第八章Security mechanisms for non-access stratum signalling and data via MME是对其进行的一次系统性、专门性的论述。本章内容相对集中，我们将在一篇文章内完成对其的全面解析。
深度解析 3GPP TS 33.401：第八章 NAS信令及经MME数据的安全机制
本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中，关于“8 Security mechanisms for non-access stratum signalling and data via MME”的核心章节，旨在为读者系统性地梳理NAS层的完整性与机密性保护机制，包括其独特的输入参数构造和激活流程。
想象一下，UE（用户设备）与核心网（EPC）之间的关系，如同一个前线士兵与后方总指挥部。士兵（UE）需要不断向指挥部（MME）汇报自己的位置（移动性管理）、请求火力支援（会话管理），指挥部也会向士兵下达战略指令。这些沟通的电报，就是NAS信令。
NAS（Non-Access Stratum，非接入层）信令的“非接入”，指的是它在逻辑上是“穿透”接入网（eNB）的。eNB对于NAS信令的内容通常是不可见的，它只负责为这些信令提供一个可靠的无线“投递”通道。NAS信令的真正端点，是UE和核心网的MME。保护这条“总指挥部热线”的安全，对于整个网络的安全稳定至关重要。
1. 概述与适用范围 (8.0 General)
The statements relating to UEs in clause 8 apply also to RNs regarding the security between a relay node and its MME.
Clause 8 also applies to the security procedures for data sent via the MME.
深度解读：
- 一致性原则：本章再次强调，关于UE的NAS安全规则，同样适用于中继节点（RN）与其MME之间的通信。
- 范围扩展：本章不仅适用于NAS信令，还适用于一种特殊情况——经由MME传输的用户数据（data via MME）。这主要指用于CIoT（蜂窝物联网）的控制面优化方案，允许极少量的数据打包在NAS信令中直接传输，以节省信令开销。
2. “防伪封条”的精细工艺：NAS完整性机制 (8.1 NAS integrity mechanisms)
第八章的重头戏，在于详细描述NAS完整性保护的具体实现。我们在前面已经知道，完整性保护是通过计算一个“消息认证码”（MAC）来实现的。8.1节则深入到了这个MAC是如何被精确计算出来的细节。
2.1 MAC计算的“配方”：NAS输入参数与机制 (8.1.1 NAS input parameters and mechanism)
计算NAS完整性保护的MAC（NAS-MAC），需要一个标准的完整性算法（如128-EIA2 AES-CMAC），以及一套精确定义的输入参数。
Input parameters to the NAS 128-bit integrity algorithms as described in Annex B are an 128-bit integrity key KNASint as KEY, an 5-bit bearer identity BEARER…, the direction of transmission DIRECTION, and a bearer specific, time and direction dependent 32-bit input COUNT…
深度解读：一个NAS-MAC的诞生，需要以下五大“原料”：
-
KEY (密钥)：128比特的
KNASint密钥。 -
MESSAGE (消息)：需要被保护的NAS信令本身。
-
DIRECTION (方向)：1比特，
0代表上行（UE to MME），1代表下行（MME to UE）。这个参数确保了上行和下行消息即使内容完全一样，其MAC值也不同，可以防止跨方向的重放攻击。 -
BEARER (承载标识)：5比特。这是一个非常有趣的设计。对于RRC和UP的保护，
BEARER是无线承载的ID。但对于NAS信令，UE和MME之间只有一个逻辑上的信令连接，并没有多个“承载”。那么这个参数是做什么用的呢？NOTE: The BEARER identity is not necessary since there is only one NAS signalling connection…but is included as a constant value so that the input parameters for AS and NAS will be the same, which simplifies specification and implementation work.
深度解读NOTE：规范解释说，包含
BEARER参数，并将其设置为一个固定的常量值0x00，是为了让NAS和AS（接入层）的算法输入参数在结构上保持一致。这极大地简化了UE和网络侧协议栈的实现，可以用一套通用的加密/完整性引擎来处理不同层级的安全，体现了设计的优雅与工程上的实用主义。 -
COUNT (计数器)：32比特。这是实现抗重放保护的核心。这个
COUNT就是我们在6.5节深入探讨过的NAS COUNT。
NAS COUNT的独特构造
规范对NAS COUNT的32比特结构给出了精确的定义：
COUNT := 0x00 || NAS OVERFLOW || NAS SQN
深度解读：
NAS SQN(Sequence Number)：低8比特，是一个序列号。它在每一条NAS消息的头部明文携带，每发一条消息就递增。NAS OVERFLOW(溢出计数器)：中间16比特。这个值不在空中传输，由UE和MME各自独立维护。当低位的NAS SQN从其最大值255回绕到0时，NAS OVERFLOW就加一。- Padding (填充)：最高的8比特固定为全
0。
场景串联：
假设小明手机当前的NAS OVERFLOW是10，NAS SQN是255。它要发送一条TAU Request。
- 手机将
NAS SQN加一，SQN变为0，同时OVERFLOW加一，变为11。 - 手机构造出32位的
NAS COUNT=0x00 | 0x000B | 0x00。 - 手机将这条
TAU Request消息，连同KNASint密钥、DIRECTION=0、BEARER=0以及这个新构造的NAS COUNT，一起送入完整性算法引擎，计算出32位的NAS-MAC。 - 手机将
TAU Request消息、NAS SQN=0以及NAS-MAC一起发送出去。 - MME收到后，用自己保存的
OVERFLOW=10和收到的SQN=0，判断出SQN发生了回绕，也将本地OVERFLOW更新为11。然后，MME构造出完全相同的NAS COUNT，执行相同的MAC计算和验证。
这个OVERFLOW + SQN的设计，在保证了32位COUNT唯一性的前提下，每次只需在空中传输8比特的SQN，极大地节省了信令开销。
2.2 “开启封条”：NAS完整性的激活 (8.1.2 NAS integrity activation)
我们已经知道NAS完整性是通过NAS SMC流程激活的。本节对此进行了更详细的阐述和强调。
NAS integrity shall be activated using the NAS SMC procedure or after a handover to E-UTRAN from UTRAN/GERAN. Once NAS integrity has been activated, NAS messages without integrity protection shall not be accepted by the UE or MME.
深度解读：
- 激活时机：除了常规的SMC流程，在从2G/3G切换到4G的场景下，NAS完整性也会被自动激活，其密钥来自映射的安全上下文。
- 严格的规则：一旦激活，所有后续的NAS消息都必须带有正确的完整性保护。任何没有完整性保护，或完整性校验失败的NAS消息，都将被无条件丢弃（除少数规范定义的例外，如某些拒绝消息）。这构成了NAS信令安全的第一道坚固防线。
NAS-MAC长度的特殊情况
The length of the NAS-MAC is 32 bit. The full NAS-MAC shall be appended to all integrity protected messages except for the NAS service request. Only the 16 least significant bits of the 32 bit NAS-MAC shall be appended to the NAS service request message.
深度解读：这是一个针对特定消息的优化。Service Request是UE从空闲态恢复时发送的第一条消息，其发生的频率非常高。为了极致地压缩这条消息的长度，节省无线资源和建立时延，规范允许其NAS-MAC被截断，只使用完整32位MAC的低16位。虽然16位的MAC在理论上更容易被碰撞（即被攻击者猜中），但考虑到Service Request消息本身的敏感度相对较低，且这种碰撞的概率在一次性交互中依然极低，因此这种优化被认为是可接受的。
3. “拉上窗帘”：NAS机密性机制 (8.2 NAS confidentiality mechanisms)
NAS机密性（加密）机制在输入参数上与完整性机制高度相似。
The input parameters for the NAS 128-bit ciphering algorithms shall be the same as the ones used for NAS integrity protection as described in clause 8.1, with the exception that a different key, KNASenc, is used as KEY, and there is an additional input parameter, namely the length of the key stream to be generated…
深度解读：计算NAS加密所需的“密钥流”时，其“配方”与完整性MAC的计算几乎完全一样，使用了相同的COUNT, BEARER, DIRECTION。主要区别有二：
- 使用不同的密钥：机密性使用
KNASenc，完整性使用KNASint。这种密钥分离是关键的安全实践，确保了即使其中一个密钥被泄露，另一个安全属性（机密性或完整性）依然不受影响。 - 多一个
LENGTH参数：加密算法需要知道需要生成多长的密钥流，这个长度与要加密的明文消息长度一致。
部分加密的特殊场景
If UE in EMM-IDLE mode uses Control Plane CIoT EPS optimisation for data transport, an initial plain NAS message including user data needs to be partially ciphered…
深度解读：这是对前面提到的“经由MME的数据传输”场景的特殊安全处理。当物联网设备通过NAS信令来传输少量数据时，整条NAS消息可能非常长，但其中只有承载用户数据的部分是敏感的，而消息头部的一些字段需要被沿途的eNB读取（例如，用于寻呼优化的信息）。在这种情况下，规范允许只对消息的“敏感载荷”部分进行加密，而保留头部为明文。这就是部分加密（Partial Ciphering）。
4. 总结
第八章系统性地巩固和细化了我们对NAS安全的理解。它像一部精密的机械设计图纸，向我们展示了4G网络“总指挥部热线”的安全保障是如何被精确实现的。
- 优雅的工程设计：通过在输入参数中引入固定的
BEARER值，实现了NAS与AS安全引擎在实现上的统一，降低了复杂度。 - 高效的计数器机制：通过
OVERFLOW+SQN的组合，实现了32位抗重放窗口，同时保持了极低的空中信令开销。 - 对关键信令的优化：通过对高频发生的
Service Request消息采用截断MAC，体现了在保证基本安全的前提下，对网络性能的极致追求。 - 密钥分离原则：
KNASint和KNASenc的严格分离，是现代密码学系统设计的基本准则，提供了更强的鲁棒性。 - 灵活适应新场景：部分加密机制的引入，展示了NAS安全框架能够灵活地适应物联网等新兴应用场景的需求。
理解了第八章，我们才算真正掌握了NAS安全“是什么”以及“如何做”。至此，我们已经完成了对4G原生安全机制（AKA、密钥体系、SMC、NAS/AS安全）核心部分的解读。
从下一篇文章开始，我们将进入一个全新的领域——第九章 Security interworking between E-UTRAN and UTRAN (E-UTRAN与UTRAN的安全互通)。我们将看到，当小明的手机在现代化的4G高速公路和经典的3G国道之间切换时，他的安全“护照”是如何被查验和转换的。
FAQ 环节
Q1：为什么NAS-MAC需要32位，而ShortResumeMAC-I只需要16位？
A1：这反映了不同场景下安全需求与性能开销的权衡。NAS信令是UE与核心网之间的长期、持续的通信渠道，面临的攻击时间和攻击面更广，使用32位MAC（提供2^32的安全性）可以提供非常高的防碰撞、防猜测保障。而ShortResumeMAC-I仅用于RRC连接恢复这一个“一次性”的、短暂的认证交互中，其上下文是动态变化的，攻击者试错的机会非常有限。在这种情况下，16位MAC（提供2^16的安全性）被认为已经足够抵御实时的伪造攻击，而其带来的信令开销减半的收益则非常可观。
Q2：如果UE或MME的NAS OVERFLOW计数器因为设备异常（如突然掉电重启）而丢失或回滚了，会发生什么？
A2：这将导致一次安全同步失败。假设UE侧的OVERFLOW回滚了。当它下次发送NAS消息时，它会使用一个已经使用过的、较小的NAS COUNT来计算MAC。MME收到后，会发现这个COUNT值在其抗重放窗口之外（太旧了），于是会拒绝该消息。通常，MME会返回一条Authentication Reject或类似的错误消息。这种持续的完整性校验失败，最终会迫使UE和MME放弃当前的安全上下文，UE需要重新发起Attach流程，通过一次全新的AKA来重建一个干净、同步的安全上下文。
Q3：NAS信令是“穿透”eNB的，那eNB真的对它一无所知吗？
A3：不完全是。虽然eNB无法解密NAS信令的内容，但它需要读取承载NAS信令的底层RRC消息的头部，以便正确地将其在空口调度和传输。此外，对于某些特定的NAS消息，UE可能会在其中包含一些供eNB使用的“提示信息”（例如，UE的寻呼优化相关的能力）。但对于NAS消息的核心载荷，例如Attach Request中的IMSI，或TAU Accept中的新GUTI，eNB是完全无法看到的，因为它们被KNASenc密钥加密了。
Q4：既然NAS信令的加密是可选的，如果运营商关闭了NAS加密，会有哪些安全风险？ A4：如果关闭NAS加密（但完整性保护通常是强制开启的），主要风险在于隐私泄露。攻击者虽然无法篡改信令，但可以通过监听空口，解密出NAS信令的明文内容。这将泄露大量敏感信息，例如：
- UE的移动性模式：攻击者可以看到UE何时发起
TAU，何时发起Service Request。 - UE的身份信息：在某些流程中，如
Attach Accept中下发的新GUTI将是明文的，攻击者可以关联新旧GUTI，降低匿名性。 - 会话管理信息：攻击者可以看到UE何时请求建立或释放一个数据承载（PDN连接）。 尽管这些信息不包含用户通话或上网的具体内容，但已经构成了严重的隐私侵犯。因此，在实践中，几乎所有运营商都会开启NAS信令加密。
Q5：为什么在构造NAS COUNT时，最高位的8比特要固定为0？
A5：这是一个为未来扩展或与其他系统兼容预留的设计。将最高位置0，可以确保当前定义的NAS COUNT值域只是32位空间的一部分。如果未来出现新的需求，比如需要定义一种新型的COUNT，就可以利用这些未使用的比特位来区分新旧COUNT类型，而不会与现有的COUNT体系发生冲突。这是一种在协议设计中常见的、具有前瞻性的做法。