TL;DR Yes, you can add digital signatures in Java even when you use newer hardware tokens such as Gemalto SafeNet eToken 5110 CC. JSignPKCS11 might help.
Maybe you've seen the infamous PKCS11 error message CKR_USER_NOT_LOGGED_IN already. Thrown even when the SunPKCS11 security provider and the keystore settings were properly configured for your hardware token.
java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:685) at java.base/java.security.Signature$Delegate.engineSign(Signature.java:1404) at java.base/java.security.Signature.sign(Signature.java:713) ... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_Sign(Native Method) at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:664) ... 6 more
I fought this issue in my JSignPDF application as several users had hit it. After some debugging over the failing SunPKCS11 implementation and over the passing pkcs11-tools one, I realized the Java implementation only covers the old version of PKCS #11. There is no support for the new login type "CKU_CONTEXT_SPECIFIC" in SunPKCS11. So I forked the OpenJDK SunPKCS11 into the intoolswetrust GitHub organization (where I keep my popular projects) and added a logic to call this login type before signing.
Sounds interesting? Do you want to try it too? Just add the Maven dependency:
<dependency> <groupId>com.github.kwart.jsign</groupId> <artifactId>jsign-pkcs11</artifactId> <version>${jsign.pkcs11.version}</version> </dependency>
and instead of class registering security provider with class "sun.security.pkcs11.SunPKCS11" use the class "com.github.kwart.jsign.pkcs11.JSignPKCS11".
NSS is not supported
If you use the SunPKCS11 for accessing NSS keystores, then don't use the JSignPKCS11 as there is no support for NSS modes.
Komentáře