-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Oli,
I've heard that some Android devices use controller chips for their internal flash storage, making the storage appear as a block device from the kernel's point of view, while others allow the kernel to access the flash chips directly. In the former case the storage will contain an ordinary block-oriented filesystem like ext2, while in the latter case it will contain a flash-specific filesystem like YAFFS. I have no idea how common each case is, but it would be easy to find out by checking the contents of /etc/mtab on a sample of Android devices. Is anyone on the list in a position to do that? Some researchers in Korea have created a modified version of YAFFS that supports secure file deletion, which could be used to create a custom Android ROM that would support secure deletion on devices with directly accessible flash chips: http://oslab.ssu.ac.kr/pdf/2008-5.pdf If the modified version of YAFFS is used then an Android device with directly accessible flash chips is preferable to one with a controller chip. But if the modified version of YAFFS isn't used, an Android device with a controller chip is preferable, because directly accessible flash chips are also directly accessible to the adversary without additional hardware (search for MTD forensics). As far as I can tell, USB flash devices and SD cards include a controller chip that presents a block device interface, so they probably can't be used with the modified version of YAFFS. As you pointed out, encrypting the data before storing it seems to be the best solution. But there are a couple of snags. The first is key storage: either the user will have to remember the key or the device will have to store it somewhere. I don't know much about Android - is there a small amount of securely deletable non-volatile storage that's available on all Android devices? The second snag is more subtle. A simple way to do encrypted storage is to use a stream cipher that supports random access to the keystream, such as AES in CTR mode. The i^th byte of the ciphertext is the i^th byte of the plaintext XORed with the i^th byte of the keystream. You can seek to any point in the storage and efficiently calculate the keystream needed to read or write that part of the storage. So far so good. *But* every time you overwrite a given part of the storage, you use the same part of the keystream. If the adversary gets two versions of the same part of the ciphertext, the XOR of the ciphertexts equals the XOR of the plaintexts. (In the worst case, one of the plaintexts is all zeroes and the adversary learns the other plaintext.) On a magnetic disk this situation is unlikely, because overwriting a logical location usually overwrites the same physical location. But on a flash disk the opposite is true: the controller goes out of its way *not* to overwrite the same physical location. So the encryption scheme needs to be chosen under the assumption that the adversary will have access to multiple versions of the same part of the ciphertext. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJQA/YqAAoJEBEET9GfxSfMb9IH/2IO7HPv5r4q30mg2mg9No/H tiASrWrjYn97NYC7iz5C6sAyfOmEyITrj9rQW9H3hHlutWZnGHJXlqfK5xnezlUo sv7zUlg34aS0AN4smNrVgBXDtuytIxh+s/BQ1JNt4Xv/1BUgZrXigkaPREyxc3vd ogBhAzVBgtupvG9eDlsxMalOy6N1Fqmam1g5enN7HEkbD0Lk0tQkMTZlb/KPB5XH FSljvXNhsIgmfZZWnU7KaipMRlZY4Yxd6jXWRfXCq6OT3pn1lkqVqvw30HPer8kw 2RSjhJvceH5GWAX/9IHmBVb2sEv5BDrLKUMqyxCBWaD3loeg81f5Dq59bzLtCgk= =QtrY -----END PGP SIGNATURE----- _______________________________________________ liberationtech mailing list [email protected] Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech
