# 5G NAS安全模式控制（SMC）信令全链拆解 ## 一、为什么需要 SMC：从"认证身份"到"激活保护" 在 5G 接入安全里，主认证（5G-AKA / EAP-AKA'）解决的是**"你是谁、你持有什么根密钥"**的问题——它最终在 AMF 与 UE 之间协商出一个共享密钥 `K_AMF`。但拿到 `K_AMF` 并不等于 NAS 信令已经被保护：`K_AMF` 只是"弹药"，还需要有人把它装进枪膛、选定口径（算法）、对准目标（NAS 层）。这个"装弹与激活"的动作，就是 **Security Mode Control（SMC，安全模式控制）过程**，定义在 3GPP TS 24.501 clause 5.4，其安全侧的依据与约束在 TS 33.501 clause 5.9 与 5.4 中给出。 SMC 是 5G 安全里一个被严重低估却极其关键的"一跳"： - 它是**第一条**用新安全上下文做完整性保护的 NAS 消息所在的过程； - 它同时完成**算法协商、密钥集标识（ngKSI）下发、降级攻击防御（replay + ABBA）**三件事； - 它把"UE 的用户面安全能力"这一 5G 新增维度确认给 UE，并为后续 AS（接入层）安全激活与 UP（用户面）安全铺路。 可以说：**没有成功的 SMC，就没有"可信赖"的 NAS 控制面。** 本文聚焦 TS 24.501 / TS 33.501 中 SMC 过程的具体信令机制，逐步拆解每个 IE 的作用、设计意图与实战排错。 --- ## 二、SMC 的完整信令时序 SMC 不是孤立发生的，它必须发生在**初始注册（或主认证完成、AMF 已获得有效 `K_AMF`）之后、AMF 下发 Registration Accept 之前**。完整上下文如下： ```text sequenceDiagram autonumber participant UE participant gNB participant AMF Note over UE,AMF: ① 注册请求（明文，携带 UE 安全能力） UE->>gNB: Registration Request
(UE security capability: NEA/NIA/UIA/UEA) gNB->>AMF: NGAP Initial UE Message (透传 NAS) Note over UE,AMF: ② 主认证（5G-AKA），产生 K_AMF AMF->>UE: Authentication Request (RAND, AUTN) UE->>AMF: Authentication Response (RES*) Note over AMF: ③ AMF 用 K_AMF 推演 KNASint/KNASenc
并选定 NEA/NIA 算法 AMF->>UE: SECURITY MODE COMMAND
(selected NAS alg, ngKSI,
replayed UE sec cap, ABBA, +IMEISV req) Note over UE: ④ UE 校验 MAC、核对 replayed 能力无降级、
核对 ABBA、激活安全上下文 UE->>AMF: SECURITY MODE COMPLETE
(完整性保护+加密; 可选 IMEISV) Note over UE,AMF: 后续 NAS 信令全部受保护 Note over AMF,gNB: ⑤ AMF 通过 NGAP 把含 UP 能力的
完整安全能力下发给 gNB AMF->>gNB: INITIAL CONTEXT SETUP REQUEST
(UE Security Capability 含 UIA/UEA) gNB->>UE: RRC Security Mode Command
(激活 AS 完整性+加密; 可选 UP 完整性) UE->>gNB: RRC Security Mode Complete gNB->>AMF: INITIAL CONTEXT SETUP RESPONSE ``` 注意第 4 步的关键属性：**SECURITY MODE COMPLETE 是第一条同时被完整性保护与加密的 NAS 消息**。而 SECURITY MODE COMMAND 本身是**只做完整性保护、不做加密**的——因为此时 UE 还未确认算法、加密尚未生效，AMF 用刚选定的 `NIA` 算法推演出 `K_NAS_int` 并对 COMMAND 计算消息鉴别码（MAC）。 --- ## 三、SECURITY MODE COMMAND 的关键 IE 解析 SMC COMMAND 携带的 IE 数量不多，但每一个都直指安全设计意图。下表是按 TS 24.501 clause 9.11.3 列出的 IE 说明： | IE 名称 | 规范章节 | 作用 | 必备/可选 | |---------|---------|------|-----------| | Extended protocol discriminator | 9.2 | 标识 5GS MM | M | | Security header type | 9.3 | 标识本消息为**完整性保护、未加密** | M | | Selected NAS security algorithms | 9.11.3.54 | AMF 选定的 `NIA` + `NEA` | M | | ngKSI | 9.11.3.55 | 标识当前 NAS 密钥集（3 bit） | M | | Replayed UE security capability | 9.11.3.48 | 回显 UE 上报的算法支持列表 | M | | Additional 5G security parameters | 9.11.3.4 | ABBA 参数，防跨架构降级 | M | | IMEISV request | 9.11.3.x | 请求 UE 在 COMPLETE 中回传 IMEISV | O | 下面用结构图展示 COMMAND 的逻辑构成与 UE 的校验动作： ```mermaid flowchart TD subgraph CMD["SECURITY MODE COMMAND (AMF→UE)"] A["Selected NAS Security Algo
NIA + NEA"] B["ngKSI
密钥集标识 0~6"] C["Replayed UE Sec Capability
NEA/NIA/UIA/UEA 列表"] D["ABBA
防降级参数(如 0x0000)"] E["IMEISV Request (可选)"] MAC["MAC_I
(用 K_NAS_int 计)"] end A --> V1["UE: 用选定 NIA 推演 K_NAS_int
并验证 MAC"] B --> V2["UE: 绑定到本次 K_AMF"] C --> V3["UE: 对比自己上报能力
若 AMF 回显更窄 → 判定降级攻击"] D --> V4["UE: 校验 ABBA 集
防止 5G↔EPS/UMTS 降级"] E --> V5["UE: 回传 IMEISV"] V1 --> OK{全部通过?} OK -->|是| SC["激活 5G NAS 安全上下文"] OK -->|否| REJ["发送 SECURITY MODE REJECT"] ``` ### 3.1 ngKSI：3 bit 的密钥集"标签" `ngKSI`（5G key set identifier）只有 3 bit，取值 `0~6` 标识 7 个不同的 NAS 密钥集，`7` 表示"当前无可用密钥"。它的作用类似 4G 的 `KSI_ASME`，但 5G 命名为 `ngKSI` 并区分**原生（native）**与**映射（mapped）**安全上下文： - **native 上下文**：由当前接入上的主认证直接产生 `K_AMF`，`t1`（接入类型标识）为当前接入； - **mapped 上下文**：在双注册/互换了接入（如 3GPP↔non-3GPP）时，由另一接入的 `K_AMF'` 派生而来，`t1` 指向源接入。 ngKSI 让 AMF 与 UE 在后续**本地鉴权**（无需再做一次完整主认证）时，能精确定位"用哪一套 NAS 密钥"，是 5G 多接入安全上下文管理的核心。 ### 3.2 Selected NAS Security Algorithms：分别协商完整性 / 加密 5G NAS 安全算法命名如下（TS 33.501 Annex A）： | 类型 | 算法族 | 含义 | |------|--------|------| | 完整性 | NIA0 / 128-NIA1 / 128-NIA2 / 128-NIA3 | null / SNOW 3G / AES / ZUC | | 加密 | NEA0 / 128-NEA1 / 128-NEA2 / 128-NEA3 | null / SNOW 3G / AES / ZUC | | UP 完整性 | UIA0 / 128-NIA1~3 | 复用 NIA 算法族 | | UP 保密 | UEA0 / 128-NEA1~3 | 复用 NEA 算法族 | 一个重要规则：**SMC 选定的 NIA 不能是 NIA0（null 完整性）**——5G 强制要求所有 NAS 控制面消息必须做完整性保护（这是相对 4G 的重要加强）。而 NEA 可以选 NEA0（即不加密），用于某些紧急呼叫或特殊策略场景，但即便如此完整性依然存在。 --- ## 四、设计意图核心：算法协商 + 降级攻击防御 SMC 最精巧的设计，不在算法本身，而在**如何防止攻击者把安全等级"压低"**。5G 通过两条独立机制叠加防御： ### 4.1 Replayed UE Security Capability：防止 bidding-down UE 在**明文**的 Registration Request 中上报自己支持的全部算法（`UE security capability`）。攻击者理论上可以篡改这份明文列表，删掉强算法，迫使 AMF 选到弱算法。SMC 用一条回手破解了它： - AMF 把**自己收到的**那份 UE 能力，原封不动**回显（replay）**在 SMC COMMAND 里； - SMC COMMAND 是**完整性保护**的（有 MAC），攻击者无法篡改； - UE 拿到回显列表后，与自己**真正支持**的能力对比——如果回显列表**更窄**（少了强算法），说明明文段被篡改过，UE 直接判定为降级攻击并拒绝。 这就把"明文能力协商"升级成了"受完整性保护的回显确认"。 ### 4.2 ABBA 参数：防止跨架构降级 `Additional 5G security parameters` 携带的 **ABBA**（Anti-Bidding down Based on Background search / Anti-Bidding down Between Architectures），是 5G 特有的防御手段，4G 不存在。它防止的场景是：攻击者诱导 UE 相信"自己在 5G 网络"，而实际把它桥接/降级到 EPS 或 UMTS，从而利用旧架构的较弱安全。 ABBA 的值是一个集合，目前典型值 `0x0000` 表示"当前为 5GS，使用 5G 安全"。UE 在派生 `K_AMF` 时把 ABBA 作为输入喂给 KDF（密钥派生函数），这意味着：**只要架构判断不同，派生出的密钥就不同，UE 与网络无法对齐，连接必然失败**——从密码学根上杜绝了降级。 ### 4.3 完整性优先的强制策略 下表对比了 4G 与 5G 在 SMC 层面的关键差异，能看出 5G"完整性优先"的演进方向： | 维度 | 4G (EPS) | 5G (5GS) | |------|----------|----------| | 密钥集标识 | KSI_ASME | ngKSI（含接入类型 t1） | | 算法命名 | EEA0~3 / EIA0~3 | NEA0~3 / NIA0~3 + UIA/UEA | | NAS 完整性是否强制 | 否（可 EIA0） | **是（禁 NIA0）** | | 用户面完整性保护 | 不支持 | **支持（UIA）** | | 防降级参数 | 无 | **ABBA** | | NAS 消息最大完整性 | 部分 | 全部控制面（除极少数） | --- ## 五、用户面安全协商：5G 的关键新增能力 SMC 表面上只激活 NAS（控制面）安全，但它承担了一个 5G 才有的重要职责——**把 UE 的用户面安全能力确认下来，并递交给 gNB**。 5G 首次允许对**用户面（Uu 上的 DRB）做完整性保护**，TS 33.501 clause 5.10 定义了 `UIA`（UP integrity）与 `UEA`（UP confidentiality）。这套能力在 UE 侧由 ME（移动设备）支持度决定，流程是： ```mermaid flowchart TD U["UE
支持 UIA/UEA 算法集"] -->|明文上报| R["Registration Request
(UE security capability 含 UIA/UEA)"] R --> AMF["AMF"] AMF -->|SMC COMMAND 回显| U2["UE 确认无降级"] AMF -->|NGAP Initial Context Setup| G["gNB
获得含 UP 的完整能力"] SMF["SMF
(基于订阅的 UP 安全策略)"] -->|"用户面完整性/保密性要求"| UPF["UPF/N4"] G -->|"RRC SMC + DRB 配置"| U3["UE
激活 UP 完整性/加密"] Note1["注：UP 完整性按 DRB 粒度激活，
由 gNB 根据 UE 能力与网络策略决定"]:::note classDef note fill:#fff3cd,stroke:#856404; ``` 需要厘清一个常见误解：**UP 完整性保护的"激活点"在 RRC（gNB↔UE），不在 NAS SMC**。NAS SMC 只负责把"UE 支持哪些 UIA 算法"这个事实确认并通过 NGAP 透传给 gNB。最终 gNB 在 **RRC Security Mode Command**（TS 38.331）中，根据网络策略和 UE 能力，为每个 DRB 决定是否开启 UP 完整性。由于完整性保护对终端处理能力消耗大，标准允许**仅对部分 DRB（如信令/QoS 流）开启**，并非全量。 --- ## 六、安全上下文状态转换 SMC 在 UE 安全状态机中触发的转换可归纳如下： ```mermaid stateDiagram-v2 [*] --> NoContext: UE 开机/注册 NoContext --> PartialAuth: 主认证成功
拥有 K_AMF 但未激活 PartialAuth --> FullNative: SMC COMPLETE 成功
(native ngKSI) FullNative --> FullMapped: 换接入/双注册
(mapped ngKSI) PartialAuth --> NoContext: SMC REJECT / 失败 FullNative --> NoContext: 去注册 note right of FullNative 此时所有 NAS 消息 完整性+加密保护生效 end note ``` 注意 `PartialAuth` 是个逻辑中间态：`K_AMF` 已就绪、算法已选，但**只有 SMC COMPLETE 返回后**，安全上下文才被双方"正式 take into use"——在此之前下行的 NAS 消息（如 Authentication Request 之后、SMC 之前）仍是未保护的。 --- ## 七、实战：抓包识别与故障排错 ### 7.1 在 Wireshark 中如何识别 SMC 用 Wireshark / TShark 抓 NGAP + 5GS-NAS 时，SMC 的辨识要点： 1. **过滤**：`ngap || nas-5gs`，定位到 Registration 流程内； 2. **SECURITY MODE COMMAND**：NAS 消息类型为 `Security mode command (0x5e)`，安全头类型字段标识"完整性保护、不加密"。Wireshark 会尝试用已配置的 `K_AMF` 解 MAC，若成功说明密钥链正确； 3. **SECURITY MODE COMPLETE**：消息类型 `Security mode complete (0x5f)`，安全头为"完整性保护+加密"。若 UE 上报了 IMEISV，可在解码后看到； 4. **次序**：必然位于 Authentication 完成之后、Registration Accept 之前；如果缺失 SMC 直接发了 Registration Accept，说明网络侧采用 null 加密且未强制——属异常。 ### 7.2 常见故障点与排错思路 | 症状 | 可能原因 | 排错方向 | |------|---------|---------| | UE 回 `SECURITY MODE REJECT` (#23) | 选定算法 UE 不支持；replayed 能力被篡改 | 核对 UE 与 AMF 算法优先级配置；抓包看 replayed 与 UE 上报是否一致 | | SMC 后无 COMPLETE，UE 静默 | MAC 校验失败（K_AMF/算法推演不一致） | 检查 USIM、KDF 输入、AMF 版本；用 Wireshark 验 MAC | | 注册失败且伴随 ABBA 相关日志 | ABBA 值不匹配 / 跨架构降级被拒 | 确认 UE 与 AMF 对 5G/EPS 互操作配置一致 | | UP 完整性未生效 | DRB 未开启；UE 能力未透传到 gNB | 检查 NGAP Initial Context Setup 是否含 UIA；SMF 订阅策略 | | 切换后 SMC 失败 | ngKSI 映射上下文出错 | 区分 native/mapped，核对 t1 接入类型 | ## 八、常见问题 **Q1：SECURITY MODE COMMAND 是加密的吗？为什么？** A：不是加密的，仅做完整性保护。因为加密需用选定的 NEA 推演 `K_NAS_enc`，而 UE 尚未确认算法；同时 UE 必须能"看懂"COMMAND 里的算法与 ABBA 才能完成协商。完整性则用选定的 NIA 计 MAC，足以防篡改。第一条真正加密的 NAS 消息是 SECURITY MODE COMPLETE。 **Q2：ngKSI 与 4G 的 KSI 有什么区别？** A：本质都是密钥集标识，但 5G 的 ngKSI 携带接入类型信息（t1），能区分 native（本接入主认证产生）与 mapped（由他接入派生）两种上下文，支撑 3GPP/non-3GPP 双注册下的密钥管理，这是 4G 单接入模型所没有的。 **Q3：为什么 SMC 要 replay UE 的安全能力？** A：UE 在 Registration Request 里以明文上报能力，易被篡改（bidding-down 攻击）。SMC COMMAND 受完整性保护，AMF 回显收到的能力，UE 比对自己真实能力——若 AMF 回显比 UE 实际支持的更窄，即判定为降级攻击而拒绝，把明文协商升级为受保护的确认。 **Q4：UP 完整性保护是在 NAS SMC 里激活的吗？** A：不是。NAS SMC 只确认 UE 支持哪些 UIA 算法并通过 NGAP 透传给 gNB。UP 完整性的真正激活发生在 **RRC Security Mode Command**（gNB↔UE，TS 38.331），按 DRB 粒度开启，受 UE 能力、网络策略与 SMF 订阅数据共同约束。 **Q5：SMC 失败会有什么后果？** A：UE 回 SECURITY MODE REJECT（未保护消息），随后通常会发起去注册或重新尝试。由于安全上下文未建立，UE 无法进入受保护通信，所有后续控制面操作被阻断——这也是为何 SMC 是 5G 接入安全最关键的"门槛过程"。 --- ## 参考来源 1. [3GPP TS 24.501 — Non-Access-Stratum (NAS) protocol for 5GS, clause 5.4 Security mode control procedure](https://www.3gpp.org/dynareport/24501.htm) — SMC 过程、COMMAND/COMPLETE/REJECT 消息与 IE 定义 2. [3GPP TS 33.501 — Security architecture and procedures for 5G System, clause 5.9 / 5.4 / 5.10](https://www.3gpp.org/dynareport/33501.htm) — NAS SMC 安全依据、密钥派生、用户面安全 3. [3glteinfo — 5G NAS Security Mode Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g-security-mode-command/) — SMC 信令流程与保护行为图解 4. [ShareTechnote — 5G Security](https://www.sharetechnote.com/html/5G/5G_Security.html) — NAS SMC 在 5G 加密激活中的角色说明 5. [Amarisoft Tech Academy — NR U-plane Integrity](https://tech-academy.amarisoft.com/NR_Uplane_Integrity.html) — 5G 用户面完整性保护特性与按需开启机制 6. [3GPP TS 38.331 — NR RRC, AS security activation](https://www.3gpp.org/dynareport/38331.htm) — RRC Security Mode Command 与 UP 完整性激活 --- > 本文由「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 等场景全覆盖。