Nitrokey 3 Test Firmware With Secure Element Support

Today we have published a special test firmware release for the Nitrokey 3. The highlight is the complete integration of the SE050 Secure Element into the OpenPGP Card. 

With this firmware it is now possible to select the "backend" for the cryptographic primitives in the OpenPGP Card. The previous software backend offers full transparency through viewable open-source source code, but only allows the generation of a maximum of RSA-2048 keys on the Nitrokey 3. Longer RSA keys can be imported, but not generated, as the computing capacity of the microcontroller is limited. The SE050 backend now enables the generation of RSA-3072 and even RSA-4096 keys, the latter in about one minute. The Secure Element is not open source hardware, so the implementations of the cryptographic primitives are not reviewable, but it offers certified security according to FIPS 140-2 Security Level 3-4 and Common Criteria EAL 6+.

A recent pynitrokey is required to switch the backends. This can be used to switch on the SE050 backend as follows:

nitropy nk3 set-config opcard.use_se050_backend true

Please note the messages displayed. When changing the backend, all OpenPGP Card data in the previous backend is irrevocably deleted. As this is a test firmware, we recommend being careful and creating backup copies of sensitive data and not using it productively yet. In future, it will also be possible to change the backend via the Nitrokey App 2, which is currently being worked on intensively.



Are there actually any OSS secure elements available? I always read that obscurity is part of its security design.
The short answer is: no - the longer is: I am not aware of any commercially available ones. Even though RISC-V got some traction recently. Under the line the design itself might be open-source, but the actual (IC) layout could be troublesome to be open-sourced due to NDAs. It's surely not the right point to go into more detail here. But on the other side: it's not really easy to get these certifications, although I am not aware if schematic/design/layout reviews are included for these. Also I would not condemn a product across the board just because it is proprietary - at least an indication for such a judgement would be necessary from my point of view. Nevertheless, generally we would also be happy to see this as Open-Source then we wouldn't have to have this discussion.
hXXps:// FPGA based solution looks promising.
When the next firmware will be release ? and using nitrokey with keepassxc still doesn't require touch presence, is there a fix for that ?
There will be a new stable release very soon with various FIDO2 detail-fixes - this will not (yet) include touch-presence for HMAC-SHA, yet...
It's always promising what's happening with the NitroKey. But on the other side it is disillusion. I hoped that the usage of the NitroKey with OpenPGP will be much more effective since the decryption of something took five time longer than with a YubiKey (and I will change from it to NitroKey). But than I cannot update the firmware because of the error "LibraryNotFoundError('Error detecting the version of libcrypto')" of pynitrokey binary for linux (I use devuan/debian). I will wait another longer time in the hope to get a useful product. As I said it is always promising what happens.
Hey, the performance should massively improve with the Secure Element being activated. For updating, yes this is a known issue, which happens due to an transient dependency of pynitrokey. If you have installed pynitrokey through pipx (as our docs suggest) there is a workaround at the end of the issue.
Yes, it is now really fast. Now the Nitrokey 3 Mini is usable for me. Thank you!
Just tested the SE050 backend and I confirm it's faster, a sign operation with a RSA 2048 key goes from 1700 ms to 900 ms, almost two times faster! That's appreciable but still slower than the Yubikey 5 (130 ms). Also the verify pin operation is still slow at 600 ms (only 10 ms on the Yubikey), I hope this can be improved as well.
thanks for the feedback and measurements - I think it will be very challenging to reach 130ms / 10ms for these operations. Currently nearly all architecture and design decisions are biased towards maximum security, this obviously introduces the longer roundtrip times. But we are trying to improve here anyways...

Add new comment

Fill in the blank.