13

Sun's PKCS11 JCE security provider is lacking some functionality we need.
So I wrote an enhanced version of it using the original sources.

Unfortunately the JCE infrastructure rejects the new provider
"JCE cannot authenticate the provider"
because it is not properly signed.

javax.crypto.JceSecurity.verifyProviderJar(...) throws.
(it calls javax.crypto.JarVerifier.verify())

Any suggestions how to sign the new provider to make it work with JCE?

Artjom B.
  • 61,146
  • 24
  • 125
  • 222
3dGrabber
  • 4,710
  • 1
  • 34
  • 42
  • 4
    FYI: we requested a certificate from Sun and got it in 3 working days, no hassles. The certificate can be used to sign as many versions we need. As this procedure may depend on your location, it might be worth to mention that we operate from Switzerland, Europe. – 3dGrabber Nov 29 '09 at 20:24

5 Answers5

10

The process is described in the document, "How to Implement a Provider."

It involves emailing Sun Oracle some information (including the CSR you generated for your signing key), then faxing a confirmation document. Getting your signed certificate back can take a week or more, so plan ahead.

You only need to sign your provider if it provides services that are restricted by some (repressive) governments. For example, a Cipher implementation is a restricted "service," while MessageDigest is an unrestricted service. I assume with the message you're getting, that you are trying to provide a restricted services.

If you provide any of these services, there's no way around it: You need a code-signing certificate issued by Sun. (One from IBM might work too; if I recall correctly, their code-signing CA is supported, but I don't know anything about their issuing process.)

erickson
  • 265,237
  • 58
  • 395
  • 493
5

An alternative is to design your custom provider using OpenJDK. This is the open-source project sponsored by Sun/Oracle, and provides the code base for their official release. OpenJDK does not require providers to be signed. OpenJDK is available (by default, now) on several Linux distributions. Unfortunately, it does not seem to be readily available on Windows or Macintosh. If you're running Windows or Macintosh, I recommend installing Linux into a VM.

If you must develop on Windows or Mac, however, you can copy the jce.jar file from an OpenJDK install over jce.jar (in your Java lib directory) of an official install. This will effectively circumvent the Jar authentication process. Be sure to put the original jce.jar file back when you're done developing, though.

Dan G
  • 59
  • 1
  • 1
2

You have to sign the JAR with "JCE Code Signing CA". In all current Java distributions, only 2 CAs (Sun and IBM) are built-in (hard-coded) and there is no way to add your own. We tried to work with Sun to sign our provider and it's almost impossible. They wouldn't issue intermediate CA cert, which means you have to go through the trouble every time you make a change.

Why don't you just user your own library? You use standard API for interoperability between different JCEs. But that's not realistic for CryptoKi/SmartCard stuff right now, you almost always need to write some custom code to interact with vendor specific API. You can even make your code mimic JCE API to minimize code changes.

ZZ Coder
  • 74,484
  • 29
  • 137
  • 169
  • 1
    I've gotten two certificates from Sun, with no trouble at all. They were very helpful and responsive. – erickson Nov 18 '09 at 17:33
  • 1
    Do you mean you get "JCE Code Signing Certificate" from Sun? They use a special CA root for JCE "JCE Code Signing CA". So regular code signing cert doesn't work. – ZZ Coder Nov 18 '09 at 18:21
  • Yes, I mean the cert that you need to sign a JCE provider. – erickson Nov 19 '09 at 00:41
  • Oh, I guess our definition of trouble is different :) Getting regular code signing cert is quite easy. That's no trouble. However, Sun required us to get export license to use strong cryptography from Dept. of Commerce to issue a JCE signing cert. That's way too much trouble for us. – ZZ Coder Nov 19 '09 at 01:12
  • 1
    That's weird. We didn't have to do that either time (we are in the US). The signature is required to prevent *import* of a provider into repressive countries, not to control export from the US. – erickson Nov 19 '09 at 08:01
  • @ZZCoder, Sun's hands are tied due to govt restrictions. It is not like they are just giving you a hard time. – CaTalyst.X Apr 11 '15 at 02:35
2

Only for extra info, i got this same exception when i build a JAR (Eclipse Juno) with the option "Extract required libraries into generated JAR" instead the correct "Package required libraries into generated JAR"

0

Well, after reading about the handshake with some Oracle authority, my solution is writing an independent Cipher class with own signature verification, which in case of other providers than "me" delegates to javax.crypto.Cipher.

This seems to be obligatory as there is nearly no algorithm available over all Java releases, also the limits of some algorithms' strength is not satisfying and essentially, Oracle does not need to know about my encryption algorithms.

Sam Ginrich
  • 661
  • 6
  • 7