FIPS 140-2 validation and FileVault 2

January 10, 2016 2 comments

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

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 certification process and has been validated as being as being FIPS 140-2 Compliant:

OS X 10.11 is currently in the process of becoming FIPS 140-2 validated. The reason El Capitan is not automatically FIPS 140-2 validated has to do with OS X’s CoreCrypto cryptography foundation and how the FIPS 140-2 certification process works.

FIPS certification

The FIPS certification 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 certification 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 certification 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 certification 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 certification 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.

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

First look at Veertu

January 10, 2016 3 comments

One of the lesser-known changes that Apple introduced with OS X Yosemite was a Hypervisor framework, which was designed to allow virtualization solutions to be built for OS X without the need for third-party kernel extensions.

Screen Shot 2016 01 08 at 11 58 50 PM

One reason for this was that eliminating the need for kernel extensions allowed the possibility of virtualization software to be distributed and sold via the Mac App Store. While neither VMware or Parallels have taken advantage of this, a new virtualization product named Veertu has recently become available in the MAS.

Screen Shot 2016 01 08 at 8 13 38 AM

Veertu is available for free from the MAS, and allows installation of selected Linux VMs, downloaded from Veertu’s online library. For more details, see below the jump.

Read more…

2015 in review

December 29, 2015 Leave a comment

The stats helper monkeys prepared a 2015 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 1,500,000 times in 2015. If it were an exhibit at the Louvre Museum, it would take about 64 days for that many people to see it.

Click here to see the complete report.

Categories: Technical

Managing El Capitan’s FileVault 2 with fdesetup

December 20, 2015 2 comments

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.

Read more…

Updated System Integrity Protection status reporting script

December 18, 2015 Leave a comment

After writing a Casper Extension Attribute script to report on the status of System Integrity Protection, I realized that I hadn’t accounted for reporting SIP’s custom configurations. These are configurations where SIP is enabled, but one or more of SIP’s protections or restrictions has been disabled. I’ve now updated the script to also report on the following SIP configurations:

  • Kext Signing: disabled
  • Filesystem Protections: disabled
  • NVRAM Protections: disabled
  • Debugging Restrictions: disabled
  • DTrace Restrictions: disabled

For more details, please see below the jump.

Read more…

Casper Extension Attribute script to report System Integrity Protection status

December 16, 2015 Leave a comment

To follow up on Apple’s changing the output of csrutil status when System Integrity Protection (SIP) is disabled, I’ve posted the following Casper extension attribute to my GitHub repo to report on whether SIP is enabled or disabled.

The script has the following functions:

If the Mac is running 10.10.x or earlier

The script reports System Integrity Protection Not Available For and then reports the relevant version of OS X. For example, the script returns the following output on a Mac running OS X 10.10.5:

System Integrity Protection Not Available For 10.10.5

If the Mac is running 10.11.x or later

This script uses csrutil status to check SIP’s status. If System Integrity Protection is disabled, the script returns the following output:


If System Integrity Protection is enabled, the script returns the following output:


For those interested, the script is available on my GitHub repo:

System Integrity Protection’s csrutil status’ message change for OS X 10.11.2

December 16, 2015 2 comments

In order to check whether System Integrity Protection (SIP) is enabled or disabled on a Mac running OS X El Capitan, you can use the csrutil command to report on SIP’s current status. For example, to learn if SIP is enabled or disabled, run the following command:

csrutil status

This command can be run without root privileges and will tell you if SIP is on or off.

If SIP is enabled on 10.11.0 or higher, you should receive the following message:

System Integrity Protection: enabled

Csrutil status enabled run outside recovery

If SIP is disabled on OS X 10.11.0 or 10.11.1, you may receive a confusing message which indicates that SIP is enabled, followed by a list of individual SIP functions which are disabled. If all functions listed are showing as being disabled, SIP is actually completely disabled; it’s just confusingly worded.

Csrutil status disabled run outside recovery 10101

It appears that Apple has updated the status message on OS X 10.11.2 to make it much more clear when SIP is disabled. On 10.11.2, if SIP is disabled, you now should receive the following message:

System Integrity Protection: disabled

Csrutil status disabled run outside recovery 10102


Get every new post delivered to your Inbox.

Join 270 other followers

%d bloggers like this: