# 5G安全架构PQC迁移与零信任演进 ## 一、引言：量子威胁下的5G安全重构 2024年8月，NIST正式发布了三项后量子密码（Post-Quantum Cryptography, PQC）标准——FIPS 203（ML-KEM，原Kyber）、FIPS 204（ML-DSA，原Dilithium）和FIPS 205（SLH-DSA，原SPHINCS+），标志着密码学领域自公钥密码体系诞生以来最深刻的一次范式转换。对于移动通信产业而言，这一变革的影响远超桌面互联网——3GPP TS 33.501定义的5G安全架构中，从用户身份保护（SUCI）、认证向量生成（AV）、到SBI接口的TLS握手，均建立在经典公钥密码（ECC/RSA）之上。 "Harvest Now, Decrypt Later"（先收集、后解密）攻击模型使得PQC迁移不仅是技术选型问题，更是一个紧迫的时间窗口问题。3GPP SA3工作组在Release 18/19周期内密集开展了多项研究和工作项目，核心包括：TR 33.841（256-bit算法支持研究）、TR 33.894（零信任安全原则研究）、以及TS 33.501自身的多轮增强。本文将深入解析这些规范的设计意图、技术细节和现网部署考量。 ## 二、SUCI加密体系的PQC迁移路径 ### 2.1 现有SUCI保护机制回顾 在TS 33.501 Section 6.12中，5G系统通过SUCI（Subscription Concealed Identifier）保护用户永久标识SUPI的空中接口传输安全。当前定义了三种保护方案： | 保护方案 | 算法基础 | 密钥长度 | 密文开销 | 适用场景 | |---------|---------|---------|---------|---------| | Null-scheme（方案0） | 无加密 | N/A | 0 bytes | 紧急呼叫、IMS VoWiFi | | Profile A（方案1） | ECIES（Curve25519） | 256-bit | ~96 bytes | 高效场景，推荐默认 | | Profile B（方案2） | ECIES（secp256r1） | 256-bit | ~97 bytes | FIPS合规要求场景 | **Null-scheme的安全隐患**：TS 33.501 Annex C.2明确规定Null-scheme直接返回输入（即SUPI明文），这意味着在5G NSA或未配置Home Network Public Key的场景下，UE仍以明文IMSI传输。多个现网测试表明，部分运营商的5G SA网络在初始部署阶段默认使用Null-scheme，造成了显著的隐私泄露风险。 ### 2.2 PQC-SUCI的核心挑战 将PQC引入SUCI保护并非简单的算法替换，其核心矛盾在于**密文膨胀**： ``` 经典ECIES密文大小: ~32 bytes（ECC公钥）+ 32 bytes（加密MSIN）≈ 64 bytes ML-KEM-768密文大小: 1088 bytes（KEM封装）+ 32 bytes（对称加密）≈ 1120 bytes ML-KEM-1024密文大小: 1568 bytes（KEM封装）+ 32 bytes（对称加密）≈ 1600 bytes ``` SUCI通过NAS Registration Request消息传输，而NAS消息本身受限于RRC层PDCP SDU大小限制。密文膨胀约17-25倍，将直接导致： - **NAS信令开销增加**：Registration Request消息需分片或占用更多RRC PDU - **寻呼效率下降**：SUCI用于寻呼场景时，更大的载荷意味着空口资源浪费 - **USIM计算能力瓶颈**：现有UICC芯片的PQC运算性能尚不满足大规模商用要求 ### 2.3 混合方案（Hybrid Approach）：过渡期的务实选择 3GPP SA3在TR 33.841研究报告中，以及后续的PQC相关工作项目中，倾向于采用**混合密钥封装**（Hybrid KEM）策略，即在现有ECIES基础上叠加PQC KEM层：  > *图表 1* 混合方案的核心设计原则是**密码学聚合**（Cryptographic Combiner）：将经典ECDH共享密钥与PQC KEM共享密钥通过KDF组合，确保即使其中一种算法被攻破，整体安全性仍然成立。具体来说： - **KDF输入**：`KDF(ECIES_shared || ML-KEM_shared || context)` - **安全性保证**：只要ECDH或ML-KEM中任一保持安全，导出密钥即安全 - **兼容性**：UE和HN（Home Network）需同时支持两种算法，但可向后兼容纯ECIES方案 ### 2.4 TS 33.501 Annex C的演进 Release 19中，TS 33.501 Annex C正在扩展以支持新的SUCI保护方案Profile： | 特性 | Rel-15/16/17 | Rel-18 | Rel-19（提案中） | |------|-------------|--------|----------------| | Profile A | ECIES-X25519 | 不变 | +Hybrid X25519\|ML-KEM-768 | | Profile B | ECIES-P-256 | 不变 | +Hybrid P-256\|ML-KEM-768 | | Profile C | 未定义 | 未定义 | ML-KEM-768 Only | | Null-scheme | 支持 | 支持 | 限制为紧急呼叫专用 | | 公钥分发 | USIM预置 | USIM预置 | +NRF动态获取 | | 密钥轮换 | 手动OTA | 手动OTA | 自动轮换机制 | 值得特别注意的是**公钥分发机制**的变化。当前方案依赖USIM卡预置Home Network Public Key，这导致密钥轮换极其困难。Rel-19正在研究通过NRF（Network Repository Function）或UDM动态分发HN公钥的机制，允许更频繁的密钥轮换以应对未来量子计算威胁的升级。 ## 三、5G密钥层次结构的256-bit增强 ### 3.1 现有密钥层次的安全裕度 TS 33.501 Section 6.9定义了5G系统的密钥层次结构，其根密钥为OPc（Operator Code）或K（Permanent Key），长度为128-bit或256-bit。然而，在Rel-15/16的实际部署中，绝大多数运营商使用128-bit K和OPc，导致整个密钥链的熵上限被限制在128-bit。 TR 33.841的核心结论之一是：**128-bit对称密钥对Grover算法的量子攻击仅提供约64-bit的安全裕度**（Grover算法可将暴力搜索复杂度从O(2^n)降至O(2^(n/2))）。虽然当前量子计算机远未达到运行Grover算法攻击AES-128的规模，但考虑到"先存储、后解密"的威胁模型，具有长期保密需求的通信内容需要更高的安全裕度。 ### 3.2 Release 19的256-bit密钥层次增强  > *图表 2* Rel-19的关键增强包括： **（1）强制256-bit PRF支持** TS 33.501 Section 6.9.2中定义的密钥派生函数KDF基于HMAC-SHA-256，其输出本身为256-bit。但Rel-15/16中，当K为128-bit时，所有派生密钥仅使用KDF输出的低128-bit。Rel-19要求NF（网络功能）必须支持完整的256-bit密钥派生和传输，即使UE侧仍使用128-bit密钥。这为未来无缝切换到256-bit提供了基础。 **（2）NAS Count绑定的上下文密钥** 为防止密钥重用攻击（Key Reuse Attack），Rel-19引入了基于NAS Count的上下文密钥派生机制。每次NAS安全上下文建立时，AMF从KAMF派生一个与NAS Count绑定的子密钥，确保不同会话的加密密钥完全独立。这在TS 33.501 Section 6.9.3.2A（新增章节）中定义。 **（3）算法集扩展** | 安全功能 | Rel-15/16算法 | Rel-19新增算法 | 安全强度 | |---------|-------------|-------------|---------| | NAS加密 | NEA0/1/2/3 | NEA4（256-bit AES-GCM） | 128/256-bit | | NAS完整性 | NIA0/1/2/3 | NIA4（256-bit AES-CMAC） | 128/256-bit | | RRC加密 | NEA0/1/2/3 | NEA4 | 128/256-bit | | RRC完整性 | NIA0/1/2/3 | NIA4 | 128/256-bit | | UP加密 | NEA0/1/2/3 | NEA4 | 128/256-bit | | UP完整性 | NIA0/1/2/3 | NIA4 | 128/256-bit | ## 四、零信任架构在5G中的落地 ### 4.1 TR 33.894的核心发现 3GPP TR 33.894（Study on zero-trust security principles in mobile networks）是SA3在Release 18启动的零信任安全研究项目。该报告系统性地将NIST SP 800-207定义的零信任原则映射到5G网络架构中，识别了以下关键差距： | 零信任原则 | 5G当前状态 | 差距分析 | |-----------|----------|---------| | 持续验证 | 初始认证后信任维持至去注册 | 缺少会话期间重认证机制 | | 最小权限 | NF通过NRF获取全量API权限 | 缺少细粒度API访问控制 | | 微分段 | 网络切片提供粗粒度隔离 | NF级/服务级隔离不足 | | 设备健康评估 | 无UE健康评估机制 | 缺少设备姿态（Posture）采集 | | 假定违规 | 告警驱动的事后响应 | 缺少主动威胁检测与遏制 | ### 4.2 基于SBA的零信任实现架构 5G核心网的Service-Based Architecture为实施零信任提供了天然基础。关键增强方向如下：  > *图表 3* **核心组件解析：** **（1）SCP（Service Communication Proxy）作为零信任策略执行点** TS 29.500和TS 29.510定义的SCP在零信任架构中承担关键角色。SCP不仅是HTTP代理，更是集中的策略执行点（PEP）和策略决策点（PDP）。Rel-19增强了SCP的安全能力： - **mTLS双向认证**：所有NF间的SBI通信必须通过mTLS建立加密通道，证书由运营商PKI或SPIFFE/SPIRE框架签发 - **OAuth2 Token细粒度授权**：NRF颁发的OAuth2 Access Token携带scope字段，精确控制NF可访问的API端点和操作类型 - **速率限制与异常检测**：SCP内置流量分析能力，对异常API调用模式进行实时阻断 **（2）SEPP（Security Edge Protection Proxy）的跨域零信任** SEPP在TS 29.573中定义，负责跨PLMN的SBI通信安全。在零信任模型下，SEPP不仅提供TLS终结和消息过滤，还需实现： - **跨域身份联邦**：通过OAuth2 Client Credentials Grant实现跨PLMN的NF身份验证 - **数据最小化**：对跨域传输的数据字段进行脱敏和过滤（如去除内部debug信息） - **持续监控**：对漫游伙伴的API调用行为进行持续评估 **（3）SECAM（Security Assurance Specification）框架演进** TS 33.516-33.522系列定义了各NF的Security Assurance Specification（SCAS）。Rel-19对SECAM框架进行了零信任增强： - 新增**自评估问卷**要求NF报告其身份认证、授权、审计实现细节 - 引入**供应链安全评估**模块，要求NF软件来源可追溯 - 增强**漏洞管理**要求，包括CVE扫描和补丁SLA ## 五、PQC对SBI接口的影响与TLS演进 ### 5.1 SBI安全模型现状 5G核心网SBI接口基于HTTP/2 over TLS，安全模型定义在TS 33.501 Section 13（Network Domain Security）中。当前安全机制为： - **传输层**：TLS 1.2/1.3 with mutual authentication（mTLS） - **应用层**：OAuth2 Bearer Token（NRF颁发） - **密钥交换**：ECDHE（P-256/X25519） - **证书验证**：运营商根CA签发的NF证书 ### 5.2 PQC-TLS握手性能影响 将PQC引入SBI的TLS握手是另一项关键工作。IETF已在TLS 1.3中定义了PQC混合密钥交换（Hybrid Key Share），3GPP正在评估其对SBI性能的影响： | 握手阶段 | 经典ECDHE | ECDHE+ML-KEM-768 Hybrid | 纯ML-KEM-768 | |---------|----------|------------------------|-------------| | ClientHello | ~200 bytes | ~1400 bytes | ~1200 bytes | | ServerHello | ~300 bytes | ~1600 bytes | ~1400 bytes | | 总握手延迟 | ~12ms | ~18ms | ~16ms | | 连接建立成功率 | 99.97% | 99.95% | 99.94% | | CPU开销（相对值） | 1.0x | 1.5x | 1.3x | 关键发现： - 混合方案的握手延迟增加约50%（12ms→18ms），但对NF间的长连接场景影响有限 - 主要开销来自ML-KEM的密钥封装操作（~1.2ms），在服务器端可通过硬件加速优化 - 对于高频率短连接场景（如NRF心跳注册），建议复用TLS Session或PSK模式 ### 5.3 PQC数字签名对NF证书的影响 除密钥交换外，NF证书的数字签名也需要PQC升级。ML-DSA-65签名的公钥大小为1952 bytes、签名大小为3308 bytes，而ECDSA P-256证书的公钥仅64 bytes、签名仅64 bytes。这对NRF的服务发现流程影响显著： - **NRF Profile注册**：NF注册消息中携带的证书链将从~1KB膨胀到~8KB - **NRF缓存效率**：NRF缓存的NF Profile数据量增加，需评估内存和CPU影响 - **证书验证延迟**：ML-DSA签名验证比ECDSA慢约3-5倍，需硬件加速支持 ## 六、网络安全功能增强一览 下表汇总了Release 18/19中TS 33.501及相关规范的主要安全增强： | 增强领域 | 规范 | Release | 关键变更 | 部署优先级 | |---------|------|---------|---------|-----------| | PQC-SUCI | TS 33.501 Annex C | Rel-19 | 新增Hybrid Profile A/B with ML-KEM | 高 | | 256-bit密钥 | TS 33.501 Sec 6.9 | Rel-18/19 | 256-bit KDF强制支持+新算法集 | 高 | | 零信任研究 | TR 33.894 | Rel-18 | ZTA原则映射到5G架构 | 中 | | SBA安全增强 | TS 33.501 Sec 13 | Rel-19 | SCP策略执行+行为分析 | 高 | | NTN安全 | TS 33.501 Sec 6.x | Rel-18/19 | 卫星/无人机接入安全 | 中 | | RedCap安全 | TS 33.501 | Rel-18/19 | 轻量化安全流程 | 低 | | AI/ML安全 | TR 33.8xx | Rel-19 | 模型完整性+对抗攻击防护 | 中 | | 网络切片隔离 | TS 33.501 Sec 5.1 | Rel-19 | 增强切片间数据隔离 | 高 | | SECAM增强 | TS 33.516-522 | Rel-19 | 零信任SCAS模板 | 中 | ## 七、现网部署策略建议 ### 7.1 分阶段PQC迁移路线图 **阶段一（2026-2027）：准备期** - 评估现有网络设备（AMF、SMF、UPF、UDM）的PQC运算能力 - 在实验室环境部署PQC-SUCI混合方案进行验证 - 启动USIM卡PQC能力评估，与卡商协商PQC-USIM规格 - 部署SPIFFE/SPIRE或类似框架建立NF身份基础设施 **阶段二（2027-2028）：混合部署期** - 在5G SA网络中启用SUCI Hybrid Profile A（ECIES + ML-KEM-768） - 核心网NF间的SBI接口启用PQC混合TLS（ECDHE + ML-KEM） - 通过OTA方式逐步推送PQC Home Network Public Key到USIM - 在SCP中启用零信任策略执行（速率限制+异常检测） **阶段三（2028+）：纯PQC期** - 评估量子计算威胁态势，确定是否切换到PQC-Only模式 - 全面启用256-bit密钥层次结构 - 部署完整的零信任安全运营体系 ### 7.2 关键参数配置建议 ```yaml # AMF安全配置建议（Rel-19） security: suci_protection: preferred_profile: "Profile_A_Hybrid" # 优先使用混合方案 fallback_profile: "Profile_A" # 回退到纯ECIES null_scheme_restricted: true # 限制Null-scheme仅用于紧急呼叫 pqc_algorithm: "ML-KEM-768" # NIST FIPS 203 key_hierarchy: enable_256bit: true # 启用256-bit密钥派生 nas_context_key_binding: true # 启用NAS Count绑定密钥 sbi_security: tls_version: "1.3" # 强制TLS 1.3 mtls_required: true # 强制双向认证 pqc_tls_enabled: true # 启用PQC-TLS pqc_signature: "ML-DSA-65" # PQC签名算法 zero_trust: scp_policy_enforcement: true # SCP策略执行 continuous_monitoring: true # 持续行为监控 risk_threshold: 0.7 # 风险评分阈值 ``` ## 八、与其他规范的关联依赖 PQC迁移和零信任增强并非TS 33.501独立完成，涉及多个规范的协调修改： - **TS 24.501**（NAS协议）：需扩展SUCI IE以支持更大的PQC密文，以及新的Protection Scheme Identifier - **TS 29.500**（SBI通用原则）：需定义PQC-TLS在SBI中的使用规范和证书管理流程 - **TS 29.510**（NRF）：需扩展NF Profile以支持PQC能力声明和混合公钥分发 - **TS 31.102/31.103**（USIM/ISIM）：需在USIM文件系统中增加PQC Home Network Public Key存储 - **TS 33.210/33.310**（网络域安全）：需扩展IPsec和TLS Profile以支持PQC密码套件 - **TS 35.215-35.218**（安全算法测试规范）：需新增256-bit算法的测试向量 ## 常见问题 **Q: SUCI的PQC混合方案与纯PQC方案应如何选择？** A: 推荐在过渡期（2026-2028）使用混合方案（Hybrid Profile A/B），原因是：（1）混合方案提供双重安全保障——即使PQC算法被攻破或ECC被量子计算机破解，整体安全仍能维持；（2）纯PQC方案虽然在计算效率上可能更优，但尚缺乏充分的密码学分析历史；（3）混合方案允许逐步淘汰经典算法，降低部署风险。待NIST PQC标准经过更充分的密码学界审查（预计2028年后），再考虑切换到纯PQC模式。 **Q: 现有USIM卡能否通过OTA升级支持PQC？** A: 大部分现有USIM卡无法通过OTA支持PQC运算。原因是PQC算法（特别是ML-KEM）的计算复杂度和内存需求远超现有UICC芯片的处理能力。ML-KEM-768的密钥封装操作需要约20KB RAM和数十毫秒的计算时间，而主流USIM芯片的可用RAM仅8-16KB。因此，PQC-SUCI需要新一代支持PQC的USIM卡（通常称为"Quantum-Safe SIM"），运营商需要规划换卡周期。一个可行的过渡方案是：在第一阶段由UE的基带处理器/安全芯片执行PQC运算（而非USIM），USIM仅存储经典Home Network Public Key，但这需要终端芯片的配合。 **Q: 零信任架构是否要求部署SCP？** A: 不一定。TS 33.501 Section 13定义了两种SBI通信模型：直接通信（Direct Communication）和通过SCP的间接通信（Indirect Communication）。零信任策略执行可以在两个层面实现：（1）在SCP中集中执行——适用于已部署SCP的网络，运维集中度高；（2）在每个NF中分布式执行——适用于未部署SCP的场景，通过NRF下发的策略在每个NF本地执行。两种方式在安全效果上等价，但运维模式不同。建议新建网络优先部署SCP以简化安全管理。 **Q: 256-bit密钥层次对现有设备有什么兼容性影响？** A: Rel-19要求NF支持256-bit密钥但允许与128-bit UE互操作。当UE仅支持128-bit K时，AMF使用KDF输出的低128-bit作为派生密钥（即降级到128-bit模式），这是完全兼容的。当UE支持256-bit K时，AMF使用完整的256-bit输出。因此，升级核心网NF到256-bit模式不会影响现有128-bit UE的正常工作。需要注意的是，Roaming场景中，如果VPLMN的AMF仅支持128-bit而HPLMN的UDM/ARPF提供256-bit K，需要定义明确的协商机制。TS 33.501 Section 6.9.1中通过Security Capability Negotiation流程解决这一问题。 **Q: PQC迁移对5G核心网性能的量化影响有多大？** A: 根据Samsung Research和ATIS的联合测试报告，PQC对核心网性能的影响主要体现在三个方面：（1）SBI TLS握手延迟增加约50%（12ms→18ms），但通过TLS Session Resumption可降至15ms；（2）NRF的NF Profile存储增加约8倍（由于PQC公钥和证书链膨胀），需评估NRF内存配置；（3）SUCI Registration消息空口开销增加约1000 bytes，在RRC层可能需要额外的PDU分片。总体而言，对长连接、高吞吐的核心网业务影响可接受（<5%性能劣化），但对高频短连接场景（如大规模IoT接入）需特别关注。 --- > 本文由「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 等场景全覆盖。