selecting-privacy-enhancing-technologies

选择增强隐私技术

概述

增强隐私技术（PET）是在个人数据收集、处理、存储和共享过程中保护数据的技术措施。GDPR 并未规定具体技术，但要求采取“适当的技术措施”（第 25(1) 条、第 32(1) 条）来落实数据保护原则。欧盟委员会于 2025 年 2 月发布的关于 PET 的通报，以及 ENISA 2023 年发布的关于利用 PET 实现隐私保护设计的报告，为采用 PET 提供了监管背景。

选择合适的 PET 取决于处理场景、数据敏感性、计算要求，以及所需的具体隐私属性（机密性、匿名性、不可关联性或透明度）。

PET 分类

1. 差分隐私（DP）

隐私属性： 统计不可区分性——无论是否包含任何个人的数据，分析输出都大致相同。

特征	详情
方法	向查询结果或模型梯度添加经过校准的噪声
隐私保证	可通过数学证明的（epsilon, delta）界限
数据效用	可通过 epsilon 调节；epsilon 越低 = 隐私性越强，效用越低
性能开销	查询时添加噪声的开销极低；DP-SGD 训练的开销中等
成熟度	已可用于生产环境（Apple、Google、美国人口普查局）
GDPR 相关性	epsilon 足够小时，支持序言 26 中的匿名化；属于第 25(1) 条规定的隐私保护设计措施

最适合： 统计分析、汇总报告，以及使用敏感数据训练 ML 模型。

库： Google DP Library、OpenDP、IBM diffprivlib、PyDP。

2. 同态加密（HE）

隐私属性： 对加密数据进行计算——只有数据所有者才能解密结果。

特征	详情
方法	对数据进行加密，使密文上的数学运算在解密后产生有效结果
隐私保证	基于密码学（基于格的困难性假设）
数据效用	精确结果（不添加噪声）
性能开销	高：比明文处理慢 1,000 倍至 1,000,000 倍，具体取决于方案和运算
成熟度	生产应用尚处于起步阶段；性能优化研究活跃
GDPR 相关性	第 32(1)(a) 条将加密作为安全措施；支持在不向处理者暴露明文的情况下进行处理

方案：

• BFV（Brakerski/Fan-Vercauteren）： 整数运算，结果精确。适用于计数、匹配。
• BGV（Brakerski-Gentry-Vaikuntanathan）： 支持模数切换的整数运算。适用于深度电路，效率较高。
• CKKS（Cheon-Kim-Kim-Song）： 对实数/复数进行近似运算。适用于 ML 推理。
• TFHE（Torus FHE）： 快速自举，逐门求值。适用于布尔电路。

库： Microsoft SEAL、IBM HELib、Google FHE（全同态加密转译器）、TFHE-rs、OpenFHE。

3. 安全多方计算（SMPC）

隐私属性： 在不泄露各方输入的情况下联合计算——每一方只能获知最终结果。

特征	详情
方法	秘密共享、混淆电路或不经意传输协议
隐私保证	信息论安全（适用于秘密共享）或计算安全（适用于混淆电路）
数据效用	精确结果
性能开销	中到高；取决于电路复杂度和参与方数量
成熟度	已在金融服务和医疗保健联盟中投入生产
GDPR 相关性	支持在不共享数据的情况下开展联合控制（第 26 条）分析；有助于实现数据最小化（第 5(1)(c) 条）

框架： MP-SPDZ、CrypTen（Meta）、MOTION、ABY/ABY3、Sharemind。

4. 联邦学习（FL）

隐私属性： 无需集中数据即可训练模型——原始数据绝不会离开数据所有者的环境。

特征	详情
方法	将模型训练分发给数据所有者；仅聚合模型更新（梯度）
隐私保障	数据本地化（原始数据保留在设备上）；通过安全聚合和 DP 加强保护
数据效用	取决于参与方之间的数据分布（IID 与非 IID）
性能开销	交换梯度会产生通信开销；需要进行多轮训练
成熟度	已在 Google（Gboard）、Apple（Siri）和医院（NVIDIA FLARE）投入生产使用
GDPR 相关性	支持第 5(1)(c) 条的数据最小化；减少跨境传输要求（第 V 章）

框架： TensorFlow Federated、PySyft（OpenMined）、NVIDIA FLARE、Flower、FedML。

5. 零知识证明（ZKP）

隐私属性： 在不透露底层数据的情况下证明某项陈述为真。

