I am trying to re-initialize my HSM key, but it doesn’t work anymore.
Entering: sc-hsm-tool --initialize --so-pin 3537363231383830 --pin 648219
Using reader with a card: Nitrokey Nitrokey HSM (DENK01022960000 ) 00 00
sc_card_ctl(*, SC_CARDCTL_SC_HSM_INITIALIZE, *) failed with PIN code or key incorrect
Using reader with a card: Nitrokey Nitrokey HSM (DENK01022960000 ) 00 00
Version : 3.2
Config options :
User PIN reset with SO-PIN enabled
SO-PIN tries left : 7
User PIN tries left : 2
Question: What can I do to factory reset the key and using which command?
I don’t remember having changed any of the PIN. All commands came from OpenSC (SmartCardHSM · OpenSC/OpenSC Wiki · GitHub).
Unfortunately Nitrokey HSM does not have factory-reset. Once the SO-PIN is lost, and all attempts are used up for User PIN as well, device becomes blocked and unusable.
The SO-PIN has a retry counter of 15 and can not be unblocked. Blocking the SO-PIN will prevent any further token initialization or PIN unblock.
Potentially, in case the SO PIN was ever changed, perhaps the format was wrong as in: Nitrokey HSM SO-PIN conversion.
Other problem with the PIN might be its invalid length, like here: Nitrokey HSM - keypairgen fails with 16-digit user PIN (edit: apparently only with OpenSC older than v0.16).
As a last resort, you can look at forum search - perhaps this would remind you anything: https://support.nitrokey.com/search?q=HSM%20PIN.
Also please make sure you are using the latest OpenSC package, which is 0.19.
Related to this topic, is there a way for a future update/upgrade so we can be able to reset a Nitrokey HSM2 if the device is blocked or SO-PIN lost?
That feature will not be added, because it would violate a security mechanism: Initializing the device does not change device authentication, which is used for authenticating the device as 2FA and for public key attestation. Without authentication, an attacker would be able to reset the device and get full access to authentication configuration. He could then set his own password and circumvent any login mechanisms that utilize device authentication.
The PKI-as-a-Service portal uses this scheme and asserts during login, that the device is authenticated and user authentication has been performed at the device (by PIN or biometric). With that scheme, no secret PIN code or login credentials need to be stored at the server (and thus can’t get lost).
In the security model of the HSM, the SO-PIN (or Initialization Code) is the mechanisms to place the device under sole control of the security officer. He can then delegate control to the final user by setting a User-PIN (or Transport-PIN). With this delegation he relinquishes control of cryptographic material. His only capability, is to reset the device and thereby clear cryptographic material (If configured during initialization, he could as well reset the User-PIN’s retry counter or set a new PIN value, but that is for convenience only).
Hello. Just ran into this issue. Would you shortly explain why couldn’t initialization erase everything from the token, including all cryptographic material and authentication configuration? An initialized token would be as good as any other other empty token to an attacker.
Because the device authentication key and certificate is generated during production of the device (i.e. when loading the firmware). That key and certificate does not change during initialization, but it is used to authenticate the device in remote management processes (like login into the PKI-as-a-Service Portal).
If the SO-PIN is lost and thus the device can no longer be reset, then the only way to fix the situation is to update the firmware and get a new device key and certificate generated.
Is there a way an firmware update be requested to re-generate the device identity even if the device is using the latest one?
If the update process in the PKI-as-a-Service Portal detects that the SO-PIN retry counter is 0, then an update to the current version is enabled, independent of whether active keys are contained or the current firmware has a lower version number.
To sum up, to unlock the SO-PIN locked Nitrokey HSM, it suffices to run the firmware update process.
@sc-hsm Just a final question: does the device need to be registered on the PKI-as-a-Service Portal before that, or it can be done so with the SO-PIN locked?
No need to register the device for a firmware update.
Hi, I have blocked out my SO-pin and verified that it is possible to reinstall firmware on the Nitrokey HSM2 The device returns to non-initialized which is excellent, but I have two questions
What happens if my userpin is blocked aswell?
The re-update of firmware follows a somewhat strange process if no registration for firmware update is needed. I have to enter a user-pin, put in my email and enter an activation code before being able to update the fw. Why? That seems like a registration to me. This may however have to do with my first question that when both SO-pin and userpin is blocked I don’t have to register.
Could you please clarify, I haven’t dared to block both SO-pin and user-pin due to that I am afraid ending up with a bricked device.
These are two different things: Portal login and firmware update. You need a HSM to log into the portal and therefore need to create a user account. Once you have an account in the portal, you could request a DevNet certificate or update your firmware (or do some of stuff we plan for the future ;-).
If you have multiple HSMs, then there is no need to register all of them. After login, you can just stick a HSM into the PC and start the firmware update. However you could also do firmware updates for remote devices: In that case you need to register the device with your account and select that device from the list when the firmware update is started. With that the device is updated the next time it connects to the portal.
One benefit of the registration process, is that we can proactively inform customers about security issues.
A blocked User-PIN does not prevent a firmware update, but as a general precaution the device must not contain any keys. This rule is only waived, if the SO-PIN is finally blocked.
The firmware update also issues new device certificates, that is why the update can only be performed via the portal, where the CA that issues those certificates is located. After the update the device is in the state as it was during initial shipment. And it has a new identity, which is why you need to repeat the registration process and associate the new id with your user account.
Ok thanks for quick response. Just to be clear if SO-pin and User-pin is blocked then I have a bricked device where it is not possible to do a firmware update? Seems to be two cases:
- User-pin blocked, SO-pin, blocked, keys on stick → device bricked
- User-pin blocked, SO-pin, blocked, no keys on stick → ???
There is no way to brick the device. You can always perform a firmware update if one of the following conditions is meet
- The device does not contain any keys
- The SO-PIN is blocked
Condition 1 is for normal use: We just want to make sure, that users do not accidentally destroy keys.
Condition 2 is for customers with a blocked SO-PIN, so they do not end up with a bricked device. That is however limited to 5 firmware updates.
OK, excuse me for asking two more things:
This is provided I have another working HSM in order to be able to log in to PKI-as-a-service?
If I only have one HSM i am toast unless I buy a new one?
Yes, you need at least one working HSM in order to log into the portal.
You can not use a blocked HSM to log into the portal for obvious security reasons.