Factory Reset On Millions of Android Devices Doesn't Wipe Storage

Bismillah writes: Ross Anderson and Laurent Simon of Cambridge University studied a range of Android devices and found that even though a "factory reset" is supposed to fully wipe storage, it often doesn't. Interestingly enough, full-device encryption could be compromised by the incomplete wiping too. ITnews reports: "The researchers estimated that 500 million Android devices may not fully wipe device disk partitions. As many as 630 million phones may not wipe internal SD cards. Five 'critical failures' were outlined in the researchers' Security Analysis of Android Factory Resets paper.

Comments

All using ancient devices

[brunes69]

"fragile full-disk encryption up to Android v4.4 (KitKat)."

"Twenty-six second-hand Android phones running versions 2.3 to 4.3 of the operating system, sold by five handset makers, were tested."

This paper did not look at Android 4.4 or above, IE, the only versions of Android that actually properly supported and advertised full disk encryption in the first place. Full disk encryption on any device prior to 4.4 was basically something the manufacturer cooked up.

If this paper shows anything to me, it is not so much about Android, it is more about how we have to force carriers to stop requiring this goddamn nonsense useless "carrier certification" so that Google can push device manufacturers to allow more direct and timely software updates.

Re:All using ancient devices

[gstoddart]

Yes, and how many of those devices are supposed to support the factory reset which wipes all the storage?

What's that? All of them?

Full disk encryption is one of 5 problems they found, but not the main one.

the researchers found that all retained at least partial amounts of data from contacts information, images and video, SMS, email, and data from third-party apps like Facebook.

They were able to recover Google authentication tokens in all devices with flawed factory reset, and were able to access master tokens in 80 percent of cases.

To test their findings, they used one of the recovered master tokens from a reset to restore the credential file.

Disk encryption, in theory, should make the factory reset more robust. But the sense I get is that the factory reset is complete garbage independent of encryption on some of these devices.

Which mostly reaffirms that I have no interest in anything but the stock Google Android. Because by the time another entity has gotten their hands on it and tweaked it to advance their own commercial interests , you really have no idea of what holes they've introduced, and you have no idea how long before they'll drop support for it.

Carrier certification is shorthand for "all of our crapware needs to be checked if we get around it". The shit carriers put on phones is for their benefit, not ours. Because it's intended to drive traffic to their garbage.

If that's possible, then it isn't encryption.

[Anonymous Coward]

No shit, you can get the encrypted data if it isn't wiped.

If the "encrypted" data can still be compromised, then it isn't truly encrypted, so encrypted storage isn't being used, and thus the "destroy the device" part applies.

Truly encrypted data is indistinguishable from random data to an attacker. In fact, that's even better than a reset device's storage being zeroed or oned out, since it doesn't indicate that the device had been obviously reset.

Besides, the summary is wrong. If you actually read the article, it says (emphasis added)

For Android users wanting to ensure their data is completely wiped from their device, the researchers suggested turning on full-disk encryption where it is offered

Re:If that's possible, then it isn't encryption.

[ledow]

Indeed - the whole point of full-disk encryption is that "reset" really consists of "zero the place where the master key was stored, which was encrypted by the user passphrase".

Do that, and do that effectively, and you don't have to touch ANYTHING else - it all becomes random gibberish without a valid key. It could literally mean just keeping a couple of hundred bytes of RAM in an EEPROM and then destroying it on "factory reset".

For convenience of detection, however, you may want to zero the first few sectors of the storage so that filesystem probes see it as "no filesystem" rather than as random gibberish. But that's got zero impact on the data that WAS within it.

There's a reason that everything before 4.4 was third-party encryption and untrusted. There's a reason that proper, system-level full storage encryption (including SD card encryption) required changes to the OS. Since then, however, you just need to make sure nobody has your passphrase to stop them getting into your device. Then make sure that nobody has the passphrase-encrypted key blocks at the beginning of the disk (usually) and the data is nothing more than random gibberish.

About the only thing needing a complete wipe of all data is really if you're put into duress to provide a key (which would obviously then provide the data) or if a key is discovered and someone wishes to prove that you DID hold the key / data (by provably decrypting with that key to show that it must have been the right one and, maybe, therefore that you had knowledge of it).

Wipe the key-block, and the encrypted data is basically undecryptable. Same way TrueCrypt etc. work. And even though your passphrase may only be 10 characters, the key block might well be hundreds of bytes long and THAT's what actually has to be decrypted first in order to get the real key to decrypt the rest of the data.

