Commit 485e219c authored by Xunnamius (Zara)'s avatar Xunnamius (Zara)

cleared new TODOs, reorganized contributions in early sections

parent d7b971dc
......@@ -10,8 +10,9 @@ switching} in space or time. We implement SwitchCrypt on an ARM big.LITTLE
mobile processor and test its performance under the popular F2FS LFS. We provide
empirical results demonstrating the conditions under which different switching
strategies are optimal and explore four related cases. We find that SwitchCrypt
achieves at least 3.3x in total energy use reduction and a 1.6x to 4.8x
reduction in I/O latency in our cases when compared to static approaches.
achieves at least 3.3x in total energy use reduction, remaining within our
energy budget, and a 1.6x to 4.8x reduction in I/O latency in our cases when
compared to static approaches.
\end{abstract}
......@@ -36,5 +37,6 @@ We provide empirical results that demonstrate the conditions under which
different switching strategies would be optimal. We then study SwitchCrypt's
dynamic flexibility through four case studies where latency, energy, and desired
security properties change dynamically. We find that SwitchCrypt achieves at
least 3.3x in total energy use reduction and a 1.6x to 4.8x reduction in I/O
latency in our cases when compared to static approaches.}
least 3.3x in total energy use reduction, remaining within our energy budget,
and a 1.6x to 4.8x reduction in I/O latency in our cases when compared to static
approaches.}
......@@ -69,26 +69,26 @@ another configuration becomes more desirable later on?}\\
\\
\textbf{Our Contributions}\\
To realize the goal of flexibly adjusting storage tradeoffs, we first introduce
a scheme to \emph{quantify} the usefulness or relative ``strength'' of ciphers
a novel design substantively expanding prior FDE work by \emph{decoupling}
cipher implementations from the encryption process. We then introduce the idea
of cipher switching using \emph{switching strategies} to ``re-cipher'' storage
units dynamically with acceptable overhead. Finally, we take advantage of cipher
switching with a scheme to \emph{quantify} the relative strength of ciphers
based on key security properties relevant to FDE. We call these ``security
scores.'' Using these security scores, we define a tradeoff space of cipher
configurations over competing concerns: total energy use, desirable security
properties in the FDE context, read and write performance, total writable space
on the drive, and how quickly the drive can converge to a single configuration.
Finally, we present SwitchCrypt, a novel design substantively expanding prior
FDE work by \emph{decoupling} cipher implementations from encryption and
employing various \emph{switching strategies} to ``re-cipher'' those units
dynamically with acceptable overhead. \TODO{I just realized the order on these
contributions is wrong. The security scores come at the end now. In fact,
I think the whole paragraph needs a rewrite to reflect the updated
structure of section 3 (and the challenges at the end of section 2).}
We implement SwitchCrypt and three switching strategies---\emph{Forward},
\emph{Selective}, and \emph{Mirrored}---to dynamically change between the ChaCha
and Freestyle stream ciphers using our novel API. We then study SwitchCrypt's
dynamic flexibility through four case studies where latency, energy, and desired
security properties change dynamically. SwitchCrypt achieves a reduction of at
least 3.3x in total energy use when compared to static approaches; further, we
see a reduction of 3.1x to 4.8x for read latency and 1.6x to 2.8x for write
latency compared to static approaches that must pick a single point in the
latency/energy/security tradeoff space.
Unifying these contributions, we present SwitchCrypt, a software mechanism that
navigates the tradeoff space made by balancing competing security and latency
requirements via cipher switching in space or time. We implement SwitchCrypt and
three switching strategies---\emph{Forward}, \emph{Selective}, and
\emph{Mirrored}---to dynamically change between the ChaCha and Freestyle stream
ciphers using our novel API. We then study SwitchCrypt's flexibility through
four case studies where latency, energy, and desired security properties change
dynamically. SwitchCrypt achieves a reduction of at least 3.3x in total energy
use when compared to static approaches; further, we see a reduction of 3.1x to
4.8x for read latency and 1.6x to 2.8x for write latency compared to static
approaches that must pick a single point in the latency/energy/security tradeoff
space.
......@@ -51,22 +51,13 @@ container or restart the device.
The above is possible if---rather than restricting the system to a single
cipher---we could flexibly encrypt data with a range of ciphers and
cryptographic keys at the block level. To achieve this, we must address three
challenges. First, we must reason about why we use one cipher over another. This
requires we \emph{quantify} the desirable security properties of different
ciphers. Second, we must understand how to flexibly encrypt independent storage
units efficiently. This requires we \emph{decouple} cipher implementations from
the encryption. Third, we need to know when to ``re-cipher'' those units and
where to store the output, ensuring acceptable overhead. We accomplish this with
our \emph{switching strategies}.
\textbf{Quantifying ciphers with disparate security properties.} To obtain a
configuration space that we might reason about, it is necessary to score certain
security properties of stream ciphers. This is challenging since different
ciphers have a wide range of disparate security properties, including ciphers
that are not length-preserving in their output. To address this challenge, we
propose a method for quantitative cipher comparison in the FDE context and use
it to define our configuration space. These cipher configurations, each with
different strengths, answer ``why'' we might prefer one over another.
challenges. First, we must understand how to flexibly encrypt independent
storage units efficiently. This requires we \emph{decouple} cipher
implementations from the encryption. Second, we need to know when to
``re-cipher'' those units and where to store the output, ensuring acceptable
overhead. We accomplish this with our \emph{switching strategies}. Third, we
must reason about why to use one cipher over another. This requires we
\emph{quantify} the desirable security properties of different ciphers.
\textbf{Decoupling ciphers from encryption for mixed-cipher layouts.} To rapidly
switch ciphers for the drive, we require a \emph{generic cipher API} and
......@@ -80,13 +71,21 @@ logical blocks (nuggets) from physical drive and other storage blocks. And since
they are independent, we can use our cipher API to select any cipher to encrypt
or decrypt any nugget at any point, answering the ``how'' of switching ciphers.
\textbf{Strategies to switch nugget ciphers with acceptable overhead.} Finally,
to answer ``when'' to switch a nugget's cipher and to ``where'' we commit the
output, we implement a series of policies we call \textit{cipher switching
strategies} that leverage the generic cipher API and drive layout to selectively
``re-cipher'' groups of nuggets, whereby the key and the cipher used to
encrypt/decrypt a nugget are switched at runtime. These strategies allow us to
navigate our configuration tradeoff space and settle on optimal points
unreachable with prior work. The challenge here is to accomplish this while
minimizing overhead.
\textbf{Strategies to switch nugget ciphers with acceptable overhead.} To answer
``when'' to switch a nugget's cipher and to ``where'' we commit the output, we
implement a series of policies we call \textit{cipher switching strategies} that
leverage the generic cipher API and drive layout to selectively ``re-cipher''
groups of nuggets, whereby the key and the cipher used to encrypt/decrypt a
nugget are switched at runtime. These strategies allow us to navigate our
configuration tradeoff space and settle on optimal points unreachable with prior
work. The challenge here is to accomplish this while minimizing overhead.
\textbf{Quantifying ciphers with disparate security properties.} Finally, to
obtain a configuration space that we might reason about, it is necessary to
score certain security properties of stream ciphers. This is challenging since
different ciphers have a wide range of disparate security properties, including
ciphers that are not length-preserving in their output. To address this
challenge, we propose a method for quantitative cipher comparison in the FDE
context and use it to define our configuration space. These cipher
configurations, each with different strengths, answer ``why'' we might prefer
one over another.
......@@ -53,10 +53,11 @@ finish before the devices dies. Further, when we get our device to a charger,
SwitchCrypt can converge nuggets back to Freestyle Balanced.
On average, using Forward cipher switching resulted in a 3.3x total energy use
reduction. We note, however, that the energy savings is not the point of this
experiment. Rather, the lesson learned is that SwitchCrypt enables the system
to move to the right point in the energy/security tradeoff space that the
current task can still be accomplished before the battery is drained.
reduction, allowing us to remain within our energy budget. We note, however,
that the energy savings is not the point of this experiment. Rather, the lesson
learned is that SwitchCrypt enables the system to move to the right point in the
energy/security tradeoff space that the current task can still be accomplished
before the battery is drained.
\subsection{Variable Security Regions}\label{subsec:uc2}
......
......@@ -26,13 +26,19 @@ various cipher configurations dynamically.
However, trading off security for energy, performance, and other concerns is not
a new idea~\cite{ScalableSecurity, WolterReinecke, ZengChow1, ZengChow2,
HaleemEtAl, LiOmiecinski}. For instance, Goodman et al. introduced trading
security for decreased energy dissipated to encrypt a bit back in
1998~\cite{ScalableSecurity}. Similar in intent to VSRs and the Selective
strategy (see \secref{usecases}), Goodman minimizes energy consumption by
separating low-priority data from high-priority and encrypting them differently. \TODO{Was Goodman's approach just for communication? We need to say more about what makes your work unique. For example: "Goodman et al.'s approach is designed for communication and only considered changing key lengths, thus it did not anticipate the need for SwitchCrypt's generic API, switching strategies, or security scores."}
Further, Wolter and Reinecke study performance and security tradeoffs, exploring
approaches to quantifying security~\cite{WolterReinecke}. \TODO{Again, need to say something more to differentiate us. Something like: "This study anticipates the value of dynamically switching ciphers but proposes no mechanisms to actually enable this switch."}
HaleemEtAl, LiOmiecinski}. For instance, Goodman et al. (1998) introduced
trading decreased security for saving energy dissipated to encrypt a bit during
wireless communication~\cite{ScalableSecurity}. Similar in intent to VSRs,
Goodman minimizes energy consumption by separating low-priority communications
from high-priority and encrypting them differently. Goodman et al.'s approach is
designed for communication and only considered changing key lengths, thus it did
not anticipate the need for SwitchCrypt's generic API, switching strategies, or
security scores. Further, Wolter and Reinecke study performance and security
tradeoffs, exploring approaches to quantifying security in several
contexts~\cite{WolterReinecke}. \TODO{Again, need to say something more to
differentiate us. Something like: "This study anticipates the value of
dynamically switching ciphers but proposes no mechanisms to actually enable this
switch."}
In the wild, companies like Google~\cite{AndroidM} and Apple~\cite{iOSFDE} have
explored performance-security tradeoffs in hardware when considering FDE
......
......@@ -15,7 +15,7 @@
%balancing seemingly conflicting operational requirements. We hope
%that this work inspires further research into achieving this balance,
%including both mechanisms and policies for exposing and navigating
%the underlying tradeoff spaces.
%the underlying tradeoff spaces. TODO
Stream ciphers are fast and offer strong security properties, but optimizing for
performance often conflicts with other key concerns. In this paper we presented
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment