New Side-Channel Attack Can Recover Encryption Keys From Google Titan Security Keys (zdnet.com) 31
A duo of French security researchers has discovered a vulnerability impacting chips used inside Google Titan and YubiKey hardware security keys. From a report: The vulnerability allows threat actors to recover the primary encryption key used by the hardware security key to generate cryptographic tokens for two-factor authentication (2FA) operations. Once obtained, the two security researchers say the encryption key, an ECDSA private key, would allow threat actors to clone Titan, YubiKey, and other keys to bypass 2FA procedures. However, while the attack sounds disastrous for Google and Yubico security key owners, its severity is not what it seems. In a 60-page PDF report, Victor Lomne and Thomas Roche, researchers with Montpellier-based NinjaLab, explain the intricacies of the attack, also tracked as CVE-2021-3011. For starters, the attack won't work remotely against a device, over the internet, or over a local network. To exploit any Google Titan or Yubico security key, an attacker would first need to get their hands on a security key in the first place.
So in other words... (Score:3)
Much stronger than a physical key (Score:5, Informative)
> It allows cloning of the key, just like a physical key does.
A physical key as typically uses for a door lock can be copied in a couple minutes. Cloning the U2F key takes ten hours. Also thousands of dollars of specialized equipment.
These hardware digital keys are significantly more secure than any brass key.
This attack is interesting mostly to specialists like myself - I'm working on designing the most secure 2FA system that can reasonably be deployed, and trying to determine if the most secure system you can do might be U2F compatible. For example I plan to physically blow certain fuses in the chip to make particular circuits physically unusable after the device is set up. It's not really a concern for users, unless that user is carrying the nuclear football or something.
Re: (Score:2)
Re: (Score:3)
Um....
Re: (Score:2)
Re: (Score:1)
Good for you for being confident. But. If I were you, my confidence in Google's security engineering skills would be considerably shaken. And that's just one announced exploit, how many others are there, not announced?
Re: (Score:2)
Re: (Score:2)
So Google gets a pass because oh who could have known?
As hot takes go, yours is pretty terrible.
Re: (Score:2)
So Google gets a pass because oh who could have known?
blah blah blah.
Google should stick to selling ads. The smart people left the building long ago. Security is well beyond the competency of any of the rest-and-vesters remaining at the smartplex.
Re: (Score:2)
This exploit doesn't help someone to gain access in any way that merely having the token wouldn't. This exploit is a problem when it comes to spy vs. spy, not cybercr
Re: (Score:2)
People might leave their 2FA keys in the office overnight - I know places that use 2FA, but the Yubikey was stuck in the machine as you were logging into and out of mach
so... (Score:2)
If you're arrested, crossing a border or otherwise lose physical control of the key, "they" own it.
Gotcha! No threats there!
If they physically have your key, they have your k (Score:2)
Yes, if you physically hand the key to someone and let them keep it overnight, they have your key. If you think they may have spent the night (and thousands of dollars) cloning it, you should probably revoke the key.
Re:so... (Score:5, Informative)
Kinda.
They also need your username and password - Keep those secure and you should be ok in the short term.
If you ever lost control of your yubikey to another party, revoke it as soon as you are able. You are back down to 1FA.
From TFA:
"
1. the adversary steals the login and password of a victim’s application account protected
with FIDO U2F (e.g. via a phishing attack);
2. the adversary gets physical access to the victim’s U2F device during a limited time frame,
without the victim noticing;
3. thanks to the stolen victim’s login and password (for a given application account), the adversary can get the corresponding client data and key handle, and then sends the authentication request to the U2F device as many time as necessary5 while performing side-channel
measurements;
4. the adversary quietly gives back the U2F device to the victim;
5. the adversary performs a side-channel attack on the measurements, and succeeds in extracting the ECDSA private key linked to the victim’s application account;
6. the adversary can sign in to the victim’s application account without the U2F device, and
without the victim noticing. In other words the adversary created a clone of the U2F device
for the victim’s application account. This clone will give access to the application account
as long as the legitimate user does not revoke its second factor authentication credentials.
"
The attack is a side channel attack against ECDSA using a bunch of lab equipment and probes. You would notice if the scenario in the quoted text were real.
However if someone could snarf your yubikey for a while and take it to a lab, then return it, they could do that attack.
The side channel traces they show in the paper have the ECDSA algorithm processing light up like a Christmas tree - not a difficult thing to attack.
This is the problem with tiny, low power crypto processors - There is nothing else going on on the the chip, so the side channel traces of the crypto operations have a high signal to noise ratio.
Yubikeys and other security tokens are not terrible. They are better than SMS based 2FA which is useless. But know where your key is and revoke as soon as you don't.
Re: (Score:2)
Yes. I know where my tokens are. I don't like silicon in them (witness the paper references in TFA for examples of why) and I don't like the usage model - there should be an interchange with the token between it and you using an independent secret in your head before it will initiate an authentication on your behalf. That gives it a user interface and makes the box bigger.
I think the current best, commonly available method is the authenticator apps on cell phones. It can require a local password from your h
In other words (Score:2)
"To exploit any Google Titan or Yubico security key, an attacker would first need to get their hands on a security key in the first place."
Basically a government can confiscate it and get it. That is worse than others actually, if you think about who can cause you the most harm .. it's usually a government rather than some fraudster. Fraudster can take your money, government can take your freedom. And your money.
Re: (Score:2)
A government can intercept the keys in the supply chain and clone them all before you ever hit the buy button on Amazon.
Re: (Score:2)
That doesn't sound any easier than this exploit... especially since it requires your password to already be compromised.
It's easier for spooks to go after your cookie jar in most ca
Re: (Score:2)
Re: (Score:2)
The user generates the key after they get it.
The host can verify that the firmware was not compromised either.
Extremely hard to defend against this (Score:2)
On an ElCheapo device, that is. This is more the type of attack that you expect a HSM to be proof against, but a HSM clocks in at 40k or so and upwards and comes in a format for a 19" rack. If you have to go to this level of effort, I would say these things are pretty secure for their application space.
Entire article undone by the last sentence. (Score:3)
WTF? (Score:2)