<!-- title: UPU远程参数更新信令全链拆解 -->
<!-- domain: core-network -->

# 5G UPU 控制面远程参数更新（UE Parameters Update）信令全链拆解

> 本文聚焦 3GPP **TS 23.502 §4.20「UE Parameters Update via UDM Control Plane Procedure」** 与 **TS 33.501 §6.15 安全机制**，逐信令、逐 IE 拆解 5GC 如何在不换卡、不重注册的前提下，远程改写 USIM 中的关键参数（如 Routing Indicator、Default Configured NSSAI、协议参数等），并分析其抗 AMF 攻陷的设计意图。

---

## 一、为什么需要 UPU：一个被低估的"空中重写 USIM"机制

在 2G/3G/4G 时代，USIM 中的长效参数（Routing Indicator、HPLMN 信息、配置 NSSAI、USAT 安全参数等）一旦烧录即固化，除非物理换卡或 OTA（Over-The-Air，基于 SMS 的 USAT 应用）下发。这两种路径各有硬伤：换卡是运营商的物流灾难；传统 SMS-OTA 则受制于 SMS 通道的可达性与 USAT 应用的实现差异，且**无法与 5G NAS 安全上下文绑定**，存在被伪造或重放的风险。

5G 在 **Release 15** 引入了 **UPU（UE Parameters Update）**，作为 AUSF 提供的 `Nausf_UPUProtection` 服务（TS 29.509）。它由 **UDM 决策、AUSF 出具密码材料、AMF 仅做透传**，最终通过 **N1 NAS 信令**送达 USIM。它的核心价值有三点：

1. **密码学绑定到 KAUSF**：更新材料用 AUSF 派生的密钥保护，而非用 NAS 安全上下文（基于 KAMF）保护，使得即使 AMF 被攻陷，攻击者也无法伪造或篡改更新内容；
2. **重放防护**：通过 16 位 `CounterUPU` 与 KAUSF 绑定，避免重放；
3. **闭环确认**：UE 应用更新后回送 `UPU-MAC-IUE`，AUSF 可验证更新是否真正落地。

UPU 在架构上与 **SoR（Steering of Roaming，TS 33.501 §6.14）** 是一对"孪生机制"——同样的"AUSF 计算 MAC + Counter + 透传 + UE 确认"模式，只是 SoR 改写的是漫游引导列表，UPU 改写的是 USIM 长效参数。理解 UPU，几乎是理解 5G 这类"网络对 USIM 的单向安全控制通道"的范本。

---

## 二、核心安全材料：四个关键字段

在进入信令流之前，必须先厘清 AUSF 为 UPU 准备的四个密码学量（TS 33.501 §6.15.2、Annex A.19/A.20）：

| 安全材料 | 计算方 | 用途 | 备注 |
|---|---|---|---|
| **UPU-MAC-IAUSF** | AUSF | 网络对 UPU data 的完整性 MAC，UE 侧验证 | 类似 SoR-MAC-IAUSF |
| **CounterUPU** | AUSF/UE 共同维护 | 16 位计数器，防重放、保证新鲜性 | 与 KAUSF 绑定 |
| **UPU-XMAC-IUE** | AUSF | AUSF 预计算的"期望 MAC"，用于验证 UE 确认 | 可选，仅在请求确认时生成 |
| **UPU-MAC-IUE** | UE（USIM） | UE 应用更新后回送的确认 MAC | AUSF 用 XMAC 对比验证 |

**密钥派生关系**（KDF，TS 33.501 Annex A.19/A.20）：

```mermaid
flowchart TD
    K["KAUSF<br/>(主认证派生)"] --> KDF1["KDF<br/>A.19/A.20"]
    CT["CounterUPU"] --> KDF1
    UD["UPU data<br/>(待更新参数)"] --> KDF1
    KDF1 --> MAC1["UPU-MAC-IAUSF"]
    KDF1 --> XMAC["UPU-XMAC-IUE (可选)"]
    MAC1 -.被 AMF 透传.-> UE["UE/USIM"]
    UE --> KDF2["USIM 侧 KDF<br/>(本地 KAUSF)"]
    KDF2 --> VMAC["校验 UPU-MAC-IAUSF"]
    KDF2 --> EMAC["UPU-MAC-IUE"]
    EMAC -.回送.-> AUSF2["AUSF<br/>对比 XMAC"]
```

