Posts Tagged ‘FileVault2’

FileVault 2 Part Deux, Enter the Dragon

Wednesday, January 30th, 2013

The Godfather of FileVault, Rich Trouton, has probably encrypted more Macs than you. It’s literally a safe bet, horrible pun intended. But even he hadn’t taken into account a particular method of institution-wide deployment of recovery keys: disk-based passwords.

As an exercise, imagine you have tier one techs that need to get into machines as part of their duties. They would rather not target-disk recovery partition boot(thanks to Greg Neagle for clearing up confusion regarding how to apply that method) and slide a valuable certificate into place and whisper an incantation into its ear to operate on an un-booted volume, nor do they want to reset someone’s password with a ‘license plate’ code, they just want to unlock a machine that doesn’t necessarily have your admin enabled for FV2 on it. Back in 10.7, before the csfde(Google’s reverse-engineered CLI filevault initialization tool, mostly applicable to 10.7 since 10.8 has fdesetup) command line tool, the process of adding users was labor-intensive as well. Even in fdesetup times, you cannot specify multiple users without having their passwords and passing them in a unencrypted plist or stdin.

In this scenario, it’s less a ‘get out of jail free’ card for users that forget passwords, and more of a functional, day-to-day let-me-in secret knock. How do I get me one of those?

Enter the disk password. (Meaning like Enter the Dragon or Enter the Wu, not really ‘enter your disk password’, this is a webpage, not the actual pre-boot authentication screen.)




How did we get here? No advanced black magic, we just run diskutil cs(short for coreStorage, the name of the quacks-like-a-duck-so-call-it-a-duck logical volume manager built in to 10.7 Lion and later) with the convert and -passphrase options, pointing it at root. We could encrypt any accessible drive, but the changes to login are what we’re focusing on now.

The end result, once the process finishes and the machine reboots next, is this(un-customizable) icon appears at the login window:


Remember that this scenario is about ‘shave and a haircut, two bits’, not necessarily the institution-wide systems meant to securely manage recovery options. Why haven’t you(or the Godfather) heard of this having been implemented for institutions until now-ish?  (Was he too busy meticulously grooming his links to anything a mac admin could possibly need to know, or composing the copious content to later link to? Say that three times fast!) (Yes, the disk password functionality has been around for a bit, but we’ve gotten a report of this being deployed, which prompted this post.) Well, there are two less attractive parts of this setup that systems like Cauliflower Vest and commercial solutions like Credant or Casper sidestep:

1. The password (for one or many hosts) needs to be sent TO a shell on the local workstations command line in some way, and rotating the password requires the previous one to be passed to stdin
2. It can be confusing at the pre-boot login window that there seems to be a user account called Disk Password visible

What’s the huge advantage over the other systems? Need to rotate the password? No decrypt/re-encrypt time! (Unlike the ‘license plate’ method.) Old passwords are properly ‘expired’! (Unlike the ‘Institutional Recovery Key’ method of using a certificate.) I hope this can be of use to the environments that may be looking for more ‘middle ground’ between complex systems and manual interaction. Usability is always a factor when discussing security products, so the additional method is a welcome one to consider the benefits of and, as always, test.

Regarding FileVault 2, Part One, In Da Club

Monday, January 28th, 2013


IT needs to have a way to access FileVault 2(just called FV2 from here on) encrypted volumes in the case of a forgotten password or just getting control over a machine we’re asked to support. Usually an institution will employ a key escrow system to manage FDE(Full Disk Encryption) when working at scale. One technique, employed by Google’s previously mentioned Cauliflower Vest, is based on the ‘personal’ recovery key(a format I’ll refer to as the ‘license plate’, since it looks like this: RZ89-A79X-PZ6M-LTW5-EEHL-45BY.) The other involves putting a certificate in place, and is documented in Apple’s white paper on the topic. That paper only goes into the technical details later in the appendix, and I thought I’d review some of the salient points briefly.

There are three layers to the FV2 cake, divided by the keys interacted with when unlocking the drive:
Derived Encryption Keys(plural), the Key Encrypting Key(from the department of redundancy department) and the Volume Encrypting Key. Let’s use a (well-worn) abstraction so your eyes don’t glaze over. There’s the guest list and party promoter(DEKs), the bouncer(KEK), and the key to the FV2 VIP lounge(VEK). User accounts on the system can get on the (DEK) guest list for eventual entry to the VIP, and the promoter may remove those folks with skinny jeans, ironic nerd glasses without lenses, or Ugg boots with those silly salt-stained, crumpled-looking heels from the guest list, since they have that authority.

