Security Policy: Difference between revisions

Jump to navigation Jump to search

Security Policy (view source)

Revision as of 17:30, 24 August 2006

88 bytes removed ,  24 August 2006
→‎Specification of Security Policy
Line 25: Line 25:
| 2 || The cryptographic module shall rely on the underlying operating system to ensure the integrity of the cryptographic module loaded into memory.
| 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 support the NSS User Role and the Crypto Officer Role. The NSS User Role is a combination of the User Role and the Crypto Officer Role as defined in FIPS PUB 140-2.
| 3 || The cryptographic module shall support the NSS User Role and the Crypto Officer Role.
|-
|-
| 4 || A cryptographic module user shall have access to ALL the services supplied by the cryptographic module.
| 4 || A cryptographic module user shall have access to ALL the services supplied by the cryptographic module.
Line 33: Line 33:
| 6 || Public key certificates shall be stored in plaintext form because of their public nature and internal CA-signing integrity features.
| 6 || Public key certificates shall be stored in plaintext form because of their public nature and internal CA-signing integrity features.
|-
|-
| 7 || (This rule is obsolete and deleted.)
| 7 || (This rule is intentionally left blank.)
|-
|-
| 8 || TLS master secrets (48-byte secrets shared between the peers in TLS connections) shall be extracted from the cryptographic module in encrypted form (the TLS session ID cache, which stores the encrypted TLS master secrets, shall be considered outside the boundary of the cryptographic module).
| 8 || TLS master secrets (48-byte secrets shared between the peers in TLS connections) shall be extracted from the cryptographic module in encrypted form (the TLS session ID cache, which stores the encrypted TLS master secrets, shall be considered outside the boundary of the cryptographic module).
Line 73: Line 73:
| 13 || The FIPS PUB 140-2 cryptographic module shall require the user to establish a password (for the NSS user role) in order for subsequent authentications to be enforced.
| 13 || The FIPS PUB 140-2 cryptographic module shall require the user to establish a password (for the NSS user role) in order for subsequent authentications to be enforced.
|-
|-
| 14 || A known password check string, encrypted with a Triple-DES key derived from the password, shall be stored in the private key database (key3.db) in secondary storage. '''Note:''' password-based encryption is not FIPS Approved.
| 14 || A known password check string, encrypted with a Triple-DES key derived from the password, shall be stored in the private key database (key3.db) 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 the private services if and only if the user successfully authenticates to the FIPS PUB 140-2 cryptographic module.
| 15 || Once a password has been established for the FIPS PUB 140-2 cryptographic module, it shall only allow the user to use the private services if and only if the user successfully authenticates to the FIPS PUB 140-2 cryptographic module.
Line 84: Line 84:
| 17 || The user's password shall act as the key material to encrypt/decrypt private key material. '''Note''': password-encrypted secret and private keys should be considered in plaintext form in FIPS mode.
| 17 || The user's password shall act as the key material to encrypt/decrypt private key material. '''Note''': password-encrypted secret and private keys should be considered in plaintext form in FIPS mode.
|-
|-
| 18 || Secret and private keys, plaintext passwords, and other security-relevant data items shall be maintained under the control of the cryptographic module. Secret and private keys shall only be passed to higher level callers in encrypted (wrapped) form with <code>FC_WrapKey</code>. '''Note''': password-encrypted secret and private keys should be considered in plaintext form in FIPS mode.
| 18 || Secret and private keys, plaintext passwords, and other security-relevant data items shall be maintained under the control of the cryptographic module. Secret and private keys shall only be passed to higher level callers in encrypted (wrapped) form with <code>FC_WrapKey</code>. '''Note''': if secret and private keys are passed to higher level callers in password-encrypted form, they should be considered in plaintext form in FIPS mode.
|-
|-
| 19 || All secret and private keys shall be stored in encrypted form (using a Triple-DES key derived from the password) in the private key database (key3.db) in secondary storage. '''Note''': password-encrypted secret and private keys should be considered in plaintext form in FIPS mode.
| 19 || All secret and private keys shall be stored in encrypted form (using a Triple-DES key derived from the password) in the private key database (key3.db) in secondary storage. '''Note''': password-encrypted secret and private keys should be considered in plaintext form in FIPS mode.
|-
|-
| 20 || (This rule is obsolete and deleted.)
| 20 || (This rule is intentionally left blank.)
|-
|-
| 21 || Once the FIPS PUB 140-2 mode of operation has been selected, the cryptographic module user shall only use the FIPS PUB 140-2 cipher suite.
| 21 || Once the FIPS PUB 140-2 mode of operation has been selected, the cryptographic module user shall only use the FIPS PUB 140-2 cipher suite.
Line 121: Line 121:
| 30 || The 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.
| 30 || The 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.
|-
|-
| 31 || The cryptographic module's pseudorandom number generator shall be periodically reseeded with unpredictable noise.
| 31 || A product using the cryptographic module shall periodically reseed the module's pseudorandom number generator with unpredictable noise.
|-
|-
| 32 || In the FIPS PUB 140-2 mode of operation, the cryptographic module shall perform a continuous random number generator test upon each invocation of the pseudorandom number generator as defined in section 4.9.2 of FIPS PUB 140-2.
| 32 || In the FIPS PUB 140-2 mode of operation, the cryptographic module shall perform a continuous random number generator test upon each invocation of the pseudorandom number generator as defined in section 4.9.2 of FIPS PUB 140-2.
Wtchang
canmove, Confirmed users
937

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/32374"

Navigation menu