芯片安全：从勾选式合规走向持续防御

核心要点

1. 硬件安全已经不能再当作附加可选功能。如今攻击已经横跨芯片、软件栈、网络、固件、FPGA 以及各类互联系统。

2. 《欧盟网络安全法案》（CRA）等法规提升了行业安全意识，倒逼企业投入安全建设，但获得认证并不代表产品真正安全。

3. 零日漏洞、AI 驱动攻击、芯粒架构让验证工作愈发复杂，对软硬件组件的透明可视能力变得不可或缺，包括物料清单、漏洞追踪、上线后持续监测。

圆桌访谈嘉宾

如今威胁已经蔓延至硬件、固件、软件、网络以及新兴芯粒架构，半导体企业不得不重新审视安全：安全不再是一纸认证，而是贯穿设计、部署、监测全流程的持续性工作。半导体工程网组织闭门圆桌会谈，探讨相关议题，参会嘉宾包括：ArterisIP 执行副总裁、首席产品营销官、安全解决方案总经理 Michal Siwinski；楷登电子高级应用工程师 Yathiendra Vunnam；是德科技高级总监兼产品组合经理 Alexander Petr；Rambus 硅安全产品高级总监 Scott Best；西门子明导静态与形式化验证产品管理总监 Chris Giles；新思科技架构高级总监 Mohit Arora；新思科技安全、处理器、无线及非易失性存储器战略项目总监 Reed Hinkel。本次圆桌于设计自动化大会（DAC）闭门举办，下文为访谈节选。阅读访谈第一部分，请点击：芯片下一次重大失效或许来自安全漏洞。

图 1：从左至右：新思科技 Arora；新思科技 Hinkel；Arteris 的 Siwinski；楷登电子 Vunnam；是德科技 Petr；Rambus 的 Best；西门子 Giles。

SE（采访方）：客户是否已经具备成体系的安全追踪落地计划？

Vunnam：我们看到很多客户在采用纵深防御方案。针对 OSI 网络模型的每一层，客户都会部署不同的安全处理单元，例如 IPsec、MACsec 等。受高算力需求驱动，客户需要这类组件实现高性能。我们观察到大量客户优先追求安全认证，这是产品商业化销售的现实诉求。 但也有另一种工作模式：客户先罗列出全部安全需求，再做筛选取舍。他们会权衡：“我们不需要所有模块都做到最高性能，那会带来更大面积开销。” 客户希望精简方案，拿到可即插即用的最终 IP 核。 同时开源计算生态热度很高，例如 OCP 项目下的 Caliptra 安全框架，这也是行业热议话题，在芯粒场景具备巨大潜力。可以把子系统部署在一颗独立芯粒上，直接即插即用。各个模块不必全部采用最先进工艺节点，以此降低器件成本。 但这也是当前最大的障碍：如何验证一颗芯粒是否安全？如何区分安全与不安全的芯粒？

Petr：我们首先要分清两类威胁：物理攻击，还是软件攻击。当下的复杂度来源于软件在技术栈中越陷越深，这里特指嵌入式软件。再看数据中心的构建逻辑：从 IC 芯片，到封装级、板级，再到整机系统，系统之间相互联网，最终形成规模堪比城镇的全域互联体系。网络成为攻击高发的瓶颈，而攻击载体就是软件。 现代系统中大量使用 FPGA，FPGA 具备可编程特性，也就引入可编程逻辑。风险不只是硬件本身故障；既会遭遇物理攻击，更常见的是攻击者经由网络、软件栈，在系统内部触发拒绝服务等恶意行为，这类案例随处可见。 多层防御体系的思路是：一旦检测到异常，就在各个层级植入防护能力。行业普遍在做左移，安全能力不断下沉，甚至下沉到 FPGA 层面。由此引出一个问题：如何看清流入产品内部的全部内容？硬件对应的软件物料清单（SBOM）重要性大幅提升，绝大多数攻击都来源于此。尤其是 AI 攻击，大多经由网络入侵，触发系统异常。 FPGA 以及其他可编程单元的大量软件都属于嵌入式软件。如今驱动硬件的各类框架，全部带有软件层。只要使用开源软件，就会引入潜在威胁。已经出现恶意势力渗透开源社区，植入后门的案例。 所以，仅仅清楚自己使用了哪些组件远远不够。更大的难题是：你使用的组件当下看似安全，但后续被爆出零日漏洞，就会被攻击者利用。因此每一层都必须部署防御，前提就是具备可见性。如果不清楚系统内部存在什么组件，就无法开展追踪。假设爆出一个全新零日漏洞，你能不能判断自己的系统是否受影响？如何判定？这本身就是巨大挑战。如果确实受影响，能否修复、能否做好防御？

Best：这里涉及个人乃至企业层面的责任追溯。客户当然清楚安全的重要性，但重视程度参差不齐。电影《大空头》里有一段经典桥段：交易员质问评级机构，“明知道这些产品一文不值，怎么还敢给出 AAA 评级？” 评级机构的答复是：不给 AAA 评级，客户就不会买单。整个行业被这套体系裹挟。 很多客户找到我们，提出需求：“我需要侧信道防护、故障注入攻击防护、PUF 物理不可克隆技术。” 我们会回复：“这些我们都可以提供，很高兴你提出了正确问题。但你打算如何部署这些能力？如何真正把它融入系统？” 这时客户常会回复：“系统是我们自己的事，你们只是 IP 供应商。” 对他们而言，安全只是走流程勾选的采购项：“我具备侧信道防护、拥有 PUF，满足 CRA 法规、满足 ISO 26262，去找是德科技或者别家机构拿到 SESIP 物联网平台安全评估 3 级认证。” 但拿到认证就代表产品真正安全吗？

