MozillaWiki

Rolesandservices: Difference between revisions

Page Discussion

Rolesandservices (view source)

Revision as of 19:10, 9 March 2007

991 bytes added ,  9 March 2007
no edit summary
No edit summary
 
(64 intermediate revisions by 7 users not shown)
Line 3: Line 3:
== Specification of Roles ==
== 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 NSS cryptographic module supports two authorized roles for operators.


The Crypto Officer role is assumed to install the NSS libraries and initialize them to operate in FIPS 140-2 mode. See [http://wiki.mozilla.org/FIPS_Design_Assurance#Installation 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.
* 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 [http://wiki.mozilla.org/FIPS_Design_Assurance#Installation 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 ==
== Specification of Maintenance Roles ==
Line 15: Line 19:
=== Authentication Policy ===
=== 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.
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 ===
=== 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.
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 ===
=== Protection of Authentication Data ===


The NSS cryptographic module stores the user's password in a special encrypted form in the NSS key database -- NSS encrypts the fixed string <code>"password-check"</code> (not including the terminating null byte) with a Triple DES key derived (using PKCS #5) from the user's password, and stores the encrypted password check string in the key database. This encryption protects against unauthorized disclosure and modification of the user's password.
The NSS cryptographic module doesn't store the user's password; instead, it stores a <i>verifier</i> 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 <code>"password-check"</code> (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.
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.
Line 29: Line 33:
=== Initialization of Authentication Mechanism ===
=== 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.
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 <code>FC_InitPIN</code> to set the operator's initial password.
<div class=note>It is not necessary to call <code>FC_InitToken</code> to initialize the NSS cryptographic module. The NSS cryptographic module is initialized automatically when <code>FC_Initialize</code> is called for the first time. The Crypto Officer may call <code>FC_InitToken</code> to re-initialize the NSS cryptographic module.</div>


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.
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 [http://developer.mozilla.org/en/docs/FC_SetPIN FC_SetPIN] with both the old password and the new password as arguments.


=== Strength of Authentication Mechanism ===
=== Strength of Authentication Mechanism ===
Line 40: Line 49:
(These requirements are enforced by the function [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#sftk_newPinCheck <code>sftk_newPinCheck</code>], which is called by the functions [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#FC_InitPIN <code>FC_InitPIN</code>] and [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#FC_SetPIN <code>FC_SetPIN</code>].)
(These requirements are enforced by the function [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#sftk_newPinCheck <code>sftk_newPinCheck</code>], which is called by the functions [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#FC_InitPIN <code>FC_InitPIN</code>] and [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#FC_SetPIN <code>FC_SetPIN</code>].)


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 the correlation between them. We assume that
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 '''independent''' with each other, and
* the characters of the password are mutually '''independent''', and
* the probability of guessing an individual character of the password is < '''1/10'''.
* the probability of guessing an individual character of the password is < '''1/10'''.
<div class=note>'''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 correlated (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.</div>
<div class=note>'''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.</div>
Since the password is >= 7 characters long, the probability that a random guess of the password will succeed can be estimated as follows.
Since the password is >= 7 characters long, the probability that a random guess of the password will succeed can be estimated as follows.
   Let G be the event that a random guess of the password succeeds.
   Let Pr(G) be the probability that a random guess of the password succeeds.
  Let Gn be the event that a random guess of the password succeeds and
  the password is n characters long.
   Let pn be the probability that the password is n characters long.
   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
   Let Pr(G|n) be the conditional probability that a random guess of the
   password succeeds, given that the password is n characters long.
   password succeeds, given that the password is n characters long.
  By the definition of conditional probability, we have
      Pr(Gn) = Pr(G|n)*pn.
   Our assumptions imply that Pr(G|n) <= (1/10)^n, and that
   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
   Pr(G|m) < Pr(G|n) if m > n. (Intuitively, it is harder to guess a
   longer password.)  Since the event G is the union of the disjoint
   longer password.)  Since the events that the password is n characters
   events Gn for n >= 7, we have
   long, for all n >= 7, are mutually exclusive, we have
       Pr(G) = Pr(G7) + Pr(G8) + Pr(G9) + ...
       Pr(G) = Pr(G|7)*p7 + Pr(G|8)*p8 + Pr(G|9)*p9 + ...
            = 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 + Pr(G|7)*p8 + Pr(G|7)*p9 + ...
             = Pr(G|7)*(p7 + p8 + p9 + ...)
             = Pr(G|7)*(p7 + p8 + p9 + ...)
Line 64: Line 68:
             <=(1/10)^7 = 1/10,000,000.
             <=(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.
This exceeds the requirement AS03.25 that the probability shall be less than one in 1,000,000.
<div class=note>Note that we meet the requirement using the conditional probability Pr(G|7) rather than the unconditional 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 [http://wiki.mozilla.org/Rolesandservices#Feedback_of_Authentication_Data Feedback of Authentication Data], we use this result to argue that the obscured feedback of the authentication data does not weaken the authentication mechanism.</div>
<div class=note>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 [http://wiki.mozilla.org/Rolesandservices#Feedback_of_Authentication_Data Feedback of Authentication Data], we use this result to argue that the obscured feedback of the authentication data does not weaken the authentication mechanism.</div>


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 <code>PR_Sleep(loginWaitTime)</code> calls in the functions [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11.c.dep.html#NSC_SetPIN <code>NSC_SetPIN</code>] and [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11.c.dep.html#NSC_Login <code>NSC_Login</code>].) 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.
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 <code>PR_Sleep(loginWaitTime)</code> calls in the functions [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11.c.dep.html#NSC_SetPIN <code>NSC_SetPIN</code>] and [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11.c.dep.html#NSC_Login <code>NSC_Login</code>].) 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.
Line 70: Line 74:
=== Feedback of Authentication Data ===
=== 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 <code>pPin</code> argument to the [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#FC_Login <code>FC_Login</code>] 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.
The NSS cryptographic module has four PKCS #11 functions that take passwords as input arguments:
 
* <code>FC_InitToken</code>: <code>FC_InitToken</code> initializes the token. The <code>pPin</code> 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.)
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.
* <code>FC_InitPIN</code>: <code>FC_InitPIN</code> initializes the user's password. The <code>pPin</code> argument is the user's initial password.
 
* <code>FC_SetPIN</code>: <code>FC_SetPIN</code> changes the user's password. The <code>pOldPin</code> argument is the user's old password, and the <code>pNewPin</code> argument is the user's new password.
'''Example 1: No feedback'''. The NSS command-line utilities such as [http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html <code>certutil</code>] and [http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html <code>pk12util</code>] do not provide any visual feedback when the operator enters the password.  For example, the <code>certutil</code> commands below list the IDs of the private keys in the key database and then change the password.
* <code>FC_Login</code>: <code>FC_Login</code> logs the user into a token. The <code>pPin</code> argument is the user's 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 <code>certutil</code> utility doesn't provide any feedback of the entered password.


'''Example 2: Obscured feedback'''. Many applications, such as [http://www.mozilla.com/firefox/ 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.
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 (<code>CKR_OK</code>) or incorrect (<code>CKR_PIN_INCORRECT</code>);
* (when initializing or changing passwords) whether the new password contains invalid characters (<code>CKR_PIN_INVALID</code>), is too weak (<code>CKR_PIN_LEN_RANGE</code>), or is good (<code>CKR_OK</code>).


[[Image:Image-FIPSPasswordPrompt.png]]
The function return value does not provide information that could be used to guess or determine the user's password.
 
'''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.)
 
[[Image:FIPSChangePassword.png]]
 
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 [http://wiki.mozilla.org/Rolesandservices#Strength_of_Authentication_Mechanism 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.
<div class=note>'''Note''': If the password is known to be n characters long, the (conditional) probability that a random guess of password will succeed is Pr(G|n), using the notation in the section [http://wiki.mozilla.org/Rolesandservices#Strength_of_Authentication_Mechanism Strength of Authentication Mechanism]. Since n >= 7, we have Pr(G|n) <= Pr(G|7) <= 1/10,000,000, which is less than the requirement upper bound 1/1,000,000.</div>


== Multiple Concurrent Operator Roles and Services ==
== Multiple Concurrent Operator Roles and Services ==
The NSS module doesn't allow concurrent '''operators'''.
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).
* 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.
* On a multi-user operating system, this is enforced by creating the NSS certificate and key databases with the 0600 access permission bits.


<div class=note>
<div class=note>
'''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.
'''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 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.
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.
</div>
</div>


== Specification of Services ==
== 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:
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 ==
== Table II. Services ==
Line 133: Line 116:
|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
|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,
* 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
* performs power-up self-tests 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.
* enforces a pair-wise consistency test on all key pair generation algorithms and a continuous random number generator test.
NSS's FIPS 140-2 PKCS #11 implementation defines the following standard crypto API. See [http://www.rsasecurity.com/rsalabs/node.asp?id=2133 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.
The NSS cryptographic module's FIPS 140-2 PKCS #11 implementation defines the following standard crypto API. (See [http://www.rsasecurity.com/rsalabs/node.asp?id=2133 PKCS #11 v2.20] for more information.) Application programs get the PKCS #11 data type definitions and function declarations by including the header file [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11.h.html pkcs11.h], which includes the header files [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11t.h.html pkcs11t.h] (for types) and [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11f.h.html pkcs11f.h] (for functions).
|-
|-
|
|
General-purpose functions
General-purpose functions
* FC_GetFunctionList()
* <code>[http://developer.mozilla.org/en/docs/FC_GetFunctionList FC_GetFunctionList]</code>
* FC_Initialize()
* <code>[http://developer.mozilla.org/en/docs/FC_Initialize FC_Initialize]</code>
* FC_Finalize()
* <code>[http://developer.mozilla.org/en/docs/FC_Finalize FC_Finalize]</code>
* FC_GetInfo()
* <code>[http://developer.mozilla.org/en/docs/FC_GetInfo FC_GetInfo]</code>
Slot and token management functions
Slot and token management functions
* FC_GetSlotList()
* <code>[http://developer.mozilla.org/en/docs/FC_GetSlotList FC_GetSlotList]</code>
* FC_GetSlotInfo()
* <code>[http://developer.mozilla.org/en/docs/FC_GetSlotInfo FC_GetSlotInfo]</code>
* FC_GetTokenInfo()
* <code>[http://developer.mozilla.org/en/docs/FC_GetTokenInfo FC_GetTokenInfo]</code>
* FC_WaitForSlotEvent()
* <code>[http://developer.mozilla.org/en/docs/FC_WaitForSlotEvent FC_WaitForSlotEvent]</code>
* FC_GetMechanismList()
* <code>[http://developer.mozilla.org/en/docs/FC_GetMechanismList FC_GetMechanismList]</code>
* FC_GetMechanismInfo()
* <code>[http://developer.mozilla.org/en/docs/FC_GetMechanismInfo FC_GetMechanismInfo]</code>
* FC_InitToken()
* <code>[http://developer.mozilla.org/en/docs/FC_InitToken FC_InitToken]</code>
* FC_InitPIN()
* <code>[http://developer.mozilla.org/en/docs/FC_InitPIN FC_InitPIN]</code>
* FC_SetPIN()
* <code>[http://developer.mozilla.org/en/docs/FC_SetPIN FC_SetPIN]</code>
Session management functions
Session management functions
* FC_OpenSession()
* <code>[http://developer.mozilla.org/en/docs/FC_OpenSession FC_OpenSession]</code>
* FC_CloseSession()
* <code>[http://developer.mozilla.org/en/docs/FC_CloseSession FC_CloseSession]</code>
* FC_CloseAllSessions()
* <code>[http://developer.mozilla.org/en/docs/FC_CloseAllSessions FC_CloseAllSessions]</code>
* FC_GetSessionInfo()
* <code>[http://developer.mozilla.org/en/docs/FC_GetSessionInfo FC_GetSessionInfo]</code>
* FC_GetOperationState()
* <code>[http://developer.mozilla.org/en/docs/FC_GetOperationState FC_GetOperationState]</code>
* FC_SetOperationState()
* <code>[http://developer.mozilla.org/en/docs/FC_SetOperationState FC_SetOperationState]</code>
* FC_Login()
* <code>[http://developer.mozilla.org/en/docs/FC_Login FC_Login]</code>
* FC_Logout()
* <code>[http://developer.mozilla.org/en/docs/FC_Logout FC_Logout]</code>
Object management functions: certificates and keys
Object management functions: certificates and keys
* FC_CreateObject()
* <code>[http://developer.mozilla.org/en/docs/FC_CreateObject FC_CreateObject]</code>
* FC_CopyObject()
* <code>[http://developer.mozilla.org/en/docs/FC_CopyObject FC_CopyObject]</code>
* FC_DestroyObject()
* <code>[http://developer.mozilla.org/en/docs/FC_DestroyObject FC_DestroyObject]</code>
* FC_GetObjectSize()
* <code>[http://developer.mozilla.org/en/docs/FC_GetObjectSize FC_GetObjectSize]</code>
* FC_GetAttributeValue()
* <code>[http://developer.mozilla.org/en/docs/FC_GetAttributeValue FC_GetAttributeValue]</code>
* FC_SetAttributeValue()
* <code>[http://developer.mozilla.org/en/docs/FC_SetAttributeValue FC_SetAttributeValue]</code>
* FC_FindObjectsInit()
* <code>[http://developer.mozilla.org/en/docs/FC_FindObjectsInit FC_FindObjectsInit]</code>
* FC_FindObjects()
* <code>[http://developer.mozilla.org/en/docs/FC_FindObjects FC_FindObjects]</code>
* FC_FindObjectsFinal()
* <code>[http://developer.mozilla.org/en/docs/FC_FindObjectsFinal FC_FindObjectsFinal]</code>
Encryption functions: Triple DES and AES in ECB and CBC modes
Encryption functions: Triple DES and AES in ECB and CBC modes
* FC_EncryptInit()
* <code>[http://developer.mozilla.org/en/docs/FC_EncryptInit FC_EncryptInit]</code>
* FC_Encrypt()
* <code>[http://developer.mozilla.org/en/docs/FC_Encrypt FC_Encrypt]</code>
* FC_EncryptUpdate()
* <code>[http://developer.mozilla.org/en/docs/FC_EncryptUpdate FC_EncryptUpdate]</code>
* FC_EncryptFinal()
* <code>[http://developer.mozilla.org/en/docs/FC_EncryptFinal FC_EncryptFinal]</code>
Decryption functions: Triple DES and AES in ECB and CBC modes
Decryption functions: Triple DES and AES in ECB and CBC modes
* FC_DecryptInit()
* <code>[http://developer.mozilla.org/en/docs/FC_DecryptInit FC_DecryptInit]</code>
* FC_Decrypt()
* <code>[http://developer.mozilla.org/en/docs/FC_Decrypt FC_Decrypt]</code>
* FC_DecryptUpdate()
* <code>[http://developer.mozilla.org/en/docs/FC_DecryptUpdate FC_DecryptUpdate]</code>
* FC_DecryptFinal()
* <code>[http://developer.mozilla.org/en/docs/FC_DecryptFinal FC_DecryptFinal]</code>
Message digesting functions: SHA-1, SHA-256, SHA-384, and SHA-512
Message digesting functions: SHA-1, SHA-256, SHA-384, and SHA-512
* FC_DigestInit()
* <code>[http://developer.mozilla.org/en/docs/FC_DigestInit FC_DigestInit]</code>
* FC_Digest()
* <code>[http://developer.mozilla.org/en/docs/FC_Digest FC_Digest]</code>
* FC_DigestUpdate()
* <code>[http://developer.mozilla.org/en/docs/FC_DigestUpdate FC_DigestUpdate]</code>
* FC_DigestKey()
* <code>[http://developer.mozilla.org/en/docs/FC_DigestKey FC_DigestKey]</code>
* FC_DigestFinal()
* <code>[http://developer.mozilla.org/en/docs/FC_DigestFinal FC_DigestFinal]</code>
Signing and MACing functions: DSA, RSA, ECDSA, and HMAC
Signing and MACing functions: DSA, RSA, ECDSA, and HMAC
* FC_SignInit()
* <code>[http://developer.mozilla.org/en/docs/FC_SignInit FC_SignInit]</code>
* FC_Sign()
* <code>[http://developer.mozilla.org/en/docs/FC_Sign FC_Sign]</code>
* FC_SignUpdate()
* <code>[http://developer.mozilla.org/en/docs/FC_SignUpdate FC_SignUpdate]</code>
* FC_SignFinal()
* <code>[http://developer.mozilla.org/en/docs/FC_SignFinal FC_SignFinal]</code>
* FC_SignRecoverInit()
* <code>[http://developer.mozilla.org/en/docs/FC_SignRecoverInit FC_SignRecoverInit]</code>
* FC_SignRecover()
* <code>[http://developer.mozilla.org/en/docs/FC_SignRecover FC_SignRecover]</code>
Functions for verifying signatures and MACs: DSA, RSA, ECDSA, and HMAC
Functions for verifying signatures and MACs: DSA, RSA, ECDSA, and HMAC
* FC_VerifyInit()
* <code>[http://developer.mozilla.org/en/docs/FC_VerifyInit FC_VerifyInit]</code>
* FC_Verify()
* <code>[http://developer.mozilla.org/en/docs/FC_Verify FC_Verify]</code>
* FC_VerifyUpdate()
* <code>[http://developer.mozilla.org/en/docs/FC_VerifyUpdate FC_VerifyUpdate]</code>
* FC_VerifyFinal()
* <code>[http://developer.mozilla.org/en/docs/FC_VerifyFinal FC_VerifyFinal]</code>
* FC_VerifyRecoverInit()
* <code>[http://developer.mozilla.org/en/docs/FC_VerifyRecoverInit FC_VerifyRecoverInit]</code>
* FC_VerifyRecover()
* <code>[http://developer.mozilla.org/en/docs/FC_VerifyRecover FC_VerifyRecover]</code>
Dual-function cryptographic functions
Dual-function cryptographic functions
* FC_DigestEncryptUpdate()
* <code>[http://developer.mozilla.org/en/docs/FC_DigestEncryptUpdate FC_DigestEncryptUpdate]</code>
* FC_DecryptDigestUpdate()
* <code>[http://developer.mozilla.org/en/docs/FC_DecryptDigestUpdate FC_DecryptDigestUpdate]</code>
* FC_SignEncryptUpdate()
* <code>[http://developer.mozilla.org/en/docs/FC_SignEncryptUpdate FC_SignEncryptUpdate]</code>
* FC_DecryptVerifyUpdate()
* <code>[http://developer.mozilla.org/en/docs/FC_DecryptVerifyUpdate FC_DecryptVerifyUpdate]</code>
Key management functions
Key management functions
* FC_GenerateKey(): DSA domain parameters (PQG)
* <code>[http://developer.mozilla.org/en/docs/FC_GenerateKey FC_GenerateKey]</code>: DSA domain parameters (PQG), TLS pre_master key.
* FC_GenerateKeyPair(): DSA, RSA, and ECDSA. Performs pair-wise consistency test.
* <code>[http://developer.mozilla.org/en/docs/FC_GenerateKeyPair FC_GenerateKeyPair]</code>: DSA, RSA, and ECDSA. Performs pair-wise consistency test.
* FC_WrapKey(): RSA Key Wrapping
* <code>[http://developer.mozilla.org/en/docs/FC_WrapKey FC_WrapKey]</code>: RSA Key Wrapping
* FC_UnwrapKey(): RSA Key Wrapping
* <code>[http://developer.mozilla.org/en/docs/FC_UnwrapKey FC_UnwrapKey]</code>: RSA Key Wrapping
* FC_DeriveKey(): Diffie-Hellman, EC Diffie-Hellman
* <code>[http://developer.mozilla.org/en/docs/FC_DeriveKey FC_DeriveKey]</code>: Diffie-Hellman, EC Diffie-Hellman, TLS PRF, TLS master key
Random number generation functions
Random number generation functions
* FC_SeedRandom()
* <code>[http://developer.mozilla.org/en/docs/FC_SeedRandom FC_SeedRandom]</code>: Performs continuous random number generator test.
* FC_GenerateRandom(): Performs continuous random number generator test.
* <code>[http://developer.mozilla.org/en/docs/FC_GenerateRandom FC_GenerateRandom]</code>: Performs continuous random number generator test.
Parallel function management functions
Parallel function management functions
* FC_GetFunctionStatus()
* <code>[http://developer.mozilla.org/en/docs/FC_GetFunctionStatus FC_GetFunctionStatus]</code>
* FC_CancelFunction()
* <code>[http://developer.mozilla.org/en/docs/FC_CancelFunction FC_CancelFunction]</code>
|}
|}
|}
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 ==
{| border="1" cellpadding="2"
|+
|-
!
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 ==
== Show Status ==


The following PKCS #11 functions output the current status of the NSS module:
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:
* <code>FC_GetTokenInfo</code>: it fills in the <code>CK_TOKEN_INFO</code> structure with the following information:
** flags: bit flags indicating status of the NSS 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.
** <code>flags</code>: bit flags indicating status of the NSS cryptographic module
** ulSessionCount: number of sessions that this application currently has open with the NSS module
*** <code>CKF_WRITE_PROTECTED (0x00000002)</code>: true if the token is write-protected.
** ulRwSessionCount: number of read/write sessions that this application currently has open with the NSS module
*** <code>CKF_LOGIN_REQUIRED (0x00000004)</code>: true if there are some cryptographic functions that a user must be logged in to perform
* 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:
*** <code>CKF_USER_PIN_INITIALIZED (0x00000008)</code>: true if the user's password has been initialized.
** state: the state of the session, i.e., no role is assumed, the User role is assumed, or the Crypto Officer role is assumed
*** <code>CKF_TOKEN_INITIALIZED (0x00000400)</code>: 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. (<code>FC_Initialize</code> 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.)
** flags: whether the session is read/write or read-only
** <code>ulSessionCount</code>: number of sessions that this application currently has open with the NSS cryptographic module
 
** <code>ulRwSessionCount</code>: number of read/write sessions that this application currently has open with the NSS cryptographic module
The following high-level NSS functions output the current status of the NSS module:
* <code>FC_GetSessionInfo</code>: If the NSS cryptographic module is in the error state, <code>FC_GetSessionInfo</code> returns <code>CKR_DEVICE_ERROR</code>. Otherwise, it fills in the <code>CK_SESSION_INFO</code> structure with the following information:
* PK11_IsFIPS: returns a boolean indicating if the NSS module is in the FIPS mode.
** <code>state</code>: the state of the session, i.e., no role is assumed, the User role is assumed, or the Crypto Officer role is assumed
** <code>flags</code>: bit flags that define the type of session
*** <code>CKF_RW_SESSION (0x00000002)</code>: true if the session is read/write; false if the session is read-only.


== Perform Self-Tests ==
== 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 [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#FC_Login <code>FC_Login</code>] or the high-level NSS function [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/pk11wrap/pk11auth.c.dep.html#PK11_Authenticate <code>PK11_Authenticate</code>].
An operator can initiate the power-up self-tests on demand by shutting down and restarting the module with the <code>FC_Finalize</code> and <code>FC_Initialize</code> functions.


== Bypass Capabilities ==
== Bypass Capabilities ==


The NSS module has no bypass capability.
The NSS cryptographic module has no bypass capability.
Wtchang
canmove, Confirmed users
937

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/27879...51326"