However, Google says attack doesn’t materially undermine Titan’s remote access protection
A new side-channel attack exploiting a vulnerability in NXP chipsets can be used to clone Google Titan Security Keys.
On January 7, Ninjalab’s Victor Lomné and Thomas Roche published a research paper, ‘A Side Journey to Titan’ (PDF), which explores how an attack can be launched against NXP A7005a chips to extract private keys and clone security devices.
Tracked as CVE-2021-3011, the vulnerability is described as an “electromagnetic-wave side-channel issue” that allows attackers to “extract the ECDSA private key after extensive physical access (and consequently produce a clone)”.
Read more of the latest authentication news
Lomné and Roche demonstrated the security flaw on the Google Titan Security key, a FIDO U2F hardware device designed to implement two-factor authentication (2FA) through the generation of a cryptographic token in order to verify the legitimacy of a user, thus preventing phishing and account takeovers.
A remote attack would have severe ramifications for 2FA hardware products. However, it is important to note that a threat actor must have physical access to a Titan device to perform the side-channel attack.
Radiation patterns
Google Titan’s secure element, the NXP A700X chip, was the subject of the research. After peeling away the Titan’s protective case, the team examined the NXP hardware and observed the electromagnetic radiation expelled during ECDSA signatures, a key element of FIDO U2F cryptographic protocols.
Custom software and algorithms were developed by the team to pick apart patterns in the hardware’s local radiation when authentication requests were made by the device, leading to the leak of partial ECDSA key information.
It took 6,000 observations for the successful extraction of a ECDSA private key linked to a Google Titan FIDO U2F account, allowing the device to be cloned.
Yubico’s YubiKey NEO and FEITIAN devices were also found to be vulnerable to the technique – albeit a costly and time-consuming endeavor.
Each attack would only relate to a single target application, and a threat actor would not only need to probe the Google Titan key for at least several hours, but would also need to know the target account’s standard username and password credentials to access an app or service.
Mitigating factors
The Google Titan attack was validated in July 2020. Google and other vendors were alerted to the research and given technical details on October 1.
On October 21, the Google Vulnerability Reward Program (VRP) acknowledged the research and gave the cybersecurity team an “honorable mention” in the Hall of Fame but no financial reward.
According to Google, as the attack relies on a microcontroller package which is not owned by the company, the research is “technically out of scope” for Google VRP.
YOU MIGHT ALSO LIKE CrackQ tool adds GUI, analysis features to Hashcat password-cracking platform
In addition, the tech giant says that this form of attack not only requires expensive equipment, physical access to a device, considerable technical skills, and custom software, but also does not materially undermine Titan’s core purpose: to provide an additional layer of security against remote attacks.
Moreover, should a key be successfully cloned using this method, the use counters of both the original and cloned keys would diverge, and this activity would be detected on the firm’s login server, preventing successful cryptographic key cloning.
The researchers still recommend using Google Titan and associated products including FIDO U2F to bolster 2FA security, as having authentication tokens in place is still an improvement on not using them at all.
Speaking to The Daily Swig, Roche said that the study of products being actively used in our daily lives is “important” to France-based Ninjalab as it forces us to connect security issues in “theory and practice.
“We hope our work improves awareness that U2F security keys are not something we should blindly rely on,” he added.
Over on Twitter, Steven Murdoch, professor of security engineering at University College London, lauded the research but said it was “irrelevant for the vast majority of users”.
However, “it would be a risk if the attacker can get temporary physical access to a token, but then wants to covertly turn that temporary access into permanent access,” he added. “If that’s a concern, be very careful how you store your token”.
RELATED LadderLeak: Side-channel security flaws exploited to break ECDSA cryptography
