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 the industry standard PKCS #11 version 2.20. The following table specifies the security rules that each product using the NSS cryptographic module shall adhere to:

Rule	Specification of the NSS Cryptographic Module Security Rules
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 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.
5	Cryptographic module services shall consist of public services, which require no authentication, and private services, which require authentication. Public services (e.g., random number generation) do not require access to the secret and private keys and other CSPs associated with the user.
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 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).
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 not allow critical errors to compromise security. Whenever a critical error (e.g., a self-test failure) is encountered, the cryptographic module shall enter an error state and the library shall need to be reinitialized to resume normal operation.
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 (128-bit, 192-bit, and 256-bit keys), AES-CBC Encrypt/Decrypt (128-bit, 192-bit, and 256-bit keys), MD2 Hash, MD5 Hash, SHA-1 Hash, SHA-256 Hash, SHA-384 Hash, SHA-512 Hash, HMAC-SHA-1,-SHA-256,-SHA-384,-SHA-512 Hash (296-bit key), RSA Encrypt/Decrypt (1024-bit modulus n), RSA-SHA-1,-SHA-256,-SHA-384,-SHA-512 Signature (1024-bit modulus n), RSA-SHA-1,-SHA-256,-SHA-384,-SHA-512 Signature Verification (1024-bit modulus n), DSA Key Pair Generation (512-bit prime modulus p), DSA Signature (512-bit prime modulus p), DSA Signature Verification (512-bit prime modulus p), ECDSA Signature (Curve P-256), ECDSA Signature Verification (Curve P-256), PRNG, and software/firmware integrity test.
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 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.
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.
16	In order to authenticate to the cryptographic module, the user shall enter the password, and the cryptographic module shall verify that the password is correct by deriving a Triple-DES key from the password, decrypting the stored encrypted password check string with the Triple-DES key, and comparing the decrypted string with the known password check string.
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 FC_WrapKey. 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.
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.
22	The FIPS PUB 140-2 cipher suite shall consist solely of Triple-DES (FIPS PUB 46-3) or AES (FIPS PUB 197) for symmetric key encryption/decryption, SHA-1, SHA-256, SHA-384, or SHA-512 (FIPS PUB 180-2) for hashing, HMAC (FIPS PUB 198) for keyed hash, random number generator (FIPS PUB 186-2 Change Notice 1), 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 signature generation and verification. 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, 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 generating and verifying PKCS #1 signatures, 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 and verify signatures.
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 cryptographic module shall perform its prime number generation and primality test via the mechanisms described in Appendix 2 of FIPS PUB 186-2.
29	The cryptographic module shall perform pseudorandom number generation via the mechanisms described in FIPS PUB 186-2 Change Notice 1.
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	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.
33	The cryptographic module takes a number of explicit zeroization steps to clear the memory region previously occupied by a plaintext secret key, private key, or password. Any plaintext secret and private keys and passwords are zeroized once the use is complete. Upon exit from the FIPS PUB 140-2 mode of operation, all plaintext secret and private keys within the cryptographic module are zeroized by having their memory contents rewritten with zeroes.
34	The TLS pseudorandom function (PRF) is contained within the cryptographic module.
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 The discretionary access control protects the binaries stored on disk from being tampered with. 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".

Authentication Policy

Specification of Roles

The NSS cryptographic module supports two roles.

The NSS User Role provides access to all cryptographic and general purpose services (except those that perform an initialization function) and all keys stored in the database.

The Crypto Officer Role is supported for installation and initialization of the module. It is assumed implicitly by performing installation or by requesting initialization of the module.

The NSS cryptographic module does not have a Maintenance Role.

Role-based Authentication

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). The password is initialized by the crypto officer as part of module initialization. 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).

Authentication shall always be required upon initializing the NSS cryptographic module in the FIPS mode. If a function that requires authentication is called before the NSS User is authenticated, it returns the CKR_USER_NOT_LOGGED_IN error code. Call the FC_Login function to provide the required authentication.

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).

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 private 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).

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 CSPs.

Security-Relevant Information

The NSS cryptographic module employs the following cryptographic keys and CSPs in the FIPS Approved mode of operation.

