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 = this.sc.determineFreeKeyId();
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 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.
AFAIK Nitrokey HSM 1 has smart card based on another hardware, and it cannot update its firmware from v2.x to v3.x. It still can follow the updates on the v2.x line.
This is the only way to update the device’s firmware. The USB component is not updateable.
Firmware 3.3 is available for the Nitrokey HSM2 at the PKI-as-a-Service Portal. The bug is already fixed in 3.2, but the updated version did not find it’s way to the firmware update service.
Please let me know, what is the latest HSM2 firmware version right now in the mid 2020?
Does your NK HSM2 have some internal serial number to uniquely identify each its piece in the existence unless clones exist? I hope it is not possible to change such serial number by a firmware update or some publicly known commands for HSM2 end users?
Can you after payment verify its unique serial number and current hardware & firmware levels and then tell it to me by e-mail to avoid a replacement on the way especially if using a cheaper delivery channel via a 3rd party?
Can I see this serial number by some read only command from a user manual of HSM2?
Can I get a user and other available manuals for HSM2 in advance before purchase to better understand what I am going to get in result.
As of today the following firmware versions are the current version
V2.5 for JCOP 2.4.1r3 based SmartCard-HSM (HSM1: DENK0100001 - DENK0100750)
V2.6 for JCOP 2.4.2r3 based SmartCard-HSM (HSM1: DENK0100751 - DENK0101751)
V3.4 for JCOP 3 based SmartCard-HSM (HSM2: DENK0100752 - DENK0104930)
V2.x is EOL. V3.x is the current production version There are currently no plans for a new version.
Each SmartCard-HSM contains a Device Authentication Key generated during production and certified by the Device Issuer CA. The ID (see above) is generated by the CA, unique within the name space of the CA and verifiable by tracing the certificate chain up to the Scheme Root CA that we operate. The Scheme Root CA public key is embedded in the SmartCard-HSM as trust anchor for peer authentication and is also embedded in OpenSC or OpenSCDP middleware. You can use the Smart Card Shell Key Manager function to verify the certificate chain:
SmartCard-HSM Version 2.6 on JCOP 2.4.2r3 Free memory 32767 byte (at least)
Issuer : CVC id-SC-HSM DICA CAR=DESRCACC100001 CHR=DEDICC0300001 CED=22. Oktober 2015 CXD=21. Oktober 2023
Device : CVC id-SC-HSM Device CAR=DEDICC0300001 CHR=DECC030079700000 CED=7. Februar 2018 CXD=21. Oktober 2023
During a firmware update, a new device certificate is generated, as the old device authentication key is removed with the firmware code. Firmware updates are protected using a challenge response authentication with secure channel establishment (SCP02) with a symmetric authentication key. That is is stored on a SmartCard-HSM in the PKI-as-a-Service Portal, which is the only source of firmware updates.
