For the first time since fdesetup‘s initial release in OS X Mountain Lion 10.8.x, Apple has not added new features to fdesetup as part of a new OS release. Instead, fdesetup maintains the same set of features in OS X El Capitan 10.11.x as it had in OS X Yosemite 10.10.x.

This decision may mean that fdesetup, an essential command-line tool for enabling, administering and disabling Apple’s FileVault 2 encryption, is now considered by Apple to be a fully-developed toolset for managing FileVault 2.

fdesetup gives Mac administrators the following command-line abilities:

• Enable or disable FileVault 2 encryption on a particular Mac
• Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
• Enable one or multiple user accounts at the time of encryption
• Get a list of FileVault 2-enabled users on a particular machine
• Add additional users after FileVault has been enabled
• Remove users from the list of FileVault enabled accounts
• Add, change or remove individual and institutional recovery keys
• Report which recovery keys are in use
• Perform a one-time reboot that bypasses the FileVault pre-boot login
• Report on the status of FileVault 2 encryption or decryption

I’ll be taking you through all of the capabilities mentioned above, with a focus on showing exactly how they work. See below the jump for details.

Enabling Filevault 2 Encryption For One Or Multiple Users

fdesetup is amazingly flexible when it comes to enabling FileVault 2 encryption from the command-line. To start with the simplest method, run the following command with root privileges to enable FileVault 2 encryption:

fdesetup enable

You’ll be prompted for the username and password of the primary user, which is the account you will work with at the FileVault 2 pre-boot login screen once the encryption is turned on.

If everything’s working properly, you’ll next be given an alphanumeric personal recovery key and prompted to restart.

VERY IMPORTANT: The fdesetup-generated personal recovery key is not saved anywhere outside the machine. Make a record of it or you will not have a recovery key available to help unlock your Mac’s encryption in case of a problem.

You can also enable additional user accounts at the time of encryption, as long as the accounts are either local or mobile accounts on the Mac being encrypted. Run the following command with root privileges to enable FileVault 2 and specify the accounts you want:

fdesetup enable -user username -usertoadd other_username -usertoadd yet_another_username

You’ll be prompted for the passwords of the accounts specified. After that, you’ll be given an alphanumeric personal recovery key and prompted to restart. All of the accounts specified should appear at the FileVault 2 pre-boot login screen.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

Additional users can be included as needed by adding additional user information under the AdditionalUsers plist key.

Note: All account passwords need to be supplied in cleartext.

Once the plist has been set up and properly formatted, run the following command with root privileges to enable FileVault 2 encryption and reference the account information in the plist file:

fdesetup enable -inputplist < /path/to/filename.plist

Since the accounts and passwords are in the plist file, fdesetup does not need to prompt for passwords. Instead, the alphanumeric personal recovery key is displayed and the user is prompted to restart. All of the accounts specified in the plist file should appear at the FileVault 2 pre-boot login screen.

To avoid the need to enter a password, fdesetup also has a -defer flag in El Capitan that can be used with the “enable” command option to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.

The property list file will be created as a root-only readable file and contain information similar to what’s show below.

Note: For security reasons, the plist file with the recovery key information should not stay on the encrypted system. Please copy it to a safe location and then securely delete this plist file from the encrypted system.

Run the following command with root privileges to defer enabling FileVault 2 and specify the account you want:

fdesetup enable -user username -defer /path/to/filename.plist

If there is no user account specified with the -user option, then the current logged-in user will be enabled for FileVault 2. If there is no user specified and no users are logged in when the command is run, then the next user that logs in will be chosen and enabled.

If you don’t want to specify the account, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist

On logout, the user will be prompted to enter their account password.

Once entered, FileVault 2 will be enabled and the recovery information plist file will be created. Once the enabling process is complete, the Mac will restart.

In addition to enabling FileVault 2 as part of the logout process, Apple added the ability to set a deferred enablement at login to OS X Yosemite. In OS X El Capitan, this means that Mac admins can set a deferred enablement with the following options:

1. Enforce FileVault 2 enablement at logout
2. Enforce FileVault 2 enablement at login
3. Enforce FileVault 2 enablement at both login and logout

To set a deferred enablement at login, the following options may be added to fdesetup‘s -defer flag:

• -forceatlogin max_cancel_attempts
• -dontaskatlogout

These additional options allow a deferred FileVault 2 enablement to be enforced at the login window, rather than waiting for a logout or restart of the Mac in question.

The -forceatlogin option must be set with an accompanying numerical value. This numerical value governs how many times the account being enabled can choose to defer having the FileVault 2 encryption process begin. For example, running the following command with root privileges will set a maximum number of ten deferral opportunities:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 10

If the user chooses to defer, they will need to select the Don’t Enable button in the dialog window when it will appear. They will also be informed of how many more times they can log in before FileVault 2 encryption must be enabled.

If immediate enforcement is desired, setting a value of zero will enforce FileVault 2 encryption at the next login. To do this, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0

The fdesetup commands shown above will enforce FileVault 2 enablement at both login and logout. If only enforcement at login is desired, the -dontaskatlogout option can be used. This will prevent a deferred FileVault 2 enablement to be enforced at logout. For example, running the following command with root privileges will enforce FileVault 2 encryption at the next login but not prompt the user on logout:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0 –dontaskatlogout

An important thing to keep in mind about the –defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The –defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.

Enabling Filevault 2 Encryption Using One Or Multiple Recovery Keys

Another capability of FileVault 2 in El Capitan is the ability to use the alphanumeric personal recovery key, an institutional recovery key using /Library/Keychains/FileVaultMaster.keychain, or both kinds of recovery key at the same time.

As seen in the earlier examples, fdesetup will provide the alphanumeric personal recovery key by default. To use the institutional recovery key, the -keychain flag needs to be used when enabling encryption:

fdesetup enable –keychain

The alphanumeric personal recovery key is displayed, but the encryption will also use the /Library/Keychains/FileVaultMaster.keychain institutional recovery key. In case recovery is needed, either recovery key will work to unlock or decrypt the encrypted drive.

If you want to specify that only the FileVaultMaster.keychain institutional recovery key be used, both the -keychain and -norecoverykey flags need to be used when enabling encryption:

fdesetup enable -keychain –norecoverykey

fdesetup is also capable of creating an institutional recovery key, using the -certificate flag to import an existing FileVault 2 public key. Once imported, fdesetup will automatically create a FileVaultMaster.keychain file to store the public key and save the keychain to /Library/Keychains.

The public key will need to be available as a DER encoded .cer certificate file. Once the certificate is available, the following command can be run with root privileges to enable FileVault 2, automatically create the institutional recovery key with the supplied public key and store it as /Library/Keychains/FileVaultMaster.keychain:

fdesetup enable -certificate /path/to/filename.cer

To specify that only the FileVaultMaster.keychain institutional recovery key be used, add the -norecoverykey flag to the command:

fdesetup enable -certificate /path/to/filename.cer -norecoverykey

