Is it possible to retrieve flash-based encrypted disks content (SSD, cellphones, USB sticks, ...) after password wipe/replacement?

Question

I have crossed such assertions a few times on this site:

One benefit of full-disk encryption is that it makes wiping the flash storage very fast.[...]

To wipe the entire drive, all you have to do is wipe the spot that stores the encryption of K (which is just one block). Once that block is gone, there is no way to decrypt the data on the drive (since K cannot be recovered), so the entire drive is as good as wiped.

However, I also saw a lot that due to wear levelling, overwriting data on a flash-based disks was not reliable: as per my understanding if I apply the procedure above the flash may just select another area and put the overwriting data there, leaving the key block K still present and readable in the chip (and the Internet is full of various cheap a relatively easy methods to directly access chip content, here is a random one which does not even require to desolder them).

In case a poor password was used to protect the disk content (by tying together the unlock password which aimed to be quick to type and the encryption one, Android seems to really try to enforce such weakness), wouldn't this mean that the whole disk content can still be retrieved even when this block has been "wiped"?

As a bonus, if I change a weak password to a strong one, theoretically the key block will be "overwritten" by a new block where the data encryption key will be protected by my new, stronger password.

However, isn't there any chance that the old block with the same encryption key protected by the previous weaker password will still be present and readable for an undetermined amount of time in the chip content, allowing an attacker to void completely the password change benefits?

Answer 1

You mean that when you overwrite or delete data on a flash-drive, the microcontroller in that flash-drive doesn't immediately delete or overwrite the block, but instead put them on a 'delete-in-future-list' to improve performance. That's true, but also read: delete-in-future-list, that 'future' is when the microcontroller has no other actions to do. As soon as it has nothing to do, it will completely delete that list. So let your flash-drive stick for a while after deleting/overwriting.

And also, the password wouldn't just say 'readable' in that block. I highly doubt it's saved in plain-text.

In case a poor password was used to protect the disk content (like a 4 PIN code on cellphone for instance...), wouldn't this mean that the whole disk content can still be retrieved even when this block has been "wiped"?

I guess you mean that someone would still be able to bruteforce the password even when the block containing the password was deleted? I guess no, because it's IMHO kind of the same as in a database. A website can't see if the hash of the given password matches the hashed password in the database, if there is no hashed-password in the database.

Bruteforcing is all about guessing the correct key to match the hash, without hash this isn't possible.

However, isn't there any chance that the old block with the same encryption key protected by the previous weaker password will still be present and readable for an undetermined amount of time in the chip content, allowing an attacker to void completely the password change benefits?

The old password-block is a temporary placed on another block. That doesn't mean the encryption-software uses that block. If it doesn't use that 'new' block to compare, the old password won't work anymore.

However, mention that there are ways to crack full-disk-encryption, just today an Android-exploit which could do this was found: Extracting Qualcomm's KeyMaster Keys - Breaking Android Full Disk Encryption.

Answer 2

It is indeed possible that the block containing the key cannot be properly erased. That's why LUKS uses AFsplit to store the key on disk.

The idea is essentially to expand a key that would normally be stored on a single disk block, into a format that requires many more, ensuring that the loss of a single of those blocks makes the key lost. So when erasing the key, LUKS only needs to be able to overwrite one of those blocks.

The number of blocks is configurable so as long as it is large enough, being unable to erase all of them is unlikely.

You can read more about AFsplit in the LUKS on disk format specification, and see a sample python implementation (linked from a crypto.stackexchange question).

Answer 3

To wipe the entire drive, all you have to do is wipe the spot that stores the encryption of K

That statement is correct under its theoretical form. If you can guarantee you can wipe the key, and no one had ever access to that block, you have wiped the disk.

I mean that if you have low-level disk access and got the right block copied somewhere, then you can take your time to crack the key, especially if password is weak.

Recall

Modern disk encryption works by using a combination of a key, which is of fixed length, protected by a user secret (e.g. the password). So the key is useless without the password and the password is useless without the key.

The answer is

To securely wipe the entire drive, two conditions must be met:

• Block containing key must never be readable by any entity except the encryption hardware (could be valid for SSDs supporting hardware FDE)
• Block containing the key must be physically, and not logically, overwritten

The second condition varies on controller implementation. Most SSDs are unsuitable for storing such sensitive data because the drive does not transactionally guarantee the wipe of a sector when you want to overwrite it.

The first is even more difficult to achieve, because it proves that the only effective FDE is the one made at hardware level where the key never leaves the device. By leaves I include going to RAM memory. E.g. BitLocker has a widely known vulnerability to hot reboot attack.