ModuleInterfaces: Difference between revisions
No edit summary |
No edit summary |
||
| (21 intermediate revisions by 4 users not shown) | |||
| Line 3: | Line 3: | ||
== Physical Ports == | == Physical Ports == | ||
The NSS module is a software-only implementation. All keys, encrypted data, and control information are exchanged through calls to library functions (logical interfaces). The physical ports; physical covers, doors, or openings; manual controls; and physical status indicators of the NSS module | The NSS cryptographic module is a software-only implementation. All keys, encrypted data, and control information are exchanged through calls to library functions (logical interfaces). The physical ports; physical covers, doors, or openings; manual controls; and physical status indicators of the NSS cryptographic module are those of the general purpose computer it runs on. | ||
== Logical Interfaces == | == Logical Interfaces == | ||
The following four logical interfaces have been designed within the NSS module. | The following four logical interfaces have been designed within the NSS cryptographic module. | ||
* Data input interface: function input arguments that specify plaintext data; ciphertext or signed data; cryptographic keys (plaintext or encrypted) and initialization vectors; and passwords that are to be input to and processed by the NSS module. | * Data input interface: function input arguments that specify plaintext data; ciphertext or signed data; cryptographic keys (plaintext or encrypted) and initialization vectors; and passwords that are to be input to and processed by the NSS cryptographic module. | ||
* Data output interface: function output arguments that receive plaintext data; ciphertext data and digital signatures; and cryptographic keys (plaintext or encrypted) and initialization vectors from the NSS module. | * Data output interface: function output arguments that receive plaintext data; ciphertext data and digital signatures; and cryptographic keys (plaintext or encrypted) and initialization vectors from the NSS cryptographic module. | ||
* Control input interface: function calls, or input arguments that specify commands and control data (e.g., algorithms, algorithm modes, or module settings) used to control the operation of the NSS module | * Control input interface: function calls, or input arguments that specify commands and control data (e.g., algorithms, algorithm modes, or module settings) used to control the operation of the NSS cryptographic module | ||
* Status output interface: function return codes, error codes, or output arguments that receive status information used to indicate the status of the NSS module | * Status output interface: function return codes, error codes, or output arguments that receive status information used to indicate the status of the NSS cryptographic module | ||
The NSS module uses different function arguments for input and output to distinguish between data and control for input and data and status for output, and to disconnect the logical paths followed by data/control entering the module and data/status exiting the module. The NSS module doesn't | The NSS cryptographic module uses different function arguments for input and output to distinguish between data and control for input and data and status for output, and to disconnect the logical paths followed by data/control entering the module and data/status exiting the module. The NSS cryptographic module doesn't use the same buffer for input and output. After the NSS cryptographic module is done with an input buffer that holds security-related information, it always zeroizes the buffer so that if the memory is later reused as an output buffer, no sensitive information may be inadvertently leaked. | ||
=== PKCS #11=== | === PKCS #11=== | ||
The logical interfaces of the NSS cryptpgraphic module consist of the PKCS #11 (Cryptoki) API. The API itself defines the cryptographic boundary, i.e., all access to the cryptographic module is through this API. The module has three PKCS #11 tokens: two tokens that implement the non-FIPS Approved mode of operation, and one token that implements the FIPS Approved mode of operation. The FIPS PKCS #11 token is designed specifically for FIPS 140-2, and allows applications using the NSS cryptographic module to operate in a strictly FIPS mode. | |||
The functions in the PKCS #11 API are listed in the table in the Specification of Services section of the [http://www.mozilla.org/projects/security/pki/nss/fips/secpolicy.pdf Security Policy]. | |||
== Inhibition of Data Output == | == Inhibition of Data Output == | ||
All data output via the data output interface is inhibited when the NSS module is in the | All data output via the data output interface is inhibited when the NSS cryptographic module is in the Error state or performing self-tests. | ||
=== In Error State === | === In Error State === | ||
The Boolean state variable <code>sftk_fatalError</code> tracks whether the NSS cryptographic module is in the Error state. Most PKCS #11 functions, including all the functions that output data via the data output interface, check the <code>sftk_fatalError</code> state variable and, if it is true, return the <code>CKR_DEVICE_ERROR</code> error code immediately. Only the functions that shut down and restart the module, reinitialize the module, or output status information can be invoked in the Error state. These functions are <code>FC_GetFunctionList</code>, <code>FC_Initialize</code>, <code>FC_Finalize</code>, <code>FC_GetInfo</code>, <code>FC_GetSlotList</code>, <code>FC_GetSlotInfo</code>, <code>FC_GetTokenInfo</code>, <code>FC_InitToken</code>, <code>FC_CloseSession</code>, <code>FC_CloseAllSessions</code>, and <code>FC_WaitForSlotEvent</code>. | |||
=== During Self-Tests === | === During Self-Tests === | ||
The NSS module performs power-up self-tests in FC_Initialize | The NSS cryptographic module performs power-up self-tests in the <code>FC_Initialize</code> function. Since no other PKCS #11 function (except <code>FC_GetFunctionList</code>) may be called before <code>FC_Initialize</code> returns successfully, all data output via the data output interface is inhibited while <code>FC_Initialize</code> is performing the self-tests. | ||
== Disconnecting the Output Data Path From the Key Processes == | == Disconnecting the Output Data Path From the Key Processes == | ||
During key generation and key zeroization, the NSS module | During key generation and key zeroization, the NSS cryptographic module may perform audit logging at Security Level 2, but the audit records do not contain sensitive information. The NSS cryptographic module doesn't return the function output arguments until key generation or key zeroization is finished. Therefore, the logical paths used by output data exiting the module are logically disconnected from the processes/threads performing key generation and key zeroization. | ||
Latest revision as of 19:05, 9 March 2007
This is a draft
Physical Ports
The NSS cryptographic module is a software-only implementation. All keys, encrypted data, and control information are exchanged through calls to library functions (logical interfaces). The physical ports; physical covers, doors, or openings; manual controls; and physical status indicators of the NSS cryptographic module are those of the general purpose computer it runs on.
Logical Interfaces
The following four logical interfaces have been designed within the NSS cryptographic module.
- Data input interface: function input arguments that specify plaintext data; ciphertext or signed data; cryptographic keys (plaintext or encrypted) and initialization vectors; and passwords that are to be input to and processed by the NSS cryptographic module.
- Data output interface: function output arguments that receive plaintext data; ciphertext data and digital signatures; and cryptographic keys (plaintext or encrypted) and initialization vectors from the NSS cryptographic module.
- Control input interface: function calls, or input arguments that specify commands and control data (e.g., algorithms, algorithm modes, or module settings) used to control the operation of the NSS cryptographic module
- Status output interface: function return codes, error codes, or output arguments that receive status information used to indicate the status of the NSS cryptographic module
The NSS cryptographic module uses different function arguments for input and output to distinguish between data and control for input and data and status for output, and to disconnect the logical paths followed by data/control entering the module and data/status exiting the module. The NSS cryptographic module doesn't use the same buffer for input and output. After the NSS cryptographic module is done with an input buffer that holds security-related information, it always zeroizes the buffer so that if the memory is later reused as an output buffer, no sensitive information may be inadvertently leaked.
PKCS #11
The logical interfaces of the NSS cryptpgraphic module consist of the PKCS #11 (Cryptoki) API. The API itself defines the cryptographic boundary, i.e., all access to the cryptographic module is through this API. The module has three PKCS #11 tokens: two tokens that implement the non-FIPS Approved mode of operation, and one token that implements the FIPS Approved mode of operation. The FIPS PKCS #11 token is designed specifically for FIPS 140-2, and allows applications using the NSS cryptographic module to operate in a strictly FIPS mode.
The functions in the PKCS #11 API are listed in the table in the Specification of Services section of the Security Policy.
Inhibition of Data Output
All data output via the data output interface is inhibited when the NSS cryptographic module is in the Error state or performing self-tests.
In Error State
The Boolean state variable sftk_fatalError tracks whether the NSS cryptographic module is in the Error state. Most PKCS #11 functions, including all the functions that output data via the data output interface, check the sftk_fatalError state variable and, if it is true, return the CKR_DEVICE_ERROR error code immediately. Only the functions that shut down and restart the module, reinitialize the module, or output status information can be invoked in the Error state. These functions are FC_GetFunctionList, FC_Initialize, FC_Finalize, FC_GetInfo, FC_GetSlotList, FC_GetSlotInfo, FC_GetTokenInfo, FC_InitToken, FC_CloseSession, FC_CloseAllSessions, and FC_WaitForSlotEvent.
During Self-Tests
The NSS cryptographic module performs power-up self-tests in the FC_Initialize function. Since no other PKCS #11 function (except FC_GetFunctionList) may be called before FC_Initialize returns successfully, all data output via the data output interface is inhibited while FC_Initialize is performing the self-tests.
Disconnecting the Output Data Path From the Key Processes
During key generation and key zeroization, the NSS cryptographic module may perform audit logging at Security Level 2, but the audit records do not contain sensitive information. The NSS cryptographic module doesn't return the function output arguments until key generation or key zeroization is finished. Therefore, the logical paths used by output data exiting the module are logically disconnected from the processes/threads performing key generation and key zeroization.