Security Advisory YSA-2024-03 (2025)

Security Advisory YSA-2024-03 Infineon ECDSA Private Key Recovery

Published Date: 2024-09-03
Tracking IDs: YSA-2024-03
CVE: In Process
CVSS Severity: 4.9

Summary

A vulnerability was discovered in Infineon’s cryptographic library, which is utilized in YubiKey 5 Series, and Security Key Series with firmware prior to 5.7.0 and YubiHSM 2 with firmware prior to 2.4.0. The severity of the issue in Yubico devices is moderate.

An attacker could exploit this issue as part of a sophisticated and targeted attack to recover affected private keys. The attacker would need physical possession of the YubiKey, Security Key, or YubiHSM, knowledge of the accounts they want to target, and specialized equipment to perform the necessary attack. Depending on the use case, the attacker may also require additional knowledge including username, PIN, account password, or authentication key. See Affected Use Cases and Mitigations for more details.

The moderate vulnerability primarily impacts FIDO use cases because the FIDO standard relies on the affected functionality by default. YubiKey PIV and OpenPGP applications and YubiHSM 2 usage may also be impacted depending on configuration and algorithm choices by the end user.

As part of ongoing improvements in Yubico products and to reduce exposure to our supply chain, the dependency on Infineon’s cryptographic library has been removed in favor of Yubico’s own cryptographic library.

For more details by use case, see Affected Use Cases below:

Not Affected Products

YubiKey 5 Series version 5.7.0 and newer

YubiKey 5 FIPS Series 5.7 and newer (FIPS submission in process)

YubiKey Bio Series versions 5.7.2 and newer

Security Key Series versions 5.7.0 and newer

YubiHSM 2 versions 2.4.0 and newer

YubiHSM 2 FIPS versions 2.4.0 and newer

Affected

YubiKey 5 Series versions prior to 5.7

YubiKey 5 FIPS Series prior to 5.7

YubiKey 5 CSPN Series prior to 5.7

YubiKey Bio Series versions prior to 5.7.2

Security Key Series all versions prior to 5.7

YubiHSM 2 versions prior to 2.4.0

YubiHSM 2 FIPS versions prior to 2.4.0

How To Tell If You Are Affected

Identify YubiKey Version

To identify the YubiKey, use Yubico Authenticator to identify the model and version of the YubiKey. The series and model of the key will be listed in the upper left corner of the Home screen. In the following example, the YubiKey is a YubiKey 5C NFC version 5.7.0.

Identify YubiHSM 2 Version

Using the YubiHSM SDK, connect to the YubiHSM 2 and use the get deviceinfo command with the following steps:

$ yubihsm-connector -d

$ yubihsm-shell

$ yubihsm> connect

$ yubihsm> get deviceinfo

Affected Use Cases and Mitigations

This issue is a side-channel vulnerability in the ECDSA implementation in the Infineon cryptographic library. In the YubiKey and YubiHSM, ECDSA is used for generating cryptographic signatures based on elliptic curves. ECDSA is heavily used in FIDO, however this could also impact PIV and OpenPGP use cases if ECC keys are used. YubiHSM 2 signing and attestation may also be impacted if ECC keys are used.

A sophisticated attacker could use this vulnerability to recover ECDSA private keys. An attacker requires physical possession and the ability to observe the vulnerable operation with specialized equipment to perform this attack. In order to observe the vulnerable operation, the attacker may also require additional knowledge such as account name, account password, device PIN, or YubiHSM authentication key.

YubiKey FIDO

Authentication

An attacker with physical possession of the YubiKey could recover FIDO credentials.

In order to exploit this issue against credentials made with strict user verification requirements via credential protection policy userVerificationRequired, an attacker would also need to have possession of the user verification (UV) factor as well (i.e. PIN or biometric).

In order to exploit this issue against credentials made with credential protection policy userVerificationOptionalWithCredentialIDList would require either the user verification factor (PIN or biometric) or the FIDO credentialID. The FIDO credentialID can be obtained by observing a relying party prompt for the YubiKey credential. For example, if a relying party requires username, password, and a FIDO credential, the attacker would need username and password in order to proceed far enough into the authentication workflow to discover the FIDO credentialID. However, if a relying party only requires username before prompting for a FIDO credential, then an attacker only needs the username in order to discover the FIDO credentialID.

Organizations may consider using identity provider settings to lessen session length and require more frequent FIDO authentication. Frequent usage of the YubiKey can help identify lost or stolen YubiKeys more quickly and reduce the window of exposure for attackers in the event of a lost or stolen YubiKey.

For more details around FIDO controls, see the related support article.

Attestation

Attestation is built-in to the FIDO and WebAuthn protocols. This feature enables each relying party to use a cryptographically verified chain of trust from the device’s manufacturer to choose which security keys to trust. This feature is shown as allow lists and disallow lists of AAGUIDs in an identity provider that may be customizable for organizations.

An attacker could exploit this issue to create a fraudulent YubiKey using the recovered attestation key. This would produce a valid FIDO attestation statement during the make credential resulting in a bypass of an organization’s authenticator model preference controls for affected YubiKey versions.

