聚焦 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 钉死在某个网络。如果不加保护，就存在三类攻击：
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 全程无感。
flowchart TD
K["K 永久密钥<br/>USIM ↔ AUSF/UDM"] --> KAUSF["KAUSF<br/>主鉴权锚点密钥"]
KAUSF -->|KDF Annex A.6| KI["KSOR-int<br/>完整性密钥"]
KAUSF -->|KDF Annex A.6| KE["KSOR-enc<br/>保密性密钥(可选)"]
KI --> MAC["SoR-MAC-IAUSF<br/>= AES-CMAC(KSOR-int, 待保护内容)"]
KE --> ENC["AES 加密 SoR List<br/>(对 VPLMN 不可见)"]
KAUSF -.同源派生.-> OTHER["KSEAF→KAMF→KgNB<br/>(接入域信令/数据面, 另一条路径)"]
KAUSF -.同源派生.-> UPU["KUPU-int/enc<br/>(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。最终：
KSOR-int 重算并比对；KSOR-int 反向计算一个 ack-MAC 上报，AUSF 验证。设计意图：完整性（MAC）解决"伪造"，新鲜性（Counter）解决"重放"，保密性（可选 AES）解决"窃听"。三者解耦，让运营商按需开启保密（很多运营商为了 VPLMN 兼容性默认不开保密，但完整性/MAC/Counter 必开）。
SoR 在登记流程里"搭便车"下发是最常见的场景。完整信令链路如下：
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)<br/>Counter SoR += 1<br/>SoR-MAC-IAUSF = AES-CMAC<br/>(可选) 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
① 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）：
③ 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。
flowchart LR
A["SoR transparent container"] --> H["SoR Header<br/>(列表类型/保密/ack指示)"]
A --> L["SoR List<br/>(优选PLMN+接入技术 / 可加密 / 可空)"]
A --> C["Counter SoR<br/>(防重放计数器)"]
A --> M["SoR-MAC-IAUSF<br/>(128-bit AES-CMAC)"]
L -.可选保密.-> E["AES 加密<br/>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 收到容器后并非无条件接受，而是过两道闸：
flowchart TD
S([收到 SoR transparent container]) --> T1{"Counter SoR > 已存值?"}
T1 -- 否 --> R1["丢弃，维持原列表<br/>(判定为重放/乱序)"]
T1 -- 是 --> T2{"重算 SoR-MAC-IAUSF 一致?"}
T2 -- 否 --> R2["丢弃，不更新<br/>(判定为伪造/损坏)"]
T2 -- 是 --> T3{"Header 指示启用保密?"}
T3 -- 是 --> D1["用 KSOR-enc 解密 SoR List"]
T3 -- 否 --> D2["直接使用明文 SoR List"]
D1 --> U["更新 操作员控制PLMN选择列表<br/>USIM/ME 存储新 Counter"]
D2 --> U
U --> A1{"Header 要求 ack?"}
A1 -- 是 --> A2["计算 SOR-MAC-IUE 上报"]
设计精髓：Counter 校验在 MAC 校验之前——即便攻击者能暴力伪造 MAC（实际不可行），单调计数器仍是独立的第二道防线。USIM 把
Counter SoR的"最后成功值"持久化（TS 31.102 相关文件），即便 UE 重启也不回退，彻底杜绝"断电重放"。
除登记搭车外，归属网可在任意时刻主动推送 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 回送。
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 受保护下发"代码路径里。
POST .../nausf-soRProtection/v1/{ueId} → 200 OK，body 含 soRMacIausf、counterSoR（TS 29.509）；Namf_Communication_N1N2MessageTransfer 的 N1 容器中携带 SoR transparent container；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。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 通用参数）。二者共享模板但互不混淆。
本文由「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 等场景全覆盖。