AI 时代，芯片安全正在重塑

专家圆桌：某半导体专业杂志邀请了以下嘉宾，共同探讨为何以及如何在设计流程的早期阶段将安全性融入芯片设计。嘉宾有：Arteris 公司执行副总裁、首席产品与营销官兼安全解决方案总经理 Michal Siwinski、Cadence 公司高级应用工程师 Yathiendra Vunnam、Keysight EDA 公司高级总监兼产品组合经理 Alexander Petr、Rambus 公司硅安全产品高级总监 Scott Best、Siemens EDA 公司静态验证与形式化验证产品管理总监 Chris Giles、Synaptics 公司架构高级总监 Mohit Arora，以及 Synopsys 安全、处理器、无线与 NVM（非易失性存储器）战略项目总监 Reed Hinkel等专家。本次圆桌讨论于近期举行的设计自动化大会（DAC）期间以闭门形式进行。以下内容节选自此次讨论。

图1： 从左至右依次为：Synaptics 的 Arora、Synopsys 的 Hinkel、Arteris 的 Siwinski、Cadence 的 Vunnam、Keysight 的 Petr、Rambus 的 Best，以及 Siemens 的 Giles。

记者： 对于芯片和系统架构师而言，目前最迫切需要应对的安全问题是什么？

Siwinski： 当前最重要、也是最关键的一件事，就是立即开始行动。当然，我们需要考虑未来技术会如何演进，以及安全问题将如何解决，但现在就必须开始规划，并让安全团队、设计团队和检验团队展开讨论，将安全作为设计阶段的关键部分，并且明确这究竟意味着什么。即使一开始做得不够完善，也必须先开始。如果现在还没有开始，那就已经太晚了。这与目前行业中的现状形成鲜明对比。如今，安全团队对于芯片安全或最终产品安全只有一些高层次的理解，他们也有一些方法可以向法务部门解释清楚，让他们同意。而设计师们只是明白他们必须确保不出错。验证团队的工作量已经超负。而验证团队早已不堪重负，他们认为：“只要功能验证正确，就应该没问题。”但这远远不够。必须将安全保障（security assurance）作为设计流程的核心原则之一，在设计之初就融入其中，并且必须立即行动起来，这才是当前最重要的事情。即使最终目标会随着技术的发展不断变化——而且它一定会变化——现在开始，仍然是最重要的。

Hinkel： 不仅要开始行动，还要弄清楚从哪里开始，因为任何产品都需要满足一个最低安全基线。如果你的产品计划销往世界上的某些地区，而又无法满足当地要求，那么产品很可能根本无法销售。也许你可以依靠软件补丁来勉强满足要求，但产品的性能不会达到预期，而且在一些安全评估中也很可能无法通过。我们注意到，客户最好先去实验室进行实地考察，问问他们：“你们想开发什么？你们是否意识到，你们的产品需要满足各种规范、认证和其他要求才能按预期销售？” 先帮助他们建立正确的认知，这样，当开始讨论真正需要投入哪些安全措施时，他们就不会那么抗拒。不同公司可以提供不同类型、不同形式、不同规模的安全解决方案，这些都很好。但安全问题不能事后补救。它必须是基础性的。如果缺少这些基础性的安全能力，你就会在PPA（产品性能评估）方面遇到问题，也会在功能实现方面失败，还会在安全评估中失败等等。而你绝不希望为了这些问题重新流片（spin a chip）。从整个行业来看，我们还能借助数字建模向客户展示，为什么必须将这些安全机制加入设计中。例如，我们工具中的一些建模能力包括侧信道功耗分析（side-channel power analysis）等，它们都是整个工具流程的一部分。关键在于，一旦客户真正理解，如果没有建立正确的防御机制，攻击者是多么容易绕过现有保护，他们就会意识到必须采取行动。他们需要在IP上投入更多成本，需要增加一些芯片面积，也需要在过去没有考虑过的地方投入资源。但是，如果他们在项目开始阶段都不知道自己的安全目标是什么，甚至没有建立一个最低可行安全基线（minimum viable baseline），那么从长远来看，他们的产品很可能会失败。

Arora： 基础架构以及其他相关要素都非常重要，鉴于攻击模式正在发生变化，基础架构也必须随之改变。与此同时，我们还观察到一个趋势：安全问题正逐渐从一个工程问题演变成一个由业务驱动的问题。这一变化越来越明显。例如，《网络韧性法案》（Cyber Resilience Act，CRA）就是一个典型案例。过去，人们的想法是，“我要设计一款安全的产品。品牌没问题，请证明它是安全的。”你必须完成所有流程和程序，以确保产品不仅仅安全，还能建立信任。

