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.