<!-- title: 5G AS安全激活与DRB密钥派生拆解 -->
<!-- domain: security -->

# 5G AS安全激活与DRB密钥派生信令拆解

## 一、引言：从NAS安全到AS安全的信任传递

5G安全架构分为两大层次：**NAS层安全**（UE ↔ AMF）和**AS层安全**（UE ↔ gNB）。当UE完成5G-AKA认证和NAS安全模式命令后，AMF已经建立了与UE的NAS层安全上下文，但空中接口的RRC信令和用户面数据（DRB）仍然处于明文传输状态。**AS安全激活**（Access Stratum Security Activation）正是将安全保护从核心网延伸到接入网的关键一步。

AS安全激活由gNB通过RRC **SecurityModeCommand** 消息触发，完成两个核心任务：（1）协商AS层加密和完整性保护算法；（2）派生四把AS密钥（KRRCint、KRRCenc、KUPint、KUPenc），分别用于RRC完整性、RRC加密、用户面完整性和用户面加密。

本文基于 **TS 33.501 V18.10.0** Section 6.6/6.7/6.9、**TS 38.331 V18.6.0** Section 5.3.4 和 **TS 38.323 V18.x** Section 5.9/5.10，完整拆解AS安全激活的信令流程、密钥派生链、PDCP层保护机制以及DRB用户面安全激活的全过程。

---

## 二、AS安全激活完整信令时序

AS安全激活发生在初始注册流程中，紧跟NAS安全建立之后、RRC重配（DRB建立）之前。以下是基于TS 38.331 Section 5.3.4的完整时序图：

```mermaid
sequenceDiagram
    participant UE
    participant gNB
    participant AMF

    Note over UE,AMF: 阶段一：NAS安全已建立（前置条件）

    AMF->>gNB: NGAP Initial Context Setup Request<br/>含 SecurityKey(KgNB) +<br/>securityAlgorithm +<br/>UESecurityCapability
    Note right of gNB: gNB从KgNB派生<br/>KRRCint/KRRCenc/<br/>KUPint/KUPenc

    Note over UE,gNB: 阶段二：AS安全激活（SRB安全）

    gNB->>UE: RRC SecurityModeCommand<br/>[SRB1/DL-DCCH]<br/>cipheringAlgorithm=NEA2<br/>integrityProtAlgorithm=NIA2
    Note left of UE: 消息仅完整性保护<br/>不加密（加密尚未激活）

    UE->>UE: 使用KRRCint验证MAC-I<br/>使用KDF派生<br/>KRRCint/KRRCenc/KUPint/KUPenc

    UE->>gNB: RRC SecurityModeComplete<br/>[SRB1/UL-DCCH]
    Note right of gNB: 该消息已同时启用<br/>完整性保护+加密

    Note over UE,gNB: 阶段三：DRB安全激活

    gNB->>UE: RRC Reconfiguration<br/>含 radioBearerConfig<br/>建立DRB（含安全策略）
    UE->>gNB: RRC Reconfiguration Complete

    Note over UE,gNB: DRB用户面数据<br/>加密+完整性保护激活
```

### 关键时序节点解析

| 步骤 | 消息 | TS参考 | 安全状态 |
|------|------|--------|---------|
| 1 | AMF→gNB: Initial Context Setup Request | TS 38.413 Section 8.3.1 | AMF下发KgNB和安全算法列表 |
| 2 | gNB→UE: SecurityModeCommand | TS 38.331 Section 5.3.4 | 仅完整性保护，不加密 |
| 3 | UE→gNB: SecurityModeComplete | TS 38.331 Section 5.3.4 | 完整性+加密同时激活 |
| 4 | gNB→UE: RRC Reconfiguration | TS 38.331 Section 5.3.5 | DRB建立，用户面安全激活 |

---

## 三、密钥派生链：从K到DRB密钥

### 3.1 完整密钥层级结构

5G安全密钥体系是一个自顶向下的层级派生结构，基于HMAC-SHA-256的KDF（Key Derivation Function）逐层推演。以下是基于TS 33.501 Section 6.1.1/6.2的完整层级：

