313 research outputs found
Deterministic, Stash-Free Write-Only ORAM
Write-Only Oblivious RAM (WoORAM) protocols provide privacy by encrypting the
contents of data and also hiding the pattern of write operations over that
data. WoORAMs provide better privacy than plain encryption and better
performance than more general ORAM schemes (which hide both writing and reading
access patterns), and the write-oblivious setting has been applied to important
applications of cloud storage synchronization and encrypted hidden volumes. In
this paper, we introduce an entirely new technique for Write-Only ORAM, called
DetWoORAM. Unlike previous solutions, DetWoORAM uses a deterministic,
sequential writing pattern without the need for any "stashing" of blocks in
local state when writes fail. Our protocol, while conceptually simple, provides
substantial improvement over prior solutions, both asymptotically and
experimentally. In particular, under typical settings the DetWoORAM writes only
2 blocks (sequentially) to backend memory for each block written to the device,
which is optimal. We have implemented our solution using the BUSE (block device
in user-space) module and tested DetWoORAM against both an encryption only
baseline of dm-crypt and prior, randomized WoORAM solutions, measuring only a
3x-14x slowdown compared to an encryption-only baseline and around 6x-19x
speedup compared to prior work
SqORAM: Read-Optimized Sequential Write-Only Oblivious RAM
Oblivious RAM protocols (ORAMs) allow a client to access data from an
untrusted storage device without revealing the access patterns. Typically, the
ORAM adversary can observe both read and write accesses. Write-only ORAMs
target a more practical, {\em multi-snapshot adversary} only monitoring client
writes -- typical for plausible deniability and censorship-resilient systems.
This allows write-only ORAMs to achieve significantly-better asymptotic
performance. However, these apparent gains do not materialize in real
deployments primarily due to the random data placement strategies used to break
correlations between logical and physical namespaces, a required property for
write access privacy. Random access performs poorly on both rotational disks
and SSDs (often increasing wear significantly, and interfering with
wear-leveling mechanisms). In this work, we introduce SqORAM, a new
locality-preserving write-only ORAM that preserves write access privacy without
requiring random data access. Data blocks close to each other in the logical
domain land in close proximity on the physical media. Importantly, SqORAM
maintains this data locality property over time, significantly increasing read
throughput. A full Linux kernel-level implementation of SqORAM is 100x faster
than non locality-preserving solutions for standard workloads and is 60-100%
faster than the state-of-the-art for typical file system workloads
Path ORAM: An Extremely Simple Oblivious RAM Protocol
We present Path ORAM, an extremely simple Oblivious RAM protocol with a small
amount of client storage. Partly due to its simplicity, Path ORAM is the most
practical ORAM scheme known to date with small client storage. We formally
prove that Path ORAM has a O(log N) bandwidth cost for blocks of size B =
Omega(log^2 N) bits. For such block sizes, Path ORAM is asymptotically better
than the best known ORAM schemes with small client storage. Due to its
practicality, Path ORAM has been adopted in the design of secure processors
since its proposal
DivORAM: Towards a practical oblivious RAM with variable block size
Oblivious RAM (ORAM) is important for applications that require hiding access patterns. Many ORAM schemes have been proposed but most of them support only storing blocks of the same size. For the variable length data blocks, they usually fill them upto the same length before uploading, which leads to an increase in storage space and network bandwidth usage. To develop the first practical ORAM with variable block size, we proposed the “DivORAM” by remodeling the tree-based ORAM structure. It employs an additively homomorphic encryption scheme (Damgård–Jurik cryptosystem) executing at the server side to save the client computing overhead and the network bandwidth cost. As a result, it saves network bandwidth 30% comparing with Ring ORAM and 40% comparing with HIRB ORAM. Experiment results show that the response time of DivORAM is 10 ×  improved over Ring ORAM for practical parameters
SoK: Cryptographically Protected Database Search
Protected database search systems cryptographically isolate the roles of
reading from, writing to, and administering the database. This separation
limits unnecessary administrator access and protects data in the case of system
breaches. Since protected search was introduced in 2000, the area has grown
rapidly; systems are offered by academia, start-ups, and established companies.
However, there is no best protected search system or set of techniques.
Design of such systems is a balancing act between security, functionality,
performance, and usability. This challenge is made more difficult by ongoing
database specialization, as some users will want the functionality of SQL,
NoSQL, or NewSQL databases. This database evolution will continue, and the
protected search community should be able to quickly provide functionality
consistent with newly invented databases.
At the same time, the community must accurately and clearly characterize the
tradeoffs between different approaches. To address these challenges, we provide
the following contributions:
1) An identification of the important primitive operations across database
paradigms. We find there are a small number of base operations that can be used
and combined to support a large number of database paradigms.
2) An evaluation of the current state of protected search systems in
implementing these base operations. This evaluation describes the main
approaches and tradeoffs for each base operation. Furthermore, it puts
protected search in the context of unprotected search, identifying key gaps in
functionality.
3) An analysis of attacks against protected search for different base
queries.
4) A roadmap and tools for transforming a protected search system into a
protected database, including an open-source performance evaluation platform
and initial user opinions of protected search.Comment: 20 pages, to appear to IEEE Security and Privac
- …