Now I re-initialize the card (for example with 3 new DKEK keys or no DKEK at all) using sc-hsm-tool --initialize. And now I want to create the first key pair with a different ECC, for example NIST-p256/secp256r1/prime256v1 with new --id and new --label:
it does not seem to implement the new configuration. If I use pkcs11-tool --list-objects
I still see listed the old --key-type (EC_PARAMS) --id and --label
Changing the SO-pin also does not have an effect.
I am wondering whether this is the expected behavior or I am doing something wrong or I am missing something.
Hmm, to my mind you can’t use pkcs11 to first time initialize the HSM. You have to use scm-hsm-tool and you need to do this carefully to allow a) the DKEK shares for backup and also b) the Security Officer Pin - otherwise it will be random and you can’t change/init the HSM again. If you never used scm-hsm-tool , you could still use pkcs11-tool and it will not show you, that the HSM is NOT fully initialized.
To understand all stored objects on the HSM , I would recommend pkcs15-tool -D
My apologies for the unclear post.
Yes, the card was initialized the first and the second time with sc-hsm-tool --initialize. Then pkcs11-tool was used to create the key pair.
I could also re-import the first key with the proper DKEK and wrap file, everything works fine, for example signing etc.
The only thing is that these parameters: --key-type, --id and --label cannot be redefined upon re initialization of the card.
Example, if I set the --id of the the third key that I generate for the first time to some number, say 13, then after reinitialize the card, the third key that I will re-create will always have --id 13 no matter what --id number I will try to set up for the key.
actually, no I haven’t used the flag --set-id because it was supposed to be a new key pair after reinitializing the card, but I will definitely give it a try, thanks!
My main concern is the key-type which remains always the same type. Going back to the previous example, if the first time I set the third key with the flag --key-type EC:secp256k1 then after reinitializing the card, the third key pair will always be a secp256k1 even if I use for example --key-type EC:prime256v1
Which version of OpenSC do you use? The latest version and even more the nightly builds, introduce some significant improvements. It may be worth trying those.
sorry again for providing sketchy info. The OpenSC version is 0.19.0 with Fedora linux (opensc-0.19.0-6.fc30.src.rpm), x86_64 architecture.
Oh I see the Nightly builds on Github, I will try one in the next few days, and report here…
I managed to manually compile the incoming new release opensc-0.20.0.tar.gz (link here)
I made sure that I was using the freshly compiled opensc-pkcs11.so library but I see the same pattern, after re-initialize the card and create a new key pair, -id, --label and --key-type remain as defined before the re-initialization.
I forgot to mention in the previous posts that instead of using sc-hsm-tool --initialize, I also tried to re-initialize the card with pkcs11-tool --init-token (even though DKEK could not be added) but the outcome was the same.
Since I know what to expect, I am ok with this but if it is a real unwanted behavior and not just me being sloppy, should I open a ticket on OpenSC?
As posted in OpenSC the case is closed. All started because I mistakenly enabled use_file_caching = true;
in the file /etc/opensc.config. The line should have remained commented.
The caching option in OpenSC is meant for read-only clients, i.e. if you provision a ready to use device with keys and certificates. It speeds up the while process, as certificates are not read over and over again.
Yeah, I think a caching option could have good reasons, but if you fire the cmd “init” a cache should also be cleared to prevent using old information.