Access restriction on sun.security.pkcs11.SunPKCS11

I'm trying to setup a PKCS11 provider for accessing a smartcard. I installed a PKCS11 library on my sys开发者_Python百科tem and followed the instructions in the Java PKCS#11 Reference Guide. In the reference they simply create an instance of sun.security.pkcs11.SunPKCS11 and pass the name of the configuration file to the constructor. When I try to compile the following code

Provider p = new sun.security.pkcs11.SunPKCS11("pkcs11.cfg");
Security.addProvider(p);

I get the following error.

Access restriction: The constructor SunPKCS11(String) is not accessible due to restriction on required library /usr/lib/jvm/java-6-sun-1.6.0.24/jre/lib/ext/sunpkcs11.jar

What am I doing wrong? I use Eclipse 3.5 with Java SE 1.6 under Ubuntu x86.

Best regards.

Look into the projects's properties and open the Libraries tab. I assume you have set the JRE System Library to an execution environment. Change it to the workspace JRE or select a specific JRE manually.

Background: By selecting an execution environment you say that you want to write an app that is compliant to the Java API. The class sun.security.pkcs11.SunPKCS11 is located in the sun package which marks it as proprietary to Sun Java implementation and is not part of the standard Java API.

Go to your project properties, Java Build Path pane, and expand the JRE System Library entry. Click Access rules and click the Edit... button. Add an Access Rule that makes Accessible the Rule Pattern sun/security/pkcs11/**. This will make Eclipse stop whining.

There is one other cause if you use a 64 bit runtime on Windows. In that case, the necessary classes are simply not present.

Solution: Use a 32 bit runtime.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880559

As far as I have come to understand, there are two ways of using PKCS#11 tokens in Java: using the Sun APIs, and using some proprietary implementation. Each has its advantages and disadvantages. Sun'API main advantage is that it maps PKCS#11 tokens onto regular KeyStores. BouncyCastle can thus access the private keys in the token without actually figuring out that it is interacting with an hardware device. Moreover any native dependency is already bundled with Sun's JVM, and you don't have to worry about porting or supporting native code on different platforms. The main disadvantage is that it is non standard, so you are not guaranteed to find it on any JVM. The commercial APIs (see IAIK's PKCS11 wrapper) are good, and even open sourced, but they have two disadvantages: they are made to work with another API (which you have to pay for...), so they do not expose the token as a KeyStore and you cannot use BouncyCastle transparently, and they have a native component which you have to maintain and distribute. If you have to work with PKCS#11 in a browser, you know what a pain that is...

The reason for that error is certain classes are only suppose to be used by the Sun JVM and with newer versions of Eclipse a warning check was put in to warn the developer of improper/illegal use of classes.

Another stackoverflow thread recommends using the Bouncy Castle implementation. Weird problem using sun.security.pkcs11.SunPKCS11: The specified procedure could not be found?