<!-- title: 后量子密码与零信任重塑5G安全架构 -->

# 后量子密码与零信任重塑5G安全架构

## 一、引言：量子威胁倒计时

2024年8月，NIST正式发布三项后量子密码（PQC）标准：**FIPS 203（ML-KEM）**、**FIPS 204（ML-DSA）**和**FIPS 205（SLH-DSA）**，标志着全球密码学基础设施进入迁移窗口期。对通信行业而言，这一迁移的紧迫性远超其他行业——移动网络的设计寿命通常为15-20年，今天部署的5G基站和核心网必须在未来量子计算机成熟后仍能安全运行。

更严峻的是"先存储后解密"（**Harvest Now, Decrypt Later, HNDL**）攻击模式：攻击者现在截获加密流量，等量子计算机成熟后再解密。这意味着**那些需要长期保密性的通信数据已经处于风险之中**。

3GPP SA3工作组已启动**TR 33.703**研究项目（Study on Quantum-safe Migration），系统评估5G系统中密码算法的量子脆弱性，并制定分阶段迁移路线图。与此同时，5G的云原生SBA架构本身就在推动一场安全范式的转变——从边界防御到**零信任架构（ZTA）**。本文将深入分析这三条技术主线如何交汇，共同重塑5G安全架构。

## 二、5G系统中的量子脆弱性分析

### 2.1 密码算法全景扫描

5G系统从UE到核心网涉及大量密码算法，其量子脆弱性各不相同：

| 密码用途 | 当前算法 | 对称/非对称 | 量子威胁等级 | 受影响的3GPP规范 |
|---------|---------|------------|------------|----------------|
| SUPI→SUCI加密 | ECIES (P-256) | 非对称 | **高** — Shor算法可破 | TS 33.501 §6.12 |
| 5G-AKA认证 | EAP-AKA' (Milenage/Tuak) | 对称 | 低 — Grover仅平方加速 | TS 33.501 §6.1 |
| 网络域安全 (NDS) | IKEv2/IPsec (RSA/ECC) | 非对称 | **高** | TS 33.210 |
| SBI通信安全 | TLS 1.3 (ECDHE) | 非对称 | **高** | TS 33.501 §13 |
| SEPP互连安全 | TLS + JSON Web Encryption | 非对称 | **高** | TS 33.501 §13.2 |
| USIM应用 | AES-128/256, SHA-256 | 对称 | 低 | TS 33.102 |
| 空口加密 | NEA1/2/3 (AES/SNOW/ZUC) | 对称 | 低 | TS 33.501 §5.3 |
| 数据完整性 | NIA1/2/3 | 对称 | 低 | TS 33.501 §5.3 |

**关键结论**：空口加密和完整性保护使用的对称算法（AES/ZUC等）仅受Grover算法影响，密钥长度翻倍即可应对（AES-256足够安全）。真正的风险集中在**所有使用公钥密码的环节**——SUCI加密、NDS、SBI安全、SEPP互连。

### 2.2 Shor算法的精确威胁

Shor算法在足够大规模的量子计算机上可以在多项式时间内分解大整数和计算离散对数，这意味着：

- **RSA-2048**：需要约4096个逻辑量子比特，按纠错码开销约需**2000万物理量子比特**
- **ECDSA P-256**：约需**2330个逻辑量子比特**，约**1000万物理量子比特**
- **时间估计**：学术界主流观点认为，达到这一规模的容错量子计算机需要到**2035-2040年**，但部分乐观估计在2030年前后

虽然量子计算机成熟尚有时日，但HNDL攻击已经构成现实威胁——特别是对于那些涉及国家安全、商业机密的长期敏感通信。

## 三、PQC在5G系统中的迁移方案

### 3.1 整体架构


![图表1](images/telecom-deep-tech-r4-1719-mermaid-0.png)

> *图表 1*


### 3.2 SUCI加密的PQC迁移——最关键的战场

