Building OpenSSL with FIPS on Mac OSX 10.11

Question

1. Is it possible to build OpenSSL with FIPS on Mac OSX 10.11 ?

• I am trying to maintain compatibility with a number of other platforms that all use OpenSSL with FIPS.
• I know Apple strongly recommends using CommonCrypto and I believe this will work for most of my cross-platform compatibility needs using equivalent digest and encryption algorithms.
• This will take a lot of extra work and will deviate from the common framework that has been built which I would rather avoid.
• I am more interested in compatibility and a solution that will work than I am in the FIPS validation.

2. Is there a OpenSSL compatible DRBG (AES-256 with df) available under Mac OSX 10.11

• My understanding is that the DRGB under Common Crypto is AES-128

Answer 1

Is it possible to build OpenSSL with FIPS on Mac OSX 10.11 ?

Yes and No. Yes, you can build the FIPS Object Module and a FIPS Capable OpenSSL library (emphasis on build).

No because its not a validated platform. It looks like the only OS X validated platform is Apple OS X 10.7 on x86-64. See Section 3, COMPATIBLE PLATFORMS, in the User Guide for the OpenSSL FIPS Object Module v2.0.

---

Is there a OpenSSL compatible DRBG (AES-256 with df) available under Mac OS X 10.11

Yes, Apple has some validated DRBGs. See Apple's 1091 certificate and CTR_DRBG at NIST's DRBG Validation List. You also might be interested in NIST's Algorithm Validation Lists.

---

I know Apple strongly recommends using CommonCrypto ...

I think this means nothing. Apple produces CommonCrypto, of course they are going to recommend it!

What Apple does not tell you is they silently abandon OSes, Frameworks and Libraries. So once you roll something tied to their libraries, you will be vulnerable because they don't backport their fixes.

As an example, Apple never backported their ECDHE-ECDSA bug fix in SecureTransport, so there are problems in the field. As another example, Apple never backported CVE-2014-1266 SecrueTransport's Goto Fail fix, so there are problems in the field. As yet another example, it took Apple something like 3 years to fix Billion Laughs in their XML parser. As yet another example, Apple never fixed CVE-2015-1130 (Hidden Backdoor with Root), so there are problems in the field.

Apple is also infamous for releasing untested and substandard software.

Apple also withhold patches and fixes, and waits to provide them with their next latest-and-greatest OS press release.

So, I find the best course from an architecture and design point of view is to avoid Apple Frameworks and Libraries. This way, you can update your app and close security holes and bugs regardless of what Cupertino is doing. Users will enjoy your updated app regardless of Apple's actions or lack of actions.

Also see Mobile Development Architecture (Vendor Patching vs App Updates)? on OWASP's mobile security mailing list.