HHEML：基于FPGA硬件加速的混合同态加密边缘隐私计算框架
1. 项目概述：当隐私保护遇上边缘计算，硬件加速如何破局？
在医疗影像分析、金融风控或者智能家居语音识别这些场景里，我们既希望享受AI模型带来的精准服务，又极度担忧自己的敏感数据（比如病历、交易记录、家庭对话）在传输和处理过程中泄露。全同态加密（FHE）技术一度被视为“隐私计算的圣杯”，它允许在不解密的情况下直接对密文进行计算，理论上能完美解决这个矛盾。但理想很丰满，现实很骨感——FHE的计算开销巨大，动辄将推理延迟从毫秒级拖到分钟甚至小时级，这对于需要实时响应的边缘设备（如手机、摄像头、医疗传感器）来说，是完全不可接受的。
于是，混合同态加密（HHE）方案应运而生，它像是一个聪明的“二段式”策略：客户端先用一个高效的对称密码（比如AES）加密原始数据，然后将这个对称密文发送给服务器；服务器端则利用FHE的“自举”特性，将这个对称密文“转换”成同态密文，再进行复杂的模型推理。这个方案把最重的FHE计算留给了云端服务器，而客户端只负责相对轻量的对称加密。然而，问题又来了：即便是对称加密，在资源极其有限的边缘设备上用软件跑，面对高维的机器学习数据（比如一张224x224的图片就是50176个数据点），依然会成为新的性能瓶颈，延迟和功耗都吃不消。
这就是我们这次要深入探讨的核心：HHEML。这个框架的聪明之处在于，它没有在算法层面死磕，而是转向了硬件。它瞄准了HHE流程中那个专为同态加密设计的、名为Pasta的轻量级对称密码，并把它“塞”进了FPGA里。通过定制化的硬件流水线设计，特别是其双XOF（可扩展输出函数）流水线架构，HHEML成功地将客户端的加密延迟从几百毫秒压缩到了个位数毫秒，实现了超过50倍的性能提升。简单来说，它用一块小小的FPGA芯片，在边缘端为隐私保护机器学习装上了一台“加密引擎”，让安全与实时兼得成为了可能。无论你是关注前沿硬件的工程师，还是正在寻找落地方案的隐私计算从业者，这个将密码学、机器学习与硬件设计深度融合的思路，都值得细细拆解。
2. HHEML系统架构与设计哲学
2.1 为什么是Pasta？—— 专为HHE而生的密码选择
在众多对称加密算法中，HHEML选择了Pasta，这绝非偶然。要理解这一点，我们需要先看看在HHE场景下，一个“好”的对称密码需要具备哪些特质。
首先，它必须是“FHE友好”的。传统的AES算法虽然快，但其S盒（非线性替换盒）操作在FHE语境下会引发严重的“噪声增长”。FHE计算就像在密文上做带误差的算术，每一次非线性操作都会让误差急剧放大，很快就能让密文变得无法解密。Pasta等新一代密码的设计目标，就是将其整个加密过程（包括非线性部分）用低次数的多项式来近似表达。这样，当服务器端需要将Pasta密文“转录”为FHE密文时，这个转录过程本身就是一个相对简单的多项式计算，对FHE的噪声预算消耗极小。
其次，它需要足够轻量。边缘设备的计算能力、内存和功耗都受限。Pasta的设计基于一种称为“海绵结构”的排列，其轮函数主要由模加、旋转和异或这些在硬件上极易高效实现的线性操作构成，结构规整，非常适合进行流水线和并行化改造。
注意：这里存在一个常见的误解，认为“硬件加速就是无脑并行”。对于密码算法，尤其是Pasta这类结构规整的算法，硬件加速的核心思路往往是“流水线化”和“资源复用”，通过精细的时序调度来提升吞吐量，而非简单地堆砌计算单元。HHEML的设计充分体现了这一点。
2.2 从软件到硬件：FPGA加速的总体蓝图
HHEML的硬件平台基于PYNQ-Z2，这是一款集成了ARM处理器（Processing System, PS）和FPGA可编程逻辑（Programmable Logic, PL）的SoC开发板。这种PS-PL架构非常适合边缘计算场景：PS部分运行标准的Linux操作系统，处理网络通信、任务调度等控制逻辑；PL部分则被编程为专用的加密加速器。
整个HHEML的工作流程可以清晰地分为以下几个阶段，我将其绘制成下表以便理解：
表1：HHEML端到端工作流程解析
| 阶段 | 执行位置 | 核心操作 | 设计目标与挑战 |
|---|---|---|---|
| 1. 密钥生成与数据准备 | PS (ARM) | 1. 在安全环境中生成Pasta所需的密钥和随机数。 2. 将待推理的机器学习数据（如图像向量）从应用层内存中取出。 | 确保密钥材料的安全存储与传递。数据需转换为FPGA加速器能高效处理的格式（如连续的数据块）。 |
| 2. 数据搬运至加速器 | PS-PL交互 (DMA) | 通过直接内存访问（DMA）控制器，将明文数据和密钥从PS端的内存高速搬运到PL端的FPGA加速器内部缓冲区。 | 这是关键瓶颈之一。DMA传输的带宽和延迟直接影响整体性能。需要精心设计数据缓冲区大小和突发传输长度，以匹配加密引擎的吞吐率。 |
| 3. 硬件加密引擎（核心） | PL (FPGA) | Pasta加密算法在定制化硬件流水线中执行。这是HHEML性能提升的核心。 | 实现双XOF流水线等优化，最大化每个时钟周期内的计算效率，减少完成一次加密所需的时钟周期数（延迟）或提高单位时间内的加密数据量（吞吐量）。 |
| 4. 密文输出与网络发送 | PS-PL交互 -> PS | 1. DMA将PL端生成的密文搬运回PS内存。 2. PS上的网络栈通过以太网将密文发送至远程的FHE服务器。 | 加密完成后需尽快“腾空”PL端缓冲区，以接收下一批数据，形成流水。网络延迟在局域网（LAN）下通常不是主要矛盾，但在广域网（WAN）下需另做优化。 |
| 5. 服务器端FHE推理 | 远程服务器 | 1. 接收Pasta密文。 2. 执行FHE转录（Transciphering）操作，将其转换为同态密文。 3. 在同态密文上执行预训练的机器学习模型推理。 4. 将加密的推理结果返回给客户端。 | HHEML的优化不涉及此阶段。它复用现有成熟的FHE软件栈（如论文中对比的GuardML框架）。硬件加速的价值在于让客户端更快地准备好可供服务器处理的密文。 |
这个流程揭示了一个重要洞见：在HHE系统中，客户端的对称加密阶段是性能瓶颈，但也是通过专用硬件最容易获得数量级提升的环节。FPGA的并行和流水线能力在这里得到了淋漓尽致的发挥。
2.3 核心创新：双XOF流水线架构详解
论文中最亮眼的优化莫过于“双XOF流水线”（Two-XOF Pipeline）。要理解它，我们得先看看Pasta加密中一个关键步骤：XOF（如SHAKE128）的作用。在Pasta的某些操作模式中，XOF被用来从密钥和随机数生成一个扩展的密钥流或随机矩阵，这个过程计算量不小。
在最初的“单XOF”设计中，对于一个大明文数据块（比如一个MNIST图像向量），加密过程可能需要很多“轮”（Round），每一轮都可能依赖或等待XOF的计算结果。论文中提到，MNIST样本在单XOF设计下需要47轮。
双XOF流水线的设计思想非常巧妙：它部署了两个并行的XOF计算单元，并让它们交替工作。想象一下一条工厂装配线，原来只有一个工人负责给产品拧上某个关键零件（XOF计算），他忙不过来，整条线都在等他。现在，我们安排两个工人（双XOF）站在流水线的两侧，一个处理当前产品时，另��个已经为下一个产品准备好了零件。这样，流水线就不用等待了。
具体到加密流程：
- 当加密引擎在处理第N个数据块的加密轮次时，XOF单元A正在为第N个数据块的下一轮（或后半部分）准备材料。
- 同时，XOF单元B已经在为第N+1个数据块（下一个待加密的样本）的初始轮次准备材料。
- 通过精妙的时序控制，两个XOF单元的计算与主加密流水线完美重叠，隐藏了XOF计算延迟。
带来的直接收益是巨大的：对于同样的MNIST数据，加密所需的轮数从47轮减少到了24轮。这相当于在算法逻辑不变、计算资源（两个XOF单元）仅小幅增加的情况下，将加密吞吐量几乎翻了一番。这种通过硬件架构优化来等效减少算法“关键路径”轮数的思路，是FPGA加速设计中非常高级的技巧。
3. 硬件实现细节与关键模块设计
3.1 Pasta密码的硬件化映射
将Pasta算法“翻译”成硬件描述语言（如Verilog或VHDL），并非简单的代码移植，而是一次从“顺序执行”到“空间并行”的思维转换。Pasta的每一轮操作都相对规整，这为流水线设计创造了条件。
一个典型的Pasta轮函数可能包含以下步骤，我们可以思考其硬件实现：
- AddRoundKey：将数据状态与轮密钥进行异或。硬件上，这就是一个宽度为数据位宽的并行异或门阵列，一个时钟周期即可完成。
- SubWords (非线性层)：这是核心。Pasta可能使用一种基于查表或算术运算的轻量级S盒。在FPGA上，我们可以用分布式RAM（LUTRAM）实现小型的S盒查找表，或者用组合逻辑直接实现其布尔函数。关键在于使其深度流水化，即拆分成多个流水线级，每级只做一部分操作，以提高时钟频率。
- ShiftRows/Permutation (线性扩散层)：对数据状态的行进行循环移位或一个固定的排列。这本质上就是连线的重排，在硬件中不消耗逻辑资源，只是改变信号之间的连接关系，可以在一个周期内“无成本”完成。
- MixColumns/Matrix Multiplication：另一个线性操作，通常是一个常数矩阵乘。我们可以将其分解为一系列乘加运算。在FPGA中，可以使用内置的DSP Slice（数字信号处理切片）来高效实现定点数乘加，并将计算展开和流水化。
实操心得：在实现这类密码的硬件流水线时，一个关键的平衡点是“流水线深度”与“频率/面积”的权衡。将一轮操作拆得太细（深度深），虽然能跑更高的时钟频率，但会增加寄存器开销和流水线填充/排空延迟。对于需要连续加密大量数据的场景，深流水线利大于弊；但对于小数据包频繁启停的场景，过深的流水线反而可能降低效率。HHEML面向机器学习数据（向量），属于前者，因此适合采用较深的流水线。
3.2 片上存储与数据接口设计
FPGA内部的Block RAM（BRAM）是宝贵的存储资源。在HHEML中，BRAM主要被用于以下几个关键缓冲区：
- 输入缓冲区：缓存从PS端通过DMA送来的待加密明文数据块。
- 输出缓冲区：缓存加密完成等待DMA取走的密文数据块。
- 轮密钥缓冲区：存储扩展后的轮密钥。由于Pasta的密钥扩展可能相对简单，这部分可以现场计算，也可以预计算后存储。
- XOF内部状态寄存器：双XOF单元各自需要维护其内部哈希状态。
设计一个高效的DMA数据通路至关重要。理想情况是，当加密引擎在处理当前缓冲区数据时，DMA已经在后台将下一批数据写入另一个输入缓冲区，同时将上一批结果从输出缓冲区读走。这需要双缓冲（Ping-Pong Buffer）甚至多缓冲技术。通过精心设计缓冲区大小（通常与AXI总线突发传输长度对齐）和控制状态机，可以确保数据流不间断，使加密引擎始终处于“饱腹”工作状态。
注意：PS与PL之间的AXI总线带宽是有限的共享资源。如果加密引擎消耗数据的速度远超DMA搬运速度，那么加速器就会“饿死”；反之，如果DMA太快，缓冲区会溢出。需要通过性能建模和实测，找到平衡点。在PYNQ-Z2上，HP端口（高性能端口）的带宽是需要重点规划和测试的对象。
3.3 控制状态机与系统集成
整个FPGA加速器需要一个“大脑”，即控制状态机（FSM）。它负责：
- 接收来自PS端（通过AXI-Lite或GPIO接口）的启动、停止、重置等控制命令。
- 协调DMA控制器、输入/输出缓冲区、双XOF单元、Pasta加密核心流水线之间的工作顺序。
- 处理异常情况，如数据校验错误、缓冲区溢出等，并产生中断通知PS端。
在PS端的软件驱动层，需要提供简洁的API，例如hheml_encrypt(data_ptr, length)。驱动负责分配DMA缓冲区、配置DMA描述符、启动FPGA加速器、等待完成中断或轮询状态，最后将结果返回给上层应用。将复杂的硬件操作封装成简单的函数调用，是软硬件协同设计成功的关键。
4. 性能评估与对比分析
4.1 实验设置与基准选择
任何硬件加速工作的价值都需要通过严谨的实验来证明。HHEML的对比基线非常明确：
- 纯软件实现：以GuardML框架的客户端软件加密部分为基准。这代表了当前主流HHE方案在通用CPU上的性能。
- 其他FPGA方案：与之前其他研究提出的FPGA加速HHE方案进行对比，以凸显其架构优势（如双XOF流水线）。
实验平台就是前文提到的PYNQ-Z2（XC7Z020 FPGA）。测试数据集通常选择MNIST、CIFAR-10等标准机器学习数据集，因为它们的数据维度（如MNIST的784维向量）具有代表性。性能指标聚焦于：
- 客户端延迟：从输入明文到输出密文准备就绪的总时间。这是衡量边缘设备响应速度的核心。
- 吞吐量：单位时间内能加密的数据量（如MB/s）。
- 功耗：FPGA在运行加密任务时的动态功耗。这是边缘设备非常关心的指标。
- 资源利用率：FPGA上查找表（LUT）、寄存器（FF）、BRAM、DSP等资源的占用百分比。这关系到设计的紧凑性和成本。
4.2 核心性能数据解读
论文中的几个表格非常直观地展示了HHEML的优势。我们来逐一拆解：
表II：双XOF流水线的威力这张表量化了架构优化最直接的效果。对于MNIST样本这样的大数据块，单XOF设计需要47轮加密，而双XOF流水线将其减半至24轮。这意味着完成单个样本加密所需的时钟周期数几乎减半，从而在相同时钟频率下，吞吐量直接翻倍。这个优化是“免费”的吗？不，它付出了额外的XOF计算单元面积，但由于XOF逻辑在整个设计中所占比例不大，因此面积开销相对较小，用少量的面积换来了翻倍的性能，性价比极高。
表III：端到端延迟对比这是最能体现HHEML实用价值的数据。我们将其拆解并与软件方案对比：
| 系统 | 客户端内部计算 (ms) | 客户端到服务器通信 (ms) | 总延迟 (ms) |
|---|---|---|---|
| GuardML (软件) | 356 | 0.4 (LAN) | 356.4 |
| HHEML (FPGA) | 6.5 | 0.4 (LAN) | 6.9 |
可以看到，通信延迟（0.4ms）在高速局域网中几乎可以忽略不计。真正的瓶颈在于客户端的加密计算。HHEML通过硬件加速，将这部分延迟从356ms降低到了6.5ms，带来了超过50倍的提升。总延迟从超过三分之一秒降低到了毫秒级，这使得许多需要实时交互的边缘AI应用（如实时医疗影像初步分析、即时语音指令识别）在启用隐私保护后依然流畅成为可能。
表IV：不同数据集下的运行时分解此表进一步确认了性能瓶颈的位置。以MNIST为例：
| 数据集 | 系统 | 客户端处理 (ms) | 服务器端解密转录 (s) | 服务器端同态评估 (s) |
|---|---|---|---|---|
| MNIST | GuardML | 356 | 9,397.5 | 54.9 |
| MNIST | HHEML | 6.5 | 9,397.5 | 54.9 |
一个非常清晰的结论跃然纸上：服务器端的FHE计算（解密转录+同态评估）耗时是绝对的大头（几千到上万秒），但这部分HHEML并未改变。HHEML的贡献在于，它几乎消除了客户端的加密开销（从356ms到6.5ms），使得整个端到端流程的“启动延迟”变得极低。用户感知到的延迟，将从“点击后等待几百毫秒才开始上传”，变成了“几乎瞬间就开始上传”，而后台漫长的服务器计算时间对用户体验的影响被前置的快速响应大大缓解了。
4.3 功耗与能效比分析
除了性能，功耗是边缘设备的生命线。FPGA在能效比上通常优于通用CPU。论文指出，FPGA实现展示了“显著更低的功耗需求”。虽然具体瓦数未在片段中给出，但我们可以推断：
- 软件方案：CPU在运行高强度加密算法时，所有核心可能都会高频运行，功耗较高（可能数瓦到十数瓦）。
- FPGA方案：只有与加密相关的特定逻辑电路在运行，其他部分可以保持静态或低功耗状态。定制化的硬件电路执行特定任务的效率远高于通用处理器，因此完成相同加密任务所消耗的能量（焦耳）要少得多。
这意味着，在电池供电的边缘设备上，采用FPGA加速的HHEML方案不仅能提供更快的响应，还能延长设备的续航时间，这对于物联网传感器等场景至关重要。
5. 实战启示与未来展望
5.1 对工程实践的指导意义
从HHEML的工作中，我们可以提炼出几条对软硬件协同设计，特别是隐私计算硬件加速非常有价值的经验：
- 瓶颈定位优先：在优化一个复杂系统时，首先要通过剖析找到真正的性能瓶颈。在HHE for PPML中，客户端加密曾是隐藏在大瓶颈（服务器FHE）之下的次级瓶颈，但恰恰是这个次级瓶颈最影响用户体验且最适合硬件加速。硬件工程师要善于发现这类“高性价比”的优化目标。
- 算法-架构协同设计：不要将算法和硬件架构割裂看待。Pasta密码本身的结构规整性为双XOF流水线等硬件优化提供了可能。未来在设计新的隐私计算原语时，应尽早考虑其硬件友好性。
- 层次化内存与数据流设计：对于数据密集型加速任务，数据搬运常常是隐藏的性能杀手。必须像设计计算单元一样，精心设计DMA、缓冲区、数据通路，确保数据能持续、高效地喂给计算核心。
- 衡量标准多元化：评估一个硬件加速方案，不能只看峰值吞吐量。对于边缘推理场景，延迟和能效比往往是更关键的指标。HHEML在延迟上的巨大提升，正是其核心价值所在。
5.2 面临的挑战与可能的改进方向
尽管成果显著，HHEML仍处于研究原型阶段，走向大规模应用还需解决一些问题：
- 灵活性 vs. 效率：当前的FPGA设计是针对Pasta密码定制的。如果未来出现更优的FHE友好型密码（如Masta, Elisabeth），可能需要重新设计硬件。可考虑设计一种更通用的、可配置的对称密码加速IP，通过微码或可重配置数据通路来适应不同的算法，但这会牺牲一部分性能和效率。
- 多模型与动态负载：实际应用中，边缘设备可能需要运行多种不同的机器学习模型，输入数据的维度和加密需求可能动态变化。加速器需要能够灵活处理不同大小的数据块，并可能支持多个并发的加密上下文。
- 与更先进FHE后端的集成：目前HHEML复用GuardML的FHE栈。未来可以探索与更高性能的FHE库（如使用GPU加速的）进行更紧密的集成，甚至将部分FHE预处理或后处理步骤也下放到FPGA，形成端到端的硬件加速管道。
- 安全性硬件加固：作为密码硬件，需要抵御侧信道攻击（如功耗分析、电磁分析）。目前的学术原型可能未充分考虑这点，产品化时需要加入随机延迟、掩码等技术进行防护。
5.3 个人思考：硬件加速在隐私计算的未来角色
从事硬件设计这些年，我深感我们正处在一个拐点。通用计算（CPU）在应对AI和密码学这类计算范式特殊的任务时越来越力不从心。像HHEML这样的工作揭示了一个趋势：未来的隐私计算，乃至整个可信计算领域，将是“专用硬件”的舞台。
FPGA以其灵活性和能效比，非常适合作为这种专用硬件的载体，尤其是在需要快速迭代算法和标准的早期阶段。随着方案的成熟，我们可能会看到更多ASIC（专用集成电路）的出现，将能效和性能推向极致。对于开发者而言，理解如何将自己的算法“映射”到硬件思维，如何与硬件工程师有效沟通，将成为一项越来越重要的技能。
HHEML不仅仅是一个加速器设计，它更是一个信号：当软件的性能优化触及天花板时，向硬件要效率，是解决隐私计算落地难题的一条必由之路。这条路虽然充满挑战，需要跨密码学、机器学习、硬件设计的深厚知识，但其带来的性能跃迁和体验革新，无疑是值得全力投入的方向。