In the CESeCore we lost caching of keys as mapped by purpose in BaseCryptoToken, as they were in the old BaseCAToken, and instead retrieve them directly from the keystore every time they're asked for.
During activation of the BaseCAToken, the mapped key aliases where pre-loaded into this cache.
When using a soft crypto token or an HSM with limited number of keys in each slot, this has little performance impact, but makes a considerable differnce when working with an HSM slot with many keys.
We should restore this caching.
Since the SUN PKCS#11 provider wont make changes in the underlying HSM slot available to an already logged in application, it is reasonable to load everything at activation and operate on both the cache and the underlying HSM when the key material is modified. (E.g. generate should add the entry to the list and load references to the generated key pair into the cache.)
- Load all aliases and public keys (certificates) into cache at activation time (key entries might be protected and the password is unknow at this time).
- Caching the list of all available map entries (implicit since the map has the .keys() method)
- Update cache with private and secret key entries when accessed.
- Perform updates (generate and delete) without locking reads as outlined below.
- Kill switch configuration in case unexpected problems occur from caching.
Since this is a hot-path in the time-critical operations, we should avoid locking as far as possible.
It is not possible to extend the KeyStore class, but we should wrap the KeyStore in order to not clog up the existing CryptoTokens.
This will isolate the map, locking and all modifications will go through this class (lowering the risk of missing something) and make JUnit testing easier.