I've often thought it would useful to have something like the rubber
hose filesystem (
http://bit.ly/1r0aBIM) on a mobile device for storing
apps and data. You could create a number of hidden volumes, each with a
different passkey that gets entered at the lock screen. If you punch in
one code, it unlocks the associated volumen and you get the set of
apps/data on that volume. If you punch in another code, you get a
another volume and set of apps/data.
In theory, it would even be possible to make any arbitrary passkey be
accepted as valid, since the filesystem could be set to initialize a new
crypto-isolated volume, with a default set of apps, if a passkey doesn't
unlock a pre-existing volume.
The primary problem with having cryptographically isolated volumes
sharing a single block device is that writing to one volume has some
probability of overwriting a block that is being used by a different
volume. Since the isolated volumes necessarily disclose zero knowledge
of the other volumes, there is no way of knowing that any arbitrary
block is part of another crypto-isolated volume. I call this the
"erasure problem".
The rubber hose filesystem dealt with the erasure problem by having the
user unlock all hidden volumes simultaneously and specifying which
volume new data was to be written to. The filesystem code then
re-arranges blocks to make all of the data, in all of the volumes, fit
onto the one block device. That is a great design for storing and then
transporting data. But is terrible for a mobile phone where you only
want to have one volume unlocked at any time and you want read/write
access to that one volume.
There is a solution however. The implementation of crypto-isolated
volumes could use erasure coding (Reed-Solomon) of the blocks to make
the filesystem resilient in the face of arbitrary block erasures. Think
of the crypto-isolated volume like a RAID N array where each block is a
single disk in the array. If one block gets overwritten, it can be
reconstructed from the other blocks.
There's a potential for "thrashing" to occur when the total amount of
data in all of the crypto-isolated volumes approaches the capacity of
the underlying block device. When that happens, the probability that
one crypto-isolated volume would overwrite a block of a different volume
approaches certainty. So any write to one volume will be more and more
likely to result in another volume needing to reconstruct erased blocks
when it is next unlocked. But the very act of reconstructing the erased
blocks and storing them back on the device again has a high probability
of overwriting a block of a different volume...which then in turn
requires reconstruction...and on and on. I call it "thrashing".
But, thankfully memory is cheap and users could be informed that they
should keep the total amount of data under some threshold to avoid
thrashing.
-dave
On 02/13/2014 01:41 PM, Jason Weathersby wrote:
> What options do we currently have for encrypted storage for Firefox OS?