Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

FileVault has the functionality to both allow and disable user accounts from booting up the encrypted drive. Reference: this cnet article. See also the stack exchange question How does FileVault 2 work with multiple decryption keys?.

In this model (master key stored encrypted on the recovery drive for each account), what would happen in the following situations?

  1. If there were two accounts authorized to boot the drive, one with the password 'test' and one with a decent 30-character passphrase? Is the drive more vulnerable because of that first account?
  2. When the drive was first encrypted, the user account on that machine (NotSmartUser) has a bad password, such as 'test.' From the cnet article, I understand that the master key is encrypted with 'test' and stored in the recovery partition. Later on, a new user account (SmartUser) is created using a good 30-character passphrase, and the first account is disabled from accessing the drive. What happens to the stored copy from NotSmartUser? Is it deleted? How is it deleted?

My understanding of master keys and encrypting them with passphrases is based on this documentation from Truecrypt.

share|improve this question

1 Answer 1

up vote 1 down vote accepted

(Like you, I am making informed guesses on how things may be done in FileVault.)

If you take a machine, such that, upon boot, typing a given password is sufficient to unlock the contents, without any intervention from external systems (i.e. it also works without a network), then, by definition, that password is sufficient to recover any encryption key and, ultimately, the data. Therefore, if at some point there are two passwords which are sufficient to boot, then the security cannot be stronger than that offered by the weaker of the two passwords. If one of these passwords is "test", then security is not high...

This might be recoverable by deleting the data elements related to the weak password. The conceptual mechanism is that the encryption key for the disk is encrypted, with a symmetric encryption algorithm, using as key something which is derived deterministically from the password (with a Key Derivation Function). Say, the disk encryption key is K, and the recovery partition contains EK1(K), EK2(K),... for keys K1, K2,... derived from the various passwords which can unlock the disk. There can be extra layers of indirection.

If password 1 is weak (key K1 is derived from a "guessable" password), then we want to prevent the attacker from learning EK1(K). Deleting that value ought to be enough, because the attack model is that the attacker, as some time T, steals the hardware altogether, and thus learns all the hard disk contents at that moment, but he has no knowledge of previous contents. This is subject to the following caveats:

  • Whether the values for account 1, when access is disabled, gets deleted, is unclear. I don't know the answer for that. It is not easily tested (you could try to reenable access for account 1 and see if typing the password for account 1 is needed for that, but even if it is not, it does not necessarily imply that the EK1(K) was kept around, because asymmetric encryption could be used).

  • Whether deletion from a disk really erases the data is a semi-open question. Most filesystems, when a file is deleted, don't overwrite the file contents; they just mark the space as reusable. When the file is specifically overwritten, whether the data really dies is debated, and the answer is likely to be different for a SSD.

  • FileVault 2 apparently has an option to store the encryption key (or something equivalent) on Apple's servers, which opens a whole range of new questions about the abilities which are thus conferred to Apple.

To sum up, it seems safer to assume that the data confidentiality offered by FileVault will be no stronger than the weakest of all passwords for all users who ever had access to the disk.

share|improve this answer
    
Thanks, this is helpful. In your second bullet point, I agree that it does not seem wise to rely on the security of the file system itself in order to really delete E_K_1 (K). Regarding the first bullet point, both Apple's documentation and an independent paper do not give much information. –  RobertR Sep 16 '13 at 19:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.