SUCI（Subscription Concealed Identifier）是5G隐私保护的基石。其核心机制是UE使用HPLMN的公钥通过ECIES方案加密SUPI，防止IMSI Catcher类攻击。

**当前ECIES方案（TS 33.501 §6.12）**：

```
SUCI = Concate(
    SUPI Type,
    Home Network Public Key Identifier,
    Routing Indicator,
    Protection Scheme ID,        // 0x01 = ECIES
    Scheme Output:
        - Ephemeral Public Key (EphPK, 33 bytes, P-256 compressed)
        - Encrypted MAC Key (Enc(K_M), 32 bytes)
        - Ciphertext (Enc(SUPI), variable)
        - MAC tag (32 bytes)
)
```

**ECIES加密核心流程**：

1. UE生成临时密钥对 $(ephSK, ephPK)$
2. 计算共享密钥：$K = KDF(x-coord(ephSK \cdot HN_{pub}))$
3. 派生加密密钥 $K_{enc}$ 和MAC密钥 $K_{mac}$
4. 加密：$C = Enc_{K_{enc}}(SUPI)$
5. 计算：$T = MAC_{K_{mac}}(C)$
6. 输出：$(ephPK, C, T)$

**PQC迁移方案——ML-KEM混合加密**：

TR 33.703和GSMA PQTN工作组推荐的方案是**混合KEM**，将ECIES与ML-KEM并行使用：

```
Hybrid SUCI Generation:
1. 经典ECIES分量:
   - 生成 (ephSK_ecc, ephPK_ecc) on P-256
   - K_ecc = KDF(x-coord(ephSK_ecc · HN_pub_ecc))
   - C_ecc = Enc(SUPI), T_ecc = MAC(C_ecc)

2. PQC ML-KEM分量:
   - encaps = ML-KEM-768.Encaps(HN_pub_mlkem)
   - (K_ml kem, ct_ml kem) = encaps
   // ct_ml kem = 1088 bytes (ML-KEM-768)

3. 混合密钥派生:
   K_hybrid = KDF(K_ecc || K_ml kem)
   C_hybrid = Enc_{K_hybrid}(SUPI)
   T_hybrid = MAC(K_hybrid, C_hybrid)

4. 输出SUCI:
   (ephPK_ecc, ct_ml kem, C_hybrid, T_hybrid)
```

**关键性能影响**：

| 参数 | ECIES (P-256) | ML-KEM-768混合 | 增幅 |
|------|--------------|---------------|------|
| 公钥大小 | 32 bytes | 1184 bytes (32+1152) | **+1152 bytes** |
| 密文开销 | 33 bytes | 1121 bytes (33+1088) | **+1088 bytes** |
| SUCI总长度 | ~70 bytes | ~2200 bytes | **+2130 bytes** |
| UE计算延迟 | ~1 ms (典型) | ~3-5 ms (估算) | +2-4 ms |
| 安全等级 | 128-bit经典 | 128-bit经典 + 192-bit量子 | 混合安全 |

SUCI从约70字节膨胀到约2200字节，对空口信令的开销增幅显著——一条RRC连接建立请求中的Registration Request消息将显著增大。这就要求gNB和核心网进行相应的缓冲区和消息解析能力升级。

### 3.3 5G-AKA的PQC增强

5G-AKA协议本身基于对称密码（Milenage/Tuak算法簇 + AES），不直接依赖公钥密码，因此在量子计算威胁下面临的风险相对较低。但学术界和3GPP仍在研究增强方案：

**5G-AKA-HPQC方案（Hybrid PQC）**：

该方案在传统5G-AKA基础上增加了一个基于ML-KEM的前向安全密钥交换层：


![图表2](images/telecom-deep-tech-r4-1719-mermaid-1.png)

> *图表 2*


注意：在PQC混合方案中，**SIDF（Subscription Identifier De-concealing Function）**需要同时支持ECIES和ML-KEM解封装，这对UDM/ARPF的计算能力提出了更高要求。

### 3.4 网络域安全（NDS）的PQC迁移

