FileVault
FileVault is a system which encrypts files on a Macintosh computer. It can be found in the Mac OS X v10.3 "Panther" operating system and later.
FileVault uses encrypted file systems which are encrypted and decrypted on the fly. A master password (and recovery key in 10.7+) is created as a precaution against a user losing their password. Although early versions were slow and caused a system to temporarily hang when used with disk-intensive applications, such as sound and video editing, the performance of FileVault has been improved in more recent versions of Mac OS X.
In Mac OS X v10.4 "Tiger" and below, FileVault stores the encrypted file system as a Sparse Disk Image, which is basically a single large file. In Mac OS X v10.5 "Leopard", FileVault stores the encrypted file system as a new image called a Sparse bundle.[1] Sparse bundles break images into smaller 8MB files called bands, allowing them to be backed up using Leopard's Time Machine feature (see below for limitations, however). If transferring FileVault data from a previous Mac that uses 10.4 using the built-in utility to move data to a new machine, the data continues to be stored in the old sparse image format, and the user must turn FileVault off and then on again to re-encrypt in the new sparse bundle format. FileVault 2, introduced in Mac OS X v10.7 "Lion", encrypts entire disks rather than users' home folders. This also solves the compatibility problems related to backup, as the encryption is transparent to backup software when the operating system is running.[2]
Contents |
[edit] Migration
[edit] Outdated versions of the OS
Migration of FileVault home directories is subject to two limitations:[3]
- there must be no prior migration to the target computer
- the target must have no existing user accounts.
If Migration Assistant has already been used , or if there are user accounts on the target:
- prior to migration, FileVault must be disabled at the source.
[edit] Complements
[edit] Disk Utility encryption of images of folders
If the user prefers to encrypt only part of their home directory — for example, ~/Documents/private — they may:
- disable FileVault
- use Disk Utility to image and encrypt the folder (sparsebundle, with encryption, is suitable)
- after encryption, trash the unencrypted original then use Finder to securely erase whatever is trashed.
If the OS or an application requires the unencrypted data to be found at its original path, then a symbolic link can be made, and the image file added to login items, and the password for the image added to the login keychain, but some such things are not for the average user. Rather than give special attention to just parts of a home directory, it may be simpler to allow FileVault encryption of the whole.
[edit] Limitations
[edit] Backups
- These limitations apply to versions of Mac OS X prior to v10.7 only.
Without Mac OS X Server: Time Machine back up of a FileVault home directory, to a local volume, can occur only whilst the user is logging (or logged) out. From such volumes:
- Time Machine is limited to restoring the home directory in its entirety
- if anything less than that is to be restored, Finder can be used.
With Mac OS X Server as a Time Machine destination:
- backups of FileVault home directories occur whilst users are logged in.
As FileVault restricts the ways in which other users' processes can access the user's content, some third party backup solutions can back up the contents of a user's FileVault home directory only if other parts of the computer (including other users' home directories) are excluded.[4][5]
[edit] Scope
FileVault is limited to encrypting home directories only in versions of Mac OS X prior to v10.7, and only those directories in their entirety. Starting with Mac OS X v10.7, FileVault only encrypts entire disks.[6]
[edit] Security
|
|
This table may contain original research. Please improve it by verifying the claims made and adding references. Statements consisting only of original research may be removed. More details may be available on the talk page. (September 2011) |
|
|
The neutrality of this article is disputed. Please see the discussion on the talk page. Please do not remove this message until the dispute is resolved. (November 2011) |
Filevault 2 on 10.7 lion uses 128-bit AES encryption in NIST-recommended[7] XTS-AESW mode. It encrypts the entire hard drive, unlike FileVault 1 which only encrypted the user's directory.
The use of 128 bit AES rather than 256 bit AES would represent a vulnerability only if a flaw were found in the algorithm that made it easier to attack smaller keys. Currently, a 128 bit key is considered long enough to be immune to brute force attack. When encrypting a disk with FileVault 2, the user is given a 24-character alphanumeric "recovery key", which is stated to be case insensitive. Thus, we have 24 characters, each of which have 36 possibilities. As there are only approximately 2^124 possibilities for such a key, this "recovery key" loses a further 4 bits of key entropy, leaving FileVault 2 with effectively 124 bit keys. While a 124 bit key should also be theoretically secure, it remains to be seen what other flaws may exist that this slight weakness could be combined with to possibly lead to insecure encryption.
FileVault employs the user's login password as the encryption pass phrase. This discourages use of cryptographically strong pass phrases. The average user will not wish to type in a pass phrase with 128 bits of entropy every time they log in to the computer, open a secure system preference, allow privilege escalation of a running program, unlock the screen saver, and so on. If the user chooses to do this, they must type in a long pass phrase every time they do these things. If they choose a weak login password or passphrase, then FileVault 1 or 2 can be broken by brute force. FileVault 2 enables the administrator to designate a number of user accounts authorized to decrypt the system disk. This means that if any one of those users has a weak pass phrase, then the system is only as secure as the weakest pass phrase chosen by any of those users.
[edit] First generation issues
Several shortcomings were identified in the first generation of FileVault. Its security can be broken by cracking either 1024-bit RSA or 3DES-EDE, both of which are considered weaker than 128-bit AES[citation needed]. Since 3DES-EDE is used only for key wrapping in FileVault-1 (and the amount of plaintext involved is quite small) - it is unlikely that 3DES weaknesses extend beyond purely theoretical.
FileVault first gen's used the CBC mode of operation (see Disk encryption theory); FileVault 2 uses stronger XTS-AESW mode. Another issue is storage of keys in the Mac OS X "safe sleep" mode.[8] A study published in 2008 found data remanence in dynamic random access memory (DRAM), with data retention of seconds to minutes at room temperature and much longer times when memory chips were cooled to low temperature. The study authors were able to use a cold boot attack to recover cryptographic keys for several popular disk encryption systems, including FileVault, by taking advantage of redundancy in the way keys are stored after they have been expanded for efficient use, such as in key scheduling. The authors recommend that computers be powered down, rather than be left in a "sleep" state, when not in physical control by the owner.[9]
Early versions of FileVault automatically stored the user's passphrase in the system keychain, requiring the user to notice and manually disable this security hole.
[edit] See also
[edit] References
- ^ http://macosx.com/article/live-filevaultsparse-bundle-backups-in-leopard.html
- ^ http://www.apple.com/macosx/whats-new/features.html#filevault2
- ^ Mac OS X 10.3, 10.4: Transferring data with Setup Assistant / Migration Assistant FAQ
- ^ Using CrashPlan with FileVault [CrashPlan PRO Support Site]
- ^ Using Encrypted Disks [CrashPlan PRO Support Site]
- ^ http://www.apple.com/macosx/lion/
- ^ http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf
- ^ Jacob Appelbaum, Ralf-Philipp Weinmann (2006-12-29) (PDF). Unlocking FileVault: An Analysis of Apple's disk encryption. http://events.ccc.de/congress/2006/Fahrplan/attachments/1244-23C3VileFault.pdf. Retrieved 2007-03-31.
- ^ J. Alex Halderman, et al. (February 2008). Lest We Remember: Cold Boot Attacks on Encryption Keys. http://citp.princeton.edu.nyud.net/pub/coldboot.pdf.