4、多源供应链安全模型：供应链参与者、信任边界与攻击面分析
Chiplet 技术的核心特征是将单一 SoC 拆解为多个具有特定功能的裸片（Die），再通过先进封装（如 2.5D/3D 封装、硅桥、Fan-Out）集成到一个封装体内。这种范式将传统 IDM（集成设备制造商）的封闭制造流程，转变为由全球多个参与者协作完成的开放式供应链。从安全视角看，Chiplet 供应链的“多源”属性意味着信任不再是一个单一实体内部的假设，而是需要在多个独立商业实体之间建立可验证的信任链。本章将系统拆解供应链中的关键参与者、定义信任边界，并深入分析各环节的攻击面，为后续章节的防护策略奠定基础。
上图展示了 Chiplet 供应链的四个主要信任边界及其对应的攻击面。与传统的单片 SoC 供应链相比，Chiplet 的信任边界数量更多、数据交换更频繁、物理接口更复杂。下面我们将逐一深入分析每个参与者的角色、信任假设与攻击面。
4.1 供应链参与者角色与信任假设
在 Chiplet 生态中，参与者不再是简单的“设计-制造-封测”线性关系，而是形成了一个多对多的网状协作网络。每个参与者都持有部分设计数据、工艺参数或测试向量，这些数据在传递过程中需要保持机密性、完整性和可用性。
| 参与者 | 核心职责 | 信任假设 | 安全关键数据 |
|---|---|---|---|
| IP 提供商 | 提供处理器核、SerDes、NoC 等可复用的功能模块 | IP 功能与文档一致，无隐藏后门 | RTL 源码、加密核、行为模型 |
| SoC 架构师/集成商 | 选择 Chiplet、定义互连协议、完成系统集成 | 各 Chiplet 接口兼容且安全 | 系统级网表、地址映射、安全配置 |
| 晶圆代工厂 | 按 GDSII 制造裸片 | 工艺参数精确，不超量生产 | GDSII 文件、光罩数据、工艺配方 |
| 封装厂 (OSAT) | 完成 2.5D/3D 封装、TSV 成型、微凸块制作 | 封装工艺不引入物理篡改 | 封装设计文件、基板布线图 |
| 测试厂 | 执行晶圆测试 (CP) 和封装测试 (FT) | 测试向量不被泄露或篡改 | 测试程序、扫描链数据、失效日志 |
| 系统 OEM | 将 Chiplet 集成到最终产品（服务器、汽车等） | 固件与 Chiplet 驱动安全 | UEFI/BIOS、设备驱动、密钥 |
信任假设是安全模型的基础。例如，当 SoC 集成商从第三方购买一个 AI 加速 Chiplet 时，它必须假设该 Chiplet 的 RTL 代码中不存在恶意逻辑。然而，在现实中，这种假设往往过于乐观。攻击者可能通过向 IP 供应商的 EDA 工具链投毒，在综合或布局布线阶段插入硬件木马，使得最终 GDSII 与原始 RTL 不一致。
4.2 信任边界定义与传递机制
信任边界是安全域之间的分界线。在 Chiplet 供应链中，信任边界不仅存在于物理实体之间（如代工厂与封装厂），也存在于数据流和设计流程的交接点。每个信任边界都需要明确的验证机制，以确保数据在跨越边界时未被篡改。
信任边界分类：
- 设计-制造边界：GDSII 文件从设计域传递到制造域。此边界需要确保光罩数据与设计意图一致，防止恶意修改。
- 制造-封装边界：裸片从晶圆代工厂流向封装厂。此边界需要验证裸片的物理身份（通过 PUF 或序列号）和电气特性。
- 封装-测试边界：封装后的 Chiplet 进入测试环节。此边界需要保护测试向量不被窃取，同时确保测试覆盖率足够发现恶意修改。
- 测试-系统集成边界：测试通过的 Chiplet 被集成到系统板卡。此边界需要验证固件与硬件的一致性。
信任传递机制通常依赖于硬件安全模块（HSM）和公钥基础设施（PKI）。例如，设计方使用私钥对 GDSII 文件签名，代工厂使用公钥验证签名后再开始制造。然而，这种机制在 Chiplet 场景下面临挑战：一个 Chiplet 可能由多个 IP 组成，每个 IP 来自不同的供应商，签名粒度如何划分？如果每个 IP 都单独签名，封装厂需要管理大量的公钥，增加了复杂性。
4.3 攻击面深度分析
攻击面是指攻击者可以利用的入口和弱点。在 Chiplet 供应链中，攻击面分布在物理、逻辑和系统三个层面。
4.3.1 物理攻击面
物理攻击面主要存在于制造和封装环节。攻击者可能通过以下方式实施攻击：
- 光罩篡改：在光罩制作过程中，攻击者修改特定层的图形，植入硬件木马。这种攻击极其隐蔽，因为木马可能只在特定条件下激活。
- 超量生产：代工厂多生产一批裸片，用于仿冒或灰色市场销售。超量生产的裸片可能被用于构建不安全的系统。
- 微探针攻击：在封装完成后，攻击者使用聚焦离子束（FIB）或微探针台直接探测 TSV 或微凸块上的信号。Chiplet 的 3D 堆叠结构使得内部信号更容易被物理接触。
4.3.2 逻辑攻击面
逻辑攻击面涉及设计数据和测试数据的篡改。例如：
- EDA 工具链投毒：攻击者入侵 EDA 工具的许可证服务器或更新服务器，在工具中植入恶意代码，使得工具在综合时自动插入后门逻辑。
- 测试向量泄露：测试向量包含了芯片的内部状态信息，攻击者通过窃取测试向量可以逆向工程芯片的逻辑结构。
- 固件更新劫持：在系统集成阶段，攻击者通过伪造固件更新包，将恶意固件刷入 Chiplet 的引导 ROM 中。
4.3.3 系统攻击面
系统攻击面关注 Chiplet 之间的互连和通信。由于 Chiplet 通过 NoC（片上网络）或 SerDes 进行通信，攻击者可能通过恶意 Chiplet 向其他 Chiplet 发送伪造消息，破坏系统的隔离性。
风险提示：在 Chiplet 架构中，一个恶意的第三方 Chiplet 可能通过共享的 NoC 发起侧信道攻击，窃取相邻 Chiplet 正在处理的敏感数据（如加密密钥）。这种攻击在传统单片 SoC 中不存在，因为所有模块都在同一个信任域内。
4.4 案例拆解：自动驾驶域控制器中的 Chiplet 供应链攻击
为了更直观地理解多源供应链的安全风险，我们分析一个自动驾驶域控制器的案例。该控制器集成了来自不同供应商的四个 Chiplet：主计算 Chiplet（供应商 A）、AI 加速 Chiplet（供应商 B）、安全岛 Chiplet（供应商 C）和通信 Chiplet（供应商 D）。
背景与约束：该域控制器需要满足 ISO 26262 ASIL-D 功能安全等级，同时需要抵御恶意攻击。供应链分布在全球多个国家和地区，每个供应商都有独立的开发环境和制造工厂。
初始现象：在系统级测试中，安全岛 Chiplet 偶尔报告虚假的故障信号，导致系统误触发紧急制动。起初工程师认为是软件 bug，但经过数周排查，发现故障信号与 AI 加速 Chiplet 的负载高度相关。
分析过程：
- 工程师首先检查了安全岛 Chiplet 的固件版本，确认固件未被篡改。
- 使用逻辑分析仪抓取 NoC 上的数据包，发现 AI 加速 Chiplet 在特定条件下会向安全岛 Chiplet 发送异常的控制消息。
- 进一步分析 AI 加速 Chiplet 的 GDSII 数据，发现其 NoC 接口逻辑中有一个未在 RTL 中出现的状态机。该状态机在收到特定序列的输入时，会向安全岛发送伪造的故障信号。
- 追溯该状态机的来源，发现它是在综合阶段由 EDA 工具自动插入的。进一步调查发现，供应商 B 使用的 EDA 工具版本已被植入恶意补丁。
实际操作步骤：
- 立即隔离 AI 加速 Chiplet，将其从 NoC 中逻辑断开。
- 与供应商 B 联合调查，确认恶意补丁的来源，并更新 EDA 工具。
- 对所有 Chiplet 的 GDSII 进行差异比对，检查是否存在其他未声明的逻辑。
- 在安全岛 Chiplet 中增加消息认证机制，拒绝来自非信任源的 NoC 消息。
结果与复盘：通过上述措施，系统恢复了正常。但此次事件暴露了多源供应链的深层问题：即使每个供应商都声称其设计是安全的，但工具链的信任缺失可能导致最终产品存在漏洞。复盘经验包括：
- 必须对 EDA 工具链进行完整性校验，不能盲目信任供应商提供的工具。
- 在 Chiplet 接口层面增加硬件安全机制（如消息认证码），而不是仅依赖软件层防护。
- 建立跨供应商的安全审计机制，定期交换安全事件信息。
4.5 常见误区与总结复盘
在构建 Chiplet 多源供应链安全模型时，常见以下误区：
误区一：认为只要每个供应商都通过 ISO 27001 认证，供应链就是安全的。实际上，ISO 27001 关注的是信息安全管理体系，并不覆盖硬件木马检测或物理攻击防护。
误区二：将信任边界等同于公司边界。在 Chiplet 场景下，同一家公司内部的不同部门（如设计部门和测试部门）之间也可能存在信任边界。
误区三：忽视数据格式转换过程中的安全风险。GDSII 转换为 OASIS 格式时，可能丢失安全属性（如加密标记），导致后续环节无法验证数据完整性。
总结：多源供应链安全模型的核心是“不信任，必验证”。每个参与者都需要对其接收的数据和硬件进行独立验证，而不是依赖上游的信任声明。信任边界应基于数据流和物理接口来定义，而不是基于组织架构。攻击面分析需要覆盖物理、逻辑和系统三个层面，并定期进行安全评估和渗透测试。