analysis and benchmarking of privacy-preserving …...of berkeley, california, published path oram...

Politecnico di Milano

Scuola di Ingegneria Industriale e dell’InformazioneCorso di Laurea Magistrale in Ingegneria Informatica

Dipartimento di Elettronica, Informazione e Bioingegneria

Analysis and Benchmarking of Privacy-preservingMethods to Access Outsourced Data

Relatore: Prof. Gerardo PELOSI

Correlatore: Ing. Alessandro BARENGHI

Tesi di Laurea di:

Guglielmo P. F. MOLINARI Matr. 837667

Anno Accademico 2016–2017

Alla mia famiglia

Ringraziamenti

I miei ringraziamenti vanno al mio relatore e controrelatore, GerardoPelosi e Alessandro Barenghi, che mi hanno assistito nella comprensione esvolgimento di questa tesi.Inoltre, voglio ringraziare la mia famiglia che mi ha supportato durante tuttoil mio percorso formativo, permettendomi in fine di raggiungere il traguardodi un titolo magistrale. In particolar modo ringrazio mia madre Attilia, chemi ha sempre spinto a migliorarmi.Vorrei anche citare Isabella per il suo aiuto e sostegno in questi anni.

Sommario

Da quando é nato Internet, lo sviluppo tecnologico di nuovi dispositivinon é mai cessato. Negli ultimi anni abbiamo assistito a delle piccole ri-voluzioni nel modo in cui ci approcciamo ad Internet ed al modo in cui loviviamo. Smartphone, tablet e smartwatch fanno ormai parte della nostravita quotidiana e questi strumenti dialogano costantemente con internet eci permettono di trasferire velocemente enormi quantitá di informazioni chefino a vent’anni fa erano inimmaginabili. Con lo sviluppo di questi nuoviapparecchi, sono nate anche nuove infrastrutture che permettono di salvaregrossi quantitativi di dati su sistemi che esistono solo in rete, é nato il cloudcomputing. In questo documento verrá trattato il problema della sicurezzadelle comunicazioni e del passaggio di dati in rete e di come é possibile pro-teggersi utilizzando particolari algoritmi chiamati Oblivious Random AccessMemory (ORam). In particolare verrá analizzata la questione del manteni-mento della segretezza dei contenuti salvati su database esterni e di come igestori di queste piattaforme possano carpire informazioni applicando mo-delli statistici. Vedremo anche come il classico sistema di difesa, la cifratura,non é assolutamente sufficiente per arginare questo pericolo e di come sianonecessarie una serie di contromisure per avere la certezza della privacy deipropri dati. A tal fine, in questa tesi verranno presentati tutti gli elementi percomprendere il problema, le tipologie di soluzioni ed infine verranno espostequattro diverse implementazioni di algoritmi Oram, con relativi benchmark,per poter discutere i punti deboli e di forza di ogni sistema.

Abstract

Since Internet was born, the technological development of new deviceshasn’t stopped. In the last few years we have assisted to little revolutionsin the way we approach Internet and how it affects our lives. Smartphones,tablets and smartwatches are part of our ordinary life an these tools contin-uously communicate with each other using Internet enabling us to transfera large amount of information very fast, a thing that would be inconceivabletwenty years ago. Furthermore, with the development of these new devices,a new kind of online infrastructure that has the capability to store largeamounts of data was born, it is the cloud computing. In this document itwill be discussed the internet communication security problem and how itis possible to protect a data transfer using special algorithms called Oblivi-ous Random Access Memory (ORam). In particular, it will be discussed theprivacy threat that affects documents saved in external storages and howthe cloud service providers can steal secret information applying statisticalmodels. Also, it will be shown how common security precautions, like thecryptography, are not enough to solve the problem and how necessary it isto implement a series of countermeasures to guarantee the privacy of thedata. So, in this thesis, it will be explained the privacy problem and howthe service providers can steal information. Then, the possible solutions tothe problem are discussed, followed by the implementations of four Oramalgorithms. At the end of the document, there is a series of benchmarks ofthe four security systems that show the strength and the weakness of eachsolution.

Contents

Introduction 1

1 The Problem 3

1.1 The Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 The Contermeasures . . . . . . . . . . . . . . . . . . . . . . . 8

2 Shuffle Index 11

2.1 Structure of Shuffle Index . . . . . . . . . . . . . . . . . . . . 11

2.2 Theory and Protection Thecniques . . . . . . . . . . . . . . . 14

2.2.1 Cover Searches . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Cached Searches . . . . . . . . . . . . . . . . . . . . . 16

2.2.3 Shuffling . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.4 The Implementation . . . . . . . . . . . . . . . . . . . 18

2.3 Functional Example . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5 Security & Privacy Considerations . . . . . . . . . . . . . . . 27

3 Path Oram 29

3.1 Structure of Path Oram . . . . . . . . . . . . . . . . . . . . . 29

3.2 Theory of Path Oram . . . . . . . . . . . . . . . . . . . . . . 31


3.4 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36


4 Ring Oram 39

4.1 Structure of Ring Oram . . . . . . . . . . . . . . . . . . . . . 39

4.2 Theory of Ring Oram . . . . . . . . . . . . . . . . . . . . . . 42

i

CONTENTS

4.2.1 Access Function . . . . . . . . . . . . . . . . . . . . . . 44

4.2.2 ReadPath Function . . . . . . . . . . . . . . . . . . . . 46

4.2.3 EvictPath Function . . . . . . . . . . . . . . . . . . . . 49

4.2.4 EarlyReshuffle Function . . . . . . . . . . . . . . . . . 54


4.4 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59


5 Xor Ring Oram 63

5.1 Theory of XRing Oram . . . . . . . . . . . . . . . . . . . . . 64

5.1.1 ReadXorPath Function . . . . . . . . . . . . . . . . . . 65

5.1.2 Dummy Blocks Property . . . . . . . . . . . . . . . . . 67

5.1.3 WriteBucket Function . . . . . . . . . . . . . . . . . . 69

5.2 Structure of XRing Oram . . . . . . . . . . . . . . . . . . . . 71

5.3 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71


6 Experimental Evaluation 75

6.1 System Specifications . . . . . . . . . . . . . . . . . . . . . . . 75

6.2 Benchmarks Specifications . . . . . . . . . . . . . . . . . . . . 77

6.2.1 Measurements . . . . . . . . . . . . . . . . . . . . . . . 77

6.2.2 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2.3 Comparison Criterion . . . . . . . . . . . . . . . . . . 78

6.3 Base Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.3.1 Shuffle Index . . . . . . . . . . . . . . . . . . . . . . . 80

6.3.2 Path Oram . . . . . . . . . . . . . . . . . . . . . . . . 84

6.3.3 Ring Oram . . . . . . . . . . . . . . . . . . . . . . . . 85

6.3.4 XRing Oram . . . . . . . . . . . . . . . . . . . . . . . 88

6.4 Confrontation Tests . . . . . . . . . . . . . . . . . . . . . . . 89

6.4.1 Average Internet Accesses . . . . . . . . . . . . . . . . 93

6.5 Bandwidth Evaluations . . . . . . . . . . . . . . . . . . . . . 95

6.5.1 Bandwitdh Formulae . . . . . . . . . . . . . . . . . . . 98

6.5.2 Bandwitdh Confrontations . . . . . . . . . . . . . . . . 104

7 Conclusion 111

ii

CONTENTS

Conclusion 1117.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Bibliography 113

iii

CONTENTS

iv

List of Figures

2.1 Shuffle Index structure as seen by the server . . . . . . . . . . 13

2.2 Ideal Shuffle Index structure for the client . . . . . . . . . . . 13

2.3 Real Shuffle Index structure for the client . . . . . . . . . . . 13

2.4 Example of search into the cloud and change of variables dur-ing the Access procedure . . . . . . . . . . . . . . . . . . . . . 24

2.5 Initial status of the B+-tree . . . . . . . . . . . . . . . . . . . 24

2.6 Permutation inside the B+-tree . . . . . . . . . . . . . . . . . 25

2.7 Shuffle Index final result . . . . . . . . . . . . . . . . . . . . . 26

2.8 Cypher Block Chaining (CBC) encryption mode . . . . . . . 27

3.1 Oram tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 Oram tree after stash insertions . . . . . . . . . . . . . . . . . 35

3.3 Oram tree after saves . . . . . . . . . . . . . . . . . . . . . . . 36


4.1 Ring Oram tree . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2 ROram tree after aR research . . . . . . . . . . . . . . . . . . 57

4.3 ROram tree after EvictPath function . . . . . . . . . . . . . 58

4.4 ROram tree after EarlyReshufle function . . . . . . . . . . . 58



6.1 HDD performances . . . . . . . . . . . . . . . . . . . . . . . . 76

6.2 Shuffle Index LAN test with B=25 . . . . . . . . . . . . . . . 81

6.3 Shuffle Index LAN test with B=40 . . . . . . . . . . . . . . . 82

6.4 Shuffle Index WAN 30ms test with B=25 . . . . . . . . . . . . 82

v

LIST OF FIGURES

6.5 Shuffle Index WAN 30ms test with B=40 . . . . . . . . . . . . 836.6 Path Oram LAN test . . . . . . . . . . . . . . . . . . . . . . . 846.7 Path Oram WAN test . . . . . . . . . . . . . . . . . . . . . . 856.8 Ring Oram LAN test . . . . . . . . . . . . . . . . . . . . . . . 866.9 Ring Oram WAN test . . . . . . . . . . . . . . . . . . . . . . 876.10 XRing Oram LAN test . . . . . . . . . . . . . . . . . . . . . . 886.11 XRing Oram WAN test . . . . . . . . . . . . . . . . . . . . . 896.12 Confrontation test in LAN environment and ∆#Blocks = −76 896.13 Confrontation test in LAN environment and ∆#Blocks = 856 . 916.14 Confrontation test in WAN environment and ∆#Blocks = −76 916.15 Confrontation test in WAN environment and ∆#Blocks = 856 926.16 Bandwidth trend, ∆#Blocks = −76 . . . . . . . . . . . . . . . 1046.17 Bandwidth trend, ∆#Blocks = 856 . . . . . . . . . . . . . . . . 1066.18 Bandwidth trend, ∆#Blocks = −479 . . . . . . . . . . . . . . . 1076.19 Bandwidth trend, ∆#Blocks = 328 . . . . . . . . . . . . . . . . 109

vi

List of Tables

3.1 Legend of Path Oram . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Table of the main variables . . . . . . . . . . . . . . . . . . . 42

5.1 Main variables table . . . . . . . . . . . . . . . . . . . . . . . 71

6.1 System Hardware Specifications . . . . . . . . . . . . . . . . . 756.2 Tuning Parameters . . . . . . . . . . . . . . . . . . . . . . . . 776.3 New algorithms configurations . . . . . . . . . . . . . . . . . . 107

vii

LIST OF TABLES

viii

List of Algorithms

2.2.1 Shuffle Index algorithm . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Path Oram Access algorithm . . . . . . . . . . . . . . . . . . . 32

4.2.1 Non-recursive Ring ORAM. . . . . . . . . . . . . . . . . . . . . 444.2.2 ReadPath procedure. . . . . . . . . . . . . . . . . . . . . . . . 464.2.3 GetBlockOffset procedure. . . . . . . . . . . . . . . . . . . . . 484.2.4 EvictPath procedure. . . . . . . . . . . . . . . . . . . . . . . . 494.2.5 ReadBucket procedure. . . . . . . . . . . . . . . . . . . . . . . 514.2.6 WriteBucket procedure. . . . . . . . . . . . . . . . . . . . . . . 534.2.7 EarlyReshuffle procedure. . . . . . . . . . . . . . . . . . . . . . 54

5.1.1 ReadXorPath procedure. . . . . . . . . . . . . . . . . . . . . . 655.1.2 WriteBucket procedure. . . . . . . . . . . . . . . . . . . . . . . 69

ix

LIST OF ALGORITHMS

x

Introduction

What is an Oblivios RAM? What is the meaning of its acronym? Whatis its purpose? Why do we need it? The first person to talk about Oramwas Oded Goldreich, an Israeli professor of Computer Science that in 1987formulated the Oram theory. Then, in 2012, a PhD student of the universityof Berkeley, California, published Path Oram [1], one of the most impor-tant and efficient algorithms of its category. Oram is the abbreviation forOblivious Random Access Memory and is an algorithm category that hasthe purpose to hide the way in which people access to data stored in thecloud. In fact, the cloud service provider can obtain non-trivial informationabout the content stored in the servers even if the information is protectedby a strong cypher. Today, these intersection attacks [2] have become easierand more feasible than before because big companies have the computationalpower and the economic resources to do so. Also, the explosion of affordablecloud services and the computerization of little/medium enterprises has ex-posed more and more data to indiscreet eyes. For this reason, since 1987,many security algorithms have been published to protect the privacy of theusers.

Objective

The goal of this thesis is to compare four main Oram algorithms byrunning a series of tests in order to see how they work in common situationsand not only in their best scenario. To show what was obtained there isa dedicated chapter for each algorithm in which it is possible to find allthe features and a detailed explanation of their functioning. Inside eachalgorithm chapter, there is also a simple functional example to make clearerhow each system works. The last part of the thesis is dedicated to the

1

Introduction

benchmarks, how they were performed and which criterion of comparisonwas used, followed by a detailed analysis and explanation of the obtainedresults.

2

Chapter 1

The Problem

The privacy of personal information is one of the biggest problems thatour society is facing nowadays. Many of the e-commerce and of the so-cial media platforms employ users’ information to make profit, using thedata themselves or selling them to third parties. Basically, they see howusers approach their platforms, what is searched, clicked and viewed in themobtaining significant information. The same kind of extrapolation of datahappens on cloud storages where companies save important information suchas government documents, hospital records or personal emails. In fact, thesmall and medium enterprises that have not the economic resources to buildand maintain a personal cloud storage generally buy a cloud from a serviceprovider exposing themselves to a privacy threat. Nevertheless, both thecloud service providers and the clients take advantage of the cloud comput-ing infrastructure. In fact, this kind of market has seen a big expansion inthe last few years and is still growing due to the great demand.The privacy threat derives from the fact that the cloud service providershave the physical access to the machines and they can observe: how manyrequests are made in a certain period of time, the usage of the resourcesand the access patterns. It is important to note that the service providerhas not malevolent intentions but is very curious about what is stored in itsservers. In fact, gaining more information about its customers can representa great chance to earn more money for the big companies. This way, theycan offer customized services to their clients and cut the costs modifying thehardware on servers or migrating the service on different machines without

3

CHAPTER 1. The Problem

a noticeable loss of performances for the clients, improving the efficiency ofthe cloud. These service and cloud improvements are possible by analysingthe data obtained from the intersection attacks. For the service providersthis knowledge extraction is fundamental in order to be more competitive onthe market.The core problem is the storage of data in third parties databases because itis there that the leakage of information takes place. The first countermea-sure to this threat is concealing all the data with a cypher, before savingthem into the external storages. This is a good first step, but it is not thesolution to the problem because the encryption can only achieve the secrecy(confidentiality) of the data but it cannot hide how the owner accesses tothem. In fact, it is possible to retrieve the content of the encrypted infor-mation using some techniques that are examined in depth in Section 1.1.Furthermore, the service provider can see the access patterns of its clients,and this represents the main information leakage factor.It is important to clarify that, in this analysis, it is supposed that the serverknows the client’s security measures and the algorithms employed, but notthe security keys of the client. This assumption is essential because the se-curity of a system does not rely on the secrecy of the chosen algorithm, buton how it works and which security features it employs.To go deeper into the problem it is fundamental to explain every criticalpoint of the data outsourcing in external databases:

1. Static memory placement: When data is stored, it is placed in aspecific location of the memory and this location changes very rarely.Unless the client applies special countermeasures, this weakness enablesthe server to count how often the client accesses to his information.Also, the server can map memory areas with the same query identifiersused by the client. Therefore, the service provider can retrieve thecontent of the whole storage, with a certain degree of accuracy, eitherhaving a little knowledge of its clients’ business sector or using the helpof external databases like Google Trend. The explanation of how thisis possible is in Section 1.1.

2. Sequential queries: The normal behaviour of the client is to accessto the data in a useful way for him. In fact, he wants to extrapolate in-

4

formation from the cloud making a series of interrogations useful for hisgoals. For instance, the client can search for emails coming from a spe-cific sender, or check the sale volumes of the last two months, or checkthe incomes of his employees. To obtain knowledge from the cloud,the client makes a sequence of queries that share a common topic. Theserver knows this common behaviour and the learning process of theservice provider is even easier if the data extractions are made in in-terrogation bursts. With this behaviour, the server can draw a map ofcorrelation between the cyphered contents and can infer informationcollecting all the leakages. The main reason why this is feasible is dueto the static memory placement of the data.

3. Repetition of queries: The repetition of queries problem is charac-terized by the repetition of equal or similar requests during the exis-tence of the cloud. It doesn’t matter if the client makes an identicalrequest with two seconds or two years between one and the other, be-cause the server can easily see that they are equal. In fact, the serviceprovider can count how many times each interrogation is made invest-ing a very little amount of resources.In case the server doesn’t want to employ a permanent memory or hasa limited amount of storage, the repetition time will become funda-mental. In the first case, the server can see equal queries until thememory is refreshed or the machine is rebooted. In the second case,the server can count only the most frequent interrogations as it hasnot enough space to save them all. So, the information leakage is evenclearer when the repetition of queries happens in a very short periodof time between each other.

4. Frequency of queries: The number of requests made in a certainperiod of time defines the frequency with which the client accesses thecloud. Usually the client only performs interrogations when he needssome data. Sometimes he needs to retrieve all the information fromthe cloud, but sometimes he has the information in a local memory,so he can drop one or more queries. Also, it is common for the clientto have a cache system that holds useful data for the current taskand this client feature emphasizes the frequency of queries problem. In

5


this way the service provider can profile his client behaviour and gaininformation about the usage of cloud data and the correlation betweenthem.

All of this information leakages, combined together, represent a serious threatto the security of an external storage. In fact, all the four problems makeintersection attacks feasible. The core idea of these attacks is to guess whatis saved in the cloud observing the behaviour of the client without breakingthe cypher.Each information has its unique identifier and its fixed position in the cloud.Every time the client makes a query, the server can see which identifiersare involved and which memory locations are accessed more often. Withthis expedient, the server can make assumptions on the importance of theencrypted contents sorting them using the access frequencies. The morequeries are made, the higher will be the speculation accuracy of the serverand the information leakage of the cyphered content stored in the cloud.How is it possible to protect the data? During the last decades, the securitycommunity has proposed a multitude of algorithms called Oblivious RandomAccess Memory (Oram). The adoption of one of these security systems makesthe server’s counting useless and hides the correlation between data, makingintersection attacks infeasible.

1.1 The Attack

Before explaining how the attack is leaded towards a cloud computingstorage, it is important to define some baseline characteristics of the system.The first thing to say is that all the contents on the cloud are cyphered usinga secure cryptographic algorithm, so this is not the weak link in the chain.Second, all the information are accessed using a unique identifier (id) andonly the client knows the pairing < id, content >, where the content is a use-ful information. There are no other kinds of security measures implementedby the client, so each of the four problems mentioned previously is presentin the outsourced data scheme.The main characteristic of the intersection attacks [2] consists in countinghow often an id is used by analysing the client’s requests. This entails that,every time an identifier is used, an identical query is generated on the server

