NSSCryptoModuleSpec/Section 9: Self Tests
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
|
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. |
All the PKCS #11 functions that perform cryptographic operations or output data check the Boolean state variable |
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 |
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 |
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 |
Draft | ||||
Results of power-up self-tests successful completion indicator for the power-up self-tests. |
VE.09.10.01 |
The |
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 |
Draft | ||||
specify the method used to compare the calculated output with the known answer. |
|
Draft | |||||
Error State when two outputs are not equal. |
When the two outputs are not equal, the module enters the Error state (by setting the Boolean state variable |
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 |
The Digital Signature Algorithm (DSA) is used as the Approved authentication technique (validation certificate# 172) for the integrity test of the software components. Software components protected using the digital signatures are the softoken (PKCS #11) and freebl libraries (e.g., libsoftokn3.so and libfreebl3.so). (See Security Policy Rule #36 for a list of module files by platform.) When the softoken and freebl libraries are built, a DSA public/private key pair with a 1024-bit prime modulus p 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. FC_Initialize calls nsc_CommonInitialize and then the DSA signature is verified before the library initialization is allowed to proceed.
|
Draft | |||||
EDC for software integrity | VE.09.24.01 | (N/A) | |||||
Critical functions test |
The critical security functions of the cryptographic module are:
|
Draft | |||||
Key transport method |
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 |
Draft | |||||
Digital signatures |
The |
Draft | |||||
Approved authentication technique used for the software/firmware load test |
N/A. No software or firmware components can be externally loaded into the cryptographic module. |
Draft | |||||
Manual Key Entry Test |
(N/A) The cryptographic module does not support manual key entry. | ||||||
Random number generator is implemented, document the continuous RNG test performed |
The module performs the continuous random number generator test on the Approved RNG. In the alg_fips186_2_cn_1 function, if the 320-bit block |
Draft | |||||
Bypass Test | (N/A) NSS does not implement a bypass service. | Draft |
Return to: NSSCryptoModuleSpec