NR AS安全模式控制（SMC）与双算法协商信令深度拆解

引言：NAS安全 ≠ AS安全——5G双层安全激活的设计哲学

在5G系统中，安全激活并非一步到位的单一操作，而是被精心拆分为NAS层安全和AS层安全两个独立阶段。NAS安全模式控制（NAS SMC）由AMF发起，保护UE与核心网之间的NAS信令；而AS安全模式控制（AS SMC）由gNB发起，保护UE与基站之间的RRC信令和用户面数据。

这种双层设计的核心意图在于：信任域隔离。核心网和接入网由不同实体运营时，NAS密钥与AS密钥完全隔离，gNB无法获得KNAS密钥，AMF也无法直接控制AS算法选择。本文将聚焦TS 33.501 Section 6.4/6.6与TS 38.331 Section 5.3.4中定义的AS SMC完整机制，逐步拆解从算法协商到密钥推演的全链路信令过程。

一、AS SMC在5G初始接入中的时序定位

AS安全模式控制并非孤立存在，它嵌入在5G UE初始注册流程的特定位置。以下是完整的时序上下文：

sequenceDiagram
    participant UE
    participant gNB
    participant AMF

    Note over UE,AMF: Phase 1: RRC连接建立（无安全保护）
    UE->>gNB: RRCSetupRequest
    gNB->>UE: RRCSetup
    UE->>gNB: RRCSetupComplete（携带Registration Request）
    gNB->>AMF: INITIAL UE MESSAGE

    Note over UE,AMF: Phase 2: NAS认证与NAS SMC
    AMF->>UE: Authentication Request/Result（5G-AKA）
    AMF->>UE: NAS Security Mode Command
    UE->>AMF: NAS Security Mode Complete
    AMF->>UE: Registration Accept

    Note over UE,AMF: Phase 3: Initial Context Setup → AS SMC
    AMF->>gNB: INITIAL CONTEXT SETUP REQUEST<br/>（含KgNB + SecurityAlgorithm优先列表）
    gNB->>UE: SecurityModeCommand<br/>（RRC消息，已完整性保护）
    UE->>gNB: SecurityModeComplete<br/>（RRC消息，已加密+完整性保护）
    gNB->>AMF: INITIAL CONTEXT SETUP RESPONSE

    Note over UE,AMF: Phase 4: 专用承载建立
    gNB->>UE: RRCReconfiguration（已安全保护）
    UE->>gNB: RRCReconfigurationComplete

关键设计要点：AS SMC必须在NAS SMC之后执行，因为gNB所需的KgNB密钥是从KAMF推演而来的。AMF在Initial Context Setup Request消息中将KgNB传递给gNB，gNB才能启动AS层的密钥推演和安全激活。

二、AS安全模式控制信令逐消息拆解

2.1 SecurityModeCommand（gNB → UE）

SecurityModeCommand是RRC层消息，由TS 38.331 Section 6.2.2定义。其ASN.1结构如下：

SecurityModeCommand ::= SEQUENCE {
    rrc-TransactionIdentifier          RRC-TransactionIdentifier,
    criticalExtensions                 CHOICE {
        securityModeCommand            SecurityModeCommand-IEs,
        criticalExtensionsFuture       SEQUENCE {}
    }
}

SecurityModeCommand-IEs ::= SEQUENCE {
    securityConfigSMC                  SecurityConfigSMC,
    lateNonCriticalExtension           OCTET STRING OPTIONAL,
    nonCriticalExtension               SEQUENCE {} OPTIONAL
}

SecurityConfigSMC ::= SEQUENCE {
    securityAlgorithmConfig            SecurityAlgorithmConfig
}

SecurityAlgorithmConfig ::= SEQUENCE {
    cipheringAlgorithm                 CipheringAlgorithm,
    integrityProtAlgorithm             IntegrityProtAlgorithm OPTIONAL
}

关键IE解析：

安全保护状态：SecurityModeCommand消息本身使用选定的完整性保护算法进行保护（使用KRRCint密钥），但不进行加密。这是因为在发送此消息时，下行加密尚未激活——加密从SecurityModeComplete消息开始生效。

2.2 SecurityModeComplete（UE → gNB）

SecurityModeComplete ::= SEQUENCE {
    rrc-TransactionIdentifier          RRC-TransactionIdentifier,
    criticalExtensions                 CHOICE {
        securityModeComplete           SecurityModeComplete-IEs,
        criticalExtensionsFuture       SEQUENCE {}
    }
}

