FIPS Design Assurance

Configuration Management

Configuration Management System

NSS 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 NSS. NSS 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. NSS source includes all makefiles and scripts used to create the NSS release on every platform supported.

NSS 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.

NSS 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 36 (files with extensions other than .chk) will be labeled as "NSS 3.11.5".
• 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.

Installation

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) for delivering authenticated versions of the NSS cryptographic module.

To install the NSS cryptographic module in the approved manner perform the following steps. Refer to Security Policy Rule 36 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 Rule 36 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 two libraries, libsoftokn3 and libfreebl3, as described in Section 1. The combined role that is supported is realized entirely within these two libraries. Each of these libraries is shipped with a checksum file containing a DSA signature of the library file. When NSS 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 annotated 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.

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 NSS 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.

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