Rolesandservices

This is a draft document.

Specification of Roles

A series of security libraries represent the cryptographic module which present the same application programmer interface (API ) to client and server products utilizing NSS. There are minor variations, listed in the module interfaces description, but these do not break the following definition of roles. The NSS cryptographic module utilizes a single role approach -- this role is a combination of both the User Role and the Cryptographic Officer Role, and will be referenced below as NSS User. An NSS User utilizes secure services, and is also responsible for making decisions related to retrieval, updating, and deletion of keys from their key database. This is true for both client and server products. For multiple user products, like the HTTP Server, the server still operates in this single role paradigm, under a single identity.

The Crypto Officer role is assumed during installation of the NSS libraries and initializing them to operate in FIPS 140-2 mode. See Installation. The Crypto Officer must arrange for control of access to the module both before and after initialization. Control consists of management of physical access to the computer executing the NSS code as well as management of the security facilities provided by the operating system.

Authentication Policy

The NSS cryptographic module utilizes Role-Based Authentication - An operator who is allowed to use the cryptographic module must perform an authentication sequence using information unique to that operator (individual password) to perform sensitive services using the cryptographic module. Role-based authentication is utilized to safeguard a users private key information. However, Discretionary Access Controls (DAC) are used to safeguard all other NSS User information (e.g., the Public Key Certificate database). An NSS User may use a product (e.g. Netscape Navigator) without establishing a personal private key -- e.g., they may utilize SSL 3.0 Server Authentication without having a private key established. However, to enable SSL on the server products, a private key and public key certificate are required to enable secure services. An individual password is required in order to start the server -- this password is used to decrypt the private key.

Specification of Maintenance Roles

This section is not applicable to the NSS cryptographic module since it does not have a Maintenance Role.

Multiple Concurrent Operator Roles and Services

In FIPS 140-2, the term "operator" means an individual accessing a cryptographic module or a process (subject) operating on behalf of the individual, regardless of the assumed role.

The NSS module doesn't support concurrent operators in the first sense of the term "operator." However, the NSS module allows multiple concurrent processes to access it. Moreover, the NSS module allows a process to open multiple concurrent sessions (connections) with it.

PKCS #11 requires that a role be assumed on a per process basis.

• Each process accessing the NSS module needs to assume a role separately.
• When a process assumes a role, all the concurrent sessions between the process and the NSS module assume that role.

The separation of the roles assumed by each process and the corresponding services within each role is maintained by the process protection of the underlying general purpose operating system. Within each process, since there can be at most one assumed role at any time, the separation of authorized roles and corresponding services isn't an issue.

Note: the description in this section actually applies to any PKCS #11 module that supports concurrent processes and runs on a general purpose operating system.

Specification of Services

In each of the following services, since there is only one role, the user has access to ALL the services mediated by the application (for both client and server products). Routines have been specified for each service and denoted whether or not they are public, meaning that they require no authentication to utilize, or private, meaning that authentication must be provided prior to the routine being utilized. This model allows a type of safety state by allowing a NSS user to logout (thus disallowing any access to private services) without ending the session, and then log back in to re-authenticate private services rendered by the cryptographic module. All public and private services are listed in the following table:

Table II. Services

