FIPS Design Assurance

Configuration Management

Configuration Management System

The NSS cryptographic module is maintained according to the development standards and rules of the Mozilla Foundation. The CVS version control system is used for maintaining all changes to the source files of the NSS cryptographic module. The source files are contained within four directories within the mozilla.org CVS repository. Each file is tracked with a revision number and a complete change history is maintained. Releases are given a CVS tag when the release is published. A source file is uniquely identified by its fully qualified pathname within the source tree and the revision number or CVS tag. The source files include all makefiles and scripts used to create the NSS cryptographic module on every platform supported.

Documentation is published on www.mozilla.org, wiki.mozilla.org, and developer.mozilla.org. www.mozilla.org is maintained by CVS. wiki.mozilla.org and developer.mozilla.org are maintained by wiki. The wiki keeps a history of changes by time stamp for each wiki page and image.

The NSS cryptographic module uses Bugzilla (https://bugzilla.mozilla.org/) for bug tracking. Bugzilla tracks not only bugs but also enhancement requests and dependencies.

Configuration List

The configuration items are:

• cryptographic module: the module is uniquely identified by the set of module components (the libsoftokn3 and libfreebl3 libraries) and has the same version as the module components. See the next item.
• software module components: the libsoftokn3 and libfreebl3 libraries are uniquely identified by their file names. On Unix, their versions can be uniquely identified by the what or ident command, for example, "what libsoftokn3.so | grep NSS" and "ident libfreebl3.so | grep NSS". On Windows, their versions can be uniquely identified by the Version tab in the Properties dialog. Each executable file in Security Policy Rule 33 (files with extensions other than .chk) will be labeled as "NSS 3.11.4".
• security policy (including user guidance): the security policy is uniquely identified by its URL, and its version is uniquely identified by the "last modified" time stamp at the bottom of the security policy.
• operating system: see the operating system documentation for the methods used to uniquely identify the operating system and its version. (On Unix, use the "uname -a" command. On Linux, use the "cat /etc/redhat-release" command. On Mac OS X, use the "About This Mac" command in the Apple menu. On Windows, use the System applet in the Control Panel.)
• associated module documentation: each documentation page is uniquely identified by its URL, and its version is uniquely identified by the "last modified" time stamp at the bottom of the page.

Delivery

NSS cryptographic module releases are available from mozilla.org's secure download site as compressed (gzipped) tar files or zip files. The site uses the HTTPS protocol (HTTP over TLS) to maintain security when delivering the NSS cryptographic module to authorized operators. The SSL certificate of the site has a 1024-bit RSA public key and is issued by the following chain of certification authorities (CAs):

• GlobalSign Root CA of GlobalSign nv-sa, Belgium. 2048-bit RSA public key.
• GlobalSign RootSign Partners CA of GlobalSign nv-sa, Belgium. 2048-bit RSA public key.
• XRamp Security Services GS CA of XRamp Security Services Inc, San Antonio, Texas, US. 2048-bit RSA public key. XRamp is a WebTrust Certified CA.
  • Certification Practices Statement (CPS): http://www.xrampsecurity.com/legal/issuer.asp
  • WebTrust audit report and management's assertions: https://cert.webtrust.org/SealFile?seal=359&file=pdf
  • Other legal documents: http://www.xrampsecurity.com/legal/

Additionally, the modules are available via S/MIME signed email. Authorized operators may contact the vendor for this form of delivery.

Installation

To install the NSS cryptographic module in the approved manner perform the following steps. Refer to Security Policy Rule 33 for more detail about these steps.

1. Expand the tar or zip file into a directory in a location that is suitably secured using the capabilities of the local operating system. Similarly download and expand a version of NSPR libraries.
2. Use the chmod 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.
3. Use the chmod utility to set the file mode bits of the associated .chk files to 0644. For example, on most Unix and Linux platforms.
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 C_GetFunctionList 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 FC_GetFunctionList and call the function pointers in that list. See the Sample Cryptographic Module Initialization Code section of the Security Policy for an example of a programmatic method of placing the NSS cryptographic module into FIPS mode.

Components

All software components of the NSS cryptographic module are contained within three libraries, libsoftokn3, libfreebl3, and libnssdbm3 as described in Section 1. The combined role that is supported is realized entirely within these three libraries. Each of these libraries is shipped with a checksum file containing a DSA signature of the library file. When the NSS cryptographic module is started up in FIPS mode, the module recomputes the SHA-1 hash of the library file and verifies the signature. Initialization fails if the signature is not valid.

An cross-reference source listing of the software components contained in the NSS cryptographic module is here.

The hardware components contained in the NSS cryptographic module are the hardware components of a general purpose computer.

Functional Specification

The NSS cryptographic module is an implementation of the PKCS #11 standard. The following documents serve as the functional specification that informally describes the NSS cryptographic module, the external interfaces (logical interfaces or API) of the module, and the purpose of the interfaces:

• PKCS #11 v2.20: API specification
• NSS cryptographic module, FIPS mode of operation: API documentation

See also

• specification of services: our vendor information for the requirements AS03.14 and AS03.15 in Section 3.2, and
• design specification: our vendor information for the requirement AS01.14 in Section 1.

Functions

After installation and setup the Crypto Officer must ensure the integrity of the cryptographic module during normal operation. The following rules should be adhered to.

1. Physical security of the computer and peripherals must be maintained.
2. Write access to the files and directories where the NSS cryptographic module is installed must be restricted to the Crypto Officer via the access control mechanisms of the host operating system.
3. Access to the memory space of the running crypto application must be secure from snooping.
4. Private key database passwords must be secured.
5. Private key material that is imported to or exported from the cryptographic module, e.g., in PKCS #12 files, must be encrypted and the passwords protected.
   Password-based encryption is not FIPS-Approved, so password-encrypted private key material in PKCS #12 files is considered in plaintext form within the scope of FIPS 140-2.

The crypto officer and user nonproprietary guidance for the NSS cryptographic module is part of the Security Policy.