Security Policy

This is a draft document.

Module Information

• Module name: NSS cryptographic module
• Module version: 3.11.5
• Vendor name: Red Hat and Sun Microsystems
• Document version: 1.1
• Document revision date: 2006-08-11

Specification of Security Policy

The NSS cryptographic module is a general-purpose cryptographic library. Its API is based on RSA Security's PKCS #11 version 2.20. The following table states the various security policy rules that each product using the NSS cryptographic module will adhere to:

Rule	Statement of the NSS Cryptographic Module Security Policy
1	The NSS cryptographic module shall consist of 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 Crypto Officer 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 plaintext form because of their public nature and internal CA-signing integrity features.
7	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	TLS master secrets (private key data) shall be extracted from the cryptographic module in encrypted form (the TLS secure session ID cache shall be considered outside the boundary of the cryptographic module).
9	For the FIPS PUB 140-2 mode of operation, the cryptographic module shall enforce rules specific to FIPS PUB 140-2 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 library shall be required to be reinitialized).
11	Upon initialization of the FIPS PUB 140-2 cryptographic module library, 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, AES-ECB Encrypt/Decrypt, AES-CBC Encrypt/Decrypt, MD2 Hash, MD5 Hash, SHA-1 Hash, SHA-256 Hash, SHA-384 Hash, SHA-512 Hash, HMAC Hash, RSA Encrypt, RSA Decrypt, RSA Signature, RSA Signature Verification, DSA Signature, DSA Signature Verification, ECDSA Signature, ECDSA Signature Verification, and PRNG.
12	Shutting down and restarting the FIPS PUB 140-2 cryptographic module with the FC_Finalize and FC_Initialize functions shall execute the same power-up self-tests detailed above when initializing the module library for the FIPS PUB 140-2 mode. This allows a user to execute these power-up self-tests on demand as defined in Section 4.9.1 of FIPS PUB 140-2.
13	The FIPS PUB 140-2 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 the private 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. Note: password-encrypted private keys should be considered in plaintext in FIPS mode.
18	Private keys, plaintext 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.
19	All private keys shall be stored in an encrypted form in secondary storage. Note: password-encrypted private keys should be considered in plaintext in FIPS mode.
20	Integrity checks shall be applied to the private and public key material retrieved from the database to ensure genuine data.
21	Once the FIPS PUB 140-2 mode of operation has been selected, the cryptographic module user shall only use FIPS PUB 140-2 cipher suite functionality.
22	The FIPS PUB 140-2 cipher suite shall consist solely of DES/Triple-DES (FIPS PUB 46-3) or AES (FIPS PUB 197) for encryption/decryption, SHA-1, SHA-256, SHA-384, or SHA-512 (FIPS PUB 180-2) for hashing, Diffie-Hellman, EC Diffie-Hellman, or Key Wrapping using RSA keys for key establishment, and DSA (FIPS PUB 186-2), RSA (PKCS #1), or ECDSA (ANSI X9.62) for generic signature generation and verification functionality. Caveats: Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 112 bits of encryption strength) EC Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 256 bits of encryption strength) RSA (PKCS #1, key wrapping, key establishment methodology provides between 80 bits and 192 bits of encryption strength)
23	Once the FIPS PUB 140-2 mode of operation has been selected, DES/Triple-DES/AES shall be limited in its use to perform encryption/decryption using either CBC or ECB mode.
24	Once the FIPS PUB 140-2 mode of operation has been selected, SHA-1, SHA-256, SHA-386, and SHA-512 shall be the only algorithms used to perform one-way hashes of data.
25	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 encrypting and decrypting key material for key exchange.
26	Once the FIPS PUB 140-2 mode of operation has been selected, DSA and ECDSA shall be used in addition to RSA to generate signatures and to perform verification on them.
27	In the FIPS PUB 140-2 mode of operation, the cryptographic module shall perform a pair-wise consistency test upon each invocation of RSA, DSA, and ECDSA key pair generation as defined in section 4.9.2 of FIPS PUB 140-2.
28	The FIPS PUB 140-2 cryptographic module shall employ its prime number generation and primality test via the mechanisms described in Appendix 2 of FIPS PUB 186-2.
29	The FIPS PUB 140-2 cryptographic module shall utilize pseudorandom number generation as defined via the mechanisms described in FIPS PUB 186-2 Change Notice 1.
30	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.
31	The FIPS PUB 140-2 cryptographic module's pseudorandom number generator shall be periodically reseeded 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.
33	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.
34	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 TLS pre-master secrets.
35	For operation in FIPS PUB 140-2 Security 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.
36	The NSS cryptographic module consists of the following shared libraries/DLLs and the associated .chk files: Windows XP Service Pack 2 softokn3.dll softokn3.chk freebl3.dll freebl3.chk 32-bit HP-UX B.11.11 PA-RISC libsoftokn3.sl libsoftokn3.chk libfreebl_32int_3.sl libfreebl_32int_3.chk libfreebl_32fpu_3.sl libfreebl_32fpu_3.chk 64-bit HP-UX B.11.11 PA-RISC libsoftokn3.sl libsoftokn3.chk libfreebl3.sl libfreebl3.chk Mac OS X 10.4 libsoftokn3.dylib libsoftokn3.chk libfreebl3.dylib libfreebl3.chk 64-bit Trusted Solaris 8 SPARC libsoftokn3.so libsoftokn3.chk libfreebl_64int_3.so libfreebl_64int_3.chk libfreebl_64fpu_3.so libfreebl_64fpu_3.chk 32-bit Solaris SPARC libsoftokn3.so libsoftokn3.chk libfreebl_32int_3.so libfreebl_32int_3.chk libfreebl_32int64_3.so libfreebl_32int64_3.chk libfreebl_32fpu_3.so libfreebl_32fpu_3.chk 64-bit Solaris 10 AMD64, Red Hat Enterprise Linux 4 x86, Red Hat Enterprise Linux 4 x86_64, and other Unix/Linux platforms not mentioned above libsoftokn3.so libsoftokn3.chk libfreebl3.so libfreebl3.chk The NSS cryptographic module requires the Netscape Portable Runtime (NSPR), which consists of the following shared libraries/DLLs: Windows XP Service Pack 2 plc4.dll plds4.dll nspr4.dll HP-UX B.11.11 PA-RISC libplc4.sl libplds4.sl libnspr4.sl Mac OS X 10.4 libplc4.dylib libplds4.dylib libnspr4.dylib 32-bit Solaris SPARC libplc4.so libplds4.so libnspr4.so cpu/sparcv8plus/libnspr_flt4.so 64-bit Solaris 10 AMD64, 64-bit Trusted Solaris 8 SPARC, Red Hat Enterprise Linux 4 x86, Red Hat Enterprise Linux 4 x86_64, and other Unix/Linux platforms not mentioned above libplc4.so libplds4.so libnspr4.so Step 1: Install the shared libraries/DLLs and the associated .chk files in a directory on the shared library/DLL search path, which could be a system library directory (/usr/lib on Unix/Linux or C:\WINDOWS\system32 on Windows) or a directory specified in the following environment variable: Windows XP Service Pack 2: PATH HP-UX B.11.11 PA-RISC: SHLIB_PATH Mac OS X 10.4: DYLD_LIBRARY_PATH AIX: LIBPATH Solaris, Linux, and other Unix/Linux platforms not mentioned above: LD_LIBRARY_PATH Step 2: Use the chmod utility to set the file mode bits of the shared libraries/DLLs to 0755 so that all users can execute the library files, but only the files' owner can modify (i.e., write, replace, and delete) the files. For example, on most Unix and Linux platforms, $ chmod 0755 libsoftokn3.so libfreebl*3.so libplc4.so libplds4.so libnspr4.so Step 3: Use the chmod utility to set the file mode bits of the associated .chk files to 0644. For example, on most Unix and Linux platforms, $ chmod 0644 libsoftokn3.chk libfreebl*3.chk Step 4: By default the NSS cryptographic module operates in the non-FIPS Approved mode, meaning that if an application calls the standard PKCS #11 function C_GetFunctionList and calls the function pointers in that list, it gets the non-FIPS Approved mode. To run the NSS cryptographic module in the FIPS Approved mode, an application must call the alternative function FC_GetFunctionList and call the function pointers in that list. Here is the sample code using NSPR functions (declared in the header file "prlink.h") for dynamic library loading and function symbol lookup: #include "prlink.h" #include "cryptoki.h" #include <assert.h> #include <stdio.h> /* * An extension of the CK_C_INITIALIZE_ARGS structure for the * NSS cryptographic module. The 'LibraryParameters' field is * used to pass instance-specific information to the library * (like where to find its config files, etc). */ typedef struct CK_C_INITIALIZE_ARGS_NSS { CK_CREATEMUTEX CreateMutex; CK_DESTROYMUTEX DestroyMutex; CK_LOCKMUTEX LockMutex; CK_UNLOCKMUTEX UnlockMutex; CK_FLAGS flags; CK_CHAR_PTR *LibraryParameters; CK_VOID_PTR pReserved; } CK_C_INITIALIZE_ARGS_NSS; int main() { char *libname; PRLibrary *lib; CK_C_GetFunctionList pC_GetFunctionList; CK_FUNCTION_LIST_PTR pFunctionList; CK_RV rv; CK_C_INITIALIZE_ARGS_NSS initArgs; PRStatus status; /* Get the platform-dependent library name of the NSS cryptographic module */ libname = PR_GetLibraryName(NULL, "softokn3"); assert(libname != NULL); lib = PR_LoadLibrary(libname); assert(lib != NULL); PR_FreeLibraryName(libname); pC_GetFunctionList = (CK_C_GetFunctionList) PR_FindFunctionSymbol(lib, "FC_GetFunctionList"); assert(pC_GetFunctionList != NULL); rv = (*pC_GetFunctionList)(&pFunctionList); assert(rv == CKR_OK); /* Call FC_Foo as pFunctionList->C_Foo */ initArgs.CreateMutex = NULL; initArgs.DestroyMutex = NULL; initArgs.LockMutex = NULL; initArgs.UnlockMutex = NULL; initArgs.flags = CKF_OS_LOCKING_OK; initArgs.LibraryParameters = (CK_CHAR_PTR *) "configdir='.' certPrefix='' keyPrefix='' secmod='secmod.db' flags= "; initArgs.pReserved = NULL; rv = pFunctionList->C_Initialize(&initArgs); assert(rv == CKR_OK); /* ... */ rv = pFunctionList->C_Finalize(NULL); assert(rv == CKR_OK); status = PR_UnloadLibrary(lib); assert(status == PR_SUCCESS); return 0; } To reiterate, the mode of operation of the NSS cryptographic module is determined by the second argument passed to the PR_FindFunctionSymbol function. For the non-FIPS Approved mode of operation, look up the standard PKCS #11 function "C_GetFunctionList". For the FIPS Approved mode of operation, look up the alternative function "FC_GetFunctionList".

Non-NIST-Recommended Elliptic Curves

The NSS cryptographic module implements all the NIST-Recommended elliptic curves in FIPS 186-2 and the following non-NIST-Recommended curves:

• ANSI X9.62 prime curves
  • prime192v2
  • prime192v3
  • prime239v1
  • prime239v2
  • prime239v3
• ANSI X9.62-1998 binary curves
  • c2pnb163v1
  • c2pnb163v2
  • c2pnb163v3
  • c2pnb176w1 (disallowed in ANSI X9.62-2005). Note: the NSS cryptographic module incorrectly named this curve c2pnb176v1.
  • c2tnb191v1
  • c2tnb191v2
  • c2tnb191v3
  • c2pnb208w1 (disallowed in ANSI X9.62-2005)
  • c2tnb239v1
  • c2tnb239v2
  • c2tnb239v3
  • c2pnb272w1 (disallowed in ANSI X9.62-2005)
  • c2pnb304w1 (disallowed in ANSI X9.62-2005)
  • c2tnb359v1
  • c2pnb368w1 (disallowed in ANSI X9.62-2005)
  • c2tnb431r1
• SEC 2 prime curves
  • secp112r1
  • secp112r2
  • secp128r1
  • secp128r2
  • secp160k1
  • secp160r1
  • secp160r2
  • secp192k1
  • secp224k1
  • secp256k1
• SEC 2 binary curves
  • sect113r1
  • sect113r2
  • sect131r1
  • sect131r2
  • sect163r1
  • sect193r1
  • sect193r2
  • sect239k1

Although FIPS 140-2 Implementation Guidance IG 1.6 allows the use of non-NIST-Recommended curves in the FIPS Approved mode of operation, we recommend that the non-NIST-Recommended curves not be used in the FIPS mode.

Specification of Roles

The NSS cryptographic module utilizes a single role approach -- this role, called NSS User, is a combination of both the User Role and the Crypto Officer Role. An NSS User has access to all services of the module and all keys stored in the data base.

Authentication Policy

The NSS cryptographic module uses Role-Based Authentication to control access to the module. To perform sensitive services using the cryptographic module, an operator must explicitly request to assume the NSS User role by logging into the module, and perform an authentication procedure using information unique to that operator (individual password). Role-based authentication is used to safeguard a user's private key information. However, Discretionary Access Control (DAC) is used to safeguard all other NSS User information (e.g., the public key certificate database).

Strength of Authentication Mechanism

In FIPS mode, the NSS cryptographic module imposes the following requirements on the password.

• The password must be at least seven characters long.
• The password must consist of characters from three or more character classes. We define five character classes: digits (0-9), ASCII lowercase letters, ASCII uppercase letters, ASCII non-alphanumeric characters (such as space and punctuation marks), and non-ASCII characters. If an ASCII uppercase letter is the first character of the password, the uppercase letter is not counted toward its character class. Similarly, if a digit is the last character of the password, the digit is not counted toward its character class.

To estimate the probability that a random guess of the password will succeed, we assume that

• the characters of the password are independent with each other, and
• the probability of guessing an individual character of the password is < 1/10.

Since the password is >= 7 characters long, the probability that a random guess of the password will succeed is < (1/10)^7 = 1/10,000,000.

After each failed authentication attempt in FIPS mode, the NSS cryptographic module inserts a one-second delay before returning to the caller, allowing at most 60 authentication attempts during a one-minute period. Therefore, the probability of a successful random guess of the password during a one-minute period is < 60 * 1/10,000,000 = 0.6 * (1/100,000).

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

The NSS cryptographic module doesn't allow concurrent operators.

• For Security Level 1, the operating system has been restricted to a single operator mode of operation, so concurrent operators are explicitly excluded (FIPS 140-2 Sec. 4.6.1).
• On a multi-user operating system, this is enforced by making the NSS certificate and key databases readable and writable by only the owner of the files.

FIPS 140-2 Implementation Guidance 6.1 clarifies the use of a cryptographic module on a server.

When a crypto module is implemented in a server environment, the server application is the user of the cryptographic module. The server application makes the calls to the cryptographic module. Therefore, the server application is the single user of the cryptographic module, even when the server application is serving multiple clients.

Note: The NSS cryptographic module does allow concurrent processes with the same user identity to access the module, with the restriction that all the concurrent processes must open the NSS databases in read-only mode. Each process accessing the module needs to assume a role separately.

The NSS cryptographic module also allows a process to open multiple concurrent sessions (connections) with the module. When a session within a process assumes a role, all the concurrent sessions within the process assume that role (PKCS #11 v2.20, Sec. 11.4, C_Login).

Specification of Services

Since there is only one role, the user has access to ALL the services. Routines have been specified for each service and denoted whether or not they are public, meaning that the user doesn't need to authenticate to the module to use the routine, or private, meaning that the user needs to authenticate to the module to use the routine. This model allows a type of safety state by allowing a NSS user to log out (thus disallowing any access to private services) without ending the session, and then log back in to re-authenticate and access private services rendered by the cryptographic module. All public and private services are listed in the following table:

Table II. Services

Name of Service

Description of Service in Terms of Routines

PKCS #11

The PKCS #11 API specifies a standard interface based upon the PKCS #11 standard, which allows for the selection of a FIPS 140-2 mode of operation that provides both public and private services as well as a means of authentication into all private services, creates and maintains entry points for all FIPS 140-2 specific routines including sftk_fipsPowerUpSelfTest() at initialization as well as on demand, and enforces a pairwise consistency check on all key generation algorithms. The NSS cryptographic module's FIPS 140-2 PKCS #11 implementation defines the following standard crypto API: Category Function Description FIPS 140-2 specific FC_GetFunctionList Return the list of FIPS 140-2 functions General purpose FC_Initialize initializes Cryptoki FC_Finalize finalizes Cryptoki (1.1) FC_GetInfo obtains general information about Cryptoki Slot and token management FC_GetSlotList obtains a list of slots in the system FC_GetSlotInfo obtains information about a particular slot FC_GetTokenInfo obtains information about a particular token FC_GetMechansimList obtains a list of mechanisms supported by a token FC_GetMechanismInfo obtains information about a particular mechanism FC_InitToken initializes a token FC_InitPIN initializes the normal user?s PIN FC_SetPIN modifies the PIN of the current user Session management FC_OpenSession opens a connection or "session" between an application and a particular token FC_CloseSession closes a session FC_CloseAllSessions closes all sessions with a token FC_GetSessionInfo obtains information about the session FC_GetOperationState saves the state of the cryptographic operation in a session (1.1) FC_SetOperationState restores the state of the cryptographic operation in a session (1.1) FC_Login logs into a token FC_Logout logs out from a token Object management (private) FC_CreateObject creates an object FC_CopyObject creates a copy of an object FC_DestroyObject destroys an object FC_GetObjectSize obtains the size of an object in bytes FC_GetAttributeValue obtains an attribute value of an object FC_SetAttributeValue modifies an attribute value of an object FC_FindObjectsInit initializes an object search operation FC_FindObjects continues an object search operation FC_FindObjectsFinal finishes an object search operation (1.1) Encryption and decryption (private) FC_EncryptInit initializes an encryption operation FC_Encrypt encrypts single-part data FC_EncryptUpdate continues a multiple-part encryption operation FC_EncryptFinal finishes a multiple-part encryption operation FC_DecryptInit initializes a decryption operation FC_Decrypt decrypts single-part encrypted data FC_DecryptUpdate continues a multiple-part decryption operation FC_DecryptFinal finishes a multiple-part decryption operation Message digesting (public) FC_DigestInit initializes a message-digesting operation FC_Digest digests single-part data FC_DigestUpdate continues a multiple-part digesting operation FC_DigestKey continues a multi-part message-digesting operation by digesting the value of a secret key as part of the data already digested (1.1) FC_DigestFinal finishes a multiple-part digesting operation Signature and verification (private) FC_SignInit initializes a signature operation FC_Sign signs single-part data FC_SignUpdate continues a multiple-part signature operation FC_SignFinal finishes a multiple-part signature operation FC_SignRecoverInit initializes a signature operation, where the data can be recovered from the signature FC_SignRecover signs single-part data, where the data can be recovered from the signature FC_VerifyInit initializes a verification operation FC_Verify verifies a signature on single-part data FC_VerifyUpdate continues a multiple-part verification operation FC_VerifyFinal finishes a multiple-part verification operation FC_VerifyRecoverInit initializes a verification operation where the data is recovered from the signature FC_VerifyRecover verifies a signature on single-part data, where the data is recovered from the signature Dual-function cryptographic operations FC_DigestEncryptUpdate continues a multiple-part digesting and encryption operation (1.1) FC_DecryptDigestUpdate continues a multiple-part decryption and digesting operation (1.1) FC_SignEncryptUpdate continues a multiple-part signing and encryption operation (1.1) FC_DecryptVerifyUpdate continues a multiple-part decryption and verify operation (1.1) Key management (private) FC_GenerateKey generates a secret key FC_GenerateKeyPair generates a public-key/private-key pair FC_WrapKey wraps (encrypts) a key FC_UnwrapKey unwraps (decrypts) a key FC_DeriveKey derives a key from a base key Random number generation (public) FC_SeedRandom mixes in additional seed material to the random number generator FC_GenerateRandom generates random data. Performs continuous random number generator test. Function management FC_GetFunctionStatus obtains updated status of a function running in parallel with the application FC_CancelFunction cancels a function running in parallel with the application Callbacks Notify processes notifications from Cryptoki

Bypass Capabilities

This section is not applicable to the NSS cryptographic module because it does not implement a bypass capability.

Access Control Policy

This section identifies the cryptographic keys and CSPs that the user has access to while performing a service, and the type of access the user has to the parameters.

Security-Relevant Information

The NSS cryptographic module employs the following cryptographic keys and CSPs.

• secret, private, and public cryptographic keys (both plaintext and encrypted)
• internal state of the random number generator
• authentication data (passwords)
• audited events and audit data

Service Relationships to Security-Relevant Information Matrix

TODO: Table IV. Access Rights within Services

Table IV. Access Rights within Services (Out of Date)

Service	Service Routine	Security Relevant Data Item	Read Access	Write Access
Certificate Storage and Retrieval	AddCertToPermDB()	CERTCertDBHandle	X	X
		CERTCertificate	X	X
		CERTCertTrust	X	X
		certDBEntryCert	X	-
	CERT_ClosePermCertDB()	CERTCertDBHandle	X	X
	SEC_FindPermCertByKey()	CERTCertDBHandle	X	X
		SECItem	X	X
		certDBEntryCert	X	-
	SEC_OpenPermCertDB()	CERTCertDBHandle	X	X
		SECStatus	X	-
	SEC_DeletePermCertificate()	CERTCertDBHandle	X	X
		CERTCertificate	X	X
		SECStatus	X	-
	SEC_TraversePermCerts()	CERTCertDBHandle	X	X
		SECStatus	X	-

Means of Access

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

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.

Role-based Authentication

The NSS cryptographic module uses role-based authentication. It uses a single-role mechanism referred to above as a NSS User. Authentication shall always be required upon initializing the NSS cryptographic module in the FIPS mode. If a PKCS #11 function that requires authentication is called before the NSS User is authenticated, it returns the CKR_USER_NOT_LOGGED_IN error code. Call the PKCS #11 function FC_Login to provide the required authentication.

Mitigation of Other Attacks

The NSS cryptographic module is designed to mitigate the following attacks.

Other Attacks	Mitigation Mechanism	Specific Limitations
Timing attacks on RSA	RSA blinding Timing attack on RSA was first demonstrated by Paul Kocher in 1996[1], who contributed the mitigation code to our module. Most recently Boneh and Brumley[2] showed that RSA blinding is an effective defense against timing attacks on RSA.	None.
Cache-timing attacks on the modular exponentiation operation used in RSA and DSA	Cache invariant modular exponentiation This is a variant of a modular exponentiation implementation that Colin Percival[3] showed to defend against cache-timing attacks.	This mechanism requires intimate knowledge of the cache line sizes of the processor. The mechanism may be ineffective when the module is running on a processor whose cache line sizes are unknown.
Arithmetical errors in RSA signatures	Double-checking RSA signatures Arithmetical errors in RSA signatures might leak the private key. Ferguson and Schneier[4] recommend that every RSA signature generation should verify the signature just generated.	None.

Results of FIPS 140-2 Level 2 Validation of NSS Cryptographic Module 3.11.5

FIPS 140-2 Section	Description	Validation Level Obtained
1.0	Cryptographic Modules	2
2.0	Module Interfaces	2
3.0	Roles, Services, and Authentication	2
4.0	Finite State Machine Model	2
5.0	Physical Security	2
6.0	Operational Enviroment	2
7.0	Cryptographic Key Management	2
8.0	EMI/EMC	2
9.0	Self-Tests	2
10.0	Design Assurance	2
11.0	Mitigation of other Attacks	2
C	Cryptographic Security Policy	2

Platform List

• Level 1
  • RHEL 4 x86
  • Windows XP Service Pack 2
  • 64-bit Solaris 10 AMD64
  • HP-UX B.11.11 PA-RISC
  • Mac OS X 10.4

• Level 2
  • RHEL 4 x86_86
  • 64-bit Trusted Solaris 8 SPARC

References

[1] P. Kocher, "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems," CRYPTO '96, Lecture Notes In Computer Science, Vol. 1109, pp. 104-113, Springer-Verlag, 1996. (http://www.cryptography.com/timingattack/)

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

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

[4] N. Ferguson and B. Schneier, Practical Cryptography, Sec. 16.1.4 "Checking RSA Signatures", p. 286, Wiley Publishing, Inc., 2003.