常见问答|为什么混合部署是确保PQC迁移安全的关键?

我们希望这篇文章能够帮助我们初步提出关于后量子计算的加密保护、混合部署的采用以及遵循这种方法时需要考虑的事项的建议。

在上一篇文章《谷歌发布后量子密码学计划,距离PQC更进一步》中,Google的安全研究团队讨论了Google的后量子密码学威胁模型,以及它是如何推动我们对后量子密码(PQC)转换的应对措施,包括我们如何对风险进行优先排序。

此外,Google还分享了适应量子计算对您数据构成的风险的建议,其中一个建议是使用混合部署方法。

在本篇文章中,Google将讨论在后量子密码世界中采用混合部署的优势及其背后原因,并分享如何实施指导混合计划。

以下为原文,经公钥密码开放社区编译:

什么是混合部署?

在这个背景下,混合部署的概念相对简单明了。它是两种公钥算法的结合,这些算法来自:

·经典密码学:像ECDH或ECDSA这样我们目前依赖的算法。

·后量子密码学(PQC):一种专门设计用于抵抗量子计算机攻击的新算法。

混合算法同时采用两种算法,提供针对传统和潜在量子对手的分层防御。任何安全的混合结构都必须保证整个系统至少与混合算法中使用的最强算法一样安全。

换句话说:混合算法中的组合方案绝不能削弱各个底层加密算法的安全性。

混合结构的合理性

让我们深入探讨为什么混合结构在这个复杂的过渡时期中提供独特的优势:

(一)降低与新算法相关的风险

后量子算法虽然前景光明,但尚未像我们当前的系统一样经过数十年的审查和实际测试。

这不仅适用于算法审查,尤其也适用于实施方面。因此,避免完全依赖这些较新的算法是明智之举。通过保留我们熟知的加密技术,同时逐步集成PQC,我们可以规避风险,确保后量子算法或实施中的意外缺陷不会引入新的漏洞。

(二)安全过渡

将整个加密基础设施迁移到新的后量子算法是一项艰巨的任务。混合结构创造了一条循序渐进、灵活的采用路径。组织可以更快地引入和测试PQC,同时基于现有的强大系统保持运营安全。

过去我们进行的测试验证了混合式方法的有效性通过以混合方式部署PQC,我们在Chrome浏览器(2016年、 2019年)中对真实流量进行了实验,而不会危及用户数据。

这些实验表明,在最坏的情况下,仍然可以像使用传统保护一样安全地保护用户数据免受量子对手攻击,这并非理论情境。

我们所使用的CECPQ2b中的PQC部分SIKE被证实存在漏洞,但在那次实验中所有数据仍然得到了传统X25519算法的保护。

值得注意的是,虽然密码学上相关的量子计算机 (CRQC)能够破解传统的加密算法,但不可能立刻所有对手都能够获得一个量子计算机,并且攻击成本也很高。我们预计,如果将来CRQC首次出现,传统算法的附加层仍将提供有价值的安全优势。

成本之争

混合部署并非免费。它们可能会对性能产生负面影响并增加复杂性。

(一)协议复杂性

混合结构可能会给协议设计者带来额外的复杂性。设计者必须决定如何组合方案。如果可用的方案太多,可能很快导致需要所有实现支持的选项组合激增。

(二)实施复杂性

实施两种加密算法会增加工程成本并导致更大的攻击面。然而,在大多数情况下,经过审查的经典加密系统的实现已经可用并部署,主要成本和风险来自添加新的 PQC 算法。

我们在此推荐的混合结构简单且易于实施,而更复杂的结构可能会给实施带来额外的风险。

(三)计算成本

混合解决方案对性能有负面影响,但在许多情况下,PQC算法造成的开销已经占主导地位,尤其是在参数大小方面。例如,如果Kyber768密文为1088字节,并包括额外的32字节X25519共享秘钥,影响可以忽略不计。同样,Dilithium3签名为3309字节,而Ed25519签名仅需要额外的64字节。

(四)它不是一个永久解决方案

这不是一个永久的解决方案,部署混合解决方案可能意味着必须进行两次PQC迁移。首先引入混合方案,然后当加密相关的量子计算机可用时进行第二次迁移,并减少/消除经典算法的优势,这意味着应该将其删除。

我们的建议

为了简化集成并最大限度地降低安全风险,我们强烈建议将混合构造封装在单一、定义明确的类型中。

例如,结合了X25519和Kyber768的混合KEM应当被呈现为一个新的、独立的算法。这种方法隐藏了实现细节,使得混合方案对最终用户来说和任何其他算法一样难以区分。

这种策略有几个优点。它简化了使用,使混合方案像任何其他更高级别的算法一样易于实现。此外,它还可以防止混合系统和传统系统之间意外重复使用密钥材料。虽然与传统协议兼容的混合签名可能看起来很方便,但会引入复杂性并可能导致降级攻击。

我们强烈建议不要将混合方案作为简化传统转换或提供向后兼容性的手段。始终为混合和非混合方案使用不同的密钥材料。

