Commit 9412df13 authored by Xunnamius (Zara)'s avatar Xunnamius (Zara)

related work

parent a8768095
......@@ -3,9 +3,9 @@
In this section, we provide four case studies and empirical results
demonstrating the practical utility of cipher switching. We cover a wide range
of situations, highlighting concerns like configuration convergence
(\cref{subsecuc4}), trading off security and writable space (\cref{subsecuc2}),
meeting latency goals (\cref{subsecuc3}), keeping within an energy budget
(\cref{subsecuc1}), etc. We also demonstrate the utility of both temporal and
(\cref{subsec:uc4}), trading off security and writable space (\cref{subsec:uc2}),
meeting latency goals (\cref{subsec:uc3}), keeping within an energy budget
(\cref{subsec:uc1}), etc. We also demonstrate the utility of both temporal and
spatial switching strategies, exploring the range of conditions under which
certain strategies are optimal.
......@@ -156,8 +156,7 @@ the wrong hands, she cannot afford to lose that data either. In such a scenario,
it would be useful if, instead of destroying the data, the storage layer could
switch itself to a more secure state as quickly as possible.
\begin{figure}[ht] \textbf{Custody Panic Use Case: Security Goals vs Time
Constraint}\par\medskip
\begin{figure}[ht] \textbf{Custody Panic Use Case: Security Goals vs Time}\par\medskip
\centering
{\input{charts/usecase-custody.tex}} \caption{Actual security score vs
security goal with respect to the time and ISE.}
......
\section{Related Work}\label{sec:related}
The standard approach to FDE, using AES-XTS, introduces significant overhead.
Within the last year and a half 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:
The standard approach to FDE, using AES-XTS, introduces significant overhead.
Within the last year and a half 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
......@@ -18,25 +18,25 @@ To enable FDE using stream ciphers, prior work explores several approaches:
to prevent overwrites (StrongBox~\cite{StrongBox}).
\end{itemize}
Though the tradeoffs and ideas explored in this paper can apply to any use of
stream ciphers in FDE using some binary additive operation, we focus on the
lattermost prior approach with SwitchCrypt: a stream cipher based FDE and
metadata layer that exploits LFS overwrite-averse behavior to achieve
high-performance encryption.
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.
Unlike prior 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 re-ciphering or \emph{cipher
switching}, where a nugget's contents are decrypted using the old key and
inactive cipher configuration and encrypted using a new key and the active
cipher configuration before completing the I/O operation; instead of myopically
pursuing a performance win, this allows users (or the operating system) to trade
off different ciphers and their characteristics 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: \textit{An Energy/Security Scalable
Encryption Processor Using an Embedded Variable Voltage DC/DC Converter},
published by Goodman et al. in 1998, introduced trading security for decreased
energy dissipated to encrypt a bit~\cite{ScalableSecurity}. Similar in intent to
VSRs and the Selective strategy (see \secref{usecases}), they minimize energy
consumption by separating low-priority data from high-priority and encrypting
them differently. Similarly, Wolter and Reinecke study performance and security
tradeoffs, exploring approaches to quantifying security~\cite{WolterReinecke}.
\TODO{A paragraph on FDE prior work; include StrongBox, Google Adiantum using a
reduced round version of ChaCha for real life crypto, dm-crypt?, Secure Block
Device; include other ciphers in the same vein as Freestyle}
\TODO{Include papers that trade energy/perf vs securty; Scalable Encryption
paper, energy saving cryptosystems, LastPass whitepaper trading crypto for
reduced latency in PBKDF2, etc.} \TODO{Agreed that this last one is critical. PErhaps cut the prior todo for space.}
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}.
......@@ -65,7 +65,7 @@
legend style={ column sep=1ex },
legend entries={%
{\scriptsize Mirrored Scores (Without SwitchCrypt)},
{\scriptsize Desired Minimum Score (Exclusive)},
{\scriptsize Desired Minimum Score},
{\scriptsize Actual Minimum Score (SwitchCrypt)}
},
legend style={
......
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