FIPS Module Specification: Difference between revisions

Line 3: Line 3:
==Cryptographic Module Specification==
==Cryptographic Module Specification==


A series of '''security libraries''' represent the cryptographic module which present an application programmer 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.
A series of '''security libraries''' present an application programming 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 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. Functions that are being certified include TripleDES(KO 1,2,3 56/112/168), AES(128/192/256), SHS (SHA-1, -256, -384 -512), HMAC, DSA (512/1024), RSA (1024/8092).
The cryptographic module is defined to be a subset of these libraries. The subset is below the top layer of libraries normally called by application programs, but the subset may be called by application programs directly if they so choose. Module 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).


===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 argument; all output is returned to the caller either as return codes or as updated memory objects pointers to which constitute some of the arguments.
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.


{| border="1" cellpadding="2"
{| border="1" cellpadding="2"
Line 20: Line 20:
Name
Name
|-
|-
| CRMF || libnss3
| PKCS #11 || libsoftokn3
|-
| FREEBL || libfreebl3* (one is selected at run time)
|-
|}
 
Higher-level NSS libraries use the NSS module. These higher-level libraries are outside the cryptographic boundary.
 
{| border="1" cellpadding="2"
|+
|-
!
Higher-level NSS API
!
Library
Name
|-
| CRMF || libcrmf
|-
|-
| S/MIME || libsmime3
| S/MIME || libsmime3
Line 30: Line 47:
| JAR || libjar
| JAR || libjar
|-
|-
| PKCS #5 || pk11wrap, libsoftokn3
| PKCS #5 || libnss3
|-
| PKCS #11 || libsoftokn3
|-
| FREEBL || libfreebl3* (one is selected at run time)
|-
|-
| PKCS #12 || libpkcs12
| PKCS #12 || libpkcs12
Line 40: Line 53:
|}
|}


Filename extensions depend upon the target operating environment. For some CPUs libfreebl is distributed in more than one variant. The optimal version is selected at run time.
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.


===The Cryptographic Boundary===
===The Cryptographic Boundary===
NSS's PKCS#11 (Cryptoki) implementation forms the cryptographic module. The API itself is considered to define the 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.
NSS's PKCS #11 (Cryptoki) implementation forms the cryptographic module. The API itself is considered to define the 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.


[[ Image:Fipsmod.png ]]
[[ Image:Fipsmod.png ]]


===Approved Mode of Operation===
===Approved Mode of Operation===
In order to run the NSS module in the FIPS approved mode an attribute must be explicitly set on the module. This can be done programatically or by running the NSS module utility function. An example command line is below.
In order to run the NSS module in the FIPS approved mode, an attribute must be explicitly set on the module. This can be done programmatically or by running the NSS module utility '''modutil'''. An example command line is below.


'''modutil -fips true -dbdir certdir'''
'''modutil -fips true -dbdir certdir'''
canmove, Confirmed users
937

edits