我们对实际构造的主要建议是:

·对于使用X-Wing组合器的KEM。

·对于签名,只需并行使用两个签名方案。

深入探究混合结构

在接下来的两个部分中,我们将详细讨论迄今为止已提出的以混合方式部署PQC的方法。特别是,我们要强调的是,已经有许多相互竞争的提案,其中细微的差别可能会让混合结构的领域变得令人困惑。

密钥封装机制(KEMS)

混合KEM的目标是让两个当事方之间拥有一个通过将PQC和ECDH等经典算法进行密钥封装(或密钥协商)而派生出的单个共享秘密。

一个良好的实现应该保证强度至少和两个算法中强度更高的那个一样。

最近行业提出了许多KEM组合器候选方案,这些方案定义在IETF草案中,包括:

·TLS 1.3中的混合密钥交换

·混合密钥封装机制(Hybrid KEMs)的组合器函数

·Chempat:通用实例化PQ/T混合密钥封装机制

·X25519Kyber768Draft00混合后量子密钥协商

·X-Wing:通用混合后量子KEM

·在互联网X.509公钥基础设施和CMS中使用的复合ML-KEM

这些候选方案中每个都提出了一种不同的KEM组合器方法。NIST SP800-56C允许通过串联生成混合共享密钥:Z’ = Z || T。

NIST正在努力制定另一份提供有关KEM的进一步指导的特别出版物(参见NIST FIPS 203,引用“特别出版物800-227:密钥封装机制建议”)。(相关链接:https://csrc.nist.gov/pubs/fips/203/ipd

在Chrome中,我们过去曾使用不同的混合选项:

2016年:CECPQ1,使用了X25519和NewHope。

2019年:CECPQ2(以及CECPQ2b),使用了 X25519+HRSS和X25519+SIKE,并使用HKDF(shared_secret_A || shared_secret_B)来派生共享密钥。

在Google,我们也一直在ALTS中使用CECPQ2混合方案。

2023年:X25519+Kyber768,使用的是secret_A || secret_B,以及TLS 1.3密钥派生中的结果。

请注意,这些基于“简单”串联的KEM组合器之所以有效,主要是由于TLS密钥派生的特性(因为您已经在KDF中包含了完整传输的哈希值)。

对于大多数应用程序,单个定义明确的混合组合器如X-Wing可能更可取。这种构造的主要优点是简单、高效,并带有安全证明。

虽然通用组合器可能在某些用例中是理想的,但它们也有几个缺点。

首先,实施者需要小心如何构建组合器。例如,一个简单的KDF(secret_A || secret_B)组合器可能无法为所有可能的KEM选择实现IND-CCA 。

为所有可能的实例提供安全性的通用组合器(例如

https://eprint.iacr.org/2018/024.pdf)将引入额外的开销(例如在KDF部分中包含所有密文),这可能对特定KEM的选择并非必要。

签名

对于一般用途,我们建议并行使用签名,最好是以一种待定义的标准方式固定两种签名方案,就像X-Wing在KEMs的情况下所做的那样。

混合签名的目标是为一条消息拥有单一签名,只有在使用底层签名方案创建了有效签名时才能验证。优秀的实现应该保证和两种算法中更强的那种一样强大。

与KEMs类似,有许多选项可考虑关于如何组合签名。幸运的是,简单地并行产生这两个签名,只有在两者都经过验证时才接受签名,就足以拥有一个提供不可伪造性并且非常简单实现的混合方案。

HybridKeyGen() -> (secret_hybrid, public_hybrid)

其他组合器可以提供额外的属性——

在安全密钥中,我们选择了嵌套签名,以消除在Dilithium+ECDSA混合签名中结合时ECDSA的可塑性。像不可分离性这样的属性已经被研究过,可以防止剥离或重复使用签名的部分,以创建一个对其中一个基础密钥的有效非混合签名。

然而,这些组合器带来了额外的复杂性,如果密钥材料在混合和非混合密钥之间严格分开,那么我们认为追求这些额外的可分离性属性的好处非常有限。

结论

我们希望这篇文章能够帮助我们初步提出关于后量子计算的加密保护、混合部署的采用以及遵循这种方法时需要考虑的事项的建议。

敬请关注我们下一篇关于PQC的文章,当然,随着技术的不断发展,我们的指导和推荐的最佳实践也将随之演变。


相关阅读

专访亚数TrustAsia产品总监徐忠灏:量子计算真的遥不可及吗?

Q-Day比我们想象的更近吗?IBM研究人员称混合量子AI可能构成近期威胁

谷歌发布后量子密码学计划,距离PQC更进一步

Apple宣布为iMessage推出“突破性” 后量子加密协议PQ3

欧盟委员会呼吁采取“紧急行动”,加快制定向后量子密码迁移路线图

深度好文——后量子互联网的现状如何?

深度好文——后量子TLS的设计选择

(本文来源|Google 图源|Pixabay  转载|公钥密码开放社区)