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安全激活发生在初始注册流程中,紧跟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建立,用户面安全激活 |
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
每一步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) | 用户面加密 |
一个关键的设计要点: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 ::= 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名称 | 存在性 | 取值范围 | 说明 |
|---|---|---|---|
| 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+扩展字段 |
| 算法 | 全称 | 基础密码 | 应用层 | 安全强度 |
|---|---|---|---|---|
| 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(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
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)
这是5G相比LTE的一个重要增强——用户面完整性保护:
| 安全属性 | SRB(信令承载) | DRB(数据承载) |
|---|---|---|
| 加密 | 必须激活(除SMC消息) | 默认激活 |
| 完整性保护 | 必须激活 | Rel-15可选,Rel-16+部分场景必选 |
| MAC-I长度 | 32位 | 32位 |
| 保护范围 | RRC消息 | 用户面IP/以太网数据 |
设计意图:LTE只对信令面做完整性保护,不保护用户面数据完整性。5G引入UP integrity protection,可以防止中间人篡改用户面数据(如篡改DNS响应、注入恶意payload)。
这是一个容易被忽视但非常重要的设计细节:
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密钥的派生和激活。
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/>加密 + 完整性保护生效
DRB的安全配置嵌套在PDCP-Config中,包含以下关键字段:
| IE路径 | 字段 | 说明 |
|---|---|---|
| radioBearerConfig → drb-ToAddModList → pdcp-Config → securityConfig | ciphering | 是否启用DRB加密 |
| 同上 | integrityProtection | 是否启用DRB完整性保护 |
| 同上 | integrityProtectionNEA2 | 是否指定NEA2用于UP完整性(Rel-17+) |
当UE建立多个DRB时,所有DRB共享相同的KUPenc和KUPint,但通过不同的BEARER ID和独立的COUNT值实现密钥流分离。这意味着:
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派生完成
在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 || ...)
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/>(新密钥加密)
在Wireshark中解码5G NAS/RRC时,AS安全激活的关键标识:
| 抓包特征 | 判断依据 |
|---|---|
| SecurityModeCommand出现 | 在DL-DCCH (SRB1)上看到RRC securityModeCommand |
| 加密激活标志 | SecurityModeComplete之后,SRB1消息显示"Ciphered"或无法解码 |
| DRB建立 | RRC Reconfiguration中包含drb-ToAddModList |
| 完整性验证失败 | Wireshark显示"MAC-I verification failed" |
场景一: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切换)只保证前向安全。
本文由「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 等场景全覆盖。
