MozillaWiki

Security Policy: Difference between revisions

Page Discussion

Security Policy (view source)

Revision as of 20:50, 23 March 2007

16,554 bytes removed ,  23 March 2007
m
→‎Specification of Security Policy
Line 3: Line 3:
[http://www.mozilla.org/projects/security/pki/nss/fips/secpolicy.pdf Security Policy]
[http://www.mozilla.org/projects/security/pki/nss/fips/secpolicy.pdf Security Policy]


==Specification of Security Policy==
The NSS cryptographic module is a general-purpose cryptographic library. Its API is based on the industry standard [http://www.rsasecurity.com/rsalabs/node.asp?id=2133 PKCS #11] version 2.20. The following table specifies the security rules that each product using the NSS cryptographic module shall adhere to:


{| border="1" cellpadding="2"
|+
|-
!
Rule
!
Specification of the NSS Cryptographic Module Security Rules
|-
|-
| 1 || The NSS cryptographic module shall consist of software libraries compiled for each supported platform.
|-
| 2 || The cryptographic module shall rely on the underlying operating system to ensure the integrity of the cryptographic module loaded into memory.
|-
| 3 || The cryptographic module shall support the NSS User Role and the Crypto Officer Role.
|-
| 4 || A cryptographic module user shall have access to '''all''' the services supplied by the cryptographic module.
|-
| 5 || Cryptographic module services shall consist of public services, which require no authentication, and private services, which require authentication. Public services (e.g., random number generation) do not require access to the secret and private keys and other CSPs associated with the user.
|-
| 6 || Public key certificates shall be stored in plaintext form because of their public nature and internal CA-signing integrity features.
|-
| 7 || (This rule is intentionally left blank.)
|-
| 8 || TLS master secrets (48-byte secrets shared between the peers in TLS connections) shall be extracted from the cryptographic module in encrypted form (the TLS session ID cache, which stores the encrypted TLS master secrets, shall be considered outside the boundary of the cryptographic module).
|-
| 9 || For the FIPS PUB 140-2 mode of operation, the cryptographic module shall enforce rules specific to FIPS PUB 140-2 requirements.
|-
| 10 || The FIPS PUB 140-2 cryptographic module shall not allow critical errors to compromise security. Whenever a critical error (e.g., a self-test failure) is encountered, the cryptographic module shall enter an error state and the library shall need to be reinitialized to resume normal operation.
|-
| 11 || Upon initialization of the FIPS PUB 140-2 cryptographic module library, the following power-up self-tests shall be performed:<br>
# RC2-ECB Encrypt/Decrypt,
# RC2-CBC Encrypt/Decrypt,
# RC4 Encrypt/Decrypt,
# DES-ECB Encrypt/Decrypt,
# DES-CBC Encrypt/Decrypt,
# Triple DES-ECB Encrypt/Decrypt,
# Triple DES-CBC Encrypt/Decrypt,
# AES-ECB Encrypt/Decrypt (128-bit, 192-bit, and 256-bit keys),
# AES-CBC Encrypt/Decrypt (128-bit, 192-bit, and 256-bit keys),
# MD2 Hash,
# MD5 Hash,
# SHA-1 Hash,
# SHA-256 Hash,
# SHA-384 Hash,
# SHA-512 Hash,
# HMAC-SHA-1,-SHA-256,-SHA-384,-SHA-512 Hash (296-bit key),
# RSA Encrypt/Decrypt (1024-bit modulus ''n''),
# RSA-SHA-1,-SHA-256,-SHA-384,-SHA-512 Signature (1024-bit modulus ''n''),
# RSA-SHA-1,-SHA-256,-SHA-384,-SHA-512 Signature Verification (1024-bit modulus ''n''),
# DSA Key Pair Generation (512-bit prime modulus ''p''),
# DSA Signature (512-bit prime modulus ''p''),
# DSA Signature Verification (512-bit prime modulus ''p''),
# ECDSA Signature (Curve P-256),
# ECDSA Signature Verification (Curve P-256),
# PRNG, and
# software/firmware integrity test.
|-
| 12 || Shutting down and restarting the FIPS PUB 140-2 cryptographic module with the <code>FC_Finalize</code> and <code>FC_Initialize</code> functions shall execute the same power-up self-tests detailed above when initializing the module library for the FIPS PUB 140-2 mode. This allows a user to execute these power-up self-tests on demand as defined in Section 4.9.1 of FIPS PUB 140-2.
|-
| 13 || The FIPS PUB 140-2 cryptographic module shall require the user to establish a password (for the NSS user role) in order for subsequent authentications to be enforced.
|-
| 14 || A known password check string, encrypted with a Triple-DES key derived from the password, shall be stored in the private key database (key3.db) in secondary storage.
|-
| 15 || Once a password has been established for the FIPS PUB 140-2 cryptographic module, it shall only allow the user to use the private services if and only if the user successfully authenticates to the FIPS PUB 140-2 cryptographic module.
|-
| 16 || In order to authenticate to the cryptographic module, the user shall enter the password, and the cryptographic module shall verify that the password is correct by
* deriving a Triple-DES key from the password,
* decrypting the stored encrypted password check string with the Triple-DES key, and
* comparing the decrypted string with the known password check string.
|-
| 17 || The user's password shall act as the key material to encrypt/decrypt private key material. '''Note''': password-encrypted secret and private keys should be considered in plaintext form in FIPS mode.
|-
| 18 || Secret and private keys, plaintext passwords, and other security-relevant data items shall be maintained under the control of the cryptographic module. Secret and private keys shall only be passed to higher level callers in encrypted (wrapped) form with <code>FC_WrapKey</code>. '''Note''': if secret and private keys are passed to higher level callers in password-encrypted form, they should be considered in plaintext form in FIPS mode.
|-
| 19 || All secret and private keys shall be stored in encrypted form (using a Triple-DES key derived from the password) in the private key database (key3.db) in secondary storage. '''Note''': password-encrypted secret and private keys should be considered in plaintext form in FIPS mode.
|-
| 20 || (This rule is intentionally left blank.)
|-
| 21 || Once the FIPS PUB 140-2 mode of operation has been selected, the cryptographic module user shall only use the FIPS PUB 140-2 cipher suite.
|-
| 22 || The FIPS PUB 140-2 cipher suite shall consist solely of
* Triple-DES (FIPS PUB 46-3) or AES (FIPS PUB 197) for symmetric key encryption/decryption,
* SHA-1, SHA-256, SHA-384, or SHA-512 (FIPS PUB 180-2) for hashing,
* HMAC (FIPS PUB 198) for keyed hash,
* random number generator (FIPS PUB 186-2 Change Notice 1),
* Diffie-Hellman, EC Diffie-Hellman, or Key Wrapping using RSA keys for key establishment, and
* DSA (FIPS PUB 186-2), RSA (PKCS #1), or ECDSA (ANSI X9.62) for signature generation and verification.
<div class=note>'''Caveats''':
* Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 112 bits of encryption strength)
* EC Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 256 bits of encryption strength)
* RSA (PKCS #1, key wrapping, key establishment methodology provides between 80 bits and 192 bits of encryption strength)
</div>
|-
| 23 || Once the FIPS PUB 140-2 mode of operation has been selected, Triple-DES/AES shall be limited in its use to perform encryption/decryption using either CBC or ECB mode.
|-
| 24 || Once the FIPS PUB 140-2 mode of operation has been selected, SHA-1, SHA-256, SHA-386, and SHA-512 shall be the only algorithms used to perform one-way hashes of data.
|-
| 25 || Once the FIPS PUB 140-2 mode of operation has been selected, RSA shall be limited in its use to generating and verifying PKCS #1 signatures, and to encrypting and decrypting key material for key exchange.
|-
| 26 || Once the FIPS PUB 140-2 mode of operation has been selected, DSA and ECDSA shall be used in addition to RSA to generate and verify signatures.
|-
| 27 || In the FIPS PUB 140-2 mode of operation, the cryptographic module shall perform a pair-wise consistency test upon each invocation of RSA, DSA, and ECDSA  key pair generation as defined in section 4.9.2 of FIPS PUB 140-2.
|-
| 28 || The cryptographic module shall perform its prime number generation and primality test via the mechanisms described in Appendix 2 of FIPS PUB 186-2.
|-
| 29 || The cryptographic module shall perform pseudorandom number generation via the mechanisms described in FIPS PUB 186-2 Change Notice 1.
|-
| 30 || The cryptographic module shall seed its pseudorandom number generation via invoking a noise generator specific to the platform on which it was implemented (e.g., Macintosh, UNIX, or Windows). Pseudorandom number generator shall be seeded with noise derived from the execution environment such that the noise is not predictable.
|-
| 31 || A product using the cryptographic module shall periodically reseed the module's pseudorandom number generator with unpredictable noise.
|-
| 32 || In the FIPS PUB 140-2 mode of operation, the cryptographic module shall perform a continuous random number generator test upon each invocation of the pseudorandom number generator as defined in section 4.9.2 of FIPS PUB 140-2.
|-
| 33 || The cryptographic module takes a number of explicit zeroization steps to clear the memory region previously occupied by a plaintext secret key, private key, or password. Any plaintext secret and private keys and passwords are zeroized once the use is complete. Upon exit from the FIPS PUB 140-2 mode of operation, all plaintext secret and private keys within the cryptographic module are zeroized by having their memory contents rewritten with zeroes.
|-
| 34 || The TLS pseudorandom function (PRF) is contained within the cryptographic module.
|-
| 35 || For operation in FIPS PUB 140-2 Security 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 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.
|-
| 36 || The NSS cryptographic module consists of the following shared libraries/DLLs and the associated <code>.chk</code> files:
* Windows XP Service Pack 2
** <code>softokn3.dll</code>
** <code>softokn3.chk</code>
** <code>freebl3.dll</code>
** <code>freebl3.chk</code>
* 32-bit HP-UX B.11.11 PA-RISC
** <code>libsoftokn3.sl</code>
** <code>libsoftokn3.chk</code>
** <code>libfreebl_32int_3.sl</code>
** <code>libfreebl_32int_3.chk</code>
** <code>libfreebl_32fpu_3.sl</code>
** <code>libfreebl_32fpu_3.chk</code>
* 64-bit HP-UX B.11.11 PA-RISC
** <code>libsoftokn3.sl</code>
** <code>libsoftokn3.chk</code>
** <code>libfreebl3.sl</code>
** <code>libfreebl3.chk</code>
* Mac OS X 10.4
** <code>libsoftokn3.dylib</code>
** <code>libsoftokn3.chk</code>
** <code>libfreebl3.dylib</code>
** <code>libfreebl3.chk</code>
* 64-bit Trusted Solaris 8 SPARC
** <code>libsoftokn3.so</code>
** <code>libsoftokn3.chk</code>
** <code>libfreebl_64int_3.so</code>
** <code>libfreebl_64int_3.chk</code>
** <code>libfreebl_64fpu_3.so</code>
** <code>libfreebl_64fpu_3.chk</code>
* 32-bit Solaris SPARC
** <code>libsoftokn3.so</code>
** <code>libsoftokn3.chk</code>
** <code>libfreebl_32int_3.so</code>
** <code>libfreebl_32int_3.chk</code>
** <code>libfreebl_32int64_3.so</code>
** <code>libfreebl_32int64_3.chk</code>
** <code>libfreebl_32fpu_3.so</code>
** <code>libfreebl_32fpu_3.chk</code>
* 64-bit Solaris 10 AMD64, Red Hat Enterprise Linux 4 x86, Red Hat Enterprise Linux 4 x86_64, and other Unix/Linux platforms not mentioned above
** <code>libsoftokn3.so</code>
** <code>libsoftokn3.chk</code>
** <code>libfreebl3.so</code>
** <code>libfreebl3.chk</code>
The NSS cryptographic module requires the Netscape Portable Runtime (NSPR), which consists of the following shared libraries/DLLs:
* Windows XP Service Pack 2
** <code>plc4.dll</code>
** <code>plds4.dll</code>
** <code>nspr4.dll</code>
* HP-UX B.11.11 PA-RISC
** <code>libplc4.sl</code>
** <code>libplds4.sl</code>
** <code>libnspr4.sl</code>
* Mac OS X 10.4
** <code>libplc4.dylib</code>
** <code>libplds4.dylib</code>
** <code>libnspr4.dylib</code>
* 32-bit Solaris SPARC
** <code>libplc4.so</code>
** <code>libplds4.so</code>
** <code>libnspr4.so</code>
** <code>cpu/sparcv8plus/libnspr_flt4.so</code>
* 64-bit Solaris 10 AMD64, 64-bit Trusted Solaris 8 SPARC, Red Hat Enterprise Linux 4 x86, Red Hat Enterprise Linux 4 x86_64, and other Unix/Linux platforms not mentioned above
** <code>libplc4.so</code>
** <code>libplds4.so</code>
** <code>libnspr4.so</code>
'''Step 1:''' Install the shared libraries/DLLs and the associated <code>.chk</code> files in a directory on the shared library/DLL search path, which could be a system library directory (<code>/usr/lib</code> on Unix/Linux or <code>C:\WINDOWS\system32</code> on Windows) or a directory specified in the following environment variable:
* Windows XP Service Pack 2: <code>PATH</code>
* HP-UX B.11.11 PA-RISC: <code>SHLIB_PATH</code>
* Mac OS X 10.4: <code>DYLD_LIBRARY_PATH</code>
* AIX: <code>LIBPATH</code>
* Solaris, Linux, and other Unix/Linux platforms not mentioned above: <code>LD_LIBRARY_PATH</code>
'''Step 2:''' Use the <code>chmod</code> utility to set the file mode bits of the shared libraries/DLLs to '''0755''' so that all users can execute the library files, but only the files' owner can modify (i.e., write, replace, and delete) the files. For example, on most Unix and Linux platforms,
  $ chmod 0755 libsoftokn3.so libfreebl*3.so libplc4.so libplds4.so libnspr4.so
The discretionary access control protects the binaries stored on disk from being tampered with.
'''Step 3:''' Use the <code>chmod</code> utility to set the file mode bits of the associated <code>.chk</code> files to '''0644'''. For example, on most Unix and Linux platforms,
  $ chmod 0644 libsoftokn3.chk libfreebl*3.chk
'''Step 4:''' By default the NSS cryptographic module operates in the non-FIPS Approved mode, meaning that if an application calls the standard PKCS #11 function <code>C_GetFunctionList</code> and calls the function pointers in that list, it gets the non-FIPS Approved mode. To run the NSS cryptographic module in the FIPS Approved mode, an application must call the alternative function <code>FC_GetFunctionList</code> and call the function pointers in that list. Here is the sample code using NSPR functions (declared in the header file <code>"prlink.h"</code>) for dynamic library loading and function symbol lookup:
<pre>
#include "prlink.h"
#include "cryptoki.h"
#include <assert.h>
#include <stdio.h>
/*
* An extension of the CK_C_INITIALIZE_ARGS structure for the
* NSS cryptographic module. The 'LibraryParameters' field is
* used to pass instance-specific information to the library
* (like where to find its config files, etc).
*/
typedef struct CK_C_INITIALIZE_ARGS_NSS {
    CK_CREATEMUTEX CreateMutex;
    CK_DESTROYMUTEX DestroyMutex;
    CK_LOCKMUTEX LockMutex;
    CK_UNLOCKMUTEX UnlockMutex;
    CK_FLAGS flags;
    CK_CHAR_PTR *LibraryParameters;
    CK_VOID_PTR pReserved;
} CK_C_INITIALIZE_ARGS_NSS;
int main()
{
    char *libname;
    PRLibrary *lib;
    CK_C_GetFunctionList pC_GetFunctionList;
    CK_FUNCTION_LIST_PTR pFunctionList;
    CK_RV rv;
    CK_C_INITIALIZE_ARGS_NSS initArgs;
    PRStatus status;
    /* Get the platform-dependent library name of the NSS cryptographic module */
    libname = PR_GetLibraryName(NULL, "softokn3");
    assert(libname != NULL);
    lib = PR_LoadLibrary(libname);
    assert(lib != NULL);
    PR_FreeLibraryName(libname);
    pC_GetFunctionList = (CK_C_GetFunctionList) PR_FindFunctionSymbol(lib,
        "FC_GetFunctionList");
    assert(pC_GetFunctionList != NULL);
    rv = (*pC_GetFunctionList)(&pFunctionList);
    assert(rv == CKR_OK);
    /* Call FC_Foo as pFunctionList->C_Foo */
    initArgs.CreateMutex = NULL;
    initArgs.DestroyMutex = NULL;
    initArgs.LockMutex = NULL;
    initArgs.UnlockMutex = NULL;
    initArgs.flags = CKF_OS_LOCKING_OK;
    initArgs.LibraryParameters = (CK_CHAR_PTR *)
        "configdir='.' certPrefix='' keyPrefix='' secmod='secmod.db' flags= ";
    initArgs.pReserved = NULL;
    rv = pFunctionList->C_Initialize(&initArgs);
    assert(rv == CKR_OK);
    /* ... */
    rv = pFunctionList->C_Finalize(NULL);
    assert(rv == CKR_OK);
    status = PR_UnloadLibrary(lib);
    assert(status == PR_SUCCESS);
    return 0;
}
</pre>
To reiterate, the mode of operation of the NSS cryptographic module is determined by the second argument passed to the <code>PR_FindFunctionSymbol</code> function.
* For the non-FIPS Approved mode of operation, look up the standard PKCS #11 function <code>"C_GetFunctionList"</code>.
* For the FIPS Approved mode of operation, look up the alternative function <code>"FC_GetFunctionList"</code>.
|}


==Authentication Policy==
==Authentication Policy==
Glen
219

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/52828"