National Institute of Standards and Technology

Implementation Guidance for FIPS PUB 140-1, continued

PART 4 (sections 8-11)

Go to:

• Part 1 (Overview/General)
• Part 2 (sections 1-4)
• Part 5 (expired guidance)

Section 8 - Cryptographic Key Management

8.1 List of FIPS-approved key management methods

Question/Problem

Resolution

• Key generation:
  • Note: Whenever a module generates a key to be used with a FIPS-approved algorithm (e.g., for generating/verifying a signature, encrypting another key, encrypting data, etc.), then that key shall be generated using one of the methods listed below.

  • Pseudorandom number generation:
    • ANSI X9.17, Financial Institution Key Management (Wholesale), Appendix C (referred to by FIPS 171, Key Management Using ANSI X9.17);
    • FIPS 186, Digital Signature Standard (DSS), Appendix 3.1;
    • FIPS 186, Appendix 3.2.

  • Random number generation: Currently, there is no FIPS-approved random number generator. However, FIPS 186 allows for such a random number generator to be used in generating values for x and k (provided that in the future there exists a FIPS for random number generation - 10/29/97).

    (10/29/97)
    For key generation, FIPS 186 specifically states in Appendix 3 that "They (keys) shall be generated by the techniques given in this appendix, or using other FIPS approved security methods." This applies to the generation of any key used by a FIPS-approved algorithm, within a FIPS 140-1 cryptomodule. It is acceptable for the output of a random number generator to generate a seed value for one of the FIPS-approved pseudorandom number generators listed above, in order to generate keys.

• Key distribution:
  • Secret key based:
    • FIPS 171, Key Management Using ANSI X9.17

  • Public key based: Currently, there is no FIPS-approved public-key based key distribution technique. Until such time as one is available, commercially available public key methods may be used.

Additional Comments

8.2 Using various public-key methods for key management/distribution

Question/Problem

Resolution

There are implementations of such methods which use a combination of a public-key algorithm and a hashing algorithm. In this case, the hashing algorithm used shall be a FIPS-approved hashing algorithm (e.g., FIPS 180-1, Secure Hash Standard (SHS)); use of a non-FIPS approved hashing algorithm in this situation would NOT be acceptable.

Additional Comments

8.3 Use of key loaders and its implications

Question/Problem

Resolution

The requirements for key entry at Levels 3 and 4 (requiring entry of encrypted keys or using split knowledge procedures) were specified to allow for environments where dual control of keys is desired. The implication is carried in the requirements that the cryptographic module must have the capability to support a key entry function that requires more than one user to have control during the key entry process.

Additional Comments

8.4 Use and testing of FIPS 171 key distribution techniques

Question/Problem

Resolution

1. The vendor provides the lab with written affirmation of compliance to FIPS 171. This affirmation shall include supporting statements which show how all 27 elements of FIPS 171 are addressed (particularly those X9.17 options which are specified as mandatory in FIPS 171), and shall identify exactly where these elements are addressed in the cryptomodule's source code. Some of the optional elements may in fact not be implemented - in that case, the vendor should indicate that these options are not implemented.

2. Based on the vendor's written affirmation, the lab shall verify that the FIPS 171 elements affirmed to be implemented in the cryptomodule actually correspond with elements listed in FIPS 171. In addition, the lab shall verify that the mandatory elements in FIPS 171 are addressed in the written affirmation. (e.g., Vendor affirmation states that "Key notarization is implemented as required in element #10 of FIPS 171, and it occurs within the 'notarize_key()' function in the 'key_mgmt.c' file. This function is called from the following places within the source code: . . ."; the lab also verifies that key notarization is required by FIPS 171.)

3. The lab then compares the cryptomodule code with the appropriate FIPS 171 element, referencing the appropriate specification in ANSI X9.17 as necessary. (e.g., The lab compares the key notarization implementation with steps listed in section 7.5 of ANSI X9.17 to verify that notarization is being done correctly.) This is intended to verify the correct implementation of the particular FIPS 171 requirement, and NOT the verification of all elements of ANSI X9.17. Verification by the lab is especially important for the 16 elements in FIPS 171 which are identified as "mandatory" or "forbidden".

Additional Comments

8.5 Initialization Vector (IV) requirements

Question/Problem

Resolution

IV Size: The required IV length for the various modes of DES, based on FIPS 74 and 81, is as follows:

IV Generation: There are several cases involving IV generation - one when the IV is generated externally, and then loaded into the module for use, and another when the IV is generated internally:

1. IVs generated outside a 140-1 cryptomodule:

   The randomness of externally generated IVs does not have to be checked by the module using that IV; however, the IV must be of the required minimum length for the appropriate DES mode (as indicated above).

   In addition, if the IV is to be used with DES in the OFB mode, then it is not acceptable for the IV to remain fixed for multiple encryptions, if the same key is used for those encryptions.

