首页 › core-network › UPU远程参数更新信令全链拆解

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。它的核心价值有三点：

密码学绑定到 KAUSF：更新材料用 AUSF 派生的密钥保护，而非用 NAS 安全上下文（基于 KAMF）保护，使得即使 AMF 被攻陷，攻击者也无法伪造或篡改更新内容；
重放防护：通过 16 位 CounterUPU 与 KAUSF 绑定，避免重放；
闭环确认：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）：

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

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 内部：

用本地存储的 KAUSF 派生 UPU 密钥输入；
读取 CounterUPU，与本地计数器比较——必须严格大于本地值才接受（新鲜性）；
重算 MAC，比对 UPU-MAC-IAUSF；
通过则写入新参数，更新本地 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 位计数器：

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）作为派生根的机制之一：

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 流程的指纹非常清晰：

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

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

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 决定重试/放弃并触发重认证。

参考来源

3GPP TS 23.502 — §4.20 UE Parameters Update via UDM Control Plane Procedure — 信令流程 Stage 2 定义
3GPP TS 33.501 — §6.15 UPU Security Mechanism / Annex A.19-A.20 KDF — UPU-MAC 计算与 CounterUPU 规范
UPU (UE Parameters Update) — 3GPP Explorer Glossary — 机制总览、跨版本变更（66 CR）
TS 33.501 §6.15.2.1 Procedure for UPU / §6.15.2.2 Counter — iTecSpec — 流程与计数器在线索引
WO2024236448A1 / WO2024161326 — Enhanced UPU Procedures — 增强 UPU（多容器、确认增强）专利解读
US20250159473 — Routing Indicator Update via UPU Procedure — 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学通信知识星球海报-扫码加入