5G漫游引导（SoR）安全保护机制全链拆解

一、为什么需要SoR：一个被"中间人"威胁的漫游决策

在5G漫游场景中，UE的PLMN选择（驻留哪个运营商网络）直接决定漫游结算收益归属。归属网络（HPLMN）希望把漫游用户"引导"到自己签约的、资费更优的合作伙伴网络上；而拜访网络（VPLMN）出于自身利益，有强烈动机篡改甚至伪造"优选PLMN列表"，让UE长期驻留在能给自己带来分成的网络上。在没有完整性保护的时代，这种"漫游引导"（Steering of Roaming，SoR）实际上是可以被VPLMN中间人攻击的——它篡改下发给UE的列表，UE无从分辨真伪。

3GPP在TS 33.501中专门为这个问题设计了独立的安全机制（§6.14），其核心思想只有一句话：只有真正持有用户长期密钥的归属网络（AUSF），才能为SoR列表"盖章"（MAC），UE只认这个章，拜访网络只能当透明的"快递员"。 本文基于TS 33.501 V18.10.0（Release 18）、TS 24.501、TS 23.122与TS 23.502，逐条拆解这套机制的密钥推演、信令流程、IE结构与抓包排错要点。

值得一提的是，SoR与另一组机制UPU（UE Parameters Update，§6.15）是一对"姊妹"设计：UPU-MAC的KDF结构与SoR完全同构（Annex A.19/A.20对应A.17/A.18），只是UPU用于推送UE参数更新（如路由指示、默认配置的NSSAI），SoR用于推送漫游优选列表。理解了SoR，UPU也就通了。

二、为什么用K_AUSF而不是K_SEAF——机制设计的灵魂

要理解SoR，必须先看懂它的密钥选择。5G主认证后建立的密钥层级是：

K(永久) → K_AUSF → K_SEAF → K_AMF → {K_NAS_int, K_NAS_enc, K_gNB ...}

关键点在于密钥的可见性边界： - K_AUSF：仅在UE与归属网络的AUSF之间共享。 - K_SEAF / K_AMF：在漫游时由AUSF下发给拜访网络的SEAF/AMF，即VPLMN完全掌握。

如果把SoR的MAC用K_AMF或K_SEAF来算，那么掌握这些密钥的VPLMN就能自己伪造一个合法的MAC——这正是要防的攻击！所以SoR刻意选用K_AUSF：这是密钥层级中"拜访网络永远摸不到"的最高一级密钥。于是：

• AUSF用K_AUSF算出 SoR-MAC-I_AUSF，VPLMN无密钥、无法伪造；
• UE本地也持有K_AUSF（主认证时与AUSF同步建立），可独立验算。

这就是SoR安全性的根基：用密钥的"不可见性"换取"不可伪造性"。下面所有KDF细节都围绕K_AUSF展开。

三、密钥推演：Annex A.17 / A.18 的精确KDF

5G KDF基于HMAC-SHA-256（TS 33.501 Annex B.2），输入串 S = FC || P0 || L0 || P1 || L1 || ...，取输出的相应低位作为派生密钥/MAC。

3.1 下行MAC：SoR-MAC-I_AUSF（Annex A.17）

这是AUSF为下发列表盖的"章"，UE据此验真：

注意一个精妙设计：P2取的是"容器第22字节之后"的部分。这是因为容器前22字节是固定的元信息（IEI/长度/SoR header/MAC/Counter），真正可变的有效载荷（优选PLMN列表或secured packet）从第23字节开始，所以MAC只对"业务内容"做保护，同时header和Counter单独作为P0/P1计入——既避免冗余，又把所有影响UE决策的字段都覆盖到。

3.2 上行MAC：SoR-MAC-I_UE（Annex A.18）

UE成功验证并应用列表后，要给网络一个"我确实收到了"的回执，回执里也带一个MAC，由UE用K_AUSF算出：

网络侧（AUSF）用同样输入算出 SoR-XMAC-I_UE 与UE上报的 SoR-MAC-I_UE 比对，确认UE真的处理了这份列表。这解决了"列表到底有没有生效"的可观测性问题——运营商可以据此计费/审计引导成功率。

四、防重放：16位Counter_SoR（§6.14.2.3）

光有MAC还不够。设想VPLMN截获一份历史上合法的SoR列表（带合法MAC），日后反复重放给UE——只要MAC不变，UE就会一直接受过时列表。Counter_SoR就是为此设计的"新鲜性令牌"：

