Even the Federal Government Won’t Buy Apple Products That Don’t Meet Encryption Standards

| Analysis

There's been much fuss lately about the desire by the FBI to be able to break into any iPhone it needs to. But the FBI is just one government agency. The interesting backstory here is that the Federal Government, in general, won't buy products that don't meet certain cryptographic standards. It's called FIPS 140-2 certification, and Apple has just announced that the cryptographic modules in iOS 9 and OS X 10.11 have obtained that validation. It's delicious irony.

From Wikipedia: "The Federal Information Processing Standard (FIPS) Publication 140-2 ... is a U.S. government computer security standard used to accredit cryptographic modules.

Why is FIPS 140-2 important in this case? Symantec explains.

There are many reasons why a product requires FIPS 140-2 validation, and the compelling one is regulatory. FIPS 140-2 evaluation is required for sale of products implementing cryptography to the Federal Government. If you don't have a certificate or at least demonstrate a commitment to obtaining one, then there is a good chance that you won't be able to sell your product in this key market.

While Apple doesn't have a predominant position when it comes to the sale of computers to the Federal Government, it does sell a significant number of Macs—as well as iPhones. It's enough that it constitutes a small but important part of Apple's overall revenue.

Apple's FIPS 140-2 Certification Statement

Recently, Apple made the following announcement.

Apple is pleased to announce the FIPS 140-2 Level 1 Validations for the two Cryptographic Modules used by both iOS 9 & OS X El Capitan v10.11 were all completed! (3/29/16; 4/05/16)

Knowledge Base References

There are Apple Support Knowledge Base Articles for iOS and OS X resources relating to ALL Validations and Certifications including FIPS 140-2, Common Criteria Certification, [link added by author] Security Guidance Resources, and requesting Volatility Statements....

iOS product security: Validations and guidance

OS X: Security certifications and validations

This topic, including the Common Criteria Certification, is a vast, technical area, and there are many nuances and complications beyond the scope of this introductory article. For example, Apple's certification of what's called "cryptographic erase" comes into play for classified material (or even private data). Another is that the recent Apple certification is only for "Level 1" which does not cover tamper resistance (Level 3) or physical security around the cryptographic module (Level 4). What's interesting, however, is that:

1. Apple has been working to secure its systems and comply with the applicable government security and cryptographic standards for quite some time. For example, I wrote about it in 2010. "Apple Announces Common Criteria Certification for Snow Leopard."

2. Even as the Apple vs. FBI conflict raged on, Apple was about the formal business of certifying its products, as it always has, for the FIPS 140-2 standard in recognition of the government's (and other organization's) need for secure and auditable systems.

And so, even as one government agency charged with law enforcement is eager to have the ability to access secured iPhones, other government agencies, for many years, have demanded that if Apple is going to sell products to them, they must meet certain cryptographic standards.

The contrast and conflict between two seemingly opposed needs, even if not on a strictly equivalent technical level, is most interesting and is worth monitoring, especially in light of pending Congressional legislation.


1. Email: Security Certification at Apple

2. Apple list server for product security matters.

Popular TMO Stories



Once branch of the US government doing something that contradicts what another branch is doing?
One part of the US Government doing something that will make it harder for other departments to do their job?
Why does that not surprise me.
I wonder how many iPhones are used by FBI Agents?


I am not sure when this became effective, but OS X standard boot procedure now tests and verifies the FIPS crypto modules. If this fails then the kernel panics (in the Unix sense) and shuts down.

Problem is that a regular user has no clue of such a failure. Even if you boot in verbose-mode you can’t see it - it goes by too fast. When it happened to me the only way I found it was to take an iPhone video of the boot process and examine it step-by-step.

Scott B in DC