6

1.1. The Attack

side to retrieve the necessary information (Repetition of queries problem).At the same time, the server can understand the specific memory area asso-ciated to an id, because of the static memory placement problem.Now the service provider has all the necessary elements to make the attack.The key idea is very similar to the method employed for breaking a mono-alphabetic cypher. The attacker counts the frequencies of the letters of acyphered text, then he uses the basic knowledge of the letter frequencies ofthe language in which the message is written. At this point, he only needsto pair equal/similar frequencies between the cypher and the alphabet andretrieve the hidden text. In case the language of the plain text is unknown,it is necessary to perform another guessing phase choosing the alphabet thathas the most similar letter frequencies and the same number of distinct char-acters to the hidden text. The precision of the attack depends on the lengthof the cyphered text and on the size of the alphabet. If the accuracy is toolow, the attacker only needs to collect more cyphered text and repeat theprocedure.In the cloud scenario there are many analogies: the concealed source is thewhole content in the cloud, the identifiers are the alphabet letters, the num-ber of queries are comparable to the length of the cyphered text, the ad-ditional knowledge (the plain language) is the business sector of the client(medical, technological, military etc). As before, the attacker counts howmany times an id is used and associates it to a memory area with the sameaccess frequency. Then he can use the information about the client’s businesssector and select an auxiliary knowledge (e.g., Google Trends) to know themost frequent searched keywords in that specific field to pair keywords/idswith the same/similar frequencies. If the service provider has no informationabout its client, it has to apply the same kind of guessing technique explainedbefore, obviously it is a more complicated scenario, but the principle is thesame. In fact, the attack can be successful if the server dynamically adjuststhe client’s business sector and repeats multiple times the intersection attackon different knowledge bases. The guess might be inaccurate in the very firstrounds performed since, at the beginning, the server has no idea about theexact user’s background, but with the increase of the attack rounds, it cangradually identify the exact business sector of the client. It is important tounderstand that this kind of attacks are not infeasible.

7


Now the service provider knows all the keywords of the cloud and it canextrapolate further knowledge using the correlation between contents. Asmentioned before, the sequential queries problem and the frequency queriesproblem show clearly the access patterns of the client and the correlation be-tween specific data. With this further step, the attacker can read the cloud.For example, if the outsourced data scheme is the one of a hospital, it ispossible to associate patients with their diseases or with their therapy usingthe disclosed contents and the access patterns.

1.2 The Contermeasures

This section deals with the countermeasures that can be implemented tosolve the outsourced data schemes problems. The basic idea is to make in-tersection attacks infeasible, creating confusion on the server side and hidingreal researches with useless requests. But how is this possible? There aredifferent problems that afflict an outsourced data scheme, but for each ofthem there is a solution.One of the first countermeasure commonly used in Oram algorithms is to ob-fuscate the correlation between multiple queries performing a series of fakesearches. This technique is more powerful if for each real information re-quest more cover searches are performed. This number is usually chosen bythe client once and then it is maintained for all the queries. It is impor-tant to understand that this fake searches must be different every time theyare scheduled. However, there are constraints to follow and these uselessrequests have a considerably high cost in terms of resources, but by usingthem, sequential queries can be performed with a certain degree of security.The second countermeasure is to change continuously the position of thecontents inside the cloud. The client has the power to choose where to placeeach information inside the external storage. This kind of behaviour has thepurpose to randomize the data positions from the server point of view andhas the same objective as shuffling a card deck. How is this done? Basically,the client changes the combination of < id, content > every time he hasthe possibility, and the effect on the cloud side is a storage that is continu-ously shuffled. What changes in the database is the content placement, notthe cloud structure. Unfortunately, the service provider can still recognize

8

1.2. The Contermeasures

the same cyphered information relocated in the cloud if its encryption isalways the same. Symmetric encryption schemes will always have the sameoutcome if the inputs are always the same. So, it is necessary to modifysomething before applying the cypher algorithm. The possible solutions canbe changing the initialization vector (iv) or the encryption key. Otherwise itis common to add some random pad inside the structure of the information.With these stratagems, the server has no possibility to recognize the relo-cation of the same content. This countermeasure solves the static memoryplacement and the repetition of queries problems because every informationis forced to change its position and identifier. Moreover, with the help ofcover searches, it is solved the problem of correlation leakage, too.The last threat remaining is the queries frequency problem that reveals theclient usage behaviour of his data. To solve this issue, it is possible to choosea fixed number of queries to perform in a single period of time. This makesit impossible to profile the client’s behaviour because there is no mutationin his actions.

9


10

Chapter 2

Shuffle Index

The first algorithm presented in this document is Shuffle Index [3]. Itis an algorithm published in 2015 by teachers and researchers of Universitádegli Studi di Milano, Universitá degli Studi di Bergamo and Politecnico diMilano. The main goal of the algorithm is to guarantee the privacy andthe security of outsourced data. There are many similar protocols with thesame features, but this one has substantial differences from the others as itimplements particular solutions that could make it one of the most balancedalgorithms in terms of performances and costs.

2.1 Structure of Shuffle Index

This part of the document is focused on the description of the data struc-tures implemented in Shuffle Index, fundamental for the comprehension ofthe protocol. Without further hesitations it is time to see how Shuffle Indexis structured and how it works. The main data structure is an unchainedB+-tree. Every node of the unchained B+-tree has at most a fan-out of Fchildren, except for the root that always has F children (the case of a treewith only the root is not representative). Inside each node there is a vectorof indexes that points to its children. The internal organization of the datastructure holds the following rule: the i-th child of any internal node in theunchained B+-tree is the root of a subtree containing the values v with:v < v1; vi−1 ≤ v < vi, i = 2, ..., q − 2; v ≥ vq−1, ordered from the smallest tothe greatest.Every B+-tree node has a bucket inside that is composed of blocks and it

11

CHAPTER 2. Shuffle Index

is here that it is possible to save information. The number of blocks perbucket is equal to B = F − 1 and every block has a unique identifier foridentification and searchable reasons.

Definition1.3 (B+-tree): The tree of height H is formed by (F )H−1F−1 nodes.

Every node has an identifier id ∈ [0, (F )H−1F−1 − 1]. Inside the tree there are

H levels identified by L ∈ [0, H − 1]. The first L− 1 levels contain internalnodes, while the leaf level L contains leaf nodes.

Definition1.1 (InternalNode) : Let <id, keys[B], childrenIds[B + 1]> bethe configuration of a node that is not a leaf. The first component is theunique identifier of the node. The keys[B] vector represents the space whereit is possible to store B research keys useful for choosing which path to fol-low. The childrenIds[B + 1] vector contains all the identifiers of the childnodes. B is the parameter that defines the bucket size.

Definition1.1 (LeafNode) : Let <id, bucket[B]> be the configuration ofa leaf node. The first component is the unique identifier of the node andthe bucket[B] is the vector where the Blocks are saved. These nodes arethe only ones that have information inside them. B is the parameter thatdefines the bucket size.

Definition1.2 (Block) : Let <idb, data> be the structure of a block, whereidb ∈ [0, B · ( (F )H−1

F−1 − 1)] represents a unique identifier that is also the re-search key of the block. The data field is the space dedicated to save usefulinformation.

To better understand the physical structure of Shuffle Index, it is proposeda simple representation of an unchained B+-tree (Figure 2.1) as it is seenby the server.

12

2.1. Structure of Shuffle Index

Figure 2.1: Shuffle Index structure as seen by the server

In Figure 2.2 it is shown how the data structure is filled ideally.

Figure 2.2: Ideal Shuffle Index structure for the client

In Figure 2.3, it is represented an instance of the same B+-tree as itcould be saved on the cloud. These interlaced relationships between nodeshave the purpose to confuse the server and hide the access patterns. But itshould be noted that the node identifiers remain at their places.

Figure 2.3: Real Shuffle Index structure for the client

It is important to understand that the physical structure of the treealways remain the same whatever action the client performs. What changesevery time are the nodes contents and the parent/child relationships. In fact,the algorithm maintains the tree continuously shuffled, constantly modifyingthe data inside the structure. How this is done will be explained more indetail in the next section.

13


2.2 Theory and Protection Thecniques

Before going into the details of the algorithm, it is important to definethe security features of Shuffle Index. The algorithm uses three techniques toensure that no information can leak from the cloud or during the data trans-fer through Internet. These strategies are: the cover searches, the cachedsearches and the shuffling. Also, each node of the tree is encrypted using astrong and secure cypher to ensure the confidentiality of its content.

2.2.1 Cover Searches

As the name suggests, the functionality of the cover searches is to hidethe real searches performed on the cloud. It is important to conceal the realqueries, otherwise the counting of the access content frequencies is feasibleand intersection attacks can be performed. In fact, the server can pair a phys-ical location with a specific content (they have the same frequencies) and,at the same time, it can guess the importance of the information by usingan ascending ordering of frequencies. For instance, consider two consecutiverequests of ’F’ on the Figure 2.3 scheme. The server will access at nodes(001); (103); (207) twice, revealing that the two queries refer to the sameinformation. To mitigate the repetition of queries problem, the stratagemis to search useless contents during a real request. This is a simple andvery effective action because it confuses the server. The number of coversearches performed for each real request is chosen by the client setting theparameter num_cover. For example, with one cover search per real query,the client will perform four accesses: two pointing to the block ’F’ and twopointing towards two other blocks, for instance ’I’ and ’M’. So, for the firstquery, the server will access to nodes (001); (101, 103); (201, 207) and then(001); (103, 104); (207, 211). With this trick, the server has a probabilityp = 0.5 · 0.5 = 0.25, rather than p = 1, to infer a sequential access to thesame node. In case the required content is in the client cache, the algorithmperforms an additional cover search (num_cover+1), otherwise there are twopossible security breaches. In the first case, the client tends to completelyavoid accessing the cloud, but this reveals that the target content is alreadyin cache (frequency of queries problem). In the second case, the client tendsto make only the num_cover searches, revealing that all these researches

14

2.2. Theory and Protection Thecniques

are fake and the server still infers a cached content. For this reason it isimportant to make the same amount of queries every time. Here below thecover searches are formally defined.

15


Definition1.4 (Cover searches) : Let < id0, b0 >, ..., < idm, bm > bea set of nodes forming a Shuffle Index built over a candidate key with domainD, and let v0 be a value in D. A set v1, ..., vn of values in D is a set of coversearches for v0 if ∀vi, vj ∈ v0, ..., vn : vi 6= vj =⇒ path(vi) ∩ path(vj) =

< id0, b0 >, that is, it contains only the root of Shuffle Index.

This means that the only node in common for every search, fake or not,must be the root of the tree and nothing else. This is a very strong con-straint and a very safe measure for the algorithm because it binds the valueof num_cover to the fan-out of the root F . To summarize the way in whicha search works, when the algorithm has to retrieve a content on the cloud itwill perform one search plus the number of cover searches. This sum cannotbe greater than the fan-out because there are not more than F possible pathsoutgoing the root of the tree. Each cover search path is chosen uniformlyat random to make indistinguishable real and fake searches. Also, anothersafe feature is that all the researches are performed in parallel, level by level(every num_cover+1 nodes at each level of Shuffle Index is retrieved beforeproceeding to the next level). This means that the parent-child relationshipbetween nodes of adjacent levels is broken because at each level any of thenum_cover+1 parents could be associated with any of the num_cover+1children, therefore producing (num_cover + 1)h potential paths.

2.2.2 Cached Searches

A cached search is a special case of data request. Basically, the neededinformation is in the client cache and it is not necessary to make the wholesearch procedure to retrieve the content. As mentioned before, in this case,the Shuffle Index algorithm will perform (num_cover+1) fake searches tohide the unnecessary request to prevent any leakage of information (queriesfrequency problem). Also, this strategy will make intersection attacks worsebecause the searches are completely uncorrelated between each other. Butbefore going on with the explanation, it is important to define how the cacheworks.

Definition1.5 (Cache) : Let < id0, b0 >, ..., < idm, bm > be a set of nodesforming an unchained B+-tree of heightH. A cache C of size num_cache for

16


the unchained B+-tree is a layered structure of L+1 sets Cache0, .., CacheL,where:

• Cache0 contains the root node < id0, n0 >;

• Cachel, l = 1, ..., L, contains num_cache nodes belonging to the l−thlevel of the unchained B+-tree;

• ∀n ∈ Cachel, l = 1, ..., L, the parent of n in the unchained B+-treebelongs to the Caclel−1 (path continuity property).

In other words, the cache is composed of multiple levels going from zero to L.When a node is taken from the server, it is placed at the same depth in thecloud. When the cache is full and a new node has to be inserted, the LeastRecently Used (LRU) policy is applied to make space for the new node. Thepath continuity property guarantees that all the nodes retrieved for the realsearch are in cache, starting from the root (always in cache) going down tothe leaf requested.The cache is useful for hiding equal searches made at distance num_cachefrom each other, because the targeted information is still in the cache andthe algorithm will only perform fake researches in the second query. Thisprevents from short intersection attacks and the server can not distinguish adifferent behaviour of the client because he always makes the same numberof requests.

2.2.3 Shuffling

Cover and cache searches aren’t sufficient to counteract all the possibleleakages of information because the static memory placement problem is stillnot solved. In fact, the server can still see the access patterns if its obser-vation goes beyond the cache size. To counteract this weakness, the ShuffleIndex algorithm implements the node shuffling mechanism.

Definition1.6 (Shuffling) : Let N = < id1, n1 >, ..., < idm, nm >be a set of nodes at the same level of an unchained B+-tree and π be apermutation of id1, ..., idm. The node shuffling of N with respect to π is theset < id1, n

′1 >, ..., < idm, n

′m > of nodes, where idi = π(idj) and n′i = nj

with i, j = 1, ...,m.

17


The definition states that every time a level of the cloud is accessed, allthe nodes at the same depth will be shuffled changing their node identi-fiers. It is important to remind that a real query with its cover searches isperformed in parallel, level by level. Another point of strength of the shuf-fling operation is how the permutation is performed. The π function usesnodes from Cachel and the last read nodes. As it is possible to imagine, allthe parent-child relationships and the data locality of nodes are eliminatedfrom the server point of view. For instance, let’s assume three accesses withthe following paths (001);(101,103);(201,207); (001);(103,104);(207,211);(001);(102,103);(207,208). The server sees the presence of a common leafnode, 207. The three queries aim at accessing the same node only if: thesecond and third requests are for the content of node 207 (the probabilityis 0.5 · 0.5 = 0.25); the data target of the first request coincides with thecontent of node 207 after the first shuffling operation (the probability is 0.5);and the content of node 207 is not moved by the second shuffling operation(the probability is 0.5). As a consequence, 0.0625 is the probability that thethree requests aim at the same node. Without this procedure the server caneasily infer a probability of 0.5 · 0.5 · 0.5 = 0.125 that the three queries pointat the same data location. It is possible to assert that it is not a high prob-ability, but performing this operation multiple times can seriously threatenthe privacy of the information.

2.2.4 The Implementation

This part of the document deals with the internal functioning of theShuffle Index algorithm and how it can reach its security objectives. All thevariables, auxiliary functions and subroutines are highlighted and explainedin details. It is an important part of the discussion of Shuffle Index becausewithout a clear picture of how it works, it will be difficult to understand allthe following observations and considerations.

18


Algorithm 2.2.1: Shuffle Index algorithm

1 . S : Shuffle Index on a candidate key with domain D, leaf level L,fan-out F /

2 . Cachel, l = 0, ..., L : cache /

3 . num_cache: number of nodes in Cachel, l = 1, ..., L /

4 . num_cover: number of cover searches /

Input: target_value: value to be searched in Shuffle IndexOutput: n: leaf node that contains target_value

5 MAIN6 . Initialize variables /7 Non_Caches := Non_Cached_P := 08 let n0 be the unique node in Cache0

9 target_id := n0.id

10 cache_hit := TRUE . the root always belongs to Cache0

11 num_cover := num_cover + 1

12 for i := 1...num_cover do cover_id[i] := target_id

13 . Choose cover searches /14 for i := 1...num_cover do15 randomly choose cover_value[i] in D s.t. ∀j := 1, ..., i− 1,

16 ChildToFollow(n0, cover_value[i]) 6= ChildToFol-low(n0, cover_value[j])

17 ChildToFollow(n0, cover_value[i]) 6∈n.id|n ∈ Cache1 and

18 ChildToFollow(n0, cover_value[i]) 6= ChildToFol-low(n0, target_value)

19 . Search, shuffle and update cache and index structure /20 for l := 1...L do21 let n ∈ Cachel−1 such that n.id = target_id22 target_id :=ChildToFollow(n, target_value)23 . identify the nodes to read from the server /24 if target_id 6∈ n.id|n ∈ Cachel then25 ToRead_ids := target_id26 if cache_hit then27 cache_hit := FALSE28 num_cover := num_cover − 1

29 else30 ToRead_ids := ∅

19


31

32 for i := 1...num_ cover do33 let n ∈ Cachel−1

⋃Non_Cached_P such that

n.id = cover_id[i]

34 cover_id[i] := ChildToFollow(n, cover_value[i])35 ToRead_ids := ToRead_ids

⋃cover_id[i]

36 . read blocks /37 Read := Decrypt(ReadBlocks(ToRead_ids))

38 . shuffle nodes /39 let π be a permutation of ToRead_ids

⋃n.id|n ∈ Cachel

40 foreach n ∈ Read⋃Cachel do n.id := π(n.id)

41 . determine effects on parents and store nodes at level l-1 /42 foreach n ∈ Cachel−1

⋃Non_Cached_P do

43 for i:=1...F do n.pointers[i]:=π(n.pointers[i])

44 WriteBlock(n.id, Encrypt(n))

45 target_id := π(target_id)

46 for i:=1...num_ cover do cover_id := π(cover_id)

47 . update cache level l /48 Non_Cached := Read

49 if cache_ hit then50 refresh the timestamp of n ∈ Cachel s.t. n.id = target_id51 else52 let deleted be the least recently used node in Cachel53 let n ∈ Read s.t. n.id = target_id54 insert n into Cachel55 Non_Cached_P := Non_Cached

56 . Write nodes at level L /

57 foreach n ∈ CacheL⋃Non_Cached_P do

WriteBlock(n.id,Encrypt(n))

58 . Return the target leaf node /59 return n

60 CHILDTOFOLLOW (n,v)61 i:=062 if v ≥ n.values[1] then63 while i+1 < Lenght(n.values) AND v>n.values[i+1] do64 i:=i+1

65 return n.pointers[i]

20


There is only one parameter passed through the prototype of the function.That is:

• target_value: This variable is a research key that identifies a preciseblock. It is used to discern which path to follow using the internalorganization of the unchained B+-tree.

Now it is possible to move on to the major steps accomplished by the ShuffleIndex algorithm:

• Select cover_values (line 12 to 18): The parameter num_coverdetermines the number of cover searches to perform during a sin-gle request. By default settings, the algorithm defines num_cover+1cover_values, useful to hide the target_value search. The additionalcover search is useful in case the target_value is in cache. These covervalues have to hold some constraints:

