I’m trying to update the firmware for a NitroKey HSM (of which the SO pin is blocked and I don’t know either pin anymore), but the portal is stating the firmware update failed:
“Device Issuer CA DEDINK02 not ready. Already logged in and licenses available ?
Firmware update failed, possibly leaving the SmartCard-HSM in a corrupted state.
Please follow the instructions at”
The issuer for the NitroKey is DEDINK0100001, and the current HSM is on version 2.5.
Is there a way to get this to succeed?
We are experiencing a major network outage at the office after an excavator cut into the main fiber line for our area.
That disconnected all HSMs from the PKI-as-a-Service cloud instance, so that any operations that require key material (Firmware Update, DevNet CA Certificates) are currently impossible.
Contrary to the message, your HSM is not left in corrupted state, as without keys no changes in the firmware are possible.
We’ll post an update if the issue is resolved.
Thanks for the reply.
Looks like I’ve selected the best possible time then to try and update the firmware 
I hope that those fibers get restored fast, that must be very annoying for your company.
The fiber is fixed, we are online again and firmware updates should be working.
Glad you are back on-line. How does one sign up for PKI as a service so I can do a firmware update?
Just go to www.pki-as-a-service.net, insert your SmartCard-HSM or Nitrokey-HSM and press continue.
Unless you already have a local client running (Smart Card Shell or OCF) you get a page with instructions on how to download and install the client.
If the client is already running, the portal will check, if the HSM is already registered. If not, you are prompted to enter an e-mail address, to which an activation code is send. You need to enter the code in the portal and are registered.
Then choose Home / Update firmware to check for updates.
You only need to register with one token and can update any token you attach.
Thanks, I did the registration and so far it only seems to see the working HSM2. The one requiring the firmware update wasn’t listed yet (I didn’t want to go too far as I don’t want to wipe the working one). Do I need to exhaust my SO login attempts before it will show the inaccessible HSM?
I stopped at the “Create Firmware Update Request” screen.
When you start the request you need to select “card in reader” and insert the device you want to update. It will then probe the card and tell you what can be done. The update only starts when the pre-flight check is OK and an update is available. Nothing will happen until you click “Update”.
The firmware update has the ability to perform the update remotely. For that you need to select one of the registered tokens. The process will then inspect the token the next time it connects to the portal and perform the update.
There a basically three ways a SmartCard-HSM can connect to the portal:
The second variant can be used to update firmware remotely. Imagine you have placed a SmartCard-HSM in an IOT device somewhere remotely. You don’t want to walk there, pick it up, take it home to do the update. Instead you can schedule the update by selecting the token from the list and let the portal to the job then next time the token connects.
Thanks for the detailed answer. I think my situation is unusual so i’ll share some details to see what you’d recommend. I have 2 HSM2 installed inside of a server (inside meaning via the internal USB bus). Of course the server is several thousand miles from where i’m located, but I do have remote console access. I registered the working HSM and expired the use count of the SO PIN of the locked HSM.
The PKI-as-a-service has yet to show the expired SO PIN HSM as an option. I can select the “current token in reader” but that is the working one. I don’t have an easy way to remove the working HSM leaving only the expired one as they are internally installed. Is there a way to point the firmware update to the locked HSM or does it assume the logged in token is the one to receive the firmware update?
Are you using the OCF client or a Smart Card Shell on the server ?
Do you have an UI from which you can access the OCF client ? Then you could switch the token after login using the tray icon.
In the Smart Card Shell you could select the other token in the reader configuration.
I can use scsh3gui (I presume that is the OCF client). Yes i’m able to select either smartcard in the reader preferences. BTW, separate question is can I do the setup without the gui using other tools in that package? I’d like to be able to import pkcs12 files without using the GUI.
Back to the original topic. If I change something in the reader configuration in the scsh3gui can that direct where the firmware update goes?
FWIW I was using the java client referenced by the portal for my prior firmware download tests.
OCF is the OpenCard Framework used in the Smart Card Shell (scsh3gui) to access the smartcard. The OCF client is a minimal daemon that allows the portal to access the smartcard. The daemon waits on port 27001 for a GET request from the browser to trigger the connection to the portal.
The same mechanism is provided by the Smart Card Shell, if you enable “Start background web client” under Options / Preferences.
Right now there is no headless script to import a PKCS#12 container, but you could use the scriptrunner or scsh3 (without the “gui”) to run a script that does that like the import plugin in the key manager (see keymanager/plugins/220-importp12-plugin.js for details).
Thanks so is it sufficient to use the smartcard gui and change the “reader configuration” to only include the HSM we want updated after doing the initial login? Not sure if they both go thru the same backend before accessing the HSM (using OCF).
Sorry … and start the background web client.
I tried the background web client option and changed the Options->Reader Configuration to only show the locked HSM (is this just a local gui option or does it affect the OCF server’s config?) When I go to do the update it errors saying to please remove the keys first and references the working HSM. I’m missing what I can do to force it to use the locked HSM.
I can see in the portal, that you successfully completed a firmware update. Was that for the token in question ?
Generally the portal offers an update, if a new firmware version is available or the retry counter for the SO-PIN has reached zero. In the later case it doesn’t matter if there are keys on the device.
I updated the working HSM just to see what would happen. The portal never shows the locked HSM. The locked one has an SO-PIN of zero now.
Maybe there is a misunderstanding: The portal will never show the other token in the selection list, just because it doesn’t know it.
You need to select “card in reader” and on the client switch to from the token you used to login to the token you want to update.
Ok, yes that is understood. I guess i’m not sure how to do that switch. The smartcard gui changes to the reader configuration to ignore the working one has no affect on the firmware update. Which client are you referring to? Is this the downloaded java OCF client? If so, I don’t interact with that client so how do I tell it to ignore one of the HSM?
When you start the client with
java -jar ocf-cc.jar
it should create an icon in the tray. Click on that icon and select “Reader Configuration”. Then select the token in the “Select Reader” drop down list.
If the tray icon does not show up, then start the client with
java -jar ocf-cc.jar -w
The -w will open the log window. In the log windows you can right click to open the same menu that shows up at the tray icon.