💻 computer science

SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow

本文提出了 SPARC，这是一个自动化的硅前框架，它利用宏单元级的信息流追踪技术，能够高效地检测、评估并精准定位处理器设计中功耗侧信道泄漏的具体硬件与软件根因，且与现有方法相比实现了显著的仿真加速。

原作者： Andrija Nešković, Christian Ewert, Mladen Berekovic, Saleh Mulhem

发布于 2026-07-28

📖 1 分钟阅读☕ 轻松阅读

原作者： Andrija Nešković, Christian Ewert, Mladen Berekovic, Saleh Mulhem

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你有一份美味蛋糕的超级秘密食谱。你把它写下来，锁进保险箱，然后交给一个机器人去烘焙。你以为自己很安全，因为机器人读不懂你的笔记。但如果机器人的烤箱在搅拌糖和搅拌面粉时发出的“嗡嗡”声不一样呢？或者如果机器人在处理秘密配料时，它的功率计闪烁得稍微亮了一点点呢？站在旁边的狡猾小偷可以通过听这些嗡嗡声或观察功率计，在从未见过笔记的情况下，推断出你的食谱。这就是在计算机芯片领域中“功耗侧信道攻击”（power side-channel attacks）令人胆战心惊的现实。现代计算机就像这些机器人一样；它们使用电力来处理秘密数据（如你的密码或加密密钥）。每当芯片内部的一个微小开关开启或关闭时，它都会消耗一点点电量。如果这些电力的跳变模式取决于秘密数据，那么聪明的攻击者就可以通过监听功耗来窃取秘密。

为了阻止这种情况，工程师需要在芯片物理制造之前（一个被称为“前硅”阶段）对其设计进行检查。他们需要准确找出芯片是在哪里以及何时通过其功耗无意中“泄露”了秘密。问题在于，现代芯片极其复杂，拥有数十亿个微小的部件。试图检查每一个部件，就像试图通过逐一查看每一根干草来寻找一根特定的针——这既耗时漫长，往往也是不可能实现的。现有的工具要么太慢，无法处理大型设计，要么无法告诉你究竟是软件中的哪条特定指令或硬件中的哪根特定导线导致了泄漏。它们只会告诉你：“嘿，某处存在泄漏，”但不会给你修复它所需的地图。

于是有了 SPARC，这是由研究人员 Andrija Nešković 及其团队推出的一种新型自动化侦探工具。把 SPARC 想象成一名超级聪明、高速运转的安全警卫，它不仅观察整栋建筑，还戴着一副特殊的“有色眼镜”，只能看到那些与秘密数据接触的部分。SPARC 并没有检查处理器中的每一根导线，而是使用一种叫做“信息流追踪”（Information Flow Tracking）的技术，将秘密数据标记出来，使其在芯片中移动。然后，它构建了一个特殊的芯片“影子”版本，该版本只关注携带这些被标记秘密的导线。

以下是 SPARC 如何破解谜题的：

标记（The Tagging）： 当芯片运行一个秘密程序（如加密算法）时，SPARC 会对数据进行标记。这就像是在每一件秘密信息上贴上一个发光的贴纸。
影子（The Shadow）： SPARC 创建了一个简化且运行快速的芯片版本，它只追踪这些发光的贴纸，忽略其他一切。这使得模拟过程极其快速——比处理类似设计的以往方法快了约 8 倍。
监听（The Listening）： 随着芯片的运行，SPARC 会测量这些发光贴纸的“功率”。它使用一种统计测试（一种高级数学方法，用于判断某种模式是由于偶然还是由于设计导致的）来精准捕捉芯片在哪些时刻泄露了秘密。
根因分析（The Root Cause）： 这是最神奇的部分。一旦 SPARC 发现泄漏，它并不会止步于此。它会将发光的贴纸追溯回导致硬件导线闪烁的精确位置，以及导致该现象的软件中精确的代码行。它会告诉工程师：“嘿，秘密之所以泄露，是因为程序中的这条特定指令与芯片中的这个特定寄存器发生了交互。”

研究人员在三种不同类型的计算机处理器（用于简单任务的小型处理器和用于复杂工作的强大处理器）以及两种不同类型的秘密数学运算（经典的 AES 代码和一种新的量子抗性代码 ML-KEM）上测试了 SPARC。他们发现，SPARC 不仅能成功识别已知的泄漏，甚至还能发现“乱序执行”（out-of-order）处理器中隐藏的、更隐蔽的新型泄漏——即使软件试图隐藏这些秘密，这些泄漏依然存在。

