1. 项目概述：当数据安全成为业务刚需

最近几年，我经手和参与评审的涉及敏感数据的项目越来越多，从金融风控到医疗健康，再到企业内部的人力资源分析。一个核心的矛盾点始终存在：业务部门迫切需要利用数据进行联合分析、检索和计算以产生价值，而安全与合规部门则要求数据“看得见、摸不着”，严禁明文出域。传统的方案，比如数据脱敏后计算，损失了精度；搭建可信执行环境（TEE），成本和技术门槛又太高。直到我们团队决定啃下“同态加密”这块硬骨头，并基于Java和Vue构建一个全栈平台，才算找到了一个在安全与可用性之间相对平衡的支点。

这个项目的核心目标很明确： 设计并实现一个平台，让用户（主要是数据分析师和业务人员）能够在前端页面上，像操作普通数据库一样，对经过同态加密的密文数据进行安全的检索与计算，而服务器端在整个过程中都无法解密数据，从而在根本上杜绝数据泄露风险。 它不是为了炫技，而是为了解决真实生产环境中的痛点——如何在保障数据隐私的前提下，释放数据的计算价值。如果你正在为数据安全合规问题头疼，或者对如何将前沿密码学技术工程化落地感兴趣，那么这次从零到一的实战经验分享，或许能给你带来一些切实的参考。

2. 整体架构设计与技术选型背后的逻辑

当我们决定要做这件事时，面临的第一个问题就是架构设计。一个易于使用、安全可靠、性能可接受的系统，必须建立在清晰的分层架构之上。

2.1 为什么是Spring Boot + Vue的前后端分离架构？

选择这个黄金组合，几乎是国内Java全栈项目的标准答案，但在这里有更深层的考量。首先， 业务逻辑的复杂性与安全性要求 ，决定了后端必须稳固。Spring Boot的生态成熟，能让我们快速集成安全框架、连接池、监控等企业级组件，更重要的是，它对 多线程并发处理 的支持很好。同态加密计算是CPU密集型操作，一个请求可能处理成千上万条密文，我们必须利用后端强大的计算资源和精细的线程池控制，避免前端页面被卡死。Vue则负责提供 响应式、组件化的用户界面 ，将复杂的加密操作封装成简单的表单、按钮和结果展示区域，让非技术人员也能轻松上手。前后端通过RESTful API交互，职责清晰，也便于后期分别进行性能优化和功能扩展。

2.2 同态加密库的抉择：HElib vs SEAL vs TenSEAL？

这是项目的灵魂所在，选型过程我们纠结了很久。同态加密方案主要分三类： 全同态加密（FHE）、部分同态加密（SHE）和层次同态加密（Leveled FHE） 。FHE理论上能执行任意次数的加法和乘法，但当前性能开销巨大，不适合生产环境。因此，面向实际应用，我们聚焦于SHE和Leveled FHE。

  • HElib (IBM) ：老牌FHE库，功能强大，但API较为底层，学习曲线陡峭，且文档以C++为主，Java调用需要经过一层JNI（Java Native Interface）封装，引入额外的复杂性和调试难度。
  • SEAL (Microsoft) ：微软研究院出品，是目前最活跃、文档最完善的同态加密库之一。它明确区分了 BFV方案（用于整数算术）和CKKS方案（用于浮点数近似计算） 。CKKS方案特别适合机器学习等场景，因为它支持对加密后的浮点数进行近似计算，效率相对较高。SEAL同样基于C++，但社区提供了更好的绑定支持。
  • TenSEAL ：一个基于SEAL的Python库，包装得更友好。但对于我们以Java为核心的后端来说，引入Python进程间通信反而增加了系统复杂度。

我们的最终选择是：基于SEAL库（CKKS方案），通过JNI进行封装，供Java后端调用。 理由如下：

  1. 场景匹配 ：我们的敏感数据检索与计算，大量涉及统计指标（如求和、平均、方差），这些多为浮点数运算，CKKS的近似计算特性完全满足需求，且效率在可接受范围内。
  2. 生态与未来 ：SEAL背靠微软，持续维护，社区活跃，遇到问题更容易找到解决方案或同行讨论。
  3. 性能平衡 ：相较于BFV，CKKS在相同安全级别下能处理更大的数据量（打包技术），这对批量数据计算至关重要。

