Rycombe Consulting logo

FIPS 140-3 summary

In moving from FIPS 140-2 to FIPS 140-3, NIST has updated the standard to reflect changes in technology since the publication of FIPS 140-2.

FIPS 140-3 was announced on 12th January 2005. However, the publication of the draft revisions and its approval has not followed the original timeline. The final version will hopefully be published and approved sometime this year and then after Derived Test Requirements are published, the standard will become effective soon after and labs will be able to accept FIPS 140-3 validations.

Once FIPS 140-3 is effective, after a transition period, FIPS 140-2 will be retired and validation under FIPS 140-2 will end. However, that is still some time away and all validations commencing in the short term will be to FIPS 140-2.

Software requirements are given greater prominence in a new area dedicated to software security, and an area specifying requirements to protect against non-invasive attacks is provided. However, in practice, this will in most cases not require significant changes to be made to products that are compliant at FIPS 140-2.

Reference to Common Criteria and requirements for the use of Common Criteria certified operating systems has been dropped from the requirements and there is more emphasis on audit requirements through the operational environment requirements.

Major changes include the following:

The concept of a hybrid module has been formally added to the standard. A hybrid module is one whose cryptographic functionality is contained in software or firmware, which also includes some special purpose hardware within the cryptographic boundary of the module.

For module interfaces, an extra control output interface has been formalised and at level 3 and 4 the concept of a Trusted Channel has been added.

At level 4, two factor authentication of operators is now required (At least two of three: something known, something possessed, some physical property).

Physical security requirements have been added to counter non-invasive attacks at level 3 and level 4.

Design assurance requirements increase through the levels, so for example, at level 2 a functional specification is required and at level 3, a detailed design. Testing requirements have been introduced, with functional testing required at levels 1 and 2 and low-level testing required at level 3 and above.

New self-tests have been introduced. There is now the requirement for a pre-operational bypass test.

A software security section has been added to the requirements. These are summarised as follows:

The requirements are cumulative, with each subsequent level either augmenting or replacing the requirements of the previous level as appropriate.

Rycombe Consulting 1999-2015. All Rights Reserved.