# 5G 漫游引导（Steering of Roaming, SoR）安全机制全链拆解 > 聚焦 **3GPP TS 33.501 §6.14（Rel-18/20）** 中定义的 **Steering of Roaming（SoR，漫游引导）安全机制**，并结合 TS 23.122、TS 24.501、TS 29.509、TS 31.102，逐信令拆解归属网（HPLMN）如何在不信任的访问网（VPLMN）链路上，把"优选漫游伙伴 PLMN 列表"安全地下发到 UE，同时杜绝伪造与重放。 --- ## 一、问题背景：为什么漫游引导必须"上锁" 当 UE 漫游到 VPLMN 时，其 PLMN 选择行为（TS 23.122）依赖 USIM/ME 中存储的 **"operator controlled PLMN selector with access technology"（操作员控制的 PLMN+接入技术选择列表）**。这份列表直接决定 UE 排队优选哪个漫游伙伴——这对归属网具有**强商业价值**（结算价、QoS、合作战略）。 问题在于：下发这条列表的链路必然经过 **VPLMN（AMF）**，而 VPLMN 在商业博弈上是**不可信的**——它有动机让 UE 一直驻留在自己身上赚取漫游费，或者一个伪基站（IMSI catcher）更可以直接伪造一个"劣质"列表把 UE 钉死在某个网络。如果不加保护，就存在三类攻击： 1. **伪造注入**：恶意/竞争网络注入虚假 PLMN 列表，把 UE 引导到高成本或受控网络； 2. **重放**：把归属网历史上某次"对自己有利"的列表反复重放，使 UE 永远选不到更优伙伴； 3. **窃听**：商业敏感的"优选伙伴排名"被 VPLMN 旁路读取。 SoR 安全机制（TS 33.501 §6.14）正是为同时封堵这三种攻击而设计：用 **MAC 保证真实性**、用 **Counter 保证新鲜性**、用 **可选加密保证保密性**。 --- ## 二、安全架构与密钥层级 SoR 的密码学根是主鉴权锚点密钥 **KAUSF**（5G AKA / EAP-AKA' 阶段由永久密钥 K 派生），而**不是**访问域的 KAMF/KgNB。这是设计上的关键选择——KAMF 由 VPLMN 的 AMF 持有，用它保护 HPLMN→UE 的内容等于"让嫌疑人保管证据"。KAUSF 只存在于 **AUSF（HPLMN）** 与 **UE（USIM/ME）** 两端，VPLMN 全程无感。 ```mermaid flowchart TD K["K 永久密钥
USIM ↔ AUSF/UDM"] --> KAUSF["KAUSF
主鉴权锚点密钥"] KAUSF -->|KDF Annex A.6| KI["KSOR-int
完整性密钥"] KAUSF -->|KDF Annex A.6| KE["KSOR-enc
保密性密钥(可选)"] KI --> MAC["SoR-MAC-IAUSF
= AES-CMAC(KSOR-int, 待保护内容)"] KE --> ENC["AES 加密 SoR List
(对 VPLMN 不可见)"] KAUSF -.同源派生.-> OTHER["KSEAF→KAMF→KgNB
(接入域信令/数据面, 另一条路径)"] KAUSF -.同源派生.-> UPU["KUPU-int/enc
(UE 参数更新 UPU 复用同一根)"] ``` 派生函数采用 3GPP 通用 KDF（HMAC-SHA-256）：`Kout = KDF(KAUSF, FC || P0 || L0 || P1 || L1 …)`，其中**算法类型区分符（algorithm distinguisher）**用来把 `KAUSF` 分别映射为 `KSOR-int`（喂给 AES-CMAC 算完整性 MAC）与 `KSOR-enc`（喂给 AES 算保密性），具体的 FC 取值与参数串见 **TS 33.501 Annex A.6**。最终： - **SoR-MAC-IAUSF = AES-CMAC(KSOR-int, Counter_SoR ‖ SoR_List(待保护内容) …)**，长度 **128 bit**； - UE 侧独立派生 `KSOR-int` 重算并比对； - **SoR-MAC-IUE**：当归属网请求确认时，UE 用 `KSOR-int` 反向计算一个 ack-MAC 上报，AUSF 验证。 > **设计意图**：完整性（MAC）解决"伪造"，新鲜性（Counter）解决"重放"，保密性（可选 AES）解决"窃听"。三者解耦，让运营商按需开启保密（很多运营商为了 VPLMN 兼容性默认不开保密，但完整性/MAC/Counter 必开）。 --- ## 三、核心信令时序（登记期间下发，§6.14.2.1） SoR 在登记流程里"搭便车"下发是最常见的场景。完整信令链路如下： ```mermaid sequenceDiagram participant UE participant AMF as AMF(VPLMN) participant UDM as UDM(HPLMN) participant AUSF as AUSF(HPLMN) UE->>AMF: Registration Request(漫游) AMF->>UDM: Nudm_UECM_Registration / Nudm_SDM_Get(订阅) Note over UDM: 判定: UE 处于漫游, 需下发 SoR UDM->>AUSF: Nausf_SoRProtection_Get(SoR List, ack指示, 旧Counter, UE保密能力) Note over AUSF: KSOR-int/enc = KDF(KAUSF)
Counter SoR += 1
SoR-MAC-IAUSF = AES-CMAC
(可选) AES 加密 SoR List AUSF-->>UDM: SoR-MAC-IAUSF + 新Counter SoR (+加密SoR List) Note over UDM: 组装 SoR transparent container UDM-->>AMF: 订阅数据中携带 SoR transparent container AMF-->>UE: REGISTRATION ACCEPT(含 SoR transparent container) Note over UE: ①Counter↑? ②派生KSOR→验MAC ③(可选)解密 ④更新列表+存Counter UE->>AMF: REGISTRATION COMPLETE(含 SOR-MAC-IUE, 若需ack) AMF->>UDM: 转发 ack UDM->>AUSF: 校验 SOR-MAC-IUE ``` ### 逐步 IE 解析 **① Nudm_SDM_Get / Nudm_UECM_Registration（AMF→UDM）** AMF 在登记时从 UDM 拉取订阅数据。UDM 据此识别 UE 当前注册的 PLMN，决定是否触发 SoR。该步**不携带任何 SoR 密码材料**。 **② Nausf_SoRProtection_Get（UDM→AUSF）—— 密码计算的真正发起方** 注意：标准要求由 **AUSF** 计算 SoR-MAC，而非 UDM 自己算（UDM 不持有 KAUSF 的运算责任分离）。携带的关键 IE（TS 29.509）： - **SoR List**：优选 PLMN+接入技术组合（可为空列表）； - **List type**：普通列表 / **secured packet**（封装给 USIM 的受保护分组，常用于 OTA）； - **Acknowledgement indication**：是否要求 UE 回 ack； - **Current SoR Counter**：用于派生新计数器； - **UE confidentiality support**：UE 是否支持保密（决定是否启用 KSOR-enc）。 **③ AUSF 返回**：`SoR-MAC-IAUSF`（128b）+ `Counter SoR`（已自增）+（如启用保密）已加密的 SoR List。 **④ 组装 SoR transparent container（UDM）** UDM 把"列表 + 计数器 + MAC"打包成 **SoR transparent container**。它对 AMF/VPLMN 是**完全透明**的——VPLMN 既不需要也无法解释其内部密码字段，只负责透传。 **⑤ REGISTRATION ACCEPT（AMF→UE）** 承载 `SOR transparent container` IE（TS 24.501 §9.11.3.51）。 **⑥ UE 处理与 ack**：UE 严格校验后更新列表，并在请求 ack 时回 `SOR-MAC-IUE`。 --- ## 四、SoR transparent container IE 结构 ```mermaid flowchart LR A["SoR transparent container"] --> H["SoR Header
(列表类型/保密/ack指示)"] A --> L["SoR List
(优选PLMN+接入技术 / 可加密 / 可空)"] A --> C["Counter SoR
(防重放计数器)"] A --> M["SoR-MAC-IAUSF
(128-bit AES-CMAC)"] L -.可选保密.-> E["AES 加密
KSOR-enc"] ``` | 字段 | 说明 | 作用 | |------|------|------| | **SoR Header** | 1 字节指示：列表类型（操作员控制 PLMN 选择列表 / secured packet / 受禁列表）、是否含 SoR List、是否启用保密、是否要求 ack | 解析路由：列表类还是 OTA 受保护分组 | | **SoR List** | 优选 PLMN（3 字节 MCC+MNC）+ 接入技术标识（含 NG-RAN/5G）；**可为空列表**（语义=不改变现有列表但需 ack） | UE 自动 PLMN 选择排序依据；可被 AES 加密 | | **Counter SoR** | 严格递增计数器，是 MAC 输入之一；UE/USIM 存储最后一次成功值 | **防重放**：VPLMN 重放旧包会被单调性校验拦截 | | **SoR-MAC-IAUSF** | 128 bit，AUSF 用 KSOR-int 计算，UE 重算验证 | **防伪造**：VPLMN 无 KAUSF 无法伪造合法 MAC | > 关键语义：**空列表 ≠ 无操作**。当归属网希望"维持当前引导但确认 UE 在线"时，可下发空列表并请求 ack；当希望让 UE 完全按 HPLMN 配置重选时，下发完整排名列表。`list type = secured packet` 时，SoR List 字段是一个封装好的受保护分组（典型用于把内容经 USIM OTA 落地到卡上文件，如 EF）。 --- ## 五、UE 端校验状态机（Counter + MAC 双重闸门） UE 收到容器后并非无条件接受，而是过两道闸： ```mermaid flowchart TD S([收到 SoR transparent container]) --> T1{"Counter SoR > 已存值?"} T1 -- 否 --> R1["丢弃，维持原列表
(判定为重放/乱序)"] T1 -- 是 --> T2{"重算 SoR-MAC-IAUSF 一致?"} T2 -- 否 --> R2["丢弃，不更新
(判定为伪造/损坏)"] T2 -- 是 --> T3{"Header 指示启用保密?"} T3 -- 是 --> D1["用 KSOR-enc 解密 SoR List"] T3 -- 否 --> D2["直接使用明文 SoR List"] D1 --> U["更新 操作员控制PLMN选择列表
USIM/ME 存储新 Counter"] D2 --> U U --> A1{"Header 要求 ack?"} A1 -- 是 --> A2["计算 SOR-MAC-IUE 上报"] ``` > **设计精髓**：Counter 校验在 MAC 校验之前——即便攻击者能暴力伪造 MAC（实际不可行），单调计数器仍是独立的第二道防线。USIM 把 `Counter SoR` 的"最后成功值"持久化（TS 31.102 相关文件），即便 UE 重启也不回退，彻底杜绝"断电重放"。 --- ## 六、登记后下发与两种载体对比（§6.14.2.2） 除登记搭车外，归属网可在**任意时刻**主动推送 SoR（策略变更、合作伙伴调整、批量重引导）： | 维度 | 登记期间下发 §6.14.2.1 | 登记后下发 §6.14.2.2 | |------|----------------------|---------------------| | 触发 | UE 初始/周期登记到 VPLMN | HPLMN 策略变更、运营下发 | | 下行承载 | **REGISTRATION ACCEPT** | **DL NAS TRANSPORT**（payload = SoR transparent container） | | ack 承载 | REGISTRATION COMPLETE | **UL NAS TRANSPORT**（含 ack 类型 container） | | 适用场景 | 漫游 VPLMN | VPLMN **或** HPLMN（HPLMN 内也可引导） | | AUSF 服务 | Nausf_SoRProtection_Get | Nausf_SoRProtection_Get（同一服务） | 登记后下发时，UDM 通过 `Namf_Communication_N1N2MessageTransfer`（N1 = DL NAS TRANSPORT）把容器经 AMF 透传给 UE，UE 的 ack 则用 `UL NAS TRANSPORT` 的 ack 类型 container 回送。 --- ## 七、SoR vs UPU：同根不同命的姊妹机制 5G 里还有个高度相似的机制 **UPU（UE Parameters Update，§6.15）**，同样基于 KAUSF、同样 MAC+Counter，但用途不同。理解二者差异能避免协议开发中的混淆： | 维度 | **SoR** 漫游引导 | **UPU** UE 参数更新 | |------|------------------|---------------------| | 规范 | TS 33.501 §6.14 / TS 23.122 | TS 33.501 §6.15 / TS 31.102 | | 派生密钥 | KAUSF→**KSOR-int/enc** | KAUSF→**KUPU-int/enc** | | 管控对象 | 漫游 PLMN + 接入技术**选择列表** | 通用参数：路由指示、默认配置 NSSAI、运营商名、CDP 地址等 | | 触发逻辑 | 漫游登记 / 漫游策略变更 | 归属网参数配置变更 | | 下行消息 | REGISTRATION ACCEPT / DL NAS TRANSPORT | CONFIGURATION UPDATE COMMAND / DL NAS TRANSPORT | | 完整性标签 | SoR-MAC-IAUSF；ack: SOR-MAC-IUE | UPU-MAC-Iausf；ack: UPU-MAC-Iue | | 透明性 | 对 VPLMN 透明（可选保密） | 对服务网透明 | > 二者共享 KAUSF 根与 KDF 模板，仅靠"算法区分符"和"MAC 名称"区分——这也是为什么厂商实现常把它们放在同一"AUSF 受保护下发"代码路径里。 --- ## 八、抓包识别与排错实战 ### 抓包怎么认这个流程（pcap-analyzer / TShark） - **SBI 面**：HTTP/2 `POST .../nausf-soRProtection/v1/{ueId}` → `200 OK`，body 含 `soRMacIausf`、`counterSoR`（TS 29.509）； - **Nudm 面**：订阅数据 GET 响应或 `Namf_Communication_N1N2MessageTransfer` 的 N1 容器中携带 SoR transparent container； - **N1（NAS）面**：`DL NAS TRANSPORT`（msg_type=0x67）或 `REGISTRATION ACCEPT` 中解析到 `sorTransparentContainer`；上行 ack 在 `UL NAS TRANSPORT` / `REGISTRATION COMPLETE`。 - 推荐过滤：`nas-5gs.sor_transparent_container` 或按 `http2.headers.content-type` + `nausf`。 ### 常见故障点 1. **MAC 校验失败** → UE 丢弃、列表不更新。根因多为：KAUSF 不一致（鉴权失步）、AUSF/UDM 部署变更后密钥不同步、中间盒篡改了 container； 2. **Counter 不增 / 回放** → 单调性校验拦截；若 AMF 缓存重发旧包，会被卡在第一道闸； 3. **UDM 自己算 MAC**（绕过 AUSF）→ 厂商早期实现或 UDM/AUSF 合设时的内部路径问题，可能与标准口径不符，跨厂商互通时暴露； 4. **保密能力不匹配**（UE 不支持保密，但 HPLMN 仍加密）→ 解密失败； 5. **USIM 不支持 SoR**（老卡）→ ME 侧接管或忽略，列表落 ME 非易失存储； 6. **ack 未返回** → 归属网无法确认落地，下次登记会重发。 ## 九、设计哲学小结 SoR 把"归属网信任域"通过 **KAUSF** 这一锚点密钥，安全地延伸到了"不可信 VPLMN 之上"的 UE。它用三件套（MAC 防伪 / Counter 防重放 / 可选加密防窃听）解耦了三种威胁，用"透明容器"把 VPLMN 降级为纯传输管道，用"AUSF 运算 + UDM 策略"的责任分离支撑漫游合规。对协议工程师而言，**SoR 是理解 5G 如何在漫游场景下做"端到端归属信任"的最佳样本**——它和 UPU 一起，构成了 KAUSF 这根钥匙能开的"两把锁"。 --- ## 常见问题 **Q1: SoR-MAC-IAUSF 为什么用 KAUSF 派生，而不用 KAMF？** A: KAMF 是访问域密钥，由 VPLMN 的 AMF 持有；用它保护"归属网→UE"的内容等于把保护交给潜在攻击者。KAUSF 只在 AUSF(HPLMN) 与 UE 两端，是唯一可信的根，故派生 KSOR-int 来算 MAC。 **Q2: "透明容器"里的"透明"到底指什么？** A: 指对服务网 AMF/VPLMN **不解释、不参与密码运算**，只透传字节流。VPLMN 没有 KAUSF 无法伪造或验证 MAC，但仍可能看到明文列表字节——这就是"可选保密"存在的意义：开启后连列表内容都对 VPLMN 不可见。 **Q3: Counter SoR 如何防重放？严格递增够吗？** A: 足够。UE/USIM 持久化"最后成功值"，每次要求 `新Counter > 旧值`。VPLMN 重放旧包必然 ≤ 旧值而被第一道闸拦截；即便 UE 重启也不回退（落 USIM 文件），断电重放同样失效。 **Q4: 没有 SoR 能力的 USIM 怎么办？** A: 由 ME 侧接管校验与存储（列表与 Counter 落 ME 非易失存储），或直接忽略。换卡/换机后的行为取决于持久化位置，这是厂商实现差异的高发区。 **Q5: SoR 和 UPU 都用 KAUSF，怎么区分？** A: 通过 KDF 的**算法类型区分符**派生出不同的密钥（KSOR-int vs KUPU-int）和不同名称的 MAC（SoR-MAC-IAUSF vs UPU-MAC-Iausf），管控对象也不同（PLMN 选择列表 vs 通用参数）。二者共享模板但互不混淆。 --- ## 参考来源 1. [3GPP TS 33.501 V18.10.0 — Security architecture (§6.14 SoR, Annex A.6 KDF)](https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.10.00_60/ts_133501v181000p.pdf) — 官方规范，SoR 安全机制与密钥派生权威定义 2. [iTechSpec — TS 33.501 §6.14 Steering of roaming security mechanism](https://itecspec.com/spec/3gpp-33-501-6-14-steering-of-roaming-security-mechanism/) — 6.14.1/6.14.2/6.14.2.3 章节结构镜像与速查 3. [GSMA IR.73 v10.0 — Steering of Roaming Implementation Guidelines](https://www.gsma.com/newsroom/wp-content/uploads/IR.73-v10.0.pdf) — 运营商侧 SoR 落地与 5GS 实施指南 4. [Cisco — Nausf_SoRProtection SMF/5GC API Reference](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/smf/2020-02-0/b_SMF-API-Reference/b_test-SMF_chapter_01011.pdf) — AUSF SoR 保护服务操作 IE 与语义 5. [SIMartis — OTA in 5G SA: From Roaming Steering to SIM-Level Execution](https://simartis.com/media/articles/ota-in-5g-sa-from-roaming-steering-to-sim-level-execution-in-the-core) — SoR 容器承载 PLMN/接入技术组合的工程解读 --- > 本文由「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 等场景全覆盖。