– Not same path (line 16): the path to follow for any cover_valuemust have only the root as common node.

– Not in cache (line 17): the level one following child of acover_value must not be in cache.

– Not same path of target_value (line 18): the path of anycover_value must be different from the path of the target_value.

These constraints are very binding because, from the root, it is possibleto have only F different paths in total. It is mandatory to have at leasta fan-out F =num_cover+2 (one for the target_value, the others arenum_cover+1 cover searches) or the algorithm will not work properly.So, the dimension of the bucket B, the fan-out F and the securityparameter num_cover are strictly related.

This part deals with the level by level search (i.e., l ∈ [1, L]):

• Node in cache (lines 21 to 30): here it is ascertained if theChildToFollow(n0,target_id) is in cache or not. Basically, if the nodeis not present in Cachel, it is necessary to retrieve the target_id nodeand to drop one cover_search. In fact, the algorithm always performsnum_cover+1 reads, if the target_id node is in cache the reads re-quests will be only for cover values, otherwise one of the num_cover+1

21


reads will be a research for a useful content. This is achieved in-crementing or decrementing the num_cover number and filling withproper identifiers the To_Reads_ids vector. In the case of a cachehit, To_Reads_ids will be full of cover_ids, otherwise there will beone less cover_id in To_Reads_ids and its place will be taken by thetarget_id.

• Node to read (lines 32 to 35): Here are determined all the nextnode identifiers for the cover_values. All of them are inserted into theTo_Reads_ids vector.

• Read operation (line 37): All the node identifiers insideTo_Reads_ids are retrieved from the cloud, then decrypted. Now thealgorithm has a Read vector full of nodes extracted from the level l ofthe unchained B+-tree.

• Permutation (lines 39 to 40): All the nodes inside Read and insideCachel undergo the permutation procedure. What really happens isthat node identifiers are swapped. In fact, it is not necessary to up-date other variables of nodes because they will be changed in the nextiteration of the Access function, during the update fathers phase.

• Update fathers and store (lines 42 to 44): It is fundamental toupdate the children indexes inside the father nodes, otherwise the in-ternal organization of the tree will be destroyed permanently. So, allthe fathers previously read receive the new identifiers of their childrenand then they are encrypted and stored on the cloud.

• Update cover_ids and target_id (lines 45 to 46): the updateof the identifiers must be applied also on the target_id and on thecover_id vector.

• Cache update (lines 49 to 55): The node with the identifier target_idis placed inside the Cachel. In case there is not enough space, the LRUpolicy is applied to empty a slot for the new node. All the other nodesof level read during this iteration are placed in Non_Cached_P withthe purpose to be re-uploaded in the next iteration.

22


After the algorithm has reached the bottom of the unchained B+-tree anduploaded the permuted nodes at the leaf level, there is still one operation todo before ending the Access procedure:

• Return (line 59) (Retrieve of the real node): At the beginning of theresearch procedure, the target_id node can be in the cloud or in Cache.At this point of the Access function, the requested node must be insideCacheL and it is possible to retrieve and return the requested node tothe client.

The only auxiliary function inside the Access operation is ChildToFollow.Its purpose is to retrieve the next node identifier given a node n and a re-searchKey v. The function uses the internal organization of the node tochoose which child identifier must be returned.

23


2.3 Functional Example

There is no better way to explain the whole Access operation than usingan example. The initial parameters are num_cover = 1, num_cache = 2

and target_value =’F’. In Figure 2.4 is shown how the data structures arepopulated inside the Access function, during the research. The table mustbe read row by row from left to right. The rows represent at which level lof the B+-tree the algorithm is performing its operations and which cachelevel (Cachel) is in use.

Figure 2.4: Example of search into the cloud and change of variables duringthe Access procedure

Starting from the possible cloud configuration shown in Figure 2.5, thefirst step accomplished by the algorithm is to choose the cover searches.Following the constraints for the selection of cover_values, it is supposedthat the two additional researches are ’S’ and ’M’.

Figure 2.5: Initial status of the B+-tree

In iteration l = 1, the next node to read for ’F’ is 103, obtained usingChildToFollow(001,’F’), which is in Cache1. For the two cover valuesthe results are 104 and 102, respectively and these identifiers are added tothe To_Reads_ids vector. Then the algorithm reads the selected nodes

24

2.3. Functional Example

and decrypts and puts them into the Read vector. Each node in Cache1

and Read goes through the permutation phase so the node identifiers areswapped following: (101 → 102), (103 → 101), (102 → 104), (104 → 103).In Figure 2.6 there is the graphical representation of the permutation thattakes place, see only level l = 1. Now target_id = π(target_id) = 101.The node 101 (the old 103) is saved in Cache1 and the other read nodes areplaced in Non_Cached. The last step is to update the children pointers ofthe 001 node following π, then encrypt and store the node in the cloud.

Figure 2.6: Permutation inside the B+-tree

In iteration l = 2, To_Reads_ids will be 202, 207 because thetarget_id node is not in cache, so the second cover search is dropped. Thenodes are read and then permuted (202→ 210), (203→ 207), (207→ 202),(210→ 203) using nodes in Cache2 and Read. The target_id node 202 (theold 207) is placed in Cache2 discarding 203 because it is supposed that node203 is the least recently used (LRU cache policy). Then the update phaseoccurs and the father nodes 101, 102, 103, 104 present in Cache1 and inNon_Cached_P following π. After that, there is the encryption and thestorage of the nodes into the cloud.The final result can be seen in Figure 2.7.

25


Figure 2.7: Shuffle Index final result

2.4 Complexity

This section deals with the time and space complexities of Shuffle Indexmain data structures. It is possible to figure out which part of the algorithmcould be a bottleneck reading the functions descriptions.

• Multilevel Cache (client): it is the most important structure onclient side. It works just like a cache so it is very useful for the userbecause it memorizes the last num_cache · H nodes read during thereal researches. Also, it is a flexible structure because its dimension canbe customized by the client so it is tailor-made for him. The cache sizeis determined by the parameter num_cache and by the height H of theB+-tree, so the spatial complexity is O(num_cache · (L+1)). A moreaccurate analysis is O((num_cache · L) + 1) because the root level ofthe B+-tree contains only one node so it is necessary to memorize onlyone element in Cache0. The normal usage of the cache is level by level,so the algorithm works on single vectors that have time complexity ofO(num_cache) (for Cache0isO(1)).

• Non_Cached (client): it is not a permanent vector but it is usedmultiple times in the Access function. Its time and spatial complexityare O(num_cover).

• Non_Cached_P (client): it is not a permanent vector but it is usedmultiple times in the Access function. Its time and spatial complexityare O(num_cover).

26

2.5. Security & Privacy Considerations

2.5 Security & Privacy Considerations

This section deals with the security features of Shuffle Index and howthey prevent the leakage of information.The four key points to guarantee are: Data confidentiality, Data in-tegrity, Access confidentiality, Pattern confidentiality.

Figure 2.8: Cypher Block Chaining (CBC) encryption mode

The data confidentiality and the data integrity are guaranteed byan AES cypher. It was chosen to use a security key of 16Byte and a CypherBlock Chaining (CBC) encryption mode. This cypher modality, Figure 2.8,hides the content partitioning it into fragments of the same length as thekey. The first fragment is xored with an Initialization Vector (IV) and thenencrypted. Each subsequent fragment is encrypted after being xored withthe previously encrypted fragment.The Access confidentiality and the Pattern confidentiality are guaran-teed by the shuffling procedure. In fact, the permutation function π reshufflesthe nodes choosing them uniformly at random. From the server point of view,it is impossible to predict or guess where a precise content is repositionedeven if it knew the initial position of the relocated node content. Also, thisprevents the server from recognising the access patterns (pattern confiden-tiality) of the client. Furthermore, the cached nodes and the cover searchesmake the algorithm even stronger to any possible intersection attack.

27


28

Chapter 3

Path Oram

Path Oram [1] is an algorithm created by Emil Stefanov, a brilliant stu-dent who was among the first to talk about oblivious random access memoryprotocol. This algorithm uses very simple ideas to solve the complex privacyproblem. Many other algorithms have reproposed similar solutions as it is alandmark in this academic topic. The key idea of this security system wasto use one of the most powerful data structure for the cloud (binary tree),in term of insertion/deletion/research complexity, and to implement a fastaccessing procedure. Furthermore, Path Oram employs a completely differ-ent randomizing technique compared with Shuffle Index, that guarantees theprivacy of the cloud contents.

3.1 Structure of Path Oram

The memory structure that was chosen for the cloud is a binary-tree witha height H and 2H−1 leaves. The implemented tree has the property beingperfect (complete and balanced) this implies that all leaves have the samedistance from the root, too. The memory structure can be subdivided inlevels that are numbered from 0 to L, where 0 is the root level and L = H−1

is the leaf level.Each node in the tree has a bucket inside, this bucket is composed of B blockswhere information can be stored. If a bucket is not full with real blocks, theremaining slots are filled with dummy blocks.

29

CHAPTER 3. Path Oram

Definition1.1 (Binary tree) : The binary tree of height H = L + 1 isformed by 2H − 1 nodes, each one of them is characterized by < idi, b >,where idi is the identifier having i ∈ [0, 2H − 2] and b a Bucket.

Definition1.2 (Bucket) : Let bucket[B] be a vector of dimension B filledwith < idb, z > blocks.

Definition1.3 (Block) : Let < idb, data > be a block of the tree, whereidb ∈ [0, B · (2H − 2)] is the unique block identifier. The data field is thespace dedicated to save useful information.

There are 2L leaves in the tree, each one has a unique path obtainable us-ing the specific function P (x), where x is the leaf identifier. This functionretrieves all the node identifiers along the path from the root to the leaf x.There is also a similar function P (x, l) that returns the exact identifier atdepth l starting from the top of the tree.On the client side there are two data structures:

• Stash: the purpose of the stash is to collect all the blocks that cannotbe saved on the cloud. This occurrence can happen some times duringthe normal procedures of access to the server and it is demonstratedthat the worst-case size is O(log(N) · Ω(1)) [1]. The stash contains avariable number of < idb, info > retrieved blocks.

• Position map: In the client, all the pairs of < idb, x > are stored,where x is a leaf identifier of the tree and idb is a block identifier.This mapping function is used during the searching process to retrievethe position of a specific block. Every block, if not in stash, must bepresent in one of the nodes along the path P (x).

On the server side the memory structure is a collection of nodes < idi, b >.In fact it can be claimed that during the normal reading and writing processon the cloud, the server continuously observes a fixed logical structure ofindexes while the buckets inside nodes change constantly.

30

3.2. Theory of Path Oram

3.2 Theory of Path Oram

In this section, all the details of Path Oram and its working mechanismswill be discussed. To begin with it is fundamental to show the legend of thesymbols.

N Total # blocks outsourced to server

H Height of binary tree

L Leaf level of binary tree

Z Block size (in bits)

B Capacity of each bucket(in blocks)

P (x) Path from root to leaf node x

P (x, l) Node identifier at level l along the path P (x)

S Client’s local stash

position Client’s local position map

x := position[a] Block a is currently associated with a leaf node x, i.e.,block a resides somewhere along P (x) or in the stash.

Table 3.1: Legend of Path Oram

The initial situation on the server side is a tree completely filled withrandom dummy blocks. On the client side all of the auxiliary data structures,like the stash and the position map, are empty because there are no realblocks saved on the cloud.The two main operations executable on cloud are reads and writes, bothof them are performed by the Access function. In the pseudo-code below isshown how the function works step by step.

31


Algorithm 3.2.1: Path Oram Access algorithm

1 Access (op,a,data*):2 x← position[a]3 position[a] ← UniformRandom(0...2L − 1)4 for l ∈ 0, 1, ..., L do5 S ← S

⋃ReadBucket(P (x, l))

6 data← Read block a from S

7 if op = write then8 S ← (S − (a, data))

⋃(a, data∗)

9 for l ∈ L,L− 1, ..., 0 do10 S′ ← (a′, data′) ∈ S : (x, l) = P (position[a’], l)11 S′ ← Select min (|S′|, Z) blocks from S′

12 S ← S − S′

13 WriteBucket(P (x, l), S′)

14 return data

There are three parameters that characterize the Access function:

• op: this variable has the function to describe the client’s operationthat he wants to actuate (read,write).

• a: it is the block identifier requested by the client on which the reador write operation will be applied.

• data*: it is the new data to write on the cloud. In a read operationthis parameter is not utilized.

The procedure of cloud accessing can be resumed in four main steps:

1. Remap block (line 2 to 3): the position of the needed block is re-trieved and then it is remapped with a new leaf identifier. The oldvalue is saved in x until the end of the procedure.

2. Read path (line 4 to 6): all the node buckets belonging to the pathP (x) are read and placed into the stash. With this operation the pres-ence of the block a is forced inside the stash. In fact, before the Accessfunction call, the a block only can be in two places: in cloud along thepath P (x), or it is already in stash due to a previous operation.

32

3.2. Theory of Path Oram

3. Update block (lines 6 to 8): the block having the identifier equal toa is retrieved from the stash. If the specified operation op is a writeone, the chosen block is updated with the new data∗ and saved againon the stash.

4. Write path (line 9 to 15): this is the real concealing feature of thealgorithm. Starting from the leaf level and going up to the root, foreach node along the path P (x), the algorithm tries to fill up eachbucket with all the possible blocks in stash, following this condition: ablock a′ ∈ stash can be placed in the node bucket P (x, l) if and only ifthe path P (position[a′]) intersects P (x) at the exact level l. In otherwords, for each a′ ∈ stash, it is checked if their path P (position[a′])

has a common node on P (x) at depth l (∀a′ ∈ stash, ifP (x, l) =

P (position[a′], l) =⇒ a′ can be saved in P (x, l)). The maximumnumber of possible blocks per bucket is equal to B. If there are lessblocks to complete the bucket, the remaining free slots are occupiedby fake random blocks. The meaning of this procedure is to shuffle thecontent of the path P (x) every time the client accesses to the cloud.Before uploading the node into the cloud, it must be encrypted.

33



The example proposed below has the purpose to clarify any doubts per-taining the Path Oram algorithm and its logic. So, for instance, a possiblerepresentation of an POram tree with a four slots bucket (B = 4) and a pos-sible stash are shown in Figure 3.1. For convenience reasons dummy blocksare omitted.

102

204203202201

101

001

O P S V N

Q H W R A L X U B T

E M I

STASH: D J G C F Y

Figure 3.1: Oram tree

Starting from this configuration, it will be simulated a research on theserver supposing a write request on the block R. Therefore the steps toretrieve the content are:

• Access function: the function prototype will be

