Rolesandservices
This is a draft document.
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 utilizes secure services and is also responsible for the retrieval, updating, and deletion of keys from his key database.
The Crypto Officer role is assumed to install the NSS libraries and initialize them to operate in FIPS 140-2 mode. See Installation. The Crypto Officer must control the access to the module both before and after initialization. Control consists of management of physical access to the computer executing the NSS code as well as management of the security facilities provided by the operating system.
Specification of Maintenance Roles
This section is not applicable to the NSS cryptographic module since it does not have a Maintenance Role.
Operator Authentication
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). An NSS User may use a product (e.g., Mozilla Firefox) without establishing a personal private key -- e.g., they may utilize SSL Server Authentication without having a private key established. However, to enable SSL on a server product, a private key and public key certificate are required to enable secure services. An individual password is required in order to start the server -- this password is used to decrypt the private key.
Clearing of Previous Authentications on Power Off
The results of authentications are in memory, so they are automatically cleared when the process accessing the NSS module terminates or the general purpose computer is powered off.
Protection of Authentication Data
The NSS cryptographic module doesn't store the user's password; instead, it stores a verifier for the user's password in the NSS key database. The NSS cryptographic module derives a Triple DES key from the user's password (using PKCS #5), encrypts the fixed string "password-check" (not including the terminating null byte) with the key, and stores the encrypted password check string as the verifier in the key database. It is computationally infeasible to obtain the password from the verifier. This protects against unauthorized disclosure and modification of the user's password.
Recall that all the private and secret keys stored in the NSS key database are encrypted with the same Triple DES key derived from the user's password. If an attacker gains access to the key database on a single-user system or can bypass the discretionary access control on the key database on a multi-user system, it is possible for the attacker to replace the encrypted password check string in the key database with a password check string encrypted with a key derived from his own password, effectively substituting his password for the user's password. Although the attacker will be able to log in to the NSS cryptographic module with his password, he won't be able to see any of the private and secret keys in the key database because he can't decrypt them.
Initialization of Authentication Mechanism
The operator (implicitly) assumes the Crypto Officer role when installing the NSS library files. Once the NSS library files are installed on the system, the Crypto Officer calls the PKCS #11 function FC_InitToken to initialize the NSS cryptographic module, and calls the function FC_InitPIN to set the NSS User's initial password. From then on, the operator only assumes the NSS User role.
Since the NSS cryptographic module does not use a factory-set or default password to authenticate the operator for the first time the module is accessed, login to the general purpose computer is used to control access to the module before it is initialized. If the general purpose computer is not protected with a system login password, procedural controls or physical access control must be used to control access to the computer before the module is initialized.
Change of Authentication Data
To change the password, call the function FC_SetPIN with both the old password and the new password as arguments.
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.
(These requirements are enforced by the function sftk_newPinCheck, which is called by the functions FC_InitPIN and FC_SetPIN.)
To estimate the probability that a random guess of the password will succeed, we have to make some assumptions about the probability distribution of the individual characters of the password and their joint probabilities. We assume that
- the characters of the password are mutually independent, 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 can be estimated as follows.
Let Pr(G) be the probability that a random guess of the password succeeds.
Let pn be the probability that the password is n characters long.
Let Pr(G|n) be the conditional probability that a random guess of the
password succeeds, given that the password is n characters long.
Our assumptions imply that Pr(G|n) <= (1/10)^n, and that
Pr(G|m) < Pr(G|n) if m > n. (Intuitively, it is harder to guess a
longer password.) Since the events that the password is n characters
long, for all n >= 7, are mutually exclusive, we have
Pr(G) = Pr(G|7)*p7 + Pr(G|8)*p8 + Pr(G|9)*p9 + ...
< Pr(G|7)*p7 + Pr(G|7)*p8 + Pr(G|7)*p9 + ...
= Pr(G|7)*(p7 + p8 + p9 + ...)
= Pr(G|7)
<=(1/10)^7 = 1/10,000,000.
This exceeds the requirement AS03.25 that the probability shall be less than one in 1,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. (See the PR_Sleep(loginWaitTime) calls in the functions NSC_SetPIN and NSC_Login.) 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). This exceeds the requirement AS03.26 that the probability shall be less than one in 100,000.
Feedback of Authentication Data
The NSS cryptographic module doesn't have its own routine for password entry because NSS-based applications use different user interface toolkits. Instead, each NSS-based application needs to implement its own password entry routine and pass the entered password as the pPin argument to the FC_Login function of the NSS cryptographic module. Therefore, the FIPS 140-2 requirements on the feedback of authentication data (AS03.27 and AS03.28) do not apply to the NSS cryptographic module.
We give three examples of the feedback of passwords provided by NSS-based applications to illustrate how NSS-based applications meet the requirements of AS03.27 and AS03.28.
Example 1: No feedback. The NSS command-line utilities such as certutil and pk12util do not provide any visual feedback when the operator enters the password. For example, the certutil commands below list the IDs of the private keys in the key database and then change the password.
$ certutil -K -d . Enter Password or Pin for "NSS FIPS 140-2 Certificate DB": Enter Password or Pin for "NSS FIPS 140-2 Certificate DB": <0> $ certutil -W -d . Enter Password or Pin for "NSS FIPS 140-2 Certificate DB": Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: Password changed successfully. $
The certutil utility doesn't provide any feedback of the entered password.
Example 2: Obscured feedback. Many applications, such as Mozilla Firefox, provide obscured feedback when the operator enters the password. Each character entered is represented by an asterisk (*). The only information provided by the obscured feedback is the length of the password. The figure below is a screen shot of Mozilla Firefox's password prompt.
Example 3: Feedback on password strength. When the operator changes the password, some applications provide an indication of the strength of the new password to help the operator choose a strong password. The figure below shows the password quality meter in Mozilla Firefox's Change Master Password prompt. (Note that the current and new passwords are obscured.)
If the length of the password is known or the password quality is known to be low, it does weaken the strength of the authentication mechanism. This is why the NSS cryptographic module imposes a minimum password quality, so that even with the knowledge of the password length or quality, the probability of guessing the password is still less than the required upper bound.
Multiple Concurrent Operator Roles and Services
The NSS 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 creating the NSS certificate and key databases with the 0600 access permission bits.
Note: The NSS 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 NSS module needs to assume a role separately. The separation between the roles and services performed by concurrent processes is enforced by the process protection of the underlying operating system.
The NSS module also allows a process to open multiple concurrent sessions (connections) with the module. PKCS #11 requires that 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). Therefore, the separation of the roles assumed by concurrent sessions and the corresponding services isn't an issue.
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 they are public, meaning that they require no authentication to utilize, or private, meaning that authentication must be provided before the routine is utilized. 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 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 |
|
Table III below specifies the services provided by the high-level NSS libraries above the NSS module. Table III is incomplete and is provided for informational purposes only.
Table III. High-Level Services
|
Name of Service |
Description of Service in Terms of Routines |
|---|---|
| Certificate Storage and Retrieval | [Out of date] This private service consists of six routines used to perform certificate storage and retrieval including SEC_OpenPermCertDB(), AddCertToPermDB(), SEC_TraversePermCerts(), SEC_FindPermCertByKey(), SEC_DeletePermCertificate(), and CERT_ClosePermCertDB(). |
| Digital Signatures | This private service consists of the routines used to perform signature generation (...) and the routines used to perform signature verification (...). In general, the key generation service must be invoked prior to invoking this service. |
| Encryption/Decryption | This private service consists of the routines used to perform Encryption/Decryption (...). |
| Hashing | This public service consists of the routines used to perform hashing including (...). |
| Key Generation | This private service is utilized to perform key generation and consists of the routines used to perform DSA domain parameter generation including (...), and the routines used for DSA, RSA, and ECDSA key pair generation (...). Pair-wise consistency test is performed on new key pairs. |
| PKCS #5 Password-Based Encryption | The PKCS #5 API specifies a standard interface based upon the PKCS #5 standard which allows this private service to be used to perform password-based encryption and consists of the five routines including SEC_PKCS5GetCryptoAlgorithm(), SEC_PKCS5GetIV(), SEC_PKCS5GetKeyLength(), SEC_PKCS5GetPBEAlgorithm(), and SEC_PKCS5IsAlgorithmPBEAlg(). |
| Private Key Storage and Retrieval | [Out of date] This private service is utilized to perform private key storage and retrieval and consists of the seven routines including SECKEY_OpenKeyDB(), SECKEY_TraverseKeys(), SECKEY_UpdateKeyDBPass1() SECKEY_UpdateKeyDBPass2(), SECKEY_FindKeyByPublicKey(), SECKEY_DeleteKey(), and SECKEY_CloseKeyDB(). |
| Pseudorandom Number Generation | This public service consists of the two routines used for global pseudorandom number generation -- PK11_GenerateRandomOnSlot and PK11_GenerateRandom -- and the two routines used for seeding pseudorandom number generation -- PK11_SeedRandom and PK11_RandomUpdate. A continuous random number generator test is performed whenever a new pseudorandom number is generated. |
| TLS pseudorandom function (PRF) | TLS pseudorandom function (PRF) is utilized by the TLS protocol to produce FIPS 140-2 compliant hashes of security relevant data items (pre-master secret). |
Show Status
The following PKCS #11 functions output the current status of the NSS cryptographic module:
- FC_GetTokenInfo: it fills in the CK_TOKEN_INFO structure with the following information:
- flags: bit flags indicating status of the NSS cryptographic module, such as whether there are some cryptographic functions that a user must be logged in to perform, whether the user's password has been initialized, whether the module has been initialized.
- ulSessionCount: number of sessions that this application currently has open with the NSS cryptographic module
- ulRwSessionCount: number of read/write sessions that this application currently has open with the NSS cryptographic module
- FC_GetSessionInfo: If the NSS module is in the error state, FC_GetSessionInfo returns CKR_DEVICE_ERROR. Otherwise, it fills in the CK_SESSION_INFO structure with the following information:
- state: the state of the session, i.e., no role is assumed, the User role is assumed, or the Crypto Officer role is assumed
- flags: whether the session is read/write or read-only
Perform Self-Tests
An operator who is already logged in can initiate and run the power-up self-tests by logging into the module again with a call to the PKCS #11 function FC_Login.
Bypass Capabilities
The NSS cryptographic module has no bypass capability.