Security Advice: SmartCard-HSM generates weak AES Keys

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.

Update: Before updating, you need to register an account at CardContact Developer Network (CDN) first (instructions).

2 Likes

What great timing I was about to start experimenting with these features.

I have requested an update, does it need to be manually authorized? I just see ‘Request scheduled (Submit)’

Can you link us the relevant pull requests please.

Make sure you select “Current token in reader” and press submit. The portal will then
probe the current software version and select the appropriate update protocol.

You can always start over by creating a new update request.

1 Like

Got it, Thanks.

I just had a minor heart attack when attempting to re-import my keys and it was failing due to

sc_card_ctl(*, SC_CARDCTL_SC_HSM_UNWRAP_KEY, *) failed with Not enough memory on card

If you generate a key first using pkcs11-tool, then try to unwrap it works fine.

That is due to the JavaCard garbage collector.

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.

I was unable to export my keys via Keystore Explorer, so I simply deleted them via Keystore Explorer.

After the update I cannot access the token anymore via Keystore Explorer.

Seems like I have to completely reset the device?? That’s not a nice way of firmware update :-1:

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 ?

Hi,
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.

Is there anyway to get the firmware without a browser ? My HSM are build into server with no GUI/X

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 :smiley:

I will try the the PKI Portal now …
<Flame on!!!>
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

No need to use Java Web Start in the browser. It’s sufficient to execute the Java client on the commandline with java -jar ocf-cc.jar -v

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.

Nope: that is not working on macOS as Apple has banned java - means you need to install java direct from Oracle and for cmd-line you will need a developer version (full version)

C or GO could also be plattform independent code if you do it right. But such a discussion might be a rat-hole :smiley:
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.

1 Like