It is also possible to include the public key data in a plist file, which allows the use of a plist to set up the institutional recovery key. The plist needs to follow the format below:

Using the public key’s DER encoded certificate file, the public key data for the plist can be obtained using the base64 tool by using the following command:

base64 /path/to/filename.cer > /path/to/filename.txt

At this point, you would copy the data string contained in the text file and place it into the Certificate value area of the plist file. You would store either the password of an existing FileVault 2-enabled user or (if available) an existing personal recovery key in the Password key in the plist.

Forcing A Restart When Enabling Filevault 2 Encryption

Along with the various options for enabling, it’s also possible to force a restart of the Mac once FileVault 2 has been successfully configured. This can help automate the process of enabling FileVault 2 on a Mac if no input from a logged-in user is needed.

For example, an institution may want to pre-configure its Macs to automatically encrypt with FileVault 2 at first boot with a local admin account enabled. It also wants to use only the institutional recovery key. If a plist with the desired account information and public key data to create the institutional recovery key is available, the following command could be run with root privileges to enable FileVault 2 and force a restart at the first boot:

fdesetup enable -inputplist < /path/to/filename.plist -norecoverykey -forcerestart

Once fdesetup had finished enabling the accounts in the plist file and creating /Library/Keychains/FileVaultMaster.keychain, the Mac would immediately restart and display the enabled accounts at the pre-boot login screen.

If you want to use the alphanumeric personal recovery key with -forcerestart, you will also need to output the personal recovery key and other information into a plist file. Taking the example above, the institution’s automated setup would run the following command with root privileges to automatically encrypt with FileVault 2 at first boot using both types of recovery key and a local admin account enabled:

fdesetup enable -inputplist < /path/to/filename.plist -outputplist > /path/to/recoverykeyinfo.plist –forcerestart

Disabling Filevault 2 Encryption

In contrast to all of the various options available for enabling FileVault 2 using fdesetup, the command to turn off FileVault 2 encryption is the following:

fdesetup disable

Adding Additional Users After Filevault 2 Has Been Enabled

Once FileVault 2 has been enabled, you can add additional users using fdesetup. To do so, you will need to a) wait until the FileVault 2 encryption has completed and b) provide both the username and password of a previously enabled account as well as the password of the account you want to add. The following command run with root privileges will enable a user account named otheruser:

fdesetup add -usertoadd otheruser

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

When adding additional users using a plist file, the top level Username key is ignored, and the Password key value should either be an existing FileVault user’s password or the existing personal recovery key. Additional users can be added as needed by adding additional user information under the AdditionalUsers plist key.

Note: All account passwords need to be supplied in cleartext.

Once the plist has been set up and properly formatted, run the following command with root privileges to add additional users by referencing the account information in the plist file:

fdesetup add -inputplist < /path/to/filename.plist

Listing Current Filevault 2 Users

To list all accounts enabled for FileVault 2, run the following command with root privileges:

fdesetup list

All accounts will be listed with both the accounts’ username and UUID

Removing Users From The List Of Filevault 2 Enabled Accounts

You can remove users from the list of FileVault enabled accounts by using either their username or the account’s UUID. To remove the account using the username, run the following command with root privileges:

fdesetup remove -user username_goes_here

To remove the account using the account’s UUID, run the following command with root privileges:

fdesetup remove -uuid UUID_here

In both cases, successful removal of the account will not produce any additional output. If the account being removed is not currently enabled for use with FileVault 2, an error message will be displayed.

Managing Individual And Institutional Recovery Keys

fdesetup in El Capitan includes the ability to change, add and remove both personal and institutional recovery keys. This gives Mac admins much greater ability to manage recovery keys, including the capability to quickly update or remove compromised personal and/or institutional recovery keys in the event of a data breach or other problem.

You can add or change recovery keys using fdesetup changerecovery. To change to a new personal key, run the following command with root privileges:

fdesetup changerecovery -personal

You’ll be prompted for the password of an existing FileVault 2-enabled user or the existing personal recovery key. Once entered, a new personal recovery key will be generated and displayed. The former personal recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, run the following command with root privileges to change to a new personal recovery key and reference the password or recovery key in the plist file:

fdesetup changerecovery -personal -inputplist < /path/to/filename.plist

In the event that the Mac in question does not have a personal recovery key, running the commands above will add a personal recovery key instead of changing an existing one.

To change to a new institutional recovery key, you will need to have the new public key available. If you have a new institutional public key available as a DER encoded certificate file, you can run the following command with root privileges to replace the current institutional key:

fdesetup changerecovery -institutional -keychain -certificate /path/to/filename.cer

If an institutional keychain is being used on this Mac, you will see a message that an existing FileVault Master keychain was found and moved. The reason for this is that, as part of this process, the current institutional key’s /Library/Keychains/FileVaultMaster.keychain file is replaced with a new /Library/Keychains/FileVaultMaster.keychain file that includes the new institutional recovery key’s public key.

While the former institutional key’s /Library/Keychains/FileVaultMaster.keychain was moved and not deleted, the former institutional recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

You can also use the current institutional recovery key to authenticate the change to the new institutional key. If you have a keychain file available containing the private key of the current institutional key, you can run the following command with root privileges to replace the current institutional key:

fdesetup changerecovery -institutional -keychain -certificate /path/to/filename.cer -key /path/to/filename.keychain

You’ll be prompted for the keychain’s password. Once entered, the current institutional key will be replaced with the new one.

In the event that the Mac in question does not have an institutional recovery key, running the commands above (with the exception of using the current institutional key for authentication) will add a institutional recovery key instead of changing an existing one.

Removing Individual And Institutional Recovery Keys

You can remove recovery keys using fdesetup removerecovery. To remove the current personal recovery key, run the following command with root privileges:

fdesetup removerecovery -personal

You’ll be prompted for the password of an existing FileVault 2-enabled user or the existing personal recovery key. Once entered, the personal recovery key will be removed from the system. The former personal recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, run the following command with root privileges to remove the current personal recovery key and reference the password or recovery key in the plist file:

fdesetup removerecovery -personal -inputplist < /path/to/filename.plist

To remove institutional recovery keys, run the following command with root privileges:

fdesetup removerecovery -institutional

You’ll be prompted for the password of an existing FileVault 2-enabled user, or a personal recovery key if one is available. Once entered, the institutional recovery key will be removed from the system and will no longer work.

The removal of the institutional key can also be automated using a properly formatted plist via a standard input stream (stdin). The plist is the same as the one used for removing the personal key.

Once the plist has been set up and properly formatted, run the following command with root privileges to remove the institutional recovery key and reference the password or recovery key in the plist file:

fdesetup removerecovery -institutional -inputplist < /path/to/filename.plist

You can also use the recovery key associated with an institutional key to authenticate the removal of that institutional key. Once authenticated, the institutional key is removed from the system and will no longer work.

If you have a keychain file containing the private key for the current institutional key available, you can run the following command with root privileges to remove the current institutional key:

fdesetup removerecovery -institutional -key /path/to/filename.keychain

It is possible to use fdesetup removerecovery to remove one or both recovery keys on a particular Mac. Once the recovery keys are removed, the only way to unlock the FileVault 2 encryption is by using the password of an enabled account. That said, you could use fdesetup changerecovery to add one or both types of recovery keys back to the encrypted Mac.

Recovery Key Reporting

To go along with the ability to manage recovery keys, fdesetup in El Capitan enables Mac admins to detect which types of recovery keys are in use on a particular Mac. To check if a personal recovery key is in use, run the following command with root privileges:

fdesetup haspersonalrecoverykey

If FileVault 2 is using a personal recovery key, this command will return true. Otherwise it will return false.

To check if an institutional recovery key is in use, run the following command with root privileges:

fdesetup hasinstitutionalrecoverykey

If FileVault 2 is using an institutional recovery key, this command will return true. Otherwise it will return false.

One-Time Filevault 2 Encryption Bypass

fdesetup in El Capitan has the authrestart verb, which allows a FileVault 2-encrypted Mac to restart, bypass the FileVault 2 pre-boot login screen, and goes straight to the OS login window. To restart and bypass the FileVault 2 pre-boot login screen, run the following command with root privileges:

fdesetup authrestart

When the fdesetup authrestart command is run, it asks for the password of an existing FileVault 2-enabled user or a personal recovery key.

Once authenticated, the authrestart process puts an unlock key in system memory and reboots. On reboot, the reboot process automatically clears the unlock key from memory.

It’s also possible to automate this process by importing the authentication via a properly formatted plist. The plist needs to follow the format below:

Either the password of an existing FileVault 2-enabled user or a personal recovery key would be stored in the Password key in the plist.

Once the plist has been set up and properly formatted, use the following command with root privileges to run the authrestart process and reference the password or recovery key in the plist file for authentication:

fdesetup authrestart -inputplist < /path/to/filename.plist

fdesetup authrestart may not be supported by all El Capitan-compatible Macs. To verify if a specific Mac supports authrestart, run the following command with root privileges:

fdesetup supportsauthrestart

If the Mac supports fdesetup authrestart, this command will return true. Otherwise it will return false.

The authrestart function can also be leveraged part of enabling FileVault 2 encryption. To re-use a previous example, an institution may want to pre-configure its Macs to automatically encrypt with FileVault 2 at first boot with a local admin account enabled and using only an institutional recovery key. It also wants the Macs to bypass the login screen and boot normally, so that the encryption process can continue unattended.

If a plist with the desired account information and public key data to create the institutional recovery key is available, the following command could be run with root privileges to enable FileVault 2, automatically reboot the Mac, bypass the FileVault 2 pre-boot login screen and boot normally to the OS login window.

fdesetup enable -authrestart -inputplist < /path/to/filename.plist -norecoverykey

Once fdesetup had finished enabling the accounts in the plist file and creating /Library/Keychains/FileVaultMaster.keychain, the Mac would immediately restart, bypass the pre-boot login screen and boot the OS. The encryption of the boot volume would proceed normally after the reboot.

If using the alphanumeric personal recovery key with -authrestart, the personal recovery key and other information will need to be exported to a plist file. Taking the example above, the institution’s automated setup would run the following command with root privileges to automatically encrypt with FileVault 2 at first boot using both types of recovery key and a local admin account enabled:

fdesetup enable -authrestart -inputplist < /path/to/recoverykeyinfo.plist -outputplist > /path/to/recoverykeyinfo.plist

Reporting On Filevault 2 Encryption Or Decryption Status

fdesetup can report on FileVault 2 encryption or decryption status. Running the following command with root privileges will display the current state:

fdesetup status

Conclusion

fdesetup in El Capitan is a solid tool for FileVault 2 management, with the abilities to enable FileVault 2, add and remove users from the list of FileVault 2 authorized accounts, manage recovery keys, report on FileVault 2’s status and more. Among its greatest strengths are:

• It allows options for automating FileVault 2 setups via scripting.
• fdesetup’s deferred enablement option can be used to set up a self-service procedure for enabling encryption either at login or logout.
• It supports multiple recovery keys for FileVault 2, giving Mac admins more options for handling recovery situations.
• It allows you to rotate or remove recovery keys on an as-needed basis.
• It provides a one-time method for bypassing encryption on restart, to accommodate situations where an encrypted Mac needs to be restarted from a remote location.

Managing FileVault 2 encryption using this tool will save you time and give encryption options available with no other software.

One question I’ve seen which has caused confusion for folks who deal with security regulations is this: Is FileVault 2 FIPS 140-2 compliant?

The answer is: Yes, depending on the version of OS X

The cryptography used by FileVault 2 on the following versions of OS X has gone through the FIPS validation process and has been validated as being FIPS 140-2 Compliant:

• OS X 10.8.x
• OS X 10.9.x
• OS X 10.10.x

The CoreCrypto cryptographic modules used by OS X 10.11 are currently in the process of becoming FIPS 140-2 validated. The reason FileVault 2 in El Capitan is not automatically FIPS 140-2 compliant has to do with OS X’s CoreCrypto cryptography foundation and how the FIPS 140-2 validation process works.

FIPS validation

The FIPS validation process tests a specific cryptographic module used inside a system to protect information. It also applies only to a cryptographic module used in a shipping product; the cryptographic module in question can’t be a prototype or in beta. 

Another important thing to know is that the testing is very specific and applies only to the cryptographic module submitted for review. If the vendor changes anything in the cryptographic module, it loses its FIPS validation and has to be resubmitted for laboratory testing and government review.

There are three major phases in the process:

Phase 1: Design and Documentation

In order to prepare for the FIPS validation process, the cryptographic module in question has to be designed to pass the various tests involved and also be properly documented. This is the part of the process which the vendor has the most control over.

Phase 2: Laboratory Testing

Once the cryptographic module has been designed, documented and shipped, it is submitted to a third-party accredited Cryptographic and Security Testing (CST) laboratory to test the module(s) in question against FIPS 140-2’s qualitative levels of security. This testing can take an indeterminate amount of time, depending on how well the cryptographic module is designed and documented.

Best case: A cryptographic module that properly meets the requirements and with all required documentation written correctly can complete its laboratory testing in two to three months.

Phase 3: Government Review

After the lab has tested the cryptographic module, a report on the testing is submitted to the Cryptographic Module Validation Program (CMVP) for review. CMVP is a joint US-Canadian program that reviews all the test reports, with the CMVP Validation Authorities being the National Institute of Standards and Technology (NIST) for the US Government and the Communications Security Establishment (CSE) for the Government of Canada. This review can also take an indeterminate amount of time, depending on how many test reports need review, and can range from two months to eight months.

Apple and CoreCrypto

Apple’s CoreCrypto library is used by various components in OS X to provide low level cryptographic primitive support. This is the cryptographic library which is submitted by Apple to the FIPS 140-2 validation process.

With every version of iOS and OS X, Apple has made changes to CoreCrypto. As part of making those changes, Apple has had to resubmit CoreCrypto to laboratory testing and government review as part of the FIPS 140-2 validation process.

Apple’s stated intention is to continue FIPS 140-2 validation for OS X’s CoreCrypto cryptography foundation, which would also cover FileVault 2 on future versions of OS X, but the validation process itself can only be begun once that future OS has been released. Meanwhile, as noted above, the testing and governmental review process will take months to complete.

The good news is that it’s possible to at least see where Apple is in the process. NIST has a website where the current list of modules in the process can be viewed via a PDF which is updated weekly. To check for Apple’s progress, search the PDF for entries where Apple Inc. is listed as the vendor.

For more information on this subject, Apple has KBase articles available via the links below:

Product security, validations, and guidance for iOS

Product security, validations, and guidance for OS X

Apple’s existing FIPS validations are also available for reference via the link below:

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401vend.htm

For those who wanted a copy of my FileVault 2 talk at MacAD UK 2016, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MacADUK2016pdf

Keynote – http://tinyurl.com/MacADUK2016key

On OS X 10.9.0 – 10.11.x, you can run the following command to verify if a FileVault 2-encrypted Mac is using an institutional recovery key (IRK) as a valid recovery key.

fdesetup hasinstitutionalrecoverykey

If FileVault 2 is using an IRK, this command will return true.

Otherwise it will return false.

As part of the release of OS X 10.11.2, a new function was added to fdesetup‘s hasinstitutionalrecoverykey verb. Now, in addition to identifying whether or not FileVault 2 on a particular Mac has an institutional recovery key, a new -device option has been added which outputs a SHA-1 hash in hexadecimal notation of the IRK’s public key. This helps Mac admins answer two questions about institutional recovery keys:

1. Is an IRK being used as a valid recovery key on this Mac?
2. If an IRK is in use, which one is being used?

The -device option needs to be supplied with an identifier for the encrypted drive in question. This can be in the form of a BSD device name ( /dev/diskX ), the mount path ( /Volumes/Macintosh HD or / ), or a UUID for the Logical Volume or Logical Volume Family of a CoreStorage volume.

To display the hash for an IRK’s public key on the Mac’s boot volume, run the command below with root privileges:

fdesetup hasinstitutionalrecoverykey -device /

It should output the hash of the IRK’s public key in hexadecimal notation.

This value should be consistent across all FileVault 2-encrypted Macs which are using this IRK, so it should help Mac admins identify if a particular Mac is set up with the correct FileVault 2 institutional recovery key (or keys) used by their shop.

To assist with this, I’ve written a script to report the hash of the IRK’s public key. For more details, see below the jump.

The script is designed to check the OS on a particular Mac and verify that it’s running 10.11.2 or later. If the Mac is running an earlier OS, the script reports the following:

Not Available – Unable To Export IRK Public Key Hash On, followed by the OS version.

If the script verifies that it is running on 10.11.2 or later, the script continues on to see if the Mac is encrypted and if it is using an IRK as a valid recovery key.

If the Mac is not encrypted, the script reports the following:

Not Available – Encryption Not Enabled

If the Mac is encrypted but is not using an IRK, the script reports the following:

Not Available – Valid IRK Not Found

If the Mac is encrypted and an IRK is in use as a valid recovery key on the Mac’s boot volume, the script reports the hash of the IRK’s public key in hexadecimal notation.

The script is available on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/report_IRK_public_key_hash

A Casper Extension Attribute is also available on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/report_IRK_public_key_hash

Apple officially announced on Wednesday, April 6th that the FIPS 140-2 validations for the cryptographic modules used by iOS 9 and OS X 10.11.x have now been completed. This is significant news for folks who want to use FileVault 2 in government and regulated industries (such as financial and health-care institutions.)

For folks who haven’t heard of it before, FIPS 140-2 is an information technology security accreditation program run jointly by the US and Canadian governments. This program is used by private sector vendors to have their cryptographic modules certified for use in US and Canadian government departments and private industries with regulatory requirements for security.

As part of the announcement, Apple has released KBase articles and guidance for security offices who deal with encryption:

Apple FIPS Cryptographic Modules v6.0 for OS X El Capitan v10.11 – https://support.apple.com/HT205748

Crypto Officer Role Guide for FIPS 140-2 Compliance OS X El Capitan v10.11 – https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT205748/APPLEFIPS_GUIDE_CO_OSX10.11.pdf

According to Apple, the OS X El Capitan Cryptographic Modules, Apple OS X CoreCrypto Module v6.0 and Apple OS X CoreCrypto Kernel Module v6.0, require no setup or configuration to be in “FIPS Mode” for FIPS 140-2 compliance on devices running OS X El Capitan 10.11.x.

FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X El Capitan v10.11 documentation, in the Compliant Applications and Services section.

For more information about the validation certification, please see below the jump.

iOS 9

Module Name: Apple iOS CoreCrypto Module, v6.0
Certificate #2594: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2594
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2594.pdf

Module Name: Apple iOS CoreCrypto Kernel Module, v6.0
Certificate #2609: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2609
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2609.pdf

OS X El Capitan v10.11

Module Name: Apple OS X CoreCrypto Module, v6.0
Certificate #2610: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2610
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2610.pdf

Module Name: Apple OS X CoreCrypto Kernel Module, v6.0
Certificate #2597: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2597
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2597.pdf

Apple made a change to the fdesetup authrestart command in macOS Sierra, where running fdesetup authrestart will no longer require the encrypted Mac in question to restart immediately.

The delayed restart option can be enabled by adding the -delayminutes verb to the fdesetup authrestart command and specifying one of the following:

• Time in minutes = Delay the restart command for a set number of minutes
• 0 = immediate restart
• -1 = wait indefinitely for restart

Using the -1 option means that the user can restart at their convenience and their encrypted Mac will automatically bypass the FileVault 2 pre-boot login at the next reboot.

To show what this behavior looks like, please see the videos below:

fdesetup authrestart delayminutes 0

fdesetup authrestart delayminutes 0

Note: The video has been edited to artificially reduce the amount of time the restart process takes to run. Run time of the pre-edited video was 1 minute 30 seconds.

fdesetup authrestart delayminutes 1

fdesetup authrestart delayminutes 1

Note: The video has been edited to artificially reduce the amount of time the restart process takes to run. Run time of the pre-edited video was 2 minutes 18 seconds.

fdesetup authrestart delayminutes -1

fdesetup authrestart delayminutes -1

Note: The video has been edited to artificially reduce the amount of time the restart process takes to run. Run time of the pre-edited video was 1 minute 43 seconds.

As part of the various announcements at WWDC 2016 in June 2016, Apple announced that there would be a new filesystem named Apple File System (APFS) being released in 2017. As part of the functionality of APFS, encryption is being natively supported by APFS as a primary feature of the filesystem.

Encryption and APFS

