This year the Christmas release brings new versions of our CMS-S/MIME and Time Stamp toolkits:
- IAIK-CMS with S/MIMEv3 5.0
- IAIK-TSP 2.3
Also have a look at the recently released new versions of our IAIK-JCE and Elliptic Curve core crypto toolkits:
- IAIK-JCE 5.2
- IAIK ECCelerate 2.15
We proudly present a new release of our new IAIK ECCelerate™ elliptic curve library! Version 2.10 brings along new curves, performance improvements and some minor bugfixes! It is based on the latest standards and replaces our old IAIK-ECC library. IAIK ECCelerate™ is based on Java 5/6 technology and has been thoroughly optimized for speed. Currently, it supports ECDSA, ECDH, ECIES and optionally ECMQV.
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.