Hacker News Reader

Comment by adenylyl | Hacker News Reader

"Erase the affected volume" is really the best solution they could come up with?

I think encryption uses a generated key to encrypt most of the disk, and stores that key encrypted with the user password on the disk. That makes changing the password fast; they only need to re-encrypt the encrypted key with the new password, and write it out. Problem is that an attacker who knows the old password may already have decrypted the generated key, so they can decrypt the encrypted data from the raw data, even after the password was changed.

Erasing generates a new key for the data. I think it could be done without reformatting, but they still would have to read each block, decrypt with the old key, encrypt with the new, and write back the result. Testing the recovery procedure for that (how do you know where to restart that after it crashed?) would be a challenge, though.

Couldn't you just turn off FileVault (decrypts the drive), let that finish, then turn it back on again?

I guess that doesn’t remove the master key. Maybe, it also is used as the ID that uniquely identifies the disk?

This is called using a KEK (key encryption key) to encrypt a DEK (data encryption key) or a FEK (file encryption key), depending on the exact purpose.

As you point out, erasure can rotate keys. What Apple apparently didn't provide was a straightforward way for key rotation as a key management function. This surely appears to have been rushed to market.

My favorite is that they can't even QA the workaround instructions.

Restore the data that you backed up in Step 1

Backup is step 2.

As others have pointed out, the password was apparently written in plain text on the disk. So yes, I think a complete erase is warranted.

That can’t be the reason. If you _change_ the password (and use good passwords that are not correlated with each other), an attacker learns nothing from being able to read your old password.

The key is also stored on the disk, encrypted with the password. So presumably an attacker reading the disk could recover the encrypted key and the password and use those to recover the encryption key, which they could then use to decrypt any un-erased fragments of files they find on the disk.

Or something like that. It's an admittedly implausible scenario, but good security is not based on "meh, it probably won't happen". Of course, a much more plausible scenario is password re-use.

Propably couldn't come up with a way to restore the password hint because it was nowhere saved in plain text

Reply on news.ycombinator.com