VE 07KeyMgmt

This is a draft document

Key Management

1. The NSS cryptographic module uses secret keys (for symmetric key algorithms such as AES and Triple DES, and HMAC), public keys and private keys (for asymmetric key algorithms such as DSA, RSA, and ECDSA), and seed keys (for the Approved RNG). Its authentication data are passwords.
2. Our private key and certificate databases are hash (DBM) indexed flat files (regular files).
3. Private keys and secret keys are stored in the private key database. At Security Level 1, the operating system is restricted to a single operator mode of operation, which protects against unauthorized disclosure, modification, and substitution of the private keys and secret keys stored in the private key database. At Security Level 2, we use the discretionary access control mechanism of the operating system on the private key database to protect against unauthorized disclosure, modification, and substitution of the private keys and secret keys stored in the private key database.
   The private keys and secret keys stored in the private key database are password-encrypted using DES-EDE3 (Triple DES) to provide additional protection against unauthorized disclosure, modification, and substitution. The password-based encryption is considered by FIPS as in plaintext form.
   When the private keys and secret keys reside in memory, they are protected by the OS.
4. Public keys are stored in two ways.
   1. Public keys in public/private key pairs (owned by the operator) are stored as attributes of the associated private keys in the private key database.
   2. X.509 v3 certificates containing public keys are stored DER encoded in the certificate database. The certificates are not encrypted, but are digitally signed by the Certification Authority (CA) that created them.
   3. At Security Level 1, the operating system is restricted to a single operator mode of operation, which protects against unauthorized modification and substitution of the public keys and certificates stored in the private key and certificate databases. At Security Level 2, we use the discretionary access control mechanism of the operating system on the private key and certificate databases to protect against unauthorized modification and substitution of the public keys and certificates stored in the private key and certificate databases.
5. PKCS #12 (or previously known as PFX) defines a protocol for wrapping (encrypting) and unwrapping (decrypting) private key material and related certificates for import/export.
6. The exported private key is encrypted with a DES-EDE3 (Triple DES) key derived from a user provided password -- see PKCS #5 below.
7. No passwords (e.g., the export password for PKCS #12, or the private key database password) are stored on disk in plaintext.
8. PKCS #5 is used to convert a user's password to a DES-EDE3 (Triple DES) key that is used to encrypt a known plaintext to determine if it matches the password stored in the database, or in the case of exported private key.
9. Prior to exiting the Cryptographic Module, all passwords entered by users and private key (stored on disk) are zeroized from memory.
10. PKCS #12 can be used to archive a wrapped (encrypted) private key for recovery purposes.
11. Our use of DES and DES-EDE3, as called out in PKCS #12, are FIPS 46-3 validated.
12. The NSS cryptographic module's Triple DES implementation conforms to FIPS 46-3. ( TripleDES)
13. The NSS cryptographic module's SHA-1 implementation conforms to FIPS 180-2. See SHS.
14. The NSS cryptographic module's DSA implementation conforms to FIPS 186-2. (DSA)

Key Generation

The FC_GenerateKey and FC_GenerateKeyPair functions of the NSS cryptographic module perform key generation. FC_GenerateKey generates secret keys and domain parameters, and FC_GenerateKeyPair generates public/private key pairs.

Approved key generation method: The NSS cryptographic module uses the Approved RNG specified as Algorithm 1 of FIPS 186-2 Change Notice 1 to generate cryptographic keys used by the Approved and non-Approved security functions. The validation certificate for the Approved RNG is Cert# 208.

The prime numbers that are generated for both RSA and DSA are tested using Miller-Rabin test (FIPS 186-2 Appendix 2.1. A Probabilistic Primality Test).

Security of key generation method: The seed key of the Approved RNG is 256 bits. The keys generated by the NSS cryptographic module have at most 256 bits of security. (See NIST Special Publication (SP) 800-57 Part 1, Table 2 in Section 5.6.1 on page 63.) Therefore, compromising the security of the key generation method (e.g., guessing the seed value to initialize the Approved RNG) requires at least as many operations as determining the value of the generated key.

Key Establishment Techniques

The NSS cryptographic module uses the following asymmetric key establishment techniques listed in FIPS 140-2 Implementation Guidance Section 7.1, which FIPS 140-2 Annex D says are allowed in a FIPS Approved mode of operation:

• Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 112 bits of encryption strength). The module supports Diffie-Hellman public key sizes of 1024-2236 bits, corresponding to 80-112 bits of security.
• EC Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 256 bits of encryption strength). The module supports elliptic curve key sizes of 163-571 bits, corresponding to 80-256 bits of security.
• Key Wrapping using RSA keys (PKCS #1, key wrapping, key establishment methodology provides between 80 bits and 192 bits of encryption strength). The module supports RSA key sizes of 1024-8192 bits, corresponding to 80-192 bits of security. Note: The Cryptographic Algorithm Validation Program (CAVP) can only validate RSA key sizes up to 4096 bits, so our RSA algorithm implementation has only been validated for RSA key sizes of 1024-4096 bits.

The strengths of security of the asymmetric key establishment techniques are obtained from Table 2 of Section 5.6.1, NIST SP 800-57 Part 1.

The NSS cryptographic module does not implement the Over-The-Air-Rekeying (OTAR) Protocol.

Entity Association Assurance

The public and private keys are correlated based on Distinguished Name information contained in the public key certificate, or in the private key information fields. The X.500 standard describes how this correlation is accomplished.

Key Entry and Output Methods

The NSS cryptographic module does not employ either manual or electronic key entry and output methods.

The NSS cryptographic module does not support entry of the seed key during key generation.

The NSS cryptographic module uses automated key transport methods, so the cryptographic key being transported needs to meet the key entry/output requirements (in Section 4.7.4 of FIPS 140-2). Automated key transport methods use the FC_UnwrapKey and FC_WrapKey functions.

• The FC_UnwrapKey function enters an encrypted secret or private key into the NSS cryptographic module.
• The FC_WrapKey function outputs an encrypted secret or private key from the NSS cryptographic module.

For example, in a TLS handshake with RSA key exchange, the NSS SSL library (outside the cryptographic module boundary) calls FC_WrapKey to output the premaster secret (encrypted with the server's RSA public key) from the cryptographic module on the client side, sends it to the server in the ClientKeyExchange message, and calls FC_UnwrapKey to enter the RSA-encrypted premaster secret into the cryptographic module on the server side.

Encrypted secret and private keys, entered into or output from the NSS cryptographic module and used in the FIPS Approved mode of operation, are encrypted using one of the following Approved algorithms:

• Key Wrapping using RSA keys
• AES
• Triple DES

Note: If the AES or Triple DES key is derived from a password, the encrypted secret or private key is considered to be in plaintext form because password-based encryption is not FIPS Approved.

In the FIPS Approved mode of operation, secret and private keys established using automated methods (e.g., key transport protocols such as Key Wrapping using RSA keys) can only be entered into or output from the NSS cryptographic module in encrypted form (using FC_UnwrapKey and FC_WrapKey).

Random Number Generator

There are three random number generators (RNGs) used in the NSS cryptographic module.

The first RNG is the Standard C Library function rand() (declared in the header file <stdlib.h>). The rand() function is a non-Approved RNG and used within the NSS cryptographic module only for probabilistic algorithms such as the Miller-Rabin primality test.

The second RNG (on Unix and Unix-like platforms only) is the special device /dev/urandom. It is a non-Approved RNG and used only once during the library initialization of the NSS cryptographic module for generating (1024 bytes) seeds for the Approved RNG, described next.

The third RNG is an Approved RNG, implementing Algorithm 1 of FIPS 186-2 Change Notice 1. The Approved RNG is used within the NSS cryptographic module for all cryptographic purposes, including the generation of cryptographic keys used by an Approved security function.

If the seed and seed key input to the Approved RNG have the same value, the Approved RNG returns a failure status code and doesn't produce any output. The check is done by the memcmp function call in the function FIPS186Change_GenerateX:

           if (memcmp(XKEY_old, XSEEDj, BSIZE) == 0) {
               /* Should we add the error code SEC_ERROR_BAD_RNG_SEED? */
               PORT_SetError(SEC_ERROR_INVALID_ARGS);
               rv = SECFailure;
               goto done;
           }

Key Zeroization

The NSS cryptographic module takes a number of explicit zeroization steps to clear the memory region previously occupied by a private key or password. In summary, private keys are always stored in encrypted form. Any key material that has been unwrapped (decrypted) for use is zeroed once the use is complete. The function used to zero memory used by private key material is the Standard C library function memset() or its synonym PORT_Memset():

 #define PORT_Memset     memset

If the memory used by private key material is allocated from the heap, the PORT_ZFree() function can be used to both zero and free memory:

 void
 PORT_ZFree(void *ptr, size_t len)
 {
     if (ptr) {
         memset(ptr, 0, len);
         PR_Free(ptr);
     }
 }

(PR_Free() calls the Standard C library function free() to free memory allocated from the heap.)