Archive

Archive for the ‘FileVault 2’ Category

Creating multiline login banners

March 25, 2017 2 comments

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"

LWScreenShot 2017 03 25 at 11 31 14 AM

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.

Read more…

Using FileVault 2 recovery keys on FileVault 2-encrypted Macs to provide access for local admins

February 23, 2017 1 comment

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

Figure 25 Using fdesetup remove with username


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

fdesetup add -usertoadd username_goes_here

Figure 21 Using fdesetup add usertoadd to enable additional accounts


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.

Read more…

Using Disk Utility on macOS Sierra to unlock FileVault 2-encrypted boot drives

October 11, 2016 Leave a comment

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.

Read more…

System Preferences problem when enabling FileVault 2 using an IRK is fixed in macOS Sierra

October 8, 2016 Leave a comment

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.

FileVault 2 and the rise of Apple File System

October 7, 2016 Leave a comment

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.

fdesetup authrestart no longer requires an immediate restart in macOS Sierra

September 22, 2016 5 comments

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.

FileVault 2 on El Capitan is now FIPS 140-2 Compliant

April 20, 2016 1 comment

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.11https://support.apple.com/HT205748

Crypto Officer Role Guide for FIPS 140-2 Compliance OS X El Capitan v10.11https://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.

Screen Shot 2016 04 20 at 7 14 05 AM

 

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

Read more…

%d bloggers like this: