canmove, Confirmed users
937
edits
VE 07KeyMgmt: Difference between revisions
Jump to navigation
Jump to search
→Key Management
| Line 3: | Line 3: | ||
=Key Management= | =Key Management= | ||
# Our private key and certificate databases are hash (DBM) indexed flat files (regular files). | # 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> | # 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> | ||
# When the secret keys and private keys reside in memory, they are protected by the OS from unauthorized disclosure, modification, and substitution. | # When the secret keys and private keys reside in memory, they are protected by the OS from unauthorized disclosure, modification, and substitution. | ||
# Public keys are stored in two ways. | # Public keys are stored in two ways. | ||
# | #* 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. <div class=note>Attributes of private keys are also password-encrypted as explained in the note above.</div> | ||
# | #* 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. | ||
# | #* 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. | ||
# When the public keys reside in memory, they are protected by the OS from unauthorized modification and substitution. | # When the public keys reside in memory, they are protected by the OS from unauthorized modification and substitution. | ||
# The NSS cryptographic module uses the following cryptographic keys, cryptographic key components, and CSPs: | |||
#* 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), | |||
#* seed keys (for the Approved RNG), and | |||
#* authentication data (passwords). | |||
# The 1024-bit DSA public keys for the software/firmware integrity test are stored along with the DSA signatures in the .chk files for the softoken (PKCS #11) and freebl shared libraries/DLLs. The DSA domain parameters (prime p, subprime q, base g) and public key (y) are stored in a straight binary format (i.e., not DER encoded). | # The 1024-bit DSA public keys for the software/firmware integrity test are stored along with the DSA signatures in the .chk files for the softoken (PKCS #11) and freebl shared libraries/DLLs. The DSA domain parameters (prime p, subprime q, base g) and public key (y) are stored in a straight binary format (i.e., not DER encoded). | ||
# 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. | # 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. | ||