例如，在其中一个处理器上，尽管软件使用了“掩码”（masking，一种通过使秘密看起来随机来保护它的技术）技术，但 SPARC 发现芯片内部的“重排序缓冲区”（reorder buffer，即指令的等待室）仍会通过其功耗无意中泄露秘密的形态。SPARC 精确地指出了负责这一现象的特定硬件信号和特定的软件指令。

结果令人振奋：SPARC 可以在短短几小时内（对于简单的任务甚至只需几分钟）分析一个运行大规模加密任务的复杂处理器，而旧方法可能会耗时数天甚至完全失败。通过为工程师提供一份关于“什么在泄漏”以及“为什么泄漏”的清晰地图，SPARC 帮助他们在芯片制造之前修复设计，让未来的计算机更难被黑客攻击。这就像是给厨师一份清单，准确列出是哪些食材让烤箱发出了嗡嗡声，以便他们在别人偷走秘密之前，修改食谱或改进烤箱设计。

技术摘要：SPARC – 预硅阶段功耗侧信道泄漏的自动化根因分析

1. 问题陈述

功耗侧信道泄漏（PSCL）对密码学软件的机密性构成了严重威胁，这种威胁源于处理器设计中的架构和微架构伪影。尽管目前已存在软件和硬件层面的防护措施（如掩码技术），但 CPU 层级的漏洞仍可能破坏这些保护机制。在**预硅（pre-silicon）**评估领域存在一个关键空白：现有框架无法同时提供可扩展性、秘密敏感性以及硬件与软件联合的根因归因能力。

现有方法存在以下根本性局限：

门级分析（Gate-level analysis）： 依赖于完整的门级网表，导致运行时间极长（例如，对于包含约 10 万个单元的设计，运行时间超过 60 小时）。
软件/指令集架构（ISA）级分析： 通常忽略了大部分开关活动，或无法将泄漏归因于底层的硬件信号。
可扩展性与精度的权衡： 目前尚无框架能在预硅语境下提供一种可扩展的方法，用以识别何时发生泄漏、哪些硬件信号产生了贡献，以及哪些软件指令触发了这些泄漏。

2. 方法论：SPARC 框架

SPARC 是一个自动化的框架，旨在直接从仿真中评估 PSCL 并进行根因分析。它运行在宏单元级（macro-cell level），作为高层 RTL 与底层门级网表之间的中间抽象层。该层将设计表示为参数化功能原语（加法器、多路复用器、比较器）的图，在保留语义结构的同时，避免了 HDL 的复杂性和门级分析的可扩展性问题。

该框架分为四个阶段运行：

2.1 插桩（宏单元 IFT）

SPARC 使用专门的转换过程（实现为 Yosys pass）为 RTL 设计插桩，引入**信息流追踪（IFT）**和泄漏估计逻辑。

污点传播（Taint Propagation）： 它追踪硬件中秘密数据（如加密密钥）的可达性。
泄漏阴影（Leakage Shadows）： 为每个信号 $s$ $s$ 生成一个泄漏阴影 $s_{leak}$ $s_{l e ak}$ 。如果一个信号既是受污的（受秘密影响）又是变化的（发生状态切换），则被视为存在泄漏。
- 对于时序元件： $s_{leak}[i][t] = (s[i][t] \oplus s[i][t-1]) \land s_{t0}[i][t]$ ，其中 XOR 用于检测变化，AND 用于强制执行密钥依赖性。
- 对于组合逻辑节点：采用保守模型（ $s_{leak} = s_{t0}$ ），假设任何输出变化即为泄漏传播。

2.2 量化

插桩过程将每个信号的泄漏指标聚合为每个仿真周期的标量计数器，以模拟动态功耗：

汉明重量（HW）计数器： 计算持有逻辑 1 值的受污比特数量（模拟与电荷相关的功耗）。
汉明距离（HD）计数器： 计算自前一周期以来发生变化的受污比特数量（模拟基于变化的功耗）。
这些计数器提供了周期精确的密钥相关动态功耗代理，并可配置为针对特定模块或整个设计。

2.3 泄漏评估（TVLA）

