💻 computer science

Controller Datapath Aware Verification of Masked Hardware Generated via High Level Synthesis

本文提出了一种名为 MaskedHLSVerif 的硬件掩码验证策略，通过针对高综合（HLS）生成的控制器数据路径进行状态级形式化验证，有效解决了现有工具在处理资源复用架构时产生的误报问题，并能够准确检测由 HLS 优化引发的掩码缺陷。

原作者： Nilotpola Sarma, Vaishali Ghanshyam Chaudhuri, Chandan Karfa

发布于 2026-03-20

📖 1 分钟阅读☕ 轻松阅读

原作者： Nilotpola Sarma, Vaishali Ghanshyam Chaudhuri, Chandan Karfa

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

这篇论文讲述了一个关于**“如何确保加密芯片安全”的故事，特别是当这些芯片是由“自动编程机器人”（高级综合工具，HLS）**制造的时候。

为了让你更容易理解，我们可以把整个过程想象成**“建造一座防窃听的秘密银行”**。

1. 背景：为什么要“打码”？（Masking）

想象一下，黑客想偷银行金库的密码。他们不直接撬锁，而是通过监听银行大门开关时的电流声（功耗侧信道攻击）来猜密码。

普通做法：直接处理密码，电流声会暴露密码。
打码做法（Masking）：把密码拆成几份（比如分成“上半部分”和“下半部分”），再加上一些毫无意义的随机噪音。
- 黑客听到的只是“噪音 + 上半部分”和“噪音 + 下半部分”的混合声，根本猜不出真正的密码。
- 这就是**“掩码技术”**，它是保护芯片安全的盾牌。

2. 问题：自动造房机器人的“偷懒”（HLS 的副作用）

以前，造这种防窃听的芯片需要顶级专家手工设计，非常慢且容易出错。
现在，工程师们发明了一种**“自动编程机器人”（HLS 工具）**。你只需要给它一份写好的“打码软件说明书”（C 语言代码），它就能自动把它变成“硬件图纸”（RTL 代码）。

优点：速度快，省人力。
缺点：这个机器人不懂安全，它只在乎**“怎么造得最快、最省材料”**。
- 为了省材料，机器人会把本来应该分开用的“计算器”（乘法器）共用。
- 为了省时间，它会重新排列计算步骤（比如把先算 A 再算 B，改成先算 B 再算 A）。

这就出大问题了！
虽然功能上（算出来的结果）是对的，但在安全上，这种“共用”和“重排”可能会让原本被拆散的密码碎片重新凑在一起，或者让噪音失效。黑客又能通过电流声猜出密码了！

3. 旧工具的失败：瞎猜的“安检员”

以前，人们用一种叫 REBECCA 的“安检员”（验证工具）来检查这些芯片图纸。

它的逻辑：它看着图纸，心想：“这个计算器（多路复用器）理论上可以连接 A、B、C、D 任何输入。”
它的错误：它不管**“实际上”机器人有没有安排 A 和 B 同时工作。它假设所有理论上可能的组合**都会发生，然后去检查这些组合是否安全。
结果：它发现了很多**“假警报”（False Positives）**。
- 比喻：就像安检员看着一扇平时只走 VIP 的电梯，却假设“如果普通人强行挤进去会发生什么”，然后大喊“这里不安全！”。其实电梯根本不会让普通人挤进去，所以是安全的。但安检员不懂电梯的控制逻辑，误报了。

4. 新方案：聪明的“状态检查员”（MaskedHLSVerif）

这篇论文的作者开发了一个新工具叫 MaskedHLSVerif。

核心思想：它不再瞎猜，而是看懂机器人的“排班表”（有限状态机 FSM）。
怎么做：
1. 分而治之：它把整个设计按“时间片”拆开。比如，第一秒机器人只在做任务 A，第二秒只做任务 B。
2. 只看当下：在检查第一秒时，它只关心第一秒真正会发生的输入组合。它知道第二秒的任务在第一秒是不可能发生的，所以直接忽略。
3. 逐个击破：它把整个大工程拆成几个小任务，一个一个地用旧安检员（REBECCA）去检查。
比喻：
- 旧安检员：看着整个大楼的平面图，假设“如果有人在 1 楼同时按 10 楼的按钮会怎样”，然后报警。
- 新安检员：拿着**“值班表”**，走到 1 楼时，只看 1 楼正在发生的事；走到 10 楼时，只看 10 楼正在发生的事。它知道 1 楼的人按不了 10 楼的按钮，所以不会瞎报警。

