你今天发出的每一个数据包,都可能在 2032 年被公开朗读
这不是科幻。这是一场已经开始、但还没有结束的抢劫案——赃物已经被搬走,钥匙却要等到几年后才配好。 本文用第一性原理与苏格拉底提问法,从"加密到底为什么安全"这个最朴素的问题出发, 一路推导到 NIST/CNSA 2.0 标准、Cisco 全栈量子安全战略、Trustworthy 硅片级信任根, 以及 Cisco 8000 系列安全路由器上真正可落地的配置与迁移路径。
一场"先搬走保险箱,再慢慢配钥匙"的抢劫
我们习惯于这样理解安全事件:黑客攻进来 → 数据被偷 → 我们发现 → 我们修补。 整个链条里有一个隐含假设:"数据被偷"和"数据被读懂"是同一件事。 后量子时代最反直觉的地方,就是它把这两件事在时间轴上撕开了——中间可能隔着五年、十年。
先问一个问题:如果一个小偷搬走了你的保险箱,但他没有钥匙,你会报警吗?
大多数人会说:"当然要报,但至少东西是安全的。"——这正是今天绝大多数企业对加密流量的心理状态。 可如果这个小偷知道,五年后市面上会出现一把万能钥匙呢? 那么他今天搬走保险箱这个动作,就不是失败的抢劫,而是一次极其耐心的、成功率 100% 的预付款。
这个攻击模式有一个专有名字:HNDL(Harvest Now, Decrypt Later)。 Cisco 的《Quantum-Ready Migration Guide》把它形容得非常准确:这些被归档的加密流量是一个 "时间胶囊(time capsule)"——今天不可读,但一旦 CRQC 投入运行,几十年的知识产权、国家机密、金融记录都会被追溯性地(retroactively)解密。
把 HNDL 想成"银行把所有监控录像都存了下来,但看不懂里面的口型"。 十年后,唇语识别 AI 出现了。于是十年前那些"看了也没用"的录像,一夜之间变成了完整的对话记录。 你无法回到十年前重新拉上窗帘——时间是单向的,这也是为什么"以后再说"在密码学里是最昂贵的一个决定。
于是问题变得非常尖锐:凭什么量子计算机能"配出万能钥匙"? 要回答它,我们必须先回到一个更朴素、更根本的问题—— 我们今天所依赖的"加密",到底为什么是安全的?
这就是第一章。请注意:本文接下来不会先讲量子物理,因为那是本末倒置。 我们要先搞清楚"锁"的原理,才能理解"钥匙"为什么失效。
在量子时代,"数据被偷"与"数据被读懂"之间隔着五到十年——而你今天的选择,决定的是十年后的那一天。
加密为什么安全?答案不是"复杂",而是"时间"
要理解量子威胁,必须先把"加密"这件事拆到不能再拆的原子层。 我们要问的不是"用了什么算法",而是"这个算法的安全性,最终建立在什么之上?"
1.1 第一问:什么叫"安全"?
如果我告诉你,任何加密都可以被暴力破解——只要一个一个试完所有可能的钥匙——那你还认为加密是安全的吗?
是的,任何加密理论上都可以被暴力破解。所以密码学从来没有承诺"不可破解", 它承诺的是另一件事:"破解所需的时间成本,超过了这份数据的价值周期。"
加密(Encryption):把可读的明文(Plaintext)按某个算法与密钥(Key)转换为不可读的密文(Ciphertext), 使得没有正确密钥的人,要还原明文所需的计算量,在实际工程意义上不可行(computationally infeasible)。
请把注意力放在最后半句:安全性的落脚点是"计算不可行"——一个关于时间和算力的经济学判断, 而不是一个关于"绝对不可能"的物理断言。
加密不是一堵墙,而是一个"迷宫收费站"。 任何人都可以走进迷宫,但走出来平均需要 300 万亿年。 我们说"这是安全的",意思是:宇宙的年龄只有 138 亿年,而你要走 2 万多个宇宙的年龄。 ——这就是 RSA-2048 面对今天最强超级计算机的处境(约 300 万亿年,超过宇宙年龄的 2 万倍)。
而量子计算做的事,不是"跑得更快",而是"把迷宫的墙拆掉,直接看见出口"。这是本质区别,第二章会展开。
1.2 第二问:现代密码学的四大职能是什么?
很多人把"加密"等同于"保密"。这是一个代价高昂的简化。现代密码学同时承担四项互不相同的职能—— 而量子计算对它们的冲击程度完全不同。这个区分,将直接决定后面所有的技术选型与迁移优先级。
机密性 Confidentiality
只有目标接收方能读懂内容。
典型实现:AES-256-GCM 加密数据载荷。
完整性 Integrity
内容在传输过程中没被篡改一个比特。
典型实现:SHA-384/512 哈希、GCM 的认证标签。
身份认证 Authentication
对面那台设备/那个人,确实是他声称的身份。
典型实现:RSA/ECDSA 数字证书。
不可否认 Non-Repudiation
发送方事后无法否认"这是我签的"。
典型实现:数字签名 + PKI 信任链。
记住这张图。因为后面你会看到一个惊人的事实:量子计算几乎完全放过了"机密性"的执行者(AES), 却精准打击了"身份认证"和"密钥交换"的执行者(RSA / ECC / DH)。
1.3 第三问:为什么会有"两种"加密?
如果对称加密又快又强,为什么还需要发明又慢又复杂的非对称加密?
因为对称加密有一个绕不过去的死结:双方必须先拥有同一把钥匙。 可如果你们还没有安全通道,你要怎么把钥匙安全地送过去? 这就是密码学史上著名的"密钥分发问题(Key Distribution Problem)"。
- 一把钥匙,加解密同用。
- 快——基于替换(Substitution)与置换(Permutation)等高度非线性的简单运算,适合大流量批量加密。
- 典型密钥长度:80 ~ 256 bit。
- 代表算法:AES-256-GCM、3DES。
- 死结:如何把这把钥匙安全送到对面?
- 密钥泄露后,所有历史数据需重新加密。
- 一对钥匙:公钥可公开,私钥绝不外传。
- 公钥加密的,只有私钥能解;私钥签名的,公钥可验证。
- 慢——依赖大整数模幂、椭圆曲线点乘等复杂数学运算,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 份黄。
三大主流公钥算法,用的是三个不同的"颜料桶":
| 算法 | 正向运算(容易) | 反向难题(困难) | 陷门(私钥的作用) |
|---|---|---|---|
| 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) | 标量乘法与点减法 |
图 1-1 陷门函数:安全性 = "反向计算的时间成本"。量子计算改变的正是这个红色箭头的成本。
1.5 把 RSA 拆到只剩算术:一个 5 分钟就能手算完的例子
抽象讲一万遍不如亲手算一遍。下面用一个刻意选到极小的例子,把 RSA 完整跑通。 请特别注意最后一步——它会直接告诉你量子计算机要攻击的是哪个环节。
- 随机选两个质数:p = 11,q = 3 这两个数是绝密的(私钥材料)。真实场景中它们各有 1024 bit。
- 计算模数:n = p × q = 11 × 3 = 33 n 是公钥的一部分,可以公开。
- 计算欧拉函数:φ(n) = (p−1)(q−1) = 10 × 2 = 20 这是"陷门"的核心——只有知道 p、q 的人才能算出它。
- 选公钥指数:e = 3(须与 φ(n) 互质) 工程上常取费马素数 65537(二进制 10000000000000001,只有两个 1,硬件运算极快)。
- 求私钥:d = e⁻¹ mod φ(n) → 3 × d ≡ 1 (mod 20) → 3 × 7 = 21 ≡ 1 (mod 20) → d = 7 公钥 = (n=33, e=3) 私钥 = (d=7)
- 加密(用公钥):明文 m = 2 → c = mᵉ mod n = 2³ mod 33 = 8 Alice 把 8 发到公网上。任何人都能看到 8、33、3。
- 解密(用私钥):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)都分为两个阶段:
图 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 束手无策?
这需要我们进入量子力学——但不用担心,我们依然只用第一性原理和类比,不写一个薛定谔方程。
加密的安全从不建立在"复杂"之上,而建立在"反向计算需要多少时间"之上——而量子计算,重新定义了时间。
量子计算凭什么撬开这把锁?——它不是更快,而是完全不同
关于量子计算,市面上流传最广、也最有害的一个说法是:"它比经典计算机快一亿倍。" 这句话不算错,但它会把你导向完全错误的结论。 如果量子计算只是"更快",那我们只需把 RSA-2048 升级到 RSA-8192 就万事大吉了。 现实是:这么做几乎没有意义。要理解为什么,我们必须先问一个看起来很笨的问题。
2.1 第一问:把经典计算机加速一亿倍,就等于量子计算机吗?
假设我给你一台运算速度是今天全球最强超算一亿倍的经典计算机。你能破解 RSA-2048 吗?
算一下:经典超算需要约 300 万亿年。快一亿倍 → 300 万年。
还是不行。
再快一亿倍呢?→ 0.03 年,约 11 天。看起来可行了?
但只要把密钥从 2048 bit 加到 4096 bit,破解时间就会重新回到天文数字。
因为质因数分解的难度是指数级增长的,而你的算力只是线性增长。
你永远追不上。
这就是关键洞察:单纯"变快"永远打不赢指数级难题。要赢,你必须换一种解题方式。
想象一个巨大的迷宫,出口只有一个。
经典计算机是一个跑得飞快的人:他一条路一条路地试,跑错了就退回来换一条。你把他的速度提高一亿倍,他还是一次只能待在一条路上。
量子计算机做的事完全不同:它把水灌进整个迷宫。所有路径同时被"探索",然后通过巧妙的物理干涉,让通向出口的那条水路"变亮",其余路径互相抵消。
差别不在腿的速度,而在"同时身处多少条路上"。这就是叠加(Superposition)。
2.2 四个原子概念:量子计算的全部秘密
我们不需要薛定谔方程。理解量子威胁只需要四个概念,而且每一个都有精确的日常类比。
量子比特(Qubit):信息的基本单位,与经典比特一样只有 |0⟩ 与 |1⟩ 两个可测量的基态, 但它遵循量子力学而非经典物理的规则。物理实现可以是超导电路、囚禁离子、光子等—— 它的威力不来自物理载体,而来自它所展现的量子性质。
经典比特在任一时刻必须是 0 或 1。量子比特可以处于两者的线性组合状态:
| 数学表达 | 含义 |
|---|---|
|ψ⟩ = α|0⟩ + β|1⟩ |
α、β 称为振幅(Amplitude),是复数 |
P(0) = α² , P(1) = β² |
概率 = 振幅的平方——这是全章最重要的一个等式 |
α² + β² = 1 |
所有可能结果的概率之和必须等于 1 |
表 2-1 量子态的三行数学。请牢记 概率 = 振幅²,2.4 节会用它解释一切。
一枚旋转中的硬币。
它落地前,问它"是正面还是反面"是没有意义的——它处于"既是正面、又是反面"的旋转态。
但你一伸手把它拍住(测量),它立刻变成一个确定的正面或反面,旋转态永久消失。
这个"拍住"的动作,术语叫"波函数坍缩(Collapse)"。它是量子计算最大的约束——也是所有算法设计的核心难点。
图 2-1 经典比特与量子比特的根本分野。右侧红框提示了量子计算最大的工程约束:测量即坍缩。
纠缠(Entanglement):两个或多个量子比特被关联起来, 使得其中一个的状态会直接决定另一个的状态,无论它们相距多远。 这是已被实验反复验证的物理现象,也是量子信息科学的核心。
一双手套,分装在两个不透明的盒子里,寄往地球两端。
你打开自己那个,发现是左手 —— 你瞬间就知道地球另一端那个必然是右手。
这个类比不完美(经典关联也能做到),但它抓住了工程上最重要的那一点:
纠缠之后,多个量子比特的"命运"被绑定在一起,不能再分别描述。
为什么这很重要?因为量子纠错(QEC)、逻辑量子比特、以及跨芯片的分布式量子计算(DQC), 全都建立在纠缠之上。它是把"小机器拼成大机器"的胶水。
这是最容易被忽略、却最决定性的一个概念。因为它回答了一个致命的追问:
既然量子比特"同时算出了所有答案",那我们不就直接读出来吗?为什么还需要设计复杂的量子算法?
因为测量会坍缩。10 个量子比特承载了 1024 个状态,但你一测量,
只会随机得到其中 1 个——而且是按概率随机的。
如果 1024 个答案的概率都是 1/1024,那你读出来的就是一个纯随机数,毫无用处。
所以量子算法真正的工作,不是"算出答案",而是"在测量之前,把正确答案的概率推到接近 100%"。
把量子计算想成"降噪耳机"。
降噪耳机的原理是:产生一个与噪音反相 180° 的声波,两者叠加后互相抵消——这叫破坏性干涉(Destructive Interference)。
而同相的声波叠加会变得更响——这叫建设性干涉(Constructive Interference)。
量子算法工程师就是"声学调音师":他精心排布量子门, 让所有错误答案的振幅互相抵消(变静音),让正确答案的振幅叠加放大(变响亮)。 测量时,你听到的自然就是那个被放大的正确答案。
实现这一切的工具,是量子门(Quantum Gate)——它操作振幅 θ 与相位 Φ, 并且输入与输出的量子比特数量永远相等(与经典门不同)。几个关键门:
2.3 量子并行性:2ⁿ 的暴力美学
现在把叠加与纠缠合起来看。n 个量子比特可同时承载 2ⁿ 个状态。 这个指数不是修辞,它的增长速度会击穿你的直觉:
| 量子比特数 | 可同时承载的状态数 | 现实参照 |
|---|---|---|
| 1 | 2¹ = 2 | — |
| 3 | 2³ = 8 | — |
| 10 | 2¹⁰ = 1,024 | — |
| 20 | 2²⁰ = 1,048,576 | 约一百万 |
| 127 | 2¹²⁷ ≈ 1.7 × 10³⁸ | IBM Eagle(2021)。该机比经典对手快约 1.58 亿倍: 同一任务经典机需 2,500 年,它需 1 分钟 |
| 275 | 2²⁷⁵ ≈ 10⁸² | ≈ 宇宙中原子总数 |
| 1,121 | 2¹¹²¹ ≈ 10³³⁷ | IBM Condor(2023)——已远超任何物理类比 |
表 2-2 量子并行性的指数曲线。请注意:状态数多 ≠ 有用——见 2.4 节的 Grover 实例。
2.4 眼见为实:Grover 算法的"振幅放大"四轮
为了让"干涉管理"从抽象变具体,我们看一个 4 量子比特(16 个状态)的搜索实例。
目标:在 16 个位置中找出唯一的正确答案(假设是 |1010⟩)。
图 2-2 Grover 算法的振幅放大。量子算法的本质不是"算出答案",而是"把正确答案的概率推高到可测量"。
2.5 第二问:三种加速的分野——为什么 RSA 死了,AES 活了?
现在我们抵达本章的核心。量子算法带来的加速不是只有一种, 而这个差异,直接把整个密码学世界劈成了"生"与"死"两半。
图 2-3 三种加速曲线的分野。这张图解释了后量子迁移的全部优先级逻辑。
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 算法把 N 次搜索降为 √N 次。对 256 bit 密钥(N = 2²⁵⁶)而言, 这意味着攻击者需要 √(2²⁵⁶) = 2¹²⁸ 次迭代。听起来"折半"了,很吓人。 但让我们老老实实把这个数算出来。
- 2¹²⁸ ≈ 3.4 × 10³⁸ 次迭代 即 340,000,000,000,000,000,000,000,000,000,000,000,000 次
- 假设每次迭代只需 1 微秒(10⁻⁶ 秒)——这是极其乐观的假设 真实量子门操作 + 纠错开销要慢得多
- 总耗时 = 3.4 × 10³⁸ × 10⁻⁶ = 3.4 × 10³² 秒
- 换算为年:3.4 × 10³² ÷ 3.15 × 10⁷ ≈ 1.1 × 10²⁵ 年
- 宇宙年龄 ≈ 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 时间的关键杠杆。而它正在以令人不安的速度改善:
| 时间 | 机构 | 物理 : 逻辑 | 比率 |
|---|---|---|---|
| 早期理论估计 | — | 10,000 : 1 | 10,000× |
| 2023 年 3 月 | 49 : 1 | 49× | |
| 2023 年 12 月 | Harvard | 48 : 1 | 48× |
| 2024 年 2 月 | IBM | 288 : 12 | ≈ 24× |
| 2024 年 4 月 | Microsoft + Quantinuum | 30 : 4 | ≈ 7.5× |
表 2-4 QEC 编码效率的演进。从 10,000× 到 7.5× ——三个数量级的改善,全部发生在最近两年内。
图 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:
图 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,我们凭什么现在行动?
业界最权威的三个预测口径,给出的答案并不一致——但它们的结论方向完全一致:
如果连专家都只能给出"10 到 15 年"这样宽泛的区间,那"现在行动"是不是过度反应?
恰恰相反。这个不确定性本身,就是必须现在行动的理由。下面三条,每一条都独立成立:
HNDL 已经在发生
不需要等 Q-Day。攻击者今天就在归档你的流量。 你要保护的不是"未来的数据",而是此刻正在链路上流动的数据——那是唯一无法追溯修补的东西。
设备生命周期 5–10 年
网络设备一旦上架,通常服役 5 到 10 年。 你今天采购的路由器,必须能撑过 Q-Day。 若采购时没有 PQC 能力与硬件加速,届时唯一的选项是紧急全网硬件更换——成本与风险都不可控。
迁移本身耗时数年
密码资产盘点、供应商评估、硬件刷新、软件升级、互操作验证、合规审计—— 大型企业的完整迁移周期通常是 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 更隐蔽、更致命的攻击面。
量子计算的杀伤力不在于它有多少个量子比特,而在于它换了一种解题方式——所以"把密钥加长"这条路,从第一天起就是死路。
把"紧迫感"变成一个不等式——以及三个比 HNDL 更可怕的攻击面
到目前为止,我们说了很多"必须现在行动"。但在董事会上,"必须"是一个很弱的词。
CFO 会问:"凭什么是现在,而不是三年后?"
本章的目标有两个:把这份紧迫感压缩成一个三变量的不等式;
然后告诉你——真正的威胁远不止"数据被解密"这一种,而另外两种,比 HNDL 更快、更狠、更难修补。
3.1 第一问:如何判断我的组织"已经"处于危险中?
在 Q-Day 到来之前,"我们还有多少时间"这个问题,真的只取决于量子计算机什么时候出现吗?
不是。它取决于三个数字的关系:
① 你的数据需要保密多久;
② 你完成迁移需要多久;
③ Q-Day 距离现在多久。
如果 ① + ② 已经超过了 ③,那么你不是"未来会有风险"——你是此刻正在制造未来必然泄露的数据。
这个判断被 Michele Mosca 教授形式化为一个极其简洁的不等式。 它是整个后量子风险管理领域唯一一条可以写在便签上的公式。
a + b > c
Mosca 定理(Mosca's Theorem):若"数据保密期"加上"迁移所需时间", 超过了"CRQC 出现所需时间",则风险已经实质发生,必须立即启动转型。
把它想成"给一封信选信封"。
c = 一种新型透视眼镜将在 6 年后上市。
b = 你需要 3 年才能换用防透视的新信封。
a = 这封信的内容必须保密 10 年。
那么在未来 3 年里,你寄出的每一封信,都是用旧信封装的,而它们要保密到第 13 年—— 其中第 6 到第 13 年这 7 年,全都暴露在透视眼镜之下。 你今天投进邮筒的每一封信,都在为 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 算法攻破的不只是"密钥交换",它同时攻破了数字签名——
而数字签名撑起的,是整个网络的身份体系和信任根。
"加密保护机密性,但认证保护身份。"——如果身份可以被伪造,那么再强的加密都只是为攻击者服务的加密。
图 3-2 量子威胁的三层攻击面。后两层几乎从未出现在主流讨论中——却恰恰是 CNSA 2.0 优先级最高的部分。
3.3 逐层解剖:三个攻击面的真实杀伤链
Cisco《Quantum-Ready Migration Guide》把这称为"最直接且最阴险的威胁(most immediate and insidious)"。 攻击者正在跨全球 WAN 链路,从高价值目标处截获并归档 PB 级加密流量。
杀伤链(两个阶段,中间隔着数年):
- 【今天】被动监听 WAN 链路,完整录制 IKEv2 / TLS 握手包 + 后续加密载荷 不需要突破任何防线,也不产生任何异常告警——因为这只是"看"
- 【今天】按目标、时间、协议归档入库,形成"时间胶囊" 存储成本是唯一投入,而存储成本正在逐年下降
- 【Q-Day】对归档的握手包运行 Shor 算法,从公钥反推私钥 指数级加速,分钟到小时级完成
- 【Q-Day】重建会话密钥(Session Key) 此时 AES-256 完好无损,但它的钥匙已经在攻击者手里
- 【Q-Day】追溯性解密数年历史流量 知识产权、国家机密、个人信息全部暴露
Cisco 的原文警告值得逐字读一遍: "如果你的数据具有 10 年以上的保密周期,那么它今天通过传统 IPsec VPN 传输时就已经被攻破了(it is already compromised)。 推迟实施 PQC 这个决定,等同于主动放弃你当前通信的长期机密性。"
这是本章最需要你重新校准认知的部分。 今天用于 VPN 隧道建立、BGP 路由更新、管理访问的数字签名(RSA / ECDSA), 全部暴露在 Shor 算法之下。而签名被破意味着两件事:
身份伪造 Identity Forgery
攻击者可伪造用于标识网络对端的数字签名, 从而冒充一个可信的 Hub、一台管理服务器、或任意一个端点。 在协议层面,它"就是"那台设备。
控制平面劫持 Control Plane Hijacking
认证被破后,攻击者可向路由表注入恶意路由, 或直接建立"可信"隧道进入网络核心—— 绕过所有边界防御,且不触发任何传统告警(without triggering a single classical alarm)。
HNDL 像是偷走了公司过去十年的会议录音。糟糕,但已经发生的事无法改变。
认证崩塌像是伪造了 CEO 的身份证、笔迹和门禁卡。
他现在可以走进任何会议室,签署任何文件,指挥任何人——而所有人都会照办,因为"证件是真的"。
更可怕的是:门禁系统的日志里,写的是"CEO 已授权进入"。你的 SIEM 不会报警,因为一切"合规"。
既然认证崩塌这么可怕,为什么它反而不需要"提前防御"?——它不是要等 Q-Day 才生效吗?
问对了,但答案分两半,而第二半才是关键。
对于"通信中的签名"(VPN 认证、TLS 证书):是的,它没有 HNDL 那种"追溯"效应——
攻击者无法用未来的能力伪造一份过去的签名并让它生效。所以理论上可以晚一点换。
但对于"设备与固件的签名"(下一个攻击面):完全相反。
因为那些签名验证密钥,是在设备出厂时烧进硅片的——而硅片不能远程升级。
量子威胁不止存在于软件层,它延伸到设备最底层的地基。 如果启动流程没有被量子安全签名保护,整条硬件信任链就是断裂的。 Cisco 明确列出了三种后果:
恶意代码注入
攻击者可在启动序列中注入恶意代码。 这些代码运行在比操作系统更深的层级, 因此对标准安全监控工具完全不可见,同时提供持久化的高权限访问。
假冒硬件与软件
缺少量子安全的硬件信任根,攻击者可推送带恶意载荷的"官方"固件更新, 或在供应链中植入假冒元器件——两者都能绕过传统完整性检查。
持久化后门
攻击者可建立属于他自己、而非组织的"信任根"。 此后设备被永久攻陷——任何软件补丁都无法移除一个被"合法"启动流程验证通过的后门。
这解释了一个乍看反直觉的事实: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 如何为每一项提供量子安全版本。
把三个攻击面并排对照,优先级逻辑会立刻自明:
| 对比维度 | ① 机密性崩塌 | ② 认证崩塌 | ③ 信任根崩塌 |
|---|---|---|---|
| 攻击对象 | 加密数据流 | 数字签名 / 控制平面 | 启动链 / 硬件身份 |
| 需要等 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)。 分级的依据是三个维度的交叉:数据敏感度与保留期、业务关键性、当前加密用法与升级约束。
最高 存在直接量子脆弱性的关键基础设施 核心 WAN 骨干、数据中心互联(DCI)、跨境专线、VPN 汇聚 Hub、管理平面(SSH / TLS)。 这些链路承载全公司流量,且直接使用 RSA / DH / ECDH 做密钥交换。 → 立即行动。这里就是 HNDL 的主猎场。
高 嵌入了密码学的业务关键用途 核心交易系统、支付网关、身份认证服务(RADIUS / TACACS+ / LDAPS)、PKI 证书颁发机构。 特点是密码学被深度嵌入应用逻辑,改动需要应用侧配合。 → 近期规划,同步启动供应商沟通。
中 具有长期机密性要求的数据 知识产权归档、临床试验数据、法务档案、长期客户 PII。 这些数据的 a 值极大(15–25 年),即使当前流量不多,也必然越过 Mosca 不等式。 → 优先处理其传输与备份链路。
低 仅有短生命周期密码需求的系统 会话级临时凭证、短周期营销数据、开发测试环境、公开信息发布通道。 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 偷走你的过去,认证崩塌偷走你的现在,而信任根崩塌偷走设备的一生——只有最后一种,补丁永远救不回来。
换成什么?——NIST 六年竞赛、五大算法,与一台单核笔记本引发的警醒
前三章回答了"为什么"和"有多急"。现在进入最实际的问题:换成什么?
答案不是一个算法,而是一套五件套——因为我们要修补的是三个不同的攻击面,
而每个攻击面需要不同的数学工具。但在介绍它们之前,必须先讲一个失败的故事,
因为那个失败定义了整个迁移策略的形态。
4.1 第一问:既然量子破了 RSA,为什么不直接发明一个"更强的 RSA"?
如果 RSA 的问题是"质因数分解不够难",那我们能不能找一个更难的数学问题,用同样的方式造一个新 RSA?
方向对了,但"更难"是个陷阱。
我们需要的不是"对经典计算机更难",而是"对量子计算机也难"——
这是两个完全不同的要求。
Shor 算法的杀伤力来自一个特定的数学结构:周期性。任何能被转化为"求周期"的问题,都会被它撬开。
所以我们必须找到一类没有周期结构可供利用的难题。
而"哪些数学问题真的没有这种结构"——这个判断,谁也不敢一个人下。所以必须搞一场全球公开竞赛。
后量子密码学 PQC(Post-Quantum Cryptography): 研究运行在经典计算机上、但能抵抗量子计算机攻击的密码算法的学科。
请注意两个关键限定:
① 运行在经典计算机上——PQC 不需要量子硬件,你现有的路由器 CPU 就能跑(这与 QKD 有本质区别);
② 抵抗量子攻击——它们被分析为对经典与量子计算机都安全。
2016 年 12 月,NIST 启动了密码学史上最大规模的公开征集。 六年时间,全球学界与产业界共同参与,经历了一场极其残酷的淘汰。
图 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 第二问:为什么需要五个算法,而不是一个?
回顾第三章的三攻击面表格最后一行。答案已经在那里了: 三个攻击面对应三种不同的密码学职能,需要三类不同的算法; 再加上被"削弱但未攻破"的对称加密与哈希,共五件套。
替代 DH / ECDH
FIPS 203
替代 RSA / ECDSA
FIPS 204
替代 RSA / ECDSA
SP 800-208
算法不变
FIPS 197
算法不变
FIPS 180-4
图 4-2 五大算法与四大密码学职能的映射。蓝色 = 必须换算法(Shor 攻击面);绿色 = 只需加长密钥(Grover 攻击面)。
下面逐一精讲。请特别留意每个算法"为什么被选中"的理由——那里面藏着很多工程智慧。
全称:Module-Lattice-Based Key-Encapsulation Mechanism(基于模格的密钥封装机制)。 竞赛期原名 CRYSTALS-Kyber,NIST 标准化后正式改名为 ML-KEM。
它解决的问题:今天的密钥交换算法(如 ECDH)直接暴露在 Shor 算法之下。 ML-KEM 用于保护通信系统之间初始秘密的交换—— 这个环节是我们在第一章图 1-2 中标红的"阶段一",也是 HNDL 攻击的唯一入口。
NIST 选择它作为通用加密标准的理由: ① 使用相对较小的密钥,便于交换; ② 运行速度快,对大多数工作负载有利。
这两点在网络设备上尤其重要——第七章你会看到 Cisco 8000 系列如何用 SNP 硅片把这个优势放大到线速。
三档参数集(安全强度递增、性能递减):
| 参数集 | 封装公钥 | 密文 | IKEv2/IPsec SA 建立所需消息数 | CNSA 2.0 |
|---|---|---|---|---|
| 传统 DH / ECDH(对照) | — | — | 4 条 | 已弃用 |
| ML-KEM-512 | 800 B | 768 B | 6 条 | — |
| ML-KEM-768 | 1184 B | 1088 B | 6 条 | — |
| ML-KEM-1024 | 1568 B | 1568 B | 8 条 | 要求 |
表 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
全称:Module-Lattice-Based Digital Signature Algorithm(基于模格的数字签名算法)。 竞赛期原名 CRYSTALS-Dilithium。
它解决的问题:直接对应第三章的攻击面 ②(认证崩塌)。 一台 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 再用它验证应用镜像
全称:Leighton-Micali Signature(LMS,RFC 8554)/ eXtended Merkle Signature Scheme(XMSS,RFC 8391)。 两者都属于哈希签名方案(HBS · Hash-Based Signature)。
既然已经有了通用签名算法 ML-DSA,为什么固件签名要单独用一套 LMS?这不是增加复杂度吗?
NSA 在 CNSA 2.0 中明确给出了三条理由,每一条都很有说服力:
NIST 已完成标准化
在 CNSA 2.0 发布时(2022 年 9 月),LMS/XMSS 已经被 NIST 标准化很久了,而其他后量子签名尚未标准化。有现成标准就先用。
这个用例更为紧急
固件签名对应的正是第三章的攻击面 ③(信任根崩塌)——唯一一个无法靠软件补丁补救的攻击面。因此必须最先动手。
性能弱点在此场景影响最小
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——两者并存,各取所长。
这是五件套中唯一"算法完全不变"的一项。 CNSA 2.0 相对 CNSA 1.0 在对称密码部分的唯一变化,是把 SHA-512 加入了列表—— NSA 自己的措辞是"a modest change... that allows a bit more flexibility"(一处温和的变更,提供了一点额外灵活性)。
为什么它能幸免?第二章已经完整论证过,这里补充一个更本质的解释: 对称分组密码使用的替换(substitution)与置换(permutation)等运算是高度非线性的。 这些非线性组件使量子算法难以在输入与输出之间找到有用的关联关系—— 而那种关联,恰恰是破解加密的关键。
换句话说:AES 的数学结构本身,就对量子算法所针对的"特定困难问题"具有天然免疫力。 Shor 算法找不到周期可以利用;Grover 算法只能提供平方级加速,且难以并行。
GCM 模式的额外价值:AES-GCM-256 同时提供机密性、完整性与认证三重保障, 这也是为什么它被 CNSA 2.0 列为对称加密的必备保护措施。
哈希函数在安全体系中扮演关键角色,尤其是在数字签名与完整性校验中。 CNSA 2.0 要求所有密级均使用 SHA-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 的机制差异,是本节最有工程价值的部分。
图 4-3 DH 与 ML-KEM 的机制对比。核心差异:DH 是"对称的双向计算",ML-KEM 是"一方生成、一方封装、原方解封装"的三步流程。
| 对比维度 | Diffie-Hellman / ECDH | ML-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 与业界节点)
NSA 依据 2022 年白宫行政命令(EO)与 NSM-10 发布 CNSA 2.0,公布算法选择与迁移时间表。此时 NIST PQC 标准尚未定稿——NSA 主动前瞻发布,目的是让厂商提前构建、让采购官员与系统所有者知道要求是什么。
FIPS 203(ML-KEM)、FIPS 204(ML-DSA)、FIPS 205(SLH-DSA)发布,成为新密码标准的基础。同时 SP 800-208(LMS/XMSS)已在此前完成标准化。
PQC 镜像签名与验证的优先采用日期。Cisco 官方给出的对应节点同为 CY 2025。
Cisco 计划在2026 年底前,为其核心产品组合的大部分实现量子安全通信与量子安全产品能力——提前于监管截止日期。
所有新的国家安全系统采购必须符合 CNSA 2.0。这是采购环节最硬的一条红线——它意味着 2026 年做出的选型决策,直接决定 2027 年能否交付。
无法支持 CNSA 2.0 的所有设备与服务必须全部淘汰。NSS 需在此日期前完成设备转换。软件固件签名与传统网络设备均需在此时进入 CNSA 2.0 独占状态。
CNSA 2.0 算法进入强制使用阶段。Cisco 白皮书亦引用 CSfC 项目要求:PQC 认证加密在 2031 年 12 月前成为国家安全系统的强制要求。
剩余类别全部进入 CNSA 2.0 独占;定制应用与遗留设备必须已完成更新或替换。
依据 NSM-10,NSA 预期 NSS 向量子抗性算法的转型在 2035 年前全面完成。这也是多数国家(欧盟、英国、日本、韩国、台湾等)设定的终点年份。
图 4-4 CNSA 2.0 与全球关键合规节点整合时间线。2027 与 2030 是两个真正会影响今年采购决策的日期。
NSA 规定的五步执行方法
CNSA 2.0 并非只给日期,它还规定了转型的通用执行方法。 这五步对企业同样适用,只需把 NIAP 换成你自己的合规框架:
- NIAP 发布保护配置文件(Protection Profiles),明确产品须支持 CNSA 2.0 算法,符合 NIST 与其他标准组织的标准,并推动符合标准的密码设备开发。
- 所有新设备必须满足保护配置文件要求;旧设备必须在下一次更新时满足要求,以维持 NIAP 合规。
- 一旦经验证与测试的方案可用,即开始将 CNSA 2.0 算法作为首选配置选项。——注意这一步的措辞:不是"可用就切换",而是"可用就设为首选",允许混合共存。
- 由 NIAP 保护配置文件要求与 NSM-10 技术刷新要求,共同决定何时移除遗留算法支持。
- 此后,未定期刷新的遗留设备与软件将需要豁免(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 在其中扮演了标准共同作者的角色。
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 的设计初衷本身就是"多重密钥交换",即混合。
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 密钥协商
IETF Draft
PQ/T Hybrid Key Exchange with ML-KEM in SSH 将椭圆曲线与 ML-KEM 方案同时作为密钥交换方法,目标是构造出即使使用量子计算机也无法求解的离散算法问题
IETF Draft
Module-Lattice Key Exchange in SSH 定义 SSH 中的模格密钥交换
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 月,全球后量子转型已从理论规划进入积极执行阶段。 以下是十个走在最前面的国家与地区:
- 2027新国家安全系统(NSS)采购须具量子抗性
- 2030NSS 设备转型须于 12 月 31 日前完成
- 2035强制使用 NIST 批准算法
- 2026年底前所有成员国应已启动转型规划
- 2030年底前完成高风险用例的 PQC 转型
- 2035年底前完成中风险用例的 PQC 转型
- 2027年底前识别需升级的密码服务并制定迁移计划
- 2031年底前执行高优先级升级,并随 PQC 演进优化计划
- 2035年底前完成所有系统、服务与产品的 PQC 迁移
- 2026年底前组织须制定细化的 PQC 转型计划
- 2028预期开始关键系统迁移
- 2030年底前停止使用量子脆弱的非对称算法
- 2027密码资产盘点、试点与混合部署、标准细化(CRYPTREC 更新)
- 2030关键系统迁移,政府强制力加强
- 2035完成 PQC 全面转型(政府 + 关键行业)
- 2027意识与指引阶段;HKMA 向银行发出建议,OGCIO 监测与技术更新
- 2032PQC 迁移指引、行业专项预期
- 2035(预计)银行与政府系统强制采用 PQC
- 2027关键信息基础设施(CII)应用启动 PQC 迁移;国防、电力、电信等 CII 行业完成基础建设
- 2028常规企业完成基础建设;CII 行业进行高优先级迁移
- 2029CII 行业全面采用 PQC
- 2027风险评估与资产盘点、PQC 试点与混合部署、内部治理框架
- 2030标准与行业指引正式化,监管审查力度上升
- 2030+关键行业可能进入强制 PQC 迁移
- 2023政府已宣布分行业推进战略
- 2025-2028在公共行政、能源、医疗行业开展试点部署
- 2035全国范围转型目标年
- 2027五年 PQC 计划、产业采用、金融业指引发布
- 2032PQC 技术标准正式化、行业专项合规要求
- 2035政府系统、关键基础设施、金融机构强制采用 PQC
- CA加拿大 CCCS:
ITSM.40.00PQC 迁移路线图 - 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 的答案:一家同时在建设量子网络与防御量子攻击的公司
前四章我们完成了完整的推导:锁的原理 → 钥匙如何失效 → 有多急 → 换成什么。
现在进入落地环节。
而 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 的双引擎:研究与孵化
构建量子安全网络需要两个高度专业化的组织协同—— 一个负责"探索什么是可能的",一个负责"把可能变成可部署的"。
研究方向:复杂数学问题构造,包括:
- 格密码(Lattice-based)——ML-KEM / ML-DSA 的基础
- 编码密码(Code-based)——如 Classic McEliece 一类
- 哈希密码(Hash-based)——LMS / XMSS 的基础
这些方向的共同特征是:目前被认为对量子计算机而言是难解的(intractable)。
使命:通过识别并验证下一代算法,为"能抵御量子攻击的安全网络"打下地基。 该研究部门与全球学术机构合作,推进这一关键领域的最前沿能力。
产出量化:Cisco Research 已在全球产业界与高校间开展协作, 产出 30 余篇量子技术论文。
角色:将研究成果转化为能够预见并满足客户需求的基础技术。
投入方向:量子相关技术开发,包括:
- 量子安全密码算法与协议
- 量子安全网络(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 提供三条并行路径,构成一个完整的迁移谱系:
手工预共享密钥 IOS XE 17.11.1a 起
可用于任何 IKEv2 IPsec 场景
管理员在两端 IPsec 对等体上手工配置同一个 PPK, 设备将其混入 IKEv2 密钥派生流程(依 RFC 8784)。
优势:简单、部署快、无需额外基础设施。
局限:大规模网络中密钥管理负担极重;存在"密钥熵不足"与密钥暴露风险。
适用:小规模部署、快速验证、高价值点对点链路。
动态 PPK IOS XE 17.11.1a 起
支持 QKD / KMS / BYOK
通过 Cisco SKIP(Secure Key Integration Protocol) 从外部密钥源(QKD 设备、密钥管理系统)动态获取每次 IKEv2 执行的全新 PPK。
优势:每次协商都是新鲜高熵密钥;自动化密钥管理与轮换;可规模化。
局限:需引入外部密钥基础设施;QKD 需专用光纤且成本较高。
适用:数据中心互联(DCI)、少量高价值站点、政府与国防场景。
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 的核心。
图 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 配置唯一的差异—— 只有一行。这是"低门槛快速起步"的核心价值。
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
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
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)
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 密钥服务器, 对路由器来说接口完全一致——这就是加密敏捷性在密钥源层面的体现。
图 5-4 SKIP 五步流程。核心设计:实际预共享密钥从不穿越链路,链路上只有元数据 PPK-ID。量子计算机无法用一个 ID 推导出密钥本体。
密钥源必须满足的两条 SKIP 合规要求:
- 必须实现 SKIP 协议或 API(依 Cisco SKIP 规范)
- 必须使用带外同步机制,向加密器对(发起方与响应方)提供同一个 PPK
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
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 听起来像终极方案——用量子物理保护密钥,窃听会被立即发现。为什么 Cisco 反而把它列为"需谨慎评估"?
因为 QKD 有三个绕不开的工程现实,以及两个来自最权威监管机构的明确否定。
QKD 的真实优势
窃听者无法读取编码在量子态中的信息,且任何窃听尝试都会被发送方与接收方立即察觉。 已在 1000 公里距离上实现。安全性建立在物理定律而非计算假设之上。
QKD 的硬约束
需要直连(direct connection)——因为当前的光交换机会破坏量子效应。 这意味着必须专用光纤,无法穿越常规运营商网络。
Cisco 明确列出的六项部署前评估维度:
- 厂商协作:选择有能力与 Cisco 网络基础设施完成集成、测试与鉴定的 QKD 厂商
- 可扩展性评估:评估厂商的密钥同步技术在大规模企业部署下的表现
- 成本收益分析:评估总体拥有成本,含初始硬件投入与长期管理开销
- 安全责任划分:在这种"双盒方案(two-box solution)"架构中,清晰界定 QKD 厂商组件与 Cisco 设备之间的安全边界
- 标准演进:确定该方案如何适配原生 PQC 标准并维持加密敏捷性
- 法规合规:NSA 禁止 QKD 方案;德国联邦信息安全办公室(BSI)不推荐 QKD
QKD 像是在两栋大楼之间架一条专用气动管道传递纸条。 物理上极其安全——任何人打开管道都会被立刻发现。 但你没法给全球 3000 个分支机构都铺这样一条管道。
而原生 PQC 像是把纸条上的文字换成一种"就算被读到也解不开"的密码—— 它可以走任何现有邮路。这就是为什么 QKD 适合数据中心互联(少量高价值链路), 而 PQC 适合全网规模化。
BYOK:把密钥源的选择权交给客户。
Cisco 采取的策略是"Bring Your Own Key"—— 密钥源选项对客户完全开放,可依据自身环境、用例、成本约束、所需安全等级自行选择。 Cisco 设备支持 SKIP 接口,从任意合规密钥源获取密钥。
三类可选密钥源:
补充说明: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)、DMVPN。GETVPN 除外 |
| 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 关键字。
这一个关键字,就是加密敏捷性在配置层面的落点。
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—— 例如与你无法控制的企业外部设备对等时。
图 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 算法。
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 大公钥需分片
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
DMVPN 通过组合 mGRE + IPsec/IKEv2 + NHRP 实现大规模 IPsec VPN 部署。 PQC 应用在 IKEv2 层,确保动态 NHRP 注册与后续的 Spoke-to-Spoke 隧道 都以量子安全的会话密钥初始化。配置与标准 IKEv2 IPsec 完全一致。
FlexVPN
FlexVPN 原生构建于 IKEv2 之上,是 PQC 的天然归属。 可用单一一致的 PQC 策略覆盖站点到站点、远程接入、Hub-and-Spoke 全部拓扑。 通过模块化"Smart Default"配置目录,可在整个 fabric 上快速切换到量子安全标准。
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 加密套件——这条路径对无法部署证书体系的环境更实用。
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.
部署前务必核对平台支持矩阵。
| 平面 | 协议 | 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 年新采购红线。以下是两批交付清单。
IKEv2 IPsec · DMVPN · FlexVPN · SD-WAN IPsec · MACsec · SSH · TLS
IPsec · MACsec · SSH · TLS;TLS 1.3 更新覆盖:
RadSec · TACACS · LDAP
IKEv2 IPsec · MACsec · SSH · TLS
SSH
MACsec · SSH · TLS
TLS 与 MLS,覆盖 Webex App 与设备,支持端到端加密会议
TLS · DTLS · 认证能力(Authentication capabilities)
RadSec · TACACS · LDAP · CAPWAP · VxLAN
SSH · TLS* | Nexus Dashboard:SSH · TLS (HTTPS/API)* | ACI:SSH(设备访问)* · TLS(内外部通信)*
IPsec · SSH · TLS 解密(TLS Decryption)
IPsec
TLS · SSH · SFTP(混合模式)
RADIUS · EAP · TACACS · HTTPS(关键服务) · LDAPS · IPsec · SSH
表 5-5 Cisco 量子安全通信路线图。* 标注项为 2027 年 7/8 月,取决于软件发布排期。路线图可能变更,最后更新:2026 年 8 月 11 日。
| 产品线 | 计划产品 / 平台 |
|---|---|
| 企业路由(IOS-XE) | 新品发布:Cisco Secure Router 8131H、8151H-C、8211、8221、8221L、8225、8650;Cisco 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 这一个关键字,就是三千个站点零中断迁移的全部秘密。
刻在硅片里的信任根——为什么这是唯一补丁救不回来的东西
第五章我们把"量子安全通信"这根支柱完整落地了。
现在进入第二根:量子安全产品。
这一章会比前面更"硬"——我们要一路下沉到硅片、到主板上那颗物理芯片、
甚至下沉到 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 物理设备。 它将设备唯一身份与密码密钥存储在一个与主处理器和内存相隔离的、防篡改环境中。
TAm 提供两类价值:产品保障功能(Product Assurance)与 四项基础安全能力(Foundational Security Features)。 下面逐一解剖这四项能力。
X.509v3 证书,保存产品标识符(PID)与序列号。 在制造阶段实施,并链接到一个可公开识别的根证书颁发机构。
关键设计:SUDI 证书、其关联密钥对、以及整条证书链
全部存储于防篡改的 TAm 芯片内;密钥对与特定 TAm 芯片密码学绑定,
且私钥永不导出。
→ 这使克隆或伪造身份信息在实践上不可能。
为密钥、口令、客户凭据以及设备的其他关键安全信息提供高安全存储。
其优势之一:能够存储私有加密密钥与口令, 获得更高等级的安全性。亦可在 TAm 之外分配安全存储。
强随机数生成(RNG)是加密的核心;而弱 RNG 会摧毁整个加密体系。 RNG 在创建密钥、建立用户与网站间的高安全通信、以及重置邮箱口令中扮演关键角色。
没有可靠的随机性,攻击者就能预测系统将生成什么,从而破坏算法。
TAm 符合 NIST 规范,提供可通过 NIST SP 800-90A 与 800-90B 认证的 RNG,
从 TAm 内部的真随机源提取熵。
向运行中的操作系统与应用提供密钥管理与密码服务。
可生成客户自控证书的密钥对——即通常所说的 本地有效证书(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 代码。
这一个顺序的调换,就把信任的起点从"可写的闪存"移到了"不可写的硅片"。
图 6-2 Cisco 硬件锚定 Secure Boot 与信任链。注意底部红条:失败不是"报警后继续",而是"直接不让它跑"。
失败处理机制的关键设计(这一点区别于"仅告警"的方案):
如果 Cisco Secure Boot 逻辑执行的完整性检查失败——无论是硬件验证还是 Bootloader 验证—— 该状态会被提供给主机系统,以便采取适当措施,确保被攻陷的系统不具备功能, 例如将系统保持在复位状态,或禁用部分功能以阻碍其运行。
在 Cisco 8000 系列上,这一机制由 SNP(安全网络处理器)执行: 若设备在启动时检测到硬件修改或签名不匹配,SNP 将中止初始化流程, 阻止一台已被攻陷的设备加入生产网络。
经典 Secure Boot 使用 RSA / ECDSA 做签名验证——而这正是第三章攻击面 ③ 的入口。 量子安全 Secure Boot 的改造,就是把每一级的签名算法替换为量子抗性算法:
图 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)利用未受保护的总线连接。
换句话说:金库很安全,但从金库通往柜台的那条走廊,你有没有装监控?
图 6-4 CPU ↔ TAm 数据总线的量子安全加固。Cisco 通过对总线加密应用 ML-KEM 与 AES-GCM-256,确保连这条内部通信路径也针对量子威胁得到加固。
这就像银行不仅把现金放在金库里,还给"从金库推到柜台"的那辆推车加了装甲。
大多数人只会想到金库的门够不够厚。而真正的专业设计,会假设"内部走廊也可能有人"。
还有一层容易被漏掉:FPGA 配置比特流。 Cisco 使用 FPGA 实现多种系统功能,包括信任锚设计与数据面加密 FPGA。 在可能的情况下,Cisco 使用 256 位 AES 密钥加密这些器件的配置比特流—— 因为如果这一层被改写,上面所有密码学都成为空中楼阁。
6.5 镜像签名与运行时防御:信任链的两端
| 步骤 | 动作 | 产物与用途 |
|---|---|---|
| 第一步 | 使用哈希算法(类似校验和)计算该代码块的哈希值 | 唯一指纹。Cisco 采用 SHA512(SHA2 家族)以保守应对未来量子攻击 |
| 第二步 | 用 Cisco 私钥加密该哈希 | 得到数字签名,随镜像一同附加并交付。签名镜像可在运行时被校验,验证软件未被修改 |
表 6-1 镜像签名两步流程。这就是你在 cisco.com 下载页面看到 SHA512 校验值的原因——它让你在加载到虚拟机前可手工验证完整性。
三项由此获得的保障:
- 帮助确保固件、BIOS 与其他软件是真实且未被修改的
- 提供关键检查,使只有正版、未修改的软件能在 Cisco 设备上启动
- 有效缓解持久化攻击(persistent attacks)
执行时序非常重要:该流程使用 TAm 中安装的 X.509 SUDI 证书, 验证 Cisco 硬件是真实的(由 Cisco 制造)。 硬件真实性检查仅在 Secure Boot 流程完成、且软件已被验证为可信之后才运行。
为什么是这个顺序?因为如果软件本身不可信,那么"由软件报告的硬件检查结果"也不可信。 必须先确立软件可信,才能相信它对硬件的判断。这是一个极其严谨的逻辑排序。
Secure Boot 保护的是"启动那一刻"。但系统运行起来之后呢? 运行时防御针对的是向运行中的软件注入恶意代码的攻击。 Cisco 的运行时防御包含三项,它们是互补的(complementary)——可单独实施,也可多项协同部署:
ASLR
地址空间布局随机化
Address Space Layout Randomization
每次运行时随机化内存布局,使攻击者无法预测关键代码与数据的地址,
令针对固定地址的漏洞利用失效。
BOSC
内置对象大小检查
Built-in Object Size Checking
在运行时校验对象大小,阻断缓冲区溢出这一类最经典的代码注入路径。
X-space
可执行空间保护
将数据区域标记为不可执行, 使被注入到数据区的恶意载荷无法被 CPU 当作指令运行。
补充:运行时完整性(Runtime Integrity)—— 诸如 IMA(Integrity Measurement Architecture,完整性度量架构) 的技术依赖密码学验证,确保设备在运行期间持续处于可信状态。
而这正是第三章表 3-2 中列出的量子暴露面之一: 若缺少量子安全算法,运行时完整性检查可被绕过或伪造。
6.6 第三问:Cisco 是什么时候开始做这件事的?
NIST 的 PQC 竞赛 2016 年才启动,标准 2024 年才发布。那在此之前,有没有人已经在生产设备里跑量子安全签名了?
有。而且比竞赛启动还早三年。
LDWM 是一种哈希签名方案(HBS),基于 Lamport、Diffie、Winternitz、Merkle
数十年前开创的研究。Cisco 将其用于在加载软件镜像或固件前进行验证。
具体参数:SHA256 哈希、Winternitz 参数 W=4、树高 H=10。
LDWM 也存在于多个服务提供商平台的 FPGA 实现的 Cisco 信任锚模块中。
Cisco 自 2013 年起,即在 Catalyst 9000 系列交换机上使用 LDWM 哈希签名提供量子安全 Secure Boot。 ——这意味着当业界还在讨论"量子威胁是不是科幻"的时候,Cisco 的量子安全签名已经在客户机房里跑了。
Call for Nominations 发布——比 Cisco 的 LDWM 生产部署晚了三年。
David McGrew、Scott Fluhrer、Michael Curcio 共同撰写了 LMS 标准(RFC 8554)——
一种有状态 HBS 方案,是 LDWM 的演进版本。
LMS 在 LDWM 基础上,采纳了 Leighton 与 Micali 在 1995 年发表工作中的思想,
并引入了提供域分离(domain separation)的特定参数。
这项工作随后扩展到量子安全网络传输协议, 特别是通过 SKIP(2017 年开发)实现 QKD 集成。
新的硬件路线图将切换到 LMS 等更具后量子特性的镜像签名方案。 Cisco 明确表示:LDWM 与 LMS 签名方案将继续被集成到更多平台中; Ubiquitous PQ Trust Anchors(无处不在的后量子信任锚)是 Cisco 的目标。
图 6-5 Cisco 量子安全信任锚的时间线。关键洞察:因为信任锚被内建在设备中,且被刻意设计成难以更新,所以它必须"提前很多年"就做对。
Cisco 官方对"为什么必须这么早动手"的解释,是整章最重要的一句话:
"即使这样的大规模量子计算机预计在一段时间内还不会存在, 信任锚被内建在 Cisco 设备中,并且是被刻意设计成难以更新的(deliberately hard to update)。"
这就是第三章"补丁救不回来"的正面表述: 难以更新既是它安全的原因,也是它必须提前正确的原因。
实现直接、代码体积极小
Cisco 选择 HBS 是因为其实现直接(straightforward implementation)与最小的代码体积(minimal code size)——这对 Microloader 这种必须塞进硅片的场景至关重要。
本质被充分理解
它们的well-understood nature——基于数十年公开研究,密码分析历史最长。这也是 NSA 在 CNSA 2.0 中给出的三条理由之一。
基础原语简单
建立在简单原语(simple primitives)之上——安全性等同于哈希函数本身的强度,无需引入新的数学难题假设。
碰撞攻击天然无效
攻击者构造的哈希碰撞对 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)。
该计划在方案全生命周期内持续评估、监控与改进安全性。
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 之后,性能会掉多少?
信任锚被刻意设计成难以更新——难以更新是它安全的原因,也正是它必须在出厂那一刻就已经是量子安全的原因。
打开机箱:为什么量子安全需要一颗全新的硅片?
前两章我们讲清了"能力":量子安全通信与量子安全产品。
但能力必须有载体。而这一章要回答一个所有 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 系列安全路由器的核心。它是专门构建的特化硅片, 用于承载下一代密码学的沉重计算需求,同时维持高性能路由。
线速 PQC 加速:SNP 提供处理 PQC 算法所需的专用硬件引擎, 不带来软件加密通常伴随的性能"税"。
统一安全处理:通过将安全功能直接集成到包处理路径中, SNP 确保深度包检测与 PQC 原生加密都以线速执行。
可编程微码(Programmable uCode)的价值常被低估: 它意味着新特性可以通过微码更新下发, 而不必等下一代硅片——这是硬件层面的加密敏捷性。
SNP 内建 AI/ML 引擎,与硬件包分发引擎、内联加密引擎、 集成流量管理器共同构成系统级芯片(System-on-chip)。
在 8300 / 8400 上,安全 AI/ML 具备"就绪卸载(Ready to offload)"能力—— 为未来 AI 驱动的安全分析预留了硅片级算力。
图 7-1 SNP 系统级芯片架构。注意 Trust Anchor 与 Crypto Engine 都在芯片内部——这正是第六章"总线加密"能被实现的物理前提。
7.3 三大构件:IOS XE、SNP、QFP
Cisco 8000 Series Secure Routers 建立在三块构件之上, 分支/园区侧与数据中心侧使用不同的转发引擎:
Cisco IOS XE
云原生操作系统。安全与网络融合、可编程性(本地 + 云)。
单一镜像 universalk9,可运行于
Autonomous 自治模式或 SD-WAN Controller 模式。
Secure Networking Processor
分支与园区转发引擎。 8400 / 8300 / 8200 Series Secure Routers 由 SNP 驱动, 具备可处理后量子密码算法的专用加密卸载引擎。
Quantum Flow Processor
数据中心转发引擎。第三代 QFP 提供 高性能、高扩展 ASIC,支撑 8500 / 8600 系列的超大规模转发。
896 个线程听起来像一个数字,但请这样想: 它相当于一条有 896 个工位的流水线,而且每个工位都能独立处理一个完整的包。
而"16 个加密引擎,各自拥有专用资源"这句话的分量在于"专用"二字—— 它意味着加密工位不需要排队等公共资源, 所以你在启用 PQC 之后,那 896 个转发工位的效率不受影响。
7.4 第二问:同一颗芯片,如何既擅长转发又擅长安全?
纯路由场景需要最大转发能力;启用了 NGFW + IPS + TLS 解密的场景则需要大量服务处理能力。同一颗硅片怎么可能两者都最优?
答案是:不试图"同时最优",而是"按意图动态划分"。
SNP / QFP 支持动态资源分配(Dynamic Resource Provisioning)——
根据你的部署意图,把核心资源在控制平面(CP)、包处理引擎(PPE)、
服务平面(SP)、接收与流量管理(Rx+TM)之间重新划分。
适用意图:路由 / SD-WAN 为主,追求最大转发与 IPsec 吞吐。
核心分配倾向 PPE——最大化并行包处理能力。
典型用例:MPLS CPE、Overlay VPN、SD-WAN AAR、Secure Networks(SRv6)。
适用意图:NGFW、TLS 解密、TCP 优化 / DRE、vDSP 等重服务场景。
核心分配倾向 SP——为深度检测与有状态服务预留算力。
典型用例:Secure Branch DIA/DCA(内建 Secure Firewall + IPS + URL-F + AMP)、AppQoE、语音。
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 内部究竟经历了什么。 这对故障排查与性能调优都有直接价值。
图 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 分类与限速 → uRPF → IPsec → NAT → Firewall → SSLVPN → Netflow → PBR / ACL → 转发(IP 单播负载均衡 / 组播 / MPLS 封装与解封装 / FRR / AToM)→ Marking / Policing / Accounting → TCP MSS 调整 → Queuing → 出接口。
这条链的长度正是"为什么需要 896 个线程"的原因—— 每个包都要跑一遍这条流水线,而且必须在线速内跑完。
7.6 IOS XE:单镜像、双模式、可编程
Autonomous 自治模式
传统 CLI / 自主管理。适用于 MPLS CPE、Overlay VPN、 Internet Gateway、Secure Networks(SRv6)等场景。简化部署。
SD-WAN Controller 模式
由 SD-WAN Manager 集中编排。 适用于需要应用感知路由(AAR)、集中策略、量子安全策略批量下发的场景。 加速 SD-WAN 部署。
universalk9 镜像,两种运行模式 —— 无需更换软件包| 层次 | 组成 | 价值 |
|---|---|---|
| 控制与管理层 | 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 的零接触部署与第六章的 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 受限的运营商网络而不被丢弃。
! ① 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 分片)。 这不是性能问题,是包装问题——但如果不处理,门根本打不开。
"标准化"的真正价值在于跨厂商互通。 Cisco 8000 系列与 Cloudflare WAN 的 PQC 互操作已完成实测验证:
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。
新增 10GE 铜口与 XGSPON WAN
新增 10GE 与 mGig WAN
4× 10GE 与 mGig 连接
新增 25GE WAN
扩展至 8M
相对上一代提升
图 7-3 相对上一代的性能跃升倍数。请注意 8300 的 10× 与威胁防护的 6×——这两个数字直接决定了"安全分支"能否与"纯路由分支"用同一台设备。
关键能力:所有端口支持线速 WAN MACsec, 搭载第三代 QFP。
| 型号 | 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 加速),逻辑就反过来了。
而且有第三方独立验证的数据支撑——这不是自我宣称。
图 7-4 NetSecOpen 独立认证结果。NetSecOpen 是可信的第三方评测组织,其认证报告可用于支撑部署决策,而非厂商自测数据。
| 能力域 | 功能 | 作用 |
|---|---|---|
| 下一代防火墙 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 状态, 同时保持高可用与关键业务零停机。
| 前置项 | 要求 | 不满足时的处理 |
|---|---|---|
| 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 的存在会直接决定你只能走方案二。
DMVPN Hub 热替换 基于冗余的滚动升级
适合机架空间受限环境
在既有拓扑内用 8000 系列安全路由器替换遗留 Hub。
利用 pqc optional 的向后兼容特性,使单台 Hub 能同时服务
遗留 Spoke 与已迁移的 PQC Spoke。
并行架构(PQC 孤岛) 绿地方案
风险规避型组织的推荐路径
在遗留网络旁新建一套 PQC 原生的 8000 系列 Hub 集群。 Spoke 按站点逐个迁移至新"孤岛", 通过 NNI(Network-to-Network Interface)维持两个环境之间的可达性。
图 7-5 DMVPN PQC 迁移两条路径对照。选择依据不是技术偏好,而是"你是否具备 Hub 冗余"与"你的风险容忍度"。
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 引流至备用 Hub。此时业务由备用 Hub 承载,主用 Hub 进入可操作窗口。
- 物理更换:用 Cisco 8000(G2)替换遗留 Hub。新 Hub 已预置上述
pqc optional配置。 - 验证遗留 Spoke 使用经典算法重新建立隧道。这一步验证的正是
optional的回退能力——第五章场景矩阵的第 2/3 号场景。 - 恢复流量均衡,然后对备用 Hub 重复上述流程。完成后两台 Hub 均为 PQC-ready,可开始按站点迁移 Spoke。
- NNI 桥接(The NNI Bridge):在遗留 Hub 集群与新的 8000 系列(G2)Hub 集群之间建立 Network-to-Network Interface。使用路由协议(如 BGP 或 EIGRP) 在已迁移与未迁移站点之间交换路由,以在迁移过程中维持通信。
-
WAN 传输共享(WAN Transport Sharing):最有效的方法是
将 DMVPN Hub 与传输电路同时接入一个中间的二层 WAN 传输层。
该架构通过让两代 Hub 同时驻留在同一条物理电路上、使用各自独立的公网 IP 构建独立隧道 Fabric,
实现"洁净室(clean-room)"迁移。
价值:借助这个中间交换机,Spoke 可以纯粹通过配置或边缘硬件更新完成迁移, 而数据中心侧的物理交接始终保持稳定 —— 零影响迁移。 -
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 sortedshow 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 statusshow processes cpu platform sorted | sec snort |
Snort 引擎数量、各引擎健康态(Green/Yellow/Red)、系统内存使用率、整体系统状态 |
表 7-7 关键资源监控命令速查。三个 SNMP MIB 应纳入常态化监控基线,而非等到故障才查。
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> - 关闭软件冗余
redundancy→mode none
QFP / 数据面 DRAM 告急
- 降低 NAT 最大条目数
ip nat translation max-entries <n>nat64 translation max-entries <n> - 降低防火墙会话上限
parameter-map type inspect global→session total <count> - 降低 Flexible NetFlow 缓存上限
flow monitor M1→cache entries <n>
图 7-6 资源耗尽缓解手册。这些是"在采购到货之前先撑住"的应急动作,不是长期方案。
Secure Firewall 健康检查的正确读法:
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 软件发布时直接启用,而不必再做一次硬件刷新。
下周一早上就能开始:一份可提交立项的迁移路线图
前七章我们完成了完整的技术推导。但技术从来不是迁移失败的原因。
真正的失败原因是:没有优先级、没有 CBoM、没有预算生命周期、
没有厂商问卷、没有可度量的进展报告。
本章不再讲原理,只讲"下周一你该做什么"。
8.1 第一问:三步走还是六步走?
如果只能记住三个词,哪三个?
Discovery(发现)→ Prioritization(优先级)→ Implementation(实施)。
Cisco 把它压缩成"3 Steps to crypto-agility":
① 审计密码技术(硬件与软件);② 从 WAN 开始识别量子脆弱点;
③ 规划、准备、采纳量子抗性算法。
但三步只适合向董事会讲故事。要真正执行,需要展开为六阶段。
图 8-1 后量子迁移六阶段方法论。注意底部虚线回环:这不是瀑布流程,而是随标准演进持续迭代的闭环。
8.2 阶段一:教育——为什么这一步不能跳过
目标:确保 IT、网络安全与领导层共同理解量子威胁及其对 WAN 基础设施与数据的影响。
三个必须同步认知的点:
- 威胁的时间性:HNDL 意味着"损失"发生在今天,而"暴露"发生在未来(第三章)
- 威胁的层次性:不只是数据被解密,还有认证崩塌与信任根崩塌(第三章)
- 解法的谱系性:不是"上了 ML-KEM 就完事",而是量子抗性 × 加密敏捷性(第五章)
组织保障:建立量子卓越中心(Quantum Center of Excellence)。
它的职责不是"技术攻关",而是推动跨职能对齐与内部专家培养。 因为迁移会同时触及网络、安全、应用、采购、合规、审计六个部门—— 没有一个跨职能的常设组织,这件事必然在部门墙上撞碎。
跳过教育阶段,等于让消防队在不知道"什么是可燃物"的前提下去演练。 他们会把水浇在最显眼的地方——而真正的火源(信任根、认证体系)无人问津。
本文本身,就是可以直接发给这三类人的教育材料。
8.3 阶段二:评估与优先级——CBoM 是唯一的地基
如果你的迁移计划里没有一份 CBoM,你怎么知道自己迁完了?
你不知道。这就是为什么"没有 CBoM 的迁移计划只是一份愿望清单"。
| 维度 | 内容 | 要求 |
|---|---|---|
| 覆盖资产 | 算法(Algorithms)· 密钥(Keys)· 协议(Protocols)· 证书(Certificates) | 特别标注所有非对称加密用法——那就是 Shor 算法的完整攻击面地图 |
| 覆盖环境 | 本地(on-premises)· 云 · IaaS · SaaS | 需记录全部管理协议、叠加 VPN 与密码资产 |
| 发现方法 | ① 代码分析工具 ② 网络流量分析 ③ 动态分析工具 |
工具化为主,避免依赖人工问卷(覆盖率与准确率均不可控) |
| 输出格式 | 机器可读格式,推荐 CycloneDX(OWASP) | 必须机器可读,否则无法支撑后续的自动化合规度量与漂移检测 |
表 8-1 CBoM 构建规格。"机器可读"这一条决定了阶段六(监控)是否可行——手工表格无法支撑持续合规。
评估密码资产的四个维度:
分级结果直接引用第三章的 Tier 1–4 优先级阶梯。 并叠加三个影响主题(Three Impact Themes)作为选型考量: 遗留与 EoL 系统 · 升级路径受限的系统 · PQ 使能软件对硬件的支持度。
| 能力 | 作用 |
|---|---|
| 平台级特性分析 | 分析信任锚、安全启动、安全存储等平台级特性 |
| 三平面密码分析 | 分析管理、控制、数据平面的加密敏捷性与通信协议 |
| 精确定位改造需求 | 识别出哪些资产需要硬件替换、软件升级、或特定特性激活才能达成量子安全状态 |
| 全球合规追踪 | 持续追踪组织对CNSA 2.0 及欧盟、英国、加拿大、澳大利亚、日本等效标准的合规进度 |
| 合规度量(未来能力) | 持续按行业强制标准(如 FIPS 203)度量网络状态,生成面向利益相关方的自动化合规报告 |
| 配置漂移检测(未来能力) | 主动识别被手工回退到非 PQC 状态的设备,确保安全态势不随时间退化 |
| 预测性分析(未来能力) | 通过分析加密流量健康度与 SNP 利用率,在性能瓶颈影响生产流量之前预测它 |
表 8-2 Cisco IQ 的发现审计与持续合规能力。"配置漂移检测"是最容易被低估的一项——它把"迁移完成"从一次性事件变成可持续验证的状态。
两种自动化评估路径(可组合使用):
① 配置与状态采集:采集 running-config 与 show 输出,
由 Cisco IQ 分析并给出发现项与建议。
例如:发现 crypto ikev2 proposal 中 group 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)。理由很朴素: 核心节点数量少(4–8 个 Hub),改造工作量可控; 而核心一旦 PQC-ready,就能立刻服务任何后续迁移的分支—— 反之若先改分支,它们找不到能对话的 PQC Hub。
图 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 阶段六:监控——量子安全是持续运营,不是一次性工程
迁移完成之后,这个项目就结束了吗?
不。因为有两件事会持续变化:标准会演进,配置会漂移。
量子演进里程碑
追踪量子硬件进展、量子纠错、分布式量子计算(DQC)。 第二章已证明:Q-Day 可被一篇论文单方面提前——所以监控不能只看硬件新闻。
标准演进
追踪 RFC、PQC 算法、监管截止日期。 并评估对你的战略的影响——必要时回到阶段 3 重新研究选项。
自身进展
追踪变更推进过程中的项目状态与合规度。 依托 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, 并叠加了本文各章的具体依据。
-
用 Cisco IQ 做一次量子风险审计。
发现当前环境中的量子脆弱热点;识别缺少线速 ML-KEM 所需 SNP 的遗留 ISR4K 与 ASR1K 资产。
→ 同时启动 CBoM 构建(表 8-1),产出机器可读的 CycloneDX 清单。 -
现代化硬件基座。
启动 Cisco 8000 Series Secure Routers 的采购与备货;
优先覆盖承载高价值数据、面临 HNDL 风险的站点。
→ 依据:硬件采购是关键路径,无法压缩(8.5 节);软件可等,硬件不能等(第七章)。 -
标准化到 IKEv2。
如果遗留 DMVPN 或站点到站点隧道仍在使用 IKEv1,今天就启动向 IKEv2 的过渡。
→ 这是实施 ML-KEM 等 PQC 算法的强制前提;也决定你能否走 Hot Swap 而非 Parallel Island(表 7-6)。 -
启用第一跳安全。
更新 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 的迁移计划只是一份愿望清单——而硬件采购是唯一无法被压缩的关键路径。
回到开头那个问题:你今天发出的数据包,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 批准的算法与硬件锚定的信任,
你不只是在更新一台路由器——你是在为组织数据的主权做未来防护。
面对量子威胁,沉默本身就是一个漏洞。主动现代化是唯一的防御。"
时间是单向的。你今天加密的每一个数据包,都在为十年后的那一天投票——而这一票,无法重投。
完整术语表
按主题分组。每个术语给出中英文、精准定义,以及在本文中首次出现的章节。
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 > c。a = 数据保密期;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 冗余,要求现网已是 IKEv2。Parallel 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 混合流量。相对上一代提升约 6×。
- 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
参考资料与延伸阅读
本文全部技术论断均来自以下一手资料。按类别分组,标注本文引用的核心章节。
标准与规范
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 / SSH;Module-Lattice Key Exchange in SSH;ML-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 InfrastructureWAN-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 2025RFC 8784 密钥派生数学、Manual/Dynamic PPK 完整 CLI 与 show 输出、四种协商场景、平台支持矩阵
数据手册
Cisco Trustworthy Technologies Data Sheet 六大技术清单:镜像签名、安全启动、TAm、信任链、硬件真实性检查、运行时防御
路线图
Cisco Quantum-Safe Communications Roadmap Last updated Aug 11, 20262026 年 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 Computerarxiv.org/abs/quant-ph/9508027
1996
Grover, L. A fast quantum mechanical algorithm for database searcharxiv.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.com/site/us/en/about/trust-center/post-quantum-cryptography
research.cisco.com/research-projects/quantum
cisco.com/site/us/en/products/networking/sdwan-routers/8000-secure-routers
cisco.com/c/en/us/td/docs/routers/ios/config/17-x/sec-vpn/b-security-vpn
提供文档、合规资源与平台完整性指引,用于验证 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。