Security Policy

From MozillaWiki
Revision as of 00:07, 11 April 2006 by Neil.williams (talk | contribs)
Jump to navigation Jump to search

This is a draft document.

Specification of Security Policy

A security policy includes the precise specification of the security rules under which the cryptographic module must operate, including rules derived from the security requirements of the FIPS PUB 140-1 standard, and the additional security rules listed below. The rules of operation of the cryptographic module that define within which role(s), and under what circumstances (when performing which services), an operator is allowed to maintain or disclose each security relevant data item of the cryptographic module.

There are three major reasons for developing and following a precise cryptographic module security policy:

  • To induce the cryptographic module vendor (Sun Microsystems) to think carefully and precisely about who they want to access the cryptographic module, the way different system elements can be accessed, and which system elements to protect.
  • To provide a precise specification of the cryptographic security to allow individuals and organizations (e.g., validators) to determine whether the cryptographic module, as implemented, does obey (satisfy) a stated security policy.
  • To describe to the cryptographic module user (organization, or individual operator) the capabilities, protections, and access rights they will have when using the cryptographic module.

It should be noted that NSS utilizes RSA's PKCS #11, version 2.01, to form most of its cryptographic boundary. This, along with some certificate handling mechanisms, comprise the entire cryptographic module boundary. The following table states the various security policy rules which will be adhered to by each product utilizing NSS:

Rule

Statement of NSS Security Policy

1 The NSS cryptographic module shall consist of a series of binary software libraries compiled for each supported platform.
2 The cryptographic module shall rely on the underlying operating system to ensure the integrity of the cryptographic module loaded into memory.
3 The cryptographic module shall enforce a single role approach which is a combination of the User Role and the Cryptographic User Role as defined in FIPS PUB 140-2.
4 A cryptographic module user shall have access to ALL the services supplied by the cryptographic module.
5 Cryptographic module services shall consist of public services which require no authentication, and private services which require authentication.
6 Public key certificates shall be stored in plain text form because of their public nature and internal CA-signing integrity features.
7 SSL 2.0, 3.0, and TLS shall utilize authentication mechanisms above the cryptographic module which pass-through to utilize PKCS #11 authentication mechanisms which are within the cryptographic module.
8 SSL master secrets (private key data) shall be protected within the boundary of the cryptographic module (the SSL secure session ID cache shall be considered within the boundary of the cryptographic module).
9 For the FIPS PUB 140-1 mode of operation, the cryptographic module shall enforce rules specific to FIPS PUB 140-1 requirements.
10 The FIPS PUB 140-2 cryptographic module shall use an exception handling mechanism to ensure that critical errors are not allowed to compromise security (i. e. - whenever a critical error is encountered, the cryptographic module shall be required to be reinitialized).
11 Upon initialization of the FIPS PUB 140-1 cryptographic module, the following power-up self-tests shall be performed:
  1. RC2-ECB Encrypt/Decrypt,
  2. RC2-CBC Encrypt/Decrypt,
  3. RC4 Encrypt/Decrypt,
  4. DES-ECB Encrypt/Decrypt,
  5. DES-CBC Encrypt/Decrypt,
  6. triple DES-ECB Encrypt/Decrypt,
  7. triple DES-CBC Encrypt/Decrypt,
  8. MD2 Hash,
  9. MD5 Hash,
  10. SHA-1 Hash,
  11. RSA Encrypt,
  12. RSA Decrypt,
  13. RSA Signature,
  14. RSA Signature Verification,
  15. DSA Signature, and
  16. DSA Signature Verification.

Additionally, if the user performs logout services, these same power-up self-tests are performed when the user logs back in to the FIPS PUB 140-2 cryptographic module.

