# 5G 安全模式命令（SMC）信令全链拆解：从鉴权结果到接入安全激活 ## 一、SMC 是 5G 接入安全的"分水岭" 在 5G 系统中，主鉴权（5G AKA / EAP-AKA'）成功之后，USIM 与 ARPF/UDM 之间虽然协商出了根密钥 `K` 派生的 `KAUSF → KSEAF`，但这只是"双方都拿到了正确的密钥材料"，并不意味着空口上的信令已经受到保护。把"鉴权结果"真正落地为"可用的、激活的、被算法保护的安全上下文"，靠的就是 **Security Mode Command（SMC，安全模式命令）** 这条消息。 SMC 在 5G 接入安全链路中承担三个不可替代的职责： 1. **算法协商**：网络（AMF）从 UE 上报的安全能力中"选定"一套 NAS 加密算法（NEA）和 NAS 完整性算法（NIA），并把选定的算法下发给 UE； 2. **上下文激活**：触发 UE 与 AMF 把刚派生的 `KAMF` 转换为 NAS 层实际使用的 `KNASenc / KNASint`，并开始对 N1 信令进行完整性保护与加密； 3. **降级攻击防护**：通过"回放 UE 安全能力"机制，让 UE 校验网络看到的自身能力与自己实际发送的是否一致，从协议层杜绝伪基站剔除强算法的 bidding-down 攻击。 需要特别强调：5G 存在**两个独立的 SecurityModeCommand**——一个工作在 NAS 层（TS 24.501 §5.4.2，AMF↔UE），另一个工作在 AS/RRC 层（TS 38.331，gNB↔UE）。两者保护对象、触发时机、密钥来源都不同，但共同构成了从核心网到空口的完整安全握手。本文以 **NAS SMC** 为核心主线进行全链拆解，并衔接 **AS SecurityModeCommand** 完成端到端视图。 ## 二、SMC 在安全建立链路中的位置（端到端时序） 下图为一次初始注册中，从主鉴权完成到 AS 安全激活的完整信令链。NAS SMC 与 AS SecurityModeCommand 一前一后，构成"双层安全激活"。 ```mermaid sequenceDiagram participant UE participant gNB participant AMF participant UDM/ARPF as UDM/ARPF UE->>gNB: RRC Setup Request (SRB0, 明文) gNB->>UE: RRC Setup (建立 SRB1, 明文) UE->>gNB: RRC Setup Complete (承载 Registration Request, 明文) gNB->>AMF: INITIAL UE MESSAGE (携带 Registration Request) Note over UE,UDM/ARPF: 主鉴权 5G AKA / EAP-AKA' AMF->>UDM/ARPF: Authentication 流程 UDM/ARPF-->>AMF: AV (含 XRES*/HXRES*, KAUSF) AMF->>UE: Authentication Request (RAND, AUTN) UE-->>AMF: Authentication Response (RES*) Note over AMF: 派生 KSEAF → KAMF (锚定密钥) Note over AMF: 选择 NAS 算法, 派生 KNASenc/KNASint AMF->>UE: SECURITY MODE COMMAND (完整性保护, 不加密) Note right of AMF: 携带: 选定NAS算法 / 回放UE安全能力 / ngKSI / IMEISV请求 UE->>UE: 校验回放能力==自身能力, 派生密钥, 完整性校验 UE-->>AMF: SECURITY MODE COMPLETE (完整性+加密, 可携带 IMEISV) Note over AMF,gNB: NAS 安全激活完成, 进入 AS 安全激活 AMF->>gNB: INITIAL CONTEXT SETUP REQUEST Note right of AMF: 携带: Kng-ran / NCC / UE安全能力 / 允许算法列表 Note over gNB: 派生 KRRCenc/KRRCint/KUPenc/KUPint gNB->>UE: SecurityModeCommand (RRC, 完整性保护) Note right of gNB: 携带: securityAlgorithmConfig (加密+完整性算法) UE-->>gNB: SecurityModeComplete (RRC, 完整性保护) gNB->>UE: RRC Reconfiguration (加密+完整性, 建立 SRB2/DRB) UE-->>gNB: RRC Reconfiguration Complete AMF->>UE: Registration Accept (经 NAS 加密+完整性) ``` 可以看到，**NAS SMC 是整个空口安全的真正起点**：在它之前，所有 NAS 消息（包括承载鉴权响应的关键消息）都是明文；在它之后，N1 信令开始具备机密性与完整性。而 AS SecurityModeCommand 紧随其后，把保护范围从"NAS 信令"扩展到"RRC 信令 + 用户面"。 ## 三、NAS SECURITY MODE COMMAND 消息 IE 逐项拆解 NAS SMC 的消息结构定义在 TS 24.501 §8.2.25（SECURITY MODE COMMAND）、§8.2.26（COMPLETE）、§8.2.27（REJECT）。下表逐项解析 SMC 消息中的关键 IE： | Information Element（IE） | 是否必选 | 作用与设计意图 | |---|---|---| | **Extended protocol discriminator** | M | 标识 5GMM 协议，值为 7E（5GS Mobility Management） | | **Security header type** | M | 标识本消息的安全头类型。SMC 虽不加密，但携带完整性保护 MAC，故头类型为"完整性保护且加密"（0x4），实际净荷以 null cipher 体现 | | **Security protected NAS message** | M | 承载被完整性保护的 5GMM 净荷 | | **Selected NAS security algorithms** | M（在净荷内） | 网络为本次上下文选定的 NAS 加密算法（NEA0~3）与完整性算法（NIA0~3），各占 4 bit | | **ngKSI** | M | 5G NAS 密钥集标识，标识本 SMC 激活的是哪一套密钥。0~6 为本机上下文，7 表示无可用密钥 | | **Replayed UE security capabilities** | M | AMF 把它从 UE 处收到的安全能力（5G NAS 加密/完整性算法列表，EPS NAS 算法，可选 additional 5G NAS）原样回放给 UE，供 UE 反向校验 | | **IMEISV request** | O | 若置位，请求 UE 在 COMPLETE 中回传 IMEISV（设备软硬件版本标识），用于设备识别与黑白名单 | | **Additional 5G security information** | O | 携带辅助安全指示位（如初始 NAS 消息重传指示等） | | **Message authentication code (MAC)** | M | 由 KNASint + 下行 NAS COUNT + 选定 NIA 算法计算所得，是完整性保护的核心证据 | **关键设计意图——"完整性优先"**：根据 TS 24.501 §4.4.2.5，AMF 在发送 SMC **之前**必须先激活 NAS 完整性保护（即先用 `KNASint` 算出 MAC），但 SMC 本身**不加密**。原因很直观——SMC 正是用来告诉 UE"接下来用什么加密算法"的，UE 此刻还无法解密任何加密内容，因此 SMC 必须以明文净荷+完整性 MAC 的形式发出。这也意味着 **SECURITY MODE COMPLETE 是第一条真正被加密的 NAS 上行消息**。 ## 四、算法协商与降级攻击防护 算法协商看似只是"网络挑一套算法"，实则是 5G 抵御伪基站降级攻击的核心防线。整个逻辑如下图： ```mermaid flowchart TD A["UE 在初始 NAS 消息中上报
UE security capabilities
(NEA0-3, NIA0-3 等)"] --> B["AMF 保存 UE 能力集合"] B --> C{"AMF 按本地优先级
在 UE 能力 ∩ 网络允许集
内选最强算法"} C --> D["AMF 派生 KNASenc / KNASint
(TS 33.501 Annex A.7)"] D --> E["SECURITY MODE COMMAND
回放 UE security capabilities
+ 选定算法"] E --> F{"UE 校验: 回放能力 == 自身能力?"} F -->|不一致| G["判定降级/篡改攻击
发送 SECURITY MODE REJECT"] F -->|一致| H["UE 校验 MAC
(完整性验证)"] H -->|MAC 失败| I["丢弃 SMC, 不激活"] H -->|MAC 通过| J["派生 NAS 密钥
激活完整性+加密
发送 COMPLETE"] ``` **为什么"回放 UE 安全能力"能防降级？** 攻击场景是：伪基站在 UE 上报能力的中转链路上**剔除**强算法（如 NEA3），只把弱算法（NEA0）透传给真网络，诱导网络为 UE 选定弱算法。5G 的对策是——网络在 SMC 中**原样回放**它收到的 UE 能力集合。UE 收到后与自己**实际发送**的能力比对：若发现"我以为我支持 NEA3，但网络回放的能力里没有"，即可判定中途被篡改，立即发送 REJECT 终止流程。这一"双向确认"使得攻击者无法在不被察觉的情况下剥离强算法。 **密钥派生（聚焦 NAS 密钥）**：NAS 加密/完整性密钥并非 `KAMF` 本身，而是由 `KAMF` 经 KDF 派生。派生输入区分算法用途（TS 33.501 Annex A.7）： | 派生目标密钥 | 算法类型区分值（P0） | 第二输入 | 用途 | |---|---|---|---| | `KNASenc`（NAS 加密密钥） | 0x01（NAS enc） | 选定 NEA 算法标识 | N1 信令机密性 | | `KNASint`（NAS 完整性密钥） | 0x02（NAS int） | 选定 NIA 算法标识 | N1 信令完整性 | | `KRRCenc`（RRC 加密密钥） | 0x03（RRC enc） | NEA 算法标识 | RRC 信令机密性 | | `KRRCint`（RRC 完整性密钥） | 0x04（RRC int） | NIA 算法标识 | RRC 信令完整性 | | `KUPenc`（UP 加密密钥） | 0x05（UP enc） | NEA 算法标识 | 用户面数据机密性 | | `KUPint`（UP 完整性密钥） | 0x06（UP int） | NIA 算法标识 | 用户面数据完整性 | 派生函数统一为 TS 33.220 定义的 3GPP KDF（`FC=0x69`）。这种"一份锚定密钥 + 算法区分值"的设计，既保证不同用途密钥相互隔离（即便一个泄露不影响其他），又避免了为每种算法单独维护根密钥的开销。 ## 五、UE 侧接收 SMC 的验证逻辑与状态转换 UE 收到 SECURITY MODE COMMAND 后并不是无条件接受，而是要执行一套严格的校验链。下图描述 UE 5GMM 安全上下文的状态转换与判定逻辑： ```text stateDiagram-v2 [*] --> 无安全上下文: 初始注册/无密钥 无安全上下文 --> 校验中: 收到 SMC 校验中 --> 无安全上下文: 回放能力不一致 → REJECT 校验中 --> 无安全上下文: MAC 校验失败 → 丢弃 校验中 --> 部分安全_仅完整性: 接受SMC, 激活KNASint 部分安全_仅完整性 --> 完整安全: 发送COMPLETE, 激活KNASenc加密 完整安全 --> 完整安全: 后续NAS消息: 完整性+加密 完整安全 --> 无安全上下文: 去注册/安全上下文失效 完整安全 --> 校验中: 重新NAS SMC(算法变更/AMF切换) ``` **SECURITY MODE REJECT 的常见原因值**（TS 24.501 §9.5）：#5 `Semantically incorrect message`（语义错误，常因回放能力校验失败触发）、#23 `Security mode rejected, unspecified`（不支持所选算法）、#24 `Non-5G authentication unacceptable`。出现 REJECT 即意味着本次安全激活失败，网络通常回退至发起去注册或重新鉴权。 值得注意的是**"SMC 必须是第一条被保护的 NAS 消息"原则**：除初始 REGISTRATION REQUEST、IDENTITY RESPONSE 等少数明文消息外，UE 若在收到 SMC **之前**收到其它需要保护却未保护的 NAS 消息，应视为异常并拒绝。这一约束确保安全上下文在任何业务信令之前先建立到位。 ## 六、接入层（AS）安全激活：RRC SecurityModeCommand NAS 安全激活完成后，AMF 通过 NGAP **INITIAL CONTEXT SETUP REQUEST**（TS 38.413）把 AS 安全材料交给 gNB：包括 `Kng-ran`、`Next Hop Chaining Count (NCC)`、UE 安全能力、以及网络允许的算法列表。gNB 据此派生 AS 密钥，并发起 **RRC SecurityModeCommand**（TS 38.331）激活 AS 安全。 下表对比 NAS SMC 与 AS SecurityModeCommand，帮助厘清两者边界： | 维度 | NAS Security Mode Command | AS (RRC) SecurityModeCommand | |---|---|---| | **规范** | TS 24.501 §5.4.2 / TS 33.501 §6.7 | TS 38.331 / TS 33.501 §6.6 | | **信令端点** | UE ↔ AMF（N1 接口） | UE ↔ gNB（Uu 接口） | | **保护对象** | NAS（N1）信令 | RRC 信令 + 用户面（UP）数据 | | **密钥来源** | AMF 从 KSEAF 派生 KAMF → KNASenc/int | gNB 从 AMF 下发的 Kng-ran 派生 KRRC/UP | | **携带算法** | Selected NAS security algorithms | securityAlgorithmConfig（cipheringAlgorithm + integrityProtAlgorithm） | | **激活顺序** | 完整性优先，COMPLETE 启加密 | RRC 完整性优先激活，加密随后 | | **典型时序** | 注册流程中，鉴权后立即发起 | 初始上下文建立阶段，NAS SMC 之后 | **AS 安全激活的关键设计点**： 1. **完整性保护先于加密**：与 NAS 类似，gNB 先激活 RRC 完整性保护（用 `KRRCint`），SecurityModeCommand 本身即被完整性保护；UE 回复 SecurityModeComplete 后，加密（`KRRCenc`）与用户面保护（`KUPenc / KUPint`）才全面启用。5G 用户面**默认开启完整性保护**（这是相较 4G 的重要增强，4G 用户面仅有加密无完整性）。 2. **密钥更新（Key Refresh）与 NCC**：gNB 通过 `MasterKeyUpdate`（含 NCC）触发 AS 密钥前向更新，NCC 每次切换/更新递增，使旧密钥无法回溯，满足前向安全。 3. **算法选择受网络约束**：gNB 选定的 AS 算法必须落在 AMF 在 NGAP 中下发的"允许算法列表"内，与 UE 安全能力取交集，同样具备反降级能力。 ## 七、实战：抓包识别与故障排查 **1. 抓包如何识别 SMC 流程** 在 Wireshark/TShark 中（3GPP NGAP/5G-NAS/RRC 协议树）： - **NAS SMC**：在 N1 信令中查找 `Security Mode Command` / `Security Mode Complete`（5GMM）。展开 SMC，重点检查 `Selected NAS security algorithms`（如 `128-NEA2`/`128-NIA2`）、`Replayed UE security capabilities`、`ngKSI` 字段；COMPLETE 中检查是否回传了 `IMEISV`。 - **AS SecurityModeCommand**：在 SRB1（DCCH）RRC 消息中查找 `securityModeCommand`，确认 `securityAlgorithmConfig` 中的 `cipheringAlgorithm` 与 `integrityProtAlgorithm`。 - **NGAP**：检查 `INITIAL CONTEXT SETUP REQUEST` 中的 `Security key`、`Next Hop Chaining Count`、`UESecurityCapabilities`、`SecurityAlgorithm` 字段是否下发。 **2. 常见故障点** - **SMC 后立即收到 REJECT（#5）**：九成是"回放 UE 安全能力"与 UE 实际能力不符。排错方向——核查 AMF 是否完整透传了 UE 上报的 NEA/NIA 能力位（尤其 additional 5G NAS 能力），是否存在中间网元裁剪能力位；核查 UE USIM/ME 能力是否正确声明。 - **MAC 校验失败导致 SMC 丢弃**：通常是 `KAMF` 派生不一致。根因多在鉴权——`KAUSF/KSEAF` 计算输入（如 SQN、SUPI/serving network name）两侧不匹配，或 RES* 验证虽过但派生 KAMF 时的 SUPI 绑定出错。 - **算法被选成 NEA0/NIA0**：需排查是否为紧急业务（紧急注册允许 NIA0 完整性，但 NEA0 加密仅在特定场景），还是被网络配置成了弱算法——后者在生产网属安全合规风险。 - **AS SecurityModeFailure**：gNB 下发算法 UE 不支持，或 `Kng-ran` 派生出错。排查 NGAP 下发材料与 UE AS 安全能力是否一致。 ## 常见问题 **Q1：NAS SMC 和 AS SecurityModeCommand 是同一条消息吗？** A：不是。它们是分属两层的独立消息：NAS SMC（TS 24.501）工作在 UE↔AMF，激活 NAS 信令安全；AS SecurityModeCommand（TS 38.331）工作在 UE↔gNB，激活 RRC 与用户面安全。两者时序上前后衔接，但密钥来源、保护对象、协议层都不同。 **Q2：为什么 SECURITY MODE COMMAND 不加密却要做完整性保护？** A：因为 SMC 正是向 UE 通告"选定加密算法"的载体，UE 此时还不知道算法、无法解密，所以净荷必须明文；但若不做完整性保护，攻击者可篡改算法字段诱导降级。因此用 `KNASint` 计算 MAC 做完整性保护，既保证可读又防篡改——这正是"完整性优先"原则的体现。 **Q3：NEA0（空加密）什么时候会被合法使用？** A：正常商用业务不应使用 NEA0。仅在紧急呼叫注册等特定场景下，网络可允许 NIA0（空完整性，不推荐）或不加密，以保证 UE 在无有效 USIM/鉴权失败时仍能拨打紧急呼叫。生产网中出现非紧急业务的 NEA0 属安全配置缺陷。 **Q4：5G 的"回放 UE 安全能力"防降级，为什么比 4G 更强？** A：4G 在 SMC 中也有类似回放，但 5G 的安全能力集合更完整（区分 5G NAS / EPS NAS / additional 5G NAS），且 5G 强制 UE 校验，配合 SUCI 身份隐私保护、用户面完整性保护等机制，整体上把伪基站的攻击面显著压缩。任何能力位的不一致都会触发 REJECT，使降级攻击"必被发现"。 **Q5：SMC 失败后网络一般如何处理？** A：UE 发 SECURITY MODE REJECT 后，安全上下文建立失败。AMF 通常会：释放 NAS 连接、触发去注册，并在统计上记一次安全激活失败；若反复失败，可能进入重新主鉴权流程或拒绝该 UE 接入（取决于失败原因值与运营商策略）。 ## 参考来源 1. [3GPP TS 24.501 V18.8.0 — Non-Access-Stratum (NAS) protocol for 5GS; Stage 3](https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/18.08.00_60/ts_124501v180800p.pdf) — §5.4.2 Security mode control procedure, §4.4.2.5/§4.4.5/§4.4.6 NAS 安全保护, §8.2.25 SMC 消息 2. [3GPP TS 33.501 — Security architecture and procedures for 5G System](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169) — §6.6 AS security, §6.7 NAS security, Annex A 密钥派生函数（含算法区分值 0x01~0x06） 3. [3GPP TS 38.331 V18.6.0 — NR; Radio Resource Control (RRC)](https://www.etsi.org/deliver/etsi_ts/138300_138399/138331/18.06.00_60/ts_138331v180600p.pdf) — SecurityModeCommand / securityConfig / securityAlgorithmConfig IE 4. [ShareTechnote — 5G Registration & NAS Security](https://www.sharetechnote.com/html/5G/5G_Registration.html) — NAS 安全模式建立与 IMEISV 处理流程解读 5. [3glteinfo — 5G NAS Security Mode Procedure Call Flow & NR RRC SecurityModeCommand](https://www.3glteinfo.com/call-flows/5g-security-mode-command/) — NAS/AS 安全模式命令消息字段与信令流分析 6. [Devopedia — 5G Security](https://devopedia.org/5g-security) — 5G NAS 安全上下文（KAMF、ngKSI、UE 安全能力、NAS COUNT）综述 --- > 本文由「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 等场景全覆盖。