2fa

yubikeys-are-vulnerable-to-cloning-attacks-thanks-to-newly-discovered-side-channel

YubiKeys are vulnerable to cloning attacks thanks to newly discovered side channel

ATTACK OF THE CLONES —

Sophisticated attack breaks security assurances of the most popular FIDO key.

YubiKeys are vulnerable to cloning attacks thanks to newly discovered side channel

Yubico

The YubiKey 5, the most widely used hardware token for two-factor authentication based on the FIDO standard, contains a cryptographic flaw that makes the finger-size device vulnerable to cloning when an attacker gains brief physical access to it, researchers said Tuesday.

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.

Patching not possible

YubiKey-maker Yubico issued an advisory in coordination with a detailed disclosure report from NinjaLab, the security firm that reverse-engineered the YubiKey 5 series and devised the cloning attack. All YubiKeys running firmware prior to version 5.7—which was released in May and replaces the Infineon cryptolibrary with a custom one—are vulnerable. Updating key firmware on the YubiKey isn’t possible. That leaves all affected YubiKeys permanently vulnerable.

“An attacker could exploit this issue as part of a sophisticated and targeted attack to recover affected private keys,” the advisory confirmed. “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.”

Side channels are the result of clues left in physical manifestations such as electromagnetic emanations, data caches, or the time required to complete a task that leaks cryptographic secrets. In this case, the side channel is the amount of time taken during a mathematical calculation known as a modular inversion. The Infineon cryptolibrary failed to implement a common side-channel defense known as constant time as it performs modular inversion operations involving the Elliptic Curve Digital Signature Algorithm. Constant time ensures the time sensitive cryptographic operations execute is uniform rather than variable depending on the specific keys.

More precisely, the side channel is located in the Infineon implementation of the Extended Euclidean Algorithm, a method for, among other things, computing the modular inverse. By using an oscilloscope to measure the electromagnetic radiation while the token is authenticating itself, the researchers can detect tiny execution time differences that reveal a token’s ephemeral ECDSA key, also known as a nonce. Further analysis allows the researchers to extract the secret ECDSA key that underpins the entire security of the token.

In Tuesday’s report, NinjaLab co-founder Thomas Roche wrote:

In the present work, NinjaLab unveils a new side-channel vulnerability in the ECDSA implementation of Infineon 9 on any security microcontroller family of the manufacturer.This vulnerability lies in the ECDSA ephemeral key (or nonce) modular inversion, and, more precisely, in the Infineon implementation of the Extended Euclidean Algorithm (EEA for short). To our knowledge, this is the first time an implementation of the EEA is shown to be vulnerable to side-channel analysis (contrarily to the EEA binary version). The exploitation of this vulnerability is demonstrated through realistic experiments and we show that an adversary only needs to have access to the device for a few minutes. The offline phase took us about 24 hours; with more engineering work in the attack development, it would take less than one hour.

After a long phase of understanding Infineon implementation through side-channel analysis on a Feitian 10 open JavaCard smartcard, the attack is tested on a YubiKey 5Ci, a FIDO hardware token from Yubico. All YubiKey 5 Series (before the firmware update 5.7 11 of May 6th, 2024) are affected by the attack. In fact all products relying on the ECDSA of Infineon cryptographic library running on an Infineon security microcontroller are affected by the attack. We estimate that the vulnerability exists for more than 14 years in Infineon top secure chips. These chips and the vulnerable part of the cryptographic library went through about 80 CC certification evaluations of level AVA VAN 4 (for TPMs) or AVA VAN 5 (for the others) from 2010 to 2024 (and a bit less than 30 certificate maintenances).

YubiKeys are vulnerable to cloning attacks thanks to newly discovered side channel Read More »

loss-of-popular-2fa-tool-puts-security-minded-grapheneos-in-a-paradox

Loss of popular 2FA tool puts security-minded GrapheneOS in a paradox

Just a bit too custom for their taste —

Losing access to Authy leads to another reckoning with Google’s security model.

Scientist looking at a molecular model of graphene in a laboratory

Enlarge / Graphene is a remarkable allotrope, deserving of further study. GrapheneOS is a remarkable ROM, one that Google does not quite know how to accommodate, due to its “tiny, tiny” user numbers compared to mainstream Android.

“If it’s not an official OS, we have to assume it’s bad.”

That’s how Shawn Wilden, the tech lead for hardware-backed security in Android, described the current reality of custom Android-based operating systems in response to a real security conundrum. GrapheneOS users discovered recently that Authy, a popular (and generally well-regarded) two-factor authentication manager, will not work on their phones—phones running an OS intended to be more secure and hardened than any standard Android phone.

“We don’t want to punish users of alternative OSes, but there’s really no other option at the moment,” Wilden added before his blunt conclusion. “Play Integrity has absolutely no way to guess whether a given custom OS completely subverts the Android security model.”

Play Integrity, formerly SafetyNet Attestation, essentially allows apps to verify whether an Android device has provided permissions beyond Google’s intended models or has been rooted. Root access is not appealing to the makers of some apps involving banking, payments, competitive games, and copyrighted media.]

There are many reasons beyond cheating and skulduggery that someone might root or modify their Android device. But to prove itself secure, an Android device must contact Google’s servers through an API in Google Play Services and then have its bootloader, ROM signature, and kernel verified. GrapheneOS, like most custom Android ROMs, does not contain a Google Play Services package by default but will let users install a sandboxed version of Play Services if they wish.

Wilden offered some hope for a future in which ROMs could vouch for their non-criminal nature to Google, noting “some discussions with makers of high-quality ROMs” about passing the Compatibility Test Suite, then “establishing some kind of relationship we can use to trust them.” But it’s “a lot of work on both sides, including by lawyers,” Wilden notes. And while his team is happy to help, higher-level support is tough because “modders are such a tiny, tiny fraction of the user base.”

The official GrapheneOS X account was less hopeful. It noted that another custom ROM, LineageOS, disabled verified boot at installation, and “rolls back security in a lot of other ways,” contributing to “a misconception that every alternate OS rolls back security and isn’t production quality.” A typical LineageOS installation, like most custom ROMs, does disable verified boot, though it can be re-enabled, except it’s risky and complicated. GrapheneOS has a page on its site regarding its stance on, and criticisms of, Google’s attestation model for Android.

Ars has reached out to Google, GrapheneOS, and Authy (via owner Twilio) for comment. At the moment, it doesn’t seem like there’s a clear path forward for any party unless one of them is willing to majorly rework what they consider proper security.

Loss of popular 2FA tool puts security-minded GrapheneOS in a paradox Read More »