• AUSF与UE为每个K_AUSF绑定一个16位计数器；
• UE在新K_AUSF生成存储时初始化为 0x00 0x00；AUSF在控制面SoR方案下新K_AUSF存储时初始化为 0x00 0x01；
• AUSF每计算一次新SoR-MAC-I_AUSF就把Counter加1；
• Counter_SoR作为P1参与KDF，所以改Counter就改MAC，无法复用旧MAC；
• UE只接受严格大于已存储值的Counter；
• 只有当MAC验证成功后，UE才存储新Counter——防止攻击者用大Counter"毒化"UE状态机导致后续合法列表被拒；
• UE生成上行SoR-MAC-I_UE时，使用从HPLMN收到的（已验证存储的）Counter。

这一组规则构成一个简洁的单调递增状态机：合法列表的Counter必然递增，重放的Counter必然≤已存值而被拒，且即便攻击失败也不会污染UE的计数器。16位计数器对K_AUSF生命周期（一次主认证周期）内的SoR更新次数绰绰有余。

五、完整信令时序图

SoR有两条下发路径：注册期（在REGISTRATION ACCEPT中捎带）和注册后（DL NAS TRANSPORT独立下发）。下图合并展示主流的"注册期下发+注册后更新"双路径与回执链路。

sequenceDiagram
    autonumber
    participant UE
    participant AMF as AMF (VPLMN)
    participant UDM as UDM (HPLMN)
    participant AUSF as AUSF (HPLMN)

    Note over UE,AUSF: 前置：主认证完成，UE与AUSF共享K_AUSF
    UDM->>AUSF: Nausf_SoRProtection_Get<br/>(SoR header, 优选PLMN列表, ACK指示)
    AUSF->>AUSF: Counter_SoR++ ; KDF(K_AUSF, FC=0x77, ...)<br/>生成 SoR-MAC-I_AUSF
    AUSF-->>UDM: SoR-MAC-I_AUSF, Counter_SoR
    UDM->>AMF: Nudm_SDM_Get / N1N2MessageTransfer<br/>(SOR transparent container, 透传)
    AMF->>UE: REGISTRATION ACCEPT<br/>(Payload container = SOR transparent container)

    UE->>UE: KDF(K_AUSF, FC=0x77) 算 XMAC<br/>校验 Counter_SoR>已存 且 MAC相等
    Note over UE: 验证通过→应用优选列表(TS 23.122)<br/>存储Counter_SoR
    UE->>UE: KDF(K_AUSF, FC=0x78) 算 SoR-MAC-I_UE
    UE->>AMF: REGISTRATION COMPLETE<br/>(上行SOR transparent container = 回执MAC)
    AMF->>UDM: N1MessageNotify (回执)
    UDM->>AUSF: Nausf_SoRProtection_Verify
    AUSF->>AUSF: 算 SoR-XMAC-I_UE 比对
    AUSF-->>UDM: 验证结果(引导是否生效)

    Note over UE,UDM: ——注册后更新（独立路径）——
    UDM->>AUSF: Nausf_SoRProtection_Get (新列表)
    AUSF-->>UDM: 新 SoR-MAC-I_AUSF + 新Counter_SoR
    UDM->>AMF: Namf_Communication_N1N2MessageTransfer(N1消息)
    AMF->>UE: DL NAS TRANSPORT (Payload container=SOR container)
    UE->>AMF: UL NAS TRANSPORT (上行回执MAC)
    AMF->>UDM: 回执转发

几个关键节点说明： - 第2步UDM是"请求方NF"（requester NF），SoR header可由UDM构造、也可由AUSF根据收到的ACK指示与列表自行构造（A.17原文）。 - 第4步AMF对容器内容完全不理解、不解析、不修改——它只是按Payload container的"container type=SOR transparent container"原样搬运。这正是安全边界：AMF即使想篡改也无能为力，因为篡改后MAC对不上。 - 第6步UE的验算与第3步AUSF的计算使用完全相同的输入（K_AUSF、FC=0x77、header、Counter、列表字节），故XMAC与MAC必相等——这是HMAC-SHA-256的确定性保证。 - 第8-10步回执链路让HPLMN获得"引导成功"的确认，可对接计费/分析系统。

六、SOR transparent container 的字节级结构（TS 24.501 §9.11.3.51）

该IE是type 6信息元素（长度可变，带2字节长度域），最小长度20字节。其经典布局（List type=1，承载PLMN/access technology列表）如下：