注意 ：JNI的集成是一大挑战。你需要自己编写C++的JNI包装层，编译为动态链接库（.dll或.so），并确保在不同部署环境（开发、测试、生产）下的库文件路径正确。我们花了近两周时间才让整个调用链路稳定下来。

2.3 核心工作流设计

平台的核心工作流可以概括为“一次初始化，多次安全计算”：

  1. 密钥生成与分发 ：在可信客户端（或一个独立的密钥管理服务）生成同态加密的公钥（ pk ）和私钥（ sk ）。 pk 发送给服务器用于加密数据和执行计算； sk 由数据所有者严格保密，用于解密最终结果。
  2. 数据加密上传 ：客户端使用 pk 对敏感数据（如工资、医疗记录）进行加密，然后将密文上传至服务器数据库。服务器存储的始终是密文。
  3. 密文检索与计算 ：用户在前端界面提交计算任务（如“计算部门A的平均薪资”）。前端将计算请求（明文）发送至后端。后端根据请求，从数据库取出对应的密文数据，在内存中利用SEAL库和 pk 执行同态加密计算（如一系列加法和乘法），生成结果密文。
  4. 结果返回与解密 ：后端将结果密文返回给前端。前端使用本地持有的 sk 对结果密文进行解密，得到明文结果，并展示给用户。

整个过程中，服务器接触到的只有密文和公钥，永远无法接触明文数据和解密私钥，从而实现了“数据可用不可见”。

3. 核心模块拆解与实现细节

3.1 后端Java核心：JNI封装与计算引擎

后端的核心是一个 同态加密计算引擎 。我们将其设计为一个独立的Spring Boot Service。

1. JNI封装层（ SealJniWrapper ）： 我们创建了一个 SealJniWrapper 类，通过 native 关键字声明本地方法。

public class SealJniWrapper {
    // 加载JNI动态库
    static {
        System.loadLibrary("sealjni");
    }

    // 初始化CKKS上下文（参数设置）
    public native long createContext(int polyModulusDegree, long[] coeffModulusBits, int scale);
    // 使用公钥加密一个双精度数组（批量打包）
    public native byte[] encryptDoubles(long contextHandle, byte[] publicKey, double[] values);
    // 同态加法
    public native byte[] addCiphertexts(long contextHandle, byte[] ciphertext1, byte[] ciphertext2);
    // 同态乘法（明文乘密文）
    public native byte[] multiplyPlain(long contextHandle, byte[] ciphertext, double[] plainMultiplier);
    // 使用私钥解密
    public native double[] decryptDoubles(long contextHandle, byte[] secretKey, byte[] ciphertext);
    // 释放资源
    public native void destroyContext(long contextHandle);
}

对应的C++ JNI实现（ sealjni.cpp ）内部，则调用SEAL库的API。这里的关键是 参数配置 ： polyModulusDegree （多项式模次数）和 coeffModulusBits （系数模数的比特数）直接决定了安全强度和计算能力。我们经过测试，选择了 polyModulusDegree=8192 的一组平衡参数，既能满足128位安全级别，又能支持一定深度的乘法运算。

2. 计算服务（ HomomorphicComputationService ）： 这个服务类封装了业务逻辑。例如，处理“求平均薪资”的请求：

@Service
public class HomomorphicComputationService {
    @Autowired
    private CiphertextDataRepository dataRepo; // 假设的密文数据DAO

