FIPS Design Assurance: Difference between revisions
| Line 10: | Line 10: | ||
The configuration items are: | 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. | * 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 <code>what</code> or <code>ident</code> command, for example, <code>"what libsoftokn3.so | grep NSS"</code> and <code>"ident libfreebl3.so | grep NSS"</code>. On Windows, their versions can be uniquely identified by the Version tab in the Properties dialog. | * 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 <code>what</code> or <code>ident</code> command, for example, <code>"what libsoftokn3.so | grep NSS"</code> and <code>"ident libfreebl3.so | grep NSS"</code>. On Windows, their versions can be uniquely identified by the Version tab in the Properties dialog. Each executable file in [http://wiki.mozilla.org/Security_Policy#Specification_of_Security_Policy 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. | * 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 <code>"uname -a"</code> command. On Linux, use the <code>"cat /etc/redhat-release"</code> 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.) | * operating system: see the operating system documentation for the methods used to uniquely identify the operating system and its version. (On Unix, use the <code>"uname -a"</code> command. On Linux, use the <code>"cat /etc/redhat-release"</code> 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.) | ||
Revision as of 01:12, 5 August 2006
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
whatoridentcommand, 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 FTP site as compressed (gzipped) tar files or zip files. The tar or zip file is expanded into a directory 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 cryptographic module libraries from this directory.
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.
- Physical security of the computer and peripherals must be maintained.
- 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.
- Access to the memory space of the running crypto application must be secure from snooping.
- Private key database passwords must be secured.
- 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.