D-kriptik Blog

So, this post is motivated by a couple of recent threads on FIPS 140. I have noticed that whenever FIPS 140 becomes a topic of a mailing list, blog post, or some other such forum, the discussion is generally one (or a combo) of the following. (It has been a long day, so hopefully this post is coherent enough.)

1. A vendor has been put at a competitive disadvantage because they do not have FIPS 140 validation. Perhaps their competitors have it. Perhaps a bid requires it. Whatever the case may be, they don’t have it, so now they want to tear it down.

   Also found here are people that just dislike FIPS 140 or, perhaps, standards in general.

2. A vendor has gone through the process, and it was quite painful. So, now they vent about all the changes they had to make, how silly particular requirements were, how incompetent the lab staff was, etc.
3. An expert tells stories of how the requirements are ambiguous and the labs all vary in how they interpret the requirements.

   Also found here (and often quite different from the previously described expert) are people that have run into FIPS a number of times over the years, which has caused them exposure to differing requirements without having seen the evolution of those changes.

So, I was thinking about what triggers these three bullets. What are some causes of excessive pain in going through a FIPS 140 validation? How ambiguous are the FIPS 140 requirements? Do the labs really vary much? My focus is bullet two, but lets discuss one and three first.

• I think one mainly stems from a vendor that is not willing, or just unable, to go through the FIPS process. Since FIPS 140-2 validation is ruled out by such a vendor, the only course of action is to question FIPS 140. Unfortunately for such vendors, attacking FIPS 140 does not change the fact these requirements are what the US government wants to see in cryptographic products it uses in sensitive but unclassified environments.

  As I wrote recently outside of public view,

  I assumed this as a given (in both the metzdowd crypto and dailydave threads), but perhaps it should be noted that FIPS 140-2 provides a baseline set of requirements for a cryptographic module to be used by the US government in sensitive but unclassified (SBU) environments. If a US government agency finds that it needs to secure information using cryptographic measures in an SBU environment, then it uses a product that meets this baseline to provide these cryptographic services.

  (Of course, others are free to adopt (portions of) these requirements as well, such as the financial or media communities. This sometimes happens outside of the US, but the cryptographic algorithms permitted are changed and perhaps things like FCC testing are omitted.)

  And, yes, the number one push for vendors to go through a FIPS 140-2 validation effort is a desire to sell to the US government. If you want your crypto product used in an SBU environment, then you have to meet the baseline security mandated for such an environment. Lots of people seem to complain about this, but it makes sense to me.

Moving along,

• I think three is mainly a means of spreading disinformation in order to drum up work for the author. There is not much else to say about that.

  However, three can also result from someone having seen smatterings of FIPS 140 over the years but not having the full picture of the evolution of FIPS 140, which I think includes many people that have a large amount of applied crypto experience. This may be an example of that.

  In addition I’ve heard of evaluations where the generator is required to use a monotonically increasing counter (clock value) as the seed, so you can’t just use the PRNG as a postprocessor for an entropy polling mechanism. Then again I know of some that have used it as exactly that without any problems.

  Breaking this short paragraph down in terms of FIPS 140 is not quite trivial, so lets take a look…

  • Under FIPS 140-1, IIRC (and it has been 6 or so years since I last looked at it), there were no explicit requirements around PRNG seeding. So, one could get away with using a clock as the seed to the PRNG. Most often, labs would point this out as a problem, but, without FIPS teeth, they could just recommend that a vendor change it, not require that they change it. While I have never heard of a lab recommending that a vendor use the system clock alone to seed the PRNG, it was possible under 140-1 for that to happen. (Requiring it, well, no.)
  • Under FIPS 140-2, this hole in the standard was fixed. Sure, it took interpretation of the key management requirements to translate to all FIPS-approved PRNGs that seed themselves internally having a seed that meets a baseline strength requirement, and that baseline seed strength requirement had to be translated into a set of entropy gathering techniques that the labs thought reasonable, but, that happened fairly quickly after the release of FIPS 140-2, and there are now standard techniques that all labs smile upon at this point. (And, no, the labs (and NIST/CSE) do not accept solely the system clock being used to seed a PRNG.)

  As you can see, two different versions of the FIPS 140 standard as well as many years of time were covered in the quoted couple of sentences.