5. 成果：不仅防误报，还能抓真凶

作者用这个新工具测试了 6 个著名的加密算法（比如 PRESENT 密码）：

消除误报：对于自动生成的芯片，旧工具会报错说“不安全”，但新工具发现其实是安全的（因为那些危险的组合根本不会发生）。
发现真问题：作者故意让“自动机器人”开启了一个“优化功能”（重排计算顺序）。结果，新工具成功抓到了这个优化带来的真实漏洞，而旧工具因为只会瞎报警，反而可能漏掉这种具体的逻辑错误。

总结

这篇论文就像是在说：

“我们请了个自动机器人来造防窃听芯片，但它为了省材料，把零件混用了。以前的安检员太笨，看到零件能混用就报警，导致很多假警报。

我们发明了一个新安检员，它懂得看机器人的排班表，只检查真正会发生的情况。这样既消除了假警报，又能精准地发现机器人因为‘偷懒’而造成的真实安全隐患。”

这项技术让自动设计加密芯片变得更加安全、可靠且高效。

这篇论文提出了一种名为 MaskedHLSVerif 的验证流程，旨在解决由高层次综合（High-Level Synthesis, HLS）工具生成的掩码（Masked）硬件在抗侧信道攻击（PSCA）安全性验证中的关键问题。

以下是对该论文的详细技术总结：

1. 研究背景与问题 (Problem)

背景： 掩码（Masking）是防御功耗侧信道攻击（PSCA）的常用手段。手动设计掩码硬件既耗时又容易出错。因此，业界趋势是利用 HLS 工具，将经过验证的掩码软件（C/C++ 代码）自动转换为掩码 RTL 硬件，以缩短设计周期并支持设计空间探索（DSE）。
核心问题：
1. HLS 优化带来的安全隐患： HLS 工具最初并非为安全设计，其优化策略（如表达式平衡、重新关联、资源复用等）可能会破坏掩码的安全性，导致生成的 RTL 存在侧信道漏洞，尽管功能上是正确的。
2. 现有验证工具的局限性（假阳性）： 现有的硬件掩码验证工具（如 REBECCA）通常假设数据路径是静态的，或者保守地检查所有语法上可能的数据流路径。然而，HLS 生成的设计通常包含控制器（FSM）和数据路径复用（Resource-shared datapath）。在资源受限下，HLS 会在不同的时钟周期复用硬件资源（如乘法器），导致某些输入组合在特定状态下永远无法到达。
3. 假阳性（False Positives）： 现有工具（如 REBECCA）在验证此类设计时，会检查所有理论上可能的 MUX 输入组合，包括那些在 FSM 控制下实际上永远不会发生的组合。这导致工具错误地报告存在泄漏（假阳性），使得设计者无法区分真正的安全漏洞和 HLS 架构特性导致的误报。

2. 方法论 (Methodology)

论文提出了一种**状态感知（State-Aware）**的验证策略，核心思想是利用 HLS 生成的有限状态机（FSM）结构，将设计分解为状态特定的子设计进行验证。

核心流程 (MaskedHLSVerif)：
1. RTL 生成： 使用 HLS 工具将掩码软件转换为 RTL 设计。
2. 状态分解（State-wise Splitting）：
  - 分析 HLS 生成的 FSM 控制器，识别每个状态（State）下激活的数据路径操作。
  - 将原始设计 $D$ 分解为一系列状态特定的子设计 $D_x$ （对应每个 FSM 状态）。
  - 关键创新： 在构建每个子设计 $D_x$ 时，不仅包含当前状态的操作，还递归地包含所有依赖的前序状态的操作。这确保了输入信号的标签（Label）可以直接映射回原始设计的输入（Share/Mask/Public），避免了中间信号标签推导的复杂性。