Access(”writeop”, aR, ”#”)

• Retrieve and remap: The algorithm discovers the position of theneeded block on cloud and pairs it with a new leaf with id 201, forinstance. The remapping will only be applied after the block will besaved again on the server side, so for the moment the block still lie onpath P (x). The x value is obtained using x ← position[aR]. In thiscase x = 202.

• Stash insertions: the client saves all buckets along the pathP (202) = 001, 101, 202, Figure 3.2. As mentioned before, the block

34


aR can be only in two places during this phase, either in cloud or instash. If aR is already in stash, it is crucial to make the research forsecurity reasons (query frequency problem).

Figure 3.2: Oram tree after stash insertions

• Research in Stash: the content is retrieved from the stash.

• Write: if the operation specified is a write, as it is in this case, thecontent of the retrieved block is changed with ”#” that is the data∗

parameter value. Otherwise there isn’t any data manipulation.

• Saves: from the leaf 202 to the root 001, the algorithm starts to fillup the buckets on path P (202). For this example it is supposed that,at the end of this phase, the data structures will appear as shown inFigure 3.3.

35


Figure 3.3: Oram tree after saves

It is possible to notice the contents change. Also, it is important tomention that with the new pairing < #, 201 > of the accessed block, thealgorithm is capable to place it on the node 101 because at that depth theold path P (202) and the new P (201) converge, so the block can be saved onthe cloud. If, for instance, the new path was P (204), the only common nodewould be the root 001.

3.4 Complexity

The time and memory complexity are fundamental parameters for com-parisons among algorithms. Also they show clearly the costs and the neededresources to run properly the algorithm. In particular, the complexity dis-cussion is subdivided between the client and the server side.

• Stash (client): this structure has a worst case memory complexity ofO(log(N)·B) and a time complexity for a search of O(log(N)) where Ndenote the number of blocks in stash. It is important to mention thatthe stash is a data structure that continuously change its dimensiondue to its nature.

• Position: it is a map function pairing blocks identifiers and leaf iden-tifiers < idb, x >. It has a size complexity of O(N) · Ω(bid + x) anda time complexity of O(log(N)). This mapping function has a fixedmaximum dimension O((2L+1 − 1) · B) · Ω(bid + x) when the binary

36


tree is used at its maximum capabilities.

• Cloud: it has size complexity equal to O(2L+1 − 1) · Ω(node). Thetime complexity is equal to O(log(N)) or it can be also seen as O(H)

because the cloud is a perfect binary tree.

• Packet Size: the packet dimension travelling through the network isΩ(node) = Ω(idnode + idleftNode + idrightNode +B ·Ω(block)). A blockis Ω(block) = Ω(idb + data).




The data confidentiality and the data integrity are guaranteed byan AES cypher. It was chosen to use a security key of 16Byte and a CypherBlock Chaining (CBC) encryption mode. This cypher modality, Figure 2.8,hides the content partitioning it into fragments of the same length as thekey. The first fragment is xored with an Initialization Vector (IV) and thenencrypted. Each subsequent fragment is encrypted after being xored withthe previously encrypted fragment.The Access confidentiality and the Pattern confidentiality are guar-anteed by the way in which the blocks are paired with the leaf identifiers.In fact, each time the algorithm requests a block, the association < idb, x >

37


is changed. The new leaf identifier is chosen uniformly at random among2L leaves present in the tree. This means that the next time the block isuploaded into the cloud, its position will be along a new random leaf path.Also, the height at which the block is placed is not predictable making anyintersection attack infeasible.It is also important to describe why the stash doesn’t grow out of all pro-portion. It is possible to assert that all the blocks are paired with a leafuniformly at random. This means that the client accesses uniformly at ran-dom the cloud because every time he reads a different path from the rootto a leaf. This happens even if the client continuously researches the sameblock because its < idb, x > changes constantly. At the same time, it isimpossible that the stash goes out of control because each path is read andrefreshed uniformly at random, so it is possible to find an intersection nodewhere a stash block can be placed over multiple accesses.

38

Chapter 4

Ring Oram

Ring Oram [4] is an advanced version of Path Oram. It was proposedfor the first time during the 24th USENIX Security Symposium in Wash-ington DC in 2015. The differences between Path Oram and Ring Oramare significant and all of them have a unique goal: reducing the bandwidth.In fact many Oram algorithms require a great amount of resources to runand this is one of their drawback because it makes them unaffordable. So,the authors of Ring Oram worked on the efficiency and the cost reduction ofPath Oram and pushed forward the state of the art of this protocol. The newalgorithm has a 2.3x to 4x bandwidth reduction, as claimed by the authors.This kind of result is achieved using little stratagems that together make asubstantial difference. During the detailed explanation of Ring Oram, all ofthe new solutions will be made clear and pointed out.

4.1 Structure of Ring Oram

The main structure of Ring Oram is a perfect binary-tree (complete andbalanced) with a height H and 2H − 1 nodes. The tree can be subdivided inlevels that are numbered from 0 to L, where 0 is the root level and L = H−1

is the leaf level. It is a very simple and organized structure, easy to build,to maintain and that has useful properties. The binary tree is composed ofnodes inside which is placed a bucket.

Definition1.1 (Binary tree) : The binary tree of height H is formed by2H − 1 nodes, each one of them is characterized by < idi, b >, where idi is

39

CHAPTER 4. Ring Oram

the node identifier having i ∈ [0, 2H − 2] and b is a bucket.

Definition1.2 (Bucket) : Let Blocks[Z + S] be a vector of dimensionB = Z + S filled with blocks. Z represents the number of potential realblocks per bucket, while S are dummy blocks.

Definition1.3 (Block) : Let < z > be a of block of the tree, where zis the encrypted information. The field z is obtained by applying z =

Ek(info||randomPad), with E a symmetric encryption function, k the en-cryption key, randomPad a value chosen at random during the encryption.

Also, inside a node, there are the following variables:

• Count: it is a counter of how many times a node is accessed. Itis useful for a new security feature of the algorithm. In the TheorySection is described its application.

• Valids[Z + S]: it is a vector that represents the validity of each block(real and dummy ones).

• Metadata: it is a memory section containing multiple variables. It isused by Ring Oram for bandwidth usage reduction and for choosingprecisely which block to pick up from a node in the cloud.

– Addrs[Z + S] : every block needs to be identified with a key ∈[0, (Z+S) · (2H − 2)] (or address) and this vector contains all theidentifiers of the blocks inside the bucket. The key in position i(i ∈ [0, Z + S)) is the identifier of the block placed in the nodeBlocks[i] vector.

– Ptrs[Z] : this vector represents the position of the (potentially)Z real blocks inside the vector Blocks[Z + S] of the node. Infact, the positions of real and dummy blocks in a node bucket israndomized and the Ptrs vector saves where are placed the realones. The implementation of this shuffling feature is explained inthe Theory Section.

– Leafs[Z + S] : in this vector are placed the leaf labels for all theblocks in the bucket.

40

4.1. Structure of Ring Oram

• Blocks[Z + S]: here are placed all the real and dummy blocks storedin the node. Each block is composed by:

– data : in this field is saved the real content to be stored in thecloud.

– randomPad : this field is important for security reasons. It iscreated totally at random before a block is saved on the cloud.This guarantees not to have the same kind of encryption for thesame block.

• idNode: it is the identifier of the node in the cloud.

• idLeftNode: it is the identifier of the left child.

• idRightNode: it is the identifier of the right child.

For a correct functioning of the algorithm, all the blocks are paired with aleaf identifier. In fact, as in Path Oram, the two data structures positionand stash are still present. They maintain their role in the algorithm butthere are little changes:

• Stash: the purpose of the stash is to collect all the blocks that cannotbe saved on the cloud. This occurrence can happen some times duringthe normal procedures of access to the server and it is demonstratedthat the worst-case size is O(log(N) · Ω(stashElem)) [4]. The Stashcontains a variable number of < idb, stashElem > elements. ThestashElem is a new data structure useful for saving all the importantinformation of a block. In fact, due to different requirements, it isnecessary to save in stash the block identifier idb, the block informationdata and the leaf identifier leaf associated to the block.So stashElem has the following fields:

– data: variable where is stored the useful information of a block.

– addr: variable where is stored the block identifier.

– leaf : variable where is stored the leaf identifier.

• Position map: In the client, all the pairs of < idb, l > are storedwhere l is a leaf identifier of the tree and idb is a block identifier. This

41


mapping function is used during the searching process to retrieve theposition of a specific block. Every block, if not in stash, must bepresent in one of the nodes along the path P (x).

4.2 Theory of Ring Oram

Before going into the details of the algorithm, it is useful to point out allthe main variables and functions that are involved in Ring Oram. In table1 is shown a summary.

N Number of real data blocks in ORAM

H Height of the ORAM tree

L Leaf level of the ORAM tree

Z Maximum number of real blocks per bucket

S Number of slots reserved for dummies per bucket

B Total number of blocks per bucket

K Data block size (in bits)

A Eviction rate (larger means less frequent)

P (l) Path to reach leaf l

P (x, i) The i-th node identifier (towards the root) on P (l)

P (x, i, j) The decrypted j-th block in node P (l, i)

Table 4.1: Table of the main variables

The algorithm starts initializing all the binary tree nodes with dummyblocks, but before being placed in the cloud, the nodes must be encrypted.Not all the components of the node need to be cyphered and there are twomain reasons for this: first, some information inside the variables are eas-ily retrieved/calculated by the server; second, it is simply meaningless andcostly.So, each node component is encrypted (or not) following the scheme below:

• Count (clear): this counter is an information easily retrievable by theserver because it represents how many times a node is accessed sinceits creation. Also this information does not represent a threat for theprotocol.

42

4.2. Theory of Ring Oram

• Valids[Z +S] (clear): it is a vector of auxiliary information necessaryto the algorithm. If the server knows if a block is valid or not does notrepresent a threat. In fact, even if Ring Oram conceals this information,the server will understand that, after a block access, the protocol wouldnot re-access to the same block until a node refresh.

• Metadata (cyphered): this component of the node contains vital in-formation for Ring Oram so it must be encrypted. The metadatadescribes exactly the shape of a node, which part contains useful in-formation and which contains dummy blocks.

• Blocks[Bucket] (cyphered): this part contains dummy and real blocks.It is fundamental to encrypt all this memory area because it is wherethe client’s contents are stored.

• idNode (clear): it is a variable related to the cloud structure. Thenodes inside the binary-tree are fixed in a specific positions so it isuseless to encrypt their identifiers.

• idLeftNode (clear): it is a child identifier so it is left as it is.

• idRightNode (clear): it is a child identifier so it is left as it is.

43


4.2.1 Access Function

The next phase of the Ring Oram explanation is a detailed description ofthe Access function. It is the fundamental client’s function for downloadingand uploading data from the cloud.Algorithm 4.2.1: Non-recursive Ring ORAM.

1 Function Access(op,a,data′)2 Global/persistent variables: round

3 l′ ← UniformRandom(0,2L − 1)4 l← PositionMap[a]5 PositionMap[a]← l′

6 data← ReadPath(l, a)7 if data=⊥ then8 . If block a is not found on path l, it must be in Stash /9 data← read and remove a from Stash

10 if op=read then11 data′ ← data

12 if op=write then13 data← data′

14 Stash← Stash⋃

(a, l′, data)

15 round← round +1 modA16 if round = 0 then17 EvictPath()

18 EarlyReshuffle(l)

The function has a global/persistent variable called round. Its purposeis to count how many times the Access function is called after a EvictPathprocedure was performed and it is a client’s variable. There are three pa-rameters that characterize the Access function:

• op: this variable defines the operation wanted by the client, so basicallyit specifies if it is a read or write operation.

• a: it is the block identifier requested by the client.

• data′: it is the new data to write on the cloud. In a read operation

44


this parameter has the purpose to return the requested block to theclient, the block with identifier a.

The procedure to access to the cloud can be summarized in nine main steps:

1. New leaf (line 3): it is generated a new leaf identifier l’ employed forremapping the requested block a (line 5).

2. Leaf retrieve (line 4): it is retrieved the leaf identifier associated withthe a block. This information is obtained using the mapping functionPositionMap.

3. Remap block (line 5): here it is saved the new pairing between thea block identifier and the new leaf l’.

4. Read path (line 6): the ReadPath function will return a decryptedblock. It could be the a block or a dummy block. The detailed expla-nation of the ReadPath is in Algorithms 4.2.2.

5. Check block (lines 6 to 9): if the obtained block from ReadPath is adummy one, this implies that the a block must be in stash and it isretrieved from it.

6. Check Operation (lines 10 to 13): at this point, the algorithm hasthe a block saved in the data variable. In case of a read operation,the Access function handles the storage of the a block inside the data’variable. Otherwise the content of the retrieved block is overwrittenwith data’.

7. Save in stash (line 14): the a block is saved into the stash.

8. Rounding (lines 15 to 17): the statical variable round maintains theinformation of how many times the client has accessed the cloud. Everytime round is a multiple of A, the algorithm performs a security taskwith the purpose to reshuffle all the blocks on a path (from the root toa leaf). The A parameter is chosen by the client (see Table 4.1). Thedetails of the EvictPath operation are shown in Algorithm 4.2.4.

9. EarlyReshuffle (line 18): this function has the purpose to check if thenodes along path P (l) have an access counter equal to or higher than

45


the value S. In this case, the bucket of each of these nodes is reshuffled.The details of this operation are shown in Algorithm 4.2.7.

4.2.2 ReadPath Function

The first auxiliary function to examine is ReadPath. As its name suggests,ReadPath is the real perpetrator that reads L + 1 blocks along a path. Infact, its result is the a block to retrieve or a dummy block in case a is noton the server. The following algorithm shows, in an academical way, howthe researched block is retrieve. The reason for this choice is because it iseasier to understand the procedure if the important steps are pointed outsingularly. In the real implementation, the client prepares a list of neededinformation to send to the server instead of asking for single data each time.The two implementation have the same result, but the performances aredifferent.Algorithm 4.2.2: ReadPath procedure.

1 Function ReadPath(l,a)2 data←⊥3 for i← 0 to L do4 valids ← GetValids(P (l, i)) . Network communication

5 meta ← GetMetadata(P (l, i)) . Network communication

6 offset ← GetBlockOffset(meta,valids,a)

7 data’← P (l, i,offset) . Network communication

8 Invalidate P (l, i,offset) . Server side

9 P (l, i).count ← P (l, i).count+1 . Server side

10 if data′ 6=⊥ then11 data← data′

12 return data

There are two parameters that characterize the ReadPath function:

• l: this leaf identifier is useful to describe in which path the blocks mustbe retrieved.


The procedure of block retrieving can be resumed in three main steps:

46


1. Data initialization (line 2): data is the variable that will contain theresult of this operation. It is initialized with a dummy block (⊥). Incase the a block is found during the process, data will be rewrittenwith the a content.

2. Read a path (lines 3 to 11): for all the nodes on path l:

(a) GetValids (line 4): it is a function that reads the valids vector ofthe node specified by P (l, i). A network communication betweenthe client and the server takes place.

(b) GetMetadata (line 5): it is a function that reads and decryptsthe metadata of the node specified by P (l, i). A network commu-nication between the client and the server takes place.

(c) GetBlockOffset (line 6): the function returns the offset of ablock inside the node bucket. If a is in the bucket, its offset isreturned, otherwise a random dummy block offset is. The blockpointed by the offset must be a valid one, see Algorithm 4.2.3 formore details.

(d) Get block (line 7): P (l, i,offset) returns the decrypted block onpath l, at depth i, placed in the node bucket at position offset.The function also sets as invalid the retrieved block and incre-ments the access counter of the accessed node. A network com-munication between the client and the server takes place.

(e) Block invalidation(Server side) (line 8): This operation is per-formed by the server when the block P (l, i, offset) is sent to theclient. So there isn’t a real client request of invalidation becauseit is implied in the request of a block.

(f) Increment of the counter(Server side) (line 9): This operationis performed by the server when the block P (l, i, offset) is sentto the client. In fact, the counter has the exact purpose to counthow many times a node is accessed for reading a block. So thereisn’t a real client request for the increment of counter because itis implied in the request of a block.

(g) Check block (lines 10 to 11): if the obtained block is not adummy one, data is rewritten with data′ that has the meaningful

47


content.

3. Return (line 12): the function returns the computated block.

In the real implementation, all the valids and metadata of the nodes alongthe path P (l) are retrieved in a single request. Then, the client processesthese data and prepare a list of blocks to read from the cloud. Another singlerequest is performed and the H needed blocks are received from the serverin a single time. After that, the client performs the checks on the blocks andpicks up the needed one, if present.

GetBlockOffset Function

GetBlockOffset is an auxiliary function for ReadPath and it has the taskof choosing which block will be read.Algorithm 4.2.3: GetBlockOffset procedure.

1 Function GetBlockOffset(meta,valids,a)2 for j ← 0 to Z − 1 do3 ptr ← meta.ptrs[j]

4 if a = meta.addrs[ptr] and valids[ptr] then5 . offset of interest /6 return ptr

7 return a pointer to a random valid dummy

There are three parameters that characterize the GetBlockOffset func-tion:

• meta: it is the decrypted metadata of a node. Inside of it are placedall the relevant content information.

• valids: vector of valid blocks inside the node bucket.


What is done in this function is scanning all the real valid blocks insidethe bucket of a node. In other Oram machines it usually happens that thealgorithms are forced to download the entire bucket to pick the right block.This is very costly in terms of bandwidth. Conversely, Ring Oram uses alighter package full of useful information for the block selection. In fact,

48


the algorithm checks for at most Z times (the exact number of potentialreal blocks in a bucket) if the valid real block identifiers match with a (a =

meta.addrs[ptr] and valids[ptr]). The algorithm takes advantage of thevector of real block pointers meta.ptrs[] to check the right identifiers. Incase there is no positive match (a is not here), the function returns a randomvalid dummy position.

4.2.3 EvictPath Function

The EvictPath function purpose is to maintain the information in thecloud secure and this subroutine is triggered statically by the algorithm. Itstask is to reshuffle all the blocks inside a path that is chosen in a deterministicway.Note that, as for the ReadPath function, the EvictPath procedure shownis the academical one.Algorithm 4.2.4: EvictPath procedure.

1 Function EvictPath2 Global/persistent variables G initialized to 03 l′ ← G mod 2L

4 G← G+ 1

5 for i← 0 to L do6 . A bucket is read from the cloud and added to the stash /7 Stash ← Stash

⋃ReadBucket(P (l, i))

8 for i← L to 0 do9 . A new bucket is created and uploaded into the cloud /

10 WriteBucket(P (l, i),Stash)

The global/persistent G variable has the purpose to select which pathis reshuffled during the EvictPath procedure and it is nod destroyed at theend of the function. Note that this variable is saved on the client side.The function needs no parameters so it possible to skip directly to the ex-planation of the pseudo-code. The main steps of EvictPath are three:

• Choose path (lines 3 to 4): the function deterministically chooseswhich path to follow using the persistent variable G. Each time thefunction is employed, G is incremented by one. So, at the first exe-cution, EvictPath will reshuffle the path l′ = 0, the next time l′ = 1,

49


until l = 2L − 1, then it will restart from l′ = 0.

• Read all buckets (lines 5 to 7): starting from the root to the leaf l′,each real valid block belonging to the path P (l′) is read and saved inthe stash. The implementation of ReadBucket is in Algorithm 4.2.5.

• Write all buckets(lines 8 to 10): starting from the leaf l′ to theroot, each node belonging to the path P (l′) is completely rewrittenusing blocks inside the stash. The implementation of WriteBucket isin Algorithm 4.2.6.

The real implementation of this function differ from this one in how areperformed the reads and the writes of the buckets. In fact, all the blocks areread in a unique request and all the written nodes are uploaded on the cloudin another single communication.

50


ReadBucket Function

ReadBucket is the first of the two auxiliary functions used in theEvictPath subroutine. As it is possible to imagine by reading the functionname, the purpose of this procedure is to read the real valid blocks of a node.However it is not so easy and immediate as one could think.Algorithm 4.2.5: ReadBucket procedure.

1 Function ReadBucket (n)

2 valids ← GetValids(n) . Network communication

3 meta ← GetMetadata(n) . Network communication

4 . Counter for the # of real block read /5 z ← 0

6 for j ← 0 to Z − 1 do7 ptr ← meta.ptrs[j]8 if valids[ptr] then9 . The block is downloaded from the cloud /

10 data’← P (l, i,offset) . Network communication

11 z ← z + 1

12 if addrs[j] 6=⊥ then13 Stash← Stash

⋃(addrs[ptr],leafs[j],data′)

14 for j ← z to Z − 1 do15 . dummyOffset 6∈ meta.ptrs & valids[dummyOffset] = true /16 P (l, i,dummyOffset) . Network communication

The unique parameter of the function is n, the node identifier. Read-Bucket can be summarized in five steps:

1. GetValids (line 2): it is a function that reads the valids vector of then node. A network communication between the client and the servertakes place.

2. GetMetadata (line 3): it is a function that reads and decrypts themetadata of the n node. A network communication between the clientand the server takes place.

3. The counter (line 5): z will represent the number of potential realblocks that are read in the first cycle. It is important because the

51


algorithm must read Z blocks from each bucket, otherwise reading lessblocks will reveal the internal status of the node (some potential realblocks can be invalid).

4. Read a bucket (lines 6 to 13): for Z times:

(a) Read a block (lines 7 to 10): using the pointers to the potentialreal blocks and the valids vector, the algorithm reads all thevalid potential real blocks. The reads counter is incremented (z ←z+1). The blocks are downloaded using the P (l, i,offset) functionthat makes the network request and decrypts the received block.

(b) Check block (lines 12 to 13): if the read block is not a dummyone, it is saved into the stash. It is important to remember thatless than Z real blocks could be saved in a bucket, so it is manda-tory to check the content before saving it into the stash.

5. Final reads (lines 14 to 16): if less than Z blocks are read (becausemany were no longer valid) the algorithm reads Z − z valid dummyblocks to maintain an indistinguishable behaviour.

52


WriteBucket Function

WriteBucket is another auxiliary function and its task is to rewrite anentire node. This implies also the creation/rewriting of the metadata relatedto the node and of the other additional variables essential for the correctoperation of Ring Oram.Algorithm 4.2.6: WriteBucket procedure.

1 Function WriteBucket (a,Stash)2 . Find up to Z blocks from Stash that can reside in this node n

and save the information in the vectors data′, addrs and leafs /

3 FindBlocks(a,Stash,data′,addrs,leafs)

4 . New random pointers for real blocks positions /5 ptrs ← PRT(0,Z + S − 1)6 . Counter for the # of real block inserted /7 z ← 0

8 for j ← 0 to Z − 1 do9 blocks[ptrs[j]]← data′[j]

10 meta.addrs[ptrs[j]] = addrs[j]11 meta.leafs[ptrs[j]] = leafs[j]12 z ← z + 1

13 Fill the rest of the (Z + S − z) free positions in the blocks vectorwith dummy blocks and update the metadata

14 valids← 1Z+S

15 count← 0

16 encrypt meta, blocks

17 . Save metadata and blocks on cloud, there is a network dataexchange /

18 WriteNode(n,count,valids,meta,blocks)

The two function parameters are:

• a : it is the node identifier to be rewritten.

• Stash: it is the stash, where it is possible to retrieve all the blockspresent on client side.

WriteBucket can be summarized in four steps:

53


1. Find blocks (line 3): in stash are present all the downloaded blocksfrom the cloud. Using this data structure it is possible to retrieve allthe possible blocks that can be saved on a. Also it is possible to obtainthe relative auxiliary variables of a block such as the addr (identifierblock) and the leaf with which is paired. So the function FindBlockshas the task to fill the vectors data′, addrs and leafs with the correctinformation.

2. Pointer randomization (line 5): it is necessary to create new Z

pointers for the real blocks. Each pointer must be different from theothers and holds ptr ∈ [0, Z + S − 1].

3. Node creation (lines 8 to 15): the new node bucket is filled with theretrieved blocks from the stash. The remaining (Z + S − z) positionsinside the node bucket are filled up with dummy blocks. Consequently,all the auxiliary information of the node is set correctly. It is importantto understand that the new leaf remapping feature of Access (line 5)takes place here. All the blocks as set as valid (line 14) and the counteris set to zero (line 15).

4. Encryption and Send (lines 16 to 18): The blocks vector is encryptedas for the metadata. Then the node is saved on the cloud. A networkcommunication between the client and the server takes place.

4.2.4 EarlyReshuffle Function

The EarlyReshuffle procedure is performed every time before the end ofthe Access function. Its main task is to reshuffle nodes with a too high accesscounter.

Algorithm 4.2.7: EarlyReshuffle procedure.

1 Function EarlyReshuffle(l)2 for i← 0 to L do3 if P(l,i).count ≥ S then4 . in both operation there is a network communication/5 Stash ← Stash

⋃ReadBucket(P (l.i))

6 WriteBucket(P (l.i),Stash)

54


There is only one parameter for the EarlyReshuffle function:

• l: this is the leaf identifier used to describe the path P (l) to check.

The function can be summarized:

• Check path (lines 2 to 6): for all the nodes on path P (l) with a nodeaccess counter equal to or greater than the number of dummy blocksinside a bucket (S), then :

– ReadBucket (line 5): all the real valid blocks are read and savedinto the stash.

– Refresh node (line 6): the entire node bucket is rewritten usingblocks inside the stash. Also, all the auxiliary variables like valids,counter and the metadata are generated accordingly to the newinserted data. A more detailed explanation of the WriteBucketfunction can be found in Algorithm 4.2.6.

55



After the definition and explanation parts, it is the moment to see howRing Oram really works and in what it differs from the other algorithms.Figure 4.1 shows an example of the structures on the client and the serverside. For convenience, dummy blocks are represented by @ and invalid blocksby −. It is also supposed to have Z = 3 slots for real blocks, S = 1, A = 2

, round = 1 and G = 3. The access counters are represented by c variablesaside each node.

Figure 4.1: Ring Oram tree

Note that nodes 201, 203 have two dummy blocks each. It is not anerror, but a possible node state because Z represents the maximum numberof real blocks per bucket and not a constraint.The simulation presumes a write operation on the block R, therefore thesteps to retrieve the content are:

• Access function: the function prototype will be

Access(”writeop”, aR, ”#”).

• Retrieve and remap: The algorithm generates a new leaf identifier l′

to remap the aR block, but before applying the pairing change, the ac-tual leaf is retrieved l← position[aR]. In this case l← position[aR] =

202 and l′ ← 201.

56


• ReadPath: the client will read two random valid dummy blocks fromnodes 001, 101 and the requested aR block from 202. Note in Figure4.2 that all the read blocks are now invalid on server side and thecounters of the used nodes are incremented.

• Operation: in this example the operation chosen is a write one, there-fore the content of aR is rewritten using data′ = # and the result isplaced in stash. The new client and server states are represented inFigure 4.2.

Figure 4.2: ROram tree after aR research

• EvictPath: the EvictPath operation is triggered because round isequal to zero after the increment and the modulo operation. G = 3

so l′ ← 3. To be consistent with the leaf indexes of the example, itis needed to add 101 to l′ to have a correct matching, so l′ ← 204.During the procedure is computated a new G and its new value isG = (G + 1)mod2L = (3 + 1)mod4 = 0. The supposed final result isshown in Figure 4.3.

57


Figure 4.3: ROram tree after EvictPath function

• EarlyReashuffle: the EarlyReshuffle operation is applied on the pathl = 202. The nodes that have a too high counter are 101, 202 so theymust be reshuffled. A possible final result is illustrated in Figure 4.4.

Figure 4.4: ROram tree after EarlyReshufle function

58

4.4. Complexity

4.4 Complexity

Binary research trees are a very powerful data structure because theyallow fast lookup, addition and removal of items inside nodes. Also, for theOram usage, we are in the case of a perfect binary tree, a balanced andcomplete one. In fact this type of memory design guarantees very powerfulproperties for complexity research. One of them is how it is possible touse the identifier of a leaf to discriminate which path follow to reach it.For example, in a balanced binary tree of height H, level numbered from0 to L = H − 1 and there are 2L leaves. If the leaves are numbered leftto right from 0 to 2L − 1, the following property holds: starting from theless significant bit of the identifier, the path will go right at every bit one,otherwise at every bit zero it will go left until a leaf is reached. This operationconsists of a shift of n positions of the identifier plus a single bit ANDoperation. On computers, this task is faster than an exponential powerconfrontation and this optimization can speed up the algorithm significantly.Now it will be analysed the main data-structures in Ring Oram in terms ofspace and time complexity:

• Stash (client): this structure has a worst case memory complexity ofO(log(N)) · Ω(bid, stashElem) and a time complexity for a search ofO(log(N)). N denotes the number of blocks in stash. It is importantto mention that the stash is a data structure that continuously changesits dimension due to its nature.

• Position (client): it is a map function pairing blocks identifiers andleaf identifiers < idb, l >. Each element has a size complexity Ω(bid, l)

and a time complexity of O(log(N)), where N is the number of realblocks saved in the cloud. This mapping function has a maximumdimension Z · (2L+1 − 1) ·Ω(bid, l) when the binary tree is used at itsmaximum capabilities.

• Cloud: size (2L+1 − 1) · Ω(node) time complexity O(log(N)).

• Metadata Packet Size: the packets dimension travelling through thenetwork is Ω(valids[Z + S], addrs[Z + S], leafs[Z + S], ptrs[Z]).

• Counter Packet Size: the packets dimension travelling through the

59


network is Ω(counter).

• Block Packet Size: the packets dimension travelling through thenetwork is Ω(block) = Ω(z) = K.




The data confidentiality and the data integrity are guaranteed byan AES cypher. It was chosen to use a security key of 16Byte and a CypherBlock Chaining (CBC) encryption mode. This cypher modality, Figure 2.8,hides the content partitioning it into fragments of the same length as thekey. The first fragment is xored with an Initialization Vector (IV) and thenencrypted. Each subsequent fragment is encrypted after being xored withthe previously encrypted fragment.The Access confidentiality and the Pattern confidentiality are guar-anteed by the way in which the blocks are paired with the leaf identifiers.In fact, each time the algorithm requests a block, the association < idb, l >

is changed. The new leaf identifier is chosen uniformly at random among2L leaves present in the tree. This means that the next time the block isuploaded into the cloud, its position will be along a new random leaf path.Also, the height at which the block is placed is not predictable making any

60


intersection attack infeasible.It is also important to describe why the stash doesn’t grow out of all pro-portion. It is possible to assert that all the blocks are paired with a leafuniformly at random. This means that the client accesses uniformly at ran-dom the cloud because every time he reads a different path from the root to aleaf. This happens even if the client continuously researches the same blockbecause its < idb, l > changes constantly. At the same time, it is impossiblethat the stash goes out of control because each path is read and refresheduniformly at random, so it is possible to find an intersection node where astash block can be placed over multiple accesses.

61


62

Chapter 5

Xor Ring Oram

This is the last Oram machine presented in this thesis. As expressed inthe title, it is still a Ring Oram machine, but with a major difference in howblocks are sent through Internet. This new feature has the potentiality todrastically reduce the total bandwidth used by the algorithm. But to makethis possible, it is necessary to modify some data structures of the binarytree, how the encryption works and how the client dialogues with the server.Without further hesitation, the new feature is the Xor technique [5] and ittakes place in the ReadPath function, from that the new function name isReadXorPath. The tree structure isn’t changed, so the tree levels are stillnumbered from 0 to L = H − 1, where 0 is the root level and L is the leaflevel. Using ReadXorPath, the client still asks for H blocks, but it will re-ceive a unique block that is obtained by xoring all the H requested blocks.This permits XRing Oram [4] to save bandwidth and to reduce the networklatencies because less quantity of data are transferred. In the next part ofthe XRing Oram explanation it is possible to learn how the new feature isimplemented and in which condition it is possible to employ the new trick.To avoid useless concepts repetitions, in all the sections of the XRing Oramare described the differences and the modifications between this machine andthe classic Ring Oram one. Without further hesitation, the analysis of thealgorithm can begin from the theory part, instead of the structural one. Thereason of this is because it is easier to understand the data structure modi-fication if we have in mind the new ReadXorPath functional requirements.

63

CHAPTER 5. Xor Ring Oram

5.1 Theory of XRing Oram

The new challenge of XRing Oram is to create a new data protocol be-tween the client and the server that permits:

1. the server to send a unique block data packet through Internet.

2. the client to receive a unique block and still retrieve the requestedinformation.

In the ReadXorPath procedure, the client still wants to retrieve the a block,so he requests, for H times, the metadata of a node, then he chooses whichblock to read and then obtains it. The H requests can be H − 1 fake blocksplus a real one, otherwise they are all fake because the needed block is notin cloud. This information is crucial for the further analysis, so it must bekept in mind.With the Xor trick, the server expects to receive H blocks requests so toperform b0 ⊕ ... ⊕ bH−1. Then it sends the xor result to the client. Theclient knows that brec ← ba ⊕ bdummies, where ba is the block that the clientwants, bdummies is the xor result of H − 1 encrypted dummy blocks and brecis the result of the xoring technique, performed by the server, that the clientreceives.After this new information, it is possible to see the ReadXorPath implemen-tation.

64

5.1. Theory of XRing Oram

5.1.1 ReadXorPath Function

As for ReadPath, the goal of ReadXorPath is to retrieve the requested ablock from the cloud, if present, otherwise it returns a dummy block. So,from the Access function point of view, the two "readpath" procedures areidentical.Algorithm 5.1.1: ReadXorPath procedure.

1 Function ReadXorPath(l,a)2 data←⊥3 depthBlock ← −1

4 for i← 0 to L do5 nodeIds ← P (l, i)

6 valids ← GetValids(P (l, i)) . Network communication

7 meta ← GetMetadata(P (l, i)) . Network communication

8 offsets ← GetBlockOffset(meta,valids,a)9 if meta.adds[offsets[i]] = a then

10 depthBlock ← i

11 . The client sends a list of blocks to read to the server /12 data’← ReadXoredBlocks(nodeIds,offsets,ivs)

13 if depthBlock 6= −1 then14 for j ← 0 to L do15 if j 6= depthBlock then16 dummy ←⊥17 dummy ← Encrypt(dummy,ivs[j])18 data’ ← data’ ⊕ dummy19 data ← Decrypt(data’,ivs[depthFound])

20 return data

There are two parameters that characterize the ReadXorPath function:

• l: this leaf identifier describes in which path the function performs theresearch.


The procedure of block retrieving can be resumed in five main steps:

65


1. Data initialization (lines 2 to 3): data is the variable that will containthe result of this operation. It is initialized with a dummy block (⊥).In case the a block is found during the process, data will be rewrittenwith the a content. The depthBlock variable will contain the depth ofthe requested block (if found), otherwise it will contain -1. It is alsoused as discriminator for the decryption phase.

2. Read auxiliary data (lines 4 to 10): for all the nodes on the path l:

(a) Save identifiers (line 5): the node identifiers along the path P (l)

are saved in the vector nodeIds because they will be sent to theserver all at once.

(b) GetValids (line 6): it is a function that reads the valids vector ofthe node specified by P (l, i). A network communication betweenthe client and the server takes place.

(c) GetMetadata (line 7): it is a function that reads and decryptsthe metadata of the node specified by P (l, i). A network commu-nication between the client and the server takes place.

(d) GetBlockOffset (line 8): the function returns the offset of avalid block inside the bucket node. If a is in the bucket, its offsetis returned, otherwise a random valid dummy block offset is. Theoffset is saved in the vector offsets because they will be sent tothe server all at once.

(e) Check block (lines 9 to 10): using the metadata it is possible tocheck if the a block is present inside the node. If it is found, itsdepth is saved inside the depthBlock variable. This functionalitycan be implemented inside the GetBlockOffset function, but hereis made explicit to highlight it.

3. ReadXoredBlocks (line 12): this auxiliary function has the purposeto send the list of node identifiers (nodeIds) and the relative blockoffsets (offsets) to the server. This makes the correct selection ofblocks along path P (l) possible and it enables the server to apply thexor technique. ReadXoredBlocks will place the brec in data′ and it willfill the ivs vector with the initialization vectors sent by the server. Themeaning of this new vector will be made clear in the Dummy Blocks

66


Property Section. On server side, the counter of all the accessed nodesis incremented and all the read blocks are invalidated.

4. Decryption of brec (lines 13 to 19): if the a block is present alongthe path P (l), depthBlock must contain its location depth and so thedecryption procedure can have place, otherwise it is skipped and thealgorithm goes to line 20.

(a) Retrieve of a (lines 14 to 19): for L−1 times, the algorithm cre-ates an encrypted dummy block dummy using each time a differ-ent initialization vector sent by the server. Then dummy is xoredwith data′. After that, data′ will contain only the encrypted ver-sion of ba that is possible to retrieve usingDecrypt(data′, ivs[depthFound]),the result is assigned to data.

5. Return (line 20): the data variable is returned.

5.1.2 Dummy Blocks Property

The use of the Xor technique implies that the client has the capabilityand/or the information to rebuild the dummy blocks. If this condition doesnot hold, it is impossible to retrieve the ba from brec. In Ring Oram, arandom pad is the component of each block, but memorizing this field ofeach block on client side is too expensive. So it is necessary to eliminatethe random pad. The problem persists if the data field of dummy blocks isstill random. So, the client has to create dummy blocks with a deterministicprocedure. To do so there are two ways, the first one is to adopt a fixeddummy and use it every time, the second one is to fix the assigned valueof the dummy data field. Now the Xor technique is feasible, but there is abig security flaw: the server clearly distinguishes the real blocks from thedummy ones because they are always the same. It is a dog chasing its owntail.The solution to this problem is to encrypt each block, dummy and real, ina different way without having a random field inside the variable. This isthe exact purpose of the initialization vectors introduced in XRing Oram.In fact, each time the client has to save a block in cloud, it creates a randomiv for his strong symmetric cypher, then he encrypts the block with the iv

67


and his fixed encryption key. Now the client can store the cyphered blockand the iv in cloud because the server cannot retrieve the information usingthe iv. With this technique, the client can employ the Xor trick and savebandwidth without increasing the memory used.The XRing Oram algorithm has some minor modifications in some functionsdue to its new protocol. The new encryption method requires that theEncryption, Decryption, ReadBucket procedures must be adapted. In factthese functions have to manage the blocks and the initialization vectors. Thefunctions have the new task of using the right iv for the corresponding block.The first two has a new variable passed thought their prototype otherwise theencryption/decryption does not work. The third function has the additionaltask to download the initialization vectors of the read blocks.

68


5.1.3 WriteBucket Function

WriteBucket is an auxiliary function of the XRing Oram algorithm thathas the purpose to generate and save a node into the cloud. Due to the newcryptographic requirements there are some modification inside the function.Algorithm 5.1.2: WriteBucket procedure.

1 Function WriteBucket (a,Stash)2 . Find up to Z blocks from Stash that can reside in this node n

and save the information in the vectors data′, addrs and leafs /

3 FindBlocks(a,Stash,data′,addrs,leafs)

4 . New random pointers for real blocks positions /5 ptrs ← PRT(0,Z + S − 1)6 . Counter for the # of real block inserted /7 z ← 0

8 for j ← 0 to Z − 1 do9 blocks[ptrs[j]]← data′[j]

10 meta.addrs[ptrs[j]] = addrs[j]11 meta.leafs[ptrs[j]] = leafs[j]12 z ← z + 1

13 Fill the rest of the (Z + S − z) free positions in the blocks vectorwith dummy blocks and update the metadata

14 valids← 1Z+S

15 count← 0

16 . Blocks encryption with new initialization vectors /17 for j ← 0 to Z + S − 1 do18 ivs[j] = GenIv()19 Encryption(blocks[j],ivs[j])

20 Encryption(meta)

21 . Save the node on cloud, there is a network data exchange /22 WriteNode(n,count,valids,meta,ivs,blocks)

The two function parameters are:

• a : it is the node identifier to be rewritten.

• Stash: it is the stash, where it is possible to retrieve all the blocks

69


present on client side.

WriteBucket can be summarized in six steps:

1. Find blocks (line 3): in stash are present all the downloaded blocksfrom the cloud. Using this data structure it is possible to retrieve allthe possible blocks that can be saved on a. Also it is possible to obtainthe relative auxiliary variables of a block such as the addr (identifierblock) and the leaf with which is paired. So the function FindBlockshas the task to fill the vectors data′, addrs and leafs with the correctinformation.

2. Pointer randomization (line 5): it is necessary to create new Z

pointers for the real blocks. Each pointer must be different from theothers and hold ptr ∈ [0, Z + S − 1].

3. Node creation (lines 8 to 15): the new node bucket is filled with theretrieved blocks from the stash. The remaining (Z + S − z) positionsinside the node bucket are filled up with dummy blocks. Consequently,all the auxiliary information of the node is set correctly. It is importantto understand that the new leaf remapping feature of Access (line 5)takes place here. All the blocks as set as valid (line 14) and the counteris set to zero (line 15).

4. Blocks Encryption (lines 17 to 19): to encrypt a block it is necessaryto generate an initialization vector. This new random iv is provided bythe function GenIv() that has this unique purpose. Then it is possibleto perform the encryption of the block.

5. Metadata Encryption (line 20): after the encryption of the blocks,it is possible to cypher the metadata.

6. Node upload (line 22): the WriteNode function sends all the newdata to the server that stores the node into the cloud.

70

5.2. Structure of XRing Oram

5.2 Structure of XRing Oram

The main variables of ReadXorPath are:

N Number of real data blocks in ORAM

H Height of the ORAM tree

L Leaf level of the ORAM tree

Z Maximum number of real blocks per bucket

S Number of slots reserved for dummies per bucket

B Data block size (in bits)

A Eviction rate (larger means less frequent)

P (l) Path l

P (x, i) The i-th node identifier (towards the root) on P (l)

Table 5.1: Main variables table

As it is easy to notice, the only change is the lack of the P (x, i, j) functionthat is no longer needed.Instead, inside the node structure, it is necessary to store the initializationvectors of the blocks. To do so the ivs vector is created as a new field andits capacity is of Z + S, a slot for each block iv. The ivi is the initializationvector of the bi block, where i ∈ [0, Z + S).The other modification inside the node data structure is the discarding ofthe randomPad field because it is no longer necessary.

5.3 Complexity

XRing Oram is a variation of Ring Oram and they share the main datastructures. In fact the cloud is still organized using a perfect binary tree. Onclient side, the stash and the position map function are still present.The time and space complexities of XRing Oram are generally different fromRing Oram due to the changes on the node structure and how the algorithmdialogues with the server.

• Stash (client): this structure has a worst case memory complexityof O(log(N)) · Ω(stashElem) and a time complexity for a research of

71


O(log(N)), where N denotes the number of blocks in stash. It is im-portant to mention that the stash is a data structure that continuouslychange its dimension due to its concept nature.

• Position (client): it is a map function pairing blocks identifiers andleaf identifiers < idb, l >. Each element has a size complexity Ω(bid, l)

and a time complexity of O(log(N)), where N is the number of realblocks saved in the cloud. This mapping function has a maximumdimension Z · (2L+1 − 1) ·Ω(bid, l) when the binary tree is used at itsmaximum capabilities.

• Node: size

Ω(idnode, idleft, idright, counter, valids[Z + S], ptrs[Z],

ivs[Z + S], blocks[Z + S], leafs[Z + S])

• Block: size Ω(data).

• Cloud: size (2L+1 − 1) · Ω(node), time complexity O(log(N)).

• Metadata Packet Size:Ω(valids[Z + S], addrs[Z + S], leafs[Z + S], ptrs[Z]).

• Counter Packet Size: Ω(counter).

• Block Packet Size: Ω(block) + Ω(iv).

• Xor Block Packet Size: Ω(block) + Ω(iv ·H).

72





The data confidentiality and the data integrity are guaranteed byan AES cypher. It was chosen to use a security key of 16Byte and a CypherBlock Chaining (CBC) encryption mode. This cypher modality, Figure 2.8,hides the content partitioning it into fragments of the same length as thekey. The first fragment is xored with an Initialization Vector (IV) and thenencrypted. Each subsequent fragment is encrypted after being xored withthe previously encrypted fragment.The Access confidentiality and the Pattern confidentiality are guar-anteed by the way in which the blocks are paired with the leaf identifiers.In fact, each time the algorithm requests a block, the association < idb, l >

is changed. The new leaf identifier is chosen uniformly at random among2L leaves present in the tree. This means that the next time the block isuploaded into the cloud, its position will be along a new random leaf path.Also, the height at which the block is placed is not predictable making anyintersection attack infeasible.It is also important to describe why the stash doesn’t grow out of all pro-portion. It is possible to assert that all the blocks are paired with a leafuniformly at random. This means that the client accesses uniformly at ran-dom the cloud because every time he reads a different path from the root to a

73


leaf. This happens even if the client continuously researches the same blockbecause its < idb, l > changes constantly. At the same time, it is impossiblethat the stash goes out of control because each path is read and refresheduniformly at random, so it is possible to find an intersection node where astash block can be placed over multiple accesses.

74

Chapter 6

Experimental Evaluation

This chapter of the thesis is dedicated to the benchmarks. After havingillustrated the hardware specifications of the test system, there is a generalexplanation of how the tests were performed and which parameters werechanged in each experiment. Then, after each chart, there is the analysis ofthe obtained results.

6.1 System Specifications

The system employed for the benchmarks has, as operative system, Ubuntu16.04.1 LTS at the kernel version 4.10.0-37. The following table illustratesthe hardware specifications of the computer.

Hardware

Type Specifications

CPU Intel i5 4670k 4.2 Ghz

Ram 16GB 1860 Ghz

SSD (only OS) Samsung Evo 840 120GB

HDD 250GB 7200 Rpm

Table 6.1: System Hardware Specifications

All the tests were performed in the cleanest situation possible having thesystem boosted at its maximum capabilities and cleared from all the pro-grammes that could interfere with the results, like Dropbox and automatic

75

CHAPTER 6. Experimental Evaluation

update programmes.For the kind of benchmarks defined in this thesis, the performances of thedisk are fundamental, so in Figure 6.1 there is a complete picture of thecapabilities of the hardware.

Figure 6.1: HDD performances

76

6.2. Benchmarks Specifications

6.2 Benchmarks Specifications

Before starting with the analysis of the algorithms, it is fundamental tospecify how the benchmarks are performed and which considerations weremade. In fact, the four algorithms are very heterogeneous because each onehas multiple configurations and different tuning parameters. In Table 6.2there is a summary of all the configuration variables of the four algorithms.

Name Abbreviation Meaning

Height H Height of the treeLevel L Leaf levelBucket B Bucket dimensionZ Z Number of real blocks per bucketS S Number of dummy blocks per bucketnum_cover C Number of cover searchesnum_cache CC Size of the cache per level

Table 6.2: Tuning Parameters

6.2.1 Measurements

A benchmark is composed of a hundred of Access operations, fifty writesfollowed by fifty reads. It was chosen not to randomize the values toread/write for three reasons: first, to have exactly the same case test for everyalgorithm; second, to eliminate a degree of randomness to better profile thealgorithms; third, to stress the security features of the algorithms simulatinga real case scenario, no client randomly accesses to his data.For every Access call, the following time measurements are taken:

• Wall Access Time: the wall access time represents the total timeneeded to perform a whole Access action. This time can be seen as thesum of all the other components.

• Client Computational Time: this time calculation represents the cputime necessary to perform all the computational operations on theclient side. The network operations are not present in this measure-ment.

77


• Server Computational Time: this time calculation represents the cputime necessary to perform all the computational operations on theserver side. The network operations are not present in this measure-ment.

• Total Disk Time: it is the utilization disk time necessary for reads andwrites during a whole Access operation.

• Network Time: it is the total network time necessary to sends andreceive the data from the server, during a whole Access operation.

The time measurements taken are employed for the calculation of the aver-ages that are used to produce the benchmarks charts.

6.2.2 Network

From the network point of view, all the data exchanges between clientand server utilize the tcp protocol and they are performed in a localhostenvironment. Also, to have a better simulation of the network behaviour,the traffic control (TC) Linux kernel programme was used to manipulatethe network. In fact, with this tool, it is possible to shape how the networkworks. It was chosen to simulate two test cases with two different aver-age round trip times (RTT) and standard deviations (SD), both followinga normal distribution. The first case is a LAN simulation with an averageRTT=0.42ms and a SD=0.04ms recreated using the following command "tcqdisc add dev lo root netem delay 0.42ms 0.04ms distribution normal". Thesecond case is a WAN continental connection with an average RTT=30msand a SD=2.5ms obtained with the following command "tc qdisc add dev loroot netem delay 30ms 2.5ms distribution normal".

6.2.3 Comparison Criterion

Due to the completely different data structures of Shuffle Index (un-chained B+-tree), on one side, and the other three algorithms (binary tree),on the other side, it wasn’t possible to perform the benchmarks using a fixedheight H nor a fixed bucket size B. In fact, Shuffle Index has the flexibilityto increase the branching factor F and develop its tree in width rather than

78

6.2. Benchmarks Specifications

in height. So, without using this property, the test wouldn’t be representa-tive of a real use case because it would be disadvantageous for Shuffle Index.For this reason, the number of real data that can be stored into the cloud ischosen as criterion for comparison.Here the formulae useful for the capacity comparison having a tree withheight H are shown:

• Shuffle Index capacity : B2 · ((B + 1)H−1)

• Path Oram capacity : B · (2H − 1)

• Ring Oram capacity : Z · (2H − 1)

• XRing Oram capacity : Z · (2H − 1)

For Path Oram, Ring Oram and XRing Oram the calculus is quite easybecause every node can store useful information. Instead, the unchainedB+-tree of Shuffle Index can only store information at the leaf level andthese nodes can only be half full. These constraints are imposed by theunchained B+-tree itself and by how it is defined. In fact, the maximumstorage capacity of this structure is obtained multiplying the number of leafnodes ((B + 1)H−1) by the maximum number of data per bucket (B2 ).For the benchmarks it was chosen to have two case tests: the first with#Blocks = 8188 real blocks obtained from a binary tree with H = 11

and B = 4 (#Blocks = B · (2H − 1) = 4 · (211 − 1)), the second case with#Blocks = 4·213 = 32764 real blocks. For Ring/XRing Oram, it is set Z = 4

instead of B. This kind of binary tree configurations are the common onessuggested in the papers of the algorithms. Instead, for Shuffle Index it waschosen to find the shortest and widest B+-tree with the minimum deviationof real blocks ∆#Blocks = MIN(#BlocksShuffle −#BlocksBinarytree). Theactual implementation is explained in the benchmarks part of Shuffle Index.Note that it is supposed to have equal information storing capacities amongthe blocks of the algorithms, otherwise these calculations are not correct.

79


6.3 Base Tests

To have a full picture of the behaviour of each algorithm, in this sec-tion there are four dedicated analysis for each security system. Inside everyexplanation there are multiple benchmark charts followed by detailed stud-ies of how each parameter effects the performances of an algorithm. Also,this four parts are preparatory for the last benchmarks section where theconfrontations among the algorithms are made.

6.3.1 Shuffle Index

The main parameters of Shuffle Index are the height H, the bucket sizeB, the num_cover C and the num_cache CC. Due to its unique data struc-ture, Shuffle Index can have a wider but shorter tree compared to a binarytree with the same number of blocks. In fact, for the Shuffle Index bench-marks, it was chosen to have a height H = 3, that is the minimum heightwithout compromising the algorithm security, and to modify the branch-ing factor F = B + 1 until the needed amount of blocks is reached. Theminimum ∆#Blocks = MIN(#BlocksShuffle − #BlocksBinarytree) in thecase of #BlocksBinarytree = 8188 is obtained with a bucket size B = 25

(#BlocksShuffle = 8112, ∆#Blocks = 262). For the configuration with#Blocks = 32764, the bucket size is equal to B = 40, implying#BlocksShuffle = 33620, ∆#Blocks = 856. For this reason, there are twodistinct charts for each network configuration. Note that these branchingfactors were obtained supposing to have equal information storing capabili-ties between the blocks of the algorithms. In Figure 6.2 are shown the mainparameters variations of the algorithm at bucket size B = 25 in a LAN en-vironment. The test is performed changing a single variable each time tobetter highlight the increase or decrease of the average wall Access time.

80

6.3. Base Tests

0,15 0,16 0,17

88,27 88,24 89,24

0,24 0,25 0,28

Total: 88,65 Total: 88,65 Total: 89,69

0,00

10,00

20,00

30,00

40,00

50,00

60,00

70,00

80,00

90,00

100,00

H3B25C1CC1 H3B25C1CC2 H3B25C2CC1

Mill

isec

on

ds

[ms]

Avg Wall Access Time LAN

Avg Computation Server

Avg Network

Avg Computation Client

Total

Figure 6.2: Shuffle Index LAN test with B=25

Starting from the left and going to the right of the figure, there is thefollowing sequence: base test, a num_cache = 2 and a num_cover = 2.The base test is the simplest configuration possible of Shuffle Index and it isuseful for the comparison with the other set ups.It is clear that the major component of the average wall Access time is thenetwork latency. The results are interesting even if there aren’t considerabledifferences in the three scores. In fact, this shows that Shuffle Index, dueto its fixed height, doesn’t suffer from an increase of the number of coversearches if the internet connection has a wide bandwidth data transmission.Also in the case with num_cache = 2 there is pretty much the same resultof the base test. The reason for minimal difference can be found in how thebenchmarks are performed. In fact, the first time that Shuffle Index accessesto a previous block is after forty-nine Access operations. This dimension isclearly bigger than the cache size, so the benefits of a larger cache are notobservable in this benchmark.

81


0,15 0,17 0,19

88,35 88,40 88,29

0,25 0,250,26


0,00

10,00

20,00

30,00

40,00

50,00

60,00

70,00

80,00

90,00

100,00


Mill

isec

on

ds

[ms]



Avg Network


Total

Figure 6.3: Shuffle Index LAN test with B=40

This chart represents the case with #BlocksShuffle = 33620 in a LAN en-vironment. The results obtained are equal to the previous case. This meansthat a wider tree has the same performances of a narrower one and thisconfirms the important feature of Shuffle Index. In fact, in both the config-urations with B = 25 and B = 40, Shuffle Index performs the same amountof requests, what changes is the amount of data transferred per send/receiveaction. In the case of a internet connection with a narrow bandwidth datatransmission capacity, the difference between the two configuration can beseen.

0,15 0,17 0,18

322,81 324,54 323,30

0,24 0,26 0,26


0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00


Mill

isec

on

ds

[ms]

Avg Wall Access Time WAN 30ms


Avg Network


Total

Figure 6.4: Shuffle Index WAN 30ms test with B=25

This benchmark is the first one simulating a WAN internet connection.The shape of the chart remains similar to the previous ones. The average

82

6.3. Base Tests

network latency has increased due to the bigger RTT, but the other timecomponents of the average wall Access time haven’t changed.

0,16 0,18 0,19

325,08 324,64 325,43

0,25 0,260,26


0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00


Mill

isec

on

ds

[ms]



Avg Network


Total

Figure 6.5: Shuffle Index WAN 30ms test with B=40

Also in this benchmark, the results are very similar to the previous ones.From this charts it is possible to evict that it is not how many data aretransferred between the server and the client, but the number of times thatinternet is accessed that makes worst the performances of an algorithm. Thegeneral conclusion on Shuffle Index is that it can take advantage of its widerdata structure without losing performances compared to a binary tree thatcan only grow in height. The network latency has a great impact on theperformances because it is the main slowing factor of the Access procedure.With an RTT increased by 63.8%, the algorithm slows down by almost 3.68%even in the case with two cover searches where more nodes are retrieved fromthe cloud.

83


6.3.2 Path Oram

In this section, the Path Oram benchmarks are presented, first in a LANthen in a WAN network simulation. In both the charts there are threehistograms: the first represents the performances of a binary tree with heightH = 11; the second is a tree with bucket size B = 5; the third is a tree withH = 13. In fact, Path Oram has only these tuning parameters.

4,31 4,27

14,59

44,30 44,13

44,15

0,18 0,18

0,22Total: 48,80 Total: 48,58

Total: 58,96

0,00

10,00

20,00

30,00

40,00

50,00

60,00

70,00

H11B4 H11B5 H13B4

Mill

isec

on

ds

[ms]



Avg Network


Total

Figure 6.6: Path Oram LAN test

The first two results share a comparable shape and timing. The increasein the bucket size doesn’t affect the performance of the algorithm. In fact,the internet band is not a bottleneck. Instead, the change of height has agreat impact on Path Oram, but it’s not a problem of network time, buta client computational time that slows down Path Oram. This happensbecause Path Oram needs to compute the node indexes using an exponentialoperation that is more heavier more height is the tree. In fact, the averageclient computational time (red part) has increased considerably compared tothe other two test cases. Instead, the network has basically remained thesame in all the three tests and remains the greatest slowing factor of thealgorithm.

84

6.3. Base Tests

4,25 3,84 14,50

161,36 161,42161,21

0,20 0,19 0,18Total: 165,80 Total: 165,45

Total: 175,90

0,00

20,00

40,00

60,00

80,00

100,00

120,00

140,00

160,00

180,00

200,00

H11B4 H11B5 H13B4

Mill

isec

on

ds

[ms]



Avg Network


Total

Figure 6.7: Path Oram WAN test

In the WAN benchmark, Figure 6.7, the average network time increasesapproximately by 3.40% in the worst case, but clearly becomes the dominantcontributor to the overall Access time. The other parts of the chart arecomparable to the previous ones and this confirms the fact that Path Oramis sensitive to the change in height H of the binary tree. Note that theaverage client computational times in the tests with H = 13 of Figure 6.6and Figure 6.7 are basically equal, confirming the more heavier exponentialoperation.

6.3.3 Ring Oram

Ring Oram is a direct evolution of Path Oram. In fact, they have themain data-structures on client and server side in common. But, as mentionedbefore, this algorithm is focused on the reduction of the used bandwidth.For a correct functioning of Ring Oram, it is necessary to set more parametersin comparison with the other algorithms seen. These variables are: thenumber of potential real blocks per bucket Z, the number of dummy blocksper bucket S and A, the frequency parameter with which the EvictPathfunction is called. For a correct set up of the algorithm, it is mandatory tofollow these three steps:

1. First, it is chosen a Z that satisfies the client’s requirement.

2. Second, it is chosen A. It is necessary to find the largest A ≤ 2Z sothat Zln(2Z/A) +A/2− Z − ln(4) > 0 is held.

85


3. Third, it is chosen S. It is necessary to find an S ≥ 0 that minimises(2Z + S) · (1 + Poisscdf (S,A)), where Poisscdf (S,A) is the cumula-tive distribution Poisson function. Also, for performance reasons, itis preferable to select an S ≥ A. The reason for this relation be-tween these two apparently uncorrelated variables is the security ofthe algorithm. In fact, A is the frequency with which a whole pathis reshuffled, while S is used by the EarlyReshuffle function to de-termine if a node needs to be reshuffled. Triggering the EvictPathprocedure too frequently (A is too little) costs a lot in terms of perfor-mances, instead a too large A can cause procedural (no valid dummiesin a node) and security problems (nodes accessed too many times) thatEarlyReshuffle cannot manage by itself.Due to these constraints, the best S value is always:

S = MIN(S ≥ A) = A

In our case where Z ∈ [4, 5] implies an A = 3 and an S = 3. So every RingOram and XRing Oram test always has an A = 3 and an S = 3 set up. Notethat the overall bucket dimension is obtained by the sum B = Z + S. So,for the case Z = 4, the bucket size is equal to B = 7 and for the case withZ = 5, the bucket size is equal to B = 8.

1,61 1,75 3,71

314,85 321,55 322,63

0,62 0,62 0,64Total: 317,07 Total: 323,92 Total: 326,98

0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00

H11B4 H11B5 H13B4

Mill

isec

on

ds

[ms]



Avg Network


Total

Figure 6.8: Ring Oram LAN test

This first benchmark is performed in a LAN network configuration. Asfor Path Oram, there are three histograms, the first represents the base test

86

6.3. Base Tests

with a bucket B = 4 and height H = 11, the second one has a bucket equalto B = 5 and the last one has an height equal to H = 13.The reasoning that must be applied to explain these results is similar to theones done in the other benchmarks. In fact, it is clear that what makes analgorithm better or worst than an other is the number of data requests perAccess phase. Every time a security system accesses to the internet, it paysa flat RTT cost no matter what kind of data are transferred. This explainwhy different configuration of an algorithm, in the same internet simulation,performs similarly.For Ring Oram happens the same thing. The overall average access walltime of the three tests are comparable, with a slightly increase in the clientcomputational time when the height is H = 13.

1,64 1,65 3,99

1021,67 1025,83 1021,34

0,62 0,62 0,66


0,00

200,00

400,00

600,00

800,00

1000,00

1200,00

H11B4 H11B5 H13B4

Mill

isec

on

ds

[ms]



Avg Network


Total

Figure 6.9: Ring Oram WAN test

As for the previous benchmark, the overall analysis holds. In the WANenvironment, Ring Oram maintains its constant behaviour. Also, it is possi-ble to assert that Ring Oram heavily suffers from a high round trip time dueto the multiple communications needed per Access phase. In fact, comparedto Path Oram, Ring Oram has the additional task to read the metadata of anode before accessing it. This means an additional send and receive of databetween the client and the server with an increase of the overall networktime per Access operation. It must be highlighted that Ring Oram was builtfor reducing the bandwidth consumption and not the network latencies andthis study case is explained in the Bandwidth Evaluation Section.

87


6.3.4 XRing Oram

XRing Oram is a variant of Ring Oram that implements the Xor trick.This new feature is useful for the bandwidth reduction because here, for eachReadPath operation, only one block packet with size Ω(block) is received.The drawback of this operation is an increase in the algorithm complexitybecause there are more computations to perform.

2,90 3,07 8,68

386,38 386,34 390,64

15,24 15,2117,30


0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00

400,00

450,00

H11B4 H11B5 H13B4

Mill

isec

on

ds

[ms]



Avg Network


Total

Figure 6.10: XRing Oram LAN test

As for the LAN Ring Oram benchmark, XRing Oram has a similar be-haviour having, as worst case, the H = 13 test. The overall server and clientcomputational times haven’t increased, so it is possible to assert that theXor feature doesn’t slow down the algorithm, in fact, xoring bits is one ofthe most efficient operations for a computer.

88

6.4. Confrontation Tests

3,07 2,70 8,31

1211,83 1212,18 1215,56

34,91 35,20 37,84


0,00

200,00

400,00

600,00

800,00

1000,00

1200,00

1400,00

H11B4 H11B5 H13B4

Mill

isec

on

ds

[ms]



Avg Network


Total

Figure 6.11: XRing Oram WAN test

In the WAN benchmark, the average network time increases by 3% com-pared to the worst case in the LAN configuration.

6.4 Confrontation Tests

This section deals with the discussion of the four algorithms using ascriterion for comparison the number of blocks. The histograms show thebehaviours of the protocols in their base tests.

0,154,31

1,612,90

88,27 44,30

314,85

386,38

0,240,18

0,62

15,24

Total: 88,65

Total: 48,80

Total: 317,07

Total: 404,52

0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00

400,00

450,00

Shuffle H3 B25 Poram H11 Roram H11 XROram H11

Mill

isec

on

ds

[ms]


Avg Total Server

Avg Network


Total

Figure 6.12: Confrontation test in LAN environment and ∆#Blocks = −76

The results are quite clear. Path Oram has an advantage over the otherprotocols and it is 1.81 times faster than Shuffle Index, that has the secondbest result. It is obvious, at this point, to assert that the network communi-

89


cations are the main reason why an algorithm performs well or not. In fact,it is crucial, from a performance point of view, how each security protocolimplements the data transmissions and for implementation it is meant:

• number of communications per Access phase: every time an algorithmneeds to communicate with the server it has to pay a high time costfor the establishment of the tcp protocol. Also, the higher the RTTis, the higher the amount of network time per Access operation willbe. For instance, if an algorithm performs three requests, it will paythree times the communication costs and it will be in disadvantage incomparison with another protocol that requires less data exchanges.These costs are not related to the size of the data to transmit, but itis the costs for accessing and using the internet channel that is paid.

• total size of transmitted data per Access phase: sending more dataimplies a higher time of transmission. This time becomes an importantcofactor of the overall network time when the total size of data tobe transmitted became significant. For further explanations see theBandwidth Evaluation Section.

Even supposing an equal usage of the network on behalf of the algorithms(in terms of total data transmitted), it can be asserted that the same kind ofresults would be obtained. The main reason for this statement is that PathOram performs only a single request-receive of nodes and then it sends themback reshuffled. Shuffle Index has a similar behaviour but these operationsare executed level by level, so the number of internet communications isrelated to the height of the tree. For Ring/XRing Oram there is a single dataexchange for all the metadata needed, then another one for all the blocks and,after all, there are the EvichtPath and EarlyReshuffle functions that usethe tcp protocol. This means that Path Oram has the best implementation,Shuffle Index places in second position, followed by the two other algorithms.Before going on with the other benchmarks, it is important to highlight thereason why there is a great difference between Ring Oram and XRing Oram.The main explanation is in the total size of transmitted data per Access phase.In fact, due to security constraints and due to the Xor feature, XRing Oramneeds to upload/download more data than Ring Oram even if the the Xor

90


trick is implemented in these test cases. An explanation for this phenomenonis in the Bandwidth Evaluation section.

0,15 14,59

3,71 8,6888,35 44,15

322,63

390,64

0,250,22

0,64

17,30

Total: 88,74

Total: 58,96

Total: 326,98

Total: 416,62

0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00

400,00

450,00


Mill

isec

on

ds

[ms]


Avg Total Server

Avg Network


Total

Figure 6.13: Confrontation test in LAN environment and ∆#Blocks = 856

In Figure 6.13 there are the results of the benchmarks with a∆#Blocks = 856 in a LAN environment. The results confirm the generaltrends of the algorithms: Path Oram is still the best, followed by ShuffleIndex and the other two algorithms. Note that the time gap between ShuffleIndex and Path Oram is smaller than before. In fact, Shuffle Index maintainsits timings when the bucket dimension changes, while the additional twolevels of the tree of Path Oram makes worst its performance.The other two algorithms have worst performances than Shuffle Index andPath Oram as seen in Figure 6.12.

0,15 4,251,64 3,07

322,81

161,36

1021,671211,83

0,240,20

0,62

34,91

Total: 323,21Total: 165,80

Total: 1023,93

Total: 1249,81

0,00

200,00

400,00

600,00

800,00

1000,00

1200,00

1400,00


Mill

isec

on

ds

[ms]


Avg Total Server

Avg Network


Total

Figure 6.14: Confrontation test in WAN environment and ∆#Blocks = −76

91


This is the first benchmark in a WAN configuration. The average networktimes of the algorithms have grown from the LAN configuration and the onewho accesses multiple times to the internet is the one who pays more interms of performances. It is possible to note that Path Oram still maintainsthe first place, with a speed up of 1.95 % compared with the result of ShuffleIndex. It is to consider that a LAN configuration represents a case wherethe server is physically in the same building of the client, while a WANconfiguration represents a continental connection like Milan with a Europeancapital like Berlin, Paris or London. The Ring Oram and XRing Oramalgorithms are the protocols that suffer more from the worst RTT. In fact,they have slowed down by 3.22% and 3.14%, respectively, compared to theFigure 6.12 benchmark.

0,16 14,503,99 8,31

325,08161,21

1021,34

1215,56

0,250,18

0,66

37,84

Total: 325,49

Total: 175,90

Total: 1031,32

Total: 1261,72

0,00

200,00

400,00

600,00

800,00

1000,00

1200,00

1400,00


Mill

isec

on

ds

[ms]


Avg Total Server

Avg Network


Total

Figure 6.15: Confrontation test in WAN environment and ∆#Blocks = 856

In this last comparison, it is possible notice the same trend observed inthe previous benchmarks. The one who has less internet accesses is the onewho has more advantages over the others. Also, the gap difference betweenShuffle Index and Path Oram, as seen in Figure 6.13, is less evident due tothe fact that Shuffle Index remains constant in its timing, while Path Oramslows down a little bit. In fact, in the previous case the gap was 157.41ms,while, in this case, the time difference is equal to 149.59ms, meaning a 1.85%speed up.

92


6.4.1 Average Internet Accesses

The benchmarks of the four algorithms have revealed and important com-mon behaviour of the algorithms. The average number of internet accessesis a hidden characteristic of each security system.In the comparisons among different configurations of an algorithm, in a com-mon internet environment, the time performances are very similar. From atheoretical point of view, these behaviour of the systems is strange. In fact,different configurations of an algorithm mean different time and spatial com-plexities, so different time performances. In practise, what happened, is thatthe combination of a large bandwidth internet connection and the optimiza-tion of the algorithms implementations hides these different time and spatialcomplexities. In fact, when a bucket size is changed, the node size is changed,too. This means a increase of the bandwidth usage and an increase of theaverage network time due to the higher transmission time. But, with a largebandwidth internet connection, the transmission time difference is almostequal to zero in this benchmarks, so the results don’t presents any differ-ence. This configuration represents a real case scenario, where the clientbuys an appropriate internet connection for his requirements.In the case where the hight of a tree is changed, the time complexity of analgorithm is changed, too. But each system implementation is optimized insuch a way that the Access function performs the minimum number of sendoperations. For instance, if there are multiple nodes to read from the cloud,the Access procedure gathers all the node identifiers and then it sends themin a single packet. This means that there is no time complexity differencebetween reading eleven of thirteen nodes, because the algorithm perform al-ways a single node request. The only thing that changes is the size of thetransferred data between the client and the server. But, since there is a widebandwidth internet connection, this data size difference doesn’t affect thetime performances. After this explanation, it is possible to understand whyan algorithm performs better than an other. In fact, it is the average numberof internet accesses that influences the time performances in a considerableway.In the following explanation the average numbers of internet accesses arecalculated. For convenience reason, it is used a new parameter,

93


called avgCom, to represent the obtained average values.

• Shuffle Index : this algorithm performs the researches level by level.Also, it uses the same kind of procedure to upload new nodes into thecloud. So, for every level, the system performs a nodes request, then forthe nodes to upload, it sends the node identifiers and the relative nodesin two distinct packets. So the average number of internet accesses isequal to:

avgCom = H · 3

• Path Oram: this security system works in a different way than ShuffleIndex due to its different cloud data structure. It performs a singlerequest for all the nodes along a chosen path. Then, the algorithmupload H new nodes sending, in two different packets, all the nodeidentifiers and the nodes. So the average number of internet accessesis equal to:

avgComm = 3

• Ring/XRing Oram: the analysis of Ring Oram and XRing Oram isequal for both because they share the same kind of internet accesspattern. In fact, the Xor technique affects the bandwidth consumption,not the number of requests.The two algorithms have the same cloud data structure of Path Oram,but how they access to it is different. In fact, Ring Oram and XRingOram must download the metadata of a node before perform any kindof manipulation. So, in the ReadPath function, there is a request forthe metadata of the nodes along a path and then another request for theblocks. After that, there are only two other procedures that can accessto the internet and they are the EarlyReshuffle and the EvictPathfunctions. In EarlyReshuffle, there is a H ·Poisscdf probability, overA Access calls, that at least a node must be reshuffled. In this casethere is a metadata request for all the node that need to be reshuffled,then the request for the valid real blocks in the nodes takes place. Atthe end, the function sends all the new nodes in a single packet. Due

94

6.5. Bandwidth Evaluations

to the not hidden node identifier field, there isn’t the necessity to senda packet containing all the node identifiers during the upload phase.For EvictPath, things are more easier. In fact, when it’s triggered,the function has the same number of accesses of the EarlyReshuffleprocedure, but with a probability equal to one instead of H ·Poisscdf .So the average number of internet accesses over A Access calls is equalto:

avgCom = avgComRead + avgComEarlyReshuffle + avgComEvictPath

avgComRead = 2

avgComEarlyReshuffle = H · Poisscdf · 3

avgComEvictPath =3

A

So the final formula is:

avgComm = 2 +H · Poisscdf · 3 +3

A

This analysis proves clearly why Path Oram has the best time performanceover the others. The simply reason is because it performs less data exchanges.In fact, Path Oram pays less RTT and spends less time waiting the serveranswers. The same reasoning explains why Shuffle Index has the second bestresults followed by the others. So this analysis describes, in general, how canperform an algorithm, but it cannot precisely predict the average networktime because the server response time is different among the algorithms.Without the system optimization, things are very different because, in thiscase, the height of the tree matters. Also, in the case with a narrow band-width internet connection, the increase on the node dimension will heavilyaffects the time performances of the algorithms.

6.5 Bandwidth Evaluations

The last study case to analyse is related to the bandwidth consumption.Here is presented the discussion, in terms of costs, of the internet band usage

95


of the four algorithms. In fact, this is a key aspect that the client must takeinto account when he chooses his security system.The analysis is focused on the upload and download of nodes/blocks betweenthe client and the server. The main differences between the algorithms are:

• Managing nodes or blocks: if the algorithm exchanges nodes withthe server, it will have a bigger packet size to send and receive incomparison with the request of a single block. This dimension canbe represented by the ratio between the block size and the node sizeRatioblock/node = Ω(Block)

Ω(Node) . It is mandatory to pay attention with Shuf-fle Index because its internal nodes haven’t got any blocks inside, butresearch keys that have a completely different size complexity.

• Height of the tree: during an Access phase, all the four systemsread a path starting from the root level to the leaf level. So, thenumber of nodes/blocks received is equal to the height H of the datastructure (for Shuffle Index is H · (num_cover = 1)). Also, duringthe reuploading/reshuffling phase, the algorithms send back the samenumber of nodes/blocks.

• Real information size: if the data field inside the blocks has a verylarge memory size, the difference between reading/writing nodes orblocks starts to weigh considerably. Also, the ratio between the size ofthe needed information and the total dimension of the packet gets worsein the case of reads/writes of entire nodes. This because unnecessaryparts of a node are downloaded.

• Metadata packet: this characteristic is proper of Ring Oram andXRing Oram algorithms. They use this new feature to read/writeblocks instead of nodes. The key idea of using this new data structure isto receive useful information contained in a smaller data packet insteadof an entire node. With this information it is possible to select a singleblock that is retrieved from the cloud. The total bandwidth used isequal to the request/receive of the metadata plus the request/receiveof the selected block. The algorithms have a gain only if the quantity ofdata exchanged is smaller than the quantity needed for a normal noderequest. For Path Oram, Ring Oram and XRing Oram, this key aspect

96


depends on the actual information storing capacity of a block. In thecase of a comparison between Ring Oram and XRing Oram, on oneside, and Shuffle Index, on the other side, there is another variable totake into account that is the different height of the tree data structures.This aspect has already been analysed in the second point (Height ofthe tree).

• Xor technique: it is a special characteristic of XRing Oram. Duringthe ReadXorPath function, the Xor technique enables the algorithmto receive a unique block instead of H ones. This is a great advan-tage over the other algorithms because it reduces drastically the totalbandwidth used. The drawback of this trick is that it is not employableduring other procedures of the protocol. For the EvictPath functionit is mandatory to read H whole nodes and to send the same amountof nodes back. For the EarlyReshuffle function, it is still impossibleto exploit the Xor technique because the procedure reads all the realvalid blocks of a node.

• Padding: the padding technique is required for security reasons. Ev-ery field, node or chunk of bytes that has to be cyphered must be amultiple of the size of encryption key chosen (sizekey). If this con-straint is not held, the cryptographic scheme will be insecure. Forthis reason, the pad is inserted inside the variables to be encrypted.In general, the maximum dimension of a required pad is equal topadmax = sizekey − 1B. For the four algorithms, it was chosen asizekey = 16B, so it implies a padmax = 15B.The place and the size of a pad change in relation to the algorithmsdue to the different objects to encrypt. Shuffle Index and Path Oramhave to encrypt entire nodes. This means that, in the worst case, thepadding inside these objects is equal to padmax. Instead, for RingOram and XRing Oram, the objects to be cyphered are the metadataand the blocks of a node. So, for both these data structures, it is nec-essary to expect a padding field that can have a size equal to padmax.Considering the worst case among the four algorithms, the total sizeof pad inserted in Ring Oram and XRing Oram nodes is greater thanin the other cases. Also, Ring/XRing Oram focus on the bandwidth

97


usage reduction and this padding constraint can weigh a lot if the realinformation size per block is very small, four bytes for example. Thisbecause they are sending and receiving more pads than real informa-tion.

The first consideration that is possible to make concerns Path Oram, RingOram and XRing Oram. They employ an identical cloud data structure sothe height of the tree is not important. For the comparison with ShuffleIndex things change. In fact, its cloud data structure is completely differentfrom the other ones and, as mentioned before, in a test case with a similaramount of nodes, Shuffle Index has a shorter tree, so the height is a crucialfactor. This means that Shuffle Index consumes more bandwidth sendingand receiving nodes, but, with its lower tree, the overall bandwidth can beless than the others. The real information size per block, combined withthe number of real blocks per bucket, is a key aspect in this analysis. Infact, these two parameters determine the global dimension of a node and theranking of an algorithm.

6.5.1 Bandwitdh Formulae

After these general considerations, it is possible to advance in the analy-sis and study on how the amortised bandwidths are calculated over A Accesscalls. In fact, for Ring Oram and XRing Oram, the bandwidth consump-tion changes considerably when the EvictPath is triggered, so the formulaeconsider the average bandwidth over a period of A accesses for all the algo-rithms.

Shuffle Index Bandwidth

For every Access phase, this algorithm makes num_cover + 1 nodesrequests for each level of the tree (num_cover fake researches plus a real orfake research), so, in total, (H − 1) · (num_cover + 1) node identifiers aresent to the server (the root is always cached). Then Shuffle Index receives(H − 1) · (num_cover + 1) nodes. After that, the root node plus (H − 1) ·(num_cover+1) nodes are shuffled and sent into the cloud together with Hnode identifiers, because otherwise the server wouldn’t know where to placethem. In fact, the cloud nodes of Shuffle Index are fully encrypted, so the

98


client must specify the position of each node during the uploading phase.Another important thing to remember is the different dimension betweeninternal and leaf nodes. So, for the tree levels numbered from 0 to L − 1,the algorithm exchanges inner nodes, while at the leaf level L, it exchangesleaf nodes.The total bandwidth is:

BandTotal = BandRead +BandWrite

BandRead = (H − 1) · (num_cover + 1) · Ω(idnode) + (H − 2)·

·(num_cover + 1) · Ω(nodeinternal) + (num_cover + 1) · Ω(nodeleaf )

BandWrite = Ω(idroot) + Ω(noderoot) + (H − 1) · (num_cover + 1)·

·Ω(idnode) + (H − 2) · (num_cover + 1) · Ω(nodeinternal)+

+(num_cover + 1) · Ω(nodeleaf )

In the case with num_cover = 1 the formula becomes :


BandRead = (H − 1) · (2) · Ω(idnode) + (H − 2) · (2) · Ω(nodeinternal)+

+(2) · Ω(nodeleaf )

BandWrite = Ω(idroot) + Ω(noderoot) + (H − 1) · (2) · Ω(idnode)+

+(H − 2) · (2) · Ω(nodeinternal) + (2) · Ω(nodeleaf )

Shuffle Index doesn’t change its bandwidth consumption over multiple ac-cesses to the cloud, so amortised cost is equal to the formula shown above.

Path Oram Bandwidth

The Access function of Path Oram performs a single request to retrieveH nodes along a path, so H node identifiers are sent and then H nodesare received. After that, the algorithm uploads the same amount of data,

99


so other H nodes plus their identifiers travel through internet. The nodeidentifiers are necessary, as in Shuffle Index, because the nodes are fullyencrypted and the client must specify where to place each node.The total bandwidth is:


BandRead = H · Ω(idnode) +H · Ω(node)

BandWrite = H · Ω(idnode) +H · Ω(node)

Path Oram doesn’t change its bandwidth usage over multiple accesses to thecloud, so its amortised cost over A accesses is equal to the formula above.

Ring Oram Bandwidth

For Ring Oram, the bandwidth consumption changes over A accesses tothe cloud. In fact, exactly after A calls of the Access function, the EvictPathprocedure is triggered. This function reads and reshuffles all the buckets overa path. During this operation there is a high exchange of data between theclient and the server, so the bandwidth formula of Ring Oram musts considerthis important aspect. In fact, the analysis evaluates the bandwidth over Aaccesses, then the amortised cost is extracted.Ring Oram sends H ·Ω(idnode) for A times to retrieve the metadata of nodes.Then it receives A ·H ·Ω(meta) data useful for the selection of the blocks. Atthis point, Ring Oram specifies to the server which blocks it wants, sendinga series of pairs of < idnode, idblock >. So, in total, the algorithm sendsA ·H · [Ω(idnode) + Ω(idblock)] for the blocks requests. Finally, A ·H blocksare retrieved from the cloud. So, the BandReadPath over A accesses is alwaysequal to:

BandReadPath = A ·H · [2 · Ω(idnode) + Ω(meta) + Ω(idblock) + Ω(block)]

After each access, Ring Oram performs a EarlyReshuffle procedure. Theprobability that a node needs to be reshuffled over A Access calls is givenby a binomial cumulative density function Binomcdf (S, 2lA, 2−l). The mo-

100


tivations for this result is given following the reasoning done in the RingOram document [4]. The explanation starts saying that a node at level lof the tree will be processed by EvictPath once for every 2lA EvictPath

operations, due to the reverse-lexicographic order of eviction paths. Sec-ond, each EvictPath procedure is driven by an independent and uniformlyrandom path that statistically means that any node, at level l, is touchedwith equal probability 2−l. Then, the distribution on the expected numberof times ReadPath operations touch a given node in level l, between twoconsecutive EvictPath calls, is given by a binomial distribution of 2lA trialsand success probability 2−l. This is exactly a binomial cumulative densityfunction Binomcdf (S, 2lA, 2−l).Another observation that is possible to make is that the binomial distributionquickly converges to a cumulative Poisson distribution function Poisscdf (S,A).This Poisscdf represents the probability that a node needs to be reshuffledover A accesses.After this explanation phase, it is possible to calculate the bandwidth con-sumption of EarlyReshuffle. The function starts receiving and checkingA node counters, so A ·H node identifiers are sent. If a counter is not toohigh, nothing more is done. In the other case, that happens with a Poisscdfprobability, the procedure requests the node metadata. Then the functionretrieves the Z real blocks from the bucket. After that, an upload operationof a whole node takes place. Note that when a node is sent to the server, it isnot necessary to specify where it must be placed. In fact, the node identifierfield is not encrypted so the server has access to it.The final EarlyReshuffle bandwidth consumption is shown in the formulabelow:

BandEarlyReshuffle = A ·H · [Ω(idnode) + Ω(counter)]+

+H · Poisscdf · Ω(idnode) + Ω(meta)+

+Z · [Ω(idnode) + Ω(idblock) + Ω(block)] + Ω(node)

Note that the second addend of the sum hasn’t the A parameter insidebecause the Poisscdf already takes into consideration the probability of anode reshuffle over A accesses.For EvictPath, the analysis is easier than EarlyReshuffle. In fact, when

101


it is triggered, the function reads all the real blocks inside the nodes alonga chosen path. Then, it uploads H new nodes into the cloud. So, first, thefunction requests H metadata, then it requires H ·Z blocks and finally sendsH nodes to the server. The EvictPath function is called only once over aperiod of A accesses, so this parameter is not present in the formula.The total bandwidth consumption of EvictPath over A accesses is equal to:

BandEvictPath = H · Ω(idnode) + Ω(meta)+


The total amortised bandwidth cost of Ring Oram is obtained summingthe BandReadPath, the BandEarlyReshuffle and the BandEvictPath and thendividing the result by A.The final formula, after removing some common variables, is:

BandTotal = BandReadPath +BandEarlyReshuffle +BandEvictPath

BandReadPath = H · [2 · Ω(idnode) + Ω(meta) + Ω(idblock) + Ω(block)]

BandEarlyReshuffle = H · [Ω(idnode) + Ω(counter)]+

+1

A·H · Poisscdf · Ω(idnode) + Ω(meta)+


BadEvictPath =1

A·H · Ω(idnode) + Ω(meta)+


102


XRing Oram Bandwidth

XRing Oram has the same kind of bandwidth costs as Ring Oram forthe EvictPath and EarlyReshuffle functions. Instead, in the ReadPathprocedure, the algorithm receives a single block instead of H ones.So the total amortised bandwidth usage is equal to:

BandTotal = BandReadPath +BandEarlyReshuffle +BandEvictPath

BandReadPath = H · [2 · Ω(idnode) + Ω(meta) + Ω(idblock)] + Ω(block)

BandEarlyReshuffle = H · [Ω(idnode) + Ω(counter)]+

+1

A·H · Poisscdf · Ω(idnode) + Ω(meta)+


BadEvictPath =1

A·H · Ω(idnode) + Ω(meta)+


103


6.5.2 Bandwitdh Confrontations

In the following benchmarks it is shown the amortised bandwidth con-sumption of each algorithm while the real information size per block changes.For convenience reasons, a new variable infoSize, that represents the realinformation size per block, is defined.

1,00

10,00

100,00

1000,00

10000,00

4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768

Log 1

0(B

and

wid

th[K

B])

Data storing capabilities of a block in Byte [B]

Bandwidth Consumption

Shuffle Index B25H3C1CC1 POram H10B4 ROram H10Z4S3A3 XROram H10Z4S3A3

Figure 6.16: Bandwidth trend, ∆#Blocks = −76

In this first benchmark, Figure 6.16, it was chosen to employ the samebase test settings seen in the benchmarks with ∆#Blocks = −76. In fact, itis important to study the overall behaviour of the algorithms and not onlyfocusing on their possible points of strength. The four lines in the chart rep-resent the trend of the total amount of data that travel through internet, withthe change of the real information size per block (infoSize ∈ [4B, 32KiB]).The chart shows interesting results that clearly illustrate the characteristicsof each algorithm. Due to the complexity of the following analysis, the con-siderations among the algorithms are subdivided into multiple comparisons.

• Shuffle Index vs Path Oram: with small infoSize dimension, PathOram has an advantage over Shuffle Index because the node dimensionof the latter is bigger than the other one. In fact, the gap between thebucket size B of the binary tree and the bucket size BShuffle of ShuffleIndex is equal to ∆B = 21. Furthermore, the BShuffle parameteraffects the size of the childrenIds and keys vectors, for an internalnode, and the bucket vector of a leaf node. All of these differencescontribute to rank Path Oram ahead of Shuffle Index. But, when the

104


infoSize dimension grows considerably, the height factor inside thebandwidth formulae becomes crucial. In fact, with a infoSize ≥ 128B,the ranking between Shuffle Index and Path Oram is inverted. Thisbecause, the inner nodes of Shuffle Index don’t grow so much in size incomparison to a node of Path Oram. The reason for this phenomenonis due to the fact that inner nodes store identifiers and research keys,not actual information, so the infoSize doesn’t affect them. Also, theshorter tree of Shuffle Index helps a lot in terms of bandwidth saving.

• Ring/XRing Oram vs Path Oram: the only common result, amongthe three, is with a infoSize = 4B. The reason for this result isexplained by the different padding constraints between the algorithmsand by the low Ratioblock/node = Ω(Block)

Ω(Node) . In fact, with such a smallinfoSize, Ring Oram and XRing Oram use more bandwidth exchang-ing metadata and indexes while it would be more efficient to read thewhole node, like Path Oram does. With the increase of the infoSizevalue, Path Oram starts to consume more bandwidth than the othertwo algorithms.

• Ring Oram vs XRing Oram: the comparison between these two similaralgorithms shows interesting results. First, it is noticeable that RingOram has better performances than XRing Oram until the infoSizebecomes higher than 32 bytes. This is explicable by the fact thatXRing Oram has to exchange continuously initialization vectors withthe server. Each iv has a size of 16 bytes, so it is not a negligible datadimension because it affects the packets and the nodes dimensions.With an infoSize = 128B, the line of XRing Oram is lower than theRing Oram one. This means that reading H blocks or only one ofthem makes the difference between the two algorithms. This is stillvalid even if the node size of XRing Oram is always greater than theRing Oram one.The last consideration of this comparison concerns the flat trend of thealgorithms when infoSize ∈ [4B, 16B]. Note that 16B is the exact sizeof the encryption key. This means that, when the infoSize is smallerthan 16B, the blocks are filled with pads until their global dimensionreaches exactly 16B. In fact, the padding constraint must be held, so

105


when infoSize ∈ [4B, 16B] there isn’t any change in the bandwidthbecause the total dimension of a block doesn’t change. Simply, part ofthe pad space is left to the new infoSize dimension. In the other casesit is always possible to observe a change in the bandwidth because theinfoSize increase is always greater than 16B, so the block size changesevery time. With a more granular increase in the infoSize parameter(smaller than the sizekey), it will be possible to observe a step functiontrend with a gap every time the block size changes.

1,00

10,00

100,00

1000,00

10000,00

4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768

Log 1

0(B

and

wid

th[K

B])


Bandwidth Consimption


Figure 6.17: Bandwidth trend, ∆#Blocks = 856

In Figure 6.17 are shown the bandwidth consumptions with the algorithmsettings seen in the benchmarks with ∆#Blocks = 856. The chart is very simi-lar to the previous one seen in Figure 6.16. The only thing that changes is thetrade-off point where Shuffle Index becomes more efficient than Path Oram.In the benchmark of Figure 6.16, the point where the line of Shuffle Indexstays below the Path Oram one is in infoSize = 16B. In this new test, theswitching point is almost at infoSize = 64B. This happens because PathOram needs to read two more nodes than in the previous benchmark (Figure6.16), while Shuffle Index has a bigger node size. In fact, the new BShuffle

is equal to 40, a great increment in comparison with the old BShuffle = 25.

106


1,00

10,00

100,00

1000,00

10000,00

100000,00

1000000,00

4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768

Log 1

0(B

and

wid

th[K

B])


Bandwidth Consumption


Figure 6.18: Bandwidth trend, ∆#Blocks = −479

In this benchmark it was chosen to test how the bandwidth consumptionschange with a completely new configuration represented in Table 6.3.

Algorithm H B Z S A num_covers num_cache

Shuffle Index: 3 50 1 1

Path Oram: 10 32

Ring Oram: 10 78 32 46 46

XRing Oram: 10 78 32 46 46

Table 6.3: New algorithms configurations

The meaning of this benchmark is to observe how the bandwidth con-sumptions change increasing the Path Oram bucket size to B = 32. Thisimplies, for Ring Oram and XRing Oram, a Z = 32 and new values for Aand S. For Shuffle Index, a new BShuffle = 50 and a ∆#Blocks = −479 wereobtained, following the constraints explained in the Comparison Criterionsection.Considerations:

• Shuffle Index vs Path Oram: it is clear that Shuffle Index is moreefficient than Path Oram. This happens because of two factors that arethe different height of the trees and the different node data structures.The advantage of having a shorter tree implies less nodes to read alonga path. Also, Shuffle Index reads (H − 2) · (num_cover + 1) internal

107


nodes before reading num_cover + 1 leaf nodes. The internal nodesare less big than a Path Oram node and this emphasises the efficiencyof Shuffle Index.

• Ring Oram vs XRing Oram: the bandwidth difference between thetwo algorithms is not so evident until the infoSize reaches dimensionsgreater than 256 bytes. At that point, it is clear that XRing Oramhas an advantage over Ring Oram, in terms of bandwidth saving. Thisemphasises the fact that the Xor trick makes sense only when theblocks size becomes significant and overcomes the bandwidth costs ofthe upload/download of initialization vectors.

• Ring/XRing Oram vs the others: in this benchmark it is evident theadvantage of managing blocks rather than nodes. The gap betweenRing Oram and XRing Oram, on one side, and the other two algo-rithms, on the other side, is huge. In the case with infoSize = 4B,where the gap is less wide, there is a bandwidth difference equal to:

∆Diff = BandShuffle −BandXRing =

= 150831, 06KB − 1540, 16KB = 149290, 9KB ≈ 149MB

This 149MB gap is calculated taking into account the best case be-tween Shuffle Index and Path Oram, on one side, and the worst casebetween Ring Oram and XRing Oram, on the other side. Note thatthis additional cost is paid for each Access phase.

108


1,00

10,00

100,00

1000,00

10000,00

100000,00

1000000,00

10000000,00

4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768

Log 1

0(B

and

wid

th[K

B])


Bandwidth Consimption


Figure 6.19: Bandwidth trend, ∆#Blocks = 328

This benchmark has the same settings as the previous one, with theonly difference that the height H of the binary trees is no more eleven, butthirteen. Also, the BShuffle parameter is adjusted obtaining a ∆#Blocks =

328, to have a comparable number of real blocks among the different datastructures.The chart confirms the overall trends of the algorithms seen in Figure 6.18.The main thing to highlight is the gap reduction at infoSize = 4B betweenShuffle Index and Path Oram. This phenomenon was already observed inFigure 6.17 and the reason is that in Shuffle Index there is a great increasein the BShuffle that affects the node data structures of the algorithm, andso the bandwidth, too.

109


110

Chapter 7

Conclusion

7.1 Summary

This thesis has required an intense study of privacy-preserving methodsfor outsourced data, the problems that afflict these systems and which so-lutions are feasible. As for many new subjects, there is a learning curve tofollow and, little by little, it has been possible to master the topic. Thedocumentation papers were fundamental, first, to build up the necessaryknowledge, second, to understand the differences among the algorithms.Starting from the pseudo-codes inside the papers, it was created an imple-mentation of each protocol using the C++ language. Sometimes the detailsweren’t clear enough and it has been necessary to return on the code mul-tiple times to adjust parameters, operations and make each algorithm workproperly. Also, the debugging phase has been quite complex due to therandomness of the Access function components, like the cover values, theremapping phase, the leaf remapping and the reshuffling of nodes.After this preparatory part, the next step was to benchmark the algorithmsin a proper way, without having miscalculation in the times taken duringthe execution. Also, there was the problem of how to perform the tests.The four algorithms share only few parameters between each other and ev-eryone has its proper constraints to hold. For instance, a wrong set up ofA,Z, S variables for Ring/XRing Oram has the potentiality to invalidateall the analysis of the benchmarks. Then, it was important to execute thetests in a smart way, adjusting with the setting parameters one by one. Also,

Conclusion

it was mandatory to prepare the computer for the calculation, without anyprogramme working in background, especially the ones that are I/O boundand that use the disk extensively.It was a step by step procedure that finally had, as a result, a completepicture of the behaviours of the algorithms.

7.2 Conclusion

From a pure time perspective, Path Oram has the best results over theother algorithms. In fact, it was always, at least, 1.5 times faster than theother systems, in all the configurations. Its simple access policy and thechoice to use a binary tree as cloud data structure have paid off and provenits validity. The drawback of Path Oram is its bandwidth consumption. Ina normal use case, where the information size is more than four bytes, theamount of data transferred per Access phase is very high. In fact, in the com-parison with the other algorithms, Path Oram has the highest bandwidthconsumption. Also, with a too high tree, Path Oram may slow down to reachthe same time performances as Shuffle Index. This happens because the Hparameter is the one that mostly affects the performances of Path Oram.In conclusion, the characteristic of this algorithm is to be very fast, but itsdownside is to consume a lot of bandwidth.Shuffle Index has shown interesting features because, with its unique clouddata structure, it can enlarge its tree rather than grow in height, like theother security systems. With a height H = 3, the algorithm guarantees thesecurity of the data and a balanced performance. In fact, it is the secondbest algorithm among the others and the third worst in bandwidth consump-tion. An optimal configuration for this algorithm can be a combination ofa relatively small bucket (B = 4) with a very wide tree. This because, forbandwidth saving reasons, it is better to have a not too large node size andsplit the information all over the tree. Also, doing that, it is possible toexploit the Shuffle Index characteristic: it hasn’t worst time performancesin the case of a wide tree data structure.Ring Oram and XRing Oram are an advanced version of Path Oram, butthey are focused on the bandwidth savings. This goal has led the authors ofthe system to preferring to download/upload blocks rather than entire nodes.

112

Conclusion

This has paid off in the bandwidth analysis, but the drawbacks were clearin the time performances. What is gained on one side, is lost on the other.Also, with their multiple settings parameters, it can be easier to choose awrong configuration. Ring Oram and XRing Oram have shown their bestbandwidth results in the analysis with a very large bucket size (Z = 32). Infact, with such large nodes, the advantage of managing blocks rather thannodes is clear. So, it is better for them to have a very large bucket size B,a good amount of real blocks Z and a lot of dummy blocks S. This is justi-fied by the fact that, with this kind of set up, the reshuffle procedure insideEarlyReshuffle is triggered less frequently. Furthermore, it is important todistinguish the results of Ring Oram and XRing Oram. From a time perfor-mance perspective, Ring Oram has always a lower average wall Access time.In the bandwidth analysis at equal configurations with a small infoSize RingOram surprisingly consumes less bandwidth than XRing Oram. In fact, forXRing Oram, the continuous exchange of initialization vectors, between theclient and the server, weighs more than downloading all the blocks along apath. XRing Oram starts to consume less bandwidth than Ring Oram onlywhen the infoSize increases considerably.The general conclusion about these four algorithms is that all of them guar-antee the privacy of data in external cloud environments. The main differ-ences between them are the time performances, the bandwidth consumptionand their optimal configuration. A client needs to choose if he prefers a fastalgorithm and paying a high bandwidth Internet communication channel,otherwise he can pick up a slower system but that consumes less bandwidth.Also, he must consider the dimension of the data to upload into the cloud andif it is possible to split them in multiple pieces. The evaluation of these threemain characteristics has as result the selection of one of the four algorithmspresented.

113

Conclusion

114

Bibliography

[1] Emil Stefanov, Marten van Dijk, Elaine Shi, Christopher Fletcher, LingRen, Xiangyao Yu, and Srinivas Devadas. Path oram: An extremelysimple oblivious ram protocol. In Proceedings of the 2013 ACM SIGSACConference on Computer & Communications Security, CCS ’13,pages 299–310, New York, NY, USA, 2013. ACM.

[2] Chang Liu, Liehuang Zhu, Mingzhong Wang, and Yu-An Tan. Searchpattern leakage in searchable encryption: Attacks and new construction.Inf. Sci., 265:176–188, May 2014.

[3] Sabrina De Capitani Di Vimercati, Sara Foresti, Stefano Paraboschi,Gerardo Pelosi, and Pierangela Samarati. Shuffle index: Efficient andprivate access to outsourced data. ACM Trans. Storage, 11(4):19:1–19:55,October 2015.

[4] Ling Ren, Christopher Fletcher, Albert Kwon, Emil Stefanov, ElaineShi, Marten van Dijk, and Srinivas Devadas. Constants count: Practicalimprovements to oblivious RAM. In 24th USENIX Security Symposium(USENIX Security 15), pages 415–430, Washington, D.C., 2015. USENIXAssociation.

[5] Jonathan Dautrich, Emil Stefanov, and Elaine Shi. Burst ORAM:Minimizing ORAM response times for bursty access patterns. In 23rdUSENIX Security Symposium (USENIX Security 14), pages 749–764, SanDiego, CA, 2014. USENIX Association.

[6] Elaine Shi, T.-H. Hubert Chan, Emil Stefanov, and Mingfei Li. ObliviousRAM with O((Log(N))3) Worst-case Cost. pages 197–214, 2011.

115

analysis and benchmarking of privacy-preserving …...of berkeley, california, published path oram...

Documents