NSSCryptoModuleSpec/Section 9: Self Tests: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
m (GPHemsley moved page Section 9: Self Tests to NSSCryptoModuleSpec/Section 9: Self Tests without leaving a redirect: NSSCryptoModuleSpec page)
 
(20 intermediate revisions by 4 users not shown)
Line 22: Line 22:
|| [http://wiki.mozilla.org/VE_09#VE.09.04.01 VE.09.04.01 ]     
|| [http://wiki.mozilla.org/VE_09#VE.09.04.01 VE.09.04.01 ]     
||  
||  
Failure of any of the power-up, conditional, or operator-initiated self-tests causes the cryptographic module to enter the Error state ([http://wiki.mozilla.org/FIPSFSM#States State 3 ]). When the cryptographic module is in the Error state, most functions (including all the cryptographic functions) do nothing and return the error code <code>CKR_DEVICE_ERROR</code>. See also the [http://wiki.mozilla.org/Rolesandservices#Show_Status Show Status] service of the cryptographic module.
Failure of any of the power-up, conditional, or operator-initiated self-tests causes the cryptographic module to enter the Error state ([http://wiki.mozilla.org/FIPSFSM#States State 3 ]). If the pairwise consistency test fails, the <code>FC_GenerateKeyPair</code> function returns the error code <code>CKR_GENERAL_ERROR</code>. If any other self-test fails, the PKCS #11 function returns the error code <code>CKR_DEVICE_ERROR</code>. When the cryptographic module is in the Error state, most PKCS #11 functions (including all the functions that perform cryptographic operations) do nothing and return the error code <code>CKR_DEVICE_ERROR</code>. See also the [http://wiki.mozilla.org/Rolesandservices#Show_Status Show Status] service of the cryptographic module.
{| border="1" cellpadding="2"
{| border="1" cellpadding="2"
|+
|+
|-  
|-  
|'''CKR_DEVICE_ERROR''' ||  Cryptographic module is in the Error state, or has entered the Error state because a self-test (except the pairwise consistency test) fails.
|'''CKR_DEVICE_ERROR''' ||  Cryptographic module is in the Error state, or has entered the Error state because a self-test (other than the pairwise consistency test) fails.
|-  
|-  
|'''CKR_GENERAL_ERROR''' ||  Cryptographic module has entered the Error state because the pairwise consistency test fails.
|'''CKR_GENERAL_ERROR''' ||  Cryptographic module has entered the Error state because the pairwise consistency test fails.
Line 40: Line 40:
||  
||  
[http://wiki.mozilla.org/VE_09#VE.09.05.01 VE.09.05.01 ]          [http://wiki.mozilla.org/VE_09#VE.09.06.01 VE.09.06.01 ]     
[http://wiki.mozilla.org/VE_09#VE.09.05.01 VE.09.05.01 ]          [http://wiki.mozilla.org/VE_09#VE.09.06.01 VE.09.06.01 ]     
||  
||
'''Power-up self-test''':
All the PKCS #11 functions that perform cryptographic operations or output data check the Boolean state variable <code>sftk_fatalError</code> on entry. In the Error state (<code>sftk_fatalError</code> is true), no action besides returning the error code <code>CKR_DEVICE_ERROR</code> is taken by those functions, which prevents cryptograhic operations and data output. (See also [http://wiki.mozilla.org/ModuleInterfaces#In_Error_State In Error State].)
[http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#FC_Initialize PKCS #11 Initialization]:
During the PKCS #11 initialization of the FIPS 140-2 module, any error return
from the battery of self-tests will put the module in the Error state.
 
The Error state will inhibit further cryptographic operations ([http://wiki.mozilla.org/ModuleInterfaces#In_Error_State In Error State ]).
 
Output from the cryptographic module is via two paths: 1) the return code of the cryptographic function and, 2) buffers and objects which are operated on by the function, the locations of which are passed as function arguments. In the Error state the return code is always <code>CKR_DEVICE_ERROR</code>. No action besides setting the return code is taken by the requested function, which prevents data output of the second type.
|| Draft
|| Draft
|-
|-
Line 61: Line 54:
[http://wiki.mozilla.org/VE_09#VE.09.20.01 VE.09.20.01 ]  
[http://wiki.mozilla.org/VE_09#VE.09.20.01 VE.09.20.01 ]  
||  
||  
The module can perform the following self-tests:
* [http://wiki.mozilla.org/Power_Up_Selftests Power-up tests ]
* Power-up self-tests
 
** Cryptographic algorithm tests: A known-answer test is conducted for all cryptographic functions (e.g., encryption, decryption, authentication and random number generation) of each Approved cryptographic algorithm implemented by the cryptographic module: RC2, RC4, DES, Triple DES, AES-128, AES-192, AES-256, MD2, MD5, SHA-1, SHA-256, SHA-384, SHA-512, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, RSA, DSA, RNG, and ECDSA (see the [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstest.c.html power-up self-tests source code]).<div class=note>'''Note:''' Cryptographic algorithms whose outputs vary for a given set of inputs (DSA and ECDSA) are tested using a known-answer test. The message digest algorithms have independent known-answer tests.</div>
* Conditional tests
** Software integrity test
** Pair-wise consistency test (for public and private keys): the module performs the pair-wise consistency test specified in FIPS 140-2 Section 4.9.2 when it generates RSA, DSA, and ECDSA key pairs.
* Conditional self-tests
** Continuous random number generator test: the module performs the continuous random number generator test specified in FIPS 140-2 Section 4.9.2 that tests for failure to a constant value.
** Pair-wise consistency test (for public and private keys)
** In addtion to power up, NSS also performs health checks on the random number generate at instantiate and reseed time.
** Continous random number generator test
** No other conditional tests are performed.


These tests are mandatory for the FIPS 140-2 mode of
These tests are mandatory for the FIPS 140-2 mode of
Line 119: Line 112:
||  
||  


PORT_Memcmp is used to compare the calculated
<code>PORT_Memcmp</code>, a synonym for <code>memcmp</code>, is used to compare the calculated output with the known answer byte by byte.  
output with the known answer.  
[http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstest.c.dep.html                      sftk_fipsPowerUpSelfTest]
[http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstest.c.dep.html                      sftk_fipsPowerUpSelfTest]
|| Draft
|| Draft
Line 146: Line 138:
[http://wiki.mozilla.org/VE_09#VE.09.22.03 VE.09.22.03 ]     
[http://wiki.mozilla.org/VE_09#VE.09.22.03 VE.09.22.03 ]     
||  
||  
 
The [http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf Digital Signature Algorithm (DSA)] is used as the Approved authentication technique ([http://csrc.nist.gov/cryptval/dss/dsaval.htm#172 validation certificate# 172]) for the integrity test of the software components. Software that is protected using the digital signatures is the softoken and freebl libraries (e.g., libsoftokn3.so and libfreebl3.so). When the softoken and freebl libraries are built, a DSA public/private key pair is generated, the private key is used to generate a DSA signature of the library, and the public key and signature are stored in a file with the name ''libraryname''.chk. When the self-test is initiated (e.g., at initialization for the FIPS mode), the module verifies the signatures (in the ''libraryname''.chk files) of the softoken and freebl libraries. If the signature verification fails, the self-test fails.
[http://wiki.mozilla.org/FIPS_Operational_Environment#Software_Integrity_Test Software Integrity Test]
 
[http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstokn.c.dep.html#FC_Initialize    FC_Initialize] calls [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11.c.dep.html#nsc_CommonInitialize nsc_CommonInitialize] and then the DSA signature is verified before the library initialization is allowed to proceed.
 


|| Draft
|| Draft
Line 163: Line 152:
||
||
The critical security functions of the cryptographic module are:
The critical security functions of the cryptographic module are:
* Random number generation. Used for the generation of cryptographic keys used by Approved cryptographic algorithms. Tested by the power-up random number generator known-answer test and the conditional [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/freebl/prng_fips1861.c.dep.html#alg_fips186_2_cn_1 continuous random number generator test].
* Random number generation. Used for the generation of cryptographic keys used by Approved cryptographic algorithms. Tested by the random number generator health tests on power up, instantiate and reseed time and the conditional [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/freebl/prng_fips1861.c.dep.html#alg_fips186_2_cn_1 continuous random number generator test].
* Operation of the cryptographic algorithms. Used for encryption, decryption, and authentication. Tested by the power-up [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstest.c.html cryptographic algorithm tests] and the conditional [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11c.c.dep.html#sftk_PairwiseConsistencyCheck pairwise consistency test] (when the module generates public and private keys).
* Operation of the cryptographic algorithms. Used for encryption, decryption, and authentication. Tested by the power-up [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/fipstest.c.html cryptographic algorithm tests] and the conditional [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11c.c.dep.html#sftk_PairwiseConsistencyCheck pairwise consistency test] (when the module generates public and private keys).
|| Draft
|| Draft
Line 173: Line 162:
||  
||  
RSA encryption (Key Wrapping using RSA keys) is the only key transport
RSA encryption (Key Wrapping using RSA keys) is the only key transport
method that VE.09.31.01 applies to. The pairwise consistency check, as defined in AS09.31, is implemented in the [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11c.c.dep.html#sftk_PairwiseConsistencyCheck sftk_PairwiseConsistencyCheck] function. See the source code under the comment "Pairwise Consistency Check of Encrypt/Decrypt."
method that VE.09.31.01 applies to. The pairwise consistency check, as defined in AS09.31, is implemented in the <code>[http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11c.c.dep.html#sftk_PairwiseConsistencyCheck sftk_PairwiseConsistencyCheck]</code> function. (See the source code under the comment "Pairwise Consistency Check of Encrypt/Decrypt.") If the <code>sftk_PairwiseConsistencyCheck</code> call fails, <code>FC_GenerateKeyPair</code> sets <code>sftk_fatalError</code> to true (to enter the Error state) and returns the error code <code>CKR_GENERAL_ERROR</code>.
|| Draft
|| Draft
|-
|-
Line 181: Line 170:
[http://wiki.mozilla.org/VE_09#VE.09.33.01 VE.09.33.01 ]  
[http://wiki.mozilla.org/VE_09#VE.09.33.01 VE.09.33.01 ]  
||
||
The [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11c.c.dep.html#sftk_PairwiseConsistencyCheck sftk_PairwiseConsistencyCheck] function of the module tests the pairwise consistency of the public and private keys used for digital signatures by the calculation and verification of a signature. If the signature cannot be verified, the test fails. See the source code under the comment "Pairwise Consistency Check of Sign/Verify."
The <code>[http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/softoken/pkcs11c.c.dep.html#sftk_PairwiseConsistencyCheck sftk_PairwiseConsistencyCheck]</code> function of the module tests the pairwise consistency of the public and private keys used for digital signatures by the calculation and verification of a signature. If the signature cannot be verified, the test fails. (See the source code under the comment "Pairwise Consistency Check of Sign/Verify.") If the <code>sftk_PairwiseConsistencyCheck</code> call fails, <code>FC_GenerateKeyPair</code> sets <code>sftk_fatalError</code> to true (to enter the Error state) and returns the error code <code>CKR_GENERAL_ERROR</code>.
|| Draft
|| Draft
|-
|-
Line 208: Line 197:
[http://wiki.mozilla.org/VE_09#VE.09.43.01 VE.09.43.01 ]  
[http://wiki.mozilla.org/VE_09#VE.09.43.01 VE.09.43.01 ]  
||  
||  
The module performs the continuous random number generator test on the Approved RNG. In the [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/freebl/prng_fips1861.c.dep.html#alg_fips186_2_cn_1 alg_fips186_2_cn_1] function, if the 320-bit block <code>x_j</code> matches
There is only one random number generator (RNG) used in the NSS cryptographic module. The RNG is an Approved RNG, implementing Algorithm Hash_DRBG of [http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf NIST SP 800-90].
the previous 320-bit block <code>rng->Xj</code> (the odds are 2^320), then
the status code <code>SECFailure</code> is returned. This will
propogate up to calling functions to put the cryptographic
module in the Error state. The first block is not used (see the [http://www.mozilla.org/projects/security/pki/nss/fips/nss-source/mozilla/security/nss/lib/freebl/prng_fips1861.c.dep.html#prng_RandomUpdate prng_RandomUpdate] function) but is saved for comparison with the next block.
|| Draft
|| Draft
|-
|-

Latest revision as of 12:03, 11 May 2015

Note: This is a draft - A work in progress! - Not official.


Document Description

DTR Section

Assessment

Status

List every error state & error indicator - Document all error states associated with each self-test, and indicate for each error state the expected error indicator.

VE.09.04.01

Failure of any of the power-up, conditional, or operator-initiated self-tests causes the cryptographic module to enter the Error state (State 3 ). If the pairwise consistency test fails, the FC_GenerateKeyPair function returns the error code CKR_GENERAL_ERROR. If any other self-test fails, the PKCS #11 function returns the error code CKR_DEVICE_ERROR. When the cryptographic module is in the Error state, most PKCS #11 functions (including all the functions that perform cryptographic operations) do nothing and return the error code CKR_DEVICE_ERROR. See also the Show Status service of the cryptographic module.

CKR_DEVICE_ERROR Cryptographic module is in the Error state, or has entered the Error state because a self-test (other than the pairwise consistency test) fails.
CKR_GENERAL_ERROR Cryptographic module has entered the Error state because the pairwise consistency test fails.
Draft

Module in Error State: Ensure that cryptographic operations cannot be performed and all data output via the data output interface is inhibited while the module is in the error state. See VE02.06.01 for the vendor design requirement.

VE.09.05.01 VE.09.06.01

All the PKCS #11 functions that perform cryptographic operations or output data check the Boolean state variable sftk_fatalError on entry. In the Error state (sftk_fatalError is true), no action besides returning the error code CKR_DEVICE_ERROR is taken by those functions, which prevents cryptograhic operations and data output. (See also In Error State.)

Draft

List and describe the power-up & conditional self-tests performed by the module

VE.09.07.01 VE.09.13.01 VE.09.16.01 VE.09.18.01 VE.09.18.02 VE.09.19.01 VE.09.19.02 VE.09.20.01

  • Conditional tests
    • Pair-wise consistency test (for public and private keys): the module performs the pair-wise consistency test specified in FIPS 140-2 Section 4.9.2 when it generates RSA, DSA, and ECDSA key pairs.
    • Continuous random number generator test: the module performs the continuous random number generator test specified in FIPS 140-2 Section 4.9.2 that tests for failure to a constant value.
    • In addtion to power up, NSS also performs health checks on the random number generate at instantiate and reseed time.
    • No other conditional tests are performed.

These tests are mandatory for the FIPS 140-2 mode of operation.

Draft

For each error condition, document the actions neccessary to clear the condition and resume normal operation.

VE.09.07.02

The cryptographic module has only one Error state, which is entered when any self-test fails. The error code CKR_DEVICE_ERROR returned by cryptographic functions indicates that the module is in the Error state. For the fatal error condition CKR_DEVICE_ERROR, the only way to clear the condition is to shut down and restart the module. Upon restart the power-up tests will be initiated automatically and do not require operator intervention.

Draft

Describe automatic initiation of power-up self-tests requires that the running of power-up self-tests not involve any inputs from or actions by the operator.

VE.09.09.01

When the FC_Initialize function is called, which initializes the PKCS #11 library of the NSS cryptographic module for the FIPS Approved mode of operation, the power-up self-tests are initiated automatically and don't require operator intervention.

Draft

Results of power-up self-tests successful completion indicator for the power-up self-tests.

VE.09.10.01

The FC_Initialize function returns the code CKR_OK upon successful completion of the power-up self-tests.

Draft

Procedure by which an operator can initiate the power-up self-tests on demand

VE.09.12.01

The operator can initiate the power-up self-tests on demand by calling the FC_Finalize and FC_Initialize functions to shut down and restart the module.

Draft

specify the method used to compare the calculated output with the known answer.

VE.09.17.01

PORT_Memcmp, a synonym for memcmp, is used to compare the calculated output with the known answer byte by byte. sftk_fipsPowerUpSelfTest

Draft

Error State when two outputs are not equal.

VE.09.17.02

When the two outputs are not equal, the module enters the Error state (by setting the Boolean state variable sftk_fatalError to true) and returns the error code CKR_DEVICE_ERROR.

Draft
Independant cryptographic algorithm implemenations VE.09.20.02

(N/A) The NSS cryptographic module doesn't include two independent implementations of the same cryptographic algorithm.

Draft

Integrity test for software components

VE.09.22.01 VE.09.22.02 VE.09.22.03

Software Integrity Test

Draft
EDC for software integrity VE.09.24.01 (N/A)
Critical functions test

VE.09.27.01

The critical security functions of the cryptographic module are:

  • Random number generation. Used for the generation of cryptographic keys used by Approved cryptographic algorithms. Tested by the random number generator health tests on power up, instantiate and reseed time and the conditional continuous random number generator test.
  • Operation of the cryptographic algorithms. Used for encryption, decryption, and authentication. Tested by the power-up cryptographic algorithm tests and the conditional pairwise consistency test (when the module generates public and private keys).
Draft

Key transport method

VE.09.31.01

RSA encryption (Key Wrapping using RSA keys) is the only key transport method that VE.09.31.01 applies to. The pairwise consistency check, as defined in AS09.31, is implemented in the sftk_PairwiseConsistencyCheck function. (See the source code under the comment "Pairwise Consistency Check of Encrypt/Decrypt.") If the sftk_PairwiseConsistencyCheck call fails, FC_GenerateKeyPair sets sftk_fatalError to true (to enter the Error state) and returns the error code CKR_GENERAL_ERROR.

Draft

Digital signatures

VE.09.33.01

The sftk_PairwiseConsistencyCheck function of the module tests the pairwise consistency of the public and private keys used for digital signatures by the calculation and verification of a signature. If the signature cannot be verified, the test fails. (See the source code under the comment "Pairwise Consistency Check of Sign/Verify.") If the sftk_PairwiseConsistencyCheck call fails, FC_GenerateKeyPair sets sftk_fatalError to true (to enter the Error state) and returns the error code CKR_GENERAL_ERROR.

Draft

Approved authentication technique used for the software/firmware load test

VE.09.35.01 VE.09.35.02

N/A. No software or firmware components can be externally loaded into the cryptographic module.

Draft

Manual Key Entry Test

VE.09.40.01 VE.09.40.02

(N/A) The cryptographic module does not support manual key entry.

Random number generator is implemented, document the continuous RNG test performed

VE.09.42.01 VE.09.43.01

There is only one random number generator (RNG) used in the NSS cryptographic module. The RNG is an Approved RNG, implementing Algorithm Hash_DRBG of NIST SP 800-90.

Draft
Bypass Test

VE.09.45.01 VE.09.45.02 VE.09.46.01 VE.09.46.02

(N/A) NSS does not implement a bypass service. Draft

Return to: NSSCryptoModuleSpec