Cryptographic Equipment
Assessment Laboratory (CEAL)

FIPS 140-2 FAQ

Frequently Asked Questions about the Federal security requirements for Cryptographic Modules v2.0
[Copyright 2002, CygnaCom Solutions, Inc.]
  1. What are the government regulations on security products? (view)
  2. When do products have to be validated by? (view)
  3. Why should I get my product validated? (view)
  4. Canít I just get a waiver? (view)
  5. Who validates products for 140-2 compliance? (view)
  6. What do I have to do to get my product evaluated? (view)
  7. Isnít this for hardware only? (view)
  8. What "documentation" do I need? (view)
  9. Whatís a Finite State Machine? (view)
  10. What if I canít produce that kind of documentation? (view)
  11. Hey! All my information is proprietary. (view)
  12. Are you evaluating my competitorís product? (view)
  13. What are the different "levels" of security? (view)
  14. How much does an evaluation cost? (view)
  15. What happens if my product has a problem? (view)
  16. Will you test conformance of RSA? (view)
  17. Why FIPS 140-2? (view)
  18. When does FIPS 140-2 become a standard? (view)
  19. What is the deadline for FIPS 140-1? (view)
  20. Will validations against FIPS 140-1 still be valid? (view )
  21. What is the difference between FIPS 140-1 & FIPS 140-2? (view)
  22. How do I get more information? (view)
  23. May I distribute this FAQ? (view)

1. What are the government regulations on security products? (top)
The National Institute of Standards and Technology (NIST) has published the Federal Information Processing Standards (FIPS) Publication 140-2 to cover Security Requirements for Cryptographic Modules. This publication regulates what products Federal agencies may purchase that "use cryptographic-based security systems to protect unclassified information within computer and telecommunication systems." This means that anything (hardware or software) that uses encryption, or other crypto protection must meet FIPS 140-2 requirements before Federal clients are allowed to buy it.

You can review the actual FIPS 140-2 publication from NIST at http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf. For more information on the FIPS 140-2 process you can review the 140-2 related documents at http://csrc.nist.gov/groups/STM/index.html.

2. When do products have to be validated by? (top)
They must be validated before they can be sold to the US Government. FIPS 140-2 phased in validation requirements as follows:

Jan 31, 1997: The government must buy validated products.
Jan 31, 1996: Must buy products submitted for validation.
Jan 11, 1994: Need vendor-written letter of compliance.

Grandfather exceptions apply for Federal Standard 1027 and FIPS 140 compliant products only.

3. Why should I get my product validated? (top)
Four reasons:

The strongest reason: If you want to sell to Federal agencies, who require it, you have to get it.

Sometimes applicable: The validation program ensures that a product has been designed to meet accepted security guidelines, increasing the likelihood that its security is strong. This helps prevent subsequent costly redesigns to correct security design weaknesses.

Currently debatable: Consumer confidence in the security of products is often based on who says itís secure. The value of a stamp denoting compliance with strict government security requirements for cryptographic modules might soon become a marketplace discriminator. The value and recognition of FIPS 140-2 compliance is currently growing in the ever-expanding computer-security marketplace.

May soon be the case: The banking industry is planning to adopt exclusive use of FIPS 140-2 validated products. If this does happen, selling products to the banking industry as well as the Federal government will require validation.

4. Canít I just get a waiver? (top)
It is possible to get a waiver signed by the head of a federal agency, sent to the Committee on Government Operations of the House of Representatives and the Committee on Governmental Affairs of the Senate, published in the Federal Register, and published in the Commerce Business Daily. It is also possible to win the lottery. While the chances of winning the lottery are published, the chances of obtaining a waiver are currently unknown.

5. Who validates products for 140-2 compliance? (top)
NIST acting for the Department of Commerce issues 140-2 validations. (Actually, NIST acts in concert with the Canadian Communications Security Establishment (CSE) to jointly issue validation certificates.) NIST will only validate products that have been evaluated by a NVLAP accredited laboratory for FIPS 140-2 Overview. On July 31, 1995 two US laboratories were accredited to perform compliance testing (one of them is CygnaCom Solutionsí CEAL.) Since then, one other laboratory (in Canada) has been accredited. Information on the accreditation program along with lists of laboratories and validated products can be found at http://csrc.nist.gov/groups/STM/index.html.

