Infineon’s Cryptographic Library Suffers From An ECDSA Private Key Recovery Vulnerability
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 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 and using OpenPGP options to require PIN for signing.
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 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
| April 19, 2024 | NinjaLab informs Yubico of their research |
| May 21, 2024 | Yubico releases YubiKey 5.7 |
| September 2, 2024 | Yubico announces YubiHSM 2.4 |
| September 3, 2024 | Yubico releases advisory YSA-2024-03 |
READ MORE HERE