And now the one I really wanted to discuss,

• I think two is the result of number of components, some of which break down as follows.
  1. Vendor misunderstanding of the FIPS 140 requirements and terminology.

     The FIPS 140-2 standard itself is fairly vague, but the language of the standard has been translated into a set of vendor requirements and testing requirements in a document known as the Derived Test Requirements (DTRs). If a vendor does not know about this document, they can make up all sorts of ways to meet the wording of the FIPS 140-2 standard that having nothing to do with the intent of the standard. Even using the DTRs, vendors can sometimes make mistakes. And, once a misunderstanding is made, the vendor may implement things that were not required by FIPS 140 and may even miss things that were.

     Also here are misunderstandings of terminology, which can quickly lead to things like the lab digging into parts of a product that normally would not need deep examination because the vendor implied FIPS 140 relevance through improper terminology. These misunderstandings can be damaging both in terms of inaccurate documentation as well as ineffective lab interactions.

  2. Vendor misinterpretation of lab (or NIST/CSE) questions and issues.

     I think that vendors often do not know what the lab is trying to get at when asking questions and can make changes that have nothing to do with the issue the lab is really trying to have addressed. This can lead to chains of events, such as, the lab raises an issue, the vendor makes a change, the lab riases the same issue, the vendor makes another change, the lab raises the same issue, the vendor makes another change, and the lab is finally happy. The vendor then feels that all those changes were required by FIPS, when perhaps just the last change was necessary to resolve the issue.

     Also here are difficulties that arise when a vendor says the wrong thing to the lab, tries to figured out what the lab is getting at and answer that instead of the lab’s question, or just writes long winded responses to lab questions/issues. You can easily say the wrong thing, and that will result in far more digging by the lab, even though it would not be warranted if the vendor response was more accurate in FIPS 140 terms.

  3. Labs can, and do, make requests and recommendations.

     Such suggested changes are not required by FIPS 140, but the labs feels they would be good for some other reason, such as security or usability. Sometimes vendors misinterpret these requests as required changes.

  4. New labs, new lab staff, new technologies, and new revisions of FIPS 140 (and related) standards can make for created requirements. (This is where you can find the most variation among labs.)

     A new lab or new lab staff might create issues that don’t really exist under the FIPS 140 requirements, as they themselves do not have much experience with FIPS 140. For example, software validations are the most common area of difficulty for new labs or lab staff. Software does not fit well into FIPS 140-2, and so you can hear ridiculous requests from new FIPS 140 people in this regard.

     New technologies and new FIPS 140 (and related) standards often require work to figure just how the FIPS 140 requirements are to be met. This results in quite difficult validations, and there really is not much to be done here except to grind through it. (With FIPS 140-3 coming down the pipe, this should be kept in mind.) For example, when FIPS 140-2 first came out, no one knew exactly how all of the new requirements were to be interpreted. Those first few validation were painful, drawn out, and basically test cases to solidify the standard. Another example, when IPsec VPNs first came out, FIPS 140-1 interpretations had to be established to meet bypass mode requirements. FIPS 140-2 did its best to pull these interpretations into FIPS 140, although this is one of the more ambiguous parts of 140-2.

All this can add up to extra work, more money, lots of frustration, and perhaps even tears. So, what can you do to avoid an agonizing FIPS 140-2 validation? It really boils down to knowing the requirements and the process.

If you are willing to bring in an outside FIPS 140 expert or have internal FIPS 140 expertise, then that is the best way to get through a validation. Experts know the requirements and the process, and can make validation as painless as it can be.

Without expertise, you can get started by building up a basic understanding of the FIPS 140-2 terminology, process, and requirements. The Cryptographic Module Validation Program (CMVP) website is the place to begin such research. Besides the FIPS 140-2 standard and, more importantly, the DTRs, there are documents like the annexes (A, B, C, D), implementation guidance (IGs), and frequently ask questions (FAQs) available. More so, there are lots of examples of Security Policies out there to help you see how other vendors navigated the requirements (at a high level, at least).

Your thoughts?

This entry was posted on Thursday, February 1st, 2007 at 4:13 am and is filed under Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.