• AES secret keys: The module supports 128-bit, 192-bit, and 256-bit AES keys. The keys may be stored in memory or in the private key database (key3.db).
• Triple DES secret keys: 168-bit. The keys may be stored in memory or in the private key database (key3.db).
• HMAC secret keys: HMAC key size must be greater than or equal to half the size of the hash function output. The keys may be stored in memory or in the private key database (key3.db).
• DSA public keys and private keys: The module supports DSA key sizes of 512-1024 bits. The keys may be stored in memory or in the private key database (key3.db).
• RSA public keys and private keys (used for digital signatures and key transport): The module supports RSA key sizes of 1024-8192 bits. The keys may be stored in memory or in the private key database (key3.db).
• EC public keys and private keys (used for ECDSA digital signatures and EC Diffie-Hellman key agreement): The module supports elliptic curve key sizes of 163-571 bits. (See the section "Non-NIST-Recommended Elliptic Curves" below.) The keys may be stored in memory or in the private key database (key3.db).
• Diffie-Hellman public keys and private keys (used for key agreement): The module supports Diffie-Hellman public key sizes of 1024-2236 bits. The keys may be stored in memory or in the private key database (key3.db).
• TLS premaster secret (used in deriving the TLS master secret): 48-byte. Stored in memory.
• TLS master secret (used in the generation of symmetric cipher keys, IVs, and MAC secrets for TLS): 48-byte. Stored in memory.
• seed key of the Approved random number generator: 256-bit. Stored in memory.
• authentication data (passwords): Stored in the private key database (key3.db).
• audited events and audit data (Security Level 2 only): Stored in the system audit logs.

Non-NIST-Recommended Elliptic Curves

The basic ECC version of the NSS cryptographic module only implements the NIST-Recommended elliptic curves P-256, P-384, and P-521 in FIPS 186-2.

The extended ECC version of the NSS cryptographic module implements all the NIST-Recommended elliptic curves 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 Services

The Crypto Officer role is assumed implicitly during installation of the module. The NSS User role is entered by authenticating, or logging in, to the module. Some services require the user to assume the NSS User role. Other services do not impose any role requirement.

Each service is provided by a PKCS #11 function. The following table lists the defined services and correlates role, service type and type of access to security-relavant information. Access type is Read/Write/Zeroize.

Service Category	Role	Function Name	Description	CSPs Accessed	Access type, e.g. RWZ
FIPS 140-2 specific		FC_GetFunctionList	return the list of FIPS 140-2 functions	none	-
Installation and Initialization
	Crypto Officer	FC_InitToken	initializes a token	all keys	Z
	Crypto Officer	FC_InitPIN	initializes the normal user's PIN	none	W
General purpose		FC_Initialize	initializes Cryptoki. This function provides the Power Up self-test service	none	R
		FC_Finalize	finalizes Cryptoki	all keys	Z
		FC_GetInfo	obtains general information about Cryptoki	none	-
Slot and token management		FC_GetSlotList	obtains a list of slots in the system	none	-
		FC_GetSlotInfo	obtains information about a particular slot	none	-
		FC_GetTokenInfo	obtains information about the token. This function provides the Show Status service	none	-
		FC_GetMechansimList	obtains a list of mechanisms supported by a token	none	-
		FC_GetMechanismInfo	obtains information about a particular mechanism	none	-
	NSS User	FC_SetPIN	modifies the PIN of the current user	password	RW
Session management		FC_OpenSession	opens a connection or "session" between an application and a particular token	none	-
		FC_CloseSession	closes a session	session's keys	Z
		FC_CloseAllSessions	closes all sessions with a token	all session keys	Z
		FC_GetSessionInfo	obtains information about the session	none	-
	NSS User	FC_GetOperationState	saves the state of the cryptographic operation in a session	none	-
	NSS User	FC_SetOperationState	restores the state of the cryptographic operation in a session	none	-
	NSS User	FC_Login	logs into a token	password	R
	NSS User	FC_Logout	logs out from a token	none	-
Object management	NSS User	FC_CreateObject	creates an object	key	W
	NSS User	FC_CopyObject	creates a copy of an object	original key new key	R W
	NSS User	FC_DestroyObject	destroys an object	key	Z
	NSS User	FC_GetObjectSize	obtains the size of an object in bytes	none	-
	NSS User	FC_GetAttributeValue	obtains an attribute value of an object	none	-
	NSS User	FC_SetAttributeValue	modifies an attribute value of an object	none	-
	NSS User	FC_FindObjectsInit	initializes an object search operation	none	-
	NSS User	FC_FindObjects	continues an object search operation	none	-
	NSS User	FC_FindObjectsFinal	finishes an object search operation	none	-
