Rolesandservices

This is a draft document.

Specification of Roles

The NSS cryptographic module supports two authorized roles for operators.

• 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 private key database. An NSS User utilizes secure services and is also responsible for the retrieval, updating, and deletion of keys from the private key database.

• The Crypto Officer Role is supported for the installation (see Installation) and initialization of the module. The Crypto Officer must control the access to the module both before and after installation. Control consists of management of physical access to the computer executing the NSS cryptographic module code as well as management of the security facilities provided by the operating system.

The NSS cryptographic module uses a combined role approach -- by authenticating to the module, an operator assumes both the NSS User Role and the Crypto Officer Role at the same time.

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 -- this password is used to encrypt and decrypt the user's private key. However, Discretionary Access Control (DAC) is used to safeguard all other NSS User information (e.g., the public key certificate database).

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 cryptographic 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 cryptographic module library files. Once the NSS cryptographic module library files are installed on the system, the Crypto Officer calls the function FC_InitPIN to set the operator's initial password.

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 has four PKCS #11 functions that take passwords as input arguments:

• FC_InitToken: FC_InitToken initializes the token. The pPin argument is the Security Officer's initial password. (The Security Officer in PKCS #11 has a very limited role: to initialize the token and to set the normal user's password. For our module, the Security Officer is roughly equivalent to the crypto officer role.)
• FC_InitPIN: FC_InitPIN initializes the user's password. The pPin argument is the user's initial password.
• FC_SetPIN: FC_SetPIN changes the user's password. The pOldPin argument is the user's old password, and the pNewPin argument is the user's new password.
• FC_Login: FC_Login logs the user into a token. The pPin argument is the user's password.

When passwords are passed to these functions as input arguments, there is no visible display of the passwords, and the only feedback mechanism is the function return value. The function return value gives away the following information about the password:

• whether the entered password is correct (CKR_OK) or incorrect (CKR_PIN_INCORRECT);
• (when initializing or changing passwords) whether the new password contains invalid characters (CKR_PIN_INVALID), is too weak (CKR_PIN_LEN_RANGE), or is good (CKR_OK).

The function return value does not provide information that could be used to guess or determine the user's password.

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 creating the NSS certificate and key databases with the 0600 access permission bits.

Specification of Services

Since the Crypto Officer's functions are limited to module installation and initialization, the NSS User has access to all the services. Routines have been specified for each service and denoted whether they are public services, meaning that they require no authentication to utilize, or private services, meaning that authentication must be provided before the routine is utilized. This model allows a type of safety state by allowing an operator to log out (thus disallowing any access to private services) without ending the session, and then log back in to re-authenticate into private services rendered by the cryptographic module. All public and private services are listed in the following table:

Table II. Services

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
    • CKF_WRITE_PROTECTED (0x00000002): true if the token is write-protected.
    • CKF_LOGIN_REQUIRED (0x00000004): true if there are some cryptographic functions that a user must be logged in to perform
    • CKF_USER_PIN_INITIALIZED (0x00000008): true if the user's password has been initialized.
    • CKF_TOKEN_INITIALIZED (0x00000400): true if the token has been initialized. If login is required (which is true for the FIPS mode of operation), this flag means the user's password has been initialized. (FC_Initialize automatically creates the certificate and private key databases if they don't exist, so whether the module is initialized or not is entirely determined by the existence of the user's password.)
  • 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 cryptographic 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: bit flags that define the type of session
    • CKF_RW_SESSION (0x00000002): true if the session is read/write; false if the session is read-only.

Perform Self-Tests

An operator can initiate the power-up self-tests on demand by shutting down and restarting the module with the FC_Finalize and FC_Initialize functions.

Bypass Capabilities

The NSS cryptographic module has no bypass capability.