SecurityModeComplete是AS SMC成功完成的确认消息。与Command不同，此消息同时进行完整性保护和加密。UE在发送此消息前，已完成了全部AS密钥的推演，包括KRRCint、KRRCenc和KUPenc。

重要细节：SecurityModeComplete消息体几乎为空（无关键IE），它仅靠RRC事务标识符匹配SecurityModeCommand。其真正的安全意义在于：这条消息的发送本身就证明了UE已成功激活了AS安全上下文。

2.3 SecurityModeFailure（UE → gNB）——异常路径

当UE无法接受gNB选择的算法时，会返回SecurityModeFailure：

SecurityModeFailure ::= SEQUENCE {
    rrc-TransactionIdentifier          RRC-TransactionIdentifier,
    criticalExtensions                 CHOICE {
        securityModeFailure            SecurityModeFailure-IEs,
        criticalExtensionsFuture       SEQUENCE {}
    }
}

触发SecurityModeFailure的典型场景： 1. gNB选择的加密算法不在UE支持列表中 2. gNB选择的完整性保护算法不在UE支持列表中 3. UE在推演密钥时检测到内部错误

三、算法协商机制深度解析

3.1 算法选择的三个约束条件

gNB在发送SecurityModeCommand之前，需要完成算法选择。这个选择受三重约束：

flowchart TD
    A["AMF提供的SecurityAlgorithm<br/>（运营商策略优先级列表）"] --> D{gNB算法选择引擎}
    B["UE上报的UESecurityCapability<br/>（UE支持的算法集合）"] --> D
    C["gNB本地支持的算法集合<br/>（基站设备能力）"] --> D
    D --> E[取三方交集]
    E --> F[按优先级排序选择最高优先级算法]
    F --> G[生成SecurityModeCommand]

    style A fill:#e1f5fe
    style B fill:#fff3e0
    style C fill:#e8f5e9
    style G fill:#fce4ec

约束1：AMF提供的SecurityAlgorithm

AMF在Initial Context Setup Request中向gNB传递SecurityAlgorithm IE，其中包含运营商配置的算法优先级列表。这个列表决定了当多种算法同时可用时，gNB应优先选择哪种算法。

约束2：UE安全能力

UE在Registration Request中通过UESecurityCapability IE上报自己支持的所有5G安全算法：

约束3：gNB本地能力

gNB根据自身设备能力（硬件加密引擎支持的算法集合）进行最终过滤。

3.2 算法优先级排序与选择

TS 33.501 Section 5.4.3定义了算法选择规则：

选择流程： 1. 取UE支持集合 ∩ gNB支持集合 ∩ AMF允许集合 = 可用算法集合 2. 如果可用集合为空 → 触发安全失败 3. 从可用集合中，按AMF指定优先级选择最高优先级算法 4. 加密算法和完整性保护算法独立选择

3.3 5G安全算法一览

NEA0/NIA0的使用限制（TS 33.501 Section 5.4.3.2）： - 空加密算法NEA0仅允许用于未认证的紧急呼叫 - 空完整性保护算法NIA0绝不允许用于RRC完整性保护（即AS SMC中完整性保护算法不能选NIA0） - 运营商可通过配置进一步限制空算法的使用

四、AS密钥推演链路完整拆解

4.1 从KAMF到AS密钥的完整层级

flowchart TB
    K["K（USIM/UDM共享根密钥）"]
    K --> CKIK["CK || IK<br/>（认证向量输出）"]
    CKIK --> KAUSF["KAUSF<br/>KDF: FC=0x6A"]
    KAUSF --> KSEAF["KSEAF<br/>KDF: FC=0x6C"]
    KSEAF --> KAMF["KAMF<br/>KDF: FC=0x6D"]

    KAMF --> KNASint["KNASint<br/>KDF: FC=0x65<br/>P0=算法类型=0x03"]
    KAMF --> KNASenc["KNASenc<br/>KDF: FC=0x65<br/>P0=算法类型=0x02"]
    KAMF --> KgNB["KgNB<br/>KDF: FC=0x6F"]

    KgNB --> KRRCint["KRRCint<br/>KDF: FC=0x69<br/>P0=0x03+算法ID"]
    KgNB --> KRRCenc["KRRCenc<br/>KDF: FC=0x69<br/>P0=0x02+算法ID"]
    KgNB --> KUPint["KUPint<br/>KDF: FC=0x69<br/>P0=0x05+算法ID"]
    KgNB --> KUPenc["KUPenc<br/>KDF: FC=0x69<br/>P0=0x04+算法ID"]

    style K fill:#ffcdd2
    style KgNB fill:#fff9c4
    style KRRCint fill:#c8e6c9
    style KRRCenc fill:#c8e6c9
    style KUPenc fill:#bbdefb
    style KUPint fill:#bbdefb