关键设计：**AMF 全程不接触 KAUSF，也不参与 MAC 计算**。AMF 看到的只是"一段由 AUSF 包装好的密文/MAC + Counter"，只能原样透传给 UE。这正是 UPU 抗 AMF 攻陷的根基。

---

## 三、完整信令时序图

下图描述网络发起、请求确认（Requested Acknowledgement = true）的完整链路（TS 23.502 §4.20.2 + TS 33.501 §6.15.2.1）：

```mermaid
sequenceDiagram
    autonumber
    participant USIM as UE / USIM
    participant AMF as AMF (N1)
    participant UDM as UDM
    participant AUSF as AUSF
    participant UDR as UDR

    Note over UDR,AUSF: 前提：UE 已通过 5G-AKA 完成主认证，<br/>KAUSF 已在 AUSF 与 USIM 两侧建立
    UDR->>UDM: 订阅/策略变更<br/>(如 Routing Indicator 需更新)
    UDM->>AUSF: Nausf_UPUProtection<br/>Result(compute): UPU data, RequestedAck=TRUE
    Note over AUSF: ① 派生 Kausf_input<br/>② CounterUPU += 1<br/>③ 计算 UPU-MAC-IAUSF<br/>④ (可选)UPU-XMAC-IUE
    AUSF-->>UDM: UPU-MAC-IAUSF, CounterUPU,<br/>UPU-XMAC-IUE, UPUMACIAUSF
    UDM->>AMF: Namf_Communication_N1MessageNotify<br/>(含 UPU data: UPU-MAC-IAUSF+CounterUPU+待更新参数)
    Note over AMF: AMF 不解密、不校验，<br/>仅封装为 NAS 消息透传
    AMF->>USIM: DL NAS TRANSPORT<br/>(UPU data container)
    Note over USIM: ① 用本地 KAUSF 派生<br/>② 校验 CounterUPU 新鲜<br/>③ 校验 UPU-MAC-IAUSF
    Note over USIM: 验证通过 → USIM 写入新参数<br/>(Routing Indicator/NSSAI 等)
    USIM->>USIM: 计算 UPU-MAC-IUE
    USIM-->>AMF: UL NAS TRANSPORT<br/>(UPU-MAC-IUE)
    AMF-->>UDM: Nudm_UECM / N1 报告<br/>(UPU ack: UPU-MAC-IUE)
    UDM->>AUSF: Nausf_UPUProtection<br/>Verify(UPU-MAC-IUE, CounterUPU)
    Note over AUSF: UPU-MAC-IUE ?= UPU-XMAC-IUE
    AUSF-->>UDM: Verify Result (成功/失败)
    alt 验证失败 / 未收到 ack
        UDM->>AUSF: 触发重新认证 (Re-authentication)
        Note over AUSF,USIM: 重新执行 5G-AKA → 新 KAUSF<br/>CounterUPU 在 UE 侧重置为 0x0000
    end
```

---

## 四、逐信令、逐 IE 解析

### 步骤 1：UDM 决策与 AUSF 算料（Nausf_UPUProtection）

UDM 在 UDR 中订阅数据变更（如 `RoutingIndicator`、`DefaultConfiguredNssai`、`UeRadioPagingPriority` 等）。决策更新后，UDM 作为 `Nausf_UPUProtection` 的消费者，调用 **`Result`（compute）** 服务操作，向 AUSF 提交：

| 输入 IE | 含义 |
|---|---|
| `UpuData` | 待更新参数的明文/封装容器（最终会下发给 USIM） |
| `UpuHeaderInd` | 是否包含 UPU 头（影响 USIM 解析格式） |
| `RequestedAck` | 是否请求 UE 确认（true 时 AUSF 才生成 UPU-XMAC-IUE） |

AUSF 返回字段（TS 29.509 响应体）：

| 输出 IE | 含义 |
|---|---|
| `UpuMacIausf` | 网络侧完整性 MAC |
| `CounterUpu` | 本次递增后的计数器（16 位） |
| `UpuXmacIue` | 仅 RequestedAck=true 时返回，用于后续验证 UE 确认 |

