[论文解读] Oblivious Storage with Low I/O Overhead

Michael T. Goodrich, Michael Mitzenmacher+2 more|arXiv (Cornell University)|Oct 9, 2011

Cryptography and Data Security参考文献 18被引用 4

一句话总结

该论文提出了一种新颖的不经意存储（OS）方案，通过利用递归缓冲区洗牌技术，结合大小为 $O(N^{1/c})$ 的客户端私有内存（其中 $c \geq 2$ 为常数），实现了每次数据访问的 $O(1)$ 摊销I/O开销。该方法在通信和存储成本最低的前提下，同时保障了数据内容和访问模式的隐私，相较于以往的OS解决方案，在云存储系统（如Amazon S3）中展现出更高的I/O效率和更低的经济成本。

ABSTRACT

We study oblivious storage (OS), a natural way to model privacy-preserving data outsourcing where a client, Alice, stores sensitive data at an honest-but-curious server, Bob. We show that Alice can hide both the content of her data and the pattern in which she accesses her data, with high probability, using a method that achieves O(1) amortized rounds of communication between her and Bob for each data access. We assume that Alice and Bob exchange small messages, of size $O(N^{1/c})$, for some constant $c\ge2$, in a single round, where $N$ is the size of the data set that Alice is storing with Bob. We also assume that Alice has a private memory of size $2N^{1/c}$. These assumptions model real-world cloud storage scenarios, where trade-offs occur between latency, bandwidth, and the size of the client's private memory.

研究动机与目标

• 设计一种实用的不经意存储系统，使半诚实的云服务器无法获知数据内容和访问模式。
• 在保持强隐私保证的前提下，最小化云环境下的数据外包所导致的I/O开销和通信成本。
• 通过最小化在Amazon S3等云存储服务上的远程操作次数，降低不经意访问的经济成本。
• 通过简化协议并减少存储膨胀，超越现有的ORAM和OS方案。
• 通过参数 $c$ 实现客户端内存与通信大小之间的可调权衡，实现每次访问的 $O(1)$ 摊销I/O开销。

提出的方法

• 该方案使用递归缓冲区洗牌算法，在多级存储中不经意地管理数据项和虚拟项，确保访问模式不可区分。
• 客户端私有内存大小为 $O(N^{1/c})$，用于存储中间缓冲区和元数据，支持在远程I/O之前进行高效的本地洗牌。
• 每次访问涉及 $O(1)$ 次远程I/O操作：每次访问包含一次获取和一次删除操作，且I/O次数在多个操作间实现摊销。
• 系统将云存储建模为键值存储，并使用大小为 $O(N^{1/c})$ 的消息，以平衡带宽与客户端内存开销。
• 在最低层使用类似Cuckoo哈希的结构，以支持在不经意访问期间高效地插入和删除操作。
• 协议设计兼容真实世界的云API，避免了完整ORAM模拟的复杂性。

实验结果

研究问题

• RQ1 是否可以在保持强隐私保证的前提下，实现 $O(1)$ 摊销I/O开销的不经意存储？
• RQ2 客户端内存大小 $O(N^{1/c})$ 的选择如何影响不经意存储中的I/O效率和通信成本？
• RQ3 与以往的OS方案相比，递归缓冲区洗牌技术能否同时降低I/O和数据传输开销？
• RQ4 所提出的OS方案在Amazon S3等真实云平台上的实际性能和经济成本如何？
• RQ5 与现有方案（如Boneh等人[4]和Williams等人[23]）相比，该方法在I/O效率和存储开销方面表现如何？

主要发现

• 所提出的OS方案实现了每次访问 $O(1)$ 摊销I/O开销，对于 $c=2$，摊销情况下仅需2次I/O；对于 $c=3$，摊销情况下仅需7次I/O。
• 对于 $c=2$，与Boneh等人[4]相比，I/O开销从13次降至1次，数据传输量减少10%。
• 访问100万个1KB大小的项目，总经济成本估算为 $55,066（$c=2$），由于远程操作次数更少，显著低于其他方案。
• 对于 $c=2$，平均每次访问的延迟降低至500ms（摊销），相较于Boneh等人[4]在10万个项目的场景下，访问时间提升30%。
• 存储开销为 $N + 2N^{1/2}$（$c=2$），与Boneh等人[4]一致，远低于 $O(N\log N)$ 的方案。
• 该方法具有良好的可扩展性：对于 $c=3$，摊销I/O次数仍保持在7次，100万个项目的总成本为 $170,646，仍低于竞争方案。