FIPS Design Assurance

Configuration Management

NSS is maintained according to the development standards and rules of the Mozilla Foundation. The CVS configuration management facility is used for maintaining all changes to the source modules of NSS. NSS source files are contained within a fixed number of sub-trees within the mozilla CVS repository. Each file is tracked with a version identifier and a complete change history is maintained. Releases are given an RCS tag when the release is published. A source file is fully identified by its fully qualified name within the source tree and the version string. NSS source includes all make files and scripts used to create the NSS release on every platform supported.

NSS Documentation is published on and maintained by wiki.mozilla.org. The wiki keeps a history of changes by time stamp for each wiki page and image.

Installation

NSS releases are available from mozilla.org's FTP site as compressed (zipped) tar files. The file is expanded into a file system subtree in a location that is suitably secured using the capabilities of the local operating system.

Typically, at this point, an application is configured to use NSS libraries from this subtree. Such configuration is not specified here but consists of the following steps which can also be performed with NSS command line utilities.

• Initialize the certificate and private key data bases.

• Import certificates which are to be used by the application into the data base.

• Put the NSS cryptographic module into FIPS mode see Approved Mode of Operation and Rule #36 for information on accomplishing this programatically and via command line utilities.

Components

All components of the crytpographic module are contained within two libraries, softtokn3 and freebl3, as described in Section 1 . The combined role which is supported is realized entirely within these two libraries. Each of these libraries is shipped with a checksum file containing a signed SHA-1 hash of the library file. When NSS is started in FIPS mode the loader recomputes the hash and verifies the signature. Initialization fails if the signature is not valid.

A list of software modules is here .

Functions

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

1. Physical security of the computer and peripherals must be maintained.

1. Access to the files and directories where NSS is installed must restricted to the Crypto officer via the access mechanisms of the host operating system.

1. Access to the memory space of the running crypto application must be secure from snooping.

1. Certificate data base passwords must be secured.

1. Private key material that is imported to or exported from the crypto module, e.g. in PKCS #12 files, must be encrypted and the passwords protected.

There is no proprietary guidance for the NSS crypto module.