Commit 9734a59e authored by Xunnamius (Zara)'s avatar Xunnamius (Zara)

everything cleared except sprinkling in last overhead todos

parent 485e219c
......@@ -4,12 +4,11 @@ There are several important concerns modern filesystems must balance. Paramount
among them are data security and performance. Increasingly important is energy
consumption in both mobile devices and in enterprise storage
\cite{android-M-mobile-motivation, enterprise-motivation}. However, all of these
concerns exist in contention with one another: stronger security properties can
harm latency and require increased energy use, while reducing energy consumption
will generally require increasing latency or accepting weaker security
properties.
concerns exist in contention: stronger security properties can harm latency and
increase energy use, while reducing energy consumption typically requires
increasing latency or accepting weaker security properties.
The state of the art for securing data is Full-Drive Encryption (FDE).
The state of the art for securing data is Full Drive Encryption (FDE).
Traditional FDE employs a single \emph{cryptographic cipher} to encrypt,
decrypt, and authenticate backing store contents on the fly. Understandably,
this process impacts system performance and energy use considerably. Yet, end
......@@ -28,14 +27,14 @@ random read performance, a 50.5\% drop in random write performance, and a
staggering 80.7\% drop in sequential read
performance''~\cite{android-M-mobile-motivation-2}.
Traditionally, FDE's impact on drive performance and energy efficiency depends
on choice of filesystem/mapper and the choice of cipher, as different ciphers
expose different performance and efficiency characteristics while offering
contrasting security properties. In this way, cipher choice can be viewed as a
key \emph{configuration} parameter for FDE systems. The tradeoffs of choosing a
cipher include: 1) increased system performance (\ie{overall reduced FDE
overhead}), 2) reduced energy use, and 3) the ability to encrypt devices that
would otherwise be too slow or energy-inefficient to support FDE.
FDE's impact on drive performance and energy efficiency depends on choice of
filesystem/mapper and the choice of cipher, as different ciphers expose
different performance and efficiency characteristics. In this way, cipher choice
can be viewed as a key \emph{configuration} parameter for FDE systems. The
tradeoffs of choosing a cipher include: 1) increased system performance
(\ie{overall reduced FDE overhead}), 2) reduced energy use, and 3) the ability
to encrypt devices that would otherwise be too slow or energy-inefficient to
support FDE.
However, the de facto standard choice for FDE is the slow AES \emph{block
cipher} (AES-XTS)~\cite{AES, AES-XTS}. Prior research introduced the motivation
......@@ -58,7 +57,7 @@ drive space.
Further, while the cipher choice can be configured statically at compile- or
boot-time with respect to some common-case, in traditional FDE, these
configurations cannot adapt to changes that might arise while the system is
configurations cannot adapt to changes that arise while the system is
running. Examples include changes in resource availability, runtime environment,
desired security properties, and adhering to changing OS energy budgets.
......
......@@ -48,27 +48,26 @@ API}.
The \emph{merkle tree} ensures the integrity of all data on a per-nugget level.
The \emph{keycount store} keeps track of each nugget's 64-bit cryptographic key.
The \emph{transaction journal} keeps track of writes to nuggets, allowing
SwitchCrypt to detect and respond to overwrites. The \emph{monotonic counter}
prevents the system state from being rolled back. The \emph{per-nugget
metadata} is a drive-backed array where extra cryptographic material is stored
depending on the cipher used to encrypt the nugget. The size of the array is
determined by ciphers loaded through the \emph{generic stream cipher API}.
SwitchCrypt to detect and respond to overwrites. The \emph{monotonic counter}
prevents the system state from being rolled back. The \emph{per-nugget metadata}
is a drive-backed array where extra cryptographic material is stored depending
on the cipher used to encrypt the nugget. The size of the array is determined by
ciphers loaded through the \emph{generic stream cipher API}.
\subsection{Generic Stream Cipher API} \label{subsec:api}
There are \emph{many} ciphers we might use with SwitchCrypt, each with various
input requirements and output considerations. A key difference with prior work
is that SwitchCrypt
must be able to encrypt and decrypt arbitrary nuggets without worrying about a
cipher's implementation details; prior approaches could have cipher-specific
implementations because they did not consider switching.
Thus, the cipher-specific details
must be handled with care or security is violated. With our
novel cipher API, we present an interface that \emph{decouples} cipher
implementations from the encryption/decryption process. This allows any cipher
to be integrated into SwitchCrypt without modification or special
considerations. Hence, different stream ciphers become interchangeable when they
would normally be incompatible, preventing us from trading them off one another.
input requirements and output considerations. A key difference with prior work
is that SwitchCrypt must be able to encrypt and decrypt arbitrary nuggets
without worrying about a cipher's implementation details; prior approaches could
have cipher-specific implementations because they did not consider switching.
Thus, the cipher-specific details must be handled with care or security is
violated. With our novel cipher API, we present an interface that
\emph{decouples} cipher implementations from the encryption/decryption process.
This allows any cipher to be integrated into SwitchCrypt without modification or
special considerations. Hence, different stream ciphers become interchangeable
when they would normally be incompatible, preventing us from trading them off
one another.
The API is accessible at three levels:
......@@ -97,17 +96,16 @@ The API is accessible at three levels:
approach.
\end{enumerate}
Were we using simple ciphers exclusively, \ie{those that do not differentiate between
encryption and decryption and always produce output of the same length as the
input}, we could generate a keystream and XOR it with data without the
the need for a new a API. However, some cipher implementations treat
encryption and decryption as two distinct operations. Others require different
parameters or special considerations before XORing the keystream with data.
Others produce extra output that must be stored during encryption and fetched
during decryption. Others exhibit some combination of these concerns. Our API
presents the cryptographic driver with a single unified interface where these
disparate concerns are abstracted away, laying the groundwork for
\emph{cipher switching}.
Were we using simple ciphers exclusively, \ie{those that do not differentiate
between encryption and decryption and always produce output of the same length
as the input}, we could generate a keystream and XOR it with data without the
the need for a new a API. However, some cipher implementations treat encryption
and decryption as two distinct operations. Others require different parameters
or special considerations before XORing the keystream with data. Others produce
extra output that must be stored during encryption and fetched during
decryption. Others exhibit some combination of these concerns. Our API presents
the cryptographic driver with a single unified interface where these disparate
concerns are abstracted away, laying the groundwork for \emph{cipher switching}.
\subsection{Cipher Switching Strategies} \label{subsec:strategies}
......@@ -118,10 +116,10 @@ encrypt nugget contents. When a cipher switch occurs, a different cipher becomes
the active cipher. At this point, SwitchCrypt must determine \emph{when} to
re-cipher a nugget and \emph{where} to store the output on the drive.
``Re-ciphering'' here means using a non-active cipher to decrypt a nugget's
contents and using the active cipher to re-encrypt them. Depending on
the use case, it may make the most sense to re-cipher a nugget
immediately, or eventually, or to maintain several areas of differently-ciphered
nuggets concurrently.
contents and using the active cipher to re-encrypt them. Depending on the use
case, it may make the most sense to re-cipher a nugget immediately, or
eventually, or to maintain several areas of differently-ciphered nuggets
concurrently.
A naive approach would immediately switch every nugget to the desired cipher,
but the latency and energy cost would be unacceptable. Hence, a more adaptable
......@@ -135,7 +133,7 @@ strategy. Determining \emph{where}---in which storage region and across which
nuggets--to output ciphertext we call \emph{spatial switching}, for which we
propose the \emph{Mirrored} and \emph{Selective} switching strategies.
\textbf{A) Forward Switching Strategy.} When a nugget is encountered during I/O
\textbf{Forward Switching Strategy.} When a nugget is encountered during I/O
that is encrypted using a cipher other than the active cipher, the Forward
strategy dictates that this nugget be re-ciphered immediately. If a particular
nugget encrypted with a non-active cipher configuration is never encountered
......@@ -167,13 +165,13 @@ configuration is encountered. Of course, this has the same dire implications for
performance as simply re-initializing the entire system or encrypted
container with the new cipher.}
\textbf{B) Selective Switching Strategy.} When SwitchCrypt is initialized with
the Selective strategy, the backing store is partitioned into $C$ regions where
$C$ represents the maximum number of ciphers; each regions' nuggets are
encrypted by each of the $C$ ciphers respectively. For instance, were
SwitchCrypt initialized using two ciphers ($C = 2$), the backing store would be
partitioned in half; all nuggets in the first region would be encrypted with the
first cipher while all nuggets in the second would be encrypted with the other.
\textbf{Selective Switching Strategy.} When SwitchCrypt is initialized with the
Selective strategy, the backing store is partitioned into $C$ regions where $C$
represents the maximum number of ciphers; each regions' nuggets are encrypted by
each of the $C$ ciphers respectively. For instance, were SwitchCrypt initialized
using two ciphers ($C = 2$), the backing store would be partitioned in half; all
nuggets in the first region would be encrypted with the first cipher while all
nuggets in the second would be encrypted with the other.
Hence, unlike the Forward strategy, which schedules individual nuggets to be
re-ciphered at some point in time after the active cipher configuration is
......@@ -189,19 +187,19 @@ security regions on the same drive.
Regions of the backing store will not be in a consistent state and will likely
contain different data.
\textbf{C) Mirrored Switching Strategy.} Similar to the Selective strategy, when
\textbf{Mirrored Switching Strategy.} Similar to the Selective strategy, when
SwitchCrypt is initialized with the Mirrored strategy, the backing store is
partitioned into $C$ regions where $C$ represents the maximum number of ciphers;
each regions' nuggets are encrypted by each of the $C$ ciphers respectively.
However, unlike the Selective strategy, all write operations that hit one
region are mirrored into the other regions immediately. The mirrored
strategy allows the wider system to indicate (via the active cipher) within
which region a \emph{read} operation should occur. In this way, the Mirrored
strategy represents a form of spatial cipher switching. A user could take
advantage of this to \emph{quickly} converge the backing store to a single
cipher configuration without loss any data or the performance penalty of
re-ciphering an entire region's nuggets.
However, unlike the Selective strategy, all write operations that hit one region
are mirrored into the other regions immediately. The mirrored strategy allows
the wider system to indicate (via the active cipher) within which region a
\emph{read} operation should occur. In this way, the Mirrored strategy
represents a form of spatial cipher switching. A user could take advantage of
this to \emph{quickly} converge the backing store to a single cipher
configuration without loss any data or the performance penalty of re-ciphering
an entire region's nuggets.
All regions of the backing store will always be in a consistent state and always
share the same data.
......
......@@ -188,8 +188,8 @@ backing store.
These overhead numbers are the penalty paid for the additional flexibility of
being able to reach configurations points that are simply unachievable without
SwitchCrypt. We believe SwitchCrypt's design keeps these overheads acceptably
low and thus achieves the desired goal of flexibly navigating latency/security
tradeoffs for full drive encryption.
low, achieving the desired goal of flexibly navigating latency/security
tradeoffs for FDE.
\subsection{Augmented Threat Analysis}\label{subsec:4}
......
......@@ -2,46 +2,35 @@
The standard approach to FDE, using AES-XTS, introduces significant overhead.
Recently, it has been established that encryption using \emph{stream ciphers}
for FDE is faster than using AES~\cite{StrongBox, AnotherPaper1, AnotherPaper2}.
However, when used naively in drive encryption, stream ciphers are widely known
to be vulnerable to ``overwrite attacks'' like pad reuse and
rollback~\cite{KatzLindell, StrongBox}. To enable FDE using stream ciphers,
prior work explores several approaches:
\begin{itemize}
\item Use a non-deterministic CTR mode with specially designed cipher and
filesystem (Freestyle~\cite{Freestyle}).
\item Use a length-preserving ``tweakable super-pseudorandom permutation''
construction with nonce-accepting stream cipher (Adiantum~\cite{Adiantum}).
\item Use a stream cipher in a binary additive (XOR) mode leveraging metadata
management and Log-structured File Systems' (LFS) overwrite-averse behavior
to prevent overwrites (StrongBox~\cite{StrongBox}).
\end{itemize}
for FDE is faster than using AES~\cite{StrongBox, AnotherPaper1, AnotherPaper2},
but in practice it is non-trivial. Prior work explores several approaches: a
non-deterministic CTR mode (Freestyle~\cite{Freestyle}), a length-preserving
``tweakable super-pseudorandom permutation'' (Adiantum~\cite{Adiantum}), and a
stream cipher in a binary additive (XOR) mode leveraging LFS overwrite-averse
behavior to prevent overwrites (StrongBox~\cite{StrongBox}).
Unlike StrongBox and other work, which focuses on optimizing performance despite
re-ciphering due to overwrites, SwitchCrypt maintains overwrite protections
while abstracting the idea of re-encrypting nuggets out into cipher switching;
instead of myopically pursuing a performance win, this allows the trade off of
various cipher configurations dynamically.
instead of myopically pursuing a performance win, we trade off 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. (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."}
HaleemEtAl, LiOmiecinski}. For instance, Goodman et al. introduced selectively
decreasing security to save energy~\cite{ScalableSecurity}. Similar in intent to
VSRs, Goodman et al. 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 iteration/round
count, thus it did not anticipate the need for SwitchCrypt's generic API,
switching strategies, or security scores. Further, Wolter and Reinecke study
approaches to quantifying security in several contexts~\cite{WolterReinecke}.
This study anticipates the value of dynamically switching ciphers but proposes
no mechanisms to enable this in FDE.
In the wild, companies like Google~\cite{AndroidM} and Apple~\cite{iOSFDE} have
explored performance-security tradeoffs in hardware when considering FDE
support. Google's Adiantum uses a less secure reduced round version of
ChaCha~\cite{Adiantum}. LastPass (LogMeIn) has dealt with scaling the number of
iterations of its PBKDF\#2, trading performance for security~\cite{LastPass}. \TODO{Need a summary sentence here, too. Again, need to make it clear that what we are doing is related to this work, but solved many novel challenges.}
Companies like LastPass and Google have explored performance-security tradeoffs.
Google's Adiantum uses a less secure reduced round version of
ChaCha~\cite{Adiantum}; LastPass has dealt with scaling the number of iterations
of PBKDF\#2, trading performance for security~\cite{LastPass}. \TODO{Need a
summary sentence here, too. Again, need to make it clear that what we are doing
is related to this work, but solved many novel challenges.}
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