PKCS #11 provider shutdown process, key zeroization

[Matthew Hall]

Hello,

I am working on a product which uses the Sun PKCS #11 provider. I was curious 
how the FIPS mode worked, in particular about the shutdown procedure and 
whether or not it performed key and password zeroization, so I was reading 
through the OpenJDK 7 trunk version of the implementation code to learn more.

In share/classes/sun/security/pkcs11/wrapper/PKCS11.java we have some 
methods:

private static native void finalizeLibrary();

I could not find any code which ever called this method. In 
share/native/sun/security/pkcs11/wrapper/p11_general.c, all the implementation 
code for this native method is commented out, with an XXX marker but no 
explanation why it's commented out.

public native void C_Finalize(Object pReserved) throws PKCS11Exception;

I could not find any code which ever called this either, but at least the 
implementation code is not commented out, and looks like it would probably 
work if it was called. I believe that this method often implements zeroization 
so it seems like it could be an issue if nothing is ever calling this.

/**
 * Calls disconnect() to cleanup the native part of the wrapper. Once this
 * method is called, this object cannot be used any longer. Any subsequent
 * call to a C_* method will result in a runtime exception.
 *
 * @exception Throwable If finalization fails.
 */
public void finalize() throws Throwable {
    disconnect();
}

Next we have the finalizer, which calls the disconnect method. Note that it is 
documented as throwing an exception, but any exceptions during finalization 
would be ignored and not reported anywhere, which would mean we would not have 
a way of knowing that unloading is failing and nothing is getting zeroized 
properly. (This is according to Object#finalize documentation).

Is there a way to obtain a reference to the PKCS11 wrapper and call this 
function explicitly? I could not find a good way to do it. Since finalize 
might never get called if the object never gets unreferences, I can't see how 
we could be sure the keys are zeroized right, even if some of the items inside 
of disconnect perform the zeroization, which I'm not sure that they do.

/**
 * Disconnects the PKCS#11 library from this object. After calling this
 * method, this object is no longer connected to a native PKCS#11 module
 * and any subsequent calls to C_ methods will fail. This method is for
 * internal use only.
 * Declared private, because incorrect handling may result in errors in the
 * native part.
 *
 * @preconditions
 * @postconditions
 */
private native void disconnect();

Let's take a look at the implementation of disconnect from 
solaris/native/sun/security/pkcs11/wrapper/p11_md.c:

/*
 * Class:     sun_security_pkcs11_wrapper_PKCS11
 * Method:    disconnect
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_sun_security_pkcs11_wrapper_PKCS11_disconnect
    (JNIEnv *env, jobject obj)
{
    ModuleData *moduleData;
    TRACE0("DEBUG: disconnecting module...");
    moduleData = removeModuleEntry(env, obj);

    if (moduleData != NULL) {
        dlclose(moduleData->hModule);
    }

    free(moduleData);
    TRACE0("FINISHED\n");

}

If you read through removeModuleEntry, the only interesting operation 
performed there is:

(*env)->SetLongField(env, pkcs11Implementation, pNativeDataID, 0);

This is setting the pNativeDataID field from the PKCS #11 class to zero.

Then, the higher code in disconnect will dlclose the library. However dlclose 
is only reference-counting, and does not guarantee the library will be removed 
from memory, or that the removed memory will be zeroized.

In addition if the keys are stored in a dynamic area and not a static area 
inside the library, which is what I suspect, they could still be present in 
memory after this point, which seems to be against what's required for 
zeroization in FIPS.

Therefore I am asking now, if we are sure that the way all of this works will 
perform the key zeroization we expect. Can anybody comment on whether this 
could be an actual issue or not?

In addition, I noticed there are a number of pieces of code that are zeroizing 
keys using \x20 instead of \x00:

share/classes/com/sun/crypto/provider/PBEKey.java:70:        java.util.Arrays.fill(passwd, ' ');
share/classes/com/sun/crypto/provider/PBEKeyFactory.java:151:                java.util.Arrays.fill(passwdChars, ' ');
share/classes/com/sun/jmx/remote/security/FileLoginModule.java:561:            Arrays.fill(password, ' ');
share/classes/com/sun/security/auth/module/LdapLoginModule.java:1000:            Arrays.fill(password, ' ');
share/classes/java/io/Console.java:84: *     java.util.Arrays.fill(passwd, ' ');
share/classes/java/io/Console.java:388:                Arrays.fill(rcb, 0, len, ' ');
share/classes/java/security/KeyStore.java:297:                Arrays.fill(password, ' ');
share/classes/sun/net/www/protocol/http/spnego/NegotiateCallbackHandler.java:91:                if (password != null) Arrays.fill(password, ' ');
share/classes/sun/security/pkcs11/P11KeyStore.java:253:                Arrays.fill(password, ' ');
share/classes/sun/security/pkcs11/SunPKCS11.java:1191:                Arrays.fill(pin, ' ');
share/classes/sun/security/util/Password.java:104:                        Arrays.fill(lineBuffer, ' ');
share/classes/sun/security/util/Password.java:118:            Arrays.fill(buf, ' ');
share/classes/sun/security/util/Password.java:123:                Arrays.fill(consoleEntered, ' ');
share/classes/sun/security/util/PolicyUtil.java:174:                Arrays.fill(keyStorePassword, ' ');

Officially I don't think this is allowed either, but it's a more minor issue 
than the other item I'm asking about.

Regards,
Matthew.