    public byte[] calculateAverage(String deptId) {
        // 1. 从数据库查询该部门所有员工的薪资密文 List<byte[]>
        List<byte[]> salaryCiphers = dataRepo.findSalaryCiphersByDept(deptId);
        if (salaryCiphers.isEmpty()) {
            return null;
        }

        // 2. 获取JNI上下文和公钥（从配置或缓存中）
        long ctxHandle = SealContextHolder.getContext();
        byte[] publicKey = KeyManager.getPublicKey();

        // 3. 同态求和：将所有薪资密文依次相加
        byte[] sumCipher = salaryCiphers.get(0);
        for (int i = 1; i < salaryCiphers.size(); i++) {
            sumCipher = sealWrapper.addCiphertexts(ctxHandle, sumCipher, salaryCiphers.get(i));
        }

        // 4. 同态乘以常数（1/N）: 构造一个明文向量，每个元素都是 1.0/N
        int n = salaryCiphers.size();
        double[] plainMultiplier = new double[n]; // 这里简化，实际CKKS打包后维度是polyModulusDegree/2
        Arrays.fill(plainMultiplier, 1.0 / n);
        // 需要先将明文向量编码并加密（或直接使用CKKS的`multiply_plain`）
        byte[] avgCipher = sealWrapper.multiplyPlain(ctxHandle, sumCipher, plainMultiplier);

        return avgCipher; // 返回平均薪资的密文
    }
}

实操心得 ：同态加密计算非常消耗内存和CPU。务必在Service层做好 资源管理 和 超时控制 。我们为每个计算请求配置了独立的超时时间（如30秒），并在JNI层防止内存泄漏。此外，对于大规模数据，需要考虑分批计算，避免单次操作耗尽内存。

3.2 前端Vue工程：复杂交互的简化封装

前端的目标是将底层的加密解密和复杂的计算请求，包装成用户友好的操作。我们使用Vue 3 + TypeScript + Element Plus。

1. 密钥管理组件（ KeyManager.vue ）： 负责生成、加载、保存密钥对。私钥 sk 绝不能 通过网络传输，我们使用浏览器的 localStorage （或更安全的 IndexedDB ）进行本地存储，并在使用时通过 Crypto.subtle API进行进一步的包装保护。公钥 pk 则在上传数据前发送给后端。

2. 数据加密上传组件（ DataUpload.vue ）： 用户上传CSV或Excel文件。前端解析文件，逐行读取敏感列（如薪资），调用一个Web Worker（避免阻塞主线程）中的JavaScript加密库（如 seal.js ，一个SEAL的WebAssembly移植版）或通过后端提供的轻量级加密接口，使用公钥 pk 进行加密。加密完成后，将密文（和对应的非敏感明文ID）打包上传至后端。

3. 计算任务面板（ ComputationPanel.vue ）： 这是用户交互的核心。我们设计了一个类似“计算器构建器”的界面：

  • 数据源选择 ：树形结构展示数据库中的密文数据表/视图。
  • 操作符拖拽 ：提供“求和”、“平均”、“计数”、“方差”等操作符，用户可以拖拽到画布上。
  • 条件筛选 ：由于同态加密下无法直接对密文进行 WHERE 比较，我们采用了“映射-过滤”的变通方案。例如，想筛选“部门=A”，我们会在加密前为每条数据附加一个“部门标签”的密文（使用不同的加密方案或编码方式），在计算时通过特定的同态操作实现筛选逻辑。这部分是最高挑战，通常需要根据业务定制。
  • 任务提交与结果展示 ：用户构建好计算任务后，点击提交。前端将计算描述（JSON格式）发送给后端。后端执行完毕后返回结果密文，前端调用本地私钥 sk 解密，并将明文结果以图表或表格形式展示。
<template>
  <div>
    <el-select v-model="selectedTable" placeholder="选择数据表">
      <!-- 选项从后端动态获取 -->
    </el-select>
    <el-select v-model="selectedColumn" placeholder="选择计算列">
      <!-- 根据selectedTable动态加载列 -->
    </el-select>
    <el-select v-model="selectedOperation" placeholder="选择计算操作">
      <el-option label="求和" value="sum"></el-option>
      <el-option label="平均值" value="avg"></el-option>
      <el-option label="方差" value="variance"></el-option>
    </el-select>
    <el-button @click="submitComputation" :loading="loading">执行计算</el-button>
    <div v-if="result">计算结果：{{ result }}</div>
  </div>
