51学通信

深度解析 3GPP TS 33.501：6.4 NAS安全机制 (信令保护的“双重锁”)

21分钟阅读

深度解析 3GPP TS 33.501：6.4 NAS安全机制 (信令保护的“双重锁”)

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“6.4 NAS security mechanisms”的核心章节，旨在为读者深度剖析5G非接入层（NAS）信令是如何被一对坚不可摧的“双重锁”——机密性与完整性——所保护的。

在上一篇文章中，我们详细探讨了5G安全上下文这份“数字护照”的生命周期，了解了它如何在网络中被分发、传递和管理。我们知道，这份护照的核心是密钥K_AMF。今天，我们将聚焦于这份“护照”最直接、最重要的用途：如何用它来保护UE与核心网AMF之间的“悄悄话”——NAS信令。

本篇文章将深入解读规范的6.4节——NAS安全机制。这一节是5G安全从理论走向实践的关键一步，它详细定义了保护N1接口（UE与AMF之间的逻辑接口）信令的“双重锁”——机密性（Confidentiality）和完整性（Integrity）——的具体实现细节。我们将揭示：

  • 在多重连接（如同时使用蜂窝和Wi-Fi）的复杂场景下，NAS安全如何做到“井然有序”？
  • 为信令“上锁”时，需要哪些精确的“钥匙”和“参数”？
  • 防止重放攻击的“生命线”——NAS COUNT计数器，是如何被严格管理的？
  • 在建立安全之前，第一条NAS消息是如何实现“自我保护”的？

我们的主角“安安”正坐在车站的VIP休息室，她的手机不仅连接着运营商的5G蜂窝网络，同时也接入了运营商提供的免费高速Wi-Fi。在她看来，这只是为了获得更快的网速。但在核心网工程师“李工”的眼中，一场对“多重连接”场景下NAS安全的精妙管理正在上演。

1. 6.4.1 通用原则 & 6.4.2 多重连接下的安全 - “一把钥匙”与“两把锁”

NAS安全机制的根本目标，是保护UE与AMF之间N1接口上传输的所有信令消息。这份保护依赖于双方共享的5G安全上下文，特别是其中的K_AMF。然而，当UE通过多种途径（如3GPP接入和非3GPP接入）连接到网络时，情况变得复杂起来。

1.1 连接不同运营商网络：各自为政

6.4.2.1 Multiple active NAS connections with different PLMNs …the UE shall independently maintain and use two different 5G security contexts, one per PLMN serving network.

这种情况比较简单。如果安安的手机连接着中国移动的5G，同时又通过VoWiFi连接到了另一家运营商的网络，那么她的手机必须维护两套完全独立的安全上下文。这就像她持有两本不同国家的护照，进入哪个国家就用哪本护照，互不干涉。

1.2 连接同一运营商网络：共享核心，分离计数

这是技术上的关键点，也是安安当前所处的场景：她的手机通过5G蜂窝和运营商Wi-Fi，同时连接到了同一个AMF。

6.4.2.2 Multiple active NAS connections in the same PLMN’s serving network The AMF and the UE shall establish a common NAS security context consisting of a single set of NAS keys and algorithm… The common NAS security-context shall have parameters specific to each NAS connection. The connection specific parameters include a pair of NAS COUNTs for uplink and downlink and unique NAS connection identifier.

解读： 为了效率和管理的简化，规范规定在这种情况下，采用**“共享核心，分离计数”**的模型。

  • 共享核心 (Common NAS Security Context)：UE和AMF之间只建立和维护一套公共的NAS安全上下文。这意味着，无论是通过蜂窝还是Wi-Fi发送的NAS信令，都使用同一套NAS密钥（从同一个K_AMF派生出的K_NASint/K_NASenc）和相同的安全算法。这就像安安只需要一本护照（一个K_AMF），就可以在同一个国家的多个“关口”进出。

  • 分离计数 (Separate COUNTs & Identifiers)：为了防止跨接入类型的攻击（例如，在Wi-Fi上窃听了一条消息，然后拿到蜂窝网络上重放），必须为每条NAS连接维护独立的“账本”。

    • 独立的NAS连接标识符 (NAS connection identifier)：0x01代表3GPP接入（蜂窝），0x02代表非3GPP接入（Wi-Fi）。
    • 独立的NAS COUNT计数器：每条连接都有一对独立的、用于防重放的上行和下行计数器。

