Hello. I own a Nitrokey HSM in order to store lots of data objects on it. I thought this would be no problem, but i found out, that this leads to enormous loading time, when i want to use the token. I need to access it via C++ and the OpenSC PKCS11 library but when i call the C_Initialize-method, it takes ages. Setting the OPENSC_DEBUG environment variable to at least 3, i saw that all objects are read on initialization. Is this expected behavior or are there ways to omit this?
Hi @szszszsz. Thank you for forwarding my question to the github page. I just provided an output file and further information and hope someone can help me on this.
In my opinion it’s a twofold problem. I don’t see any need of preloading the keys, when initializing the token (but this is just a guess as i don’t have enough insight into the topic and probably it is needed) and the hardware seems to be a bit slow. The mentioned Yubikey maybe is faster, but is also around 10 times of the price of a Nitrokey HSM, so i think one will have to make a decision if speed is really that important.
To bring this to an end :
The solution for this particular problem is either to invest much more money or to set the OpenSC use_file_caching parameter to true (which i’m not very happy with, since it stores the plain data on the harddrive).
I have not looked into the source code to see why the entries are cached (seen logs only), but I guess this initial discovery process is for accessing the objects through their labels. Perhaps disabling this operation and having smartcard-external address cache (client application local relation db of labels to slot, or file path), or not using labels at all, would solve this problem.
It can only store data that are available publicly anyway (most of them even prior to the authentication with PIN). However, the problem is with initial discovery here.
I tried to not use labels but this didn’t change anything. I think i will either use the provided file cache or try to compress my many objects into only a few and do the split programmatically.
@saper The objects were stored with the attributes CKA_PRIVATE but this seems not to affect the label and application data.
Edit: Ah i think i misinterpreted your answer @saper. You meant that the actual data is still save? This is indeed a good point.
I need to revoke my latter post. The data is cached after i logged in to the token, even if it’s marked “private”. In my opinion this is a security issue. This is not totally related to the initial question, but since using file caching is the only feasible solution i have by now, i post it, just to show the implications of the “use_file_cache” parameter.
Even CKA_PRIVATE objects have some public data (label and others) - and this is what can be extracted. The actual private key does not leave the HSM ever.
If you keep secret data in your label, those data are not safe at all.
Yes, label or id would have been ok, but also the value attribute was stored on the disk, which was not ok. But since i changed a bunch of stuff in my program, i don’t have to use the caching anymore, so the problem is gone.
