Archive

Archive for the ‘Apple File System’ Category

T2, FileVault and brute force attack protection

November 1, 2018 1 comment

Apple recently released an overview document for its new T2 chip, which includes how the new T2 chip-equipped Macs have new protections against brute force attacks. This protection only applies if FileVault is enabled and is similar in concept to how iOS devices set with passcodes are protected against brute force attacks.

On iOS, if an incorrect passcode is entered more than five times, a one minute delay is set.

Img 58462d7da9d03 477x600

After the sixth try, the delay is now five minutes and the delays get longer from there until the device has the 10th wrong passcode entered and the device wipes.

Screen Shot 2018 11 01 at 4 31 50 PM

On Apple iOS devices with a Secure Enclave, those delays are enforced by the Secure Enclave processor. Similarly, the T2 chip-equipped Macs also have a Secure Enclave processor which is managing access attempts and introducing delays.

For Macs with Secure Enclave, the enforcement looks like this:

  • 30 unlock attempts via using the password at the login window or target disk mode
  • 10 unlock attempts via using the password in Recovery Mode
  • 30 unlock attempts for each enabled FileVault recovery mechanism
    • iCloud recovery
    • FileVault personal recovery key
    • FileVault institutional recovery key

The maximum number of unlock attempts is 90, regardless of the mix of methods used. After 90 attempts, the Secure Enclave processor will no longer process any requests to do the following:

  • Unlock the volume
  • Decrypt the volume
  • Verify the password / recovery key

Delays are also imposed on macOS between attempts.

Screen Shot 2018 11 01 at 8 40 50 AM

So what happens after 90 attempts? Does the Mac lock forever and become a paperweight?

After checking with AppleCare Enterprise, the answer is that the Mac will not be a paperweight, but that the Mac’s boot drive will need to be erased before it can be used again. This approach helps make sure that the Mac is still usable, but also ensures that the encrypted data stored on the boot drive is no longer recoverable.

For more information about brute force protection for encrypted iOS and macOS devices, I recommend checking out Apple’s currently available white papers:

Reclaiming drive space by thinning Apple File System snapshot backups

April 7, 2018 14 comments

As part of a recent clean-up of my Apple File System-formatted (APFS) boot drive, I deleted a number of files. However, I noticed that deleting files did not free up nearly as much space as I thought it should. When I investigated, I noticed that my boot drive had a number of Time Machine snapshots stored on it.

Screen Shot 2018 04 07 at 2 04 39 PM

A quick way to reclaim space from a particular snapshot immediately would be to delete the snapshot using the tmutil command line tool, using the command shown below:

tmutil deletelocalsnapshots snapshot-name-here

However, I didn’t want to delete backups if I could avoid it since I might need something stored in one of them. After some research, I was able to find a tmutil command that did what I needed. For more details, please see below the jump:

Read more…

Slides from the “Managing FileVault 2 on macOS High Sierra” Session at MacAD UK 2018 Conference

February 21, 2018 4 comments

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

PDF – http://tinyurl.com/MacADUK2018pdf

Keynote – http://tinyurl.com/MacADUK2018key

Hat tip to the attendee who brought to my attention that fdesetup sync is not supported on encrypted APFS boot drives. I’ve now updated the slides to reflect that it works on macOS High Sierra for HFS+ drives only.

HFS+

Screen Shot 2018 02 21 at 12 54 13 PM

APFS

Screen Shot 2018 02 21 at 1 04 16 PM

Secure Token and FileVault on Apple File System

January 20, 2018 33 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…

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

January 8, 2018 5 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 12 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 2 comments

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

%d bloggers like this: