Rolesandservices

From MozillaWiki
Jump to navigation Jump to search

This is a draft document.

Specification of Roles

The NSS cryptographic module utilizes a single role approach -- this role, called NSS User, is a combination of both the User Role and the Crypto Officer Role. An NSS User utilizes secure services and is also responsible for the retrieval, updating, and deletion of keys from his key database.

The Crypto Officer role is assumed to install the NSS libraries and initialize them to operate in FIPS 140-2 mode. See Installation. The Crypto Officer must control the 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.

Specification of Maintenance Roles

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

Authentication Policy

The NSS cryptographic module uses Role-Based Authentication to control access to the module. To perform sensitive services using the cryptographic module, an operator must explicitly request to assume the NSS User role by logging into the module, and perform an authentication procedure using information unique to that operator (individual password). Role-based authentication is used to safeguard a user's private key information. However, Discretionary Access Control (DAC) is used to safeguard all other NSS User information (e.g., the public key certificate database). An NSS User may use a product (e.g., Mozilla Firefox) without establishing a personal private key -- e.g., they may utilize SSL Server Authentication without having a private key established. However, to enable SSL on a server product, 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.

Multiple Concurrent Operator Roles and Services

The NSS module doesn't allow concurrent operators.

  • For Security Level 1, the operating system has been restricted to a single operator mode of operation, so concurrent operators are explicitly excluded (FIPS 140-2 Sec. 4.6.1).
  • On a multi-user operating system, this is enforced by creating the NSS certificate and key databases with the 0600 access permission bits.

Note: The NSS module does allow concurrent processes with the same user identity to access the module, with the restriction that all the concurrent processes must open the NSS databases in read-only mode. Each process accessing the NSS module needs to assume a role separately. The separation between the roles and services performed by concurrent processes is enforced by the process protection of the underlying operating system.

The NSS module also allows a process to open multiple concurrent sessions (connections) with the module. PKCS #11 requires that when a session within a process assumes a role, all the concurrent sessions within the process assume that role (PKCS #11 v2.20, Sec. 11.4, C_Login). Therefore, the separation of the roles assumed by concurrent sessions and the corresponding services isn't an issue.

Specification of Services

Since there is only one role, the user has access to ALL the services. Routines have been specified for each service and denoted whether they are public, meaning that they require no authentication to utilize, or private, meaning that authentication must be provided before the routine is utilized. This model allows a type of safety state by allowing a NSS user to log out (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

PKCS #11
The PKCS #11 API is a crypto API based on the PKCS #11 standard and allows for the selection of a FIPS 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 140-2 specific routines including sftk_fipsPowerUpSelfTest() at module start-up as well as on demand for subsequent logins, and
  • enforces a pair-wise consistency test on all key generation algorithms and a continuous random number generator test.

NSS's FIPS 140-2 PKCS #11 implementation defines the following standard crypto API:

General-purpose functions

  • FC_GetFunctionList()
  • FC_Initialize()
  • FC_Finalize()
  • FC_GetInfo()

Slot and token management functions

  • FC_GetSlotList()
  • FC_GetSlotInfo()
  • FC_GetTokenInfo()
  • FC_WaitForSlotEvent()
  • FC_GetMechanismList()
  • FC_GetMechanismInfo()
  • FC_InitToken()
  • FC_InitPIN()
  • FC_SetPIN()

Session management functions

  • FC_OpenSession()
  • FC_CloseSession()
  • FC_CloseAllSessions()
  • FC_GetSessionInfo()
  • FC_GetOperationState()
  • FC_SetOperationState()
  • FC_Login()
  • FC_Logout()

Object management functions

  • FC_CreateObject()
  • FC_CopyObject()
  • FC_DestroyObject()
  • FC_GetObjectSize()
  • FC_GetAttributeValue()
  • FC_SetAttributeValue()
  • FC_FindObjectsInit()
  • FC_FindObjects()
  • FC_FindObjectsFinal()

Encryption functions

  • FC_EncryptInit()
  • FC_Encrypt()
  • FC_EncryptUpdate()
  • FC_EncryptFinal()

Decryption functions

  • FC_DecryptInit()
  • FC_Decrypt()
  • FC_DecryptUpdate()
  • FC_DecryptFinal()

Message digesting functions

  • FC_DigestInit()
  • FC_Digest()
  • FC_DigestUpdate()
  • FC_DigestKey()
  • FC_DigestFinal()

Signing and MACing functions

  • FC_SignInit()
  • FC_Sign()
  • FC_SignUpdate()
  • FC_SignFinal()
  • FC_SignRecoverInit()
  • FC_SignRecover()

Functions for verifying signatures and MACs

  • FC_VerifyInit()
  • FC_Verify()
  • FC_VerifyUpdate()
  • FC_VerifyFinal()
  • FC_VerifyRecoverInit()
  • FC_VerifyRecover()

Dual-function cryptographic functions

  • FC_DigestEncryptUpdate()
  • FC_DecryptDigestUpdate()
  • FC_SignEncryptUpdate()
  • FC_DecryptVerifyUpdate()

Key management functions

  • FC_GenerateKey()
  • FC_GenerateKeyPair()
  • FC_WrapKey()
  • FC_UnwrapKey()
  • FC_DeriveKey()

Random number generation functions

  • FC_SeedRandom()
  • FC_GenerateRandom()

Parallel function management functions

  • FC_GetFunctionStatus()
  • FC_CancelFunction()
See PKCS #11 v2.20 for the purpose, function, and the specification of inputs and outputs of each API routine.
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().
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.
TLS pseudorandom function (PRF) TLS pseudorandom function (PRF) is utilized by the TLS protocol to produce FIPS 140-2 compliant hashes of security relevant data items [pre-master secret].

Show Status

The following PKCS #11 functions output the current status of the NSS module:

  • FC_GetTokenInfo: it fills in the CK_TOKEN_INFO structure with the following information:
    • flags: bit flags indicating status of the NSS module, such as whether there are some cryptographic functions that a user must be logged in to perform, whether the user's password has been initialized, whether the module has been initialized.
    • ulSessionCount: number of sessions that this application currently has open with the NSS module
    • ulRwSessionCount: number of read/write sessions that this application currently has open with the NSS module
  • FC_GetSessionInfo: If the NSS module is in the error state, FC_GetSessionInfo returns CKR_DEVICE_ERROR. Otherwise, it fills in the CK_SESSION_INFO structure with the following information:
    • state: the state of the session, i.e., no role is assumed, the User role is assumed, or the Crypto Officer role is assumed
    • flags: whether the session is read/write or read-only

The following high-level NSS functions output the current status of the NSS module:

  • PK11_IsFIPS: returns a boolean indicating if the NSS module is in the FIPS mode.

Perform Self-Tests

An operator who is already logged in can initiate and run the power-up self-tests by logging into the module again with a call to the PKCS #11 FC_Login function or the high-level NSS PK11_Authenticate function.

Bypass Capabilities

The NSS module has no bypass capability.

Retrieved from "https://wiki.mozilla.org/index.php?title=Rolesandservices&oldid=26778"