Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Encrypted Storage Firefox OS

92 views
Skip to first unread message

Jason Weathersby

unread,
Feb 13, 2014, 4:41:50 PM2/13/14
to dev-w...@lists.mozilla.org
What options do we currently have for encrypted storage for Firefox OS?

Dave Hylands

unread,
Feb 13, 2014, 7:46:29 PM2/13/14
to Jason Weathersby, dev-w...@lists.mozilla.org
Hi Jason,

Currently nothing (that I'm aware of)

You may want to read/follow bug 777917

Dave Hylands
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

Harald Kirschner

unread,
Feb 14, 2014, 2:36:11 PM2/14/14
to
I understand the biggest use case for bug 777917 is additional data protection when loosing your phone. This seems to be separate from keychain, which also seems to be simpler to implement.

I gathered the use cases for keychain srorage: https://etherpad.mozilla.org/webapi-keychain
I hope comments can either confirm them or render them invalid having alternative solutions.

Thanks, Harald

cyberphone

unread,
Mar 19, 2014, 10:16:03 AM3/19/14
to
On Thursday, February 13, 2014 10:41:50 PM UTC+1, Jason Weathersby wrote:
> What options do we currently have for encrypted storage for Firefox OS?


I would also take a look in these documents:

http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf
https://www.samsungknox.com/en/solutions/knox/technical

Dave Huseby

unread,
Mar 20, 2014, 2:35:43 PM3/20/14
to dev-w...@lists.mozilla.org
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?
signature.asc
0 new messages