Yubikeys for example can require a touch on the token to activate it. A dedicated attacker could still trick you into activating the token by waiting for you to do something where you'd need to activate it, but it significantly raises the bar.
They also entirely prevent various compromises:
* Theft or loss of the laptop does not mean loss of token.
* Even if the token gets lost, cracking it will be hard. A dedicated attacker might be able to do it, but a 6 digit pin with 3 tries is hard to guess. Decapping and convincing a yubikey to reveal the secret key is likely possible, but nontrivial.
* Attacks where the attacker can read files do not turn into a compromise of key material.
* Even a compromise that allows code execution would require a sophisticated attacker to pivot: You'd need to figure out how to make good use of the acces gained either in a fully automated fashion or be online when the victim has its token plugged in. You cannot collect the key and later figure out what to do. This pretty much rules out attacks such as the one we're discussing here.
So while they do not protect against a full persistent compromise, there are quite a few cases that they do protect against.
>* Theft or loss of the laptop does not mean loss of token.
Doesn't seem relevant when you probably have FDE enabled.
>* Even if the token gets lost, cracking it will be hard. A dedicated attacker might be able to do it, but a 6 digit pin with 3 tries is hard to guess. Decapping and convincing a yubikey to reveal the secret key is likely possible, but nontrivial.
To be fair, if you weren't using a token, and were just storing the password protected keyfile on your FDE protected computers, there's nothing to "lose" either.
>* Attacks where the attacker can read files do not turn into a compromise of key material.
Only if the keyfile isn't password protected.
>* Even a compromise that allows code execution would require a sophisticated attacker to pivot: You'd need to figure out how to make good use of the acces gained either in a fully automated fashion or be online when the victim has its token plugged in. You cannot collect the key and later figure out what to do. This pretty much rules out attacks such as the one we're discussing here.
Keyfiles are already harder to monetize than other information you can steal off a computer. There's no market for id_rsa/.asc files, but there are for credit card numbers, personal info, bank/email logins. You have to put in the legwork to make money off them (eg. logging into each server and checking what's on it or whether they can be used to pivot elsewhere, seeing who your contacts are to see whether they can be duped using a signed email, or checking whether you're a maintainer for a software project and using your key to sign a malicious update. Therefore, it's safe to assume that attackers interested in your key files are also sophisticated enough to perform the pivot.
> >* Theft or loss of the laptop does not mean loss of token.
> Doesn't seem relevant when you probably have FDE enabled.
You still need to regard the key as compromised - it's no longer under your control and you have no idea what a potential attacker would try. Most FDE does not lock the disk when the computer goes to sleep, so the attacker can now try to break in via Firewire, ...
While with a physical token, as long as the token is in your possession, the key is entirely under your control (unless you have a backup on your computer, which kind of goes against the idea)
> Therefore, it's safe to assume that attackers interested in your key files are also sophisticated enough to perform the pivot.
Like they strictly did not even attempt in that case? This seems to be targeting python developers. Now, with a python developers ssh keyfile and gpg keyfile (if I manage to unlock it), I could do quite a bit of damage For example try it on github. It's trivial to associate an ssh key with a github acct - the info is public.
>Most FDE does not lock the disk when the computer goes to sleep, so the attacker can now try to break in via Firewire, ...
Fair point, but this is a very untypical threat model. Basically it protects you against targeted physical attacks. Targetted, because your average laptop thief isn't going to be pulling off DMA attacks. I certainly have not heard of it occurring (targeted or untargeted) in the wild.
>This seems to be targeting python developers. Now, with a python developers ssh keyfile and gpg keyfile (if I manage to unlock it),
There lies the problem. If you used a reasonably secure password (ideally from a password manager), your keys would be as secure as they would be stored on a token. This wasn't an attack that only tokens could mitigate. A free password manager would do just as well.
They also entirely prevent various compromises:
* Theft or loss of the laptop does not mean loss of token.
* Even if the token gets lost, cracking it will be hard. A dedicated attacker might be able to do it, but a 6 digit pin with 3 tries is hard to guess. Decapping and convincing a yubikey to reveal the secret key is likely possible, but nontrivial.
* Attacks where the attacker can read files do not turn into a compromise of key material.
* Even a compromise that allows code execution would require a sophisticated attacker to pivot: You'd need to figure out how to make good use of the acces gained either in a fully automated fashion or be online when the victim has its token plugged in. You cannot collect the key and later figure out what to do. This pretty much rules out attacks such as the one we're discussing here.
So while they do not protect against a full persistent compromise, there are quite a few cases that they do protect against.