The club owner has his name on the lease(the ‘license plate’ key or cert-based recovery), and the bouncer’s paycheck. Until drama pop off, and the cops raid the joint, and they call the ambulance and they burn the club down… and there’s a new lease and ownership and staff, the bouncer knows which side of his bread is buttered.

The bouncer is a simple lad. He gets the message when folks are removed from the guest list, but if you tell him there’s a new owner(cert or license plate), he’s still going to allow the old owner to sneak anybody into the VIP for bottle service like it’s your birthday, shorty. Sorry about the strained analogy, but I hope you get the spirit of the issue at hand.

The moral of the story is, there’s an expiration method(re-wrapping the KEK based on added/modified/removed DEKs) for the(in this case, user…) passphrase-based unlock. ONLY. The FilevaultMaster.keychain cert has a password you can change, but if access has been granted to a previous version with a known password, that combination will continue to work until the drive is decrypted and re-encrypted. And the license plate version can’t be regenerated or invalidated after initial encryption.

So the two institutional-scale methods previously mentioned still get through the bouncer unlock the drive until you tear the roof of the mofo tear the club up de- and re-encrypt the volume.

But here’s an interesting point, there’s another type of DEK/passphrase-based unlock that can be expired/rotated besides per-user: a disk-based passphrase. I’ll get to describing that in Part Deux…

Technical Overview of Mac Business Encryption methods

Friday, March 2nd, 2012

For a more in-depth look at security on the Mac, we’ll contrast the technical features (and limitations) of Mac full disk encryption methods. A balance that always needs to be struck when implementing a highly complex system is between maintainability and features. Employees need an easy to use yet reliable solution, and support personnel need to be able to consistently ensure that everything is functional and able to be audited. To understand the changes to encryption features leading up to the present, we’ll start by describing the implementation used by one of the most popular vendor’s, Symantec, and their PGP product.

PGP has a very long history in data encryption, and since Apple moved to the Intel processor platform (and EFI), they have been able to provide many features that were previously only fully supported on Windows. In an ideal situation, they and other vendors (like Sophos and McAfee) construct a way to tie your directory service to a keyserver, and therefore have authentication stay in one central place. Client software performs the local encryption on each workstation, and after completion users are granted secure access to a pre-boot environment, so only after authentication succeeds does the actual system boot. The encryption itself is based on a key that is independent of the user, multiple users including the admin can be added, and there is even a feature called the Recovery Token in case someone forgets their password (which gets regenerated after a single use, once the laptop then connects back to the keyserver).

The changes Apple made during its build-up to Lion jeopardized PGP’s pre-boot environment, which caused serious side effects. From Snow Leopard 10.6.6 on, Symantec had to be vigilant to insure their product was updated in a timely fashion, and many customers began to doubt the future viability of the solution. Businesses still wanted the features products like PGP offered, so a balance needed to be struck.

Apple released FileVault2 with Lion, and has since documented one method of achieving some sort of centralization: generating and storing the FileVaultMaster.keychain. A drawback of this process is many of the workflow steps surrounding it require custom, secure methods to be devised for implementing and auditing this process. Further, since support personnel need access to the single key that will unlock any machine encrypted with this process, the fact that the key cannot be easily reset and never expires becomes a prominent flaw.

Cauliflower Vest, as discussed previously, instead utilizes the recovery key. This reduces the risks associated with storing and retrieving the unlock mechanism centrally, as it is tied to each employee’s Google Apps account. It is sent and stored securely, and access controls can be put in place to grant access to support personnel. The csfde tool that is bundled with the project can also be used independently, if another data store or authentication mechanism to secure the transport and storage is preferable. Deployment and enforcement were priorities of the project as well, and a graphical interface to guide employees through setting up their encryption in a self-service manner round out the salient features. It can still be considered a compromise when compared to the functionality offered to businesses previously, but Google’s Macintosh Operations team should be commended for making available a feature-rich and flexible open source solution.

See Recovery Partitions in Lion

Thursday, September 15th, 2011

The Mac OS 10.7 Lion installer creates a hidden Recovery Partition on your boot device. By default this partition is hidden in the Disk Utility’s device and volume listings. You can reveal these hidden volumes in Disk Utility using the Debug menu, but first you’ll have to enable the menu with the Terminal command:

defaults write DUDebugMenuEnabled 1

Once enabled, open Disk Utility and select Show Every Partition from the Debug menu. Your hidden Recovery and EFI partitions should now be visible and available for imaging, etc.