当前位置：首页 > news >正文

手把手拆解NAS Security Mode Command：5G安全模式建立的关键一步

news 2026/6/5 8:17:06

手把手拆解NAS Security Mode Command：5G安全模式建立的关键一步

在5G核心网的信令交互中，NAS Security Mode Command（NAS安全模式命令）扮演着承前启后的关键角色。这条看似简单的控制消息，实际上承载着网络与终端之间安全通道建立的完整协商逻辑。对于从事核心网运维和信令分析的工程师而言，深入理解这条消息的构造原理和交互机制，能够快速定位90%以上的安全相关故障场景。

1. NAS安全模式控制流程的全局定位

当UE完成鉴权流程后，AMF（接入和移动性管理功能）需要与终端协商后续通信的安全参数。这个过程被称为NAS安全模式控制流程（NAS Security Mode Control Procedure），而NAS Security Mode Command正是该流程的启动信号。与4G时代不同，5G的安全模式建立具有三个显著特征：

双向算法协商：AMF不仅选择加密算法，还需考虑终端支持的完整性保护算法组合
上下文同步机制：通过ngKSI（密钥集标识符）确保双方使用相同的安全上下文
防降级攻击设计：ABBA参数和算法选择机制有效抵御强制降级攻击

典型触发场景包括：

初始注册流程中鉴权成功后的安全建立
跨AMF切换时新AMF重建安全上下文
周期性注册更新时的安全参数刷新

sequenceDiagram participant UE participant AMF UE->>AMF: Registration Request (含UE安全能力) AMF->>UE: NAS Security Mode Command UE->>AMF: NAS Security Mode Complete/Reject

注意：虽然安全模式流程通常伴随注册流程出现，但在紧急注册等特殊场景下可能被跳过

2. 消息结构深度解析

NAS Security Mode Command的IE（信息元素）布局遵循严格的逻辑顺序，每个字段都有其特定的安全使命。通过Wireshark捕获的实际消息示例如下：

NAS Security Mode Command (0x5d) ├─ Security header type: Integrity protected (0x01) ├─ Protocol discriminator: NAS (0x0e) ├─ Message type: Security Mode Command (0x5d) ├─ Selected NAS security algorithms │ ├─ Type: 0x15 │ ├─ Length: 0x01 │ └─ Value: 0x21 (加密算法NEA2+完整性算法NIA2) ├─ ngKSI │ ├─ Type: 0x11 │ ├─ Length: 0x01 │ └─ Value: 0x07 (KSI=7, NAS标识=0) ├─ Replayed UE security capabilities │ ├─ Type: 0x14 │ ├─ Length: 0x04 │ └─ Value: 0xee800021 (EEA0/EEA1/EEA2, EIA1/EIA2) ├─ Additional 5G security information │ ├─ Type: 0x36 │ ├─ Length: 0x01 │ └─ Value: 0x80 (RINMR=1, HDP=0) └─ ABBA ├─ Type: 0x38 ├─ Length: 0x02 └─ Value: 0x0001

2.1 核心IE功能详解

Selected NAS security algorithms
AMF基于以下优先级进行算法选择：

本地策略允许的最高安全级别算法
UE在Registration Request中声明的支持能力
运营商配置的禁用算法黑名单

常见算法组合编码：

算法标识	加密算法	完整性算法
0x21	NEA2	NIA2
0x11	NEA1	NIA1
0x01	NEA0	NIA0

ngKSI的同步机制
该参数包含两个关键信息：

低4位表示KSI值（0-7）
高4位表示NAS标识（0表示5G NAS，1表示EPS NAS）

Replayed UE security capabilities验证
UE收到该IE后必须执行三项检查：

算法列表是否被篡改
支持的算法强度是否被降级
EPS能力字段是否与初始注册一致

3. 异常处理逻辑剖析

3.1 RINMR标志位的特殊作用

当AMF检测到以下情况时，会在Additional 5G security information中设置RINMR=1：

初始Registration Request完整性校验失败
NAS message container解密失败
安全上下文版本不匹配

此时UE需要在Security Mode Complete中通过NAS message container重传完整的初始消息。典型的重传消息结构如下：

# NAS Security Mode Complete中的消息容器示例 nas_container = { "message_type": "Registration Request", "5gmm_capability": 0x80, "ue_security_capability": 0xee800021, "requested_nssai": [...], "sor_transparent_container": b'...' # 需要加密的敏感信息 }

3.2 安全模式拒绝场景

当UE验证失败时，会触发Security Mode Reject流程。常见拒绝原因包括：

原因值	描述	处理建议
#23	UE安全能力不匹配	检查Replayed UE security capabilities
#24	算法不支持	核对Selected NAS security algorithms
#96	无效必选IE	验证ABBA等必选字段存在性

关键提示：即使发送Security Mode Reject，UE仍需保持原有安全上下文（如果存在）继续通信

4. 实战调试技巧

4.1 信令跟踪分析方法

使用UERANSIM模拟器重现异常场景时，建议关注以下关键点：

# 在AMF配置文件中强制设置特定算法 amf: security: preferred_integrity_algorithm: NIA2 preferred_ciphering_algorithm: NEA2 reject_nea0: true

调试时重点关注的三阶段计数器：

PRE_SECURITY：初始消息的COUNT初始值
SECURITY_SETUP：安全模式命令期间的临时COUNT
POST_SECURITY：安全建立后的正式COUNT

4.2 常见故障模式

场景1：持续性Security Mode Reject
可能原因：

UE与AMF的USIM卡算法配置不一致
核心网升级后新增算法黑名单
终端基带芯片存在算法实现缺陷

场景2：RINMR循环触发
解决方案：

检查AMF的UE上下文存储是否完整
验证Kamf密钥推导参数是否同步
确认NAS COUNT重置机制是否正常

在现网部署中，曾遇到过一个典型案例：某厂商AMF在跨版本升级后，由于算法选择逻辑变更，导致大量终端反复触发安全模式重建。最终通过抓包分析发现是Selected NAS security algorithms字段的编码方式与终端预期不一致，通过补丁更新解决了该问题。

5. 安全增强实践

为提升5G NAS层安全性，建议在网络侧实施以下策略：

算法组合策略

强制禁用NEA0/NIA0空算法
优先选择256位加密算法（如NEA3）
对物联网设备采用独立算法白名单

密钥管理增强

# Kamf推导增强示例（增加盐值） def derive_kamf(kseaf, snn, abba, salt=b'5G_salt'): input_string = snn + abba + salt return hmac.new(kseaf, input_string, hashlib.sha256).digest()

抗重放攻击机制

严格校验NAS COUNT单调递增
设置COUNT阈值强制重鉴权
对ABBA参数实施动态变化

在实际网络优化中，通过引入这些增强措施，某运营商将NAS层安全事件发生率降低了73%。特别是在工业物联网场景下，定制化的算法策略有效防范了针对低功耗设备的定向攻击。

理解NAS Security Mode Command的每个细节，就像掌握了5G安全大厦的门禁系统。当遇到UE无法接入、频繁掉线等疑难问题时，从这条关键消息入手分析，往往能快速定位到安全上下文不同步、算法协商失败等根源原因。建议运维团队建立标准化的信令分析checklist，将本文提到的关键验证点纳入日常监控体系。

查看全文

http://www.jsqmd.com/news/953919/