FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html FIPS PUB 140-1 Network Security Services Security Policy [Updated to reflect NSS 3.2.2 Maintenance Validation] 1.1 Specification of Security Policy A security policy includes the precise specification of the security rules under which the cryptographic module must operate, including rules derived from the security requirements of the FIPS PUB 140-1 standard, and the additional security rules listed below. The rules of operation of the cryptographic module that define within which role(s), and under what circumstances (when performing which services), an operator is allowed to maintain or disclose each security relevant data item of the cryptographic module. There are three major reasons for developing and following a precise cryptographic module security policy: To induce the cryptographic module vendor (Sun Microsystems) to think carefully and precisely about who they want to access the cryptographic module, the way different system elements can be accessed, and which system elements to protect. To provide a precise specification of the cryptographic security to allow individuals and organizations (e.g., validators) to determine whether the cryptographic module, as implemented, does obey (satisfy) a stated security policy. To describe to the cryptographic module user (organization, or individual operator) the capabilities, protections, and access rights they will have when using the cryptographic module. It should be noted that NSS utilizes RSA's PKCS #11, version 2.01, to form most of its cryptographic boundary. This, along with some certificate handling mechanisms, comprise the entire cryptographic module boundary. The following table states the various security policy rules which will be adhered to by each product utilizing NSS: Table I. NSS Security Policy Rules Rule Statement of NSS Security Policy Rule The NSS cryptographic module shall consist of a series of binary software libraries compiled 1 for each supported platform. The cryptographic module shall rely on the underlying operating system to ensure the integrity 2 of the cryptographic module loaded into memory. 1 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html The cryptographic module shall enforce a single role approach which is a combination of the 3 User Role and the Cryptographic User Role as defined in FIPS PUB 140-1. A cryptographic module user shall have access to ALL the services supplied by the 4 cryptographic module. Cryptographic module services shall consist of public services which require no 5 authentication, and private services which require authentication. Public key certificates shall be stored in plain text form because of their public nature and 6 internal CA-signing integrity features. SSL 2.0, 3.0, and TLS shall utilize authentication mechanisms above the cryptographic module 7 which pass-through to utilize PKCS #11 authentication mechanisms which are within the cryptographic module. SSL master secrets (private key data) shall be protected within the boundary of the 8 cryptographic module (the SSL secure session ID cache shall be considered within the boundary of the cryptographic module). For the FIPS PUB 140-1 mode of operation, the cryptographic module shall enforce rules 9 specific to FIPS PUB 140-1 requirements. The FIPS PUB 140-1 cryptographic module shall use an exception handling mechanism to 10 ensure that critical errors are not allowed to compromise security (i. e. - whenever a critical error is encountered, the cryptographic module shall be required to be reinitialized). Upon initialization of the FIPS PUB 140-1 cryptographic module, the following power-up self-tests shall be performed: (1) RC2-ECB Encrypt/Decrypt, (2) RC2-CBC Encrypt/Decrypt, (3) RC4 Encrypt/Decrypt, (4) DES-ECB Encrypt/Decrypt, (5) DES-CBC Encrypt/Decrypt, (6) triple DES-ECB Encrypt/Decrypt, (7) triple DES-CBC Encrypt/Decrypt, (8) MD2 Hash, 11 (9) MD5 Hash, (10) SHA-1 Hash, (11) RSA Encrypt, (12) RSA Decrypt, (13) RSA Signature, (14) RSA Signature Verification, (15) DSA Signature, and (16) DSA Signature Verification. Additionally, if the user performs logout services, these same power-up self-tests are performed when the user logs back in to the FIPS PUB 140-1 cryptographic module. Subsequent logins to the FIPS PUB 140-1 cryptographic module during the same established 12 session shall execute the same series of power-up self-tests detailed above when logging-in under the FIPS PUB 140-1 mode. This allows a user to execute these power-up self-tests on 2 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html demand as defined in section 4.11.1 of FIPS PUB 140-1. The FIPS PUB 140-1 cryptographic module shall require the user to establish a password (for 13 the user role) in order for subsequent authentications to be enforced. 14 All passwords shall be stored in an encrypted form in secondary storage. Once a password has been established for the FIPS PUB 140-1 cryptographic module, it shall 15 only allow the user to use security services if and only if the user successfully authenticates to the FIPS PUB 140-1 cryptographic module. In order to verify the user's stored password, the user shall enter the password, and the 16 verification that the password is correct shall be performed by the cryptographic module via PKCS #5 password-based encryption mechanisms. 17 The user's password shall act as the key material to encrypt/decrypt private key material. The cryptographic module shall only extract private keys wrapped with a password according 18 to PKCS #12. Private keys, plain text PINs, and other security relevant data items (SRDIs) shall be 19 maintained under the control of the cryptographic module, and shall not be passed to higher level callers. 20 All private keys shall be stored in an encrypted form in secondary storage. Integrity checks shall be applied to the private and public key material retrieved from the 21 database to ensure genuine data. Once the FIPS PUB 140-1 mode of operation has been selected, the cryptographic module 22 shall only allow FIPS PUB 140-1 cipher suite functionality. The FIPS PUB 140-1 cipher suite shall consist solely of DES/Triple-DES (FIPS PUB 46-3) for encryption/decryption, SHA-1 (FIPS PUB 180-1) for hashing, RSA for key distribution, and 23 DSA (FIPS PUB 186) or RSA (PKCS #1) for generic signature signing and verifying functionality. Once the FIPS PUB 140-1 mode of operation has been selected, DES/Triple-DES shall be 24 limited in its use to perform encryption/decryption using either CBC or ECB mode. Once the FIPS PUB 140-1 mode of operation has been selected, SHA-1 shall be the only 25 algorithm used to perform one-way hashes of data. Once the FIPS PUB 140-1 mode of operation has been selected, RSA shall be limited in its use 26 to generation of PKCS#1 signatures and verification of them, and to signing and verifying key material for key exchange. Once the FIPS PUB 140-1 mode of operation has been selected, DSA shall be used in addition 27 to RSA to generate signatures and to perform verification on them. In the FIPS PUB 140-1 mode of operation, the cryptographic module shall perform a pairwise 28 consistency test upon each invocation of RSA and DSA key generation as defined in section 4.11.2 of FIPS PUB 140-1. The FIPS PUB 140-1 cryptographic module shall employ its prime number generation and 29 verification via the mechanisms described in Appendix 2 of FIPS PUB 186. The FIPS PUB 140-1 cryptographic module shall utilize pseudorandom number generation as 30 defined via the mechanisms described in Appendix 3 of FIPS PUB 186. 3 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html The FIPS PUB 140-1 cryptographic module shall seed its pseudorandom number generation via invoking a noise generator specific to the platform on which it was implemented (e. g. - 31 MacIntosh, UNIX, or Windows). Pseudorandom number generator shall be seeded with noise derived from the execution environment such that the noise is not predictable. The FIPS PUB 140-1 cryptographic module's pseudorandom number generator shall 32 periodically reseed itself with pseudorandom noise. In the FIPS PUB 140-1 mode of operation, the cryptographic module shall perform a 33 pseudorandom number generation test upon each invocation of the pseudorandom number generator as defined in section 4.11.2 of FIPS PUB 140-1. Upon exit from the FIPS PUB 140-1 mode of operation, all security relevant data items within 34 the cryptographic module which are stored to secondary storage shall be zeroized by having their memory contents rewritten with zeroes. The TLS pseudorandom function (PRF) is contained within the cryptographic module, and it shall enforce if one hash is weak the PRF function would remain strong, this is accomplished 35 by exclusive-oring the results of the two hashes in computation of security relevant data items -- specifically SSL pre-master secrets. For operation in FIPS PUB 140-1 Level 2 mode, the machine shall be labeled in a tamper-evident manner. Labels are to be supplied by the vendor and placed by the user on the bottom right and left edges midway between the front and the back of the case. Before placing 36 labels, clean the portion of the case where the labels will adhere with rubbing alcohol, and allow the case to dry. Apply the labels to the indicated locations, and allow labels to set for 24 hours. The FIPS module is activated with a call to SECMOD_DeleteModule(), with the module to 37 delete being the internal module. This will disable non-FIPS use of NSS, and enable the FIPS mode of operation. NSS clients may provide UI for enabling FIPS operation. Additionally, a cryptographic module security policy should be expressed in terms of the roles, services, cryptographic keys , and other critical security parameters . It should consist of, at a minimum, an identification and authentication (I&A) policy and an access control policy. An I&A policy specifies whether a cryptographic module operator is required to identify his or her self to the system, and, if so, what information is required and how it should be presented to the system in order for the operator to prove his or her identity to the system (i.e., authenticate themselves). Information required to be presented to the system might be passwords or individually unique biometric data. Once an operator can perform service(s) using the cryptographic module, an access control policy specifies what mode(s) of access he or she has to each security relevant data item while performing a given service. 1.2 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 . A 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 4 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html Server, the server still operates in this single role paradigm, under a single identity. 1.2.1 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. 1.3 Specification of Maintenance Roles This section is not applicable to the NSS cryptographic module since it does not have a Maintenance Role. 1.4 Multiple Concurrent Operator Roles and Services Since NSS-based applications always operate under a single role, under a single identity, no separate concurrent processes take place within an NSS-based application. In the case of separate threads of execution within the same process, NSS's threading model consists of a shared data segment with separate stack instances, and does not allow threads to leak insecurity into or out of the given process. Further, since a thread is not a separate process, and all threads of a given process live within the confines of that process, then all threads are subject to the same security imposed on the process itself. 1.5 Specification of Services The vendor documentation shall fully describe each service including its purpose and function. Possible services may include, but not be limited to, the following: Cryptographic operations such as encryption, decryption, message integrity, digital signature generation, digital signature verification, and other operations that require the use of cryptography. Key management operations such as key and parameter entry, key generation, key output , key archiving, key zeroization, and other key management functions. Cryptographic management functions such as audit parameter entry and setting, alarm handling and resetting, and other cryptographic management functions. Performance of operator-selectable self tests, such as cryptographic algorithm tests, software/firmware tests , critical functions tests, statistical random number generator tests, or any additional tests that can be initiated by an operator. The vendor documentation shall specify, for each service, the service inputs, corresponding service outputs, and the authorized role or roles in which the service can be performed. Service inputs shall consist of all data or control inputs to the module that initiate or obtain specific services, operations, or functions. 5 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html Service outputs shall consist of all data and status outputs that result from services, operations or functions initiated or obtained by service inputs. The vendor may supply a matrix that displays the services that can be performed in each role. 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 This private service consists of six routines used to perform certificate storage and Certificate retrieval including SEC_OpenPermCertDB(), AddCertToPermDB(), Storage and SEC_TraversePermCerts(), SEC_FindPermCertByKey(), Retrieval SEC_DeletePermCertificate(), and CERT_ClosePermCertDB(). 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 Digital for RSA signature generation, verification, and entity association: RSA_Sign(), Signatures 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. This private service consists of the four routines used to perform DES Encryption/Decryption including DES_CreateContext(), DES_Encrypt(), Encryption/ DES_Decrypt(), and DES_DestroyContext(). Single-key DES service is provided by Decryption 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(). This public service consists of the eight routines used to perform SHA-1 hashing including SHA1_NewContext(), SHA1_CloneContext(), SHA1_Begin(), Hashing SHA1_Update(), SHA1_End(), SHA1_HashBuf(), SHA1_Hash(), and SHA1_DestroyContext(). 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 Key private key generation called RSA_NewKey() (only used for entity association in Generation 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(). 6 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html The PKCS #5 API specifies a standard interface based upon the PKCS #5 standard PKCS #5 which allows this private service to be used to perform password-based encryption Password-Based and consists of the five routines including SEC_PKCS5GetSalt(), Encryption SEC_PKCS5GetIV(), SEC_PKCS5GetKey(), SEC_PKCS5CipherData(), and SEC_PKCS5CreateAlgorithmID(). The PKCS #11 API specifies a standard interface based upon the PKCS #11 standard which allows for the selection of a FIPS PUB 140-1 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-1 PKCS #11 implementation defines the following standard crypto API: Category Function Description FIPS PUB 140-1 FC_GetFunctionList Return the list of FIPS PUB 140-1 functions specific General FC_Initialize initializes Cryptoki purpose FC_Finalize finalizes Cryptoki (1.1) FC_GetInfo obtains general information about Cryptoki Slot and FC_GetSlotList obtains a list of slots in the system token FC_GetSlotInfo obtains information about a particular slot management FC_GetTokenInfo obtains information about a particular token FC_GetMechansimList obtains a list of mechanisms supported by a token FC_GetMechanismInfo obtains information about a particular mechanism PKCS #11 FC_InitToken initializes a token FC_InitPIN initializes the normal user?s PIN FC_SetPIN modifies the PIN of the current user Session FC_OpenSession opens a connection or "session" between an management application and a particular token FC_CloseSession closes a session FC_CloseAllSessions closes all sessions with a token FC_GetSessionInfo obtains information about the session FC_GetOperationState saves the state of the cryptographic operation in a session (1.1) FC_SetOperationState restores the state of the cryptographic operation in a session (1.1) FC_Login logs into a token FC_Logout logs out from a token Object FC_CreateObject creates an object management FC_CopyObject creates a copy of an object FC_DestroyObject destroys an object FC_GetObjectSize obtains the size of an object in bytes FC_GetAttributeValue obtains an attribute value of an object FC_SetAttributeValue modifies an attribute value of an object 7 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html FC_FindObjectsInit initializes an object search operation FC_FindObjects continues an object search operation FC_FindObjectsFinal finishes an object search operation (1.1) Encryption FC_EncryptInit initializes an encryption operation and FC_Encrypt encrypts single-part data decryption FC_EncryptUpdate continues a multiple-part encryption operation FC_EncryptFinal finishes a multiple-part encryption operation FC_DecryptInit initializes a decryption operation FC_Decrypt decrypts single-part encrypted data FC_DecryptUpdate continues a multiple-part decryption operation FC_DecryptFinal finishes a multiple-part decryption operation Message FC_DigestInit initializes a message-digesting operation digesting FC_Digest digests single-part data FC_DigestUpdate continues a multiple-part digesting operation FC_DigestKey continues a multi-part message-digesting operation by digesting the value of a secret key as part of the data already digested (1.1) FC_DigestFinal finishes a multiple-part digesting operation Signature FC_SignInit initializes a signature operation and FC_Sign signs single-part data verification FC_SignUpdate continues a multiple-part signature operation FC_SignFinal finishes a multiple-part signature operation FC_SignRecoverInit initializes a signature operation, where the data can be recovered from the signature FC_SignRecover signs single-part data, where the data can be recovered from the signature FC_VerifyInit initializes a verification operation FC_Verify verifies a signature on single-part data FC_VerifyUpdate continues a multiple-part verification operation FC_VerifyFinal finishes a multiple-part verification operation FC_VerifyRecoverInit initializes a verification operation where the data is recovered from the signature FC_VerifyRecover verifies a signature on single-part data, where the data is recovered from the signature Dual-function FC_DigestEncryptUpdate continues a multiple-part digesting and cryptographic encryption operation (1.1) operations FC_DecryptDigestUpdate continues a multiple-part decryption and digesting operation (1.1) FC_SignEncryptUpdate continues a multiple-part signing and encryption operation (1.1) FC_DecryptVerifyUpdate continues a multiple-part decryption and verify operation (1.1) Key FC_GenerateKey generates a secret key management FC_GenerateKeyPair generates a public-key/private-key pair FC_WrapKey wraps (encrypts) a key 8 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html FC_UnwrapKey unwraps (decrypts) a key FC_DeriveKey derives a key from a base key Random number FC_SeedRandom mixes in additional seed material to the random generation number generator FC_GenerateRandom generates random data Function FC_GetFunctionStatus obtains updated status of a function running in management parallel with the application FC_CancelFunction cancels a function running in parallel with the application Callbacks Notify processes notifications from Cryptoki 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 PKCS #12 such as private keys and certificates between two parties and consists of the eight Personal routines including SEC_PKCS12CreateExportContext, Information SEC_PKCS12CreatePasswordPrivSafe(), SEC_PKCS12AddCertAndKey(), Exchange SEC_PKCS12Encode(), SEC_PKCS12DestroyExportContext(), SEC_PKCS12DecoderStart(), SEC_PKCS12DecoderUpdate(), and SEC_PKCS12DecoderFinish(). Prime This public service consists of the two routines used for generating a prime number Number including mpp_make_prime() and mpp_pprime(). Generation This private service is utilized to perform private key storage and retrieval and consists Private Key of the seven routines including SECKEY_OpenKeyDB(), SECKEY_TraverseKeys(), Storage and SECKEY_UpdateKeyDBPass1() SECKEY_UpdateKeyDBPass2(), Retrieval SECKEY_FindKeyByPublicKey(), SECKEY_DeleteKey(), and SECKEY_CloseKeyDB(). This public service consists of the four routines used for global pseudorandom number generation including RNG_RNGInit(), RNG_GenerateGlobalRandomBytes(), Pseudorandom RNG_RandomUpdate(), and RNG_RNGShutdown(), and the three routines used for Number seeding pseudorandom number generation including RNG_GetNoise(), Generation RNG_SystemInfoForRNG(), and RNG_FileForRNG(). A continuous pseudorandom number generator test is performed whenever a new pseudorandom number is generated. SSL Session ID This public service consists of the five routines used to perform session ID cache Cache management including SSL_ConfigServerSessionIDCache(), ssl_FreeSID(), (Secret ssl_LookupSID(), ssl_ChooseSessionIDProcs(), and SSL_ClearSessionCache(). Management) TLS TLS pseudorandom function (PRF) is utilized by SSL 3.0 protocol to produce FIPS pseudorandom 140-1 compliant hashes of security relevant data items [pre-master secret]. See SSL function (PRF) changes in Security Module 1.01 for full details. 1.6 Bypass Capabilities This section is not applicable to NSS since it does not allow for any bypass capability. 9 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html 1.7 Access Control Policy The access control policy enforced by the cryptographic module must be sufficiently precise, and of sufficient detail to allow the operator and testers to know what security relevant data items the operator has access to while performing a service, and the modes of access he or she has to these data items. Also, the testers and operator must be able to know if and how the kinds of data items accessible changes when the service is invoked from each role in which it can be invoked. 1.7.1 Security Relevant Data Items Security relevant data items consist of data types used for Certificate Storage and Retrieval, Digital Signatures, Encryption/Decryption, Generic Containers, Hashing, Key Generation, PKCS #5 Password-Based Encryption, PKCS #12 Personal Information Exchange, Private Key Storage and Retrieval, Pseudorandom Number Generation, and SSL Session ID Cache (Secret Management). All security relevant data items are identified by category, type, name, and description in the following table: 10 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html Table III. Security Relevant Data Items Description of Data Category Type of Data Item Name of Data Item Item The structure containing two typedef struct SECAlgorithmIDStr SECAlgorithmID SECItems which identify the X.500 algorithm. Generic container used to hold type of typedef struct SECItemStr SECItem data, actual data content, and length of data. Generic container used for low-level private key structures including RSA and typedef struct DSA private keys. SECKEYLowPrivateKey SECKEYLowPrivateKeyStr This structure is used below the PKCS #11 service layer and contains the actual private key. Generic Generic container Containers used for low-level public key structures including RSA and typedef struct DSA public keys. SECKEYLowPublicKey SECKEYLowPublicKeyStr This structure is used below the PKCS #11 service layer and contains the actual public key. Generic container used as a high-level pointer to the defined typedef struct private key SECKEYPrivateKey SECKEYPrivateKeyStr structures, and is used above the PKCS #11 service layer. Generic container used as a high-level typedef struct SECKEYPublicKey pointer to the defined SECKEYPublicKeyStr public key structures, and is used above the 11 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html PKCS #11 service layer. Generic container used to identify the typedef enum SECOidTag supported object IDs. Generic container used primarily to typedef enum _SECStatus SECStatus indicate success or failure. The structure representing an typedef struct CERTCertificateStr CERTCertificate X.509 certificate object (the unsigned form). The structure Certificate typedef struct representing a handle CERTCertDBHandle Storage and CERTCertDBHandleStr to an open certificate Retrieval database. The trust structure typedef struct CERTCertTrustStr CERTCertTrust containing flags for SSL and email. The structure for typedef struct _certDBEntryCert certDBEntryCert certificate database entries. The structure representing the context of a digital typedef struct DSAPrivateKeyStr DSAPrivateKey signature containing data associated with the private portion of the DSA key pair. The structure representing the Digital context of a digital Signatures signature verification typedef struct DSAPublicKeyStr DSAPublicKey containing data associated with the public portion of the DSA key pair. The structure representing the typedef struct RSAPrivateKeyStr RSAPrivateKey context of an RSA signature generation 12 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html or decryption mechanism used for both signature generation and key exchange; containing data associated with the private portion of the RSA key pair. The structure representing the context of an RSA signature verification or encryption mechanism used for typedef struct RSAPublicKeyStr RSAPublicKey both signature verification and key exchange; containing data associated with the public portion of the RSA key pair. The structure representing the context of a DES encryption/decryption containing an encrypt/decrypt flag, space for up to three distinct keys, space Encryption/ typedef struct DESContextStr DESContext for the carry-forward Decryption needed for CBC modes of DES, and function pointers to the appropriate encryption and decryption functions associated with that mode of DES. The structure representing the context of a SHA-1 Hashing typedef struct SHA1ContextStr SHA1Context hash containing information relevant to performing a SHA-1 hash. 13 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html The structure representing the context of a digital signature key generation containing multiple items typedef struct PQGParamsStr PQGParams including pointers to both low-level public and private key structures containing the public and private portions of the DSA key pair. The structure representing the context of a digital signature containing data associated with typedef struct PQGVerifyStr PQGVerify the verification (in Key terms of validity) of a Generation set of parameters contained in a DSA key pair. The structure containing the private typedef struct DSAPrivateKeyStr DSAPrivateKey portion of the DSA key pair. The structure containing the public typedef struct DSAPublicKeyStr DSAPublicKey portion of the DSA key pair. The structure containing the private typedef struct RSAPrivateKeyStr RSAPrivateKey portion of the RSA key pair. The structure containing the public typedef struct RSAPublicKeyStr RSAPublicKey portion of the RSA key pair. PKCS #5 Utilizes this generic Password-Based container to hold typedef struct SECItemStr SECItem password-based Encryption encryption data. 14 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html The structure representing the typedef struct SEC_PKCS12ExportContext context of a SEC_PKCS12ExportContextStr PKCS #12 PKCS#12 export Personal operation. Information The structure Exchange representing the typedef struct SEC_PKCS12DecoderContext context of a SEC_PKCS12DecoderContextStr PKCS#12 import operation. The structure used to typedef struct mp_int hold very large numbers. Prime The integer used to Number hold error codes Generation from the typedef int mp_err Multi-Precision Arithmetic (big integer) library. The structure typedef struct representing a handle SECKEYKeyDBHandle SECKEYKeyDBHandleStr into the private key Private Key database. Storage and Retrieval Utilizes this generic typedef struct container used for SECKEYLowPrivateKey SECKEYLowPrivateKeyStr low-level private key structures. The structure containing all typedef struct SSLSecurityInfoStr SSLSecurityInfo information relevant to SSL security. SSL Session ID Cache The structure (Secret containing data Management) relevant to the SSL typedef struct SSLSessionIDStr SSLSessionID session ID including the session ID cache and the master secret. 1.7.2 Service Relationships to Security Relevant Data Items Matrix 15 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html Table IV. Service Routine to Security Relevant Data Items Matrix Read Write Service Service Routine Security Relevant Data Item Access Access CERTCertDBHandle X X CERTCertificate X X AddCertToPermDB() CERTCertTrust X X certDBEntryCert X - CERT_ClosePermCertDB() CERTCertDBHandle X X CERTCertDBHandle X X Certificate SEC_FindPermCertByKey() SECItem X X Storage and certDBEntryCert X - Retrieval CERTCertDBHandle X X SEC_OpenPermCertDB() SECStatus X - CERTCertDBHandle X X SEC_DeletePermCertificate() CERTCertificate X X SECStatus X - CERTCertDBHandle X X SEC_TraversePermCerts() SECStatus X - DSAPrivateKey X - DSA_SignDigest() SECStatus X - DSAPublicKey X - DSA_VerifyDigest() SECStatus X - SECKEYLowPrivateKey X - RSA_Sign() SECStatus X - SECKEYLowPublicKey X - RSA_CheckSign() Digital SECStatus X - Signatures SECKEYLowPublicKey X - RSA_CheckSignRecover() SECStatus X - SECKEYLowPrivateKey X - RSA_SignRaw() SECStatus X - SECKEYLowPublicKey X - RSA_CheckSignRaw() SECStatus X - SECKEYLowPublicKey X - RSA_CheckSignRecoverRaw() SECStatus X - DES_CreateContext() DESContext - X Encryption/ DESContext X X Decryption DES_Encrypt() SECStatus X - 16 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html DESContext X X DES_Decrypt() SECStatus X - DES_DestroyContext() DESContext - X SHA1_NewContext() SHA1Context - X SHA1Context X - SHA1_CloneContext() SHA1Context - X SHA1_Begin() SHA1Context - X Hashing SHA1_Update() SHA1Context X X SHA1_End() SHA1Context X X SHA1_HashBuf() SECStatus X - SHA1_Hash() SECStatus X - SHA1_DestroyContext() SHA1Context - X PQGParams - X PQG_ParamGen() PQGVerify - X SECStatus X - PQGParams - X PQG_ParamGenSeedLen() PQGVerify - X SECStatus X - PQGParams X - PQG_VerifyParams() PQGVerify X - SECStatus X - PQGParams X - DSA_NewKey() DSAPrivateKey - X Key SECStatus X - Generation PQGParams X - DSA_NewKeyFromSeed() DSAPrivateKey - X SECStatus X - RSA_NewKey() RSAPrivateKey - X SECKEYLowPublicKey X - RSA_EncryptBlock() SECStatus X - SECKEYLowPrivateKey X - RSA_DecryptBlock() SECStatus X - SECKEYLowPublicKey X - RSA_EncryptRaw() SECStatus X - SECKEYLowPrivateKey X - RSA_DecryptRaw() SECStatus X - 17 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html SECAlgorithmID X X SEC_PKCS5GetSalt() SECItem X - SECAlgorithmID X X SEC_PKCS5GetIV() SECItem X - SECAlgorithmID X X PKCS #5 SEC_PKCS5GetKey() Password-Based SECItem X - SECAlgorithmID X X Encryption SEC_PKCS5CipherData() SECItem X X SECItem X - SECOidTag X - SEC_PKCS5CreateAlgorithmID() SECItem X X SECAlgorithmID - X SEC_PKCS12CreateExportContext() SEC_PKCS12ExportContext X X SEC_PKCS12CreatePasswordPrivSafe() SEC_PKCS12ExportContext X - SEC_PKCS12ExportContext X - SEC_PKCS12AddCertAndKey() CERTCertificate X - SECStatus X - PKCS #12 Personal SEC_PKCS12ExportContext X - SEC_PKCS12Encode() Information SECStatus X - Exchange SEC_PKCS12DestroyExportContext() SEC_PKCS12ExportContext - X SEC_PKCS12DecoderStart() SEC_PKCS12DecoderContext X X SEC_PKCS12DecoderContext X - SEC_PKCS12DecoderUpdate() SECStatus X - SEC_PKCS12DecoderFinish() SEC_PKCS12DecoderContext - X mp_int X X Prime mpp_make_prime() mp_err X - Number Generation mp_int X - mpp_pprime() mp_err X - SECKEY_CloseKeyDB() SECKEYKeyDBHandle X X SECKEYKeyDBHandle X X SECKEY_DeleteKey() CERTCertificate X - Private Key SECStatus X - Storage and Retrieval SECKEYKeyDBHandle X X SECKEY_FindKeyByCert() CERTCertificate X X SECKEYLowPrivateKey X X SECKEY_OpenKeyDB() SECKEYKeyDBHandle X - 18 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html SECKEYKeyDBHandle X X SECKEY_TraversePermKeys() SECStatus X - SECKEYKeyDBHandle X X SECKEY_UpdateKeyDBPass1() SECStatus X - SECKEYKeyDBHandle X X SECKEY_UpdateKeyDBPass2() SECItem X X SECStatus X - RNG_RNGInit() SECStatus X - Pseudorandom RNG_GenerateGlobalRandomBytes() SECStatus X - Number Generation RNG_RandomUpdate() SECStatus X - RNG_RNGShutdown() void - - SSLSecurityInfo X X ssl_ChooseSessionIDProcs() SSLSessionID - X SSL Session ID SSL_ClearSessionCache() SSLSessionID X X Cache SSLSessionID X X (Secret ssl_LookupSID() Management) SSLSessionID X - SSLSessionID X X ssl_FreeSID() SSLSessionID - X SSL pre-master pk11_PRF() const SECItem *secret X X secrets 1.8 Means of Access Prior to execution of the Client or Server products, the Security Libraries are stored on disk in compiled binary form. NSS relies on Discretionary Access Controls (DAC) to protect the binary image from being tampered with. 1.9 Zeroization Within the Security Libraries, there are a number of explicit zeroization steps that are taken to clear the memory region previously occupied by a private key or password. In summary, private keys are not stored in plaintext. Any key material that has been unwrapped for use is zeroed once the use is complete. The function used to both zero and free memory used by private key material is PORT_ZFree(). 1.10 Role-based Authentication Since all NSS-based products utilize role-based authentication, and all products use a single-role mechanism referred to above as a NSS User, authentication shall always be required upon initializing the FIPS Cryptographic Module. This is true of all NSS-based client and server products, and shall be handled via the PKCS #11 mechanism of required authentication. 19 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html 1.11 Identity-based Authentication This section is not applicable to NSS since it is only applicable to products attempting to be certified to security level three or four. Results of FIPS 140-1 Level 2 Maintenance Validation of NSS 3.2.2 FIPS 140-1 Description Validation Section Level Obtained 1.0 Cryptographic Modules 2 2.0 Module Interfaces 2 3.0 Roles and Services 2 4.0 Finite State Machine Model 2 5.0 Physical Security 2 6.0 Software Security 2 7.0 Operating System Security 2 8.0 Cryptographic Key Management 2 9.0 Cryptographic Algorithms 2 10.0 EMI/EMC 2 11.0 Self-Tests 2 Results of FIPS 140-1 Level 1 Maintenance Validation of NSS 3.2.2 FIPS 140-1 Description Validation Section Level Obtained 1.0 Cryptographic Modules 1 2.0 Module Interfaces 1 3.0 Roles and Services 2 4.0 Finite State Machine Model 1 5.0 Physical Security 1 20 of 21 8/23/2002 4:36 PM FIPS PUB 140-1: 1.0 : Security Policy file:///F:/Netscape/Project%20Documentation/report/V1.4/policy.html 6.0 Software Security 1 7.0 Operating System Security 1 8.0 Cryptographic Key Management 1 9.0 Cryptographic Algorithms 1 10.0 EMI/EMC 1 11.0 Self-Tests 1 Platform List To meet the FIPS 140-1 level 1 requirement, the operating system on which NSS runs must allow only one user at a time. Windows 95, 98, and Me are single-user operating systems. Other operating systems (Windows NT 4.0, Windows 2000, SunOS, Linux, AIX, HP-UX, and OSF1) must be running in single-user mode. For the level 2 certificate, the platform validated was a Sun Ultra 1 running Solaris 8 and was configured according to the specifications listed in the Common Criteria documents referred to in the link below http://www.commoncriteria.org/ccc/epl/productType/epldetail.jsp?id=42 Level Platform Validated Obtained Windows 98 1 SunOS 5.8 2 Vendor Affirmed Platform Level Windows 95, Me, NT 4.0, 2000 1 SunOS 5.6 SPARC SunOS 5.8 SPARC 32-bit, 64-bit 1 SunOS 5.8 x86 Linux 2.2 1 AIX 4.3.3 32-bit, 64-bit 1 HP-UX B.11.00 32-bit, 64-bit 1 OSF1 V5.0A 1 21 of 21 8/23/2002 4:36 PM