6. What do I have to do to get my product evaluated? (top)
Submit your product and documentation to a NIST NVLAP accredited laboratory (such as CygnaCom Solutionsí CEAL) for evaluation. The Laboratory will analyzes the product documentation for compliance with 140-2 requirements. If the product is compliant, the test results can then be forwarded to NIST who will issue the validation.

The only real work to be done for submission to the laboratory is the gathering or writing of the appropriate documentation.

7. Isnít this for hardware only? (top)
No. The old Federal Standard 1027 and FIPS 140 dealt mostly with hardware. However, FIPS 140-2 covers both software and hardware implementations of encryption and other cryptographic technology for unclassified use. Specifically: "cryptographic-based security systems to protect unclassified information within computer and telecommunication systems (including voice systems) that are not subject to Section 2315 of Title 10, U.S. Code, or Section 3502(2) of Title 44, U.S. Code."

8. What "documentation" do I need? (top)
Documentation usually consists of a mix of some or all of the following: product descriptions, operating manuals, design documents, code listings, design specifications, blueprints, manufacturing designs, component specifications, third-party documentation, and third-party certifications and licenses. This documentation must give enough information to satisfy all the applicable categories of security requirements listed in FIPS 140-2, some of which are applicable to hardware, some to software, and some to both. These categories are: crypto module, module interfaces, roles & services, finite state machine, physical security, environmental failure protection, software security, operating system security, key management, cryptic algorithms, electro-magnetic interference, and self-tests. In addition, NIST requires that every vendor supply a non-proprietary security policy document with each validated module. A review of the FIPS PUB 140-2, the Derived Test Requirements, and the Implementation Guidance will clarify the applicability and requirements of each documentation category.

9. Whatís a Finite State Machine? (top)
Finite State Machine (FSM): a mathematical model of a sequential machine which is comprised of a finite set of states, a finite set of inputs, a finite set of outputs, a mapping from the sets of inputs and states in to the set of states (i.e., state transition), and a mapping from the sets of inputs and states onto the set of outputs (i.e., an output function).

An FSM is required for all validated products. A simplified example of an FSM is available for review at: http://www.cygnacom.com/labs/ceal_finite_state.htm.

10. What if I canít produce that kind of documentation? (top)
Many vendors are surprised to know that they already have produced most of the documentation they need. However, itís often buried in the project files, and usually isnít in a usable, presentable, or even legible format. The most economical production process is for the developers to write documentation that completely satisfies FIPS 140-2 requirements during the product design and development stages. (Unfortunately, this rarely happens.) Since most products are already developed, and the developers are committed to other projects, we understand that documentation production can be difficult and/or costly. The CEAL laboratory will, when requested, provide assistance in assembling, preparing, or writing the proper documentation.

11. Hey! All my information is proprietary. (top)
The CEAL laboratory at CygnaCom Solutions takes great care to properly handle vendor-proprietary information:

All laboratory staff sign legally binding non-disclosure agreements as required by each vendor.

All laboratory equipment, computers, files, notes, vendor supplied equipment, and vendor information is physically and procedurally secured.

All information pertinent to a vendor is physically and procedurally secured from release to other vendors.

Under special instances, portions of CEAL testing may be performed at vendor sites under vendor-controlled security arrangements. The CEAL Quality Manual and its sections detailing handling of vendor proprietary material are available for review by customers.

12. Are you evaluating my competitorís product? (top)
Because of the sensitive nature of product evaluations, the CEAL will not release any information on product evaluations to anyone. This includes competing vendors, Federal agencies, computer press, NIST, NSA, and CEAL and CygnaCom Solutions employees not involved in evaluating a product. It is up to each vendor whether to release information, and whether to submit laboratory results to NIST for validation. (The CEAL produces a report ready for submission to NIST, but the vendor exercises the option to submit it.) If you want competitors to know your product is being evaluated and how it is doing, you are, of course, free to tell them. We will decline to confirm it unless you inform us in writing that we may release that information.

13. What are the different "levels" of security? (top)
One, Two, Three, and Four. One reflects the least stringent security implementation, and four represents the highest level of security. Some common level discriminators include:

DOS and Windows software can only meet level 1 requirements.

Software running on multi-user operating systems must meet level two or higher (two requires C2, three requires B1, and four requires B2.)

Level two hardware must have locks or tamper evident seals. Level three and four hardware requires active tamper detection and response.

Level three and four modules must use encryption or split knowledge procedures for cryptographic key input.

