There’s wide consensus among security experts that physical two-factor authentication keys provide the foremost effective protection against account takeovers. Research published today doesn’t change that, 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 need to steal a target’s account password and to also gain covert possession of the physical key for as many as 10 hours. The cloning also requires up to $ 12,000 worth of kit , custom software, and a complicated background in EE 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) wouldn’t avoid [an] unnoticed security breach by attackers willing to place 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, may be a method that creates account takeovers much harder to tug 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 also are 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 means that despite the weakness, it’s still safer to use a Titan Security Key or another affected authentication device to check in to accounts than not to.
Attack of the clones
The cloning works by employing a hot air gun and a scalpel to get rid of 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 takes measurements as it is being registered to work with a new 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 computer circuit board and one a 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 carefully put some drops of acid on the package, until we saw 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 get 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 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 may be a strength from a security point-of-view: intentionally it’s impossible to make a clone. It is moreover an obstacle for side-channel reverse-engineering. With no control whatsoever on the key key it’s barely possible to know the small print 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 corporate . A Google spokeswoman said that attacks that need 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 might include Yubico’s YubiKey NEO and a number of other 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.
Representatives from chipmaker NXP and Feitian weren’t immediately available for comment.
One countermeasure which will partially mitigate the attack is for service providers that provide key-based 2FA to use a feature baked into the U2F standard that counts the amount 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 corporation 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 end 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.
