439
edits
FIPS Operational Environment: Difference between revisions
FIPS Operational Environment (view source)
Revision as of 18:59, 16 November 2011
, 16 November 2011→Software Integrity Test
| (6 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
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: | 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 | * Security Level 1 | ||
** Red Hat Enterprise Linux Version 6 32 bit | |||
** Red Hat Enterprise Linux Version 6 64 bit | |||
** Red Hat Enterprise Linux Version | |||
** Red Hat Enterprise Linux Version | |||
==Single Operator Mode of Operation== | ==Single Operator Mode of Operation== | ||
| Line 55: | Line 49: | ||
# 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>. | # 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. | # 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''' | '''Solaris''' | ||
| Line 62: | Line 61: | ||
# 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>. | # 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. | # 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=== | ===Windows XP Instructions=== | ||
| Line 76: | Line 81: | ||
* [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-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://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== | ==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 # | 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 #15] 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].) | [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].) | ||
| Line 101: | Line 108: | ||
===Access to Cryptographic Keys, CSPs, and Plaintext Data=== | ===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 <code>dbsopen()</code> or <code>dbopen()</code> calls in the [http:// | 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 | $ ls -l *.db | ||
-rw------- 1 wtchang wtchang 65536 May 15 22:16 cert8.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:16 key3.db | ||
-rw------- 1 wtchang wtchang 32768 May 15 22:15 secmod.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. | 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. | ||