293908 - Allow PK11SecureRandom.setSeed for a specific token

Status: RESOLVED WONTFIX

(JSS Graveyard :: Library, defect)

Description

[Steve Parkinson]

I would like to add additional entropy to a particular token for RNG purposes.

The current PK11SecureRandom.setSeed() call always uses the 'Best Slot'.
I need to ENSURE a specific token is used.

There are a couple of ways to do this:

1) implement PK11Token.getRandomGenerator() - currently throws
NotImplementedException. This is probably the right way to go
longer term.

OR
2) have PK11SecureRandom() constructor take a token. Then, 
when PK11SecureRandom.setSeed() is called, it will use
this token.


I have implemented and will attach a patch for 2).  However, PK11SecureRandom
also provides another method, nextBytes() which retrieves random bytes.
In the patch I provided, it does not retrieve them from the token specified in
the PK11SecureRandom constructor, so the bytes may not come from the right
token. Indeed, there is no NSS API to specify what token the random bytes come
from, only:
PK11_GenerateRandom(unsigned char *data,int len);

This is fine for my application, because I am not expecting to actually use the
nextBytes API - (I'm generating keys and I can specify a token for this).

I have sprinkled plenty of warnings in the javadoc about this.

Comment 1

[Steve Parkinson]

Attachment: Patch for option #2

Comment 2

[Wan-Teh Chang]

Comment on attachment 183409 [details] [diff] [review]
Patch for option #2

Option 1 does seem better, but it is a lot more work and
achieves the same thing your patch does.

Your patch is a reasonable extension to the PK11SecureRandom
class.	However, because of the limitation of PK11_GenerateRandom,
the class will be asymmetric in the slot used by the setSeed
and nextBytes methods, so it is best that we check in this
patch in conjunction with a new NSS function that calls
C_GenerateRandom on a particular slot.

If it is okay for PK11SecureRandom.nextBytes to use your token,
you can do what you want by marking your token the "best slot"
for the CKM_FAKE_RANDOM PKCS #11 mechanism.

Comment 3

[Wan-Teh Chang]

To mark a token as the "best slot" for random number
generation, see the "-mechanisms mechanism-list" option
in the modutil documentation:
http://www.mozilla.org/projects/security/pki/nss/tools/modutil.html

Comment 4

[Wan-Teh Chang]

Comment on attachment 183409 [details] [diff] [review]
Patch for option #2

When I reviewed this patch again, I found an error in it.

>Index: security/jss/org/mozilla/jss/pkcs11/PK11SecureRandom.c
...
>@@ -128,12 +133,24 @@ Java_org_mozilla_jss_pkcs11_PK11SecureRa
...
>     /*
>      * Obtain the appropriate "slot"
>      */
>+	if (jtoken == NULL) {
>+    	slot = PK11_GetBestSlot( CKM_FAKE_RANDOM, NULL );
>+	} else {
>+    	JSS_PK11_getTokenSlotPtr(env, this, &slot);
>+	}

We should pass jtoken instead of this as the second argument
to JSS_PK11_getTokenSlotPtr.

Comment 5

[Wan-Teh Chang]

Attachment: Patch for option #2, v1.1

This is Steve's patch after my editing.  I
removed the unused PK11SECURERANDOM_CLASS_NAME
macro, renamed a few identifiers, and edited
some comments.	The most important change is to fix
the second argument to the JSS_PK11_getTokenSlotPtr
call and to check the call's return value.

I'm wondering if we could make nextBytes() throw
an exception if a token was supplied in the constructor.
Since the nextBytes() prorotype doesn't throw any
exception, I think this would be an interface change.

I'm unhappy that the setBytes native method needs to
look up the token object field *every time*.  It seems
that other JSS classes avoid this by passing the token
jobject as an argument to these methods from Java to
JNI.  I will attach such a patch next.

Comment 6

[Wan-Teh Chang]

Attachment: Alternate patch for option #2 (untested)

In this patch I pass the token field from Java to JNI so
that we don't need to look it up in JNI.

Glen, Steve, does this patch break "binary compatibility"
of JSS?

Glen, does a null object reference in Java become a NULL
jobject value in JNI?

Steve, if you could test this patch, I'd appreciate it.

Comment 7

[BMO Automation]

JSS development has moved from the Mozilla community to the Dogtag PKI community. Please re-file this bug at https://github.com/dogtagpki/jss if it is still relevant. Thank you!