很多工程师对 5G 安全的第一印象停留在"5G AKA 认证完成、KAMF 算出来就安全了"。这是一个危险的误解。认证流程（TS 33.501 Section 6.1）只是让网络与 UE 共享了一个根密钥 KAMF，并互相确认了身份；但此时空口的 NAS 信令、RRC 信令、用户面数据全部仍是明文、未完整性保护的裸奔状态。从"握有一把钥匙"到"真正把门锁上"，中间还差两个关键动作——NAS 安全模式命令（NAS SMC） 与 AS 安全模式命令（AS SMC）。
这正是本文聚焦的核心机制。它定义在 3GPP TS 33.501（5G 安全架构）Section 6.6 / 6.7、TS 24.501（5GMM）Section 5.4.2、TS 38.331（NR RRC）Section 5.3.4 三份规范里。理解双层 SMC，本质上是理解 5G 安全上下文如何被"激活"、算法如何协商、密钥如何分层推演、以及规范如何用一招"回放 UE 安全能力"来抵御降级攻击。
本文将按"触发时机 → NAS 层握手 → AS 层握手 → 密钥推演 → 防降级 → 抓包识别 → 排错"的顺序，把这条安全激活链路完整拆开。
5G 的安全在协议栈上被刻意拆成两层，分别由不同的网络功能激活：
| 维度 | NAS SMC | AS SMC |
|---|---|---|
| 规范定位 | TS 33.501 §6.7.2 / TS 24.501 §5.4.2 | TS 33.501 §6.6 / TS 38.331 §5.3.4 |
| 信令发起方 | AMF（核心网） | gNB（接入网） |
| 保护对象 | UE↔AMF 的 NAS 信令 | UE↔gNB 的 RRC 信令 + 用户面数据 |
| 依赖输入密钥 | KAMF | KgNB（由 KAMF 推演） |
| 激活的密钥 | KNASint、KNASenc | KRRCint、KRRCenc、KUPint、KUPenc |
| 触发时机 | 鉴权成功后；或切换/重激活场景 | AMF 下发 Initial Context Setup 后 |
这种"NAS 安全由 AMF、AS 安全由 gNB 各自激活"的分工，是 5G 相对 4G 的重要演进：4G 中 MME 与 eNB 同样分层，但 5G 进一步强化了"AS 安全必须在 NAS 安全建立之后才激活"的时序约束，从而把空口密钥与核心网安全状态绑定，提升整条链路的抗攻击能力。
在初始注册场景中，双层 SMC 的位置非常固定。下表给出 TS 23.502 Section 4.2.2.2（注册流程）中安全相关步骤的真实排布：
flowchart TD
A["1. Registration Request<br/>(UE→AMF, 无保护)"] --> B["2. 5G AKA 鉴权<br/>(产生 KSEAF → AMF 推 KAMF)"]
B --> C["3. NAS Security Mode Command<br/>(AMF→UE, 完整性保护, 不加密)"]
C --> D["4. NAS Security Mode Complete<br/>(UE→AMF, 完整性+加密)"]
D --> E["5. Initial Context Setup Request<br/>(AMF→gNB, 携带 UE 安全能力+KAMF)"]
E --> F["6. AS Security Mode Command<br/>(gNB→UE, RRC 完整性保护, 不加密)"]
F --> G["7. AS Security Mode Complete<br/>(UE→gNB, RRC 完整性保护)"]
G --> H["8. Registration Accept<br/>(AMF→UE, NAS 加密, 经已加密 RRC 传输)"]
注意一个关键约束：AS 安全绝不会先于 NAS 安全激活。AMF 必须先与 UE 完成 NAS SMC，确认 NAS 层已上锁，才会触发 Initial Context Setup 把安全上下文交给 gNB。这条时序是 TS 33.501 §6.1.1 强制要求的，目的是避免"空口已加密但核心网认证未完成"这种半安全状态被攻击者利用。
sequenceDiagram
participant UE
participant AMF
Note over UE,AMF: 前置：5G AKA 已完成，双方持有 KAMF<br/>ngKSI = 5G key set identifier
AMF->>UE: 算法选择（依据 UE 安全能力 + 网络配置优先级）
Note over AMF: 由 KAMF 经 KDF 推 KNASint / KNASenc
AMF->>UE: NAS Security Mode Command
Note right of AMF: IE: ngKSI, Selected NAS Security Algorithms,<br/>Replayed UE Security Capability,<br/>Additional 5G Security Info,<br/>(IMEISV Request)<br/>本条消息：用 KNASint 完整性保护，不加密
UE->>UE: 校验完整性<br/>校验回放能力是否匹配<br/>校验所选算法是否在能力内
alt 校验通过
UE->>UE: 推 KNASint / KNASenc，挂载安全上下文
UE->>AMF: NAS Security Mode Complete
Note left of UE: 首条 加密+完整性 保护的上行 NAS<br/>(可携带 IMEISV)
else 校验失败
UE->>AMF: NAS Security Mode Reject
Note left of UE: 进入 MM-DEREGISTERED，安全上下文作废
end
| IE 名称 | 所在消息 | 作用 | 取值/备注 |
|---|---|---|---|
| ngKSI | SMC | 指明本次安全上下文对应的 KAMF（native 或 mapped） | 0~6（值 7 保留） |
| Selected NAS Security Algorithms | SMC | 选定的 NAS 完整性 + 加密算法 | 如 NIA2/NEA2 |
| Replayed UE Security Capability | SMC | 把 UE 在 Registration Request 中上报的安全能力原样回放 | 5GS + E-UTRA + 其他接入能力全集 |
| Additional 5G Security Information | SMC | UE 应额外允许的算法集（防降级补强） | 可选 |
| IMEISV Request | SMC | 请求 UE 在 Complete 中返回 IMEISV | 可选 |
| IMEISV | Complete | 终端全球唯一标识（含软件版本） | 受加密保护 |
这是整个 NAS SMC 设计中最值得玩味的一笔。UE 在 Registration Request 里上报自己的安全能力时，那条消息是没有任何保护的——攻击者完全可以做中间人，把 UE 支持的强算法（如 NEA3）篡改成"只支持 NEA0 空算法"，诱骗 AMF 选择弱算法。
规范给出的解法是：AMF 在已被完整性保护的 SMC 消息里，把 UE 当初上报的安全能力原样"回放"回去。UE 收到 SMC 后，会把"回放的能力"与"自己真正上报的能力"逐比特比对。一旦不一致，UE 立刻判定遭到篡改，发起 Reject。由于 SMC 本身有 KNASint 完整性保护，攻击者无法再篡改这条回放内容——降级攻击的窗口由此被关死。
这是一个反复被问倒工程师的细节：NAS SMC 用了完整性保护，但没有加密。原因很直观——这条消息里携带的是"UE 接下来要用哪个加密算法"。如果连这条消息本身都加密，UE 还没算出 KNASenc、还没确定算法，根本无从解密，会陷入鸡生蛋的死循环。所以规范规定 SMC 只完整性保护、不加密；而紧接着的 Security Mode Complete 才是第一条"加密 + 完整性"双重保护的上行 NAS 消息。
flowchart LR
subgraph SMC下行["NAS SMC（下行）"]
A1["完整性保护: ON (KNASint + NIAx)"] --- A2["加密: OFF"]
end
SMC下行 --> Complete上行
subgraph Complete上行["NAS Security Mode Complete（上行）"]
B1["完整性保护: ON"] --- B2["加密: ON (KNASenc + NEAx)"]
end
Complete上行 --> 后续
subgraph 后续["后续所有 NAS 信令"]
C1["完整性 + 加密 全程开启"]
end
AS SMC 的触发来自 AMF 下发的 Initial Context Setup Request（N2 消息）。这条请求里，AMF 会把两样东西交给 gNB：UE Security Capability（UE 支持的算法集）和 KAMF（核心网根密钥的 AS 端入口）。gNB 拿到 KAMF 后，先推演出 KgNB，再独立完成 AS 算法选择与激活。
sequenceDiagram
participant UE
participant gNB
participant AMF
AMF->>gNB: Initial Context Setup Request<br/>(携带 UE Security Capability + KAMF)
Note over gNB: KgNB = KDF(KAMF, 上行 NAS COUNT)<br/>选定 AS 算法 → 推 KRRCint/enc, KUPint/enc
gNB->>UE: RRC Security Mode Command (TS 38.331)
Note right of gNB: IE: securityConfig → securityAlgorithmConfig<br/>本条: RRC 完整性保护(KRRCint), 不加密
UE->>UE: 校验完整性<br/>校验算法是否在能力内<br/>校验所选算法 >= NAS 已选算法(防降级)
UE->>UE: 推 AS 各密钥, 激活 RRC 完整性+加密、UP 完整性+加密
UE->>gNB: RRC Security Mode Complete
Note left of UE: 完整性保护, 不加密
Note over gNB,UE: 此后 RRC 与用户面进入 完整性+加密 全保护状态
约束一：RRC 信令完整性保护永远开启。TS 33.501 §6.6.1.1 明确规定，NR 的 RRC 信令不允许使用空完整性算法（NIA0）。这与 NAS 层允许在"未认证紧急呼叫"时使用 NEA0/NIA0 形成鲜明对比——接入网层面不留这个口子。
约束二：用户面完整性保护必须被支持。这是 5G 相对 4G 的重大安全增强。4G 时代用户面只有加密、无完整性，导致"篡改用户面数据"成为现实威胁。NR 强制要求终端与网络都支持 KUPint，在多数商用配置中 UP 完整性默认开启，从而堵上了空口用户面篡改的漏洞。
约束三：AS SMC 同样只完整性保护、不加密。原理与 NAS SMC 一致：消息里携带算法选择，必须让 UE 明文读到。
flowchart TD
K["K (USIM 永久根密钥)"] --> KA["5G AKA / EAP-AKA'"]
KA --> KSEAF["KSEAF<br/>(AUSF→SEAF, TS 33.501 A.5)"]
KSEAF --> KAMF["KAMF<br/>(SEAF→AMF, A.6, FC=0x6C)"]
KAMF -->|"FC=0x69, dist=0x16"| KNI["KNASint (NIA)"]
KAMF -->|"FC=0x69, dist=0x15"| KNE["KNASenc (NEA)"]
KAMF -->|"FC=0x6E, 输入=上行NAS_COUNT"| KgNB["KgNB (A.6)"]
KgNB -->|"FC=0x69, dist=0x18"| KRI["KRRCint"]
KgNB -->|"FC=0x69, dist=0x17"| KRE["KRRCenc"]
KgNB -->|"FC=0x69, dist=0x1A"| KUI["KUPint"]
KgNB -->|"FC=0x69, dist=0x19"| KUE["KUPenc"]
5G 所有密钥推演都基于同一个 HMAC-SHA-256 框架：
Key = HMAC-SHA-256( Key_in , S )
S = FC || L0 || P0 || L1 || P1 || ... || Ln || Pn
其中 FC 是函数码（1 字节），Pi 是输入参数，Li 是 Pi 的长度（2 字节大端）。双层 SMC 相关的两个关键 FC：
FC=0x6E（推 KgNB）：S = 0x6E || len || 上行 NAS COUNT。这里把"上行 NAS COUNT"作为输入，是 5G 的一招妙手——它把 KgNB 与 NAS 的状态机绑定。每次 NAS SMC 后上行 NAS COUNT 会推进，从而保证每次激活都会产生全新的 KgNB，杜绝密钥重用。
FC=0x69（算法密钥推演，TS 33.501 Annex A.7）：S = 0x69 || 0x00 0x01 || dist || 0x00 0x01 || alg_id。其中算法密钥区分符 dist 取值如下表：
| dist 值 | 推演目标 | 父密钥 |
|---|---|---|
| 0x15 | KNASenc | KAMF |
| 0x16 | KNASint | KAMF |
| 0x17 | KRRCenc | KgNB |
| 0x18 | KRRCint | KgNB |
| 0x19 | KUPenc | KgNB |
| 0x1A | KUPint | KgNB |
算法标识 alg_id 中，128-NEA1=1、128-NEA2=2、128-NEA3=3、128-NIA1=1、128-NIA2=2、128-NIA3=3；NEA0/NIA0=0 为空算法。
无论是 AMF 选 NAS 算法，还是 gNB 选 AS 算法，遵循同一套规则（TS 33.501 §6.7.3）：
商用网络最常见组合是 128-NEA2（基于 AES）+ 128-NIA2，因其性能与安全兼顾、且有硬件加速支持；高安全场景会叠加 128-NEA3（基于 ZUC）。
5G 在双层 SMC 中布下了三道互相印证的闸门，使中间人降级攻击极难得手：
| 闸门 | 机制 | 作用 |
|---|---|---|
| 闸门 1 | NAS SMC 内回放 UE 安全能力 | 检测 Registration Request 阶段的能力篡改 |
| 闸门 2 | AS 所选算法不得弱于 NAS 所选算法 | UE 校验，防止接入网被降级到弱算法 |
| 闸门 3 | UP 完整性保护强制支持 | 防止用户面数据被静默篡改 |
其中闸门 2 是一个常被忽略的细节：UE 在校验 AS SMC 时，会比较 gNB 选的 AS 算法强度与此前 NAS 已激活的算法强度。若发现"NAS 用 NEA2、AS 却被降到 NEA0"，UE 有理由怀疑接入网链路被劫持，可据此拒绝。这条逻辑把 NAS 与 AS 的安全等级耦合起来，大幅压缩了攻击面。
实战中，工程师最常在 NGAP/NAS/RRC 联合抓包里定位安全激活。关键判据：
Message type = Security mode command (0x5D) 与 Security mode complete (0x5E)。SMC 消息会展开 Selected NAS security algorithms、Replayed UE security capability、Additional 5G security information 等字段。ngKSI，结合鉴权流程可判断用的是 native 还是 mapped 安全上下文。securityModeCommand（消息名 SecurityModeCommand），其内含 securityConfig → securityAlgorithmConfig，给出 gNB 选定的完整性/加密算法。Ciphered 或无法解析明文（若无 KAMF/KgNB 注入）；若注入了密钥（商用抓包工具支持配置 K 值），可还原明文。这是判断"AS 安全是否真正激活"最直观的方式——SMC Complete 之后报文开始被加密，即说明 AS 握手成功。Initial Context Setup Request 中展开 UE Security Capability 与 Security Key（即 KAMF），可确认核心网是否正确下发密钥。一个快速排错口诀：鉴权过、NAS SMC 过、却卡在 AS SMC → 优先查 gNB 是否收到 KAMF、UE 安全能力是否被正确传递；NAS SMC 都没到 → 回头看鉴权链路或 AMF 算法配置。
| 故障现象 | 根因方向 | 排错动作 |
|---|---|---|
| UE 回 NAS Security Mode Reject | 回放能力不匹配；或所选算法 UE 不支持 | 核对 UE 上报能力、AMF 算法配置、排除中间人篡改 |
| 卡在 AS SMC，RRC 不 Complete | gNB 未收到 KAMF/UE 安全能力；算法交集为空 | 查 NGAP Initial Context Setup 字段；查 gNB 算法许可列表 |
| SMC 后仍可明文看到后续 NAS | 加密实际未生效（NEA0 误配） | 检查是否误启用空算法；紧急呼叫外禁用 NEA0/NIA0 |
| 切换后掉话/鉴权异常 | KgNB 未随上行 NAS COUNT 刷新，密钥重用 | 核对 NAS SMC 触发与 key refresh 流程 |
| IMEISV 一直收不到 | SMC 未带 IMEISV Request，或 UE 拒绝 | 确认 AMF 策略与 UE 实现是否支持 IMEISV 上报 |
某局点曾出现"抓包看到 NAS SMC 成功，但后续信令仍明文"。排查发现 AMF 在非紧急场景误配了 NEA0，导致名义上握手成功、实际未加密。这是闸门 1/2 失守的典型——既未触发 UE 拒绝（因 UE 也声明支持 NEA0），又失去保护。修复：AMF 侧将 NEA0/NIA0 限定为仅紧急呼叫可用，强制商用流程选 NEA2 及以上。
Q1：NAS SMC 与 AS SMC 为什么必须分开、不能合并成一条？ A：因为两层由不同的网络功能负责、保护不同的协议栈：NAS 层由 AMF 端到端保护 UE↔AMF 信令，AS 层由 gNB 保护 UE↔gNB 的 RRC 与用户面。二者密钥链路不同（KAMF vs KgNB）、生命周期不同（NAS 安全跨 gNB 切换保持，AS 安全随 gNB 变化而刷新）。合并会破坏这种分层解耦，也会让"AS 弱于 NAS"的防降级校验失去意义。
Q2：为什么 NAS SMC 消息只完整性保护、不加密？ A：因为消息里携带"选定加密算法"和"回放的安全能力"，UE 必须先明文读到这些信息，才能算出 KNASenc 并完成校验。若对 SMC 加密，UE 会陷入"无算法无法解密、无解密无法获知算法"的循环。规范把"加密生效"推迟到第一条上行 NAS Security Mode Complete。
Q3：NEA0/NIA0 空算法在 5G 里还有用吗？ A：有，但被严格限定。它仅允许用于"未认证的紧急呼叫"，使未插卡或鉴权失败的终端也能拨打紧急电话。除此以外的商用流程严禁使用，否则会触发降级风险。NR 的 RRC 层面更是完全禁止 NIA0，RRC 完整性永远开启。
Q4：KgNB 推演为什么要带"上行 NAS COUNT"？ A：为了把 AS 密钥与 NAS 状态机绑定，保证每次 NAS SMC（每次安全激活）都产生全新的 KgNB，从源头杜绝密钥重用。这是一种前向安全强化——即便某次 KgNB 泄露，也无法回溯或横向复用到其他会话。
Q5：抓包时看到 NAS SMC 成功，但之后报文还是明文，问题在哪？ A：几乎可断定是空算法（NEA0）被误启用，造成"握手成功但未加密"的假安全。应立即核查 AMF/gNB 算法许可列表，将 NEA0/NIA0 限定为仅紧急呼叫，并强制商用流程选用 NEA2/NIA2 及以上。
本文由「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 等场景全覆盖。