Hackers can clone Google Titan 2FA keys using a side channel in NXP chips
There’s wide consensus among security experts that physical two-factor authentication keys provide the most effective protection against account takeovers. Research published today doesn’t change that thinking, but it does show how malicious attackers with physical possession of a Google Titan key can clone it.
There are some steep hurdles to clear for an attack to be successful. A hacker would first have to steal a target’s account password and also gain covert possession of the physical key for as many as 10 hours. The cloning also requires up to $12,000 worth of equipment and custom software, plus an advanced background in electrical engineering and cryptography. That means the key cloning—were it ever to happen in the wild—would likely be done only by a nation-state pursuing its highest-value targets.
“Nevertheless, this work shows that the Google Titan Security Key (or other impacted products) would not avoid [an] unnoticed security breach by attackers willing to put enough effort into it,” researchers from security firm NinjaLab wrote in a research paper published Thursday. “Users that face such a threat should probably switch to other FIDO U2F hardware security keys, where no vulnerability has yet been discovered.”
The 2FA gold standard
Two-factor authentication, or 2FA, is a method that makes account takeovers much harder to pull off. Instead of using only a password to prove someone is authorized to access an account, 2FA requires a second factor, such as a one-time password, possession of a physical object, or a fingerprint or other biometric.
Physical keys are among the—if not the—most secure forms of 2FA because they store the long-term secret that makes them work internally, and only output non-reusable values. The secret is also impossible to phish. Physical keys are also more convenient, since they work on all major operating systems and hardware.
The Titan vulnerability is one of the only weaknesses ever to be found in a mainstream 2FA key. However improbable, a successful real-world exploit would completely undermine the security assurances the thumb-size devices provide. The NinjaLab researchers are quick to point out that despite the weakness, it’s still safer to use a Titan Security Key or another affected authentication device to sign in to accounts than not to.
Attack of the clones
The cloning works by using a hot air gun and a scalpel to remove the plastic key casing and expose the NXP A700X chip, which acts as a secure element that stores the cryptographic secrets. Next, an attacker connects the chip to hardware and software that take measurements as the key is being used to authenticate on an existing account. Once the measurement-taking is finished, the attacker seals the chip in a new casing and returns it to the victim.
-
The extracted Titan printed circuit board and one part of the casing.
-
Recto of a Titan PCB.
-
Verso of the Titan PCB.
-
“We first protected the PCB by sticking some aluminium tape around it and cut a square just above the NXP A7005a package. Then we warmed some fuming nitric acid and put carefully some drops of acid on the package, until we see the die appear.” This figure depicts the result.
-
The side-channel analysis platform used in this study.
-
The spatial position of the EM probe above the die of the Titan NXP A7005a.
Extracting and later resealing the chip takes about four hours. It takes another six hours to take measurements for each account the attacker wants to hack. In other words, the process would take 10 hours to clone the key for a single account, 16 hours to clone a key for two accounts, and 22 hours for three accounts.
By observing the local electromagnetic radiations as the chip generates the digital signatures, the researchers exploit a side channel vulnerability in the NXP chip. The exploit allows an attacker to obtain the long-term elliptic curve digital signal algorithm private key designated for a given account. With the crypto key in hand, the attacker can then create her own key, which will work for each account she targeted.
Paul Kocher, an independent cryptography expert with no involvement in the research, said that while the real-world risk of the attack is low, the side-channel discovery is nonetheless important, given the class of users—dissidents, lawyers, journalists, and other high-value targets—who rely on it and the possibility that attacks will improve over time.
“The work is notable because it’s a successful attack against a well-hardened target designed for high-security applications, and clearly breaks the product’s security characteristics,” he wrote in an email. “A real adversary might well be able to refine the attack (e.g., shortening the data collection time and/or removing the need to physically open the device). For example, the attack might be extendable to a token left in a hotel gym locker for an hour.”
Doing the impossible
Indeed, the Google Titan, like other security keys that use the FIDO U2F standard, is supposed to make it impossible to transfer crypto keys and signatures off the device, as the NinjaLab researchers noted:
As we have seen, the FIDO U2F protocol is very simple, the only way to interact with the U2F device is by registration or authentication requests. The registration phase will generate a new ECDSA key pair and output the public key. The authentication will mainly execute an ECDSA signature operation where we can choose the input message and get the output signature.
Hence, even for a legitimate user, there is no way to know the ECDSA secret key of a given application account. This is a limitation of the protocol which, for instance, makes [it] impossible to transfer the user credentials from one security key to another. If a user wants to switch to a new hardware security key, a new registration phase must be done for every application account. This will create new ECDSA key pairs and revoke the old ones.
This limitation in functionality is a strength from a security point-of-view: by design it is not possible to create a clone. It is moreover an obstacle for side-channel reverse-engineering. With no control whatsoever on the secret key it is barely possible to understand the details of (let alone to attack) a highly secured implementation. We will have to find a workaround to study the implementation security in a more convenient setting.
Risk assessment
Despite describing a way to compromise the security of a key Google sells, the research won’t receive a payment under Google’s bug bounty program, which provides rewards to hackers who discover security flaws in Google products or services and privately report them to the company. A Google spokeswoman said that attacks that require physical possession are out of scope of the company’s security key threat model. She also noted the difficulty and expense in carrying out an attack.
While the researchers performed their attack on the Google Titan, they believe that other hardware that uses the A700X, or chips based on the A700X, may also be vulnerable. If true, that would include Yubico’s YubiKey NEO and several 2FA keys made by Feitian.
In an email, Yubico spokeswoman Ashton Miller said the company is aware of the research and believes its findings are accurate. “While the researchers note that physical device access, expensive equipment, custom software, and technical skills are required for this type of attack, Yubico recommends revoking access for a lost, stolen, or misplaced YubiKey NEO to mitigate risk,” she wrote.
In a statement, NXP officials wrote:
NXP is aware of the report and appreciates the co-operation of the researchers. Since October 2020 we have actively communicated to the majority of potentially affected customers and given them the opportunity to discuss with our security experts. This effort is almost completed. We encourage customers to complete their own risk assessment for their systems and applications that use the affected products. The root cause cannot be fixed in the affected products. However, there are use-cases where countermeasures may be applied on system level. Newer generations of these products with additional countermeasures are available.
Representatives from Feitian weren’t immediately available for comment.
One countermeasure that can partially mitigate the attack is for service providers that offer key-based 2FA to use a feature baked into the U2F standard that counts the number of interactions a key has had with the provider’s servers. If a key reports a number that doesn’t match what’s stored on the server, the provider will have good reason to believe the key is a clone. A Google spokeswoman said the company has this feature.
The research—from Ninjalab co-founders Victor Lomné and Thomas Roche in Montpellier, France—is impressive, and in time, it’s likely to result in the side-channel vulnerability being fixed. In the meantime, the vast majority of people using an affected key should continue doing so, or at the very most, switch to a key with no known vulnerabilities. The worst outcome from this research would be for people to stop using physical security keys altogether.
Post updated to add comment from NXP.