如何在产品的整个生命周期中持续维护这种信任变成了关键所在。此外，我们的客户，也就是系统集成商，对于如何处理漏洞（vulnerability）也变得越来越严格。因此，除了那些更基础的安全能力之外，我们正在看到越来越多监管法规的出现，它们正在推动整个行业以一种完全不同的方式思考安全问题。

Vunnam：我和我们的研发团队关注的一个重点是，LLM（层级模型）究竟需要保障哪些方面。大多数人关注的是LLM的数据隐私，但我们认为，在芯片和数据中心层面，最大的威胁是集成损坏。你的数据决定了你想要执行的操作。如果攻击者能够获取提示信息或篡改模型权重，他们就能改变执行路径。鉴于LLM的设计方式以及我们反复使用数据的方式，一旦出现漏洞，你如何保证下次使用类似数据时数据的安全性？你又如何确定你的智能体工作流程是安全的？这是一个我们一直在讨论的有趣话题。

Petr：既然我们讨论的是芯片安全，也讨论的是设计栈的安全，就像之前提到的那样，我们需要转变一下思维方式。你可以用我们讨论多物理场的方式来阐述这一点。如今，所有问题都变得更加复杂，因为我们可以利用LLM等新技术来解决更大的问题空间。一旦我们把范围扩大，集成、可用性等等问题就会引出一个问题：谁在主导需求？CAD团队会认为应该由他们来定义需求；热分析工程师会这么认为；模拟设计工程师会这么认为；数字设计工程师也会这么认为。所以基本上，每个人都想掌控一切，主导需求，最终形成了一种复杂的局面。这是一个很有意思的话题。最终，你需要把这些纳入你的规范。如果没有规范，那就什么都做不成。在软件栈方面，我们也面临着像SSDF（软件安全开发框架）这样的问题。所以，尽管监管力度有所减弱，但作为软件供应商，我们现在必须达到一定的标准。欧洲信用评级机构（CRA）的要求更严格，因为他们明确表示，如果做错了什么，利润就会受到影响，而且还要支付罚款。因此，在某些领域，我们向客户提供安全软件的问题变得尤为重要。由于我们现在都在使用某种co-pilot式智能体框架，LLM的问题也变得越来越关键。在某些情况下，我们会依赖一些并非由我们公司拥有的前沿模型。整个系统中引入了一个新的参与方。于是，我们必须保护与这些模型之间的通信通道，并确保不会从这一侧发起攻击。这要求软件开发流程采用一种全新的设计周期。即使我们使用自己的LLM，也会将其部署在本地。这是一种缓解安全隐患的方法，即“我们将其部署在不同的硬件上，部署在本地边缘（on-prem edge）环境中”。 总而言之，只要谈到安全问题，它几乎可以扩展到所有领域。

Best：回到刚才关于“立即开始行动”的话题。来到DAC的大多数人关注的是安全服务（secure services）。而安全服务离不开底层的安全软件。安全软件又离不开底层的安全硬件。因此，从一家硬件公司的角度来看，首先必须做的一件事，就是建立硬件安全（hardware security）。因为并不是所有硬件都是一样的。有普通硬件，也有抗篡改硬件（tamper-resistant hardware）。如果你没有一支专门负责抗篡改硬件的团队，那么最好从项目一开始就建立这样一支团队，或者与拥有这类能力的合作伙伴合作。否则，你就无法真正实现安全服务，因为你无法一路追溯到可信根源（ground truth），也无法确认这些服务最终是在抗篡改硬件上运行的。

Giles： 这个问题可以用规模来概括。如今全球面临的安全问题，以及我们整个行业面临的安全问题，本质上都是规模问题。真正理解安全的人太少了。真正理解信任根（Root of Trust）重要性的人也太少了。遗憾的是，即使暂时不考虑AI，目前整个行业能够做到的，也只是说：“这里列出了所有曾经被利用过的漏洞，我们去检查这些漏洞，确保它们不会再次出现在当前设计中。”但真正的问题在于，危险往往来自那些你没有想到的东西。即使拥有完善的规格说明，即使团队中有真正理解安全的人，仍然可能存在尚未发现、却可以被利用的漏洞。我并不认为安全漏洞的状态空间（state space）是有限的。一定还存在尚未被发现、但可以被利用的漏洞。现在，再把AI纳入这个讨论。从人类的智力基础来看，我们能够做到的事情终究有限。遗憾的是，好的AI并不能完全帮助我们。而恶意AI的发展速度，很可能会超过我们抵御攻击的能力。因此，我们面临的是一个规模问题。这是计算能力方面的规模问题，也是构建防御能力方面的规模问题。我们需要让好的AI，也就是白帽黑客AI（white hat hacker AI），能够跑赢恶意AI。归根结底，这仍然是知识规模的问题，我们需要规模化。这一点与形式化验证（formal verification）所面临的问题非常相似。而且毫不奇怪的是，安全也需要形式化验证所具有的那种详尽性（exhaustive nature）。然而，全世界真正理解这一点的人仍然太少了。换句话说，世界需要AI来帮助普及安全知识，并让这些知识实现规模化。

