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 ). When the cryptographic module is in the Error state, most functions (including all the cryptographic functions) 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 or has entered the Error state.	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	Power-up self-test: 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 (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 CKR_DEVICE_ERROR. No action besides setting the return code is taken by the requested function, which prevents data output of the second type.	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	The module can perform the following self-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 power-up self-tests source code). 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. Software integrity test Conditional self-tests Pair-wise consistency test (for public and private keys) Continous random number generator test 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 is used to compare the calculated output with the known answer. 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	The Digital Signature Algorithm (DSA) is used as the Approved authentication technique (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. 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	VE.09.27.01 VE.09.28.01	Random Number Generator Self tests are the Continuous Pseudo-Random Number Self-Tests	Draft
Key transport method	VE.09.31.01 VE.09.32.01	RSA encryption is the only FIPS approved key transport method that VE.09.31.01 applies to. See sftk_PairwiseConsistencyCheck The other key transport/establishment methods either use a symmetric wrapping key (encrypting/wrapping with TDES or AES) or require two public/private key pairs (Diffie-Hellman or its elliptic curve variants).	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.	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	VE.09.40.01 VE.09.40.02	(N/A) NSS does not implement manual Key entry
Random number generator is implemented, document the continuous RNG test performed	VE.09.42.01 VE.09.43.01	Continuous Pseudo-Random Number Self-Tests In this code reference, if the SHA-1 hash matches the previous SHA-1 hash (the odds are 2^160), then the error code SECFailure is returned. This will propogate up to calling functions to put the cryptographic module in critical error state.	Draft
ByPass Service	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