FIPS Module Specification: Difference between revisions

Jump to navigation Jump to search
Line 3: Line 3:
==Cryptographic Module Specification==
==Cryptographic Module Specification==


A series of '''security libraries''' present an application program interface ('''API''') to client and server applications utilizing NSS. The libraries are compiled and built for specific platforms (see [http://wiki.mozilla.org/Security_Policy#Platform_List Platform List]) and tagged with a release identifier to be published on mozilla.org. The release compliant with FIPS 140-2 is NSS 3.11.5.
The NSS cryptographic module is a cryptographic library that presents an application program interface ('''API''') based on the PKCS #11 standard to applications. The NSS cryptographic module is compiled and built for specific platforms (see [http://wiki.mozilla.org/Security_Policy#Platform_List Platform List]) and tagged with a release identifier to be published on [https://ftp.mozilla.org ftp.mozilla.org]. The release compliant with FIPS 140-2 is version 3.11.5.


The cryptographic module is defined to be a subset of the functions within these libraries. The subset is below the top layer of functions normally called by application programs, but the subset may be called by application programs directly if they so choose. Functions that are being certified include Triple DES(KO 1,2,3 56/112/168), AES(128/192/256), SHS (SHA-1, SHA-256, SHA-384, SHA-512), HMAC, DSA (512-1024), and RSA (1024-8092).
Functions that are being certified include Triple DES(KO 1,2,3 56/112/168), AES(128/192/256), SHS (SHA-1, SHA-256, SHA-384, SHA-512), HMAC, RNG, DSA (512-1024), RSA (1024-8092), and ECDSA.


===Module Components===
===Module Components===
NSS is a software cryptographic implementation. No hardware or firmware components are included. All input to the module is via function arguments; all output is returned to the caller either as return codes or as updated memory objects pointed to by some of the arguments.
The NSS cryptographic module is a software cryptographic implementation. No hardware or firmware components are included. All input to the module is via function arguments; all output is returned to the caller either as return codes or as updated memory objects pointed to by some of the arguments.


{| border="1" cellpadding="2"
{| border="1" cellpadding="2"
Line 15: Line 15:
!
!
Cryptographic
Cryptographic
Module
Module Components
!
!
Library
Library
Line 28: Line 28:
<div class=note>'''Note''': Filename extensions depend upon the target operating environment. For some CPUs libfreebl3 is distributed in more than one variant. The optimal version is selected at run time.</div>
<div class=note>'''Note''': Filename extensions depend upon the target operating environment. For some CPUs libfreebl3 is distributed in more than one variant. The optimal version is selected at run time.</div>


The database code of the NSS module (Berkeley DB 1.85, in mozilla/dbm and mozilla/security/nss/lib/softoken/dbmshim.c) is excluded from the security requirements of FIPS 140-2.
The database code of the NSS cryptographic module (Berkeley DB 1.85, in mozilla/dbm and mozilla/security/nss/lib/softoken/dbmshim.c) is excluded from the security requirements of FIPS 140-2.
<div class=note>'''Rationale''': The security-related information stored in the databases is either encrypted (e.g., secret and private cryptographic keys) or digitally signed (e.g., certificates and CRLs). If the database code is malfunctioning or misused, the PKCS #5 password-based encryption of the secret and private cryptographic keys will ensure their confidentiality and detect data corruption or malicious changes, and the digital signatures on the public data (certificates and CRLs) will detect data corruption or malicious changes. Therefore, the malfunction or misuse of the database code cannot cause a compromise under any reasonable condition.</div>
<div class=note>'''Rationale''': The security-related information stored in the databases is either encrypted (e.g., secret and private cryptographic keys) or digitally signed (e.g., certificates and CRLs). If the database code is malfunctioning or misused, the PKCS #5 password-based encryption of the secret and private cryptographic keys will ensure their confidentiality and detect data corruption or malicious changes, and the digital signatures on the public data (certificates and CRLs) will detect data corruption or malicious changes. Therefore, the malfunction or misuse of the database code cannot cause a compromise under any reasonable condition.</div>


Line 47: Line 47:
|-
|-
| NSPR hashtables and arena pools || libplds4
| NSPR hashtables and arena pools || libplds4
|-
|}
The NSS module is used by the following higher-level NSS libraries outside the cryptographic boundary.
{| border="1" cellpadding="2"
|+
|-
!
Higher-level NSS API
!
Library
Name
|-
| CRMF || libcrmf
|-
| S/MIME || libsmime3
|-
| Certificate<br>Management || libnss3
|-
| SSL || libssl3
|-
| JAR || libjar
|-
| PKCS #5 || libnss3
|-
| PKCS #12 || libsmime3
|-
|-
|}
|}


===The Cryptographic Boundary===
===The Cryptographic Boundary===
The NSS module is a multiple-chip standalone cryptographic module. The physical boundary of the NSS module is the enclosure of the general purpose computer it runs on, including any hardware or software that inputs, processes, or outputs important security parameters that could lead to the compromise of sensitive information if not properly controlled.
The NSS cryptographic module is a multiple-chip standalone cryptographic module. The physical boundary of the NSS cryptographic module is the enclosure of the general purpose computer it runs on, including any hardware or software that inputs, processes, or outputs important security parameters that could lead to the compromise of sensitive information if not properly controlled.


NSS's PKCS #11 (Cryptoki) implementation forms the cryptographic module. The API itself is considered to define the logical cryptographic boundary, thus all implementation is considered below the boundary. Also included in this module is the FIPS PKCS #11 token. This is a Cryptoki token designed specifically for FIPS, and allows applications using NSS to operate in a strictly FIPS mode. The diagram below shows the relationship of the layers.
The NSS cryptographic module implements the PKCS #11 (Cryptoki) API. The API itself defines the logical cryptographic boundary, thus all implementation is inside the boundary. The NSS cryptographic module has two modes of operation: non-FIPS mode (the default) and FIPS mode. <div class=note>The non-FIPS mode is implemented with a pair of PKCS #11 tokens, and the FIPS mode is implemented with the FIPS PKCS #11 token.</div> The FIPS mode is designed specifically for FIPS, and allows applications using the NSS cryptographic module to operate in a strictly FIPS mode. The diagram below shows the relationship of the layers.


[[ Image:Fipsmod.png ]]
[[ Image:Fipsmod.png ]]
Line 115: Line 88:
===Design Specification===
===Design Specification===


The design of the software components of the NSS module is specified in the following documents:
The design of the software components of the NSS cryptographic module is specified in the following documents:
* [http://wiki.mozilla.org/Section_4:_Finite_State_Model Finite State Model and Description]
* [http://wiki.mozilla.org/Section_4:_Finite_State_Model Finite State Model and Description]
* [http://www.mozilla.org/projects/security/pki/nss/intro.html Introduction to NSS]
* [http://www.mozilla.org/projects/security/pki/nss/intro.html Introduction to NSS]
Line 123: Line 96:


===Security-Related Information===
===Security-Related Information===
Security-related information whose disclosure or modification can compromise the security of the NSS module includes:
Security-related information whose disclosure or modification can compromise the security of the NSS cryptographic module includes:
* secret and private cryptographic keys (both plaintext and encrypted)
* secret and private cryptographic keys (both plaintext and encrypted)
* passwords
* passwords
* audited events, audit data
* audited events, audit data
canmove, Confirmed users
937

edits

Navigation menu