```mermaid
graph TD
    K["K (USIM/ARF永久密钥)"] -->|认证向量导出| CK_IK["CK ‖ IK<br/>(认证响应)"]
    CK_IK -->|KDF: FC=0x6A| KAMF["KAMF<br/>(Access and Mobility Key)"]
    KAMF -->|KDF: FC=0x69| KgNB["KgNB<br/>(gNB密钥)"]
    KgNB -->|KDF: FC=0x70| KRRCint["KRRCint<br/>(RRC完整性密钥)"]
    KgNB -->|KDF: FC=0x71| KRRCenc["KRRCenc<br/>(RRC加密密钥)"]
    KgNB -->|KDF: FC=0x72| KUPint["KUPint<br/>(UP完整性密钥)"]
    KgNB -->|KDF: FC=0x73| KUPenc["KUPenc<br/>(UP加密密钥)"]

    style K fill:#1a1a2e,color:#fff
    style KAMF fill:#16213e,color:#fff
    style KgNB fill:#0f3460,color:#fff
    style KRRCint fill:#e94560,color:#fff
    style KRRCenc fill:#e94560,color:#fff
    style KUPint fill:#533483,color:#fff
    style KUPenc fill:#533483,color:#fff
```

### 3.2 KDF参数详细拆解

每一步KDF调用都使用HMAC-SHA-256，输入参数严格按照TS 33.501 Annex A定义：

**KgNB从KAMF派生**（TS 33.501 Section 6.9.1）：
```
KDF Input = FC(0x6E) || P0(ACCESS_TYPE) || L0 || P0(architectural separation)
```
- FC = 0x6E
- P0 = Access Type（1 = 3GPP接入）
- L0 = P0长度（2字节）

**AS密钥从KgNB派生**（TS 33.501 Section 6.6.1）：
```
Key = HMAC-SHA-256(KgNB, FC || Algorithm_Type_Distinguisher || Algorithm_Identity || 0x00 || ...)
```

| 派生密钥 | FC值 | Algorithm Type Dist. | 用途 |
|----------|------|---------------------|------|
| KRRCint | 0x70 | 0x03 (RRC integrity) | RRC信令完整性保护 |
| KRRCenc | 0x71 | 0x02 (RRC encryption) | RRC信令加密 |
| KUPint | 0x72 | 0x01 (UP integrity) | 用户面完整性保护 |
| KUPenc | 0x73 | 0x00 (UP encryption) | 用户面加密 |

### 3.3 gNB与UE的密钥同步机制

一个关键的设计要点：**AMF只把KgNB传给gNB，不直接传AS密钥**。AS密钥由gNB和UE各自独立派生，保证密钥不二次传输。

| 实体 | 持有的密钥材料 | 派生行为 |
|------|--------------|---------|
| AMF | KAMF → KgNB | 将KgNB通过NGAP发给gNB |
| gNB | KgNB + 安全算法ID | 独立派生4把AS密钥 |
| UE | KAMF（NAS安全上下文） | 从KAMF独立派生KgNB，再派生4把AS密钥 |

这种设计的核心意图是：**信任锚点在AMF**，gNB是安全执行的代理。即使gNB被攻破，也无法回溯到KAMF或K（因为KDF是单向函数）。

---

## 四、SecurityModeCommand消息深度解析

### 4.1 ASN.1结构（TS 38.331 Section 6.2.2）

```asn1
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
}
```

### 4.2 关键IE详解

| IE名称 | 存在性 | 取值范围 | 说明 |
|--------|--------|---------|------|
| rrc-TransactionIdentifier | 必选 | 0-3 | 事务标识，用于匹配Command和Complete |
| cipheringAlgorithm | 必选 | NEA0/NEA1/NEA2/NEA3 | NEA0=空加密；NEA1=SNOW-3G；NEA2=AES-CTR；NEA3=ZUC |
| integrityProtAlgorithm | 可选 | NIA0/NIA1/NIA2/NIA3 | 若不出现，表示不改变当前完整性算法 |
| lateNonCriticalExtension | 可选 | - | Rel-16+扩展字段 |

### 4.3 安全算法对比

| 算法 | 全称 | 基础密码 | 应用层 | 安全强度 |
|------|------|---------|--------|---------|
| **NEA0** | Null Ciphering | 无 | RRC/UP | 无保护，仅用于紧急呼叫/测试 |
| **NEA1** | 128-SNOW-3G | SNOW-3G流密码 | RRC/UP | 128位 |
| **NEA2** | 128-AES-CTR | AES计数器模式 | RRC/UP | 128位，全球部署最广 |
| **NEA3** | 128-ZUC | ZUC流密码 | RRC/UP | 128位，中国国密标准 |
| **NIA0** | Null Integrity | 无 | RRC | 无保护 |
| **NIA1** | 128-SNOW-3G | SNOW-3G | RRC/UP | 128位 |
| **NIA2** | 128-AES-CMAC | AES-CMAC模式 | RRC/UP | 128位 |
| **NIA3** | 128-ZUC | ZUC | RRC/UP | 128位 |

---

