💻 computer science

Gyokuro: Source-assisted Private Membership Testing using Trusted Execution Environments

本文提出了 Gyokuro 系统，利用可信执行环境（TEE）替代传统证明机制，通过验证服务器对数据项的添加进度而非直接生成存在性证明，实现了高效、可扩展且隐私性强的源辅助私有成员测试。

原作者： Yoshimichi Nakatsuka, Nicolas Dutly, Kari Kostiainen, Srdjan Capkun

发布于 2026-03-25

📖 1 分钟阅读☕ 轻松阅读

原作者： Yoshimichi Nakatsuka, Nicolas Dutly, Kari Kostiainen, Srdjan Capkun

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

这篇论文介绍了一个名为 Gyokuro（玉露，一种日本绿茶）的新系统。它的核心任务是解决一个非常棘手的问题：如何在不泄露秘密的情况下，确认某个东西确实被存进了一个巨大的公共数据库里？

为了让你轻松理解，我们可以把整个系统想象成一个**“超级透明的保险箱”和“严格的公证处”**的故事。

1. 核心难题：想查账，但不想暴露想查什么

想象一下，你买了一支昂贵的药（数据项），药盒上有个二维码（来源辅助信息）。你想知道这支药的供应链记录是否真的被存入了一个公共的“官方日志”（数据库）里，以防假药。

传统方法的困境：
- 直接问： 如果你直接问官方日志：“这支药在吗？”官方日志就知道你想查这支药了。如果官方日志是坏人，它可能会偷偷把这支药删掉，然后骗你说“没这支药”，或者更糟，它知道你在查什么，从而泄露你的隐私。
- 下载全库： 如果你把整个官方日志（可能有几十亿条记录）下载下来自己查，那太慢了，而且你的手机会爆炸。
- 加密查询： 以前有很多复杂的加密方法（像 PIR、ORAM 等），但它们要么太慢，要么计算量太大，根本跑不动。

2. Gyokuro 的创意解法：不看“内容”，只看“进度条”

Gyokuro 换了一个思路。它不直接问“药在不在？”，而是问：“你处理数据的进度条走到哪了？”

它利用了三个角色：

药厂（数据源）： 给你药和二维码。
官方日志（服务器/数据库）： 负责存药记录。
可信的保险箱（TEE）： 这是一个硬件级别的“黑盒子”（如 Intel SGX 或 AMD SEV），里面的代码是锁死的，外面的人（包括服务器管理员）无法偷看或篡改。
第三方公证员（Monitor）： 一个独立的机构，定期去抄写官方日志的账本，确保没人偷偷删数据。

故事流程：

第一步：提交与“收据” (Upload)

药厂把药的信息发给“可信保险箱”。
保险箱收到后，立刻在内部的一个计数器上加 1，并给你一张电子收据（POR）。
关键点： 这张收据上写着：“我在第 100 号计数器时收到了你的药”。此时，药还在保险箱的缓冲区里，还没真正存入巨大的公共数据库。
保险箱攒够了一批药（比如 1000 个），就一次性把它们扔进公共数据库，然后计数器继续加。

第二步：你的查询 (Testing)

过了几天，你拿着药和那张“第 100 号收据”去查账。
你不需要告诉服务器你想查哪支药！你只需要问服务器：“现在的计数器走到第几号了？”
服务器（通过可信保险箱）给你一张**“处理证明”（POP）**，上面写着：“现在的计数器已经到了第 5000 号”。
逻辑推理： 既然现在的进度（5000）远远超过了你拿到收据时的进度（100），那就说明你的药肯定已经被处理并扔进数据库里了！因为保险箱是按顺序处理的，不可能跳过。

第三步：防止“偷梁换柱” (Consistency Check)

你可能会担心：服务器会不会把数据库里的药偷偷删了？
这时候，第三方公证员登场了。公证员定期下载整个数据库，算出一个“总账本指纹”（哈希值）。
你同时向“可信保险箱”和“公证员”索要这个指纹。
如果两者的指纹对得上，说明数据库是完整的，没人删数据。
如果指纹对不上，或者进度条没动，你就知道出问题了。

3. 为什么这个方法很厉害？（比喻版）

隐私保护（像盲盒）：
传统的查账是“把药盒打开给管理员看，问他在不在”。Gyokuro 是“管理员只看进度条，完全不知道你在查哪支药”。即使管理员想偷看，他也只能看到你在问“进度条是多少”，而不知道具体是哪支药。这就像你在图书馆查书，管理员只看到你问“第 500 页之后的书都在吗？”，而不知道你在找哪本具体的书。
速度极快（像闪电）：
以前的方法需要遍历几亿条记录，像在大海里捞针。Gyokuro 只需要比对两个数字（计数器）和两个指纹。这就像你不需要数完超市里所有的苹果，只需要看收银台的小票总数是否增加了，就知道你的苹果被扫进去了。
- 实测数据： 查一次账只需要 7 毫秒（眨眼都来不及），每秒能处理 1400 次查询。
无需下载（像看新闻）：
你不需要下载整个数据库（几 GB 甚至 TB 的数据），只需要几个字节的小数据包。

