Nitrokey HSM 2 expected behavior

I just want to share my finding on using the Nitrokey HSM 2.

I initialize the card, for example with 1 DKEK keys, then I create the first key pair, say a secp256k1 key pair with:

pkcs11-tool --module --login --pin 123456 --keypairgen --key-type EC:secp256k1 --id 1 --label "first-key"

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:

pkcs11-tool --module --login --pin 654321 --keypairgen --key-type EC:prime256v1 --id 10 --label "key-1"

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

But I could be wrong at all :smiley:

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.

Hmm, strange. So you use e.g. pkcs11-tool --pin xxxxxx --set-id 44 --id 13 --type privkey to change the ID from 13 to 44 ?

If that is not working, I assume some bugs :smiley:

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 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?

Yes please.


1 Like

Also a thanx from my side for reporting the bug to OpenSC …

cc @sc-hsm

I can’t reproduce the issue. See the topic on OpenSC.

1 Like

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.

My humble apologies for the trouble

1 Like

LOL - ok, that is an easy one. A bit confusing, seems that the cache is not flushed when you do an init, nor ?

so it seems, indeed it was a odd way to find out,
in the end it was all good and we/I learnt something!

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.