> **设计意图**：把"算 MAC"这一高敏感操作收敛到 AUSF，使 UDM 也不直接持有 KAUSF 的派生密钥输入的全部算力路径——UDM 持有签约，AUSF 持有认证态与计数器，职责分离。

### 步骤 2：UDM → AMF（Namf_Communication_N1MessageNotify）

UDM 把 `UpuData`、`UpuMacIausf`、`CounterUpu` 打包，通过 **`Namf_Communication_N1MessageNotify`** 通知 UE 当前注册的服务 AMF。注意 UDM 也可通过 `Nudm_UECM`（注册管理）服务中携带 N1 消息容器下发。

### 步骤 3：AMF → UE（DL NAS TRANSPORT）

AMF 把容器封装进 **DL NAS TRANSPORT** 消息（TS 24.501）。此时 **PDU Session ID 字段不填**（纯 NAS 携带），消息体含一个特殊的 payload container type 指向 **UPU data**：

| NAS IE | 编码要点 |
|---|---|
| Extended protocol discriminator | 5GMM（0x7E） |
| PDU session ID | 不存在（absent） |
| Payload container type | 指示为 UPU data |
| Payload container | 内嵌 UpuData + UpuMacIausf + CounterUpu |

> **关键**：这一段 NAS 消息虽然整体受 NAS 安全上下文（KAMF）的机密性/完整性保护，但**UPU 内层 MAC（UPU-MAC-IAUSF）是独立的、基于 KAUSF 的二重保护**。即使 NAS 加密层被剥离，攻击者仍无法伪造内层 MAC。

### 步骤 4：USIM 校验与写卡

UE 的 NAS 层收到后，将内层容器**透交给 USIM 应用**（因为目标参数存储在 USIM）。USIM 内部：

1. 用本地存储的 KAUSF 派生 UPU 密钥输入；
2. 读取 `CounterUPU`，与本地计数器比较——必须**严格大于**本地值才接受（新鲜性）；
3. 重算 MAC，比对 `UPU-MAC-IAUSF`；
4. 通过则写入新参数，更新本地 `CounterUPU`，并计算 `UPU-MAC-IUE`。

### 步骤 5：UE → AMF（UL NAS TRANSPORT）回送确认

UE 通过 **UL NAS TRANSPORT** 上报 `UPU-MAC-IUE`（仅当网络请求确认时）。

### 步骤 6：AUSF 验证确认（Verify）

AMF 将 `UPU-MAC-IUE` 经 UDM 回送至 AUSF，AUSF 执行 **`Verify`** 服务操作，比较 `UPU-MAC-IUE` 与预先计算的 `UPU-XMAC-IUE`。一致即更新闭环成功。

### 步骤 7：失败与恢复（Counter 失同步）

若 USIM 校验失败（如换卡后计数器落后、KAUSF 失同步）、或确认超时未到，UDM 不会无限重试，而是触发**重新认证（Re-authentication）**：重新执行 5G-AKA 后派生新的 KAUSF，UE 侧按 §6.2.2.2 将 `CounterUPU` **重置为 0x0000**，从而重新对齐。

---

## 五、CounterUPU 状态转换图

`CounterUPU` 是 UPU 防重放的核心。它是一个与 KAUSF 生命周期绑定的 16 位计数器：

```text
stateDiagram-v2
    [*] --> Zero: 主认证完成<br/>新 KAUSF 存储<br/>CounterUPU=0x0000
    Zero --> Incremented: 收到合法 UPU<br/>AUSF: +1, UE: 校验后写新值
    Incremented --> Incremented: 后续每次 UPU 继续递增
    Incremented --> Mismatch: 校验失败/换卡/失同步
    Mismatch --> Zero: 触发重新认证<br/>新 KAUSF<br/>UE 侧重置 0x0000
    note right of Mismatch
        CounterUPU 必须
        严格大于本地值，
        否则拒绝（防重放）
    end note
```

注意 16 位计数器的**理论上限（65535）**：在极端长期不换卡场景下需关注回绕，实际部署中以重新认证重置为常态路径。

---

## 六、UPU vs SoR 孪生机制对比