场景代入： 李工看着安安的会话信息，解释道：“安安现在有两条通往我这个AMF的路。但我们之间只认同一套‘暗号本’（K_AMF）。不过，为了安全，我们规定，从‘蜂窝’这条路送来的信，必须是连续编号的（使用COUNT_3GPP），从‘Wi-Fi’那条路送来的信，则使用另一套独立的连续编号（使用COUNT_non3GPP）。如果我收到一封来自‘蜂窝’路的信，但用的却是‘Wi-Fi’路的编号，我就会立刻把它当作伪造的信件丢弃。”

2. 6.4.3 & 6.4.4 完整性与机密性机制 - “双重锁”的精密构造

NAS信令的保护依赖于“双重锁”：先用完整性密钥签名（贴上防伪封条），再用机密性密钥加密（放入保险箱）。这两把锁的构造和使用方法被严格定义。

6.4.3.1 NAS input parameters to integrity algorithm The input parameters to the NAS 128-bit integrity algorithms as described in Annex D shall be set as follows. The KEY input shall be equal to the KNASint key. The BEARER input shall be equal to the NAS connection identifier. The DIRECTION bit shall be set to 0 for uplink and 1 for downlink. The COUNT input shall be constructed as follows: COUNT := 0x00 || NAS COUNT

解读： 无论是完整性算法（NIA）还是机密性算法（NEA），它们的输入参数都高度相似，包括：

  • KEY：128位的密钥。完整性保护使用K_NASint，机密性保护使用K_NASenc。密钥分离是强制要求。
  • COUNT：一个32位的输入计数器。这是防重放攻击的核心。它由一个8位的NAS SQN（在NAS消息头中传输）和一个16位的NAS OVERFLOW（在UE和AMF本地维护）拼接而成。每当NAS SQN从255回绕到0时，NAS OVERFLOW就加1。这确保了在K_AMF的生命周期内，COUNT值永不重复。
  • BEARER：5位的承载标识。对于NAS保护，这个值就等于我们上面提到的**NAS connection identifier**（0x01或0x02）。这个参数告诉算法，应该去取哪一套NAS COUNT计数器来与消息头中的SQN组合。
  • DIRECTION：1位的方向，0代表上行（UE→AMF），1代表下行（AMF→UE）。
  • MESSAGE / LENGTH：需要保护的消息本身及其长度。

这些参数的精确组合，确保了即使使用相同的密钥，对不同方向、不同连接、不同顺序的消息，所生成的密钥流和MAC值都是独一无二的。

3. 6.4.5 NAS COUNT的处理 - 信任的“生命线”

如果说密钥是静态的信任基础，那么动态变化的NAS COUNT就是维持这份信任持续有效的“生命线”。

It is essential that the NAS COUNTs for a particular KAMF are not reset to the start values (that is the NAS COUNTs only have their start value when a new KAMF is generated). This prevents the security issue of using the same NAS COUNTs with the same NAS keys, e.g. key stream re-use…

核心原则：K_AMF与NAS COUNT的组合永不重复 规范以“essential（至关重要）”一词强调了这个原则。重用相同的密钥和相同的COUNT值，在密码学上是灾难性的，这会导致“密钥流重用”。

场景代入： 李工用一个通俗的比喻解释了密钥流重用的危险：“想象一下，我们的加密算法就像一本一次性的密码本（One-Time Pad）。K_AMF决定了你用哪一本密码本，而COUNT决定了你从密码本的第几页开始抄写。如果你用同一本密码本（K_AMF不变），又两次都从第一页（COUNT被重置）开始抄，那么两份不同的明文，就会被同一段密钥流加密。攻击者只需要拿到这两份密文，将它们进行异或运算，就能消除掉密钥流，直接得到两份明文异或的结果，从而极大地破解你的信息。”

为了防止这种情况，规范严格规定，NAS COUNT只有在以下三种**K_AMF被全新创建**的情况下才能被重置为0：

  1. 一次成功的主认证后，生成了一个新的原生K_AMF。
  2. 从EPS（4G）移动过来，生成了一个新的映射K_AMF。
  3. 在AMF间切换（mobility registration update）或N2切换（handover）后，生成了一个新的K_AMF。

除此之外，只要K_AMF还在使用，NAS COUNT就必须持续累加，绝不允许回退。

4. 6.4.6 初始NAS消息的保护 - “先有鸡还是先有蛋”的解决方案

在UE与AMF建立起安全上下文之前，它们之间没有共享的密钥。那么，UE发送的第一条Registration Request消息，如何保证其安全呢？这是一个典型的“先有鸡还是先有蛋”的安全引导问题。

规范 Figure 6.4.6-1: Protecting the initial NAS message 展示了这个巧妙的流程。

  • 情况一：UE“失忆”（没有有效的安全上下文） UE只能发送一条未受保护的Registration Request，其中只包含最基本的信息，如SUCI或旧的GUTI，以及UE的安全能力。这些信息用于网络的识别和路由。

  • 情况二：UE“有记忆”（有一个之前存储的有效安全上下文） UE会发送一条经过完整性保护的Registration Request。这条消息被巧妙地分为两部分：

    1. 明文部分：包含GUTI和ngKSI，用于让AMF能快速找到对应的安全上下文。
    2. 密文部分 (NAS Container)：包含注册请求的其余部分（如请求的切片信息等），使用旧的NAS加密密钥进行加密。

场景代入：

  1. “智行一号”首次开机：它发送了一条只包含SUCI的、未受保护的Registration Request。AMF收到后，知道必须走完整认证流程。
  2. 认证成功后：AMF发起SMC流程，双方建立安全上下文。
  3. “智行一号”进入空闲模式后被唤醒：它发送了一条受旧密钥保护的Service Request（一种初始NAS消息），其中包含了GUTI和ngKSI。AMF收到后，用ngKSI找到旧密钥，验证消息完整性。验证通过，连接迅速恢复。
  4. 如果AMF找不到旧密钥（例如，UE移动到了一个新AMF且上下文传递失败）：AMF会发现无法验证收到的消息。此时，它会像情况一一样，强制UE重新进行一次完整的主认证。

这个机制确保了，在有条件的情况下尽可能地快速恢复安全，在没有条件的情况下则退回到最安全、最原始的完整认证流程。

5. 6.4.7 SMS over NAS - 短信业务的安全保障

For MO/MT SMS over NAS … the NAS Transport message shall be ciphered and integrity protected using the NAS security context…

本节简要说明，当通过NAS信令通道来传输短信时（而非通过用户数据通道），承载短信内容的NAS Transport消息，也同样受到我们上面讨论的NAS安全机制的“双重锁”保护。

6. 总结

本章深入解读了6.4节，为我们揭示了5G网络中枢神经——NAS信令——安全保护的全部技术细节。

  • 多连接的智慧：通过“共享NAS上下文 + 独立NAS计数器”的精妙设计，优雅地解决了多接入场景下的安全与效率问题。
  • 算法的精确输入：通过KEY, COUNT, BEARER, DIRECTION等一系列精确的输入参数，确保了每一次密码学运算的唯一性和安全性。
  • COUNT的生命线：通过对NAS COUNT计数器近乎苛刻的管理规则，从根本上杜绝了致命的“密钥流重用”攻击，保障了加密体系的稳固。
  • 安全引导的巧思：通过对初始NAS消息的分情况处理，解决了安全建立之前的“第一步”保护问题，实现了安全与效率的平衡。

