Lots of rumors and hushed voices have accompanied the buildup to Google’s Macintosh Operations team revealing they had cracked the FileVault2 key escrow ‘nut’. All they had been saying up until recently was… don’t use institutional keys. Now the fruits of their labor have been open sourced, and wouldn’t you guess? It’s very google-specific (echoing Simian before it, a major part relies upon Google App Engine), but who’s concerned with that when they’ve even shared the building blocks that make up the solution (after navigating the undocumented API’s to achieve our common goal).

As an exercise, I used the csfde binary that was released along with the tools and documented the process (top left in this diagram, probably having something to do with ‘core storage full disk encryption’). First, I needed the source code, which you could download here or use git from here if you’re savvy. Then, as I was running this from a new machine, I’d need Xcode. A quick trip to the Mac App Store later the .app was installed… and while I thought I was good, I didn’t realize I only had the IDE. When I tried to build the csfde.xcodeproj file… I couldn’t figure out where the binary was supposed to pop out on the other side. And then I went to that path in the terminal and got this message:

Allisters-MacBook-Air:csfde 318admin$ xcodebuild

xcode-select: Error: No Xcode folder is set. Run xcode-select -switch <xcode_folder_path> 

That wasn’t particularly illuminating, but luckily all i needed was a quick trip to Xcode’s Preferences > Downloads to get the command line tools.

Then I decided to come at it from another angle: plain ol’ make. Having an affinity for makefiles due to a particular project, I saw that I could call make csfde from the root of the cauliflowervest source code folder - but Xcode wasn’t actually done barking at me, I needed to set my Xcode path with xcode-select -switch /Applications/Xcode.app before make would run…just like I was told above. And then I had csfde right where I wanted it! …in the src/csfde/build/Default folder. Y’know.   

After checking the BSD name of my boot disk,

I fed csfde the options it wanted, and I was off to the races. Well, the drive wasn’t supposed to actually start encrypting until after a reboot, but I had my recovery code spit out and the stage was set!

And since new things like this are worth testing, I verified the recovery code works… and doesn’t expire after use… and can’t be swapped out at present without de- and re-encrypting…. and you can only give one user access at a time with the csfde tool (as Greg Neagle points out here).

All in all, it works as advertised. Just like how the MDM solutions can only work with the API’s that are exposed as updates occur… file those radars early and often to get a documented solution AND in anticipation of OS updates!