If you notice you can't install new macOS updates on a Mac, it could be that it's still in the process of FileVault encrypting.
If you want to validate your FileVault recovery key from the terminal, you can do
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
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
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:
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 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:
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:
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
ProxyPass / http://0.0.0.0:8000/
ProxyPassReverse / http://0.0.0.0:8000/
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.
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.
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).
This isn't a comprehensive list:
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.)
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).
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.keychainThis will prompt you for a password you set when you originally created the institutional recovery key.
- Then, run diskutil cs listwhich 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.keychainYou should then see output like thisStarted 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.
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:
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
Defer = 1;
NoRecoveryKey = 1;
OutputPath = "/PATH/TO/recovery.plist";
UseKeychain = 1;
Usernames = (
To check FileVault general status (not deferral status) run the command
FileVault master keychain appears to be installed.
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
Difficulties in automating FileVault
FileVault encryption is unfortunately one of the things for Mac admins that is extremely difficult to automate.
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.
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:
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:
Copy it somewhere:
Unlock the keychain:
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