案例研究
PDF案例研究
车辆的量子安全信任：竞赛已经开始
与 Michael Gardiner、Alexander Truskovsky、George Neville-Neil 和 Atefeh Mashatan 的讨论
量子计算的理论已经存在近三十年了，这要归功于物理学家保罗·贝尼奥夫在 1980 年代初期提出的图灵机的量子力学模型。在那段时间里，这个概念似乎更像是一个遥远的愿景，而不是迫在眉睫的现实。这种情况在 2019 年发生了突然的改变，当时谷歌 AI 与 NASA 联合声称，他们已经成功完成了一项传统计算机无法实现的量子计算。
虽然许多人热切期待着量子计算的到来可能开启的新前景，但密码学家和安全专家通常并不认同这种热情，因为最令人期待的量子优势之一出现在整数分解领域，这对于基于 RSA（Rivest-Shamir-Adleman）的安全至关重要。此外，早在 1994 年，麻省理工学院数学家彼得·肖尔就开发出了一种量子算法，能够解决对于 Diffie-Hellman 密钥交换和椭圆曲线密码学至关重要的离散对数问题。
现在看来，量子计算能力可能会在未来十年或二十年内实现商业化——很可能以云服务的形式出现——安全专业人士已经以前所未有的紧迫感转向应对量子驱动攻击威胁的挑战。
汽车行业尤其如此，现在下线的汽车有时被称为“移动数据中心”，以承认它们包含的所有娱乐和通信功能。自动驾驶系统也正在快速发展，这并不能减轻这些担忧。事实上，汽车网络安全的风险似乎即将变得前所未有的高，而与此同时，当代网络安全的某些基础正在变得毫无意义。
为了在接下来的讨论中探讨这方面的含义，acmqueue 汇集了一些已经在为汽车行业构建新的信任环境的人：ISARA 公司的技术战略总监 Alexander Truskovsky，该公司正在努力开发量子安全密码信任根；泰雷兹的解决方案架构师 Mike Gardiner，他一直致力于为汽车行业量身定制量子安全保护措施；瑞尔森大学网络安全研究实验室主任 Atefeh Mashatan；以及 JUUL Labs 的工程运营安全总监 George Neville-Neil，许多人更熟悉他的身份是 Kode Vicious。
ATEFEH MASHATAN 在汽车行业的量子漏洞方面，您认为您最大的担忧是什么？
MICHAEL GARDINER 一个主要的担忧与智能汽车的空中软件更新有关——例如特斯拉——拥有量子计算机的人可能会发布恶意固件，同时制造出它来自制造商的假象。车辆发送回制造商的遥测数据也存在风险，这些数据可能会被拦截或篡改，使其看起来车辆去了它实际上没有去的地方。
AM 我们为什么要忍受与空中更新相关的风险？
MG 既然我们的汽车变得智能，它们实际上已经变成了车轮上的数据中心。也就是说，它们现在越来越多地由软件组件组成，所有这些组件本质上都包含漏洞。汽车制造商可以使用软件更新，不仅可以提供使汽车通用娱乐系统保持最新的新功能，还可以纠正其他系统中出现的缺陷。
ALEXANDER TRUSKOVSKY 为了提供一些规模感，像福特 F-150 这样的车辆配备了超过 1 亿行代码。你可以很容易地想象出那里需要处理相当多的错误。这实际上不是一个是否需要软件更新的问题，而是需要多少以及多久更新一次的问题。通常，您宁愿不让车主承担每次需要管理这些更新时都去经销商处的费用和不便。预计到 2022 年，每辆售出的汽车都将内置一定程度的自主性。当然，这使得建立某种机制来及时有效地更新该软件变得更加关键。
GEORGE NEVILLE-NEIL 说一辆汽车有 1 亿行代码是一回事，但大多数构建包含安全关键和非安全关键组件的系统的人都足够聪明，知道他们需要将这些东西彼此分开。我们对安全关键组件的空中更新不会最终与娱乐系统的更新捆绑在一起有多大信心？我问这个问题是因为娱乐系统只是一个巨大的、丑陋的 Linux 盒子，里面充满了某个小丑想要包含的每个开源库，以便人们能够在车里播放音乐、视频和游戏。
另一方面，制动系统是据推测由成年人编写的，并且理想情况下已与所有其他系统隔离——不仅通过数字防火墙隔离，而且还通过物理隔离。我相信会为这些安全关键系统单独发送软件更新，而不是与汽车通用娱乐系统的软件更新一起发送。
MG 在汽车行业，许多这些组件都是很久以前编写的代码，最近不一定被查看过或由第三方审查过。因此，您现在在汽车中找到的娱乐系统通常能够在安全关键系统使用的同一个 CAN [控制器区域网络] 总线上通信。
GNN 这有点令人不安。
AT 我同意，但在现阶段，空中更新主要仅用于娱乐系统。一些制造商，如特斯拉，可以通过软件更新启用一些其他功能，但在大多数情况下，只有娱乐系统以这种方式更新。此外，随着计算机化的转变，许多车辆现在正在切换到不同的网络系统。也就是说，您将看到组件之间更多的基于以太网的通信，因为 CAN 总线根本无法处理当前自动驾驶系统要求带来的负载。
因此，如今，车辆的设计既要可更新，又要适应更高级的计算机系统。但请记住，车辆设计周期很长——通常为五到八年——这意味着计划在五年后首次亮相的车辆已经设计完成。
AM 目前正在采取什么措施来保护汽车的软件更新？
AT 如果在经销商处处理，技工可以使用 USB 密钥下载软件更新，通常没有签名——即使这不是一个明智的做法。相比之下，空中软件更新绝对需要代码签名，这需要一个公钥基础设施，信任锚点是嵌入在车辆中的根证书——私钥属于原始设备制造商。有了这个基础设施，更新可能会以类似于当前发送到手机或笔记本电脑的方式交付给汽车，因为它们将被数字签名，然后车辆将采取额外的步骤来验证软件的真实性，然后再应用它。
问题在于，这个系统核心的嵌入式信任锚点是基于经典公钥密码学的，一旦攻击者能够使用量子计算机，这些信任锚点将很容易被破解。将这些过时的信任锚点更换为新的、针对量子攻击进行强化的信任锚点，将需要将车辆送去维修。在某些情况下，这可能很容易通过更新公钥来完成，但在更多情况下，升级将需要某种硬件更换。
这就引出了与自动驾驶汽车出现相关的另一个问题，自动驾驶汽车包括与 ECU [发动机控制单元] 通信的传感器，ECU 又与刹车和转向系统通信，以便车辆知道往哪里转向以及何时刹车。在这种情况下，不同的组件之间将中继消息，并且需要对消息进行身份验证，以便 ECU 知道它们确实来自车辆的实际刹车传感器或碰撞传感器——而不是由一些试图控制车辆的黑客冒充。
所有这一切都表明，这是一个零信任基础设施，其中每条消息都需要经过身份验证，并且自动驾驶决策必须完全经过身份验证。用于此环境的密码学尚未由 NIST [国家标准与技术研究院] 标准化。尽管如此，虽然核心量子安全算法的某些参数可以修改，但这些算法的基本原理——即密钥大小、速度以及事物的执行方式——不会改变。这意味着这些算法可以开始在车辆组件上进行测试，以便汽车制造商能够尽快开始发布包含能够支持后量子密码学的硬件的新车型。
此外，与此同时，可以开始在车辆中嵌入量子安全信任锚点，因为用于代码签名的数学本质上已经准备就绪。然后，几年后，一旦最终标准可用，我们一直在谈论的量子安全软件更新通道就可以用于补充信任锚点，并添加在此期间开发的任何其他量子安全功能，其中大部分预计与自动驾驶的要求有关。
AM 如果 NIST 标准证明与您目前正在使用的抗量子算法不完全兼容，会发生什么情况？
AT 您必须对冲风险，这意味着您需要为每种类型的密码算法提供支持——格密码、多变量密码、基于代码的密码、基于哈希的密码，等等。如果基于格的方法被证明被破解，那么您需要准备好使用基于哈希和多变量的方法。因此，您确实需要能够移植所有这些算法。
AM 除了空中软件更新之外，一旦量子计算商业化，汽车制造商还应该特别关注什么？
AT 实际上，还有另一个与软件更新相关的问题我们应该首先讨论。在自动驾驶汽车的情况下，有时制造商需要向车辆发送各种经过身份验证的命令。为这些命令提供安全性与保护软件更新所需的安全性非常相似——也就是说，两者都需要以相同的方式进行身份验证。
我所说的命令是指在发生事故后可能发送给自动驾驶汽车的命令。在这种情况下，可以向车辆发送经过身份验证的命令，以指示其前往特定的服务设施，或让汽车自行驶出交通，停靠在路肩上。显然，这些命令也需要是量子安全的。我主要是在谈论身份验证，但加密也起着重要作用，因为我们需要为用户提供隐私保护。
MG 这还有另一个方面：由于用户将通过他们的移动设备连接到智能汽车，他们发送的任何命令以及汽车发送回他们移动设备的任何信息也需要受到保护，以保护隐私。黑客在这里有很多机会获取敏感的私人信息。
AM 用户与其车辆之间的这些通信目前是否受到某种形式的加密保护？
GNN 我的印象是，汽车内部的通信目前尚未加密，并且在不久的将来也不太可能加密。鉴于有很多人已经接入 CAN 总线，现在将开始接入以太网，它们真的应该被加密。但我还没有看到任何标准规定这将是必需的。
MG 是的，这也是我的理解。
GNN 让我们也不要忘记，大量的位置数据在这些新型车辆之间来回传输，这绝对存在很多问题。
AM 是的，这超出了隐私问题，因为访问这些位置数据甚至可能被用来进行绑架或其他暴力犯罪。从事后量子安全工作的人员是否正在考虑这个问题？
MG 量子驱动的攻击将能够完全否定遥测信息的隐私性，因为它仅受非对称密码学保护。无论如何，目前大多数安全工作都集中在软件更新的完整性上。
AT 是的，以及车辆安全。在具有自动驾驶系统的汽车的情况下，来自其他车辆和其他来源的关于前方路段发生碰撞的信息可能会改变车辆的驾驶指令。但是这些数据是可伪造的，这显然对车辆乘员的安全构成威胁。
GNN 考虑到这一点以及我们一直在讨论的其他安全风险，您认为在整个汽车世界中部署抗量子密码学和 PKI [公钥基础设施] 的最佳时间表是什么？这与实际可行的方案相比如何？
MG 即使我们现在开始部署，我们也会受到汽车行业供应链问题的摆布。按照目前的速度，将这些类型的设计变更纳入量产汽车大约需要五年时间。
AT 车辆在道路上的平均寿命约为 11 年半。然后我们需要从这个时间倒推，考虑到设计一辆汽车大约需要五年时间。这意味着今天做出的设计决策在 16 年半后仍然应该有意义。NIST 和其他组织的建议是，到 2030 年，应采取措施缓解量子计算威胁。显然，当我们应该何时开始对车辆进行量子安全防护这个问题时，已经存在相当大的紧迫性。
尽管快速行动的压力很大，但汽车行业可能会逐步推进生产配备量子安全信任的车辆。几乎毫无疑问，这些步骤中的第一步将侧重于确保安装在汽车中的嵌入式计算设备实际上能够应对挑战。
仅仅这一点就将代表汽车制造商的巨大转变，他们过去一直依赖最便宜的现成微控制器。但是，当需要为一系列复杂的量子安全加密算法或自动驾驶系统势必会对需要与各种传感器持续通信的控制器提出的吞吐量需求提供支持时，这根本不够用。
GNN 让我们谈谈汽车行业在实施抗量子 PKI 时将面临的一些挑战。它不会完全像在数据中心内部或为始终在线的事物部署 PKI 那样。您一直在研究哪些关键差异？
MG 当您考虑诸如通过 Web 浏览器进行金融交易的信任根之类的东西时，您将遇到的所有受信任的 CA [证书颁发机构] 都是浏览器制造商和 CA/浏览器论坛 [CA 和浏览器软件、操作系统和其他启用 PKI 的应用程序的供应商组成的联盟] 事先商定的。关于如何使用这些证书以及用于哪些密钥以及使用多长时间的规则已经确定。
在汽车领域，没有与此等效的东西。汽车制造商应该能够在早期将其量子安全 PKI 推广到其车辆中，而无需首先获得广泛的行业接受。
GNN 这实际上使事情变得更容易了吗？还是最终看起来像当年所有浏览器人员都必须找到某种方法达成一致时出现的问题？
MG 我不这么认为——至少在行业开始谈论车辆基础设施或车辆到车辆的通信之前不会这样。这将需要更广泛的行业协议来确定哪些应该被允许，哪些不应该被允许。但是，就目前而言，如果我们只是谈论针对某个特定车型的固件更新，或者在制造商和汽车之间或在用户的手机和汽车之间保护遥测信息需要什么，这可以在制造商的基础上单独处理。
GNN 鉴于此，推广这些保护措施的路线图是什么样的？您说我们正在谈论保护预期设计寿命为 16 年半的对象。因此，如果今天是第一天，那么汽车制造商在实施这些措施方面，未来一两年需要做些什么？
AT 首先，他们应该能够至少并行做几件事。一是，在他们设计新车时，他们可以将 CAN 总线迁移到以太网，同时更新所有充当控制器的嵌入式计算设备。这些东西他们可以自己设计，也可以从市场上购买。无论哪种方式，都有必要评估这些设备，以确保它们能够支持所有可用的加密算法系列。其中一些算法可能多年都不会使用，但汽车制造商至少应该确信他们今天安装的硬件将能够处理它们。
与此同时，他们还可以确保他们当前的软件/固件更新功能将能够利用目前可用于该目的的最安全算法——特别是，有状态的基于哈希的签名。
在完成这两个目标后，汽车制造商将确信它拥有能够长期支持量子安全密码学的硬件，以及一个量子安全通道，可以通过该通道在未来几年推送额外的量子安全功能。
AM 考虑到汽车 16 年半的设计寿命，汽车制造商目前正在嵌入的计算设备能够胜任所有这些任务吗？
AT 这是一个很好的问题。我们在不久的将来会看到许多算法将非常复杂。然而，汽车制造商通常不会为这些计算设备花费超过绝对必要的费用——这意味着他们购买的设备通常非常有限。这可能会变得有趣，因为量子安全算法肯定会比他们目前运行的加密算法要求更高。
AM 您可以量化一下吗？
AT 这完全取决于情况。有些算法，如格密码，运行速度很快，但它们也具有很大的密钥和签名。然后，您还有一些算法，如超奇异同源，它们具有小得多的密钥，但运行速度慢得多。
由于这里的一个考虑因素与自动驾驶汽车的运行有关，因此还必须考虑吞吐量。也就是说，您需要能够处理每秒可能 100 条消息，因为始终会有一些传感器与一些控制器通信——所有这些都必须实时发生。此外，其中一些消息很可能被加密或需要签名，这将大大增加处理时间。但制造商仍然必须确保他们能够满足这些实时要求。这可能被证明是一个相当大的挑战。
AM 另一个潜在的挑战——空中更新呢？有多少汽车制造商可能会开始朝着这个方向发展？
AT 我读到，在未来几年内，汽车行业预计通过空中软件更新而不是在经销商处亲自处理软件更新来节省 350 亿美元。
AM 有人对汽车行业可能遭受量子驱动攻击的风险进行了评估吗？
MG 我们已将短期内的潜在风险评为低，随着时间的推移，风险会升至中等到高。但是，由于我们认为任何攻击的影响都至关重要，因此即使在短期内，我们也将其视为至少为中等风险。
GNN 量子安全 PKI 的实施时间表是什么？首先需要发生什么？您认为这会在什么时候发生？
MG 我认为汽车制造商首先希望实现的是提高其汽车资源的密码敏捷性。也就是说，他们列表的首位是获得处理量子安全算法、固件更新和遥测通信的能力。就车辆内部发生的事情而言，这可能暂时不是那么令人担忧，仅仅是因为这需要物理访问。
无论如何，仅仅采购能够处理增加的负载的组件本身就代表着巨大的变化，因为这些组织习惯于只关注提供基本内置功能但除此之外几乎没有其他功能的小型微控制器。现在他们将不得不更多地考虑未来，而不知道未来究竟会是什么样子，也不知道这将需要多少额外的容量。我认为他们需要四到五年时间才能从规划到将某些东西投入使用。
GNN 您认为这条道路至少在某种程度上会类似于当年人们担心在台式系统中嵌入安全计算元件时发生的情况吗？如果您在 10 或 15 年前想要使用 SSL [安全套接字层]，您必须在服务器中添加专门的加密组件。您是否看到这里的第一个推动力是使用汽车制造商以前使用的相同微控制器以及一些额外的加密组件？还是您认为他们将需要放弃这些微控制器并升级到包含内置加密指令的完整现代处理器？如果是这样，由于现在所有这些加密指令都是非对称的而不是抗量子的，这将如何工作？
MG 最初，汽车制造商要么必须内置更多的通用计算设备，以便他们能够实现所需的灵活性，要么他们需要研究 FPGA [现场可编程门阵列] 技术，以便满足该要求。这是因为目前所有的 ASIC 和其他硬件可能都无法处理这些新的量子安全算法。他们可以尝试其他一些方法，但这些方法可能与 2024 年的该标准不符。
GNN FPGA——或任何其他类似的东西——将代表成本的显着增加。您认为汽车制造商愿意承担吗？
MG 我不确定。但我认为他们可以考虑依赖车辆内部的对称密钥方案，然后尝试以这种方式处理完整性和加密。通过这种方法，他们或许可以只使用一个集中的 FPGA，负责所有内部汽车世界和外部世界之间的转换。但这可能仍然与未来几年内将成为标准的任何事物不符。
由于量子密码标准尚未最终确定，我们可能会在未来几年看到许多方面的调整。但有一件事是肯定的——量子计算即将到来。并且它不再遥远。
不过，令人欣慰的是，各组织开始意识到，一旦那一天到来，他们就不能措手不及。从经验来看，他们已经知道，仅仅从一种加密算法转移到另一种加密算法就需要相当长的时间和精力。转向量子安全算法将涉及远不止这些，并且在将一切都做对方面，风险也会更高。
AM 在预测未来的挑战方面，从过去做出的一些密码学变更中可以吸取哪些教训？
MG 可能是这样。例如，SHA-1（安全哈希算法 1）可能已经被破解了好几年了，但仍然有一些东西在野外继续使用它。除非我们现在开始为后量子挑战做准备，否则我们将发现自己处于相同的境地，即在量子计算到来很久之后，该行业仍然继续依赖不再有效的密码学。总的来说，网络安全行业在应对新事物时往往非常规避风险。但这正是人们需要考虑的情况之一，即如果他们现在不开始准备，他们可能会将自己置于更高的风险之中，因为毫无疑问量子计算即将到来。
AT 过去的另一个很好的例子是，美国国家安全局 [NSA] 在 2005 年宣布了 Suite B 密码学，并强制所有政府机构都应实施它。但是，在 10 年后，又发布了另一项公告，称任何尚未完成迁移到 Suite B 的人都应暂停并等待新的量子安全标准的出现。也就是说，在过去的 16 年中，美国政府和加拿大政府都未能完成其向 Suite B 密码学的迁移。这让您对大型组织从一种算法迁移到另一种算法到底需要多长时间有了一个很好的了解。
其中一些量子安全算法的行为与安全专家已经习惯的行为截然不同。也就是说，典型的签名算法有一个私钥和一个公钥。私钥签名，而公钥验证，您可以根据需要执行任意多次。对于量子安全算法，您也有一个公钥来验证签名，但私钥却非常不同。基本上，它是一个一次性密钥的集合，这些密钥以二叉树的形式组织，其中每个密钥都是一个叶子，树的根是您的公钥。在签名验证操作期间，您使用其中一个私钥进行签名，但随后必须丢弃该密钥。
您实际拥有的是大量耗尽型私钥，您需要管理和维护这些私钥的状态。以前从未这样做过。因此，现在，使用这些方案创建根证书和签名实体证书的 PKI 组织需要比以前做更多的计划。这是因为，在根证书的情况下，树的高度决定了潜在签名的数量，并且在该数量增长与可以实现的效率之间存在权衡。这意味着您需要进行计划，以便确定您想要从特定密钥接受的最大签名数量。您还需要为高可用性提供支持并为灾难恢复进行计划。
对于大型私钥树，小心状态也很重要。如果您在多个位置备份，则需要在所有这些位置共享该状态，这当然非常不切实际。关键是，您最终会改变整个运营计划，仅仅因为您现在正在处理一个耗尽型密钥。在某些时候，即使签名证书的公钥仍然有效，您也可能会耗尽私钥。很容易看出，不习惯这些类型问题的人可能会对量子安全算法感到非常沮丧。
MG 人们需要习惯的另一个重大密码学变化是缺少像 RSA 这样的通用、万能密钥。今天，RSA 用于加密、签名和交换密钥。但这些较新的算法实际上不允许使用单个密钥，甚至使用一对密钥进行多次操作。
GNN 这些树到底有多大？
AT 实际上，既有单树变体，也有多树变体。单树变体的树高度从 5 开始，您有 32 个可能的签名验证密钥对，到树高度 25，您有大约 3200 万个密钥。然后，您可以将这些集合嵌套在许多多树格式中，从而允许基本上无限数量的密钥。但这自然会导致严重的复杂性。正如已经指出的，状态管理也可能很快变得非常复杂。
不建议将这些方案用于通用用途，但它们在您签名一次然后多次验证它的情况下效果非常好。这适用于根证书，甚至中间证书，因为这些是您创建一次的同时也签署了一堆证书的东西，然后这些证书会被一遍又一遍地使用。这也适用于代码签名，您签名一次，然后许多车辆只需要验证签名，这实际上使工作变得容易得多。
GNN 好的，因此在分发密钥时，将由 PKI 处理这些树。关于如何在汽车中维护这些密钥的存放，有什么想法？
AT 这是一个很好的问题，但实际上它并不适用于汽车。相反，它适用于软件更新实际签名的地方，即汽车制造商数据中心内的硬件安全模块 [HSM]。您在车辆端找到的系统对应部分是公钥，它充当二叉树的根节点，对于有状态的、基于哈希的签名方案，其长度仅为 60 个八位字节 [每个八位字节由八位组成]——也就是说它非常小。
实际上，车辆仅负责完成这里容易的部分。它只需要验证签名，这相对容易，因为该方案依赖于哈希运算，而这是所有当前的汽车硬件节点都能够做到的。
话虽如此，它仍然比汽车制造商习惯的哈希运算量稍多一些。但这就是全部了。整个签名验证过程仅涉及执行几百次哈希运算。这就是为什么这个方案非常适合今天部署的原因。事实上，它现在就可以用于软件更新，因为即使是目前车辆中发现的计算机硬件也能够支持它。与此同时，与新私钥相关的真正困难可以转移到数据中心，在那里可以使用几个 HSM 来处理所有签名和备份要求。
GNN 考虑到这一切，您认为人们现在应该最关注哪些与量子相关的问题？为什么？
AT 当然没有必要同时担心所有事情。这实际上又回到了产品生命周期和设计周期的问题。例如，金融服务业有其自身的量子问题需要解决，但那些人没有必要放下一切，立即重新思考信用卡安全。这是因为信用卡交易是短期的，而且卡本身每隔几年就会更换一次。即使在最坏的情况下，几天之内也可以发行一张新的信用卡。无论如何，您现在钱包里的任何信用卡都可能在通用量子计算能力可供潜在对手使用之前被更换多次。
另一方面，汽车制造商需要考虑更长的产品生命周期。同样，他们不必应对航空航天业面临的真正令人望而生畏的产品生命周期问题，航空航天业的喷气发动机通常服役几十年，而且当然不能轻易更换。航空航天领域已经进入一个他们需要深入关注迫在眉睫的量子安全威胁的时间框架——这意味着他们很快就需要对该问题的所有方面给出答案。
汽车制造商可以首先将注意力转向确保今天设计和制造的任何发动机硬件都能够处理一旦攻击者能够利用量子计算能力时将变得至关重要的密码学。一旦汽车行业掌握了这一点，它就可以将注意力转向确保它也能够以量子安全的方式交付软件和固件更新。
GNN 您能想到任何似乎已经正确处理这个问题的行业或组织吗？
MG 从行业的角度来看，您有 ETSI [欧洲电信标准协会]，它已经开始弄清楚其标准将如何演变，除了 NIST 正在进行的工作之外，还将并行添加抗量子密码学和量子密钥分发。CA/浏览器论坛也在努力标准化后量子证书，DigiCert 是该领域特别响亮的声音。
在更组织化的层面上，现在在微软、谷歌和 Cloudflare 出现了一些很好的例子。他们都在 TLS [传输安全层]、SSH [安全外壳] 和 VPN [虚拟专用网络] 连接中集成抗量子密码学方面做了一些非常公开的实验。他们迄今为止构建的许多代码都可以在开源存储库中找到，因此其他人可以利用它。我想说这些组织也非常关注即将到来的转型的实用性，以及需要做些什么来确保现实世界的系统为最终标准化的任何事物做好准备。这些实验中一个有希望的结论是，它们表明这些方案的整体性能仍然受网络传输主导，这意味着可能无需担心用户体验会受到过度影响。
在目前正在应对这一挑战的人中，共同的主线似乎是关注密码学敏捷性，而不是试图预测哪种提议的方案最终将被认证。这表明，至少在组织层面，人们理解，只要所有这些努力都是为了实现敏捷性而构建的，那么修改这些标准的努力就可以并行向前推进。组织似乎也在以务实的方式对待自己的努力，假设混合量子和经典方案可能被证明是满足合规性目标所必需的。
这也是我对汽车行业的建议：将密码学敏捷性作为首要关注点，不要过度优化任何特定的实现。这应该有助于量子转型，同时允许适应不断变化的区域要求。对于资源有限且需要集中精力的公司，我想说完整性和身份问题是需要关注的问题。信任根往往是最难更换的，因为人们相信它们可以长期信任，然而，最终，分布式系统中所有完整性问题都依赖于共享的信任根。
版权所有 © 2021 归所有者/作者所有。出版权已许可给 。
最初发表于 Queue vol. 19, no. 2—
在 数字图书馆 中评论本文
更多相关文章
Christoph Kern - 软件安全开发生态系统
如何设计和实施信息系统以使其安全可靠是一个复杂的话题。软件安全和安全的高级设计原则和实施指南已得到很好的确立并被广泛接受。例如，Jerome Saltzer 和 Michael Schroeder 关于安全设计原则的开创性概述早在 50 年前就已发表，各种社区和政府机构也发布了关于如何避免常见软件弱点的综合最佳实践。
Michael Loftus、Andrew Vezina、Rick Doten、Atefeh Mashatan - 零信任的到来：这意味着什么？
过去，企业网络安全就像城堡和护城河。首先，保护边界，然后在内部发生的事情方面，信任，但要验证。当然，边界是公司网络。但是，在这一点上，这甚至意味着什么呢？由于大多数员工现在至少在某些时候在家工作，并且组织越来越依赖云计算，因此不再存在单一的企业范围的边界。而且，随着公司安全漏洞在过去二十年中已成为常规新闻，信任也基本上消失了。
© 保留所有权利。