4. 这个系统能用来做什么？

证书透明度（CT）： 浏览器检查网站证书是否被合法签发并记录，防止黑客伪造证书，同时不暴露你在访问什么网站。
供应链审计： 消费者买药或奢侈品，扫码确认供应链记录在案，证明是真货，但不需要向官方透露你买了什么（保护商业机密或个人隐私）。
数据溯源： 验证一张新闻照片或视频是否被官方记录过，防止 AI 伪造（Deepfake），同时不泄露你正在调查哪条新闻。

5. 有什么缺点吗？

这个系统依赖一个**“可信的硬件保险箱”（TEE）**。

比喻： 这就像我们假设那个“黑盒子”是绝对诚实且无法被黑客攻破的。虽然目前的技术（如 Intel SGX）非常安全，但理论上如果未来出现了能攻破这种硬件的黑客，或者硬件厂商自己作恶，这个信任基础就会动摇。
不过，相比于以前那些慢吞吞、耗资源的加密方法，Gyokuro 在速度和隐私之间找到了一个极佳的平衡点。

总结

Gyokuro 就像是一个**“不看内容只数数的超级管家”**。它利用硬件的安全性和第三方的监督，让你在不暴露“我想查什么”的前提下，确信“我的东西确实被存好了”。它把原本需要几秒甚至几分钟的复杂验证，压缩到了眨眼之间（7 毫秒），让大规模、高隐私的数据库验证成为可能。

这是一份关于论文《Gyokuro: Source-assisted Private Membership Testing using Trusted Execution Environments》（Gyokuro：基于可信执行环境的源辅助私有成员测试）的详细技术总结。

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

核心问题：私有成员测试 (PMT) 的局限性
私有成员测试（Private Membership Testing, PMT）旨在让客户端验证某个数据项是否存在于数据库中，而无需向数据库运营商或外部方泄露该数据项的具体内容。现有的 PMT 方案（如私有信息检索 PIR、私有集合交集 PSI、 oblivious RAM ORAM 等）通常面临以下挑战：

效率与可扩展性差：许多方案需要复杂的密码学原语，导致通信和计算开销随数据库规模增大而显著增加。
隐私泄露风险：基于可信计算（TEE）的现有方案通常要求客户端将查询发送给 TEE，这使得查询内容在 TEE 内部以明文形式存在，容易受到侧信道攻击（Side-channel attacks）的威胁。
缺乏源辅助信息利用：现有的方案往往忽略了数据源在提交数据时提供的辅助信息（Source-assisted information）。

特定场景：源辅助私有成员测试 (SPMT)
本文聚焦于 SPMT 这一变体。在 SPMT 中，客户端不仅拥有待验证的数据项，还拥有数据源在数据首次提交时提供的辅助信息（如数字签名、时间戳等）。

应用场景：证书透明度（CT）日志审计、供应链审计（如药品供应链）、数据溯源验证、公共文档审计。
现有痛点：设计一种既高效、可扩展，又能严格保护隐私的 SPMT 协议极具挑战性。例如，在 CT 日志审计中，浏览器通常无法进行高效的私有审计，或者仅能提供半私有的 $k$ -集合匿名性。

2. 方法论：Gyokuro 系统 (Methodology)

Gyokuro 提出了一种不同于传统方案的思路：不要求服务器证明“数据存在”，而是利用可信执行环境（TEE）证明“服务器已处理了足够多的数据进度”，从而推断目标数据已被存储。

核心设计思想

利用 TEE 的执行完整性而非机密性：
- 传统 TEE 方案依赖 TEE 的机密性来隐藏查询，但这容易受侧信道攻击。
- Gyokuro 假设 TEE 的执行完整性（Execution Integrity）是可信的，但承认无法保证绝对的执行时效性（Execution Timeliness，即恶意服务器可延迟网络包或暂停 TEE）。
- 解决方案：不直接验证数据是否“现在”在库中，而是验证 TEE 是否已经“处理了足够多的进度”，使得目标数据必然已被处理。
双协议流程：
- 上传协议 (Upload Protocol)：
  - 数据源将数据项 $d$ 发送给 TEE。
  - TEE 生成一个“接收证明”（Proof Of Reception, POR），包含数据 $d$ 、当前单调递增的计数器值 $cnt_{POR}$ 以及 TEE 的签名。
  - TEE 将数据批量存入外部数据库，并更新一个累加器（如哈希链），同时递增计数器。
