2024年8月,NIST正式发布三项后量子密码标准——FIPS 203(ML-KEM,密钥封装)、FIPS 204(ML-DSA,数字签名)和FIPS 205(SLH-DSA,无状态哈希签名)。这标志着全球密码学基础设施进入代际迁移的关键窗口期。对于移动通信产业而言,这不仅是算法替换问题,更是对3GPP安全架构(TS 33.501)底层基石的全面重构。
量子计算对通信安全的威胁可以用一个简单的时间公式描述:
$$T_{threat} = T_{harvest} + T_{quantum} - T_{migration}$$
其中 $T_{harvest}$ 是攻击者"先存储、后解密"(Harvest-Now, Decrypt-Later)的数据采集周期,$T_{quantum}$ 是容错量子计算机达到破解现有公钥密码所需量子比特数的时间,$T_{migration}$ 是网络完成PQC迁移的时间。当 $T_{threat} < 0$ 时,已被截获的通信数据将面临泄露风险。
在5G网络中,至少有五个安全协议层面临量子威胁:
| 安全层 | 传统算法 | 量子威胁 | 影响范围 |
|---|---|---|---|
| SUPI/SUCI加密 | ECIES(x25519/secp256r1) | Shor算法可破 | 用户身份隐私 |
| 5G-AKA认证 | ECDH/ECDSA | Shor算法可破 | 网络接入认证 |
| SBI接口保护 | TLS 1.3 + RSA/ECDSA | Shor算法可破 | 核心网NF间通信 |
| IPsec隧道 | IKEv2 + DH/ECDSA | Shor算法可破 | RAN-Backhaul |
| 漫游安全(SEPP) | TLS + 证书体系 | Shor算法可破 | 跨PLMN互联 |

图表 1
ML-KEM基于Module-Learning With Errors(MLWE)问题。其安全性基础可以形式化为:
给定矩阵 $A \in \mathbb{Z}_q^{k \times k}$,秘密向量 $s \in \mathbb{Z}_q^k$,误差向量 $e \in \mathbb{Z}_q^k$,计算 $b = As + e$。已知 $(A, b)$,求解 $s$ 在多项式时间内不可行。
ML-KEM密钥封装的核心流程:
// KeyGen
pk, sk = ML-KEM.KeyGen()
// pk = (A, t = As + e), sk = s
// Encaps
(ss, ct) = ML-KEM.Encaps(pk)
// ct = (u = A^T·r + e1, v = t^T·r + e2 + μ(ss))
// 其中 r, e1, e2 为随机/噪声项,μ()为编码函数
// Decaps
ss' = ML-KEM.Decaps(ct, sk)
// ss' = Decode(v - u^T·s) = μ(ss)
与当前5G中使用的ECIES(基于x25519 ECDH)对比:
| 参数 | ECIES-x25519 | ML-KEM-768 | ML-KEM-1024 |
|---|---|---|---|
| 安全等级 | Classical 128-bit | NIST Level 3 | NIST Level 5 |
| 量子安全 | 否 | 是 | 是 |
| 公钥大小 | 32字节 | 1,184字节 | 1,568字节 |
| 密文大小 | 32字节 | 1,088字节 | 1,568字节 |
| 共享密钥 | 32字节 | 32字节 | 32字节 |
| 密钥生成 | ~50μs | ~15μs | ~25μs |
| 封装 | ~50μs | ~18μs | ~28μs |
| 解封装 | ~50μs | ~18μs | ~28μs |
关键发现:ML-KEM在运算速度上并不比ECC慢,甚至在某些平台上更快。但开销在于带宽——公钥和密文从32字节膨胀到1KB+。这在通信协议中是必须正视的问题。
ML-DSA用于替代ECDSA/RSA进行数字签名,保护SBI接口证书链和SEPP漫游认证。
// Sign(sk, M)
z = Hash(M) mod q
y ← RandomPoly()
w = A·y mod q
c = Hash(w || z)
s = y + c·sk // 核心签名计算
return σ = (c, s)
// Verify(pk, M, σ)
w' = A·s - c·pk mod q
c' = Hash(w' || Hash(M))
return c' == c
签名尺寸对比:
| 算法 | 公钥大小 | 签名大小 | 签名速度 | 验证速度 |
|---|---|---|---|---|
| ECDSA-P256 | 64字节 | 64字节 | ~80μs | ~80μs |
| ML-DSA-44 | 2,496字节 | 2,420字节 | ~120μs | ~30μs |
| ML-DSA-65 | 3,936字节 | 3,309字节 | ~200μs | ~55μs |
| ML-DSA-87 | 4,672字节 | 4,627字节 | ~300μs | ~95μs |
5G中SUCI的计算流程如下:

图表 2
根据TS 33.501 Annex C.2,SUCI的加密方案有两种Profile: - Profile A:ECIES using Curve x25519(RFC 7748) - Profile B:ECIES using Curve secp256r1(NIST P-256) - Null-Scheme:明文传输(仅用于紧急呼叫等场景)
ECIES计算SUCI的伪代码:
// UE侧SUCI计算
Input: SUPI (IMSI), pk_HN (Home Network Public Key)
Output: SUCI
1. 生成临时密钥对: (eph_sk, eph_pk) ← KeyGen()
2. 共享密钥: shared_secret ← ECDH(eph_sk, pk_HN)
3. KDF推导: K_enc || K_mac ← KDF(shared_secret, info)
4. 加密SUPI: C ← AES-128-GCM(K_enc, SUPI)
5. MAC标签: T ← HMAC-SHA-256(K_mac, C)
6. SUCI = scheme_output || eph_pk || C || T
将ECIES替换为ML-KEM的SUCI计算方案:
// PQC-SUCI计算(UE侧)
Input: SUPI, pk_HN (ML-KEM Public Key)
Output: PQC-SUCI
1. 密钥封装: (K, ct) ← ML-KEM.Encaps(pk_HN)
2. KDF推导: K_enc || K_mac ← KDF(K, "5G-PQC-SUCI")
3. 加密SUPI: C ← AES-256-GCM(K_enc, SUPI)
4. MAC标签: T ← HMAC-SHA-256(K_mac, C)
5. PQC-SUCI = PQC_ID || ct || C || T
关键差异分析:
| 维度 | ECIES-SUCI | PQC-SUCI (ML-KEM-768) |
|---|---|---|
| SUCI总长度 | ~80字节 | ~1,200字节 |
| Registration Request增量 | +48字节 | +1,168字节 |
| RRC信令开销 | 可忽略 | 需评估RRC PDU分段 |
| SIDF解密计算 | ECDH (~50μs) | ML-KEM.Decaps (~18μs) |
| 量子安全 | 否 | Level 3 |
考虑到PQC算法尚未经过充分的时间考验(即可能存在经典/量子攻击的潜在漏洞),3GPP SA3和IETF的PQUIP工作组均推荐混合方案——同时使用传统算法和PQC算法,安全性取交集:
// Hybrid PQC-SUCI
Input: SUPI, pk_HN_classic (x25519), pk_HN_pqc (ML-KEM-768)
Output: Hybrid-SUCI
1. 经典分量: K_classic ← ECDH(eph_sk, pk_HN_classic)
2. PQC分量: (K_pqc, ct_pqc) ← ML-KEM.Encaps(pk_HN_pqc)
3. 组合密钥: K_hybrid ← KDF(K_classic || K_pqc, "5G-HYBRID-SUCI")
4. 加密: C ← AES-256-GCM(K_hybrid, SUPI)
5. Hybrid-SUCI = HYBRID_ID || eph_pk || ct_pqc || C || T
安全性论证:只要ECDH或ML-KEM之一保持安全,用户身份即受保护。即:
$$\text{Security}{\text{hybrid}} = \text{Security}$$}} \cup \text{Security}_{\text{ML-KEM}
代价是SUCI长度进一步增加(~1,280字节),但换来双保险。
传统5G-AKA使用ECDH进行密钥协商。2025年发表的5G-AKA-HPQC(Hybrid Post-Quantum Cryptography)协议提出了混合方案:

图表 3
前向安全性增强:传统5G-AKA不支持前向安全性(PFS)。HPQC方案通过在每次认证时生成新的临时ECDH密钥对和新的ML-KEM封装,实现了PFS:
$$K_{session} = \text{KDF}(CK | IK | K_{ECDH} | K_{ML\text{-}KEM})$$
即使长期密钥在未来被量子计算机破解,历史会话密钥仍然安全。
在典型商用5G网络中的时延增量:
| 认证阶段 | 传统5G-AKA | 5G-AKA-HPQC | 增量 |
|---|---|---|---|
| UE侧计算 | ~2ms | ~4ms | +2ms |
| HN侧计算 | ~3ms | ~6ms | +3ms |
| 信令传输 | ~15ms (avg) | ~16ms | +1ms |
| 总认证时延 | ~20ms | ~26ms | +6ms |
| 注册请求大小 | ~100字节 | ~1,400字节 | +1,300字节 |
6ms的时延增量在大多数5G场景中可以接受,但在URLLC(超可靠低时延)场景下需要优化。
5G核心网基于Service-Based Architecture(SBA),所有NF通过HTTP/2 RESTful API通信。传统边界安全模型在SBA中失效——攻击者一旦突破NF边界,即可横向移动。零信任架构(ZTA,参考NIST SP 800-207)在5G中的实现涉及三个核心维度:

图表 4
根据TS 29.500和TS 33.501,5GC的SBI接口使用TLS保护。PQC迁移方案:
TLS 1.3混合密钥交换(RFC 9180 + draft-ietf-tls-hybrid-design):
// TLS 1.3 Hybrid Key Share
ClientHello:
key_share = {
X25519(32 bytes), // 经典分量
ML-KEM-768(1184 bytes) // PQC分量
}
// 总 key_share ≈ 1216 bytes
ServerHello:
key_share = {
X25519(32 bytes),
ML-KEM-768(ct: 1088 bytes)
}
// 共享密钥推导
K = KDF(K_ECDH || K_ML-KEM)
| 接口 | 服务 | TLS模式 | PQC增强方案 |
|---|---|---|---|
| Nudm | UDM服务 | mTLS | Hybrid X25519+ML-KEM-768 |
| Nausf | AUSF服务 | mTLS | Hybrid X25519+ML-KEM-768 |
| Namf | AMF服务 | mTLS | Hybrid X25519+ML-KEM-768 |
| Nsmf | SMF服务 | mTLS | Hybrid X25519+ML-KEM-768 |
| Nnrf | NRF服务 | mTLS + OAuth2 | 证书链增加ML-DSA-65 |
| N32 | SEPP漫游 | TLS + JOSE | ML-DSA签名JWT |
NRF(Network Repository Function)是SBA的核心服务发现组件。零信任架构要求:
// NRF Scoped Access Token (PQC增强)
Header: {
"alg": "ML-DSA-65", // PQC签名算法
"typ": "JWT"
}
Payload: {
"iss": "nrf.5gc.mnc001.mcc460",
"sub": "amf-1.5gc.mnc001.mcc460",
"aud": "udm.5gc.mnc001.mcc460",
"scope": "nudm-ueauthentication",
"exp": 1747526400,
"nbf": 1747522800,
"jti": "a1b2c3d4-e5f6-7890"
}
Signature: ML-DSA-65(signing_key, Header || Payload)
ML-DSA签名的JWT token大小约为3.4KB(对比ECDSA-P256的~200字节),增加了约3.2KB的开销。对于高并发场景(如每秒百万级Token验证),这会对NRF性能产生显著影响。
SEPP(Security Edge Protection Proxy)是5G漫游架构的安全网关,通过N32接口实现跨PLMN安全通信。

图表 5
PQC迁移对SEPP的影响:
| SEPP组件 | 传统方案 | PQC方案 | 影响 |
|---|---|---|---|
| N32-c TLS握手 | TLS 1.3 + ECDH | Hybrid X25519+ML-KEM | 握手时间+5ms |
| JWS签名 | ECDSA-P256 | ML-DSA-65 | 签名大小+3.2KB |
| JWE加密 | AES-128-CBC | AES-256-GCM (不变) | 无影响 |
| 证书链 | RSA/ECDSA 3层 | ML-DSA 3层 | 证书总量+12KB |
| 每消息开销 | ~500字节 | ~5KB | 增加10倍 |
实际部署考量:国际漫游场景中,VPLMN和HPLMN可能处于不同的PQC迁移阶段。SEPP需要支持协商机制——在N32-c握手阶段协商是否使用PQC算法:
// N32-c capability negotiation
SEPP_A -> SEPP_B: {
"supportedVersions": ["v1", "v2-pqc"],
"supportedAlgorithms": {
"signing": ["ECDSA-P256", "ML-DSA-65"],
"keyExchange": ["X25519", "ML-KEM-768",
"X25519+ML-KEM-768"]
}
}
3GPP SA3工作组正在推进多个PQC相关工作项:
| 工作项 | 规范编号 | 状态 | 核心内容 |
|---|---|---|---|
| 256-bit算法支持研究 | TR 33.841 (Rel-16) | 已完成 | 评估256位对称算法,为PQC铺路 |
| PQC SUCI研究 | FS_PQC_SEC (Rel-19) | 进行中 | 研究ML-KEM用于SUCI加密的可行性 |
| PQC SBI接口 | TS 33.501 CR (Rel-19) | 讨论中 | SBI接口TLS混合密钥交换 |
| PQC AKA增强 | TS 33.501 CR (Rel-19) | 讨论中 | 5G-AKA协议PQC增强 |
| PQC证书框架 | TS 33.310 CR | 规划中 | ML-DSA证书签发与验证 |
| SUCI MAC增强 | FS_ePPID (Rel-19) | 进行中 | SUCI防重放和防链接增强 |

图表 6
当前USIM(UICC)平台计算能力有限,直接在USIM上执行ML-KEM/ML-DSA运算面临严峻挑战:
| USIM平台 | CPU频率 | RAM | ML-KEM-768 Encaps | ML-DSA-65 Sign |
|---|---|---|---|---|
| 传统Java Card | 10-20MHz | 4-8KB | ~30秒 | ~60秒 |
| 高端Java Card | 50-100MHz | 16-32KB | ~3秒 | ~8秒 |
| eUICC (eSE) | 200MHz+ | 64KB+ | ~500ms | ~1.5s |
| eUICC (TEE) | 1GHz+ | 512KB+ | ~50ms | ~200ms |
建议方案:
短期(2025-2027):SUCI计算卸载到ME(Mobile Equipment),USIM仅存储PQC私钥并提供安全接口。ME通过ME-PACE接口(TS 31.101)获取加密参数,在应用处理器上执行ML-KEM运算。
中期(2027-2029):新一代eUICC内置硬件加速器,支持ML-KEM/ML-DSA原生指令。算法在Secure Element中完成,无需卸载到ME。
长期(2029+):6G USIM(USIM+)原生支持PQC,SUCI计算完全在卡内完成,恢复端到端安全链路。
// 部署优先级矩阵
Priority = Impact(risk) × Feasibility(effort)
P1 (Critical + Easy):
- SEPP N32-c TLS → Hybrid X25519+ML-KEM
- NRF JWT签名 → ML-DSA-65
- OAM接口TLS → Hybrid
P2 (Critical + Hard):
- SUCI加密 → Hybrid ECIES+ML-KEM
- 5G-AKA → 5G-AKA-HPQC
- USIM密钥管理 → PQC密钥分发
P3 (Medium + Easy):
- EMS/NMS管理接口 → Hybrid TLS
- Logging/Sonar安全 → ML-DSA签名
P4 (Medium + Hard):
- 全量NF证书替换 → ML-DSA PKI
- IPsec全隧道 → IKEv2+ML-KEM
PQC-SUCI的1.2KB增量对RRC层有直接影响:
RegistrationRequest消息通过UL-DCCH承载。当SUCI长度超过RRC PDU限制时,需要触发RRC SegmentationRegistration Request中5GS Registration Type和Mobile Identity(SUCI)在同一NAS消息。PQC-SUCI可能触发NAS消息分段优化建议: 1. 使用压缩技术减少SUCI长度(如仅传输ML-KEM ct的低192字节,使用相同KDF推导剩余部分) 2. 在gNB侧实现RRC早期数据传输(Early Data Transmission, TS 38.331 clause 7.3a)来承载大SUCI 3. 对于URLLC终端,可考虑使用GUTI重注册(无需传输SUCI),仅在首次注册时使用PQC-SUCI
Q: PQC-SUCI和传统SUCI能否在同一网络中共存?
A: 可以。3GPP TS 33.501的SUCI格式中包含Protection Scheme ID字段。传统ECIES-SUCI使用scheme-id 0x01/0x02,PQC-SUCI可分配新的scheme-id(如0x03),Hybrid-SUCI分配0x04。UE根据USIM中预置的Home Network Public Key类型自动选择scheme。网络侧的SIDF(SUPI Subscription Identifier De-concealing Function)需要同时支持所有已定义的scheme,根据SUCI中的scheme-id字段路由到对应的解密模块。
Q: 运营商如何在不更换USIM卡的情况下实现PQC迁移?
A: 短期内可以通过"ME卸载"方案实现。USIM卡存储经典ECDH密钥,ME负责ML-KEM运算。具体来说,USIM通过GET CHALLENGE等APDU命令将Home Network公钥传递给ME,ME执行ML-KEM封装后将密文通过PUT DATA命令写回。但这降低了安全性——ME侧的密钥材料可能被提取。更安全的方案是利用OTA(Over-The-Air)机制远程更新USIM卡上的PQC公钥和算法小程序(applet),但这依赖于卡片剩余空间和OTA平台支持。
Q: PQC迁移对核心网性能的影响有多大?
A: 根据现有测试数据,影响主要体现在三个方面:(1) TLS握手时间增加约30-50%(因ML-KEM密钥交换的额外计算和传输开销),(2) JWT/OAuth2 token大小增加约15倍(ML-DSA-65签名约3.3KB vs ECDSA 64字节),影响NRF和SCP的内存与吞吐量,(3) SEPP漫游消息体膨胀约10倍,增加跨PLMN链路带宽消耗。建议在核心网部署PQC硬件加速卡(如支持ML-KEM/ML-DSA的HSM),可将TLS握手性能恢复到传统水平。
Q: 混合方案(Hybrid)的安全性真的比纯PQC高吗?
A: 从数学角度,混合方案的安全性等于两个组件安全性的并集。只要传统算法(ECDH)或PQC算法(ML-KEM)之一未被破解,系统就是安全的。这提供了"时间缓冲"——即使ML-KEM被发现存在结构性漏洞(类似SIKE被破解的情况),ECDH仍然保护通信安全。但混合方案的代价是性能和带宽开销翻倍。在过渡期(2025-2030)强烈推荐混合方案;当PQC算法经过充分密码分析验证后(预计2030+),可考虑切换到纯PQC。
Q: 6G安全架构是否会直接采用PQC?
A: 3GPP对6G(Rel-21+)的安全架构设计正在讨论中。业界共识是6G应原生支持PQC——即从协议设计之初就假设量子威胁存在,而非在现有5G-AKA上打补丁。这意味着6G-AKA可能直接使用ML-KEM/ML-DSA作为默认算法,SUCI加密默认PQC,SBI接口TLS默认混合密钥交换。但向后兼容5G UE的需求意味着6G网络仍需支持传统算法至少一个Release周期。
本文由「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 等场景全覆盖。