3GPP TS 33.210定义的网络域安全依赖IPsec/IKEv2，其密钥交换使用Diffie-Hellman（通常为ECDH P-256或P-384）。这是PQC迁移的另一个重点领域。

**迁移策略（参照IETF draft-pan-ipsecme-pqc-ikev2）**：

- **IKE_SA_INIT交换**：在KE payload中添加ML-KEM密钥交换分量
  - 传统：`KE = {DH Group, DH Public Value}`
  - 混合：`KE = {DH Group, DH Public Value} + {ML-KEM-768 Ciphertext}`
- **IKE_INTERMEDIATE交换**：使用独立的ML-KEM封装载荷
- **混合密钥计算**：$SKEYSEED = prf(DH\_shared || ML-KEM\_shared || nonce\_i || nonce\_r)$

O-RAN联盟也在同步推进PQC研究，O-RAN Study on Post-Quantum Cryptography已作为2025年发布的技术文档之一，重点分析O-RAN组件间接口（如O1, O2, A1, E2接口）的PQC迁移方案。

### 3.5 SBI安全的PQC迁移

5GC的Service-Based Interface使用TLS 1.3保护NF间通信。TLS 1.3的密钥交换基于ECDHE，证书签名使用RSA或ECDSA——两者都面临量子威胁。

**迁移路径**：

1. **密钥交换**：采用混合ECDHE+ML-KEM密钥交换（参照IETF draft-kampanakis-ml-kem-ikev2思路适配TLS）
2. **证书签名**：从ECDSA/RSA迁移到ML-DSA（FIPS 204）或ML-DSA+ECDSA混合签名
3. **TLS版本要求**：TR 33.703明确要求**淘汰TLS 1.2**，强制使用TLS 1.3+，这为PQC迁移提供了更好的基础

**ML-DSA签名算法性能参数**：

| 参数 | ECDSA P-256 | ML-DSA-65 | 增幅 |
|------|-------------|-----------|------|
| 公钥 | 64 bytes | 1952 bytes | **+1888 bytes** |
| 签名 | 64 bytes | 3309 bytes | **+3245 bytes** |
| 签名时间 | ~0.5 ms | ~2.5 ms | +2 ms |
| 验证时间 | ~1 ms | ~0.8 ms | 相当 |
| 安全等级 | 128-bit经典 | 128-bit经典+量子 | 混合安全 |

在5GC SBI场景中，每个NF实例需要持有混合证书（包含ECDSA和ML-DSA公钥），NRF服务注册和发现过程中需要验证双重签名。这显著增加了握手开销，但对NF间高频短连接场景（如AMF-SMF交互）的影响可控，因为TLS 1.3支持会话恢复。

## 四、SUCI增强隐私机制深度解析

### 4.1 从IMSI到SUCI的设计哲学

4G LTE中IMSI以明文传输的根本问题在于：IMSI是永久标识符，一旦被捕获就可以被用于长期跟踪。5G引入SUCI的核心设计原则是：**永久标识符（SUPI）永远不在空口以明文传输**。


![图表3](images/telecom-deep-tech-r4-1719-mermaid-2.png)

> *图表 3*


### 4.2 SUCI的协议细节（TS 33.501 Annex C）

SUCI的计算遵循ECIES-Profile A或Profile B（TS 33.501 Annex C.3）：

**Profile A（确定性加密模式）**：
```
输入: SUPI (IMSI: mcc-mnc-msin), HN_pub_key (P-256)
输出: SUCI

步骤:
1. ephKey = Generate-EC-Key-Pair()
2. shared = ECDH(ephKey.private, HN_pub_key)
3. K = KDF(shared.x, "5G AKA SUPI encryption")
4   // 使用SHA-256作为KDF
4. K_enc = K[0:128]   // AES-128加密密钥
5. K_mac = K[128:256]  // HMAC-SHA-256密钥
6. C = AES-CTR(K_enc, SUPI_bytes)
   // 注意: 使用CTR模式, 不需要IV
7. T = HMAC-SHA-256(K_mac, C)
8. SUCI = SUPI-Type | Key-ID | Routing | Scheme-ID | ephKey.pub | C | T
```