Encryption and decryption	NSS User	FC_EncryptInit	initializes an encryption operation	encryption key	R
	NSS User	FC_Encrypt	encrypts single-part data	encryption key	R
	NSS User	FC_EncryptUpdate	continues a multiple-part encryption operation	encryption key	R
	NSS User	FC_EncryptFinal	finishes a multiple-part encryption operation	encryption key	R
	NSS User	FC_DecryptInit	initializes a decryption operation	decryption key	R
	NSS User	FC_Decrypt	decrypts single-part encrypted data	decryption key	R
	NSS User	FC_DecryptUpdate	continues a multiple-part decryption operation	decryption key	R
	NSS User	FC_DecryptFinal	finishes a multiple-part decryption operation	decryption key	R
Message digesting		FC_DigestInit	initializes a message-digesting operation	none	R
		FC_Digest	digests single-part data	none	R
		FC_DigestUpdate	continues a multiple-part digesting operation	none	R
	NSS User	FC_DigestKey	continues a multi-part message-digesting operation by digesting the value of a secret key as part of the data already digested	key	R
	NSS User	FC_DigestFinal	finishes a multiple-part digesting operation	key	R
Signature and verification (private)	NSS User	FC_SignInit	initializes a signature operation	signing or HMAC key	R
	NSS User	FC_Sign	signs single-part data	signing or HMAC key	R
	NSS User	FC_SignUpdate	continues a multiple-part signature operation	signing or HMAC key	R
	NSS User	FC_SignFinal	finishes a multiple-part signature operation	signing or HMAC key	R
	NSS User	FC_SignRecoverInit	initializes a signature operation, where the data can be recovered from the signature	RSA signing key	R
	NSS User	FC_SignRecover	signs single-part data, where the data can be recovered from the signature	RSA signing key	R
	NSS User	FC_VerifyInit	initializes a verification operation	signature verification key or HMAC key	R
	NSS User	FC_Verify	verifies a signature on single-part data	signature verification key or HMAC key	R
	NSS User	FC_VerifyUpdate	continues a multiple-part verification operation	signature verification key or HMAC key	R
	NSS User	FC_VerifyFinal	finishes a multiple-part verification operation	signature verification key or HMAC key	R
	NSS User	FC_VerifyRecoverInit	initializes a verification operation where the data is recovered from the signature	RSA signature verification key	R
	NSS User	FC_VerifyRecover	verifies a signature on single-part data, where the data is recovered from the signature	RSA signature verification key	R
Dual-function cryptographic operations	NSS User	FC_DigestEncryptUpdate	continues a multiple-part digesting and encryption operation	encryption key	R
	NSS User	FC_DecryptDigestUpdate	continues a multiple-part decryption and digesting operation	decryption key	R
	NSS User	FC_SignEncryptUpdate	continues a multiple-part signing and encryption operation	signing or HMAC key and encryption key	R
	NSS User	FC_DecryptVerifyUpdate	continues a multiple-part decryption and verify operation	signature verification or HMAC key and decryption key	R
Key management (private)	NSS User	FC_GenerateKey	generates a secret key	key	W
	NSS User	FC_GenerateKeyPair	generates a public-key/private-key pair	key pair	W
	NSS User	FC_WrapKey	wraps (encrypts) a key	wrapping key wrapped key	R W
	NSS User	FC_UnwrapKey	unwraps (decrypts) a key	unwrapping key unwrapped key	R W
	NSS User	FC_DeriveKey	derives a key from a base key	base key derived key	R W
Random number generation (public)		FC_SeedRandom	mixes in additional seed material to the random number generator	RNG seed key	RW
		FC_GenerateRandom	generates random data. Performs continuous random number generator test	RNG seed key	RW
Function management		FC_GetFunctionStatus	obtains updated status of a function running in parallel with the application	none	-
		FC_CancelFunction	cancels a function running in parallel with the application	none	-
Callbacks		Notify	processes notifications from Cryptoki	none	-

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 Module Specification	2
2.0	Cryptographic Module Ports and Interfaces	2
3.0	Roles, Services, and Authentication	2
4.0	Finite State 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 Module Security Policy	2

Platform List

• Level 1
  • Red Hat Enterprise Linux 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
  • Red Hat Enterprise Linux 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.