Rotating the FileVault 2 Master Password

If you want to use FileVault 2 with FileVaultMaster.keychain as a managed recovery key, the issue of regularly changing your institution’s Master Password may come up if your worksite mandates password rotation. Since the Master Password’s sole function is to act as the password used to unlock the FileVaultMaster.keychain, this should be relatively straightforward. As long as the public key on your Macs and the private and public keys in your escrowed FileVaultMaster.keychain stay the same, the password to unlock FileVaultMaster.keychain can be updated as often as needed.

There’s two strategies you can use here:

1. You can change the password on a copy of your institution’s FileVaultMaster.keychain and push the updated FileVaultMaster.keychain to /Library/Keychains on your Macs – In my opinion, this is probably the most secure way to do this because you’re replacing one encrypted file with another encrypted file, without revealing in transit what the new password is. The main danger would be an incomplete or corrupted copy of the keychain file somehow being pushed to the machines.

2. You can use the security command to update the existing FileVaultMaster.keychain on the machines – In this case, you’re using the security command’s keychain password functionality to update the password used to unlock /Library/Keychains/FileVaultMaster.keychain from a known old password to a known new password. You would need to use sudo, or run it as root, as the FileVault keychain should be owned and writable only by root. Here’s the command to use (command should be all on one line):

The main security concern here would be that the passwords referenced in the command would be sent in the clear, and all sudo-using commands will show up in /var/log/system.log. Running the commands as the root user without using sudo would mean that the command should not show up in /var/log/system.log, but it may show up in the root user’s history.

Like this:

Related

After the 1st Master Password is set and deployed to clients, is it OK to use another Mac to update the password, prep the FileVaultMaster.keychain for deployment and then deploy to clients? Is there any reason I have to use the exact same Mac each time I want to rotate the password?

If I am following the first strategy, do I change the password on the FileVaultMaster.keychain that is deployed to end users or do I work on original escrowed FVM.keychain? Then build up a library of escrowed FVM.keychains for each new password?

You’re changing the password on the keychain deployed to your end-user’s machines. If you choose, you can also change the password of your escrowed FileVault recovery keychain to match but that’s up to you. The important thing is keeping track of what the recovery keychain’s password is set to for when you need to do a recovery.

The main thing to keep in mind is that the recovery keychain’s password only unlocks the keychain. Once unlocked, it’s the keychain’s contents that actually allow the recovery process to work.

I don’t understand the point of rotating the shared key. While anyone with the password can unlock the shared key keychain, it can’t be used to decrypt an encrypted drive. Only the escrowed key with the Private Key still in it can unlock a drive (regardless of the password on either keychain).

Is there a way to replace FileVaultMaster.keychain, not change it’s password? Lets take the scenario that the privately securted FileVaultMaster.keychain was compromised in someway. Is there any method to rollout a new physical FileVaultMaster.keychain (with pub key) on client computers, as well as a new FIleVaultMaster.keychain (with pub and priv key) on a secured server?

Yes, but you will need to decrypt / re-encrypt the FV 2-encrypted Mac(s) using the new FileVaultMaster.keychain. Otherwise, the new FileVaultMaster.keychain would not be recognized as a valid recovery keychain.

Christopher

August 8, 2012 at 6:45 pm

Thanks! That confirms what I’ve been testing… Now this makes me question whether using FileVaultMaster.keychain is a safe and viable solution in an enterprise environment. In this case, all Mac’s would have to be unencrypted/reencrypted in the event the privately held FileVaultMaster.keychain was compromised. Maybe this is why Google has opted to use the other method and escrow the pin with their app engine. Thanks for your help!

Christopher

August 8, 2012 at 8:43 pm

…to add to my previous comment.. I have not tested, but it appears if you encrypted by utilizing the unique pin (passphrase) method and if you needed to change it, you can simply run the ‘diskutil cs changeVolumePassphrase’ command. It seems you wouldn’t need to go through a decrypt/encrypt process. …And obviously your escrowed passphrase for a particular client would need to be updated. If you saved it with Apple, well.. that couldn’t be updated, I think.

‘diskutil cs changeVolumePassphrase’ changes the password used to unlock a CoreStorage encrypted volume. This would apply to a non-boot volume which is encrypted.

The command does not force FileVault 2 to generate and use a new alphanumeric recovery key. You would need to decrypt / re-encrypt in order to have the FileVault 2 encryption process generate and use a new alphanumeric recovery key.