5.2 关键应用场景

5.2 关键应用场景

本节摘要：SOURCE 5.2 覆盖 TLS 1.3、VPN、电子邮件 S/MIME、IoT 固件签名、区块链与政府 PKI。本节用场景对照表对齐推荐算法套件。

本节地图

1. 为公网 Web 选混合 TLS 套件
2. 说明 IoT 受限设备的 Kyber-512 取舍
3. 对比区块链地址方案迁移难点

一、场景对照（SOURCE 5.2）

二、性能对比实测关注点

• 握手延迟 ms 级增加是否触发 SLA
• 证书链大小 vs MTU
• 移动端电量与 Kyber encaps CPU

⚠️ 常见坑：IoT 用 SPHINCS+ 签 OTA——签名体积超 MTU 分包复杂。

💡 关键直觉：场景决定参数集；Web 与 IoT 不能共用同一「标准答案」。

一节小结

• Web：混合 TLS 先行
• IoT：小参数 Kyber/Falcon
• PKI：跟随 FIPS 与本国监管
• 区块链迁移最难（地址不变性）

深入讨论：各场景选型背后的真实约束

Web 场景的选型约束是「兼容性与带宽」。公网 TLS 要同时服务浏览器、移动端与各种 SDK，任何客户端不支持混合码点都会回退，因此通常采用 X25519MLKEM768 这类组合，既能被新客户端完整利用，又能被老客户端安全忽略。证书链方面，签名的体积会直接反映在握手字节数上，CDN 与终端都要同步升级，否则出现「客户端支持混合、证书链却是纯 RSA」的半套状态。

IoT 场景的约束是「资源与生命周期」。终端设备可能只有几十 KB 内存、数年一次固件更新，密钥交换选择 Kyber-512 可以显著降低封装开销，签名则倾向于 Falcon 这类小体积方案以便塞进 OTA 包。更要紧的是设备生命周期管理：出厂即写入的密钥与固件签名算法，决定了设备能否在未来安全地接收更新，因此 IoT 选型必须把「十年后这台设备还能安全升级」纳入考量。

# 场景选型速查（供方案评审参考）
场景        推荐组合                  核心考量
Web TLS     X25519MLKEM768           客户端兼容、握手带宽
VPN/IKEv2   ML-KEM + ML-DSA 混合      两端同步、UDP 包尺寸
S/MIME      ML-DSA 证书               邮件链大小、互操作
IoT 固件    Kyber-512 + Falcon        内存、功耗、OTA 体积
政府 PKI    FIPS 203/204 标准算法      合规时间表、审计要求
区块链      地址与签名迁移方案          地址不变性约束
​

区块链是特别值得单独说的场景：地址通常由公钥哈希推导，用户、交易所与链上合约大量依赖旧格式地址，换成 PQC 签名几乎意味着地址体系的整体变更，涉及钱包、节点、合约与资产迁移，难度远高于 Web TLS。这类场景的现实策略是先保证签名算法可升级，再逐步推进地址体系演进，而不是指望一次硬分叉解决所有问题。

工程实践扩展：场景选型的验收口径

每个场景在上线前都要定义自己的验收口径，而不是共用一份 Web 场景的标准。VPN 场景验收的是「隧道建立成功且两端算法一致」，邮件场景验收的是「证书链能被主流客户端验证且签名体积可控」，IoT 场景验收的是「固件更新包完整性与签名验证在目标芯片上的耗时」。验收口径的差异，正是上一节「场景约束决定参数集」的落地体现。

验收时还应包含负向用例：VPN 在两端算法不一致时能否协商到共同支持的安全组？邮件客户端版本过旧时证书链验证失败是拒绝还是降级？IoT 设备升级失败后能否回滚到上一版固件？这些负向用例往往暴露真实风险，比正向用例更能推动实现完善。

# 分场景验收口径速查
场景        正向验收                    负向验收
Web TLS     混合握手成功，证书链完整     老客户端回退经典套件可用
VPN         隧道建立，两端算法一致       协商失败时能回退安全组
邮件        证书被主流客户端验证         旧客户端提示但不阻断投递
IoT 固件    签名验证通过，体积不超限     升级失败可回滚上一版本
政府 PKI    证书符合 FIPS 要求           吊销后系统正确拒绝
区块链      签名算法升级不影响链上安全   旧地址资产仍可迁移
​

把验收口径与迁移试点绑定，每个场景的推进就有了清晰的完成定义。第 5 章的三节之间正是这样的递进关系：5.1 给出总体节奏，5.2 细化场景约束，5.3 兜底风险预案，三者共同构成一份可执行的迁移方案。