flowchart TB
    subgraph CT["SOR transparent container (TS 24.501 §9.11.3.51)"]
        direction TB
        O1["octet 1<br/>SOR transparent container IEI"]
        O23["octet 2-3<br/>Length of contents"]
        O4["octet 4<br/>SoR header<br/>(List type / SOR data type / ACK指示 / 各SI标志位)"]
        O520["octet 5-20<br/>SoR-MAC-I<sub>AUSF</sub> (16字节=128bit)"]
        O2122["octet 21-22<br/>Counter<sub>SoR</sub> (16bit)"]
        O23n["octet 23* - m*<br/>Length + PLMN ID and access technology list<br/>(或 secured packet，List type=0时)"]
        Oo["octet o* ...<br/>(可选) SOR-CMCI / SOR-SNPN-SI / SOR-SNPN-SI-LS"]
    end
    style O520 fill:#ffd6d6,stroke:#b30000
    style O2122 fill:#fff2cc,stroke:#bf9000
    style O4 fill:#d9ead3,stroke:#38761d

对应的IE参数说明表：

注意上行（回执）容器更精简：只含IEI/长度/header/SoR-MAC-I_UE（FC=0x78算出的回执MAC），不再带列表。

七、UE验证与应用的状态机

UE收到容器后的处理是一个明确的判定流程，下图给出其决策路径（结合§6.14.2.3的Counter规则）：

flowchart TD
    A["收到 REGISTRATION ACCEPT / DL NAS TRANSPORT<br/>含 SOR transparent container"] --> B{"Counter_SoR > 已存值?"}
    B -- 否 --> R1["拒绝（疑似重放）<br/>不更新，不上报回执"]
    B -- 是 --> C["用本地 K_AUSF、FC=0x77 算 XMAC"]
    C --> D{"XMAC == 收到的 SoR-MAC-I_AUSF?"}
    D -- 否 --> R2["验证失败：丢弃<br/>不存储Counter，不上报回执"]
    D -- 是 --> E["存储新 Counter_SoR<br/>（仅验签成功才存）"]
    E --> F["按 TS 23.122 应用优选PLMN/接入技术列表"]
    F --> G["FC=0x78 算 SoR-MAC-I_UE"]
    G --> H["发 REGISTRATION COMPLETE / UL NAS TRANSPORT 带回执"]
    style R1 fill:#f4cccc
    style R2 fill:#f4cccc
    style E fill:#d9ead3
    style F fill:#d9ead3

设计意图小结：步骤B（先比Counter）和步骤E（验签成功才存Counter）联合起来，把"重放"和"状态毒化"两类攻击都堵死——即便攻击者伪造一个超大Counter，由于没有K_AUSF算不出正确MAC，会在步骤D失败，UE也不会存储这个大Counter，下次真正合法的列表仍能被接受。

八、与相关机制/方案的对比

一个常被忽略的对比是为何SoR不用secured packet（USIM OTA式）而要新建机制：secured packet依赖USIM与HPLMN间的长期密钥、走SIM卡应用层，更新慢、且依赖USIM能力；而SoR走5G NAS层、用主认证刚建立的K_AUSF，注册后即可立即生效、无需USIM OTA往返，更适合"实时引导漫游"这种对时延敏感的商业场景。

九、抓包识别：如何在报文里找到SoR

在Wireshark/TShark中（5G NAS dissector）识别SoR流程：

1. 下行（网络→UE）：找 Registration accept 或 DL NAS TRANSPORT 消息；
2. 展开 Payload container → Payload container type 应为 "SOR transparent container"（区别于N1 SM info、UE parameters update等）；
3. 展开该container，可见： - SOR-MAC-I（16字节）、Counter（2字节）、List type、SOR data type、ACK 指示位； - 若List type=1，后面跟着 Length of PLMN ID and access technology list 与各 PLMN ID + Access technology 条目（MCC/MNC + 接入技术标识）。
4. 上行（UE→网络）：找 Registration complete 或 UL NAS TRANSPORT，其 Payload container type = SOR transparent container，内含 SOR-MAC-I 回执（FC=0x78计算），通常不含列表。

快速TShark过滤示例：

# 抓取所有承载SOR透明容器的NAS消息
tshark -i <iface> -Y "nas_5gs.payload_container_type == 4" -V
# （注：container type 4 在多数版本dissector中映射为SOR，5为UPU；以实际版本为准）

识别要点：SoR消息总是出现在N1（NAS）层、总是封装在Payload container里、AMF侧不解析内容——所以你在N2（NGAP）或N11（AMF-UDM SBI）上看到的是"透传"形态。

十、常见故障点与排错思路

故障1：UE不应用新SoR列表（引导失效）。 最常见原因是MAC验证失败。排查方向： - 用抓包确认下行容器完整传输（未在SBI/N2被截断）； - 核对AUSF侧K_AUSF是否与UE一致（若中间发生再认证、K_AUSF更新但Counter未同步，会失配）； - 检查AUSF的Counter_SoR与UE已存值：若因掉电、双注册等原因UE的Counter"超前"（大于AUSF），则AUSF后续列表Counter恒≤UE，UE会一直拒绝——需触发重新主认证重置K_AUSF+Counter。

