Relyea: /* Operational Environment */

==Operational Environment==

The operational environment for the NSS cryptographic module is a general purpose, modifiable operational environment that uses one of the following commercially-available operating systems:

* Security Level 1
** Red Hat Enterprise Linux Version 6 32 bit
** Red Hat Enterprise Linux Version 6 64 bit

==Single Operator Mode of Operation==

All the major general purpose operating systems today are multi-user OS. When the NSS cryptographic module is used at Security Level 1, only one user account should be created in the OS. The following explains how to configure each OS for single user.

===Mac OS X Instructions===

To delete other user accounts
# Log into your user account.
# From the '''Apple''' menu, choose '''System Preferences'''.
# From the '''View''' menu, choose '''Accounts'''.
# All the user accounts are listed on the left hand side of the '''Accounts''' dialog. Your user account is listed under '''My Account''' and should have Admin privilege. If there is no user account under '''Other Accounts''', stop here. Otherwise, follow the steps below to delete the other accounts.
# If the lock icon at the lower left corner of the '''Accounts''' dialog is locked, click the lock to make changes.
# Select a user account under '''Other Accounts'''.
# Click the minus sign (-) at the lower left corner of the '''Accounts''' dialog to delete the selected user account.
# Repeat the above two steps until there is no user account under '''Other Accounts'''.

To turn off remote login and other services
# Log into your user account.
# From the '''Apple''' menu, choose '''System Preferences'''.
# From the '''View''' menu, choose '''Sharing'''.
# In the '''Sharing''' dialog, select the '''Services''' tab. All the services are listed under the message "Select a service to change its settings." If none of the checkboxes is checked, stop here. Otherwise, follow the steps below.
# If the lock icon at the lower left corner of the '''Sharing''' dialog is locked, click the lock to make changes.
# Unckeck all the checkboxes, including '''Remote Login''', '''FTP Access''', and '''Apple Remote Desktop'''.

