5G 用户面完整性保护与抗重放机制拆解

聚焦 TS 33.501 §5.4 / Annex A.7、TS 38.331 pdcp-Config.integrityProtection、TS 38.323 §5.9 三个规范之间的协同，拆解从安全策略下发到 PDCP MAC-I 校验的全链路。

一、为什么 5G 必须引入"用户面完整性保护"

在 LTE 时代，空口的用户面（UP）只做加密（ciphering），不做完整性保护。这并非疏忽，而是带宽与处理能力的折衷——下行吞吐量动辄几百 Mbps，对每个 PDCP PDU 计算 4 字节 MAC-I 在早期基带芯片上是不可承受的开销。

但这一设计留下了一个被反复利用的缺口：加密只能保证"看不到"，却保证不了"改不了"。攻击者即使无法解密，也可以在空口上翻转密文比特、注入或重放 PDU，从而引发：

• aLTEr 攻击：利用 LTE 用户面缺乏完整性校验，通过中间人篡改 DNS 响应，把 UE 引导到恶意 DNS。
• 被动降级：篡改承载建立信令，迫使 UE 回落到低安全承载。
• 重放注入：重复发送已捕获的加密包，扰乱上层 TCP/QUIC 状态机。

为此，3GPP 在 TS 33.501 中为 5G NR 用户面引入了完整性保护（User Plane Integrity Protection, UPIP），并在 Release 16 将其"支持能力"提升为 UE/基站的强制实现要求（实现强制，激活仍由网络按承载决定）。本机制的规范落点横跨三个 TS，三者职责清晰：

设计意图可以一句话概括：把"是否对用户面做完整性"从一个不可协商的缺陷，变成一个网络可按 DNN/切片/承载粒度策略化决策、且 UE 一定具备能力的可控开关。

二、端到端信令时序：从策略到 MAC-I 校验

sequenceDiagram
    autonumber
    participant UDM as UDM/UDR
    participant AMF as AMF
    participant gNB as gNB
    participant UE as UE
    participant PDCP as PDCP实体

    Note over UDM,AMF: 1. 安全策略来源
    UDM->>AMF: 订阅数据含每DNN/S-NSSAI<br/>UP完整性策略(required/preferred/notNeeded)
    Note over AMF: 2. 注册流程中AMF建立安全上下文
    AMF->>UE: Authentication(5G AKA/EAP) → 建立KSEAF→KAMF
    Note over UE,gNB: 3. AS安全模式激活(SMC, TS 38.331)
    gNB->>UE: RRC SecurityModeCommand<br/>(integrity算法=NIA1/2/3, ciphering算法=NEA1/2/3)
    UE->>gNB: RRC SecurityModeComplete(含UE安全能力)
    Note over gNB: 推演: KNG-R→KRRCint, KUPint, KUPenc (Annex A.7)
    Note over AMF,gNB: 4. 下发会话建立+安全指示
    AMF->>gNB: NGAP InitialContextSetupRequest/<br/>PDUSessionResourceSetupRequest<br/>SecurityIndication{integrityProtectionRequirement=required}
    Note over UE,gNB: 5. DRB建立并激活UP完整性
    gNB->>UE: RRC Reconfiguration<br/>drb-ToAddMod{pdcp-Config{integrityProtection=enabled}}
    Note over UE,PDCP: 6. 数据面逐包校验
    UE->>PDCP: 上行PDCP Data PDU + MAC-I(4B)
    PDCP->>gNB: COUNT递增, 用KUPint重算MAC-I比对
    Note over gNB,PDCP: 失配→丢弃; COUNT越窗→丢弃(抗重放)

下面对每个阶段做 IE 级解析。

2.1 安全策略的来源与下发（TS 33.501 §5.4 + TS 38.413）

UP 完整性策略本质上是一个运营商策略，而非协议本身强制的"always on"。它的来源链是：

1. UDR/UDM：在订阅数据或本地配置中，按 (DNN, S-NSSAI) 维度存储安全策略，字段含义为该会话的用户面完整性保护要求，取值三态：required（必须）、preferred（优先）、not needed（不需要）。
2. AMF：在 PDU 会话建立/上下文建立时，通过 NGAP 把策略带给 gNB。
3. gNB：拿到 SecurityIndication 后，结合 UE 安全能力（UE 是否支持 UP 完整性）和选定的算法，决定每条 DRB 是否真的激活。

NGAP 中承载该策略的 IE（TS 38.413）：

设计要点：required 是硬约束——若 UE 不支持，gNB 应拒绝建立该承载并回告失败；preferred 是软偏好——能力允许时尽量做。这种三态设计让运营商可以为高价值切片（如 URLLC、企业专网）单独打上 required，而为海量尽力而为流量保持 not needed 以省算力。

2.2 AS 安全上下文激活（TS 38.331 SecurityModeCommand）

完整性算法的"选择"发生在 AS SMC 阶段，且控制面与用户面共用同一套算法标识。SecurityModeCommand 携带：

• securityAlgorithmConfig.integrityProtAlgorithm：NIA0/1/2/3（甚至 256-bit 变体）。
• securityAlgorithmConfig.cipheringAlgorithm：NEA0/1/2/3。