故障2：Counter回卷/重置后列表被持续拒绝。 按§6.14.2.3，Counter绑定K_AUSF生命周期。新主认证→新K_AUSF→Counter重置（UE为0x0000，AUSF控制面为0x0001）后应恢复正常。若仍拒绝，检查UE是否把Counter存到了非易失存储（规范要求：支持5G扩展存储的USIM存USIM，否则存ME非易失内存）——存到易失内存会在重启后回零，造成与网络不同步。

故障3：组合注册时延异常增大（约数十秒）。 GSMA IR.73实测指出：在组合注册（Combined Registration）上叠加SoR流程，会带来约75秒量级的注册时延。根因是SoR回执要等REGISTRATION COMPLETE，而组合注册的EPS/5GS协调拉长了窗口。优化建议：把SoR放到注册后用DL NAS TRANSPORT下发，避免阻塞初始注册；或调整ACK指示策略（不强求每次都回ACK）。

故障4：VPLMN漫游引导"看起来生效但资费仍是旧伙伴"。 这是经典的VPLMN侧篡改未遂但UE仍按本地EHPLMN/EPLMN旧优先级选网的情况。需确认UE是否真的收到了带合法MAC的新列表（看抓包），并核对UE侧SoR列表在TS 23.122选择逻辑中的优先级位置——SoR列表仅在自动选网模式且满足条件时才"覆盖"部分本地列表，并非无条件最高优先。

故障5：AMF透传失败导致容器丢失。 AMF若因不支持（旧版本）或Payload container处理Bug而丢弃该IE，UE收不到列表。表现为抓包里只有N11（UDM→AMF）有容器、N1（AMF→UE）没有。检查AMF版本是否支持TS 24.501 §9.11.3.51及对应Payload container type。

常见问题

Q1：SoR用的K_AUSF，UE每次注册都换吗？会否导致Counter频繁重置？ A：K_AUSF在每次5G主认证（5G AKA或EAP-AKA'）时重新派生，所以重新认证会重置Counter（UE置0x0000）。常态下不会频繁触发——只要不重新认证，K_AUSF与Counter在整个注册周期内保持，SoR可多次增量下发。

Q2：SoR-MAC-I_AUSF和SoR-MAC-I_UE为什么FC不同（0x77 vs 0x78）？ A：KDF要求派生结果与用途严格绑定。下行（网络盖章给UE）和上行（UE回执给网络）虽都用K_AUSF，但语义相反，用不同FC（0x77/0x78）隔离，避免上下行消息在KDF层面产生可关联/可伪造的交叉，是标准的"用途分离"安全工程实践。

Q3：拜访网络能不能伪造一个Counter很大的容器来"毒化"UE？ A：不能造成持久危害。伪造大Counter但没有K_AUSF→算不出正确MAC→UE在第D步验签失败→不存储该Counter（§6.14.2.3明确"仅在MAC验证成功后才存储Counter"）。所以UE状态机不受污染，后续HPLMN的合法列表仍被正常接受。

Q4：SoR和UPU到底什么关系？ A：架构上同源、KDF同构。SoR（§6.14，A.17/A.18）推漫游优选列表，UPU（§6.15，A.19/A.20）推UE运行参数（路由指示、默认配置NSSAI等）。两者都用K_AUSF、都有16位单调Counter、都走NAS的Payload container、都有下行MAC+上行回执MAC。掌握其一即通其二。

Q5：如果UE处于手动选网模式，SoR还有效吗？ A：SoR列表影响的是自动选网模式下的PLMN优先级（TS 23.122）。手动模式下用户指定网络，SoR列表不强制改写用户选择，但其安全验证（MAC/Counter）仍会执行并存储，等切回自动模式时生效。

参考来源

1. 3GPP TS 33.501 V18.10.0 — Security architecture and procedures for the 5G System — §6.14 Steering of roaming security mechanism，§6.14.2.3 SoR Counter，Annex A.17/A.18 KDF
2. TS 33.501 §6.14 — Steering of roaming security mechanism（在线版） — 6.14.2.1/6.14.2.2/6.14.2.3 子节索引
3. TS 33.501 Annex A.17 — SoR-MAC-I_AUSF generation function — FC=0x77，KEY=K_AUSF，P0/P1/P2参数定义
4. 3GPP TS 24.501 — NAS protocol for 5GS — §9.11.3.51 SOR transparent container IE，§8.2.8.2 回执处理
5. GSMA IR.73 — Steering of Roaming Implementation Guidelines V10.0 — 组合注册叠加SoR导致约75秒注册时延的实测与商业指引
6. 3GPP TS 23.122 — NAS functions related to Mobile Station — 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 等场景全覆盖。