This is a draft document

Key Management

Our private key and certificate databases (for both client and server products) are hash (DBM) indexed flat files (regular files).
The private keys and secret keys are stored encrypted using DES-EDE3 (triple-DES) in the private key database. The password-based encryption protects against unauthorized disclosure, modification, and substitution of the private keys and secret keys stored in the private key database. When the private keys and secret keys reside in memory, they are protected by the OS.
The X509 v3 certificates 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.
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.
The exported private key is encrypted with a DES-EDE3 (triple-DES) key derived from a user provided password -- see PKCS #5 below.
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 plaintext session IDs (for SSL), passwords entered by users, and private key (stored on disk) are zeroed from memory.
PKCS #12 can be used to archive a wrapped (encrypted) private key for recovery purposes.
Our use of DES and DES-EDE3, as called out in PKCS #12, are FIPS 46-3 validated.
NSS's triple-DES implementation conforms to FIPS 46-3. ( TripleDES)
NSS's SHA-1 implementation conforms to FIPS 180-2. See SHS.
NSS's DSA implementation conforms to FIPS 186-2. (DSA)
All key/certificate management operations of the NSS cryptogrpahic service providers (CSPs) are FIPS 140-2 validated.

Key Generation

The prime numbers that are generated for both RSA and DSA are tested using FIPS 186-2 [APPENDIX 2.1. A PROBABILISTIC PRIMALITY TEST] -- Miller-Rabin test.

Key Establishment Techniques

NSS uses the following Approved key establishment techniques listed in Annex D to FIPS PUB 140-2:

Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 112 bits of encryption strength)
Key Wrapping using RSA keys (PKCS #1, key wrapping, key establishment methodology provides between 80 bits and 192 bits of encryption strength)

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

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

Random Number Generator

TBS.

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

VE 07KeyMgmt

Contents