Nitrokey HSM 2 vs HSM 1 Import Key


I find that key export and import for HSM 1 differs from HSM 2.

On HSM1, key generation with key algorithms ECDSA_256,WRAP set allows me to successfully export and import an EC private key given a DKEK. On HSM 2, I may successfully export but not import.

The error provided from scsh3 version 3.15.377 is as follows:

GPError: Card (CARD_INVALID_SW/28416) - "Unexpected SW1/SW2=6F00 (Checking error: No precise diagnosis) received" in /home/micharu123/CardContact/scsh3/scsh/sc-hsm/SmartCardHSM.js#1240
    at /home/micharu123/CardContact/scsh3/scsh/sc-hsm/SmartCardHSM.js#1240
    at /home/micharu123/CardContact/scsh3/scsh/sc-hsm/HSMKeyStore.js#229
    at /home/micharu123/CardContact/scsh3/keymanager/keymanager.js#1814
    at /home/micharu123/CardContact/scsh3/keymanager/keymanager.js#2049

In my debugging effort, I found that setting no key algorithms resulted in a HSM 2 successful export and import (again, given a DKEK). The backtrace implicated an importKey function error. I printed the wrap and id by inserting the following into KeyManager.prototype.importKey:

    var a = new ASN1(bin);

	var wrap = a.get(0).value;
	var id =;
    print("VALUES: ",  wrap, id);

The wrap value for importing a key with algorithms ECDSA_SHA256,WRAP was 0000. This was the same for a key with no specified algorithms.

I am curious, then, what is the intended way to export encrypted key material using a DKEK? Should we never specify the key algorithms?


I can reproduce the issue and we are looking to isolate and fix the issue. The generated 6F00 response code indicates that there is an issue in the code.


I was wondering when you might have an answer/solution for this? We appreciate the hard work!


I can confirm that this is a bug in the SmartCard-HSM 3.1 firmware. The bug is tracked as issue #168 in our internal tracking system.

We plan to release a 3.2 firmware update and make it available on the PKI-as-a-Service portal.

Users that rely on key wrap/unwrap are requested to generate keys without an algorithm list (the default behavior when using OpenSC or sc-hsm-embedded). The bug only occurs if keys are generated using the Smart Card Shell and if the algorithm list is not left empty.

Keys generated on 3.1 and exported with an algorithm list can be imported in the 3.2 firmware version.

We apologize for the issue, which was caused by a functional requirement dropped during development of the 3.1 firmware. This dropped requirement caused the removal of a test case that also contained the algorithm import test.


No worries! If you could respond to this thread when the firmware is released, that would be much appreciated.

Also, while we are on the topic, I was curious about the firmware update procedure. I noticed that the PKI-as-a-Service portal supported firmware updates. However, I had read (long ago) that the Nitrokey HSM could not flash new firmware without having physical access to the chip inside the USB casing.

Is that not true?

I avoided a firmware update on my older HSM 1s for fear of bricking.


The Nitrokey HSM has two different firmware components, the firmware in the USB and the firmware in the embedded Secure Element. The firmware in the SE can be updated via the PKI-as-a-Service portal.