**Profile B（非确定性加密模式，增加随机性）**：
在Profile A的基础上增加了额外的随机输入，进一步防止关联分析。

### 4.3 Null-Scheme与隐私风险

TS 33.501定义了"null-scheme"（Protection Scheme ID = 0x00），即不加密直接传输SUPI。这主要用于：
- 未配置HPLMN公钥的场景
- 紧急呼叫（Emergency Call）
- 某些M2M/IoT设备

**实际部署中的严重问题**：

SK Telecom的实践表明，如果不在USIM中强制预置HPLMN公钥，大量UE会fallback到null-scheme，导致隐私保护形同虚设。SKT通过强制USIM刷新，在5G SA激活时实现了99%的SUCI采用率。**这一经验对所有运营商都是重要参考——SUCI隐私保护的有效性完全取决于USIM预配置。**

### 4.4 PQC增强SUCI的隐私分析

引入ML-KEM混合方案后，SUCI的隐私保护获得了一个重要附加属性：**即使未来量子计算机出现，历史SUCI记录也无法被追溯解密**。这对于需要长期隐私保护的用户（如政府、军方、企业高管）尤为重要。

但同时引入了一个新的隐私风险：**SUCI消息尺寸显著增大（从~70 bytes到~2200 bytes），使得基于流量大小的指纹分析更容易区分用户**。缓解措施包括：
- 使用ML-KEM-512代替ML-KEM-768（牺牲量子安全等级换取更小尺寸）
- 填充方案将所有SUCI统一到固定大小
- 使用多注册GUTI减少SUCI传输频率

## 五、零信任架构在5G核心网中的落地

### 5.1 为什么5G天然需要零信任

5G核心网的三个架构特征使得传统边界安全模型完全不适用：

1. **SBA服务化架构**：NF之间通过HTTP/2 SBI通信，没有明确的网络边界
2. **云原生部署**：NF以容器/微服务形式运行在云基础设施上，网络位置动态变化
3. **网络切片**：多租户共享物理基础设施，需要细粒度的隔离和访问控制

### 5.2 NIST零信任模型与5G安全架构的映射

NIST SP 800-207定义的零信任核心原则与3GPP TS 33.501的映射关系：

| ZTA原则 | NIST定义 | 5G对应机制 | 3GPP规范 |
|---------|---------|-----------|---------|
| 持续验证 | 每次访问都需认证授权 | NRF令牌服务(NF发现需OAuth令牌) | TS 33.501 §13.3 |
| 最小权限 | 仅授予完成任务所需的最低权限 | NF Service Access Authorization | TS 33.501 §13.4 |
| 微分段 | 将网络划分为小的安全域 | 网络切片隔离 | TS 33.501 §5.7 |
| 设备健康验证 | 验证设备安全状态 | UDM订阅数据中的接入限制 | TS 33.501 §6.2 |
| 加密传输 | 所有通信加密 | SBI TLS 1.3 + NDS IPsec | TS 33.210/TS 33.501 |
| 持续监控 | 实时安全分析 | NWDAF安全分析 | TS 33.501 §13.5 |

### 5.3 5GC-SDP：5G核心网的软件定义边界

IEEE和学术界提出了**5GC-SDP（5G Core Software-Defined Perimeter）**架构，将零信任原则系统性地融入5GC。其核心组件包括：


![图表4](images/telecom-deep-tech-r4-1719-mermaid-3.png)

> *图表 4*


**工作流程**：

1. **NF启动时**：NF向NRF注册时需提供mTLS证书（未来为PQC混合证书），NRF验证后颁发服务访问令牌
2. **NF间通信**：NF-A调用NF-B的服务时：
   - 首先向NRF获取NF-B的实例信息和访问令牌
   - 令牌中包含具体的**服务操作权限**（如仅允许AMF调用SMF的PDU Session Create，不允许调用PDU Session Release）
   - NF-B作为PEP，验证令牌后执行策略