为了检测泄漏，SPARC 采用基于 Welch's $t$ -检验的测试向量泄漏评估（TVLA）。

轨迹生成： 生成匹配的成对仿真轨迹，其中明文和掩码随机性是相同的，但密钥不同（ $K_0$ vs. $K_1$ ）。
假设检验： 在每个仿真周期，对各轨迹组中的 HW/HD 计数器值进行比较。
判定准则： 如果 $|t| > 4.5$ ，则将该周期分类为存在泄漏。这识别了特定时间间隔内，经过污点过滤后的聚合开关活动在统计上依赖于密钥。

2.4 根因归因

一旦识别出泄漏区间，SPARC 执行两阶段归因：

信号级归因： 在泄漏窗口内，对比不同密钥组之间的单个泄漏阴影线。信号按累积的密钥相关汉明重量差值（ $\Delta_s$ ）进行排名，以识别主要的泄漏载体硬件信号。
指令级归因： 将仿真期间记录的程序计数器（PC）值映射到源代码级的函数和行号。这实现了将特定的硬件信号与正在执行的软件指令（例如特定的加载/存储或分支操作）联系起来。

3. 核心贡献

宏单元级 IFT： 在宏单元级部署 IFT，实现了跨硬件信号和软件指令的、可扩展的泄漏源识别，弥合了 RTL 与门级分析之间的鸿沟。
自动双重根因分析： 该框架提供了一个独特的流水线，能够检测泄漏周期、精准定位特定硬件信号，并将其映射回正在执行的软件指令。
可扩展的仿真环境： 集成到 Verilator 中的专用转换过程允许执行加密软件并收集密钥相关的泄漏轨迹，与门级方法相比，显著降低了运行时开销。
定量泄漏建模： 将 IFT 扩展到同时模拟基于数值（HW）和基于变化（HD）的泄漏，提供了一种快速、可扩展的预硅评估流程。

4. 实验结果

该框架在三个具有不同微架构复杂度的开源 RISC-V 处理器上进行了验证：

Ibex： 2 级顺序执行，32 位（RV32IMC）。
Proteus： 可配置的乱序超标量，32 位（RV32IM）。
Rocket： 5 级顺序执行，64 位（RV64G）。

工作负载：

AES-128（未掩码和一阶布尔掩码版本）。
ML-KEM (CRYSTALS-Kyber-512, 未掩码)。

研究发现：

泄漏检测： SPARC 成功检测到了所有“处理器-算法”组合中的密钥相关泄漏，并将泄漏定位到特定的仿真周期。
微架构泄漏： 在 Proteus 处理器上的掩码 AES-128 实现中，SPARC 识别出了微架构泄漏伪影（具体涉及重排序缓冲区、分支目标预测器和 AXI 总线），这些伪影违反了掩码假设，使得尽管有第一阶软件保护，密钥相关信息仍被暴露。
根因精度： 框架成功地将泄漏峰值映射到特定的硬件信号（例如 Scheduler_rob_ssbPredictorEntries）和软件指令（例如 add_round_key, memcpy）。
性能： 在处理同类设计时，SPARC 实现了比以往方法（如 Telescope）8 倍的单条轨迹仿真加速。
- 在复杂的 Proteus 核心上完成 AES（掩码和未掩码）的总评估时间 < 25 分钟。
- 在 Proteus 上完成 Kyber-512 的总评估时间 ~ 10 小时。
- 插桩开销处于合理范围（复杂处理器 < 9 分钟），且设计规模仅增加了约 11-12%。

5. 重要性与主张

论文声称 SPARC 提供了一个在设计流程早期缓解 PSCL 的实用框架。通过在预硅阶段实现精确且可扩展的根因分析，它允许硬件设计师修改 RTL（例如，实现专门的密钥加载路径或清除持有秘密的状态），同时也允许软件开发者重构加密操作。

作者强调，SPARC 解决了根因分析中的“三个基本问题”：

RQ1： 设计在哪些仿真周期发生泄漏？
RQ2： 哪些信号对泄漏做出了贡献？
RQ3： 哪些软件指令导致了泄漏？

这项工作将该工具定位为设计阶段进行**“评估–修改–再评估”快速迭代**的工具，这与那些针对最终设计提供保证但计算成本极高的形式化验证工具有所区别。该框架旨在通过在设计阶段识别并修复泄漏源，从而增强未来处理器的安全性。