SE： 对于负责带领设计团队的芯片架构师来说，他们必须制定一套安全规划。你们的客户目前是如何应对这一问题的？你们是否发现，工程团队已经建立了一套有组织的安全实施方案——从产品规格说明中定义安全要求，再贯穿设计、验证、制造，最终延伸到产品部署后的整个生命周期？

Siwinski： 是的。我们今天讨论的这些理念其实并不新鲜。安全并不是一夜之间突然变得重要的事情。当然，今年4月随着 Mythos 的出现，它确实变得更加引人关注，但这就是现实。那时， LLM 不仅能够发现新的漏洞，也就是那些未知的未知（unknown unknowns），而且还能深入到底层硬件。这一点没有软件层面的讨论那么公开，但事实上，这些模型如今已经足够强大，它们不仅能够贯穿整个软件栈，还能够深入到底层硬件。因此，这已经不仅仅是一个软件问题。它现在已经成为一个芯片层面的问题。从某种意义上说，硬件安全问题甚至更具挑战性。当然，你也可以认为，硬件漏洞相对更少，因为芯片能够实现功能的方式毕竟是有限的。但另一方面，一旦芯片已经进入量产并完成部署，问题就不再只是打一个简单补丁那么容易了。当然，你也许足够幸运，也许可以通过固件更新（firmware）解决，或许芯片中设计了冗余逻辑，或许还预留了一些额外的密码学模块，可以进行替换。但软件领域不同，一旦发现漏洞，通常可以迅速修复并发布补丁。而在硬件领域，我们直到今天仍然在应对 Spectre 和 Meltdown漏洞。这么多年过去了，它们仍然不断出现新的变种，而且几乎每周都会有新的报道。虽然已经过去很多年了，但这还只是其中一种被研究得非常透彻、文档最完整的漏洞类型。然而，情况依然如此。至于客户以及行业的真实情况，其实这并不是什么新鲜事。还是那句话：“只有偏执狂才能生存（Only the paranoid survive）。”有些企业比其他企业更加谨慎。当然，并不是所有公司都愿意公开谈论自己为什么如此谨慎。这一点，其实和过去功能安全（Functional Safety）的发展过程非常相似。对于经历过 26262 版本的人来说，应该都很熟悉。过去，人们对于安全的态度是：“不讨论安全。”“当然是安全的。”“没必要谈这个话题。”而现在则变成了：“当然必须讨论安全。”因为有法规和认证要求。法务部门不会允许你销售一颗不符合要求的芯片。如果你的产品能够贴上“安全”的标签，它的平均销售价格（ASP）就会更高。所以这不仅仅是技术问题，它还具有商业价值，至于具体采用什么方式实现，那是另外一个问题。功能安全已经从过去的一个禁忌话题，发展成为今天人人都必须面对的现实。我们必须解决它，并形成最佳实践。网络安全（Cybersecurity），至少在半导体行业，也正在经历完全相同的发展过程。再回到那些公开分享经验的客户，这件事已经在发生。Arm 就是一个典型例子，Arm 多年来一直在做这项工作，只是几周前，他们才正式公开宣布这一点。他们表示，所有处理器如今都会从硬件安全的角度进行设计，同时考虑硬件安全将如何影响整个软件系统栈。也就是说，他们会从软件到底层硬件进行整体思考，明确真正意义上的“安全”是什么，以及如何将安全融入设计之中。那么，应该如何从零开始构建安全？如何迈出第一步？如何让不同团队共同制定目标？以 Arm 为例，他们还需要让验证团队——而验证团队往往最擅长的是逆向思维（negative thinking）——真正参与其中。如果大家熟悉正向测试（positive testing）与负向测试（negative testing）的概念，就会知道，这些工作建立在形式化验证（formal verification）的基础之上。不过，虽然形式化验证非常重要，但它也存在明显的规模限制。它只能验证在特定工作负载（workloads）下，软件如何运行在硬件之上，并针对这些工作负载进行验证。它对于某些场景非常有效，但它必须与其他方法结合使用。实现这一目标的方法有很多。例如，是否可以基于CWE（Common Weakness Enumeration，通用缺陷枚举）建立最佳实践？是否能够结合各种实践方法、测试以及负向测试，对整个设计进行统一编排（orchestrate），从而形成一种能够在运行时执行、完成部署、实现规模化，并最终向整个产品链持续推广（propagated downstream）的安全体系？答案是：可以。未来它还会继续演进吗？会。目前也确实已经存在相应的解决方案。

