Commit c07d21af authored by Xunnamius (Zara)'s avatar Xunnamius (Zara)

final paper updates

parent 91bdbc15
......@@ -3,7 +3,7 @@
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
\cite{DmC-Android,Thereska}. However, all of these
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.
......@@ -37,19 +37,19 @@ 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
and method for using \emph{stream ciphers} like the high performance ChaCha20
cipher for FDE in lieu of AES-XTS~\cite{StrongBox, ChaCha20}. More recent
work---such as Google's HBSH (hash, block cipher, stream cipher, hash) and
Adiantum~\cite{HBSH, Adiantum}---brings the use of stream ciphers for drive
encryption to industrial strength products.
cipher} (AES-XTS)~\cite{XTS, XTSComments, NISTXTS}. Prior research introduced
the motivation and method for using \emph{stream ciphers} like the high
performance ChaCha20 cipher for FDE in lieu of AES-XTS~\cite{StrongBox,
ChaCha20}. More recent work---such as Google's HBSH (hash, block cipher, stream
cipher, hash) and Adiantum~\cite{Adiantum}---brings the use of stream ciphers
for drive encryption to industrial strength products.
There is a rich choice of stream ciphers with a variety of different performance
characteristics and opposing security properties. Some of these include: ChaCha
variants with different round counts (e.g., ChaCha8 and ChaCha20) or stronger
security properties (e.g., Freestyle) and others---SalsaX, AES in counter mode
(AES-CTR), Rabbit, Sosemanuk, etc~\cite{Freestyle, SalsaX, Rabbit, Sosemanuk,
ChaCha20, AES-CTR}. Given this variety, the cipher configuration providing the
ChaCha20, AESCTR}. Given this variety, the cipher configuration providing the
fastest I/O throughput is almost always different than the configuration
providing the most desirable security properties, and both may differ from the
configuration that uses the least energy or allows the most writable
......@@ -57,9 +57,9 @@ 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 arise while the system is
running. Examples include changes in resource availability, runtime environment,
desired security properties, and adhering to changing OS energy budgets.
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.
Hence, any common-case configuration will inevitably sacrifice one concern for
another, even when it is not optimal to the end user. \emph{But what if our
......
......@@ -302,12 +302,13 @@ ciphers can co-exist on the backing store securely, depending on the use case
\subsection{Quantifying Cipher Security Properties} \label{subsec:quantify}
Every cipher mentioned in this paper is considered secure in that \emph{there
are no known practical attacks against them}~\cite{All, Ciphers, Again}. This
implies data is kept confidential versus any adversary, however it is often
desirable to secure data at rest in special contexts or considering future
adversaries with abundant resources. In this way, a cipher that is more
resilient to cryptanalysis or brute-force or round count than is currently
required or a cipher that elegantly handles nonce-reuse might be more desirable.
are no known practical attacks against them}~\cite{ChaCha20, Freestyle, SalsaX,
Rabbit, Sosemanuk, AESCTR}. This implies data is kept confidential versus any
adversary, however it is often desirable to secure data at rest in special
contexts or considering future adversaries with abundant resources. In this way,
a cipher that is more resilient to cryptanalysis or brute-force or round count
than is currently required or a cipher that elegantly handles nonce-reuse might
be more desirable.
To simplify reasoning about trading off such disparate cryptographic properties
in the FDE context, we must have a way to quantitatively compare a cipher's
......@@ -320,13 +321,12 @@ FDE (see: \tblref{security-quant}).
Our scoring scheme is a combination of well understood schemes: scoring ciphers
on their confusion and diffusion of plaintext bits during
encryption~\cite{MicrosoftCryptanalysisAES,SchneiersOnRounds} (commonly known as
\emph{round count}), on how they behave when given the same input
parameters~\cite{random-output1,Freestyle,random-output2} (normally an
unacceptable confidentiality-breaking overwrite condition), and on there being
penalties for supplying the wrong key when attempting to decrypt (\ie{an
attacker should have to do more work than the
defender})~\cite{scrypt,Freestyle,others2}.
encryption~\cite{attack1,attack2,AESItself} (commonly known as \emph{round
count}), on how they behave when given the same input
parameters~\cite{random1,Freestyle,random2} (normally an unacceptable
confidentiality-breaking overwrite condition), and on there being penalties for
supplying the wrong key when attempting to decrypt (\ie{an attacker should have
to do more work than the defender})~\cite{Freestyle,Mercy}.
\textbf{1) Output randomization (OR).} A cipher with output randomization
generates different ciphertexts non-\\deterministically given the same key,
......
......@@ -110,16 +110,16 @@ latency, all without compromising the security needs of the most sensitive data.
This usecase illustrates using temporal Forward switching to offset the
debilitating decline in performance when SSDs reach end-of-life
(EoL)~\cite{SSDEOL1, SSDEOL2, SSDEOL3}. We demonstrate the utility of such a
system to dynamically stay within a strict latency budget while meeting minimum
security requirements, which is not possible using prior work.
(EoL)~\cite{SSDEOL1}. We demonstrate the utility of such a system to dynamically
stay within a strict latency budget while meeting minimum security requirements,
which is not possible using prior work.
Due to garbage collection and wear-leveling requirements of SSDs, as free space
becomes constrained, I/O performance drops precipitously~\cite{SSDEOL1, SSDEOL2,
SSDEOL3}. With prior work, our strict latency ceiling is violated. However, if
SwitchCrypt is made aware when the backing store is in such a state, we can
offset some of the performance loss by switching the ciphers of high traffic
nuggets to the fastest cipher available using Forward switching.
becomes constrained, I/O performance drops precipitously~\cite{SSDEOL1}. With
prior work, our strict latency ceiling is violated. However, if SwitchCrypt is
made aware when the backing store is in such a state, we can offset some of the
performance loss by switching the ciphers of high traffic nuggets to the fastest
cipher available using Forward switching.
We begin by writing 10 40MB files to SwitchCrypt per each cipher as a baseline.
We then introduce a delay into SwitchCrypt I/O of $20ms$, simulating drive
......@@ -176,9 +176,9 @@ physical drives). Both the desired and minimum security score of the drive is
triggered---the desired minimum security score goes to 3, the highest
possible---at which point the system executes ISE and completely erases the
drive containing the minimally scored data. ISE is known to be much faster than
TRIM and completes in as little as 3
seconds~\cite{SeaGate,Samsung,ThatOtherOEM}. Once complete, the most secure form
of the data is all that remains. The backing store has been ``locked down.''
TRIM and completes in as little as 3 seconds~\cite{ISE1,ISE2,ISE3}. Once
complete, the most secure form of the data is all that remains. The backing
store has been ``locked down.''
Our goal is to lock down the backing store, slowing down any attacker as much as
possible such that, even if they copy and permanently store her data off-site
......
......@@ -2,12 +2,12 @@
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},
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}).
for FDE is faster than using AES~\cite{StrongBox}, 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
......@@ -17,16 +17,16 @@ and security wins as well.
Further, trading off security for energy, performance, and other concerns is not
a new research area~\cite{ScalableSecurity, WolterReinecke, ZengChow1,
ZengChow2, HaleemEtAl, LiOmiecinski}. Goodman et al. introduced selectively
decreasing the security of some data to save energy~\cite{ScalableSecurity}.
However, their 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. 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. Similarly, companies like LastPass and
Google have explored performance-security tradeoffs. Google's Adiantum (above)
uses a less secure reduced round version of ChaCha~\cite{Adiantum}. While not an
FDE solution, LastPass has dealt with scaling the number of iterations of
PBKDF\#2, trading performance for security during login
sessions~\cite{LastPass}.
ZengChow2, HaleemEtAl, LiOmiecinski, Merkel4, Merkle3}. Goodman et al.
introduced selectively decreasing the security of some data to save
energy~\cite{ScalableSecurity}. However, their 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. 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.
Similarly, companies like LastPass and Google have explored performance-security
tradeoffs. Google's Adiantum (above) uses a less secure reduced round version of
ChaCha~\cite{Adiantum}. While not an FDE solution, LastPass has dealt with
scaling the number of iterations of PBKDF\#2, trading performance for security
during login sessions~\cite{LastPass}.
This diff is collapsed.
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