Flat ORAM: A Simplified Write-Only Oblivious RAM Construction for Secure Processors

Flat ORAM: A Simplified Write-Only Oblivious RAM Construction for Secure Processors

Syed Kamran Haider University of Connecticut syed.haider@uconn.edu  and  Marten van Dijk University of Connecticut marten.van_dijk@uconn.edu
Abstract.

Oblivious RAM (ORAM) is a cryptographic primitive which obfuscates the access patterns to a storage thereby preventing privacy leakage. So far in the current literature, only ‘fully functional’ ORAMs are widely studied which can protect, at a cost of considerable performance penalty, against the strong adversaries who can monitor all read and write operations. However, recent research has shown that information can still be leaked even if only the write access pattern (not reads) is visible to the adversary. For such weaker adversaries, a fully functional ORAM turns out to be an overkill causing unnecessary overheads. Instead, a simple ‘write-only’ ORAM is sufficient, and, more interestingly, is preferred as it can offer far more performance and energy efficiency than a fully functional ORAM.

In this work, we present Flat ORAM: an efficient write-only ORAM scheme which outperforms the closest existing write-only ORAM called HIVE. HIVE suffers from performance bottlenecks while managing the memory occupancy information vital for correctness of the protocol. Flat ORAM resolves these bottlenecks by introducing a simple idea of Occupancy Map (OccMap) which efficiently manages the memory occupancy information resulting in far better performance. Our simulation results show that, on average, Flat ORAM only incurs a moderate slowdown of over the insecure DRAM for memory intensive benchmarks among Splash2 and for SPEC06. Compared to HIVE, Flat ORAM offers performance gain on average and up to energy savings.

Cloud computing security; Hardware security; Secure computer architectures; Oblivious RAM; Side channels
copyright: rightsretaineddoi: 10.475/123_4isbn: 123-4567-24-567/08/06conference: ; ; journalyear: 2017ccs: Security and privacy Security in hardwareccs: Security and privacy Systems security

1. Introduction

User’s data privacy concerns in computation outsourcing to cloud servers have gained serious attention over the past couple of decades. To address this challenge, various trusted-hardware based secure processor architectures have been proposed including TPM (Arbaugh et al., 1997; Sarmenta et al., 2006; Trusted Computing Group, 2004), Intel’s TPM+TXT (Grawrock, 2006), eXecute Only Memory (XOM) (Lie et al., 2003a, b; Lie et al., 2000), Aegis (Suh et al., 2003; Suh et al., 2005), Ascend (Fletcher et al., 2012), Phantom (Maas et al., 2013) and Intel’s SGX (McKeen et al., 2013). A trusted-hardware platform receives user’s encrypted data, which is decrypted and computed upon inside the trusted boundary, and finally the encrypted results of the computation are sent to the user.

Although all the data stored outside the secure processor’s trusted boundary, e.g. in the main memory, can be encrypted, information can still be leaked to an adversary through the access patterns to the stored data (Zhuang et al., 2004). In order to prevent such leakage, Oblivious RAM (ORAM) is a well established technique, first proposed by Goldreich and Ostrovsky (Goldreich and Ostrovsky, 1996). ORAM obfuscates the memory access pattern by introducing several randomized ‘redundant’ accesses, thereby preventing privacy leakage at a cost of significant performance penalty. Intense research over the last few decades has resulted in more and more efficient and secure ORAM schemes (Boneh et al., 2011; Damgård et al., 2011; Goodrich et al., 2011, 2012a, 2012b; Ostrovsky, 1990; Ostrovsky and Shoup, 1997; Shi et al., 2011; Stefanov et al., 2012; Stefanov et al., 2013; Williams and Sion, 2012; Fletcher et al., 2015; Zhang et al., 2015; Yu et al., 2015).

A key observation regarding the adversarial model assumed by the current renowned ORAM techniques is that the adversary is capable of learning fine-grained information of all the accesses made to the memory. This includes the information about which location is accessed, the type of operations (read/write), and the time of the access. It is an extremely strong adversarial model which, in most cases, requires direct physical access to the memory address bus in order to monitor both read and write accesses, e.g. the case of a curious cloud server.

On the other hand, for purely remote adversaries (where the cloud server itself is trusted), direct physical access to the memory address bus is not possible thereby preventing them from directly monitoring read/write access patterns. Such remote adversaries, although weaker than adversaries having physical access, can still “learn” the application’s write access patterns. Interestingly, privacy leakage is still possible even if the adversary is able to infer just the write access patterns of an application.

