VE 07KeyMgmt: Difference between revisions

# Our private key and certificate databases are hash (DBM) indexed flat files (regular files).

# 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. <div class=note>The private keys and secret keys stored in the private key database are actually encrypted using three-key Triple DES in CBC mode (DES-EDE3-CBC) to provide additional protection against unauthorized disclosure, modification, and substitution. Although Triple DES is an Approved security function, the key encrypting key is derived from the user's password using an extension of the PKCS #5 PBKDF1 key derivation function (see the <code>[http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/lowpbe.c.dep.html#nsspkcs5_PBKDF1Extended nsspkcs5_PBKDF1Extended]</code> function) with an iteration count of 1 and SHA-1 as the underlying hash function. Since password-based encryption such as PKCS #5 is not FIPS Approved, the private and secret keys in the private key database are considered in plaintext form by FIPS 140-2 (see FIPS 140-2 Section 4.7 and FIPS 140-2 IG 7.1). For more information on how the secret and private keys in the private key database are password-encrypted, see the <code>[http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/lowpbe.c.dep.html#nsspkcs5_CipherData nsspkcs5_CipherData]</code> function.</div>

#* TLS master secret (used in the generation of symmetric cipher keys, IVs, and MAC keys for TLS)

# No passwords (e.g., the export password for PKCS #12, or the private key database password) are stored on disk in plaintext.

# 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.

# Prior to exiting the Cryptographic Module, all passwords entered by users and private key (stored on disk) are zeroized from memory.

'''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 [http://csrc.nist.gov/cryptval/rng/rngval.html#208 Cert# 208].

'''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 [http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf 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.

The [http://wiki.mozilla.org/Security_Policy#Specification_of_Security_Policy Security Policy] is also annotated with these caveats.

Since there is only one user, by definition all the secret and private keys in the NSS cryptographic module are associated with the module owner.

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 <code>FC_UnwrapKey</code> and <code>FC_WrapKey</code>).

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

 

The first RNG is the Standard C Library function <code>rand()</code> (declared in the header file <code><stdlib.h></code>). The <code>rand()</code> 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 <code>/dev/urandom</code>. 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 RNG validation certificate is [http://csrc.nist.gov/cryptval/rng/rngval.html#208 Cert# 208].) 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.

 

 

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

If the memory used by private key material is allocated from the heap, the [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/util/secport.c.dep.html#PORT_ZFree <code>PORT_ZFree()</code>] function can be used to both zeroize and free memory:

A plaintext secret or private key is zeroized when it is deleted.

* the NSS cryptographic module switches between the FIPS and non-FIPS modes.

Passwords are automatically zeroized immediately after use.