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.2* Document revision date: 2006-08-25==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:{| border="1" cellpadding="2"|+|-!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.
|-| 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.chkThe 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.soStep 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_PATHStep 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.soThe 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.chkStep 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.
==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** sect239k1Although 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 or initialization of the module. The NSS User role is assumed explicitly 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-relevant information. Access type is Read/Write/Zeroize.
| ServiceCategory | Role | Function Name | Description | CSPs | Accesstype, |
| FIPS140-2 specific | FC_GetFunctionList | returnthe list of FIPS 140-2 functions | none | - | |
| Module Initialization | |||||
| Crypto Officer | FC_InitToken | initializes or re-initializesa token | password and all keys | Z | |
| Crypto Officer | FC_InitPIN | initializesthe normal user's password | password | W | |
| General | FC_Initialize | initializes the module library for the FIPS mode of operation. This function provides the power-up self-test service | none | - | |
| FC_Finalize | finalizes (shuts down) themodule library | all keys | Z | ||
| FC_GetInfo | obtainsgeneral information about the module library | none | - | ||
| Slotand | FC_GetSlotList | obtainsa list of slots in the system | none | - | |
| FC_GetSlotInfo | obtainsinformation about a particular slot | none | - | ||
| FC_GetTokenInfo | obtainsinformation about the token. This function provides the Show Statusservice. | none | - | ||
| FC_GetMechansimList | obtainsa list of mechanisms supported by a token | none | - | ||
| FC_GetMechanismInfo | obtainsinformation about a particular mechanism | none | - | ||
| NSS User | FC_SetPIN | changesthe password of the current user | password | RW | |
| Sessionmanagement | FC_OpenSession | opensa connection or "session" between an application and a particular token | none | - | |
| FC_CloseSession | closesa session | session's keys | Z | ||
| FC_CloseAllSessions | closesall sessions with a token | all keys | Z | ||
| FC_GetSessionInfo | obtainsinformation about the session | none | - | ||
| FC_GetOperationState | savesthe state of the cryptographic operation in a session. This function is only implemented for message digest operations. | none | - | ||
| FC_SetOperationState | restoresthe state of the cryptographic operation in a session. This function is only implemented for message digest operations. | none | - | ||
| NSS User | FC_Login | logsinto a token | password | R | |
| NSS User | FC_Logout | logsout from a token | none | - | |
| Object | NSS User | FC_CreateObject | createsan object | key | W |
| NSS User | FC_CopyObject | createsa copy of an object | original key new key | R W | |
| NSS User | FC_DestroyObject | destroysan object | key | Z | |
| NSS User | FC_GetObjectSize | obtainsthe size of an object in bytes | key | R | |
| NSS User | FC_GetAttributeValue | obtainsan attribute value of an object | key | R | |
| NSS User | FC_SetAttributeValue | modifiesan attribute value of an object | key | W | |
| NSS User | FC_FindObjectsInit | initializesan object search operation | none | - | |
| NSS User | FC_FindObjects | continuesan object search operation | keys matching the search criteria | R | |
| NSS User | FC_FindObjectsFinal | finishesan object search operation | none | - | |
| Encryption and | NSS User | FC_EncryptInit | initializesan encryption operation | encryption key | R |
| NSS User | FC_Encrypt | encryptssingle-part data | encryption key | R | |
| NSS User | FC_EncryptUpdate | continuesa multiple-part encryption operation | encryption key | R | |
| NSS User | FC_EncryptFinal | finishesa multiple-part encryption operation | encryption key | R | |
| NSS User | FC_DecryptInit | initializesa decryption operation | decryption key | R | |
| NSS User | FC_Decrypt | decryptssingle-part encrypted data | decryption key | R | |
| NSS User | FC_DecryptUpdate | continuesa multiple-part decryption operation | decryption key | R | |
| NSS User | FC_DecryptFinal | finishesa multiple-part decryption operation | decryption key | R | |
| Message | FC_DigestInit | initializesa message-digesting operation | none | - | |
| FC_Digest | digestssingle-part data | none | - | ||
| FC_DigestUpdate | continuesa multiple-part digesting operation | none | - | ||
| NSS User | FC_DigestKey | continuesa multi-part message-digesting operation by digesting the value of asecret key as part of the data already digested | key | R | |
| FC_DigestFinal | finishesa multiple-part digesting operation | none | - | ||
| Signature and | NSS User | FC_SignInit | initializesa signature operation | signing/HMAC key | R |
| NSS User | FC_Sign | signssingle-part data | signing/HMAC key | R | |
| NSS User | FC_SignUpdate | continuesa multiple-part signature operation | signing/HMAC key | R | |
| NSS User | FC_SignFinal | finishesa multiple-part signature operation | signing/HMAC key | R | |
| NSS User | FC_SignRecoverInit | initializesa signature operation, where the data can be recovered from thesignature | RSA signing key | R | |
| NSS User | FC_SignRecover | signssingle-part data, where the data can be recovered from the signature | RSA signing key | R | |
| NSS User | FC_VerifyInit | initializesa verification operation | verification/HMAC key | R | |
| NSS User | FC_Verify | verifiesa signature on single-part data | verification/HMAC key | R | |
| NSS User | FC_VerifyUpdate | continuesa multiple-part verification operation | verification/HMAC key | R | |
| NSS User | FC_VerifyFinal | finishesa multiple-part verification operation | verification/HMAC key | R | |
| NSS User | FC_VerifyRecoverInit | initializesa verification operation where the data is recovered from the signature | RSA verificationkey | R | |
| NSS User | FC_VerifyRecover | verifiesa signature on single-part data, where the data is recovered from thesignature | RSA verificationkey | R | |
| Dual-function | NSS User | FC_DigestEncryptUpdate | continuesa multiple-part digesting and encryption operation | encryption key | R |
| NSS User | FC_DecryptDigestUpdate | continuesa multiple-part decryption and digesting operation | decryption key | R | |
| NSS User | FC_SignEncryptUpdate | continuesa multiple-part signing and encryption operation | signing/HMAC key encryption key | R R | |
| NSS User | FC_DecryptVerifyUpdate | continuesa multiple-part decryption and verify operation | decryption key verification/HMAC key | R R | |
| Key | NSS User | FC_GenerateKey | generatesa secret key | key | W |
| NSS User | FC_GenerateKeyPair | generatesa public-key/private-key pair | key pair | W | |
| NSS User | FC_WrapKey | wraps(encrypts) a key | wrapping key key to be wrapped | R R | |
| NSS User | FC_UnwrapKey | unwraps(decrypts) a key | unwrapping key unwrapped key | R W | |
| NSS User | FC_DeriveKey | derivesa key from a base key | base key derived key | R W | |
| Randomnumber | FC_SeedRandom | mixesin additional seed material to the random number generator | RNG seed key | RW | |
| FC_GenerateRandom | generatesrandom data. Performs continuous random number generator test | RNG seed key | RW | ||
| Parallel function management | FC_GetFunctionStatus | a legacy function, which simply returns the value 0x00000051 (function not parallel) | none | - | |
| FC_CancelFunction | a legacy function, which simply returns the value 0x00000051 (function not parallel) | none | - |
== Mitigation of Other Attacks ==The NSS cryptographic module is designed to mitigate the followingattacks.{| border="1" cellpadding="2"|+|-!Other Attacks!Mitigation Mechanism!Specific Limitations|-| Timing attacks on RSA|| RSA blindingTiming 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 exponentiationThis 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 signaturesArithmetical 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.