Caused by a bug in the GENERATE SYMMETRIC KEY command, the SmartCard-HSM
(aka Nitrokey HSM2) in versions 3.1 and 3.2 generates weak AES keys with
little to no entropy.
AES keys generated that way must be considered broken and users relying on the
AES key generation are strongly encouraged to update to the latest 3.3 firmware
available at the PKI-as-a-Service Portal.
We apologize for the inconvenience. We use an elaborate automated test system, trying
to achieve 100% test coverage. That bug, however, was well hidden and was only
discovered by one of the regular code reviews.
Please note, that RSA and ECC keys and other security mechanisms are not affected by this bug. The DKEK mechanism that uses AES keys is not affected as well.
If you access the device once with the Key Manager in the Smart Card Shell, then garbage collection is explicitly started to reclaim memory.
The system tries to find a good balance between memory wear-out, response time and availability of memory. We explicitly trigger garbage collection when we run out of memory, objects are deleted or the INITIALIZE DEVICE is called without parameter. Garbage collection always runs before an APDU is executed, so a command failing with OOM will see garbage collection not before the next command.
There is also a bug in the JVM that we can not fix: If you import a key directly after device initialization, then the call sometimes reports an OOM. If you reset the device, import usually works.
To update the firmware you need to remove all keys first.
Objects allocated in a JavaCard are always linked to the applet instance. We need to destroy the applet instance and remove load files before the new load files can be uploaded and a new instance created. There no other way of doing that.
What happened when you tried to export the keys in the Key Manager ?
after the update I was a bit upset, finding the HSM2 complete empty:
“SmartCard-HSM has never been initialized. Please use --initialize to set SO-PIN and user PIN.”
So I have to start the DKEK-procedure once again - Turnschuhadministration #ausSicherheitsgründen.
It’s actually the other way round: You can not perform an update until the device is empty. After the update you can restore your keys after you set-up the original DKEK.
You don’t want anyone to load new firmware code into the device while active key material is contained. And again, an update is only required if you rely on the AES Key Generation function, which very few users actually do.
No, you need a browser to log into your account and do the probing to set up the proper update service request. The actual update could technically be done without a browser, but there is currently no mechanism in the portal to do the first step.
I have to correct myself: There is a way, if the token was registered under your account.
You can register multiple SmartCard-HSMs under the same account (same e-mail).
When you request a firmware update, you can select either “Current token in reader” or select one of the registered token from the list (The list does not show the token you used for login).
If you select a token from the list, then you can connect the token to the service using the ocf-cc.jar client. You need to basically follow the recovery procedure, but without the “?TOKEN” from the URL.
The first connection will probe the device and you can see the service request updated in the PKI-as-a-Service portal. If that step goes well, you connect the token again and the update should occur.
Instead of using the Java client you could try the RAMoverHTTP client that is part of our own PKCS#11 module. You need to enable the client with ./configure --enable-ram and have libcurl-openssl-dev installed.
But once again. This is a little experimental, so your mileage may vary.
OK, Java is a No-Go
RAMoverHTTP sounds like an option - next time. This time I have allready de-plugged the sticks that have bin in the 5 cm space before the walll
I will try the the PKI Portal now …
I need a java web client for the portal on my computer ?!
Ok, overall it is not working on a iMac as it is not from a certified developer. When I pushback macOS SIP, I am asked to download Java SE - where Apple loud and clear say’s “NO”.
Man, could you do it a bit simpler in the future ?! I always need some “development” engines around to configure your keys …
Now I need to setup a VM with macOS, install Java Runtime and hope that not another hurdle is around
… no further hurdle beside the deleting of all keys
Java is IMHO the only way to have platform independent code. We support the SmartCard-HSM on Windows, MacOS, Linux and Android. And sorry, our development capacity is limited. We can not just re-implement all the stuff on different technologies over and over again.
I’m always open for suggestions, if there is a better way. And the stuff is open-source. If someone feels like he should implement a different client, go ahead, we are here to support you.
C or GO could also be plattform independent code if you do it right. But such a discussion might be a rat-hole
IMHO FW updates is a matter of how you will do it. Now, I don’t know exactly how a SmartCard is supporting its FW update. Maybe that is something you could explain ?
When I compare it e.g. to smaller uPros , you would have a serial connection, a new FW image which you will transport to the SmartCard , a bootstrap loader that is moving the image to the actual position , if found and restarts. There might be some fuses, but all could be done with a small cmd-line program.
If that works , you could wrap a OS specific GUI around it to support selection of the image and status messages.
Depending how the update works, there might be other solutions without installing java or other supporting tools that support the end tool.
Another possibility is a portal like yubico is providing: exchange the key.
While I understand your complains about beeing a small company, a company is growing fatsre, if it provides an excellent service to their customers. It is just a diffrent , if customers a saying " FW upgrade is nasty but easy" or " Wow, what a crab procedure to get back my control on the token - needed hours to do so " - just a thinking
The firmware update requires regeneration of the device authentication key and the issuance of a new device certificate. That process can not be done offline, as the CA key can not be made publicly available.
I don’t quite understand your issue with Java. I use java on my Mac without any issues.
Ok understand that problem with the CA Certificate. I assume that is also the reason, why the key get a new serial number ?
about java - I have used java while it was still developed by sun and also later. So I have a small history and also see how it is sometimes used today in a purpose that was not the original intention from the developers. And I also agree it is my personal issue. I still believe a p-code like language/system might be good for prototyping, but not for final solutions. C is much faster, GO might be more future oriented.
I truly believe that java anyhow has some challenges in the future as it needs to be licensed by Oracle no longer for free. So if a company today wants to update the FW from SC-HSM, they already need a business license. I assume that will influence the usage of java tremendous in the future.
What I overall don’t like, if I need to install a general purpose toolsuite, just to do a FW update.
Would there be a possibility to integrate that into the NitroKey App ? The App could handle the online connection without java.