Hi, when following this guide0 I am hitting the very issue described in this thread on CardContact’s support forum1. So I tried disabling smartcard plug and play and answering “No” to “Automatically access card with Key Manager”, it’s still failing with the same error:
>GPError: Card (CARD_INVALID_SW/25344) - "Unexpected SW1/SW2=6300 (Warning processing: State of non-volatile memory changed) received" in /home/smartcard/scsh-withJRE-3.18.39/scsh/sc-hsm/ManagePKA.js#142 at /home/smartcard/scsh-withJRE-3.18.39/scsh/sc-hsm/ManagePKA.js#142 at /home/smartcard/scsh-withJRE-3.18.39/keymanager/keymanager.js#1785 at /home/smartcard/scsh-withJRE-3.18.39/keymanager/keymanager.js#3022
I am using Nitrokey HSM2 from a desktop computer. My SmartCard Shell instance runs in a Debian 12 virtual machine, and I connect HSM to the remote host through VMware Remote Console. So I tried running SmartCard Shell right on the desktop computer, and got the exact same error.
Is there something I am missing? How can I get n-of-m authentication working?
The signature will obviously fail, if the private key used for signing does not match the public key imported during n-of-m setup. Are you sure that public and private key match ?
Can you post the last 10 APDUs from the trace tab in the Smart Card Shell up until the error happens ?
So i tried to reinitialize one hsm using smartcard shell, with “resetting pin with so-pin not allowed”, and brainpool256r1 as a curve (instead of p384r1 as before). Then I exported the publick key, and tried to replace in the CA HSM one of the previous allowed key with the newer one. It failed with “Security condition not satisfied”. The log and trace are in the zip file attached. card_replace_public_key_2024-09-30.zip (7.1 KB)
You need to be authenticated to replace the registered public keys. As you can not authenticate using the 384 bit key, you need to re-initialize the target device and import the brainpoolP256r1 public keys.
I will need to check, if we can support authentication keys that are not brainpoolP256r1 keys. The current code expects a 256 bit signature, which is why the ManagePKA code assumes a fixed signature length.
At least we should prevent users from importing public keys that are not brainpoolP256r1 for PKA.
Alright, thank you! Before I re-initialize the target device, are there best practices I should be aware of, regarding key backups in particular?
As a reinit of the CA HSM is required in case there is no possibility to reach the quorum of authentication keys, is it safe to say that each authentication key should be set with a (different) DKEK, and that the target should have its DKEK too?
Public key authentication and key domains are unrelated. The former is one of the authentication mechanisms, while the later allows encrypted key backup. There is no dependency of one on the other.
It’s quite common to have a different regime for managing DKEK shares and PKA. There is no need to assign the same key custodians for n-of-m in PKA and n-of-m when accessing DKEK shares.
Obviously both mechanisms control access to sensitive key material. While PKA controls access to the key on the device, DKEK share control access to keys while they are not on the device, but in transit or backup.
You probably know, that there is a third mechanism, XKEK key domains, where control over key distribution is even more strict, with a group signer that entitles devices to be part of a key domain. While in DKEK key domains the key could be disclosed outside the HSM, if the DKEK share is disclosed, in XKEK key domains that is not possible (unless someone compromises the Scheme PKI).
We aimed to split the dkek shares across the same key custodians for simplicity sake, but indeed that may not be the most common approach.
Thanks for your help, I confirm I could successfully authenticate to the HSM. So I thought I was close to have my root CA signed, seems I was wrong. So maybe I’ll ask for help again soon.
