<!-- title: 5G用户面完整性保护机制拆解 -->
<!-- domain: security -->

# 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，三者职责清晰：

| 规范 | 角色 | 关键章节 |
|------|------|----------|
| **TS 33.501** | 安全架构与需求、密钥推演、算法 | §5.4、§6.2、Annex A.7 |
| **TS 38.413** | 核心网向基站下发安全策略 | `SecurityIndication` IE |
| **TS 38.331** | RRC 配置每条 DRB 的 PDCP 安全 | `drb-ToAddMod.pdcp-Config` |
| **TS 38.323** | PDCP 实体执行 MAC-I 计算与抗重放 | §5.9、§5.10 |

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

---

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

```text
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）：

| IE 名称 | 关键子字段 | 取值 | 含义 |
|---------|-----------|------|------|
| `SecurityIndication` | `integrityProtectionRequirement` | required / preferred / not-needed | 网络对该会话用户面完整性的硬性要求 |
| `SecurityIndication` | `confidentialityProtectionRequirement` | required / preferred / not-needed | 加密要求（独立配置） |
| `SecurityResult`（gNB→AMF 回告） | `integrityProtectionResult` | performed / not performed | gNB 实际激活结果，供 AMF 记账/计费 |

> 设计要点：`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）：

```mermaid
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 配置：

| IE 路径 | 字段 | 作用 |
|---------|------|------|
| `drb-ToAddMod` | `pdcp-Config` | 该 DRB 的 PDCP 安全参数容器 |
| `pdcp-Config` | `integrityProtection` | present=激活完整性（DRB） |
| `pdcp-Config` | `cipheringDisabled` | 显式关闭加密（如空口明文调试/特殊场景） |
| `pdcp-Config` | `sdap-Config` / `rlc-Mode` | 关联 RLC AM/UM 模式 |

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

```mermaid
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 与抗重放窗口

```mermaid
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 能力对比

| 维度 | EPS (LTE) | 5G NR R15 | 5G NR R16/R17+ |
|------|-----------|-----------|----------------|
| 用户面完整性 | **无**（仅加密） | 可选，仅 RLC AM | **实现强制**，AM+UM 均支持 |
| 用户面加密 | 可选 | 可选（可关） | 可选，可与完整性独立配置 |
| 控制面完整性 | 强制 | 强制 | 强制（256-bit 算法可选） |
| 算法 | EIA1/2/3 | NIA1/2/3（同基底） | NIA1/2/3 + 256-bit NIA |
| 抗重放 | 仅 CP | CP+UP(激活时) | CP+UP(激活时) |
| 策略粒度 | 无 | 每 DNN/S-NSSAI | 每 DNN/S-NSSAI |

---

## 五、抓包识别与故障排查

### 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 常见故障点

| 现象 | 可能原因 | 排查思路 |
|------|----------|----------|
| 大量 PDCP PDU 丢弃，TCP 吞吐骤降 | MAC-I 校验失败（密钥不同步） | 检查 SMC 算法协商、KNG-R 刷新时机、是否发生 intra-gNB DU change 未刷新 |
| 注册成功但 DRB 建立失败 | 策略 `required` 但 UE 能力不支持 | 查 NGAP `UE Security Capability` 是否含 UP 完整性能力；确认 UE R16 支持位 |
| 切换后少量包丢失 | 切换瞬间 COUNT/HFN 未同步 | 检查源/目标 gNB 间 PDCP COUNT 转发、HO Command 中安全配置 |
| 基带 CPU 占用升高 | NIA2(AES)在高吞吐下开销大 | 评估算法选型，URLLC 切片可保留，海量 eMBB 可设 `preferred` |
| VoNR 偶发杂音 | R15 UE 不支持 UM 完整性却被配 `required` | 确认 UE R 版本；R15 UE 的 UM 承载不应强制完整性 |
## 六、常见问题

**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](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169) — §5.4 用户面安全要求、§6.2 与 Annex A.7 AS 密钥推演（KUPint 等）
2. [ETSI TS 138 323 V19.0.0 — NR; PDCP specification](https://www.etsi.org/deliver/etsi_ts/138300_138399/138323/19.00.00_60/ts_138323v190000p.pdf) — §5.9 完整性保护与校验、COUNT/MAC-I 机制
3. [3GPP TS 38.331 — NR RRC](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3197) — `drb-ToAddMod.pdcp-Config.integrityProtection`、SecurityModeCommand 算法配置
4. [ShareTechnote — 5G PDCP](https://www.sharetechnote.com/html/5G/5G_PDCP.html) — PDCP MAC-I、SN/HFN 与完整性图解
5. [5G6G Academy — NEA and NIA: 5G Encryption and Integrity Protection Algorithms](https://www.5g6gacademy.com/learn/5g-encryption-algorithms) — NIA1/2/3 算法族与 R16 强制支持说明
6. [3glteinfo — 5G PDCP Ciphering and Integrity Protection](https://www.3glteinfo.com/5g/protocols/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 等场景全覆盖。

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