PKCS #11 provider shutdown process, key zeroization

[Matthew Hall]

It's great to hear from you, Milton! Below I have placed everything into one 
report in order of importance. Perhaps someone could take a look at let me 
know what the solution is if there are some, and how we could work together to 
correct anything that could be an issue.

1. Correct procedure for PKCS11 provider shutdown and reload

How do you shutdown the provider, zeroize all keys and passwords, and reopen 
it, without restarting the whole JVM?

Also, assuming you can't shutdown and restart, why is the secure shutdown and 
finalization code comments out and not called, with just XXX and no 
explanation of why it was disabled? It's very important for FIPS that 
everything is shut down properly so things aren't left sitting around in 
memory.

The details for this are rather long to describe, see below signature for more 
detail.

2. Code which logs contents of Private Keys in toString() by default

Quite a number of bits of code are printing out the content of the private
exponent of the RSA Private Keys by default into the toString() output, which
could lead to key compromise if they're printed into a log.

share/classes/sun/security/pkcs11/P11Key.java:552:            sb.append("\n  private exponent: ");
share/classes/sun/security/pkcs11/P11Key.java:624:            sb.append("\n  private exponent: ");
share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java:238:        sb.append("\n  private exponent: ");
share/classes/sun/security/rsa/RSAPrivateKeyImpl.java:105:                + n + "\n  private exponent: " + d;

Ordinarily I believe FIPS and PCI would require that there isn't any code
sitting around that could accidentally or unexpectedly print out the private
key data. Is this toString() behaving that way for a good reason?

3. Key and password zeroization

A number of pieces of code 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.

Thanks,
Matthew.

More detail on (1): Correct procedure for PKCS11 provider shutdown and reload

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?

Regards,
Matthew.