Commit 65963a83 authored by Xunnamius (Zara)'s avatar Xunnamius (Zara)

finished abstract, intro, motivation, design, implementation updates

parent f24054f4
......@@ -32,8 +32,8 @@ With a traditional filesystem or encrypted container, we are stuck with the
high-latency \emph{high-energy} cipher configuration chosen at initialization.
With the ability to re-cipher individual storage units, we can achieve this
functionality by switching to a cipher configuration that trades the security
properties of active areas of storage (\ie{to where the downloaded movie's bytes
functionality by switching to a cipher configuration that trades \emph{some}
security of active areas of storage (\ie{to where the downloaded movie's bytes
and filesystem metadata updates are being committed}) so that we stay within our
curtailed energy budget and successfully retrieve the entire file. Had we
remained at the high-latency high-energy cipher configuration, we would have
......@@ -41,10 +41,10 @@ blown past our budget in the middle of downloading the file.
And thanks to the ``battery saver'' mode, our device remains alive long enough
for us to reach a charger, allowing the system to return to a non-curtailed
energy budget, our system can return those storage areas to their even more
secure cipher configuration dynamically, allowing the security of the backing
store to recover without having to recreate the entire underlying filesystem or
encrypted container or restart the device.
energy budget. Our system can return any storage areas to their more secure
cipher configuration dynamically, allowing the security of the backing store to
recover without having to recreate the entire underlying filesystem or encrypted
container or restart the device.
\subsection{Key Challenges}
......
......@@ -391,4 +391,32 @@ scores 0 and ChaCha20 scores 1\@.
\subsection{Putting It All Together} \label{subsec:summary}
Let's revisit the motivating example from \secref{motivation}.
Let's revisit the motivating example from \secref{motivation}. Initially, I/O
requests come down from the LFS and are received by the cryptographic driver,
which divides the request by which nuggets it touches. For each nugget, the
per-nugget metadata is consulted to determine with which cipher the nugget is
encrypted. If it's encrypted with the active cipher, which must be true if we
have not initiated a cipher switch, the write is handled like prior work:
encrypted data is read in from the backing storage, the merkle tree is consulted
to ensure the integrity of encrypted data, the transaction journal is consulted
during write operations so that overwrites are handled and pad-reuse violations
are avoided, and then the keycount store is consulted to derive the nugget's
unique encryption key from some master secret. Using the generic stream cipher
API to call out to the active stream cipher implementation, SwitchCrypt
encrypts/decrypts the nugget's contents~\cite{StrongBox} and commits any updates
back to backing storage.
When the device enters ``battery saver'' mode, the energy monitoring software
downclocks the CPU and indicates to SwitchCrypt that a more energy-efficient
cipher should be used until we return to a non-curtailed energy budget. Now,
when the cryptographic driver divides I/O requests into each affected nugget,
the per-nugget metadata shows SwitchCrypt that the nugget is encrypted using a
cipher that is not the active cipher. This triggers the re-ciphering code path.
Since we're using the Forward switching strategy, this means the nugget data is
immediately decrypted by calling out to the inactive cipher through the API and
then re-encrypted by calling out to the active cipher. Depending on the API
level the cipher is implemented at, either 1) the cryptographic driver manages
encrypting/decrypting data and updating the merkle tree, transaction journal,
and keycount store or 2) the cipher implementation handles updating SwitchCrypt
internals directly. Afterwards, the I/O operation is committed to the backing
store.
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