这些机制共同构筑了UE与核心网之间一条安全、可靠的“神经通路”，确保了所有控制指令都能准确、保密、不可篡改地传达。

FAQ

Q1：为什么在多连接到同一AMF时，要共享NAS密钥，而不是像连接不同PLMN那样用独立的密钥？ A1：主要是为了效率和简化管理。从逻辑上看，UE与AMF之间的NAS层关系是唯一的，无论UE通过何种物理路径接入。使用一套共享的NAS密钥（源自同一个K_AMF）可以：1) 减少密钥存储：UE和AMF都只需要维护一套核心NAS密钥。2) 简化密钥管理：当需要进行密钥更新（如主认证后）时，只需更新这一套公共的密钥即可，无需为每条接入路径都进行一次复杂的密钥更新流程。通过独立的COUNT计数器已经足以防止跨接入的攻击，因此没有必要再引入多套密钥带来的额外复杂性。

Q2：NAS消息头中的SQN只有8位，很快就会用完回绕，这如何保证防重放？ A2：这正是NAS OVERFLOW计数器存在的意义。UE和AMF在本地都会维护一个更长的NAS OVERFLOW计数器（16位）。当8位的SQN从255跳变到0时，本地的OVERFLOW计数器就会加1。在进行密码学运算时，算法使用的32位COUNT是由OVERFLOW和SQN拼接而成的。因此，即使SQN在不断循环，32位的COUNT在K_AMF的整个生命周期内（可以发送2^32条消息）都不会重复。接收方会根据收到的SQN和自己本地的OVERFLOW来判断这个SQN是否“新鲜”，从而有效防止重放攻击。

Q3：如果一条NAS消息的完整性校验失败了，网络会怎么处理？ A3：根据规范6.4.3.3 NAS integrity failure handling，如果AMF或UE在启动了完整性保护后，收到一条完整性校验失败（MAC值不匹配）或缺少MAC值的NAS消息，标准做法是直接丢弃该消息。这是一种严格的“安全优先”策略。因为无法验证消息的来源和完整性，就必须假设它可能来自攻击者或已被篡改，处理它可能会带来未知的安全风险。对于某些极少数的、在TS 24.501中明确列出的例外消息，AMF可能会采取一些特定的补救措施，但常规原则就是“校验失败，立即丢弃”。

Q4：为什么保护初始NAS消息时，要把消息拆成“明文部分”和“密文部分”？ A4：这是为了让AMF能够在解密前，就知道如何去解密。当UE使用一个旧的安全上下文来保护Registration Request时，它需要告诉AMF“我是谁”（GUTI）以及“我用的是哪套旧钥匙”（ngKSI）。这两个信息必须是明文的，否则AMF收到一包无法识别的加密数据，将无从下手。AMF在收到消息后，先读取明文部分的GUTI和ngKSI，用它们在数据库中找到对应的旧密钥，然后再用这个旧密钥去解密“密文部分”（NAS Container），并验证整个消息的完整性。这种“先明后密”的结构，是实现安全上下文快速恢复的关键。

Q5：K_AMF、K_NASint和K_NASenc三者之间是什么关系？ A5：是严格的父子派生关系。K_AMF是“父密钥”。当需要保护NAS信令时，UE和AMF会使用一个标准的密钥派生函数（KDF），以K_AMF作为输入，再加上一些用于区分用途的参数（如算法类型、算法ID），分别派生出K_NASint和K_NASenc这两个“子密钥”。K_NASint被专门用于完整性保护算法，K_NASenc被专门用于机密性保护算法。这种从同一个父密钥为不同目的派生出不同子密钥的做法，被称为“密钥分离”，是现代密码学协议设计的最佳实践之一。

关系图谱