On the 3rd of September, Yubico announced YSA-2024-03, a vulnerability in the infineon cryptograhpic library which may allow private key extraction to be performed. As is tradition, arm chair experts and thought leaders everywhere rushed to have hot takes on the situation, without adequately understanding the way that the attack works and how it fits into Webauthn on a technical level.
TL;DR - Do I Need To Worry
No. This attack while cool as heck, is not a risk to the majority of yubikey users.
But I write opensource code, I'm a target of NSA/ASIO/MI5/Obsidian Order surveillence
No you aren't, keep using your yubikeys.
The Attack
Let's examine yubicos statement about the attack.
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.
Wow, that's pretty scary. Private keys can be recovered from our secure key hardware! The attacker only needs possession! Think of the evil maid's getting excited to perform this attack right now!
This statement sadly on the part of Yubico is vague to the details of how the attack is carried out and this affects people's ability to perform adequate risk assessment.
The details are buried in the eucleak paper, but the attacker requires:
- The private key must be ECDSA (the default for Webauthn/FIDO2)
- Physical access to the yubikey
- Knowledge of the users PIN
- The ability to disassemble the key
- Specialised equipment to recover the keys
From this, there are four key defences that you still have:
- Your PIN
Without knowing your PIN, the keys can not be recovered. The recovery can only be performed during a signature operation using the key which requires your PIN for each operation.
The authors of the eucleak paper note this:
When this is possible activate all defense layers, e.g. enforce the use of a PIN (or any biometrics) to access to the device.
Provided that the websites you have used your key with enforce user verification (aka a PIN) then the key would be impossible te recover without this. Yubikeys natively have PIN bruteforce protections to prevent and limit the ability of at attacker to attempt to steal your PIN, even with possession.
- The Attack Is Destructive
To carry out the attack, the yubikey needs to be taken apart or drilled open. It's extremely obvious when someone carries this out, and only a highly resourced, motivated, and skilled attacker could consider repairing the key in such a way to mask the subterfuge.
- The Attack Requires Possession
The attacker needs physical access to the key for approximately one hour to carry out the attack, and that is excluding the possible time to repair the damaged key case post attack.
- The Attack Targets ECDSA Keys - Not the Master Key
Every website that you enroll your yubikey to as a device has a unique private key associated to it. While this attack can retrieve the private key, this only allows the attacker to recover one private key at a time, which requires the key to be a resident key, or the attacker needs the CredentialID associated to this yubikey to proceed. Each CredentialID is protected by a device master key and so extraction of one private key only compromises the one target site - not every credential the key has ever issued.
In addition of the attacker is targetting a website that may be behind a VPN, they may not be able to capture the CredentialID in the place to allow the attack to proceed. In some cases the CredentialID may be behind a pre-auth (such as a password auth) step which also prevents the attacker accessing the CredentialID needed for the private key attack to begin at all.
Threat Model - Consumer Device
So now knowing this what is the risk to the average consumer?
Given the need for your PIN, physical access, and the attack being destructive, it's unlikely that anyone will carry out this attack without a high value target and reason.
Another way to frame this, is that there are very few persons in the world who would be worth the expenditure in resources to conduct a targetted against in this manner. And if the attacker is already in possession of the device and your PIN, in most cases the need to execute this attack aren't required since the attacker can simply sign in to your account and then steal the session cookies or whatever else.
Finally, the authors of the paper even state:
Let us emphasize here that we strongly encourage to continue to use an EUCLEAK vulnerable product rather than switching to a solution that does not involve a secure element.
Side Quest - Attestation
As a refresher, lets talk about what attestation is.
When you enroll a security key to a website, that website has no knowledge about your key. In fact all that website sees (in simple versions) is a public key and some boolean flags describing true/false if you touched the device during the signature, and if you entered a PIN or biometric when you used the device.
Yes, that's right, when you enter your PIN to your security key, that stays local on the key and all the remote website sees is a "promise, I actually did check the PIN, you can trust me".
This means someone could easily just make a software key that sends the user-presence and user-verification flags, even if they didn't actually validate them or enforce presence or verification (looking at you password managers).
In most cases though this isn't a problem - the use of cryptographic authentication for the user is a significant improvement over the use of passwords and/or other factors. If a user chooses to do a silly and make a fake-cereal-box key, that's on them to accept the finding out of their fucking around.
But in other places, we can not afford to find out. There may be regulations or rules that enforce policies that must be adhered to for a number of reasons.
For this reason we need a way to signal to the website not just that we have "a security key" but that we have a precise make and model of key, that conforms to a set of guaranteed properties. To achieve this, security keys support a process called attestation which provides a cryptographic proof that the key is a specific make and model.
This allows a website to trust a certificate authority (such as the Yubico CA) and when the key is enrolled it uses it's attestation key to sign the public key as we enroll our key to the website. The website can then trace the trust chain back cryptographically to the Yubico CA and have a strong proof that the key being enrolled must be a legitimate yubikey.
THreat Model - Attestation
So now with our eucleak attack, this does have an impact on sites that enforce attestation. This is because a yubikeys attestation key can now be extracted from a legitimate device that is in the attackers possession. Using the extracted attestation key, we can now sign any key as though it came from a real yubikey. Your password manager could cosplay cryptographically as a yubikey for example.
This has implications on sites that do require strict attestation as it is now possible that someone may attempt to enroll "I can't believe it's not a yubikey" to an account, bypassing the expected security controls.
There are still limited use cases for this, but the primary would be enrolling an attacker controlled exportable key to an account, while retaining the appearance of it being a legitimate yubikey.
NOTE: This does not affect PIV/SmartCard attestation by default since smartcard attestation in yubikeys uses an RSA attestation key instead of an ECDSA one. If you have enrolled your own attestation key that uses ECDSA then this can be extracted, but again falls into the categories above regarding the need for possession and destruction of the key.
Conclusion
While this attack is novel and super technically cool in a spy thriller move heist kind of way, for most yubikey users there is minimal risk to your keys.
The risks that do exist are to organisations with high security assurance needs which rely on attestation, as the trust in attestation provided by the device may now come into question in some circumstances.