The PKCS#11 standard has been around since 1995 and is a platform-independent API to access and use cryptographic functions in hardware security modules (HSMs), smart cards, USB tokens, TPMs and the like. PKCS#11 is standardized in the Oasis standardization organization.
In PKI and digital signature solutions, the use of cryptographic modules is widespread. On the server side, where our products mostly operate, it is mandatory in many audit schemes to use cryptographic modules that are certified. The two most prominent certifications being FIPS 140-2 (FIPS 140-3 is upcoming) and EN 419 221-5 (eIDAS Cryptographic Module for Trust Services). For PrimeKey products, such as EJBCA and SignServer, PrimeKey strives to support as wide range of cryptographic tokens as possible and therefore uses the standard PKCS#11 API to access these modules. Our products developed in Java can make use of two different client implementations of PKCS#11, the Java PKCS#11 provider which is built into the Java JDK on a high level, or JackNJI11 which gives more low level control to the PKCS#11 interface.
The PKCS#11 standard has had (among other things) a hard time keeping up with the fast cryptographic development in recent years. This has led to a number of vendor defined mechanisms being used in different vendor's HSMs and tokens. This is bad in general as a single API can no longer be used with different vendor's tokens, in effect creating lock-in effects and higher costs. As cryptography is used for a number of different use cases, all vendors don't need or want to implement the full specification. For example, if the use case is pure digital signatures, implementing key wrapping or AES encryption is not needed and would only delay the product and make it more expensive. In general, it has worked surprisingly well over the years, but there have been subtle nuances requiring consideration when attempting to use a new token claiming to be PKCS#11 compliant causing interoperability issues between clients and servers.
PKCS#11 v3.0 adds new cryptographic mechanisms, and adds profiles to the API, something that may be used to enhance interoperability between implementations. With PKCS#11 v3.0, there are now standardized mechanisms for signatures using the SHA3 hash algorithm, i.e. SHA3-256withRSA, SHA3-512 with ECDSA, etc. The PrimeKey products have supported SHA3 for quite some time, but only using software crypto token, waiting for generic standardized HSM support. In the same way as with SHA3, EdDSA signatures are now a standard part of PKCS#11. Having supported the Ed25519 and Ed448 signature algorithms for a while in the PrimeKey products, also in software crypto token, it is now possible to support it in a standard way across HSMs that implement PKCS#11 v3.0 and later.
It is on PrimeKey’s roadmap to update, the Java PKCS#11 provider and our implementation in JackNJI11, for the PrimeKey products, and information about this will be shared in the product release notes.