fdesetup

Validate a FileVault recovery key using a .plist file

If you want to validate your FileVault recovery key from the terminal, you can do

sudo fdesetup validaterecovery

and then be prompted for the recovery key.

But what if you want to use a .plist to validate the recovery key instead of getting prompted for the key? This is where it's a bit counterintuitive, at least as far as I've tested on macOS 10.12.6 and 10.13.1.

When you enable FileVault using a command like

sudo fdesetup enable -outputplist > /PATH/TO/RECOVERYINFO.plist

it generates a .plist at RECOVERYINFO.plist with the recovery key and some other keys (EnabledDate, EnabledUser, HardwareUUID, LVUUID, RecoveryKey, and SerialNumber).

But if you try to validate the recovery using that .plist, the command will just hang.

The reason it hangs is it's looking for the Password key in the .plist instead of the RecoveryKey key (which is the one fdesetup generated!). From the the man page for fdesetup:

fdesetup validaterecovery -inputplist < /fvinput1-recoverykeyonly.plist
Gets the existing personal recovery key in the "Password" key value of the plist and returns
"true" if the recovery key appears to be valid

The Crypt project actually takes the RecoveryKey out and then temporarily creates a .plist with the Password key in order to validate.

So, yeah, if you're not using Crypt, you'd essentially have to do that—copy the RecoveryKey key to be a new Password key in order for this command to work:

sudo fdesetup validaterecovery -inputplist < /PATH/TO/RECOVERYINFO.plist

Setting up deferred FileVault encryption

In Enabling FileVault Encryption for Client Macs, I mentioned that deferred enablement is one option for mass-deploying encryption to clients, with the major downside that you can enable it for only one user and not multiple users at once.

If you do want to go that route, though, this is the command (assuming you're using an institutional recovery key) you would use:

sudo fdesetup enable -user USERNAME -defer /PATH/TO/recovery.plist -norecoverykey -keychain -forceatlogin 10

where USERNAME is the username of the user you want to defer enablement for (otherwise, it will just be the last user to log out) and /PATH/TO is where you want to put the deferred-enablement info—the info itself is not sensitive, but I'd probably plop in some place like /private/var/root, just so no one messes with it by accident.

This will also allow the user to put off enabling FileVault encryption ten times before she's forced to enable it. You can adjust the -forceatlogin number to whatever you think makes sense for your organization.

Check the deferral status with

sudo fdesetup showdeferralinfo

If you haven't yet run deferred enablement, the result will be

Not found.

(end period included). If you have run deferred enablement, you'll get back an array of results from the .plist:

{
Defer = 1;
NoRecoveryKey = 1;
OutputPath = "/PATH/TO/recovery.plist";
UseKeychain = 1;
Usernames = (
USERNAME
);
}

To check FileVault general status (not deferral status) run the command

fdesetup status

which will return

FileVault is Off.

(end period included) if FileVault is not yet enabled and

FileVault is On.
FileVault master keychain appears to be installed.

(end periods included) if it is enabled.

So if you have a script checking for whether to do a deferred enablement, you probably want to check that FileVault is Off and that deferral info is Not Found.

After FileVault encryption is enabled, the deferral information will still be there, but

fdesetup status

will show

FileVault is On.

Enabling FileVault Encryption for Client Macs

Difficulties in automating FileVault

FileVault encryption is unfortunately one of the things for Mac admins that is extremely difficult to automate.

Crypt

There's a project called Crypt that involves a login hook that checks whether encryption is enabled or not and then prompts the user to enable encryption. Once that's done, the individual recovery key is sent to a Django webapp.

You can create text files with usernames and plain text passwords to import in to automate FileVault encryption: Managing El Capitan’s FileVault 2 with fdesetup.

addCurrentUser script

You can use a script that prompts the current user to enable FileVault encryption.

My sort-of version of Crypt

I did a slight modification of the Crypt approach by creating a logout script that checks whether encryption is enabled or not. If it's not, the user will see the FileVault tab of System Preferences when she logs in:
FileVaultCheck.sh

No perfect solution

At the end of the day, though, someone has to be prompted to manually enter passwords or you have to store passwords in plain text somewhere. If you are a Mac admin who wants a local admin account to be enabled as a FileVault user but also want your individual laptop users' accounts also enabled, it's not feasible (or a good idea) to collect all of their passwords and store them in plain text in a file somewhere or several files.

The safest but still troublesome way to enable FileVault encryption is to enable it for the local admin account, enable it for the primary user, and then grab her to enter her password right away.

You can also defer enablement (which will prompt the user at login or logout to enable FileVault), but, according to Rich Trouton, this can be done for only a single user and not multiple users.

Details on enabling users

Here's a bit of a weird thing that I didn't see documented anywhere.

If you have accounts that already exist—say, Constance, Randall, and Hudson—and Constance enabled FileVault encryption, then Randall and Hudson will not be able to decrypt the machine unless Constance knows their passwords and manually enables their accounts to be able to use FileVault.

If, however, Constance is the only user of the machine, and she enables FileVault, and then she decides to add Randall and Hudson as new users afterwards, Randall and Hudson will automatically be able to decrypt the computer. This generally works, but I've also seen situations in which it doesn't (for example, if you delete a user account and then re-add one with the exact same name—the "new" account will not be able to decrypt the computer until you enable the user manually to do so).

Creating the institutional recovery key

If you want to use an institutional recovery key (instead of collecting automatically-generated individual recovery keys), I found this PeachPit tutorial (by Rich Trouton) to be the clearest. I'll boil down the steps here with minimal explanation.

Create the FileVault master keychain:

sudo security create-filevaultmaster-keychain /Library/Keychains/FileVaultMaster.keychain

Don't forget the password you create it with.

Copy it somewhere:

cp /Library/Keychains/FileVaultMaster.keychain ~/Desktop/

Once a copy is on your desktop, you may want to make many more copies to store in different places.

Unlock the keychain:

sudo security unlock-keychain /Library/Keychains/FileVaultMaster.keychain

Launch up /Applications/Utilities/Keychain Access and then go to File > Add Keychain to add the keychain you created.

Click FileVaultMaster from the left pane and then select the private key and delete it.

Then right-click FileVaultMaster and lock it.

Then distribute a .pkg whose payload will be that keychain (sans private key) to /Library/Keychains on your client machines.

Using the institutional recovery key in recovery mode

In theory, you probably have a local admin account that can decrypt the computer, but if you give a user admin privileges and the user accidentally deletes the local admin account or changes its password and then forgets what the new password is (along with the user's own password), that's when your institutional recovery key can come in handy to decrypt the drive. In other words, you should probably never need it, but it's nice to have as a failsafe. I mean, you're backing up the user's data with CrashPlan (or some other backup solution) anyway, but you may still want to decrypt the drive.

For more details, check out Using a FileVault institutional recovery key to unlock an encrypted disk