Post-Quantum Cryptography · Cisco Trustworthy · Secure Routers 8000

你今天发出的每一个数据包,都可能在 2032 年被公开朗读

这不是科幻。这是一场已经开始、但还没有结束的抢劫案——赃物已经被搬走,钥匙却要等到几年后才配好。 本文用第一性原理苏格拉底提问法,从"加密到底为什么安全"这个最朴素的问题出发, 一路推导到 NIST/CNSA 2.0 标准、Cisco 全栈量子安全战略、Trustworthy 硅片级信任根, 以及 Cisco 8000 系列安全路由器上真正可落地的配置与迁移路径。

2027-01-01 美国 CNSA 2.0:新采购的国家安全系统必须合规
2030-12-31 无法支持 CNSA 2.0 的设备必须全部退役
~897,864 2025 年最新研究估算:破解 RSA-2048 所需物理量子比特
10+ 年 金融、政务、国防数据的典型保密期——已经进入危险区
📖 阅读定位:CISO / 安全架构师 / 网络平台负责人 🧭 方法论:第一性原理 + 苏格拉底提问 🔧 落地对象:Cisco IOS XE 26.1.1+ / 8000 Series Secure Routers
序章 · Prologue

一场"先搬走保险箱,再慢慢配钥匙"的抢劫

我们习惯于这样理解安全事件:黑客攻进来 → 数据被偷 → 我们发现 → 我们修补。 整个链条里有一个隐含假设:"数据被偷"和"数据被读懂"是同一件事。 后量子时代最反直觉的地方,就是它把这两件事在时间轴上撕开了——中间可能隔着五年、十年。

先问一个问题:如果一个小偷搬走了你的保险箱,但他没有钥匙,你会报警吗?

大多数人会说:"当然要报,但至少东西是安全的。"——这正是今天绝大多数企业对加密流量的心理状态。 可如果这个小偷知道,五年后市面上会出现一把万能钥匙呢? 那么他今天搬走保险箱这个动作,就不是失败的抢劫,而是一次极其耐心的、成功率 100% 的预付款

这个攻击模式有一个专有名字:HNDL(Harvest Now, Decrypt Later)。 Cisco 的《Quantum-Ready Migration Guide》把它形容得非常准确:这些被归档的加密流量是一个 "时间胶囊(time capsule)"——今天不可读,但一旦 CRQC 投入运行,几十年的知识产权、国家机密、金融记录都会被追溯性地(retroactively)解密。

类比

把 HNDL 想成"银行把所有监控录像都存了下来,但看不懂里面的口型"。 十年后,唇语识别 AI 出现了。于是十年前那些"看了也没用"的录像,一夜之间变成了完整的对话记录。 你无法回到十年前重新拉上窗帘——时间是单向的,这也是为什么"以后再说"在密码学里是最昂贵的一个决定。

于是问题变得非常尖锐:凭什么量子计算机能"配出万能钥匙"? 要回答它,我们必须先回到一个更朴素、更根本的问题—— 我们今天所依赖的"加密",到底为什么是安全的?

这就是第一章。请注意:本文接下来不会先讲量子物理,因为那是本末倒置。 我们要先搞清楚"锁"的原理,才能理解"钥匙"为什么失效。

序章 · 记忆锚点

在量子时代,"数据被偷"与"数据被读懂"之间隔着五到十年——而你今天的选择,决定的是十年后的那一天。

第一章 · First Principles

加密为什么安全?答案不是"复杂",而是"时间"

要理解量子威胁,必须先把"加密"这件事拆到不能再拆的原子层。 我们要问的不是"用了什么算法",而是"这个算法的安全性,最终建立在什么之上?"

1.1 第一问:什么叫"安全"?

如果我告诉你,任何加密都可以被暴力破解——只要一个一个试完所有可能的钥匙——那你还认为加密是安全的吗?

是的,任何加密理论上都可以被暴力破解。所以密码学从来没有承诺"不可破解", 它承诺的是另一件事:"破解所需的时间成本,超过了这份数据的价值周期。"

精准定义

加密(Encryption):把可读的明文(Plaintext)按某个算法与密钥(Key)转换为不可读的密文(Ciphertext), 使得没有正确密钥的人,要还原明文所需的计算量,在实际工程意义上不可行(computationally infeasible)

请把注意力放在最后半句:安全性的落脚点是"计算不可行"——一个关于时间和算力的经济学判断, 而不是一个关于"绝对不可能"的物理断言。

类比

加密不是一堵墙,而是一个"迷宫收费站"。 任何人都可以走进迷宫,但走出来平均需要 300 万亿年。 我们说"这是安全的",意思是:宇宙的年龄只有 138 亿年,而你要走 2 万多个宇宙的年龄。 ——这就是 RSA-2048 面对今天最强超级计算机的处境(约 300 万亿年,超过宇宙年龄的 2 万倍)。

而量子计算做的事,不是"跑得更快",而是"把迷宫的墙拆掉,直接看见出口"。这是本质区别,第二章会展开。

1.2 第二问:现代密码学的四大职能是什么?

很多人把"加密"等同于"保密"。这是一个代价高昂的简化。现代密码学同时承担四项互不相同的职能—— 而量子计算对它们的冲击程度完全不同。这个区分,将直接决定后面所有的技术选型与迁移优先级。

C

机密性 Confidentiality

只有目标接收方能读懂内容。
典型实现:AES-256-GCM 加密数据载荷。

I

完整性 Integrity

内容在传输过程中没被篡改一个比特。
典型实现:SHA-384/512 哈希、GCM 的认证标签。

A

身份认证 Authentication

对面那台设备/那个人,确实是他声称的身份。
典型实现:RSA/ECDSA 数字证书。

N

不可否认 Non-Repudiation

发送方事后无法否认"这是我签的"。
典型实现:数字签名 + PKI 信任链。

记住这张图。因为后面你会看到一个惊人的事实:量子计算几乎完全放过了"机密性"的执行者(AES), 却精准打击了"身份认证"和"密钥交换"的执行者(RSA / ECC / DH)。

1.3 第三问:为什么会有"两种"加密?

如果对称加密又快又强,为什么还需要发明又慢又复杂的非对称加密?

因为对称加密有一个绕不过去的死结:双方必须先拥有同一把钥匙。 可如果你们还没有安全通道,你要怎么把钥匙安全地送过去? 这就是密码学史上著名的"密钥分发问题(Key Distribution Problem)"。

对称 Symmetric Encryption
  • 一把钥匙,加解密同用。
  • ——基于替换(Substitution)与置换(Permutation)等高度非线性的简单运算,适合大流量批量加密。
  • 典型密钥长度:80 ~ 256 bit。
  • 代表算法:AES-256-GCM、3DES。
  • 死结:如何把这把钥匙安全送到对面?
  • 密钥泄露后,所有历史数据需重新加密。
非对称 Asymmetric / Public-Key
  • 一对钥匙:公钥可公开,私钥绝不外传。
  • 公钥加密的,只有私钥能解;私钥签名的,公钥可验证。
  • ——依赖大整数模幂、椭圆曲线点乘等复杂数学运算,CPU 开销大。
  • 典型密钥长度:512 ~ 4096 bit。
  • 代表算法:RSA、Diffie-Hellman (DH)、ECC / ECDH / ECDSA。
  • 解决了密钥分发,也提供了签名与身份认证。

于是,工程界给出了一个所有现代安全协议(IPsec、TLS、SSH、MACsec)都在用的经典组合拳:

先用"慢而聪明"的非对称密码,安全地商定一把对称密钥;再用"快而强壮"的对称密码,加密真正的海量数据。

IPsec 就是最典型的例子:先用 IKEv2(内含 DH/ECDH、RSA/ECDSA)建立安全通道并协商密钥, 再切换到 AES-GCM-256 高速加密数据平面流量。

类比

就像寄送一个保险箱。
非对称加密 = 一个只能单向投入、无法取出的信箱口(公钥),任何人都能塞信进去,但只有信箱主人有钥匙(私钥)能打开。
我们用这个信箱口,只寄一样东西:一把真正的物理钥匙(对称会话密钥)
之后所有的重型货运,都用这把物理钥匙——因为它开锁只需一秒,而不是三分钟。

这个设计极其优雅,但也埋下了整个后量子危机的种子:如果"信箱口"被撬开了,那把物理钥匙就在里面等着被拿走。

1.4 第四问:非对称密码的"安全"到底建立在什么之上?

现在我们抵达了第一性原理的最底层。答案只有一个词:陷门函数(Trapdoor Function)

精准定义

陷门函数(Trapdoor Function):一个正向计算极其容易、反向求解极其困难的数学函数, 但如果掌握一个额外的秘密信息("陷门",即私钥),反向求解又会重新变得容易。

类比

把两桶不同颜色的颜料倒在一起搅拌,只需三秒钟。 但要从这桶混合色里,把原来的两种颜色精确地分离回去——几乎不可能。
这就是"正向易、反向难"。而"陷门"就是那张写着配方比例的纸条:有了它,你瞬间就知道原来是 3 份蓝加 7 份黄。

三大主流公钥算法,用的是三个不同的"颜料桶":

表 1-1 三大公钥算法的陷门结构对照
算法 正向运算(容易) 反向难题(困难) 陷门(私钥的作用)
RSA
Rivest–Shamir–Adleman
模幂运算
Modular Exponentiation
大整数质因数分解
Prime Factorization
凭欧拉函数 φ(n) 直接算出解密指数 d
DH
Diffie-Hellman
模幂运算 离散对数问题(DLP)
Discrete Logarithm Problem
模幂运算的可交换性(Commutative)
ECC
Elliptic Curve Cryptography
标量点乘
Scalar Point Multiplication
椭圆曲线离散对数(ECDLP) 标量乘法与点减法
陷门函数原理图 明文经易于计算的加密运算变为密文,反向解密极其困难,但持有私钥可通过陷门快速还原。 明文 Plaintext "Hello" 48 65 6C 6C 6F 密文 Ciphertext "Rijvs" UmlqdnM= 加密运算 · 容易 毫秒级完成(模幂 / 点乘) 无私钥反向求解 · 计算不可行 RSA-2048 ≈ 300 万亿年(经典计算机) 陷门 = 私钥 持有陷门 → 反向也变容易

图 1-1 陷门函数:安全性 = "反向计算的时间成本"。量子计算改变的正是这个红色箭头的成本。

1.5 把 RSA 拆到只剩算术:一个 5 分钟就能手算完的例子

抽象讲一万遍不如亲手算一遍。下面用一个刻意选到极小的例子,把 RSA 完整跑通。 请特别注意最后一步——它会直接告诉你量子计算机要攻击的是哪个环节。

  1. 随机选两个质数:p = 11,q = 3 这两个数是绝密的(私钥材料)。真实场景中它们各有 1024 bit。
  2. 计算模数:n = p × q = 11 × 3 = 33 n 是公钥的一部分,可以公开。
  3. 计算欧拉函数:φ(n) = (p−1)(q−1) = 10 × 2 = 20 这是"陷门"的核心——只有知道 p、q 的人才能算出它。
  4. 选公钥指数:e = 3(须与 φ(n) 互质) 工程上常取费马素数 65537(二进制 10000000000000001,只有两个 1,硬件运算极快)。
  5. 求私钥:d = e⁻¹ mod φ(n) → 3 × d ≡ 1 (mod 20) → 3 × 7 = 21 ≡ 1 (mod 20) → d = 7 公钥 = (n=33, e=3) 私钥 = (d=7)
  6. 加密(用公钥):明文 m = 2 → c = mᵉ mod n = 2³ mod 33 = 8 Alice 把 8 发到公网上。任何人都能看到 8、33、3。
  7. 解密(用私钥):m = cd mod n = 8⁷ mod 33 = 2,097,152 mod 33 = 2 2,097,152 ÷ 33 = 63,550 余 2。明文完美还原。

现在,请你扮演攻击者:你手里有 n = 33、e = 3、c = 8。你需要什么才能算出私钥 d ?

你需要 φ(n) = (p−1)(q−1)。而要算 φ(n),你必须知道 p 和 q。 而要知道 p 和 q,你必须把 33 分解成 11 × 3

33 你一眼就分解出来了。但如果 n 是一个 617 位的十进制数(RSA-2048)呢?
——整个 RSA 的安全性,就悬在这一根线上:质因数分解有多难。

第一性原理结论: RSA 的安全性不来自算法复杂,不来自实现精妙,也不来自密钥"够长"。 它唯一来自一个数学猜想:"大整数质因数分解在经典计算机上是指数级困难的。"

DH 和 ECC 同理——它们悬挂在"离散对数问题"和"椭圆曲线离散对数问题"这两根线上。 而 Shor 算法,恰好就是一把专门剪断这三根线的剪刀。

1.6 第五问:量子威胁到底藏在协议的哪一段?

这是本章最有工程价值的一个问题。因为它决定了:你要升级的不是"整个网络",而是一个非常具体的环节

所有现代传输安全协议(IKEv2/IPsec、TLS 1.3、SSH、MACsec via EAP-TLS)都分为两个阶段:

安全会话两阶段与量子脆弱点 阶段一密钥交换使用非对称密码,量子脆弱;阶段二数据加密使用AES-256对称密码,量子安全。 端点 A Initiator 公钥 / 私钥 端点 B Responder 公钥 / 私钥 阶段一:密钥交换与身份认证 · 量子脆弱 Quantum-Vulnerable 算法:RSA · Diffie-Hellman · ECDH · ECDSA (非对称 / 公钥密码) 动作:交换公钥 → 各自结合自己的私钥 → 推导出同一个共享秘密(Shared Secret) 产物:会话密钥 Session Key(用于阶段二) ⚠ 公钥在链路上明文传输 → Shor 算法可从公钥反推私钥 → 会话密钥失守 阶段二:数据加密与完整性 · 量子安全 Quantum-Safe 算法:AES-GCM-256 + SHA-384/512 (对称密码) 动作:用阶段一产出的会话密钥,高速加密所有业务流量 ✓ 高熵随机密钥 + 高度非线性运算 → Grover 算法仅提供平方级加速,仍不可行 结论:钛合金保险库(AES-256)造得再好,钥匙却装在一个未封口的信封里寄出去

图 1-2 一次安全会话的两阶段解剖。量子威胁 100% 集中在阶段一——这既是坏消息,也是好消息:它意味着改造范围是明确、可界定的。

类比

Cisco 白皮书里有一句极其精辟的表述,值得原样记住: "这就像建了一个钛合金金库,却把钥匙装在一个没封口的信封里邮寄出去(building a titanium vault but mailing the key in an unsealed envelope)。"

如果攻击者能破解密钥交换机制,那么后续数据加密有多强,完全无关紧要

1.7 本章收束:我们究竟要保护什么?

把前面五问的推导,压缩成一条清晰的因果链:

#推导步骤工程含义
安全 = 破解成本 > 数据价值周期安全是时间经济学,不是绝对承诺
对称加密快但无法解决密钥分发必须引入非对称密码作为"信箱口"
非对称安全性 = 陷门函数的反向难度整个 PKI 悬挂在 3 个数学难题上
协议分两阶段:密钥交换 + 数据加密脆弱点只在阶段一,范围可界定
阶段一用公钥密码,且公钥在链路上明文可见HNDL 攻击者只需截获握手过程即可"预付款"

表 1-2 第一章推导链。第 ⑤ 条是整个后量子迁移工作的起点。

现在我们已经知道锁的构造,也知道锁孔在哪。下一个问题自然浮现: 量子计算机凭什么能撬开这个锁孔?它是"更快的计算机",还是"完全不同的机器"? 为什么它能秒杀 RSA,却对 AES-256 束手无策?

这需要我们进入量子力学——但不用担心,我们依然只用第一性原理和类比,不写一个薛定谔方程

第一章 · 记忆锚点

加密的安全从不建立在"复杂"之上,而建立在"反向计算需要多少时间"之上——而量子计算,重新定义了时间。

第二章 · The Quantum Threat

量子计算凭什么撬开这把锁?——它不是更快,而是完全不同

关于量子计算,市面上流传最广、也最有害的一个说法是:"它比经典计算机快一亿倍。" 这句话不算错,但它会把你导向完全错误的结论。 如果量子计算只是"更快",那我们只需把 RSA-2048 升级到 RSA-8192 就万事大吉了。 现实是:这么做几乎没有意义。要理解为什么,我们必须先问一个看起来很笨的问题。

2.1 第一问:把经典计算机加速一亿倍,就等于量子计算机吗?

假设我给你一台运算速度是今天全球最强超算一亿倍的经典计算机。你能破解 RSA-2048 吗?

算一下:经典超算需要约 300 万亿年。快一亿倍 → 300 万年。
还是不行。

再快一亿倍呢?→ 0.03 年,约 11 天。看起来可行了?
但只要把密钥从 2048 bit 加到 4096 bit,破解时间就会重新回到天文数字。 因为质因数分解的难度是指数级增长的,而你的算力只是线性增长。 你永远追不上。

这就是关键洞察:单纯"变快"永远打不赢指数级难题。要赢,你必须换一种解题方式。

类比

想象一个巨大的迷宫,出口只有一个。
经典计算机是一个跑得飞快的人:他一条路一条路地试,跑错了就退回来换一条。你把他的速度提高一亿倍,他还是一次只能待在一条路上

量子计算机做的事完全不同:它把水灌进整个迷宫。所有路径同时被"探索",然后通过巧妙的物理干涉,让通向出口的那条水路"变亮",其余路径互相抵消。

差别不在腿的速度,而在"同时身处多少条路上"。这就是叠加(Superposition)。

2.2 四个原子概念:量子计算的全部秘密

我们不需要薛定谔方程。理解量子威胁只需要四个概念,而且每一个都有精确的日常类比。

概念一 · 量子比特 Qubit
精准定义

量子比特(Qubit):信息的基本单位,与经典比特一样只有 |0⟩ 与 |1⟩ 两个可测量的基态, 但它遵循量子力学而非经典物理的规则。物理实现可以是超导电路、囚禁离子、光子等—— 它的威力不来自物理载体,而来自它所展现的量子性质。

概念二 · 叠加 Superposition

经典比特在任一时刻必须是 0 或 1。量子比特可以处于两者的线性组合状态:

数学表达含义
|ψ⟩ = α|0⟩ + β|1⟩ α、β 称为振幅(Amplitude),是复数
P(0) = α² , P(1) = β² 概率 = 振幅的平方——这是全章最重要的一个等式
α² + β² = 1 所有可能结果的概率之和必须等于 1

表 2-1 量子态的三行数学。请牢记 概率 = 振幅²,2.4 节会用它解释一切。

类比

一枚旋转中的硬币。
它落地前,问它"是正面还是反面"是没有意义的——它处于"既是正面、又是反面"的旋转态。 但你一伸手把它拍住(测量),它立刻变成一个确定的正面或反面,旋转态永久消失。

这个"拍住"的动作,术语叫"波函数坍缩(Collapse)"。它是量子计算最大的约束——也是所有算法设计的核心难点。

经典比特与量子比特对比 经典比特任一时刻只能是0或1;量子比特可处于叠加态,测量后坍缩为确定值。 经典比特 Classical Bit 0 低电平 1 高电平 任一时刻,只能是其中一个 n 个经典比特 同时表示 1 个状态 10 个比特 → 一次只能是 1024 个组合中的某 1 个 量子比特 Qubit(叠加态) |ψ⟩ = α|0⟩ + β|1⟩ 0 1 同时存在,各占一定概率 测量 1 坍缩 · 叠加态永久消失 概率 = 振幅² (α² + β² = 1) n 个量子比特 同时表示 2ⁿ 个状态 10 个量子比特 → 同时承载全部 1024 个组合

图 2-1 经典比特与量子比特的根本分野。右侧红框提示了量子计算最大的工程约束:测量即坍缩

概念三 · 纠缠 Entanglement
精准定义

纠缠(Entanglement):两个或多个量子比特被关联起来, 使得其中一个的状态会直接决定另一个的状态,无论它们相距多远。 这是已被实验反复验证的物理现象,也是量子信息科学的核心。

类比

一双手套,分装在两个不透明的盒子里,寄往地球两端。 你打开自己那个,发现是左手 —— 你瞬间就知道地球另一端那个必然是右手。
这个类比不完美(经典关联也能做到),但它抓住了工程上最重要的那一点: 纠缠之后,多个量子比特的"命运"被绑定在一起,不能再分别描述。

为什么这很重要?因为量子纠错(QEC)、逻辑量子比特、以及跨芯片的分布式量子计算(DQC), 全都建立在纠缠之上。它是把"小机器拼成大机器"的胶水。

概念四 · 干涉 Interference

这是最容易被忽略、却最决定性的一个概念。因为它回答了一个致命的追问:

既然量子比特"同时算出了所有答案",那我们不就直接读出来吗?为什么还需要设计复杂的量子算法?

因为测量会坍缩。10 个量子比特承载了 1024 个状态,但你一测量, 只会随机得到其中 1 个——而且是按概率随机的。

如果 1024 个答案的概率都是 1/1024,那你读出来的就是一个纯随机数,毫无用处。

所以量子算法真正的工作,不是"算出答案",而是"在测量之前,把正确答案的概率推到接近 100%"。

类比

把量子计算想成"降噪耳机"。
降噪耳机的原理是:产生一个与噪音反相 180° 的声波,两者叠加后互相抵消——这叫破坏性干涉(Destructive Interference)。 而同相的声波叠加会变得更响——这叫建设性干涉(Constructive Interference)

量子算法工程师就是"声学调音师":他精心排布量子门, 让所有错误答案的振幅互相抵消(变静音),让正确答案的振幅叠加放大(变响亮)。 测量时,你听到的自然就是那个被放大的正确答案。

实现这一切的工具,是量子门(Quantum Gate)——它操作振幅 θ 与相位 Φ, 并且输入与输出的量子比特数量永远相等(与经典门不同)。几个关键门:

H · Hadamard 把一个确定态打散成 50/50 的均匀叠加态。所有量子算法的第一步几乎都是它——"初始化并行性"。
X · Pauli-X 量子版 NOT 门,绕 X 轴旋转 180°:|0⟩ ↔ |1⟩。
T 绕 Z 轴旋转 45°(π/4)。调相位用——这是控制干涉的精细旋钮。
CNOT · 受控非 作用于 2 个量子比特:控制位为 |1⟩ 时翻转目标位。这是产生纠缠的关键门。

2.3 量子并行性:2ⁿ 的暴力美学

现在把叠加与纠缠合起来看。n 个量子比特可同时承载 2ⁿ 个状态。 这个指数不是修辞,它的增长速度会击穿你的直觉:

量子比特数可同时承载的状态数现实参照
12¹ = 2
32³ = 8
102¹⁰ = 1,024
202²⁰ = 1,048,576约一百万
1272¹²⁷ ≈ 1.7 × 10³⁸IBM Eagle(2021)。该机比经典对手快约 1.58 亿倍:
同一任务经典机需 2,500 年,它需 1 分钟
2752²⁷⁵ ≈ 10⁸²≈ 宇宙中原子总数
1,1212¹¹²¹ ≈ 10³³⁷IBM Condor(2023)——已远超任何物理类比

表 2-2 量子并行性的指数曲线。请注意:状态数多 ≠ 有用——见 2.4 节的 Grover 实例。

2.4 眼见为实:Grover 算法的"振幅放大"四轮

为了让"干涉管理"从抽象变具体,我们看一个 4 量子比特(16 个状态)的搜索实例。 目标:在 16 个位置中找出唯一的正确答案(假设是 |1010⟩)。

Grover算法振幅放大过程 初始16个状态概率均等,经过三轮振幅放大后目标状态概率接近100%。 初始化后(H 门) 16 个状态概率均为 6.25% ▲ 红色为目标状态 |1010⟩ 第 1 轮迭代后 目标振幅被放大,其余被压低 P(目标) ≈ 47% 第 2 轮迭代后 建设性干涉持续累积 P(目标) ≈ 78% 第 3 轮迭代后 错误答案几乎完全静音 P(目标) ≈ 96% 每一轮迭代由两个阶段构成 ① Oracle(预言机) 给目标状态的振幅打上负号(相位翻转)——只做标记,不做放大 ② Amplification(振幅放大) 围绕平均振幅做反射,使被标记项升高、未标记项降低 关键:Grover 只需 √N 次迭代(16 个状态 ≈ 4 次),而经典搜索最坏需 N 次(16 次) 这是平方级(Quadratic)加速 —— 记住这个词,它决定了 AES-256 的命运

图 2-2 Grover 算法的振幅放大。量子算法的本质不是"算出答案",而是"把正确答案的概率推高到可测量"。

2.5 第二问:三种加速的分野——为什么 RSA 死了,AES 活了?

现在我们抵达本章的核心。量子算法带来的加速不是只有一种, 而这个差异,直接把整个密码学世界劈成了"生"与"死"两半。

线性、平方级与指数级加速对比 指数级加速曲线远超平方级,Shor算法为指数级威胁RSA,Grover算法为平方级不足以威胁AES-256。 问题规模 n(密钥长度 / 数据量) 加速倍数 线性 y = x 平方级 y = x² 指数级 y = 2ˣ Shor 算法在此 加长密钥 → 攻击成本几乎不增加 RSA / DH / ECC 全线失守 Grover 算法在此 密钥翻倍 → 攻击成本仍指数增长 AES-256 依然安全 Shor(1994) • 本质:周期查找算法 • 攻破:质因数分解 + 离散对数 • 加速:指数级(Exponential) → 公钥体系(PKI)根基崩塌 Grover(1996) • 本质:无结构数据库搜索 • 目标:对称密钥暴力搜索 • 加速:平方级(Quadratic) → 仅"折半"有效密钥强度 加速的"类型", 比量子比特的"数量"更致命

图 2-3 三种加速曲线的分野。这张图解释了后量子迁移的全部优先级逻辑。

Shor 算法:为什么它能一刀切断三条命线?

Shor 算法(Peter Shor, 1994)本质上是一个周期查找(Period-Finding)算法。 它的深刻之处在于:质因数分解和离散对数问题,都可以被数学变换成"求某个函数的周期"。 而求周期,恰好是量子傅立叶变换(QFT)擅长到极致的事情。

类比

想象你在听一段极其嘈杂的录音,想知道里面藏着的鼓点节奏是多少 BPM。
经典做法:一秒一秒地数拍子,反复回放,极其缓慢。
量子做法:把整段音频一次性送进一个"频谱分析仪", 周期性的鼓点会在频谱上形成一根极其明亮的尖峰,其余噪音被平摊成背景。

Shor 算法就是密码学的频谱分析仪。 而 RSA、DH、ECC 的数学结构里,恰好都藏着一根"周期性的鼓点"。

Shor 算法的攻击链条(回顾第一章的手算例子):

① 攻击者在链路上截获公钥 n(公开可见)→ ② Shor 算法用指数级加速,从 n 分解出 p 和 q → ③ 计算 φ(n) = (p−1)(q−1) → ④ 求出私钥 d → ⑤ 解出会话密钥 → ⑥ AES-256 加密的所有数据被完整解开

请注意第 ⑥ 步:AES-256 本身没有被攻破,它只是被"绕过"了。 锁没坏,钥匙被抄了。

Grover 算法:为什么它对 AES-256 无能为力?

Grover 算法把 N 次搜索降为 √N 次。对 256 bit 密钥(N = 2²⁵⁶)而言, 这意味着攻击者需要 √(2²⁵⁶) = 2¹²⁸ 次迭代。听起来"折半"了,很吓人。 但让我们老老实实把这个数算出来。

  1. 2¹²⁸ ≈ 3.4 × 10³⁸ 次迭代 即 340,000,000,000,000,000,000,000,000,000,000,000,000 次
  2. 假设每次迭代只需 1 微秒(10⁻⁶ 秒)——这是极其乐观的假设 真实量子门操作 + 纠错开销要慢得多
  3. 总耗时 = 3.4 × 10³⁸ × 10⁻⁶ = 3.4 × 10³² 秒
  4. 换算为年:3.4 × 10³² ÷ 3.15 × 10⁷ ≈ 1.1 × 10²⁵ 年
  5. 宇宙年龄 ≈ 1.38 × 10¹⁰ 年 → 比值 ≈ 7.8 × 10¹⁴ 约等于「780 万亿倍宇宙年龄」。Cisco 白皮书保守表述为"接近十亿倍宇宙年龄"——无论取哪个量级,结论完全一致

还有第二道保险:Grover 算法极难并行化(parallelizes poorly)。

与经典暴力破解不同——经典破解你买 1000 台机器就快 1000 倍。 但 Grover 的振幅放大是一个串行的、必须逐轮累积干涉的过程: 把 1000 台量子计算机并联,加速比只有约 √1000 ≈ 31.6 倍,而不是 1000 倍。 这让"堆硬件"这条路也被堵死了。

那为什么密码学界还是说"量子会削弱对称加密"?

因为 Grover 确实把有效安全强度折半了:AES-128 的有效强度降到约 64 bit(这是真正需要担心的), 而 AES-256 降到约 128 bit —— 而 128 bit 安全强度,至今仍被视为坚不可摧的黄金标准

所以正确的表述不是"对称加密安全",而是"足够长的对称密钥安全"。 这也正是 CNSA 2.0 明确要求 AES 必须使用 256 位密钥(所有密级)、 哈希必须用 SHA-384 或 SHA-512 的原因——为 Grover 的折半效应预留了两倍余量。

把两种算法的分野固化成一张表——这张表值得贴在墙上:

维度 Shor 算法 · 生死威胁 Grover 算法 · 可管理风险
加速类型 指数级 Exponential 平方级 Quadratic
攻击目标 非对称 / 公钥密码:
RSA、DH、ECDH、ECDSA
对称密码与哈希:
AES、SHA
被破坏的密码学职能 密钥交换 + 身份认证 + 不可否认 机密性(仅"削弱",非"攻破")
加长密钥能否解决 不能
RSA-8192 仍会被破,只是稍慢

128 → 256 bit 即恢复安全余量
能否靠堆硬件加速攻击 可有效并行 并行效率极差(√k 而非 k)
应对策略 必须更换算法
→ ML-KEM / ML-DSA / LMS
仅需加长密钥
→ AES-256、SHA-384/512
迁移紧迫度 最高——HNDL 已在发生 中等——多数环境已达标

表 2-3 Shor 与 Grover 对照表。整个后量子迁移工程的优先级,完全由左右两列的差异决定。

2.6 第三问:到底需要多少量子比特?——"逻辑"与"物理"的巨大鸿沟

新闻里常见"某公司发布 1000 量子比特处理器",很多人据此推断 Q-Day 还很远。 这是一个危险的误读,因为它混淆了两种完全不同的量子比特。

如果量子比特这么强大,为什么 IBM 有 1121 个量子比特,却破不了 RSA-2048(只需 1400 个)?

因为量子比特极其脆弱。它会因为环境噪声而"失相干(Decoherence)"——就像一枚旋转的硬币被桌面震动干扰而提前倒下。 一个"裸奔"的物理量子比特,根本无法支撑 Shor 算法所需的数百万步连续运算。

解决方案叫量子纠错(QEC):用很多个物理量子比特, 通过纠缠编码出一个稳定可靠的"逻辑量子比特"。

精准定义

量子纠错 QEC(Quantum Error Correction): 一整套技术,通过将一个逻辑量子比特编码到多个物理量子比特之上, 使得错误可以被检测并纠正,而无需直接测量底层量子态(因为测量会导致坍缩)。

逻辑量子比特(Logical Qubit):经 QEC 保护后、错误率足够低、可用于实际长程算法的"虚拟"量子比特。 破解密码所需的数字(RSA 1400 个 / AES-256 6681 个)指的都是逻辑量子比特。

类比

QEC 就像 RAID 磁盘阵列。
单块硬盘(物理量子比特)不可靠,随时可能坏。于是你用 5 块硬盘做 RAID, 对外呈现为一块极其可靠的"逻辑磁盘"——即使某块物理盘出错,数据依然完好。

更妙的是:QEC 的"校验"必须不直接读取数据本身——就像你不能为了检查硬盘健康而把数据全删了重写。 这在量子世界里是通过巧妙的纠缠测量实现的,也正是 QEC 最精妙的地方。

这个"比率"正在急速下降——这是 Q-Day 最大的加速器

物理 : 逻辑量子比特的比率,是决定 Q-Day 时间的关键杠杆。而它正在以令人不安的速度改善:

时间机构物理 : 逻辑比率
早期理论估计10,000 : 110,000×
2023 年 3 月Google49 : 149×
2023 年 12 月Harvard48 : 148×
2024 年 2 月IBM288 : 12≈ 24×
2024 年 4 月Microsoft + Quantinuum30 : 4≈ 7.5×

表 2-4 QEC 编码效率的演进。从 10,000× 到 7.5× ——三个数量级的改善,全部发生在最近两年内。

于是,"破解 RSA-2048 需要多少物理量子比特"这个数字,三次崩塌
破解RSA-2048所需物理量子比特估算的三次下降 从2012年10亿个物理量子比特,到2019年2000万个,到2025年约90万个,三次估算下降超过99.9%。 破解 RSA-2048 所需的物理量子比特估算 13 年间,同一个目标的门槛下降了 99.91% 2012 · Fowler et al. 1,000,000,000 ≈ 10 亿个 当时结论: "工程上遥不可及" −98% 2019 · Gidney & Ekerå 20,000,000 ≈ 2000 万个 耗时估算: 约 8 小时 −95% 2025 · Gidney 897,864 ≈ 90 万个 对照 IBM Condor(2023)已有: 1,121 个物理量子比特 2026 · Babbush et al.(最新) 破解 ECC-256 所需量子比特再降 10 倍 → 估算约 500,000 个物理量子比特。曲线仍在向下。