选中后，gNB 与 UE 分别用 KNG-R 推演出四把 AS 密钥（TS 33.501 §6.2 / Annex A.7）：

flowchart LR
    KAMF[KAMF] --> KNGR[K<sub>NG-R</sub><br/>gNB根密钥]
    KNGR --> KRRCCenc[K<sub>RRC-enc</sub>]
    KNGR --> KRRCint[K<sub>RRC-int</sub>]
    KNGR --> KUPenc[K<sub>UP-enc</sub>]
    KNGR --> KUPint[K<sub>UP-int</sub>]
    KUPint -.加密算法identity+NIA算法.-> MAC[MAC-I计算]

    style KUPint fill:#ffe0b2,stroke:#e65100
    style MAC fill:#c8e6c9,stroke:#2e7d32

KDF 推演（Annex A.7）的输入串结构为标准 3GPP Key Derivation Function 形式：

S = FC(0x69) || Algorithm_Type(1B) || Algorithm_Identity(1B) || L0(2B) || L1(2B)
Key = HMAC-SHA-256( K_NG-R , S )   // 截取低128/256bit

• Algorithm_Type：加密=0x01，完整性=0x02。
• Algorithm_Identity：0/1/2/3 对应 NIA0/1/2/3。

因此 KUPint 与 KRRCint 推演公式相同，仅 Algorithm_Type 区分用途——这是规范刻意复用，保证算法切换时四把密钥同步刷新。

2.3 每 DRB 激活：RRC 配置（TS 38.331）

算法选好后，是否对某条 DRB 实际生效，取决于 RRCReconfiguration 中 drb-ToAddMod 内的 PDCP 配置：

R15 与 R16 的关键差异在于适用范围：

flowchart TB
    subgraph R15
        A1[DRB-RLC AM] -->|支持UP完整性| B1[integrityProtection可选]
        A2[DRB-RLC UM] -->|不支持| C1[仅加密]
    end
    subgraph R16
        D1[DRB-RLC AM] -->|支持| E1[integrityProtection]
        D2[DRB-RLC UM] -->|R16扩展支持| E2[integrityProtection]
    end
    style B1 fill:#fff9c4
    style E2 fill:#c8e6c9

• R15：UP 完整性仅对 RLC AM（确认模式） 的 DRB 可选激活；RLC UM（非确认，典型用于 VoNR/视频）不能做完整性。
• R16：扩展到 RLC UM 也可激活完整性，并要求 UE 必须支持 UP 完整性（实现强制）。这样 VoNR 等时延敏感承载也能获得防篡改保护。

这是为什么 VoNR 的安全等级在 R16 之后显著提升——之前的 IMS RTP 流在空口只加密、可被比特翻转，R16 后可同时做完整性。

三、PDCP 执行机制：MAC-I 与 COUNT（TS 38.323 §5.9）

完整性保护与抗重放的实际执行在 PDCP 子层。其工作模型由两个核心概念支撑：MAC-I 与 COUNT。

3.1 MAC-I 的计算

MAC-I（Message Authentication Code – Integrity）是 4 字节的认证标签，PDCP 实体对每一个数据 PDU 独立计算并附加在 PDU 末尾。计算输入（TS 38.323 §5.9）：

MAC-I = F( KEY = K_UPint ,
           BEARER = RB_Identity ,
           DIRECTION = 0(上行)/1(下行) ,
           COUNT = HFN || PDCP_SN ,
           MESSAGE = PDCP_DataPDU_without_MAC-I )

其中：

• KEY：即上节推演的 KUPint（128 或 256 bit）。
• BEARER：承载标识，防止跨承载重放。
• DIRECTION：方向位，防止上下行混淆。
• COUNT：32 bit 的包计数器，单调递增，是抗重放的核心。
• 算法函数 F：NIA1（基于 SNOW 3G，等同 128-EIA1）、NIA2（基于 AES-CMAC，等同 128-EIA2）、NIA3（基于 ZUC，等同 128-EIA3）。NIA0 为空算法，仅在特殊测试场景使用。

接收端用同样的输入重算 MAC-I'，与收到的 MAC-I 比对：不一致 → 丢弃该 PDU 并触发安全违规计数。

3.2 COUNT 与抗重放窗口

flowchart TD
    subgraph COUNT["COUNT (32 bit)"]
        HFN["HFN 超帧号 (高位)"] --- SN["PDCP_SN 序列号 (12/18 bit)"]
    end
    COUNT -->|每发/收一个PDU| INC["COUNT += 1 (单调递增)"]
    INC --> RX["接收端维护重排序/接收窗口"]
    RX -->|PDU COUNT落在窗口内且已收过| DROP["丢弃=抗重放"]
    RX -->|COUNT落在窗口内未收过| ACCEPT["接收+校验MAC-I"]
    RX -->|COUNT落后于窗口下沿| DROP2["丢弃=乱序超窗"]

    style DROP fill:#ffcdd2,stroke:#c62828
    style DROP2 fill:#ffcdd2,stroke:#c62828
    style ACCEPT fill:#c8e6c9,stroke:#2e7d32

