Re: [cryptography] secure deletion on SSDs (Re: Asynchronous forward secrecy encryption)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/09/13 00:18, Adam Back wrote: On Mon, Sep 23, 2013 at 01:39:35PM +0100, Michael Rogers wrote: 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. Hmm well thats interesting no? With the ability to securely delete a single key you can probably use that to selectively delete files with an appropriate key management structure. eg without optimizing that, you could have a table of per file keys, encrypted with the master key. To delete a given file you'd re-encrypt everything in the file table to a new key, except the deleted file, and delete, then over-rewrite this effaceable storage area. Yes, absolutely, that's what makes it so frustrating - they already have per-file encryption keys with user-selectable key management policies and a hierarchy of keybags - adding a policy for efficient secure deletion would be a small amount of work. But it's work that would have to be done by Apple, not in userland. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSQU8rAAoJEBEET9GfxSfM9FsIALdSvuPTB4b8zUa9NnVSz+bM JdgQ9/pMB60V2/3Ebjm6zZHEZ/AmWDOQslOGCOANMa1JkbL51Hfzhd5qFllEXyeK 8T2pX6K0vKwyPWBmeASMATtiUxXgvf1NCE+TzQexmb/OEBF+Kq384tgu9Jps+H6K ktIXFImUBnkrjpp7g4mUbJv4SOZBdBrT7kLqouSPS/UdfscZhnlPS1yT713J1GIL nJBNjAabkaMsk77RfvasCk5NQZxUz0T/3g51Xf/eaoFij7AXK9nGJVrOAPti0WsW hfdKlxMzsWDOpHAtHFChpkdTAH1bQEbZXW6XXOvZYuSFkK2yM1nAb/ba4+CVclk= =ttTm -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] secure deletion on SSDs (Re: Asynchronous forward secrecy encryption)
On 24/09/13 11:36 AM, Michael Rogers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/09/13 00:18, Adam Back wrote: On Mon, Sep 23, 2013 at 01:39:35PM +0100, Michael Rogers wrote: 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. Hmm well thats interesting no? With the ability to securely delete a single key you can probably use that to selectively delete files with an appropriate key management structure. eg without optimizing that, you could have a table of per file keys, encrypted with the master key. To delete a given file you'd re-encrypt everything in the file table to a new key, except the deleted file, and delete, then over-rewrite this effaceable storage area. Yes, absolutely, that's what makes it so frustrating - they already have per-file encryption keys with user-selectable key management policies and a hierarchy of keybags - adding a policy for efficient secure deletion would be a small amount of work. But it's work that would have to be done by Apple, not in userland. Right. Reading this, as posted by Michael Rogers: http://nelenkov.blogspot.co.uk/2013/08/credential-storage-enhancements-android-43.html Android's offering is a mess. Here's the clue: Instead of introducing yet another Android-specific API, key store access is exposed via standard JCE APIs, namely KeyGenerator and KeyStore. Plonk. A mess of corporate/proprietary accesses that aren't guaranteed compatible nor reliable nor secure across platforms/releases, and provide only a bare minimum idea some long-dead designer seemed keen on. Ug, it's back to the 1990s, when every BigCorp imagines they can create the secure platform for everyone else's corporate lemmings. I don't expect Apple to be able to solve this mess, as they are also subject to competing interests within (cf 'effaceable storage' only for their own purposes). They'll likely do a much better job than Android because they are vertically integrated and care more, but that doesn't mean they can solve it. I feel like we're on our own. Which means that notions like Shamir Secret Sharing have more credence than I'd like, I'd ordinarily run a mile from such exotica. On 23/09/13 15:39 PM, Michael Rogers wrote: On 23/09/13 05:12, Dev Random wrote: So, I submit that PFS in [ed: STUFF] 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. Yes, enticing thoughts! iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] secure deletion on SSDs (Re: Asynchronous forward secrecy encryption)
On Tue, Sep 24, 2013 at 12:03:12AM +0200, Adam Back wrote: [In response to the idea of using encrypted file hashes as part of the key wrapping procedure...] Thats not bad (make the decryption dependant on accessibility of the entire file) nice as a design idea. But that could be expensive in the sense that any time any block in the file changes, you have to re-encrypt the encryption or, more efficiently the key computed from the hash of the file. Still you have to re-write the header any time there is a block change, and do it atomically or log recoverably ideally. Also you have re-read and hash the whole file to re-compute the xor sha(encrypted-file) header. Well I guess even that is relatively fixable probably eg merkle hash of the blocks of the file instead plus a bit of memory cacheing. You should want to do COW anyways. If you use a Merkle hash tree then the additional hashing is minimized. You know, like ZFS. Still, at the end of the day, if you can recover enough past blocks you can recover deleted files. Truly wiping anything requires being able to at least wipe encryption keys (wrapped or otherwise), and since the amount of truly wipeable storage is so limited... it's much harder to support secure file deletion than secure filesystem/device wipe. What the OS could do is give you a smallish number of securely wipeable containers, and you manage the rest from there. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] secure deletion on SSDs (Re: Asynchronous forward secrecy encryption)
(Changing the subject line to reflect topic drift). Thats not bad (make the decryption dependant on accessibility of the entire file) nice as a design idea. But that could be expensive in the sense that any time any block in the file changes, you have to re-encrypt the encryption or, more efficiently the key computed from the hash of the file. Still you have to re-write the header any time there is a block change, and do it atomically or log recoverably ideally. Also you have re-read and hash the whole file to re-compute the xor sha(encrypted-file) header. Well I guess even that is relatively fixable probably eg merkle hash of the blocks of the file instead plus a bit of memory cacheing. Adam On Mon, Sep 23, 2013 at 03:00:03PM +0200, Natanael wrote: 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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] secure deletion on SSDs (Re: Asynchronous forward secrecy encryption)
On Mon, Sep 23, 2013 at 01:39:35PM +0100, Michael Rogers wrote: 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. Hmm well thats interesting no? With the ability to securely delete a single key you can probably use that to selectively delete files with an appropriate key management structure. eg without optimizing that, you could have a table of per file keys, encrypted with the master key. To delete a given file you'd re-encrypt everything in the file table to a new key, except the deleted file, and delete, then over-rewrite this effaceable storage area. Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