4.2 KgNB推演（TS 33.501 Annex A.7）

AMF使用以下KDF从KAMF推演出KgNB：

KgNB = HMAC-SHA-256(KAMF, S)
其中 S = FC || P0 || L0 || P1 || L1
FC  = 0x6F
P0  = access type (0 = 3GPP access)
L0  = 0x00 0x01
P1  = 不存在（无额外参数）
L1  = 不存在

4.3 AS密钥推演（TS 33.501 Annex A.9）

gNB和UE分别使用相同的KDF从KgNB推演出四个AS密钥：

K_AS = HMAC-SHA-256(KgNB, S)
其中 S = FC || P0 || L0 || P1 || L1
FC  = 0x69
P0  = algorithm type distinguisher
L0  = 0x00 0x01
P1  = algorithm identity
L1  = 0x00 0x01

Algorithm Type Distinguishere取值：

Algorithm Identity取值：

推演示例：假设gNB选择了NEA2作为加密算法、NIA2作为完整性保护算法，则：

KRRCint = HMAC-SHA-256(KgNB, 0x69 || 0x03 || 0x0001 || 0x02 || 0x0001)
KRRCenc = HMAC-SHA-256(KgNB, 0x69 || 0x02 || 0x0001 || 0x02 || 0x0001)
KUPenc  = HMAC-SHA-256(KgNB, 0x69 || 0x04 || 0x0001 || 0x02 || 0x0001)
KUPint  = HMAC-SHA-256(KgNB, 0x69 || 0x05 || 0x0001 || 0x02 || 0x0001)

4.4 密钥推演的关键设计原则

原则一：算法绑定。AS密钥的推演将算法标识作为KDF输入参数，意味着不同算法会产生不同的密钥。这确保了即使KgNB相同，选择NEA1和NEA2会得到完全不同的KRRCenc。如果后续通过切换改变算法，密钥也会随之改变。

原则二：方向隔离。虽然AS层没有像NAS那样显式区分上行/下行密钥，但加密计数器（COUNT）的方向位确保了上下行使用不同的计数器空间，防止重放攻击。

原则三：前向安全。每次切换时，gNB会基于NH（Next Hop）参数或源gNB的KgNB推演新的目标gNB密钥，确保旧密钥无法从新密钥推演（详见TS 33.501 Section 6.9）。

五、AS SMC完整状态机与异常处理

5.1 AS安全激活状态机

stateDiagram-v2
    [*] --> AS_Security_Not_Activated: RRC连接建立
    AS_Security_Not_Activated --> AS_Security_Activation_Pending: 发送SecurityModeCommand
    AS_Security_Activation_Pending --> AS_Security_Activated: 收到SecurityModeComplete
    AS_Security_Activation_Pending --> AS_Security_Not_Activated: 收到SecurityModeFailure
    AS_Security_Activation_Pending --> AS_Security_Failed: T360定时器超时
    AS_Security_Activated --> AS_Security_Reactivation: RRC重配触发算法更新
    AS_Security_Reactivation --> AS_Security_Activated: 新算法激活完成
    AS_Security_Activated --> [*]: RRC连接释放
    AS_Security_Failed --> [*]: RRC连接释放

5.2 定时器与重传

5.3 NAS SMC与AS SMC的时序关系

一个常见疑问是：NAS SMC和AS SMC能否并行执行？答案在TS 33.501 Section 6.6中有明确规定：

为什么不能并行？ 因为AS SMC所需的KgNB来自AMF的Initial Context Setup消息，而这个消息通常在NAS SMC完成之后才发送。此外，并行执行会引入安全漏洞——攻击者可能利用两个SMC之间的时间差进行降级攻击。

六、用户面安全激活机制

6.1 UP安全的三种模式

TS 33.501 Section 6.6.2为用户面安全定义了三种激活模式：

UP安全激活方式：用户面安全不是通过AS SMC单独激活的，而是通过RRCReconfiguration消息中的SecurityConfig字段间接激活。AMF在Initial Context Setup Request中携带UP安全策略（UPSecurityPolicy IE），gNB根据此策略决定是否激活UP完整性保护。

6.2 UP安全策略传递链

UDM订阅数据 → UDR → PCF策略 → AMF（UPSecurityPolicy）→ gNB（SecurityIndication）→ PDCP层

AMF通过N2接口（Initial Context Setup Request）向gNB传递SecurityIndication IE：

七、实战抓包识别与故障排查

7.1 抓包中如何定位AS SMC流程

在Wireshark中解码ngap和rrc_nr协议后，AS SMC流程可通过以下关键帧标识：

Wireshark过滤表达式：

rrc_nr.securityModeCommand || rrc_nr.securityModeComplete || rrc_nr.securityModeFailure

7.2 常见故障场景与排查思路

故障1：SecurityModeFailure循环

故障2：AS SMC后RRC消息解密失败

故障3：AS安全激活延迟过大

5G相对4G的关键安全增强： 1. 禁止空完整性保护：4G允许EIA0用于RRC完整性保护，5G严格禁止NIA0用于AS层完整性 2. 用户面完整性保护：5G新增了UP完整性保护能力，防止用户面数据被篡改 3. UP安全策略：核心网可以通过策略控制UP安全激活，4G中UP安全完全由eNB本地决定

常见问题

Q1: NAS SMC和AS SMC中的算法可以不同吗？ A: 可以且通常是不同的。NAS SMC中AMF选择NAS层算法（KNASenc/KNASint），AS SMC中gNB选择AS层算法（KRRCenc/KRRCint）。两者独立选择，但都从KAMF→KgNB这一条密钥链路衍生。实际网络中，NAS和AS通常都选择NEA2/NIA2（AES），但这并非强制要求。

Q2: 为什么SecurityModeCommand只做完整性保护不做加密？ A: 这是一个"鸡和蛋"的问题。SecurityModeCommand中携带了加密算法标识，UE需要先读取这个消息才能知道用什么算法来加密。如果这条消息本身被加密，UE就不知道用什么算法解密它。因此设计为先激活完整性保护（用KRRCint保护），UE确认算法后再激活加密。完整性保护本身已经能防止消息被篡改。

Q3: 切换场景下AS安全如何处理？ A: 切换时AS安全分为Xn切换和N2切换两种情况。Xn切换中，源gNB直接将KgNB（或NH推演的新密钥）传递给目标gNB，目标gNB重新推演AS密钥，但不会重新执行AS SMC过程——安全上下文通过RRCReconfiguration中的handoverType字段隐式更新。N2切换中，AMF参与密钥分发，目标gNB从AMF获得新的SecurityKey。

Q4: UP完整性保护为什么有速率限制？ A: 完整性保护算法（如AES-CMAC）对每个PDCP SDU都需要计算一个消息认证码（MAC-I），计算开销较大。对于高速数据业务（如1Gbps下载），逐包完整性保护可能成为性能瓶颈。因此TS 33.501引入了maximumIntegrityProtectedDataRate参数，允许运营商配置速率上限，超过上限的数据包可以跳过完整性保护。

Q5: 256-bit算法何时引入5G？ A: TS 33.501 Release 18（R18）已开始讨论256-bit安全算法的引入框架，但截至R19，标准中仍以128-bit算法为主。256-bit算法的标准化涉及KDF扩展、算法标识扩展（需要新的算法ID）、以及USIM卡硬件升级等多个方面，预计在6G标准（Release 20+）中才会正式强制要求。

参考来源

1. 3GPP TS 33.501 V19.x.x — Section 6.4（AS密钥推演）、Section 6.6（AS安全激活流程）、Annex A.7/A.9（KDF定义）
2. 3GPP TS 38.331 V19.x.x — Section 5.3.4（SMC RRC过程定义）、Section 6.2.2（消息ASN.1结构）
3. 3GPP TS 24.501 V19.x.x — NAS SMC消息编码与UESecurityCapability IE定义
4. 3glteinfo - 5G NR SecurityModeCommand — RRC消息结构详解
5. TelecomTrainer - Understanding 5G NR AS Security — AS安全密钥推演步骤指南

本文由「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 等场景全覆盖。