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:
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.
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: