ICMC15: FIPS is FIPS, Real World is Real World and Never the Twain Shall Meet?

Ashit Vora, Co-Founder and Laboratory Director, Acumen Security

Ashit's journey has taken him from a Lab, then to a Vendor, and now back to a Lab.  He's seen the experience from both sides.  He's been working with FIPS 140-2 since 2003. The world has changed greatly since then, but the standard has not.

FIPS 140-2 has been approved since May 2001. It was very hardware focused, as that's what was common in the marketplace. There was only a small handful of approved algorithms.

There is a requirement that the standard is supposed to be updated every 5 years, so there was a draft of FIPS 140-3 in September 2005... a draft.  As of now, we *might* get FIPS 140-3 in May 2016, if it's delayed even a little bit it will turn into a long delay, as the standard has to be signed off by the Secretary of Department of Commerce - a political appointee, which will change when there is a new US President.

FIPS 140-2 is an open commercial project. The standard itself is 69 pages. Many vendors read that only and say, "I've read and understand the standard and we're ready!"  There are 127 pages of Derived Test Requirements, and 63 pages of implementation guidance.  IG was originally supposed to be an FAQ, but it has evolved to really be the new rules.

There are 287 requirements for FIPS, 50% of them are documentation requirements. More than 50% of the requirements are orthogonal to crypto.

OpenSSL has had 5 vulns in 2013, 22 in 2014 and 26 in 2015, but how many times has their FIPS module changed since 2013? Zero.

CMVP believes FIPS is a solutions, vendors think it's a means to an end (to sell to the government), and to the federal agencies it is merely a checkbox.

What is it really? A bit of everything and a bit of nothing. Ensures what is claimed has been implemented correctly - that's a good thing! At levels 1 and 2 little more assurance than the product implements crypto as per spec. FIPS validation does not mean the overall "cryptographic posture" of the system is secure.

The standard was developed with the best intentions, but it has not been able to change with our fast changing industry.  There have been a few improvements, like the changes for CRNG relaxation and possible relaxation on integrity checks.

COTS product - easy to buy a produce and open at your own leisure. Causes vendors to downgrade to level 1 or design prupose built "opacity shields". Tamper labels in a similar vein add nothing to security posture of the product. Products are rarely deployed with the opacity shields and tamper labels in place, they just don't fit on the rack. Plus, end users need to make modifications.

Real world: Key Management - possible to have a module FIPS validated w/out including key management at all. In fact MOST software libraries do not include key management.  This is a direct result of crypto boundaries shrinking!

Password requirements are rudimentary at best. No consideration for password complexity, frequency, etc.

Real World: OpenSSL. It is the MOST widely used cryptographic library in the world.  ost prevalent in networking products, but also showing up in IoT, etc. Many products gain FIPS compliance just by including OpenSSL.  That validation, however, does not cover TLS, key management - etc. Hence, the small boundary.

FCC/FSM and configuration management requirements do NOT add security.  The FSM (Finite State Machine) is almost always created AFTER the product is completed.

We have a test on software firmware load test, it checks that it's valid, but there is no root of trust.  A self signed cert gets you through this check.

Should follow the CC direction: use the standard as a base/toolkit and provide technology specific requirements (that map back to the standard).

Do not tie validations to specific versions. Allow for minor changes/bug fixes. Validations take a long time (12-18 months), but vendors tend to push fixes every month. Often very minor. Yes, there may be that one corner case where one vendor screws this up and makes a critical change - but why punish all vendors for one person's mistake?

Due to this, vendors are making VERY small boundaries, which means we're actually looking at a tiny portion of the security relevant system. Need to encourage larger boundaries, but that's only possible if engineers can fix small bugs.

Spend time on the most important sections: Section 1, Section 5 and Section 7.

Focus on key life cycle! Make those requirements more all-encompassing. Implementing crypto algorithms is easy (?!?), but key management is hard. [NOTE: it's all hard :-)]

Question what about making physical security optional?  Maybe, but it should be tied to the expected deployment environment. For example, a publicly accessible wifi access point might need to be more strict than a router buried in the bowels of a government building.

Randy Easter recommended just doing Level 1 for physical security, but Ashit noted that if they do everything else to Level 2 they will end up with a Level 1 overall validation. Randy noted that this is a matter of informing end customers - easier said than done!

Randy also wants to know how CMVP has relaxed rules w/out notifying the Secretary of Commerce?  Ashit noted that "that ship has sailed" with the Implementation Guidance.

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