Hinkel： 我们的客户类型非常多样。有些客户专门针对安全建立了大量文档和详细的规格说明。还有一些客户拥有规模庞大的安全团队，他们安全团队的人数，甚至可能比一些使用他们产品的公司总员工数还要多。另外，还有一些客户只有最基础的规格说明，本质上不过是一份市场经理整理出来的项目要点清单，可能会提到密码学（cryptography）之类的内容。但是，他们对软件几乎一无所知。因为他们只是做硬件的。再进一步的客户，则会让软件团队参与进来，这样至少软件层面的需求能够得到覆盖。他们知道从软件角度需要完成哪些工作，因此也会提出更多安全需求。而我们最常遇到的，则是中间这一大类客户。他们认为自己懂安全，但实际上并没有真正理解，因为他们大多是靠自学摸索出来的。我刚进入这个行业时，从安全角度接触到的第一个概念，就是 CIA——保密性（Confidentiality）、完整性（Integrity）和可用性（Availability）。很多年以来，整个行业对安全的关注主要集中在完整性上。人们并没有真正理解可用性的重要性。而如今，可用性已经变得极其重要，原因有两个。第一，如果系统是自动驾驶系统或其他自主系统，那么它的功能必须始终保持可用。否则，整个系统都有可能失效。严重时，甚至可能造成人员死亡或其他严重后果。这又回到了功能安全的话题。功能安全本身就投入了大量精力来保障完整性和可用性。第二，当我们谈到黑客攻击时，大多数人首先想到的是数据窃取，或者设备被攻击者控制等情况。但实际上，最危险、也最容易实施的一种攻击，就是拒绝服务攻击（Denial of Service）。攻击者只需要切断通信，或者中断系统中某个关键环节，就能够造成经济损失。如果他们更聪明一点，他们甚至会把这种攻击设计成可以随时开启、随时关闭。然后告诉你：“这是我的加密货币钱包地址，把钱转过来。”这种情况屡见不鲜。这是目前最主要的一类攻击。很多人认为，这类攻击主要源于电子邮件钓鱼等手段。实际上，它同样发生在各种设备上。甚至有整座城市的供水系统曾经因此被勒索，遗憾的是，目前还没有完善的报告机制。很多情况下，即使发生了安全事件，也没有法律要求必须公开披露。我认为，这种情况应该改变。目前，金融机构以及部分特定行业已经被要求强制报告安全事件。但许多支付赎金的组织仍然没有义务报告。否则，人们会更加重视这个问题。未来，安全领域的信息透明度（transparency），以及整个安全市场的透明度，都将变得越来越重要。

Arora： 先接着谈可用性。曾经有一段时间，拒绝服务攻击并不在我们的安全考虑范围之内。CrowdStrike 事件也是如此。但如今情况已经完全不同。这类事件足以让整个世界陷入混乱。我们现在看到，大量工作都依赖于微服务（microservices），而这正与可用性密切相关。确保产品始终可用，已经成为任何安全基础架构都必须具备的一项最低要求。实现这一目标主要有两种方式。一种是在攻击发生后尽快完成检测并实施修复。另一种，则是通过物理层检测等手段，尽可能彻底避免攻击发生。然而，如今物理攻击的门槛已经大幅降低。借助AI的帮助，实施攻击变得异常容易。过去一次物理攻击可能需要投入数百万美元，现在已经完全不是这样了。现在这类攻击的成本低得多。甚至可以直接委托第三方实验室完成其中一部分工作。因此，这已经不再只是国家级攻击者的能力，普通攻击者同样能够做到。所以在安全基础架构中，必须具备这样的能力，使整个架构拥有足够的韧性。随着SoC变得越来越复杂，你必须真正理解整个SoC的结构，以及它所面临的攻击面（attack profile），才能够有效保护它。例如，一颗复杂的SoC可能包含约200个电源节点（power nodes）。芯片会不断遭受攻击，频繁地进出各种域。在这种情况下，如何确保信任根（Root of Trust），或者其他安全处理器，能够真正发挥作用？它必须能够全面、透明地感知整个系统正在发生什么。另外，我还看到，安全机制正在不断演进。以前安全更多是基于权限控制。例如：“允许访问这个。”“禁止访问那个。”现在安全将更多基于上下文（context）进行判断。例如：“为什么我的NPU正在访问蓝牙协议栈（Bluetooth stack）的内存？”安全系统应该能够识别这种异常行为。因此，它必须具备更强的自适应能力和韧性，而这些能力都需要由底层安全基础架构来提供支持。随着攻击越来越多、攻击成本越来越低，我们必须建立一套能够保障整个信任体系的基础架构。这种保障不仅覆盖安全启动，还必须覆盖运行时，并贯穿产品的整个生命周期。