One day before Christmas we have released a new version of our core crypto toolkit IAIK-JCE!
Please also have a look at the toolkits we have released during the last months. Especially we want to point your attention to the new versions of our SSL/TLS library iSaSiLk which supports TLS 1.2 now, and our Elliptic Curve provider Eccelerate TM !
The new version 5.0 of our SSL/TLS library supports TLS 1.2 and implements the TLS_FALLBACK_SCSV
cipher suite value as countermeasure against protocol downgrade attacks on the Transport Layer Security (TLS) protocol trying to enforce a fall back to SSL 3.0, which is vulnerable to a padding-oracle attack if CBC is used ("POODLE" -- Padding Oracle On Downgraded Legacy Encryption attack).
When running some of the samples which try to generate keys, I get an
. What is wrong?
We had similar problems with certain cards; e.g. the Rainbow iKey2032 and DataKey cards. This is due to bugs in drivers. As workaround you can try to set the class and key-type attributes as not present. This may look like this:
maybe the driver accepts the key template if you try this.
This normally means that the PKCS#11 driver you are using has a bug. We observed this bug with the drivers for iButton (version 1.01) and with older drviers for Datakey cards and iKey 2000 series tokens. For Datakey cards and iKey 2000 series tokens there are already drivers that fix this bug.
Bug details: The wrapper asks the driver for the required buffer length for returned data. It uses the method specified in the PKCS#11 standard - it passes NULL_PTR as buffer when calling the driver function (e.g. C_Sign). The driver must answer with the required buffer length, but it must not abort any active operation (e.g. signing). Thereafter, the wrapper allocates the required buffer and calls the function (e.g. C_Sign) a second time, providing the appropriate buffer. Now the driver should process the operation and finalize it if appropriate. Drivers with that bug abort the active operation after the first (query buffer length) call. According to the standard they must not do this.
If you want to do a workaround, this is possible.
You have to modify the function Java_iaik_pkcs_pkcs11_wrapper_PKCS11Implementation_C_1Sign in the file pkcs11wrapper.c.
Instead of asking for the required buffer length, modify the wrapper to use a buffer with a sufficient length. Have a look the source code, you will quickly see what has to be done. To anticipate the question: No, this workaround will not become part of the next release. We do not include any code which's only purpose is to workaround bugs of third-party products. Ask the vendor of the product to fix the bug.
It seems that you do not have the pkcs11wrapper.dll (or libpkcs11wrapper.so under Unix) in you search path. You can provide such a path directly to the Java™ VM setting the java.library.path system property like:
where ../bin/<windows|unix>/<platform>/release is the path where the pkcs11wrapper.dll (or libpkcs11wrapper.so under unix) file is. You can also place the file in the folder for binary files of you Java™ Runtime Environment; e.g. the jre/bin folder. Alternatively, you can also place the file pkcs11wrapper.dll in the system directory of Windows. On Unix systems you can place the libpkcs11wrapper.so in a lib directory of the system.