[liberationtech] secure wipe of flash memory

[Michael Rogers]

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