@geoduck, one thing has nothing to do with another. The FIPS 140 certification program is not even done by the government. It’s managed by the National Institute of Standards and Technology (NIST) but is performed by outside contractors. It is a certification program that allows independent testing of crypto modules to meet levels of security. A lot of products are on the list. It allows those of us who have to implement security for the government (yes, I do infosec for the feds… I am no longer in areas I cannot talk about) to trust the device and/or software in order to concentrate on other aspects of the services.

@vpndev, that is irrelevant. The reason it is there is not to say it is FIPS certified but loading software that will help an appropriately configured system to be compliant with government encryption requirements. However, it’s the wrong nomenclature and a residual of past ills when defining what is supposed to be standard government crypto.


Scott: I am not going to argue the relevancy with you. I do remember that boot-time checking was required in the past - maybe that’s changed.

But let me be crisp about three things ...
1. with OS X 10.11.x there is a default boot sequence
2. the boot sequence includes running tests against FIPS-compliant crypto modules in the kernel
3. if the test fails, the boot process panics and the system shuts down

There is no warning or notice for “regular” users, and that is the point I was attempting to make. I am not claiming any certification for the software - I am only reporting what it says itself in the boot process. I must admit that I don’t understand your point about “irrelevancy”.

Scott B in DC

@vpndev What you said is true but not relevant. Compliance is not the same as certified. FIPS 140-2 defines a certification program. Saying something is compliant means that it is programmed in a manner that could possibly be tested and receive a certification but has not been formally tested. How everything else is implemented is not relevant.

You have demonstrated why those of us who do this daily for a living collectively rolled our eyes over the context of the encryption discussion. The discussions focuses on one aspect of the issue without understanding that one risk sprouts 20 others. This is not easy and cannot be distilled into a few statements. If it could be that easy we wouldn’t have the problems we have now and, most of all, I could retire!


Scott: your criticism may be true but it also is not relevant. If you go back and look at what I posted, it was that OS X tests and verifies the crypto modules in the kernel. I never mentioned the words compliant or certified - you did. I believe that at one time Apple’s FIPS 140-2 implementation *was* certified, although I’m not 100% certain of that (it was some years ago). Whether they are, or were, or never were, is of no consequence.

My point was to alert people that
1. crypto modules were present in the kernel
2. they were tested at boot time to make sure that the results were what they should be
3. if they weren’t, then the system shut down very fast with no effective warning or notice

That way, people with an unexplained boot-time problem would have a possible cause to look for.

That was all. Have a nice day.

Scott B in DC

@vpndev: my comments are assuming that they are in the context of the original article. Thus, I assume that it is a comment based on the report by John Mortallero.

That being said, there are other issues that could be holding up a boot. One of the more egregious problems that could hold up a boot process are disk issues. Other common issues are RAM errors.

Do you know what the crypto start up is doing? ALL it is doing is checking the code for consistency; verifying that the code has not been altered; making sure that the pseudo random number generator is sufficiently random; and other consistency checks. Unless you flash the PROMs in the areas where the crypto boot code is stored then the chances of the crypto modules causing your Mac to not startup is slim to none and slim has left town!


The boot-time “panic” message specifically said that the FIPS check had failed, and a few seconds later the system halted (power off). This is what it said:

OSX FIPS Integrity Test: HMAC comparison failed
FIPS USER Space POST: Integrity test failed!
FIPS POST failed!
[date] <Emergency>: Boot task failed: fips
[date] <Emergency>: Shutting down in 3 seconds.

I am not sure what caused this problem - it was just after a system upgrade so something may have been borked in that. I reinstalled the OS and the problem was fixed.

The only reason I mentioned it here is because the cause was so difficult to find. The system just started to boot - and then powered off. No message at all. Most people don’t know about verbose-mode but even that wasn’t much help - the text went by very fast and disappeared. It was not until I was able to get an iPhone video of it that I could actually read it. I hope my technique may be of help to some people.

Lee Dronick

The FBI Director doesn’t trust his laptop camera and has the tape to prove it.


Log in to comment (TMO, Twitter or Facebook) or Register for a TMO account