Secure Token and FileVault on Apple File System

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:

.@rtrouton Not strictly true.

If you bind to AD and suppress SetupAssistant, the first mobile AD user logging in will indeed get a SecureToken.

There are undocumented subtleties Apple follows in bootstrapping the first SecureToken user from none. pic.twitter.com/yZ7khKCmne

— mikeymikey (@mikeymikey) January 20, 2018

---

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.

Oracle Java 9 JDK and JRE installation scripts for macOS

Oracle has started to release Java 9 for macOS, so I’m posting a couple of scripts to download and install the following:

Oracle Java 9 JRE
Oracle Java 9 JDK

Oracle has been releasing two separate versions of Java 8 simultaneously and may do the same for Java 9, so these Java 9-focused scripts are designed to allow the user to set which version they want to install: the CPU release or the PSU release.

The difference between CPU and PSU releases is as follows:

• Critical Patch Update (CPU): contains both fixes to security vulnerabilities and critical bug fixes.
• Patch Set Update (PSU): contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems.

For more details on the differences between CPU and PSU updates, please see the link below:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

For more information, please see below the jump.

FileVault recovery key redirection profile changes in macOS High Sierra

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.

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

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.

Setting your Mac to receive macOS beta updates using seedutil

As part of a discussion of how to build test VMs, a colleague mentioned how they were using the seedutil tool to help configure Macs to access Apple’s beta updates. I hadn’t run across this tool before, so I decided to do some research and see if I could make it work for my own testing needs. For more details, see below the jump.