</template>

<script setup lang="ts">
import { ref } from 'vue';
import { executeHomomorphicQuery } from '@/api/computation';
import { decryptResult } from '@/utils/crypto';

const selectedTable = ref('');
const selectedColumn = ref('');
const selectedOperation = ref('');
const result = ref<number | null>(null);
const loading = ref(false);

const submitComputation = async () => {
  loading.value = true;
  try {
    const request = {
      table: selectedTable.value,
      column: selectedColumn.value,
      operation: selectedOperation.value
    };
    // 1. 发送计算请求，获取结果密文
    const encryptedResult = await executeHomomorphicQuery(request);
    // 2. 前端使用本地私钥解密
    const plainResult = await decryptResult(encryptedResult.data.ciphertext);
    result.value = plainResult[0]; // 假设结果是单个数值
  } catch (error) {
    console.error('计算失败:', error);
    ElMessage.error('计算执行失败');
  } finally {
    loading.value = false;
  }
};
</script>

3.3 数据库设计：存储密文与元数据

数据库（我们选用PostgreSQL）不再存储明文敏感数据，而是存储密文。表结构设计需要仔细考量。

核心数据表 encrypted_salary ： 

CREATE TABLE encrypted_salary (
    id BIGSERIAL PRIMARY KEY, -- 唯一业务ID，明文
    employee_id VARCHAR(64) NOT NULL, -- 员工ID，明文，用于关联
    department VARCHAR(64), -- 部门，明文（非敏感或可加密）
    -- 核心敏感字段，存储为二进制密文（BLOB）
    salary_cipher BYTEA NOT NULL,
    -- 元数据，用于辅助计算和查询优化
    encryption_scheme VARCHAR(32) NOT NULL DEFAULT 'CKKS',
    poly_modulus_degree INT, -- 加密参数，解密时需要
    scale BIGINT, -- 加密参数，解密时需要
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_employee_dept ON encrypted_salary(employee_id, department);

要点 ：

  1. BYTEA 类型用于存储二进制密文。密文体积很大，一条记录的密文可能达到几十KB甚至几百KB， 必须评估存储成本 。
  2. 必须同时存储加密时所用的 关键参数 （如 poly_modulus_degree , scale ），因为解密时必须使用相同的参数上下文。这些可以统一存储在另一张配置表中。
  3. 保留必要的明文关联字段（如 employee_id , department ），用于执行非敏感的条件筛选和关联查询。如果部门信息也敏感，则需要将其也加密，但这会使查询逻辑极度复杂。

4. 核心挑战、解决方案与性能调优实录

将同态加密投入实用，我们遇到了无数坑。这里分享几个最典型的。

4.1 挑战一：密文膨胀与计算开销

问题 ：一个 double 类型的薪资数值（8字节），加密成CKKS密文后可能变成约16KB。计算（尤其是乘法）速度极慢，单次乘法可能需要数十到数百毫秒。

我们的优化组合拳 ：

  1. 批量打包（Batching） ：CKKS方案的核心优势。它可以将一个明文向量（例如 [1000.0, 2000.0, 3000.0] ）编码并加密到 单个密文 中。这样，一次同态加法操作就能完成整个向量的加法，实现了“SIMD”（单指令多数据）式的并行计算。这极大地提高了吞吐量。在我们的薪资计算中，我们将同一部门的多条薪资打包进一个或几个密文中进行处理。
  2. 计算深度管理 ：同态加密，特别是CKKS，对乘法深度有限制。每次乘法都会增大密文中的“噪声”，超过一定深度后无法正确解密。我们需要在业务设计阶段就规划好计算路径，尽量使用加法，避免不必要的连续乘法。对于复杂的计算（如多项式拟合），需要采用“重线性化”和“模切换”技术，但这需要更深入的密码学知识。
  3. 异步计算与任务队列 ：对于耗时的计算任务，绝不能阻塞HTTP请求。我们引入了 Redis + Spring Boot的 @Async ，将计算任务提交到线程池，立即返回一个任务ID。前端轮询或通过WebSocket获取任务状态和结果。
  4. 缓存计算结果 ：对于常见的、输入不变的计算请求（如“上月部门A总薪资”），可以将结果密文缓存起来（注意缓存的是密文，安全性不变）。下次相同请求直接返回缓存密文，大幅提升响应速度。

4.2 挑战二：密文上的条件查询（检索）

这是同态加密的“阿克琉斯之踵”。你无法直接对密文执行 WHERE salary > 5000 这样的操作。

我们的变通方案 ：

  1. 预计算与标签化 ：对于常见的筛选条件，我们在数据加密上传前就做好准备。例如，需要按薪资范围查询，我们可以在加密时，额外生成几个“标签密文”，分别表示“是否大于5k”、“是否在5k-10k之间”等。这些标签本身也是同态加密的，可以在后续计算中通过同态乘法进行“选择”操作。但这需要预知查询模式，不够灵活。
  2. 可搜索加密（Searchable Encryption） ：对于精确匹配查询（如 employee_id = 'E001' ），我们可以采用对称加密下的可搜索加密方案（如SSE），但这与同态加密是两套体系，增加了系统复杂性。
  3. 可信代理模式（妥协方案） ：在安全要求稍低的场景，可以引入一个“可信代理”组件。代理持有解密密钥的一个份额（通过秘密共享），服务器将需要筛选的密文与条件发送给代理，代理在安全环境中进行部分解密和比较，返回一个加密的筛选结果给服务器。这相当于将信任边界从服务器部分转移到了代理。

在我们的平台中，我们主要采用了第一种“预计算标签化”方案，因为它与我们的计算平台结合最紧密，对于已知的、固定的分析报表需求，这是一种有效的折中。

4.3 挑战三：密钥管理与生命周期安全

私钥 sk 的安全是整个系统的生命线。

我们的策略 ：

  1. 客户端持有 ：私钥永远不离开可信的客户端环境（用户浏览器或专用客户端软件）。这是最安全的模式。
  2. 密钥派生与存储 ：不直接存储原始的 sk 。前端在生成密钥对时，会要求用户输入一个强口令。使用该口令通过PBKDF2算法派生出一个密钥加密密钥（KEK），再用KEK对 sk 进行加密后存储到 localStorage 。每次使用需要用户输入口令解密。
  3. 密钥轮换 ：定期（如每季度）建议用户生成新的密钥对。旧数据可以用旧密钥解密后，再用新公钥加密。这个过程可以设计成后台任务，但需要用户配合。
  4. 服务端零密钥 ：后端服务绝不存储、也不传输私钥。任何要求后端提供私钥的操作都是错误的设计。

5. 部署、监控与未来展望

5.1 系统部署要点

  1. 环境依赖 ：后端服务器需要安装对应操作系统的SEAL C++库及其依赖（如CMake, g++）。我们使用Docker将JNI封装层、编译好的动态库和Java应用一起打包，确保环境一致性。
  2. 资源预留 ：同态加密计算是内存和CPU大户。K8s部署时，需要为Pod设置较高的 requests 和 limits ，特别是内存。我们建议至少预留4核CPU和8GB内存作为计算节点的基线。
  3. 水平扩展 ：由于计算是密集型的，无状态的（除缓存外），非常适合水平扩展。我们可以部署多个计算引擎实例，通过Nginx或API Gateway进行负载均衡。

5.2 监控与日志

没有监控，线上系统就是盲人骑瞎马。我们重点监控：

  • 应用指标 ：每个计算任务的耗时（P99， P95）、成功率、JNI调用错误次数。
  • 系统指标 ：计算节点的CPU使用率、内存使用率（警惕内存泄漏）、GC情况。
  • 业务指标 ：每日计算任务类型分布、平均数据量大小。 我们使用Prometheus + Grafana进行监控看板展示，关键错误日志通过ELK收集，方便排查问题。

5.3 常见问题排查速查表

问题现象 可能原因 排查步骤
前端解密失败，提示“解密错误”或结果乱码 1. 前后端加密/解密参数不一致。
2. 密文在传输或存储过程中损坏。
3. 私钥不匹配或损坏。		 1. 检查后端返回的密文元数据（ poly_modulus_degree , scale ）是否与前端解密上下文参数一致。
2. 检查网络传输是否启用二进制格式（如 axios 的 responseType: 'arraybuffer' ）。
3. 重新生成密钥对，测试加密解密一个简单数字。
计算任务长时间不返回或超时 1. 数据量过大，单次计算超时。
2. JNI层死锁或崩溃。
3. 服务器资源（CPU/内存）耗尽。		 1. 查看任务日志，确认输入数据规模。考虑实施分页或分批计算。
2. 检查后端应用日志，是否有JNI相关的崩溃信息（如 hs_err_pid 文件）。
3. 监控服务器资源使用情况，升级配置或增加节点。
同态乘法后解密结果偏差巨大 1. 乘法深度超限，噪声过大。
2. CKKS的 scale 参数设置不合理，导致精度损失溢出。		 1. 简化计算逻辑，减少连续乘法次数。使用 Evaluator.relinearize() 和 ModulusSwitch 管理噪声。
2. 在加密前调整 scale 值，或使用动态 scale 调整策略。
前端加密上传速度极慢 1. 在浏览器主线程进行大量加密计算。
2. 待加密数据行数过多。		 1. 将加密操作移入 Web Worker ，避免阻塞UI。
2. 在前端进行分片上传，一次处理100-200行数据。

5.4 项目的局限与思考

经过这个项目，我深刻认识到同态加密并非银弹。它是一项强大的隐私增强技术，但代价是巨大的性能开销和工程复杂度。它最适合的场景是 对性能不极度敏感、数据隐私要求极高、且计算模式相对固定 的分析任务，比如合规要求的跨机构联合统计、金融领域的风险模型评估等。

对于更复杂的即席查询（Ad-hoc Query）或需要频繁比较、排序的场景，目前的同态加密技术仍力有未逮。通常需要结合其他技术，如可信执行环境（TEE）、联邦学习（Federated Learning）或差分隐私（Differential Privacy），形成混合解决方案。

最后一点个人体会 ：做这类深度技术项目，团队里必须有一个愿意深钻密码学原理的人，不能只停留在调库的层面。因为一旦出现奇怪的解密错误或性能瓶颈，你需要能看懂SEAL的文档和源码，甚至能调试C++的JNI代码。同时，和业务方保持紧密沟通，管理好他们的预期，明确告诉他们什么能做、什么不能做、以及做的代价是什么，这比技术本身更重要。这个平台上线后，并没有立刻替代所有传统数据分析，而是在几个对数据保密等级要求最高的场景中率先跑了起来，成为了我们数据安全体系中的一个重要拼图。

# 同态加密
Logo
亚马逊云科技技术品牌专区

更多推荐

LoRA（低秩适配）：大模型高效微调的革命性技术

LoRA（低秩适配）是一种高效的大模型微调技术，通过冻结预训练模型权重并注入低秩可训练矩阵，显著降低计算和存储成本。相比全量微调，LoRA参数减少90%以上，显存需求降至3-8GB，训练时间缩短至数小时，且支持灵活任务切换。其核心优势包括低硬件门槛、高效训练和部署灵活性，适用于垂直领域适配、生成式AI定制等场景。经验表明，秩r=4或8通常效果良好，但LoRA在数据量极大或任务复杂时可能受限。技术演

avatar 亚马逊云科技技术品牌专区
cover

2026年AI写作辅助平台推荐：9款高效AI工具终极指南

avatar 亚马逊云科技技术品牌专区
cover

TVA对具身智能领域“莫拉维克悖论“的挑战（19）

avatar 亚马逊云科技技术品牌专区