12 Subsequent logins to the FIPS PUB 140-2 cryptographic module during the same established session shall execute the same series of power-up self-tests detailed above when logging-in under the FIPS PUB 140-2 mode. This allows a user to execute these power-up self-tests on demand as defined in section 4.11.1 of FIPS PUB 140-2.
13 The FIPS PUB 140-1 cryptographic module shall require the user to establish a password (for the user role) in order for subsequent authentications to be enforced.
14 All passwords shall be stored in an encrypted form in secondary storage.
15 Once a password has been established for the FIPS PUB 140-2 cryptographic module, it shall only allow the user to use security services if and only if the user successfully authenticates to the FIPS PUB 140-2 cryptographic module.
16 In order to verify the user's stored password, the user shall enter the password, and the verification that the password is correct shall be performed by the cryptographic module via PKCS #5 password-based encryption mechanisms.
17 The user's password shall act as the key material to encrypt/decrypt private key material.
18 The user's password shall act as the key material to encrypt/decrypt private key material.
19 Private keys, plain text PINs, and other security relevant data items (SRDIs) shall be maintained under the control of the cryptographic module, and shall not be passed to higher level callers.
20 All private keys shall be stored in an encrypted form in secondary storage.
21 Integrity checks shall be applied to the private and public key material retrieved from the database to ensure genuine data.
22 Once the FIPS PUB 140-2 mode of operation has been selected, the cryptographic module shall only allow FIPS PUB 140-1 cipher suite functionality.
23 The FIPS PUB 140-2 cipher suite shall consist solely of DES/Triple-DES (FIPS PUB 46-3) for encryption/decryption, SHA-1 (FIPS PUB 180-1) for hashing, RSA for key distribution, and DSA (FIPS PUB 186) or RSA (PKCS #1) for generic signature signing and verifying functionality. (checkthis)
24 Once the FIPS PUB 140-2 mode of operation has been selected, DES/Triple-DES shall be limited in its use to perform encryption/decryption using either CBC or ECB mode.
25 Once the FIPS PUB 140-2 mode of operation has been selected, SHA-1 shall be the only algorithm used to perform one-way hashes of data. (checkthis)
26 Once the FIPS PUB 140-2 mode of operation has been selected, RSA shall be limited in its use to generation of PKCS#1 signatures and verification of them, and to signing and verifying key material for key exchange.
27 Once the FIPS PUB 140-2 mode of operation has been selected, DSA shall be used in addition to RSA to generate signatures and to perform verification on them.
28 In the FIPS PUB 140-2 mode of operation, the cryptographic module shall perform a pairwise consistency test upon each invocation of RSA and DSA key generation as defined in section 4.11.2 of FIPS PUB 140-2.
29 The FIPS PUB 140-2 cryptographic module shall employ its prime number generation and verification via the mechanisms described in Appendix 2 of FIPS PUB 186. (checkthis)
30 The FIPS PUB 140-2 cryptographic module shall utilize pseudorandom number generation as defined via the mechanisms described in Appendix 3 of FIPS PUB 186. (checkthis)
31 The FIPS PUB 140-2 cryptographic module shall seed its pseudorandom number generation via invoking a noise generator specific to the platform on which it was implemented (e. g. - MacIntosh, UNIX, or Windows). Pseudorandom number generator shall be seeded with noise derived from the execution environment such that the noise is not predictable.
32 The FIPS PUB 140-2 cryptographic module's pseudorandom number generator shall periodically reseed itself with pseudorandom noise.
33 In the FIPS PUB 140-2 mode of operation, the cryptographic module shall perform a pseudorandom number generation test upon each invocation of the pseudorandom number generator as defined in section 4.11.2 of FIPS PUB 140-2. (checkthis)
34 Upon exit from the FIPS PUB 140-2 mode of operation, all security relevant data items within the cryptographic module which are stored to secondary storage shall be zeroized by having their memory contents rewritten with zeroes.
35 The TLS pseudorandom function (PRF) is contained within the cryptographic module, and it shall enforce if one hash is weak the PRF function would remain strong, this is accomplished by exclusive-oring the results of the two hashes in computation of security relevant data items -- specifically SSL pre-master secrets.
36 For operation in FIPS PUB 140-2 Level 2 mode, the machine shall be labeled in a tamper-evident manner. Labels are to be supplied by the vendor and placed by the user on the bottom right and left edges midway between the front and the back of the case. Before placing labels, clean the portion of the case where the labels will adhere with rubbing alcohol, and allow the case to dry. Apply the labels to the indicated locations, and allow labels to set for 24 hours.
37 The FIPS module is activated with a call to SECMOD_DeleteModule(), with the module to delete being the internal module. This will disable non-FIPS use of NSS, and enable the FIPS mode of operation. NSS clients may provide UI for enabling FIPS operation.
Retrieved from "https://wiki.mozilla.org/index.php?title=Security_Policy&oldid=23676"