首页 › security › 5G AS安全激活与DRB密钥派生拆解

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的完整时序图:

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的完整层级:

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)

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)

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实体的安全处理如下:

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自身的保护方式

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

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的安全策略:

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值实现密钥流分离。这意味着:


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

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 切换中安全上下文的传递

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 — 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 — NR Radio Resource Control (RRC), Section 5.3.4 (Security mode procedure), Section 6.2.2 (ASN.1)
  3. 3GPP TS 38.323 — NR Packet Data Convergence Protocol (PDCP), Section 5.9/5.10 (Ciphering/Integrity)
  4. 3GLTEInfo - 5G NR Security Mode Command — RRC消息参考与解码示例
  5. OpenAirInterface - Understanding 5G NR Security — 开源实现中的安全流程详解

本文由「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学通信知识星球海报-扫码加入