MozillaWiki

FIPS Operational Environment: Difference between revisions

Page Discussion

FIPS Operational Environment (view source)

Revision as of 18:59, 16 November 2011

7,183 bytes added ,  16 November 2011
→‎Software Integrity Test
 
(41 intermediate revisions by 7 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 4
** Red Hat Enterprise Linux Version 6 32 bit
** Windows XP Service Pack 2
** Red Hat Enterprise Linux Version 6 64 bit
** Solaris 10
** HP-UX B.11.11
** Mac OS X 10.4
* Security Level 2
** Red Hat Enterprise Linux 4: CAPP EAL4+
** Trusted Solaris 8: LSPP, CAPP, and RBACPP; EAL4


==Single Operator Mode of Operation==
==Single Operator Mode of Operation==
Line 37: Line 32:


See also
See also
* NSA, ''[http://www.nsa.gov/notices/notic00004.cfm?Address=/snac/os/applemac/osx_client_final_v_1_1.pdf Apple Mac OS X v10.3.x "Panther" Security Configuration Guide]''. Read Chapter 4 ''Configuring System Settings'', Section ''Managing System Preferences'', Subsection ''Sharing'', pages 37-39. Check the [http://checklists.nist.gov/repository/ NIST Security Configuration Checklists Repository] for newer versions of this document.
* 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===
===Unix Instructions===
Line 46: Line 42:


The specific procedures for each of the UNIX variants are described below.
The specific procedures for each of the UNIX variants are described below.
'''HP-UX'''
# Log in as the "root" user.
# Edit the system file <code>/etc/passwd</code> and remove all the users except "root" and the pseudo-users. Make sure the password fields for the pseudo-users are a star (*). This prevents login as the pseudo-users.
# Edit the system file <code>/etc/nsswitch.conf</code>. Make sure that <code>files</code> is the only option for <code>passwd</code> and <code>group</code>. This disables NIS and other name services for users and groups.
# Edit the system file <code>/etc/inetd.conf</code>. Remove or comment out the lines for remote login, remote command execution, and file transfer daemons such as <code>telnetd</code>, <code>rlogind</code>, <code>remshd</code>, <code>rexecd</code>, <code>ftpd</code>, and <code>tftpd</code>.
# Reboot the system for the changes to take effect.


'''Red Hat Enterprise Linux'''
'''Red Hat Enterprise Linux'''
Line 60: 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 67: 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 81: 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://wiki.mozilla.org/Security_Policy#Specification_of_Security_Policy Security Policy Rule #36 ] 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.
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.
[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==
==Configuring Discretionary Access Control==
Line 96: Line 98:
===Access to Stored Cryptographic Software and Cryptographic Programs===
===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,
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
   $ chmod 0755 libsoftokn3.so libfreebl*3.so libnssdbm3.so
The file mode bits can be verified with the <code>ls</code> utility. For example,
The file mode bits can be verified with the <code>ls</code> utility. For example,
   $ ls -l libsoftokn3.so libfreebl*3.so
   $ 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  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 1052734 Jun  8 17:07 libsoftokn3.so
<div class=note>On HP-UX PA-RISC, replace the <code>.so</code> suffix by <code>.sl</code> in the above commands. On Mac OS X, replace the <code>.so</code> suffix by <code>.dylib</code> in the above commands.</div>
  -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===
===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://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pcertdb.c.dep.html#nsslowcert_OpenPermCertDB <code>nsslowcert_OpenPermCertDB</code>], [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/keydb.c.dep.html#nsslowkey_OpenKeyDB <code>nsslowkey_OpenKeyDB</code>], and [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pk11db.c.dep.html#secmod_OpenDB <code>secmod_OpenDB</code>] functions.) For example,
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.


===Access to Audit Data===
===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. Access to the audit data is described in the next two subsections.
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====
====Access to syslog Log Files====
Line 138: Line 148:
====Access to System Audit Log====
====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 Solaris, the NSS cryptographic module also uses the audit mechanism provided by the operating system to audit events, so the audit data are also stored in the system audit log. Only the root user can read or modify the 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):
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):
Line 149: Line 159:
   -r--r-----  1 root root 5242936 May 20 18:01 audit.log.2
   -r--r-----  1 root root 5242936 May 20 18:01 audit.log.2


On Solaris default audit records are stored in system_name:/var/audit/.
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===
===Entry of Cryptographic Keys and CSPs===
Line 161: Line 206:
* initialize or re-initialize the module, and
* initialize or re-initialize the module, and
* initialize the NSS User's password.
* initialize the NSS User's password.
Moreover, the operator assumes the crypto officer role implicitly when he performs a crypto officer function. No explicit request or authentication (beyond logging into the OS user account of the operator) is required.</div>
</div>


Every audit record contains the following information about the event:
Every audit record contains the following information about the event:
Line 173: Line 218:
** (optional) an error message. For example, "power-up self-tests failed".
** (optional) an error message. For example, "power-up self-tests failed".


The following events are auditable by the NSS cryptographic module.
===AS06.17===
* modifications, accesses, deletions, and additions of cryptographic data (e.g., cryptographic keys and audit data) and CSPs (e.g., secret and private cryptographic keys, and authentication data such as passwords and PINs): audit data and authentication data are handled below. Here we only handle cryptographic keys.
 
** Object management functions, where the object is a cryptographic key (object class <code>CKO_PUBLIC_KEY</code>, <code>CKO_PRIVATE_KEY</code>, and <code>CKO_SECRET_KEY</code>)
'''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.
*** <code>FC_CreateObject</code>
 
*** <code>FC_CopyObject</code>
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''").
*** <code>FC_DestroyObject</code>
 
*** <code>FC_GetObjectSize</code>
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.
*** <code>FC_GetAttributeValue</code>
* 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>FC_SetAttributeValue</code>
** <code>[http://developer.mozilla.org/en/docs/FC_CreateObject FC_CreateObject]</code>: addition of cryptographic keys
** Key management functions
*** "C_CreateObject(hSession=''<session handle>'', pTemplate=''<template pointer>'', ulCount=''<count>'', phObject=''<object handle pointer>'')=''<return code>''"
*** <code>FC_GenerateKey</code>
** <code>[http://developer.mozilla.org/en/docs/FC_CopyObject FC_CopyObject]</code>: access and addition of cryptographic keys
*** <code>FC_GenerateKeyPair</code>
*** "C_CopyObject(hSession=''<session handle>'', hObject=''<object handle>'', pTemplate=''<template pointer>'', ulCount=''<count>'', phNewObject=''<object handle pointer>'')=''<return code>''"
*** <code>FC_UnwrapKey</code>
** <code>[http://developer.mozilla.org/en/docs/FC_DestroyObject FC_DestroyObject]</code>: deletion of cryptographic keys
*** <code>FC_DeriveKey</code>
*** "C_DestroyObject(hSession=''<session handle>'', hObject=''<object handle>'')=''<return code>''"
** Cipher "Init" functions
** <code>[http://developer.mozilla.org/en/docs/FC_GetObjectSize FC_GetObjectSize]</code>: access of cryptographic keys
*** <code>C_EncryptInit</code>
*** "C_GetObjectSize(hSession=''<session handle>'', hObject=''<object handle>'', pulSize=''<size pointer>'')=''<return code>''"
*** <code>C_DecryptInit</code>
** <code>[http://developer.mozilla.org/en/docs/FC_GetAttributeValue FC_GetAttributeValue]</code>: access of cryptographic keys
*** <code>C_SignInit</code>
*** "C_GetAttributeValue(hSession=''<session handle>'', hObject=''<object handle>'', pTemplate=''<template pointer>'', ulCount=''<count>'')=''<return code>''"
*** <code>C_SignRecoverInit</code>
** <code>[http://developer.mozilla.org/en/docs/FC_SetAttributeValue FC_SetAttributeValue]</code>: modification of cryptographic keys
*** <code>C_VerifyInit</code>
*** "C_SetAttributeValue(hSession=''<session handle>'', hObject=''<object handle>'', pTemplate=''<template pointer>'', ulCount=''<count>'')=''<return code>''"
*** <code>C_VerifyRecoverInit</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.
* 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>
** <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>).
*** If <code>slotID</code> is invalid, the return code is 0x00000003 (<code>CKR_SLOT_ID_INVALID</code>).
*** The other input arguments are ignored. (The password of the Crypto Officer is not used because the module depends on the OS to authenticate the Crypto Officer and doesn't perform further authentication.)
*** 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>
** <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 <code>hSession</code> is invalid, the return code is 0x000000B3 (<code>CKR_SESSION_HANDLE_INVALID</code>).
Line 228: Line 303:
*** "C_Logout(hSession=''<session handle>'')=''<return code>''"
*** "C_Logout(hSession=''<session handle>'')=''<return code>''"
* explicit requests to assume a crypto officer role
* explicit requests to assume a crypto officer role
** N/A. The crypto officer role is assumed implicitly when the operator performs crypto officer functions.
** <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
* the allocation of a function to a crypto officer role
** N/A. The functions allocated to the crypto officer role are fixed.
** N/A. The functions allocated to the crypto officer role are fixed.
Relyea
439

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/34822...370279"