[security-dev 01547]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 (original) (raw)

Andrew John Hughes ahughes at redhat.com
Sun Jun 27 16:17:03 PDT 2010

On 27 June 2010 23:45, Michael StJohns <mstjohns at comcast.net> wrote:

PS - I know this is the openjdk list - but I thought this one was getting back ported.

Mike

At 05:37 PM 6/27/2010, Michael StJohns wrote: Hi guys -

I see from the Mercurial logs that this went in to both the jdk6 and jdk7 repositories.  For jdk6 - it's rev 302 which looks like this should have ended up in the 19 release But all the files in lib/ext/sunpkcs11.jar  for 20 are all tagged as 1 September 2009.... Is the sunpkcs11.jar provider not getting regenerated and rebundled during the release process? Mike

At 01:28 PM 1/21/2010, Michael StJohns wrote: At 05:12 AM 1/21/2010, Vincent Ryan wrote: I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today.

On 21/01/2010 07:44, Tomas Gustavsson wrote: Now it has one more vote. /Tomas Andrew John Hughes wrote: 2010/1/20 Tomas Gustavsson <tomas at primekey.se>: I'll second this request. This is a critical patch and many production installations have to live with this manually patched now.

I know of no pkcs11 implementation that works with the current code.

It has four votes: http://bugs.sun.com/bugdatabase/viewbug.do?bugid=6763530 I don't know how many they need to wake up and review the patch. The new release of IcedTea6 1.7 is imminent and will include the fix so it should at least be resolved on the next version shipping with most GNU/Linux distributions. Regards, Tomas Gustavsson PrimeKey Solutions AB

On Wed, 20 Jan 2010, Michael StJohns wrote: Hi - this seems to have stalled out again.  Any chance of revival? Mike

At 12:33 PM 9/24/2009, Vincent Ryan wrote: Hello Andrew, I'll need a little more time to come up to speed on this fix. I'm concerned that there may be interoperability or backwards compatibility issues.

Andrew John Hughes wrote: 2009/9/2 Andrew John Hughes <gnuandrew at member.fsf.org>: 2009/9/2 Michael StJohns <mstjohns at comcast.net>: At 09:38 PM 9/1/2009, Andrew John Hughes wrote: 2009/9/2 Michael StJohns <mstjohns at comcast.net>:  This appears to be related specifically to PKCS11. š  Specifically, PKCS11 v2.20 has some ambiguity of the representation of an EC point (which is different in the text than an ASN1 ECPoint). This is being clarified in v2.30 with the unencoded point format (e.g.the format described in  X9.62, where the first octet indicates the encoding and there are either N or 2N octets following)  being the expected value, but with PKCS11 providers allowed - legacy - to accept either. One of the reasons for going that way was how the JDK PKCS11 provider had interpreted the issue and implemented its code. I don't support this fix - among other things, this fix only deals with 1/2 of the problem.  The other half is related to encoding the value.  Also, changing the code at decodePoint seems further into the stack than needed and may affect other uses of that method. That's really too vague to be of much help in improving the patch. You seem to be saying little more than 'I don't like it'. Sorry about that.  My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly.

There's an existing JDK bug on this coming at it from a different direction - 6763530 ... and there may be considerations at https://bugzilla.mozilla.org/showbug.cgi?id=480280 It seems likely that's the NSS change that causes the current failure. The fix I submitted here is based on the way this is handle in NSS. In fact, the code is similar enough to suggest that one was developed from the other.  that should be looked at. The JDK bug is not really 'from a different direction', it's reporting exactly the same error but from a less trivial example (I get the same failure while trying to create an example key, while this seems to require specific hardware if I'm reading it correctly). Not exactly.  You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. Also see 6779460 which is mostly a duplicate of 6763530. The patch on 6779460 seems wrong.  It means that the method will return a DER-encoded value where it would either have returned an uncompressed value before or failed. My point exactly as I mentioned in the comments.  :-) It's probable that the fix I suggested at 6763530  (in comments submitted 29 Nov 08) may be a better approach given the NSS fixes.  I believe it will fix the keytool problem noted in the original message. Ok, I can see the logic in the fix and it would appear to work, though I haven't tested it. Given the patch was written nine months ago, why has it not been applied?  If it had, it would have saved me hours having to debug this same issue again. Yup.  I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. Do you have an SCA with Sun? If so, I'll create a webrev based on your patch and we can finally get this fixed.  Without it, NSS support is completely broken in OpenJDK6 which makes me wonder why this is a low priority bug! I do have an SCA on file.  Note that the recommendation from the NSS guys was to raise the priority. The reason I haven't submitted this is because I submitted a different EC fix  https://bugs.openjdk.java.net/showbug.cgi?id=100048 per the documented process  and was waiting on progress there before continuing.  I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding.  And then I got busy with some other things... Mike

Mike

At 04:39 PM 9/1/2009, Joe Darcy wrote: Andrew John Hughes wrote: 2009/8/28 Andrew John Hughes <gnuandrew at member.fsf.org>: In OpenJDK6, the elliptic curve cryptography algorithms are available if the PKCS11 provider is configured to point to NSS. See: http://blogs.sun.com/andreas/entry/thejavapkcs11provider If NSS is configured as specified in this blog, keytool can be used to generate a key as follows: Hello. Allowing keytool and friends to work in more cases if the provider is capable seems fine to me. Security team, do you have concerns about this patch? Thanks, -Joe -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8 Ok here is a new webrev: http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ with a slightly revised version of your change (you can't throw a PKCS11Exception which only takes a long ID from the native code, so I changed this to an IllegalArgumentException). Security team, does this look ok to push? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8 Ping! Security developers, any thoughts on this patch: http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ Does it look ok to push? Thanks,

It has been:

$ hg log -R jdk -k 6763530 changeset: 302:82b80660cac3 user: vinnie date: Thu Jan 21 23:59:41 2010 +0000 summary: 6763530: Cannot decode PublicKey (Proider SunPKCS11, curve prime256v1)

and certainly is present on IcedTea6's builds.

Andrew :-)

Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com)

Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

More information about the jdk6-dev mailing list