While I get wear leveling is a problem, I'm not sure if the flash in a phone
is even going to use wear-leveling, but say for the sake of argument it
does. It is however not a completely brand-new problem, relatedly spinning
disks now and then suffer sector failures, and the failed sectors are
remapped by th drive firmware to another spare good sector. Consequently
data that you might have wanted to securely delete could be left still
readable by a lower level read.
Dm-crypt(*), the hard disk encryption system on linux, offers a solution to
the sector remapping problem: a key management system called LUKS (Linux
Unified Key Setup). How it works is that the key you woul like to be able
to delete is secret shared so that you will need k of n blocks to access the
key. This provides also additional redundancy - you dont want a single copy
of your access structure in case it suffers a sector failure. To delete
simply delete all of the n blocks. So long as < k of the blocks have
failed, your data is secure. k is chosen to make that astronomically
unlikely (short of a complete disk failure, which you're going to notice).
For wear-leveling its more tricky, but it I think the trick to deletion
would be to delete and temporarily fill the disk - even wear leveling has to
delete then. You probably want the LUKS k of n trick also to account for
partial failures and inaccessible spare capacity held for remapping.
Also it seems to me that SSD drive manufacturers ought to have a special
deletable NVRAM for key storage. Its not exactly an unknown problem, would
allow instant secure deletion. Of course people may rightly not trust the
manufacturer, but it wouldnt hurt to mix it in (xor the LUKS style key and
the NVRAM deletable).
Apparently or so I've heard claim SSDs also offer lower level APIs to
actually wipe physical (not logically wear-level mapped) cells, to reliably
wipe working cells. Anyone know about those? They could be used where
available and to the extent they are trusted.
Adam
(*) DM = Device Mapper, a file system layering mechanism on linux.
On Mon, Sep 23, 2013 at 11:02:45AM +0300, ianG wrote:
On 23/09/13 07:12 AM, Dev Random wrote:
I've been thinking about this for a while now and I don't see a way to
do this with today's mobile devices without some external help.
The issue is that it's pretty much impossible to delete data securely
from a flash device.
Why is that?
That means that in order to guarantee PFS, you
have to store the keys in memory only. But again, in a mobile
environment, you don't have access to stable memory either, because of
the OS restarting your app, or the device itself rebooting.
Let's call this the persistence/deletion issue.
So, I submit that PFS in async messaging is impossible without help from
some kind of ephemeral, yet persistent storage. A possible solution
might be to store a portion of the key material (through Shamir's secret
sharing) on servers that you partially trust.
(I agree with the difficulty in general. Stating anything like PFS
in the context of a protocol makes less sense if one considers that
the clients either end save the messages.)
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
