Deploying the FileVault Institutional Key????

[ooshnoo]

Hey folks.. quick question. We're investigating the use of FV2 and have seen numerous blogs, instructions, etc... that mention copying the FileVaultMaster Institutional key to all clients in the /Library/Keychains directory.

Is this step necessary and what is the reason, as I can easily login via the Recovery partition and decrypt a drive if necesary?

[emily]

Check out @rtrouton's video on the entire FileVault 2 workflow. It'll help put all the components into perspective:
https://derflounder.wordpress.com/2013/11/13/understand-filevault-2-and-manage-disk-encryption-with-...

[rtrouton]

I have a post on institutional recovery keys and how they've used available from here:

http://derflounder.wordpress.com/2014/08/13/filevault-2-institutional-recovery-keys-creation-deploym...

Hopefully it can help answer your questions.

[jhalvorson]

I second the suggestion to read/view all of @rtrouton][/url][/url's work.

You'll want the recovery key in place as a backup to any accounts that you maintain.
The following things can go wrong:
- One of the FV2 user deletes all other accounts on the computer, including your IT account and you don't know or have access to their password.
- One of the FV2 users deletes all other accounts, but can't remember their own password, so they can't help with unlocking or decrypting.
- Your IT account password some how gets set to unknown or stops working as expected.
- The OS goes bad and won't boot. - You can boot from another resource and might be able to use the key.
- The Recovery partition goes bad and can't get past the unlocking of FV2 - You can boot from another resource and might be able to use the key.

That's when you turn to using the Institutional key*.

*Also be aware that the key can be changed.

[ooshnoo]

Thanks folks.

I spent most of yesterday afternoon reading through all of Rich's stuff, and unfortunately I'm still torn. Would a good consensus be storing the key somewhere hidden on the Mac and not in Keychains, or maybe bake it into one of our netboot images?

[rtrouton]

@ooshnoo,

Did you get a chance to read through the post that I linked in the thread? If the FileVaultMaster.keychain file is not stored in /Library/Keychains, FileVault 2 will not detect it and will not be able to use it as an institutional recovery key when encrypting.

There shouldn't be a special need to protect the FileVaultMaster.keychain file in /Library/Keychains. If you want to use an institutional recovery key, your FileVaultMaster.keychain file needs to have just the public key in it.

If both public and private keys are stored in the /Library/Keychains/FileVaultMaster.keychain file on a Mac, FileVault 2 will ignore the keychain and not use it as an institutional recovery key.

[rtrouton]

You should also not be putting the private key of your institutional recovery key on your Macs. The private key should be locked away somewhere secure.

The reason for this is that institutional recovery keys have a weakness from the cryptographic point of view, which is that the concept inherently uses one private and public key pair to unlock the encryption of more than one encrypted volume. A malicious party who compromises the private key of an institutional recovery key means that all Macs encrypted using that institutional recovery key are vulnerable. In order to maintain their encryption protection, those Macs must have their institutional key changed to a new one.

That said, Apple has taken the following steps in FileVault 2 as of OS X 10.9.x and later to mitigate the possible vulnerability of a compromised private key:

1. Making it a technical requirement that the FileVaultMaster.keychain file only contain the public key when deployed to Macs that will be using the institutional recovery key for FileVault 2 encryption.

The public key is not sensitive information and was designed as such. You can post the contents of a public key to a public billboard without compromising the security of the encrypted volume.

1. Providing a way to replace a compromised recovery key.

Before OS X 10.9.x, you would need to decrypt an encrypted Mac before being able to change an existing institutional recovery key. In 10.9.x and later, Apple's fdesetup tool can be leveraged to assist in this situation in the following ways:

Changing the compromised institutional key to a new one with fdesetup‘s changerecovery function.
End the use of an institutional key with fdesetup‘s removerecovery function.

[ryoshioka]

I had a quick question about FileVault, if I have users that have pre-existing personal recovery keys and want to add an institutional recovery key, do I have to decrypt the drive and encrypt with the institutional key or is there a way to add the institutional key?

[rtrouton]

@ryoshioka,

No, you do not need to decrypt. That said, I don't believe the capability you're looking for is one of Casper's built-in functions so you would need to script a way to do this with Apple's fdesetup tool.

I have a post describing how you can use Apple's fdesetup tool to add or change institutional recovery keys, available via the link below:

https://derflounder.wordpress.com/2014/08/13/filevault-2-institutional-recovery-keys-creation-deploy... (see the Managing institutional recovery keys with fdesetup section.)

[psliequ]

@rtrouton As always, thank you for the write ups on Filevault. I've made a habit of removing the private key myself, but JAMF's own documentation on this seems to indicate that you can upload the public/private key pair to the JSS and store it all there. The question is if deploying the public/private key pair with a Casper policy strips the private key at policy execution time (would hope so.) I'll have an opportunity to test this today to confirm.

[rtrouton]

Casper will only deploy the public key to machines that it is encrypting with an institutional recovery key (IRK). If you want to use an IRK, the FileVaultMaster.keychain file deployed to the machine as part of a Casper encryption policy must have only the public key in it.

The reason for this is if both public and private keys are stored in the /Library/Keychains/FileVaultMaster.keychain file on a Mac, FileVault 2 will ignore the keychain when encryption is enabled and not use it as an IRK. In this case, enabling FileVault 2 encryption will automatically generate a personal recovery key.

[inflicted]

Just a followup here. I followed the instructions listed out by rtrouton on filevault but ran into an issue with my apfs hard drive..
Laptop os - Mojave

The steps i took-
1-Created new filevault master keychain (multiple copies of it)
2-Edited one of the copies of the filevault master keychain to only contain the public key, and then uploaded that into JAMF as a .pem file.
3-Created a policy on JAMF to use the disk encryption configuration that contained that public key i just uploaded.
4-Rebooted laptop and finished encrypting.
5-Took the filevault master keychain and placed it in my thumb drive. This keychain contained both public and private key.
6. Boot laptop into recovery mode
7. Open up terminal and ran security unlock-keychain /path/to/FileVaultMaster.keychain to unlock the Filevault master keychain that contained both private and public key 8. Ran diskutil apfs unlockVolume UUID -recoveryKeychain /path/to/FileVaultMaster.keychain and then got this error "Error unlocking APFS Volume: The external-to-APFS security system's credential-unwrap operation failed (-69534)"

Any idea?

[amosdeane]

@huyism my knowledge of this is still relatively limited but in the first instance I would try using a thumb drive with only the private key present. I believe that if both keys are present on the Mac the key would be ignored overall, so if both are present on the thumb drive I would imagine that this could also cause an issue.

@rtrouton many thanks for your posts and discussions of this topic which have been very helpful in getting a handle on it. I have one more question which was hinted at, but I haven't found fully clarified related to ryoshioka’s question.

That is, is it ok to deploy an institutional key to a machine that was manually encrypted and already has a valid filevault recovery key in the jss, or will this invalidate the recovery key (or simply not work) if added at this stage? I’ve noticed that if the institutional key is already present on the device when you encrypt the device manually you don’t get the option for a recovery key, so I am wondering if in this scenario there is some incompatibility?

With that said, I am also aware that when we deploy encryption through the jss we deploy a configuration that simultaneously creates individual and institutional keys to machines, so I am assuming that they can coexist. I am just not sure if it is ok to use one method and then add the other option, after the fact? Any thoughts would be helpful.