Now that we know factory reset isn't secure... what now?

[blahb]

I'm writing after reading the paper "Security Analysis of Factory Resets" (fr_most15.pdf by Simon & Anderson), in which Android factory reset through 4.3.x has been revealed to basically be a joke. In light of this fact, I'm looking to come up with the simplest, secure process to follow for resetting a phone before selling it. My current phone is on 4.2.2, but I think the process should ideally be generic and applicable to as many OS's as possible.

ASSUMPTIONS
Based on the researchers' findings, let us assume the following:

1) Let us limit our concern to the data and internal SD card partitions, and we assume the latter is stored as an emulated SD card physically stored on the data partition.

2) We assume the flash memory is overprovisioned and therefore cannot be overwritten on a single pass.

3) Let us only consider 4.0.x and later devices that contain the full disk encryption (FDE) feature.

4) We require a procedure that can be employed on a phone that has not been used "securely" from the moment of purchase (such as employing FDE).

5) Let us assume our potential attackers are equipped/motivated to the point of using widely available software tools to scan for data that is logically deleted but not physically overwritten. At a minimum, we require "logical sanitisation" (storage cannot be recovered via standard hardware interfaces). "Digital sanitisation" (storage cannot be recovered via any digital means, including the bypass or compromise of the device’s controller or firmware, or via undocumented drive commands) would be preferable, if it can be achieved. We do not require "analog sanitisation" (reconstruction is impossible even with the most advanced sensing equipment and expertise).

PROPOSED SOLUTIONS
The researchers' proposed the following:

1) "Overwriting the entire partition bit-by-bit once did provide logical sanitisation for all devices and all partitions we studied; it is therefore a reliable alternative. The drawback of this method is that it requires privileged (i.e. root) access to devices in practice. This method does not provide thorough digital sanitisation, since the flash is overprovisioned – but an attacker cannot recover data using public APIs exposed by the Linux kernel."

First question, can anyone please provide a procedure to perform a bit-by-bit overwrite? I assume this would entail sending data via adb, but I would appreciate links to a specific how-to?

Second, since the flash is overprovisioned, would repeating this procedure 2-3 times ensure a reasonable likelihood that all data had been overwritten at least once and provide us with "likely" digital sanitisation in addition to logical sanitisation?

2) "Enabling Full Disk Encryption (FDE) on first use of the device would be more appropriate for ordinary users if devices support it. Enabling FDE only before performing a Factory Reset (as suggested by Google) may only provide logical sanitisation, not thorough digital sanitisation (plain-text data could still be present on the flash as it is over-provisioned). FDE was introduced in ICS (v4.0.x) so it cannot help the large number of affected GB (v2.3.x) devices. FDE for the internal SD card is not supported on all phones, and not all v4.x devices support FDE on the data partition despite AOSP’s support. As a rule of thumb, only devices with an emulated internal SD card inherit the “encryption support” from the data partition when supported. On supported Android versions, the encryption key is stored encrypted with a key derived from a salt and a user-provided PIN (or password). This encrypted blob is referred to as the “crypto footer” in the AOSP source code. An attacker who gains access to the crypto footer has enough information to brute-force the user’s PIN offline. The footer is stored in a dedicated partition or in the last 16KB of the data partition – the exact location is configured by vendors through the “encryptable=” option of the Android fstab file. In either case, we found that the footer was not erased after a flawed Factory Reset. Consequently, to logically sanitise a device with encryption, it is essential to select a strong password to thwart offline brute-force attacks. As most people just use a 4-6 digit PIN, it would usually be trivial to brute-force."

First thought, since we must assume the crypto footer can be recovered, then perhaps our process should include a step in which FDE is enabled using a long, complex, and random password in order to create a decoy crypto footer.

OPTIMAL SOLUTION???

Combining the above proposals to attempt to obtain a reasonable likelihood of digital sanitisation (but at least surely logical sanitisation), I am thinking of the following process:

1) Enable FDE encryption with a maximum-length, complex, random password (if it is not already enabled).
2) Perform a bit-by-bit overwrite of the data partition with 2-3 passes.
- What tools exist to perform this and ensure that the data and internal SD card partitions are included in the wipe?
- Following this process, what state is the phone in? Can it still be booted to Recovery mode to perform a factory reset?
3) Perform a factory reset from the Settings screens, including the "External Storage" option.
4) Enable FDE encryption with a maximum-length, complex, random password to create a decoy crypto footer.
5) Perform a factory reset from the Settings screens, including the "External Storage" option.

FEEDBACK
While the above process seems thorough, perhaps it is needlessly redundant? At a minimum, I would like to achieve 2-3 passes of bit-by-bit overwrite and the installation of a decoy crypto footer to resist decryption of any encrypted blocks that might be recoverable.

 

[UJ95x]

Encrypting your phone is really all that's necessary. It mitigates the issue to the point where it really shouldn't be anything to worry about. If you do want to overwrite the phone, only one pass is necessary. Subsequent passes are completely unnecessary

 

[syspry]

I do hand-me-downs with my devices to family. last gen goes to the wife, who subsequently passes that one on to her mom after she gets my next hand-me-down. If I must get rid of a device without handing it off, well then it gets a few holes put though it by my cordless DeWalt

 

[UJ95x]

I do hand-me-downs with my devices to family. last gen goes to the wife, who subsequently passes that one on to her mom after she gets my next hand-me-down. If I must get rid of a device without handing it off, well then it gets a few holes put though it by my cordless DeWalt

What if you're trying to sell?

 

[Rukbat]

First question, can anyone please provide a procedure to perform a bit-by-bit overwrite? I assume this would entail sending data via adb, but I would appreciate links to a specific how-to?

Run dd (it's a Linux command). Write 0s or random (that makes dd get its input from a pseudorandom generator) to the entire userdata partition.

Second, since the flash is overprovisioned, would repeating this procedure 2-3 times ensure a reasonable likelihood that all data had been overwritten at least once and provide us with "likely" digital sanitisation in addition to logical sanitisation?

Probably not, but with the normal APIs available, the overprovisioned area can't be accessed so it doesn't have to be erased. If a government agency wants your data, there might be some in the OP portion of storage that they can use forensic tools to get at.

First thought, since we must assume the crypto footer can be recovered, then perhaps our process should include a step in which FDE is enabled using a long, complex, and random password in order to create a decoy crypto footer.

TruCrypt. It not only encrypted a portion of storage, it did it in such a way that the encrypted part looked like unused random bytes. So not only was the data not readable, if you made 2 such areas, and put false data in one of them, you could give that password if forced to, and you has plausible deniability about the other data.

2) Perform a bit-by-bit overwrite of the data partition with 2-3 passes.
- What tools exist to perform this and ensure that the data and internal SD card partitions are included in the wipe?

dd.

- Following this process, what state is the phone in? Can it still be booted to Recovery mode to perform a factory reset?

If the recovery partition and boot partitions weren't wiped.

3) Perform a factory reset from the Settings screens, including the "External Storage" option.

Or an internal reset and physically remove the card.

While the above process seems thorough, perhaps it is needlessly redundant? At a minimum, I would like to achieve 2-3 passes of bit-by-bit overwrite and the installation of a decoy crypto footer to resist decryption of any encrypted blocks that might be recoverable.

Or just use dd to write garbage to the userdata partition a few times. On a hard drive,it's theoretically possible to recover data until you start wiping a ridiculous number of times, but in SS storage, writing a zero to a location leaves a zero in that location, and no weak magnetic domains of the 1 that was previously there.

 

[blahb]

In the paper I referenced, the researchers had the following findings regarding your points. They *can* work but have some limitations:

Encrypting your phone is really all that's necessary. It mitigates the issue to the point where it really shouldn't be anything to worry about.

"Full-disk encryption has the potential to mitigate the problem, but we found that [the] flawed Factory Reset leaves behind enough data for the encryption key to be recovered."

"Our study unveils five critical failures: .... (iv) the lack of Android support for proper deletion of the internal and external SD card in all OS versions; (v) the fragility of full-disk encryption to mitigate those problems up to Android v4.4 (KitKat)."

"Enabling FDE only before performing a Factory Reset (as suggested by Google) may only provide logical sanitisation, not thorough digital sanitisation (plain-text data could still be present on the flash as it is over-provisioned)."

"An attacker who gains access to the crypto footer has enough information to brute-force the user’s PIN offline. The footer is stored in a dedicated partition or in the last 16KB of the data partition – the exact location is configured by vendors through the “encryptable=” option of the Android fstab file. In either case, we found that the footer was not erased after [the] flawed Factory Reset. Consequently, to logically sanitise a device with encryption, it is essential to select a strong password to thwart offline brute-force attacks."

If you do want to overwrite the phone, only one pass is necessary. Subsequent passes are completely unnecessary

"Overwriting the entire partition “bit-by-bit” once did provide logical sanitisation for all devices and all partitions we studied; it is therefore a reliable alternative.... This method does not provide thorough digital sanitisation, since the flash is over-provisioned – but an attacker cannot recover data using public APIs exposed by the Linux kernel. "

 

[blahb]

Thank you Rukbat. I have some feedback and/or questions on a few points inline...

>> First thought, since we must assume the crypto footer can be recovered, then perhaps our process
>> should include a step in which FDE is enabled using a long, complex, and random password in
>> order to create a decoy crypto footer.

TruCrypt. It not only encrypted a portion of storage, it did it in such a way that the encrypted part looked like unused random bytes. So not only was the data not readable, if you made 2 such areas, and put false data in one of them, you could give that password if forced to, and you has plausible deniability about the other data.

I was referring to the FDE in Android and the fact that the researchers found that the footer is not overwritten during a reset and therefore can be subjected to offline brute force attacks. So, I'm not sure what you are suggesting, but it doesn't seem related to the suggestion I made of performing an FDE one-time after reset to overwrite the footer.

>> 3) Perform a factory reset from the Settings screens, including the "External Storage" option.

Or an internal reset and physically remove the card.

The "External Storage" option is to overwrite the *primary* internal SD card partition (stored as an emulated SD card physically stored on the data partition). This is not related to a *secondary* removable SD card (if present) which, per the researchers, is impossible to wipe with the Android factory reset.


NEW PROPOSED PROCESS

Based on these feedbacks, I think the process is basically unchanged except for point #1?

1) Enable FDE encryption with a maximum-length, complex, random password (if it is not already enabled). [THIS MAY BE REDUNDANT?]
2) Perform a bit-by-bit overwrite of all partitions except recovery and boot with 2-3 passes of dd. [1 pass achieves logical sanitisation, but repeat passes increase the likelihood that wear-leveling will overwrite over-provisioned areas?]
3) Perform a factory reset from the Settings screens, including the "External Storage" option.
4) Enable FDE encryption with a maximum-length, complex, random password to create a decoy crypto footer.
5) Perform a factory reset from the Settings screens, including the "External Storage" option.