Name of Service	Description of Service in Terms of Routines
Certificate Storage and Retrieval	This private service consists of six routines used to perform certificate storage and retrieval including SEC_OpenPermCertDB(), AddCertToPermDB(), SEC_TraversePermCerts(), SEC_FindPermCertByKey(), SEC_DeletePermCertificate(), and CERT_ClosePermCertDB().
Digital Signatures	This private service consists of the one routine used to perform DSA signature generation, DSA_SignDigest(), and the one routine used to perform DSA signature verification, DSA_VerifyDigest(). This service also consists of the three routines used for RSA signature generation, verification, and entity association: RSA_Sign(), RSA_CheckSign(), and RSA_CheckSignRecover(), and the three raw routines used for RSA signature generation, verification, and entity association: RSA_SignRaw(), RSA_CheckSignRaw(), and RSA_CheckSignRecoverRaw(). In general, the key generation service must be invoked prior to invoking this service.
Encryption/Decryption	This private service consists of the four routines used to perform DES Encryption/Decryption including DES_CreateContext(), DES_Encrypt(), DES_Decrypt(), and DES_DestroyContext(). Single-key DES service is provided by using the NSS_DES and NSS_DES_CBC modes with DES_CreateContext(). Triple-DES service is provided by using the NSS_DES_EDE3 and NSS_DES_EDE3_CBC modes with DES_CreateContext().
Hashing	This public service consists of the eight routines used to perform SHA-1 hashing including SHA1_NewContext(), SHA1_CloneContext(), SHA1_Begin(), SHA1_Update(), SHA1_End(), SHA1_HashBuf(), SHA1_Hash(), and SHA1_DestroyContext().
Key Generation	This private service is utilized to perform key generation and consists of the six routines used to perform DSA key generation including PQGParamGen(), PQG_ParamGenSeedLen(), PQG_VerifyParams(), DSA_CreateKeyGenContext(), DSA_NewKey(), and DSA_NewKeyFromSeed(), and the one routine used for RSA private key generation called RSA_NewKey() (only used for entity association in public key exchange). When RSA_NewKey() is used in public key exchange between two parties, the Pairwise Consistency Test requires routines to check this symmetric algorithm. These consist of two routines used for entity association which include RSA_EncryptBlock(), and RSA_DecryptBlock(), and two raw routines used for entity association which include RSA_EncryptRaw(), and RSA_DecryptRaw().
PKCS #5 Password-Based Encryption	The PKCS #5 API specifies a standard interface based upon the PKCS #5 standard which allows this private service to be used to perform password-based encryption and consists of the five routines including SEC_PKCS5GetCryptoAlgorithm(), SEC_PKCS5GetIV(), SEC_PKCS5GetKeyLength(), SEC_PKCS5GetPBEAlgorithm(), and SEC_PKCS5IsAlgorithmPBEAlg().
PKCS #11	The PKCS #11 API specifies a standard interface based upon the PKCS #11 standard which allows for the selection of a FIPS PUB 140-2 mode of operation that provides both public and private services as well as a means of authentication into all private services, creates and maintains entry points for all FIPS PUB 140-1 specific routines including pk11_fipsPowerUpSelfTest() at initialization as well as on demand for subsequent logins, and enforces a pairwise consistency check on all key generation algorithms. NSS's FIPS PUB 140-2 PKCS #11 implementation defines the following standard crypto API: FC_GetFunctionList(), FC_Initialize(), FC_Finalize(), FC_GetInfo(), FC_GetSlotList(), FC_GetSlotInfo(), FC_GetTokenInfo(), FC_GetMechanismList(), FC_GetMechanismInfo(), FC_InitToken(), FC_InitPIN(), FC_SetPIN(), FC_OpenSession(), FC_CloseSession(), FC_CloseAllSessions(), FC_GetSessionInfo(), FC_Login(), FC_Logout(), FC_CreateObject(), FC_CopyObject(), FC_DestroyObject(), FC_GetObjectSize(), FC_GetAttributeValue(), FC_SetAttributeValue(), FC_FindObjectsInit(), FC_FindObjects(), FC_EncryptInit(), FC_Encrypt(), FC_EncryptUpdate(), FC_EncryptFinal(), FC_DecryptInit(), FC_Decrypt(), FC_DecryptUpdate(), FC_DecryptFinal(), FC_DigestInit(), FC_Digest(), FC_DigestUpdate(), FC_DigestFinal(), FC_SignInit(), FC_Sign(), FC_SignUpdate(), FC_SignFinal(), FC_SignRecoverInit(), FC_SignRecover(), FC_VerifyInit(), FC_Verify(), FC_VerifyUpdate(), FC_VerifyFinal(), FC_VerifyRecoverInit(), FC_VerifyRecover(), FC_GenerateKey(), FC_GenerateKeyPair(), FC_WrapKey(), FC_UnwrapKey(), FC_DeriveKey(), FC_SeedRandom(), FC_GenerateRandom(), FC_GetFunctionStatus(), FC_CancelFunction(), FC_GetOperationState(), FC_SetOperationState(), FC_FindObjectsFinal(), FC_DigestEncryptUpdate(), FC_DecryptDigestUpdate(), FC_SignEncryptUpdate(), FC_DecryptVerifyUpdate(), FC_DigestKey(), FC_WaitForSlotEvent(),
PKCS #12 Personal Information Exchange	The PKCS #12 API will specify a standard interface based upon the forthcoming PKCS #12 standard which allows this private service to be used to exchange data such as private keys and certificates between two parties and consists of the routines SEC_PKCS12AddCertAndKey(), SEC_PKCS12AddPasswordIntegrity(), SEC_PKCS12CreateExportContext(), SEC_PKCS12CreatePasswordPrivSafe(), SEC_PKCS12CreateUnencryptedSafe(), SEC_PKCS12EnableCipher(), SEC_PKCS12Encode(), SEC_PKCS12DecoderImportBags(), SEC_PKCS12DecoderFinish(), SEC_PKCS12DecoderStart(), SEC_PKCS12DecoderUpdate(), SEC_PKCS12DecoderValidateBags(), SEC_PKCS12DecoderVerify(), SEC_PKCS12DestroyExportContext(), SEC_PKCS12IsEncryptionAllowed(), SEC_PKCS12SetPreferredCipher(), SEC_PKCS12DecoderGetCerts(), SEC_PKCS12DecoderSetTargetTokenCAs(), SEC_PKCS12DecoderIterateInit(), SEC_PKCS12DecoderIterateNext(),
Prime Number Generation	This public service consists of the two routines used for generating a prime number including mpp_make_prime() and mpp_pprime().
Private Key Storage and Retrieval	This private service is utilized to perform private key storage and retrieval and consists of the seven routines including SECKEY_OpenKeyDB(), SECKEY_TraverseKeys(), SECKEY_UpdateKeyDBPass1() SECKEY_UpdateKeyDBPass2(), SECKEY_FindKeyByPublicKey(), SECKEY_DeleteKey(), and SECKEY_CloseKeyDB().
Pseudorandom Number Generation	This public service consists of the four routines used for global pseudorandom number generation including RNG_RNGInit(), RNG_GenerateGlobalRandomBytes(), RNG_RandomUpdate(), and RNG_RNGShutdown(), and the three routines used for seeding pseudorandom number generation including RNG_GetNoise(), RNG_SystemInfoForRNG(), and RNG_FileForRNG(). A continuous pseudorandom number generator test is performed whenever a new pseudorandom number is generated.
SSL Session Cache ID Cache (Secret Management)	This public service consists of the routines used to perform session ID cache management including SSL_ConfigServerSessionIDCache(), SSL_GetSessionID(), SSL_InheritMPServerSIDCache().
TLS pseudorandom function (PRF)	TLS pseudorandom function (PRF) is utilized by SSL 3.0 protocol to produce FIPS 140-2 compliant hashes of security relevant data items [pre-master secret]. See SSL changes in Security Module 1.01 for full details.

Bypass Capabilities

When initialized in FIPS mode the module has no bypass capability.