COUNT = HFN（高位）|| PDCP SN（低位）。SN 在 PDCP 头中明文携带（12 bit 或 18 bit），HFN 不在空口传输，由收发两端根据 SN 回卷自行维护，这正是为何完整性必须用 COUNT 而非裸 SN——HFN 由双方各自维护、攻击者无法从空口推断，从而 COUNT 成为"双方共享的秘密序号"。

接收端维护一个接收/重排序窗口（受 t-Reordering 控制）：

• 收到的 PDU COUNT 若已落在窗口内且之前收过 → 判定为重放，丢弃。
• 若落后于窗口下沿 → 判定为迟到的乱序包，丢弃（防止攻击者重放旧包挤入）。
• 若在窗口内且未收过 → 接收并校验 MAC-I。

这套机制同时提供了完整性（防篡改）与抗重放（防复制注入）两重防护，且二者共用同一 COUNT 基础设施。

四、R15 / R16 / EPS 能力对比

五、抓包识别与故障排查

5.1 如何在抓包中确认 UP 完整性已激活

1. NGAP 层：在 InitialContextSetupRequest 或 PDUSessionResourceSetupRequest 中查找 SecurityIndication，确认 integrityProtectionRequirement 值；在反向 Security Result 中确认 integrityProtectionResult = performed。
2. RRC 层：在 RRCReconfiguration → drb-ToAddMod[*].pdcp-Config 中确认 integrityProtection 字段是否存在；同时核对 securityAlgorithmConfig 中 SMC 选定的 NIA 算法。
3. PDCP 层：数据 PDU 末尾多出 4 字节 MAC-I；若开启完整性但加密关闭，可见明文 payload + 4B MAC-I，便于校验。

5.2 常见故障点

Q1：用户面完整性保护开启后，为什么还要单独保留加密？二者职责不同吗？ A：是的。完整性（integrity）防篡改、防重放，加密（confidentiality）防窃听。两者在 TS 33.501 中是独立配置的（integrityProtectionRequirement 与 confidentialityProtectionRequirement 分开），用不同密钥（KUPint 与 KUPenc）。一个会话可以"只加密不完整"（R15 常见）、"只完整性不加密"（如调试明文场景，cipheringDisabled）、或"两者都开"（R16 安全首选）。这种正交设计让运营商能按需组合。

Q2：为什么用户面完整性在 LTE 时代没有，却成了 5G R16 的强制实现项？ A：核心驱动是 aLTEr 等中间人攻击被公开披露，证明"只加密不完整性"不足以抵御密文翻转/注入；同时基带芯片算力提升使每包 MAC-I 开销可接受。3GPP 顺势在 R16 将"UE/基站必须支持 UP 完整性"写入实现要求，但激活与否仍由网络按策略决定，避免一刀切造成性能损失。

Q3：MAC-I 是明文发送的，攻击者能看到，这安全吗？ A：MAC-I 的安全性依赖 KUPint 与 COUNT 的保密性，而非 MAC-I 本身的保密。KUPint 由双方各自推演、从不在空口传输；COUNT 中的 HFN 也不在空口传输（仅 SN 明文）。攻击者即便看到 MAC-I，没有密钥也无法伪造出能通过校验的新 MAC-I，也无法构造合法的重放包（被窗口机制拦截）。

Q4：激活 UP 完整性后，COUNT 回卷（wraparound）会有什么风险？ A：当 PDU 计数达到 COUNT 上限（32 bit），若继续使用同一密钥，COUNT 将回卷，理论上有重用相同 (KEY, COUNT) 对的风险。规范要求在接近回卷前刷新密钥（重新执行 AS 安全上下文建立或密钥刷新过程），保证 (KEY, COUNT) 对不重复使用，这是密码学安全的硬性前提。

Q5：VoNR 的 RTP 流在 R15 和 R16 下安全等级有何不同？ A：VoNR 承载通常是 RLC UM（低时延）。R15 下 UM 不支持 UP 完整性，所以 RTP 仅被加密，存在被比特翻转篡改的风险；R16 扩展了 UM 完整性支持后，VoNR 可同时获得完整性与抗重放保护，安全等级显著提升——这也是 R16 在语音安全上的一个重要进步。

参考来源

1. 3GPP TS 33.501 — Security architecture and procedures for 5G system — §5.4 用户面安全要求、§6.2 与 Annex A.7 AS 密钥推演（KUPint 等）
2. ETSI TS 138 323 V19.0.0 — NR; PDCP specification — §5.9 完整性保护与校验、COUNT/MAC-I 机制
3. 3GPP TS 38.331 — NR RRC — drb-ToAddMod.pdcp-Config.integrityProtection、SecurityModeCommand 算法配置
4. ShareTechnote — 5G PDCP — PDCP MAC-I、SN/HFN 与完整性图解
5. 5G6G Academy — NEA and NIA: 5G Encryption and Integrity Protection Algorithms — NIA1/2/3 算法族与 R16 强制支持说明
6. 3glteinfo — 5G PDCP Ciphering and Integrity Protection — COUNT/BEARER/DIRECTION/KEY 输入与 MAC-I 计算分析

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