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 cryptographic module libraries. See Installation. 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.

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 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 NSS User's initial password. From then on, the operator only assumes the NSS User role.

It is not necessary to call FC_InitToken to initialize the NSS cryptographic module. The NSS cryptographic module is initialized automatically when FC_Initialize is called for the first time. The Crypto Officer may call FC_InitToken to re-initialize the NSS cryptographic module.

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.

Note: Since we allow digits (10), lowercase (26) and uppercase (26) letters, and punctuation marks (>= 18) in passwords, the probability of guessing an individual character of the password should be <= 1/(10+26+26+18) = 1/80. But in practice operators do not choose from all the allowed characters with equal probabilities, and the chosen characters are not independent (e.g., they usually form a word). Our requirement of three or more character classes reduces these effects but cannot eliminate them. To compensate for these effects in our model of independent characters with uniform probability distribution, we use a conservative upper bound of 1/10 on the probability of guessing an individual character of the password.

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.

Note that we meet the requirement using the conditional probability Pr(G|7) rather than the a priori probability Pr(G). This means the strength of the authentication mechanism meets the requirement even if the attacker knows the length of the password. In the section on Feedback of Authentication Data, we use this result to argue that the obscured feedback of the authentication data does not weaken the authentication mechanism.

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 or re-initializes the token. The pPin argument is the Security Officer's initial password. (The Security Officer in PKCS #11 is roughly equivalent to the crypto officer in FIPS 140-2.) FC_InitToken ignores the pPin argument because the NSS cryptographic module doesn't have a 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.

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 NSS cryptographic 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 cryptographic 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

The PKCS #11 API is a crypto API based on the PKCS #11 standard and 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 module start-up as well as on demand for subsequent logins, and enforces a pair-wise consistency test on all key generation algorithms and a continuous random number generator test. NSS cryptographic module's FIPS 140-2 PKCS #11 implementation defines the following standard crypto API. See PKCS #11 v2.20 for the purpose, function, and the specification of inputs and outputs of each API routine. Here we only describe the deviation of our implementation from the standard, such as algorithm restrictions and conditional self-tests performed in FIPS mode. General-purpose functions FC_GetFunctionList FC_Initialize FC_Finalize FC_GetInfo Slot and token management functions FC_GetSlotList FC_GetSlotInfo FC_GetTokenInfo FC_WaitForSlotEvent FC_GetMechanismList FC_GetMechanismInfo FC_InitToken FC_InitPIN FC_SetPIN Session management functions FC_OpenSession FC_CloseSession FC_CloseAllSessions FC_GetSessionInfo FC_GetOperationState FC_SetOperationState FC_Login FC_Logout Object management functions: certificates and keys FC_CreateObject FC_CopyObject FC_DestroyObject FC_GetObjectSize FC_GetAttributeValue FC_SetAttributeValue FC_FindObjectsInit FC_FindObjects FC_FindObjectsFinal Encryption functions: Triple DES and AES in ECB and CBC modes FC_EncryptInit FC_Encrypt FC_EncryptUpdate FC_EncryptFinal Decryption functions: Triple DES and AES in ECB and CBC modes FC_DecryptInit FC_Decrypt FC_DecryptUpdate FC_DecryptFinal Message digesting functions: SHA-1, SHA-256, SHA-384, and SHA-512 FC_DigestInit FC_Digest FC_DigestUpdate FC_DigestKey FC_DigestFinal Signing and MACing functions: DSA, RSA, ECDSA, and HMAC FC_SignInit FC_Sign FC_SignUpdate FC_SignFinal FC_SignRecoverInit FC_SignRecover Functions for verifying signatures and MACs: DSA, RSA, ECDSA, and HMAC FC_VerifyInit FC_Verify FC_VerifyUpdate FC_VerifyFinal FC_VerifyRecoverInit FC_VerifyRecover Dual-function cryptographic functions FC_DigestEncryptUpdate FC_DecryptDigestUpdate FC_SignEncryptUpdate FC_DecryptVerifyUpdate Key management functions FC_GenerateKey: DSA domain parameters (PQG), TLS pre_master key. FC_GenerateKeyPair: DSA, RSA, and ECDSA. Performs pair-wise consistency test. FC_WrapKey: RSA Key Wrapping FC_UnwrapKey: RSA Key Wrapping FC_DeriveKey: Diffie-Hellman, EC Diffie-Hellman, TLS PRF, TLS master key Random number generation functions FC_SeedRandom: Performs continuous random number generator test. FC_GenerateRandom: Performs continuous random number generator test. Parallel function management functions FC_GetFunctionStatus FC_CancelFunction

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.
      Note: the NSS cryptographic module does not use the related CKF_TOKEN_INITIALIZED (0x00000400) flag because the module is never in the uninitialized state. FC_Initialize automatically initializes the module if it is not 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 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 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.