APFS supports the following levels of encryption:

• No encryption – no data is encrypted
• One key per volume (for encrypting both metadata and data) – This is equivalent to how FileVault 2 works today
• Multi-Key encryption
  • – Metadata encryption
  • – Per-File encryption
  • – Per-Extant encryption

What was not overtly stated as part of the presentation is that while Apple may continue to name the encryption “FileVault”, it will work differently than FileVault 2 does today. The reason for this is that FileVault 2 is using encrypted Core Storage volumes to provide full-volume encryption. Core Storage is built on top of HFS+ and it does not appear that Core Storage will be transitioning to APFS. Instead, it appears that Core Storage will remain an HFS+ – specific solution.

As of this date, I haven’t yet seen how APFS encryption works in practice, but one thing is clear – The move away from Core Storage is a fundamental change for how encryption will be handled for Macs, with the following areas being affected:

• How Macs become encrypted
• How to unlock the encryption
• How to decrypt an encrypted Mac
• How to repair problems affecting an encrypted Mac

In short, everything currently documented for handling encrypted Macs will likely become obsolete and new documentation will need to be written for APFS’ encryption solution.

What does this mean for FileVault 2?

With APFS already being available as a developer preview, I don’t anticipate Apple making any more changes to how FileVault 2 works. I believe that Apple is putting FileVault 2 into maintenance mode where (hopefully) bugs will be fixed but development otherwise has stopped in favor of developing APFS’ encryption.

In terms of FileVault 2 management, Apple may choose to add functionality in Sierra to Apple’s fdesetup management tool for FileVault 2 but I believe that any changes will be enhancement to existing functionality in fdesetup instead of adding new functionality. A good example of this is Sierra’s changes to fdesetup authrestart.

Starting in OS X Yosemite 10.10.x, I noticed an issue when enabling FileVault 2 via System Preferences when using an institutional recovery key.

In Mavericks and earlier versions of OS X, the behavior of System Preferences looked like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A list of users that can be enabled for FileVault 2 is displayed. The logged-in user account is marked with the green checkbox that shows that the account is enabled.
4. A message is displayed that a recovery key has been set by a company, school or institution.
5. A message prompting the user to restart is displayed.
6. Once the Restart button has been clicked, the FileVault 2 initialization process continues and restarts the Mac.
7. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.

In OS X Yosemite and OS X El Capitan, the behavior of System Preferences looks like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A message is displayed that a recovery key has been set by a company, school or institution.
4. System Preferences then displays no additional messages and will appear to hang for up to two minutes.
5. The Mac restarts without further input from the user.
6. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.

I had filed a bug report on the problem, which has now been closed as fixed after I was able to verify that the problem was resolved in macOS Sierra 10.12.0.

As of macOS Sierra 10.12.0, the behavior of System Preferences has returned to approximating the pre-Yosemite behavior. The process now looks like this:

1. Click the lock to unlock the FileVault preference pane
2. Click the Turn on FileVault… button
3. A message is displayed that a recovery key has been set by a company, school or institution.
4. A list of users that can be enabled for FileVault 2 is displayed. The logged-in user account is marked with the green checkbox that shows that the account is enabled.
5. A message prompting the user to restart is displayed.
6. Once the Restart button has been clicked, the FileVault 2 initialization process continues and restarts the Mac.
7. The Mac restarts to the FileVault 2 pre-boot login screen.

To illustrate, I’ve made a video showing the described behavior.

Starting in OS X El Capitan, Apple overhauled Disk Utility’s various functions to add new features and remove others. As of macOS Sierra, it appeared at first that the abilities to unlock or decrypt a FileVault 2-encrypted drive had both been removed from Disk Utility. After some investigation though, it looks like the ability to decrypt has been removed, but you can still unlock using Sierra’s Disk Utility. For more details, see below the jump.

1. Boot your Mac and hold down ⌘-R (Command –R) to boot from the Mac’s Recovery HD partition.

Note: You can also boot from and use any other 10.12.x-booting drive. As long as you have macOS Sierra’s Disk Utility, the process below should work.

2. Open Disk Utility.

3. Select your locked FileVault 2-encrypted boot drive.

4. Under the File menu, select Mount to mount the drive. The mount attempt should generate a password prompt to unlock the encrypted drive.

5. When prompted for a password, you can enter the password of any FileVault 2-enabled account on the drive.

6. Once you have unlocked the drive, you should then be able to use Disk Utility’s repair tools to hopefully fix whatever problem your Mac is having.

It can be difficult to provide consistent access for Mac admins when using a local admin account on FileVault 2-encrypted Macs, due to the way password changes are handled for FileVault 2-enabled accounts. The reason for the difficulty is that FileVault 2’s encryption doesn’t care about passwords, it only cares about encryption keys.

When an account on a particular Mac is enabled for FileVault 2, the account’s password is used to generate an key which can be used to unlock the encrypted Core Storage volume that FileVault 2 sets up on the Mac. When the password for the enabled account gets changed, the password and its associated key are updated by first requesting the previous password (and its associated key) to authenticate the change to the new password and associated key.

Assuming that the old password is provided as part of the password change process, no problem. However, if the old password is not provided as part of the password change process, the new password does not get an associated key to unlock FileVault 2 because the old password’s key was not invoked to authorize the change to a new key. The result of this is that the new password can be used to log into the OS and provide whatever password authorization duties are needed for the OS, but you still need the account’s old password to log into the Mac at the FileVault 2 login screen.

The usual fix for this situation is to run the following commands with root privileges:

1. Remove the user from the list of FileVault 2-enabled accounts

fdesetup remove -user username_goes_here

2. Add the user back to the list of FileVault 2-enabled accounts

fdesetup add -usertoadd username_goes_here

When the account is re-enabled using the fdesetup add -usertoadd command, a new key is set up for the user and the passwords are back in sync. However, there are two drawbacks to this approach if a Mac admin wants to automate this:

• You need to provide the password in a non-encrypted format of the account being enabled.
• You need to provide in a non-encrypted format either a recovery key or the password of another FV 2-enabled account on the Mac.

In short, the passwords and/or recovery key used to remove and re-enable the account in question need to be provided “in the clear”, where anyone successfully intercepting the passwords will be able to read them.

Fortunately, for those Mac admins who have a way to capture and escrow FileVault 2 personal recovery keys, there is an alternative to enabling the local admin account. For more details, see below the jump.

This approach relies on the encrypted Mac using an alphanumeric personal recovery key and the Mac admin having access to that personal recovery key.

If both of those conditions are true, see below for a way to log into a local admin account without needing to have that account enabled for FileVault 2.

1. If needed, boot up the Mac.

2. Once the Mac has booted to the FileVault 2 login screen, select an account if needed.

3. When prompted for the account password, click the question mark icon.

4. The next prompt will offer an option to reset the password using the recovery key. To access that, click the arrow icon.

5. Enter the alphanumeric personal recovery key and hit the Return key on the keyboard.

