Yubikeys are compromised due to the microcontroller used

Nitrokeys
1

Just curious what microcontrollers are used in nitrokeys (nitrokey passkey) and if we are impacted in anyway?

" The cryptographic flaw, known as a side channel, resides in a small microcontroller used in a large number of other authentication devices, including smartcards used in banking, electronic passports, and the accessing of secure areas. While the researchers have confirmed all YubiKey 5 series models can be cloned, they haven’t tested other devices using the microcontroller, such as the SLE78 made by Infineon and successor microcontrollers known as the Infineon Optiga Trust M and the Infineon Optiga TPM. The researchers suspect that any device using any of these three microcontrollers and the Infineon cryptographic library contains the same vulnerability."

2 Likes
2

The secure element of Nitrokey 3 is a SE050 from NXP. The main MCU is either a NRF52 or LPC55S6x type processor.

Nitrokey passkey is based on the Nitrokey 3 platform.

Basic MCU shared for multiple Nitrokey types (Pro, Start, HSM) that is used e.g. as card reader is the STM32F103R8T6 (for interacting with the secure element on a smartcard). The Nitrokey Start does not hold a separate smartcard.

The smartcard in the HSM were once based on A700x from NXP (around 2017) and are now most likely using similar successor chips that offer a JCOP Javacard runtime and are considered current by the vendor.

See here a previous statement that no Infinion chips are used.

Protecting against sidechannel attacks is very difficult.

2 Likes
3

See also our public statement about this.

1 Like
4

And from Niibe Yutaka there was also a statement that translates to the Nitrokey Start:

This week, I heard of YSA-2024-03.

In general, EdDSA is considered safe, because modular inversion is
usually done by computing number^(p-2) or using safegcd.

For Gnuk 2.2, I implemented safegcd256 for Ed25519 and Curve25519.

On the edge of Curve25519 (safegcd256 for 32-bit machine)

AFAIK, the implementation of mod_inv (which is used for ECDSA on
secp256k1) in Gnuk is OK if MCU core is not good enough with dynamic
branch prediction. If it’s not the case, we will be able to use
safegcd256 for secp256k1, since code is there.

5

Researchers at NinjaLabs discovered the attack. This sophisticated attack leverages a cryptographic bug, known as a side-channel attack, present in a tiny chip – the Infineon SLE78 – within the key. The process requires physical access to the key, disassembling it using solvents or a hot air gun, connecting the chip to $11,000 worth of equipment, and extracting private keys from the key.

To gain access to the key owner’s accounts, the attacker would also need usernames, account passwords, PIN codes, or any other authentication keys used to secure the account.

6

It is not that particular flaw that may not be easy to pull off. But gaining access to a hardware token secret key can be considered a full breach - albeit that here it is only for the individual token and not a series of keys. And the fact that code that is developed by security professionals from Infinion do not consider same execution time for cryptographic tokens. They should know better.