Tag: filevault

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

Basics of Crypt 2 and Crypt Server

Graham Gilbert created a pretty cool project called Crypt 2, which forces client machines to enable FileVault2 encryption, and then sends the recovery key to a Crypt Server.

So far the documentation on Crypt 2 is rather sparse, so this is what I was able to piece together based on the README, some asking around, and a lot of trial and error.

The server

The server bit was tricky for me to figure out. I happened to have a Ubuntu 16.04 LTS server I wanted to try it out on, but the Ubuntu 14.04 and Ubuntu 12.04 instructions did not work for 16.04. I got this error when trying to run the command to get the requirements:

Collecting django-extensions==1.6.8 (from -r
crypt/setup/requirements.txt (line 4))
Could not find a version that satisfies
the requirement django-extensions==1.6.8 (from -r crypt/setup/requirements.txt (line 4)) (from versions: 0.4, 0.4.1, 0.5, 0.6, 0.7, 0.7.1, 0.8, 0.9, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.3.0, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.3.8, 1.3.9, 1.3.10, 1.3.11, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.6.1, 1.6.2, 1.6.3, 1.6.5, 1.6.6, 1.6.7, 1.7.0, 1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.7.6, 1.7.7)
No matching distribution found for django-extensions==1.6.8 (from -r crypt/setup/requirements.txt (line 4))

It seems a lot of people go the Docker route. I'm not really an experienced Docker user, but most of the instructions are fairly straightforward.

After you install Docker, you just pull Crypt Server:

docker pull macadmins/crypt-server

Then, to test Crypt out, try the sqlite instructions from the docs.

And then, when you're ready to go full production, scrap that container, get a proper postgresql database and then follow the Using Postgres as an external database instructions.

Special notes based on things Graham Gilbert (primary developer on Crypt) told me:

  • You should not use the sqlite3 database for production. Nor should you use grahamgilbert/postgres as a docker container for a postgres database to link up. For a production Crypt server, you should link up to an external postgres database, preferably Amazon RDS or Google Cloud SQL.
  • For an external postgres database (whether self-hosted or hosted in the cloud), all you need is a database name, a username, and a password. Crypt will do the rest (creating tables and populating them).
  • If you decide to host the postgres database on the server that's running the docker container, localhost (or 127.0.0.1) is the actual Crypt docker container—it is not the host running docker. So you should specify the host as the actual fqdn or IP address.

Whether you ran the test Crypt with sqlite3 or a proper production Crypt with postgres, you should be able to see your site at 0.0.0.0:8000.

There are ton of ways, apparently, to get the site more secure. Since I'm most familiar with using Apache, I just put in a :443 VirtualHost entry with

ServerName SUBDOMAIN.MAINDOMAIN.COM:443
ProxyPass / http://0.0.0.0:8000/
ProxyPassReverse / http://0.0.0.0:8000/
and then that worked out for getting SSL going (as long as you've got SSL going for SUBDOMAIN.MAINDOMAIN.COM... that's too much to go into for one blog entry).

Once you have that set up, go to https://SUBDOMAIN.MAINDOMAIN.COM and log in with admin and password, and then immediately change the password to a new one.

You'll then have the option to add other users with various types of permissions.

The client

The Crypt 2 client is a standard .pkg you can deploy with whatever you're using to manage your client machines. You can configure your clients' Crypt 2 preferences before deploying the .pkg.

When the user who's okay to enable encryption (one not in the SkipUsers array) logs in, a window will pop up that says This machine must be encrypted. It will reboot shortly after clicking continue.

Crypt will write a file to /var/root/crypt_output.plist with values for EnabledDate, EnabledUser, HardwareUUID, LVGUUID, LVUUID, PVUUID, RecoveryKey, and SerialNumber.

After that, probably nothing will happen for some time. Crypt 2 runs a Launch Daemon that invokes /Library/Crypt/checkin every 900 seconds (15 minutes) 120 seconds (2 minutes). After around that time, you should see the client machine show up in the web interface the admin sees.

If you're using a self-signed certificate on your Crypt server, the curl command in the checkin script will fail when escrowing the recovery key. To avoid that (thanks to Graham Gilbert for the tip), you can add the .pem somewhere on the client machine and modify the .curlrc file for root to point to it.

If you click Info... ...and then Info / Request... ...and then Retrieve Key... ... you should be able to see the recovery key.

You may have to ask permission of yourself to view the recovery key (presumably if you have users with different permission levels, a user with lesser permission would ask an admin user for temporary permissions to view the recovery key).

Other options

This isn't a comprehensive list:

Why you should use FileVault personal recovery keys instead of institutional recovery keys

In my previous blog posts on FileVault, I talked about or showed how to use an institutional recovery key for FileVault encryption:
Enabling FileVault Encryption for Client Macs
Setting up deferred FileVault encryption
Using a FileVault institutional recovery key to unlock an encrypted disk

But in exploring FileVault further, I've found it's much better to use personal recovery keys instead of a single institutional recovery key, and it's not for the reason you might think.

