Archive

Archive for the ‘FileVault 2’ Category

Secure Token and FileVault on Apple File System

January 20, 2018 2 comments

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.

Users and groups preference pane only user gets secure token automatically

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.

Filevault preference pane account without secure token cannot manage 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.

Read more…

FileVault recovery key redirection profile changes in macOS High Sierra

January 15, 2018 3 comments

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.

Screen Shot 2018 01 15 at 12 40 23 PM

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.

Screen Shot 2018 01 15 at 12 44 56 PM

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.

Read more…

Secure Enclave, Mac SSD hardware encryption and the future of FileVault

January 8, 2018 4 comments

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.

Screen Shot 2018 01 07 at 9 32 21 PM

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.

Iphone7 ios11 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)

Screen Shot 2018 01 07 at 9 28 23 PM

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.

Read more…

Decrypting an APFS encrypted volume using diskutil on macOS 10.13.2

December 31, 2017 2 comments

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.

Screen Shot 2017 11 03 at 11 02 23 PM

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.

Read more…

APFS encryption status check script

November 13, 2017 1 comment

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.

Screen Shot 2017 11 12 at 8 38 08 PM

 

If not encrypted, the following message is displayed:

FileVault is Off.

Screen Shot 2017 11 12 at 8 43 07 PM

If encrypting, the following message is displayed:

Encryption in progress:

How much has been encrypted is also displayed.

Screen Shot 2017 11 12 at 8 08 30 PM

 

If decrypting, the following message is displayed without quotes:

Decryption in progress:

How much has been decrypted is also displayed.

Screen Shot 2017 11 12 at 8 38 48 PM

 

 

 

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.

Screen Shot 2017 11 12 at 8 44 11 PM

 

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

Unlock an encrypted APFS boot drive using Disk Utility

November 4, 2017 1 comment

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.

Read more…

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

November 4, 2017 5 comments

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.

Read more…

%d bloggers like this: