3 ms·

As far as I understand, when encrypting a volume, if AppleID option is enabled, a separate randomly generated recovery ("backdoor") key for the volume is sent t

by dchest 14y ago

As far as I understand, when encrypting a volume, if AppleID option is enabled, a separate randomly generated recovery ("backdoor") key for the volume is sent to Apple (http://support.apple.com/kb/HT4790 http://support.apple.com/kb/HT4790). I think, before iCloud/AppleID thing you had to call Apple support and answer questions to get this recovery key. With AppleID, I suspect the whole thing is automated. So, (again, I'm speculating), your AppleID and FileVault 2 passwords are completely independent things -- it's just that your additional recovery/backdoor key is stored in the iCloud, accessible with AppleID. Here's the analysis of FileVault 2 http://eprint.iacr.org/2012/374.pdf http://eprint.iacr.org/2012/374.pdf

nodata 14y ago
I'm not sure.. I think this article is about something slightly different: if I _disable_ storing my FileVault 2 recovery key with Apple, _then_ upgrade to Mountain Lion, is either of the following true? 1. Apple nabs a copy of my FileVault 2 recovery key 2. Apple can reset my FileVault 2 passphrase The article doesn't make it clear, and doesn't seem to test either.
- dchest 14y ago
  I don't know details about the upgrade process, so I can't answer, but this is really one question, not two: given 1 they can do everything, including 2.
  - nodata 14y ago
    No it's not.
    - dchest 14y ago
      Yes, it is. Recovery key provides access to the encrypted volume in the same way as your password. There's no other way around: if something (password, recovery key, recovery certificate) can decrypt your volume, this something can also be used to change your password/recovery key/recovery certificate, which is not really important, because they already have access to decrypted volume. In the linked analysis, the authors "reduced" the security of FileVault 2 to the entropy of 120-bit recovery key.
      - nodata 14y ago
        The only time the recovery key matters is if Apple has taken it without permission. That doesn't seem to be the case. So we're talking about whether resetting an Apple ID will also reset a FileVault passphrase.
        dchest 14y ago
        Resetting Apple ID won't reset a FileVault 2 passphrase. They are independent of each other.
        nodata 14y ago
        So what's the issue here? If I use my Apple ID to reset my system user's password, how can Apple decrypt my disk?
quonn 14y ago
I don't think this is the case. Here is how I understand it: FileVault 2 uses a generated secret key for encryption ; It uses a table that contains for each account the encrypted key, encrypted in turn with a key derived from each user password. It also generates a "backdoor" key that can recover the encryption key which you can write down or if you want (!) store with Apple. The issue described here is not related to the actual full-disk encryption and the reason why the password reset does not work when cold-booting is not related at all to missing network drivers (as described in the article.) Rather it shows that the encrypted disk can't possibly decrypted by just reseting you Apple ID, because - if you have not agreed - FileVault has _not_ stored the backdoor key on Apple servers and it can't be used to recover the encryption key. Why does recovery work when the machine is sleeping? Well, because in that case the encryption key is stored in memory and _can_ be restored if the OS wishes to give it up. It is well known that full-disk encryption only really protects you if the machine has been fully shut down. A dedicated attacker can usually recover the key by removing the battery and cooling the RAM to keep it from losing data. I agree that not being able to turn off the option is a bug that should be fixed, but the situation is not as bad as it may sound at first. TL;DR: FileVault 2 is just as secure as everyone assumed and even Apple can not decrypt your disk if the computer has been shut down. If it is running Apple could always use a backdoor if they wanted and other attackers could always extract data from memory.
- dchest 14y ago
  If the option is enabled, volume encryption is as good as your encryption password OR Apple ID password + whatever security measures Apple has against someone resetting your password (see recent stories). If the option is disabled, the encryption is as good as your encryption password, period. The complaint was that this option is now enabled by default.

by dchest 14y ago

nodata 14y ago

I'm not sure.. I think this article is about something slightly different: if I _disable_ storing my FileVault 2 recovery key with Apple, _then_ upgrade to Mountain Lion, is either of the following true? 1. Apple nabs a copy of my FileVault 2 recovery key 2. Apple can reset my FileVault 2 passphrase The article doesn't make it clear, and doesn't seem to test either.

dchest 14y ago
I don't know details about the upgrade process, so I can't answer, but this is really one question, not two: given 1 they can do everything, including 2.
- nodata 14y ago
  No it's not.
  - dchest 14y ago
    Yes, it is. Recovery key provides access to the encrypted volume in the same way as your password. There's no other way around: if something (password, recovery key, recovery certificate) can decrypt your volume, this something can also be used to change your password/recovery key/recovery certificate, which is not really important, because they already have access to decrypted volume. In the linked analysis, the authors "reduced" the security of FileVault 2 to the entropy of 120-bit recovery key.
    - nodata 14y ago
      The only time the recovery key matters is if Apple has taken it without permission. That doesn't seem to be the case. So we're talking about whether resetting an Apple ID will also reset a FileVault passphrase.
      - dchest 14y ago
        Resetting Apple ID won't reset a FileVault 2 passphrase. They are independent of each other.
        nodata 14y ago
        So what's the issue here? If I use my Apple ID to reset my system user's password, how can Apple decrypt my disk?

quonn 14y ago

I don't think this is the case. Here is how I understand it: FileVault 2 uses a generated secret key for encryption ; It uses a table that contains for each account the encrypted key, encrypted in turn with a key derived from each user password. It also generates a "backdoor" key that can recover the encryption key which you can write down or if you want (!) store with Apple. The issue described here is not related to the actual full-disk encryption and the reason why the password reset does not work when cold-booting is not related at all to missing network drivers (as described in the article.) Rather it shows that the encrypted disk can't possibly decrypted by just reseting you Apple ID, because - if you have not agreed - FileVault has _not_ stored the backdoor key on Apple servers and it can't be used to recover the encryption key. Why does recovery work when the machine is sleeping? Well, because in that case the encryption key is stored in memory and _can_ be restored if the OS wishes to give it up. It is well known that full-disk encryption only really protects you if the machine has been fully shut down. A dedicated attacker can usually recover the key by removing the battery and cooling the RAM to keep it from losing data. I agree that not being able to turn off the option is a bug that should be fixed, but the situation is not as bad as it may sound at first. TL;DR: FileVault 2 is just as secure as everyone assumed and even Apple can not decrypt your disk if the computer has been shut down. If it is running Apple could always use a backdoor if they wanted and other attackers could always extract data from memory.

dchest 14y ago
If the option is enabled, volume encryption is as good as your encryption password OR Apple ID password + whatever security measures Apple has against someone resetting your password (see recent stories). If the option is disabled, the encryption is as good as your encryption password, period. The complaint was that this option is now enabled by default.