1. 项目概述当后量子密码学遇上物理安全如果你最近在关注密码学硬件的进展尤其是那些准备应对量子计算机威胁的后量子密码PQC算法那么“侧信道攻击”和“掩码防护”这两个词一定不会陌生。我们总说PQC算法在数学上是安全的但一旦落实到芯片上运行功耗、电磁辐射这些物理信号就可能成为攻击者窃取密钥的“后门”。我最近花了不少时间研究一个具体而微的难题如何为后量子密码的核心组件——SHA-3哈希函数——设计一个既高效又安全的硬件加速器并且要实实在在地把“掩码”这种防护手段做进去而不是停留在论文公式里。这个项目的核心就是一篇题为《Accelerating First-Order Secure ML-KEM With Masked SHA-3》的学术论文。它探讨的正是这个痛点。论文指出像ML-KEMNIST标准化的后量子密钥封装机制这样的算法其运行时间有超过60%都花在了SHA-3相关的哈希计算上。如果不对这些计算进行保护整个算法的侧信道安全性就无从谈起。然而给SHA-3上掩码尤其是采用安全性更强的域定向掩码DOM方案时会带来一个非常现实的工程挑战每一轮KeccakSHA-3的核心置换函数计算都需要消耗高达1600比特的“新鲜”随机数。这个量级对于传统的真随机数发生器TRNG或简单的线性反馈移位寄存器LFSR来说都是巨大的负担但很多前期研究恰恰忽略了这部分开销。所以这篇工作的价值在于它没有只谈理想的掩码电路设计而是把一个完整的、可部署的解决方案端到了我们面前一个支持所有SHA-3/SHAKE函数的、一阶掩码的硬件加速器配套一个专门解决“随机数饥渴”问题的“随机数分发器”基于流密码Trivium/Bivium最后还把它集成到一个32位RISC-V SoC里去实际加速一个掩码版的ML-KEM解密流程。他们不仅做了FPGA和ASIC的综合评估算清了面积和性能的账还用TVLA测试向量泄漏评估方法在FPGA上实测了安全性证明了方案的有效性。接下来我就结合自己的工程经验把这个工作的里里外外、设计思路、实现细节以及那些容易踩坑的地方给大家掰开揉碎了讲清楚。2. 核心需求与挑战拆解为什么掩码SHA-3这么难在动手设计任何硬件加速器之前我们必须先彻底理解我们要解决什么问题以及为什么这个问题棘手。这个项目瞄准的是后量子密码学在嵌入式系统中的安全实现其核心需求可以分解为三个层次。2.1 需求一为PQC核心算法提供高性能哈希计算ML-KEM以及其他许多后量子算法如CRYSTALS-Dilithium严重依赖哈希函数进行伪随机数生成、承诺和密钥派生。以ML-KEM的解封装Decapsulation操作为例其算法流程中多次调用了SHA3-512作为G函数、SHAKE-256作为J函数和SHAKE-128。在纯软件实现中这些哈希函数调用是主要的性能瓶颈。因此第一个刚性需求就是提供一个高性能的SHA-3硬件加速器能够显著降低这些操作的延迟从而提升整个KEM协议的吞吐量。注意这里的“高性能”需要明确定义。对于哈希加速器常见的指标是吞吐量Gbps和每字节处理的能耗。但在这个上下文中由于集成在SoC中为软件服务更关键的指标可能是“完成一次特定哈希运算所需的时钟周期数”。论文中选择的是“每时钟周期完成一轮Keccak置换”的架构这是一个在面积和速度之间取得平衡的经典设计。2.2 需求二提供可证明的侧信道攻击防护侧信道攻击SCA通过分析设备运行时的物理泄露如功耗、电磁、时序来推断秘密信息。对于ML-KEM解密操作会使用私钥因此是SCA的主要目标。掩码是一种有效的防护手段其原理是将一个敏感数据值x分割成d1个随机份额例如对于一阶掩码d1则x x0 ⊕ x1使得攻击者需要同时获取所有份额的信息才能恢复出原始值从而将攻击复杂度从一阶提升到高阶。然而将掩码应用于SHA-3的核心——Keccak置换——并非易事。Keccak包含一个非线性的χ步骤其中涉及AND操作。在硬件中直接对掩码份额执行非线性操作会因“毛刺”而导致份额在组合逻辑中提前重组泄露信息。因此需要采用更高级的掩码方案如域定向掩码DOM它在不同“域”的边界插入寄存器并使用新鲜随机数进行“刷新”以阻断由路径延迟差异引起的毛刺传播。这正是本设计选择DOM作为基础的原因。2.3 需求三解决掩码带来的巨额随机数开销这是本项目要解决的核心工程挑战也是很多学术工作避而不谈或轻描淡写的一点。DOM方案为了在χ步骤安全地组合来自不同域的份额需要在每个时钟周期注入新鲜随机数。对于1600比特状态的Keccak且设计为每周期一轮这意味着每个时钟周期都需要1600比特全新的、不可预测的随机数。我们来算一笔账如果目标频率是100 MHz那么随机数的需求速率就是 1600 bits/cycle * 100e6 cycles/s 160 Gbps。这是一个天文数字传统的TRNG根本不可能达到这个吞吐量。使用线性反馈移位寄存器LFSR虽然速度快、面积小但其安全性存疑攻击者可能从输出序列反推内部状态。因此需要一个既能高速生成、又具备足够密码学强度的伪随机数发生器PRNG。论文中采用基于流密码Trivium/Bivium展开设计的方案正是为了在速度、面积和安全性之间取得一个可行的折衷。2.4 系统级集成与灵活性需求最后这个加速器不能是一个孤立的IP。它需要能够方便地集成到现代SoC中如通过总线内存映射并且要能灵活支持后量子密码算法中常见的混合模式即同一个算法流程中既需要对敏感数据如私钥、中间秘密进行掩码哈希计算也需要对公开数据如公钥、密文进行普通的非掩码哈希计算。因此加速器需要具备在运行时动态切换掩码与非掩码模式的能力。3. 架构设计从DOM掩码核心到随机数供给系统理解了需求和挑战我们就可以开始勾勒整个系统的架构了。整个设计可以看作是两个紧密耦合的子系统的协同一个是执行核心计算的掩码SHA-3加速器另一个是为其源源不断提供“弹药”的随机数分发器。3.1 掩码Keccak核心选型与实现论文选择了来自文献 [8] 的DOM架构作为其Keccak核心。这是一个经过精心设计、能够抵抗一阶毛刺攻击的掩码实现。其高层架构对应论文中的图3值得我们深入理解。该核心针对一阶掩码d1设计但内部操作涉及4个份额。输入数据根据所选SHA-3模式长度为速率r首先被填充并构建成4个份额。这多出来的份额是DOM方案为了满足“非完备性”安全属性而引入的。核心数据通路如下θ函数线性扩散首先在4个份额上执行θ变换。寄存器隔离θ的结果被存入4组1600比特的寄存器。这一步至关重要它不仅用于暂存每轮结果更重要的是它作为“域”的边界切断了组合逻辑毛刺的传播路径是DOM能防毛刺的关键。π◦ρ和ι◦χ变换随后进行π和ρ线性置换和循环移位接着是ι常数加和χ非线性换。设计的关键在于χ步骤的每个组件只接收一个输入份额这确保了非完备性。压缩与刷新最后通过一个压缩阶段将4个份额合并回2个份额。在域的交叉点例如从一组寄存器到下一级逻辑需要使用新鲜随机数对份额进行“刷新”操作以恢复均匀性防止信息通过联合分布泄露。这个架构实现了每时钟周期完成一轮Keccak置换对于24轮的Keccak-p[1600,24]完成一次完整的置换需要24个周期。这种设计在吞吐量和面积之间取得了较好的平衡。3.2 随机数分发器的设计流密码的工程化应用随机数分发器是本项目的创新亮点之一。它的目标很明确以每周期1600比特的速率生成密码学强度足够的伪随机数。论文评估了两种流密码Trivium和其简化版Bivium B。为什么选择流密码与分组密码或哈希函数相比流密码通常结构更简单吞吐量更高更适合生成连续的伪随机比特流。Trivium是ISO/IEC轻量级流密码标准经过广泛分析安全性有保障。Bivium是Trivium的简化版面积更小但安全性相应降低可作为资源极度受限场景下的备选。“展开”是关键原生流密码通常每周期只产生1比特或几个比特的输出。要达到1600比特/周期的目标必须采用“展开”技术。如图5所示将流密码的组合逻辑复制多份并行计算后续多个时钟周期的输出从而在一个周期内批量产生大量随机比特。具体架构如图6所示随机数分发器包含了25个并行运行的64比特展开Trivium实例。每个实例独立初始化并行工作25 * 64 1600正好满足需求。一个有限状态机FSM负责管理初始化、预热和运行状态。初始化时需要通过总线依次为每个Trivium实例写入密钥和初始向量IV。预热阶段每个实例空转不输出1152个周期4*288以充分混合内部状态确保输出序列的随机性。实操心得初始化与密钥管理在SoC中集成时这25个Trivium实例的密钥和IV管理是一个需要仔细设计的软件/硬件协同任务。论文中提到通过一个移位寄存器来串行加载然后由FSM自动分发到各实例。在实际工程中你需要确保这些种子值来自一个安全的随机源如SoC中的TRNG并且在系统生命周期内可以定期重新设定种子以应对随机数生成器状态可能被预测的风险。虽然论文未深入讨论种子来源但在实际产品中这必须是安全方案的一部分。3.3 完整的SHA-3加速器集成将掩码Keccak核心和随机数分发器封装成一个完整的、易于使用的加速器IP还需要一系列配套模块。图4展示了顶层架构输入管理模块负责接收来自处理器的32位字数据并按照SHA-3标准进行填充。这里有一个关键细节填充操作只应用于其中一个份额。如果对两个掩码份额都进行相同的填充那么在最终重组XOR时填充位会相互抵消导致填充无效破坏哈希函数的安全性。因此硬件需要智能地只对一个数据路径施加填充模式。寄存器文件有两个独立的1344比特寄存器文件分别存储两个输入份额。1344比特是SHA-3/SHAKE函数中最大的速率rSHAKE-128/256。控制单元这是一个核心指挥模块。它解析处理器发来的命令控制整个数据通路。论文定义了几条关键命令RD_SH1/RD_SH2写入第一/二个份额用于新消息的第一个数据块。RD_SH2_ABSORB写入第二个份额用于同一消息的后续数据块。SQUEEZE用于SHAKE函数请求输出更多字节。OUTPUT按字输出哈希结果两个份额依次输出。模式切换的巧思要执行非掩码计算只需将消息作为“第一个份额”写入然后在写入“第二个份额”时将数据块大小参数设为0。控制单元识别到此情况会跳过第二个份额的写入并指示Keccak核心使用全零作为第二个份额即无掩码同时将随机数输入置零。这种设计使得硬件同时支持掩码和非掩码运算无需两套硬件。输出管理模块从Keccak核心的内部状态中提取正确长度的哈希值或可扩展输出并进行必要的字节对齐和掩码操作。4. 实现、评估与安全验证实录设计完成后必须通过实现和测试来回答几个关键问题面积开销有多大性能提升有多少最重要的是它真的安全吗4.1 硬件开销分析FPGA与ASIC的代价论文在Xilinx Artix-7 FPGA和22nm FD-SOI ASIC工艺上进行了综合。FPGA结果无掩码SHA-3加速器约6990个LUT4706个FF最高频率166 MHz。掩码SHA-3加速器仅核心约18,805个LUT9168个FF最高频率163 MHz。核心的掩码开销约为LUT的269%FF的194%。频率几乎未受影响这是因为关键路径可能不在掩码逻辑部分。随机数分发器Trivium版11,966 LUTs 7403 FFs。Bivium版9,201 LUTs 4663 FFs。总开销将掩码核心和随机数分发器加起来总开销相对于无掩码版本在LUT上达到440%Trivium或400%Bivium在FF上达到352%Trivium或293%Bivium。这清晰地表明随机数生成的成本与掩码逻辑本身同等重要甚至更高绝不能忽略。ASIC结果22nm图8展示了面积-频率的设计空间探索。在最高频率1.76 GHz下无掩码加速器~54-64 kGE千门等效。掩码加速器~213 kGE。随机数分发器Trivium~130 kGEBivium~86 kGE。总开销范围在735 MHz到1.76 GHz的频率下包含随机数生成的整体面积开销是无掩码设计的300%到500%。论文也指出如果将防护等级提升到二阶掩码面积开销将再增加2倍以上随机数需求增至3倍这在硬件中通常是不切实际的。避坑指南面积评估必须包含随机数生成这是我见过很多掩码硬件论文容易犯的错误只报告核心逻辑的面积增长对随机数生成器要么假设理想存在要么用一个简单的LFSR数字代替。本工作的价值就在于它给出了一个完整的、可实现的方案及其真实成本。在实际项目评估中你必须将PRNG/TRNG的面积、功耗和性能瓶颈纳入整体考量否则设计可能根本无法在实际频率下工作。4.2 安全性验证TVLA测试理论上的安全设计必须经过实测验证。论文采用测试向量泄漏评估TVLA方法来检测一阶侧信道泄漏。TVLA使用Welch‘s t-test比较设备在处理固定输入和随机输入时的功耗或电磁轨迹的统计差异。如果t值的绝对值超过阈值通常为4.5则认为存在可检测的泄漏。实验在FPGA板上进行采集电磁辐射轨迹无掩码模式使用2万条轨迹t值在整个执行过程中显著超过阈值图9a表明存在明显泄漏。掩码模式但随机数关闭同样使用2万条轨迹t值仍然超标图9b。这说明如果没有DOM所要求的新鲜随机数进行刷新即使数据被分割成份额在非线性操作中仍然会因毛刺等原因产生泄漏。这证明了随机数刷新对于DOM方案的安全性是不可或缺的。完整掩码模式随机数开启使用100万条轨迹分别测试Trivium和Bivium作为随机源的配置。t值始终保持在阈值以下图9c 图10。这强有力地证明了在提供足量、高质量的随机数前提下所实现的一阶DOM掩码方案能够有效抵抗一阶侧信道攻击。实操心得TVLA测试的设置与解读进行TVLA测试时确保测试向量固定和随机覆盖了所有关键中间值。采集的轨迹数量要足够多通常数十万到百万级以降低统计误差。阈值4.5对应极高的置信度99.999%。即使t值偶尔“尖峰”超过4.5也需要结合具体时间点分析是否是噪声或同步问题。本工作中掩码开启后的曲线平坦是理想的结果。4.3 系统集成与性能加速最后作者将整个系统集成到一个基于CV32E40P RISC-V核心的32位SoC中图7并用于加速一个一阶掩码的ML-KEM解密软件实现。性能提升结果令人印象深刻表3纯软件实现KEM解密约需680万时钟周期其中62%的时间花在SHA-3相关函数上。J()函数SHAKE-256独占150多万周期。硬件加速后J()函数加速了243倍。G()函数SHA3-512加速了264倍。PKE.Encrypt中的哈希函数加速了95倍。整体效果KEM解密总时间加速了2倍。最关键的是SHA-3函数在总运行时间中的占比从62%骤降至1%。这意味着原本的瓶颈已被彻底移除性能限制因素转移到了多项式运算等其他模块上。这个实验完美地证明了该硬件加速器的价值它不仅提供了侧信道防护还极大地提升了后量子密码算法的实际运行效率。5. 对比、思考与未来方向5.1 与现有工作的对比论文在“相关工作”部分进行了比较。这里我结合自己的理解总结一下与纯掩码Keccak设计相比本文提供了一个完整的、可系统集成的解决方案包含了随机数生成、控制接口和软硬件协同而不仅仅是核心置换函数。与更广泛的PQC加速器相比例如文献[6]也提出了包含指令集扩展的PQC加速器但其重点在多类运算如NTT对SHA-3加速的细节和掩码成本着墨不多。本文则深度聚焦于SHA-3这一特定但至关重要的组件。与纯软件掩码实现相比如文献[34]在ARM Cortex-M4上实现了掩码Kyber性能优于本文的软件基线但这得益于其针对特定平台的汇编级优化以及可能更早的算法草案。本文的贡献在于提供了一个通用的硬件加速方案并明确了其面积/性能/安全性的权衡。5.2 工程实践中的考量与挑战随机数质量与后处理本文使用的Trivium/Bivium是密码学安全的PRNG。但在实际高安全等级应用中可能需要考虑使用TRNG作为种子并定期重新设定PRNG的种子。此外需要对PRNG的输出进行连续性测试确保其不会失效。接口与易用性加速器通过内存映射寄存器控制软件驱动需要正确序列化命令和数据传输。特别是对于长消息的分块处理、掩码与非掩码模式的切换需要清晰的软件API设计否则极易用错。功耗与电磁辐射掩码和大量随机数生成会显著增加动态功耗。在安全认证场景如Common Criteria中不仅要求能量分析安全也可能要求电磁分析安全。更复杂的屏蔽、布线策略可能需要被考虑。扩展到高阶掩码如论文所述二阶掩码的面积和随机数开销会急剧增加2倍面积3倍随机数。对于很多嵌入式场景一阶防护可能已是极限。是否需要高阶防护取决于产品的安全等级要求和成本预算。5.3 可能的优化与扩展方向随机数生成器的优化探索其他轻量级流密码或基于置换的PRNG如ASCON的轻量级模式或许能在面积和吞吐量之间找到更好的点。也可以研究随机数“按需生成”或“缓存”的架构减少瞬时带宽压力。与SoC其他安全模块的协同如果SoC中已有用于其他用途的密码学加速器或TRNG是否可以共享或复用部分资源例如用一个高性能的PRNG同时为多个需要掩码的模块服务。支持其他哈希函数或PQC算法该架构的核心是掩码Keccak。Keccak本身也是其他算法如ASCON认证加密的核心。可以评估将该加速器扩展为更通用的“掩码海绵函数加速器”的可行性。物理级防护的补充掩码是逻辑层防护可以结合电路级技术如平衡逻辑、随机时钟或布局级技术如屏蔽、分散布局来构建深度防御体系。回看整个项目它为我们提供了一个非常扎实的案例研究如何将一个理论上安全的密码学构造DOM掩码通过严谨的硬件工程实践变成一个在真实芯片上运行、经过安全测试、并能切实提升系统性能的解决方案。它告诉我们在后量子密码学走向实际部署的道路上解决像“随机数饥渴”这样的工程魔鬼细节与设计算法本身同等重要。对于正在设计安全芯片或嵌入式密码模块的工程师来说这份工作里的面积数据、架构折衷和安全验证方法都具有很高的参考价值。
后量子密码硬件安全：掩码SHA-3加速器设计与随机数供给挑战
发布时间：2026/5/27 12:00:09
1. 项目概述当后量子密码学遇上物理安全如果你最近在关注密码学硬件的进展尤其是那些准备应对量子计算机威胁的后量子密码PQC算法那么“侧信道攻击”和“掩码防护”这两个词一定不会陌生。我们总说PQC算法在数学上是安全的但一旦落实到芯片上运行功耗、电磁辐射这些物理信号就可能成为攻击者窃取密钥的“后门”。我最近花了不少时间研究一个具体而微的难题如何为后量子密码的核心组件——SHA-3哈希函数——设计一个既高效又安全的硬件加速器并且要实实在在地把“掩码”这种防护手段做进去而不是停留在论文公式里。这个项目的核心就是一篇题为《Accelerating First-Order Secure ML-KEM With Masked SHA-3》的学术论文。它探讨的正是这个痛点。论文指出像ML-KEMNIST标准化的后量子密钥封装机制这样的算法其运行时间有超过60%都花在了SHA-3相关的哈希计算上。如果不对这些计算进行保护整个算法的侧信道安全性就无从谈起。然而给SHA-3上掩码尤其是采用安全性更强的域定向掩码DOM方案时会带来一个非常现实的工程挑战每一轮KeccakSHA-3的核心置换函数计算都需要消耗高达1600比特的“新鲜”随机数。这个量级对于传统的真随机数发生器TRNG或简单的线性反馈移位寄存器LFSR来说都是巨大的负担但很多前期研究恰恰忽略了这部分开销。所以这篇工作的价值在于它没有只谈理想的掩码电路设计而是把一个完整的、可部署的解决方案端到了我们面前一个支持所有SHA-3/SHAKE函数的、一阶掩码的硬件加速器配套一个专门解决“随机数饥渴”问题的“随机数分发器”基于流密码Trivium/Bivium最后还把它集成到一个32位RISC-V SoC里去实际加速一个掩码版的ML-KEM解密流程。他们不仅做了FPGA和ASIC的综合评估算清了面积和性能的账还用TVLA测试向量泄漏评估方法在FPGA上实测了安全性证明了方案的有效性。接下来我就结合自己的工程经验把这个工作的里里外外、设计思路、实现细节以及那些容易踩坑的地方给大家掰开揉碎了讲清楚。2. 核心需求与挑战拆解为什么掩码SHA-3这么难在动手设计任何硬件加速器之前我们必须先彻底理解我们要解决什么问题以及为什么这个问题棘手。这个项目瞄准的是后量子密码学在嵌入式系统中的安全实现其核心需求可以分解为三个层次。2.1 需求一为PQC核心算法提供高性能哈希计算ML-KEM以及其他许多后量子算法如CRYSTALS-Dilithium严重依赖哈希函数进行伪随机数生成、承诺和密钥派生。以ML-KEM的解封装Decapsulation操作为例其算法流程中多次调用了SHA3-512作为G函数、SHAKE-256作为J函数和SHAKE-128。在纯软件实现中这些哈希函数调用是主要的性能瓶颈。因此第一个刚性需求就是提供一个高性能的SHA-3硬件加速器能够显著降低这些操作的延迟从而提升整个KEM协议的吞吐量。注意这里的“高性能”需要明确定义。对于哈希加速器常见的指标是吞吐量Gbps和每字节处理的能耗。但在这个上下文中由于集成在SoC中为软件服务更关键的指标可能是“完成一次特定哈希运算所需的时钟周期数”。论文中选择的是“每时钟周期完成一轮Keccak置换”的架构这是一个在面积和速度之间取得平衡的经典设计。2.2 需求二提供可证明的侧信道攻击防护侧信道攻击SCA通过分析设备运行时的物理泄露如功耗、电磁、时序来推断秘密信息。对于ML-KEM解密操作会使用私钥因此是SCA的主要目标。掩码是一种有效的防护手段其原理是将一个敏感数据值x分割成d1个随机份额例如对于一阶掩码d1则x x0 ⊕ x1使得攻击者需要同时获取所有份额的信息才能恢复出原始值从而将攻击复杂度从一阶提升到高阶。然而将掩码应用于SHA-3的核心——Keccak置换——并非易事。Keccak包含一个非线性的χ步骤其中涉及AND操作。在硬件中直接对掩码份额执行非线性操作会因“毛刺”而导致份额在组合逻辑中提前重组泄露信息。因此需要采用更高级的掩码方案如域定向掩码DOM它在不同“域”的边界插入寄存器并使用新鲜随机数进行“刷新”以阻断由路径延迟差异引起的毛刺传播。这正是本设计选择DOM作为基础的原因。2.3 需求三解决掩码带来的巨额随机数开销这是本项目要解决的核心工程挑战也是很多学术工作避而不谈或轻描淡写的一点。DOM方案为了在χ步骤安全地组合来自不同域的份额需要在每个时钟周期注入新鲜随机数。对于1600比特状态的Keccak且设计为每周期一轮这意味着每个时钟周期都需要1600比特全新的、不可预测的随机数。我们来算一笔账如果目标频率是100 MHz那么随机数的需求速率就是 1600 bits/cycle * 100e6 cycles/s 160 Gbps。这是一个天文数字传统的TRNG根本不可能达到这个吞吐量。使用线性反馈移位寄存器LFSR虽然速度快、面积小但其安全性存疑攻击者可能从输出序列反推内部状态。因此需要一个既能高速生成、又具备足够密码学强度的伪随机数发生器PRNG。论文中采用基于流密码Trivium/Bivium展开设计的方案正是为了在速度、面积和安全性之间取得一个可行的折衷。2.4 系统级集成与灵活性需求最后这个加速器不能是一个孤立的IP。它需要能够方便地集成到现代SoC中如通过总线内存映射并且要能灵活支持后量子密码算法中常见的混合模式即同一个算法流程中既需要对敏感数据如私钥、中间秘密进行掩码哈希计算也需要对公开数据如公钥、密文进行普通的非掩码哈希计算。因此加速器需要具备在运行时动态切换掩码与非掩码模式的能力。3. 架构设计从DOM掩码核心到随机数供给系统理解了需求和挑战我们就可以开始勾勒整个系统的架构了。整个设计可以看作是两个紧密耦合的子系统的协同一个是执行核心计算的掩码SHA-3加速器另一个是为其源源不断提供“弹药”的随机数分发器。3.1 掩码Keccak核心选型与实现论文选择了来自文献 [8] 的DOM架构作为其Keccak核心。这是一个经过精心设计、能够抵抗一阶毛刺攻击的掩码实现。其高层架构对应论文中的图3值得我们深入理解。该核心针对一阶掩码d1设计但内部操作涉及4个份额。输入数据根据所选SHA-3模式长度为速率r首先被填充并构建成4个份额。这多出来的份额是DOM方案为了满足“非完备性”安全属性而引入的。核心数据通路如下θ函数线性扩散首先在4个份额上执行θ变换。寄存器隔离θ的结果被存入4组1600比特的寄存器。这一步至关重要它不仅用于暂存每轮结果更重要的是它作为“域”的边界切断了组合逻辑毛刺的传播路径是DOM能防毛刺的关键。π◦ρ和ι◦χ变换随后进行π和ρ线性置换和循环移位接着是ι常数加和χ非线性换。设计的关键在于χ步骤的每个组件只接收一个输入份额这确保了非完备性。压缩与刷新最后通过一个压缩阶段将4个份额合并回2个份额。在域的交叉点例如从一组寄存器到下一级逻辑需要使用新鲜随机数对份额进行“刷新”操作以恢复均匀性防止信息通过联合分布泄露。这个架构实现了每时钟周期完成一轮Keccak置换对于24轮的Keccak-p[1600,24]完成一次完整的置换需要24个周期。这种设计在吞吐量和面积之间取得了较好的平衡。3.2 随机数分发器的设计流密码的工程化应用随机数分发器是本项目的创新亮点之一。它的目标很明确以每周期1600比特的速率生成密码学强度足够的伪随机数。论文评估了两种流密码Trivium和其简化版Bivium B。为什么选择流密码与分组密码或哈希函数相比流密码通常结构更简单吞吐量更高更适合生成连续的伪随机比特流。Trivium是ISO/IEC轻量级流密码标准经过广泛分析安全性有保障。Bivium是Trivium的简化版面积更小但安全性相应降低可作为资源极度受限场景下的备选。“展开”是关键原生流密码通常每周期只产生1比特或几个比特的输出。要达到1600比特/周期的目标必须采用“展开”技术。如图5所示将流密码的组合逻辑复制多份并行计算后续多个时钟周期的输出从而在一个周期内批量产生大量随机比特。具体架构如图6所示随机数分发器包含了25个并行运行的64比特展开Trivium实例。每个实例独立初始化并行工作25 * 64 1600正好满足需求。一个有限状态机FSM负责管理初始化、预热和运行状态。初始化时需要通过总线依次为每个Trivium实例写入密钥和初始向量IV。预热阶段每个实例空转不输出1152个周期4*288以充分混合内部状态确保输出序列的随机性。实操心得初始化与密钥管理在SoC中集成时这25个Trivium实例的密钥和IV管理是一个需要仔细设计的软件/硬件协同任务。论文中提到通过一个移位寄存器来串行加载然后由FSM自动分发到各实例。在实际工程中你需要确保这些种子值来自一个安全的随机源如SoC中的TRNG并且在系统生命周期内可以定期重新设定种子以应对随机数生成器状态可能被预测的风险。虽然论文未深入讨论种子来源但在实际产品中这必须是安全方案的一部分。3.3 完整的SHA-3加速器集成将掩码Keccak核心和随机数分发器封装成一个完整的、易于使用的加速器IP还需要一系列配套模块。图4展示了顶层架构输入管理模块负责接收来自处理器的32位字数据并按照SHA-3标准进行填充。这里有一个关键细节填充操作只应用于其中一个份额。如果对两个掩码份额都进行相同的填充那么在最终重组XOR时填充位会相互抵消导致填充无效破坏哈希函数的安全性。因此硬件需要智能地只对一个数据路径施加填充模式。寄存器文件有两个独立的1344比特寄存器文件分别存储两个输入份额。1344比特是SHA-3/SHAKE函数中最大的速率rSHAKE-128/256。控制单元这是一个核心指挥模块。它解析处理器发来的命令控制整个数据通路。论文定义了几条关键命令RD_SH1/RD_SH2写入第一/二个份额用于新消息的第一个数据块。RD_SH2_ABSORB写入第二个份额用于同一消息的后续数据块。SQUEEZE用于SHAKE函数请求输出更多字节。OUTPUT按字输出哈希结果两个份额依次输出。模式切换的巧思要执行非掩码计算只需将消息作为“第一个份额”写入然后在写入“第二个份额”时将数据块大小参数设为0。控制单元识别到此情况会跳过第二个份额的写入并指示Keccak核心使用全零作为第二个份额即无掩码同时将随机数输入置零。这种设计使得硬件同时支持掩码和非掩码运算无需两套硬件。输出管理模块从Keccak核心的内部状态中提取正确长度的哈希值或可扩展输出并进行必要的字节对齐和掩码操作。4. 实现、评估与安全验证实录设计完成后必须通过实现和测试来回答几个关键问题面积开销有多大性能提升有多少最重要的是它真的安全吗4.1 硬件开销分析FPGA与ASIC的代价论文在Xilinx Artix-7 FPGA和22nm FD-SOI ASIC工艺上进行了综合。FPGA结果无掩码SHA-3加速器约6990个LUT4706个FF最高频率166 MHz。掩码SHA-3加速器仅核心约18,805个LUT9168个FF最高频率163 MHz。核心的掩码开销约为LUT的269%FF的194%。频率几乎未受影响这是因为关键路径可能不在掩码逻辑部分。随机数分发器Trivium版11,966 LUTs 7403 FFs。Bivium版9,201 LUTs 4663 FFs。总开销将掩码核心和随机数分发器加起来总开销相对于无掩码版本在LUT上达到440%Trivium或400%Bivium在FF上达到352%Trivium或293%Bivium。这清晰地表明随机数生成的成本与掩码逻辑本身同等重要甚至更高绝不能忽略。ASIC结果22nm图8展示了面积-频率的设计空间探索。在最高频率1.76 GHz下无掩码加速器~54-64 kGE千门等效。掩码加速器~213 kGE。随机数分发器Trivium~130 kGEBivium~86 kGE。总开销范围在735 MHz到1.76 GHz的频率下包含随机数生成的整体面积开销是无掩码设计的300%到500%。论文也指出如果将防护等级提升到二阶掩码面积开销将再增加2倍以上随机数需求增至3倍这在硬件中通常是不切实际的。避坑指南面积评估必须包含随机数生成这是我见过很多掩码硬件论文容易犯的错误只报告核心逻辑的面积增长对随机数生成器要么假设理想存在要么用一个简单的LFSR数字代替。本工作的价值就在于它给出了一个完整的、可实现的方案及其真实成本。在实际项目评估中你必须将PRNG/TRNG的面积、功耗和性能瓶颈纳入整体考量否则设计可能根本无法在实际频率下工作。4.2 安全性验证TVLA测试理论上的安全设计必须经过实测验证。论文采用测试向量泄漏评估TVLA方法来检测一阶侧信道泄漏。TVLA使用Welch‘s t-test比较设备在处理固定输入和随机输入时的功耗或电磁轨迹的统计差异。如果t值的绝对值超过阈值通常为4.5则认为存在可检测的泄漏。实验在FPGA板上进行采集电磁辐射轨迹无掩码模式使用2万条轨迹t值在整个执行过程中显著超过阈值图9a表明存在明显泄漏。掩码模式但随机数关闭同样使用2万条轨迹t值仍然超标图9b。这说明如果没有DOM所要求的新鲜随机数进行刷新即使数据被分割成份额在非线性操作中仍然会因毛刺等原因产生泄漏。这证明了随机数刷新对于DOM方案的安全性是不可或缺的。完整掩码模式随机数开启使用100万条轨迹分别测试Trivium和Bivium作为随机源的配置。t值始终保持在阈值以下图9c 图10。这强有力地证明了在提供足量、高质量的随机数前提下所实现的一阶DOM掩码方案能够有效抵抗一阶侧信道攻击。实操心得TVLA测试的设置与解读进行TVLA测试时确保测试向量固定和随机覆盖了所有关键中间值。采集的轨迹数量要足够多通常数十万到百万级以降低统计误差。阈值4.5对应极高的置信度99.999%。即使t值偶尔“尖峰”超过4.5也需要结合具体时间点分析是否是噪声或同步问题。本工作中掩码开启后的曲线平坦是理想的结果。4.3 系统集成与性能加速最后作者将整个系统集成到一个基于CV32E40P RISC-V核心的32位SoC中图7并用于加速一个一阶掩码的ML-KEM解密软件实现。性能提升结果令人印象深刻表3纯软件实现KEM解密约需680万时钟周期其中62%的时间花在SHA-3相关函数上。J()函数SHAKE-256独占150多万周期。硬件加速后J()函数加速了243倍。G()函数SHA3-512加速了264倍。PKE.Encrypt中的哈希函数加速了95倍。整体效果KEM解密总时间加速了2倍。最关键的是SHA-3函数在总运行时间中的占比从62%骤降至1%。这意味着原本的瓶颈已被彻底移除性能限制因素转移到了多项式运算等其他模块上。这个实验完美地证明了该硬件加速器的价值它不仅提供了侧信道防护还极大地提升了后量子密码算法的实际运行效率。5. 对比、思考与未来方向5.1 与现有工作的对比论文在“相关工作”部分进行了比较。这里我结合自己的理解总结一下与纯掩码Keccak设计相比本文提供了一个完整的、可系统集成的解决方案包含了随机数生成、控制接口和软硬件协同而不仅仅是核心置换函数。与更广泛的PQC加速器相比例如文献[6]也提出了包含指令集扩展的PQC加速器但其重点在多类运算如NTT对SHA-3加速的细节和掩码成本着墨不多。本文则深度聚焦于SHA-3这一特定但至关重要的组件。与纯软件掩码实现相比如文献[34]在ARM Cortex-M4上实现了掩码Kyber性能优于本文的软件基线但这得益于其针对特定平台的汇编级优化以及可能更早的算法草案。本文的贡献在于提供了一个通用的硬件加速方案并明确了其面积/性能/安全性的权衡。5.2 工程实践中的考量与挑战随机数质量与后处理本文使用的Trivium/Bivium是密码学安全的PRNG。但在实际高安全等级应用中可能需要考虑使用TRNG作为种子并定期重新设定PRNG的种子。此外需要对PRNG的输出进行连续性测试确保其不会失效。接口与易用性加速器通过内存映射寄存器控制软件驱动需要正确序列化命令和数据传输。特别是对于长消息的分块处理、掩码与非掩码模式的切换需要清晰的软件API设计否则极易用错。功耗与电磁辐射掩码和大量随机数生成会显著增加动态功耗。在安全认证场景如Common Criteria中不仅要求能量分析安全也可能要求电磁分析安全。更复杂的屏蔽、布线策略可能需要被考虑。扩展到高阶掩码如论文所述二阶掩码的面积和随机数开销会急剧增加2倍面积3倍随机数。对于很多嵌入式场景一阶防护可能已是极限。是否需要高阶防护取决于产品的安全等级要求和成本预算。5.3 可能的优化与扩展方向随机数生成器的优化探索其他轻量级流密码或基于置换的PRNG如ASCON的轻量级模式或许能在面积和吞吐量之间找到更好的点。也可以研究随机数“按需生成”或“缓存”的架构减少瞬时带宽压力。与SoC其他安全模块的协同如果SoC中已有用于其他用途的密码学加速器或TRNG是否可以共享或复用部分资源例如用一个高性能的PRNG同时为多个需要掩码的模块服务。支持其他哈希函数或PQC算法该架构的核心是掩码Keccak。Keccak本身也是其他算法如ASCON认证加密的核心。可以评估将该加速器扩展为更通用的“掩码海绵函数加速器”的可行性。物理级防护的补充掩码是逻辑层防护可以结合电路级技术如平衡逻辑、随机时钟或布局级技术如屏蔽、分散布局来构建深度防御体系。回看整个项目它为我们提供了一个非常扎实的案例研究如何将一个理论上安全的密码学构造DOM掩码通过严谨的硬件工程实践变成一个在真实芯片上运行、经过安全测试、并能切实提升系统性能的解决方案。它告诉我们在后量子密码学走向实际部署的道路上解决像“随机数饥渴”这样的工程魔鬼细节与设计算法本身同等重要。对于正在设计安全芯片或嵌入式密码模块的工程师来说这份工作里的面积数据、架构折衷和安全验证方法都具有很高的参考价值。
