ICMC: Introduction to FIPS-140-2

Presented by Steve Weingart, Cryptographic & Security Testing Laboratory Manager, at atsec information security.

While I'm not new to FIPS-140-2, but as I'm here in Gaithersberg, MD for the inaugural International Cryptographic Module Conference, it's always good to get a refresher from an expert.  Please note: these are my notes from this talk and should not be taken as gospel on the subject. If you need a FIPS-140 validation - you should probably engage a professional :-)

Since the passage of Federal Information Security Management Act (FISMA) of 2002, US  Federal Government can no longer waive FIPS requirements. Vendors just simply need to comply to various FIPS standards, including FIPS-140-2 (the FIPS standard that is relevant to cryptography and security modules).  Financial institutions and others that care about third party evaluations also want to see this standard implemented.

Technically, a non-compliant agency could lose their funding.

FIPS-140 is a joint program between US NIST and Canadian CSEC (aka CSE).

All testing for FIPS-140 is done by accredited labs (accredited by National Voluntary Laboratory Scheme).  Labs, though, cannot perform consulting on the design of the cryptographic module. Could be seen as a conflict of interest, if they were seen as designing and testing the same module.  They can use content you provide to make your Security Policy and Finite State Machine (FSM), as those documents have to be in a very specific format that individual vendors will likely have trouble creating them their first time out.

A cryptograpic module is defined by its security functionality, well-defined boundaries and have at least one approved security function.  A module can be contained in hardware, software, firmware, software-hybrid, firmware-hybrid.

Security functionality can be: symmetric/asymmetric key cryptography, hashing, message authentication, RNG, or key management.

The testing lab makes sure that you've implemented the approved security functions correctly to protect sensitive information, makes sure you cannot change the module after it's been validated (integrity requirement), and that you prevent unauthorized use of the module.

Your users need to be able to query the module to see if it is performing correctly and to see the operational state it is in.

FIPS-140 has been around, originally as Federal Standard 1027, since about 1982.  Of course, as technology changes, the standard gets out of date.  FIPS-140-2 came out in 2001 with some change notices in 2002.  FIPS-140-3 has had many false starts.  A large quantity of implementation guidance has come  out (the IG is approaching, if not overtaking, the size of the initial FIPS-140-2 document).

Some brief clarifications: the -<number> on the standard refers to the version.  The first was FIPS-140, next FIPS-140-1, and the final currently adopted one is FIPS-140-2.

Each of those versions have levels that you can be evaluated at. Level one is the "easiest", level four is the hardest (available to hardware only).

FIPS-140-3 has had two rounds of public drafts, there were over 1200 comments, but it seems there is just one person still working on this draft.  In addition, there are not any Derived Test Requirements (DTR) so the labs cannot even consider writing tests for the standard.

There are new versions of "FIPS-140-3" by ISO (19790)  (released in 2012), essentially competing with the NIST draft.  Though, the original goal was to have the ISO standard be the same document, just as an international standard.

Right now, you can validate against the ISO standard in other countries - not in the US or Canada, though.  If you used an international body to validate your module against the ISO standard, it would not get you through the door to US or Canadian Government customers.

It's up to NIST and CSEC to pick one of these, create transition guidance and testing information to let vendors and labs move forward.

ISO 19790 has many improvements, but if you implement them, you will not pass FIPS-140-2 testing. For example, ISO 19790 allows lazy POST (only testing when needed), but FIPS-140-2 requires POST of the entire boundary any time any part of the boundary is used.

FIPS-140-2 has four levels, and it doesn't matter if 99% of your module meets all of the items required for a higher level (like level 2) - but 1% only meets level 1, you cannot be validated at the higher level.

The ISO document doesn't point to specific EAL common criteria levels, helping to alleviate the chicken and the egg circular dependency for FIPS-140 levels. For example, FIPS-140-2 Level 2 requires a EAL validated OS underneath.  The EAL validation requires a FIPS-140-2 validated crypto module.

The finite state model means that you can only be in one state at one time. That means you cannot be generating key material at the same time you're performing cryptographic operations in another thread. This can be very difficult to accomplish with modern day multi-threaded programs - the labs that do the validation review source code, too, so no sneaking around them!

Mr. Weingart keeps reminding us that FIPS-140 is a validation, not an evaluation.

There are some good questions about how do things like OASIS KMIP interact with the requirements for FIPS-140-2 cryptographic key management requirements?  The general thought is they should harmonize, but KMIP doesn't seem to be referenced.

Around key generation, RNG and entropy generation is very important, and with the current news - this is being heavily scrutinized by NIST right now.  Simply using /dev/random (without knowing anything about its entropy sources) is not sufficient. Of course, when you're also the provider of /dev/random, you have a bit more knowledge. We should expect further guidance in this area.

Cryptographic modules have to complete power on self-tests (POSTs) to ensure that the module is functioning properly - no shortcuts allowed! (again, your code will be reviewed - shortcuts will be seen!).  There are also some conditional self-tests - tests run when a certain condition occur, for example, generating a key.

If any of these tests fail, you must not perform *any* cryptographic operations until the failure state has been cleared and all POSTs are rerun.  That is, even if your POSTS for SHA1 fail, you cannot even provide AES or ECC.

If you make any additional "extra credit" security claims, like "we protect against timing attacks", that either needs to be  verified by the lab, or a disclaimer needs to be placed in your security policy.

Implementation Guidance

There is a lot of new implementation guidance coming up, fast and furiously.

The most contentious one is the run Power on Self-Tests all the time (whether in FIPS mode or not). This can be problematic, particularly for something like a general purpose OS or smartcards. Things that may not have been designed for this, or that just don't have great performance capabilities (like smartcards) this can make your device or system unusable for customers that do not need FIPS-140 validated hardware/software.

IG G.14, for example, has some odd things on algorithms, like RSA4096 will be removed from approval, but RSA 2048 won't be. This seems to be related to performance issues, according to discussions in the room, but that seems a harsh punishment for perf issues.  Check SP800-31A for more details about what will and will not be allowable going forward.

Cryptographic Algorithm Validation Program

Any algorithms used in approved mode need to be validated to make sure they are operating correctly.  This step is required before you can submit to the CMVP  (Cryptographic Module Validation Program).  This is a very mechanical process - you have either passed the algorithm tests, or you haven't.  CAVP turn around to issue certificates for your algorithms is typically very quick, because there isn't wiggle room or room for interpretation.

You will work with labs (22 approved ones that are accredited currently) on this, and a consulting firm that will help you to work with the labs, work on your documentation, design, architecture, etc.  You can hire another lab as a consultant, just your lab cannot consult for you. (back to that they cannot test what they designed)

Preparing yourself for validation

Read FIPS-140-2, implementation guidance, SP-800s documentations, etc.

Take training, where available and possible.

Enlist help on your design and architecture as early as possible, get a readiness assessment.

You can do your algorithm testing early, find and fix problems early in your development.

Iterate as needed (if this is your first time, you'll almost certainly have to iterate to get this right).


This post syndicated from: Thoughts on security, beer, theater and biking!