ModuleInterfaces

This is a draft

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 would be those of the general purpose computer it runs on.

Logical Interfaces

The following four logical interfaces have been designed within 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 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.
• 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
• Status output interface: function return codes, error codes, or output arguments that receive status information used to indicate the status of the NSS 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 mix input and output buffers.

The logical interfaces of the NSS module consist of the following APIs.

PKCS #11

This defines NSS's PKCS #11 (Cryptoki) implementation. The API itself is considered to define the top edge of the cryptographic boundary, i.e., all application and upper level library access to the FIPS module is through this API. Also included in this module is the FIPS PKCS #11 token and the crypto algorithm support library called freebl. The FIPS PKCS #11 token is a Cryptoki token designed specifically for FIPS, and allows applications using NSS to operate in a strictly FIPS mode.

The functions in the PKCS #11 API are listed in Table II of the Security Policy.

S/MIME

Interfaces for S/MIME version 3 and PKCS #7 secure mail. Not part of the cryptographic boundary.

SSL/TLS

Interfaces for Secure Sockets Layer and Transport Layer Security. Not part of the cryptographic boundary.

Certificate

Used for high-level certificate calls, for example processing the parts of a certificate, and CRL management. Not part of cryptographic boundary.

Key

High-level private/public key calls. Includes retrieving information about the key, such as its strength. Not part of cryptographic boundary.

Crypto

Provides high-level access to hashing, signature, and verification operations. Not part of cryptographic boundary.

PKCS #12

Interface for PKCS #12, Personal Information Storage and Retrieval. Used to allow import/export of certificates and private keys in a secure manner. Not part of cryptographic boundary.

CRMF

Interfaces for CRMF/CMMF. Not part of cryptographic boundary.

JAR

Signed object interface. Not part of cryptographic boundary.

Inhibition of Data Output

All data output via the data output interface is inhibited when the NSS module is in the fatal error state or performing self-tests.

In Error State

When the NSS module is in the fatal error state, most PKCS #11 functions, including all the functions that output data via the data output interface, do nothing and 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 fatal error state: 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 module performs power-up self-tests in FC_Initialize and FC_Login.

No PKCS #11 function (except FC_GetFunctionList) works before the NSS module is "powered up" (i.e., before FC_Initialize is called), so all data output via the data output interface is inhibited while FC_Initialize is performing the self-tests.

When the user is not logged in to the NSS module, all functions that use secret or private cryptographic keys, including those that output data via the data output interface, do nothing and return the CKR_USER_NOT_LOGGED_IN error code immediately. Only the following functions may be called when the user is not logged in to the NSS module: FC_GetFunctionList, FC_Finalize, FC_GetInfo, FC_GetSlotList, FC_GetSlotInfo, FC_GetTokenInfo, FC_GetMechanismList, FC_GetMechanismInfo, FC_InitToken, FC_InitPIN, FC_OpenSession, FC_CloseSession, FC_CloseAllSessions, FC_GetSessionInfo, FC_Login, FC_DigestInit, FC_Digest, FC_DigestUpdate, FC_DigestFinal, FC_SeedRandom, FC_GenerateRandom, FC_GetOperationState, FC_SetOperationState, and FC_WaitForSlotEvent.