- 测试协议 (Testing Protocol)：
  - 客户端持有目标数据 $d'$ 及其对应的 POR（源辅助信息）。
  - 客户端向 TEE 请求“处理证明”（Proof Of Processing, POP），即 TEE 对当前计数器值 $cnt_{POP}$ 的签名。
  - 逻辑推断：如果 $cnt_{POP} > cnt_{POR}$ ，说明 TEE 已经处理了比接收 $d'$ 时更多的数据，因此 $d'$ 必然已被处理并存储。
  - 一致性检查：客户端同时向第三方监控器（Monitor）和 TEE 请求累加器值。如果两者匹配，证明数据库未被恶意删除数据，且 TEE 与监控器视图一致。
关键组件：
- 单调递增计数器：存储在 TEE 内部，用于追踪处理进度。
- 累加器 (Accumulator)：TEE 和监控器分别维护数据库内容的哈希链（或默克尔树根），用于验证数据完整性。
- 第三方监控器 (Monitor)：负责定期下载数据库并验证累加器，防止服务器分裂视图攻击（Split-view attacks）。

隐私保护机制

在成员测试阶段，客户端不向 TEE 或数据库发送任何关于其感兴趣的数据项的信息。
客户端仅通过比较计数器数值和累加器哈希值来推断结果。
即使 TEE 遭受侧信道攻击，由于查询内容从未进入 TEE，客户端的隐私依然得到保护。

3. 主要贡献 (Key Contributions)

问题识别：明确了源辅助私有成员测试（SPMT）在证书透明度、供应链审计等热门应用中的重要性，并指出当前缺乏高效、可扩展的解决方案。
新颖方案 (Gyokuro)：
- 提出了一种基于 TEE 的 SPMT 方案，利用 TEE 的执行完整性而非机密性。
- 实现了零信息泄露：客户端在测试过程中不向服务器、TEE 或第三方透露其查询目标。
- 摆脱了对复杂密码学原语（如 ORAM）的依赖，避免了侧信道攻击风险。
性能突破：
- 常数级复杂度：通信和计算开销与数据库大小无关（ $O(1)$ ），支持大规模数据库（如数十亿条证书）。
- 高吞吐量：实现了每秒每核数千次请求的处理能力。
安全分析：证明了方案在对抗恶意服务器、恶意数据源和半诚实监控器情况下的正确性和隐私性。

4. 实验结果 (Results)

作者在 Azure 云环境（基于 AMD SEV TEE）上进行了实现和评估：

延迟 (Latency)：
- 上传延迟：约 6.5 ms（在 1024 个并发数据源下）。
- 成员测试延迟：约 7 ms（包括密码学验证、远程认证等所有步骤）。
- 延迟主要受网络 RTT 影响，与数据库规模无关。
吞吐量 (Throughput)：
- 上传吞吐量：约 1021 请求/秒/核。
- 测试吞吐量：约 1432 请求/秒/核（在 2048 个并发客户端下）。
可扩展性：
- 系统能够轻松应对大规模场景。例如，对于证书透明度（CT），每天数百万的证书提交和数十亿次查询，Gyokuro 的性能绰绰有余。
实现细节：
- 使用 Go 语言实现 TEE 逻辑（约 1.5K 行代码）。
- 利用 ECDSA (SECP256R1) 和 SHA256。
- 使用 SQLite3 作为内存数据库。

5. 意义与局限性 (Significance & Limitations)

意义：

隐私与安全的新范式：Gyokuro 展示了如何利用 TEE 的“进度证明”而非“数据保密”来解决隐私问题，有效规避了针对 TEE 机密性的侧信道攻击。
实用性强：极低的延迟和极高的吞吐量使其能够直接应用于现有的大规模系统（如浏览器 CT 日志审计、药品供应链监管）。
开源：作者已开源了完整的实现代码，促进了后续研究和部署。

局限性：

依赖 TEE 信任假设：方案的安全性依赖于 TEE 的执行完整性不被破坏。如果未来 TEE 硬件被攻破（如出现针对执行完整性的攻击），方案将失效。相比之下，纯密码学方案不依赖硬件信任。
非交互式限制：虽然减少了交互，但仍需 TEE 和监控器的参与，无法做到完全的非交互式（Non-interactive）本地验证（如下载整个数据库）。
DoS 攻击：无法防御拒绝服务攻击（恶意服务器不响应请求）。

未来工作：

探索无需 TEE 的设计方案。
扩展设计以支持更复杂的查找操作（Lookup）。
将 Gyokuro 集成到现有的实际应用中。

总结

Gyokuro 是一项在隐私保护与系统性能之间取得极佳平衡的创新工作。它通过巧妙利用 TEE 的进度追踪机制和第三方监控，解决了传统 PMT 方案中效率低、隐私易受侧信道攻击的痛点，为证书透明度、供应链审计等关键基础设施提供了高效、可扩展且隐私安全的解决方案。