特征	详情
方法	证明者证明自己知道某个秘密（例如，年龄 ≥ 18 岁），但不透露该秘密（出生日期）
隐私保障	完备性（错误陈述无法被证明）和零知识性（验证者除了知道陈述为真之外，不会获知任何信息）
数据效用	二元验证（证明有效/无效）；不披露任何数据
性能开销	生成证明：中到高；验证证明：快
成熟度	已用于区块链身份认证；企业身份验证领域正在兴起
GDPR 相关性	实现极致的数据最小化——无需披露数据即可证明合规；支持第 5(1)(c) 条和第 25 条

系统： zk-SNARKs（Groth16、PLONK）、zk-STARKs、Bulletproofs。

6. 可信执行环境（TEE）

隐私属性： 隔离计算——数据在硬件保护的安全区内处理，连系统管理员也无法访问。

特征	详情
方法	使用安全区（Intel SGX、AMD SEV、ARM TrustZone、AWS Nitro）实现硬件强制隔离
隐私保障	基于硬件的证明和内存加密
数据效用	可在安全区内进行完整计算
性能开销	低到中等；安全区内存有限，可能需要流式传输数据
成熟度	已投入生产使用：Azure Confidential Computing、AWS Nitro Enclaves、Google Confidential VMs
GDPR 相关性	第 32(1)(a) 条要求处理过程中的加密；第 28 条规定处理者保障；防范内部人员威胁

用例匹配矩阵

用例	DP	HE	SMPC	FL	ZKP	TEE	推荐首选方案
对客户数据进行汇总分析	5	2	3	2	1	3	差分隐私
对分布式医院数据训练 ML 模型	3	1	2	5	1	3	联邦学习
不共享财务记录进行信用评分	2	3	5	2	2	3	安全多方计算
不透露出生日期进行年龄验证	1	1	1	1	5	2	零知识证明
在第三方云中处理加密客户数据	2	5	2	1	1	4	同态加密
跨银行开展反洗钱工作	2	2	5	3	2	3	安全多方计算
隐私保护基因组分析	3	4	3	3	1	4	HE + TEE 组合
对托管在云端的 ML 模型进行机密推理	2	4	2	1	1	5	可信执行环境
隐私保护调查和投票	5	1	3	1	2	1	差分隐私
在加密数据库中安全搜索关键词	1	4	1	1	1	4	同态加密

评分：1 = 不太适用，5 = 非常适用

PET 选择决策框架

步骤 1：定义隐私要求

• 主要的数据保护原则是什么？（最小化、保密、匿名化、不可链接）
• 目标是保护传输中、静态存储中还是处理过程中的数据？
• 对手模型是诚实但好奇，还是恶意？
• 是否存在跨组织边界（多个控制者／处理者）？

步骤 2：评估约束条件

• 可接受的性能开销是多少？（实时处理还是批处理）
• 计算预算是多少？（HE 需要显著更多的资源）
• 涉及多少参与方？（SMPC 的扩展性受参与方数量影响）
• 是否有可用的硬件信任根？（TEE 需要特定硬件）
• 团队具备哪些密码工程专业知识？

步骤 3：评估组合方案

许多生产部署会组合使用 PET，以实现纵深防御：

组合	优势
FL + DP	联邦学习结合差分隐私梯度更新，可防止梯度反演攻击
FL + Secure Aggregation	聚合服务器无法看到单个梯度
HE + TEE	在飞地内处理加密数据，提供双重保护
SMPC + DP	对 SMPC 输出添加噪声，提供形式化的匿名化保证
ZKP + TEE	证明计算是在飞地内正确执行的，同时不泄露输入

步骤 4：验证 GDPR 合规性

• 所选 PET 是否符合第 25(1) 条的设计阶段数据保护要求？
• 是否落实了第 32(1) 条中的具体安全措施？
• 是否支持第 5(1)(c) 条的数据最小化原则？
• 如果声称实现了匿名化，是否符合序言第 26 条关于防止单独识别、关联和推断的标准？
• 是否充分记录了 PET 的隐私保证，以用于 DPIA（第 35 条）？

主要法规参考

• GDPR 第 25(1) 条——设计阶段数据保护
• GDPR 第 32(1)(a) 条——将加密和假名化作为安全措施
• GDPR 第 5(1)(c) 条——数据最小化原则
• GDPR 序言第 26 条——匿名信息
• ENISA 报告：《数据保护工程》（2022）
• 欧盟委员会关于 PET 的通告（2025 年 2 月）
• EDPB《第 4/2019 号指南：第 25 条所述的设计阶段和默认数据保护》