The Top 3 Mistakes When Starting a FIPS 140-2 Project
by Steve Weingart
1. Starting without the standard in mind
Probably the biggest problem causing issue in a FIPS 140-2 validation project is when the developer decides to ‘back into’ the standard after the fact. Trying to validate a product that was developed without being mapped to the standard is more difficult at the very least and has a potential for failure at the worst.
FIPS 140-2 has many specific system requirements including: self-test on start-up, where the integrity of the module has to be verified and all cryptographic functions have to be run against known answer tests to ensure correct operation. The entire lifecycle of the cryptographic keys has to be managed, from how they are created; to how they are used, transported, stored and ultimately how they are destroyed (or zeroized in FIPS 140-2 parlance). How random numbers for key creation are generated, how user authentication is performed and which cryptographic algorithms are used (and in what context), are also functions that have to be performed in a compliant manner.
When the developer comes to a validation test lab with a cryptographic module that is missing required components, or has implemented them in a non-compliant way, it always makes the validation process more difficult, more time consuming and ultimately more expensive for the developer.
The best time to start with the standard is when the design and architecture are first beginning. Reading the standard for the general overview, then really getting into the details of the Derived Test Requirements and Implementation Guidance documents (all available at the NIST Cryptographic Module Validation Program website) will get you started down the best path to a successfully validated FIPS 140-2 cryptographic module.
2. Being unaware of your responsibilities
As in #1 above, many customers come to test labs not knowing anything about their part in the validation process. Validation is a team effort. The developer must supply the lab with all of the required documents and artifacts for testing, but that is really only the beginning. It is the open support and cooperation - both ways - that allows the project to go smoothly and quickly. The relationship between the lab and the customer should not be adversarial. We are all on the same side. The goal is to get your product validated, but the lab has to meet that goal by assisting and guiding you in meeting every requirement. It is not the lab that issues the Certificate of Validation; it is issued by the CMVP (Cryptographic Module Validation Program) at NIST in the U.S., and the CSEC (Computer Security Establishment Canada) in Canada. Both of those agencies review the final test report and then usually ask the lab for clarification on several points, sometimes sending us back for some additional evidence, before issuing the certificate. So it is you and the lab working together to present your case to the program, and we really have to be a team.
The best way to set up for this teamwork is to choose your lab early in the development process. That way the lab can start to review your architecture and design early on, hopefully saving you from going down any non-compliant paths. The lab can also provide training on the FIPS 140-2 standard and its requirements, as well as perform a readiness assessment to go over your design in detail, before the formal validation process begins. Going down this path is probably the best way to make sure your validation experience is a good one.
3. Expecting a “rubber stamp”
After seeing the first two pitfalls above, this one may seem redundant, but unfortunately it’s not. Many folks never get it that receiving a Certificate of Validation for your product is not just a matter of paying some money, tossing some documentation over the fence and waiting for the Certificate to arrive. The FIPS 140-2 process entails documentation review, code review, testing of your product both in its normal state, as well as in induced error states and more testing to see if your security protection mechanisms work as claimed. This work is performed by highly trained engineers and each of these tests and reviews must be formally documented. The final report often runs 50+ pages and is what NIST and CSEC review. It is a serious process and it is backed up by months of serious work for each validation. As a customer, you definitely get a lot of work for your time and money.
I hope this gives a bit of insight into the FIPS 140-2 validation process and helps to prepare you and your product for an easier and successful path to a Certificate of Validation.
1. Starting without the standard in mind
Probably the biggest problem causing issue in a FIPS 140-2 validation project is when the developer decides to ‘back into’ the standard after the fact. Trying to validate a product that was developed without being mapped to the standard is more difficult at the very least and has a potential for failure at the worst.
FIPS 140-2 has many specific system requirements including: self-test on start-up, where the integrity of the module has to be verified and all cryptographic functions have to be run against known answer tests to ensure correct operation. The entire lifecycle of the cryptographic keys has to be managed, from how they are created; to how they are used, transported, stored and ultimately how they are destroyed (or zeroized in FIPS 140-2 parlance). How random numbers for key creation are generated, how user authentication is performed and which cryptographic algorithms are used (and in what context), are also functions that have to be performed in a compliant manner.
When the developer comes to a validation test lab with a cryptographic module that is missing required components, or has implemented them in a non-compliant way, it always makes the validation process more difficult, more time consuming and ultimately more expensive for the developer.
The best time to start with the standard is when the design and architecture are first beginning. Reading the standard for the general overview, then really getting into the details of the Derived Test Requirements and Implementation Guidance documents (all available at the NIST Cryptographic Module Validation Program website) will get you started down the best path to a successfully validated FIPS 140-2 cryptographic module.
2. Being unaware of your responsibilities
As in #1 above, many customers come to test labs not knowing anything about their part in the validation process. Validation is a team effort. The developer must supply the lab with all of the required documents and artifacts for testing, but that is really only the beginning. It is the open support and cooperation - both ways - that allows the project to go smoothly and quickly. The relationship between the lab and the customer should not be adversarial. We are all on the same side. The goal is to get your product validated, but the lab has to meet that goal by assisting and guiding you in meeting every requirement. It is not the lab that issues the Certificate of Validation; it is issued by the CMVP (Cryptographic Module Validation Program) at NIST in the U.S., and the CSEC (Computer Security Establishment Canada) in Canada. Both of those agencies review the final test report and then usually ask the lab for clarification on several points, sometimes sending us back for some additional evidence, before issuing the certificate. So it is you and the lab working together to present your case to the program, and we really have to be a team.
The best way to set up for this teamwork is to choose your lab early in the development process. That way the lab can start to review your architecture and design early on, hopefully saving you from going down any non-compliant paths. The lab can also provide training on the FIPS 140-2 standard and its requirements, as well as perform a readiness assessment to go over your design in detail, before the formal validation process begins. Going down this path is probably the best way to make sure your validation experience is a good one.
3. Expecting a “rubber stamp”
After seeing the first two pitfalls above, this one may seem redundant, but unfortunately it’s not. Many folks never get it that receiving a Certificate of Validation for your product is not just a matter of paying some money, tossing some documentation over the fence and waiting for the Certificate to arrive. The FIPS 140-2 process entails documentation review, code review, testing of your product both in its normal state, as well as in induced error states and more testing to see if your security protection mechanisms work as claimed. This work is performed by highly trained engineers and each of these tests and reviews must be formally documented. The final report often runs 50+ pages and is what NIST and CSEC review. It is a serious process and it is backed up by months of serious work for each validation. As a customer, you definitely get a lot of work for your time and money.
I hope this gives a bit of insight into the FIPS 140-2 validation process and helps to prepare you and your product for an easier and successful path to a Certificate of Validation.
I couldn't agree more. I would expand on ". . . choose your lab early in the development process. That way the lab can start to review your architecture and design early on. . . "
ReplyDeleteSteve implied, but didn't state explicitly that a limited investment up front for a design review can save many thousands of dollars in engineering rework and in additional reviews (of the reworked design).
This advice is right on. I would expect that from Steve since he was on the team that developed FIPS 140-1. These points should appear early on the Cryptographic Module Validation Program website.
ReplyDeleteMiles