6. The FileVault 2-encrypted boot drive will unlock and boot to the OS login window.

7. At the OS login window, a Reset Password window will appear. Click the Cancel button to halt the password reset process.

8. Log into the Mac using the desired local admin account.

Note: Once a personal recovery key is used to log into a Mac, I recommend replacing it by rotating to a new personal recovery key. For those interested in automating this, my colleague John Kitzmiller has documented how to set up an automated recovery key rotation process using Casper. His post is available via the link below:

https://www.johnkitzmiller.com/blog/automatically-re-issue-individual-filevault-2-recovery-keys-after-single-use-with-the-casper-suite/

In a number of Mac environments, there is a need or requirement for a login banner (otherwise known as a lock message). This message appears in the following locations:

• FileVault 2 pre-boot login screen
• OS login window
• Screensaver lock window

Brevity is best, as staying within a maximum of three lines permits the banner text to be displayed consistently in all three locations. Exceeding the three-line limit may result in the text being cut off and not fully displayed.

You can set this banner text from the command line using the following defaults command, which should be run with root privileges:

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"

Being able to consistently set when lines begin and end can be challenging though, as the defaults command is not able to interpret a newline command natively. However, it is possible to set a multi-line login banner and be able to consistently set when lines begin and end. For more details, see below the jump.

To accommodate for the defaults command’s inability to interpret newline commands, you can use the printf utility to format the text of the login banner as designed and store the formatted text as a variable. printf is able to interpret the characters \n as indicating a carriage return, so it is possible to run the following command:

printf "This Mac belongs to John Doe\nPhone number: 1-555-555-1212\nReward offered if found.\n"

To display the following text:

This Mac belongs to John Doe
Phone number: 1-555-555-1212
Reward offered if found.

In order to set a login banner with this message, you could run a script like the one shown below, using root privileges:

#!/bin/bash

loginbannertext=`printf "This Mac belongs to John Doe\nPhone number: 1-555-555-1212\nReward offered if found."`

# Set login banner

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "$loginbannertext"

The message will appear at the login window,  screensaver lock window, and FileVault 2 login with the desired lines of text beginning and ending as specified.

Note: If the message does not appear at the FileVault 2 login, you also need to remove certain cache filenames ending in .efires from the following location:

/System/Library/Caches/com.apple.corestorage/EFILoginLocalizations

As part of Apple’s FileVault 2 encryption, Apple has provided for the use of recovery keys. These keys are a backup method to unlock FileVault 2’s encryption in the event that the usual method of logging using a user’s account password is not available.

There are two main types of recovery keys available:

1. Personal recovery keys (PRK) – These are recovery keys that are automatically generated at the time of encryption. These keys are generated as an alphanumeric string and are unique to the machine being encrypted. In the event that an encrypted Mac is decrypted and then re-encrypted, the existing personal recovery key would be invalidated and a new personal recovery key would be created as part of the encryption process.

2. Institutional recovery keys (IRK) – These are pre-made recovery keys that can be installed on a system prior to encryption and most often used by a company, school or institution to have one common recovery key that can unlock their managed encrypted systems.

This recovery key model has continued to be used on Apple File System (APFS), starting with macOS High Sierra 10.13.0, with one important difference:

• You can encrypt an APFS boot drive using an IRK.
• You cannot unlock or decrypt an encrypted APFS boot drive using an IRK.

Update 11-3-2017: This has been fixed in macOS 10.13.1. For information on how to unlock and decrypt an encrypted APFS boot drive using an IRK, please see the link below:

Unlock or decrypt an encrypted APFS boot drive from the command line

For more details, see below the jump.

The issue appears to be that a necessary function has not been added to the diskutil command line tool. For FileVault 2 on macOS Sierra and earlier, the command to unlock using an IRK is shown below:

diskutil cs unlockVolume -recoverykeychain /path/to/filename_goes_here.keychain

This command uses diskutil‘s CoreStorage functions, which do not apply to Apple File System. Meanwhile, there is not an equivalent command available for diskutil’s Apple File System’s functions. If there was, it should look something like this:

diskutil apfs unlockVolume -recoverykeychain /path/to/filename_goes_here.keychain

An encrypted volume must be unlocked before it can be decrypted, so without the ability to unlock using an IRK, you cannot decrypt using an IRK.

I’ve opened a ticket with Apple Enterprise support for this issue; hopefully a fix is available in a future OS update.

As part of working with Apple File System (APFS) volumes, it may be necessary to decrypt a boot drive using APFS’s native encryption in order to fix a problem. To decrypt an encrypted APFS boot drive from the command line, you will need to do the following:

1. Identify the relevant encrypted APFS volume
2. Unlock the encrypted APFS volume
3. Decrypt the encrypted APFS volume

For more details, see below the jump.

Identifying the encrypted APFS volume

A necessary pre-requisite to unlocking APFS encryption is to identify the correct encrypted volume. To do this, open Terminal and run the following command:

diskutil apfs list

Running the specified diskutil command will give you a listing of all APFS containers and volumes. To help identify what you’re looking for, I’ve highlighted the identifier of the encrypted APFS volume in this example:

Unlocking the encrypted APFS volume

If you have access to the password of one of the enabled accounts on the encrypted APFS volume, you can unlock using the command shown on the screen. You will be prompted to provide the password.

diskutil apfs unlockVolume /dev/apfs_volume_id_here

You should then see output similar to the following:

If you have access to the personal recovery key associated with the encrypted APFS volume, you can unlock using the command shown on the screen. You will need to provide the recovery key as part of the command.

diskutil apfs unlockVolume /dev/apfs_volume_id_here -passphrase recovery_key_goes_here

You should then see output similar to the following:

If using an institutional recovery key, you can unlock the encryption using a FileVaultMaster keychain that contains both the public and private key of your institutional recovery key. One requirement is that you will need to be booted from Recovery HD or from Internet Recovery. Here’s how to do this:

1. Copy the FileVaultMaster keychain that contains both the public and private key of your institutional recovery key to a drive that you can access from Recovery HD.

2. Boot to Recovery HD.

3. Open Terminal.

4. Get the APFS volume ID of the encrypted drive by running the following command:

diskutil apfs list

5. With the APFS volume ID information acquired, run the following command to unlock the FileVaultMaster.keychain:

security unlock-keychain /path/to/FileVaultMaster.keychain

Once this command is run, you’ll need to enter the keychain’s password when prompted. If the password is accepted, you’ll be taken to the next prompt.

6. Run the following command to unlock the encrypted APFS volume on the encrypted Mac:

diskutil apfs unlockVolume /dev/apfs_volume_id_here -recoverykeychain /path/to/FileVaultMaster.keychain

You should then see output similar to the following:

Decrypting the encrypted APFS volume

Update 12-31-2017: The procedure used for decryption has changed as of macOS 10.13.2. For more details, please see the link below:

https://derflounder.wordpress.com/2017/12/31/decrypting-an-apfs-encrypted-volume-using-diskutil-on-macos-10-13-2/