UPU 与 SoR 共享同一套"AUSF 算 MAC + Counter + 透传 + 确认"范式，是 5G 安全架构中可复用的设计模式：

| 维度 | UPU（TS 33.501 §6.15） | SoR（TS 33.501 §6.14） |
|---|---|---|
| **触发网元** | UDM（参数/签约变更） | UDM/HPLMN（漫游引导） |
| **被改写对象** | USIM 长效参数（Routing Indicator、NSSAI 等） | 漫游引导列表（OPLMNwACT 等） |
| **承载 NAS 消息** | DL/UL NAS TRANSPORT（UPU data） | DL/UL NAS TRANSPORT（SoR data） |
| **MAC 名称** | UPU-MAC-IAUSF / UPU-MAC-IUE | SoR-MAC-IAUSF / SoR-MAC-IUE |
| **Counter** | CounterUPU（与 KAUSF 绑定） | CounterSoR（与 KAUSF 绑定） |
| **计算位置** | AUSF（Nausf 服务） | AUSF（Nausf 服务） |
| **AMF 角色** | 透传，不可伪造 | 透传，不可伪造 |
| **是否请求确认** | 可选（RequestedAck） | 可选（同样有 ack 模式） |
| **典型应用** | 远程重写 Routing Indicator（Rel-16 新增） | 引导漫游终端优选 HPLMN 合作运营商 |

二者唯一的实质差异是**语义/改写目标**不同，密码学框架完全同构。这也意味着厂商实现时常常复用同一套"AUSF MAC 计算引擎"。

---

## 七、密钥层级与 KAUSF 的"二跳"使用

理解 UPU 必须把它放进 5G 密钥层级看。UPU 是少数**直接复用 KAUSF（而非 KAMF）**作为派生根的机制之一：

```mermaid
flowchart TD
    K["K (长效主密钥, USIM/UDM)"] --> AKA["5G-AKA / EAP-AKA'<br/>主认证"]
    AKA --> KAUSF["KAUSF"]
    KAUSF --> KSEAF["KSEAF → KAMF<br/>(常规 NAS/RRC/UP 安全)"]
    KAUSF --> SOR["SoR 密钥派生<br/>SoR-MAC"]
    KAUSF --> UPU["UPU 密钥派生<br/>UPU-MAC / CounterUPU"]
    KAMF -.AMF 攻陷不影响.-> UPU
    style UPU fill:#d4edda,stroke:#28a745
    style KAUSF fill:#fff3cd,stroke:#ffc107
```

这是 UPU 安全性的命门：**KAUSF 是锚点，UPU 从 KAUSF 直接分叉**，跳过了 KAMF/KSEAF 这一层。因此即使整个服务 PLMN 的 AMF 被攻破，攻击者拿到的也只是 KAMF 系列密钥，无法推回 KAUSF，自然无法伪造 UPU。

---

## 八、实战：抓包识别与排错

### 8.1 抓包识别（Wireshark/TShark）

在 NGAP/NAS 抓包中，UPU 流程的指纹非常清晰：

1. **无 PDU Session ID 的 DL NAS TRANSPORT**：在 N2（NGAP `DownlinkNASTransport`）+ NAS 层，看到 `Payload container type = UPU data`（区别于 5GMM/5GSM/SM/LCS 等类型）；
2. **紧随的 UL NAS TRANSPORT** 携带 `UPU-MAC-IUE`（若请求确认）；
3. 在 SBI（HTTP/2）抓包侧，可看到 `POST .../nausf-upuprotection/{apiVersion}/.../upu/result` 与 `/upu/verify`（Nausf_UPUProtection 服务），以及 UDM 对 AMF 的 `N1MessageNotify`。

一条 TShark 检索示例（N1 侧）：

```bash
tshark -r upu.pcap -Y 'nas-5gs.message_type==0xD7 && nas_5gs.payload_container_type==...' -V
```

### 8.2 常见故障点

