在4G/EPS时代，用户面（UP）数据在空口上只有机密性保护（Confidentiality/Ciphering），没有完整性保护。也就是说，eNB和UE之间的用户数据被加密以防止窃听，但攻击者理论上仍可以篡改、注入或重放密文数据流——因为加密本身并不能保证数据未被修改。这一缺陷在物联网、工业控制、车联网等对数据完整性敏感的场景下被放大。
3GPP在TS 33.501（5G系统安全架构与流程）中专门为用户面引入了完整性保护（Integrity Protection）机制，使5G空口用户面同时具备机密性 + 完整性 + 重放保护三重能力。这套机制由SMF依据订阅策略决策、由AMF经NGAP透传、最终在gNB与UE之间通过RRC和PDCP层激活。本文聚焦这一从SMF策略到PDCP MAC-I的完整激活链路，对应TS 33.501 §6.6（UP安全机制）与TS 38.413（NGAP SecurityIndication/SecurityResult IE）。
核心设计意图有三点：
1. 防篡改：通过32位MAC-I校验，丢弃任何被篡改的PDCP PDU（TS 33.501 §6.6.4.2）。
2. 策略可配、可分级：用 Required / Preferred / Not needed 三档语义（TS 38.413 §9.3.1.x），让运营商按DNN/切片强制或建议开启。
3. 算力受限可控：用 Maximum Integrity Protected Data Rate（MAXIPD，TS 38.413 §9.3.1.103） 上下行限速，避免gNB/UE为海量低价值流量做完整性运算而耗尽CPU。
UP完整性保护的激活本质上是一次三段式协商：
SecurityIndication + Maximum Integrity Protected Data Rate 通过NGAP下发给gNB，gNB决定是否激活、选用何种算法，并通过 SecurityResult 反馈结果。KUPint，PDCP层为每个用户面PDU计算并附挂32位MAC-I。flowchart TD
A[UDM<br/>DNN订阅UP安全策略] -->|Nudm_SDM| B[SMF<br/>决策 required/preferred]
B -->|SecurityIndication<br/>MAXIPD| C[AMF]
C -->|NGAP透传| D[gNB<br/>选算法/按DRB激活]
D -->|RRC Reconfig<br/>integrityProtection per DRB| E[UE]
D -.->|派生 KUPint| F[(KgNB)]
E -.->|派生 KUPint| G[(KgNB')]
D -->|SecurityResult| C
C -->|反馈| B
E -->|每个PDU附挂32位MAC-I| H[PDCP用户面数据]
以下时序描绘一个典型场景：UE已完成注册与5G AKA主认证、NAS SMC已建立，现发起一个策略为UP完整性"Required"的PDU会话建立（例如运营商将关键物联网DNN强制开启UP IP）。
sequenceDiagram
autonumber
participant UE
participant gNB
participant AMF
participant SMF
participant UDM
participant UPF
UE->>AMF: PDU SESSION ESTABLISHMENT REQUEST (NAS)
Note over AMF,SMF: AS SMC已激活(CLAUSE 6.7.4), KRRCint/enc已就绪
AMF->>SMF: Nsmf_PDUSession_CreateSMContext (含UE Security Capability)
SMF->>UDM: Nudm_SDM_Get (SmData/DNN配置)
UDM-->>SMF: UP安全策略 (integrity=required, ciphering=required)
SMF->>UPF: N4 Session Establishment (PDR/FAR/QER)
SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>N2 SM(PDU Session Resource Setup)+ N1 SM(Accept)
Note right of SMF: N2 SM携带 SecurityIndication IE<br/>IntegrityProtectionIndication = required<br/>ConfidentialityProtectionIndication = required<br/>Maximum Integrity Protected Data Rate UL/DL
AMF->>gNB: NGAP PDU SESSION RESOURCE SETUP REQUEST<br/>(UE Security Capability + SecurityIndication + MAXIPD)
gNB->>gNB: 比对UE算法能力与本地优先级表<br/>选定128-NIAx / 128-NEAx
gNB->>UE: RRCReconfiguration<br/>DRB-ToAddMod: pdcp-Config{integrityProtection=on, ciphering=on}<br/>+ N1 SM容器
Note over gNB: STEP 1c: gNB生成 KUPint / KUPenc (源自KgNB, CLAUSE 6.6.2)
Note over UE: STEP 2a.1: UE生成 KUPint / KUPenc
UE->>gNB: RRCReconfigurationComplete
Note over UE,gNB: PDCP为每个UP PDU计算32-bit MAC-I并校验
gNB->>AMF: PDU SESSION RESOURCE SETUP RESPONSE<br/>含 SecurityResult (IntegrityProtectionResult=performed)
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (SecurityResult反馈)
时序中第10步是整个机制的激活触发点：RRC Reconfiguration消息中的DRB-ToAddMod，每个DRB的 pdcp-Config 里独立指明 integrityProtection 与 ciphering 是否开启。这正是TS 33.501 §6.6.2 Figure 6.6.2-1中"1b：gNB shall send the RRC Connection Reconfiguration message ... containing indications for the activation of UP integrity protection and ciphering for each DRB"的落地实现。
这是AMF下发给gNB的"策略指令"，定义在TS 38.413 §9.3.1.x，ASN.1结构（取自spec第44980行附近）：
SecurityIndication ::= SEQUENCE {
integrityProtectionIndication IntegrityProtectionIndication,
confidentialityProtectionIndication ConfidentialityProtectionIndication,
iE-Extensions ProtocolExtensionContainer { {SecurityIndication-ExtIEs} } OPTIONAL,
...
}
IntegrityProtectionIndication ::= ENUMERATED { required, preferred, not-needed, ... }
ConfidentialityProtectionIndication ::= ENUMERATED { required, preferred, not-needed, ... }
| IE字段 | 取值 | gNB行为（依据TS 33.501 §6.6.1） |
|---|---|---|
| IntegrityProtectionIndication | required | gNB必须激活UP完整性，不得否决；若无法满足（如算法不支持），gNB拒绝该PDU Session的UP资源建立并向SMF回reject-cause |
| IntegrityProtectionIndication | preferred | gNB尽量激活；若条件不满足可不激活，可被否决，流程继续 |
| IntegrityProtectionIndication | not-needed | gNB不得激活；策略同样不可被否决 |
| ConfidentialityProtectionIndication | 同上三值 | 同上，作用于UP加密 |
| Maximum Integrity Protected Data Rate (UL/DL) | 整数(bps) | 上行/下行受完整性保护的数据速率上限，保护gNB/UE算力（TS 38.413 §9.3.1.103） |
gNB在响应消息（如PDU SESSION RESOURCE SETUP RESPONSE、INITIAL CONTEXT SETUP RESPONSE）中向核心网回填实际执行结果：
SecurityResult ::= SEQUENCE {
integrityProtectionResult IntegrityProtectionResult,
confidentialityProtectionResult ConfidentialityProtectionResult,
...
}
IntegrityProtectionResult ::= ENUMERATED { performed, not-performed, ... }
SecurityResult是排障的"第一现场"：如果策略是 required 而回填 not-performed，则配置链路必然异常。
UE通过该IE声明自身支持的安全算法位图：128-NEA0/1/2/3（加密）、128-NIA0/1/2/3（完整性），其中 NIA0 为空算法（NULL）。该IE在注册时上报、在NAS SMC中被AMF回放以防降级攻击（bidding-down）。注意：当UE连接ng-eNB时，需额外置 EIA7 位表示支持与ng-eNB的UP完整性保护（TS 33.501 §6.6.4.3），Rel-15及更早UE不支持此能力。
UP完整性保护使用的密钥 KUPint 是5G密钥层级树（TS 33.501 §6.2.1）中的一个分支，由 KgNB 派生：
graph TD
K["KAUSF (主认证产出)"] --> KS["KSEAF"]
KS --> KA["KAMF (NAS SMC激活)"]
KA -->|"KDF, Annex A.9<br/>security key"| KG["KgNB (gNB级)"]
KG -->|"algorithm distinguisher + id"| RRCint["KRRCint (RRC完整性)"]
KG --> RRCenc["KRRCenc (RRC加密)"]
KG --> UPint["KUPint (UP完整性) ⬅本文焦点"]
KG --> UPenc["KUPenc (UP加密)"]
KA -.->|"KDF Annex A"| NASint["KNASint"]
KA -.-> NASenc["KNASenc"]
关键点（TS 33.501 §6.2.1、§6.6.2）：
KUPint 与 KUPenc、KRRCint、KRRCenc 都从 KgNB 用相同的KDF派生，靠算法区分符（algorithm distinguisher）+ 算法标识（algorithm identifier）区分不同用途（§6.2.2：可由ngKSI + {区分符, 标识符}唯一识别）。MESSAGE=用户面分组、KEY=KUPint、BEARER=5位承载标识、DIRECTION=1位方向、COUNT=32位PDCP COUNT，输出32位MAC-I附挂在PDCP PDU末尾。理解三值语义的差异是排障与策略设计的关键。下图给出gNB侧的决策逻辑：
stateDiagram-v2
[*] --> 收到策略
收到策略 --> 判断required: IntegrityProtectionIndication==required
收到策略 --> 判断preferred: ==preferred
收到策略 --> 强制不激活: ==not-needed
判断required --> 可激活?
可激活? --> 激活UP_IP_and_KUPint: 是(算法&能力支持)
可激活? --> 拒绝PDU_Session: 否 -> reject-cause -> SMF
判断preferred --> 可激活2?
可激活2? --> 激活UP_IP: 是
可激活2? --> 不激活_but_继续: 否(允许降级)
强制不激活 --> 不放MAC-I
激活UP_IP_and_KUPint --> 回填SecurityResult: performed
不激活_but_继续 --> 回填SecurityResult2: not-performed
一个容易被忽略的细节：策略为 preferred 时，切换后可能出现激活/去激活状态翻转（TS 33.501 §6.6.1 NOTE 2）。因此source gNB在HANDOVER REQUEST中必须携带UP安全策略，target gNB按策略重新决策，SMF在Path-Switch时还要比对gNB上报的策略与本地存储是否一致，不一致则告警并下发正确策略。
| 维度 | 4G EPS（TS 33.401） | 5GS（TS 33.501 + 38.413） |
|---|---|---|
| UP机密性保护 | 支持（加密） | 支持（加密） |
| UP完整性保护 | 不支持（仅控制面有完整性） | 支持（5G标志性增强） |
| 重放保护 | UP无 | UP支持（基于PDCP COUNT） |
| 策略粒度 | 无（全局开启加密） | 按PDU Session / DNN / 切片可配 |
| 策略三值语义 | 无 | required / preferred / not-needed |
| 速率保护 | 无 | MAXIPD（上行/下行独立） |
| 结果回填 | 无 | SecurityResult（performed/not-performed） |
| MAC-I长度 | — | 32位（PDCP PDU） |
| 算法 | — | 128-NIA1/2/3（及NIA0空算法） |
在NGAP过滤（ngap）中关注以下字段：
ngap.criticalityDiagnostics 之前的 PDU Session Resource Setup List；ngap.integrityProtectionIndication（值为 required/preferred/not-needed）；ngap.confidentialityProtectionIndication；ngap.maximumIntegrityProtectedDataRate（上行/下行）；ngap.integrityProtectionResult（performed/not-performed）。在NR RRC（rrc）中：定位 RRCReconfiguration → DRB-ToAddMod → pdcp-Config → integrityProtection（TRUE/FALSE）、ciphering。
在NR PDCP（pdcp）中：开启完整性保护后，每个用户面PDU会带 MAC-I（32-bit），可用 pdcp.mac-i 字段过滤；校验失败会触发丢弃。
UE Security Capability 中NIA位图与gNB配置的算法优先级表是否交集为空。required，gNB会直接拒绝UP资源建立并回reject-cause（§6.6.1）。需要确认UE是否支持所选NIA算法。preferred 策略下切换可能翻转激活状态；若target gNB未收到或误改策略，SMF会在Path-Switch比对时告警。需检查Xn/N2切换消息中UP安全策略是否完整透传。Not Needed（§相关条款：unauthenticated emergency call）。这是合规设计，非故障。5G UP完整性保护的本质是把"是否保护"从协议强制项变成了"可运营的策略"：协议层保证UE/gNB必须具备该能力（强制性），而激活与否交给SMF按DNN/切片/订阅决策（灵活性），并通过SecurityResult形成闭环可审计（可观测性）。这种"能力强制 + 策略可选 + 结果回填"的三段式架构，是5G安全相对4G最核心的进步之一，也是URLLC、工业互联网等场景能在公网上承载的关键前提。
Q1：UP完整性保护（integrity）和UP机密性保护（confidentiality/ciphering）有什么区别？ A：机密性（ciphering）解决"防窃听"，用KUPenc加密数据；完整性（integrity）解决"防篡改/防重放"，用KUPint计算32位MAC-I校验。两者独立配置、独立派生密钥、可单独开关。4G只有机密性，5G两者皆有。
Q2：NIA0（空算法）开启了完整性保护吗？
A：没有。NIA0是NULL算法，等同于不计算MAC-I。若DRB的 integrityProtection 未置TRUE，则gNB与UE"shall not integrity protect the traffic of such DRB and shall not put MAC-I into PDCP packet"（§6.6.2）。排错时应区分"算法是NIA0"与"完整性根本未激活"两种情况。
Q3：为什么需要Maximum Integrity Protected Data Rate？ A：UP完整性保护要求每个PDU都做MAC-I运算，对gNB基带与UE芯片CPU有开销。MAXIPD（TS 38.413 §9.3.1.103）对受保护数据速率设上限，超出部分不被完整性保护或被限速，从而在安全性与算力之间取得平衡。
Q4：切换（Xn/N2）后UP完整性保护状态会变吗？
A：策略为 required 或 not-needed 时不会变（不可被否决）；策略为 preferred 时可能翻转（§6.6.1 NOTE 2）。因此source gNB必须在HANDOVER REQUEST携带UP安全策略，target gNB按策略决策，SMF在Path-Switch比对一致性，不一致则告警并下发正确策略。
Q5：UP完整性保护对所有DRB都生效吗？ A：策略作用于一个PDU Session的所有DRB，但gNB是逐DRB激活的（§6.6.1：activate per each DRB）。同一PDU session的DRB在激活状态上应保持一致（MR-DC场景§6.10.4明确"all DRBs belonging to the same PDU session shall have the integrity protection either on or off"）。
本文由「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 等场景全覆盖。