2. IVs generated inside a 140-1 cryptomodule:
   • IVs generated within a module shall be pseudorandomly or randomly generated.

   • IVs may be generated with a FIPS-approved pseudorandom number generator (PRNG) or random number generator (RNG) (see Guidance 8.1). In addition, FIPS 74 states that "The DES may be used as a pseudorandom number generator to generate the IV."

   In the case where a module generates IVs with a method that is non-FIPS approved, then the lab shall 1) inform NIST/CSE of this fact, and 2) be able to demonstrate that the IV generator is capable of generating random data. This shall be accomplished by running one or more of the statistical random number generator tests from section 4.11.1 of FIPS 140-1, as required under TE08.05.01.

   Any RNG or PRNG that is used to generate IVs shall fulfill all relevant requirements in FIPS 140-1, including the Continuous RNG self-test (AS11.22). There may be other applicable tests. For example, if level 3 or 4 is desired, then a statistical RNG/PRNG self-test must be implemented internally by the module (AS11.16).

Additional Comments

Section 9 - Cryptographic Algorithms

9.1 FIPS-approved algorithms

Question/Problem

Resolution

• Encryption (Secret-key based):
  • Data Encryption Algorithm, in FIPS 46-2, Data Encryption Standard (DES), using the various modes specified in FIPS 81, DES Modes of Operation.

  • Skipjack Algorithm, referred to in FIPS 185, Escrowed Encryption Standard (EES) and specified in the R21 Technical Report entitled "SKIPJACK" (S) (R21-TECH-044-91), using the modes specified in FIPS 81.

• Electronic signatures (Secret-key based):
  • Data Authentication Algorithm (a.k.a., Message Authentication Code (MAC)), in FIPS 113, Computer Data Authentication.

• Digital signatures (Public-key based):
  • Digital Signature Algorithm (DSA), specified in FIPS 186, Digital Signature Standard (DSS).

• Hash (message digest) generation:
  • Secure Hash Algorithm (SHA-1), in FIPS 180-1 (SHS).

Additional Comments

9.2 Cryptomodule with no FIPS-approved algorithms cannot be validated

Question/Problem

Resolution

Additional Comments

9.3 SHA-1 granularity

Question/Problem

Resolution

If an SHA-1 implementation successfully passes SHA-1 validation tests for byte-oriented messages only, then the SHS Validation Certificate shall indicate that the implementation has been validated only for the hashing of byte-ordered data.

Additional Comments

9.4 Triple DES implementation within a 140-1 cryptomodule

Question/Problem

Resolution

1. the DES engine(s) used within the Triple DES implementation must be validated as conforming to FIPS 46-2/81 as appropriate; and

2. it must implement one or more of the following modes of Triple DES (a.k.a. TDEA) listed in draft American National Standard X9.52, "Triple Data Encryption Algorithm" in section 3.3:
   1. TDEA Electronic Codebook Mode (TECB);

   2. TDEA Cipher Block Chaining Mode (TCBC);

   3. TDEA Cipher Block Chaining Mode - Interleaved (TCBC-I);

   4. TDEA Cipher Feedback Mode (TCFB);

   5. TDEA Cipher Feedback Mode - Pipelined (TCFB-P);

   6. TDEA Output Feedback Mode (TOFB);

   7. TDEA Output Feedback Mode - Pipelined (TOFB-P);

   * Note that modes 8) TDEA Cipher Block Chaining with Output Feedback Masking (TCBCM) and 9) TDEA Cipher Block Chaining with Output Feedback Masking - Interleaved (TCBCM-I) will NOT be recognized as being FIPS 140-1 compliant.

Additional Comments

Section 10 - Electromagnetic Interference / Electromagnetic Compatibility (EMI/EMC)

10.1 FCC Testing and Certification Requirements

Question/Problem

Resolution

1. radio receivers, and
2. personal computers and peripherals designated for
   1. business use (Class A), and
   2. home use (Class B)

This information was accurate at the time that this guidance was issued, and may change in the future as a result of FCC requirements changes.

[Part 15 applies to non-intentional emitters and low power transmitters. Low power transmitters (eg., garage door openers, <1W spread spectrum devices, and keyless entry systems) can achieve compliance with FCC requirements under Part 15.

(Subpart J does not apply to non-intentional radiators - this was changed in 1992. Non-intentional emitter requirements now reside in Subpart B of FCC Part 15.)

High power radio transmitters, and transmitters providing certain classes of service (eg., land mobile, business use, etc.) must be "Type Accepted" according to the appropriate Rule Part, which is based on the designated band and service that the transmitter is to be used.]

*Note that these are procedures that the vendor should have already taken with an FCC-approved lab - these are not new requirements for CMT labs. In each of the cases below, information is listed which a CMT lab shall require from a vendor. The information provided to the CMT lab shall be reflected in the 140-1 validation report.

1. Radios (both transmitters and receivers)
   • FCC Procedures:
     1. A "listed" lab tests a device for conformance to FCC requirements. ("Listed" means that the FCC has determined that a lab meets certain FCC criteria based on a filing of site description and site performance data--it does not imply accreditation by the FCC.)
     2. The lab issues a test report, and either the lab or vendor submits that report to the FCC, along with a formal Application for "Certification", "Notification" or "Type Acceptance", as required by the type of device. The applicant submits a proposed FCC ID Number which is composed of the combination of an FCC Grantee Code prefix (a 3 alpha-character code assigned by the FCC) and a number of discretionary suffix digits that are the choice of the applicant.
     3. If all is in order, the FCC Grants an Equipment Authorization; the vendor can then legally sell the equipment. The FCC ID number must be applied to the equipment with appropriate warning statements on the label and in the user's manual.

   • ***CMT Lab Procedures (applicable to AS10.01):
     
     • The CMT lab shall request the FCC ID number from the cryptomodule vendor.

