Bruce Schneier
Schneier on Security
A blog covering security and security technology.
« Lousy Password Security on Tesco Website | Main | Rudyard Kipling on Societal Pressures »
August 16, 2012
An Analysis of Apple's FileVault 2
This is an analysis of Apple's disk encryption program, FileVault 2, that first appeared in the Lion operating system. Short summary: they couldn't break it. (Presumably, the version in Mountain Lion isn't any different.)
Posted on August 16, 2012 at 6:49 AM • 21 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Patrix • August 16, 2012 9:58 AM
AFAIK all users on a Mac have access to the whole disk after login, within the limits of Unix access rights. Doesn't this limit the protection offered by FV2 to the quality of the weakest user password?
Cliff • August 16, 2012 10:02 AM
I also wonder about hacks via Firewire or Thunderbolt, didn't see any mention of that in their paper.
Philippe • August 16, 2012 10:08 AM
If I remember correctly. You can specify which accounts can unlock the decryption of the filevault, in effect limiting who can start the computer after a shutdown.
Chris W • August 16, 2012 10:42 AM
@Cliff
They mention it in 4.4 last paragraph.
I do wonder how easy it will be to extract the encrypted master key, for offsite bruteforcing. With sufficient resources no password except the very best will be safe enough.
Still, I would bet on dropping in a piece of malware that extracts the decryption key from memory and store it somewhere I can get to. Then we can at least decrypt it if he/she happens to shutdown the device during a police raid.
Full-drive encryption is only as good as the weakest driver.
Then again, moderate security is sufficient for 99.9% of us. No use looking at it in black and white.
AlanS • August 16, 2012 11:08 AM
Nasty bug: http://cryptome.org/2012/05/...
FileVault 2’s Apple ID Backdoor
http://mjtsai.com/blog/2012/08/07/...
According to reviews last year FV2 involves a huge performance hit and changing the recovery key requires de-crypting and re-encrypting the drive.
Clive Robinson • August 16, 2012 11:10 AM
From what is written the system appears to be reasonably OK from the "Data at Rest" point of view...
However from reading the paper I can see one possible fly in the ointment with the initial setup and the Random Number Generator.
From what has been written the OS RNG is "based" on Yarrow (which has been a superseded design for some time now) [1].
Very roughly Yarrow is based on the idea of an "entropy pool" which when a system is powered up would be empty. As entropy is very hard come by on modern computer systems and accrues relativly slowly Yarrow stores the entropy in a periodicaly updated file to "save some of the entropy" in the event of a system crash etc
What is not said in the paper is what the contents of that file are (or if it exists) on first bootup, or if there are safeguards in place.
So what is unknown from the paper (and as far as I'm aware Apple has not said) is what happens if you turn on a "factory fresh" system and immediately activate FileVault, that is just how "random" is the recovery key going to be from system to system?
[1] Yarrow was developed by Bruce Schneier, Niels Ferguson and John Kelsey ( http://www.schneier.com/paper-yarrow.html ) as a Cryptographicaly Secure Pseudo Random Number Generator (CSPRNG) and is fully Open Source and is used on OpenBSD and other *nix's of which MacOS X is one.
James Sutherland • August 16, 2012 11:30 AM
@Patrix: No; with FileVault, each user home directory becomes a separate volume (sparsebundle) mounted only when they log in. It used to carry a significant performance hit (you were loopback-mounting one journalled filesystem on top of another), though they improved that lately.
@Cliff: Firewire/Thunderbolt give you the ability to modify the system's memory on a hardware level. If you capture a machine with the filesystem mounted (i.e. the encryption key still in memory) you could get in that way - otherwise, it's useless.
In short: to get in, you need the key - either from the system's own RAM or the user (or some variant, such as a keylogger). Pretty effective security, for once.
James Sutherland • August 16, 2012 11:40 AM
Clive: A factory-fresh machine will lead you through several steps first, including downloading updates, connecting to your network, selecting or taking a picture for your account - by the time you reach the first opportunity to enable FileVault, the hardware interrupts alone should have provided enough system entropy for a secure key.
It looks as if all current shipping hardware includes Intel's hardware RNG, too, in which case presumably the random key is generated using that thermal noise. Good luck predicting that...
Patrix • August 16, 2012 2:06 PM
@JamesSutherland: Separate bundles is FV1. FV2 is whole disk encryption. Once I'm logged in I can access the home directories of all users. And logging in only requires my usual login password (which is then used to unlock the disk key) that's why I wonder how attack-proof the whole thing really is. The encryption itself may be very strong but there seem to be ways around it.
Patrix • August 16, 2012 2:10 PM
And now that I had time to read the paper itself:
"Our work allows [...] to decrypt any data from a FileVault 2 encrypted
volume, when the user password [...] are known." (ch5/Conclusions)
James Sutherland • August 16, 2012 4:14 PM
Thanks Patrix - yes, an interesting change from FV1. I had worried that this would mean ANY user account - even a shared guest-style account for a friend to check email with - would blow the whole disk wide-open, but at least the disk encryption key is only available to the designated users (when you enable FV2 on a multi-user Mac, you are asked to designate which users will be given this access: anyone without that access will have to ask someone else to unlock the machine on bootup before they can log in).
Given the work Apple put in to getting nested NFS+ filesystems working well for FV1, I would not be surprised to see the separate encrypted home directory sparsebundles return in a future version to guard against this - or indeed a third party tool restoring this functionality now.
jml • August 16, 2012 4:14 PM
@Patrix first post:
You're rightish about the weakest-user-password issue. What's new to me from the article is that in a cold-machine state, if multiple accounts on the Mac are FV2 unlock-enabled, your strength is limited by the weakest password of any of the enabled accounts.
Obvious, yes, but - in some scenarios, you may have local-admin users, probably with domain- or directory-joined accounts where there's enforcement of password quality. Unless the local-admin user creates one or more local accounts and unlock-enables them for cold-boot decryption before enrolling. The local-account password quality enforcement available in OS-X, if you even know to turn it on, is really limited.
@AlanS above, and adding or removing FV2 unlock-enabled accounts does seem to involve unenrolling/decrypting and re-enrolling/encrypting the whole volume.
See also http://support.apple.com/kb/HT4790
I found the paper to be very helpful in thinking about FV2, and what advice those using it need to be provided.
-jml
D. G. • August 16, 2012 5:01 PM
FileVault Vulnerability and How to Protect Yourself, privacycast blog, Feb 3 2012.
Well, theory has become practice, albeit in a very constrained way. A forensic software company called Passware has announced that the latest version of their Passware Kit Forensic (version 11.4, cost: US$995) can extract the keys to FileVault 2 in an average of 40 minutes regardless of the length and complexity of the passwords. This is a bit of hyperbole, however, as the conditions under which the password can be recovered are highly constrained, and it turns out, easily remedied.
The idea being that cryptographic strength alone is not the measure of the security of a system. There's also other system vulnerabilities for the wily user to wind their way through such as FileVault 2’s Apple ID Backdoor.
There's also the ability to create writable disk images (see Encrypt Folders with Password Protection in OS X the Easy Way, OS X Daily, 12 August 2012) That allows you to keep the pass phrase (key) out of your keychain, putting the onus of key management on the user.
After 10.7.2 you are at least protected against DMA memory access via expansion bus (FireWire, Thunderbolt) while your machine is asleep.
Karl Schmidt • August 16, 2012 5:55 PM
Of course, without the source code being made available, you have no idea if there is a back-door installed for government organizations.
MingoV • August 16, 2012 6:23 PM
I believe that whole disk encryption is counterproductive for typical users. It provides a false sense of security: anyone who can access a running Macintosh computer for a minute can acquire a login password without the owner's knowledge.
My top three Macintosh computer data security recommendations are:
1. Avoid using the Keychain utility for important passwords.
2. Store documents that need security in an encrypted disk image* that has a strong password.
3. Unmount encrypted disk images when not in use (including even brief periods of being away from the computer).
To make the latter easier, I wrote applets that run in the background and unmount encrypted disk images after "x" minutes of idle time or when the computer goes to sleep.
*Other advantages to this approach (vs. whole disk encryption) are easy and secure backups of encrypted disk images, fewer slowdowns and problems related to disk fragmentation, and access to other files if the owner forgot the password or is unavailable (away, incapacitated, dead).
some_pondering_admin • August 17, 2012 1:10 PM
@MingoV
I like and agree with much of what you say. I am just wondering though, for point 2 (Store documents that need security...), if you have thought about cached files, other silent backups, and the human proclivity to err (accidentally misfiling or mislabeling documents)?
Those are the points that to me shout 'mandatory whole disk encryption' when it comes to corporate use. Yes, individuals should be able to accept the risk that they under-protect their own data but when it comes to the data of others, which they are responsible for in the course of their work, I don't think they get to make that call.
What do you think? (PS remember, I mostly agree with you and I especially like your solution to 3.)
Bill • August 17, 2012 9:09 PM
"It provides a false sense of security: anyone who can access a running Macintosh computer for a minute can acquire a login password without the owner's knowledge."
That's an interesting theory. How? Would love to see your proof.
Jason T. Miller • August 19, 2012 2:43 PM
@James Sutherland,
The biggest difficulty for a third party providing encrypted home directory support on anything more than a "YMMV" basis, I think, would be ongoing QA and testing, as Apple continues to harden file permissions and tweak their sandboxing model with each major and minor release. For example, do application-scoped bookmarks [1] to files in a user's home directory persist when this home directory is subsequently encrypted, decrypted, or re-encrypted? Will they continue to do so when Apple changes the implementation in a subsequent point release? And so on.
Louis St-Amour • September 8, 2012 12:07 AM
Very useful, includes sections on auto-erasing FV key when entering sleep mode as well as setting up firmware passwords to prevent FireWire/Thunderbolt attacks: http://training.apple.com/pdf/WP_FileVault2.pdf
Of course, that document also reveals a few known shortcomings and is meant for choosing a deployment strategy. One major point is the lack of Windows/BootCamp compatibility, but with RAM so cheap, I'm sure many of us virtualize instead.
gerosnet • September 20, 2012 8:59 PM
if somehow your mac gets a software keylogger, can it retrieve the passwords needed to enter your data?
Bohdi • November 3, 2012 4:43 PM
If I have located the Full Volume Master Key in memory, how can this be used to mount/gain access to either an image of the FV2 protected Mac or the actual Mac?
Subscribe to comments on this entry
Post a comment
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.
|
| Subscribe |
Subscribe via Kindle |
| Blog Menu |
SearchPowered by DuckDuckGoBlog Home Page
Archives by Date2013 J F M A M
Tags  |
| Latest Book |
more books by Bruce Schneier |
Comments