Organizations relying on FIDO attestation to ensure genuine YubiKeys are in use may consider supplementing FIDO login with other credentials such as YubiOTP or RSA attestation statements from PIV or OpenPGP. For more information about FIDO attestation and detailed instructions, see the related support article.

YubiKey PIV and OpenPGP

Signing

An attacker could duplicate elliptic curve signing keys. For PIV signing keys, the attacker requires a PIN to perform and observe a signing operation. The attacker may require the PIN in the OpenPGP use case depending on the OpenPGP PIN configuration.

Users can mitigate by using RSA or ed25519 signing keys. For more information about PIV and OpenPGP configuration options as well as detailed instructions, see the related support article.

Attestation

YubiKeys are all made with a PIV attestation certificate and a separate OpenPGP attestation certificate. These are signed by Yubico CAs and can be used to produce a cryptographic statement that a PIV or OpenPGP key was created on the YubiKey. By default both the PIV attestation certificate and OpenPGP attestation certificate are RSA keys, if a user has replaced the key(s) with their own elliptic curve key(s), an attacker could produce a valid attestation statement for a key made outside of the YubiKey. The attacker does not require the PIN to perform and observe an attestation operation.

Users can mitigate by using RSA attestation certificates.

YubiHSM

For all YubiHSM cases, the attacker would also require an authentication key that has the appropriate capabilities to perform signing actions with the affected elliptic curve key.

There are authentication methods available on the YubiHSM 2. One is using a password and the other is using YubiHSM Auth which stores an authentication key in a YubiKey. Authenticating to a YubiHSM with either method does not rely on ECDSA and is unaffected by this issue.

For more information about HSM configuration and detailed instructions, see the related support article.

Signing

An attacker could duplicate elliptic curve signing keys. The attacker would need to be able to authenticate to the HSM with sufficient capabilities to perform signing actions.

Users can mitigate by using RSA or ed25519 signing keys.

Attestation

If a user is attesting with their own elliptic curve key instead of the Yubico provided YubiHSM attestation key an attacker could produce a valid attestation statement for a key made outside of the YubiHSM. The attacker requires an authentication key with sign attestation capabilities to perform and observe an attestation operation.

Users can mitigate by using RSA attestation certificates.

Support Article: https://support.yubico.com/hc/en-us/articles/15705749884444

Research: https://ninjalab.io/eucleak/

Yubico has rated this issue as Moderate. It has a CVSS score of 4.9

On April 19, 2024, Dr. Thomas Roche from NinjaLab notified Yubico of this security issue. We thank them for reporting it and working with us under coordinated vulnerability disclosure.

Timeline

Are all of Yubico’s devices affected?

No. Our latest YubiKey 5 Series and Security Key Series, which started shipping on May 21, 2024 are not affected by Infineon’s cryptographic library vulnerability. These devices come with the new 5.7 firmware, which contains Yubico’s own cryptographic library. This means that the vulnerability discovered in Infineon’s library does not impact these new devices in any way.

How easy is this vulnerability to exploit?

It’s important to note that while the vulnerability exists in previous YubiKey series, exploiting it is complex. According to the researchers, any attempt to exploit this vulnerability would require significant resources and knowledge. The attacker would need physical possession of the YubiKey, Security Key, or YubiHSM, knowledge of the accounts they want to target, and specialized equipment to perform the necessary attack. Depending on the use case, the attacker may also require additional knowledge including username, PIN, account password, or authentication key.

Even with this potential risk, by maintaining possession of your YubiKey and if it is lost or stolen, deregistering it promptly from applications and services that it is registered with, you effectively mitigate this vulnerability.

Is FIDO authentication still recommended over other authentication methods like OTP or SMS?

Yes, FIDO remains the strongest, most phishing-resistant authentication protocol available. Both Yubico and the researchers who discovered this vulnerability strongly recommend the continued use of FIDO authenticators over weaker authentication methods like OTP or SMS. Using a YubiKey remains significantly safer than not using one at all.

What should I do if my YubiKey is lost or stolen?

To maximize security, we advise all users to take precautions to maintain physical control of their YubiKeys. If your YubiKey is ever lost or stolen, promptly deregister the key from all associated applications and services. This is an effective way to immediately mitigate risks associated with this type of vulnerability. This also supports the best practice of having both a primary and a backup key.

Why doesn’t Yubico allow firmware updates for its devices?

We understand there are questions about why Yubico does not allow firmware updates for our keys. We believe that not allowing firmware updates is the best practice to maximize the security of your keys. Firmware updates, while potentially convenient, can introduce new vulnerabilities. By preventing firmware updates, we ensure that your firmware remains secure from the moment it is programmed. More details on our position can be found in our knowledge base article, which we encourage you to read for a deeper understanding.

Where do the FIPS keys fit into this scenario?

As with other YubiKey models, for current FIPS devices, we similarly advise to take precautions to maintain physical control of your YubiKeys and promptly deregister the key from all associated applications and services if lost or stolen.

Will Yubico be doing a key replacement program?

As this risk has been rated as “moderate” according to the Common Vulnerability Scoring System (CVSS) and as maintaining possession of your YubiKey and deregistering it promptly if it is lost or stolen, can effectively mitigate this risk, we do not have an active key replacement program. If you have concerns about your YubiKey, please reach out to our customer support team, and we will do our best to address your needs in a timely manner.