[cryptography] Asynchronous forward secrecy encryption

Michael Rogers michael at briarproject.org
Mon Sep 23 08:39:35 EDT 2013

Hash: SHA1

On 23/09/13 05:12, 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.  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.

Yes, this is a major issue with current mobile devices. As far as I'm
aware, SSD commands like Trim and Secure Erase aren't available on SD
cards or the built-in flash storage of mobile devices.

Apple came within a whisker of solving the problem in iOS by creating
an 'effaceable storage' area within the flash storage, which bypasses
block remapping and can be deleted securely. However, iOS only uses
the effaceable storage for resetting the entire device (by deleting
the key that encrypts the user's filesystem), not for securely
deleting individual files.



A similar approach would be possible on Android, but I don't know of
any Android devices with effaceable storage. The closest I've seen is
hardware-backed key storage, where keys are generated, wrapped and
deleted by a TPM-like chip. Software can use the TPM to perform
operations using the wrapped keys but can't directly access them, and
thus they can't be exported from the device without cracking open the
TPM (physically or via a vulnerability).


In combination with a hardware-based flash controller, this raises the
bar for undeleting data pretty high: the adversary must compromise the
flash controller to get access to data that's been logically but not
physically deleted, then compromise the TPM to unwrap or undelete the
deleted key with which the deleted data was encrypted.

I'm not saying the bar is too high for a national security agency, but
it's too high for some adversaries, so I believe it's worthwhile to
think about forward secrecy on current mobile devices.

> 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.

Sounds like a great idea, especially in combination with a panic
button or dead man's switch feature that alerts the servers to delete
their shares.


Version: GnuPG v1.4.10 (GNU/Linux)


More information about the cryptography mailing list