See also
* NSA, ''[http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_systems.shtml NSA Security Configuration Guide]
* [http://www.nsa.gov/applications/links/notices.cfm?address=http://images.apple.com/support/security/guides/docs/Leopard_Security_Config_2nd_Ed.pdf Mac OS X Security Configuration for Version 10.5 Leopard Second Edition]''

===Unix Instructions===
The general idea is the same across all Unix variants.
* Remove all login accounts except "root" (the superuser).
* Disable NIS and other name services for users and groups.
* Turn off all remote login, remote command execution, and file transfer daemons.

The specific procedures for each of the UNIX variants are described below.

'''Red Hat Enterprise Linux'''
# Log in as the "root" user.
# Edit the system files <code>/etc/passwd</code> and <code>/etc/shadow</code> and remove all the users except "root" and the pseudo-users. Make sure the password fields in <code>/etc/shadow</code> for the pseudo-users are either a star (*) or double exclamation mark (!!). This prevents login as the pseudo-users.
# Edit the system file <code>/etc/nsswitch.conf</code> and make <code>files</code> the only option for <code>passwd</code>, <code>shadow</code>, and <code>group</code>. This disables NIS and other name services for users and groups.
# In the <code>/etc/xinetd.d</code> directory, edit the files <code>eklogin</code>, <code>gssftp</code>, <code>klogin</code>, <code>krb5-telnet</code>, <code>kshell</code>, <code>rexec</code>, <code>rlogin</code>, <code>rsh</code>, <code>rsync</code>, <code>telnet</code>, and <code>tftp</code>, and set the value of <code>disable</code> to <code>yes</code>.
# Reboot the system for the changes to take effect.

See also
* NSA, ''[http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_systems.shtml NSA Security Configuration Guide]
* ''[http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
Guide to the Secure Configuration of Red Hat Enterprise Linux 5]''

'''Solaris'''
# Log in as the "root" user.
# Edit the system files <code>/etc/passwd</code> and <code>/etc/shadow</code> and remove all the users except "root" and the pseudo-users. Make sure the password fields in <code>/etc/shadow</code> for the pseudo-users are either a star (*) or NP. This prevents login as the pseudo-users.
# Edit the system file <code>/etc/nsswitch.conf</code> and make <code>files</code> the only option for <code>passwd</code>, <code>shadow</code>, and <code>group</code>. This disables NIS and other name services for users and groups.
# In the <code>/etc/inetd.d</code> directory, edit the files <code>eklogin</code>, <code>gssftp</code>, <code>klogin</code>, <code>krb5-telnet</code>, <code>kshell</code>, <code>rexec</code>, <code>rlogin</code>, <code>rsh</code>, <code>rsync</code>, <code>telnet</code>, and <code>tftp</code>, and set the value of <code>disable</code> to <code>yes</code>.
# Reboot the system for the changes to take effect.

See also
* NSA, ''[http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_systems.shtml NSA Security Configuration Guide]
* ''[http://www.nsa.gov/ia/_files/os/sunsol_10/s10-cis-appendix-v1.1.pdf
An Overview of Solaris 10 Operating System Security Controls ]''

===Windows XP Instructions===

# Log on with your user account.
# Click '''Start > Control Panel > User Accounts'''.
# Make sure the '''Guest''' account is off. If the Guest account is on, click its icon and click "Turn off the guest account" to turn it off.
# Follow the steps below to delete the other accounts. <div class=note>'''Note:''' User Accounts may show some accounts that are used by programs. For example, '''ASP.NET Machine Account''' (shown as '''ASP.NET Machine A...''' in User Accounts) is used by Microsoft .NET Framework 1.1 for running the ASN.NET worker process (aspnet_wp.exe), and '''SQLDebugger''' is used by Microsoft Visual Studio .NET Debugger. Deleting such accounts could cripple the programs using these accounts. As a precaution, remove those programs before deleting these accounts.</div>
# Click the icon of an account other than your own account and the '''Guest''' account.
# Click "Delete the account".
# Repeat the above two steps until all the accounts other than your own account and the '''Guest''' account have been deleted.

See also
* [http://csrc.ncsl.nist.gov/publications/nistpubs/index.html#sp800-68 SP 800-68 Guidance for Securing Microsoft Windows XP Systems for IT Professionals: A NIST Security Configuration Checklist]. Section 6.5 ''System Services'' explains how to disable unnecessary services such as '''NetMeeting Remote Desktop Sharing''' and '''Telnet''' to reduce the number of attack vectors against the system. Section 7.2.1 ''Built-in Accounts'' explains how to disable default user accounts, which are often used in exploits against computer systems. Note that the recommendation in Section 7.2.3 ''Daily Use Accounts'' is at odds with the single operator mode of operation requirement of FIPS 140-2 Security Level 1.
* [http://csrc.ncsl.nist.gov/publications/nistpubs/index.html#sp800-69 Draft SP 800-69 Draft Special Publication 800-69, Guidance for Securing Microsoft Windows XP Home Edition: A NIST Security Configuration Checklist]. Read Appendix B.2 ''Disable Default User Accounts'' and Appendix B.5 ''Disable Unneeded Services''. Note that Appendix A ''Essential Security Settings'', Step 6: ''Set Up Limited User Accounts'' is at odds with the single operator mode of operation requirement of FIPS 140-2 Security Level 1.
* [http://www.nsa.gov/ia/_files/os/winxp/NSA_Windows_XP_Security_Guide_Addendum.pdf NSA Windows XP Security Guide Addendum]
* [http://www.nsa.gov/ia/_files/os/winxp/Windows_XP_Security_Guide_v2.2.zip Zipped Windows XP Security Configuration Guides]

==Software Integrity Test==

The [http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf Digital Signature Algorithm (DSA)] is used as the Approved authentication technique ([http://csrc.nist.gov/cryptval/dss/dsaval.htm#172 validation certificate# 172]) for the integrity test of the software components. [http://wiki.mozilla.org/FIPS_Module_Specification#Module_Components Software components ] protected using the digital signatures are the softoken (PKCS #11) and freebl libraries (e.g., libsoftokn3.so and libfreebl3.so). (See [http://www.mozilla.org/projects/security/pki/nss/fips/secpolicy.pdf Security Policy Rule #33] for a list of module files by platform.) When the softoken and freebl libraries are built, a DSA public/private key pair with a 1024-bit prime modulus p is generated, the private key is used to generate a DSA signature of the library, and the public key and signature are stored in a file with the name ''libraryname''.chk. When the self-test is initiated (e.g., at initialization for the FIPS mode), the module verifies the signatures (in the ''libraryname''.chk files) of the softoken and freebl libraries. If the signature verification fails, the self-test fails.

[http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#FC_Initialize FC_Initialize] calls [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11.c.dep.html#nsc_CommonInitialize nsc_CommonInitialize] and then the DSA signature is verified before the library initialization is allowed to proceed. If the signature verification fails, FC_Initialize puts the module in the Error state by setting the Boolean state variable <code>sftk_fatalError</code> to true. All the PKCS #11 functions that perform cryptographic operations or output data check <code>sftk_fatalError</code> on entry. In the Error state (<code>sftk_fatalError</code> is true), no action besides returning the error code <code>CKR_DEVICE_ERROR</code> is taken by those functions, which prevents cryptograhic operations and data output. (See also [http://wiki.mozilla.org/ModuleInterfaces#In_Error_State In Error State].)

==Configuring Discretionary Access Control==

On Unix (including Linux and Mac OS X), discretionary access control can be configured by setting the file mode bits of the files.

Below we describe how to set the file mode bits to specify the set of roles that can access each component of the NSS cryptographic module.

===Access to Stored Cryptographic Software and Cryptographic Programs===
When installing the NSS cryptographic module library files, the operator shall use the <code>chmod</code> utility to set the file mode bits of the library files 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,
$ chmod 0755 libsoftokn3.so libfreebl*3.so libnssdbm3.so
The file mode bits can be verified with the <code>ls</code> utility. For example,
$ ls -l libsoftokn3.so libfreebl*3.so
-rwxr-xr-x 1 wtchang wtchang 455411 Jun 8 17:07 libfreebl3.so
-rwxr-xr-x 1 wtchang wtchang 1052734 Jun 8 17:07 libsoftokn3.so
-rwxr-xr-x 1 wtchang wtchang 263540 Jun 8 17:07 libnssdbm3.so
<div class=note>On windows, replace the <code>.so</code> suffix by <code>.dll</code> in the above commands. On Mac OS X, replace the <code>.so</code> suffix by <code>.dylib</code> in the above commands.</div>

===Access to Cryptographic Keys, CSPs, and Plaintext Data===

Cryptographic keys, CSPs, and plaintext data are stored in the NSS databases. The NSS cryptographic module creates its database files with the '''0600''' permission bits so that only the owner can read or modify the database files. (See the [http://mxr.mozilla.org/security/ident?i=dbsopen <code>dbsopen()</code>] or [[http://mxr.mozilla.org/security/ident?i=dbopen <code>dbopen()</code>] calls in the [http://mxr.mozilla.org/security/ident?i=nsslowcert_OpenPermCertDB <code>nsslowcert_OpenPermCertDB</code>], [http://mxr.mozilla.org/security/ident?i=nsslowkey_OpenKeyDB <code>nsslowkey_OpenKeyDB</code>], and [http://mxr.mozilla.org/security/ident?i=secmod_OpenDB <code>secmod_OpenDB</code>] functions.) For example,
$ ls -l *.db
-rw------- 1 wtchang wtchang 65536 May 15 22:16 cert8.db
-rw------- 1 wtchang wtchang 32768 May 15 22:16 key3.db
-rw------- 1 wtchang wtchang 32768 May 15 22:15 secmod.db
or
$ls -l *.db
-rw------- 1 gb staff 9216 May 6 10:22 cert9.db
-rw------- 1 gb staff 11264 May 6 10:22 key4.db

Since the cryptographic keys and CSPs are stored in encrypted form, the owner needs to assume the NSS User role by authenticating with the password to decrypt the cryptographic keys and CSPs stored in the private key database.

===Access to Audit Data===

The NSS cryptographic module may use the Unix <code>syslog()</code> function and the audit mechanism provided by the operating system to audit events. (Auditing is not yet implemented on Windows.) Auditing is turned off by default. To turn on the auditing capability, you need to set the environment variable NSS_ENABLE_AUDIT to 1. You also need to configure the operating system's audit mechanism.

Access to the audit data is described in the next two subsections.

====Access to syslog Log Files====

On Unix (including Linux and Mac OS X), the NSS cryptographic module uses the <code>syslog()</code> function to audit events, so the audit data are stored in the system log. Only the root user can modify the system log. On some platforms, only the root user can read the system log; on other platforms, all users can read the system log.

The system log is usually under the <code>/var/adm</code> or <code>/var/log</code> directory. The exact location of the system log is specified in the <code>/etc/syslog.conf</code> file. The NSS cryptographic module uses the default '''user''' facility and the '''info''', '''warning''', and '''err''' severity levels for its log messages. We give two examples below.

'''Red Hat Enterprise Linux 4''': The <code>/etc/syslog.conf</code> file on Red Hat Enterprise Linux 4 has:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
which specifies that <code>/var/log/messages</code> is the system log. The permission bits of the system log are:
$ ls -l /var/log/messages
-rw------- 1 root root 38054 Jun 9 10:18 /var/log/messages
so only the root user can read or modify the system log.

'''Solaris 10''': The <code>/etc/syslog.conf</code> file on Solaris 10 has:
*.err;kern.debug;daemon.notice;mail.crit /var/adm/messages
which specifies that <code>/var/adm/messages</code> is the system log. The permission bits of the system log are:
$ ls -l /var/adm/messages
-rw-r--r-- 1 root root 0 Jun 7 03:10 /var/adm/messages
so all users can read the system log, but only the root user can modify it.

====Access to System Audit Log====

To meet the audit requirements of FIPS 140-2 at Security Level 2, on Red Hat Enterprise Linux 4 and Trusted Solaris, the NSS cryptographic module also uses the audit mechanism provided by the operating system to audit events. The audit data are stored in the system audit log. Only the root user can read or modify the system audit log.

On Red Hat Enterprise Linux 4, the system audit log is in the <code>/var/log/audit</code> directory. This directory and the log files in it have the following permission bits (the following commands were run as the root user; only the root user can run the second command):
# ls -ld /var/log/audit
drwxr-x--- 2 root root 4096 Jun 1 19:50 /var/log/audit
# ls -l /var/log/audit
total 13460
-rw-r----- 1 root root 3248038 Jun 8 17:50 audit.log
-r--r----- 1 root root 5242886 Jun 1 19:50 audit.log.1
-r--r----- 1 root root 5242936 May 20 18:01 audit.log.2

On Solaris default audit records are stored in: /var/audit/.

'''Configure the Solaris Auditing:'''

To configure the system audit mechanism on Solaris the following administration tasks need to be completed. Create the audit class 'fp', then create the audit event 'AUE_FIPS_AUDIT ' and add the class 'fp' to the audit_control file.

Edit /etc/security/audit_class
add line:
0x99000000:fp:NSS FIPS Security Msgs

Edit /etc/security/audit_event
add line:
34444:AUE_FIPS_AUDIT:fp

Edit /etc/security/audit_control
add 'fp' to the "flags:" as in:
flags:lo,ap,fp

Turn on audit service:

On Trusted Solaris 8, auditing is enabled by default; for non-trusted Solaris run: /etc/security/bsmconv (either as root or a user that has been given the Audit Control RBAC profile in Solaris 8)
and reboot your system.
After the system has rebooted, ensure auditd is running: ps -ecf | grep auditd

'''Viewing the audit trail:'''

By default the audit logs are stored in /var/audit. To view the active audit trail, ensure there is only one *not_terminated* audit files. If there are others, delete the older ones before executing this command.

#cd /var/audit
#tail -0f *not_terminated* | praudit

Note: On Trusted Solaris 8 you need to assume a role with the tail and praudit commands with the proc_audit_appl and proc_audit_tcb privileges.

You can also view the existing audit files using auditreduce.
#cd /var/audit
#auditreduce -m 34444 *not_terminated* | praudit -l

===Entry of Cryptographic Keys and CSPs===

'''N/A'''. The NSS cryptographic module does not support manual entry of cryptographic keys and CSPs.

==Auditable Events==

<div class=note>Many auditable events required by FIPS 140-2 are related to the crypto officer role. In the NSS cryptographic module, the crypto officer role is only used to perform these functions:
* install the module,
* initialize or re-initialize the module, and
* initialize the NSS User's password.
</div>

Every audit record contains the following information about the event:
* date and time of the event
* the string "NSS ''<softoken library name>''", which identifies the NSS cryptographic module. On Red Hat Enterprise Linux and Solaris, this string is "NSS libsoftokn3.so"
* process ID (pid) of the process using the NSS cryptographic module
* user ID (uid) of the user who owns the process
* the audit text message, which usually consists of
** the PKCS #11 function that generated the event. For example, <code>FC_Login</code>.
** the arguments and return code (error code) of the function. Arguments that contain sensitive information such as passwords are omitted.
** (optional) an error message. For example, "power-up self-tests failed".

===AS06.17===

'''AS06.17''' requires that the module record modifications, accesses, deletions, and additions of cryptographic data and CSPs. In our module, cryptographic data and CSPs are cryptographic keys, audit data, and authentication data. We address cryptographic keys in this section and audit data and authentication data in the next section.

If a function has an object handle pointer argument (e.g., ''phKey''), on a successful return we also record the object handle stored in the location pointed to by the argument (e.g., "''*phKey = 0x01234567''").

Below we list the functions that we audit and specify the format of the audit messages. For brevity we omit the optional returned object handles in the audit message specification.
* Object management functions, when the object is a cryptographic key (object class <code>CKO_PUBLIC_KEY</code>, <code>CKO_PRIVATE_KEY</code>, and <code>CKO_SECRET_KEY</code>)
** <code>[http://developer.mozilla.org/en/docs/FC_CreateObject FC_CreateObject]</code>: addition of cryptographic keys
*** "C_CreateObject(hSession=''<session handle>'', pTemplate=''<template pointer>'', ulCount=''<count>'', phObject=''<object handle pointer>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_CopyObject FC_CopyObject]</code>: access and addition of cryptographic keys
*** "C_CopyObject(hSession=''<session handle>'', hObject=''<object handle>'', pTemplate=''<template pointer>'', ulCount=''<count>'', phNewObject=''<object handle pointer>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_DestroyObject FC_DestroyObject]</code>: deletion of cryptographic keys
*** "C_DestroyObject(hSession=''<session handle>'', hObject=''<object handle>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_GetObjectSize FC_GetObjectSize]</code>: access of cryptographic keys
*** "C_GetObjectSize(hSession=''<session handle>'', hObject=''<object handle>'', pulSize=''<size pointer>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_GetAttributeValue FC_GetAttributeValue]</code>: access of cryptographic keys
*** "C_GetAttributeValue(hSession=''<session handle>'', hObject=''<object handle>'', pTemplate=''<template pointer>'', ulCount=''<count>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_SetAttributeValue FC_SetAttributeValue]</code>: modification of cryptographic keys
*** "C_SetAttributeValue(hSession=''<session handle>'', hObject=''<object handle>'', pTemplate=''<template pointer>'', ulCount=''<count>'')=''<return code>''"
* Key management functions
** <code>[http://developer.mozilla.org/en/docs/FC_GenerateKey FC_GenerateKey]</code>: addition of cryptographic keys
*** "C_GenerateKey(hSession=''<session handle>'', pMechanism=''<mechanism>'', pTemplate=''<template pointer>'', ulCount=''<count>'', phKey=''<key object handle pointer>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_GenerateKeyPair FC_GenerateKeyPair]</code>: addition of cryptographic keys
*** "C_GenerateKeyPair(hSession=''<session handle>'', pMechanism=''<mechanism>'', pPublicKeyTemplate=''<template pointer>'', ulPublicKeyAttributeCount=''<count>'', pPrivateKeyTemplate=''<template pointer>'', ulPrivateKeyAttributeCount=''<count>'', phPublicKey=''<key object handle pointer>'', phPrivateKey=''<key object handle pointer>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_WrapKey FC_WrapKey]</code>: access of cryptographic keys
*** "C_WrapKey(hSession=''<session handle>'', pMechanism=''<mechanism>'', hWrappingKey=''<key object handle>'', hKey=''<key object handle>'', pWrappedKey=''<buffer that receives the wrapped key>'', pulWrappedKeyLen=''<pointer to length>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_UnwrapKey FC_UnwrapKey]</code>: access and addition of cryptographic keys
*** "C_UnwrapKey(hSession=''<session handle>'', pMechanism=''<mechanism>'', hUnwrappingKey=''<key object handle>'', pWrappedKey=''<pointer to bytes>'', ulWrappedKeyLen=''<length>'', pTemplate=''<template pointer>'', ulAttributeCount=''<count>'', phKey=''<key object handle pointer>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_DeriveKey FC_DeriveKey]</code>: access and addition of cryptographic keys
*** "C_DeriveKey(hSession=''<session handle>'', pMechanism=''<mechanism>'', hBaseKey=''<key object handle>'', pTemplate=''<template pointer>'', ulAttributeCount=''<count>'', phKey=''<key object handle pointer>'')=''<return code>''"
* Cipher "Init" functions
** <code>[http://developer.mozilla.org/en/docs/FC_EncryptInit FC_EncryptInit]</code>: access of cryptographic keys
*** "C_EncryptInit(hSession=''<session handle>'', pMechanism=''<mechanism>'', hKey=''<key object handle>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_DecryptInit FC_DecryptInit]</code>: access of cryptographic keys
*** "C_DecryptInit(hSession=''<session handle>'', pMechanism=''<mechanism>'', hKey=''<key object handle>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_SignInit FC_SignInit]</code>: access of cryptographic keys
*** "C_SignInit(hSession=''<session handle>'', pMechanism=''<mechanism>'', hKey=''<key object handle>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_SignRecoverInit FC_SignRecoverInit]</code>: access of cryptographic keys
*** "C_SignRecoverInit(hSession=''<session handle>'', pMechanism=''<mechanism>'', hKey=''<key object handle>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_VerifyInit FC_VerifyInit]</code>: access of cryptographic keys
*** "C_VerifyInit(hSession=''<session handle>'', pMechanism=''<mechanism>'', hKey=''<key object handle>'')=''<return code>''"
** <code>[http://developer.mozilla.org/en/docs/FC_VerifyRecoverInit FC_VerifyRecoverInit]</code>: access of cryptographic keys
*** "C_VerifyRecoverInit(hSession=''<session handle>'', pMechanism=''<mechanism>'', hKey=''<key object handle>'')=''<return code>''"
* Miscellaneous
** <code>[http://developer.mozilla.org/en/docs/FC_DigestKey FC_DigestKey]</code>: access of cryptographic keys
*** "C_DigestKey(hSession=''<session handle>'', hKey=''<key object handle>'')=''<return code>''"

===AS06.18 and AS06.19===

In compliance with '''AS06.18''' and '''AS06.19''', the following events are auditable by the NSS cryptographic module.
* attempts to provide invalid input for crypto officer functions: We log the use of all crypto officer functions with the return code. The return code tells us whether the operator attempted to provide invalid input.
** <code>FC_InitToken(slotID, pPin, ulPinLen, pLabel)</code>
*** If <code>slotID</code> is invalid, the return code is 0x00000003 (<code>CKR_SLOT_ID_INVALID</code>).
*** The other input arguments are ignored. (<code>pPin</code> and <code>ulPinLen</code> specify the password of the PKCS #11 Security Officer, which is the empty string. Although the function doesn't verify the password, the empty string should be passed as the password.)
** <code>FC_InitPIN(hSession, pPin, ulPinLen)</code>
*** If <code>hSession</code> is invalid, the return code is 0x000000B3 (<code>CKR_SESSION_HANDLE_INVALID</code>).
*** If the password that <code>pPin</code> points to has an invalid UTF-8 character, the return code is 0x000000A1 (<code>CKR_PIN_INVALID</code>).
*** If <code>ulPinLen</code> is too short or too long, or the password that <code>pPin</code> points to is too weak (doesn't have enough character types), the return code is 0x000000A2 (<code>CKR_PIN_LEN_RANGE</code>).
* the addition or deletion of an operator to/from a crypto officer role: Since any authorized operator can assume the crypto officer role, this event is equivalent to the addition or deletion of a user account in the OS. These events are recorded by the audit mechanism of the OS.
** Red Hat Enterprise Linux 4
*** The programs <code>/usr/sbin/useradd</code>, <code>/usr/sbin/usermod</code>, and <code>/usr/sbin/userdel</code> in the shadow-utils package audit the addition or deletion of user accounts. You can verify by doing <code>ldd</code> against the programs and seeing that they are linked to <code>libaudit.so.0</code>. The audit message types are <code>AUDIT_ADD_USER</code> and <code>AUDIT_DEL_USER</code>.
*** FMT_MSA.1 ''All modifications of the values of security attributes'', FMT_MTD.1 User Attributes ''All modifications to the values of TSF data'', and FAU_SMR.1 ''Modifications to the group of users that are part of a role'' are auditable events. (See [http://www.commoncriteriaportal.org/public/files/epfiles/ST_VID10072-ST.pdf Security Target], Table 5-1, pages 31-32.)
** Trusted Solaris 8: Audit.5 ''The creation, deletion, disabling or enabling of user accounts is auditable''. (See [http://www.commoncriteriaportal.org/public/files/epfiles/TSolaris8_Issue3.1.pdf Security Target], page 55.)
* operations to process audit data stored in the audit trail: these operations are recorded by the audit mechanism of the OS.
** Red Hat Enterprise Linux 4: FAU_SAR.1 ''Reading of information from the audit records'' and FAU_SAR.2 ''Unsuccessful attempts to read information from the audit records'' are auditable events. (See [http://www.commoncriteriaportal.org/public/files/epfiles/ST_VID10072-ST.pdf Security Target], Table 5-1, pages 29-30.)
** Trusted Solaris 8: Audit.2 ''Attempts to access to objects are auditable''. (See [http://www.commoncriteriaportal.org/public/files/epfiles/TSolaris8_Issue3.1.pdf Security Target], page 54.)
* requests to use authentication data management mechanisms
** <code>FC_InitPIN</code> calls (which initialize the NSS User's password)
*** "C_InitPIN(hSession=''<session handle>'')=''<return code>''"
** <code>FC_SetPIN</code> calls (which change the NSS User's password)
*** "C_SetPIN(hSession=''<session handle>'')=''<return code>''"
* use of a security-relevant crypto officer function
** <code>FC_InitToken</code> calls (which re-initialize the module)
*** "C_InitToken(slotID=''<slot ID>'', pLabel=''"<token label>"'')=''<return code>''"
** <code>FC_InitPIN</code> calls (which initialize the NSS User's password)
*** "C_InitPIN(hSession=''<session handle>'')=''<return code>''"
* requests to access authentication data associated with the cryptographic module
** N/A. The module doesn't give the operator access to the authentication data.
* use of an authentication mechanism (e.g., login) associated with the cryptographic module
** <code>FC_Login</code> calls
*** "C_Login(hSession=''<session handle>'', userType=''<user type>'')=''<return code>''"
** <code>FC_Logout</code> calls
*** "C_Logout(hSession=''<session handle>'')=''<return code>''"
* explicit requests to assume a crypto officer role
** <code>FC_Login</code> calls
*** "C_Login(hSession=''<session handle>'', userType=''<user type>'')=''<return code>''"
* the allocation of a function to a crypto officer role
** N/A. The functions allocated to the crypto officer role are fixed.
* other auditable events
** Power-up self-test failure
*** "C_Initialize()=''<return code>'' power-up self-tests failed"
** Pair-wise consistency test failure
*** "C_GenerateKeyPair(hSession=''<session handle>'', pMechanism->mechanism=''<mechanism>'')=''<return code>'' self-test: pair-wise consistency test failed"
** Continuous random number generator test failure
*** "C_GenerateRandom(hSession=''<session handle>'', pRandomData=''<pointer>'', ulRandomLen=''<length>'')=''<return code>'' self-test: continuous RNG test failed"
** Switching between FIPS and non-FIPS modes
*** "enabled FIPS mode"
*** "disabled FIPS mode"

FIPS Validation

2011-11-16T18:49:55Z

Relyea: /* Algorithms */

FIPS Validation

2011-11-16T18:49:29Z

Relyea: /* Updates */

FIPS Validation

2011-11-16T18:48:40Z

Relyea: /* Schedule */

FIPS Validation

2011-11-16T18:48:09Z

Relyea: /* Vendor Information */

== NSS FIPS 140 validation ==

Softoken is a component of [[NSS]], and has a separate version number. The most recent FIPS validated Softoken is 3.12.4 and is in '''NSS 3.12.4''' and '''NSS 3.12.5''' and '''NSS 3.12.6'''. Binaries are available [https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_4_RTM/ | here].

NSS softoken has completed FIPS 140 validation four times: 1997, 1999, 2002, 2007 and 2009. View [http://www.mozilla.org/projects/security/pki/nss/fips/ | NSS FIPS validation history ] here. View the [[FIPS2009]] validation here.

This page documents our current NSS FIPS 140 validation.

==Updates==

April 2010 NSS Softoken has finished its validation [http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1280 NSS Certs]

== Platforms for 2011 ==
* Level 1
** RHEL '''6''' x86 32 bit (no AES-NI)
** RHEL '''6''' x86 64 bit

== Algorithms ==

Plan is to validate all FIPS-approved algorithms that NSS implements and NIST has tests for. There are eight such algorithms.

{| border="1" cellpadding="2" summary="Algorithms"
|-
!Algorithms !! Key Size !! Modes !! Certificates

|-
![http://csrc.nist.gov/groups/STM/cavp/documents/des/tripledesval.html TripleDES]
| KO 1,2,3 (56,112,168)
||
TECB(e/d; KO 1,2,3)<br>
TCBC(e/d; KO 1,2,3)
||
Pending]
|-
! [http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html AES]
| 128/192/256
||
ECB(e/d; 128,192,256)<br>
CBC(e/d; 128,192,256)
||
Pending
|-
![http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf/ SHS (including all variants: SHA-1, SHA-256, SHA-384, and SHA-512)]
[http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm SHS]
|
SHA-1 (BYTE-only)<br>
SHA-256 (BYTE-only)<br>
SHA-384 (BYTE-only)<br>
SHA-512 (BYTE-only)
|| N/A ||
Pending
|-
! [http://csrc.nist.gov/groups/STM/cavp/documents/mac/hmacval.html HMAC]
|
HMAC-SHA1, HMAC-SHA256,<br>
HMAC-SHA384, HMAC-SHA512
||
KeySize < BlockSize,<br>
KeySize = BlockSize,<br>
KeySize > BlockSize
||
Pending
|-
! [http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html DRBG]
| N/A
||
Hash_DRBG of [http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf NIST SP 800-90]
||
Pending
|-
! [http://csrc.nist.gov/groups/STM/cavp/documents/dss/dsaval.htm DSA]
| 512-1024 ||
PQG(gen)MOD(1024);<br>
PQG(ver)MOD(1024);<br>
KEYGEN(Y)MOD(1024);<br>
SIG(gen)MOD(1024);<br>
SIG(ver)MOD(1024);
||
Pending
|-
! [http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsaval.html RSA]
| 1024-8192 ||
ALG[RSASSA-PKCS1_V1_5]; SIG(gen);
SIG(ver);
||
Pending
|-
! [http://csrc.nist.gov/groups/STM/cavp/documents/dss/ecdsaval.html ECDSA]
(Extended ECC)
| 163-571 ||
PKG: CURVES( ALL-P ALL-K ALL-B );<br>
PKV: CURVES( ALL-P ALL-K ALL-B );<br>
SIG(gen): CURVES( ALL-P ALL-K ALL-B );<br>
SIG(ver): CURVES( ALL-P ALL-K ALL-B );
||
Not In 2011 Validation
|-
! [http://csrc.nist.gov/groups/STM/cavp/documents/dss/ecdsaval.html ECDSA]
(Basic ECC)
| 256-521 ||
PKG: CURVES( ALL-P P-256 P-384 P-521 );<br>
PKV: CURVES( ALL-P P-256 P-384 P-521 );<br>
SIG(gen): CURVES( ALL-P P-256 P-384 P-521 );<br>
SIG(ver): CURVES( P-256 P-384 P-521 );
||
Not In 2011 Validation
|}

== Dependant Bugs ==
{| border="1" cellpadding="2" summary="Dependent Bugs"
|-
! Bug !! Description !! Completed
|-
||| ||
|}

== Testing Lab ==
[http://www.saic.com/infosec/testing-accreditation/ SAIC ]

== FIPS 140 Information ==

[http://csrc.nist.gov/cryptval/ NIST Cryptographic Module Validation Program ]

[http://csrc.nist.gov/CryptoToolkit/ NIST Crypto Toolkit ]

== NSS FIPS 140-2 Validation Docs ==

[[ NSSCryptoModuleSpec | NSS FIPS 140-2 Validation Docs ]]

== FIPS 140-2 Derived Test Requirements (DTR) ==

[[ FIPS 140-2 Vendor Requirement Docs | FIPS 140-2 Derived Test Requirements (DTR) ]]

== Vendor Information ==

This validation is supported and maintained by the following corporations:

Red Hat, Inc.: http://www.redhat.com/about/contact/

== Schedule ==

{| border="1" cellpadding="2" summary="schedule table"
|-
! Milestone !! Item !! Deps !! Time !! Who !! Completed
|-
| M1 || Initial Setup || || || ||
|-
| 1a || Choose validation Lab, approve costs, and sign NDA || all || || all || [http://www.atlanlabs.com/ Atlan]
|-
| 1d || Define Algorithms, Key Sizes and modes || || || ||
|-
| M2 || Complete NSS 3.12 FIPS dependant bugs || || || ||
|-
| M3 || Update documentation (numbers in parentheses refer to sections in FIPS documentation) || || || ||
|-
| 3a. || (1.0) Security policy, new algorithms || 1d || 2 wks || all ||
|-
| 3b. || Generate annotated source tree (LXR -> HTML) || M2 || || ||
|-
| 3c. || (2.0) Finite State Machine || 3b || 3 wks || ||
|-
| 3d. || (3.0/4.0) Cryptographic Module Definition || 3b || 2 wks || ||
|-
| 3e. || (6.0) Software Security (rules-to-code map) || 3b || 2 wks || ||
|-
| 3f. || (8.0) Key Management Generate 20K random #'s || || 1 day || ||
|-
| 3g. || (9.0) Cryptographic Algs || 3a || 3 days || ||
|-
| 3h. || (10.0) Operational Test Plan || || 1 day || ||
|-
| 3i. || Document architectural changes between 3.2 and 3.11 || || 5 days || ||
|-
| M4 || Send docs to testing lab || || || ||
|-
| 4a. || Security Policy || || all || ||
|-
| 4b. || Finite State Machine || 3c || || ||
|-
| 4c. || Module Def. / rules-to-code || 3d,3e || || ||
|-
| M5 || Operational validation || || || ||
|-
| 5a. || Algorithm testing || || 1 month || ||
|-
| 5b. || Operational testing || 3h || 1 week || ||
|-
| 5c || set up machines for Lab to run operational tests on, provide Lab tech with access to machines (last time we both sent a box to the lab and set up a temporary account in the intranet for them) || || || ||
|-
| M6 || Internal QA of docs || M2-M5 || 1 week || all ||
|-
| M7 || Communication between NSS team / Lab / NIST about status of validation / algorithm certificates || M1-5 || 3-6 mos || all ||
|}

<BR>
[[Category:NSS]]

FIPS 140-2 Vendor Requirement Docs 2009

2011-11-16T18:46:04Z

Relyea: Created page with " Section 1: Cryptographic Module Specifcation Section 2: Cryptographic Module Ports and Interfaces [[ F2009VE_03 | Section 3: Roles, Servic..."

[[ F2009VE_01 | Section 1: Cryptographic Module Specifcation ]]

[[ F2009VE_02 | Section 2: Cryptographic Module Ports and Interfaces ]]

[[ F2009VE_03 | Section 3: Roles, Services, and Authentication ]]

[[ F2009VE_04 | Section 4: Finite State Model ]]

[[ F2009VE_05 | Section 5: Physical Security (N/A) ]]

[[ F2009VE_06 | Section 6: Operational Enviroment ]]

[[ F2009VE_07 | Section 7: Cryptographic Key Management ]]

[[ F2009VE_08 | Section 8: EMI/EMC ]]

[[ F2009VE_09 | Section 9: Self-Tests ]]

[[ F2009VE_10 | Section 10: Design Assurance ]]

[[ F2009VE_11 | Section 11: Mitigation of Other Attacks ]]

[[ F2009VE_14 | Appendix C: Cryptographic Module Security Policy ]]

[[Category:NSS]]