Once the drive has been unlocked, you can then decrypt the APFS volume using the command shown below:

diskutil apfs decryptVolume /dev/apfs_volume_id_here

You should then see output similar to the following:

As long as you are using root or admin privileges, no additional authentication is required to decrypt an unlocked encrypted volume. However, if you try to decrypt while logged in as a standard user, the diskutil tool will ask for admin authorization.

If the needed admin authorization is not provided, diskutil will halt at that point and give an insufficient privileges error.

Monitoring decryption

You can monitor decryption of the APFS volume from the command line by running the following command:

diskutil apfs list

Note: Unlike previous OSs, it is possible on macOS High Sierra to completely decrypt an encrypted APFS drive while booted from Recovery HD.

You can also monitor decryption via the following means:

1. Boot from the decrypting drive.
2. Open System Preferences
3. Open the Security & Privacy preference pane

4. Click the FileVault tab

5. View the current decryption status

In the event that you need to unlock an unbootable boot drive using Apple File System (APFS) encryption, it’s possible to do so using Disk Utility and one of the following authentication credentials:

1. The password to a FileVault-enabled account on the drive
2. A personal recovery key

For more details, see below the jump.

To unlock an encrypted APFS boot drive, please use the procedure shown below:

Note: For this example, I’m using Recovery HD‘s Disk Utility though you can also use Disk Utility from a regular boot drive.

1. Open Disk Utility.

2. Select the locked encrypted drive.

3. Click the Mount button.

4. In the password blank which appears, enter one of the following authentication credentials:

• The password to a FileVault-enabled account on the drive
• A personal recovery key

5. If the authentication is accepted, the drive should unlock and mount.

Note: You will not be able to decrypt from Disk Utility. If decryption is necessary, you will need to use the command line method documented at the link below:

Unlock or decrypt an encrypted APFS boot drive from the command line

As part of working Apple File System, I’ve developed a script which is designed to check and report the status of encrypted Apple File System (APFS) drives. Currently, here’s what the script is detecting and reporting:

It first checks to see if a Mac is running 10.13.x or higher. If the Mac is question is running 10.13.x or higher, the script reports if it is using encryption on an APFS drive and gives the encryption or decryption status.

If encrypted, the following message is displayed:

FileVault is On.

If not encrypted, the following message is displayed:

FileVault is Off.

If encrypting, the following message is displayed:

Encryption in progress:

How much has been encrypted is also displayed.

If decrypting, the following message is displayed without quotes:

Decryption in progress:

How much has been decrypted is also displayed.

If run on a drive which is not using APFS, the following message is displayed:

Unable to display encryption status for filesystems other than APFS.

The script is available below and here on my GitHub repository:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/check_apfs_encryption

I’ve also built a Jamf Pro Extension Attribute:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/check_apfs_encryption

Apple has made changes as of macOS 10.13.2 to the way you can turn off APFS encryption when using the diskutil apfs decryptVolume command.

On macOS 10.13.0 and 10.13.1, an APFS encrypted volume could be decrypted using the following procedure:

1. Identify the relevant encrypted APFS volume
2. Unlock the encrypted APFS volume
3. Decrypt the encrypted APFS volume

Once the drive has been unlocked, you could then decrypt the APFS volume using the command shown below:

diskutil apfs decryptVolume /dev/apfs_volume_id_here

As long as you were using root or admin privileges to run the command, no additional authentication was required to decrypt an unlocked encrypted volume.

However, the diskutil apfs decryptVolume command has been updated on macOS 10.13.2 to require additional authentication:

In order to decrypt using a user account’s password or personal recovery key (PRK), it is necessary to specify the following:

1. The relevant user UUID
2. The relevant account password or the PRK.

Note: As of macOS 10.13.2, it is not possible to decrypt an encrypted APFS volume using an institutional recovery key (IRK). You can unlock an encrypted APFS volume using an IRK, but diskutil apfs decryptVolume does not include functionality for using an IRK to authenticate the decryption of an encrypted APFS volume.

For more details, please see below the jump.

If you are planning to use a user account’s password to decrypt, you will first need to correctly identify the relevant encrypted APFS volume and which UUID you want to use.

In this case, we’ll be using the following APFS volume identifier:

/dev/disk1s1

The other assumption is that the encrypted APFS volume has been unlocked and is ready for decryption.

If you are booted from the encrypted drive, you can get the UUID of a user account by running the command shown below and matching which UUID belongs to the account you want to use.

fdesetup list

If you are not booted from the encrypted drive, there is another way to get the UUID by running the command shown below and looking at the entries listed as Local Open Directory User. However, this method will not display the account name and may require some guesswork if there is more than one FileVault enabled account enabled.

diskutil apfs listcryptousers /dev/apfs_volume_id_goes_here

Once you have access to the UUID and password of one of the enabled accounts on the encrypted APFS volume, you can unlock using the command below. You will be prompted to provide the password:

diskutil apfs decryptVolume /dev/apfs_volume_id_goes_here -user uuid_goes_here

If you want to use the PRK, the PRK has its own UUID which only appears if you run the following command:

diskutil apfs listcryptousers /dev/apfs_volume_id_goes_here

In this case, use the UUID associated with the Personal Recovery User entry.

If you have access to the PRK associated with the encrypted APFS volume, you can decrypt using the command below. You will need to provide the relevant UUID and the alphanumeric personal recovery key as part of the command.

diskutil apfs decryptVolume /dev/apfs_volume_id_goes_here -user uuid_goes_here -passphrase personal_recovery_key_goes_here

To show the process of decrypting an unlocked encrypted APFS volume while using a personal recovery key, please see below for a video:

The iMac Pro introduced a number of new features, but one that may have been little noticed is the introduction of hardware encryption for the iMac Pro’s SSD storage. Apple references the hardware encryption on the iMac Pro page this way:

T2 also makes iMac Pro even more secure, thanks to a Secure Enclave coprocessor that provides the foundation for new encrypted storage and secure boot capabilities. The data on your SSD is encrypted using dedicated AES hardware with no effect on the SSD’s performance, while keeping the Intel Xeon processor free for your compute tasks.

This hardware encryption means that, even if FileVault is not enabled, the data stored on the iMac Pro’s SSD storage is encrypted. What’s more, the key to unlock the encryption is stored in the iMac Pro’s Secure Enclave and never leaves the machine. Physically remove the SSD storage from the iMac Pro and you won’t be able to access any data stored on the SSD, even if you have an otherwise identical iMac Pro available.

For those with knowledge of how Apple protects data stored on iOS devices, this should sound familiar. The main difference between the iOS and macOS implementation at this point appears to be that macOS does not have the equivalent passcode lock screen.

Instead, the needed encryption key to unlock the hardware encryption is automatically provided by the Secure Enclave when the iMac Pro boots. This behavior is just like that seen on an iOS device where a passcode has not been enabled.

This is referenced when you run the following command on an iMac Pro:

diskutil apfs list