14. How much does an evaluation cost? (top)
Cost of an evaluation varies with the target validation level for the product, completeness of documentation available, nature of the product (hardware vs. software, single vs. multi-function), previous analysis and evaluation of versions of the product, and validation timeline. If you provide the CEAL with a short product description (1-5 pages) and a target level, we would be happy to provide you a detailed written cost estimate. Please send or fax requests to:

CEAL Laboratory Manager
Suite 100 West
7927 Jones Branch Drive
McLean, VA 22102-3305
Fax: (703) 848-0985

15. What happens if my product has a problem? (top)
The goal of the validation process is to ensure that products are correctly designed. If any product under evaluation will not pass the requirements for validation CEAL staff will contact the vendor and discuss the shortfalls. The CEAL is committed to helping vendors get through the validation process and will explain the problems and probable solutions. The vendor can then provide additional documentation that addresses the discrepancies, agree to change the target level of the evaluation, temporarily halt the evaluation while minor product design changes are made, or discontinue the evaluation. Often resolution of minor problems will not disrupt the evaluation schedule or the total cost of the evaluation.

16. Will you test conformance of RSA? (top)
FIPS 140-2 requires that FIPS approved algorithms be used, and that those implementations be certified as conformant. The CEAL can perform conformance testing of cryptographic algorithms. For information on which cryptographic algorithms the CEAL will test, see http://www.cygnacom.com/labs/ceal_crypto.htm. FIPS 140-2 allows modules to provide non-FIPS approved algorithms as long as the FIPS-approved version is provided.

Hence, under the current FIPS, a module that implements RSA encryption must additionally provide either DES or SKIPJACK encryption. Only the DES and SKIPJACK implementations must be validated to meet FIPS 140-2 requirements. Since there currently is no FIPS covering key-exchange, a module may implement RSA for key exchange without being tested for conformance.

17. Why FIPS 140-2? (top)
There have been several changes taking place in the field of security. To better reflect these changes and to take advantages of new developments, NIST has come up with FIPS 140-2.

18. When does FIPS 140-2 become a standard? (top)
FIPS PUB 140-2 was signed on May 25 2001. NIST or CST will accept validation reports from the laboratories against EITHER FIPS 140-1 or FIPS 140-2 until May 25, 2002.

19. What is the deadline for FIPS 140-1? (top)
NIST or CST will accept validation reports from the laboratories until May 25, 2002.

20. Will validations against FIPS 140-1 still be valid? (top)
All the validations against FIPS 140-1 will still be valid and federal agencies can still continue buying FIPS 140-1 validated modules.

21. What is the difference between FIPS 140-1 and FIPS 140-2? (top)
In 1995 NIST established the CMVP that validates cryptographic modules to FIPS 140-1 standards. This standard is officially reexamined and reaffirmed every five years. Hence beginning May 2002 FIPS 140-1 has been revised to FIPS 140-2. The document at the below site gives an overview of the difference between the FIPS 140-1 and FIPS 140-2 http://csrc.nist.gov/publications/nistpubs/800-29/sp800-29.pdf

22. How do I get more information? (top)
You can review the FIPS 140-2 publication: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

You can review the NIST Cryptographic Module Validation Program web page (http://csrc.nist.gov/groups/STM/cavp/) that publishes FIPS 140-2 material such as lists of compliant products and accredited laboratories

You can contact the CEAL:
Tel: (703) 848-0883
Fax: (703) 848-0985
e-mail: ceal@cygnacom.com
web: http://www.cygnacom.com/labs/ceal.htm

You can submit a question via e-mail for inclusion in the FAQ. (Hint: submitting the request thousands of times to make it more frequent will not lower our response time.) Submit questions to ceal@cygnacom.com.

23. May I distribute this FAQ? (top)
Yes, if you observe the Copyright notice below. Otherwise, please contact us in writing to ask for permission to distribute this document.

[Copyright 2002, CygnaCom Solutions, Inc. This document (FIPS 140-2 FAQ: Frequently Asked Questions about the Federal security requirements for Cryptographic Modules v2.0) may be freely distributed provided it is distributed whole and intact including this Copyright notice. All other rights reserved. Please direct requests for any other duplication, quotation, excerpts or distribution to CygnaCom Solutions, Inc., Suite 5400, 7925 Jones Branch Drive, McLean, VA 22102-3378]

Contact Us

703-848-0883