2. Personal Computers and Peripheral Equipment: non-intentional emitters (Class A - business use)
   • FCC Procedures:
     1. A facility with equipment and a site that satisfies the FCC's requirements tests a device for conformance to FCC requirements.
     2. The lab issues a test report to the vendor.
     3. The vendor then puts a sticker bearing the proper warning statement on its equipment. However, this sticker does NOT bear an FCC ID number, since no such number is issued.

   • ***CMT Lab Procedures (applicable to AS10.02):
     • The CMT lab shall request the following information from the cryptomodule vendor:
       1. the name of FCC testing laboratory,
       2. the ID# of lab's test report, and
       3. the test report date.

3. PCs and Peripherals (Class B - home use)
   There are two types of procedures approved by the FCC which may be used by a vendor with a Class B product:
   • FCC Procedure #1:
     • Procedure 1 is basically identical to the procedure used for radio equipment described in section I above.

   • ***CMT Lab Procedures (applicable to AS10.03):
     • The CMT lab shall request the FCC ID Number from the cryptomodule vendor.

     ---

   • FCC Procedure #2:
     • Procedure 2 (a.k.a. "Declaration of Conformity", adopted by the FCC on May 9, 1996, and announced in the FCC's Report and Order, "FCC-96-208"):
       1. An accredited lab (accredited by either NVLAP or A2LA to do FCC testing for Part 15) tests a device for conformance to FCC requirements, and issues a test report to the vendor.
       2. The vendor then makes a "Declaration of Conformity" (DoC). This document is kept on file by the vendor - it is not filed with the FCC, but it is a releasable document.
       3. The vendor places a label on the equipment with the FCC logo and appropriate warning statement.

   • ***CMT Lab Procedures (applicable to AS10.03):
     • The CMT lab shall request a copy of the DoC from the vendor, and identify this in the 140-1 validation report.

Additional Comments

• In order to obtain the proper information from the cryptomodule vendor, it is suggested that the CMT lab ask the vendor to "provide the status of FCC approval, and whether it is Class A or Class B (if it's a PC or peripheral)"

• The list of NVLAP-accredited FCC testing laboratories can be found here.

  Note that the FCC also uses laboratories accredited by other bodies, including the American Association for Laboratory Accreditation (A2LA). The A2LA home page, with a list of their accredited laboratories, is located here.

Section 11 - Self-Tests

11.1 Performing power-up and conditional self-tests

Question/Problem

Resolution

Additional Comments

11.2 Known answer test for DSA

Question/Problem

Resolution

For the DSA known answer test, requiring an implementation to fix the k value for self-testing purposes may pose a greater risk than not implementing a known answer test at all, plus it contradicts the requirement in FIPS 186 quoted above. Thus, it is acceptable for a cryptomodule to not implement a DSA KAT.

HOWEVER, if a DSA KAT is not implemented, then there MUST be a pairwise consistency test for the DSA algorithm (see AS11.19). This test checks to see that signatures generated by the cryptomodule are verifiable, and it shall be implemented on each DSA key pair.

Additional Comments

11.3 Control of firmware or software loads

Question/Problem

Resolution

However, if the cryptomodule manufacturer wishes to continue labeling products as complying with FIPS 140-1, then the manufacturer must continue to use a validated version of the cryptographic module software/firmware. Therefore, the manufacturer's responsibility includes ensuring that additional software/firmware is validated before loading it into the cryptomodule. If the manufacturer provides another entity with the signature key, then the manufacturer must ensure that the signer of the software is acting on the manufacturer's behalf. Normally, the manufacturer would sign the software before it was sent to the laboratory for validation testing. Once validated, the signed software could be loaded by any designated party.

Additional Comments

11.4 Error Detection Code (EDC) requirements

Question/Problem

Resolution

The intent of TE11.14.01 is to have the tester verify which of two types of techniques, 1) a non-FIPS approved EDC or 2) a DAC, is used to verify the integrity of the software. Pursuant to the results of TE11.14.01, if the tester determines that an EDC is used, then test TE11.14.02 is to be performed; if a DAC is used, than test TE11.14.03 is to be performed. Test TE11.14.01 fails if the tester is unable to determine what authentication technique, if any, is being used to verify the integrity of the firmware or software.

Therefore, TE11.14.01 does not require the EDC to be FIPS-approved. A known technique such as the CRC may be used (or other common non-cryptographic firmware verification techniques); in which case TE11.14.02 applies if the tester can determine that this is the technique used. However, if a DAC is used that contains cryptographic operations such as hashing to a known value, a MAC, or a digital signature, then a FIPS-approved algorithm must be used (e.g., DSA), and either TE11.14.03 or TE11.14.04 is applicable.

Additional Comments