# 5G空口安全模式激活信令拆解：NAS与AS双SMC全链路与密钥刷新机制
## 一、为什么5G要用"两次"安全模式命令
在4G EPS中，空口安全激活由MME的NAS安全模式命令（NAS SMC）和eNB的AS安全模式命令（AS SMC）共同完成，但许多工程师在5G SA网络抓包时第一次直观地看到**两条几乎同名的Security Mode Command信令紧挨着出现**，会产生困惑：认证（5G-AKA / EAP-AKA'）明明已经派生出了主密钥，为什么还要再"握手"两次？
这背后的根本原因在于5G沿用了**NAS（非接入层）与AS（接入层）分离的安全分层模型**（TS 33.501 §6.1）。这两层的安全职责、密钥来源、保护范围完全不同：
- **NAS层安全**保护的是UE与AMF之间的移动性/会话信令（如注册、PDU会话相关NAS消息），密钥 `K_AMF` 由核心网持有，与无线制式无关——这一点对5G的多接入（3GPP接入与non-3GPP接入共享同一K_AMF）至关重要。
- **AS层安全**保护的是UE与gNB之间的RRC信令和用户面数据，密钥 `KgNB` 由接入网派生，会随每一次切换、每一次重建立而刷新。
两次SMC的本质，是网络分别向UE"宣告并验证"这两套独立的密钥与算法已经就绪。缺少任何一次，安全上下文都不完整。本文将逐条信令、逐个信息元素（IE）地拆解这一过程，并延伸到5G独有的 **K_AMF重派生（KAMF change）** 与**空算法协商**机制。
## 二、NAS安全模式控制流程（TS 24.501 §5.4.2）
### 2.1 触发时机与基本流程
NAS安全模式控制（Security mode control）是5GMM（5GS Mobility Management）协议中的一个网络发起流程。它在主认证成功、AMF获得 `K_SEAF` 并派生出 `K_AMF` 之后、UE上下文建立完成之前触发。典型顺序为：
1. UE在 `REGISTRATION REQUEST`（明文）中携带 **5GS NAS security capability**（即UE支持的NEA/NIA算法集合）和 `ngKSI = "no key" (7)`；
2. AMF与AUSF/UDM完成5G-AKA或EAP-AKA'，得到 `K_AUSF → K_SEAF`，再派生 `K_AMF`；
3. AMF根据本地策略与UE能力，**选择**一对NAS算法（一个加密NEA、一个完整性NIA），并以选中的完整性算法对应的 `KNASint` 计算 `SECURITY MODE COMMAND` 消息的NAS-MAC；
4. AMF向UE下发 `SECURITY MODE COMMAND`（明文承载但带MAC）；
5. UE用对应 `KNASint` 验证MAC，校验回放的UE安全能力、检查ngKSI与算法合法性；
6. 校验通过则激活NAS安全（启动加密与完整性保护），回送 `SECURITY MODE COMPLETE`——**这是第一条真正被加密+完整性保护的NAS消息**；失败则回送 `SECURITY MODE REJECT` 并携带5GMM cause。
### 2.2 SECURITY MODE COMMAND 关键IE解析
下表给出该消息中与安全直接相关的核心IE（IE定义见TS 24.501 §9.11）。
| IE名称 | 规范章节 | 作用 | 关键取值说明 |
|--------|---------|------|-------------|
| Selected NAS security algorithm | §9.11.3.33 | 指定本上下文使用的完整性+加密算法 | 高半字节=NIA（5G-IA0~IA3），低半字节=NEA（5G-EA0~EA3） |
| Replayed UE security capability | §9.11.3.54 | 把UE在注册请求里上报的能力原样回放 | 含5G-IA/EA、EIA/EA、UIA/EA（UP完整性）等位图 |
| ngKSI | §9.11.3.26 | 标识本次建立的NAS密钥集 | type=native/mapped，key set id 0~6；7=无有效密钥 |
| Additional 5G NAS security context | §9.11.3.8 | K_AMF重派生时携带新ngKSI | 仅KAMF change流程出现 |
| Additional 5G security information | §9.11.3.7 | 携带RGC、降级防护相关标志 | 含"RGC"等比特位 |
| IMEISV request | §9.11.3.27 | 请求UE上报IMEISV | 用于设备身份核查 |
这里有两个设计上的"巧思"需要特别注意：
**第一，为什么要把UE能力"回放"回来？** 这是5G（和4G一脉相承）的**防降级（anti-bidding-down）**机制。如果网络只单方面告诉UE"用NEA2"，UE无法判断这是网络真实选择还是中间人篡改。回放UE自己上报的能力集合，并被NAS-MAC完整性绑定，UE就能确认"网络是从我声明的能力中合法选择的"，任何试图把算法降级到空算法或弱算法的中间人篡改都会因MAC校验失败而被识破。
**第二，ngKSI的作用。** 它是 `K_AMF` 的"索引标签"。5G的ngKSI是一个两段结构：`security context flag`（native=0 / mapped=1）+ `key set identifier`（0~7）。当UE本地存了多套上下文（例如移动到新AMF后的旧上下文、或mapped上下文），ngKSI让双方在后续消息中明确"我现在用的是哪一套密钥"，避免密钥混淆。
### 2.3 NAS SMC交互时序
```mermaid
sequenceDiagram
participant UE
participant gNB as gNB (NG-RAN)
participant AMF
Note over UE,AMF: 主认证已完成,K_SEAF已就绪
AMF->>AMF: 由K_SEAF派生K_AMF,
再派生KNASint/KNASenc
AMF->>UE: SECURITY MODE COMMAND
(ngKSI, Selected NAS algo, Replayed UE sec cap, NAS-MAC)
Note over UE: 用KNASint校验MAC,
检查回放能力与算法合法性
alt 校验通过
UE->>AMF: SECURITY MODE COMPLETE
(加密+完整性保护,第一条受保护NAS消息)
Note over UE,AMF: NAS安全上下文激活
else 校验失败
UE->>AMF: SECURITY MODE REJECT
(5GMM cause #27等)
end
```
## 三、AS安全激活流程（TS 38.331 §5.3.3）
### 3.1 与NGAP初始上下文建立的耦合
NAS SMC完成后，AMF通过NGAP的 `INITIAL CONTEXT SETUP REQUEST` 把安全上下文下发给gNB——这里携带的并不是 `K_AMF` 本身（核心网主密钥绝不下沉到接入网），而是经KDF派生出的 `KgNB`（以及 `NH`、接入网允许使用的算法列表 `Allowed NSSAI`、UE安全能力等）。gNB据此进一步派生AS层各子密钥：
- `KRRCint`（RRC完整性）、`KRRCenc`（RRC加密）
- `KUPenc`（用户面加密）、`KUPint`（用户面完整性，5G新增）
派生完成后，gNB通过RRC发起 `SecurityModeCommand`。
### 3.2 SecurityModeCommand / Complete / Failure
`SecurityModeCommand`（RRC，承载于SRB1）的核心内容是 `securityAlgorithmConfig`，即一对 `integrityProtAlgorithm` 与 `cipheringAlgorithm`。该消息**自身用新选中的KRRCint做完整性保护**——这是激活AS完整性的"锚点"。UE的响应有两种：
- `SecurityModeComplete`：**第一条同时被完整性保护和加密的RRC消息**，确认AS安全已激活；
- `SecurityModeFailure`：当UE不支持网络选择的算法时回送，触发RRC连接重建。
需要强调：**SRB0（承载RRC Setup等初始消息）永远不加密**；完整性保护从 `SecurityModeCommand` 开始生效。用户面DRB的加密/完整性则随 `SecurityModeComplete` 之后通过 `RRC Reconfiguration` 建立。
## 四、注册流程中的完整双SMC时序
把NAS SMC与AS SMC放回注册流程的完整上下文中，可以看到二者紧密咬合：
```mermaid
sequenceDiagram
participant UE
participant gNB
participant AMF
participant AUSF as AUSF/UDM
UE->>AMF: Registration Request(明文,UE安全能力,SUCI/SUPI)
AMF->>AUSF: 5G-AKA / EAP-AKA'(主认证)
AUSF-->>AMF: K_AUSF→K_SEAF
AMF->>AMF: 派生K_AMF,KNASint/enc
AMF->>UE: SECURITY MODE COMMAND(NAS SMC)
UE->>AMF: SECURITY MODE COMPLETE(NAS安全激活)
AMF->>gNB: NGAP INITIAL CONTEXT SETUP REQUEST(KgNB,算法列表)
gNB->>gNB: 派生KRRCint/enc,KUPenc/int
gNB->>UE: SecurityModeCommand(AS SMC,securityAlgorithmConfig)
UE->>gNB: SecurityModeComplete(首条加密+完整性RRC消息)
gNB->>AMF: INITIAL CONTEXT SETUP RESPONSE
AMF->>UE: Registration Accept(已加密)
```
这个时序揭示了一个工程上常见的误解：**NAS SMC并不依赖AS SMC，二者可以独立失败**。NAS安全已经激活（SMC Complete已回），但如果gNB派生 `KgNB` 失败或算法不匹配导致AS SecurityModeFailure，会出现"NAS安全OK但RRC没加密"的尴尬中间态，此时网络通常触发RRC重建而非直接释放。
## 五、密钥层级与K_AMF重派生（TS 33.501 §6）
### 5.1 完整密钥链
理解两次SMC，必须看清背后的密钥派生链。5G采用层层KDF（HMAC-SHA-256）推演，任何一层密钥泄露都不会向上回溯：
```mermaid
flowchart TD
K["K(USIM永久密钥,128/256bit)"]
CKIK["CK‖IK(AKA输出)"]
KAUSF["K_AUSF"]
KSEAF["K_SEAF"]
KAMF["K_AMF(ngKSI标识)"]
KNASint["KNASint"]
KNASenc["KNASenc"]
KgNB["KgNB(由K_AMF派生,下发给gNB)"]
KRRCint["KRRCint"]
KRRCenc["KRRCenc"]
KUPenc["KUPenc"]
KUPint["KUPint(5G新增UP完整性)"]
K --> CKIK --> KAUSF --> KSEAF --> KAMF
KAMF --> KNASint
KAMF --> KNASenc
KAMF --> KgNB
KgNB --> KRRCint
KgNB --> KRRCenc
KgNB --> KUPenc
KgNB --> KUPint
style KAMF fill:#ffe0b2,stroke:#e65100
style KgNB fill:#bbdefb,stroke:#0d47a1
```
`K_AMF`（橙色）是NAS层的根、`KgNB`（蓝色）是AS层的根。两者都来自同一个 `K_SEAF`，但 `K_AMF` 由AMF持有且在切换时不变，`KgNB` 随每次切换/重建立刷新——这正是"NAS一次SMC建立后长期有效、AS每次切换都要重新派生"的密码学基础。
### 5.2 K_AMF重派生（KAMF change）——不重新认证也能换根密钥
这是5G安全中一个容易被忽略、但在长连接与高安全等级场景下极重要的机制（TS 33.501 §6.x）。当 `K_AMF` 的使用计数达到阈值、或出于前向安全考虑需要刷新时，AMF可以在**不发起二次AKA**的情况下，通过KDF从当前 `K_AMF` 派生出一个新的 `K_AMF'`，并用 `ngKSI` 指向新密钥集。
实现上，AMF在下一次 `SECURITY MODE COMMAND` 中携带 **Additional 5G NAS security context** IE，其中包含新ngKSI。UE收到后据此切换到新 `K_AMF'`，并重新派生 `KNASint/enc`、`KgNB`。其状态流转如下：
```mermaid
stateDiagram-v2
[*] --> NativeCtx: 首次SMC(ngKSI=native)
NativeCtx --> NativeCtx: 普通信令(沿用同ngKSI)
NativeCtx --> KAMFChange: SMC携带Additional NAS security context(新ngKSI)
KAMFChange --> NativeCtx: UE切换到K_AMF',重派生子密钥
NativeCtx --> MappedCtx: 跨系统(来自EPS)
MappedCtx --> NativeCtx: 本网完成5G认证后转native
```
设计意图：把"换密钥"与"鉴权"解耦。鉴权（AKA）是相对昂贵的信令流程，会消耗USIM计算资源并增加时延；而KAMF change只需一次NAS SMC、一次本地KDF，即可刷新整条NAS+AS密钥链，兼顾安全性与性能。
## 六、算法协商与空算法策略
5G统一使用 **NEA**（5G加密算法）与 **NIA**（5G完整性算法）家族，NAS与AS共用同一套算法编号（TS 33.501 Annex）：
| 算法标识 | 名称 | 依据 | 用途 |
|---------|------|------|------|
| NEA0 | 空加密 | — | 加密但实际为空(仅紧急呼叫等受限场景) |
| 128-NEA1 | 128-5G-EA1 | SNOW 3G | 加密 |
| 128-NEA2 | 128-5G-EA2 | AES-CTR | 加密(最常用) |
| 128-NEA3 | 128-5G-EA3 | ZUC | 加密 |
| NIA0 | 空完整性 | — | 完整性但实际为空(运营商策略限制) |
| 128-NIA1 | 128-5G-IA1 | SNOW 3G | 完整性 |
| 128-NIA2 | 128-5G-IA2 | AES-CMAC | 完整性 |
| 128-NIA3 | 128-5G-IA3 | ZUC | 完整性 |
协商规则严格受防降级约束：AMF/gNB选用的算法**必须是UE在注册请求中上报能力集合的子集**。`NEA0`/`NIA0` 空算法虽然规范保留，但5G对空算法的使用远比4G谨慎——尤其是**用户面完整性保护**成为5G新特性后，运营商普遍倾向强制开启非空完整性（NIA2/NIA3），以抵御伪基站注入。
| 维度 | NAS SMC | AS SMC |
|------|---------|--------|
| 发起网元 | AMF | gNB |
| 消息协议 | 5GMM (TS 24.501) | RRC (TS 38.331) |
| 受保护对象 | NAS信令 | RRC信令 + 用户面 |
| 根密钥 | K_AMF | KgNB |
| 切换时是否刷新 | 否(跨AMF移动性才变) | 是(每次切换/重建立) |
| 算法IE | Selected NAS security algo | securityAlgorithmConfig |
| 重派生机制 | KAMF change(带新ngKSI) | 水平/垂直派生 |
## 七、抓包识别与故障排查
### 7.1 Wireshark中的识别要点
打开一份5G SA注册抓包，按以下顺序定位：
1. **NAS层**：过滤 `nas-5gs && (nas_5gs.mm.message_type == 0x5d || nas_5gs.mm.message_type == 0x5e)`，前者是SECURITY MODE COMMAND，后者是COMPLETE。展开消息，重点看 `Selected NAS security algorithm` 的两段半字节与 `Replayed UE security capability`。
2. **AS层**：过滤 `rrc.nrRRC && (rrc.setup == SecurityModeCommand || rrc.setup == SecurityModeComplete)`，展开 `securityConfig → securityAlgorithmConfig`。
3. **NGAP层**：过滤 `ngap && ngap.procedure_code == 14`（InitialContextSetup），其中 `Security key`（即KgNB）与 `UE security capabilities` 字段是AMF下发给gNB的输入。
判断"安全是否真正激活"，看两点：NAS方向SECURITY MODE COMPLETE之后的所有NAS消息在Wireshark中应可被解码（说明已加密，且你的解密密钥已配置）；AS方向SecurityModeComplete之后的RRC与DRB应显示已加密。
### 7.2 典型故障点
- **SECURITY MODE REJECT（5GMM cause #24/27）**：最常见根因是Selected NAS algorithm不在UE上报能力集中，或ngKSI与UE本地上下文不匹配。排错时先比对UE REGISTRATION REQUEST里的能力位图与AMF选择。
- **NAS SMC Complete却不出AS SMC**：检查NGAP Initial Context Setup是否携带了合法的 `Security key`；若AMF未下发KgNB，gNB无法派生AS密钥。
- **SecurityModeFailure反复出现**：通常是UE与gNB算法实现不兼容（尤其256-bit算法在不同Release终端上的支持差异），需核查 `securityAlgorithmConfig` 中算法是否在终端支持列表内。
- **长连接业务突发掉话但KPI正常**：考虑KAMF change或KgNB水平派生异常导致的密钥不同步，可在UE侧核对NAS COUNT是否回绕、ngKSI是否被意外切换。
## 常见问题
**Q1：为什么必须NAS SMC和AS SMC两次，合并成一次不行吗？**
A：不行。NAS安全由AMF的 `K_AMF` 保证，与无线制式无关（要让3GPP与non-3GPP接入共用同一NAS密钥）；AS安全由gNB的 `KgNB` 保证，且必须随每次切换刷新。两者根密钥不同、生命周期不同、受保护对象不同，因此必须分别激活。NAS SMC是"核心网到UE"的安全确认，AS SMC是"接入网到UE"的安全确认。
**Q2：ngKSI=7代表什么？native和mapped又有何区别？**
A：ngKSI=7表示"无有效密钥可用"，通常出现在初始注册、UE本地没有任何有效安全上下文时。native（标志位=0）表示密钥来自本5G网络的直接5G-AKA/EAP-AKA'派生；mapped（标志位=1）表示由EPS侧密钥映射而来（如从4G切换/重选到5G时），是一种过渡性上下文，待本网完成认证后会转为native。
**Q3：NEA0/NIA0空算法在5G里还能用吗？**
A：规范保留但限制极严。NEA0仅允许在紧急呼叫等受限场景，NIA0同样受运营商策略约束。由于5G引入了用户面完整性保护，且伪基站威胁日益突出，主流运营商在网络侧默认拒绝空算法，强制使用NIA2/NIA3等非空完整性。
**Q4：K_AMF重派生（KAMF change）需要重新做AKA吗？**
A：不需要。AMF通过KDF从当前 `K_AMF` 派生新的 `K_AMF'`，并在下一次SECURITY MODE COMMAND里用Additional 5G NAS security context IE携带新ngKSI。UE据此切换密钥集即可，整个过程只多一次NAS SMC、无需USIM参与AKA计算，兼顾安全刷新与低开销。
**Q5：抓包里如何快速区分一条Security Mode Command是NAS的还是AS的？**
A：看协议栈与消息字段。NAS SMC在5GMM协议上，字段叫 `Selected NAS security algorithm`，必带 `ngKSI` 与 `Replayed UE security capability`，且消息带NAS-MAC；AS SMC在RRC协议上，字段叫 `securityAlgorithmConfig`（含integrityProtAlgorithm/cipheringAlgorithm），不带ngKSI。两者出现顺序固定：先NAS后AS。
## 参考来源
1. [3GPP TS 24.501 V18.x — Non-Access-Stratum (NAS) protocol for 5GS](https://www.3gpp.org/dynareport/24501.htm) — §5.4.2 Security mode control procedure；§9.11 相关IE定义
2. [3GPP TS 38.331 V18.x — NR RRC Protocol Specification](https://www.3gpp.org/Dynareport/38331.htm) — §5.3.3 Security mode activation procedure
3. [3GPP TS 33.501 V18.x — Security architecture and procedures for 5G system](https://www.3gpp.org/dynareport/33501.htm) — §6 密钥层级与KAMF change；Annex NEA/NIA算法
4. [3GPP TS 23.502 V18.x — Procedures for the 5G System](https://www.3gpp.org/dynareport/23502.htm) — §4.2.2 Registration procedure中的安全激活时序
5. [5G NAS Security Mode Command and Equipment Identity Check Explained Step-by-Step — TelecomTrainer](https://www.telecomtrainer.com/5g-nas-security-mode-command-and-equipment-identity-check-explained-step-by-step/) — SMC与设备身份核查的实操拆解
6. [5GMM-Security Mode Control procedure（一）— CSDN](https://blog.csdn.net/weixin_57568132/article/details/151116910) — mapped/native安全上下文与ngKSI的工程解析
7. [5G认证与安全性-part3-两次安全模式命令SMC（B站）](https://www.bilibili.com/video/BV1t44y157Qi/) — 为什么需要两次SMC的视频讲解
---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