John et al. demonstrated such an attack (Merin John et al., 2017) on the famous Montgomery’s ladder technique (Joye and Yen, 2002) commonly used for modular exponentiation in public key cryptography. In this attack, a -bit secret key is correctly inferred in just minutes by only monitoring the application’s write access pattern via a compromised Direct Memory Access (DMA111DMA is a standard performance feature which grants full access of the main memory to certain peripheral buses, e.g. FireWire, Thunderbolt etc.(Blass and Robertson, 2012; Böck and Austria, 2009; Maartmann-Moe, 2011; Boileau, 2006; Panholzer, 2008) device on the system. The adversary collects the snapshots of the application’s memory via the compromised DMA. Clearly, any two memory snapshots only differ in the locations where the data has been modified in the latter snapshot. In other words, comparing the snapshots not only reveals the fact that write accesses (if any) have been made to the memory, but it also reveals the exact locations of the accesses which leads to a precise access pattern of memory writes resulting in privacy leakage.

Recent work (Stewin and Bystrov, 2012) demonstrated that DMA attacks can also be launched remotely by injecting malware to the dedicated hardware devices, such as graphic processors and network interface cards, attached to the host platform. This allows even a remote adversary to learn the application’s write access pattern. Intel’s TXT has also been a victim of DMA based attacks where a malicious OS directed a network card to access data in the protected VM (Wojtczuk and Rutkowska, 2009; Wojtczuk et al., 2009).

One approach to prevent such attacks, as adapted by TXT, could be to block certain DMA accesses through modifications in DRAM controller. However, this requires the DRAM controller to be included in the trusted computing base (TCB) of the system which is undesirable. Nevertheless, there could potentially be many scenarios other than DMA based attacks where write access patterns can be learned by the adversary.

Current so-called fully functional ORAM schemes, which obfuscate both read and write access patterns, also offer a solution to such weaker adversaries. However, the added protection (obfuscation of reads) offered by fully functional ORAMs is unnecessary and is practically an overkill in this scenario which results in significant performance penalty. Path ORAM (Stefanov et al., 2013), the most efficient and practical fully functional ORAM system for secure processors so far, still incurs about performance degradation (Fletcher et al., 2012; Ren et al., 2013) over an insecure DRAM system. A far more efficient solution to this problem is a write-only ORAM scheme, which only obfuscates the write accesses made to the memory. Since read accesses leave no trace in the memory snapshot and hence do not need to be obfuscated in this model, a write-only ORAM can offer significant performance advantage over a fully functional ORAM.

A recent work, HIVE (Blass et al., 2014), has proposed a write-only ORAM scheme for implementing hidden volumes in hard disk drives. The key idea is similar to Path ORAM, i.e., each data block is written to a new random location, along with some dummy blocks, every time it is accessed. However, a fundamental challenge that arises in this scheme is to avoid collisions. I.e., to determine whether a randomly chosen physical location contains real or dummy data, in order to avoid overwriting the existing useful data block. HIVE proposes a complex inverse position map approach for collision avoidance. Essentially, it maintains a forward position mapping (logical to physical blocks) and a backward/inverse position mapping (physical to logical blocks) for the whole memory. Before each write, both forward and backward mappings are looked up to determine whether the corresponding physical location is vacant or occupied. This approach, however, turns out to be a storage and performance bottleneck because of the size of inverse position map and dual lookups of the position mappings.

A simplistic and obvious solution to this long-standing problem, from a computer architect’s perspective, would be to use a bit-mask to mark each physical block as vacant or occupied. Based on this intuition, we propose a simplified write-only ORAM scheme called Flat ORAM222Flat ORAM replaces the binary tree structure of Path ORAM with a flat array of data blocks; hence termed as ‘Flat’ ORAM.. At the core of the algorithm, Flat ORAM introduces a new data structure called Occupancy Map (OccMap): a bit-mask which offers an efficient collision avoidance mechanism. The OccMap records the availability information (occupied/vacant) of every physical location in a highly compressed form (i.e., just -bit per cache line). For typical parameter settings, OccMap is about compact compared to HIVE’s inverse position map structure. This dense structure allows the OccMap blocks to exploit higher locality, resulting in considerable performance gain. While naively storing the OccMap breaks the ORAM’s security, we present how to securely store and manage this structure in a real system. In particular, the paper makes the following contributions:

  1. We are the first ones to implement an existing write-only ORAM scheme, HIVE, in the context of secure processors with all state-of-the-art ORAM optimizations, and analyze its performance bottlenecks.

  2. A simple write-only ORAM, named Flat ORAM, having an efficient collision avoidance approach is proposed. The micro-architecture of the scheme is discussed in detail and the design space is comprehensively explored. It has also been shown to seamlessly adopt various performance optimizations of its predecessor: Path ORAM.

  3. Our simulation results show that, on average, Flat ORAM offers performance gain (up to for DBMS) over HIVE, and only incurs slowdowns of and over the insecure DRAM for memory bound Splash2 and SPEC06 benchmarks respectively.

The rest of the paper is organized as follows: Section 2 describes our adversarial model in detail along with a practical example from the current literature. Section 3 provides the necessary background of fully functional ORAMs and write-only ORAMs. The proposed Flat ORAM scheme along with its security analysis is presented in Section 4, and the detailed construction of its occupancy map structure is shown in Section 5. A few additional optimizations from literature implemented in Flat ORAM are discussed in Section 6. Section 7 evaluates Flat ORAM’s performance, and we conclude the paper in Section 8.

2. Adversarial Model

We assume a relaxed form of the adversarial model considered in several prior works related to fully functional oblivious RAMs in secure processor settings (Ren et al., 2013; Yu et al., 2015; Fletcher et al., 2015).

In our model, a user’s computation job is outsourced to a cloud, where a trusted processor performs the computation on user’s private data. The user’s private data is stored (in encrypted form) in the untrusted memory external to the trusted processor, i.e. DRAM. In order to compute on user’s private data, the trusted processor interacts with DRAM. The cloud service itself is not considered as an adversary, i.e. it does not try to infer any information from the memory access patterns of the user’s program. However, since the cloud serves several users at the same time, sharing of critical resources such as DRAM among various applications from different users is inevitable. Among these users being served by the cloud service, we assume a malicious user who is able to monitor remotely (and potentially learn the secret information from) the data write sequences of other users’ applications to the DRAM, e.g., by taking frequent snapshots of the victim application’s memory via a compromised DMA. Moreover, he may also tamper with the DRAM contents or play replay attacks in order to manipulate other users’ applications and/or learn more about their secret data.

To protect the system from such an adversary, we add to the processor chip a Write-Only ORAM controller: an additional trusted hardware module. Now all the off-chip traffic goes to DRAM through the ORAM controller. In order to formally define the security properties satisfied by our ORAM controller, we adapt the write-only ORAM privacy definition from (Haider and van Dijk, 2017) as follows:

Definition 2.1 ().

(Write-Only ORAM Privacy) For every two logical access sequences and of infinite length, their corresponding (infinite length) probabilistic access sequences and are identically distributed in the following sense: For all positive integers , if we truncate and to their first accesses, then the truncations and are identically distributed.

In other words, memory snapshots only reveal to the adversary the timing of write accesses made to the memory (i.e. leakage over ORAM Timing Channel) instead of their precise access pattern, whereas no trace of any read accesses made to the memory is revealed to the adversary. An important aspect of Definition 2.1 to note is that it completely isolates the problem of leakage over ORAM Termination Channel from ORAM’s originally targeted problem (which is also targeted in this paper) i.e., preventing leakage over memory address channel. Notice that the original definition of ORAM (Goldreich and Ostrovsky, 1996) does not protect against timing attacks, i.e. it does not obfuscate when an access is made to the memory (ORAM Timing Channel) or how long it takes for the application to finish (ORAM Termination Channel). The write-only ORAM security definition followed by HIVE (Blass et al., 2014) also allows leakage over ORAM termination channel, as two memory access sequences generated by the ORAM for two same-length logical access sequences can have different lengths (Haider and van Dijk, 2017). Therefore, in order to define precise security guarantees offered by our ORAM, we follow Definition 2.1.

Periodic ORAMs (Fletcher et al., 2012) deterministically make ORAM accesses always at regular predefined (publicly known) intervals, thereby preventing leakage over ORAM timing channel and shifting it to the ORAM termination channel. We present a periodic variant of our write-only ORAM to protect leakage over ORAM timing channel. Following the prior works (Maas et al., 2013) (Fletcher et al., 2015), (a) we assume that the timing of individual DRAM accesses made during an ORAM access does not reveal any information; (b) we do not protect the leakage over ORAM termination channel (i.e. total number of ORAM or DRAM accesses). The problem of leakage over ORAM termination channel has been addressed in the existing literature (Fletcher et al., 2014) where only bits are leaked for a total of accesses. A similar approach can easily be applied to the current scheme.

In order to detect malicious tampering of the memory by the adversary, we follow the standard definition of data integrity and freshness (Fletcher et al., 2015):

Definition 2.2 ().

(Write-Only ORAM Integrity) From the processor’s perspective, the ORAM behaves like a valid memory with overwhelming probability, and detects any violation to data authenticity and/or freshness.

2.1. Practicality of the Adversarial Model

Inputs: ,     Output:

Start:

;
for  do
     if  then    ;  
     else   ;  
     end if
end for

return

Algorithm 1 Montgomery Ladder

Modular exponentiation algorithms, such as RSA algorithm, are widely used in public-key cryptography. In general, these algorithms perform computations of the form , where the attacker’s goal is to find the secret . Algorithm 1 shows the Montgomery Ladder scheme (Joye and Yen, 2002) which performs exponentiation () through simple square-and-multiply operations. For a given input and a secret key , the algorithm performs multiplication and squaring operations on two local variables and for each bit of starting from the most significant bit down to the least significant bit. This algorithm prevents leakage over power side-channel since, regardless of the value of bit , the same number of operations are performed in the same order, hence producing the same power footprint for and .

Notice, however, that the specific order in which and are updated in time depends upon the value of . E.g., for , is written first and then is updated; whereas for the updates are done in the reverse order. This sequence of write access to and reveals to the adversary the exact bit values of the secret key . A recent work (Merin John et al., 2017) demonstrated such an attack where frequent memory snapshots of victim application’s data (particularly and ) from the physical memory are taken via a compromised DMA. These snapshots are then correlated in time to determine the sequence of write access to , , which in turn reveals the secret key. The reported time taken by the attack is minutes.

One might argue that under write-back caches, the updates to application’s data will only be visible in DRAM once the data is evicted from the LLC. This will definitely introduce noise to the precise write-access sequence discussed earlier, hence making the attacker’s job difficult. However, he can still collect several ‘noisy’ sequences of memory snapshots and then run correlation analysis on them to find the secret key . Furthermore, if the adversary is also a user of the same computer system, he can flush the system caches frequently to reduce the noise in write-access sequence even further.

3. Background of Oblivious RAMs

A fully functional Oblivious RAM (Goldreich and Ostrovsky, 1996), or more commonly known as ORAM, is a primitive that obfuscates the user’s (i.e. Processor’s) access patterns to a storage (i.e. DRAM) such that by monitoring the memory access patterns, an adversary is not able to learn anything about the data being accessed. The ORAM interface transforms the user’s access sequence of program addresses into a sequence of ORAM accesses to random looking physical addresses. Since the physical locations being accessed are revealed to the adversary, the ORAM interface guarantees that the physical access pattern is independent of the logical access pattern hence user’s potentially data dependent access patterns are not revealed. Furthermore, the data stored in ORAMs should be encrypted using probabilistic encryption to conceal the data content as well as the fact whether or not the content has been updated.

3.1. Path ORAM

Path ORAM (Stefanov et al., 2013) is currently the most efficient and well studied ORAM implementation for secure processors. It has two main hardware components: the binary tree storage and the ORAM controller. Binary tree stores the data content of the ORAM and is implemented on DRAM. Each node in the tree can hold up to useful data blocks, and any empty slots are filled with dummy blocks. All blocks, real or dummy, are probabilistically encrypted and cannot be distinguished. The path from the root node to the leaf is defined as path . ORAM controller is a piece of trusted hardware that controls the tree structure. Besides necessary logic circuits, the ORAM controller contains two main structures, a position map and a stash. The position map is a lookup table that associates the program address of a data block with a path in the ORAM tree (path ). The stash is a buffer that stores up to a small number of data blocks at a time.

Each data block in Path ORAM is mapped (randomly) to some path via the position map, i.e. at any time, the data block must be stored either on path , or in the stash. Path ORAM follows the following steps when a request on block is issued by the processor: (1) The path (leaf) number of the logical address is looked up in the position map. (2) All the blocks on path are read and decrypted, and all real blocks added to the stash. (3) Block is returned to the processor. (4) The position map of is updated to a new random leaf . (5) As many blocks from stash as possible are encrypted and written on path , where empty spots are filled with dummy blocks. Step (4) guarantees that when block is accessed later, a random path will be accessed which is independent of any previously accessed paths (unlinkability). As a result, each ORAM access is random and unlinkable regardless of the request pattern.

Path ORAM incurs significant energy and performance penalties compared to insecure DRAM. Under typical settings for secure processors (gigabytes of memory and 64- to 128-byte blocks), Path ORAM has a 20-30 level binary tree where each node typically stores 3 or 4 data blocks (Stefanov et al., 2012; Ren et al., 2013). This means that each ORAM access reads and writes 60-120 blocks, in contrast to a single read or write operation in an insecure storage system.

3.2. Write-Only ORAMs

In contrast to fully functional ORAMs, a write-only ORAM only obfuscates the patterns of write accesses made to a storage. Write-only ORAM is preferred for performance reasons over fully functional ORAMs in situations where the adversary is not able to monitor the read access patterns.

There has been very limited research work done so far to explore write-only ORAMs, and to best of our knowledge, write-only ORAMs for secure processors have not been explored at all. Li and Datta (Li and Datta, 2013) present a write-only ORAM scheme to be used with Private Information Retrieval (PIR) in order to preserve the privacy of data outsourced to a data center. Although this scheme achieves an amortized write cost of , it incurs a read cost of for a storage of blocks each of size . For efficient reads, it requires the client side storage (i.e. the on-chip position map) to be polynomial in . In a secure processor setting, DRAM reads are usually the major performance bottleneck, and introducing a complexity polynomial in on this critical path is highly unwanted.

A recent work, HIVE (Blass et al., 2014), has proposed a write-only ORAM scheme for hidden volumes in hard disk drives. Although HIVE write-only ORAM presented-as-is (Blass et al., 2014) targets a totally different application, we believe that its parameter settings can be tweaked to be used in the secure processor setting. This paper is the first one to implement HIVE in the secure processor context, and we consider this implementation as the baseline write-only ORAM to be compared with our proposed Flat ORAM.

Roche et al. (Roche et al., 2017) have also proposed an efficient write-only ORAM scheme for hard disk storages. This scheme along with its complex optimizations has been implemented in software which is completely feasible at the DRAM-Disk boundary. However, in this work, we target the Processor-DRAM boundary for our proposed ORAM which needs to be implemented in hardware, and hence our focus is only towards simplified algorithms and optimizations which can easily be synthesized in hardware without substantial area overhead.

4. Flat ORAM Scheme

In this section, we first present the core algorithm of Flat ORAM, then we discuss its architectural details and various optimizations for a practical implementation.

4.1. Fundamental Data Structures

Position Map (PosMap):

It is a standard Path ORAM structure that maintains randomized mappings of logical blocks to physical locations. However there is one subtle difference between PosMap of Path ORAM and Flat ORAM. In Path ORAM, PosMap stores a path number for each logical block and the block can reside anywhere on that path. In contrast, PosMap in Flat ORAM stores the exact physical address where a logical block is stored.

Occupancy Map (OccMap):

OccMap is a newly introduced structure in Flat ORAM. It is essentially a large bit-mask where each bit corresponds to a physical location (i.e., a cache line). The binary value of each bit represents whether the corresponding physical block contains real or outdated/dummy data. OccMap is of crucial importance to avoid data collisions, and hence for the correctness of Flat ORAM. A collision happens when a physical location, which is randomly chosen to store a logical block, already contains useful data which cannot be overwritten. Managing the OccMap securely and efficiently is a major challenge which we address in section 5 in detail.

Stash:

Stash, also adapted from Path ORAM, is a small buffer in the trusted memory to temporarily hold data blocks evicted from the processor’s last level cache (LLC). A slight but crucial modification, however, is that Flat ORAM only buffers dirty333Blocks with modified data. data blocks in the stash; while clean blocks evicted from the LLC are simply ignored since a valid copy of these blocks already exists in the main memory. This modification is significantly beneficial for performance.

4.2. Basic Algorithm

1:procedure Initialize( )
2:      Empty Position Map.
3:      Empty Occupancy Map.
4:     for  do
5:         loop
6:               UniformRand()
7:              if  then If vacant
8:                   Mark Occupied.
9:                   Record position.
10:                  break
11:              end if
12:         end loop
13:     end for
14:end procedure
Algorithm 2 Flat ORAM Initialization.

Let be the total number of logical data blocks that we want to securely store in our ORAM, which is implemented on top of a DRAM; and let each data block be of size bytes. Let be the number of physical blocks that our DRAM can physically store, i.e. the DRAM capacity (where ).

Initial Setup: Algorithm 2 shows the setup phase of our scheme. Two null-initialized arrays PosMap and OccMap, corresponding to position and occupancy map of size and entries respectively, are allocated. For now, we assume that both PosMap and OccMap reside on-chip in the trusted memory to which the adversary has no access. However, since these arrays can be quite large and the trusted memory is quite constrained, we later on show how this problem is solved. Initially, since all physical blocks are empty, each OccMap entry is set to . Now, each logical block is mapped to a uniformly random physical block, i.e. PosMap is initialized, while avoiding any collisions using OccMap. The OccMap is updated along the way in order to mark those physical locations which have been assigned to a logical block as ‘occupied’. Notice that in order to minimize the probability of collision, should be sufficiently larger than , e.g. gives a collision probability.

1:procedure ORAMRead()
2:      Lookup position
3:     s
4:     return Position is also returned.
5:end procedure
1:procedure ORAMWrite()
2:      Add to Stash
3:     return
4:end procedure
1:procedure EvictStash
2:      Read from Stash
3:     loop
4:          UniformRand()
5:         if  then If vacant
6:               Mark as Occupied.
7:               Vacate old block.
8:               Record position.
9:              DRAMWrite()
10:              
11:              break
12:         else If occupied.
13:              
14:              DRAMWrite()
15:         end if
16:     end loop
17:end procedure
Algorithm 3 Basic Flat ORAM considering all PosMap and OccMap is on-chip. Following procedures show reading, writing and eviction of a logical block from the ORAM.

Reads: The procedures to read/write a data block corresponding to the virtual address from/to the ORAM are shown in Algorithm 3. A read operation is straightforward as it does not need to be obfuscated. The PosMap entry for the logical block is looked up, and the encrypted data is read through normal DRAM read. The data is decrypted and returned to the LLC along with its current physical position . The location is stored in the tag array of the LLC, and proves to be useful upon eviction of the data from the LLC.

Writes: Since write operations should be non-blocking in a secure processor setting, the ORAM writes are performed in two steps. Whenever a data block is evicted from the LLC, it is first simply added to the stash queue, without incurring any latency. While the processor moves on to computing on other data in its registers/caches, the ORAM controller then works in the background to evict the block from stash to the DRAM. A block to be written is picked from the stash, and a new uniformly random physical position is chosen for this block. The OccMap is looked up to determine whether the location is vacant. If so, the write operation proceeds by simply recording the new position for block in PosMap, updating the OccMap entries for and accordingly, and finally writing encrypted data at location . Otherwise if the location is already occupied by some useful data block, the probability of which is , the existing data block is read, decrypted, re-encrypted444We assume that the encryption/decryption algorithms / implement probabilistic encryption, e.g. AES counter mode, as done in prior works (Ren et al., 2013; Fletcher et al., 2015). under probabilistic encryption and written back. A new random position is then chosen for the block and the above mentioned process is repeated until a vacant location is found to evict the block. Notice that storing along with the data upon reads will save extra ORAM accesses to lookup from the recursive PosMap (cf. Section 4.5).

4.3. Avoiding Redundant Memory Accesses

The fact that the adversary cannot see read accesses allows Flat ORAM to avoid almost all the redundancy incurred by a fully functional ORAM (e.g. Path ORAM). Instead of reading/writing a whole path for each read/write access as done in Path ORAM, Flat ORAM simply reads/writes only the desired block directly given its physical location from the PosMap. This is fundamentally where the write-only ORAMs (i.e. HIVE (Blass et al., 2014), Flat ORAM) get the performance edge over the fully functional ORAMs. However, the question arises whether Flat ORAM is still secure after eliminating the redundant accesses.

4.4. Security

Privacy: Consider any two logical write-access sequences and of the same length. In EvictStash procedure (cf. Algorithm 3), a physical block chosen uniformly at random out of blocks is always modified regardless of it being vacant or occupied. Therefore, the write accesses generated by Flat ORAM while executing either of the two logical access sequences and will update memory locations uniformly at random throughout the whole physical memory space. As a result, an adversary monitoring these updates cannot distinguish between real vs. dummy blocks, and in turn the two sequences and seem computationally indistinguishable.

Furthermore, notice that in Path ORAM the purpose of accessing a whole path instead of just one block upon each read and write access is to prevent linkability between a write and a following read access to the same logical block. In Flat ORAM’s model, however, since the adversary cannot see the read accesses at all, therefore the linkability problem would never arise as long as each logical data block is written to a new random location every time it is evicted (which is guaranteed by Flat ORAM algorithm). Although HIVE proposes a constant -factor redundancy upon each data write, we argue that it is unnecessary for the desired security as explained above, and can be avoided to gain performance.

Hence, the basic algorithm of Flat ORAM presented above guarantees the desired privacy property of our write-only ORAM (cf. Definition 2.1).

Integrity: Next, we move on to making the basic Flat ORAM practical for a real system. The main challenge is to get rid of the huge on-chip memory requirements imposed by PosMap and OccMap. While addressing the PosMap management problem, we discuss an existing efficient memory integrity verification technique from Path ORAM domain called  (Fletcher et al., 2015) (cf. Section 6.2) which satisfies our integrity definition (cf. Definition 2.2).

Stash Management: Another critical missing piece is to prevent the unlikely event of stash overflow for a small constant sized stash, as such an event could break the privacy guarantees offered by Flat ORAM. We completely eliminate the possibility of a stash overflow event by using a proven technique called Background Eviction (Ren et al., 2013). We present a detailed discussion about the stash size under Background Eviction technique in Section 5.4.

4.5. Recursive Position Map & PLB

In order to squeeze the on-chip PosMap size, a standard recursive construction of position map (Shi et al., 2011) is used. In a 2-level recursive position map, for instance, the original PosMap structure is stored in another set of data blocks which we call a hierarchy of position map, and the PosMap of the first hierarchy is stored in the trusted memory on-chip (Figure 1). The above trick can be repeated, i.e., adding more hierarchies of position map to further reduce the final position map size at the expense of increased latency. Notice that all the position map hierarchies (except for the final position map) are stored in the untrusted DRAM along with the actual data blocks, and can be treated as regular data blocks; this technique is called Unified ORAM (Fletcher et al., 2015).

Unified ORAM scheme reduces the performance penalty of recursion by caching position map ORAM blocks in a Position map Lookaside Buffer (PLB) to exploit locality (similar to the TLB exploiting locality in page tables). To hide whether a position map access hits or misses in the cache, Unified ORAM stores both data and position map blocks in the same binary tree. Further compression of PosMap structure is done by using Compressed Position Map technique discussed in section 6.1.

4.6. Background Eviction

Stash (cf. Section 4.1) is a small buffer to temporarily hold the dirty data blocks evicted from the LLC/PLB. If at any time, the rate of blocks being added to the stash becomes higher than the rate of evictions from the stash, the blocks may accumulate in stash causing a stash overflow. Background eviction (Ren et al., 2013) is a proven and secure technique proposed for Path ORAM to prevent stash overflow. The key idea of background evictions is to temporarily stop serving the real requests (which increase stash occupancy) and issue background evictions or so-called dummy accesses (which decrease stash occupancy) when the stash is full.

We use background eviction technique to eliminate the possibility of a stash overflow event. When the stash is full, the ORAM controller suspends the read requests which consequently stops any write-back requests preventing the stash occupancy to increase further. Then it simply chooses random locations and, if vacant, evicts the blocks from the stash until the stash occupancy is reduced to a safe threshold. The probability of a successful eviction in each attempt is determined by the DRAM utilization parameter, i.e. the ratio of occupied blocks to the total blocks in DRAM. In our experiments, we choose a utilization of , therefore each eviction attempt has probability of success. Note that background evictions essentially push the problem of stash overflow to the program’s termination channel. Configuring the DRAM utilization to be less than guarantees the termination, and we demonstrate good performance for a utilization of in Section 7. Although it is true that background eviction may have different effect on the total runtime for different applications, or even for different inputs for the same application which leak the information about data locality etc. However, the same argument applies to Path ORAM based systems, and also for other system components as well, such as enabling vs. disabling branch prediction or the L3 cache etc. Protecting any leakage through the program’s termination time is out of scope of this paper (cf. Section 2).

4.7. Periodic ORAM

As mentioned in our adversarial model, the core definition of ORAM (Goldreich and Ostrovsky, 1996) do not leakage over ORAM timing or termination channel (cf. Section 2). Likewise, the fundamental algorithm of Flat ORAM (Algorithm 3) does not target to prevent these leakages. Therefore in order to protect the ORAM timing channel, we adapt the Flat ORAM algorithm to issue periodic ORAM accesses, while maintaining its security guarantees.

In the literature, periodic variants of Path ORAM have been presented (Fletcher et al., 2012) which simply always issue ORAM requests at regular periodic intervals. However, under write-only ORAMs, such a straightforward periodic approach would break the security as explained below. Since in write-only ORAMs, the read requests do not leave a trace, therefore for a logical access sequence of (Write, Read, Write), the adversary will only see two writes occurring at times and for being the interval between two ORAM accesses. The access at time will be omitted which reveals to the adversary that a read request was made at this time.

To fix this problem, we modify the Flat ORAM algorithm as follows. Among the periodic access, for every real read request to physical block , another randomly chosen physical block is also read. Block is consumed by the processor, whereas block is re-encrypted (under probabilistic encryption) and written back to the same location from where it was read. This would always result in update(s) to the memory after each and every time period .

Security: A few things should be noted: First, it does not matter whether the location contains real or dummy data, because the plain-text data content is never modified but just re-encrypted. Second, writing back is indistinguishable from a real write request as this location is chosen uniformly at random. Third, this write to does not reveal any trace of the actual read of as the two locations are totally independent.

We present our simulation results for periodic Flat ORAM in the evaluation section.

5. Efficient Collision Avoidance

In sections 4.3 and section 4.4, we discuss how Flat ORAM outperforms Path ORAM by avoiding redundant memory accesses. However, an immediate consequence of this is the problem of collisions which now becomes the main performance bottleneck. A collision refers to a scenario when a physical location , which is randomly chosen to write a logical block , already contains useful data which cannot be overwritten. The overall efficiency of such a write-only ORAM scheme boils down to its collision avoidance mechanism. In the following subsections, we discuss the occupancy map based collision avoidance mechanism of Flat ORAM in detail and compare it with HIVE’s inverse position map based collision avoidance scheme.

5.1. Inverse Position Map Approach

Since a read access must not leave its trace in the memory in order to avoid the linkability problem, a naive approach of marking the physical location as ‘vacant’ by writing ‘dummy’ data to it upon each read is not possible. HIVE (Blass et al., 2014) proposes an inverse position map structure that maps each physical location to a logical address. Before each write operation to a physical location , a potential collision check is performed which involves two steps. First the logical address linked to is looked up via the inverse position map. Then the regular position map is looked up to find out the most recent physical location linked to the logical address . If then since the two mappings are synchronized, it shows that contains useful data, hence a collision has occurred. Otherwise, if then this means that the entry for in the inverse position map is outdated, and block has now moved to a new location . Therefore, the current location can be overwritten, hence no collision.

HIVE stores the encrypted inverse position map structure in the untrusted storage at a fixed location. With each physical block being updated, the corresponding inverse position map entry is also updated. Since write-only ORAMs do not hide the physical block ID of the updated block, therefore revealing the position of the corresponding inverse position map entry does not leak any secret information.

We demonstrate in our evaluations that the large size of inverse position map approach introduces storage as well as performance overheads. For a system with a block size of bytes and total logical blocks, inverse position map requires additional bits space for each of the physical blocks. Crucially, this large size of a single inverse position map entry restricts the total number of entries per block to a small constant, which leads to less locality within a block. This results in performance degradation.

5.2. Occupancy Map Approach

In the simplified OccMap based approach, each of the physical blocks requires just one additional bit to store the occupancy information (vacant/occupied). In terms of storage, this gives times improvement over HIVE.

5.2.1. Insecurely Managing the Occupancy Map

The OccMap array bits are first sliced into chunks equal to the ORAM block size ( bytes). We call these chunks the OccMap Blocks. Notice that each OccMap block contains occupancy information of physical locations (i.e. 8 bits per byte; 1-bit per location). Now the challenge is to efficiently store these blocks somewhere off-chip. A naive approach would be to encrypt OccMap blocks under probabilistic encryption, and store them contiguously in a dedicated fixed area in DRAM. However under Flat ORAM algorithm, this approach would lead to a serious security flaw which is explained below.

If the OccMap blocks are stored contiguously at a fixed location in DRAM, an adversary can easily identify the corresponding OccMap block for a given a physical address; and for a given OccMap block, he can identify the contiguous range of corresponding physical locations. With that in mind, when a data block (previously read from ) is evicted from the stash and written to location (cf. Algorithm 3), the old OccMap entry is marked as ‘vacant’ and the new OccMap entry is marked as ‘occupied’; i.e. two OccMap blocks and are updated. Furthermore, the location, which falls in the contiguous range covered by one of the two updated OccMap blocks, is also updated with the actual data – thereby revealing the identity of . This reveals to the adversary that a logical data block was previously read from some location within the small contiguous range covered by , and it is now written to location (i.e. coarse grained linkability). Recording several such instances of read-write access pairs and linking them together in a chain reveals the precise pattern of movement of logical block across the whole memory.

5.2.2. Securely Managing the Occupancy Map

To avoid this problem, we treat the OccMap blocks as regular data blocks, i.e., OccMap blocks are encrypted and also randomly distributed throughout the whole DRAM, and tracked by the regular PosMap. Figure 1 shows the logical organization of data, PosMap and OccMap blocks. The OccMap blocks are added as ‘additional’ data blocks at the data hierarchy (Hierarchy 0). Then the recursive position map hierarchies are constructed on top of the complete data set (data blocks and OccMap blocks). Every time an OccMap block is updated, it is mapped to a new random location and hence avoids the linkability problem. We realize that this approach results in overall more position map blocks, however for practical parameters settings (e.g. block size, DRAM, working set), it does not result in an additional PosMap hierarchy. Therefore the recursive position map lookup latency is unaffected.

Figure 1. Logical view of OccMap organization.

5.3. Performance Related Optimizations

Now that we have discussed how to securely store the occupancy map, we move on to discuss some performance related optimizations implemented in Flat ORAM.

5.3.1. Locality in OccMap Blocks

For realistic parameters, e.g. bytes block size, each OccMap block contains occupancy information of physical locations. This factor is termed as OccMap scaling factor. The dense structure of OccMap blocks offers an opportunity to exploit spatial locality within a block. In other words, for a large scaling factor it is more likely that two randomly chosen physical locations will be covered by the same OccMap block, as compared to a small scaling factor. In order to also benefit from such locality, we cache the OccMap blocks as well in PLB along with the PosMap blocks. For a fair comparison with HIVE in our experiments, we also model the caching of HIVE’s inverse position map blocks in PLB. Our experiments confirm that the OccMap blocks show a higher PLB hit rate as compared to HIVE’s inverse position map blocks cached in PLB in the same manner. The reason is that, for the same parameters, the scaling factor of inverse position map approach is just about which results in a larger size of the data structure and hence more capacity-misses from the PLB.

5.3.2. Dirty vs. Clean Evictions from LLC & PLB

An eviction of a block from the LLC where the data content of the block has not been modified is called a clean eviction, whereas an eviction where the data has been modified is called dirty eviction. In Path ORAM, since all the read operations also need to be obfuscated, therefore following a read operation, when a block gets evicted from the LLC, it must be re-written to a new random location even if its data is unmodified, i.e. a clean eviction. This is crucial for Path ORAM’s security as it guarantees that successive reads to the same logical block result in random paths being accessed. This notion is termed as read-erase, which assumes that the data will be erased from the memory once it is read.

In write-only ORAMs, however, since the read access patterns are not revealed therefore the notion of read-erase is not necessary. A data block can be read from the same location as often as needed as long as it’s contents are not modified. We implement this relaxed model in Flat ORAM which greatly improves performance. Essentially, upon a clean eviction from the LLC, the block can simply be discarded since one useful copy of the data is still stored in the DRAM. Same reasoning applies to the clean evictions from the PLB. Only the dirty evictions are added to the stash to be written back at a random location in the memory.

5.4. Implications on PLB & Stash Size

Each dirty eviction requires not only the corresponding data block to be updated but also the two related OccMAP blocks which store the new and old occupancy information. In order to relocate these blocks to new random positions, the ‘’ hierarchies of corresponding PosMAP blocks will need to be updated and this in turn implies updating their related OccMAP blocks, and so on. If not prevented, this avalanche effect will repeatedly fill the stash implying background evictions which stop serving real requests and increase the termination time. For a large enough PLB with respect to a benchmark’s locality, most of the required OccMAP blocks during the benchmark’s execution will be in the PLB. This prevents the avalanche effect most of the time (as our evaluation shows) since the OccMAP blocks in PLB can be directly updated.

Even if all necessary OccMAP blocks are in PLB, a dirty eviction still requires the data block with its PosMAP blocks to be updated. Each of these blocks is successfully evicted from the stash with probability , determined by the DRAM utilization, on each attempt. The probability that exactly attempts are needed to evict all blocks is equal to . This probability becomes very small for equal to a small constant times . If the dirty eviction rate (per DRAM access) is at most , then the stash size will mostly be contained to a small size (e.g., blocks for ) so that additional background eviction which stops serving real requests is not needed.

Notice that the presented write-only ORAM is not asymptotically efficient: In order to show at most a constant factor increase in termination time with overwhelming probability, a proper argument needs to show a small probability of requiring background eviction which halts normal execution. An argument based on M/D/1 queuing theory or 1-D random walks needs the OccMap to be always within the PLB and this means that the effective stash size as compared to Path ORAM’s stash definition includes this PLB which scales linearly with and is not .

6. Adopting More Existing Tricks

Here we discuss a few more architectural optimizations from the Path ORAM paradigm which can be flawlessly incorporated and are implemented in Flat ORAM for further improvements and features.

6.1. Compressed Position Map

The recursive position map for a total of logical data blocks creates hierarchies of position map. Here represents the number of positions stored in one PosMap block, and is called PosMap scale factor. A higher value of PosMap scale factor would result in less number of PosMap hierarchies and hence yield better performance.

To achieve this goal, Compressed Position Map (Fletcher et al., 2015) has been proposed, which results in less PosMap hierarchies than uncompressed PosMap. The basic idea is to store a monotonically increasing counter in the PosMap entry for each logical data block. This counter along with the block’s logical address is used as a ‘seed’ to a keyed pseudo-random function in order to compute a random position for the block. Every time a block is to be written, its PosMap counter is first incremented so that a new random position is generated by the pseudo-random function for the block. To compress these counters to a feasible size, (Fletcher et al., 2015) presents an optimization using a big group counter and several small individual counters per PosMap block. We refer the readers who might be interested in more details to the above citation.

We tweak the compressed PosMap technique for Flat ORAM. The key modification is that the counter for any block to be evicted is incremented even upon unsuccessful eviction attempts, i.e. even if a collision is detected. It is important because otherwise the pseudo-random function will generate the same random location over and over which is already occupied, and hence the block will never be evicted.

6.2. Integrity Verification (PMMAC)

Flat ORAM also implements an efficient memory integrity verification technique termed as PosMap MAC (PMMAC) (Fletcher et al., 2015). PMMAC leverages the per-block counters of compressed PosMap to perform MAC555Message Authentication Code (MAC), e.g. a keyed cryptographic hash, is a small piece of information to verify the authenticity of a message/data. checks on the data upon reads. Suppose a logical block has a counter , then upon writes, the ORAM controller computes a MAC using the secret key and writes the tuple to the DRAM. Upon reads, the potentially tampered data tuple is read. The ORAM controller recomputes and checks whether . If so, the data integrity is verified. Also, since the counter is incremented upon every write, the freshness of the data is also verified, i.e. integrity check guarantees that the most recently written data has been read.

7. Experimental Evaluation

7.1. Methodology

Secure Processor Configuration
Core model 1 GHz, in order core
Total Cores 4
L1 I/D Cache 32 KB, 4-way
Shared L2 cache 512 KB per tile, 8-way
Cacheline (block) size 128bytes
DRAM bandwidth 16 GB/s
Conventional DRAM latency 100 cycles
Default ORAM Configuration
ORAM Capacity 8 GB
Working Set Size 4 GB
Number of ORAM hierarchies 4
ORAM Block size 128 Bytes
PLB Size 32kB
Stash Size 100 Blocks
Compressed PosMap & Integrity Enabled

Table 1. System Configuration.

We use Graphite (Miller et al., 2010) to model different ORAM schemes in all our experiments. Graphite simulates a tiled multi-core chip. The hardware configurations are listed in Table 1. We assume there is only one memory controller on the chip, and all ORAM accesses are serialized. The DRAM in Graphite is simply modeled by a flat latency. The 16 GB/s is calculated assuming a 1 GHz chip with 128 pins and pins are the bottleneck of the data transfer.

We use Splash-2 (Woo et al., 1995), SPEC06 (Henning, 2006) and two OLTP database management system (DBMS) (Yu et al., 2014) workloads namely YCSB (Cooper, Silberstein, Tam, Ramakrishnan, and Sears, Cooper et al.) and TPCC (The Transaction Processing Council, 2007) to evaluate our Flat ORAM scheme (flat_oram) against various baselines. Three baseline designs are used for comparison: the insecure baseline using normal DRAM (dram), the state of the art Path ORAM with dynamic prefetching (Yu et al., 2015) (path_oram) and an adaptation of the write-only ORAM scheme from HIVE (hive) in the context of secure processor architectures with several additional optimizations. For all ORAM schemes, we enable the PLB, the compressed position map and integrity verification. The default parameters for ORAM schemes are shown in Table 1. Unless otherwise stated, all the experiments use these ORAM parameters.

7.2. Performance Comparison

(a) Splash2
(b) SPEC06
(c) DBMS
Figure 5. Normalized Completion Time and Memory Accesses with respect to Insecure DRAM.
(a) Splash2
(b) SPEC06
Figure 8. Overall PLB Hit Rate (PosMap blocks and OccMap blocks).

Although all ORAM schemes incur performance slowdown over DRAM, however it is important to note that this slowdown is proportional to the memory intensiveness of the application. Memory bound applications suffer from higher performance degradation than compute bound applications. Figure (a)a, Figure (b)b and Figure (c)c show normalized completion times (shown by solid bars) of Splash2, SPEC06 and DBMS benchmarks with respect to DRAM. Splash2 and SPEC06 benchmarks are sorted in ascending order of slowdowns over DRAM from left to right. We consider all the benchmarks with less than 2 overhead as Computation Intensive benchmarks (plotted over green background) and all those with more than 2 overhead as Memory Intensive benchmarks (plotted over red background).

Clearly, Path ORAM incurs the highest overhead, as expected, among all three ORAM schemes because it is a fully functional ORAM which provides higher security. However, the point of presenting this comparison is to convince the readers that using Path ORAM for only write-access protection is indeed an overkill when better alternatives (e.g. HIVE, Flat ORAM) exist. On average, Path ORAM incurs about slowdown for Splash2 and for SPEC06 memory intensive benchmarks (mem_avg). TPCC and YCSB incur and slowdowns respectively.

HIVE also shows significant performance degradation compared to Flat ORAM for memory intensive benchmarks (ocean_contiguous, ocean_non_contiguous, mcf, tpcc, ycsb). The average slowdown of HIVE adaptation for memory bound Splash2 and SPEC06 workloads even after several additional optimizations is and respectively. Whereas Flat ORAM outperforms HIVE by up to performance gain on average, having respective average slowdowns of and . For DBMS, the performance gain of Flat ORAM over HIVE approach up to .

This performance gap is primarily because the inverse position map approach of HIVE results in significantly increased number of additional DRAM accesses. Figure 5 also shows normalized total number of DRAM accesses w.r.t. insecure DRAM system (shown by red markers) for HIVE and Flat ORAM. These numbers include both the DRAM accesses issued to serve regular ORAM requests and also the ones caused by background evictions (cf. Section 4.6). The normalized access count for Path ORAM is around on average, and is not shown on the plots. It can be seen that HIVE issues and DRAM accesses as opposed to Flat ORAM’s and accesses on average for each request issued by the processor for memory intensive Splash2 and SPEC06 workloads respectively.

The reason for higher number of DRAM accesses from HIVE can be found in Figure 8 which shows the overall PLB hit rate of both HIVE and Flat ORAM. The large memory footprint of the HIVE’s inverse position map structure results in overall more data being inserted into the PLB and hence translates into higher number of evictions from PLB. Consequently the ORAM controller experiences higher number of PLB misses and issues relatively higher number of DRAM accesses. Whereas the dense structure of OccMap offers a smaller memory footprint, thus causing less PLB evictions and exhibiting better locality (cf. Section 5.3) which directly translates into performance gain.

The normalized number of DRAM accesses is proportional to the energy consumption of the memory subsystem. I.e., a higher number of DRAM accesses would result in more energy consumption. On average, Flat ORAM saves up to energy over HIVE for various workloads.

7.3. Sensitivity Study

In this section, we will study how different parameters in the system affect the performance of write-only ORAMs.

DRAM Utilization:
(a) ycsb
(b) sjeng
Figure 11. Sweep Physical DRAM Capacity.

When a block needs to be written to the DRAM, a random position is chosen and if that location is vacant, the block is written at that location (cf. Section 4.2). The probability that a randomly chosen location is ‘vacant’ is determined by the DRAM utilization, i.e. the ratio of occupied blocks to total blocks in DRAM. In order to study the effect of DRAM utilization, we show the results of various physical DRAM sizes (, , ) for a constant working set of in Figure 11. The resulting DRAM utilizations are , and respectively.

Going from to utilization, memory intensive benchmarks (ycsb) gain performance, as the collisions during write operations are reduced by half. However, the jump from to utilization yields little gain because the collision probability of at mark is already too low to be a major performance bottleneck. Notice that HIVE benefits more compared to Flat ORAM from the reduced collisions since it has a much higher collision-penalty. Since less memory intensive benchmarks (sjeng) are not constrained by write operations anyway, lower utilizations do not help much.

Stash Size:
(a) ocean_non_contiguous
(b) sjeng
Figure 14. Sweep Stash Size.

As discussed in Section 4.6, when the stash occupancy increases than a particular threshold, the ORAM starts performing ‘background evictions’. Since background evictions cause the real requests to be suspended temporarily, frequent background evictions cause performance degradation. A larger stash is less likely to become full and thus reduces background eviction rate and improves performance.

In Figure 14, the stash size is swept for two different benchmarks, one is highly memory intensive (ocean_non_contiguous) and the other one is significantly less memory bound (sjeng). The memory intensive benchmark benefits from a large stash, as it experiences high background evictions rate at lower stash sizes. The less memory intensive benchmark does not benefit much from increased stash sizes, as it already has a low background evictions rate. In general, Flat ORAM shows significant performance gain over HIVE even at small stash sizes.

DRAM Latency & Bandwidth:
(a) ocean_contiguous
(b) sjeng
Figure 17. Sweep DRAM latency.
(a) ocean_contiguous
(b) sjeng
Figure 20. Sweep DRAM bandwidth.

In Path ORAM, each ORAM access results in about DRAM accesses on average under typical parameter settings. Most of these accesses can be issued in a burst without waiting for the first data block to arrive, since the addresses are known a priori, e.g. accessing a full path. Therefore, the DRAM bandwidth becomes the main bottleneck in Path ORAM, whereas the DRAM latency plays less significant role as it is incurred less often.

However, the write-only ORAMs under consideration typically only issue less than DRAM accesses per ORAM access (cf. Section 7.2). Furthermore, there could be interdependencies within these accesses, e.g., reading an OccMap block to find out if a position is vacant, and then issuing further writes in case a vacant position is found. In such cases, DRAM latency is incurred more often and hence plays more prominent role in the overall performance than the DRAM bandwidth.

This phenomenon is shown in DRAM latency and bandwidth sweep studies in Figure 17 and Figure 20 respectively. Memory intensive benchmarks (ocean_contiguous) are more sensitive to DRAM latency and experience more performance degradation at higher latencies. On the other hand, compute bound benchmarks (sjeng) are less sensitive to the DRAM latency. Increasing the DRAM bandwidth seems to help only a little as expected and explained in the discussion above.

Periodic ORAM:
(a) Splash2
(b) SPEC06
Figure 23. Periodic ORAM accesses. Normalized w.r.t. Insecure DRAM. ORAM Period = 100 cycles.

Figure 23 shows the experimental results of periodic write-only ORAM schemes. The results are normalized to insecure DRAM. The period in terms of number of cycles between two consecutive ORAM accesses is chosen to be 100 cycles. In general, adding periodicity to our ORAM scheme does not significantly hurt performance.

8. Conclusion

We propose an efficient and practical write-only Oblivious RAM scheme called Flat ORAM for secure processor architectures. It is the first write-only ORAM with a concrete implementation in secure processors domain. The implementation details are discussed and the design space is comprehensively explored. On memory intensive Splash-2 and SPEC06 benchmarks, Flat ORAM only incurs on average and slowdown respectively. Compared to a closest related work in the literature, Flat ORAM offers up to higher performance and energy savings.

Acknowledgements.
The work is partially supported by NSF grant CNS-1413996 for MACS: A Modular Approach to Cloud Security.

References

  • (1)
  • Arbaugh et al. (1997) W. Arbaugh, D. Farber, and J. Smith. 1997. A Secure and Reliable Bootstrap Architecture. In Proceedings of the 1997 IEEE Symposium on Security and Privacy. 65–71. citeseer.nj.nec.com/arbaugh97secure.html
  • Blass et al. (2014) Erik-Oliver Blass, Travis Mayberry, Guevara Noubir, and Kaan Onarlioglu. 2014. Toward robust hidden volumes using write-only oblivious RAM. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security. ACM, 203–214.
  • Blass and Robertson (2012) Erik-Oliver Blass and William Robertson. 2012. TRESOR-HUNT: attacking CPU-bound encryption. In Proceedings of the 28th Annual Computer Security Applications Conference. ACM, 71–78.
  • Böck and Austria (2009) Benjamin Böck and Secure Business Austria. 2009. Firewire-based physical security attacks on Windows 7, EFS and BitLocker. Secure Business Austria Research Lab (2009).
  • Boileau (2006) Adam Boileau. 2006. Hit by a bus: Physical access attacks with Firewire. Presentation, Ruxcon 3 (2006).
  • Boneh et al. (2011) Dan Boneh, David Mazieres, and Raluca Ada Popa. 2011. Remote Oblivious Storage: Making Oblivious RAM practical. Manuscript, http://dspace.mit.edu/bitstream/handle/1721.1/62006/MIT-CSAIL-TR-2011-018.pdf. (2011).
  • Cooper, Silberstein, Tam, Ramakrishnan, and Sears (Cooper et al.) Brian F. Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan, and Russell Sears. Benchmarking cloud serving systems with YCSB. In SoCC’10. 143–154.
  • Damgård et al. (2011) Ivan Damgård, Sigurd Meldgaard, and Jesper Buus Nielsen. 2011. Perfectly Secure Oblivious RAM without Random Oracles. In TCC.
  • Fletcher et al. (2015) Christopher Fletcher, Ling Ren, Albert Kwon, Marten van Dijk, and Srinivas Devadas. 2015. Freecursive ORAM: [Nearly] Free Recursion and Integrity Verification for Position-based Oblivious RAM. In Proceedings of the Int’l Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS).
  • Fletcher et al. (2014) Christopher Fletcher, Ling Ren, Xiangyao Yu, Marten Van Dijk, Omer Khan, and Srinivas Devadas. 2014. Suppressing the Oblivious RAM Timing Channel While Making Information Leakage and Program Efficiency Trade-offs. In Proceedings of the Int’l Symposium On High Performance Computer Architecture.
  • Fletcher et al. (2012) Christopher Fletcher, Marten van Dijk, and Srinivas Devadas. 2012. Secure Processor Architecture for Encrypted Computation on Untrusted Programs. In Proceedings of the 7th ACM CCS Workshop on Scalable Trusted Computing; an extended version is located at http://csg.csail.mit.edu/pubs/memos/Memo508/memo508.pdf (Master’s thesis). 3–8.
  • Goldreich and Ostrovsky (1996) O. Goldreich and R. Ostrovsky. 1996. Software protection and simulation on oblivious RAMs. In J. ACM.
  • Goodrich et al. (2011) Michael T. Goodrich, Michael Mitzenmacher, Olga Ohrimenko, and Roberto Tamassia. 2011. Oblivious RAM simulation with efficient worst-case access overhead. In Proceedings of the 3rd ACM workshop on Cloud computing security workshop (CCSW ’11). ACM, New York, NY, USA, 95–100. https://doi.org/10.1145/2046660.2046680
  • Goodrich et al. (2012a) Michael T. Goodrich, Michael Mitzenmacher, Olga Ohrimenko, and Roberto Tamassia. 2012a. Practical oblivious storage. In Proceedings of the second ACM conference on Data and Application Security and Privacy (CODASPY ’12). ACM, New York, NY, USA, 13–24. https://doi.org/10.1145/2133601.2133604
  • Goodrich et al. (2012b) Michael T. Goodrich, Michael Mitzenmacher, Olga Ohrimenko, and Roberto Tamassia. 2012b. Privacy-preserving group data access via stateless oblivious RAM simulation. In SODA.
  • Grawrock (2006) David Grawrock. 2006. The Intel Safer Computing Initiative: Building Blocks for Trusted Computing. Intel Press.
  • Haider and van Dijk (2017) Syed Kamran Haider and Marten van Dijk. 2017. Revisiting Definitional Foundations of Oblivious RAM for Secure Processor Implementations. arXiv preprint arXiv:1706.03852 (2017).
  • Henning (2006) John L Henning. 2006. SPEC CPU2006 benchmark descriptions. ACM SIGARCH Computer Architecture News 34, 4 (2006), 1–17.
  • Joye and Yen (2002) Marc Joye and Sung-Ming Yen. 2002. The Montgomery powering ladder. In International Workshop on Cryptographic Hardware and Embedded Systems. Springer, 291–302.
  • Li and Datta (2013) Lichun Li and Anwitaman Datta. 2013. Write-only oblivious RAM-based privacy-preserved access of outsourced data. International Journal of Information Security (2013), 1–20.
  • Lie et al. (2003a) D. Lie, J. Mitchell, C. Thekkath, and M. Horwitz. 2003a. Specifying and Verifying Hardware for Tamper-Resistant Software. In Proceedings of the IEEE Symposium on Security and Privacy.
  • Lie et al. (2003b) D. Lie, C. Thekkath, and M. Horowitz. 2003b. Implementing an Untrusted Operating System on Trusted Hardware. In Proceedings of the Nineteenth ACM Symposium on Operating Systems Principles. 178–192.
  • Lie et al. (2000) David Lie, Chandramohan Thekkath, Mark Mitchell, Patrick Lincoln, Dan Boneh, John Mitchell, and Mark Horowitz. 2000. Architectural Support for Copy and Tamper Resistant Software. In Proceedings of the Int’l Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-IX). 168–177.
  • Maartmann-Moe (2011) Carsten Maartmann-Moe. 2011. Inception. Break & Enter: http://www. breaknenter. org/projects/inception/[accessed 25 February 2014] (2011).
  • Maas et al. (2013) Martin Maas, Eric Love, Emil Stefanov, Mohit Tiwari, Elaine Shi, Krste Asanovic, John Kubiatowicz, and Dawn Song. 2013. Phantom: Practical oblivious computation in a secure processor. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 311–324.
  • McKeen et al. (2013) Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V Rozas, Hisham Shafi, Vedvyas Shanbhogue, and Uday R Savagaonkar. 2013. Innovative instructions and software model for isolated execution.. In HASP@ ISCA. 10.
  • Merin John et al. (2017) T. Merin John, S. Kamran Haider, H. Omar, and M. van Dijk. 2017. Connecting the Dots: Privacy Leakage via Write-Access Patterns to the Main Memory. To appear at International Symposium on Hardware Oriented Security and Trust (HOST). Available at ArXiv e-prints: https://arxiv.org/abs/1702.03965 (2017). arXiv:cs.CR/1702.03965
  • Miller et al. (2010) Jason E. Miller, Harshad Kasture, George Kurian, Charles Gruenwald III, Nathan Beckmann, Christopher Celio, Jonathan Eastep, and Anant Agarwal. 2010. Graphite: A Distributed Parallel Simulator for Multicores. In HPCA.
  • Ostrovsky (1990) R. Ostrovsky. 1990. Efficient computation on oblivious RAMs. In STOC.
  • Ostrovsky and Shoup (1997) Rafail Ostrovsky and Victor Shoup. 1997. Private Information Storage (Extended Abstract). In STOC. 294–303.
  • Panholzer (2008) Peter Panholzer. 2008. Physical security attacks on windows vista. SEC Consult Vulnerability Lab, Vienna, Tech. Rep (2008).
  • Ren et al. (2013) Ling Ren, Xiangyao Yu, Christopher Fletcher, Marten van Dijk, and Srinivas Devadas. 2013. Design Space Exploration and Optimization of Path Oblivious RAM in Secure Processors. In Proceedings of the Int’l Symposium on Computer Architecture. Available at Cryptology ePrint Archive, Report 2013/76.
  • Roche et al. (2017) Daniel S Roche, Adam J Aviv, Seung Geol Choi, and Travis Mayberry. 2017. Deterministic, Stash-Free Write-Only ORAM. arXiv preprint arXiv:1706.03827 (2017).
  • Sarmenta et al. (2006) Luis F. G. Sarmenta, Marten van Dijk, Charles W. O’Donnell, Jonathan Rhodes, and Srinivas Devadas. 2006. Virtual Monotonic Counters and Count-Limited Objects using a TPM without a Trusted OS. In Proceedings of the 1st STC’06.
  • Shi et al. (2011) E. Shi, T.-H. H. Chan, E. Stefanov, and M. Li. 2011. Oblivious RAM with Worst-Case Cost. In Asiacrypt. 197–214.
  • Stefanov et al. (2012) E. Stefanov, E. Shi, and D. Song. 2012. Towards practical oblivious RAM. In NDSS.
  • Stefanov et al. (2013) Emil Stefanov, Marten van Dijk, Elaine Shi, Christopher Fletcher, Ling Ren, Xiangyao Yu, and Srinivas Devadas. 2013. Path ORAM: An Extremely Simple Oblivious RAM Protocol. In Proceedings of the ACM Computer and Communication Security Conference.
  • Stewin and Bystrov (2012) Patrick Stewin and Iurii Bystrov. 2012. Understanding DMA malware. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 21–41.
  • Suh et al. (2003) G. Edward Suh, Dwaine Clarke, Blaise Gassend, Marten van Dijk, and Srinivas Devadas. 2003. aegis: Architecture for Tamper-Evident and Tamper-Resistant Processing. In Proceedings of the ICS (MIT-CSAIL-CSG-Memo-474 is an updated version). ACM, New-York. http://csg.csail.mit.edu/pubs/memos/Memo-474/Memo-474.pdf(revisedone)
  • Suh et al. (2005) G. Edward Suh, Charles W. O’Donnell, Ishan Sachdev, and Srinivas Devadas. 2005. Design and Implementation of the aegis Single-Chip Secure Processor Using Physical Random Functions. In Proceedings of the ISCA’05. ACM, New-York. http://csg.csail.mit.edu/pubs/memos/Memo-483/Memo-483.pdf
  • The Transaction Processing Council (2007) The Transaction Processing Council. 2007. TPC-C Benchmark (Revision 5.9.0). http://www.tpc.org/tpcc/spec/tpcc_current.pdf. (June 2007).
  • Trusted Computing Group (2004) Trusted Computing Group. 2004. TCG Specification Architecture Overview Revision 1.2.
    http://www.trustedcomputinggroup.com/home. (2004).
  • Williams and Sion (2012) Peter Williams and Radu Sion. 2012. Single round access privacy on outsourced storage. In Proceedings of the 2012 ACM conference on Computer and communications security (CCS ’12). ACM, New York, NY, USA, 293–304. https://doi.org/10.1145/2382196.2382229
  • Wojtczuk and Rutkowska (2009) Rafal Wojtczuk and Joanna Rutkowska. 2009. Attacking intel trusted execution technology. Black Hat DC 2009 (2009).
  • Wojtczuk et al. (2009) Rafal Wojtczuk, Joanna Rutkowska, and Alexander Tereshkin. 2009. Another way to circumvent Intel trusted execution technology. Invisible Things Lab (2009).
  • Woo et al. (1995) S. C. Woo, M. Ohara, E. Torrie, J. P. Singh, and A. Gupta. 1995. The SPLASH-2 programs: characterization and methodological considerations. In Proceedings of the 22nd Annual International Symposium on Computer Architecture. 24–36.
  • Yu et al. (2014) Xiangyao Yu, George Bezerra, Andrew Pavlo, Srinivas Devadas, and Michael Stonebraker. 2014. Staring into the Abyss: An Evaluation of Concurrency Control with One Thousand Cores. Proceedings of the VLDB Endowment 8, 3 (2014), 209–220.
  • Yu et al. (2015) Xiangyao Yu, Syed Kamran Haider, Ling Ren, Christopher Fletcher, Albert Kwon, Marten van Dijk, and Srinivas Devadas. 2015. Proram: dynamic prefetcher for oblivious ram. In Proceedings of the 42nd Annual International Symposium on Computer Architecture. ACM, 616–628.
  • Zhang et al. (2015) Xian Zhang, Guangyu Sun, Chao Zhang, Weiqi Zhang, Yun Liang, Tao Wang, Yiran Chen, and Jia Di. 2015. Fork path: improving efficiency of ORAM by removing redundant memory accesses. In Proceedings of the 48th International Symposium on Microarchitecture. ACM, 102–114.
  • Zhuang et al. (2004) Xiaotong Zhuang, Tao Zhang, and Santosh Pande. 2004. HIDE: an infrastructure for efficiently protecting information leakage on the address bus. In Proceedings of the 11th ASPLOS. https://doi.org/10.1145/1024393.1024403
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
""
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
   
Add comment
Cancel
Loading ...
316038
This is a comment super asjknd jkasnjk adsnkj
Upvote
Downvote
""
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters
Submit
Cancel

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test
Test description