Posts Tagged ‘cauliflower vest’

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…

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.

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.