Posts Tagged ‘filevault 2’

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.)

 

diskPasswordification

 

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:

diskPassicon

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

FileVaultIcon

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…

Lion’s New Security Features, Manageable for Businesses with a Solution from Google

Friday, February 24th, 2012

The big cat, Lion, has been out of the bag for a while, and even with Mountain Lion slated to come out this Summer, many are still devising strategies to tame it. In particular, there’s been uncertainty about the update to Apple’s encryption solution, FileVault. In the past it wasn’t as fully featured as encryption solutions from Symantec (PGP) and others, but the functionality of those third party products has been faltering due to ‘plumbing’ changes Apple’s made in order to accommodate, new with Lion, FileVault2 – their higher-performance, whole disk encryption solution.

From a security and ease-of-use perspective, when you encrypt the entire hard drive (or ‘disk’), your documents are much safer if your laptop should happen to be lost or stolen. Only user accounts granted access to un-encrypt the computer (which happens just by logging in with your user name and password like normal) can get at the files. However, there is a ‘get out of jail free’ card provided, just in case you forget your password – the Recovery Key, which is a 24-character code that Apple can even store for you.

When using FileVault 2 in Lion, businesses lose several features they would otherwise have with 3rd party whole disk encryption solutions: we’d like to store that key centrally for our company, keep an inventory on which computers are encrypted, and not worry what user account encrypted the computer when we need to re-deploy it for someone else. Apple’s consumer-focused, manual process for storing the Recovery Key doesn’t help us, so Macintosh Operations at Google have stepped onto the scene with a solution: Cauliflower Vest.
Yes, the name is… distinct, but really it’s just an anagram (same letters, different words) for FileVault Escrow, which means storing the FileVault Recovery Key centrally. A big caveat of using this solution is that it relies on a Google Apps account for every employee whose machine you’d like to use FileVault with. Generously, Google’s Mac Ops team took the time and went the distance to allow us to adapt their tool for use with other centralized systems.

Adjusting to the new changes in Lion can be a considerable amount of work for many administrators. 318 has been a reseller for Google Apps and can also build custom solutions that adapt open source products to your businesses needs. For assistance, please contact your 318 Professional Services Manager, or sales@318.com if you are not yet a customer.