Corporate Security Blog

FIPS: The Crypto "Catch 22"

Joshua Brickman
Director, Security Evaluations

Hello, Oracle blog reader! My name is Joshua Brickman and I run Oracle's Security Evaluations team (SECEVAL). At SECEVAL we are charged with shepherding certain Oracle products through security certifications and accreditations, mostly for government use. Today in my initial blog I'd like to talk to you about cryptography [1] (or crypto) as it relates to these government certifications.

First a little history; crypto actually goes back to classical Rome. The Caesar Cipher was used by the Roman military to pass messages during a battle. In World War II, Germany was very successful encrypting messages utilizing a machine known as "Enigma." But when Enigma's secret codes were famously broken (due mostly to procedural errors) it helped to turn the tide of the war. The main idea of crypto hasn't changed though: only allow intended recipients to understand a given message—to everyone else it's unintelligible [2].

Today's crypto is created by complex computer modules utilizing "algorithms." The funny thing about crypto is someone is always trying to break it — but usually using computers (also running complex programs). One of the U.S. government's approaches to combatting code breaking has been via the Federal Information Processing Standard (FIPS) program maintained by the National Institute of Standards and Technology (NIST). NIST uses FIPS to publish approved algorithms that software needs to correctly implement in order to claim their products meet the FIPS standard. The FIPS standard defines acceptable algorithms; vendors implement their crypto to meet them.

So why would technology vendors need to comply with this standard? Well FIPS "140-2" defines the acceptable algorithms and modules that can be procured by the US government. In fact NIST keeps a list of approved modules (implementations of algorithms) on their website. To get on this list of approved modules, vendors like Oracle must get their modules and algorithms validated. Unfortunately for many technology providers there isn't any alternative to FIPS 140-2 (version 2 of the current approved release) [3]. FIPS 140-2 is required by U.S. government law [4] if a vendor wants to do business with the government. The validation process is an expensive and time-consuming process. Vendors must hire a third-party lab to do the validation; most also hire consultants to write documentation that is required as a part of the process. The validation process for FIPS 140-2 requires that vendors prove they have implemented their crypto correctly against the approved algorithms. This proof is accomplished via these labs that validate each module is correctly implementing the selected algorithms.

FIPS 140-2 has also been adopted by banks and other financial services. If you think about it, this makes a lot of sense: there is nothing more sensitive than financial data and banks want assurances that the crypto they depend on to protect it is as trusted as the safes that protect the cash. Interestingly, smart-card manufacturers also require FIPS: this is not a government mandate, but rather a financial industry requirement to minimize their fraud rates (by making the cost for criminals to break the crypto in smart cards too high for them to bother). Finally the Canadian government partners with NIST on the FIPS 140-2 program known as the Cryptographic Module Validation Program (CMVP) and mirrors U.S. procurement requirements.

All of this would be the cost of doing business with the US (and Canadian) governments except that there are a couple of elements that are broken.

1. Government customers who buy crypto technology require a FIPS 140-2 certificate of validation (not a letter from a lab or being on a list of "under validation"). In our experience, a reasonable timeframe for a validation is a few months. Unfortunately, after all of the work is completed, the final "reports" (which lead to the certificates) go into a black hole otherwise known as the "In Review" status. This is when the vendor, lab (and consultant) have done as much work as possible but are now waiting for both the Canadian and US governments to review the case for validation. The queue (as I write this blog) has been as long as nine months over the last couple of years. An Oracle example was the Sun Crypto Accelerator (SCA) 6000 product. On January 14, 2013 our lab submitted the final FIPS 140-2 report for the SCA6000 to NIST. Seven months later, we heard back our first feedback on our case for validation. We finally received our certificate on September 11, 2013. NIST is quite aware of the delays [5]; they are considering several options including but not limited to increasing fees to pay for additional contractors, pushing more work to labs and/or revising their review process--but they haven't announced any changes that might resolve the issue other than minor fee increases. From our point of view, it's really difficult to justify the significant investments required for these validations when you can't predict their completion. If you think about the shelf life of technology these days, a delay of say a year in a two year "life-span" of a product reduces the value to the customer by 50%. As a vendor we have no control over that delay, and unless customers are willing to buy invalidated products (and they can't by law in the U.S.) they are forced to use older products that may be missing key new features.

