cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Community Insights

‎03-09-2015 10:21 AM

empower_banner.jpg

Reasons for Obtaining the FIPS 140-2 Validation

There are many reasons why a product requires FIPS 140-2 validation, and the compelling one is regulatory.  FIPS 140-2 evaluation is required for sale of products implementing cryptography to the Federal Government.   If you don't have a certificate or at least demonstrate a commitment to obtaining one, then there is a good chance that you won't be able to sell your product in this key market.

In addition, the financial community increasingly specifies FIPS 140-2 as a procurement requirement and is beginning to embrace it, wholly or in part in its own standards.

Other compelling reasons to obtain certification are that FIPS 140-2 can be viewed as a quality mark.  If you have FIPS 140-2 and your competition does not, then you may have a competitive advantage.

FIPS 140-2 Requirements

Documentation provided must include the following: Non-Proprietary Security Policy; Finite State Machine; Master Components List; Software/Firmware Module Descriptions; Source code listing for all software and firmware within cryptographic boundary; Description of module roles and services; Description of key management lifecycle; Algorithm Conformance Certificates; and FCC certificates for EMI/EMC compliance.

Many of these documents are probably produced during the normal product development lifecycle. However the Finite State Machine and Security Policy may be new to you. The Security Policy must be a separate releasable document that is retained by NIST, but all other documentation may be proprietary and submitted only to the testing laboratory.

FIPS 140-2 Levels

The different levels within the standard provide different levels of security, and in the higher levels, have different documentation requirements.  Each level successfively builds on the previous.

  • Level 1: The lowest level of security. No physical security mechanisms are required in the module beyond the requirement for production-grade equipment.
  • Level 2: Tamper evident physical security or pick resistant locks. Level 2 provides for role-based authentication. It allows software cryptography in multi-user timeshared systems when used in conjunction with a C2 or equivalent trusted operating system.
  • Level 3: Tamper resistant physical security. Level 3 provides for identity-based authentication.
  • Level 4: Physical security provides an envelope of protection around the cryptographic module. Also protects against fluctuations in the production environment.

FIPS 140-2 was signed on 22nd June 2001. The plan is to revise the standard every five years, and the third revision of 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. With the delay to its publication, an ISO standard (ISO/IEC 19790:2012) has been developed based around the draft of FIPS 140-3.

The current plan within NIST is to completely skip FIPS 140-3 and move to FIPS 140-4. This will essentially be a wrapper around the ISO standard. Currently there is no schedule published for the adoption of FIPS 140-4.

Here is a link to the NIST website for a copy of the FIPS 140-2 standard: latest copy of FIPS 140-2 (.pdf)

In the absence of a successor to FIPS 140-2, the criteria continue to evolve through additions to the CMVP's implementation guidance and Special Publications. A number of algorithms were depricated at the end of 2010, and there was also an increase in the minimum key length required for a number of algorithms, for example. These changes were announced in SP 800-131 A.

The validation landscape is constantly changing. To see how we can help you to negotiate it, please email DL-SYMC-FIPS-Support@symantec.com.

Links

  • NIST have all the necessary information. The FIPS 140-2 standard and related documents can be found through the following links:
  • NIST Cryptographic Validation Program. An Introduction to the Program.
  • FIPS PUB 140-2 The actual standard. Derived Test Requirements (DTR) for FIPS PUB 140-2. The DTRs take the requirements that are laid down in the standard and, as the name suggests, derive tests from them. These tests are then used to verify conformance of a product to the standard. Having such tests freely available allows a developer to easily check a product before submission.
  • Implementation Guidance for FIPS PUB 140-2. This document provides assistance in certain areas (such as how cryptographic algorithms are used or how diagnostic tests are performed) governed by international standards or long established precedence. Failure to heed this guidance can be costly.
  • FIPS 140-2 validated modules. If you require an off the shelf cryptographic module, this is the place to look.  There are a number of NVLAP-accredited Cryptographic Module Testing laboratories. The full list is available from the CMVP website.

Replacing SHA-1 with SHA-2 Certificates:

Please reference the below link for guidance in replacing/migration from SHA-1 to SHA-2 certificates: http://www.symantec.com/page.jsp?id=sha2-transition

Return to FIPS 140-2 Product Status

Return to Global Certification Management Office Program

Return to the Customer Trust Portal

0 Kudos