Hinkel：这不过是拿到对外宣传的 “AAA 评级”，方便产品推向市场而已。

Best：我并非刻意唱衰，但背后牵扯巨大商业利益。

Giles：我完全认同。行业客户的安全认知与落地水平参差不齐，同时还需要外部激励。所有人都希望控制成本、快速交付产品，安全往往取决于项目优先级。嘴上承认安全很有必要，但实际投入的资源会如实反映优先级。 如何提升安全的优先级？需要激励与约束并举。CRA 这类法规可以发挥作用，但立法只是第一步。想要推动企业把安全投入提升到应有水平，严格执法必不可少。

Petr：大家认为 NIST 安全软件开发框架（SSDF）以及欧盟 CRA 法规，是否真正改变了各个行业？

Giles：法规提升了安全意识，CRA 已经成为高频讨论话题。但是否真正改变企业实际行为，我持怀疑态度。

Petr：至今还没有企业收到罚单。

SE：CRA 针对半导体行业的生效截止日期是什么时候？

Siwinski：对半导体企业具备实际约束力的关键时间点，是今年 9 月 11 日。

Petr：有一个关键问题：漏洞披露之后，会不会引来恶意攻击者针对性试探？

Siwinski：就像刚刚讨论的，我们要披露的到底是什么？难道只是一张合规贴纸，满足法务要求，自我安慰 “我已经做完安全工作”？

Petr：法规要求必须披露软件栈内已知漏洞。

Siwinski：受监管的不只是电子设备自带软件栈，还包含接入设备的各类软硬件组件。这正是难点所在，监管对象不局限于软件。

Petr：那现在只能寄希望于运气。

Giles：后续落地执行才是重头戏。很多监管法案都会出现类似情况：临近截止日期，企业才发现落地成本极高，然后纷纷呼吁延期一年、两年，甚至修改法案条文。

Petr：SSDF 就出现过类似情况，原定时间在前年，之后政府换届，相关安排发生变动。

Hinkel：CRA 整体带来积极改变。面向全球销售的客户明白，自己必须为下游客户提供安全支撑。过去他们会说 “客户不愿为此付费”，现在已经不能这么推脱。当然世界上依然存在不愿为安全买单的市场，大家心知肚明。 我也观察到一些原本态度保守的企业，开始在芯片上部署规模空前的信任根，体量远超以往各类方案。部分企业采纳 OCP 标准，把信任根植入芯片。很多原本坚决拒绝的企业，现在都选择接受。

Arora：补充一点，CRA 的处罚力度很高，最高可处以企业年营收 4% 的罚款。企业规模越大，面临的法律风险越高。

Siwinski：本质就是奖惩并举。只要处罚这根大棒真正落地几次，其他企业就会主动规避处罚风险。

Hinkel：我多次和客户探讨正向激励因素，回到 Scott 刚刚提到的观点：需要保护资产的价值，才是安全最核心驱动力。如果企业依靠服务盈利，就必须高度重视安全。高价值服务会处理个人信息、密码、密钥等敏感数据，由此形成正向循环。 以 iPhone 举例，售价维持甚至高于初代发布水平。根源在于用户完全信任它可以保管个人重要数据。苹果持续在安全上加码，增加多层防护，单台设备安全相关投入从几美元增长到数百美元。换来的回报是：产品售价可以达到竞品的两到三倍，这份信任又反哺业务服务。 工程评审会上，如果产品经理在场，沟通效果最好。产品经理会提出诉求：“我希望打造差异化，希望对外提供付费服务。” 这时我们就要点透背后代价：“想要落地高价值服务，就必须配套服务等级协议，并且严格履约。” 否则客户乃至政府会追责，面临罚款、诉讼。欧洲是政府罚金，美国更多是民事诉讼，司法体系已经逐步受理这类案件。企业高管层越来越重视安全，向下传导压力。但产品经理必须认清现实：想要在设备上运行高价值服务，相比仅实现基础功能的设备，硬件层面就要付出更高成本。

Petr：美国军方也在拉动安全领域投入。美国国防部及其供应链厂商，例如波音、空客，会持续对安全提出严苛要求。

SE：我们换一个相关话题，还没有聊过后量子密码（PQC）。美国政府近期收紧时间节点，要求产品具备抗量子攻击能力。

Best：政府先是暂停相关时间表，之后又把截止时间提前。

Hinkel：研读行政令之后，我的判断是：并没有真正提前硬性时间节点，时间基准本身没有改动。只是不同解读，造成合规时间线的认知混乱。

SE：距离弃用旧密码算法还有五年。

Hinkel：五年是旧算法正式淘汰的时间窗口，完整完成全部组件替换需要周期。但产品内部必须提前部署后量子密码算法，对应的时间节点是三年。这是两个关键时间。 研读行政令还能看到，最大瓶颈不在硬件，也不在设备固件。公钥加速（PKA）产业耗费很长时间，才完成对全新算法与架构的适配。现有 PKA 属于老旧技术，层层打补丁，逻辑错综复杂，从设计之初就没有考虑大规模迭代升级的需求。如今要在这套补丁堆砌的旧架构之上实现全新能力，就必须大规模重构架构，才能支持各类混合密码方案与新业务需求。