3. **持续监控**：NWDAF收集所有NF通信日志，进行异常检测（如某NF突然访问非授权服务、异常高频调用等）

### 5.4 SEPP在零信任中的关键角色

**SEPP（Security Edge Protection Proxy）**是5G互连安全的核心组件（TS 33.501 §13.2），在零信任架构中扮演域间信任锚点的角色。

**SEPP的零信任增强**：

- **互连N32接口**：从TLS 1.2 + JWE升级到**TLS 1.3 + PQC混合密钥交换**
- **API级访问控制**：不仅保护传输层，还在应用层对每个SBI消息进行细粒度访问控制
- **拓扑隐藏**：SEPP作为代理隐藏内部NF拓扑，外部运营商只能看到SEPP
- **证书生命周期管理**：支持PQC混合证书的自动轮换和吊销

### 5.5 实战部署中的关键问题

**问题1：mTLS证书管理的规模爆炸**

一个中型运营商的核心网可能有数千个NF实例。每个实例需要独立的mTLS证书，证书轮换、吊销、审计的复杂度极高。

> **建议**：采用**SPIFFE/SPIRE**框架进行NF身份管理。SPIFFE为每个NF工作负载分配自动轮换的短生命周期SVID（SPIFFE Verifiable Identity Document），并与NRF的令牌服务集成。这已经在部分云原生5GC部署中得到验证。

**问题2：NRF单点风险**

NRF作为服务发现的中心节点，其安全性直接影响整个核心网的零信任基础。如果NRF被攻陷，攻击者可以伪造令牌，绕过所有访问控制。

> **建议**：
> - NRF部署为多实例集群，每个AZ至少2个实例
> - NRF数据库（NF Profile存储）使用etcd或类似分布式KV存储，开启mTLS和RBAC
> - 引入**NRF审计日志**，所有令牌颁发行为写入不可篡改的审计链

**问题3：SEPP互连证书体系**

国际漫游场景下，不同运营商的SEPP需要建立信任关系。当前基于GSMA IR.77的证书体系在引入PQC后需要重大升级。

> **建议**：遵循GSMA PQTN（Post-Quantum Telecom Network）工作组发布的Guidelines，分三个阶段：
> 1. **Phase 1**（2026-2027）：在现有TLS 1.3中添加ML-KEM混合密钥交换
> 2. **Phase 2**（2027-2028）：切换到PQC混合证书（ML-DSA + ECDSA）
> 3. **Phase 3**（2029+）：根据量子计算发展情况考虑纯PQC模式

## 六、PQC迁移分阶段路线图

综合TR 33.703研究结论、GSMA PQTN指南和ATIS量子白皮书，推荐的PQC迁移路线图：


![图表5](images/telecom-deep-tech-r4-1719-mermaid-4.png)

> *图表 5*


**各阶段USIM能力要求**：

| 阶段 | USIM要求 | 对现有终端的影响 |
|------|---------|---------------|
| Phase 0 | 无变更 | 无 |
| Phase 1 | USIM预置HPLMN PQC公钥 + ECDSA公钥 | 需要USIM换卡或OTA更新 |
| Phase 2 | USIM支持ML-KEM Encaps计算 | 部分老旧USIM卡可能不支持 |
| Phase 3 | USIM内置硬件PQC加速器 | 新发行USIM |

## 七、关键参数配置建议

### 7.1 PQC混合模式推荐配置