## 五、PDCP层安全机制：加密与完整性的执行层

### 5.1 PDCP安全处理架构

PDCP（Packet Data Convergence Protocol）是5G NR中执行加密和完整性保护的具体协议层。根据TS 38.323 Section 5.9/5.10，PDCP实体的安全处理如下：

```mermaid
graph LR
    subgraph "PDCP发送端（gNB/UE）"
        A[SDU数据] --> B{是否加密?}
        B -->|是| C[加密模块<br/>算法:NEA1/2/3<br/>密钥:KRRCenc或KUPenc]
        B -->|否| D[透传]
        C --> E{是否完整性保护?}
        D --> E
        E -->|是| F[计算MAC-I<br/>算法:NIA1/2/3<br/>密钥:KRRCint或KUPint]
        E -->|否| G[添加PDCP头]
        F --> G
        G --> H[PDCP PDU]
    end
```

### 5.2 PDCP加密/完整性输入参数

PDCP层加密和完整性保护使用以下输入参数（TS 38.323 Section 5.9/5.10）：

| 参数 | 来源 | 说明 |
|------|------|------|
| **KEY** | KDF派生 | KRRCenc / KUPenc（加密）或KRRCint / KUPint（完整性） |
| **COUNT** | PDCP层维护 | HFN ‖ PDCP SN，32位计数器，抗重放 |
| **BEARER** | DRB/SRB ID | 无线承载标识（0-31） |
| **DIRECTION** | 上行/下行 | 0=上行，1=下行 |
| **LENGTH** | 数据长度 | 待保护数据长度（位） |

加密函数调用形式：
```
CIPHERTEXT = NEA_x(KEY, COUNT, BEARER, DIRECTION, LENGTH, PLAINTEXT)
```

完整性保护函数：
```
MAC-I = NIA_x(KEY, COUNT, BEARER, DIRECTION, LENGTH, MESSAGE)
```

### 5.3 SRB与DRB安全策略差异

这是5G相比LTE的一个重要增强——**用户面完整性保护**：

| 安全属性 | SRB（信令承载） | DRB（数据承载） |
|----------|---------------|----------------|
| 加密 | 必须激活（除SMC消息） | 默认激活 |
| 完整性保护 | 必须激活 | Rel-15可选，Rel-16+部分场景必选 |
| MAC-I长度 | 32位 | 32位 |
| 保护范围 | RRC消息 | 用户面IP/以太网数据 |

**设计意图**：LTE只对信令面做完整性保护，不保护用户面数据完整性。5G引入UP integrity protection，可以防止中间人篡改用户面数据（如篡改DNS响应、注入恶意payload）。

### 5.4 SecurityModeCommand自身的保护方式

这是一个容易被忽视但非常重要的设计细节：

```mermaid
graph TD
    A["SecurityModeCommand<br/>（gNB→UE）"] --> B["✅ 完整性保护（NIA2）<br/>使用KRRCint计算MAC-I"]
    A --> C["❌ 不加密<br/>因为加密尚未激活"]

    D["SecurityModeComplete<br/>（UE→gNB）"] --> E["✅ 完整性保护（NIA2）"]
    D --> F["✅ 加密（NEA2）<br/>第一条加密消息"]

    style C fill:#ff6b6b,color:#fff
    style F fill:#51cf66,color:#fff
```

**SecurityModeCommand是第一条启用完整性保护的消息**，但此时加密尚未激活，所以消息内容是明文可见的（算法ID是明文的）。**SecurityModeComplete是第一条同时启用加密和完整性保护的消息**，UE在发送这条消息时已经完成了所有AS密钥的派生和激活。

---

## 六、DRB安全激活：从SRB到用户面

### 6.1 DRB安全激活时序

SRB安全由SecurityModeCommand激活，但DRB的安全在后续的**RRC Reconfiguration**中才真正生效。gNB在Initial Context Setup过程中建立DRB时，会在radioBearerConfig中指定每个DRB的安全策略：

```mermaid
sequenceDiagram
    participant UE
    participant gNB

    Note over UE,gNB: SRB安全已激活

    gNB->>UE: RRC Reconfiguration<br/>radioBearerConfig:<br/>- drb-ToAddModList<br/>  - DRB-Identity: 1<br/>  - pdcp-Config:<br/>    - securityConfig:<br/>      - integrityProtection: enabled<br/>      - ciphering: enabled<br/>    -headerCompression: notUsed

    UE->>UE: 为DRB-1建立PDCP实体<br/>配置KUPenc + KUPint<br/>初始化COUNT=0

    UE->>gNB: RRC Reconfiguration Complete<br/>（SRB加密+完整性保护）

    Note over UE,gNB: DRB-1用户面数据<br/>加密 + 完整性保护生效
```

