ICMC15: How Not To Do a FIPS 140 Project

Steve Weingart, Manager of Public Sector Certifications, Aruba Networks; Chris Keenan, Evaluator, Gossamer Security Solutions

Surprise! Not only will our speakers tell us how *not* to do FIPS, but as an added bonus, they will tell us the right way to do it.

There are a lot of ways to FIPS wrong  - this will make things harder and more expensive.

FIPS requirements are precise, the requirements are not soft - you can't just dive into a validation without planning.  No matter who you are or what your module is going to be, you will have to meet all of the requirements to get your validation. Yes, they are confusing, but they are still mandatory.

How can you read the standard? It will put you to sleep - true, but there is critical information in there.

"Crypto design really is rocket science" :-)

Where are your keys? Are they stored correctly? Are they deleted properly?

You simply cannot design and develop your product and do FIPS later. Once you're validated, you are set  - and you might find that the changes you make to pass validation will not work with older versions.  You can't add FIPS 140-2 like a coat of paint, it has to be designed with FIPS 140-2 in mind. [Note: You can do so... it's just painful and slow. :-)]

Why should you engage a lab before you start testing? They will help prevent you from making mistakes that everyone makes.  And you will have to show them your code and schematics.  Think of them as a partner.

Bigger is better, right? You want the highest security level, right?!?  Um... do you know what it means to do a formal model for your code?  So, maybe level 4 is not appropriate. Keep in mind that most software modules cannot get above level 1, with some getting level 2 with special considerations.

Why do you need to document things after showing the lab your code? :Will anyone even read it? Yes - the lab and CMVP will, and it needs to be availalbel to your users.

Best practice is to write the security policy in step with your architecture diagram - really designed for FIPS - but honestly, nobody does this (but if you did, you'd be happier).

This is not a fast process - the queue is 3-6 months and sometimes a year long. That doesn't count the time for procesing, etc.

It's not usually okay to use the /dev/random frm the OS. [Note: what if the OS's RNG is validated?]

If you choose a higher security level, then you should count on having the materials you're using scrutinized. Even if you have a "non FIPS mode" - your basic device may still need to meet these requirements.

Step one - get your CAVP certificates. That means you have to use approved algorithms.  Now, if you have proprietary algs you don't need certificates, but they also won't be included in your CMVP validation. [NOTE: designing your own algs? do you have rocket scientists on your team?]

Your security policy document describes how the product meets the requirements of the FIPS standard. There are test requirements around this.  No getting around this.

Are all the labs the same?  Well... they are all accredited, but they all have strengths and weaknesses and areas they excel at.  Some labs prefer to test at their site, some at yours. Some need specific types of evidence, others don't. Some focus on software, others on hardware. It's about finding the right fit for you and your product.

Have we mentioned the best thing to do is to start early?

Question: what about transitions?  You could do your work early, and be ready to go... then new "guidance" comes out. Now, having a relationship with your lab, you should get this information early.

Implementation guidance is a living document. When NIST finds that the document doesn't have enough clarity, or the world has changed, or corrects mistakes in the standard. 

It doesn't happen often, but there are sometimes cases of guidance being applied retroactively - a big pain for those in the queue. You need to have management buy in and resources until you have your certificates.

Question: If you're the OS and you get your entropy generation approved, why can't use the OS RNG?  Answer: actually you can, as long as it's used in a compliant way that meets requirements in the security policy. That's "FIPS inside".

Question: You noted that guidance doesn't add new requirements, but that's not true. We need new RNG, and entropy estimation (never required before). NIST: we sometimes have to do this, because of security concerns (like in the case of entropy). There's always been a requirement on showing where you're getting your random source, so now there's a requirement for more evidence (that is a new requirement). NIST may not have checked that before, but the requirement was there.

Question: what if you're using someone else's chips, how do we provide source code? Commercially available hardware is exempt from this requirement. Now, if there is algorithm implementation in the chip, and it hasn't been algorithm testing - you might have to do this.

Question: How do you do advanced planning when the IG changes? Yeah, that happens. We hope it doesn't, but it does.

Question: If I use the OS's RNG and it's validated, can I use that as a random seed? Yes, but... can we still do this with the latest news about sun setting older RNG validations. Also, HOW you are using it is important.


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