```
# 5GC SBI TLS 1.3 PQC配置 (示例)
tls:
  version: "1.3"
  cipher_suites:
    - TLS_AES_256_GCM_SHA384
  signature_algorithms:
    - ml_dsa_65_with_sha512    # PQC签名
    - ecdsa_secp256r1_sha256   # 传统签名(后备)
  signature_algorithms_cert:
    - ml_dsa_65
    - ecdsa_secp256r1
  key_exchange_groups:
    - x25519_ml kem768         # 混合密钥交换
    - x25519                    # 传统后备
  certificates:
    type: "hybrid"              # ECDSA + ML-DSA混合证书
    rotation: "24h"             # 短生命周期轮换

# SEPP N32互连PQC配置
sepp:
  n32:
    tls:
      version: "1.3"
      key_exchange: "x25519_ml kem768"
      certificate_type: "hybrid"
    application_layer:
      jwe_algorithm: "ECDH-ES+A256KW"  # 过渡期保留
      pqc_jwe_algorithm: "ML-KEM-768+ECDH-ES+A256KW"  # 混合模式
```

### 7.2 性能优化建议

1. **TLS会话恢复**：对高频NF间通信（如AMF↔SMF），使用TLS 1.3 PSK（Pre-Shared Key）避免重复握手
2. **证书缓存**：NRF缓存NF证书验证结果，有效期设置为证书有效期的1/3
3. **ML-KEM硬件加速**：在UPF和SEPP等高吞吐量NF上部署支持ML-KEM的硬件加速卡
4. **连接池复用**：NF间使用HTTP/2多路复用，减少TLS握手次数

## 八、常见问题

**Q: PQC迁移和零信任架构是否必须同步推进？**

A: 不是必须同步，但强烈建议协同推进。原因：PQC迁移涉及证书体系升级（从ECDSA/RSA到ML-DSA混合证书），而零信任架构恰好需要完善的证书管理和身份认证体系。在同一个PKI升级周期内同时完成两项改造，可以显著降低总成本和运维复杂度。如果先做PQC再做零信任（或反之），会导致证书体系被改造两次。

**Q: 现有5G SA网络中的UE能否通过软件升级支持PQC混合SUCI？**

A: 取决于USIM卡能力。ML-KEM Encaps计算的计算量约为ECIES的2-3倍，在USIM的有限计算资源上可能需要较长时间。多数现有USIM卡不支持通过OTA更新添加新的密码算法——需要物理换卡。但**基带处理器侧可以通过软件升级支持PQC**（如果基带芯片有足够的RAM存储ML-KEM的临时数据）。建议运营商在5G SA开通时就预置PQC能力USIM，避免后续大规模换卡。

**Q: 混合模式下，如果经典算法被攻破但PQC算法仍然安全，通信是否仍然安全？**

A: 是的。混合方案的安全性定义为"至少与其中一个分量一样安全"。在混合KEM中，最终密钥$K_{hybrid} = KDF(K_{classical} \| K_{pq c})$，攻击者需要同时攻破经典分量和PQC分量才能推导出共享密钥。因此，如果经典算法被量子计算机攻破但ML-KEM仍然安全，系统整体仍然安全。这也是3GPP TR 33.703和ANSSI（法国国家网络安全局）都强调混合方案的重要原因。

**Q: 零信任架构对5G网络切片安全有什么影响？**

A: 零信任增强了切片间的隔离性。传统模型中，同一物理基础设施上的不同切片可能通过共享的管理接口产生侧信道。零信任架构要求：每个切片内的NF使用独立的证书和身份标识；跨切片通信必须经过策略执行点（PEP）验证；NWDAF对切片间的异常流量进行实时监控。这实质上将网络切片从"逻辑隔离"提升到了"认证隔离"。

**Q: CNSA 2.0时间表对运营商有什么约束？**

A: 美国NSA的CNSA 2.0（Commercial National Security Algorithm Suite 2.0）要求：
- **2025年**：软件和固件签名开始使用PQC
- **2026年**：Web/云服务开始支持PQC
- **2030年**：国家安全系统完全迁移到PQC
- **2033年**：所有遗留系统迁移完成

虽然CNSA 2.0主要约束美国政府系统，但由于国际漫游和互连涉及多国运营商，即使非美国运营商也建议按此时间表规划，确保互操作性和合规性。

---

> 本文由「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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
