I made a suggestion like this elsewhere: Store the keys split up in several different files using Shamir's Secret Sharing Scheme. Encrypt each file with a different key. Encrypt those keys with a master key. XOR each encrypted key with the SHA256 of their respective encrypted files. Put those XORed keys in the headers of their respective files.
If you manage to securely wipe just ~100 bits of any of the files, the keys are unrecoverable. I don't know if that can provide enough assurance of secure deletion on a flash memory, but it's better than nothing. Den 23 sep 2013 14:40 skrev "Michael Rogers" <mich...@briarproject.org>: > -----BEGIN PGP SIGNED MESSAGE----- > 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. > > > http://web.archive.org/web/20130302170747/http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf > > > http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf > > 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). > > > http://nelenkov.blogspot.co.uk/2013/08/credential-storage-enhancements-android-43.html > > 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. > > Cheers, > Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJSQDaHAAoJEBEET9GfxSfMw/EH/RQ9nmgB0TfTboQJQThHOD3k > qDD0UrsjHqVwLD4oZu/rFMxIjQv0ECnLh2zJsbR9E0DqEbJAaOQ/GuDcY9RzzZ7S > w1H0Ly1ecJu/iaBQ0Ah0VC+SH0qBWupsk+mSLxeXICMR/6JuMslVYhiErM6mM94O > OLaia9slAoYDSTs+l/fOXXOtzrTTT3Nkn2M9mOhPVe6HAKNi7Ks1qXl/XMe4WZhJ > eTttbqHhkoZDHLnCjKvskwPDUGlcAhNXkZ8sfphWyr77xEOK2md8Okx6oIBzRI53 > UgKiVi3g+VwgY9jxeuUUc8xR6/yYXKncEuSCoF+oVKNsRqBTM7trKh1tU+J3Jqk= > =G1oY > -----END PGP SIGNATURE----- > _______________________________________________ > 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
