[YubiKey/YubiHSM] Security Advisory YSA-2024-03 Infineon ECDSA Private Key Recovery

For anyone using the Yubico tokens :-)

https://www.yubico.com/support/security-advisories/ysa-2024-03/

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.

Additional Resources

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

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

Severity

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

Acknowledgements

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, 2024Yubico releases YubiKey 5.7
September 2, 2024Yubico announces YubiHSM 2.4
September 3, 2024Yubico releases advisory YSA-2024-03


-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info