2. NIST also refers to outdated requirements [6] under the Common Criteria. The FIPS 140-2 Standard references Common Criteria Evaluation Assurance Level (EAL) directly when discussing eligibility for the various FIPS levels [7]. However, due to current policies with the U.S. Scheme of the Common Criteria (National Information Assurance Partnership or NIAP), it is no longer possible to be evaluated at EAL3 or higher. This prevents any vendor from obtaining a FIPS 140-2 validation (of any software or firmware cryptographic module) at any level higher than Level 1. One example of an Oracle product that we would have validated higher than Level 1 is the Solaris Cryptographic Framework (SCF). Originally coded to be validated at FIPS Level 2, Oracle SCF was forced to drop its validation claim down to Level 1. This was because NIST's Implementation Guidance for FIPS 140-2 required that the Operating Systems be evaluated against a deprecated Common Criteria Protection Profile if vendors of crypto modules running on those OSs wanted the modules to be validated at Level 2. Unfortunately an older version of Solaris was Common Criteria evaluated against that deprecated Operating System Protection Profile. The version of SCF that we needed FIPS 140-2 validated didn't run on that old version of Solaris. Oracle had market demands that required a timely completion of its FIPS validation so a business decision was made to lower the bar. We've pointed out this contradiction (as I'm sure have other vendors) but at this writing the problem is still not resolved by NIST.

Oracle is committed to working with NIAP and NIST to make both Common Criteria and FIPS 140-2 as broadly accepted as possible. U.S. and Canadian government customers want to buy products that meet the high standards defined by FIPS 140-2, and that many other security-conscious customers recognize. Along with many other vendors of crypto modules in our products, Oracle is very keen to see NIST's queue of work brought down to a level that would allow the longest shelf life for our validations. We also would like to see NIST and NIAP work together to align their policies and interpretations of standards to provide greater selection of strong cryptography. These current obstacles are providing a reduced choice of FIPS 140-2 validated products. If removed, there will be a larger number of FIPS 140-2 validated crypto modules available for purchase. Increasing choice of validated products for the US and Canadian governments can only contribute to improved national security.


[1] According to Webopedia, "Cryptography is the art of protecting information by transforming it (encrypting it) into an unreadable format, called cipher text. Only those who possess a secret key can decipher (or decrypt) the message into plain text. Encrypted messages can sometimes be broken by cryptanalysis, also called code breaking, although modern cryptography techniques are virtually unbreakable."

[2] "FIPS 140 Demystified, An Introductory Guide for Developers," by Wesley Higaki and Ray Potter, ISBN-13: 978-1460990391, 2011.

[3] FIPS 140-3 has been in draft form for many years. NIST has been pulling key elements of the new standard and adding them to FIPS 140-2 as "Implementation Guidance."

[4] "Federal Information Processing Standards (FIPS) are approved by the Secretary of Commerce and issued by NIST in accordance with the Federal Information Security Management Act of 2002 (FISMA). FIPS are compulsory and binding for federal agencies. FISMA requires that federal agencies comply with these standards, and therefore, agencies may not waive their use."

[5] As noted in the summary of the recent first FIPS Conference, "...The current length of The Queue means that it can take developers many months to get their modules validated and hence available for procurement from federal agencies. In an increasing number of cases, products are obsolete or un-supported by the time the validation is finally documented. We heard how the unpredictability of The Queue is a problem too, since it greatly affects how developers can perform their marketing, sales and project planning."

[6] For example, http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

"Security Level 3 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system that meets the functional requirements specified in the PPs listed in Annex B with the additional functional requirement of a Trusted Path (FTP_TRP.1) and is evaluated at the CC evaluation assurance level EAL3 (or higher)."

[7] There are four levels of FIPS, at level "1" all components must be "production grade" and level 2 adds requirements for physical tamper-evidence and role-based authentication. Levels 3 and 4 are typically for hardware. -- http://en.wikipedia.org/wiki/FIPS_140

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.