图 2-4 同一个攻击目标,门槛在 13 年间下降了三个数量级。这不是"量子计算机变强了",而是"我们对攻击成本的估算一直在被向下修正"。

请特别注意这个结论的性质:

上图的下降,主要不是因为量子硬件进步,而是因为算法与纠错编码的理论优化。 这意味着:Q-Day 的到来时间,可以被一篇论文单方面提前——而不需要任何新硬件出厂。

这是与传统 IT 风险管理最不一样的地方:你无法通过"观察对手买了多少机器"来预警。

2.7 第四问:Q-Day 什么时候到?——四个正在踩油门的因子

精准定义

Q-Day:CRQC(具备密码分析相关能力的量子计算机)真正可用、能够破解当代公钥密码的那一天。
Y2Q(Years to Quantum):距离 Q-Day 还剩多少年——这是安全团队真正需要盯住的倒计时。

业界普遍认为,量子计算的成熟要经历三级台阶。理解这三级台阶,你就能读懂所有量子计算新闻的真实含金量:

层级名称特征衡量指标产业现状
Level 1 NISQ
Noisy Intermediate-Scale Quantum
小规模实验;物理量子比特噪声大,限制了可扩展性;依赖量子误差缓解(Mitigation)而非纠错 Quantum Volume
量子体积
产业主体仍在此
Level 2 Early FTQC
Resilient / 早期容错
逻辑错误率显著低于物理错误率;能在维持纠错优势的前提下实现纠缠;支持更长的运算链 逻辑量子比特数
逻辑错误率
正在快速突破
Level 3 FASQ
Fault-Tolerant Application-Scale Quantum
商业级优势;可运行完整 Shor 算法 → 此即 CRQC ≈ 100 万 rQOPS
可靠量子运算/秒
终极目标

表 2-5 量子计算成熟度的三级台阶。当你看到"1121 量子比特"这类新闻时,先问它属于哪一级——绝大多数仍在 Level 1。

那么,有四个因子正在共同压缩 Y2Q:

Q-Day 四大加速因子 垂直扩展、水平扩展分布式量子计算、量子纠错编码效率、算法创新四个因子共同压缩Q-Day到来的时间。 Q-Day CRQC 可用之日 正被四股力量同时拉近 ① 垂直扩展 Vertical Scaling 单芯片物理量子比特数持续攀升 IBM 路线图:Falcon → Hummingbird → Eagle (127) → Osprey → Condor (1121) → 摩尔式增长仍在延续 ② 水平扩展 · DQC 分布式量子计算:用量子网络把多颗 小处理器"纠缠"成一台逻辑大机器 Cisco 已发布量子纠缠芯片 + 网络感知量子编译器 → 不必等单芯片长大 ③ 量子纠错 QEC 物理:逻辑比率 10,000× → 7.5× 同样的硬件,能编码出多三个数量级 的逻辑量子比特 → 当前最猛的加速器 ④ 算法创新 Algorithms 2026 Babbush et al.:破 ECC-256 所需 量子比特再降 10 倍 → 约 50 万个 另有混合量子电路声称量子门数 −99% → 一篇论文即可提前 Q-Day

图 2-5 Q-Day 的四个加速因子。请注意:其中两个(QEC 与算法)完全不需要新硬件出厂,纯靠理论突破即可生效。

为什么"分布式量子计算(DQC)"是最容易被低估的一项?

传统预期是:需要等到出现一台足够大、足够容错的单体量子计算机,才能跑完整的 Shor 算法。 但 DQC 改变了这个前提——通过量子网络把多颗较小的处理器用纠缠连接起来, 在逻辑上模拟出一台更大的机器。这意味着"单芯片量子比特数"这个我们习惯盯的指标, 可能根本不是决定 Q-Day 的那个瓶颈。

Cisco 在这条赛道上既是研究者也是建设者:Cisco Research / Cisco Quantum Labs 已发布 量子纠缠芯片网络感知量子编译器(network-aware quantum compiler), 并累计产出 30 余篇量子技术论文。——同一家公司,一手在建设量子网络,一手在为你构筑量子防线。

2.8 第五问:既然没人能确定 Q-Day,我们凭什么现在行动?

业界最权威的三个预测口径,给出的答案并不一致——但它们的结论方向完全一致

2030-04-14 Cloud Security Alliance 设立的官方 Q-Day 倒计时钟 CSA · 明确日期
10–15 年 Global Risk Institute《量子威胁时间线报告》:约 50% 受访专家的判断区间 GRI · 专家共识
"不太遥远的未来" 美国白宫 / NIST 的官方措辞:in the not-too-distant future US Gov · 官方定调
2030 – 2035 Cisco《Quantum-Ready Migration Guide》采用的功能性量子计算机出现窗口 Cisco · 规划基线

如果连专家都只能给出"10 到 15 年"这样宽泛的区间,那"现在行动"是不是过度反应?

恰恰相反。这个不确定性本身,就是必须现在行动的理由。下面三条,每一条都独立成立:

H

HNDL 已经在发生

不需要等 Q-Day。攻击者今天就在归档你的流量。 你要保护的不是"未来的数据",而是此刻正在链路上流动的数据——那是唯一无法追溯修补的东西。

L

设备生命周期 5–10 年

网络设备一旦上架,通常服役 5 到 10 年。 你今天采购的路由器,必须能撑过 Q-Day。 若采购时没有 PQC 能力与硬件加速,届时唯一的选项是紧急全网硬件更换——成本与风险都不可控。

M

迁移本身耗时数年

密码资产盘点、供应商评估、硬件刷新、软件升级、互操作验证、合规审计—— 大型企业的完整迁移周期通常是 3 年起。 如果 Q-Day 在 2032 年,你的启动窗口就在今天

Cisco 的官方表述值得原样引用(来自《Quantum-Ready Migration Guide》):

"如果你的数据具有 10 年以上的保密周期(shelf-life),那么它今天通过传统 IPsec VPN 传输时就已经被攻破了。 推迟实施 PQC 这个决定,等同于主动放弃你当前通信的长期机密性。"

以及那句更锋利的收尾:"面对量子威胁,沉默本身就是一个漏洞(silence is a vulnerability)。"

类比

这就像给房子上防洪保险。 气象学家说"未来 10 到 15 年,本地区有较大概率发生一次百年一遇洪水"。 你不会因为"日期不确定"而拒绝投保——恰恰因为不确定,你才必须现在投保。

更关键的是:密码学的"保险"不能事后追加。 洪水过后你还能重建房子,但被 HNDL 收割的流量,你永远无法收回。

2.9 本章收束:一张表锁定全部结论

#推导步骤可直接落地的工程结论
量子计算不是"更快",而是"同时探索所有路径 + 用干涉筛出答案" 加长密钥(RSA-2048→4096)对 Shor 无效,必须换算法
Shor 提供指数级加速,攻破质因数分解与离散对数 RSA / DH / ECDH / ECDSA 全线必须替换
Grover 仅提供平方级加速,且难以并行 AES-256 + SHA-384/512 仅需保证密钥长度即可
破解门槛的估算值在 13 年内下降 3 个数量级 Q-Day 可被一篇论文单方面提前,无法靠观察硬件预警
QEC 编码效率、DQC 水平扩展成为主要加速器 "单芯片量子比特数"不是正确的预警指标
Q-Day 时间不确定,但设备寿命与迁移周期是确定的 采购决策必须从今天起内建 PQC 与加密敏捷性

表 2-6 第二章推导链。第 ③ 与第 ⑥ 条共同定义了后量子迁移的范围时机

到这里,我们已经从第一性原理完整解释了"为什么": 锁的原理(第一章)、钥匙如何失效(第二章)。

但还有一个环节没有闭合。我们反复提到 HNDL,也说了"现在必须行动", 可"现在"到底有多急?有没有一个可以量化、可以拿去说服 CFO 的公式?

答案是:有。它叫 Mosca 定理,只有三个变量、一个不等号—— 而它会告诉你,你的组织是否已经处在危险区。 同时我们还要拆开"认证崩塌"与"启动链信任崩塌"这两个比 HNDL 更隐蔽、更致命的攻击面。

第二章 · 记忆锚点

量子计算的杀伤力不在于它有多少个量子比特,而在于它换了一种解题方式——所以"把密钥加长"这条路,从第一天起就是死路。

第三章 · Urgency & Attack Surface

把"紧迫感"变成一个不等式——以及三个比 HNDL 更可怕的攻击面

到目前为止,我们说了很多"必须现在行动"。但在董事会上,"必须"是一个很弱的词。 CFO 会问:"凭什么是现在,而不是三年后?"
本章的目标有两个:把这份紧迫感压缩成一个三变量的不等式; 然后告诉你——真正的威胁远不止"数据被解密"这一种,而另外两种,比 HNDL 更快、更狠、更难修补。

3.1 第一问:如何判断我的组织"已经"处于危险中?

在 Q-Day 到来之前,"我们还有多少时间"这个问题,真的只取决于量子计算机什么时候出现吗?

不是。它取决于三个数字的关系
① 你的数据需要保密多久
② 你完成迁移需要多久
③ Q-Day 距离现在多久

如果 ① + ② 已经超过了 ③,那么你不是"未来会有风险"——你是此刻正在制造未来必然泄露的数据

这个判断被 Michele Mosca 教授形式化为一个极其简洁的不等式。 它是整个后量子风险管理领域唯一一条可以写在便签上的公式。

a + b  >  c

