Want To Ensure Your Personal Android Data Is Truly Wiped? Turn On Encryption

MojoKid writes We've been around the block enough times to know that outside of shredding a storage medium, all data is recoverable. It's just matter of time, money, and effort. However, it was still sobering to find out exactly how much data security firm Avast was able to recover from Android devices it purchased from eBay, which included everything from naked selfies to even a completed loan application. Does this mean we shouldn't ever sell the old handset? Luckily, the answer is no. Avast's self-serving study was to promote its Anti-Theft app available on Google Play. The free app comes with a wipe feature that overwrites all files, thereby making them invisible to casual recovery methods. That's one approach. There's another solution that's incredibly easy and doesn't require downloading and installing anything. Before you sell your Android phone on eBay, Craigslist, or wherever, enable encryption and wait for it to encrypt the on board storage. After that, perform a wipe and reset as normal, which will obliterate the encryption key and ensure the data on your device can't be read. This may not work on certain devices, which will ask you to decrypt data before wiping but most should follow this convention just fine.

Comments

Free space

[narced]

What is not addressed is whether or not this wipes the free space as well. Recovering deleted files is easy, and if the encryption doesn't fill the device then encrypt then this trick can leave some stuff behind.

Full-disk wipe or only current data?

[Gaygirlie]

I'm under the impression that turning on encryption works by file-by-file basis, not full-disk encryption, and as such it might still be possible to find at least some old files there if the locations haven't been overwritten by new data. If it indeed works as I have the impression of then turning encryption on is still possibly inadequate a safety method.

Re:Full-disk wipe or only current data?

[swillden]

Who gives a shit what the documentation says. Actual implementation is what matters.

Absolutely. So, look at the source: https://android.googlesource.c...

That file contains the code that generates the master key, derives the key encryption key used to protect it (using scrypt), stores the protected master key, and configures dm_crypt with the master key.

Some functions to look at:

- create_encrypted_random_key(), which creates the master key (reading from /dev/urandom).
- encrypt_master_key(), which derives a KEK from your password and uses it to encrypt the master key.
- decrypt_master_key(), which does the reverse.
- create_crypto_blk_dev(), which creates dm_crypt block device.
- cryptfs_setup_volume(), which mounts an encrypted block device.
- cryptfs_enable_inplace(), which encrypts an existing file system.

Do you really trust a mobile platform to be faithful to the documentation when you're trying to wipe a partition (which could easily be implemented directly but isn't) by first encrypting all data and then throwing away the key?

The device doesn't know you're trying to wipe. It knows that you (a) requested full disk encryption and then later (b) requested a wipe. So it can't optimize (a) away. I suppose it's possible it could just lie and tell you "Yep, I'm encrypting" even though it isn't, but that's the sort of thing that would definitely get noticed by security analysts and gleefully published.

Re:srm -v -z

[wiredlogic]

The "special values" were from Guttmann's paper on wiping MFM/RLL drives. It is pointless on any modern magnetic drive or solid state memory. He points out in his newer paper on solid-state memories that multi-level flash (now used everywhere other than the most performance critical applications) is particularly hard to recover data from. Furthermore, the wear-leveling strategies used in flash mass storage devices negates any attempt to securely wipe them short of physical destruction. You're just practicing cult cargo voodoo.