6

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?

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
  • Are you sure this question requires the paragraphs starting from "4-digit PIN" inclusive? Because the first part is very interesting, but I have no clue what does PIN or password have to do with handling and erasing of the encryption key. Or maybe you could explain that relation better? – techraf Jul 02 '16 at 12:29
  • @techraf: I made it clearer. Without even mentioning people using the same numerical PIN password to unlock their SIM and to decrypt the disk, Android seem to really encourage people to use weak passwords for disk encryption by tying it to the lock screen password (it seems to require to root the phone in order to bypass this). – WhiteWinterWolf Jul 07 '16 at 14:46

3 Answers3

3

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

user2313067
  • 916
  • 1
  • 6
  • 9
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.

techraf
  • 9,141
  • 11
  • 44
  • 62
O'Niel
  • 2,740
  • 3
  • 17
  • 28
  • Regarding the password issue, to avoid being too chatty here I've just created a [chat room](https://chat.stackexchange.com/rooms/41946/room-for-whitewinterwolf-and-oniel). – WhiteWinterWolf Jul 02 '16 at 13:35
  • @WhiteWinterWolf Yes, this video: https://www.youtube.com/watch?v=4SSSMi4X_mA – O'Niel Jul 02 '16 at 13:40
  • Thanks for this video and our discussion, and I put here too a link to a related discussion from Sec.SE I mentioned during the discussion and which may be relevant to this "delete-in-future-list": [Does the ATA Trim command irrecoverably delete data on an SSD?](https://security.stackexchange.com/q/109916/32746) – WhiteWinterWolf Jul 02 '16 at 14:39
  • The passage about password storage, dealing with hashes and database seems a bit out-of-topic since it is not the way disk encryption passwords work (as discussed in chat). However I mark this as correct answer since the "delete-in-future-list" was really the key for me. I also want to add that intelligent and recent devices like some cellphones take advantage of hardware-based solutions to strengthen the disk encryption password or even directly store the master key apart from the encrypted partitions. – WhiteWinterWolf Jul 07 '16 at 14:58
1

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.

usr-local-ΕΨΗΕΛΩΝ
  • 5,310
  • 2
  • 17
  • 35