Mosca 定理(Mosca's Theorem):若"数据保密期"加上"迁移所需时间", 超过了"CRQC 出现所需时间",则风险已经实质发生,必须立即启动转型。

a 数据保密期 Data Shelf-life 这份数据必须保持机密的年数。金融行业通常为 5–10 年;国防、医疗、知识产权可达 20 年以上。
b 迁移时间 Migration Time 把整体基础设施安全过渡到量子安全框架所需的时间。依风险偏好,从最快 6 个月到 3 年不等(含盘点、采购、部署、验证)。
c 威胁时间线 Threat Timeline 距离 CRQC 可用还有几年。Cisco 规划基线取 2030–2035;部分激进估算已压缩至 2028–2030。
类比

把它想成"给一封信选信封"。
c = 一种新型透视眼镜将在 6 年后上市。
b = 你需要 3 年才能换用防透视的新信封。
a = 这封信的内容必须保密 10 年。

那么在未来 3 年里,你寄出的每一封信,都是用旧信封装的,而它们要保密到第 13 年—— 其中第 6 到第 13 年这 7 年,全都暴露在透视眼镜之下。 你今天投进邮筒的每一封信,都在为 7 年的裸奔期做贡献。

Mosca 定理时间线对比 组织A迁移快、数据保密期短,a加b小于c,安全;组织B迁移慢、数据保密期长,a加b大于c,产生长达七年的暴露窗口。 同一个 Q-Day,两种截然不同的命运 今天 +2y +4y +6y +8y +10y +12y +14y c = 6 年 · Q-Day 组织 A 电商 · 短保密期 快速迁移 b=1y a = 3 年(数据保密期) a + b = 4 < c = 6 ✓ 安全 · 数据在 Q-Day 前已过期 组织 B 金融 / 政务 / 国防 长保密期 + 慢迁移 b = 3 年(迁移期) a = 10 年(数据必须保密到 +13 年) 暴露窗口 = 7 年 这 7 年里,所有 HNDL 归档流量都将被解密 a + b = 13 > c = 6 → 风险已实质发生 结论:组织 B 今天发出的每一个数据包,都在为那 7 年的暴露窗口做贡献。时间无法回收。

图 3-1 Mosca 定理的时间线可视化。请注意:组织 B 的问题不是"迁移慢",而是"迁移慢 × 数据寿命长"的乘积效应。

把这个公式代入真实行业,结果相当刺眼:

行业 / 场景 a 数据保密期 b 典型迁移期 a+b 对比 c=6~9 判定
国防 / 情报
国家机密、作战数据
25+ 年 3 年 28 年 严重超出 极高危
金融 / 银行
交易记录、客户身份
5–10 年 2–3 年 7–13 年 超出 高危
医疗 / 生命科学
病历、临床试验数据
20+ 年 2–3 年 22+ 年 严重超出 极高危
制造 / 知识产权
配方、设计图、工艺参数
15–20 年 1–2 年 16–22 年 严重超出 极高危
关键基础设施
电网、交通、水务 OT
设备寿命 20+ 年 3+ 年(停机窗口极小) 23+ 年 严重超出 极高危
零售 / 电商促销
短周期营销数据
1–3 年 1 年 2–4 年 未超出 可控

表 3-1 Mosca 定理行业代入。除了极短周期的营销类数据,绝大多数企业核心资产都已越线。

Mosca 定理最反直觉的推论:

b(迁移时间)越长,你的风险不是"晚一点开始",而是暴露窗口按 1:1 加长。 每推迟一年启动,暴露窗口就多一年。这意味着"再观察一年"这个决定, 实际成本是"多泄露一年的数据"——而且是不可撤销的。

3.2 第二问:量子威胁只有"数据被解密"一种吗?

如果我把所有数据都换成量子安全的加密,是不是就万事大吉了?

不是。而且这可能是整个话题里最危险的一个误解。

回顾第一章的四大职能:机密性、完整性、身份认证、不可否认。 Shor 算法攻破的不只是"密钥交换",它同时攻破了数字签名—— 而数字签名撑起的,是整个网络的身份体系信任根

"加密保护机密性,但认证保护身份。"——如果身份可以被伪造,那么再强的加密都只是为攻击者服务的加密

量子威胁的三个攻击面 机密性崩塌属于延迟生效的被动攻击;认证崩塌属于实时生效的主动攻击;启动链与供应链崩塌属于永久性攻陷。 同一把 Shor 算法,三个完全不同的攻击面 攻击生效时机 → 今天已在发生 Q-Day 当天 永久持续 ① 机密性崩塌 · HNDL 攻击对象 链路上的加密数据流 性质 被动 · 延迟生效 被窃取的是 过去 ② 认证崩塌 · Identity 攻击对象 数字签名 / 证书 / 控制平面 性质 主动 · 实时生效 被窃取的是 现在与未来 ③ 信任根崩塌 · Boot 攻击对象 固件签名 / 安全启动 / 供应链 性质 植入 · 永久持续 被窃取的是 设备本身 为什么大多数企业只看到了 ①,却忽略了 ② 和 ③ • ① 有明确的名字(HNDL)和媒体热度,容易被讨论;但它本质是"损失历史数据",损害范围被截获量所限定 • ② 不需要等待归档流量 —— 攻击者伪造签名后可立即冒充可信节点、注入路由、建立"可信"隧道,且不触发任何传统告警 • ③ 一旦攻击者拥有了信任根,任何软件补丁都无法清除后门 —— 因为后门是被"合法"启动流程验证通过的 ① 偷走过去 · ② 偷走现在与未来 · ③ 偷走设备的一生

图 3-2 量子威胁的三层攻击面。后两层几乎从未出现在主流讨论中——却恰恰是 CNSA 2.0 优先级最高的部分。

3.3 逐层解剖:三个攻击面的真实杀伤链

1 机密性崩塌:Harvest Now, Decrypt Later 被动攻击 · 已在进行 · 损害等于"你被截获的全部历史"

Cisco《Quantum-Ready Migration Guide》把这称为"最直接且最阴险的威胁(most immediate and insidious)"。 攻击者正在跨全球 WAN 链路,从高价值目标处截获并归档 PB 级加密流量

杀伤链(两个阶段,中间隔着数年):

  1. 【今天】被动监听 WAN 链路,完整录制 IKEv2 / TLS 握手包 + 后续加密载荷 不需要突破任何防线,也不产生任何异常告警——因为这只是"看"
  2. 【今天】按目标、时间、协议归档入库,形成"时间胶囊" 存储成本是唯一投入,而存储成本正在逐年下降
  3. 【Q-Day】对归档的握手包运行 Shor 算法,从公钥反推私钥 指数级加速,分钟到小时级完成
  4. 【Q-Day】重建会话密钥(Session Key) 此时 AES-256 完好无损,但它的钥匙已经在攻击者手里
  5. 【Q-Day】追溯性解密数年历史流量 知识产权、国家机密、个人信息全部暴露

Cisco 的原文警告值得逐字读一遍: "如果你的数据具有 10 年以上的保密周期,那么它今天通过传统 IPsec VPN 传输时就已经被攻破了(it is already compromised)。 推迟实施 PQC 这个决定,等同于主动放弃你当前通信的长期机密性。"

生效时机:延迟(Q-Day 后) 攻击性质:被动监听 可否事后补救:不可 — 时间单向 主要防御:PQC 密钥交换 / PPK
2 认证崩塌:身份伪造与控制平面劫持 主动攻击 · Q-Day 当天即刻生效 · 不触发任何传统告警

这是本章最需要你重新校准认知的部分。 今天用于 VPN 隧道建立、BGP 路由更新、管理访问的数字签名(RSA / ECDSA), 全部暴露在 Shor 算法之下。而签名被破意味着两件事:

A

身份伪造 Identity Forgery

攻击者可伪造用于标识网络对端的数字签名, 从而冒充一个可信的 Hub、一台管理服务器、或任意一个端点。 在协议层面,它"就是"那台设备。

B

控制平面劫持 Control Plane Hijacking

认证被破后,攻击者可向路由表注入恶意路由, 或直接建立"可信"隧道进入网络核心—— 绕过所有边界防御,且不触发任何传统告警(without triggering a single classical alarm)。

类比

HNDL 像是偷走了公司过去十年的会议录音。糟糕,但已经发生的事无法改变。
认证崩塌像是伪造了 CEO 的身份证、笔迹和门禁卡。 他现在可以走进任何会议室,签署任何文件,指挥任何人——而所有人都会照办,因为"证件是真的"。

更可怕的是:门禁系统的日志里,写的是"CEO 已授权进入"。你的 SIEM 不会报警,因为一切"合规"。

既然认证崩塌这么可怕,为什么它反而不需要"提前防御"?——它不是要等 Q-Day 才生效吗?

问对了,但答案分两半,而第二半才是关键。

对于"通信中的签名"(VPN 认证、TLS 证书):是的,它没有 HNDL 那种"追溯"效应—— 攻击者无法用未来的能力伪造一份过去的签名并让它生效。所以理论上可以晚一点换。

但对于"设备与固件的签名"(下一个攻击面):完全相反。 因为那些签名验证密钥,是在设备出厂时烧进硅片的——而硅片不能远程升级。

生效时机:Q-Day 当天 · 实时 攻击性质:主动冒充 / 注入 告警可见性:不可见(协议层合规) 主要防御:ML-DSA 量子安全签名 + PQ 证书体系
3 信任根崩塌:不安全启动与供应链威胁 永久性攻陷 · 补丁无法清除 · 这是 CNSA 2.0 优先级最高的一项

量子威胁不止存在于软件层,它延伸到设备最底层的地基。 如果启动流程没有被量子安全签名保护,整条硬件信任链就是断裂的。 Cisco 明确列出了三种后果:

M

恶意代码注入

攻击者可在启动序列中注入恶意代码。 这些代码运行在比操作系统更深的层级, 因此对标准安全监控工具完全不可见,同时提供持久化的高权限访问。

C

假冒硬件与软件

缺少量子安全的硬件信任根,攻击者可推送带恶意载荷的"官方"固件更新, 或在供应链中植入假冒元器件——两者都能绕过传统完整性检查。

P

持久化后门

攻击者可建立属于他自己、而非组织的"信任根"。 此后设备被永久攻陷——任何软件补丁都无法移除一个被"合法"启动流程验证通过的后门。

这解释了一个乍看反直觉的事实:NSA 把"固件签名"列为最紧急的迁移项,而不是数据加密。

CNSA 2.0 的原文理由有三条:
① NIST 已经完成了这类算法的标准化(LMS / XMSS),而其他后量子签名当时尚未标准化
这个签名用例更为紧急(more urgent)
③ 这类算法拥有最长的密码分析历史,且其性能弱点在此场景下影响最小。

因此 CNSA 2.0 的时间表是:固件/软件签名立即开始迁移 → 2025 年前支持并优先使用 CNSA 2.0 → 2030 年前全部部署完毕—— 比网络设备(2026 支持 / 2030 独占)和操作系统(2027 / 2033)都要早。

类比

把信任根想成"房子的地基里预埋的钢筋"。
墙纸可以换,家具可以换,甚至整层楼都可以拆了重建——但地基里的钢筋,你换不了。

这就是 Cisco 官方白皮书里那句话的重量: "信任锚(Trust Anchor)被内建在 Cisco 设备中,并且是被刻意设计成难以更新的(deliberately hard to update)。"
难以更新,正是它安全的原因;也正是为什么它必须在出厂时就是量子安全的—— 这是唯一一个"必须靠硬件刷新解决、无法靠软件升级解决"的攻击面。

被波及的设备级信任机制(全部依赖非对称密码):

信任机制作用CRQC 到来后的后果
固件与镜像签名
Firmware & Image Signing
确保固件、OS 镜像、二进制文件的真实性,防止篡改 伪造签名或推导签名密钥,恶意镜像看起来完全合法
安全启动
Secure Boot
用密码签名逐级验证启动流程的每个阶段 伪造这些签名,加载恶意启动组件而仍显示为"合法"
运行时完整性
IMA · Integrity Measurement Architecture
确保设备在运行期间持续处于可信状态 完整性检查可被绕过或伪造
硬件身份
SUDI · 不可变设备身份
用于认证、远程证明(Attestation)、供应链信任 可导致设备冒充、未授权访问、供应链攻陷

表 3-2 设备级信任机制的量子暴露面。第 6 章将逐一说明 Cisco Trustworthy 如何为每一项提供量子安全版本。

生效时机:植入即永久 攻击性质:供应链 / 启动链 可否软件补救:不可 — 需硬件刷新 主要防御:LMS / ML-DSA-87 + 硅片 TAm

把三个攻击面并排对照,优先级逻辑会立刻自明:

对比维度 ① 机密性崩塌 ② 认证崩塌 ③ 信任根崩塌
攻击对象 加密数据流 数字签名 / 控制平面 启动链 / 硬件身份
需要等 Q-Day 吗 是(但归档已在进行) 是(但当天即失控) 是,但准备必须在出厂前完成
攻击可见性 不可见(被动监听) 不可见(协议层合规) 不可见(低于 OS 层)
损害范围 历史数据(有界) 网络控制权(持续) 设备终身(不可逆)
补救方式 软件升级 PQC 密钥交换 软件升级 PQ 签名 + 证书 硬件刷新
CNSA 2.0 优先级 网络设备:2026 支持 / 2030 独占 随协议栈同步 最高
立即开始 / 2025 支持 / 2030 全部部署
核心 PQC 算法 ML-KEM(FIPS 203) ML-DSA(FIPS 204) LMS / XMSS(SP 800-208)
+ ML-DSA-87

表 3-3 三攻击面对照。最后一行揭示了后量子密码学"为什么需要三套不同算法"——这也是第四章的核心内容。

3.4 第三问:不可能一次性全换,那先换哪些?

如果全网有 8000 台设备、300 个应用、上万条加密链路——你会从哪一台开始?

错误答案是"从最容易的开始"(那只是自我安慰),也不是"从最贵的开始"(那是财务视角)。 正确答案是:从"Mosca 不等式超出得最多"的地方开始。

Cisco 与 NIST 指南给出的方法是四层优先级分级(Tier 1–4)。 分级的依据是三个维度的交叉:数据敏感度与保留期、业务关键性、当前加密用法与升级约束

Tier 1
最高
存在直接量子脆弱性的关键基础设施 核心 WAN 骨干、数据中心互联(DCI)、跨境专线、VPN 汇聚 Hub、管理平面(SSH / TLS)。 这些链路承载全公司流量,且直接使用 RSA / DH / ECDH 做密钥交换→ 立即行动。这里就是 HNDL 的主猎场。
Tier 2
嵌入了密码学的业务关键用途 核心交易系统、支付网关、身份认证服务(RADIUS / TACACS+ / LDAPS)、PKI 证书颁发机构。 特点是密码学被深度嵌入应用逻辑,改动需要应用侧配合。 → 近期规划,同步启动供应商沟通。
Tier 3
具有长期机密性要求的数据 知识产权归档、临床试验数据、法务档案、长期客户 PII。 这些数据的 a 值极大(15–25 年),即使当前流量不多,也必然越过 Mosca 不等式。 → 优先处理其传输与备份链路。
Tier 4
仅有短生命周期密码需求的系统 会话级临时凭证、短周期营销数据、开发测试环境、公开信息发布通道。 a 值通常小于 2 年,Mosca 不等式不成立。 → 随常规生命周期自然迁移即可,不必挤占预算与人力。

一个容易被忽略的实操要点:分级的输出物不是"一份清单",而是一份 CBoM。

CBoM(Cryptographic Bill of Materials) 应涵盖:算法、密钥、协议、证书四类资产,覆盖本地、云、IaaS、SaaS全环境, 并特别标注所有非对称加密用法——因为那就是 Shor 算法的完整攻击面地图。

没有 CBoM,任何"迁移计划"都只是一份愿望清单。第八章会给出完整的构建方法。

3.5 第四问:既然道理都懂,为什么大多数企业还没动?

这不是执行力问题,而是五个真实存在的结构性障碍。 诚实地列出它们,比喊口号更有价值——因为每一个障碍都有对应的解法, 而这些解法恰好构成了后面几章的主线。

1对现有运营的冲击(Impact to Existing Operations)

问题:即使后量子算法能"原地替换",现代企业网络与应用部署的规模与多样性 也意味着这个过程必然带来扰动。组织越成熟,问题越复杂——因为大范围、一刀切的变更, 在理解、实施、采纳、审计四个环节上都远难于小步增量变更。

典型误区:采用"推倒重建(rip and replace)"策略,试图一次性替换所有前量子基础设施。

解法:Brownfield 渐进升级 + 加密敏捷性。 采用能与既有技术和系统互操作的升级策略,可将成熟组织的扰动降到最低。 这在技术上依赖两件事:混合模式(PQ/T Hybrid)pqc optional 这类非强制协商开关——第五、七章会详细展开。

2性能特征差异(Varied Performance Requirements)

问题:新算法的性能特征与传统非对称算法完全不同密钥通常大得多,导致:

  • 存储与带宽需求上升
  • 更严重的分片(fragmentation)——这是最容易被低估的一项
  • 可能影响性能,甚至需要重写现有应用

具体数字有多夸张?ML-KEM-1024 的封装公钥为 1568 字节、密文 1568 字节, 导致 IKEv2/IPsec SA 建立所需消息数从传统的 4 条增加到 8 条

解法(两条腿):
协议层:必须启用 IKEv2 分片(建议 crypto ikev2 fragmentation mtu 1400) 与 TCP MSS 钳制(ip tcp adjust-mss 1360),避免 IP 层分片造成丢包。
硅片层:使用带专用 PQC 加速引擎的硬件。 Cisco 8000 系列的安全网络处理器(SNP)提供线速 PQC 加速, 消除软件加密固有的"性能税"——第七章会给出实测数据。

3知识缺口(Lack of Knowledge)

问题:在企业层面,真正站在迁移一线的是 IT 与网络运维团队。 而这些团队对即将部署与配置的新算法、新协议、新硬件、新软件 可能几乎没有任何经验

真实风险:不是"不会配",而是"配错了却以为配对了"。 例如手工 PPK 场景中,如果管理员选了一个低熵的口令作为 PPK, 整个后量子安全收益会被完全抵消——而 show 命令依然会显示 "Quantum Resistant"。

解法:① 建立量子卓越中心(Quantum Center of Excellence), 推动跨职能对齐与内部专家培养; ② 依赖预验证的配置目录(Configuration Catalog)而非手写 CLI—— Cisco 提供已按 NIST 与 CNSA 2.0 标准预先工程化的 IPsec / MACsec PQC 模板; ③ 使用集中编排(Catalyst SD-WAN Manager)自动生成 ML-KEM 的 IKEv2 提案, 消除在复杂密码字符串中手工输错的风险

4厂商准备度不足(Lack of Vendor Preparedness)

问题:不能假设供应商都已准备好应对后量子密码。 大多数厂商对升级持犹豫态度,并且在没有外部压力时看不到升级的必要性。 这就产生了发现、重新实现、甚至路由器整机刷新规划的需求。

更麻烦的现实:你的 PQC 迁移不是孤岛。 云服务商、中间链路(middle-mile)互联、SSE / SASE 服务、第三方身份提供商、 企业 CA 服务器——整条密码供应链都必须同步对齐, 否则你的量子安全隧道会在某个节点降级回传统加密。

解法:① 制定厂商问卷,明确询问四件事: 当前 PQC 实现状态 / 是否支持过渡期保护机制 / 路线图清晰度 / 是否支持加密敏捷性与 PQ/T 混合;
优先选择支持 10–15 年密码演进周期的方案,避免二次刷新;
③ 坚持采用 NIST 标准化算法,确保长期互操作性并防止专有锁定(proprietary lock-in)

5预算周期错配(Budgetary Lifecycle Mismatch)

问题:PQC 迁移的三个阶段——发现(Discovery)、实施(Implementation)、 长期维护(Maintenance)——具有截然不同的投资需求特征, 但企业预算流程往往只支持"一次性项目立项"。

结果是:盘点阶段拿到了钱,实施阶段发现远超预算; 或者实施完成后没有持续预算做配置漂移检测与合规度量, 导致安全态势随时间自然退化。

解法:为三个阶段建立独立且清晰的预算生命周期, 并用可量化的合规报告支撑持续投入。 例如 Cisco IQ 可持续按行业强制标准(如 FIPS 203)度量网络状态、 生成面向利益相关方的自动化合规报告, 并主动识别被手工回退到非 PQC 状态的设备—— 让"持续维护"从成本项变成可证明的风险控制项。

一个值得放在最后的数据点:根据《2025 Cisco 网络安全就绪指数》, 31% 的受访者将"网络"列为最难防御网络攻击的领域——高于任何其他领域。

这个数字与本章的结论正好互相印证:网络既是 HNDL 的主猎场,也是企业自认最薄弱的环节。 因此"从 WAN 开始(WAN-first)"不是厂商话术,而是风险与可行性交叉后的最优解。

3.6 本章收束

#推导步骤可直接执行的动作
Mosca 定理 a + b > c 把紧迫感量化为不等式 本周内为你的核心资产估算 a、b、c 三个值
除极短周期数据外,绝大多数行业已越线 停止争论"是否要做",转入"先做哪一段"
威胁有三层:机密性 / 认证 / 信任根 迁移计划必须同时覆盖三层,不能只做数据加密
认证崩塌是实时的,且不触发传统告警 把 PQ 签名(ML-DSA)纳入与 PQ 密钥交换同等优先级
信任根崩塌无法靠软件补救,且是 CNSA 2.0 最高优先级 硬件采购决策从今天起必须包含 PQ Secure Boot 能力
Tier 1–4 分级 + CBoM 是唯一可执行的优先级方法 启动密码资产发现,产出机器可读的 CBoM
五大障碍都有对应解法:Brownfield / SNP 硬件 / 配置目录 / 厂商问卷 / 三段预算 把障碍写进项目立项书,连同解法一起提交

表 3-4 第三章推导链。第 ⑤ 条是本章最重要、也最容易被漏掉的一条。

至此,"为什么"和"有多急"都已经闭合。下一个必然的问题是:"那么,换成什么?"

我们需要三套不同的算法,来分别修补三个攻击面。 它们的名字是 ML-KEM、ML-DSA、LMS/XMSS; 它们背后是 NIST 六年全球竞赛的筛选结果,也是 NSA 一份改变行业时间表的强制令。 而在这个过程中,有一个入围算法在标准发布前被人用一台单核笔记本在一小时内攻破—— 这件事恰好解释了"为什么必须先用混合模式"。

第三章 · 记忆锚点

HNDL 偷走你的过去,认证崩塌偷走你的现在,而信任根崩塌偷走设备的一生——只有最后一种,补丁永远救不回来。

第四章 · Standards Landscape

换成什么?——NIST 六年竞赛、五大算法,与一台单核笔记本引发的警醒

前三章回答了"为什么"和"有多急"。现在进入最实际的问题:换成什么?
答案不是一个算法,而是一套五件套——因为我们要修补的是三个不同的攻击面, 而每个攻击面需要不同的数学工具。但在介绍它们之前,必须先讲一个失败的故事, 因为那个失败定义了整个迁移策略的形态。

4.1 第一问:既然量子破了 RSA,为什么不直接发明一个"更强的 RSA"?

如果 RSA 的问题是"质因数分解不够难",那我们能不能找一个更难的数学问题,用同样的方式造一个新 RSA?

方向对了,但"更难"是个陷阱。
我们需要的不是"对经典计算机更难",而是"对量子计算机也难"—— 这是两个完全不同的要求。

Shor 算法的杀伤力来自一个特定的数学结构:周期性。任何能被转化为"求周期"的问题,都会被它撬开。 所以我们必须找到一类没有周期结构可供利用的难题。

而"哪些数学问题真的没有这种结构"——这个判断,谁也不敢一个人下。所以必须搞一场全球公开竞赛。

精准定义

后量子密码学 PQC(Post-Quantum Cryptography): 研究运行在经典计算机上、但能抵抗量子计算机攻击的密码算法的学科。

请注意两个关键限定:
运行在经典计算机上——PQC 不需要量子硬件,你现有的路由器 CPU 就能跑(这与 QKD 有本质区别);
抵抗量子攻击——它们被分析为对经典与量子计算机都安全

2016 年 12 月,NIST 启动了密码学史上最大规模的公开征集。 六年时间,全球学界与产业界共同参与,经历了一场极其残酷的淘汰。

2016-12-20 征集 Call for Nominations — NIST 面向全球公开征集后量子候选算法,分两大类:公钥加密/密钥交换、数字签名
2019-01-30 17+9 第二轮候选 — 17 个公钥加密/密钥交换候选 + 9 个数字签名候选进入第二轮
2020-07-22 4+3 第三轮候选 — 大幅收窄至 4 个加密/密钥交换 + 3 个签名候选。此时 SIKE 仍在名单上
2022-07-05 4 第四轮候选 — BIKE、Classic McEliece、HQC、SIKE一个月后,SIKE 被攻破。
2024 标准正式发布 — FIPS 203(ML-KEM)、FIPS 204(ML-DSA)、FIPS 205(SLH-DSA)三项联邦标准落地

图 4-1 NIST 后量子密码标准化竞赛淘汰漏斗(2016–2024)。请注意 2022 年 7 月与 8 月之间的那一个月。

决定性事件

2022 年 8 月:SIKE 在一台单核笔记本上,一小时内被完全攻破。

SIKE(Supersingular Isogeny Key Encapsulation)是一个基于超奇异同源问题的算法, 已经通过了 NIST 六年评审的层层筛选,进入了第四轮—— 也就是说,全球最优秀的密码学家花了六年时间审视它,没有发现问题。

然后,两位研究者发表了一篇论文,用一台普通笔记本的单个 CPU 核心、一小时, 完整恢复了 SIKE 的密钥。不是"理论上可破",是"实际上已破"。

如果一个通过了六年全球评审的算法,可以在标准发布前一个月被一台笔记本攻破——你还敢把全部身家押在任何单一新算法上吗?

这就是整个后量子迁移策略最重要的一条设计原则的来源。

我们不能推倒 RSA 然后单独站在 ML-KEM 上。我们必须同时站在两条腿上: 一条传统的(已经被审视了 40 年),一条后量子的(数学上抗量子,但实现与协议都还很新)。

类比

攀岩者的"双绳原则"。
专业攀岩者从不只挂一根绳。他们同时挂两个独立的保护点—— 不是因为哪根绳子不好,而是因为"任何单点都可能有未知缺陷"这个假设永远成立。

SIKE 事件证明了这个假设在密码学里同样必要。所以混合模式(PQ/T Hybrid) 并非过渡期的妥协,而是工程上的正确姿态攻击者必须同时破解两种算法,才能攻陷这条隧道。

Cisco 官方给出了采用混合模式的两条理由,都非常务实:

理由一(技术):虽然 PQC 算法本身被认为是可靠的,但软件实现与相关协议都是全新的。 即使经过充分测试,新漏洞通常也会随时间被逐步发现。 使用混合密钥交换,可以在 PQC 实现出现问题时拥有传统密钥交换作为回退保护

理由二(合规):许多组织要求产品必须 FIPS 认证, 但目前 PQC 算法完成 FIPS 认证的平均耗时是两年甚至更久。 采用"传统算法(已 FIPS 认证)+ PQ 算法"的混合方案,可以消除这个等待期

4.2 第二问:为什么需要五个算法,而不是一个?

回顾第三章的三攻击面表格最后一行。答案已经在那里了: 三个攻击面对应三种不同的密码学职能,需要三类不同的算法; 再加上被"削弱但未攻破"的对称加密与哈希,共五件套。

密钥建立
ML-KEM
新算法

替代 DH / ECDH
FIPS 203

身份认证
ML-DSA
新算法

替代 RSA / ECDSA
FIPS 204

固件签名
LMS / XMSS
新算法

替代 RSA / ECDSA
SP 800-208

机密性
AES-GCM-256
仅加长

算法不变
FIPS 197

完整性
SHA-384 / 512
仅加长

算法不变
FIPS 180-4

图 4-2 五大算法与四大密码学职能的映射。蓝色 = 必须换算法(Shor 攻击面);绿色 = 只需加长密钥(Grover 攻击面)。

下面逐一精讲。请特别留意每个算法"为什么被选中"的理由——那里面藏着很多工程智慧。

ML-KEM FIPS 203 密钥封装机制 · 守护「机密性」

全称:Module-Lattice-Based Key-Encapsulation Mechanism(基于模格的密钥封装机制)。 竞赛期原名 CRYSTALS-Kyber,NIST 标准化后正式改名为 ML-KEM。

替代对象DH · ECDH
数学基础Module Learning with Errors
标准编号FIPS 203
CNSA 2.0 参数Level V(即 ML-KEM-1024)

它解决的问题:今天的密钥交换算法(如 ECDH)直接暴露在 Shor 算法之下。 ML-KEM 用于保护通信系统之间初始秘密的交换—— 这个环节是我们在第一章图 1-2 中标红的"阶段一",也是 HNDL 攻击的唯一入口。

NIST 选择它作为通用加密标准的理由: ① 使用相对较小的密钥,便于交换; ② 运行速度快,对大多数工作负载有利。

这两点在网络设备上尤其重要——第七章你会看到 Cisco 8000 系列如何用 SNP 硅片把这个优势放大到线速。

三档参数集(安全强度递增、性能递减):

参数集封装公钥密文IKEv2/IPsec SA 建立所需消息数CNSA 2.0
传统 DH / ECDH(对照)4 条已弃用
ML-KEM-512800 B768 B6 条
ML-KEM-7681184 B1088 B6 条
ML-KEM-10241568 B1568 B8 条要求

表 4-1 ML-KEM 参数与协议开销。注意最右列:CNSA 2.0 强制要求所有密级都使用 Level V 参数。

工程必读:密钥变大 → 必须开分片。 由于 ML-KEM 公钥远大于传统 ECDH,IKEv2 消息会超过链路 MTU。 必须启用 IKEv2 分片,避免 IP 层分片导致在 MTU 受限的运营商网络中被丢包:

crypto ikev2 fragmentation mtu 1400

同时在 Hub 隧道接口与 Spoke LAN 侧接口做 TCP MSS 钳制:ip tcp adjust-mss 1360

ML-DSA FIPS 204 数字签名算法 · 守护「身份认证 + 不可否认」

全称:Module-Lattice-Based Digital Signature Algorithm(基于模格的数字签名算法)。 竞赛期原名 CRYSTALS-Dilithium。

替代对象RSA · ECDSA
数学基础Module Lattice Problem
标准编号FIPS 204
CNSA 2.0 参数Level V(ML-DSA-87)

它解决的问题:直接对应第三章的攻击面 ②(认证崩塌)。 一台 CRQC 可以伪造用于认证设备、路由更新、软件镜像的签名, 使攻击者能够冒充可信系统。 ML-DSA 通过提供能抵抗量子攻击的签名,阻止这种"认证体系的崩塌"。

为什么它会成为主流?业界普遍判断: 基于格(lattice-based)的 CRYSTALS-Dilithium 将成为占主导地位的签名标准。 NIST 同时标准化了 SPHINCS+(更名 SLH-DSA,FIPS 205)作为备选, 它基于哈希构造、无状态,但签名体积远大。

Cisco 的定位非常明确: ML-DSA 是"通用后量子签名算法"—— 当信任锚(Trust Anchor)本身需要自己生成签名时,用的就是它。 在 Cisco 8000 系列上,它出现在两个位置:

  • IOS-XE 26.2.1 起:用于 IKEv2 隧道认证,替代 RSA/ECC 验证路由器身份
  • 安全启动第 3–4 阶段:Bootloader 用 ML-DSA-87 验证 OS 镜像,OS 再用它验证应用镜像
LMS / XMSS NIST SP 800-208 哈希签名 · 守护「固件与软件完整性」

全称:Leighton-Micali Signature(LMS,RFC 8554)/ eXtended Merkle Signature Scheme(XMSS,RFC 8391)。 两者都属于哈希签名方案(HBS · Hash-Based Signature)。

替代对象RSA · ECDSA(固件签名)
数学基础抗碰撞哈希函数
标准编号NIST SP 800-208
NSA 推荐LMS + SHA-256/192

既然已经有了通用签名算法 ML-DSA,为什么固件签名要单独用一套 LMS?这不是增加复杂度吗?

NSA 在 CNSA 2.0 中明确给出了三条理由,每一条都很有说服力:

N

NIST 已完成标准化

在 CNSA 2.0 发布时(2022 年 9 月),LMS/XMSS 已经被 NIST 标准化很久了,而其他后量子签名尚未标准化。有现成标准就先用。

U

这个用例更为紧急

固件签名对应的正是第三章的攻击面 ③(信任根崩塌)——唯一一个无法靠软件补丁补救的攻击面。因此必须最先动手。

P

性能弱点在此场景影响最小

LMS 拥有最扎实的密码分析历史;而它的性能缺陷(需管理状态)恰好与固件签名"高完整性、低频率"的特征完美契合。

类比

LMS 是"一次性密码本",ML-DSA 是"随身印章"。
有状态(Stateful)意味着:签名者必须精确记录已用过哪些密钥索引,防止重用—— 就像一本一次性密码本,用过一页必须划掉。如果重用,安全性直接崩塌。

这个约束对高频通信来说是灾难(谁能在几百万次 TLS 握手中精确记账?), 但对"一年发布几次固件"这种场景,反而完全不是问题—— 而它换来的是"安全性只依赖哈希函数本身"这一极其干净的安全假设。

NSA 的严厉提醒:为避免削弱这些签名的安全性, 你必须满足 SP 800-208 的全部要求,包括管理状态(manage state)与在硬件中实现签名(implement signing in hardware)。

另外一个技术细节值得记住:攻击者构造的哈希碰撞对 LMS 是无关的(irrelevant), 因为 LMS 从不对"攻击者可选定值"的字符串做哈希——这是一个非常优雅的设计。

Cisco 的实践历史比标准还早: Cisco 员工 David McGrew、Scott Fluhrer、Michael Curcio 共同撰写了 LMS 标准 RFC 8554。 而 Cisco 早在 2013 年就已在部分 FPGA 与硬件中部署 LDWM(LMS 的前身)用于固件验证—— 参数为 SHA256、Winternitz 参数 W=4、树高 H=10。 这比 NIST 的 PQC 竞赛启动还早三年。

CNSA 2.0 后续放宽:现在 CNSA 2.0 也允许使用 ML-DSA-87 用于固件/软件签名。 这解释了为什么 Cisco 8000 系列的安全启动流程中, Microloader 用 LMS,而 Bootloader 与 OS 用 ML-DSA-87——两者并存,各取所长。

AES-GCM-256 FIPS 197 对称加密 · 守护「机密性 + 完整性 + 认证」

这是五件套中唯一"算法完全不变"的一项。 CNSA 2.0 相对 CNSA 1.0 在对称密码部分的唯一变化,是把 SHA-512 加入了列表—— NSA 自己的措辞是"a modest change... that allows a bit more flexibility"(一处温和的变更,提供了一点额外灵活性)。

替代对象无 — 沿用
数学基础替换与置换网络
标准编号FIPS PUB 197
CNSA 2.0 要求所有密级均须 256 位密钥

为什么它能幸免?第二章已经完整论证过,这里补充一个更本质的解释: 对称分组密码使用的替换(substitution)与置换(permutation)等运算是高度非线性的。 这些非线性组件使量子算法难以在输入与输出之间找到有用的关联关系—— 而那种关联,恰恰是破解加密的关键。

换句话说:AES 的数学结构本身,就对量子算法所针对的"特定困难问题"具有天然免疫力。 Shor 算法找不到周期可以利用;Grover 算法只能提供平方级加速,且难以并行。

GCM 模式的额外价值:AES-GCM-256 同时提供机密性、完整性与认证三重保障, 这也是为什么它被 CNSA 2.0 列为对称加密的必备保护措施。

SHA-384 / SHA-512 FIPS 180-4 哈希函数 · 守护「完整性」

哈希函数在安全体系中扮演关键角色,尤其是在数字签名与完整性校验中。 CNSA 2.0 要求所有密级均使用 SHA-384 或 SHA-512, 以确保系统即使在量子能力演进的情况下也能维持对篡改的强保护。

替代对象无 — 加长即可
CNSA 1.0SHA-384
CNSA 2.0SHA-384 或 SHA-512
用途签名 · 完整性 · 固件校验

Cisco 的具体实践:为了对未来的量子攻击保持保守姿态, Cisco 选择在软件发布中使用 512 位哈希——具体是 SHA2 家族中的 SHA512

这正是你在 cisco.com 下载软件时,页面上给出 SHA512 校验值的原因—— 供你在把镜像加载到虚拟机之前手工验证完整性。 而 Secure Boot 功能则为设备上的固件与软件链提供自动的完整性与真实性验证

还有一个容易被漏掉的角落:FPGA 配置比特流。 Cisco 使用 FPGA 实现多种系统功能,包括信任锚设计与数据面加密。 在可能的情况下,Cisco 使用 256 位 AES 密钥加密这些器件的配置比特流—— 因为如果这一层被篡改,上面所有的密码学都失去意义。

五件套的整体格局,用一句话概括:

LMS、ML-KEM、ML-DSA、AES-GCM-256、SHA-512 共同构成了量子韧性安全的完整基础。 它们分别保护密钥建立、身份认证、机密性、完整性—— 这四大支柱,是抵御当前威胁与未来量子攻击的必备条件。

而优先采用这些 NIST 批准的、基于标准的算法,还有一个战略价值: 确保长期互操作性,并防止专有技术锁定(proprietary lock-in)—— 让你的系统能与多元厂商生态安全通信。

4.3 第三问:格密码凭什么抗量子?——高维迷宫里找最近的路灯

ML-KEM 与 ML-DSA 都基于"模格(Module Lattice)"。 这个名字听起来令人生畏,但它的核心直觉其实非常朴素。

我们已经知道 Shor 算法擅长"找周期"。那格密码到底藏在哪里,让周期无处可寻?

因为格密码的困难性不来自数论中的乘法结构(RSA 的质因数、DH 的模幂), 而来自高维空间中的几何问题——具体说是"在一个高维网格中找最近的点"。

几何问题没有可供傅立叶变换提取的周期性。这是格密码抗量子的根本原因。

精准定义

格(Lattice):由一组基向量通过整数线性组合生成的、在 n 维空间中规则排列的无穷点阵

Module-LWE(Module Learning with Errors,模误差学习问题): 给你一堆"近似正确"的线性方程(每个方程都被加入了微小的随机误差), 要求还原出原始的秘密向量。ML-KEM 的安全性正是与这个问题的计算困难度直接相关。

NIST 的官方评估:"目前,ML-KEM 被认为是安全的,即使面对拥有量子计算机的攻击者。"

类比 · 三层递进

第一层:想象一座城市的路灯,整齐排列成网格。
你站在城市里的任意一点,问:"离我最近的路灯在哪?"——在二维平面上,你抬头一看就知道。

第二层:现在把这座城市变成 1000 维的。
路灯依然规则排列,但"最近的那一盏"变得极难判定——因为在高维空间里, 你的直觉完全失效,所有方向看起来都差不多远。这就是"最近向量问题"的困难所在。

第三层:再给每盏路灯的位置加上一点微小的随机抖动。
你观测到的不是精确的灯位,而是"大致在那附近"。 这就是 LWE 里的"误差(Errors)"——它把问题从"难"推向了"实际上不可解"。

而"陷门"就是那张原始的城市规划图:有了它,你立刻知道每盏灯的准确坐标; 没有它,你只能在 1000 维的黑暗中盲目摸索。

理解了直觉,我们来看 ML-KEM 在协议里实际怎么跑。 它与 Diffie-Hellman 的机制差异,是本节最有工程价值的部分。

Diffie-Hellman 与 ML-KEM 密钥建立机制对比 DH双方各自生成密钥对并交换公钥,通过对称运算得出共享秘密;ML-KEM由发起方生成密钥对,响应方用公钥封装出密文与共享秘密,发起方用私钥解封装。 传统方式 · Diffie-Hellman(对称结构:双方做同样的事) Initiator 发起方 Responder 响应方 生成自己的密钥对 公钥 + 私钥 生成自己的密钥对 公钥 + 私钥 双向交换公钥 对称:双方都发、都收 私钥 + 对方公钥 → Shared Secret 私钥 + 对方公钥 → Shared Secret ⚠ Shor 算法可从公钥反推私钥 共享秘密因此可被重建 → HNDL 成立 后量子方式 · ML-KEM(非对称结构:一方 KeyGen,一方 Encaps) Alice(发起方) Bob(响应方) 1 ML-KEM KeyGen 封装公钥 ek(可公开) 解封装私钥 dk(保密) 发送封装公钥 ek 2 Bob: Encaps(ek) 输出 ① 密文 c 输出 ② 共享密钥 K Bob 侧完成,K 已就绪 K Bob 的共享密钥副本 回传密文 c(K 本身从不上链路) 3 Decaps(dk, c) → K′ 且 K′ = K 关键差异:K 从未在链路上出现过 链路上只有 ek 与 c,且两者都受格问题保护

图 4-3 DH 与 ML-KEM 的机制对比。核心差异:DH 是"对称的双向计算",ML-KEM 是"一方生成、一方封装、原方解封装"的三步流程。

对比维度Diffie-Hellman / ECDHML-KEM(FIPS 203)
结构对称性 对称——双方执行相同操作 非对称——KeyGen / Encaps / Decaps 三个不同角色
发起方产出 公钥 + 私钥 封装公钥 ek + 解封装私钥 dk
响应方产出 公钥 + 私钥 密文 c + 共享密钥 K(不需要自己的密钥对)
链路上传输 双方公钥 封装公钥 ek(去程)+ 密文 c(回程)
共享密钥如何产生 双方各自用"私钥 + 对方公钥"计算得出 响应方封装时直接生成,发起方解封装还原
安全依赖 离散对数问题(Shor 可破 Module-LWE 问题(当前认为抗量子

表 4-2 DH 与 ML-KEM 机制对照。这个结构差异,正是 IKEv2 需要 RFC 9370「多重密钥交换」扩展的原因——第五章会展开。

混合模式下,两个共享秘密如何合并?

流程是:① 执行传统密钥交换 → 得到共享秘密 1;② 执行后量子密钥交换 → 得到共享秘密 2; ③ 用密码学方式组合多个共享秘密,生成"混合共享秘密(Hybrid Shared Secret)"; ④ 用它派生最终会话密钥。

安全性结论:攻击者必须同时破解两种算法,才能攻陷这条隧道。 这正是 SIKE 事件教给我们的那一课的工程落实。

4.4 第四问:谁在设定时间表?——CNSA 2.0 的强制力

算法有了,接下来的问题是:谁说必须换?什么时候换完? 答案来自 2022 年的一份美国政府文件,它的影响力远超美国国境。

NIST 发布的是"标准",而 NSA 发布的是"要求"——这两个词的区别有多大?

区别在于强制力,以及"不合规的后果"。

NIST 的 FIPS 203/204/205 定义了算法本身怎么算
而 NSA 的 CNSA 2.0(Commercial National Security Algorithm Suite 2.0) 规定了国家安全系统(NSS)必须在何时用上这些算法,否则需要豁免(waiver)

更关键的是:CNSA 2.0 明确指出——使用任何未获国家管理者批准的密码算法,通常都是不被允许的, 且需要针对该算法、实现与用例申请专门豁免。

精准定义

CNSA 2.0:美国国家安全局(NSA)发布的商用国家安全算法套件 2.0 版, 依据 NSD-42、NSM-8、NSM-10、CNSSP 11、CNSSP 15 等授权发布。 它适用于所有 NSS 对公共密码算法的使用(区别于 NSA 自研算法), 涵盖所有非密级与密级的 NSS 系统。

关键要求:依照 CNSSP 11,提供密码服务的软硬件除满足相应版本 CNSA 要求外, 还需通过 NIAP(National Information Assurance Partnership)或 NSA 验证

CNSA 2.0 的差异化时间表:五类设备,五个截止日

这是全文最实用的一张时间表。请注意:不同类型的设备有完全不同的 deadline, 而"固件签名"是最早的那一个——这与第三章的攻击面 ③ 完全对应。

设备 / 用例类型 支持并优先使用 CNSA 2.0 独占使用 CNSA 2.0 说明
软件与固件签名
Software & Firmware Signing
2025 2030 NSA 要求立即开始迁移;未达 CNSA 1.0 合规的已部署固件也须在 2025 前转为 CNSA 2.0 合规
Web 浏览器 / 服务器与云服务 2025 2033 面向公众的加密面积最大,故支持期早、独占期晚
传统网络设备
VPN、路由器等
2026 2030 本文重点。Cisco 8000 系列正对准这一栏
操作系统 2027 2033 OS 升级链条长,予以更宽窗口
小众设备
受限设备、大型 PKI 系统
2030 2033 资源受限或改造代价极高的场景
定制应用与遗留设备 2033 前完成更新或替换 无中间态——要么升级,要么下线

表 4-3 CNSA 2.0 差异化时间表。请特别注意"网络设备 2026 支持 / 2030 独占"——这正是当下所有路由器采购决策的硬约束。

"独占使用(exclusively use)"这个词的法律含义,NSA 在脚注里说得很清楚:

"即使由于协议标准、产品可用性或互操作性要求,混合方案可能被允许或被要求, 但到了给定日期,CNSA 2.0 算法将成为强制必选项,而单独选择 CNSA 1.0 算法将不再被批准。"

翻译成工程语言:混合模式在 deadline 之后仍可保留,但"只有传统算法"的配置会直接违规。 这也再次印证了混合模式的战略价值——它既是过渡手段,也是合规终态的一部分。

关键日期整合视图(含 NSS 与业界节点)

2022-09 CNSA 2.0 发布

NSA 依据 2022 年白宫行政命令(EO)与 NSM-10 发布 CNSA 2.0,公布算法选择与迁移时间表。此时 NIST PQC 标准尚未定稿——NSA 主动前瞻发布,目的是让厂商提前构建、让采购官员与系统所有者知道要求是什么。

2024 NIST PQC 标准正式落地

FIPS 203(ML-KEM)、FIPS 204(ML-DSA)、FIPS 205(SLH-DSA)发布,成为新密码标准的基础。同时 SP 800-208(LMS/XMSS)已在此前完成标准化。

2025 固件签名 + 云服务:支持并优先使用

PQC 镜像签名与验证的优先采用日期。Cisco 官方给出的对应节点同为 CY 2025。

2026 网络设备:支持并优先使用

Cisco 计划在2026 年底前,为其核心产品组合的大部分实现量子安全通信与量子安全产品能力——提前于监管截止日期

2027-01-01 NSS 新采购必须量子抗性

所有新的国家安全系统采购必须符合 CNSA 2.0。这是采购环节最硬的一条红线——它意味着 2026 年做出的选型决策,直接决定 2027 年能否交付。

2030-12-31 设备退役截止 / 固件与网络设备独占

无法支持 CNSA 2.0 的所有设备与服务必须全部淘汰。NSS 需在此日期前完成设备转换。软件固件签名与传统网络设备均需在此时进入 CNSA 2.0 独占状态。

2031-12-31 强制使用 CNSA 2.0 算法

CNSA 2.0 算法进入强制使用阶段。Cisco 白皮书亦引用 CSfC 项目要求:PQC 认证加密在 2031 年 12 月前成为国家安全系统的强制要求。

2033 浏览器/云/OS/小众设备独占;定制与遗留系统清零

剩余类别全部进入 CNSA 2.0 独占;定制应用与遗留设备必须已完成更新或替换。

2035 NSS 整体转型完成

依据 NSM-10,NSA 预期 NSS 向量子抗性算法的转型在 2035 年前全面完成。这也是多数国家(欧盟、英国、日本、韩国、台湾等)设定的终点年份。

图 4-4 CNSA 2.0 与全球关键合规节点整合时间线。2027 与 2030 是两个真正会影响今年采购决策的日期。

NSA 规定的五步执行方法

CNSA 2.0 并非只给日期,它还规定了转型的通用执行方法。 这五步对企业同样适用,只需把 NIAP 换成你自己的合规框架:

  1. NIAP 发布保护配置文件(Protection Profiles),明确产品须支持 CNSA 2.0 算法,符合 NIST 与其他标准组织的标准,并推动符合标准的密码设备开发。
  2. 所有新设备必须满足保护配置文件要求;旧设备必须在下一次更新时满足要求,以维持 NIAP 合规。
  3. 一旦经验证与测试的方案可用,即开始将 CNSA 2.0 算法作为首选配置选项。——注意这一步的措辞:不是"可用就切换",而是"可用就设为首选",允许混合共存。
  4. 由 NIAP 保护配置文件要求与 NSM-10 技术刷新要求,共同决定何时移除遗留算法支持。
  5. 此后,未定期刷新的遗留设备与软件将需要豁免(waiver),并须提交整改计划。

强制与稽核机制(Enforcement): NSS 所有者与运营者必须依 NSM-8 与 NSM-10 报告其 CNSA 1.0 与 2.0 的更新进展。 审批官(AO)应在风险管理框架(RMF)流程中评估 SC-12 安全控制项时度量合规性, 并需验证系统上软件/固件签名的 CNSA 2.0 合规性

一个容易被忽略的重点:NSS 不应以"FIPS-validated"作为 RMF 流程的评估标准, 而必须是 NSA 批准的方案。在接受商业产品的场合,NSA 通常批准符合 CNSSP 11 (即通过 NIAP 针对已批准保护配置文件的验证)的产品,前提是它们按 CNSSP 15 与其他指引正确配置

4.5 CNSA 1.0 → 2.0:哪些算法被判了死刑?

在 CNSA 2.0 生效前,我现在用的 CNSA 1.0 算法还有效吗?

有效,而且仍是强制要求——但它们已经被明确标注了"死期"。

NSA 的原话是:"这将在被强制时,实质上弃用(effectively deprecate)RSA、Diffie-Hellman(DH) 以及椭圆曲线密码(ECDH 与 ECDSA)的使用。NSA 敦促 NSS 所有者与运营者特别关注这些要求。 在过渡期内,CNSA 1.0 合规仍继续是必需的。"

职能 CNSA 1.0(现行标准) CNSA 2.0(未来标准) 命运
密钥建立 ECDH NIST SP 800-56A
Curve P-384(所有密级)
CRYSTALS-Kyber / ML-KEM
Level V 参数(所有密级)
弃用
DH IETF RFC 3526
最小 3072 位模数
RSA FIPS SP 800-56B
最小 3072 位模数
数字签名 ECDSA FIPS PUB 186-4
Curve P-384(所有密级)
CRYSTALS-Dilithium / ML-DSA
Level V 参数(所有密级)
弃用
RSA FIPS PUB 186-4
最小 3072 位模数
固件签名 (CNSA 1.0 无专门条目,沿用 RSA/ECDSA) LMS / XMSS NIST SP 800-208
推荐 LMS + SHA-256/192;亦可用 ML-DSA-87
新增
对称加密 AES FIPS PUB 197
256 位密钥(所有密级)
AES FIPS PUB 197
256 位密钥(所有密级)
保留
哈希 SHA FIPS PUB 180-4
SHA-384(所有密级)
SHA FIPS PUB 180-4
SHA-384 或 SHA-512
微调

表 4-4 CNSA 1.0 与 2.0 完整算法对照。红色"弃用"共 5 项,全部是非对称算法——与第二章 Shor 攻击面完全吻合。

4.6 第五问:FIPS 140-3 认证到底意味着什么?为什么它要等两年?

既然 NIST 已经发布了 FIPS 203 标准,为什么产品不能立刻"FIPS 认证"?标准和认证不是一回事吗?

完全不是一回事。这个区别是整个混合模式策略的第二根支柱。

FIPS 203算法标准——它规定 ML-KEM 该怎么算。
FIPS 140-3模块验证标准——它验证"某个具体产品里的某个具体实现, 是否真的正确、安全地实现了那个算法"。

前者是"菜谱",后者是"这家餐厅的厨房卫生许可证"。有菜谱不等于能开餐厅。

精准定义

FIPS 140-3:美国联邦信息处理标准,用于验证密码模块(Cryptographic Module) 的安全要求。它验证的不是算法本身的数学,而是实现的正确性、密钥管理、物理防护、自检机制、 运行状态与错误处理等一整套工程质量。

关键事实:目前 PQC 算法完成 FIPS 认证的平均耗时是两年甚至更久

类比

把 FIPS 认证想成"新药的临床三期试验"。
分子结构(算法标准)可能已经发表在《Nature》上,全世界都认为它有效—— 但要上市销售,你还必须做完全套临床试验,证明这批药、这条生产线、这个剂型是安全的。

而这个过程无法压缩。所以问题变成:"在这两年里,我该怎么办?"

答案就是混合模式(PQ/T Hybrid)——这也是 Cisco 白皮书明确给出的第二条理由:

"许多组织要求其环境中使用的产品必须 FIPS 认证。然而如前所述, PQC 算法完成 FIPS 认证的当前平均时间为两年或更久。 采用 FIPS 认证的传统加密算法生成初始密钥的混合方案,消除了这一延迟。"

这是一个极其漂亮的工程解法: 混合模式中的传统算法部分(ECDH / P-384)已经是 FIPS 认证的, 因此整体方案可以立即满足合规要求;而 PQ 部分(ML-KEM)提供量子抗性, 并在 FIPS 认证完成后自然升级为完整合规。

Cisco 对硬件层面的建议同样务实:虽然许多 Cisco 设备已包含关键的量子安全防护 (例如用于 Secure Boot 的 LDWM),但目前尚不存在完全符合 CNSA 2.0 算法要求的硬件。 因此建议组织在产品刷新周期中,随量子安全硬件的可用而逐步纳入。

三个正在演进的硬件层标准,值得在采购问卷中列明:

  • 唯一设备身份证书(Unique Device Identity Certificates)——PQ 版本正在演进
  • PQC 就绪的 CPU 组件——业界可用性正在推进
  • PQC 就绪的 TPM(可信平台模块)——同上

4.7 协议层:IETF 如何把算法装进 IKEv2、TLS 与 SSH?

有了算法标准,还需要协议标准——规定这些算法具体怎么塞进现有握手流程。 这部分由 IETF 负责,且Cisco 在其中扮演了标准共同作者的角色

IKEv2 / IPsec ——仅支持混合模式
RFC 9370 Multiple Key Exchanges in IKEv2 定义 IKEv2 中的多重密钥交换机制,使一次握手可同时执行传统 DH/ECDH 与 PQ ML-KEM,是混合 IKEv2 的基础扩展
RFC 9242 Intermediate Exchange in IKEv2 中间交换机制,用于在 IKEv2 中传输大体积数据——这正是 ML-KEM 大公钥所必需的
RFC 8784 Mixing Preshared Keys in IKEv2 for Post-quantum Security 由 Cisco 首倡(pioneered)。定义如何将后量子预共享密钥(PPK)混入 IKEv2 密钥派生 —— 第五章的核心机制
IETF Draft PQ Hybrid Key Exchange with ML-KEM in IKEv2 定义在 RFC 9370/9242 框架下使用 ML-KEM 的具体配置文件(profile)

一个重要的技术差异,必须记住:

IKEv2 目前仅支持混合模式(Hybrid only), 而 TLS/DTLS 与 SSH 同时支持混合模式与纯 PQC(Pure-PQC)。

这不是 Cisco 的实现限制,而是协议标准层面的现状—— RFC 9370 的设计初衷本身就是"多重密钥交换",即混合。

TLS 1.3 / DTLS ——混合与纯 PQC 均支持
IETF Draft Hybrid key exchange in TLS 1.3 同时使用多种密钥交换算法,确保即使其中除一个之外全部被攻破,仍能维持量子安全。Google 等业界领袖当前已支持
IETF Draft ML-KEM Post-Quantum Key Agreement for TLS 1.3 定义 TLS 1.3 中的纯 ML-KEM 密钥协商
SSH ——混合与纯 PQC 均支持
IETF Draft PQ/T Hybrid Key Exchange with ML-KEM in SSH 将椭圆曲线与 ML-KEM 方案同时作为密钥交换方法,目标是构造出即使使用量子计算机也无法求解的离散算法问题
IETF Draft Module-Lattice Key Exchange in SSH 定义 SSH 中的模格密钥交换
CNSA 2.0 专用配置文件(Profiles)——Cisco 参与提交
draft-guthrie-cnsa2-ipsec-profile CNSA 2.0 的 IPsec 配置文件
draft-becker-cnsa2-tls-profile CNSA 2.0 的 TLS 配置文件
draft-becker-cnsa2-ssh-profile CNSA 2.0 的 SSH 配置文件
draft-ietf-opsawg-tacacs-tls13 TACACS+ over TLS 1.3——被广泛忽略的管理平面协议,同样需要 PQ 化
draft-cisco-skip-02 Cisco Secure Key Integration Protocol(SKIP)——已提交 IETF,第五章详述

历史坐标:CNSA 1.0 时期的 RFC 已经成熟,可作为迁移参照。 NSA 在 CNSA 2.0 文件中列出了六份用于实现 CNSA 1.0 的 IETF RFC, 涵盖证书与 CRL 配置(RFC 8603)、S/MIME(RFC 8755)、CMS 证书管理(RFC 8756)、 TLS/DTLS 1.2 与 1.3(RFC 9151)、IPsec(RFC 9206)、SSH(RFC 9212)

NSA 明确说明:这些文件当前适用于 CNSA 1.0,将随标准化进程推进发布更新指引。 换言之——你现在的 CNSA 1.0 配置基线,就是未来 CNSA 2.0 配置的骨架。

4.8 第六问:这只是美国的事吗?——全球十国/地区强制时间线

如果我的业务不在美国、也不服务美国政府,我可以忽略 CNSA 2.0 吗?

技术上可以,商业上不能。

原因有三:
你所在的国家很可能已经发布了自己的强制时间表(下面列出十个);
你的供应链上游会先合规——当他们只接受 PQC 连接时,你就必须跟上;
③ 严格说,NIST 与 NSA 标准仅适用于需要 FIPS 合规或涉及 NSS 的实体; 但出于实际原因,公私部门的许多组织都在主动追求这些标准,即使并未被强制。 例如金融机构就有紧迫的量子安全需求,尽管政府尚未对其提出要求。

截至 2026 年 7 月,全球后量子转型已从理论规划进入积极执行阶段。 以下是十个走在最前面的国家与地区:

US美国
  • 2027新国家安全系统(NSS)采购须具量子抗性
  • 2030NSS 设备转型须于 12 月 31 日前完成
  • 2035强制使用 NIST 批准算法
EU欧盟
  • 2026年底前所有成员国应已启动转型规划
  • 2030年底前完成高风险用例的 PQC 转型
  • 2035年底前完成中风险用例的 PQC 转型
UK英国
  • 2027年底前识别需升级的密码服务并制定迁移计划
  • 2031年底前执行高优先级升级,并随 PQC 演进优化计划
  • 2035年底前完成所有系统、服务与产品的 PQC 迁移
AU澳大利亚
  • 2026年底前组织须制定细化的 PQC 转型计划
  • 2028预期开始关键系统迁移
  • 2030年底前停止使用量子脆弱的非对称算法
JP日本
  • 2027密码资产盘点、试点与混合部署、标准细化(CRYPTREC 更新)
  • 2030关键系统迁移,政府强制力加强
  • 2035完成 PQC 全面转型(政府 + 关键行业)
HK香港
  • 2027意识与指引阶段;HKMA 向银行发出建议,OGCIO 监测与技术更新
  • 2032PQC 迁移指引、行业专项预期
  • 2035(预计)银行与政府系统强制采用 PQC
IN印度
  • 2027关键信息基础设施(CII)应用启动 PQC 迁移;国防、电力、电信等 CII 行业完成基础建设
  • 2028常规企业完成基础建设;CII 行业进行高优先级迁移
  • 2029CII 行业全面采用 PQC
SG新加坡
  • 2027风险评估与资产盘点、PQC 试点与混合部署、内部治理框架
  • 2030标准与行业指引正式化,监管审查力度上升
  • 2030+关键行业可能进入强制 PQC 迁移
KR韩国
  • 2023政府已宣布分行业推进战略
  • 2025-2028在公共行政、能源、医疗行业开展试点部署
  • 2035全国范围转型目标年
TW台湾
  • 2027五年 PQC 计划、产业采用、金融业指引发布
  • 2032PQC 技术标准正式化、行业专项合规要求
  • 2035政府系统、关键基础设施、金融机构强制采用 PQC
+其他官方指引
  • CA加拿大 CCCS:ITSM.40.00 PQC 迁移路线图
  • IN印度 TEC:TEC 910018:2025 迁移至 PQC
  • DE德国 BSI:不推荐 QKD 方案(与 NSA 立场一致)

图 4-5 全球十余国/地区 PQC 强制时间线。注意收敛性:几乎所有终点都落在 2030–2035 之间,与 CRQC 出现窗口高度吻合——这不是巧合。

合规视角下的一个战略提示: Cisco IQ 具备持续追踪组织对全球强制标准合规进度的能力, 覆盖 CNSA 2.0 及欧盟、英国、加拿大、澳大利亚、日本的等效标准。

对跨国企业而言,这解决了一个真实痛点:你不是要满足一套标准,而是要同时满足五到十套 时间表各不相同的标准——而手工追踪这件事在规模化后几乎不可行。

4.9 本章收束

#推导步骤可直接执行的动作
SIKE 在标准发布前一个月被单核笔记本攻破 不押注单一算法——所有新部署默认启用 PQ/T 混合模式
三攻击面需要三类算法:ML-KEM / ML-DSA / LMS-XMSS 迁移清单必须三条线并行,不能只做密钥交换
AES-256 与 SHA-384/512 算法不变,只需保证长度 审计现网是否仍有 AES-128 / SHA-256,这是最低成本的收益
格密码依赖高维几何而非数论周期,故抗 Shor 理解 ML-KEM 大公钥的必然性 → 提前规划分片与 MSS 钳制
CNSA 2.0:网络设备 2026 支持 / 2030 独占 / 2027 新采购红线 今年的路由器选型必须内建 PQC,否则 2027 无法交付
固件签名是最早的 deadline(2025 / 2030) PQ Secure Boot 能力写入硬件采购必选项
FIPS 140-3 认证需 2 年,而混合模式可消除这个等待 用"FIPS 认证的传统算法 + PQ 算法"组合立即满足合规
IKEv2 仅支持混合;TLS/SSH 支持混合与纯 PQC 协议侧规划需区分对待,不可一刀切
全球十余国终点收敛于 2030–2035 跨国企业需合并多套时间表取最严值作为内部基线

表 4-5 第四章推导链。第 ⑤⑥⑦ 三条构成了本年度采购与立项的直接依据。

至此,"为什么换、有多急、换成什么"三个问题全部闭合。 但还有一个横跨全章的隐性主题没有被正面命名。

我们说了混合模式、说了 pqc optional、说了"FIPS 认证的传统算法作为回退"、 说了"PQ 部分在认证完成后自然升级"——这些全都指向同一个能力。 它不是一个算法,也不是一个协议,而是一种架构属性

加密敏捷性(Crypto Agility):在保持安全性与业务连续运行的前提下, 替换并适配协议、应用、软件、硬件、固件与基础设施中密码算法的能力。

它是量子安全三大支柱中的第三根——也是唯一一根无法靠"买某个产品"获得、 必须靠架构设计与运营流程共同支撑的支柱。

下一章,我们进入 Cisco 的答案:一家公司如何同时在"建设量子网络"与"防御量子攻击"两条战线上作战? 它的战略布局是什么?"全栈量子就绪(Full-Stack Quantum Ready)"到底包含哪些层次? 以及 —— 那些今天就能配置、今天就能生效的 PPK 与 SKIP 方案,究竟如何在 FIPS 认证完成之前, 先把你的 WAN 保护起来?

第四章 · 记忆锚点

SIKE 在标准发布前一个月被一台单核笔记本攻破——从那一刻起,"只挂一根绳"就不再是勇敢,而是疏忽。

第五章 · Cisco Quantum Strategy

Cisco 的答案:一家同时在建设量子网络与防御量子攻击的公司

前四章我们完成了完整的推导:锁的原理 → 钥匙如何失效 → 有多急 → 换成什么。 现在进入落地环节。
而 Cisco 在这件事上有一个非常特殊的位置:它既是量子网络的建设者,也是量子防线的构筑者。 这不是营销话术——理解这个双重身份,恰好是理解它技术选择的钥匙。

5.1 第一问:为什么"网络厂商"会成为量子安全的关键角色?

量子密码学看起来是数学家和芯片厂的事。为什么一家做路由器和交换机的公司会站在中心位置?

回到第一章图 1-2 的那个结论:量子威胁 100% 集中在"阶段一:密钥交换与身份认证"。
而阶段一发生在哪里?它发生在网络设备之间——IKEv2 握手、TLS 握手、MACsec 密钥协商、SSH 会话建立。

换句话说:量子威胁的全部攻击面,物理上就位于网络基础设施内部。 数据中心里的应用可以晚一点改,但如果承载它们的隧道是量子脆弱的,改了也没用。

这就是"WAN-first(从 WAN 开始)"这个策略的第一性依据。

两个相互印证的数据点,共同确立了"网络优先"的合理性:

① 根据《2025 Cisco 网络安全就绪指数》,31% 的受访者将"网络"列为最难防御网络攻击的领域——高于任何其他领域。
② 而 WAN 恰恰是业务数据在传输中暴露程度最高的地方,也是 HNDL 攻击者跨全球链路收割 PB 级流量的主猎场。

最难防守的地方 + 攻击者最集中的地方 = 必须最先加固的地方。 Cisco 的原话是:"WAN 仍然是传输中业务数据最关键的一点, 使其成为防御 HNDL 攻击的决定性战场(decisive battleground)。"

5.2 Cisco 的双引擎:研究与孵化

构建量子安全网络需要两个高度专业化的组织协同—— 一个负责"探索什么是可能的",一个负责"把可能变成可部署的"。

Engine 1 · Fundamental Research Cisco Research 基础研究:探索新密码技术的理论与实践应用

研究方向:复杂数学问题构造,包括:

  • 格密码(Lattice-based)——ML-KEM / ML-DSA 的基础
  • 编码密码(Code-based)——如 Classic McEliece 一类
  • 哈希密码(Hash-based)——LMS / XMSS 的基础

这些方向的共同特征是:目前被认为对量子计算机而言是难解的(intractable)

使命:通过识别并验证下一代算法,为"能抵御量子攻击的安全网络"打下地基。 该研究部门与全球学术机构合作,推进这一关键领域的最前沿能力。

产出量化:Cisco Research 已在全球产业界与高校间开展协作, 产出 30 余篇量子技术论文

Engine 2 · Incubation Cisco Quantum Labs 孵化引擎:把研究转化为可预判客户需求的基础技术

角色:将研究成果转化为能够预见并满足客户需求的基础技术

投入方向:量子相关技术开发,包括:

  • 量子安全密码算法与协议
  • 量子安全网络(Quantum-secure networking)
  • 面向未来的通信模型

作为孵化器,Cisco Quantum Labs 主动探索并将标准落地运营化 (例如 NIST 设定的 PQC 标准),确保 Cisco 提供的方案 不只是理论上稳健,而是在真实部署中实用且可扩展

已交付的关键成果:
量子纠缠芯片(Quantum Entanglement Chip)
网络感知量子编译器(Network-aware Quantum Compiler)
这两项都属于第二章图 2-5 中的"水平扩展(DQC)"加速因子。

类比

Cisco Research 像是新药研发实验室,Cisco Quantum Labs 像是制药厂与临床中心。
前者回答"这个分子在理论上有效吗";后者回答"怎么把它做成能量产、能储运、 能在真实医院里给真实病人使用的药片"。

两者缺一不可。只有实验室,成果永远停在论文里; 只有工厂,你不知道下一代该做什么药。

一个值得单独指出的独特之处:Cisco 同时在建设量子网络与防御量子攻击。

它一手推进量子纠缠芯片与量子网络(这会加速 Q-Day 到来), 一手为客户构筑后量子防线(这会抵御 Q-Day 的冲击)。

这不是矛盾,而是最深的护城河:没有人比正在建造那把钥匙的人,更清楚这把钥匙能打开什么锁。

5.3 三大支柱:什么才算真正的"量子安全"?

如果我在 IKEv2 上启用了 ML-KEM,我的路由器就"量子安全"了吗?

不一定。这里有三个不同层级的说法,混用会导致严重误判。

说法成立条件示例陈述
量子安全的"实现"
Implementation
在某个具体协议实现中应用了量子抗性密钥交换 "我的 IKEv2 实现是量子安全的,因为我已启用了量子抗性密钥交换方法。"
量子安全的"设备"
Device
硬件、软件与配置三个层面都应用了量子抗性,并具备加密敏捷性 "我的路由器是量子安全的,因为我已在硬件、软件与配置中应用了量子抗性,并具备加密敏捷性。"
量子安全的"架构"
Architecture
所有密码实现与所有设备均已应用量子抗性 "我的架构是量子安全的,因为我已在所有密码实现和设备中应用了量子抗性。"

表 5-1 "量子安全"的三个层级。大多数厂商宣传的是第一层,而企业真正需要的是第三层。

而无论哪一层,最终都建立在三根支柱之上:

支柱一 · 量子安全通信
Quantum-Safe Communications

  • 管理平面(Management Plane)
    SSH、HTTPS/API、SNMP
  • 控制平面(Control Plane)
    IKEv2、路由协议认证、SD-WAN 控制通道
  • 数据平面(Data Plane)
    IPsec、MACsec、TLS

支柱二 · 量子安全产品
Quantum-Safe Products

  • 信任锚(Trust Anchor)
  • 安全固件(Secure Firmware)
  • 安全存储(Secure Storage)
  • 安全运行时(Secure Runtime)
  • 安全身份(Secure Identity)

支柱三 · 加密敏捷性
Crypto Agility

  • 动态密钥支持(Dynamic Key Support)
  • 高效的加密方法切换
    Efficient Encryption Method Swapping

这一根无法靠采购获得,必须靠架构设计与运营流程支撑。

图 5-1 量子安全三大支柱。公式:量子安全 = 量子抗性 × 加密敏捷性。缺任一项,都只是局部安全。

精准定义

加密敏捷性(Crypto Agility):一个密码系统能够便捷地在不同加密算法或密钥长度之间切换的能力, 从而支持向新安全标准的分阶段采纳(phased adoption), 同时保持安全性与业务持续运行

其关键构成要素包括:

  • 最小中断快速适配新密码标准
  • 支持混合方案(当前算法 + PQC 算法并存)
  • 促成向量子安全密码的分阶段迁移
  • 确保与监管指引和标准演进的兼容性
  • 支持动态密钥管理与后量子预共享密钥的安全密钥集成协议
类比

加密敏捷性像是汽车的"燃料兼容性"。
一辆只能加 92 号汽油的车,在 92 号停产那天就是废铁。 而一辆能同时兼容汽油、乙醇混合燃料、并预留了电动改装接口的车, 可以随燃料标准演进而平滑过渡。

更重要的是:你不需要在"哪种燃料最终会胜出"这个问题上赌对。 这正是 SIKE 事件教给我们的那一课,在架构层面的体现。

5.4 第二问:FIPS 认证要两年,我这两年怎么办?

如果原生 PQC 要等 FIPS 认证、等厂商实现、等互操作验证——那 HNDL 攻击者在这期间收割的数据怎么办?

这是本章最有实操价值的问题,而 Cisco 的答案是:不必等。

存在一类方案,今天就能在现网部署,立即产生量子抗性,且不依赖任何 PQC 算法的 FIPS 认证

它的思路极其巧妙:既然问题出在"用非对称密码协商出的会话密钥可被 Shor 反推", 那我们就再往会话密钥里"混入"一份从未经过链路的秘密。

这就是 PPK(Post-Quantum Pre-Shared Key,后量子预共享密钥) 方案。 Cisco 提供三条并行路径,构成一个完整的迁移谱系:

01 Manual PPK
手工预共享密钥
IOS XE 17.11.1a 起
可用于任何 IKEv2 IPsec 场景

管理员在两端 IPsec 对等体上手工配置同一个 PPK, 设备将其混入 IKEv2 密钥派生流程(依 RFC 8784)。

优势:简单、部署快、无需额外基础设施。
局限:大规模网络中密钥管理负担极重;存在"密钥熵不足"与密钥暴露风险。

适用:小规模部署、快速验证、高价值点对点链路。

02 SKIP + 外部密钥源
动态 PPK
IOS XE 17.11.1a 起
支持 QKD / KMS / BYOK

通过 Cisco SKIP(Secure Key Integration Protocol) 从外部密钥源(QKD 设备、密钥管理系统)动态获取每次 IKEv2 执行的全新 PPK

优势:每次协商都是新鲜高熵密钥;自动化密钥管理与轮换;可规模化。
局限:需引入外部密钥基础设施;QKD 需专用光纤且成本较高。

适用:数据中心互联(DCI)、少量高价值站点、政府与国防场景。

03 原生 PQC
ML-KEM 混合密钥交换
IOS XE 26.1.1 起
NIST FIPS 203 标准算法

设备内置 NIST 批准的 PQC 库,在 IKEv2 中执行 传统 DH/ECDH + ML-KEM 混合密钥交换 (依 RFC 9370 与相关 IETF draft)。

优势:标准化、无外部依赖、可规模化到数千站点、具备完整加密敏捷性。
局限:需 PQC 就绪硬件;FIPS 认证仍在推进中(故采用混合模式)。

适用所有场景的最终目标态——分支、区域枢纽、数据中心。

图 5-2 Cisco 量子安全 WAN 的三条路径。三者并非互斥——PPK 与原生 PQC 可在同一网络中共存,服务于不同优先级的站点。

5.5 深入 Manual PPK:RFC 8784 的数学与工程

要理解 PPK 为什么有效,必须看清它究竟被混进了密钥派生的哪一步。 这是 Cisco 首倡的 RFC 8784 的核心。

机制原理:混入一个"从不上链路"的秘密
RFC 8784 PPK 混入密钥派生流程 传统IKEv2仅用DH共享秘密派生会话密钥;RFC 8784将从不经过链路的PPK混入密钥派生,使攻击者即使用量子计算机推出DH私钥也无法重建会话密钥。 RFC 7296 · 传统 IKEv2 密钥派生(量子脆弱) DH 共享秘密 g^ir KDF 密钥派生函数 Session Key ✗ 不是量子安全的 公钥在链路上明文可见 Shor 算法 → 反推私钥 → 重建 g^ir RFC 8784 · 混入 PPK 后的密钥派生(量子抗性)· 由 Cisco 首倡 DH 共享秘密 g^ir(仍量子脆弱) PPK ≥256 bit 熵 · 从不上链路 KDF 两个输入混合 Session Key ✓ 量子抗性 攻击者即使用量子计算机算出 g^ir 仍因缺少 PPK 而无法重建 Session Key PPK 既不在密钥交换中传输,也不在 VPN 建立后传输

图 5-3 RFC 8784 的核心机制。混合后的结果密钥不再仅基于"可被 CRQC 分解的质数",因此无法通过窃听通信通道窃取。

密钥派生数学:逐行拆解

下面是 RFC 8784 的实际密钥派生变化。请重点看被标黄的行——那就是 PPK 混入的确切位置。

阶段 RFC 7296(传统) RFC 8784(混入 PPK)
① 父 IKE SA SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'} = prf+(SKEYSEED, ...)
SK_d = prf+(PPK, SK_d')
SK_pi = prf+(PPK, SK_pi')
SK_pr = prf+(PPK, SK_pr')
② 子 SA(IPsec SA)重协商 KEYMAT = prf+(SK_d, [g^ir(new)] | Ni | Nr) KEYMAT = prf+(SK_d, [g^ir(new)] | Ni | Nr | PPK)
③ 子 SA(IKE SA)重协商 SKEYSEED = prf(SK_d(old), g^ir(new) | Ni | Nr) SKEYSEED = prf(SK_d(old), g^ir(new) | Ni | Nr | PPK)

表 5-2 RFC 8784 密钥派生对照。注意两个细节:① PPK 不混入父 IKE SA 的加密/完整性密钥(SK_ei/SK_ai);② 阶段 ③ 的 PPK 混入是 Cisco 扩展,仅适用于动态 PPK。

解读这张表的三个关键点:

① 混入位置精准:PPK 只混入 SK_d(派生密钥)与 SK_pi/SK_pr(认证密钥), 不混入父 IKE SA 的加密与完整性密钥。这是标准的刻意设计,兼顾安全与兼容。

② 认证也被保护:SK_pi/SK_pr 用于 AUTH 载荷计算, 因此 PPK 同样被混入认证步骤——实现量子抗性的对等体认证。 这正是 show 输出中 Auth verify: PSK, QR 里那个 QR 的由来。

③ 每次重协商都受保护:阶段 ② 与 ③ 的 KEYMAT / SKEYSEED 中都追加了 PPK, 意味着密钥轮换后依然维持量子抗性,不会出现"首次协商安全、后续重协商降级"的空窗。

配置落地:发起方与响应方

下面是完整可用的 Manual PPK 配置。标黄行是与普通 IKEv2 IPsec 配置唯一的差异—— 只有一行。这是"低门槛快速起步"的核心价值。

发起方 · Router1(Initiator) IOS XE 17.11.1a+
hostname Router1
!
crypto ikev2 keyring ppk-keyring
 peer 1
  address 10.10.0.1 255.255.255.0
  ppk manual id ppk_id key cisco          ! ← 唯一新增行:本地手工 PPK
!
crypto ikev2 profile prof
 match identity remote address 10.10.0.1
 authentication local  pre-share key cisco
 authentication remote pre-share key cisco
 keyring ppk ppk-keyring                  ! ← 引用 PPK keyring
!
crypto ipsec profile prof
 set ikev2-profile prof
!
interface Tunnel0
 ip address 10.10.0.1 255.255.255.0
 tunnel source GigabitEthernet1
 tunnel destination 10.10.10.1
 tunnel protection ipsec profile prof
!
interface GigabitEthernet1
 ip address 10.10.10.2 255.255.255.0
 no shut
响应方 · Router2(Responder) 两端 ppk_id 与 key 必须完全一致
hostname Router2
!
crypto ikev2 keyring ppk-keyring
 peer 1
  address 10.10.0.1 255.255.255.0
  ppk manual id ppk_id key cisco          ! ← 与对端完全相同的 id 与 key
!
crypto ikev2 profile prof
 match identity remote address 10.10.0.1
 authentication local  pre-share key cisco
 authentication remote pre-share key cisco
 keyring ppk ppk-keyring
!
crypto ipsec profile prof
 set ikev2-profile prof
!
interface Tunnel0
 ip address 10.10.0.2 255.255.255.0
 tunnel source GigabitEthernet1
 tunnel destination 10.10.10.2
 tunnel protection ipsec profile prof
验证:如何确认隧道真的量子安全了?
验证命令输出(节选关键行) show crypto ikev2 sa detailed
R1# show crypto ikev2 sa detailed

IPv4 Crypto IKEv2 SA
Tunnel-id  Local              Remote             fvrf/ivrf   Status
2          <SrcIP>/500        <DstIP>/500        none/none   READY
   Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:19,
   Auth sign: PSK, Auth verify: PSK, QR          ! ← QR = PPK 已混入认证步骤
   Quantum Resistant                             ! ← 会话已具备量子抗性
   Life/Active Time: 86400/67640 sec
   Local spi: 56F2233195202731  Remote spi: 47670EC039B7BF5C
   Status Description: Negotiation done
   ...
   Quantum-safe Encryption using Manual PPK     ! ← 明确指出使用的是手工 PPK
   PEER TYPE: Other

三行输出,三层含义:

  • Auth verify: PSK, QR —— PPK 已被混入认证步骤,实现量子抗性对等体认证
  • Quantum Resistant —— 该 IKEv2 SA 整体已具备量子抗性
  • Quantum-safe Encryption using Manual PPK —— 采用的是手工 PPK(对照:动态 PPK 会显示 Dynamic PPK,原生 PQC 会显示 PQC: ML-KEM-1024
Manual PPK 的真实局限——为什么它只能是起点

Cisco 文档对手工 PPK 的局限描述得非常坦诚,这些局限决定了它的适用边界:

  • 规模化困难:管理员需在数十到数百个 IPsec 对等体上逐一安装密钥;不可能亲临数千个站点手工配置
  • 密钥熵风险:由人类管理员直接参与,增加了选到低熵 PPK(例如一个口令)的概率。这种错误配置会抵消混入 PPK 本应带来的全部后量子安全收益——而 show 输出仍会显示 "Quantum Resistant"
  • 缺少轮换:每次对现有 IKE SA 重新认证时,会继续使用同一个 key 与 key-id。良好的安全实践要求周期性轮换密钥,这意味着额外的手工或自动化工作
  • 分发通道悖论:如果管理员使用非量子安全的协议(如传统 SSH)分发 PPK,恶意行为者可捕获该流量,未来用量子计算机解开整个体系的安全性

最后一条尤其值得警惕:它意味着"用旧 SSH 配 PPK"这个动作本身,就在制造一个新的 HNDL 目标。 这也解释了为什么 SSH 的 PQ 化(ip ssh server algorithm kex mlkem...)与 PPK 部署必须同步进行。

5.6 第三问:如何让 PPK 既高熵又自动轮换?——SKIP 与外部密钥源

如果手工 PPK 的所有问题都源自"人在中间",那能不能让机器每次自动取一把全新的高熵密钥?

能。这正是 Cisco 开发 SKIP 的动机。

SKIP 消除了手工配置 PPK 的局限,实现每次 IKEv2 执行都使用一把全新的 PPK。 使用该 profile 时,每次重新认证都会使用不同的 key 与 key-id,让加密更加安全。

精准定义

SKIP(Secure Key Integration Protocol,安全密钥集成协议): 由 Cisco 开发的量子抗性客户端/服务器框架,作为关键的桥梁协议, 连接"PPK 增强的 IKEv2 对等体"与"任意的带外 PPK 同步机制"(例如 QKD 密钥源)。

传输层:运行于 HTTPS / TLS 之上(依 RFC 9110,TLS 1.2 或 1.3), 允许路由器(加密器)从可信密钥提供方安全获取动态 PPK。 已提交 IETF:draft-cisco-skip-02

类比

SKIP 像酒店的电子门卡系统,而 Manual PPK 像一把配了两把的铜钥匙。
铜钥匙需要人工去配、去送、去回收;而电子门卡系统在你每次入住时自动生成一张全新卡片, 退房即失效——而卡片上的密钥本身,从来没有在大厅里被公开念出来过。

SKIP 更妙的一点是:它是一个通用的适配层。 后面接 QKD 设备、接密钥管理系统、还是接第三方 PQC 密钥服务器, 对路由器来说接口完全一致——这就是加密敏捷性在密钥源层面的体现。

SKIP 五步协议流程
SKIP 协议五步流程 发起方向本地密钥源请求PPK获得PPK与PPK-ID,密钥源带外同步PPK至对端密钥源,发起方仅通过IKEv2传递PPK-ID,响应方凭ID向本地密钥源取回PPK,双方混入密钥派生。 SKIP:PPK 本身从不上链路,链路上只走 PPK-ID 站点 1 站点 2 Key Provider 1 QKD / KMS / PQC 密钥源 Local-ID = KS1 Key Provider 2 QKD / KMS / PQC 密钥源 Local-ID = KS2 2 带外同步 PPK + PPK-ID Out-of-Band Sync(机制由密钥源类型决定) Encryptor 1 IKEv2 Initiator Encryptor 2 IKEv2 Responder 1 SKIP: Get-Key ← 返回 PPK + PPK-ID HTTPS / TLS 4 SKIP: Get-Key(PPK-ID) ← 返回对应 PPK HTTPS / TLS 3 IKEv2(RFC 8784 扩展) 仅传输 PPK-ID PPK 本体从不出现在链路上 5 双方按 RFC 8784 将同一 PPK 混入密钥派生 → 量子安全的 IKEv2 / IPsec 会话密钥 被捕获的流量对 HNDL 攻击者毫无用处 —— 即使他拥有量子计算机

图 5-4 SKIP 五步流程。核心设计:实际预共享密钥从不穿越链路,链路上只有元数据 PPK-ID。量子计算机无法用一个 ID 推导出密钥本体。

密钥源必须满足的两条 SKIP 合规要求:

  • 必须实现 SKIP 协议或 API(依 Cisco SKIP 规范)
  • 必须使用带外同步机制,向加密器对(发起方与响应方)提供同一个 PPK
配置落地:动态 PPK
发起方 · SKIP 动态 PPK IOS XE 17.11.1a+
hostname Router1
!
crypto skip-client skip-client-cfg              ! ← 定义 SKIP 客户端
 server ipv4 20.20.0.4 port 9991              ! ← 本地密钥源地址与端口
 psk id skipkey key 0 cisco123                ! ← 与密钥源之间的 TLS-PSK 凭据
!
crypto ikev2 keyring ppk-keyring
 peer 1
  address 11.11.11.1 255.255.255.0
  ppk dynamic skip-client-cfg                 ! ← 动态 PPK,每次协商取新密钥
!
crypto ikev2 profile prof
 match identity remote address 11.11.11.1
 authentication local  pre-share key cisco
 authentication remote pre-share key cisco
 keyring ppk ppk-keyring
!
crypto ipsec profile prof
 set ikev2-profile prof
验证输出(动态 PPK) 注意最后两行与 Manual PPK 的差异
Cat8Kv_CPN1# show crypto ikev2 sa detailed

Tunnel-id  Local          Remote         fvrf/ivrf   Status
1          10.0.0.2/500   10.0.0.1/500   none/none   READY
   Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:20,
   Auth sign: PSK, Auth verify: PSK, QR
   Quantum Resistant
   ...
   Quantum-safe Encryption using Dynamic PPK    ! ← 动态 PPK(对比 Manual PPK)
   Local Sys Id: Cat8Kv_CPN1   Remote Sys Id: Cat8Kv_CPN2
   PEER TYPE: Other
第四问:QKD 到底该不该用?——一个必须诚实回答的问题

QKD 听起来像终极方案——用量子物理保护密钥,窃听会被立即发现。为什么 Cisco 反而把它列为"需谨慎评估"?

因为 QKD 有三个绕不开的工程现实,以及两个来自最权威监管机构的明确否定

QKD 的真实优势

窃听者无法读取编码在量子态中的信息,且任何窃听尝试都会被发送方与接收方立即察觉。 已在 1000 公里距离上实现。安全性建立在物理定律而非计算假设之上。

!

QKD 的硬约束

需要直连(direct connection)——因为当前的光交换机会破坏量子效应。 这意味着必须专用光纤,无法穿越常规运营商网络。

Cisco 明确列出的六项部署前评估维度:

  1. 厂商协作:选择有能力与 Cisco 网络基础设施完成集成、测试与鉴定的 QKD 厂商
  2. 可扩展性评估:评估厂商的密钥同步技术在大规模企业部署下的表现
  3. 成本收益分析:评估总体拥有成本,含初始硬件投入与长期管理开销
  4. 安全责任划分:在这种"双盒方案(two-box solution)"架构中,清晰界定 QKD 厂商组件与 Cisco 设备之间的安全边界
  5. 标准演进:确定该方案如何适配原生 PQC 标准并维持加密敏捷性
  6. 法规合规NSA 禁止 QKD 方案;德国联邦信息安全办公室(BSI)不推荐 QKD
类比

QKD 像是在两栋大楼之间架一条专用气动管道传递纸条。 物理上极其安全——任何人打开管道都会被立刻发现。 但你没法给全球 3000 个分支机构都铺这样一条管道。

而原生 PQC 像是把纸条上的文字换成一种"就算被读到也解不开"的密码—— 它可以走任何现有邮路。这就是为什么 QKD 适合数据中心互联(少量高价值链路), 而 PQC 适合全网规模化。

BYOK:把密钥源的选择权交给客户。

Cisco 采取的策略是"Bring Your Own Key"—— 密钥源选项对客户完全开放,可依据自身环境、用例、成本约束、所需安全等级自行选择。 Cisco 设备支持 SKIP 接口,从任意合规密钥源获取密钥。

三类可选密钥源:

① 手工预置密钥(Manual PPK) ② QKD 系统(经 SKIP API) ③ 集成密钥管理服务(KMS / Cisco SKS)

补充说明:Cisco 的集成密钥管理服务在 IOS XR 上称为 SKS(Session Key Service),是设备自身集成的按需量子安全密钥服务, 无需额外基础设施,但 KMS 使能产品数量有限。 另有第三方方案(如 Quantum Xchange Phio TX)可作为容器化应用直接托管在 Catalyst 8000 路由器上, 提供 FIPS 203 ML-KEM-1024 验证的本地 PPK, 适用于与外部密钥服务器连接困难的场景(战术、移动、非地面网络)。

适用范围与平台支持
维度说明
支持的部署形态 仅与 IKEv2 based IPsec 集成:FlexVPN(SVTI / DVTI)、DMVPNGETVPN 除外
IOS XE 17.11.1a 起 Catalyst 8000V Edge Software、Catalyst 8300 / 8500 Edge Platforms、ASR 1000 Aggregation Services Routers
IOS XE 17.12.1a 起 ISR 1000 Series Integrated Services Routers
IOS XE 17.15.3 / 17.18.1 起 Cisco 8000 Series Secure Routers
SD-WAN 控制面与数据面 DTLS/TLS 控制面与 IKEv2/IPsec 数据面的 PPK 支持在路线图上,计划于后续版本发布
密钥格式要求 使用 SKIP 配置 PPK 时,密钥源须以十六进制格式(hex)发送密钥
MACsec(IOS XR) IOS XR 7.9.1 / 7.10.1 起支持基于 PPK 的 MACsec,通过 MKA 扩展携带 PPK_ID 作为 SAK 标识符

表 5-3 PPK 方案的适用范围与平台矩阵。关键限制:仅 IKEv2 IPsec,GETVPN 不支持。

5.7 第五问:如何做到"部分升级、全网可用"?——加密敏捷性的工程实现

如果我先升级了 Hub,但 3000 个 Spoke 还没升级——隧道会不会全部断掉?

不会,前提是你正确使用了那个"可选标志"。

RFC 8784 的实现提供了一个可配置的强制标志(required flag), 决定 PPK 是否为必需。而 PQC 侧对应的是 optional 关键字。 这一个关键字,就是加密敏捷性在配置层面的落点。

强制标志:Manual PPK 与 Dynamic PPK required = 强制量子安全
R1(config-ikev2-keyring-peer)# ppk manual id 7 key cisco ?
  required    Use of PPK is mandatory        ! 强制:不支持则中止协商

R1(config-ikev2-keyring-peer)# ppk dynamic skip-client-cfg ?
  required    Use of PPK is mandatory

使用建议(Cisco 官方): 当你确定对端支持 RFC 8784 时使用 required, 以确保发起方与响应方在协商时总是建立量子抗性 VPN 而非传统 VPN

否则使用默认模式,让路由器在对端不支持 RFC 8784 时回退到传统 IKEv2 VPN—— 例如与你无法控制的企业外部设备对等时。

四种协商场景矩阵
1 发起方配置 PPK 且带 required,响应方未配置 PPK(可能不支持 RFC 8784) 发起方中止协商
2 发起方配置 PPK 不带 required,响应方未配置 PPK 回退为普通 IKEv2 / IPsec
3 发起方未配置 PPK(可能不支持),响应方配置 PPK 不带 required 回退为普通 IKEv2 / IPsec
4 双方均配置 PPK 且带 required 量子安全 IKE + IPsec SA

图 5-5 RFC 8784 四种协商场景。可选标志的设计目的:与不支持 RFC 8784 的 VPN 网关保持互操作,至少建立非量子安全的 SA,而不是完全断连。

补充规则:当双方都配置了 PPK profile(无论是否带 optional 标志) 且未遇到错误时,PPK 总会被使用

这就是"分阶段迁移"能够零业务中断的技术根据—— 同一台 Hub 可以同时服务已迁移的量子安全 Spoke 与尚未迁移的传统 Spoke

5.8 原生 PQC:从 PPK 走向标准化终态

PPK 是过渡桥梁;原生 PQC 才是终点。 自 IOS XE 26.1.1 起,Cisco 在设备内置 NIST 批准的 PQC 库, 在 IKEv2 策略内直接调用 ML-KEM 算法。

原生 PQC · IKEv2 IPsec(Cisco 关键网络首推配置) IOS XE 26.1.1+
crypto ikev2 proposal cni_ikev2_proposal
 pqc mlkem1024 optional          ! ← 非强制 PQC 协商,支持渐进迁移
 encryption aes-gcm-256           ! ← CNSA 2.0 要求 AES-256
 prf sha512                       ! ← CNSA 2.0 要求 SHA-384/512
 group 21                         ! ← 传统 ECDH 部分(混合模式的另一条腿)
!
crypto ikev2 policy cni_ikev2_policy
 proposal cni_ikev2_proposal
!
crypto ikev2 keyring ikev2keyring
 peer HUB-inet
  address 64.101.25.31
  pre-shared-key Cisco@123
 peer ANY_SPOKE
  address 0.0.0.0 0.0.0.0
  pre-shared-key Cisco@123
!
crypto ikev2 profile ikev2profile
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local  pre-share
 keyring local ikev2keyring
!
crypto ikev2 fragmentation mtu 1400  ! ← 必须!ML-KEM 大公钥需分片
验证输出(原生 PQC) show crypto ikev2 sa detailed
Router# show crypto ikev2 sa detailed

Tunnel-id  Local        Remote       fvrf/ivrf   Status
4          1.1.1.2/500  1.1.1.1/500  none/none   READY
   Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:21,
   Auth sign: PSK, Auth verify: PSK
   PQC Key Exchange: ML-KEM-1024              ! ← ML-KEM 已生效
   Life/Active Time: 86400/65905 sec
   ...
   Quantum-safe Encryption using PQC: ML-KEM-1024
   PEER TYPE: IOS-XE
同一套配置,覆盖 DMVPN 与 FlexVPN
D

DMVPN

DMVPN 通过组合 mGRE + IPsec/IKEv2 + NHRP 实现大规模 IPsec VPN 部署。 PQC 应用在 IKEv2 层,确保动态 NHRP 注册与后续的 Spoke-to-Spoke 隧道 都以量子安全的会话密钥初始化。配置与标准 IKEv2 IPsec 完全一致。

F

FlexVPN

FlexVPN 原生构建于 IKEv2 之上,是 PQC 的天然归属。 可用单一一致的 PQC 策略覆盖站点到站点、远程接入、Hub-and-Spoke 全部拓扑。 通过模块化"Smart Default"配置目录,可在整个 fabric 上快速切换到量子安全标准。

超越 IPsec:MACsec、SSH 与 SD-WAN
量子安全 LAN/WAN MACsec · 证书式 EAP-TLS(RFC 9190) IOS XE 26.1.1+
eap profile EAP-PROFILE
 method tls
 pki-trustpoint <name>
!
dot1x credentials DOT1X-CREDS
 username <username>
 pki-trustpoint <name>
!
access-session tls-version all
access-session pqc-type pqc            ! ← 为 EAP-TLS 启用 PQC ML-KEM
!
interface <interface-id>
 macsec
 authentication periodic
 authentication timer reauthenticate interval
 access-session host-mode multi-domain
 access-session closed
 access-session port-control auto
 dot1x pae both
 dot1x credentials profile DOT1X-CREDS
 dot1x authenticator eap profile EAP-PROFILE
 dot1x supplicant   eap profile EAP-PROFILE

MACsec 的量子安全链条(四步):

① 802.1X 端口认证 → ② EAP-TLS(TLS 1.3 + ML-KEM 密钥交换) → ③ 生成并共享主会话密钥(MSK) → ④ MKA 协议建立会话密钥,MACsec 会话受保护。

另一条路径(PSK 模式):使用 256 位预共享密钥, 通过量子安全 SSH 通道配置,用 AES-CMAC-256 为 MKA 派生会话密钥, 并采用 GCM-AES-256 加密套件——这条路径对无法部署证书体系的环境更实用。

量子安全 SSH(管理平面) 三个新 KEX 选项
ip ssh client algorithm kex mlkem1024nistp384-sha384
ip ssh server algorithm kex mlkem1024nistp384-sha384

! 全部可选 PQ/T 混合 KEX:
!   mlkem768nistp256-sha256
!   mlkem1024nistp384-sha384
!   mlkem768x25519-sha256

Router# show ip ssh
SSH Enabled - version 2.0
KEX Algorithms: mlkem1024nistp384-sha384,mlkem768nistp256-sha256,
                mlkem768x25519-sha256

平台限制警告:PQ/T 混合密钥交换算法仅在部分平台上受支持。 在不支持的平台上启用会产生如下日志并导致会话建立失败:

%SSH-3-KEX_PQC_NOT_SUPP: PQ/T hybrid key exchange algorithms
                          are not supported on this platform.

部署前务必核对平台支持矩阵。

SD-WAN 的量子安全化(三平面)
平面协议PQC 标准依据版本
管理平面 标准 TLS IETF Draft — Hybrid key exchange in TLS 1.3
TLS + DH/ECDH + PQC(ML-KEM)
26.2.1
控制平面 TLS / DTLS 同上(DTLS 的量子安全支持在路线图上) 26.2.1
数据平面 IKEv2 / IPsec RFC 9370 — Multiple Key Exchanges in IKEv2
IKEv2 + DH/ECDH + PQC(ML-KEM)
26.2.1
数据加密 AES-GCM-256 密码套件不变(对称加密天然抗量子)

表 5-4 SD-WAN 三平面 PQC 化路径。操作路径:Configuration Group → Add Fabric Security Feature → 选择 IKEv2 / PQC / ML-KEM 参数 → Deploy;控制面则在 Configuration → Control Components → Security → tls 中配置。

集中编排的三大价值(Catalyst SD-WAN Manager):

  • 配置目录集成:Cisco 提供预验证的配置目录,包含按 NIST 与 CNSA 2.0 标准预先工程化的 IPsec 与 MACsec PQC 模板,降低网络工程团队的研究负担
  • PQC 策略强制:可定义全局策略决定网络的"PQC 状态"——例如迁移期推送 pqc optional,遗留硬件退役后全局更新为 pqc required
  • 自动化 ML-KEM 部署:自动生成含 ML-KEM 的 IKEv2 提案,消除在大规模 DMVPN / FlexVPN 部署中手工输错复杂密码字符串的风险

加上可视化能力:Security Dashboard 提供高层视图, 显示哪些隧道当前运行于量子安全状态(ML-KEM),哪些仍依赖传统加密; Crypto Audit Logs 提供 IKEv2 协商的取证证据, 供工程师验证混合密钥交换在不同传输运营商上是否成功完成

5.9 Cisco 全栈量子就绪路线图

Cisco 计划在 2026 年底前,为其核心产品组合的大部分实现量子安全通信与量子安全产品能力提前于 CNSA 2.0 的 2027 年新采购红线。以下是两批交付清单。

第一批 · 2026 年 12 月前(Core)
企业路由Enterprise Routing · IOS-XE IKEv2 IPsec · DMVPN · FlexVPN · SD-WAN IPsec · MACsec · SSH · TLS
企业交换Enterprise Switching · IOS-XE IPsec · MACsec · SSH · TLS
TLS 1.3 更新覆盖:RadSec · TACACS · LDAP
无线Wireless · IOS-XE 空口(OTA)PQC 支持,引入安全配置文件 16 与 18
物联网IoT · IOS-XE IKEv2 IPsec · MACsec · SSH · TLS
数据中心网络Data Center · NX-OS SSH
服务提供商Service Provider · IOS-XR MACsec · SSH · TLS
Webex TLSMLS,覆盖 Webex App 与设备,支持端到端加密会议
Splunk 全部 DoD IL5 授权的 Splunk 云服务提供混合 PQC 能力
第二批 · 2027 年 6 月前
企业路由 TLS · DTLS · 认证能力(Authentication capabilities)
企业交换 扩展更多 TLS 用例
无线 dTLS 更新覆盖:RadSec · TACACS · LDAP · CAPWAP · VxLAN
数据中心 NX-OS SSH · TLS* | Nexus Dashboard:SSH · TLS (HTTPS/API)* | ACI:SSH(设备访问)* · TLS(内外部通信)*
防火墙Firewalls IPsec · SSH · TLS 解密(TLS Decryption)
Secure Client IPsec
Catalyst Center TLS · SSH · SFTP(混合模式)
Meraki Dashboard TLS 已在 Secure OS、NGINX、Envoy Gateway 中实现;安全管理通信采用混合配置
ThousandEyes Agent 通信与 API/应用访问的 TLS;全部 ThousandEyes Agent 启用 PQC 签名
Identity Services EngineISE RADIUS · EAP · TACACS · HTTPS(关键服务) · LDAPS · IPsec · SSH
Duo TLS,并提供回退选项以支持客户环境中尚未更新的系统

表 5-5 Cisco 量子安全通信路线图。* 标注项为 2027 年 7/8 月,取决于软件发布排期。路线图可能变更,最后更新:2026 年 8 月 11 日。

量子安全产品(硬件平台)
产品线计划产品 / 平台
企业路由(IOS-XE) 新品发布:Cisco Secure Router 8131H、8151H-C、8211、8221、8221L、8225、8650Cisco 8255 Secure Router Node(Unified Edge)
企业交换(IOS-XE) C9550 固定核心交换机、C9350 固定接入交换机
企业无线(IOS-XE) 后续发货批次:CW9800H1、CW9800H1-MCG、CW9800H2、CW9800M、CW9800L、CW9800L-MCG
数据中心(NX-OS) N9300 固定交换机(基于 P200)
服务提供商(IOS-XR)
仅软件版本
Cisco 8000、NCS5700(不含 NCS57C3)、NCS540 系列(不含 N540-ACC-SYS、N540X-ACC-SYS、N540-24Z8Q2C-SYS);所有支持 MACsec 的 IOS-XR 平台支持 EAP-TLS for MACsec
防火墙与 VPN 面向 1200、3100、4200、6100 的未来 PQC SKU

表 5-6 Cisco 量子安全产品路线图(Cisco Live US 2026 发布)。下一章将深入解剖其中的 8000 系列。

防火墙侧的具体节奏(值得单列,因为它涉及硬件更换):

  • 软件 PQ 特性:随 ASA 9.25 / FTD 10.5 交付(2026 年秋季)
  • PQ 签名镜像验证(ML-DSA-87):需 11.0 版本支持 TAM 升级 —— 涉及 CSF 250、260、1200、6100
  • 3100 与 4200 的新版本规划为全新产品引入(NPI),将在 FCS 时原生支持 PQ 签名镜像验证
  • 11.0 将同时是 ASA 与 FTD 镜像,交付时间为 2027 年

解读:这再次印证第三章的结论——信任根(Secure Boot)是唯一必须靠硬件刷新解决的攻击面。 软件特性可以升级,但 TAM 里的验证密钥不能。

5.10 本章收束

#推导步骤可直接执行的动作
量子攻击面物理上位于网络设备内部;WAN 是决定性战场 WAN-first:优先加固 WAN 汇聚点与 DCI 链路
量子安全 = 量子抗性 × 加密敏捷性(三大支柱) 评估厂商时三项都要问,不只问"是否支持 ML-KEM"
RFC 8784 把 PPK 混入 SK_d / SK_pi / SK_pr,且重协商亦受保护 不必等 FIPS 认证——今天即可在 17.11.1a+ 平台部署 PPK
Manual PPK 的四大局限:规模、熵、轮换、分发通道悖论 仅用于小规模与高价值点对点;并同步 PQ 化 SSH
SKIP 让 PPK 每次协商刷新,PPK 本体从不上链路 DCI / 高价值站点评估 SKIP + QKD 或 KMS;要求密钥源 hex 格式
QKD 需专用光纤,且 NSA 禁止、德国 BSI 不推荐 QKD 仅作局部方案;全网规模化依赖原生 PQC
optional / required 决定四种协商结果 迁移期统一用 optional;遗留设备退役后全局切 required
ML-KEM 大公钥必然导致分片 必配 crypto ikev2 fragmentation mtu 1400 + ip tcp adjust-mss 1360
PQC 覆盖面远超 IPsec:MACsec、SSH、SD-WAN 三平面 迁移清单必须横跨管理/控制/数据三平面
Cisco 2026 年底覆盖核心组合,早于 2027 采购红线 把路线图时间点写入采购合同的交付条款

表 5-7 第五章推导链。第 ③⑧ 两条是"今天就能做"的最短路径。

至此,量子安全通信这根支柱已经完整落地——从今天可用的 PPK,到标准化的原生 PQC, 从 IPsec 到 MACsec、SSH、SD-WAN 三平面。

但三大支柱中的第二根还没有触及:量子安全产品。 而这一根,恰恰是第三章里那个"补丁永远救不回来"的攻击面所在。

下一章我们下沉到硅片层:Cisco Trustworthy 技术究竟如何在硬件里建立一个"无法被远程篡改"的信任根? Trust Anchor module(TAm)是什么?Secure Boot 的六个阶段各自验证什么? 为什么 Cisco 早在 2013 年就开始部署量子安全签名——比 NIST 竞赛还早三年? 以及 —— SUDI 这个"刻在硅片里的身份证",为什么是零信任架构的物理基础?

第五章 · 记忆锚点

你不必等 FIPS 认证——PPK 让你今天就能把 WAN 保护起来;而 optional 这一个关键字,就是三千个站点零中断迁移的全部秘密。

第六章 · Cisco Trustworthy

刻在硅片里的信任根——为什么这是唯一补丁救不回来的东西

第五章我们把"量子安全通信"这根支柱完整落地了。 现在进入第二根:量子安全产品
这一章会比前面更"硬"——我们要一路下沉到硅片、到主板上那颗物理芯片、 甚至下沉到 CPU 与那颗芯片之间的那一根导线
因为第三章的结论仍然悬在那里:信任根一旦崩塌,任何软件补丁都无法移除后门。

6.1 第一问:信任必须从哪里开始?

操作系统由谁验证?Bootloader。Bootloader 由谁验证?BIOS。BIOS 由谁验证?……这个链条能不能一直往下问?

不能。而这个"不能",正是整个可信计算领域的第一性原理。

每一层软件都可以被上一层验证,但最底下那一层无法被任何软件验证—— 因为它就是"第一条被执行的指令"。如果它被篡改了,它自己会告诉你"一切正常"。

所以,递归必须在某处终止。而终止点不能是软件,只能是"物理上无法修改的东西"。

精准定义

硬件信任根(Hardware Root of Trust, RoT): 整条启动链中第一个、且不可被修改的验证环节。 它必须位于防篡改硬件(tamper-resistant hardware)之中, 使其无法被访问或更改

信任链(Chain of Trust):当系统中每一段代码在被允许运行之前, 其完整性都已被验证时,信任链即成立。链条起始于信任根元素, 由信任根验证链中的下一个元素(通常是固件),再依次向上传递。

类比

想象一份需要层层签字的批文。
主管签字前要看部门经理签了没,经理签字前要看总监签了没…… 但最上面那个人的签字,谁来验证?

答案是:用一枚刻在石头上、无法伪造、无法更换的公章。 它不需要被谁验证——它就是验证的起点。

而 Cisco 的做法更彻底:不仅公章是石头刻的,连"看公章的那只眼睛"也是石头刻的。 Cisco Secure Boot 把启动链中的初始元素移入了一个不可变的硬件锚点(immutable hardware anchor)—— 一小段被称为 Microloader 的启动代码,驻留在硬件器件之内,无法被访问或更改。

Cisco 对这个不可变性的强度描述,值得逐字读一遍:

"要做到(修改 Microloader)需要对该硬件器件进行逆向工程, 其复杂度之高,使其在实践上不可能实现(of significant complexity to be practically impossible)。"

并且,硬件本身还受到额外的逻辑保护——用于验证硬件镜像的完整性。

6.2 Trust Anchor module(TAm):主板上那颗防篡改芯片

精准定义

Trust Anchor module(TAm):Cisco 专有的防篡改芯片, 存在于众多 Cisco 产品之中。它提供非易失性安全存储、 安全唯一设备标识符(SUDI)、以及密码服务(随机数生成、密钥库、密码引擎)。

物理定位:它是主板上的一个物理元器件, 在制造阶段被安装进所有 Cisco 物理设备。 它将设备唯一身份与密码密钥存储在一个与主处理器和内存相隔离的、防篡改环境中。

所有 Cisco 物理设备在制造阶段即安装 TAm 芯片

TAm 提供两类价值:产品保障功能(Product Assurance)四项基础安全能力(Foundational Security Features)。 下面逐一解剖这四项能力。

ID 不可变身份Immutable Identity · SUDI

X.509v3 证书,保存产品标识符(PID)与序列号。 在制造阶段实施,并链接到一个可公开识别的根证书颁发机构

关键设计:SUDI 证书、其关联密钥对、以及整条证书链 全部存储于防篡改的 TAm 芯片内;密钥对与特定 TAm 芯片密码学绑定, 且私钥永不导出
这使克隆或伪造身份信息在实践上不可能。

ST 高安全存储Highly Secure Storage

密钥、口令、客户凭据以及设备的其他关键安全信息提供高安全存储。

其优势之一:能够存储私有加密密钥与口令, 获得更高等级的安全性。亦可在 TAm 之外分配安全存储。

RN 随机数生成与熵源RNG & Entropy Source

强随机数生成(RNG)是加密的核心;而弱 RNG 会摧毁整个加密体系。 RNG 在创建密钥、建立用户与网站间的高安全通信、以及重置邮箱口令中扮演关键角色。

没有可靠的随机性,攻击者就能预测系统将生成什么,从而破坏算法。
TAm 符合 NIST 规范,提供可通过 NIST SP 800-90A 与 800-90B 认证的 RNG从 TAm 内部的真随机源提取熵。

KM 密钥管理与密码服务Key Management & Crypto

向运行中的操作系统与应用提供密钥管理与密码服务

可生成客户自控证书的密钥对——即通常所说的 本地有效证书(LSC)本地设备身份(LDevID)证书

SUDI 可用于加密、解密、签名、验证等非对称密钥操作, 允许传入待操作数据——这使设备的远程认证成为可能。

图 6-1 Trust Anchor module 的四项基础安全能力。四者并非并列关系:SUDI 是身份,安全存储是容器,RNG 是燃料,密钥管理是引擎。

TAm 支持的客户身份功能(可直接落地的运维价值):

  • 检索 LDevID RSA 公钥
  • 在 LSC 注册之前,与证书颁发机构(CA)进行身份认证
  • 零接触部署(Zero-Touch Provisioning)认证
  • 安全启动态势评估(Secure Boot Posture Assessment)

SUDI 的业务价值:它使 Cisco 产品能够被准确、一致、电子化地识别, 用于资产管理、部署配置、版本可见性、服务权益、质量反馈与库存管理。

类比

SUDI 就是设备的"出生时植入的身份芯片"。
它不像序列号贴纸(可以撕掉重贴),也不像配置文件里的 hostname(可以随意改)。 它在工厂被烧进硅片,私钥永不出芯片,且与那一颗特定芯片绑定。

这就是零信任架构的物理基础:零信任要求"永不信任,始终验证"—— 但"验证什么"?如果被验证的身份本身可以伪造,那验证就是自欺欺人。 SUDI 提供的正是那个"无法伪造的被验证对象"。

6.3 Secure Boot:从四阶段到量子安全六阶段

设备上电那一刻,谁先说话?

在传统架构中,CPU 从 Bootloader 开始执行。而 Cisco Secure Boot 改变了这个顺序: CPU 从 Microloader 代码开始启动,而不是原始的 Bootloader 代码。

这一个顺序的调换,就把信任的起点从"可写的闪存"移到了"不可写的硅片"。

经典 Cisco Secure Boot 流程(四步核心 + 两步延伸)
Cisco 硬件锚定安全启动与信任链 上电后TAm验证微加载器并载入CPU,微加载器验证引导加载器,引导加载器验证操作系统,随后进行真实性与许可证检查,TAm持续提供关键密码服务。 信任链:每一级在运行前都已被上一级验证 Trust Anchor module(TAm)· 防篡改硬件 全程提供关键服务:SUDI 身份 · 安全存储 · 真随机数 · 密钥管理 · 密码引擎 1 硬件锚点 Hardware Anchor Microloader CPU 首条指令 存于防篡改硬件 2 CPU 执行 ML TAm 先验证 Microloader 完整性 再载入 CPU 内存 SUDI 硬件真实性校验 3 ML 验证 BL 通过 TAm API 确认 Bootloader 镜像合法 Bootloader / ROMMON 数字代码签名验证 4 BL 验证 OS 镜像签名机制校验 IOS XE 镜像 Operating System 验证通过才允许启动 5 6 OS 运行 + 校验 应用镜像验证 真实性与许可证检查 运行时防御生效 ASLR · BOSC · X-space 任一阶段校验失败 → 状态上报主机系统 → 保持复位 / 禁用功能,阻止被攻陷的系统投入运行

图 6-2 Cisco 硬件锚定 Secure Boot 与信任链。注意底部红条:失败不是"报警后继续",而是"直接不让它跑"。

失败处理机制的关键设计(这一点区别于"仅告警"的方案):

如果 Cisco Secure Boot 逻辑执行的完整性检查失败——无论是硬件验证还是 Bootloader 验证—— 该状态会被提供给主机系统,以便采取适当措施,确保被攻陷的系统不具备功能, 例如将系统保持在复位状态,或禁用部分功能以阻碍其运行。

在 Cisco 8000 系列上,这一机制由 SNP(安全网络处理器)执行: 若设备在启动时检测到硬件修改或签名不匹配,SNP 将中止初始化流程, 阻止一台已被攻陷的设备加入生产网络。

量子安全升级:把签名算法换成 LMS 与 ML-DSA-87

经典 Secure Boot 使用 RSA / ECDSA 做签名验证——而这正是第三章攻击面 ③ 的入口。 量子安全 Secure Boot 的改造,就是把每一级的签名算法替换为量子抗性算法:

1 系统上电,载入 Microloader(ML) Microloader 本身基于 LMS 签名,驻留在不可变硬件中。这是整条链的起点。 LMS · RFC 8554
2 ML 使用 LMS 验证 Bootloader(BL) Microloader 运行,以 LMS 哈希签名验证 Bootloader 的真实性与完整性。 LMS · SP 800-208
3 BL 使用 ML-DSA-87 验证 OS 镜像 Bootloader / ROMMON 被载入、验证并执行后,以 ML-DSA-87 量子安全签名验证操作系统镜像。 ML-DSA-87 · FIPS 204
4 OS 使用 ML-DSA-87 验证应用镜像 操作系统被载入、验证并执行后,继续以 ML-DSA-87 验证其上运行的应用镜像。 ML-DSA-87 · FIPS 204
5 OS 与经验证的应用正常运行 此时整条链完整闭合:从硅片到应用,每一级都被上一级用量子安全签名验证过。 Chain of Trust
6 TAm 持续提供关键服务 SUDI 身份、安全存储、真随机数、密钥管理、运行时完整性度量(IMA)全程可用。 TAm Services

图 6-3 量子安全 Secure Boot 六阶段。请注意算法分工:LMS 守护最底两级(不可变、低频、需管状态),ML-DSA-87 守护上层(通用、可更新)——这正是第四章 NSA 三条理由的工程落实。

算法分工背后的第一性逻辑:

为什么 Microloader 用 LMS,而 OS 用 ML-DSA-87?
因为 LMS 是有状态(stateful)方案——签名者需精确记录已用密钥索引。 对信任锚模块这类资源受限设备而言,管理状态是困难的; 但有状态方案的优势恰在"签名验证的效率"
而 Microloader 的场景是:签名极少(一年几次固件发布)、验证极频繁(每次上电)、 且必须在最受限的环境中完成——这正是 LMS 的最优场景。

而当信任锚需要自己生成签名时,就必须用无状态的通用方案——那就是 ML-DSA。

密钥保管的工程细节(决定这套体系是否真的可信):

  • Cisco 用私钥对所有镜像进行数字签名,私钥安全存储且永不离开构建环境(never leaving the build environment)
  • 对应的公钥被嵌入 TAm 硬件之中
  • 在 C9000 系列智能交换机上,TAm 嵌入在 FPGA 硬件中,建立起一条仅存在于 Cisco 设备的量子抗性信任链

解读:私钥不出构建环境 + 公钥焊在硅片里 = 攻击者既拿不到签名能力,也换不掉验证方。 两端都被物理约束住了。

6.4 第二问:如果连接 CPU 与 TAm 的那根线被搭上探针呢?

我们把身份和密钥都藏在防篡改芯片里了。但这些数据总要送到 CPU 去用——那段路上呢?

这正是 Cisco 在文档中称为"更微妙的漏洞(subtler vulnerability)"的东西。

因为敏感凭据(包括加密密钥)会经由 CPU 与 TAm 之间的数据总线传输, 拥有物理访问权限的攻击者可以用分析仪(analyzers)利用未受保护的总线连接。

换句话说:金库很安全,但从金库通往柜台的那条走廊,你有没有装监控?

CPU 与 TAm 之间数据总线的量子安全加密 敏感凭据经CPU与TAm之间的数据总线传输,物理接触攻击者可用分析仪窃取;Cisco对该总线应用ML-KEM与AES-GCM-256加密,使其抵御量子威胁。 最容易被忽略的攻击面:主板上那一根导线 Motherboard · 主板 CPU 主处理器 运行 OS 与应用 TAm 防篡改芯片 SUDI · 密钥 · 安全存储 与主处理器和内存相隔离 Data Bus · 数据总线 总线加密:ML-KEM + AES-GCM-256 即使这条内部通路,也已针对量子威胁加固 物理接触攻击者 + 总线分析仪 目标:窃取传输中的凭据与密钥 "量子安全产品"不只意味着换掉对外通信的算法 它意味着连主板内部两颗芯片之间的那一段路,都必须是量子安全的

图 6-4 CPU ↔ TAm 数据总线的量子安全加固。Cisco 通过对总线加密应用 ML-KEM 与 AES-GCM-256,确保连这条内部通信路径也针对量子威胁得到加固。

类比

这就像银行不仅把现金放在金库里,还给"从金库推到柜台"的那辆推车加了装甲。
大多数人只会想到金库的门够不够厚。而真正的专业设计,会假设"内部走廊也可能有人"。

还有一层容易被漏掉:FPGA 配置比特流。 Cisco 使用 FPGA 实现多种系统功能,包括信任锚设计与数据面加密 FPGA。 在可能的情况下,Cisco 使用 256 位 AES 密钥加密这些器件的配置比特流—— 因为如果这一层被改写,上面所有密码学都成为空中楼阁。

6.5 镜像签名与运行时防御:信任链的两端

镜像签名(Image Signing):两步生成唯一数字签名
步骤动作产物与用途
第一步 使用哈希算法(类似校验和)计算该代码块的哈希值 唯一指纹。Cisco 采用 SHA512(SHA2 家族)以保守应对未来量子攻击
第二步 Cisco 私钥加密该哈希 得到数字签名,随镜像一同附加并交付。签名镜像可在运行时被校验,验证软件未被修改

表 6-1 镜像签名两步流程。这就是你在 cisco.com 下载页面看到 SHA512 校验值的原因——它让你在加载到虚拟机前可手工验证完整性。

三项由此获得的保障:

  • 帮助确保固件、BIOS 与其他软件是真实且未被修改的
  • 提供关键检查,使只有正版、未修改的软件能在 Cisco 设备上启动
  • 有效缓解持久化攻击(persistent attacks)
硬件真实性检查(Hardware Authenticity Check)

执行时序非常重要:该流程使用 TAm 中安装的 X.509 SUDI 证书, 验证 Cisco 硬件是真实的(由 Cisco 制造)。 硬件真实性检查仅在 Secure Boot 流程完成、且软件已被验证为可信之后才运行。

为什么是这个顺序?因为如果软件本身不可信,那么"由软件报告的硬件检查结果"也不可信。 必须先确立软件可信,才能相信它对硬件的判断。这是一个极其严谨的逻辑排序。

运行时防御(Runtime Defenses, RTD)

Secure Boot 保护的是"启动那一刻"。但系统运行起来之后呢? 运行时防御针对的是向运行中的软件注入恶意代码的攻击。 Cisco 的运行时防御包含三项,它们是互补的(complementary)——可单独实施,也可多项协同部署

A

ASLR
地址空间布局随机化

Address Space Layout Randomization
每次运行时随机化内存布局,使攻击者无法预测关键代码与数据的地址, 令针对固定地址的漏洞利用失效。

B

BOSC
内置对象大小检查

Built-in Object Size Checking
在运行时校验对象大小,阻断缓冲区溢出这一类最经典的代码注入路径。

X

X-space
可执行空间保护

数据区域标记为不可执行, 使被注入到数据区的恶意载荷无法被 CPU 当作指令运行

补充:运行时完整性(Runtime Integrity)—— 诸如 IMA(Integrity Measurement Architecture,完整性度量架构) 的技术依赖密码学验证,确保设备在运行期间持续处于可信状态

而这正是第三章表 3-2 中列出的量子暴露面之一: 若缺少量子安全算法,运行时完整性检查可被绕过或伪造。

6.6 第三问:Cisco 是什么时候开始做这件事的?

NIST 的 PQC 竞赛 2016 年才启动,标准 2024 年才发布。那在此之前,有没有人已经在生产设备里跑量子安全签名了?

有。而且比竞赛启动还早三年。

2013 Cisco 开始在 FPGA 与硬件中部署 LDWM

LDWM 是一种哈希签名方案(HBS),基于 Lamport、Diffie、Winternitz、Merkle 数十年前开创的研究。Cisco 将其用于在加载软件镜像或固件前进行验证
具体参数:SHA256 哈希、Winternitz 参数 W=4、树高 H=10。
LDWM 也存在于多个服务提供商平台的 FPGA 实现的 Cisco 信任锚模块中。

2013 起 · Catalyst 9000 量子安全 Secure Boot 已在生产环境运行

Cisco 自 2013 年起,即在 Catalyst 9000 系列交换机上使用 LDWM 哈希签名提供量子安全 Secure Boot。 ——这意味着当业界还在讨论"量子威胁是不是科幻"的时候,Cisco 的量子安全签名已经在客户机房里跑了。

2016-12 NIST PQC 竞赛才刚刚启动

Call for Nominations 发布——比 Cisco 的 LDWM 生产部署晚了三年。

2019 Cisco 员工共同撰写 LMS 标准 RFC 8554

David McGrew、Scott Fluhrer、Michael Curcio 共同撰写了 LMS 标准(RFC 8554)—— 一种有状态 HBS 方案,是 LDWM 的演进版本。
LMS 在 LDWM 基础上,采纳了 Leighton 与 Micali 在 1995 年发表工作中的思想, 并引入了提供域分离(domain separation)的特定参数。

2017 SKIP 协议开发,扩展至量子安全网络传输

这项工作随后扩展到量子安全网络传输协议, 特别是通过 SKIP(2017 年开发)实现 QKD 集成。

当前 → 未来 硬件路线图切换到更 PQ 的镜像签名方案

新的硬件路线图将切换到 LMS 等更具后量子特性的镜像签名方案。 Cisco 明确表示:LDWM 与 LMS 签名方案将继续被集成到更多平台中; Ubiquitous PQ Trust Anchors(无处不在的后量子信任锚)是 Cisco 的目标。

图 6-5 Cisco 量子安全信任锚的时间线。关键洞察:因为信任锚被内建在设备中,且被刻意设计成难以更新,所以它必须"提前很多年"就做对。

Cisco 官方对"为什么必须这么早动手"的解释,是整章最重要的一句话:

"即使这样的大规模量子计算机预计在一段时间内还不会存在, 信任锚被内建在 Cisco 设备中,并且是被刻意设计成难以更新的(deliberately hard to update)。"

这就是第三章"补丁救不回来"的正面表述: 难以更新既是它安全的原因,也是它必须提前正确的原因。

为什么选择 HBS(哈希签名)?四条理由
S

实现直接、代码体积极小

Cisco 选择 HBS 是因为其实现直接(straightforward implementation)与最小的代码体积(minimal code size)——这对 Microloader 这种必须塞进硅片的场景至关重要。

W

本质被充分理解

它们的well-understood nature——基于数十年公开研究,密码分析历史最长。这也是 NSA 在 CNSA 2.0 中给出的三条理由之一。

P

基础原语简单

建立在简单原语(simple primitives)之上——安全性等同于哈希函数本身的强度,无需引入新的数学难题假设。

X

碰撞攻击天然无效

攻击者构造的哈希碰撞对 LMS 是无关的(irrelevant),因为 LMS 从不对"攻击者可选定其值"的字符串做哈希。这是一个极其优雅的设计。

6.7 第四问:不做 Trustworthy 会发生什么?

这些机制听起来很完备,但它们防的是"理论攻击"还是"已发生的攻击"?

Cisco 的官方回答毫不含糊:已发生。

"缺少硬件锚定的信任根已经导致了已知的入侵(has resulted in known hacks)。"

未实施 Trustworthy 的真实风险
  • 第三方可篡改 BIOS、Bootloader 或 ROM Monitor(ROMMON)启动代码,以加载被修改的软件镜像
  • 绕过硬件、真实性与许可证检查
  • 执行带有恶意意图的额外功能
  • 被篡改的代码可导致数据被操纵、数据被窃取
  • 可提供发起攻击的平台,包括拒绝服务(DoS)
  • 先进的持久性威胁可修改网络设备的硬件或软件,并数月甚至数年不被察觉,造成毁灭性破坏
实施 Trustworthy 后的确定性收益
  • 验证硬件是正版 Cisco(SUDI)
  • 防御假冒与软件篡改
  • 支持安全的加密通信
  • 启动时自动检查软件完整性,主动监控启动流程,检测到攻陷可中止启动
  • 助力设备认证与零接触部署,降低部署成本
  • RNG / 密码服务支撑安全通信

供应链维度:Value Chain Security 计划。

Cisco 与其供应商、制造与分销合作伙伴协作,通过 Value Chain Security 计划应对供应链风险。 该计划采用多层次安全方法,运用物理安全实践、逻辑安全流程与安全技术, 应对三类威胁:污染(taint)、假冒(counterfeit)、知识产权滥用(misuse of IP)

该计划在方案全生命周期内持续评估、监控与改进安全性

如何确认我的设备是否实现了 Trustworthy?

Cisco 的官方答复(值得直接引用给你的采购与运维团队):

Trustworthy 技术今天已在众多 Cisco 方案中可用。 产品团队会基于设备的使用场景(use case)将安全技术设计进产品。 这些能力当前已存在于许多 Cisco 路由、交换、无线、服务器与安全产品中, 并正在被设计进更多平台。

Cisco 会随威胁态势演进持续审视并调整产品安全要求, 持续创新并开发新的 Trustworthy 技术,在其可用时即予实施。

操作建议:联系客户经理或销售工程师,索取你所用设备的安全画像(security profile)

6.8 完整能力清单:Trustworthy 六大技术

技术 机制说明 带来的收益
镜像签名
Image Signing
两步生成唯一数字签名:哈希计算 → 私钥加密。签名随镜像交付,可在运行时校验 确保固件、BIOS、软件真实未修改;只有正版软件能启动;有效缓解持久化攻击
安全启动
Secure Boot
硬件锚定:Microloader 受防篡改硬件保护,建立信任根,防止执行被污染的网络软件 启动时自动完整性检查;监控启动流程,检测到攻陷即中止
信任锚模块
TAm
防篡改芯片,含非易失安全存储、SUDI、密码服务(RNG、密钥库、密码引擎) 制造时安装的 X.509 SUDI 提供唯一设备身份;支撑防假冒、认证、远程部署
信任链
Chain of Trust
每段代码在被允许运行前,其完整性均已被验证;由信任根逐级向上传递 安全启动系统并验证 Cisco 软件的完整性
硬件真实性检查
HW Authenticity
使用 TAm 中的 X.509 SUDI 证书验证硬件由 Cisco 制造。仅在 Secure Boot 完成后运行 验证硬件真实性,防御假冒
运行时防御
RTD
ASLR + BOSC + X-space,三者互补,可单独或协同部署 使攻击者更难或无法利用运行中软件的漏洞

表 6-2 Cisco Trustworthy 六大技术完整清单。这六项共同构成了三大支柱中的第二根:量子安全产品。

Trustworthy 的组织保障: Cisco 拥有一支专职工程师与安全经理团队,与产品开发团队协作, 将安全嵌入各产品线。并且 Cisco 使用在防御自身全球企业网络中积累的安全专长, 持续增强业务与方案的安全性。

Trustworthy 技术的实施在 Cisco 是强制要求"此类启动代码完整性流程,在 Cisco Secure Development Lifecycle(CSDL)中, 对所有基于 Cisco 平台的产品都是强制的(mandated)。"

6.9 本章收束

#推导步骤可直接执行的动作
信任的递归必须终止于不可变硬件,而非软件 采购评估中必问:信任根是否位于防篡改硅片内
TAm 提供四项基础能力:SUDI / 安全存储 / RNG / 密钥管理 确认设备是否具备 X.509v3 SUDI,作为零信任的身份基础
量子安全 Secure Boot = LMS(底两级)+ ML-DSA-87(上层) 向厂商索取各启动阶段使用的签名算法清单
校验失败时中止启动,而非仅告警 验证设备的失败处理策略:是 halt 还是 continue
CPU↔TAm 数据总线与 FPGA 比特流也必须加密 评估物理接触风险场景(远程站点、无人机房)的总线保护能力
Secure Boot 只管启动;运行期依赖 ASLR / BOSC / X-space + IMA 确认运行时完整性机制是否已 PQ 化
Cisco 2013 年即在 Catalyst 9000 部署 LDWM,早于 NIST 竞赛三年 把"厂商 PQ 实践的历史长度"纳入供应商评估维度
信任锚被刻意设计成难以更新——这既是优点也是约束 硬件采购必须一次做对;这是唯一无法软件补救的一层
BIOS / Bootloader / ROMMON 篡改是已发生的已知攻击 停止把它当"理论风险";纳入现有威胁模型

表 6-3 第六章推导链。第 ⑧ 条是本章、也是整篇白皮书最重要的采购决策依据。

到这里,三大支柱中的前两根已经完整:量子安全通信(第五章)+ 量子安全产品(第六章)

但我们一直在谈"能力",还没有谈"载体"。那些线速跑 ML-KEM 的硅片究竟长什么样? 为什么 Cisco 要专门造一颗"安全网络处理器(SNP)",而不是用通用 CPU 加密? 为什么老一代 ISR4K / ASR1K 无法通过软件升级获得量子安全?

下一章我们打开机箱:Cisco 8000 Series Secure Routers 的完整架构解剖—— 从 SNP 与第三代 QFP 的多核并行流水线,到动态资源分配、包处理生命周期、 再到 8100/8200/8300/8400/8500/8600 六个系列的性能与选型逻辑, 以及那个所有人最关心的问题:启用 PQC 之后,性能会掉多少?

第六章 · 记忆锚点

信任锚被刻意设计成难以更新——难以更新是它安全的原因,也正是它必须在出厂那一刻就已经是量子安全的原因。

第七章 · Cisco 8000 Series Secure Routers

打开机箱:为什么量子安全需要一颗全新的硅片?

前两章我们讲清了"能力":量子安全通信与量子安全产品。 但能力必须有载体。而这一章要回答一个所有 CTO 都会问、却很少被正面回答的问题:
"既然 PQC 只是软件算法,为什么不能给现有路由器打个补丁就完事?为什么必须换硬件?"

7.1 第一问:PQC 是软件算法,为什么需要专用硅片?

ML-KEM 只是一段数学运算代码。既然是软件,那我给 ISR4K / ASR1K 升级一下 IOS XE,不就量子安全了吗?

理论上可以跑起来,工程上跑不动。

回到第一章的第一性原理:非对称密码是 CPU 密集型的(CPU-intensive), 因为它依赖复杂的数学运算。这就是为什么它只被用于"通道建立",而不用于"持续数据加密"。

而 PQC 让这个问题更严重:格密码涉及高维矩阵运算, 密钥体积是传统 ECDH 的数十倍(ML-KEM-1024 公钥 1568 字节 vs ECDH 的几十字节)。

所以真正的问题不是"能不能算",而是"算的时候还能不能转发流量"。

精准定义

性能税(Performance Tax):当密码运算由通用 CPU 以软件方式执行时, 它会与控制平面、路由计算、管理任务争夺同一份 CPU 资源, 导致吞吐量下降、时延抖动、隧道建立变慢——这部分被"吃掉"的性能,就是性能税。

Cisco 的设计目标非常明确:让 PQC 的"性能税"对最终用户不可见(invisible to the end-user)。

类比

软件加密像是让公司的总经理亲自去搬货。
他确实能搬,但他一搬货,就没人签合同、没人开会、没人做决策了。 货越多,公司越瘫痪。

而专用加密引擎(SNP / Crypto Engine)像是雇了一支专业搬运队—— 他们只干搬货这一件事,干得极快,而且总经理完全不受影响

这就是"线速 PQC 加速(Line-Rate PQC Acceleration)"的含义: 加密不再是"额外负担",而是流水线上的一道内建工序。

这也直接解释了迁移指南中那条最关键的行动建议:

"使用 Cisco IQ 发现当前环境中的量子脆弱热点。 识别出缺少线速 ML-KEM 所需的安全网络处理器(SNP)的遗留 ISR4K 与 ASR1K 资产。"

注意措辞:不是"性能不够",而是"缺少 SNP"。 这是一个硬件能力的有无问题,不是快慢问题。

7.2 SNP:安全网络处理器的三大设计目标

SNP(Secure Networking Processor,安全网络处理器) 是 Cisco 8000 系列安全路由器的核心。它是专门构建的特化硅片, 用于承载下一代密码学的沉重计算需求,同时维持高性能路由

安全维度 · Security Inline Crypto
内联加密(Inline Crypto)——加密直接嵌入包处理路径
PQC-ready 加密引擎——原生支持后量子算法
Cisco Secure Firewall 加速——安全服务硬件卸载

线速 PQC 加速:SNP 提供处理 PQC 算法所需的专用硬件引擎不带来软件加密通常伴随的性能"税"

统一安全处理:通过将安全功能直接集成到包处理路径中, SNP 确保深度包检测与 PQC 原生加密都以线速执行

网络维度 · Networking Integrated Accelerators
集成硬件加速器
集成以太网控制器——1GE / mGig / 10GE / 25GE
性能定义功耗(Performance defined Power)
可编程微码——保护知识产权、保障特性一致性

可编程微码(Programmable uCode)的价值常被低估: 它意味着新特性可以通过微码更新下发, 而不必等下一代硅片——这是硬件层面的加密敏捷性。

AI/ML 引擎 · 内建智能 Built-in AI/ML Engine

SNP 内建 AI/ML 引擎,与硬件包分发引擎、内联加密引擎、 集成流量管理器共同构成系统级芯片(System-on-chip)

在 8300 / 8400 上,安全 AI/ML 具备"就绪卸载(Ready to offload)"能力—— 为未来 AI 驱动的安全分析预留了硅片级算力。

SNP 安全网络处理器架构 SNP系统级芯片包含控制CPU、信任锚、多核包处理引擎、内联加密引擎、AI/ML引擎、包分发器、流量管理器、集成以太网控制器与DRAM控制器。 Secure Networking Processor · 系统级芯片架构 安全与网络在硅片层面融合,而非在软件层面叠加 SNP · System-on-Chip DRAM Controllers ×4 · Last Level Caches (L3) Control CPU 64-bit 高性能处理器 运行 IOS XE 控制平面 Trust Anchor 内建于 SNP 之中 AI/ML Engine 内建智能分析引擎 Packet Processor Engine (PPE) 阵列 多核并行处理 · 非严格按流分发 PPEPPEPPE PPEPPEPPE PPEPPEPPE PPEPPEPPE 3rd Gen QFP: 224 PPE × 4 线程 = 896 线程 HW Assist: DST · FLB · PLU · RLB · ARL · TCM · sTCAM Packet Distributor Pkt Buffer Mgr / GPM Crypto Engine 内联加密 · PQC ready 16 个加密引擎 各自拥有专用资源 Traffic Manager 可扩展流量管理器 Flow queues 支持 复杂有状态特性 集成 I/O Ethernet Controller 1GE / mGig 10GE / 25GE L2 MACs w/ MACsec Interlaken & Mesh PCIe Gen 5 聚合 I/O 最大 240G 支持 4× QFP 级联 关键设计哲学:安全与网络在硅片层面融合(Security & Networking Convergence) 加密不是"加在包处理之后的一步",而是包处理流水线内建的一道工序

图 7-1 SNP 系统级芯片架构。注意 Trust Anchor 与 Crypto Engine 都在芯片内部——这正是第六章"总线加密"能被实现的物理前提。

7.3 三大构件:IOS XE、SNP、QFP

Cisco 8000 Series Secure Routers 建立在三块构件之上, 分支/园区侧与数据中心侧使用不同的转发引擎

OS

Cisco IOS XE

云原生操作系统。安全与网络融合、可编程性(本地 + 云)。 单一镜像 universalk9,可运行于 Autonomous 自治模式SD-WAN Controller 模式

SNP

Secure Networking Processor

分支与园区转发引擎。 8400 / 8300 / 8200 Series Secure Routers 由 SNP 驱动, 具备可处理后量子密码算法的专用加密卸载引擎

QFP

Quantum Flow Processor

数据中心转发引擎。第三代 QFP 提供 高性能、高扩展 ASIC,支撑 8500 / 8600 系列的超大规模转发。

第三代 QFP 的关键规格
224PPE(包处理引擎),每个 4 线程
896并行处理线程总数
16加密引擎,各自拥有专用资源
240G集成 L2 MAC 与 Mesh 的聚合 I/O最大值
支持 QFP 级联(Cascading)
可扩展流量管理器,Flow queues 支持复杂有状态特性
类比

896 个线程听起来像一个数字,但请这样想: 它相当于一条有 896 个工位的流水线,而且每个工位都能独立处理一个完整的包

而"16 个加密引擎,各自拥有专用资源"这句话的分量在于"专用"二字—— 它意味着加密工位不需要排队等公共资源, 所以你在启用 PQC 之后,那 896 个转发工位的效率不受影响。

7.4 第二问:同一颗芯片,如何既擅长转发又擅长安全?

纯路由场景需要最大转发能力;启用了 NGFW + IPS + TLS 解密的场景则需要大量服务处理能力。同一颗硅片怎么可能两者都最优?

答案是:不试图"同时最优",而是"按意图动态划分"。

SNP / QFP 支持动态资源分配(Dynamic Resource Provisioning)—— 根据你的部署意图,把核心资源在控制平面(CP)、包处理引擎(PPE)、 服务平面(SP)、接收与流量管理(Rx+TM)之间重新划分。

数据平面优先 · Data-plane-heavy

适用意图:路由 / SD-WAN 为主,追求最大转发与 IPsec 吞吐。

CP PPEPPEPPE PPEPPEPPE Rx+TM

核心分配倾向 PPE——最大化并行包处理能力。

典型用例:MPLS CPE、Overlay VPN、SD-WAN AAR、Secure Networks(SRv6)。

服务平面优先 · Service-plane-heavy

适用意图:NGFW、TLS 解密、TCP 优化 / DRE、vDSP 等重服务场景。

CP PPEPPE SPSPSP SP Rx+TM

核心分配倾向 SP——为深度检测与有状态服务预留算力。

典型用例:Secure Branch DIA/DCA(内建 Secure Firewall + IPS + URL-F + AMP)、AppQoE、语音。

查看当前核心分配模板 show platform software cpu alloc
G2# show platform software cpu alloc
CPU alloc information:
  Control plane cpu alloc: 0-1
  Data plane cpu alloc:    0,10-23
  Service plane cpu alloc: 2-9
  Template used: CLI-service_plane_heavy   ! ← 当前生效的资源模板

这就是"一颗芯片、两种性格"的实现方式。 它带来的运维价值是:同一个型号可以覆盖"纯路由分支"与"安全分支"两类部署, 无需为不同用例采购不同硬件——这也是硬件层面的敏捷性。

7.5 包的一生:FIA 特性调用数组

理解了资源如何划分,我们来看一个包在 SNP 内部究竟经历了什么。 这对故障排查与性能调优都有直接价值。

包在 SNP 内部的处理生命周期 包从NIC经Rx进入,由Parser解析、MCAM查表、Distributor分发到PPE阵列并行处理,途中调用Crypto Engine,最后经Traffic Manager多级队列从NIC送出。 The Life of a Packet · 包在 SNP 中的处理流水线 NIC 入向 Rx 接收 Parser 包头解析 MCAM Distributor 硬件分发引擎 非严格按流 PPE 并行阵列 执行 FIA 特性调用数组 ACL · NAT · FW · QoS · Netflow … Crypto Engine 内联 IPsec / MACsec / PQC Traffic Manager Q0 · Priority Q1 · BRR% Qn · Tail/RED 多级调度与整形 NIC 出向 Control Plane · 控制平面(IOSd / 路由计算 / 管理) 与数据平面资源隔离 → 加密负载不侵占控制平面 CPU

图 7-2 包在 SNP 内部的处理生命周期。关键点:Crypto Engine 位于 PPE 处理路径之内(内联),而非在流水线之外做"绕行卸载"。

精准定义

FIA(Feature Invocation Array,特性调用数组): 包在 PPE 中被处理时,所依次调用的特性函数序列。 它决定了这个包会经过哪些功能模块(ACL、NAT、防火墙、QoS、Netflow、IPsec……)。

查看命令:show platform hardware qfp active interface if-name <name>

数据路径上可被调用的主要特性(部分节选,体现处理链的丰富度):

L2/L3 分类 → IPv4/IPv6 校验 → QoS 分类与限速uRPFIPsecNATFirewallSSLVPNNetflowPBR / ACL → 转发(IP 单播负载均衡 / 组播 / MPLS 封装与解封装 / FRR / AToM)→ Marking / Policing / AccountingTCP MSS 调整Queuing → 出接口。

这条链的长度正是"为什么需要 896 个线程"的原因—— 每个包都要跑一遍这条流水线,而且必须在线速内跑完。

7.6 IOS XE:单镜像、双模式、可编程

单一镜像的运维价值
A

Autonomous 自治模式

传统 CLI / 自主管理。适用于 MPLS CPE、Overlay VPN、 Internet Gateway、Secure Networks(SRv6)等场景。简化部署

C

SD-WAN Controller 模式

SD-WAN Manager 集中编排。 适用于需要应用感知路由(AAR)、集中策略、量子安全策略批量下发的场景。 加速 SD-WAN 部署

同一个 universalk9 镜像,两种运行模式 —— 无需更换软件包
IOS XE 的分层架构
层次组成价值
控制与管理层 IOSd、SD-WAN、Confd、Telemetry、原生应用、容器应用、VM 云规模应用承载能力
数据库层 IOS XE Database 统一状态存储,支撑可编程性
转发与 I/O 层 CPP(QFP/SNP 抽象)、DPDK 硬件转发与软件转发路径统一
内核层 Linux Kernel 容器与应用托管的基础

表 7-1 IOS XE 分层架构。容器应用托管能力的实际意义:第五章提到的第三方 PQC 密钥模块(如 Quantum Xchange Phio TX)可直接作为托管应用运行在路由器上。

可编程性:Day 0 / 1 / 2 / n 全生命周期
Day 0零接触部署(Zero-Touch, PnP Provisioning)——设备上线
Day 1设备配置——YANG 数据模型、网络配置
Day 2设备监控——Telemetry 遥测
Day n设备优化——Guest Shell、Python 脚本、应用托管

Day 0 的零接触部署与第六章的 TAm 直接相关: SUDI 提供的不可伪造设备身份,正是零接触部署能够安全进行的前提—— 设备一上电就能向控制器证明"我是一台正版 Cisco 设备,序列号是 XXX", 无需任何人工介入,也无法被冒充。

7.7 第三问:启用 PQC 之后,性能到底掉多少?

这是最实际的问题。ML-KEM 公钥是 ECDH 的几十倍,握手消息从 4 条增加到 8 条——那吞吐量会掉多少?

Cisco 给出的答案是:零。

"Zero Throughput, Scale impact"——零吞吐量影响、零规模影响。

但这个答案需要被正确理解,否则会误导。

为什么"零影响"是成立的?三个第一性原因:

① PQC 只作用于"密钥交换",不作用于"数据加密"。
回顾第一章图 1-2:ML-KEM 替代的是阶段一的 DH/ECDH。 而承载业务流量的阶段二仍然是 AES-GCM-256,算法完全不变。 因此数据平面吞吐量在数学上就不受影响

② 密钥交换是低频事件。
IKEv2 SA 的生命周期是 86400 秒(24 小时)。 一天多算几次格运算,对全天吞吐量的影响趋近于零。

③ SNP 提供专用硬件引擎。
"尽管格密码数学复杂,Cisco 8000 系列中的 SNP 确保 ML-KEM 的密钥生成与封装不会给隧道建立引入显著时延。"

但有一个必须处理的真实副作用:分片(Fragmentation)。

这不是"性能下降",而是"配置不当会导致丢包"——两者性质完全不同。 因为 ML-KEM 公钥远大于经典 ECDH 密钥, IKEv2 分片必须启用,以确保这些更大的载荷能够穿越 MTU 受限的运营商网络而不被丢弃。

PQC 迁移的两条强制前置配置 缺一不可
! ① IKEv2 分片 —— 承载 ML-KEM 大公钥
crypto ikev2 fragmentation mtu 1400

! ② TCP MSS 钳制 —— 避免 PQC 载荷与混合密钥交换开销导致性能劣化的分片
!   应用位置:Hub 隧道接口 + Spoke LAN 侧接口
ip tcp adjust-mss 1360
类比

把 PQC 想成"换了一把更大的钥匙"。
钥匙变大了,开门那一下可能多花半秒(而且 SNP 让这半秒也几乎消失)—— 但门开了之后,货车进出的速度完全没变,因为货车用的是 AES-256,跟钥匙无关。

唯一需要注意的是:钥匙太大,可能塞不进原来的信封(MTU)。 所以你必须换个大信封,或者把钥匙拆成两个信封寄(IKEv2 分片)。 这不是性能问题,是包装问题——但如果不处理,门根本打不开。

已验证的互操作性:与 Cloudflare WAN 的实测

"标准化"的真正价值在于跨厂商互通。 Cisco 8000 系列与 Cloudflare WAN 的 PQC 互操作已完成实测验证:

Cisco 8570-G2 ↔ Cloudflare WAN · PQC IPsec 互操作验证 实测输出
C8570-G2# show crypto ikev2 sa detailed

Tunnel-id  Local                  Remote                fvrf/ivrf  Status
1          198.18.128.13/4500     162.159.79.254/4500   none/none  READY
   Encr: AES-GCM, keysize: 256, PRF: SHA384, Hash: None, DH Grp:20,
   Auth sign: PSK, Auth verify: PSK
   PQC Key Exchange: ML-KEM-1024
   Life/Active Time: 86400/59057 sec
   Local  id: ...ipsec.cloudflare.com
   Remote id: 162.159.79.254
   IETF Std Fragmentation enabled.            ! ← 标准分片已启用
   Quantum-safe Encryption using PQC: ML-KEM-1024

该互操作场景的关键配置要点(分支侧):

  • pqc mlkem1024 optional —— 非强制 PQC,保持向后兼容
  • encryption aes-gcm-256 + prf sha384 + group 20 —— 符合 CNSA 2.0 的对称与哈希要求
  • nat force-encap —— 当 CPE 位于 NAT/PAT 之后时必须启用
  • crypto ikev2 fragmentation mtu 1400 —— 强制
  • ip mtu 1450 + ip tcp adjust-mss 1350(隧道接口)

Cloudflare 侧工作流:Networking → Connectors → 创建 IPsec 隧道 → 生成 PSK → 添加路由。

这次互操作的战略意义:它证明了第四章那个论断—— 坚持 NIST 标准化算法,可确保长期互操作性并防止专有锁定。

如果 Cisco 与 Cloudflare 各自发明一套私有 PQC 方案, 那么今天这条量子安全隧道根本建不起来。标准化不是形式主义,它是互通的唯一前提。

7.8 六大系列:从小分支到数据中心的完整谱系

Cisco 8000 Series Secure Routers 覆盖六个系列, 从小型分支一路延伸到数据中心。选型的核心不是"看型号", 而是"看你要跑哪个用例、需要哪一档 IPsec 与威胁防护吞吐"。

系列 定位 转发 CEF IPsec SD-WAN AAR 威胁防护 TP
8100 小型分支
Small Branch
1.9 – 5.6 Gbps 1.5 Gbps 1 Gbps 1 Gbps
8200 中型分支
Medium Branch
5.6 – 19 Gbps 3 – 5 Gbps 2 – 4 Gbps 1 – 2.4 Gbps
8300 大型分支
Large Branch
38 Gbps 20 Gbps 12 Gbps 3.9 – 7 Gbps
8400 园区
Campus
67 – 88 Gbps 31 – 45 Gbps 20 Gbps 9.5 – 11 Gbps
8500 数据中心
Data Center
115 – 190 Gbps 48 – 63 Gbps
8600 数据中心旗舰
DC Flagship
540 Gbps 220 Gbps 82 Gbps

表 7-2 六大系列性能谱系。CEF 与 IPsec 数据基于 512 字节包长;TP(威胁防护)基于 EMIX 混合流量,含 100% DIA-NAT + 应用感知防火墙 + IPS + URL 过滤 + AMP。

相对上一代的性能跃升
8100 系列 对比 ISR1K
新增 10GE 铜口与 XGSPON WAN
8200 系列 对比 Catalyst 8200
新增 10GE 与 mGig WAN
10× 8300 系列 对比 Catalyst 8300
4× 10GE 与 mGig 连接
8400 系列 对比 C8500L-8S4X
新增 25GE WAN
路由规模 8500 系列 BGP 路由表
扩展至 8M
威胁防护吞吐 内建 Secure Firewall
相对上一代提升

图 7-3 相对上一代的性能跃升倍数。请注意 8300 的 10× 与威胁防护的 6×——这两个数字直接决定了"安全分支"能否与"纯路由分支"用同一台设备。

旗舰解剖:Cisco 8650 Secure Router
Cisco 8650 Secure Router · PQC-Ready 100G 安全路由器 3RU · XE 26.1.2
540Gbps 转发(Forwarding)
220Gbps IPsec
82Gbps SD-WAN
16M路由条目
32MNAT / 防火墙会话
380KACE(访问控制条目)
12KSD-WAN IPsec 隧道
100/40G QSFP28 端口
20×10/1G SFP+ 端口

关键能力:所有端口支持线速 WAN MACsec, 搭载第三代 QFP

Full-stack PQC NIST FIPS-203 PQC IPsec VPN Quantum-safe MACsec + EAP-TLS PQC SD-WAN PQC Secure Boot
新增型号一览(2026 新品)
型号WAN 接口核心性能版本
8221L-G2 2× 10G 铜口 WAN + 8× 1G 19 Gbps 转发 / 5 Gbps IPsec / 4 Gbps SD-WAN / 1 Gbps TP XE 26.1.2
8221-G2 2× 10G 光口 WAN + 8× 1G 19 / 5 / 4 / 1 Gbps XE 26.1.2
8225-G2 2× 10G 光口 WAN + 8× 1G 19 / 5 / 4 / 2.2 Gbps TP XE 26.1.2
8211-G2 2× 1G 光/铜 Combo + 4× 1G 5.6 / 3 / 2 / 1 Gbps XE 26.1.2
8151H-C-G2 10G 铜口 WAN + 1G Combo + 内嵌 5G Rel 17 5.6 / 1.5 / 1 / 1 Gbps XE 26.1.3
8130H-G2 10G 铜口 WAN + 4× 1G(仅路由 1.9 Gbps 转发 / 1.5 Gbps IPsec XE 26.1.3
8255-G2-UCSXE
Unified Edge 网络节点
2× 25G 背板 + 2× 10G Flex + 14× 1G PoE+ + 2× 2.5mG UPoE+ 19 / 5 / 4 / 2.2 Gbps;360W PoE 总预算 XE 26.2.1

表 7-3 2026 新增型号矩阵。全部型号原生支持 PQC IPsec / MACsec / SD-WAN 与 PQC Secure Boot。

Unified Edge 节点(8255-G2-UCSXE)值得单独关注: Cisco Unified Edge 是模块化平台,融合计算、LAN、WAN 与 SASE, 目标是在边缘安全、规模化地部署 AI

Secure Router Node 以 1U 半宽形态接入该平台, 实现 Intersight 与 SD-WAN Manager 之间的管理平面集成, 并与既有 8200 系列保持完整特性对等

7.9 七大 Secure WAN 用例:性能数据与选型依据

规格表本身没有意义,只有对应到用例才有意义。 以下是 Cisco 定义的七个主要 Secure WAN 用例, 以及每个用例下"为什么新一代更好"。

用例 业务场景 关键指标 新一代优势
① MPLS CPE CPE 由企业或 MSP 管理,与运营商 PE 建立路由对等,提供 VRF 分段与 QoS VRF + HQoS 吞吐 @512B
8100: 2.9G · 8200: 13.5G
8300: 28G · 8400: 65G
8500/8600: 420G
8300 快 2×(4× 10GE/mGig)
8400 快 3×(25GE WAN)
② Overlay VPN 企业自建 Hub & Spoke 叠加网络,含按需隧道,掌控自有拓扑 IPsec 吞吐 @512B
8100: 1.5G · 8200: 5G
8300: 20G · 8400: 45G
8600: 220G
8300 快 10×
8200 快 5×
NIST 合规 PQC
③ SD-WAN 应用感知路由(AAR),按 SLA(时延 <150ms、丢包 <1%)择优路径 AAR 吞吐 @512B
IPsec+QoS+DPI+FNF
8100: 1G · 8200: 4G
8300: 12G · 8400: 20G
8600: 82G
8100 快 3×
8200/8300 快 4×
NIST 合规 PQC
④ Secure Branch DIA/DCA 分支直连云/互联网,由内建 Secure Firewall 提供威胁防护 TP 吞吐 @EMIX
8100: 1G · 8200: 2.4G
8300: 7G · 8400: 11G
8100 新增 TLS 解密(快 6×)
8300/8400 快 3×
⑤ Secure Networks 军事保护核心、公用事业、交通、政务;通常与 Segment Routing 方案共同部署 IPsec 吞吐 @512B
同用例 ②
8200/8300 所有内建端口支持 WAN/LAN MACsec
8400 支持快速重路由(<50ms 收敛)+ 入向分类(端到端 QoS)
⑥ Internet Gateway 与多家 ISP BGP 对等,学习全量互联网路由,提供弹性访问、NAT 与抗 DoS NAT 吞吐 @512B
8300: 26G · 8400: 59G
8500/8600: 300G
8400 NAT 会话规模 2×(4M)
8500 BGP 路由规模 2×(8M)
⑦ Cloud Edge Colo/DC 站点经私有高速链路接入多云(AWS DX、Azure ER),由 IPsec 或 MACsec 加密 IPsec 吞吐 @512B
8300: 20G · 8400: 45G
8500/8600: 220G
8300 快 10×,所有内建端口支持 WAN/LAN MACsec

表 7-4 七大 Secure WAN 用例与性能对照。标注"NIST 合规 PQC"的三个用例(Overlay VPN / SD-WAN / Secure Networks)是量子迁移的第一优先级——它们对应第三章 Tier 1。

用例 ⑤ 的 MACsec 能力变化值得特别指出,因为它改变了设计模式:

上一代分支路由器中,WAN/LAN MACsec 仅在 8300-2N2S-4T2X 的内建 10GE 端口上受支持, 其他型号需要特定 NIM 模块(园区与数据中心路由器则完整支持)。

新一代 8200 系列及以上,所有内建端口均支持 WAN/LAN MACsec。 这意味着"第一跳加密"从"需要额外模块的选配项"变成了"开箱即有的基线能力"—— 直接支撑第五章提到的 PQC MACsec 部署。

7.10 内建 Secure Firewall:把安全塞进路由器

为什么不用一台独立防火墙?把防火墙功能塞进路由器,是不是牺牲了能力换取集成度?

如果是软件实现,确实是牺牲。但当安全被做进硅片(SNP 的 Secure Firewall 加速),逻辑就反过来了。

而且有第三方独立验证的数据支撑——这不是自我宣称。

99.23% 入侵防护(IPS)有效性 NetSecOpen 认证 · 8375-E-G2
99.79% 恶意软件检出率 NetSecOpen 认证 · 8235-G2

图 7-4 NetSecOpen 独立认证结果。NetSecOpen 是可信的第三方评测组织,其认证报告可用于支撑部署决策,而非厂商自测数据。

安全功能全景(Consistent Security Policy Construct)
能力域功能作用
下一代防火墙
NGFW
L3–L7 + 身份防火墙 管理穿越分支的流量
IPS / IDPS保护资产免受恶意行为者攻击
AMP防御恶意软件
沙箱(Sandboxing)通过 Threat Grid 进行文件分析
URL 过滤(URL-F)过滤互联网流量
流量解密与检测 TLS 解密 解密流量以供检测
DNS / SWG保护 Web 服务器与应用
SSE 生态集成 Auto Tunnel + HA 自动建立至 SSE 的 IPsec 隧道 —— 8 主用 / 8 备用
流量引导(Traffic Steering)基于应用的流量检测与重定向至 SSE
CASB治理对云应用的访问
FWaaS管理去往互联网的流量
DLP保护敏感数据免于未授权访问
管理、监控与分析 SD-WAN Manager · Cloud Control · Splunk 统一策略下发、可视化与全栈可观测

表 7-5 内建 Secure Firewall 与 SSE 生态能力全景。关键设计:Consistent Security Policy Construct —— 无论安全策略在本地执行还是引流至 SSE 执行,策略构造保持一致。

类比

把它想成"边检站与后方总部的分工"。
内建 Secure Firewall = 边检站,在现场就把明显有问题的挡住(低时延、不占带宽出境)。
SSE 引流 = 遇到需要深度调查的,自动转送到后方专业机构(8 主 8 备隧道,永不断线)。

而"策略构造一致"的意义是:边检站和总部用的是同一本法典。 你不需要维护两套规则,也不会出现"本地放行但云端拦截"这种令人抓狂的不一致。

7.11 迁移实战:DMVPN 的两条零中断路径

理论讲完了,我们来看一个真实的生产环境迁移蓝图: 把一个运行中的 DMVPN 环境迁移到 8000 系列,达成 ML-KEM PQC 状态, 同时保持高可用与关键业务零停机

前置条件(Hot Swap 路径必须满足)
前置项要求不满足时的处理
IKEv2 框架 迁移路径依赖 IKEv2 的混合协商能力。若现网 DMVPN 仍用 IKEv1,必须在更换硬件前先升级到 IKEv2 无法完成此基线升级的环境,应改走方案二(Parallel Island),它允许在新基础设施上从 IKEv1 直接过渡到 PQC 原生 IKEv2
TCP MSS 钳制 为容纳 PQC 载荷与混合密钥交换的额外开销,必须强制 MSS 钳制以防止性能劣化型分片
ip tcp adjust-mss 1360(所有 Hub 隧道接口 + Spoke LAN 侧接口)
强制
IKEv2 分片 因 ML-KEM 公钥显著大于经典 ECDH 密钥,必须启用 IKEv2 分片
crypto ikev2 fragmentation
强制

表 7-6 DMVPN PQC 迁移前置条件。IKEv1 的存在会直接决定你只能走方案二。

01 Hot Swap
DMVPN Hub 热替换
基于冗余的滚动升级
适合机架空间受限环境

在既有拓扑内用 8000 系列安全路由器替换遗留 Hub。 利用 pqc optional 的向后兼容特性,使单台 Hub 能同时服务 遗留 Spoke 与已迁移的 PQC Spoke。

风险中等(修改现有 Hub)
遗留影响最小(依赖 pqc optional)
回滚还原 Hub 硬件/配置
前提需具备 Hub 冗余基础设施
02 Parallel Island
并行架构(PQC 孤岛)
绿地方案
风险规避型组织的推荐路径

在遗留网络旁新建一套 PQC 原生的 8000 系列 Hub 集群。 Spoke 按站点逐个迁移至新"孤岛", 通过 NNI(Network-to-Network Interface)维持两个环境之间的可达性。

风险最低(洁净室环境)
遗留影响零(遗留网络完全不动)
回滚把 Spoke 重新归属回遗留 Hub
前提需有可用 WAN IP/端口做 NNI

图 7-5 DMVPN PQC 迁移两条路径对照。选择依据不是技术偏好,而是"你是否具备 Hub 冗余"与"你的风险容忍度"。

方案一实操:Hot Swap 的 Cisco 首推配置
关键网络绿地部署的 Cisco 首推加密配置 Mission Critical Greenfield
crypto ikev2 proposal cni_ikev2_proposal
 pqc mlkem1024 optional          ! ← 使新 Hub 可与已迁移 Spoke 协商 PQC,
                                  !   同时对遗留 Spoke 维持经典 IKEv2 交换
 encryption aes-gcm-256
 prf sha512
 group 21
!
crypto ikev2 policy cni_ikev2_policy
 proposal cni_ikev2_proposal
!
crypto ikev2 keyring ikev2keyring
 peer HUB-inet
  address 64.101.25.31
  pre-shared-key Cisco@123
 peer ANY_SPOKE
  address 0.0.0.0 0.0.0.0
  pre-shared-key Cisco@123
!
crypto ikev2 profile ikev2profile
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local  pre-share
 keyring local ikev2keyring
!
crypto ikev2 fragmentation mtu 1400
方案一实操:Hub 替换四步
  1. 通过调整路由度量,将流量从主用遗留 Hub 引流至备用 Hub。此时业务由备用 Hub 承载,主用 Hub 进入可操作窗口。
  2. 物理更换:用 Cisco 8000(G2)替换遗留 Hub。新 Hub 已预置上述 pqc optional 配置。
  3. 验证遗留 Spoke 使用经典算法重新建立隧道。这一步验证的正是 optional 的回退能力——第五章场景矩阵的第 2/3 号场景。
  4. 恢复流量均衡,然后对备用 Hub 重复上述流程。完成后两台 Hub 均为 PQC-ready,可开始按站点迁移 Spoke。
方案二实操:Parallel Island 三步
  1. NNI 桥接(The NNI Bridge):在遗留 Hub 集群与新的 8000 系列(G2)Hub 集群之间建立 Network-to-Network Interface。使用路由协议(如 BGP 或 EIGRP) 在已迁移与未迁移站点之间交换路由,以在迁移过程中维持通信。
  2. WAN 传输共享(WAN Transport Sharing):最有效的方法是 将 DMVPN Hub 与传输电路同时接入一个中间的二层 WAN 传输层。 该架构通过让两代 Hub 同时驻留在同一条物理电路上、使用各自独立的公网 IP 构建独立隧道 Fabric, 实现"洁净室(clean-room)"迁移。
    价值:借助这个中间交换机,Spoke 可以纯粹通过配置或边缘硬件更新完成迁移, 而数据中心侧的物理交接始终保持稳定 —— 零影响迁移。
  3. Spoke 迁移:新 Hub 集群上线并共享 WAN 传输后, 在每个站点用 Cisco 8000(G2)平台替换遗留路由器。 新 Spoke 使用现代化的 IKEv2 策略直接注册到 PQC 使能的 G2 Hub 集群, 在 Fabric 内建立起量子安全"孤岛"。
    过渡期内,站点间连通性由 NNI 桥接维持—— 来自已迁移 PQC Spoke 的流量可经 G2 Hub 转入遗留环境,抵达遗留目的地。

两方案的共同收尾动作:启用 PQC MACsec。

无论走哪条路径,一旦 8000 系列安全路由器就位, 都应在新 Hub 路由器与内部 LAN 交换机之间的链路上启用 PQC MACsec这确保迁移不只保护了 WAN,还提供了从分支第一跳开始的量子安全信封

这就是"纵深防御"在量子语境下的含义: 数据在 LAN 上由 MACsec(二层)加密, 跨 WAN 时由 IPsec(三层)再次加密, 对不同的收割点(harvest points)提供多层保护。

关于 SD-WAN 的战略提示(值得单独记住):

为实现量子韧性,SD-WAN 架构正从当前的"控制器分发密钥"模型演进为去中心化模型

  • IKEv2 集成:未来版本将为数据平面隧道引入原生 IKEv2 支持, 取代经由 TLS/DTLS 控制通道分发密钥的方式
  • PQC 使能:这一转向 IKEv2 的变化是功能性前提—— 它提供了在 Edge 对等体之间直接协商 ML-KEM 密钥交换所必需的标准框架
  • 准备动作:组织应今天就优先部署 Cisco 8000 系列硬件。 这确保当 PQC 使能的软件发布时,SNP 已经就位,可承载后量子计算负载而无需硬件刷新

这是本章最重要的采购论证:软件可以等,硬件不能等。

7.12 运维实战:监控什么、耗尽了怎么办

五个关键资源与对应命令
资源命令监控要点
平台资源总览 show platform resources 一屏看 RP 控制处理器、RP DRAM、ESP/QFP DRAM 的使用率与健康态
状态标识:H = Healthy · W = Warning · C = Critical
RP CPU / 内存 show proc cpu sorted
show mem stat
控制平面(IOSd)负载。SNMP:CISCO-PROCESS-MIB
数据面利用率 show platform hardware qfp active datapath utilization summary Input/Output pps 与 bps、Processing Load、RX/TX Load、Idle
技巧:bps ÷ pps ÷ 8 = 平均包长(字节)
逐核利用率 show platform hardware qfp active datapath infrastructure sw-cio 每个核心的 %PP(包处理)、%RX、%TM(流量管理)、%IDLE
加密引擎利用率 show platform hardware crypto-device utilization 1/5/15 分钟加密引擎使用率与加解密包数
SNMP:CISCO-ENTITY-PERFORMANCE-MIB
QFP 内存 (见 show platform resources SNMP:CISCO-ENTITY-QFP-MIB
Secure Firewall 资源 show utd engine standard status
show processes cpu platform sorted | sec snort
Snort 引擎数量、各引擎健康态(Green/Yellow/Red)、系统内存使用率、整体系统状态

表 7-7 关键资源监控命令速查。三个 SNMP MIB 应纳入常态化监控基线,而非等到故障才查。

一屏总览:平台资源健康态 show platform resources
G2# show platform resources
**State Acronym: H - Healthy, W - Warning, C - Critical
Resource                 Usage              Max       Warning  Critical  State
------------------------------------------------------------------------------
RP0 (ok, active)                                                         H
 Control Processor        1.75%              100%      80%      90%       H
  DRAM                    3941MB(25%)        15755MB   88%      93%       H
ESP0(ok, active)                                                         H
 QFP                                                                      H
  DRAM                    48320KB(2%)        2326528KB 85%      95%       H
资源耗尽的缓解手册(升级硬件之前的即时动作)
IOS / 控制平面 CPU 与内存告急
  • 优雅关闭路由邻居
    neighbor {ip} shutdown graceful <seconds>
  • 限制从邻居接收的前缀数量
    neighbor {ip} maximum-prefix <number>
  • 关闭软件冗余
    redundancymode none
QFP / 数据面 DRAM 告急
  • 降低 NAT 最大条目数
    ip nat translation max-entries <n>
    nat64 translation max-entries <n>
  • 降低防火墙会话上限
    parameter-map type inspect globalsession total <count>
  • 降低 Flexible NetFlow 缓存上限
    flow monitor M1cache entries <n>

图 7-6 资源耗尽缓解手册。这些是"在采购到货之前先撑住"的应急动作,不是长期方案。

Secure Firewall 健康检查的正确读法:

UTD 引擎状态 show utd engine standard status
G2# show utd engine standard status
Engine version : 1.14.16_SV3.1.81.0_XEmain
Profile        : Cloud-High
System memory  :
    Usage : 5.8%
    Status: Green
Number of engines : 6
Engine       Running   Health   Reason
==============================================
Engine(#1):  Yes       Green    None
Engine(#2):  Yes       Green    None
...
==============================================
Overall system status: Green

注意 Profile: Cloud-High—— 这个字段反映了当前的安全策略档位。 结合 show platform software cpu alloc 显示的 Template used: CLI-service_plane_heavy两者应当匹配:重服务档位需要服务平面优先的核心分配。

7.13 本章收束

#推导步骤可直接执行的动作
PQC 是软件算法,但缺少 SNP 的平台无法承载线速运算 用 Cisco IQ 识别缺 SNP 的 ISR4K / ASR1K 资产并列入刷新清单
SNP 把加密做进包处理路径(内联),而非流水线之外 评估厂商时区分"硬件卸载"与"内联加速"——后者才无性能税
动态资源分配让同一型号覆盖路由型与安全型部署 部署前用 show platform software cpu alloc 确认模板与用例匹配
PQC 只作用于阶段一密钥交换,数据面仍是 AES-256 停止担心吞吐量下降;把精力转向分片配置
ML-KEM 大公钥的真实副作用是分片,不是性能 两条强制配置:ikev2 fragmentation mtu 1400 + ip tcp adjust-mss 1360
8200 系列起,所有内建端口支持 WAN/LAN MACsec 第一跳加密从"选配模块"变为基线能力,纳入标准设计模板
与 Cloudflare WAN 的 PQC 互操作已实测通过 坚持 NIST 标准算法,拒绝任何专有 PQC 方案
IKEv1 环境无法走 Hot Swap,只能走 Parallel Island 立即盘点现网是否仍有 IKEv1——它决定你的迁移路径
SD-WAN 需先转向原生 IKEv2 才能承载 PQC 今天部署 8000 系列硬件,等软件到位即可启用,无需二次刷新
三个 SNMP MIB 覆盖 CPU/内存、QFP、加密引擎 把它们纳入常态化监控基线,而非事后排障工具

表 7-8 第七章推导链。第 ⑤⑧⑨ 三条是迁移项目最容易翻车的地方。

至此,三大支柱全部落地:量子安全通信(第五章)、量子安全产品(第六章)、 以及承载它们的硅片与平台(第七章)。

但还有最后一个问题——也是最难的一个:你有 8000 台设备、300 个应用、上万条加密链路。 从哪一台开始?谁来批预算?怎么证明进展?如何在三年后向监管机构证明合规?

下一章我们回到管理层视角,给出一份可以直接提交立项的完整迁移路线图: 六阶段方法论、CBoM 构建实操、厂商问卷、内外向迁移策略、 Cisco IQ 的发现与合规度量能力,以及最后—— 那份你可以在下周一早上就开始执行的行动清单。

第七章 · 记忆锚点

软件可以等,硬件不能等——今天部署带 SNP 的平台,等 PQC 软件发布时直接启用,而不必再做一次硬件刷新。

第八章 · Migration Roadmap

下周一早上就能开始:一份可提交立项的迁移路线图

前七章我们完成了完整的技术推导。但技术从来不是迁移失败的原因。
真正的失败原因是:没有优先级、没有 CBoM、没有预算生命周期、 没有厂商问卷、没有可度量的进展报告。
本章不再讲原理,只讲"下周一你该做什么"。

8.1 第一问:三步走还是六步走?

如果只能记住三个词,哪三个?

Discovery(发现)→ Prioritization(优先级)→ Implementation(实施)。

Cisco 把它压缩成"3 Steps to crypto-agility":
① 审计密码技术(硬件与软件);② 从 WAN 开始识别量子脆弱点; ③ 规划、准备、采纳量子抗性算法。

但三步只适合向董事会讲故事。要真正执行,需要展开为六阶段。

后量子迁移六阶段方法论 六个阶段依次为教育、评估与优先级、研究选项、制定战略、执行战略、监控进展,其中前两阶段为发现,中间两阶段为规划,后两阶段为落地与持续运营。 后量子迁移六阶段:每一阶段都有独立的预算生命周期 发现 · Discovery 规划 · Planning 落地与运营 · Execute & Operate 1 教育 Educate IT · 安全 · 领导层 建立共同认知 2 评估与优先级 Assess & Prioritize 产出 CBoM Tier 1–4 分级 3 研究选项 Research 算法 · 混合方案 厂商问卷 4 制定战略 Strategy 即时 / 近期 / 长期 加密敏捷性优先 5 执行战略 Execute 迁移 · 用户验收测试 更新标准与文档 6 监控进展 Monitor 合规度量 配置漂移检测 量子安全是持续运营的项目,不是一次性工程 —— 标准演进则回到阶段 3

图 8-1 后量子迁移六阶段方法论。注意底部虚线回环:这不是瀑布流程,而是随标准演进持续迭代的闭环。

8.2 阶段一:教育——为什么这一步不能跳过

目标:确保 IT、网络安全与领导层共同理解量子威胁及其对 WAN 基础设施与数据的影响

三个必须同步认知的点:

  • 威胁的时间性:HNDL 意味着"损失"发生在今天,而"暴露"发生在未来(第三章)
  • 威胁的层次性:不只是数据被解密,还有认证崩塌与信任根崩塌(第三章)
  • 解法的谱系性:不是"上了 ML-KEM 就完事",而是量子抗性 × 加密敏捷性(第五章)

组织保障:建立量子卓越中心(Quantum Center of Excellence)。

它的职责不是"技术攻关",而是推动跨职能对齐与内部专家培养。 因为迁移会同时触及网络、安全、应用、采购、合规、审计六个部门—— 没有一个跨职能的常设组织,这件事必然在部门墙上撞碎。

类比

跳过教育阶段,等于让消防队在不知道"什么是可燃物"的前提下去演练。 他们会把水浇在最显眼的地方——而真正的火源(信任根、认证体系)无人问津。

本文本身,就是可以直接发给这三类人的教育材料。

8.3 阶段二:评估与优先级——CBoM 是唯一的地基

如果你的迁移计划里没有一份 CBoM,你怎么知道自己迁完了?

你不知道。这就是为什么"没有 CBoM 的迁移计划只是一份愿望清单"。

CBoM 的四类资产与构建方法
维度内容要求
覆盖资产 算法(Algorithms)· 密钥(Keys)· 协议(Protocols)· 证书(Certificates) 特别标注所有非对称加密用法——那就是 Shor 算法的完整攻击面地图
覆盖环境 本地(on-premises)· 云 · IaaS · SaaS 需记录全部管理协议、叠加 VPN 与密码资产
发现方法 ① 代码分析工具
② 网络流量分析
③ 动态分析工具
工具化为主,避免依赖人工问卷(覆盖率与准确率均不可控)
输出格式 机器可读格式,推荐 CycloneDX(OWASP) 必须机器可读,否则无法支撑后续的自动化合规度量与漂移检测

表 8-1 CBoM 构建规格。"机器可读"这一条决定了阶段六(监控)是否可行——手工表格无法支撑持续合规。

评估维度与 Tier 分级

评估密码资产的四个维度:

数据敏感度与保留期(对应 Mosca 的 a
业务关键性(Criticality)
当前密码用法(Current crypto usages)
升级约束(Upgrade constraints,对应 Mosca 的 b

分级结果直接引用第三章的 Tier 1–4 优先级阶梯。 并叠加三个影响主题(Three Impact Themes)作为选型考量: 遗留与 EoL 系统 · 升级路径受限的系统 · PQ 使能软件对硬件的支持度

Cisco IQ:把发现从人工变成自动
能力作用
平台级特性分析 分析信任锚、安全启动、安全存储等平台级特性
三平面密码分析 分析管理、控制、数据平面的加密敏捷性与通信协议
精确定位改造需求 识别出哪些资产需要硬件替换、软件升级、或特定特性激活才能达成量子安全状态
全球合规追踪 持续追踪组织对CNSA 2.0 及欧盟、英国、加拿大、澳大利亚、日本等效标准的合规进度
合规度量(未来能力) 持续按行业强制标准(如 FIPS 203)度量网络状态,生成面向利益相关方的自动化合规报告
配置漂移检测(未来能力) 主动识别被手工回退到非 PQC 状态的设备,确保安全态势不随时间退化
预测性分析(未来能力) 通过分析加密流量健康度与 SNP 利用率在性能瓶颈影响生产流量之前预测它

表 8-2 Cisco IQ 的发现审计与持续合规能力。"配置漂移检测"是最容易被低估的一项——它把"迁移完成"从一次性事件变成可持续验证的状态。

两种自动化评估路径(可组合使用):

① 配置与状态采集:采集 running-configshow 输出, 由 Cisco IQ 分析并给出发现项与建议。
例如:发现 crypto ikev2 proposalgroup 15 无 PQC → 建议追加 pqc mlkem1024; 发现 SSH KEX 为 diffie-hellman-group14-sha1 → 建议改为 mlkem768nistp256-sha256

② 流量侧评估:通过 ETA(加密流量分析)与 Flow Export 采集传输中数据,分析网络传输与管理协议,逐流标注"量子脆弱"或"量子抗性"并生成报告。

8.4 阶段三:研究选项——四个必问的厂商问题

如果只能问供应商四个问题,问哪四个?

Cisco 给出的厂商问卷模板,恰好四项——而且每一项都对应本文的一个章节。

#必问问题为什么问 · 对应章节
1 当前 PQC 实现状态如何?
Current PQC implementation status
区分"路线图上有"与"今天可用"。要求提供具体版本号与 show 输出证据(第五章)
2 是否支持过渡期保护机制?
Supportability of interim protection mechanisms
即 PPK / RFC 8784 / SKIP 等不必等 FIPS 认证就能生效的方案(第五章)
3 路线图是否清晰?
Roadmap clarity
要求按产品线、按协议、按日期的清单,而非"我们正在关注"(第五章表 5-5)
4 是否支持加密敏捷性与 PQ/T 混合?
Crypto agility & hybrid PQ/T
这是最关键的一问——它决定你能否分阶段迁移、能否在算法被攻破时回退(第四章 SIKE 事件)

表 8-3 厂商问卷四问。建议做法:把这四问写入 RFP 的强制应答项,并要求提供可验证证据而非承诺。

三条选型硬约束(来自 Cisco 官方建议):

  • 与厂商协作验证硬件兼容性并规划刷新周期——不要假设现有硬件能升级
  • 选择支持 10 至 15 年密码演进周期的方案——避免二次刷新
  • 坚持 NIST 标准化 PQC 协议——确保长期互操作性并防止专有锁定

技术评估要做四件事:评估新算法与实现 · 测试兼容性 · 评估性能 · 做出有依据的采纳决策

8.5 阶段四:制定战略——三段时间线与内向外策略

三段时间线
时段动作本文对应能力
即时
Immediate
部署过渡期保护措施识别硬件支持度缺口 Manual PPK / SKIP 动态 PPK(第五章)
Cisco IQ 硬件缺口发现(第八章)
近期
Near-term
混合方案(Hybrid solutions)升级高风险系统 PQ/T 混合 ML-KEM + ECDH(第四、五章)
Tier 1 资产优先(第三章)
长期
Long-term
全面过渡到原生 PQC pqc optional 全局切换为 pqc required(第五、七章)

表 8-4 三段迁移时间线。注意"即时"这一栏——它不需要等任何新硬件或新标准。

内向外(Inward-Out)迁移策略

从核心开始还是从边缘开始?

从核心开始(Inward-Out)。理由很朴素: 核心节点数量少(4–8 个 Hub),改造工作量可控; 而核心一旦 PQC-ready,就能立刻服务任何后续迁移的分支—— 反之若先改分支,它们找不到能对话的 PQC Hub。

内向外迁移策略的五个层次 迁移从数据中心与灾备核心节点开始,向区域枢纽、远程分支、远程接入用户扩展,最终覆盖第三方云与SSE集成。 Inward-Out:从核心向外扩散,量子威胁面由内到外递增 迁移顺序 → ① 数据中心 / 灾备 DC / DR · 高端汇聚 起点:4 至 8 个 Hub 节点,覆盖 DC/DR 与云环境 遗留 ASR1K 与 Catalyst 8500 仅支持 PPK 方案;新 8500/8400 系列内建 PQC 且兼容 PPK → 优于纯 QKD 路径:可与后续区域枢纽与 Spoke 直接协商 ② 区域枢纽 Regional Hubs 聚合点:连接区域分支,同时作为全球数据中心的 Spoke 原生 PQC 支持在此层是必需的——为后续远程分支与远程接入用户的合规做准备 建议:区域枢宁与 DC 间用原生 PQC,向分支侧保留经典加密回退 ③ 远程分支 Remote Branches 规模:数百至数千个地理分散站点 原生 PQC 确保规模化的量子安全加密与认证——必须分阶段推进 → 站点数量大,采用 phased approach;考虑分支与区域枢纽间原生 PQC ④ 远程接入用户 Remote Access PQC 使能的 VPN 头端保护远程用户流量 ⚠ 但认证需要量子安全的 CA 与身份提供方 → 在整个公钥密码生态量子安全之前,远程接入用户建议保留经典加密 ⑤ 第三方集成 Third-party 云服务商 · 中间链路互联 · SSE 方案 —— 共同构成应用与用户的连通性 Fabric 8000 系列内建 PQC 将保护延伸至本地、云与远程接入全环境 → 必须核查其当前与演进中的后量子支持能力,确保与你的策略对齐

图 8-2 内向外迁移策略五层次。注意第 ④ 层的红色警告:远程接入的瓶颈不在 VPN 头端,而在证书颁发机构与身份提供方的 PQ 化进度。

硬件评估是关键路径(Critical Path)。

"迁移大规模安全 WAN(DMVPN、SD-WAN)到 PQC 时,需评估网络层级并优先处理需要立即保护的网段。 硬件评估同样关键,因为平台替换面临采购延迟与预算约束。"

翻译成项目管理语言:硬件采购周期是整个迁移项目的关键路径, 必须最早启动,因为它无法被压缩。

8.6 阶段五:执行——三条必守纪律

纪律要求本文依据
① 定义中断阈值与回滚策略 PQC 迁移需分阶段进行,确保业务连续性,并明确定义中断阈值(outage thresholds)与回滚策略 DMVPN 双方案的回滚设计(第七章表 7-6)
② 过渡期必须双栈并存 过渡期内,网络必须同时支持 PQC 与传统公钥密码(PKC)。 实施 PQ/T 混合方案可实现不同安全要求系统间的无缝互操作, 并最终迁移到纯 PQC 环境 pqc optional 四场景矩阵(第五章图 5-5)
③ 全面测试与验证 迁移计划必须验证PQC 使能的软件库已正确集成进基础设施系统, 并与 PQC 生态服务建立互操作性,包括第三方身份提供方与企业 CA 服务器 Cloudflare WAN 互操作实测(第七章)

表 8-5 执行阶段三条必守纪律。第 ③ 条常被忽略:CA 服务器与身份提供方的 PQ 化,是远程接入迁移的真正瓶颈。

执行阶段的四项交付物(不只是"设备上线"):

  • 平滑实施与迁移,最小化中断
  • 用户验收测试(User Acceptance Testing)
  • 迁移后运营指引(Post-migration operational guidance)
  • 更新内部标准、流程与文档:内部 KB、设计指南、配置模板、 信息安全策略、软件开发流程、以及 CBoM 本身

最后一项尤其重要:如果 CBoM 没有随迁移更新, 那么阶段六的合规度量就失去了基线。

8.7 阶段六:监控——量子安全是持续运营,不是一次性工程

迁移完成之后,这个项目就结束了吗?

不。因为有两件事会持续变化:标准会演进,配置会漂移。

Q

量子演进里程碑

追踪量子硬件进展、量子纠错、分布式量子计算(DQC)第二章已证明:Q-Day 可被一篇论文单方面提前——所以监控不能只看硬件新闻。

S

标准演进

追踪 RFC、PQC 算法、监管截止日期并评估对你的战略的影响——必要时回到阶段 3 重新研究选项。

P

自身进展

追踪变更推进过程中的项目状态与合规度依托 Cisco IQ 的自动化合规报告与配置漂移检测(表 8-2)。

为什么"配置漂移"是最现实的威胁?

因为在三年的迁移周期里,会有无数次故障排查、临时变更、紧急回滚。 每一次"先把 PQC 关掉试试",都可能变成永久状态——而且没人记得打开。

这就是为什么必须有自动化的漂移检测: 主动识别被手工回退到非 PQC 状态的设备,确保安全态势不随时间退化。

8.8 专业服务:四类可直接采购的加速能力

如果内部资源不足,Cisco 提供 Quantum-Ready Professional Services, 其使命是:赋能客户主动保护组织免受新兴量子威胁, 同时驾驭量子技术的巨大变革潜力以驱动创新与增长。

服务内容对应阶段
量子风险评估
Quantum Risk Assessment
通过评估与风险分析理解组织的量子威胁暴露面; 识别关键资产并对风险排序;自动化审计与评估;业务风险影响分析;资产分类 阶段 2
战略、路线图与专家培养
Strategy, Roadmap & Expertise
制定个性化转型计划;通过针对性教育与建立量子卓越中心培养内部专家、推动跨职能对齐; 量子学科教育;用例定义 阶段 1 + 4
量子安全架构设计与测试
Design & Testing
自动化审计与评估;研究补救方案;选项测试;量子安全架构设计; 加速且优先排序的转型战略;有依据的决策 阶段 3 + 4
实施与运营化
Implementation & Management
部署量子抗性密码并整改遗留系统;平滑实施与迁移; 用户验收测试;迁移后运营指引;更新标准、流程与文档; 维持合规并适配演进中的标准 阶段 5 + 6

表 8-6 Quantum-Ready Professional Services 四类服务与迁移阶段映射。可按阶段单独采购,无需一揽子承诺。

8.9 下周一的行动清单

把所有内容压缩成四条可以立刻执行的动作。 这四条来自 Cisco《Quantum-Ready Migration Guide》的 Call to Action, 并叠加了本文各章的具体依据。

  1. 用 Cisco IQ 做一次量子风险审计。 发现当前环境中的量子脆弱热点;识别缺少线速 ML-KEM 所需 SNP 的遗留 ISR4K 与 ASR1K 资产
    → 同时启动 CBoM 构建(表 8-1),产出机器可读的 CycloneDX 清单。
  2. 现代化硬件基座。 启动 Cisco 8000 Series Secure Routers 的采购与备货; 优先覆盖承载高价值数据、面临 HNDL 风险的站点
    → 依据:硬件采购是关键路径,无法压缩(8.5 节);软件可等,硬件不能等(第七章)。
  3. 标准化到 IKEv2。 如果遗留 DMVPN 或站点到站点隧道仍在使用 IKEv1,今天就启动向 IKEv2 的过渡
    → 这是实施 ML-KEM 等 PQC 算法的强制前提;也决定你能否走 Hot Swap 而非 Parallel Island(表 7-6)。
  4. 启用第一跳安全。 更新 LAN 边缘策略,在接入交换机与 Cisco 8000 Series Secure Router 之间启用 PQC MACsec, 确保从分支到核心的连续量子安全信封
    → 依据:8200 系列起所有内建端口均支持 WAN/LAN MACsec(第七章表 7-4)。

第五条(本文追加):立即 PQ 化管理平面 SSH。

依据第五章的"分发通道悖论":如果你用传统 SSH 去配置 PPK 或 PQC 策略, 那么这个配置动作本身就在制造一个新的 HNDL 目标。

最低成本、最高收益的一条动作
ip ssh client algorithm kex mlkem1024nistp384-sha384
ip ssh server algorithm kex mlkem1024nistp384-sha384
! 部署前请核对平台支持矩阵,避免 %SSH-3-KEX_PQC_NOT_SUPP

8.10 本章收束

#推导步骤可直接执行的动作
三步讲故事,六阶段做执行,且是闭环而非瀑布 立项书按六阶段拆分,每阶段独立预算生命周期
教育阶段决定后续所有阶段的对齐度 成立量子卓越中心,把本文作为首轮教育材料
没有机器可读的 CBoM,就没有可验证的迁移完成 用 CycloneDX 格式产出 CBoM,特别标注全部非对称用法
厂商问卷四问,每问都要求可验证证据 把四问写入 RFP 强制应答项
内向外策略:核心节点少、收益高、且是后续迁移的前提 4–8 个 DC/DR Hub 起步
远程接入的瓶颈是 CA 与身份提供方,不是 VPN 头端 CA / IdP 的 PQ 化进度纳入依赖项跟踪
硬件采购是关键路径,无法压缩 硬件立项与盘点并行启动,不要串行等待
配置漂移会让"已完成"的迁移悄悄退化 部署自动化漂移检测,纳入常态运维基线
迁移交付物包含标准、流程、文档与 CBoM 的更新 把文档更新写入项目验收条件,而非"有空再做"

表 8-7 第八章推导链。第 ⑦ 条是唯一一条"今天不做,三年后无法补救"的动作。

第八章 · 记忆锚点

没有 CBoM 的迁移计划只是一份愿望清单——而硬件采购是唯一无法被压缩的关键路径。

结语 · Closing

回到开头那个问题:你今天发出的数据包,2032 年会被谁读到?

本文开篇提出了一个场景:一个小偷今天搬走了你的保险箱,但没有钥匙——直到多年后,一把万能钥匙出现。 我们把它称为"一场先搬走保险箱、再慢慢配钥匙的抢劫":今天被截获归档的加密流量,就是那个还没被打开的保险箱。
现在,你已经知道这把"万能钥匙"是什么、什么时候可能出现,以及如何在它出现之前把保险箱换掉。

八章推导的一条主线

章节回答的问题最重要的一个结论
第一章 加密为什么安全? 安全性 = 反向计算的时间成本,而非"复杂度"。三大公钥算法全部悬挂在三个数学难题
第二章 量子计算凭什么撬开它? Shor 提供指数级加速(RSA/DH/ECC 必须换算法);Grover 仅平方级且难并行(AES-256 只需加长)
第三章 有多急?威胁只有一种吗? Mosca 定理 a+b>c 显示多数行业已越线;威胁有三层,且信任根崩塌无法软件补救
第四章 换成什么?谁定时间表? 五件套:ML-KEM / ML-DSA / LMS-XMSS / AES-256 / SHA-384-512; CNSA 2.0 网络设备 2026 支持 / 2030 独占 / 2027 新采购红线
第五章 不等 FIPS 认证能做什么? PPK 今天就能用(RFC 8784 / SKIP);pqc optional 一个关键字实现零中断分阶段迁移
第六章 硬件层怎么建立信任? TAm + SUDI + LMS/ML-DSA-87 六阶段安全启动; 信任锚被刻意设计成难以更新——这既是优点也是必须提前做对的原因
第七章 为什么必须换硬件?性能掉多少? 缺 SNP 的平台无法承载线速 PQC;PQC 只影响阶段一密钥交换, 吞吐零影响,但分片必须配
第八章 下周一做什么? 六阶段方法论 + CBoM + 厂商四问 + 内向外策略; 硬件采购是唯一无法压缩的关键路径

表 9-1 八章主线回顾。如果只能带走一张表,就是这一张。

三个必须同时成立的条件

量子安全通信

  • 管理平面:SSH / HTTPS-API
  • 控制平面:IKEv2 / 路由认证
  • 数据平面:IPsec / MACsec / TLS

第五章——今天即可通过 PPK 起步

量子安全产品

  • 信任锚(TAm + SUDI)
  • 安全固件与安全启动
  • 安全存储 / 安全运行时 / 安全身份

第六章——只能靠硬件刷新

加密敏捷性

  • 动态密钥支持
  • 高效的加密方法切换
  • 混合方案与分阶段采纳

贯穿全文——无法采购,只能设计

图 9-1 量子安全的三大支柱。公式:量子安全 = 量子抗性 × 加密敏捷性。乘法意味着任一项为零,结果就是零。

最后三句话

第一句(关于时间): 本文反复引用过 Cisco 那句关于"10 年保密周期"的警告——传统 IPsec VPN 传输的数据, 只要保密期超过 10 年,就已经在今天被攻破了,推迟实施 PQC 等同于主动放弃长期机密性。 如果你现在才第一次真正理解这句话的分量,说明前八章已经完成了它的使命。

第二句(关于硬件): "组织应当今天就优先部署 Cisco 8000 Series 硬件。 这确保当 PQC 使能的软件发布时,SNP 已经就位, 可承载后量子计算负载而无需硬件刷新。"

第三句(关于行动): "2025 至 2030 这个窗口,是数字网络史上最重大的密码学变革期。 通过今天采用 NIST 批准的算法与硬件锚定的信任, 你不只是在更新一台路由器——你是在为组织数据的主权做未来防护。
面对量子威胁,沉默本身就是一个漏洞。主动现代化是唯一的防御。"

Securing Today for Tomorrow

时间是单向的。你今天加密的每一个数据包,都在为十年后的那一天投票——而这一票,无法重投。

附录 · Glossary

完整术语表

按主题分组。每个术语给出中英文、精准定义,以及在本文中首次出现的章节。

A · 量子计算基础

Qubit 量子比特 · 第二章
信息的基本单位,与经典比特一样只有 |0⟩ 与 |1⟩ 两个可测量基态,但遵循量子力学规则。物理实现可为超导电路、囚禁离子、光子等;其威力不来自物理载体,而来自所展现的量子性质。
Superposition 叠加 · 第二章
量子比特可同时处于 0 与 1 的线性组合状态:|ψ⟩ = α|0⟩ + β|1⟩。概率 = 振幅²,且 α² + β² = 1。n 个量子比特可同时承载 2ⁿ 个状态。测量会导致坍缩。
Entanglement 纠缠 · 第二章
两个或多个量子比特被关联,使其中一个的状态直接决定另一个的状态,无论相距多远。已被实验反复验证,是量子纠错、逻辑量子比特与分布式量子计算的基础。
Interference 干涉 · 第二章
建设性干涉(同相叠加放大)与破坏性干涉(反相叠加抵消)。量子算法的本质工作不是"算出答案",而是在测量前把正确答案的振幅放大、错误答案的振幅抵消。
Quantum Gate 量子门 · 第二章
操作振幅 θ 与相位 Φ 的运算单元。输入与输出的量子比特数量永远相等。关键门:H(Hadamard,制造均匀叠加)、X(Pauli-X,量子 NOT)、T(Z 轴旋转 45°)、CNOT(受控非,产生纠缠)。
Shor's Algorithm Shor 算法 · 1994 · 第二章
周期查找算法,可解质因数分解与离散对数问题,提供指数级加速。直接威胁 RSA、DH、ECDH、ECDSA——即整个公钥基础设施。
Grover's Algorithm Grover 算法 · 1996 · 第二章
无结构数据库搜索算法,将 N 次搜索降为 √N 次,提供平方级加速,且难以并行化(1000 台机器仅加速约 31.6 倍)。对 AES-256 而言仍需约 2¹²⁸ 次迭代,不构成实际威胁。
QEC Quantum Error Correction · 量子纠错 · 第二章
通过将一个逻辑量子比特编码到多个物理量子比特上,使错误可被检测并纠正而无需直接测量底层量子态。物理:逻辑比率已从早期理论的 10,000× 降至约 7.5×(Microsoft + Quantinuum, 2024)。
Logical vs Physical Qubit 逻辑 / 物理量子比特 · 第二章
破解 RSA-2048 需约 1,400 个逻辑量子比特;破解 AES-256 需 6,681 个逻辑量子比特。新闻中的"1121 量子比特"指的是物理量子比特。
NISQ / Early FTQC / FASQ 量子成熟度三级 · 第二章
NISQ:噪声中等规模量子,依赖误差缓解,产业主体所在。Early FTQC:逻辑错误率显著低于物理错误率。FASQ:容错应用规模量子,约需 100 万 rQOPS,即 CRQC
DQC Distributed Quantum Computing · 分布式量子计算 · 第二章
通过量子网络将多颗较小的量子处理器用纠缠连接,在逻辑上模拟一台更大的机器。意味着"单芯片量子比特数"可能不是决定 Q-Day 的瓶颈。

B · 威胁与风险

CRQC Cryptographically Relevant Quantum Computer · 第序章
密码分析相关量子计算机——具备足够稳定量子比特数与足够低错误率、能运行破解当代公钥密码算法的量子机器。不是"完全成熟"的量子计算机,而是"足以破解今天加密"的那一台。
Q-Day / Y2Q 第二章
Q-Day:CRQC 真正可用、能破解当代公钥密码的那一天。Y2Q(Years to Quantum):距离 Q-Day 还剩多少年。CSA 设定倒计时为 2030-04-14;GRI 专家共识为 10–15 年;Cisco 规划基线取 2030–2035。
HNDL Harvest Now, Decrypt Later · 序章
先收割、后解密。攻击者今天大规模截获并归档加密流量(形成"时间胶囊"),待 CRQC 可用时追溯性解密数年历史数据。被动攻击,不产生任何告警。
Mosca's Theorem Mosca 定理 · 第三章
a + b > ca = 数据保密期;b = 迁移所需时间;c = CRQC 出现所需时间。若不等式成立,风险已实质发生。每推迟一年启动,暴露窗口按 1:1 加长。
Authentication Collapse 认证崩塌 · 第三章
Shor 算法破解数字签名后导致的两类攻击:身份伪造(冒充可信 Hub / 管理服务器 / 端点)与控制平面劫持(注入恶意路由、建立"可信"隧道)。Q-Day 当天即实时生效,且不触发任何传统告警。
Trust Root Collapse 信任根崩塌 · 第三章
启动链未受量子安全签名保护导致的三类后果:恶意代码注入(低于 OS 层,监控不可见)、假冒硬件与"官方"固件、持久化后门(任何软件补丁都无法移除)。这是唯一必须靠硬件刷新解决的攻击面。
SIKE Break SIKE 被攻破事件 · 2022-08 · 第四章
SIKE(超奇异同源密钥封装)已通过 NIST 六年评审进入第四轮,却在标准发布前被一台单核笔记本在一小时内完全攻破。这是"必须采用混合模式"最有力的实证依据。

C · 密码学与算法

Trapdoor Function 陷门函数 · 第一章
正向计算极易、反向求解极难的数学函数;但掌握额外秘密(陷门,即私钥)后反向求解重新变得容易。RSA 依赖质因数分解,DH 依赖离散对数(DLP),ECC 依赖椭圆曲线离散对数(ECDLP)。
PQC Post-Quantum Cryptography · 后量子密码学 · 第四章
研究运行在经典计算机上、但能抵抗量子攻击的密码算法的学科。不需要量子硬件——这是与 QKD 的本质区别。
ML-KEM FIPS 203 · 原 CRYSTALS-Kyber · 第四章
基于模格的密钥封装机制,替代 DH / ECDH。CNSA 2.0 要求所有密级使用 Level V 参数(ML-KEM-1024:封装公钥 1568 B、密文 1568 B,导致 IKEv2 SA 建立消息数由 4 增至 8)。三步流程:KeyGen → Encaps → Decaps。
ML-DSA FIPS 204 · 原 CRYSTALS-Dilithium · 第四章
基于模格的数字签名算法,替代 RSA / ECDSA。CNSA 2.0 要求 Level V 参数(ML-DSA-87)。用于 IKEv2 隧道认证,以及安全启动第 3–4 阶段的 OS 与应用镜像验证。
LMS / XMSS NIST SP 800-208 · 第四章
哈希签名方案(HBS)。LMS = Leighton-Micali Signature(RFC 8554,Cisco 员工共同撰写);XMSS = eXtended Merkle Signature Scheme(RFC 8391)。有状态——签名者须精确记录已用密钥索引,防止重用。NSA 推荐 LMS + SHA-256/192。攻击者构造的哈希碰撞对 LMS 无效。
SLH-DSA FIPS 205 · 原 SPHINCS+ · 第四章
基于哈希构造的无状态数字签名方案,作为 ML-DSA 的备选。签名体积远大于 ML-DSA。
LDWM 第六章
LMS 的前身,基于 Lamport、Diffie、Winternitz、Merkle 的研究。Cisco 自 2013 年起即在 Catalyst 9000 与多个 SP 平台的 FPGA 信任锚中部署(参数:SHA256、W=4、H=10)——比 NIST PQC 竞赛启动早三年。
Module-LWE 模误差学习问题 · 第四章
给出一批"近似正确"的线性方程(每个都被加入微小随机误差),要求还原原始秘密向量。ML-KEM 的安全性与此问题的计算困难度直接相关。格密码抗量子的根本原因:几何问题没有可供傅立叶变换提取的周期性。
Crypto Agility 加密敏捷性 · 第五章
在保持安全性与业务连续运行的前提下,替换并适配协议、应用、软件、硬件、固件与基础设施中密码算法的能力。要素:最小中断快速适配、支持混合方案、分阶段迁移、兼容监管演进、动态密钥管理。三大支柱中唯一无法采购、只能设计的一项。
PQ/T Hybrid 后量子/传统混合 · 第四章
传统算法(如 ECDH)与 PQC 算法(如 ML-KEM)并行运行,输出经密码学组合生成混合共享秘密。攻击者必须同时破解两种算法。两条采用理由:① PQC 实现与协议尚新,需保留回退;② 传统算法已 FIPS 认证,可消除 PQC 认证的两年等待期。

D · 标准与合规

CNSA 2.0 Commercial National Security Algorithm Suite 2.0 · 2022-09 · 第四章
NSA 发布的商用国家安全算法套件,适用于所有 NSS 对公共密码算法的使用。差异化时间表:固件签名 2025 支持 / 2030 独占;网络设备 2026 支持 / 2030 独占;OS 2027 / 2033;小众设备 2030 / 2033。使用未批准算法需申请专门豁免。
FIPS 140-3 第四章
密码模块验证标准(区别于 FIPS 203 等算法标准)。验证实现正确性、密钥管理、物理防护、自检机制等工程质量。PQC 算法完成 FIPS 认证的平均耗时为两年或更久——这正是混合模式的第二个存在理由。
NIAP National Information Assurance Partnership · 第四章
依 CNSSP 11,提供密码服务的软硬件除满足 CNSA 要求外,还需通过 NIAP 或 NSA 验证。NSS 不应以"FIPS-validated"作为 RMF 评估标准,而必须是 NSA 批准的方案。
CBoM Cryptographic Bill of Materials · 密码物料清单 · 第三章
机器可读格式(推荐 OWASP CycloneDX)的结构化清单,涵盖算法、密钥、协议、证书四类资产,覆盖本地、云、IaaS、SaaS 全环境,并特别标注全部非对称加密用法。没有 CBoM 的迁移计划只是愿望清单。
Tier 1–4 优先级分级 · 第三章
Tier 1:存在直接量子脆弱性的关键基础设施(核心 WAN、DCI、VPN 汇聚、管理平面)。Tier 2:嵌入密码学的业务关键用途。Tier 3:具长期机密性要求的数据。Tier 4:仅有短生命周期密码需求的系统。

E · 协议与实现

PPK Post-Quantum Pre-Shared Key · 后量子预共享密钥 · 第五章
至少 256 bit 熵的随机比特串,被混入 IKEv2 密钥派生流程。PPK 既不在密钥交换中传输,也不在 VPN 建立后传输——因此攻击者即使用量子计算机算出 DH 共享秘密,仍无法重建会话密钥。
RFC 8784 Mixing PPK in IKEv2 · 由 Cisco 首倡 · 第五章
定义如何将 PPK 混入 IKEv2 密钥派生:SK_d = prf+(PPK, SK_d')SK_pi/SK_pr 同理;子 SA 重协商时在 KEYMAT 与 SKEYSEED 中追加 PPK。不混入父 IKE SA 的加密与完整性密钥。提供 required 强制标志控制四种协商场景。
SKIP Secure Key Integration Protocol · Cisco 开发 · draft-cisco-skip-02 · 第五章
量子抗性客户端/服务器框架,连接"PPK 增强的 IKEv2 对等体"与任意带外 PPK 同步机制(如 QKD)。运行于 HTTPS/TLS(1.2 或 1.3)之上。五步流程中链路上只传输 PPK-ID,PPK 本体从不出现。密钥源须以 hex 格式发送密钥。
RFC 9370 / RFC 9242 第四章
RFC 9370:IKEv2 多重密钥交换,是混合 IKEv2 的基础扩展。RFC 9242:IKEv2 中间交换,用于传输大体积数据(ML-KEM 大公钥所必需)。IKEv2 目前仅支持混合模式;TLS/DTLS 与 SSH 同时支持混合与纯 PQC。
QKD Quantum Key Distribution · 量子密钥分发 · 第五章
利用量子态传递密钥;窃听者无法读取且窃听行为会被立即察觉。已在 1000 公里距离实现。硬约束:需专用光纤直连,因为当前光交换机会破坏量子效应。NSA 禁止 QKD 方案;德国 BSI 不推荐。适合 DCI 等少量高价值链路,不适合全网规模化。
SKS Session Key Service · 第五章
Cisco 在 IOS XR 上的集成密钥管理服务,设备自身提供按需量子安全密钥,无需额外基础设施。KMS 使能产品数量有限。
EAP-TLS for MACsec RFC 9190 · 第五章
证书式 MACsec 加密的量子安全链条:802.1X 端口认证 → EAP-TLS(TLS 1.3 + ML-KEM)→ 生成并共享主会话密钥 MSK → MKA 建立会话密钥。配置关键项:access-session pqc-type pqc
IKEv2 Fragmentation 第五章
因 ML-KEM 公钥远大于经典 ECDH,必须启用以避免 IP 层分片在 MTU 受限的运营商网络中被丢弃。crypto ikev2 fragmentation mtu 1400,配合 ip tcp adjust-mss 1360这是 PQC 迁移的两条强制前置配置。

F · Cisco 平台与技术

TAm Trust Anchor module · 信任锚模块 · 第六章
Cisco 专有防篡改芯片,制造阶段安装于所有 Cisco 物理设备主板,与主处理器和内存相隔离。提供四项基础能力:SUDI 不可变身份、高安全存储、NIST SP 800-90A/B 可认证的 RNG(从内部真随机源提取熵)、密钥管理与密码服务被刻意设计成难以更新。
SUDI Secure Unique Device Identifier · 第六章
X.509v3 证书,保存产品标识符(PID)与序列号,制造阶段实施,链接到可公开识别的根 CA。证书、密钥对与整条证书链全部存储于 TAm 内;密钥对与特定 TAm 芯片密码学绑定,私钥永不导出——使克隆或伪造身份在实践上不可能。零信任架构的物理基础。
Secure Boot 安全启动 · 第六章
硬件锚定启动:Microloader 受防篡改硬件保护,CPU 从 Microloader 而非原始 Bootloader 开始执行。量子安全版本六阶段:ML(LMS)→ 验证 BL(LMS)→ 验证 OS(ML-DSA-87)→ 验证应用(ML-DSA-87)→ 运行 → TAm 持续服务。校验失败即中止启动,而非仅告警。
Chain of Trust 信任链 · 第六章
系统中每段代码在被允许运行前,其完整性均已被验证。起始于信任根,由信任根验证下一元素(通常是固件),依次向上传递。Cisco 私钥永不离开构建环境;公钥嵌入 TAm 硬件。
RTD Runtime Defenses · 运行时防御 · 第六章
针对向运行中软件注入恶意代码的攻击。三项互补技术:ASLR(地址空间布局随机化)、BOSC(内置对象大小检查,阻断缓冲区溢出)、X-space(数据区标记为不可执行)。可单独或协同部署。
IMA Integrity Measurement Architecture · 第三章
依赖密码学验证,确保设备在运行期间持续处于可信状态。若缺少量子安全算法,运行时完整性检查可被绕过或伪造。
SNP Secure Networking Processor · 安全网络处理器 · 第七章
Cisco 8000 系列(8200/8300/8400)的核心硅片,专门构建以承载下一代密码学计算需求同时维持高性能路由。提供线速 PQC 加速(消除软件加密的性能税)、统一安全处理(安全功能直接集成到包处理路径)、内建 AI/ML 引擎、集成以太网控制器与可编程微码。遗留 ISR4K / ASR1K 缺少 SNP。
QFP Quantum Flow Processor · 第七章
Cisco 8500/8600 系列的转发引擎。第三代规格:224 个 PPE × 4 线程 = 896 线程、16 个各有专用资源的加密引擎、最大 240G 聚合 I/O、支持 4× QFP 级联。名称中的 "Quantum" 早于后量子语境,指流处理架构。
FIA Feature Invocation Array · 特性调用数组 · 第七章
包在 PPE 中被处理时依次调用的特性函数序列,决定该包经过哪些功能模块(ACL、NAT、防火墙、QoS、Netflow、IPsec 等)。查看命令:show platform hardware qfp active interface if-name <name>
Dynamic Resource Provisioning 动态资源分配 · 第七章
按部署意图在控制平面(CP)、包处理引擎(PPE)、服务平面(SP)、接收与流量管理(Rx+TM)之间重新划分核心。两种模板:Data-plane-heavy(路由/SD-WAN)与 Service-plane-heavy(NGFW/TLS 解密/DRE)。查看:show platform software cpu alloc
Cisco IQ 第八章
量子迁移的发现与评估引擎。分析平台级特性(信任锚、安全启动、安全存储)与管理/控制/数据三平面的加密敏捷性与通信协议,精确识别哪些资产需要硬件替换、软件升级或特性激活。持续追踪对 CNSA 2.0 及欧盟、英国、加拿大、澳大利亚、日本等效标准的合规进度。未来能力:自动化合规报告、配置漂移检测、基于 SNP 利用率的预测性分析。
Configuration Catalog 配置目录 · 第五章
Cisco 提供的预验证配置目录,包含按 NIST 与 CNSA 2.0 标准预先工程化的 IPsec 与 MACsec PQC 模板,降低工程团队的研究负担,并消除手工输错复杂密码字符串的风险。由 Catalyst SD-WAN Manager 集中下发。
Unified Edge 第七章
Cisco 模块化平台,融合计算、LAN、WAN 与 SASE,目标是在边缘安全、规模化地部署 AI。Secure Router Node(8255-G2-UCSXE)以 1U 半宽形态接入,实现 Intersight 与 SD-WAN Manager 的管理平面集成,并与既有 8200 系列保持完整特性对等。
NetSecOpen 第七章
可信第三方安全评测组织。Cisco 8000 系列认证结果:入侵防护(IPS)有效性 99.23%(8375-E-G2)、恶意软件检出率 99.79%(8235-G2)。其认证报告可用于支撑部署决策,区别于厂商自测数据。
Value Chain Security 价值链安全计划 · 第六章
Cisco 与供应商、制造与分销合作伙伴协作应对供应链风险的计划。采用多层次方法,运用物理安全实践、逻辑安全流程与安全技术,应对三类威胁:污染(taint)、假冒(counterfeit)、知识产权滥用。在方案全生命周期内持续评估、监控与改进。
CSDL Cisco Secure Development Lifecycle · 第六章
Cisco 安全开发生命周期。启动代码完整性流程在 CSDL 中对所有基于 Cisco 平台的产品都是强制的(mandated)——这使 Trustworthy 技术从"可选特性"变为"开发纪律"。

G · 部署形态与用例

DMVPN Dynamic Multipoint VPN · 第五章
通过组合 mGRE + IPsec/IKEv2 + NHRP 实现大规模 IPsec VPN 部署。PQC 应用在 IKEv2 层,确保动态 NHRP 注册与后续 Spoke-to-Spoke 隧道均以量子安全会话密钥初始化。SNP 可承载大型 DMVPN Hub 上的高并发 IKEv2 协商,即使 PQC 带来更大的密钥交换包。
FlexVPN 第五章
基于 IKEv2 的标准化 VPN 框架,原生构建于 IKEv2 之上,是 PQC 的天然归属。可用单一一致的 PQC 策略覆盖站点到站点、远程接入、Hub-and-Spoke 全部拓扑。通过模块化 "Smart Default" 配置目录快速切换到量子安全标准。含 SVTI(静态虚拟隧道接口)与 DVTI(动态虚拟隧道接口)。
IKEv2 CLB Cluster Load Balancing · 第五章
多节点 FlexVPN 网关方案。在 FlexVPN 网关集群间分发入向 IKEv2 连接请求,提供弹性可扩展的 WAN 汇聚。支持 IPv4 与 IPv6。关键组件:HSRP、CLB primary / subordinate、CLB 通信、IKEv2 重定向机制。
Hot Swap vs Parallel Island DMVPN 迁移双路径 · 第七章
Hot Swap:在既有拓扑内滚动替换 Hub,依赖 pqc optional 使单台 Hub 同时服务遗留与已迁移 Spoke。风险中等,需 Hub 冗余,要求现网已是 IKEv2Parallel Island:新建 PQC 原生 Hub 集群,通过 NNI 桥接与二层 WAN 传输共享实现洁净室迁移。风险最低,遗留网络零影响,允许从 IKEv1 直接过渡到 PQC 原生 IKEv2
NNI Network-to-Network Interface · 第七章
在遗留 Hub 集群与新 PQC Hub 集群之间建立的接口,使用路由协议(BGP 或 EIGRP)在已迁移与未迁移站点之间交换路由,以在迁移过程中维持通信。Parallel Island 方案的核心组件。
Inward-Out Migration 内向外迁移策略 · 第八章
五层次推进顺序:① 数据中心/灾备(4–8 个 Hub 起步)→ ② 区域枢纽(原生 PQC 在此层必需)→ ③ 远程分支(数百至数千站点,分阶段)→ ④ 远程接入用户(瓶颈在 CA 与身份提供方,建议保留经典加密)→ ⑤ 第三方集成(云、中间链路、SSE)。
Threat Protection TP · 威胁防护吞吐 · 第七章
Cisco 8000 系列的性能指标之一,测试组合为:100% DIA-NAT + 应用感知防火墙 + IPS + URL 过滤 + AMP,基于 EMIX 混合流量。相对上一代提升约
SSE Auto Tunnel 第七章
自动建立至 SSE(安全服务边缘)的 IPsec 隧道,规格为 8 主用 / 8 备用。配合流量引导(基于应用的检测与重定向)、CASB、FWaaS、DLP 构成完整 SSE 生态集成。核心设计原则:Consistent Security Policy Construct——本地执行与云端执行使用同一策略构造。

术语表使用建议: 本表按七个主题分组(量子基础 / 威胁风险 / 密码算法 / 标准合规 / 协议实现 / Cisco 平台 / 部署用例), 可直接摘出对应分组作为不同团队的培训材料

  • 领导层与合规团队 → B(威胁与风险)+ D(标准与合规)
  • 安全架构师 → C(密码算法)+ D + E(协议实现)
  • 网络工程与运维 → E + F(Cisco 平台)+ G(部署用例)
  • 全员基础认知 → A(量子基础)+ B
附录 · References

参考资料与延伸阅读

本文全部技术论断均来自以下一手资料。按类别分组,标注本文引用的核心章节。

标准与规范

CNSA 2.0 Announcing the Commercial National Security Algorithm Suite 2.0 NSA Cybersecurity Advisory, PP-22-1338, SEP 2022 Ver. 1.0
本文第三、四章的核心依据:差异化时间表、五步执行方法、CNSA 1.0/2.0 算法对照、强制稽核机制
FIPS 197 Advanced Encryption Standard (AES) CNSA 2.0 要求所有密级使用 256 位密钥
FIPS 180-4 Secure Hash Standard (SHA) CNSA 2.0 要求 SHA-384 或 SHA-512
FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM) 替代 DH/ECDH
FIPS 204 Module-Lattice-Based Digital Signature Standard (ML-DSA) 替代 RSA/ECDSA
FIPS 205 Stateless Hash-Based Digital Signature Standard (SLH-DSA) ML-DSA 的无状态备选
SP 800-208 Recommendation for Stateful Hash-Based Signature Schemes LMS / XMSS 的标准依据;NSA 推荐 LMS + SHA-256/192
SP 800-90A/B Random Number Generation Cisco TAm 提供可依此认证的 RNG,从内部真随机源提取熵

IETF RFC 与 Draft

RFC 8554 Leighton-Micali Hash-Based Signatures (LMS) Cisco 员工 David McGrew、Scott Fluhrer、Michael Curcio 共同撰写
RFC 8391 XMSS: eXtended Merkle Signature Scheme
RFC 8784 Mixing Preshared Keys in IKEv2 for Post-quantum Security 由 Cisco 首倡——本文第五章 PPK 方案的核心标准
RFC 9370 Multiple Key Exchanges in IKEv2 混合 IKEv2 的基础扩展
RFC 9242 Intermediate Exchange in IKEv2 用于传输 ML-KEM 大公钥
RFC 9190 EAP-TLS 1.3 证书式量子安全 MACsec 的依据
RFC 8603 / 8755 / 8756
9151 / 9206 / 9212
CNSA 1.0 实现指引六件套 依次为:证书与 CRL 配置 · S/MIME · CMS 证书管理 · TLS/DTLS 1.2 与 1.3 · IPsec · SSH。NSA 将随标准化进程发布 CNSA 2.0 版本更新
draft-cisco-skip-02 Cisco Secure Key Integration Protocol (SKIP) 动态 PPK 的协议依据
draft-guthrie-cnsa2-ipsec-profile CNSA 2.0 的 IPsec 配置文件
draft-becker-cnsa2-tls-profile CNSA 2.0 的 TLS 配置文件
draft-becker-cnsa2-ssh-profile CNSA 2.0 的 SSH 配置文件
draft-ietf-opsawg-tacacs-tls13 TACACS+ over TLS 1.3 管理平面协议的 PQ 化
Various Drafts PQ Hybrid Key Exchange with ML-KEM in IKEv2 / TLS 1.3 / SSHModule-Lattice Key Exchange in SSHML-KEM Post-Quantum Key Agreement for TLS 1.3

Cisco 官方文档

白皮书 Quantum-Ready Migration Guide: Modernizing Mission-Critical Networks with PQC May 2026
本文第五、七、八章的核心依据:HNDL 论证、DMVPN 双迁移路径、SNP 架构、Cisco IQ、Call to Action
白皮书 The Journey to Post-Quantum Cryptography in WAN Infrastructure
WAN-first 策略、Mosca 定理应用、QKD 六维评估、内向外迁移策略、全球法规时间线
白皮书 Cryptography in a Post-Quantum World NIST 算法选型、CNSA 2.0 影响与时间线、混合模式两条理由、FIPS 认证两年等待期
白皮书 Post-Quantum Trust Anchors: Security and trust in a post-quantum computing world 2019 首发 / 2024 更新
本文第六章核心依据:TAm、LDWM 2013 部署史、SHA512 选择、FPGA 比特流加密
白皮书 A Vision for Securing Networks in the Quantum Compute Era Cisco Research 与 Quantum Labs 双引擎、Full-Stack PQC、C9000 TAm in FPGA
技术文档 Building Post-Quantum Resistant Secure WAN October 2025
RFC 8784 密钥派生数学、Manual/Dynamic PPK 完整 CLI 与 show 输出、四种协商场景、平台支持矩阵
数据手册 Cisco Trustworthy Technologies Data Sheet 六大技术清单:镜像签名、安全启动、TAm、信任链、硬件真实性检查、运行时防御
路线图 Cisco Quantum-Safe Communications Roadmap Last updated Aug 11, 2026
2026 年 12 月与 2027 年 6 月两批交付清单;Cisco Live US 2026 产品发布
技术会议 BRKXAR-2027 Inside Cisco 8000 Series Secure Routers: Architecture, Use Cases, and Innovation
本文第七章核心依据:SNP/QFP 架构、动态资源分配、七大用例性能、运维监控命令
技术会议 TECETI-2401 Quantum-Ready Tectorial: Building Resilient Networks with PQC and Hybrid Solutions
量子计算原理、Shor/Grover 分野、Q-Day 加速因子、三大支柱、六阶段方法论、防火墙 PQ 节奏
解决方案 Modernization of Mission-Critical Networks February 2026 关键网络七大挑战、多层网络架构、8000 系列五大差异化能力
入门读物 Post-Quantum Cryptography (PQC) For Dummies, Cisco Special Edition Wiley, 2026
量子基础概念、五大算法角色、全球十国地区合规时间线

学术研究与业界报告

1994 Shor, P. Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer
arxiv.org/abs/quant-ph/9508027
1996 Grover, L. A fast quantum mechanical algorithm for database search
arxiv.org/abs/quant-ph/9605043
2012 Fowler et al. 破解 RSA-2048 需约 10 亿物理量子比特("工程上遥不可及")
2019 Gidney & Ekerå 同一目标降至约 2000 万物理量子比特,耗时约 8 小时
2025 Gidney 再降至 897,864 物理量子比特 arxiv.org/pdf/2505.15917
2026 Babbush et al. Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities
破解 ECC-256 所需量子比特再降 10 倍至约 50 万 arxiv.org/pdf/2603.28846
报告 Global Risk Institute 2025 Quantum Threat Timeline Report 约 50% 专家预测 Q-Day 在 10–15 年内
报告 Cloud Security Alliance Countdown to Quantum 设定 Q-Day 倒计时为 2030-04-14
报告 2025 Cisco Cybersecurity Readiness Index 31% 受访者将"网络"列为最难防御网络攻击的领域——高于任何其他领域
QEC Google Research Suppressing quantum errors by scaling a surface code logical qubit(2023,49:1)
Harvard(2023,48:1)· IBM(2024,288:12)· Microsoft + Quantinuum(2024,30:4)

各国监管指引

US NSM-10(National Security Memorandum 10)· NSD-42 · NSM-8 · CNSSP 11 · CNSSP 15 · CSfC(Commercial Solutions for Classified)
AU Australia Stay ahead of the quantum threat with PQC
CA Canada CCCS ITSM.40.00 — Roadmap for PQC migration
UK UK NCSC PQC migration timelines
IN India TEC TEC 910018:2025 — Migration to PQC
DE Germany BSI 不推荐 QKD 方案(与 NSA 立场一致)
JP Japan CRYPTREC 密码技术评价与标准更新

官方资源入口

Cisco Trust Center — Post-Quantum Cryptography
cisco.com/site/us/en/about/trust-center/post-quantum-cryptography
Cisco Research — Quantum Projects
research.cisco.com/research-projects/quantum
Cisco 8000 Series Secure Routers
cisco.com/site/us/en/products/networking/sdwan-routers/8000-secure-routers
PQC MACsec 配置指南
cisco.com/c/en/us/td/docs/routers/ios/config/17-x/sec-vpn/b-security-vpn
Cisco Security and Trust Office (STO) — Trust Center & Trust Portal
提供文档、合规资源与平台完整性指引,用于验证 PQC 使能系统

免责声明与时效性提示

本文所引用的 Cisco 路线图信息可能在无通知的情况下变更 (Cisco 官方原文:"This roadmap may change without notice.", Quantum-Safe Communications Roadmap 最后更新于 2026 年 8 月 11 日)。

量子计算能力估算、QEC 编码效率、Q-Day 预测均处于快速演进中—— 第二章已论证:Q-Day 可被一篇论文单方面提前,而不需要任何新硬件出厂。 因此本文的所有时间判断都应视为当期最优估计,而非确定结论

实际部署前请核对目标平台的软件版本支持矩阵与特性可用性—— 特别是 PQ/T 混合 SSH KEX 仅在部分平台受支持, 以及 PPK 方案不支持 GETVPN