This week Apple’s iOS received a FIPS 140 validation on the iOS CoreCrypto Kernel Module. Big congratulations to Apple! This has been in the process for well over two years, and I’m happy they got it done. I’m an enthusiastic user of their products both personally and professionally. I’m a shareholder as well. And as a product vendor with a cryptographic library focused on compliance, I’d be remiss if I didn’t address this latest news for our customers and our community.
So… what now? What does this mean for the community?
Apple can now more easily sell their hardware running iOS to the Federal Government. Obviously they haven’t had many problems in the past, but now they don’t have that familiar elephant in the room. I’ll be interested to see how their sales reflect this milestone.
For Apple End Users
We can take comfort in the fact that native iOS functions (like secure storage of unlock PINs) are now protected via a validated module. This is 100% positive and a great example of how validated cryptography benefits everyone, from your grandmother who can barely operate her iPhone, all the way to most tech savvy iPad power user. If it needs to be secure, then protect it with a validated module. Anything less is subject to scrutiny.
For App Developers
Here’s where it gets interesting. App developers that are calling native iOS for crypto functions are now calling a validated module (well, for iOS 6 anyway). This is good. But does this give you the compliance checkmark you need? Doubtful.
Case in point: Microsoft has a pile of FIPS 140 validations on Windows. Yet many of the software modules that achieve validation are from other vendors that are running on Windows machines. The fact that Microsoft has FIPS validation is irrelevant because these solutions (whether for device management or any other use) contain embedded cryptographic libraries and don’t call “native” crypto. Part of the reason is that end users, especially in the Federal space, need that FIPS 140 validation checkmark on the solutions they are procuring. It’s not enough for Symantec, McAfee, IBM, or anyone else to say, “we use CNG.SYS, so we meet FIPS.” No, they need an actual FIPS certificate in their name to close that sale. Unless the software controls its cryptography internally and it has been validated that way, it is arguably vulnerable. This is unacceptable to federal procurement officers and increasingly a point of contention in the private sector.
The same will apply here. Mobile platforms are simply a different form factor – it is still an operating system like Windows, and the standards for software running on iOS will be as stringent as they always have been. Symantec recognized this, and despite Apple’s ongoing validation efforts, Symantec App Center has FIPS 140 validation on their mobile piece because their customers demanded it (check out the second bullet point under Key Features).
Frankly, there is tremendous upside for us. Now more iOS devices will be in use with the federal government, creating more demand for apps and solutions that will still require FIPS validation on their own. App developers cannot rely on iOS crypto not to change, or to maintain certification. By using CryptoComply, app developers have the opportunity to control their crypto platform and provide the most secure solutions possible for these deployments. The cryptographic module is tightly coupled with your app, and you’ll have a common API between iOS and Android to ease development. Best of all, you can easily get a certificate in your name to knock down that big deal.
So basically, FIPS 140 validation for Apple’s iOS 6 is a big deal – it shows their commitment to security, and it demonstrates how important it is to validate encryption from top to bottom. But it is not a panacea. It doesn’t solve every challenge. In fact, it creates an increased need for further encryption validations as more devices are used in critically secure contexts. This is an important step for the mobile community, and I’m excited about what will come next.