### 6.2 DRB安全策略IE结构

DRB的安全配置嵌套在PDCP-Config中，包含以下关键字段：

| IE路径 | 字段 | 说明 |
|--------|------|------|
| radioBearerConfig → drb-ToAddModList → pdcp-Config → securityConfig | ciphering | 是否启用DRB加密 |
| 同上 | integrityProtection | 是否启用DRB完整性保护 |
| 同上 | integrityProtectionNEA2 | 是否指定NEA2用于UP完整性（Rel-17+） |

### 6.3 多DRB场景下的密钥分离

当UE建立多个DRB时，所有DRB共享**相同的KUPenc和KUPint**，但通过不同的**BEARER ID**和独立的**COUNT值**实现密钥流分离。这意味着：

- DRB-1使用 BEARER=1, COUNT_1
- DRB-2使用 BEARER=2, COUNT_2
- 密钥流不同，即使COUNT相同也不会产生密钥流重用

---

## 七、状态转换图：AS安全激活全过程

```mermaid
stateDiagram-v2
    [*] --> RRC_IDLE: 开机/脱网
    RRC_IDLE --> RRC_INACTIVE: 网络配置
    RRC_IDLE --> RRC_CONNECTED_SENDING: RRCSetupComplete<br/>(NAS RegRequest)<br/>安全=无

    state RRC_CONNECTED_SENDING {
        [*] --> NAS_Security_Active: NAS SMC完成
        NAS_Security_Active --> AS_Security_Activating: 收到SecurityModeCommand
        AS_Security_Activating --> AS_Security_Active: SecurityModeComplete<br/>SRB加密+完整性生效
        AS_Security_Active --> DRB_Security_Active: RRC Reconfig<br/>DRB安全激活
    }

    DRB_Security_Active --> RRC_CONNECTED_SECURE: 全部安全激活
    
    RRC_CONNECTED_SECURE --> Handover_Key_Update: 切换时<br/>KgNB→Ktarget_gNB
    Handover_Key_Update --> RRC_CONNECTED_SECURE: 新KgNB派生完成
```

---

## 八、切换场景的密钥更新

### 8.1 水平派生与垂直派生

在gNB间切换时，密钥需要更新以保证前向/后向安全（TS 33.501 Section 6.9.2）：

| 派生类型 | 触发条件 | 输入 | 输出 | 安全属性 |
|----------|---------|------|------|---------|
| **水平派生** | intra-gNB切换（CU内） | KgNB + KDF | KgNB' | 保证前向安全 |
| **垂直派生** | inter-gNB切换 | KgNB + target PCI + ARFCN | Ktarget_gNB | 保证前向+后向安全 |

**垂直派生KDF输入**：
```
Ktarget_gNB = KDF(KgNB, 0x12 || PCI || ARFCN-DL || 0x00 || ...)
```

### 8.2 切换中安全上下文的传递

```mermaid
sequenceDiagram
    participant UE
    participant Source_gNB
    participant Target_gNB

    Source_gNB->>Target_gNB: Xn HANDOVER REQUEST<br/>含SecurityContext<br/>(KgNB*, nextChainingCount)
    Target_gNB->>Target_gNB: 从KgNB*派生<br/>新AS密钥集
    Target_gNB->>UE: RRC Reconfiguration<br/>withReconfiguration-withSync<br/>含新PCI/ARFCN
    UE->>UE: 垂直派生Ktarget_gNB<br/>派生新AS密钥
    UE->>Target_gNB: RRC Reconfiguration Complete<br/>（新密钥加密）
```

---

## 九、抓包识别与排错实战

### 9.1 Wireshark中的AS安全激活识别

在Wireshark中解码5G NAS/RRC时，AS安全激活的关键标识：

| 抓包特征 | 判断依据 |
|---------|---------|
| **SecurityModeCommand出现** | 在DL-DCCH (SRB1)上看到RRC securityModeCommand |
| **加密激活标志** | SecurityModeComplete之后，SRB1消息显示"Ciphered"或无法解码 |
| **DRB建立** | RRC Reconfiguration中包含drb-ToAddModList |
| **完整性验证失败** | Wireshark显示"MAC-I verification failed" |

### 9.2 常见故障场景

**场景一：SecurityModeCommand后UE无响应**

可能原因：
- UE和gNB的安全算法不一致（UE不支持gNB选择的NEA/NIA算法）
- KgNB派生错误（AMF下发的SecurityKey与UE计算的KgNB不匹配）
- NAS安全上下文未正确建立

排错步骤：
1. 检查UESecurityCapability（UE注册时上报的支持算法列表）
2. 核对AMF → gNB的Initial Context Setup Request中的SecurityKey
3. 对比UE log中的KDF输入参数

**场景二：DRB建立后数据不通**

可能原因：
- KUPenc派生错误（KgNB正确但KDF输入BEARER ID错误）
- PDCP COUNT不同步（HFN初始值不一致）
- UP integrity protection策略不匹配（网络配置了但UE未启用）

排错步骤：
1. 确认RRC Reconfiguration中DRB的securityConfig配置
2. 对比gNB和UE的PDCP COUNT初始值
3. 如果是UP完整性保护问题，检查UE能力上报中upIntegrityProtectionSupport

**场景三：切换后安全失败**

可能原因：
- Ktarget_gNB垂直派生参数错误（PCI或ARFCN不匹配）
- nextChainingCount不连续（NH链断裂）
- 源gNB传递的安全上下文不完整

---
## 常见问题

**Q1: SecurityModeCommand和NAS Security Mode Command有什么区别？**

A: 两者是完全不同层次的安全消息。NAS SMC（TS 24.501）在UE和AMF之间建立NAS层安全（NAS加密+完整性），保护的是NAS信令。AS SMC（TS 38.331）在UE和gNB之间建立接入层安全，保护的是RRC信令和DRB用户面数据。时序上NAS SMC先执行，AS SMC后执行。

**Q2: 5G为什么要引入用户面（UP）完整性保护？**

A: LTE只对用户面做加密，不做完整性保护。攻击者虽然无法解密数据，但可以通过位翻转（bit-flipping）攻击篡改加密数据流，导致DNS劫持、数据注入等问题。5G引入UP integrity protection（使用NIA1/2/3算法），可以检测任何对用户面数据的篡改。Rel-16起，3GPP将部分场景（如URLLC）的UP完整性保护设为必选。

**Q3: 为什么SecurityModeCommand只做完整性保护不加密？**

A: 这是一个"鸡和蛋"的问题。SecurityModeCommand携带的正是加密算法的配置（NEA1/2/3），在UE收到并解析这条消息之前，UE和gNB还没有协商好加密算法，因此无法加密。但完整性保护使用的算法可以在AMF的安全上下文中提前约定，所以先激活完整性保护，确保消息不被篡改。

**Q4: 多DRB场景下为什么所有DRB共享KUPenc？不同的DRB安全如何隔离？**

A: 所有DRB共享KUPenc和KUPint是设计选择，因为密钥隔离通过BEARER ID参数和独立的COUNT计数器实现。NEA/NIA算法的输入包含BEARER字段，不同DRB的BEARER ID不同（DRB-1→1, DRB-2→2），因此即使密钥相同，生成的密钥流也完全不同，等效于使用了不同的密钥。这避免了为每个DRB单独派生密钥的开销。

**Q5: 切换时密钥更新的"前向安全"和"后向安全"分别指什么？**

A: **前向安全**（Forward Security）保证新gNB无法解密UE在旧gNB上的历史通信。**后向安全**（Backward Security）保证旧gNB无法解密UE在新gNB上的未来通信。垂直派生通过在KDF输入中加入target PCI和ARFCN，使得新旧gNB的密钥完全独立，同时实现前向和后向安全。水平派生（intra-gNB切换）只保证前向安全。

---

## 参考来源

1. [3GPP TS 33.501 V18.10.0](https://www.3gpp.org/DynaReport/33501.htm) — Security architecture and procedures for 5G System, Section 6.2/6.6/6.7/6.9, Annex A
2. [3GPP TS 38.331 V18.6.0](https://www.3gpp.org/DynaReport/38331.htm) — NR Radio Resource Control (RRC), Section 5.3.4 (Security mode procedure), Section 6.2.2 (ASN.1)
3. [3GPP TS 38.323](https://www.3gpp.org/DynaReport/38323.htm) — NR Packet Data Convergence Protocol (PDCP), Section 5.9/5.10 (Ciphering/Integrity)
4. [3GLTEInfo - 5G NR Security Mode Command](https://www.3glteinfo.com/messages/5g/rrc/5g-rrc-security-mode-command/) — RRC消息参考与解码示例
5. [OpenAirInterface - Understanding 5G NR Security](https://openairinterface.org/wp-content/uploads/2026/03/Understanding-5G-NR-security-with-OpenAirInterface_v1.0-.pdf) — 开源实现中的安全流程详解

---

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

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)