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）。

这里有两个设计上的"巧思"需要特别注意：

第一，为什么要把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交互时序

sequenceDiagram
    participant UE
    participant gNB as gNB (NG-RAN)
    participant AMF
    Note over UE,AMF: 主认证已完成,K_SEAF已就绪
    AMF->>AMF: 由K_SEAF派生K_AMF,<br/>再派生KNASint/KNASenc
    AMF->>UE: SECURITY MODE COMMAND<br/>(ngKSI, Selected NAS algo, Replayed UE sec cap, NAS-MAC)
    Note over UE: 用KNASint校验MAC,<br/>检查回放能力与算法合法性
    alt 校验通过
        UE->>AMF: SECURITY MODE COMPLETE<br/>(加密+完整性保护,第一条受保护NAS消息)
        Note over UE,AMF: NAS安全上下文激活
    else 校验失败
        UE->>AMF: SECURITY MODE REJECT<br/>(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放回注册流程的完整上下文中，可以看到二者紧密咬合：

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）推演，任何一层密钥泄露都不会向上回溯：

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。其状态流转如下：

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）：

协商规则严格受防降级约束：AMF/gNB选用的算法必须是UE在注册请求中上报能力集合的子集。NEA0/NIA0 空算法虽然规范保留，但5G对空算法的使用远比4G谨慎——尤其是用户面完整性保护成为5G新特性后，运营商普遍倾向强制开启非空完整性（NIA2/NIA3），以抵御伪基站注入。

七、抓包识别与故障排查

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 — §5.4.2 Security mode control procedure；§9.11 相关IE定义
2. 3GPP TS 38.331 V18.x — NR RRC Protocol Specification — §5.3.3 Security mode activation procedure
3. 3GPP TS 33.501 V18.x — Security architecture and procedures for 5G system — §6 密钥层级与KAMF change；Annex NEA/NIA算法
4. 3GPP TS 23.502 V18.x — Procedures for the 5G System — §4.2.2 Registration procedure中的安全激活时序
5. 5G NAS Security Mode Command and Equipment Identity Check Explained Step-by-Step — TelecomTrainer — SMC与设备身份核查的实操拆解
6. 5GMM-Security Mode Control procedure（一）— CSDN — mapped/native安全上下文与ngKSI的工程解析
7. 5G认证与安全性-part3-两次安全模式命令SMC（B站） — 为什么需要两次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 等场景全覆盖。