| 故障现象 | 可能根因 | 排错思路 |
|---|---|---|
| UE 不应用更新、无 UL 确认 | `CounterUPU` 失同步（USIM 计数器 > 网络侧，或反向） | 检查 USIM 是否换过卡/做过重置；触发重新认证对齐 |
| UE 回送确认但 AUSF `Verify` 失败 | KAUSF 在 USIM 与 AUSF 两侧不一致（如认证态丢失） | 核对主认证是否成功、KAUSF 是否被错误重派生 |
| AMF 收到 N1MessageNotify 但不下发 | UE 处于 CM-IDLE 且 AMF 无法寻呼，或 DL NAS 通道未建 | AMF 应在 UE 可达时下发；否则 UDM 重试或等下次注册 |
| 更新后 Routing Indicator 不生效 | USIM 应用未实现 UPU 处理（旧卡） | 确认 USIM 卡版本支持 UPU（Rel-15+）；不支持时退化为不更新 |
| 反复 UPU 失败导致频繁重认证 | AUSF/UDM 间 Counter 状态不一致 bug | 核对 AUSF 中持久化的 CounterUPU 与 UDR 签约状态 |
## 九、常见问题

**Q1：UPU 和传统 SMS-OTA（USAT）远程写卡有什么本质区别？**
A：SMS-OTA 走 SMS 承载，依赖 USAT 应用与卡上安全域，安全性受限于 SMS 通道与 OTA 密钥；UPU 走 N1 NAS 信令，密码材料由 AUSF 基于 KAUSF 计算，**与 5G 主认证密钥层级绑定**，AMF 不可伪造，且自带 CounterUPU 防重放与闭环确认，安全性量级更高。

**Q2：为什么 UPU 用 KAUSF 而不用 KAMF？**
A：因为 AMF 是服务 PLMN 网元（尤其漫游时属 VPLMN），属较低信任域。KAMF 派生自 KAUSF，若用 KAMF 保护 UPU，则 AMF 攻陷即可伪造更新。UPU 直接从 KAUSF 分叉（TS 33.501 Annex A.19/A.20），使更新只对 HPLMN 的 AUSF 与 UE 的 USIM 可见，这是"AMF 不可信"安全模型的直接体现。

**Q3：CounterUPU 失同步后如何恢复？**
A：USIM 侧的 CounterUPU 必须严格小于网络侧下发值。一旦失同步（换卡、USIM 计数器被写大、或 KAUSF 失配），UPU 校验失败，UDM 触发**重新认证**；新的 5G-AKA 派生新 KAUSF，USIM 按 §6.2.2.2 将 CounterUPU 重置为 `0x0000`，重新对齐。

**Q4：UPU 一次能更新哪些参数？**
A：典型包括 **Routing Indicator**（Rel-16 重点增强）、**Default Configured NSSAI**、HPLMN/优先 PLMN 信息、部分 USIM 安全参数等。具体由 UDM 的 `UpuData` 决定，受 USIM 应用能力限制。

**Q5：AMF 在 UPU 流程中会不会成为瓶颈或单点？**
A：AMF 仅做透传，不做密码运算，开销极小；但它决定下发时机——若 UE 处于 CM-IDLE，AMF 需先寻呼建链。如果长时间不可达，UPU 会延迟到下次注册/服务请求时下发，或由 UDM 决定重试/放弃并触发重认证。

---

## 参考来源

1. [3GPP TS 23.502 — §4.20 UE Parameters Update via UDM Control Plane Procedure](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — 信令流程 Stage 2 定义
2. [3GPP TS 33.501 — §6.15 UPU Security Mechanism / Annex A.19-A.20 KDF](https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.10.00_60/ts_133501v181000p.pdf) — UPU-MAC 计算与 CounterUPU 规范
3. [UPU (UE Parameters Update) — 3GPP Explorer Glossary](https://3gpp-explorer.com/glossary/upu/) — 机制总览、跨版本变更（66 CR）
4. [TS 33.501 §6.15.2.1 Procedure for UPU / §6.15.2.2 Counter — iTecSpec](https://itecspec.com/3gpp/33.501/s/6.15.2.1) — 流程与计数器在线索引
5. [WO2024236448A1 / WO2024161326 — Enhanced UPU Procedures](https://patents.google.com/patent/WO2024236448A1/en) — 增强 UPU（多容器、确认增强）专利解读
6. [US20250159473 — Routing Indicator Update via UPU Procedure](https://patents.justia.com/patent/20250159473) — Routing Indicator 远程更新的具体实施

---

> 本文由「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)