Re:If that's possible, then it isn't encryption.

[mlts]

The Windows format command does this. If one uses it on a BitLocker encrypted volume, it will go and zero the parts on the volume that hold the BitLocker master key, so even if someone later has a recovery password, the data is still completely gone. Same with secure erase on a number of SSDs.

Since Android is sitting on a SSD, it might be wise to move to a smarter wiping system. One that would wipe the dm-crypt data, core places of the filesystem, and after that, TRIM the entire data partition before formatting and rebuilding it. The TRIM command helps ensure that the data present isn't recoverable at the drive level, and likely will get utterly destroyed when the drive erases the TRIMmed pages.

I read about some newer phones using a chip to store the encryption key for /data, similar to how iOS does it, but when hardware starts getting involved, it becomes harder to deal with a potential backdoor.

Maybe the ideal is a small bit of storage that is used, and if it is erased, the erasure is guarenteed (where there is no way to recover previously stored data.) Then, the master key is stored there. On initial bootup, the phone prompts the user for the PIN, decrypts the key stored on that small bit of storage for the master key to /data, and proceeds from there. On an erase, /data gets force unmounted, the small storage is erased, and a blkdiscard is issued for the /data's device. Not 100%, but it will pretty much ensure anything stashed in /data is gone.

Then there is the external SD card. Unlike /data, there isn't a real standard to encrypt that storage partition. Usually it winds up being encrypted on a file by file basis with some EncFS offshot. The key for this is stored in /data, so if the phone is wiped, there isn't any way to retrieve the SD card's data. What might be an idea would be to offer the file based mechanism, but also offer the ability to format the SD card and encrypt the entire card on a device level, not just on a file by file basis.

Of course, something like phonebookfs could be used so that someone looking at the encrypted file stash on the SD card can't tell between real data and randomly generated chaff, but that may not be something for mainstream phones.

Android. The "PC" of mobile devices

[DigiShaman]

See, this is why I'm a convert to Apple iOS. Yes, there are a few reputable hardware vendors for Android like Samsung and LG; and in many cases, superior hardware specs for the latest device. The problem is the hardware/software permutation and lack of post-sales support and upgrades. THIS is why I abhor the Android platform. Yes, it's open source, but it's also chaotic in quality control when comparing and contrasting between not just vendors, but the year in which the vendor brought to market! Love it or hate it, Android is pretty much anarchy wild-wild-west while Apple is, well, Apple.

I can only speak for myself, but I like consistent, stable, and well throughout platforms; even if that renders me very little control. It all comes down to trust. Burn my trust, and I walk.

Re:Android. The "PC" of mobile devices

[jones_supa]

I know exactly what you mean, but I actually like the wild west of PC and Android. Lots of interesting devices to pick from, and low prices. It's more fun.

Re:Android. The "PC" of mobile devices

[DigiShaman]

So what you're saying is that you want companies to do your thinking for you?

If you mean "innovation", then yes. Make a product that I like and conforms with my life, and I'll be inclined to make a purchase. Life is too short. I don't have time to think of everything.

Re:New news about Old software

[thegarbz]

Since then, Android has released major versions (4.4 Kitkat, 5.0 Lollipop) and various major updates within those families (4.4.2, 4.4.4, 5.1). To put this in perspective, they're talking about risks in 2018 from software no newer than 2013 while writing and publishing in 2015.

More than half of current devices in the hands of people have the versions which they tested.

There were many fixes in Android security systems in 4.4 and also in 5.0.

Which has nothing to do with factory reset, a function implemented by the manufacturer and not a function of Android itself. Unless the manufacturers have picked up on it, 5.0 devices are just as likely to preserve user data as previous devices.

5.0 now supports hardware encryption on e.g. HTC and OnePlusOne platforms among others.

Supports means nothing. No actually it means a lot. Hardware encryption is currently supported by a tiny TINY portion of the handsets out there. But here's a fun fact for you, supported doesn't mean the end user will use it. 5.0 does not mandate encryption by default. It's not an opt out process. I don't even need to guess how many users went out of their way to turn this feature on.

but in this case the hype cherry-picks data that ignores two years of active open-source development and many security updates

All which mean diddleysquat in practical terms if the updates haven't filtered down to the population, and the updates mandate proper security practices. Neither of which has occurred in the past 2 years.