ICMC15: Collateral Damage—Vendor and Customer Impact of Frequent Policy Changes

Joshua Brickman, Director, Security Evaluations, Oracle; Glenn Brunette, Senior Director and Chief Technologist, Cybersecurity, Oracle

Glenn started the talk.

Oracle is a big company, nearly 40 years old. Originally started with one products, but no has 1,000s of products with 400,000 customers across 145 countries.  This is a lot of variance, which makes doing FIPS 140-2 at Oracle a challenge.

Many of our products and delivered systems cannot change frequently, for example products used in medical trials.

Oracle has developed many products for FIPS 140: Solaris Cryptographic Framework, StorageTek, Java Cards, Acme Packet Session Border Controller, etc.  Also leverage third-party validated modules ("FIPS Inside") like RSA BSAFE Crypto J and OpenSSL.

It's not even simple when you talk about one product. For example, our Database interacts with several different crypto modules.

We do our best to educate our customers and internal developers, try to figure out how to compare apples and oranges and figure out operational decisions.

FIPS 140 can be easy to understand in one breath, and complicated to understand in the second. Is it approved or not?  Validated vs approved?  What modes and key lengths are you validated against?

We need to be more specific.  Marketing and product documentation might say: "We're FIPS validated! We're Encrypted" - but our customers want and need more details. Even saying a product uses AES may not be sufficient, as they need to know modes supported.

Module vs product validation.  Is "Oracle Weblogic" FIPS 140 validated?  What about Oracle Solaris? It could have multiple libraries and modules under the covers.

But, if you use "FIPS Inside" approach, you won't be listed on the CMVP website, so customer doubts vendor's sincerity.  Would be nice  if there was an official place to list folks leveraging FIPS Inside strategy.

Module versioning is not consistent with product versioning.  You can get away with very vague versioning schemes, makes it challenging for customers.

How do you map a product's cryptography to modules?  The big product, like an OS, may not validate every cryptographic module included in the system. Even if the OS vendor works really hard, they might only get 80%. How does your customer know if they are using one of the non validated uses cases?

Many times products do not ship with FIPS 140 on by default, so there is a challenge to even get it turned on. Then, customers layer products - particularly in the cloud space.

The NIST website can be very clear about when you should use FIPS, yet customers don't interpret this correctly. They may only be concerned with TLS, but actually using more.  They've sometimes done the horrible workaround to drop crypto, because they don't have a validated solution.  Some customers get this, others do not.

Lack of understanding at the customer site leads to a lot of problems. We need to plan for this when making future standards, so folks aren't taking the shortest path (which is usually the wrong approach).

Josh thinks there's a lot of hope, he sees progress coming around the corner.

It's clear that NIST/CMVP want the strongest crypto NOW for their customers. Vendors want the strongest crypto for their customers, with the least performance impact. Customers WANT this, but for a low price.

Remember the critical Shampoo algorithm: lather, rinse, repeat! This should apply to the CMVP process.

Vendors face big challenges, like: AES-GCM IV Generation.  In 2007 NIST issued SP 800-38D published, with two IG's.  In 2009 IG A.5 Key/IV pair uniqueness requirements  inside the physical boundary. In 2015 IG A.5 was overhauled, based on the discovery of 1 vendor's bad application that used all zeros for their IV - so we're all punished. Change came in August 2015, no grandfathering.

When we saw the new IG draft, we stopped all ongoing work to analyze the new IG. Oracle wrote up a proposal to mitigate the impact of the new IG while still meeting the spirit of the IG and sent it to CMVP.  Whiel waiting for a response, CMVP issued another IG. On August 5, still not responding to Oracle's comments, A.5 came out. How is that working with the vendors?

IG 7.15 published in August, again no grandfathering, and we found a project that got it's entropy from a 3rd party and we could not prove it.  the third party treated this as intellectual property, so they did not want to work with CMVP.  Oracle volunteered everything we did know to CMVP, and begged for a waiver. How do you build a business around that model?  Did everyone get a waiver?  Will our next project get a waiver?

How do we get out of that cycle?

Could form a technical community (CMUF working with CMVP). Take a page from NIAP and work together to solve problems. Take advantage of the fast resources of industry!  Create one for IGs, one for FIPS 140-4, etc.  Instead of throwing IG's over the wall, work together to come up with consensus.

We need time  to react - there MUST be time to transition. Every reactive response to IG is less time for industry to build product and fix bugs. [Note: by panicking to react, we may end up introducing worse issues.]

NIAP and NIST need to go back to being a partnership - see Entropy!

Negotiate with other crypto schemes to see if any mutual recognition can be negotiated.

We can do better by working together, so let's do that :-)

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