ICMC15: Importance of Open Source to the Cryptographic Module Community

Chris Brych, Senior Principal Security Analyst, Oracle

Chris's talk will focus primarily on OpenSSL's history and potential future

The OpenSSL project has it's roots back to 1995 to the SSLeay project (Tim Hudson and Eric Young). In 1998, Tim and Eric joined RSA and started a new life and career in crypto development. There were still a lot of followers, Ben Laurie and Dr. Stephen Henson took over maintenance and changed the name to OpenSSL. In January 1999, 0.9.1 was released. Mostly maintained by volunteers. Today, we're at 1.0.2d.

There are 15 people around he world that work on OpenSSL, most are volunteers. There are 2 full time paid employees with plans to hire 2 m ore. No direct source of funding, they are relying on some private contributions and some donations.  Considering there are 7,098,576 web servers use OpenSSL (0.9.7 -> 1.0.2). This does not include application uses of OpenSSL, either, like routers.

In 2003 Steve Marquess, working for US DoD, embarked on a FIPS 140 project to validate a cryptographic toolkit derived from an OpenSSL distribution to get around exorbitant licensing fees from 3rd party toolkit vendors.  Needed a more cost effective solution.

There was a fork created in OpenSSL distribution to isolate the FIPS crypto into it's own distribution. There is a build process that is repeatable to build the exact same module that has already been validated. The hash was calculated over the fipscanister.o and verifying it with a hash published in the FIPS security Policy Document guaranteed that the same code that was validated could be used to build the FOM. Contiguous boundary created in memory that allowed for integrity checking.

This was based on the 0.9.7e distribution.  But, the DoD still wanted to make some changes to make it eve more secure.

The community saw value in someone else doing this work and started picking this up and then making contributions upstream to make it more secure.

Why use this? Well - it's free!  (subject to license restrictions).  If you're a small company, you can't afford the cost of 3rd party toolkits with FIPS support.

There's also low internal maintenance, because OpenSSL does it for you. Engineering can focus on new development features, new updates can be picked up and easily integrated and build on existing code base.

Since this was so widely accepted by many companies, many vendors stopped making their own crypto libraries. Many people, beyond the 15 core volunteers, contribute fixes.

There are disadvantages....

For example, if a bug has been publicly identified, it is out of your control - you have to wait for OpenSSL to create a fix.  You may need to wait on OpenSSL to re-certify itself, slowing down your business.  OpenSSL is not for everybody - the 80/20 rule applies here.

0.9.8 and 1.0.0 OpenSSL distributions will be EOL on December 31, 2015.  The FIPS Object Module version 1.2.4 (Cert #1051) will no longer be supported.

1.0.1 is EOL December 31, 2016 - so start thinking abou going to 1.0.2. FIPS Object Module cert #1747 is still supported by 1.0.2

But, 1.0.2 will only be around until December 31, 2019. Seems a long way out, but it will be here before we know  it. Then, we won't have anything to use #1747 with anymore.

NIST just published a draft of SPF 800-131A, r1 in July 2015, speifies non-compliant DH, ECDH and RSA in 2018.  the FIPS Object Module is not fully compliant with NIST SP 800-56A/B key agreemen. So only primitives testing for ECDH completed, KDF not tested. DH not tested as part of NIST SP 800-56A and RSA not compliant with SP 800-56B and OpenSSL does not plan to do this development.

1.1.0 is plan to be released in April/May 2016, which will include an API change. It will not be compatible with FOM 2.0.10.  That is, we lose our FIPS module!

This means that if organizations need FIPS and are now relying on OpenSSL, they will have to hire to complete this. Will have to make modifications of a code base containing over 500,000 lines of code - risky. What if they introduce other vulnerabilities?  Many vendors will have an OpenSSL validation - but they won't be the same. Confusing for end users.

Money won't solve the problem. OpenSSL is not interested, even if some vendor offered them money.

How can we solve this? if you're interested, please participate in the CMUF. We will have to get input from CMVP and the US Government needs to be involved.

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!