Security Policy

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: RC2-ECB Encrypt/Decrypt, RC2-CBC Encrypt/Decrypt, RC4 Encrypt/Decrypt, DES-ECB Encrypt/Decrypt, DES-CBC Encrypt/Decrypt, triple DES-ECB Encrypt/Decrypt, triple DES-CBC Encrypt/Decrypt, MD2 Hash, MD5 Hash, SHA-1 Hash, RSA Encrypt, RSA Decrypt, RSA Signature, RSA Signature Verification, DSA Signature, and 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.

Additionally, a cryptographic module security policy should be expressed in terms of the roles, services, cryptographic keys, and other critical security parameters. It should consist of, at a minimum, an identification and authentication (I&A) policy and an access control policy. An I&A policy specifies whether a cryptographic module operator is required to identify his or her self to the system, and, if so, what information is required and how it should be presented to the system in order for the operator to prove his or her identity to the system (i.e., authenticate themselves). Information required to be presented to the system might be passwords or individually unique biometric data. Once an operator can perform service(s) using the cryptographic module, an access control policy specifies what mode(s) of access he or she has to each security relevant data item while performing a given service.

Specification of Roles

A series of security libraries represent the cryptographic module which present the same application programmer interface (API) to client and server products utilizing NSS. There are minor variations, listed in the module interfaces description, but these do not break the following definition of roles. The NSS cryptographic module utilizes a single role approach -- this role is a combination of both the User Role and the Cryptographic Officer Role, and will be referenced below as NSS User. A NSS User utilizes secure services, and is also responsible for making decisions related to retrieval, updating, and deletion of keys from their key database. This is true for both client and server products. For multiple user products, like the HTTP Server, the server still operates in this single role paradigm, under a single identity.

Authentication Policy

The NSS cryptographic module utilizes Role-Based Authentication - An operator who is allowed to use the cryptographic module must perform an authentication sequence using information unique to that operator (individual password) to perform sensitive services using the cryptographic module. Role-based authentication is utilized to safeguard a users private key information. However, Discretionary Access Controls (DAC) are used to safeguard all other NSS User information (e.g., the Public Key Certificate database). An NSS User may use a product (e.g. Netscape Navigator) without establishing a personal private key -- e.g., they may utilize SSL 3.0 Server Authentication without having a private key established. However, to enable SSL on the server products, a private key and public key certificate are required to enable secure services. An individual password is required in order to start the server -- this password is used to decrypt the private key.

Specification of Maintenance Roles

This section is not applicable to the NSS cryptographic module since it does not have a Maintenance Role.

Multiple Concurrent Operator Roles and Services

Since NSS-based applications always operate under a single role, under a single identity, no separate concurrent processes take place within an NSS-based application. In the case of separate threads of execution within the same process, NSS's threading model consists of a shared data segment with separate stack instances, and does not allow threads to leak insecurity into or out of the given process. Further, since a thread is not a separate process, and all threads of a given process live within the confines of that process, then all threads are subject to the same security imposed on the process itself.

Specification of Services

The vendor documentation shall fully describe each service including its purpose and function. Possible services may include, but not be limited to, the following:

• Cryptographic operations such as encryption, decryption, message integrity, digital signature generation, digital signature verification, and other operations that require the use of cryptography.
• Key management operations such as key and parameter entry, key generation, key output , key archiving, key zeroization, and other key management functions.
• Cryptographic management functions such as audit parameter entry and setting, alarm handling and resetting, and other cryptographic management functions.
• Performance of operator-selectable self tests, such as cryptographic algorithm tests, software/firmware tests , critical functions tests, statistical random number generator tests, or any additional tests that can be initiated by an operator.

The vendor documentation shall specify, for each service, the service inputs, corresponding service outputs, and the authorized role or roles in which the service can be performed. Service inputs shall consist of all data or control inputs to the module that initiate or obtain specific services, operations, or functions. Service outputs shall consist of all data and status outputs that result from services, operations or functions initiated or obtained by service inputs. The vendor may supply a matrix that displays the services that can be performed in each role.

In each of the following services, since there is only one role, the user has access to ALL the services mediated by the application (for both client and server products). Routines have been specified for each service and denoted whether or not they are public, meaning that they require no authentication to utilize, or private, meaning that authentication must be provided prior to the routine being utilized. This model allows a type of safety state by allowing a NSS user to logout (thus disallowing any access to private services) without ending the session, and then log back in to re-authenticate private services rendered by the cryptographic module. All public and private services are listed in the following table:

Table II. Services

Bypass Capabilities

This section is applicable when NSS is invoked in FIPS mode.

Access Control Policy

The access control policy enforced by the cryptographic module must be sufficiently precise, and of sufficient detail to allow the operator and testers to know what security relevant data items the operator has access to while performing a service, and the modes of access he or she has to these data items. Also, the testers and operator must be able to know if and how the kinds of data items accessible changes when the service is invoked from each role in which it can be invoked.

Security Relevant Data Items

Security relevant data items consist of data types used for Certificate Storage and Retrieval, Digital Signatures, Encryption/Decryption, Generic Containers, Hashing, Key Generation, PKCS #5 Password-Based Encryption, PKCS #12 Personal Information Exchange, Private Key Storage and Retrieval, Pseudorandom Number Generation, and SSL Session ID Cache (Secret Management).

All security relevant data items are identified by category, type, name, and description in the following table:

Table III. Security Data Items

Service Relationships to Security Relevant Data Items Matrix

Table IV. Service Relationships

Means of Access

Prior to execution of the Client or Server products, the Security Libraries are stored on disk in compiled binary form. NSS relies on Discretionary Access Controls (DAC) to protect the binary image from being tampered with.

Zeroization

Within the Security Libraries, there are a number of explicit zeroization steps that are taken to clear the memory region previously occupied by a private key or password. In summary, private keys are not stored in plaintext. Any key material that has been unwrapped for use is zeroed once the use is complete. The function used to both zero and free memory used by private key material is PORT_ZFree().

Role-based Authentication

Since all NSS-based products utilize role-based authentication, and all products use a single-role mechanism referred to above as a NSS User, authentication shall always be required upon initializing the FIPS Cryptographic Module. This is true of all NSS-based client and server products, and shall be handled via the PKCS #11 mechanism of required authentication.

Identity-based Authentication

This section is not applicable to NSS since it is only applicable to products attempting to be certified to security level three or four.

Mitigation of Other Attacks

The NSS software cryptographic module is designed to mitigate the following attacks:

• timing attacks against RSA;
• cache attacks against the modular exponentiation operation used in RSA and DSA.

The NSS software cryptographic module implements the following security mechanisms to mitigate those attacks:

• RSA blinding: many papers, such as Boneh and Brumley[1], have shown that RSA blinding is an effective defense against timing attacks against RSA.
• Cache invariant modular exponentiation: this is a variant of Colin Percival's defense[2] against cache attacks against the modular exponentiation operation.

References

[1] D. Boneh and D. Brumley, "Remote Timing Attacks are Practical," http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html.

[2] C. Percival, "Cache Missing for Fun and Profit," http://www.daemonology.net/papers/htt.pdf.