3. 状态独立验证：
  - 为每个子设计 $D_x$ 生成对应的标签文件 $L_x$ 。
  - 使用现有的验证工具（如 REBECCA）对每个子设计 $D_x$ 进行独立的形式化验证。
  - 由于每个子设计只包含该状态下实际可达的输入组合，验证过程排除了不可达的 MUX 输入，从而消除了假阳性。
4. 结果聚合： 如果所有子设计 $D_x$ 均通过验证，则判定原始 HLS 生成的硬件是安全的；若任一子设计失败，则定位具体的状态和漏洞。
理论保证：
- 论文证明了状态分解的完备性（Soundness of State-wise Split）：任何执行轨迹（Trace）中的操作都至少被一个状态子设计捕获。
- 证明了验证流程的正确性：基于 REBECCA 对固定数据路径的验证能力，该流程能准确判断 HLS 生成设计的掩码安全性。

3. 主要贡献 (Key Contributions)

识别局限性： 首次明确指出了现有最先进（SOTA）的硬件掩码验证工具在处理 HLS 生成的、具有控制器 - 数据路径复用架构的设计时，会产生假阳性的根本原因。
分析 HLS 影响： 详细讨论了 HLS 前端（如重新关联、表达式平衡）和后端（资源分配、调度）优化如何具体影响掩码安全性。
提出新工具流： 开发了 MaskedHLSVerif，这是一种基于 FSM 状态分解的形式化验证方法，能够准确验证 HLS 生成的掩码硬件，避免假阳性。
实验验证： 在六个基准测试（包括级联的 DOM、COMAR、HPC1、HPC2 掩码乘法器以及 PRESENT 密码的 S 盒）上进行了验证。结果显示，现有工具（REBECCA）在这些 HLS 生成的设计上都报告了假阳性，而 MaskedHLSVerif 正确验证了它们的安全性。
漏洞检测能力： 证明了该方法不仅能验证架构，还能检测由 HLS 优化（如强制开启的“表达式平衡”pragma）引入的真实掩码漏洞。

4. 实验结果 (Results)

基准测试： 使用了 6 种不同的掩码方案（DOM, COMAR, HPC1, HPC2）和两种密码算法结构（级联乘法器、PRESENT S 盒）。
假阳性消除：
- 在 Table XI 中对比显示，对于所有 6 个 HLS 生成的设计，REBECCA 均报告了“不安全”（False），而 MaskedHLSVerif 正确报告为“安全”（True）。
- 通过 TVLA（测试向量泄露评估）实验进一步证实，这些 HLS 生成的 RTL 在物理层面上确实是安全的（t-test 值在阈值内），证明 REBECCA 的报错确实是假阳性。
真实漏洞检测：
- 在实验 2 中，作者故意在 C 代码中开启 #pragma HLS EXPRESSION_BALANCE。HLS 工具利用此优化重新关联了掩码操作，导致第二级乘法出现了一阶掩码漏洞。
- MaskedHLSVerif 成功检测到了第二状态（State 2）的验证失败，并精确定位到输出 $y_0$ 处的未掩码秘密值（Secret），而 REBECCA 由于假阳性问题无法区分此真实漏洞。

5. 意义与结论 (Significance)

填补空白： 这是首个专门针对HLS 生成掩码硬件进行形式化验证的工作。
推动自动化安全设计： 使得利用 HLS 自动从软件生成安全硬件的流程变得可行且可信，解决了“设计快但验证难/不准”的瓶颈。
方法论创新： 提出的“状态感知”验证思路不仅适用于 HLS，也为验证任何具有复杂控制流和资源复用的硬件设计提供了新的视角，即通过抽象出每个状态下的有效数据路径来简化验证空间。
未来方向： 强调了 HLS 优化对侧信道安全的影响是一个尚未被充分探索的领域，该工具为未来研究 HLS 优化与安全性之间的权衡提供了基础。

总结： 该论文通过引入状态分解策略，成功解决了现有验证工具在处理 HLS 生成的资源复用硬件时的假阳性问题，并证明了该方法既能准确验证安全设计，又能有效捕捉由 HLS 优化引入的真实安全漏洞，为安全硬件的自动化生成奠定了坚实基础。