off
FIDO2-based multi-factor authentication
Nitrokey 3A Mini received official FIDO Alliance’s certification recently. This overcomes the previously mentioned shortcoming which was the reason for removing it recently, as discussed in Remove Nitrokey
Multi-Factor Authentication
Hi. Nice to see you reaching out and keeping in touch with customers on platforms like this in near real time.
I have a few questions for you that would be useful to discuss in a public format to avoid baseless juggling of other company’s reputations.
Please comment on a passage of my post, I am very interested in the microcontrollers used in your devices and I would like to emphasize that I have no special technical knowledge in this topic, so I may make mistakes in the formulation of my thoughts during this conversation.
As far as I understand at the moment Nitrokey’s strong point is the ability to upgrade the firmware. After analyzing this topic, it became clear that:
While researching the Graphene OS forum for this situation, I was able to become familiar with a resource such as ycombinator.
The following information caught my attention there:
It’s not just YubiKey.
NinjaLab: “All Infineon security microcontrollers (including TPMs) that run the Infineon cryptographic library (as far as we know, any existing version) are vulnerable to the attack.”
Chips in e-passports from the US, China, India, Brazil and numerous European and Asian nations
Secure enclaves in Samsung and OnePlus phones
Cryptocurrency hardware wallets like Ledger and Trezor
SIM cards
TPMs in laptops from Lenovo, Dell, and HP
EMV chips in credit and debit cards
This is kind of an entire class of attack where similar paths may be able to be used on these other controllers. Don’t gloss over it.
Having studied the article, which helped to understand in detail the vulnerability of such security keys and the methodology of its deployment in practice, together with comments from
NinjaLab co-founder Thomas Roche himself.
In the present work, NinjaLab unveils a new side-channel vulnerability in the ECDSA implementation of Infineon 9 on any security microcontroller family of the manufacturer.This vulnerability lies in the ECDSA ephemeral key (or nonce) modular inversion, and, more precisely, in the Infineon implementation of the Extended Euclidean Algorithm (EEA for short). To our knowledge, this is the first time an implementation of the EEA is shown to be vulnerable to side-channel analysis (contrarily to the EEA binary version). The exploitation of this vulnerability is demonstrated through realistic experiments and we show that an adversary only needs to have access to the device for a few minutes. The offline phase took us about 24 hours; with more engineering work in the attack development, it would take less than one hour.
After a long phase of understanding Infineon implementation through side-channel analysis on a Feitian 10 open JavaCard smartcard, the attack is tested on a YubiKey 5Ci, a FIDO hardware token from Yubico. All YubiKey 5 Series (before the firmware update 5.7 11 of May 6th, 2024) are affected by the attack. In fact all products relying on the ECDSA of Infineon cryptographic library running on an Infineon security microcontroller are affected by the attack. We estimate that the vulnerability exists for more than 14 years in Infineon top secure chips. These chips and the vulnerable part of the cryptographic library went through about 80 CC certification evaluations of level AVA VAN 4 (for TPMs) or AVA VAN 5 (for the others) from 2010 to 2024 (and a bit less than 30 certificate maintenances).
I provide you with a concluding paragraph from an article written by
Dan Goodin, Senior Security Editor at Ars Technica.
It feeds into the point of interest:
A key question that remains unanswered at the moment is what other security devices rely on the three vulnerable Infineon secure modules and use the Infineon cryptolibrary? Infineon has yet to issue an advisory and didn’t respond to an email asking for one. At the moment, there is no known CVE for tracking the vulnerability.
I’m ok with this idea, but having a nitrokey dev asking for it to be reinstated rather than a general community member does seem a little off to me.
Why?
Given that you work for nitrokey, perhaps amending this part would be good
Right. I just did.
I’m uncertain about the purpose of your post, but as far as I know we actually never removed Nitrokey from the recommendation list [1]. We could certainly revise the text to include the fact that the Nitrokey 3A is now FIDO certified, which is great news.
yes nitrokey was never removed from PG recommendations. There was just a suggestion thread started to consider removing nitrokey but it never got approved.
i haven’t studied the vulnerability in detail. but it appears to mostly affect infineons secure modules .
But Nitrokey does not use a secure element by infenion , so it shouldn’t affect their keys.
That’s correct, Nitrokey is not affected by this vulnerability. Here is our public statement about it.
I was under the wrong impression that Nitrokey was removed already.
In fact it would be good to mention the FIDO2 certification for Nitrokey 3A Mini.
More important I request the following corrections.
Nitrokey has a security key capable of FIDO2 and WebAuthn called the Nitrokey FIDO2. For PGP support, you need to purchase one of their other keys such as the Nitrokey Start, Nitrokey Pro 2 or the Nitrokey Storage 2.
Nitrokey FIDO2 is not available anymore. Nitrokey Start and Nitrokey Pro 2 are obsolete. Latest Nitrokey 3 and Nitrokey Passkey both support FIDO2 and WebAuthn. Nitrokey 3 also supports PGP. The text could be changed as follows:
Nitrokey has a security keys capable of FIDO2 and WebAuthn, OTP, PGP, and encrypted stored. For PGP support, you need to purchase Nitrokey 3 or Nitrokey Storage 2.
The following warning was right for the now obsolete Nitrokey Pro 2 but is not correct for current Nitrokey 3 anymore:
While Nitrokeys do not release the HOTP/TOTP secrets to the device they are plugged into, the HOTP and TOTP storage is not encrypted and is vulnerable to physical attacks. If you are looking to store HOTP or TOTP secrets, we highly recommend that you use a YubiKey instead.
For Nitrokey 3, all credentials are encrypted with hardware key and optionally PIN-protected credentials are encrypted with PIN additionally. I suggest to remove the entire warning and not discuss implementation details for simplicity reasons.
The link to the comparison table has been moved to: Nitrokeys | Nitrokey