On an iMac Pro where FileVault is not enabled, FileVault is shown with the following status:

FileVault: No (Encrypted at rest)

This recognizes that encryption is available, but that the encryption only provides protection when the data is at rest. “Data at rest” in this context should be understood to mean when the Secure Enclave has not provided the needed encryption unlock key, which would be the case in either of the following scenarios:

1. The iMac Pro is off.
2. The SSD storage has been removed from the iMac Pro.

For more, please see below the jump.

So what does this hardware encryption mean for FileVault on Apple File System? Is it no longer needed? Will Apple be implementing a passcode lock, like they have on iOS? Will hardware encryption allow FileVault to be enabled in seconds, rather than hours?

I don’t have any inside knowledge, so treat what I’m about to say with the appropriate skepticism. It’s speculation, pure and simple.

That said, I don’t think that Apple will be mapping the iOS passcode experience directly onto macOS. The reason I say that is iOS’s encryption model incorporates an assumption that iOS is not a multi-user OS. That’s where FileVault encryption on Apple File System comes in. It provides the following:

1. The ability to support multiple user accounts.
2. An additional encryption layer, providing even more protection for the data stored on the iMac Pro’s SSD storage.

Because of this, I see FileVault on Apple File System staying around for at least the next version of macOS while Apple works out the necessary support for providing an instant-on encryption solution like on iOS, while being able to provide the multiple-user support needed on macOS.

That said, I believe that this transition will be a short one of only one to two years. FileVault on Apple File System will then become a feature needed mostly on Mac hardware which lacks a Secure Enclave. Encryption on Macs equipped with Secure Enclave will change, from something that Mac admins will need to enable and monitor, to something which is Just On and which Just Works.

Hat tip to Tim Perfitt for providing technical assistance with the content in this post. If you’re interested in the iMac Pro’s other changes, please check out Tim’s post on Secure Boot and the iMac Pro.

For macOS Sierra and earlier, Apple had a dedicated FileVault Recovery Key Redirection profile payload for FileVault recovery key redirection. This profile was designed to work with a mobile device management (MDM) server, to allow the MDM server to act as a recovery key escrow service and store FileVault personal recovery keys.

Note: Jamf Pro will be used as the example MDM server in this post. However, similar functionality is available in other MDM services.

On macOS High Sierra, this FileVault Recovery Key Redirection profile payload no longer works. In its place, Apple has added new Enable Escrow Personal Recovery Key settings to the FileVault section of the existing Security profile payload.

Adding the recovery key redirection to the Security payload may cause issues in some environments, as the Security profile payload has other settings which those environments may prefer to manage separately, or not manage at all.

For those who prefer to manage FileVault recovery key redirection separately from the other settings managed by the Security payload, it is possible to create a profile (with some manual editing) which only manages FileVault recovery key redirection. For more details, see below the jump.

The first thing to do is to create a new profile (which should not be assigned to any Macs) and configure the Security profile payload with the desired recovery settings on your MDM server.

Once the profile is configured as desired, download a copy of the profile to your workstation. After downloading, the profile can be edited to include only those settings which manage the FileVault recovery key redirection. To help with figuring out the appropriate settings, I have a sample profile available below.

Note: As currently set up, the sample profile doesn’t redirect recovery keys. It needs the relevant payload content (specifically the FileVault2Comm.cer certificate payload) from the Security profile created by your own MDM server:

Once the profile has been edited and all settings have been verified:

1. Upload the profile to your MDM server
2. Deploy the profile to a test Mac
3. Rotate the FileVault personal recovery key on the test Mac to verify that redirection is working as desired.

To make sure that the MDM server does not try to alter the edited FileVault recovery key redirection profile, I recommend signing the profile.

Signing the profile encrypts it, which prevents the MDM from changing the profile’s contents. The MDM server can now serve out the redirection profile, but will not be able to edit it or change it in any way.

As part of Apple File System’s FileVault encryption on mac OS High Sierra, Apple introduced Secure Token. This is a new and undocumented account attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume. To help make sure that at least one account has a Secure Token attribute associated with it, a Secure Token attribute is automatically added to the first account to log into the OS loginwindow on a particular Mac.

Once an account has a Secure Token associated with it, it can then create other accounts which will in turn automatically be granted their own Secure Token.

For the consumer user, this usually takes the following form:

1. Secure Token is automatically enabled for the user account created by Apple’s Setup Assistant.
2. The Setup Assistant-created user account with Secure Token then creates other users via the Users & Groups preference pane in System Preferences. Those accounts get their own Secure Token automatically.

However, Active Directory mobile accounts and user accounts created using command line tools do not automatically get Secure Token attributes associated with these accounts. Without the Secure Token attribute, those accounts are not able to be enabled for FileVault.

Update 1-20-2018: @mikeymikey has pointed out an exception to the rule:

Instead, the sysadminctl utility must be used to grant Secure Token to these accounts as a post-account creation action. In that case, the sysadminctl utility must be run by a user account with the following pre-requisites:

1. Administrative rights
2. Secure Token

For more details, please see below the jump.

There are a couple of ways to check from the command line if a particular account has the Secure Token attribute associated with it:

sysadminctl -secureTokenStatus username_goes_here

Note: The sysadminctl utility has multiple ways to provide the needed admin authorization to run. Please see this post for details.

dscl . -read /Users/username_goes_here AuthenticationAuthority

You can also check in Directory Utility to see if a Secure Token entry appears under the account’s Authentication Authority attribute.

Once it’s been verified if an account needs Secure Token, sysadminctl‘s SecureToken functions can be used to add it.

The command shown below should add Secure Token to a specified account

sysadminctl -secureTokenOn username_which_needs_secure_token_goes_here -password password_goes_here

If you want to be prompted for the account’s password, use the command shown below:

 sysadminctl -secureTokenOn username_which_needs_secure_token_goes_here -password -

To see how the process of adding Secure Token to an account which doesn’t have it works, please see the video below. It will go through the following process:

1. Using sysadminctl to check an account for its Secure Token status
2. Using sysadminctl to check the logged-in account for its Secure Token status
3. Using sysadminctl to grant Secure Token to the first account, using the logged-in account’s credentials and Secure Token.
4. Using sysadminctl to check the first account to verify that Secure Token has been added.

To see how user accounts created in System Preferences’ Users & Groups preference pane automatically get Secure Token when created by an account with Secure Token, please see the video below. It will go through the following process:

1. Creating a new user account in the Users & Groups preference pane
2. Verifying via sysadminctl that the new user account has Secure Token

I’ll be speaking at Mac Admin & Developer Conference UK 2018, which is taking place in London from February 20th – 21st, 2018. My session will be on Wednesday, February 21st and is covering FileVault management on macOS High Sierra, with discussion of how to manage encryption on both APFS and HFS Plus drives..

The full conference schedule is available from https://www.macad.uk/2018speakers/schedule/ and you can see the entire list of speakers at http://www.macad.uk/2018speakers/