diff --git a/.gitignore b/.gitignore
index 697714b441b0b83999df87f1e22e7aac0c7155cb..f9345d302aebe83b95ae63ca92c8ebe297cf520e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,5 +7,6 @@ dist/
*.idx
*.out
*.xdy
+*.vrb
.vscode/cspell.json
diff --git a/.vscode/settings.json b/.vscode/settings.json
index 426d20c85b455454b647366f12ef5e287be53ee8..314663037274c2f256cb030019e72d86ec25126c 100644
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -16,6 +16,7 @@
"Karp",
"Martello",
"Mendelsohn",
+ "Merkle",
"ORAM",
"Rainer",
"Silvano",
@@ -23,6 +24,7 @@
"Zwick",
"alertblock",
"allcaps",
+ "allowframebreaks",
"allsmallcaps",
"amsalpha",
"approxident",
@@ -35,6 +37,7 @@
"captionof",
"cheatsheets",
"chktex",
+ "citeauthor",
"colback",
"colframe",
"colsep",
@@ -85,12 +88,14 @@
"orams",
"parametrization",
"preflow",
+ "printbibliography",
"printf",
"progressbar",
"providecommand",
"psmatrix",
"psset",
"rearrangeable",
+ "recurse",
"scalebox",
"smallcaps",
"sqcases",
@@ -101,6 +106,7 @@
"tcblower",
"tcolorbox",
"textasciitilde",
+ "textcite",
"titlecodebox",
"titleformat",
"toprule",
diff --git a/bibfile.bib b/bibfile.bib
index b098c38d3a788d5211ef3d075c2e848a225a3047..7470449cabb7b8987d4010098818ac53f17c2c75 100644
--- a/bibfile.bib
+++ b/bibfile.bib
@@ -62,15 +62,25 @@
URL = {http://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-89.html},
Number = {UCB/EECS-2014-89},
Abstract = {
- Confidentiality of data is a major problem as sensitive computations migrate to the cloud. Employees in a data center have physical access to machines and can carry out attacks that have traditionally only affected client-side crypto-devices such as smartcards. For example, an employee can snoop confidential data as it moves in and out of the processor to learn secret keys or other program information that can be used for targeted attacks.
+ Confidentiality of data is a major problem as sensitive computations migrate to the cloud.
+ Employees in a data center have physical access to machines and can carry out attacks that have traditionally only affected client-side crypto-devices such as smartcards.
+ For example, an employee can snoop confidential data as it moves in and out of the processor to learn secret keys or other program information that can be used for targeted attacks.
- Secure processors have been proposed as a counter-measure to these attacks -- such processors are physically shielded and enforce confidentiality by encrypting all data outside the chip, e.g. in DRAM or non-volatile storage. While first proposals were academic in nature, this model is now starting to appear commercially, such as in the Intel SGX extensions.
+ Secure processors have been proposed as a counter-measure to these attacks --- such processors are physically shielded and enforce confidentiality by encrypting all data outside the chip, e.g. in DRAM or non-volatile storage.
+ While first proposals were academic in nature, this model is now starting to appear commercially, such as in the Intel SGX extensions.
- Although secure processors encrypt all data as it leaves the CPU, the memory addresses that are being accessed in DRAM are still transmitted in plaintext on the address bus. This represents an important source of information leakage that enables serious attacks that can, in the worst case, leak bits of cryptographic keys. To counter such attacks, we introduce PHANTOM, a new secure processor that obfuscates its memory access trace. To an adversary who can observe the processor's output pins, all memory access traces are computationally indistinguishable (a property known as obliviousness). We achieve obliviousness through a cryptographic construct known as Oblivious RAM (ORAM).
+ Although secure processors encrypt all data as it leaves the CPU, the memory addresses that are being accessed in DRAM are still transmitted in plaintext on the address bus.
+ This represents an important source of information leakage that enables serious attacks that can, in the worst case, leak bits of cryptographic keys.
+ To counter such attacks, we introduce PHANTOM, a new secure processor that obfuscates its memory access trace.
+ To an adversary who can observe the processor's output pins, all memory access traces are computationally indistinguishable (a property known as obliviousness).
+ We achieve obliviousness through a cryptographic construct known as Oblivious RAM (ORAM).
- Existing ORAM algorithms introduce a large (100-200x) overhead in the amount of data moved from memory, which makes ORAM inefficient on real-world workloads. To tackle this problem, we develop a highly parallel ORAM memory controller to reduce ORAM memory access latency and demonstrate the design as part of the PHANTOM secure processor, implemented on a Convey HC-2ex. The HC-2ex is a system that comprises an off-the-shelf x86 CPU paired with 4 high-end FPGAs with a highly parallel memory system.
+ Existing ORAM algorithms introduce a large (100-200x) overhead in the amount of data moved from memory, which makes ORAM inefficient on real-world workloads.
+ To tackle this problem, we develop a highly parallel ORAM memory controller to reduce ORAM memory access latency and demonstrate the design as part of the PHANTOM secure processor, implemented on a Convey HC-2ex.
+ The HC-2ex is a system that comprises an off-the-shelf x86 CPU paired with 4 high-end FPGAs with a highly parallel memory system.
- Our novel ORAM controller aggressively exploits the HC-2ex's high DRAM bank parallelism to reduce ORAM access latency and scales well to a large number of memory channels. PHANTOM is efficient in both area and performance: accessing 4KB of data from a 1GB ORAM takes 26.2us (13.5us until the data is available), a 32x slowdown over accessing 4KB from regular memory, while SQLite queries on a population database see 1.2-6x slowdown.
+ Our novel ORAM controller aggressively exploits the HC-2ex's high DRAM bank parallelism to reduce ORAM access latency and scales well to a large number of memory channels.
+ PHANTOM is efficient in both area and performance: accessing 4KB of data from a 1GB ORAM takes 26.2us (13.5us until the data is available), a 32x slowdown over accessing 4KB from regular memory, while SQLite queries on a population database see 1.2-6x slowdown.
}
}
@@ -125,4 +135,69 @@
acmid = {2452397},
publisher = {ACM},
address = {New York, NY, USA},
-}
\ No newline at end of file
+}
+
+@inbook{Shi:2011,
+ author = {Shi, Elaine and Chan, T. -H. Hubert and Stefanov, Emil and Li, Mingfei},
+ title = {Oblivious RAM with ${O}( \log^3 {N} )$ Worst-Case Cost},
+ bookTitle = {Advances in Cryptology -- ASIACRYPT 2011: 17th International Conference on the Theory and Application of Cryptology and Information Security, Seoul, South Korea, December 4-8, 2011. Proceedings},
+ year = {2011},
+ publisher = {Springer Berlin Heidelberg},
+ address = {Berlin, Heidelberg},
+ pages = {197--214},
+ abstract = {
+ Oblivious RAM is a useful primitive that allows a client to hide its data access patterns from an untrusted server in storage outsourcing applications.
+ Until recently, most prior works on Oblivious RAM aim to optimize its amortized cost, while suffering from linear or even higher worst-case cost.
+ Such poor worst-case behavior renders these schemes impractical in realistic settings, since a data access request can occasionally be blocked waiting for an unreasonably large number of operations to complete.
+ },
+ isbn = {978-3-642-25385-0},
+ doi = {10.1007/978-3-642-25385-0_11},
+ url = {https://doi.org/10.1007/978-3-642-25385-0_11}
+}
+
+@article{DBLP:journals/corr/abs-1106-3652,
+ author = {Emil Stefanov and Elaine Shi and Dawn Song},
+ title = {Towards Practical Oblivious {RAM}},
+ journal = {CoRR},
+ volume = {abs/1106.3652},
+ year = {2011},
+ url = {http://arxiv.org/abs/1106.3652},
+ archivePrefix = {arXiv},
+ eprint = {1106.3652},
+ pages = {1--40},
+ timestamp = {Wed, 07 Jun 2017 14:40:50 +0200},
+ biburl = {http://dblp.org/rec/bib/journals/corr/abs-1106-3652},
+ bibsource = {dblp computer science bibliography, http://dblp.org}
+}
+
+@inbook{Gentry:2013,
+ author = {Gentry, Craig and Goldman, Kenny A. and Halevi, Shai and Julta, Charanjit and Raykova, Mariana and Wichs, Daniel},
+ title = {Optimizing ORAM and Using It Efficiently for Secure Computation},
+ bookTitle = {Privacy Enhancing Technologies: 13th International Symposium, PETS 2013, Bloomington, IN, USA, July 10-12, 2013. Proceedings},
+ year = {2013},
+ publisher = {Springer Berlin Heidelberg},
+ address = {Berlin, Heidelberg},
+ pages = {1--18},
+ abstract = {
+ Oblivious RAM (ORAM) allows a client to access her data on a remote server while hiding the access pattern (which locations she is accessing) from the server.
+ Beyond its immediate utility in allowing private computation over a client's outsourced data, ORAM also allows mutually distrustful parties to run secure-computations over their joint data with sublinear on-line complexity.
+ In this work we revisit the tree-based ORAM of Shi et al. and show how to optimize its performance as a stand-alone scheme, as well as its performance within higher level constructions.
+ },
+ isbn = {978-3-642-39077-7},
+ doi = {10.1007/978-3-642-39077-7_1},
+ url = {https://doi.org/10.1007/978-3-642-39077-7_1}
+}
+
+@article{DBLP:journals/corr/abs-1105-4125,
+ author = {Michael T. Goodrich and Michael Mitzenmacher and Olga Ohrimenko and Roberto Tamassia},
+ title = {Privacy-Preserving Group Data Access via Stateless Oblivious {RAM} Simulation},
+ journal = {CoRR},
+ volume = {abs/1105.4125},
+ year = {2011},
+ url = {http://arxiv.org/abs/1105.4125},
+ archivePrefix = {arXiv},
+ eprint = {1105.4125},
+ timestamp = {Wed, 07 Jun 2017 14:41:08 +0200},
+ biburl = {http://dblp.org/rec/bib/journals/corr/abs-1105-4125},
+ bibsource = {dblp computer science bibliography, http://dblp.org}
+}
diff --git a/build.sh b/build.sh
index 756572f780d564ee462459dcc5f7caa1a889770b..016db47931f739a2add9716574d88b7aabc1b80d 100755
--- a/build.sh
+++ b/build.sh
@@ -74,7 +74,7 @@ log "DEBUG = ${DEBUG}"
echo "Cleaning up workspace"
-rm -f ${OUTDIR}/${JOBNAME}.pdf
+rm -f ${OUTDIR}/${JOBNAME}.{pdf,aux,log,out,xwm,toc,nav,snm,bbl,blg,vrb}
mkdir -p ${OUTDIR}
log "Done."
@@ -99,7 +99,7 @@ do
if [ "$j" == "1" ]
then
- bibtex ${OUTDIR}/${JOBNAME}
+ biber ${OUTDIR}/${JOBNAME}
fi
done
@@ -107,7 +107,7 @@ log "Done."
echo "Removing build files..."
-rm -f ${OUTDIR}/*.{aux,log,out,xwm,toc,nav,snm,bbl,blg}
+rm -f ${OUTDIR}/*.{aux,log,out,xwm,toc,nav,snm,bbl,blg,vrb}
log "Done."
diff --git a/main.tex b/main.tex
index 99560d710bc110cd735ce989c7fa1b33b1047c9c..f6c0548ef0af7358aaaa88de554b634aa21bec46 100644
--- a/main.tex
+++ b/main.tex
@@ -13,7 +13,12 @@
\maketitle
\begin{frame}{Table of Contents}
- \tableofcontents
+
+ \begin{multicols}{2}
+
+ \tableofcontents
+
+ \end{multicols}
\note{
\begin{itemize}
@@ -39,12 +44,15 @@
\input{sections/conclusion}
\begin{frame}[standout]
+
Questions?
+
\end{frame}
- \begin{frame}{References}
- \bibliographystyle{amsalpha}
- \bibliography{bibfile}
+ \begin{frame}[allowframebreaks]{References}
+
+ \printbibliography%
+
\end{frame}
\maketitle
diff --git a/packages.tex b/packages.tex
index ed46c981561ab73240f6ac38309926855934641b..c684452f5187279f3b93db94ef7299df9a3860db 100644
--- a/packages.tex
+++ b/packages.tex
@@ -7,3 +7,12 @@
\usepackage{mathtools}
\usepackage{listings}
\usepackage{fancybox}
+\usepackage{bm}
+\usepackage{multicol}
+\usepackage{xpatch}
+
+\usepackage[
+ backend=biber,
+ style=alphabetic,
+ sorting=ynt
+]{biblatex}
diff --git a/preamble.tex b/preamble.tex
index 1c4edcd07b3b18753c7ee285dca113805cbc29f1..951e5eb89f30e25bcbbd570b14475d4131a3e16d 100644
--- a/preamble.tex
+++ b/preamble.tex
@@ -27,6 +27,8 @@
]{static/logo.eps}\hspace{325pt}\vspace{-30pt}
}
+\addbibresource{bibfile.bib}
+
\makeatletter
\def\beamer@framenotesbegin{% at beginning of slide
\usebeamercolor[fg]{normal text}
@@ -59,3 +61,9 @@
}
\newsavebox{\mybox}
+
+\xpatchbibmacro{name:andothers}{%
+ \bibstring{andothers}%
+}{%
+ \bibstring[\emph]{andothers}%
+}{}{}
diff --git a/sections/applications-and-extensions.tex b/sections/applications-and-extensions.tex
index ec6d6c7efeb4221e68093cb648071285cfdc44ae..a9dd690e113b2214dc950758249a73fad87c64f9 100644
--- a/sections/applications-and-extensions.tex
+++ b/sections/applications-and-extensions.tex
@@ -1 +1,52 @@
+% cSpell:ignore DBLP FPGAs
+% cSpell:ignoreRegExp /textcite{.*}/
+% cSpell:ignoreRegExp /cite{.*}/
+
\section{Applications and extensions}
+
+ \begin{frame}{Oblivious Binary Search Tree}
+
+ PathORAM can be used to perform search on an oblivious binary search tree, using $\BigO{\log^2 N}$ bandwidth.~\cite{Gentry:2013}
+
+ \note{
+ TODO
+ }
+ \end{frame}
+
+ \begin{frame}{Stateless ORAM}
+
+ In order to avoid complicated (and possibly expensive) oblivious state synchronization between the clients, \citeauthor{DBLP:journals/corr/abs-1105-4125} introduce the concept of stateless ORAM~\cite{DBLP:journals/corr/abs-1105-4125} where the client state is small enough so that any client accessing the ORAM can download it before each data access and upload it afterwards.
+
+ \note{
+ If we are using recursive PathORAM, we can upload and download client state --- which is $\BigO{\log N} \cdot \omega (1)$ --- before each access.
+ This ways we can build a \emph{stateless} ORAM --- potentially, multi-user ORAM\@.
+ }
+ \end{frame}
+
+ \begin{frame}{Secure Processors}
+
+ PathORAM is particularly amenable to hardware design because of its simplicity and low on-chip storage requirements.
+
+ For example,~\textcite{Maas:EECS-2014-89} built a hardware implementation of a Path ORAM based secure processor using FPGAs and the Convey platform. % chktex 8
+
+ \note{
+ Due to its simplicity, PathORAM is particularly good for silicon implementations.
+ For example, Martin Mass has build such implementation using FPGAs.
+ }
+ \end{frame}
+
+ \begin{frame}{Integrity}
+
+ The protocol can be easily extended to provide integrity (with freshness) for every access to the untrusted server storage.
+
+ We can achieve integrity by simply treating the Path ORAM tree as a \emph{Merkle tree} where data is stored in all nodes of the tree.
+
+ \[
+ H (b_1 || b_2 || \ldots || b_Z || h_1 || h_2 )
+ \]
+
+ \note{
+ It is possible to treat PAthORAM internal tree structure as a Merkle tree.
+ Each node is tagged with the hash of the following form, which is a concatenation of hashes of all blocks in the bucket, and left and right child of the node.
+ }
+ \end{frame}
diff --git a/sections/bounds-on-stash-usage.tex b/sections/bounds-on-stash-usage.tex
index cfd30afc657040f9f842cd9c5017405e80c59e1d..d75668d32bf3aa09f5d63620d72aa82aef3f216d 100644
--- a/sections/bounds-on-stash-usage.tex
+++ b/sections/bounds-on-stash-usage.tex
@@ -1 +1,50 @@
\section{Bounds on stash usage}
+
+ \begin{frame}{Probability of failure is negligible}
+
+ \begin{block}{Main theorem}
+
+ Let $\bm{a}$ be any sequence of block addresses with a working set of size at most $N$.
+ For a bucket size $Z = 5$, tree height $L = \ceil{\log N}$ and stash size $R$, the probability of a PathORAM failure after a sequence of load/store operations corresponding to $\bm{a}$, is at most
+
+ \[
+ \Pr \left[ \text{st} \left( \text{ORAM}_L^5 [ \bm{s} ] \right) > R | a( \bm{s} ) = \bm{a} \right] \le 14 \cdot (0.6002)^R
+ \]
+
+ where the probability is over the randomness that determines $\bm{x}$ and $\bm{y}$ in $\bm{s = (a, x, y)}$.
+
+ \end{block}
+
+ \note{
+ The whole proof of negligible failure probability is about proving this theorem.
+ It might look complex, but simply put, what is says is that for any ORAM with 5 blocks per bucket, stash usage exceeds some stash size $R$ with probability at most exponentially small with respect ot $R$.
+
+ Or, even simpler, the probability of exceeding stash capacity decreases exponentially with the stash size, given that the bucket size $Z$ is large enough.
+
+ The authors prove this theorem in three steps.
+ }
+ \end{frame}
+
+ \begin{frame}{Probability of failure is negligible}
+
+ \begin{block}{Proof outline}
+
+ \begin{enumerate}
+ \item
+ Introduce a second ORAM, called $\infty$-ORAM
+ \item
+ Characterize the distributions of real blocks over buckets in a $\infty$-ORAM for which post-processing leads to a stash usage $> R$
+ \item
+ Analyze the usage of subtrees $T$ (introduced in the proof)
+ \end{enumerate}
+
+ \end{block}
+
+ \note{
+ First, they introduce a second ORAM, called $\infty$-ORAM, together with an algorithm that post-processes the stash and buckets of $\infty$-ORAM in such a way that the blocks over buckets distribution of $\infty$-ORAM and real ORAM are the same.
+
+ Second, they show that the stash usage after post-processing is $> R$ if and only if there exists a subtree $T$ for which its ``usage'' in $\infty$-ORAM is more than its ``capacity''.
+
+ Finally, they show how a mixture of a binomial and a geometric probability distribution expresses the probability of the number of real blocks that do not get evicted from a subtree after a sequence of load/store operations.
+ }
+ \end{frame}
diff --git a/sections/path-oram-protocol.tex b/sections/path-oram-protocol.tex
index b1bdc74b5eb5499316c249d39e12acd0efff35cd..b62d78390ff5b8f42c42f89df3b03dfa134aefe4 100644
--- a/sections/path-oram-protocol.tex
+++ b/sections/path-oram-protocol.tex
@@ -262,20 +262,20 @@
}
\end{frame}
-\begin{frame}{Complexity}
-
- \begin{block}{Computation}
- Client's computation is $\BigO{\log N} \cdot \omega (1)$ per data access.
- We treat the server as a network storage device, so it only needs to do the computation necessary to retrieve and store $\BigO{\log N}$ blocks per data access.
- \end{block}
+ \begin{frame}{Complexity}
+
+ \begin{block}{Computation}
+ Client's computation is $\BigO{\log N} \cdot \omega (1)$ per data access.
+ We treat the server as a network storage device, so it only needs to do the computation necessary to retrieve and store $\BigO{\log N}$ blocks per data access.
+ \end{block}
- \note{
- Each access the client reads and writes the whole path, which is order of $\log N$ in size.
- It re-encrypts each block, so the total complexity is $\BigO{\log N} \cdot \omega (1)$.
+ \note{
+ Each access the client reads and writes the whole path, which is order of $\log N$ in size.
+ It re-encrypts each block, so the total complexity is $\BigO{\log N} \cdot \omega (1)$.
- Server, on the other hand, does not perform encryption, so its complexity is $\BigO{\log N}$.
- }
-\end{frame}
+ Server, on the other hand, does not perform encryption, so its complexity is $\BigO{\log N}$.
+ }
+ \end{frame}
%%% fragile frame
\begin{frame}[fragile]{Full algorithm}
@@ -303,3 +303,25 @@
\end{frame}
%%% end fragile frame
+
+ \begin{frame}{Security analysis}
+
+ \begin{gather*}
+ \bm{p} = \left( \text{position}_M [a_M], \text{position}_{M-1} [a_{M-1}], \ldots , \text{position}_1 [a_1] \right) \\
+ \Pr [ \bm{p} ] = \left( \frac{1}{2^L} \right)^M
+ \end{gather*}
+
+ \begin{itemize}
+ \item
+ The sequence of encrypted paths is computationally indistinguishable from a random sequence of bit strings
+ \item
+ $A(\vec{y})$ is computationally indistinguishable from a random sequence of bit strings
+ \end{itemize}
+
+ \note{
+ Our definition of security requires that the access pattern is indistinguishable from random.
+ Encrypted paths look random enough by the definition of security --- and we use randomized encryption since deterministic one does not even satisfy chosen plaintext attack security.
+ The access pattern is random enough since the probability of a particular access is $\frac{1}{2^L}$ --- uniform in the number of blocks because each access the position table is re-randomized.
+ For $M$ access, the probability is even smaller by the Bayes rule.
+ }
+ \end{frame}
diff --git a/sections/recursion-and-parametrization.tex b/sections/recursion-and-parametrization.tex
index a25c6e4d30f62bf4879cec0bba585ac74ed0878c..12a62e20b09efe3c8f261b7709ec4ad6df946a1c 100644
--- a/sections/recursion-and-parametrization.tex
+++ b/sections/recursion-and-parametrization.tex
@@ -1 +1,27 @@
+% cSpell:ignore DBLP
+
\section{Recursion and parametrization}
+
+ \begin{frame}{Recursion technique}
+
+ In our non-recursive scheme described in the previous section, the client must store a relatively large position map.
+
+ The idea is simple: instead of storing the position map on the client side, we store the position map on the server side in a smaller ORAM, and recurse~\cite{Shi:2011, DBLP:journals/corr/abs-1106-3652}.
+
+ \note{
+ One of the ways to make the client even thinner is to use recursion.
+ Zero-level ORAM contains data blocks, the position map of $i_\text{th}$ ORAM is stored in the ${(i+1)}_\text{st}$ ORAM, and the client stores the position map for the last ORAM\@.
+ The access to a block in a zero-level ORAM triggers recursive calls all up to the last ORAM\@.
+ }
+ \end{frame}
+
+ \begin{frame}{Shared Stash}
+
+ The client storage for the recursive PathORAM construction (with non-uniform block sizes) can be reduced from $\BigO{\log^2 N} \cdot \omega (1)$ to $\BigO{\log N} \cdot \omega (1)$ by having a \emph{single stash} shared among all levels of the recursion.
+ This is possible while still maintaining a negligible probability of stash overflow.
+
+ \note{
+ It is proven in the paper that we do not need to have separate stash for every level of recursion to maintain negligible probability of failure.
+ Having single stash reduces client storage by the order of $\log N$.
+ }
+ \end{frame}