First look: Full System Encryption in Mac OS X 10.7 “Lion”

One of the most valuable changes in Mac OS X 10.7 “Lion” is a complete overhaul of FileVault, Apple’s disk encryption system for protecting private data such as stored pictures, emails, documents and home movies.

In Mac OS X 10.4 and 10.5, FileVault could only be used to encrypt the “home folder” for each user, and it was widely criticized for a number of implementation flaws and security issues.

With 10.7 “Lion”, Apple intends to solve some of these flaws and significantly enhance security and privacy by turning FileVault into a disk level encryption system, not only for the main filesystem, but also for any external drive a user wants to protect with encryption.

While Apple is not the first to implement full system encryption, anyone running 10.7 will be able to use it, compared to Windows where an Ultimate or Enterprise edition of the operating system is needed to enable Microsoft’s system encryption feature called BitLocker (Truecrypt is a free alternative).

Linux has also had full disk encryption for a long time, however enabling it requires the operating system to be installed in a specific way, and encrypting the system afterward is difficult if not impossible using common and easy to use tools.

Apple’s implementation, like Truecrypt and BitLocker before it, allows the user to turn system encryption on and off at any time, only a quick reboot is required to start the encryption or decryption process, which happens in the background while your machine is being used.

Setting it up is very simple, all you need is a working installation of Mac OS X 10.7 “Lion” and a few minutes to click through the assistant.

The old FileVault preference area in System Preferences > Security has been replaced by a new Disk Encryption screen, offering just one button which allows you to turn on or off system encryption.

Apple’s system encryption implementation uses your existing user password to unlock the system during boot, which means you don’t have to set and remember a 2nd system password. However, forgetting your user password could prevent you from gaining access to your files, so Apple built in a “recovery key” that can be used to unlock the system.

Clicking the arrow next to “Show Recovery Key” will allow you to write the key down or copy it somewhere, but if you’re afraid you’ll lose that too, Apple has you covered.

While the idea of giving Apple a key to unlock your system could make some users uneasy, for the average user it’s a great feature to have. If you ever lose access to your encrypted Mac, you should be able to contact Apple and have them send you the recovery key after answering a few security questions.

That’s basically all there is to it, just a few simple screens and a restart button.

The next restart of the system presents you with a login screen. It looks a lot like the standard login screen, however until you enter a password, the OS itself hasn’t actually booted yet, and your disk is still locked (which is why I had to take that picture with my iPhone; screenshots at that stage of the boot process aren’t possible).

One nice detail that Apple got right is that once you enter your password at the boot unlock screen, you don’t have to enter it again to login.

After the system boots, it starts encrypting the disk in the background. This does cause things to be a bit slow (ok a lot slow) for a while, but once it finishes, the system will speed up a bit. Right now in the developer preview, performance isn’t perfect (especially disk writes), but expect that to improve by the time Lion is ready for release.

Encrypted external drives are even easier to setup, however you can’t encrypt a drive that already has files on it right now.

To create a new encrypted HFS disk, just open Disk Utility and you’ll see a new option when you visit the Erase screen for a hard drive.

You’re asked to enter a password, which unlike the system encryption password, is not tied to your user account, so you can take this drive and use it on another Mac so long as you remember the password.

The next time you connect the drive, this is what you’ll see: a simple password dialog box, entering the correct password allows the external drive to mount. Simple eh?

Hopefully Apple refines this new FileVault system even more, especially in the performance area, but I can say for myself I’m quite pleased with it so far.

That’s great. So this should be largely a functional replacement for PGP WDE and WinMagic. Both products had lengthy multi-month delays in getting new versions out for Snow Leopard, which delayed users upgrading to 10.6. And in PGP’s case, communications have been horrid and concerns notably increased after Symantec’s acquisition of them. WinMagic’s support has been good if you call them, but proactive communications from them regarding OSX updates and product compatibility issues have been problematic as well. I have no doubt that the OSX client base for both vendors is modest and internal resources are biased towards other platforms. It has reminded me of my years using Linux and dealing with nVidia and GPU drivers. You are the step child in the computer world.

One difference is the use of the user login password as the pre-boot unlock key, whereas PGP and WinMagic use lengthy passphrases, which were not tied to the user account, as seems to be the case for external HDs with Lion. One will want to seriously consider increasing the strength of the OSX user login password as a result.

http://twitter.com/EricStephens Eric A. Stephens

Have they solved the problem with the need to logoff in order to allow TimeMachine to backup the disk?

Anonymous

Apparently… there was also the other problem of having to log out to reclaim the disk space from deleted files, along with the inordinate time that took.

The actual encryption key is not the login password/passphrase. The pre-boot login only “unlocks” the use of the actual encryption key, which is used disk wide under this model, similar to PGP’s WDE and WinMagic, both of which I have used on OSX. Although there, you have a two step login process. First the system wide passphrase, to unlock the encryption and then your user account login. The new FileVault will, in effect, enable single sign-on.

Is it also similar to dm-crypt/luks, which I have used on Linux.

Thus, once a user logs in, account level R/W file/directory permissions, as now, would keep one user from seeing another user’s data. System-wide encryption protects the data from folks who would otherwise gain physical access to the HD, where they don’t have login access (eg. on a lost laptop).

Being disk-wide, it is therefore transparent to the OS and to applications. So real-time encrypt/decrypt of data during HD read/writes occurs, which would now allow, for example, Time Machine to function properly, unlike under the current FileVault implementation. You can also maintain encrypted TimeMachine backup HDs, which I do as well. System-wide encryption also protects other areas, such as system temp files/folders and swap space, where data would otherwise be written in the clear, as is the case with FileVault now.

I have not seen anything published anywhere to suggest that encryption of the individual directory trees (like FileVault now) is being done also. That would require user specific encryption keys, which means that you would be double encrypting, once at the disk level, once at the user level, which would really slow down throughput.

Perhaps they will offer the option to retain the current FileVault behavior at the user level as an option, if you don’t want disk wide encryption.

For external HD’s as noted, the encryption process will require a single login password/passphrase, nothing user specific.

For me, I am happily looking forward to Apple providing this functionality at the OS level, to get away from the aforementioned third party apps.

Anonymous

@Eric: Yes, from everything that is being published, this new approach will be transparent to FV. No more encrypted containers with sparse bundles…

@hyhybt: That should not be an issue, again as this new approach should be at the OS level and transparent to normal file operations, because you are not dealing with encrypted containers.