IRK not necessarily less secure than PRK

Yes, from a security standpoint, you could make the case that an institutional recovery key creates a single breach point (someone obtains that one recovery key and thus can decrypt all your institution's machines), but I don't think this makes personal recovery keys more secure necessarily. First of all, the personal recovery key itself can unlock a machine, but the institutional recovery key is used in combination with a password to unlock the keychain. Secondly, most likely you're storing your personal recovery keys all in one place—it may be a secure place, but it's also a single breach point. If you somehow access that one storage location (database, spreadsheet, whatever you're using to store the personal recovery keys), you have access to all the recovery keys for all the machines.

I suppose you could scatter the personal recovery keys in multiple storage locations. There is always an artistic (not scientific) balance between security and convenience, so that's up to you how you decide to store things. The point, though, is that an IRK is not necessarily less secure than a PRK.

You could make the case that with something like Crypt2 you at least have an audit trail of when recovery keys were accessed, and you can generate new ones, so personal recovery keys do have one small distinct security advantage.

IRK is less useful than a PRK, though

As I was rolling out encryption to our fleet using an institutional recovery key, I started to realize through testing (fortunately not through an actual emergency) how limited in functionality the institutional recovery key is compared to the personal recovery key.

First of all, unless you are physically in front of the machine or using ARD to remote into a virtual session, you cannot enable another FileVault user without storing the password for it in plain text. If you try to do so via SSH and the command-line, you'll be prompted for the password of an FV-enabled user or for the personal recovery key, so having the IRK doesn't help there.

That's not really the worst part. The worst part is that, as far as I can tell (based on Google searches, asking other Mac admins, and just trial and error), there is no way to reset a forgotten user password with just the institutional recovery key. You can unlock the encrypted volume and save the data, but you can't just say "Reset this user's password." You can, as a horribly long workaround, decrypt the drive, log in as another admin user, reset the other user's forgotten password, wait for the decryption to finish completely, and then re-encrypt. That can take a really long time.

But if you just use personal recovery keys, you can have the user try to log in three times, and she'll be prompted to enter the recovery key to reset the forgotten password, and then be prompted to enter a new password. (You can also just hit the question mark next to the password field, which will take you there directly instead of having to fail a few times.)

Wesley Whetstone has created a neat little pkg that can generate/regenerate personal recovery keys: fde-rekey. Wesley Whetstone has since abandoned fde-rekey in favor of Crypt.

Once you've switched that over, you can also remove the institutional recovery key (yes, it's possible to have both an IRK and a PRK). If you're using Munki, I wrote a nopkg that will remove the IRK after fde-rekey is installed.

P.S. Another good reason not to use institutional recovery keys: Unlocking or decrypting using an institutional recovery key does not work with encrypted APFS boot drives on macOS High Sierra 10.13.0. It may work in 10.13.1, but that hasn't been verified yet (as of this writing).

Using a FileVault institutional recovery key to unlock an encrypted disk

You may have set up FileVault encryption using an institutional recovery key (more details in Enabling FileVault Encryption for Client Macs).

It's possible you have a local admin account on the FileVault-enabled machine, so if a user says "Oh, no! I forgot my password," you can reset the password. But what if your user also has admin privileges and deletes your local admin account, so there is no user account (with a known password) that can unlock the encrypted volume?

Well, that's where your institutional recovery key comes in handy.

  • Put your original FileVaultMaster.keychain (the one without the private key deleted) on an external drive or thumb drive
  • Boot the client machine into recovery mode (Cmd-R at bootup).
  • Plug in the drive with the FileVaultMaster.keychain file on it. It should automount in recovery mode, but you can also mount it using Disk Utility.
  • Go to Utilities and select Terminal.
  • Unlock the keychain:
    security unlock-keychain /Volumes/NAMEOFDRIVE/FileVaultMaster.keychain
    This will prompt you for a password you set when you originally created the institutional recovery key.
  • Then, run
    diskutil cs list
    which will list out the CoreStorage logical volume groups. Find the UUID of the Logical Volume (most likely the LV Name will be Macintosh HD if you went with defaults, and the Content Hint will be Apple_HFS). As the UUID will likely be at least 32 characters long, you probably want to highlight and copy it (to paste later).
  • To unlock the volume (to get at the files), run this command
    diskutil cs unlockVolume YOUR-LONG-UUID-COPIED-FROM-EARLIER -recoveryKeychain /Volumes/NAMEOFDRIVE/FileVaultMaster.keychain
    You should then see output like this
    Started CoreStorage operation
    Logical Volume successfully unlocked
    Logical Volume successfully attached as disk18 Logical Volume successfully mounted as /Volumes/Macintosh HD
    Core Storage disk: disk18
    Finished CoreStorage opeartion
  • You can then fetch anything you won't from the unlocked and mounted disk.

Acknowledgements: I created this tutorial with the help of Apple's official documentation on it and Rich Trouton's Unlock or decrypt your FileVault 2-encrypted boot drive from the command line.

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.

fdesetup

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