342582 - Test program of the softoken as a stand-alone PKCS #11 library

Status: RESOLVED FIXED

(NSS :: Test, enhancement, P2)

Description

[Wan-Teh Chang]

We are considering writing a test program of the softoken
as a stand-alone PKCS #11 library for FIPS 140-2 validation.

Comment 1

[Wan-Teh Chang]

Attachment: Work in progress

This test program doesn't use NSPR or NSS to
simlate a third-party application that uses
the softoken as a stand-alone PKCS #11 library.

It now does the following:
initialize the cert and key databases,
set a password,
generate a few random bytes,
log in,
log out,
generate an AES key,
use it to encrypt another plaintext AES key and import that
key into the FIPS module, and
use the imported AES key to encrypt a FIPS AES test case.

It passed the test.

Comment 2

[Wan-Teh Chang]

Attachment: Work in progress v2

Added DSA domain parameter (PQG) generation, key
pair generation, signature generation and verification.

Added SHA-1 message digest.

Comment 3

[Wan-Teh Chang]

Attachment: login.c: test program for concurrent login attempts within one minute

This test program shows that concurrent login attempts
from multiple threads are serialized and each have a
one second delay after login failure.  So an application
can make at most 60 login attempts within one minute.

Comment 4

[glen beasley]

Attachment: Work in Progress V3

* pk11mode.c - Test FIPS or NONFIPS Modes for the NSS PKCS11 api.
 *              The goal of this program is to test every function
 *              entry point of the PKCS11 api at least once.
 *              To test in FIPS mode: pk11mode
 *              To test in NONFIPS mode: pk11mode nonFIPS
 *
 * Currently this program is Windows only.
 *
 * NSS PKCS11 API entry points still todo:
 * FC_DigestEncryptUpdate
 * FC_DecryptDigestUpdate
 * FC_SignEncryptUpdate
 * FC_DecryptVerifyUpdate
 * FC_DeriveKey
 * Notify

Comment 5

[glen beasley]

Attachment: work in progress v4

Comment 6

[glen beasley]

Attachment: work in progess v5

Comment 7

[glen beasley]

Attachment: patch to create Broken Builds (never to be checked in)

Comment 8

[Wan-Teh Chang]

Attachment: patch to create Broken Builds v2 (never to be checked in)

We need to include the NSPR headers "prenv.h" and "prprf.h",
otherwise there are compiler warnings.

Comment 9

[Julien Pierre]

I experimented with the earlier version of the program that didn't use NSPR, but used native Windows code instead. I did this experiment with the OS_TARGET=WINNT configuration .

I made a single modification to the test program :
I added a Sleep(10000) statement right after the call to FreeLibrary() right before the end of main() to sleep for 10 seconds at the end of the program.

Then, I tried to load the NSS 3.10 softoken . Many tests failed, starting with login. So, I #ifdef'ed them out, but I kept the LoadLibrary / C_Initialize / C_Finalize / FreeLibrary and the sleep statement .

The pk11mode program crashed, trying to execute code in one of the threads that had been started by NSPR, because NSPR had been unloaded as a result of the FreeLibrary call on softoken . That is because NSPR got unloaded from memory by the OS at the time that softoken got unloaded from the program by pk11mode .

With the NSS 3.11 softoken, this crashing problem doesn't currently exist, because softoken leaks freebl3.so in memory, which causes libnspr4.so to also be leaked. Fixing this leak causes the above-mentioned crash to reappear.

If the pk11mode test program used NSPR, NSPR would stay resident in memory, hiding this crash. Currently, pk11mode uses native code on Windows, and NSPR on other platforms. I think it is worth having pk11mode not use NSPR so we can test that the softoken works properly in non-NSPR programs. It may be worth doing that on platforms other than just windows, since we know for example that the Solaris JDK doesn't use NSPR and loads / unloads softoken .

Comment 10

[Julien Pierre]

Note that the crash I reported in comment 9 did not occur when I tested the OS_TARGET=WIN95 version of the NSS 3.10 softoken .

Comment 11

[Wan-Teh Chang]

Originally I wanted the test program to be completely
independent of NSPR and NSS for exactly this reason.
I wanted to be sure that a third-party application can
use the softoken.  The test program used native OS functions
and the official PKCS #11 header files.  I made it work
on Windows.  But we didn't have time to port the code to
other platforms, so we use NSPR on the other platforms.
Then, we decided to use NSS's PKCS #11 header files.
(The official PKCS #11 headers need platform-dependent
macro definitions.  RSA Security only provides the
macro definitions for Windows.  So even the PKCS #11
headers need to be ported to non-Windows platforms.)

Comment 12

[glen beasley]

Attachment: patch to create Broken Builds v3 (never to be checked in)

Comment 13

[Wan-Teh Chang]

Attachment: patch to create Broken Builds v4 (never to be checked in)

Added environment variables to make the conditional self-tests
(pair-wise consistency test and continuous RNG test) fail.