Introduction to FIPS 140-2
FIPS 140-2 is a security standard developed by the governments of the USA and Canada to certificate IT products that implement cryptographic operations in order to protect sensitive or important information.
This IT products commonly named “Cryptographic modules” in the jargon of FIPS 140-2, must be validated by the Cryptographic Module Validation Program (CMVP), which verifies that they comply with the FIPS 140-2 security requirements at the same time that verifies that the cryptographic algorithms implemented by the module comply with the Cryptographic Algorithm Validation Program (CAVP).
Which pitfalls concerns to FIPS 140-2?
When manufacturers want to certify an IT product to be FIPS 140-2 compliant, the first problem they encounter is that they must develop a product which complies with the 11 areas related to its own the design and implementation, implementing at the same time, at least one cryptographic algorithm approved by the standard.
As if it were not enough to have to develop a product according to the standard, the manufacturer must generate the required documentation to be able to face the CMVP and the CAVP successfully, depending on the security level to be complied by the module.
In our experience, the doubts experimented by the manufacturers in the most cases, result in long delays in the module development and certification, even making the certification impossible in some cases. Some of the most common doubts are:
- What is the security level that the module must comply with?
- What hardware/software components are part of the cryptographic boundary?
- What are the approved, non-approved and affirmed cryptographic operations?
- What do the user and crypto officer roles imply? What is the authentication method to be used? What are the services accessible by each role?
- What are the required states to be implemented by the Finite State Model (FSM)?
- Does the module need to implement any physical security measure?
- Does the module need to pass the EMI/EMC and obtain and FCC-ID?
- What type of operations must the module to implement? What type of attacks should the module mitigate?
How to dispel the pitfalls?
Because of the specific language and the particularities of the concepts specified by the standard, in jtsec we are aware of the great effort required to face the FIPS 140-2 certification process for the first time and, in addition, of what means to do so without guarantees of ever obtaining the certification.
As FIPS 140-2 consultants, our two main premises are, on the first place, do get the product certified as soon as possible and, on the second place, to do it in a way that makes the process as simple and easy as possible for the manufacturer.
For this purpose, besides generating all the required documentation for the certification, our aim is to address all doubts and difficulties encountered when facing the standard for the first time, giving a more tangible and clear sense to all the technicalities and concepts of the standard, and helping the manufacturer to define the appropriate design for its module.
This way, our team accompanies the manufacturer during the whole process of designing the module, starting by identifying the level of security that it must comply with, which of its parts belong within the boundary, what services it will offer to every user role and what states the finite state model have in accordance to the cryptographic operations that are to be implemented.
Once the security level is set, the next relevant aspect is to clarify what cryptographic operations will be implemented in the module, in order to identify all the Critical Security Parameters (CSPs) depending on whether the module implements symmetric and asymmetric key generation, signature generation and verification key, Random Number Generation (RNG), etc., as identifying which are these parameters and for what are the used by the module, it will be possible to define what parts of hardware/software compose the cryptographic boundary and what parts are excluded from it. This step is particularly relevant because it allows us to define all the cryptographic data input/output interfaces or control input and status output interfaces, thus being able to establish the flow that the information follows through the module.
Concerning the user roles, the difficulty relies on defining the services related to each of them and authenticating them, considering that in many situations the modules are not able to implement an authentication system or in case of implementing it, know if it is an authentication system accepted by FIPS 140-2.
Depending on the defined user roles and the implemented cryptographic operations, the states that compose the Finite State Model (FSM) will be defined in conjunction with the transitions between them, considering some particularities like the module not being able to operate or output cryptographic data until the power-up self-test is successfully passed. Moreover, it must provide a method to verify the module state whenever the user wants and a method to execute the power-up self-test on demand.
Regarding the self-tests, it is necessary to consider if the module only needs to perform the power-up self-test or if it also needs to perform the conditional self-tests, depending on if it supports cryptographic operations based on public private keys, if it implements bypass, firmware/software updates or manual key entry. It is important to consider that during the power-up self-test the module must perform tests to verify the correct operation of the cryptographic algorithms and that depending on the module specifications, it will also be necessary to carry out an integrity test of the firmware/software contained within the module.
The FIPS 140-2 standard considers the necessity of incorporating physical protections, which can vary from applying a simple polymer to hardware components, to contain the module inside covers with possible interfaces and access openings that have anti-tampering measures. In the same way, in some case it is also necessary to perform the EMI/EMC test to obtain the FCC-ID, as well as test under extreme conditions of power and temperature to verify the correct operation of the module depending on its security level.
Finally, is very important to define the processes related to the key management as the generation, establishment, import and zeroization keys processes performed by the cryptographic module to ensure that there are no unwanted disclosures of information related to the CSPS as a result of an inappropriate management.
Facing the certification
When facing the certification, the manufactures have the option to try by themselves or counting with the assistance of jtsec.
In case of trying it by themselves, as seen above, it usually leads to delays in deadlines, increasing costs and, in some cases, not even passing certification, ending up in a labyrinth with no way out in terms of product development and obtaining the certificate. It is not uncommon for us to have to rescue blocked projects because of incorrect decisions.
However, in case of contracting our assistance from the beginning, the manufacturer ensures that the product can be designed in compliance with the standard, as well as the development of the needed documentation in the shortest time, optimizing cost and obtaining better offers in negotiation with the laboratories, and also, obtaining the competitive advantage of passing the certification successfully.
