For this particular case: if you have GnuPG or SSH private keys, do not store them on-disk. Use a hardware token, such as a gnuk token, or a token with a secure element if you also want resistance against physical key exfiltration. A gnuk-based hardware token can be had in a nice format for under 30 Euro [1] or you could buy a STM32F103-based microcontroller for a few bucks and flash gnuk [2] if you like DIY. If you are a company, invest the 50 Euro in hardware tokens for your employees, one compromised SSH private key means that all the machines that use the public key are suspect.
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions.
I fully agree. It seems that the UNIX model is not very compatible with the macOS permission system, but one could imagine defining multiple types of shell sessions, each with its own set of permissions.
yubikeys can store GPG keys and emulate SSH keys via gpg-agent.
Indeed. Same for gnuk keys. I currently use a gnuk key (Nitrokey Start) with Ed25519 and have GPG set up as the SSH agent for SSH. Though I hope to switch to a YubiKey soon, so that I don't need a separate key for U2F/Fido2.
I'm really looking forward to the U2F support - it's built into openssh and allows multiple ssh-keys tied to a single yubikey. The gnupg stack has become more stable, but it's always been the problematic part of the setup.
The other advantage is that you can use the cheap U2F/Fido yubikeys without GPG/applet support.
Hardware tokens usually have three slots for keys. That's enough for a full set of signing, encryption and authentication keys. It is not wise to keep the primary certification key there, though. Hardware tokens can fail or be lost or stolen. Subkeys are expendable but the primary key is important enough for special treatment.
The best way to keep it offline is to make a paper backup with the paperkey tool and store it in a safe:
In addition to this, it's a good idea to QR encode the key. QR codes are quickly and easily restored with a laptop camera and they support even 4096 bit RSA keys.
The zbarcam program can be used for this purpose but current versions have binary data decoding problems and aren't easy to interface with. I sent some patches to that fix these problems but they haven't been reviewed yet:
I never understood the point of hardware tokens. If the machine it's plugged into it's compromised, the attacker can still use it to sign whatever they want. If the attacker has persistence on your machine, it's as good as stealing the key file. You're basically counting that you can discover the infection before the attacker can use it, or the attacker is unsophisticated so all they do is copy your .asc files (although you could also protect against this by putting your key files in a weird location). Depending on how proficient the attacker is and how vigilant you are, it could be a while before it's discovered. When you do discover it, you still have to revoke/rotate your keys since you have no idea what it could have been used for. So you end up not saving any effort at all.
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.
Yubikey owner. You have to physically insert the USB key and then interact with it (touch it) to do signing/auth/etc. If you hijacked the signing touch step, you'd notice that your signature wasn't generated by the touch and would know you're compromised. The key isn't plugged into the computer except when you're using it, and if you're in Qubes you have VM isolation for the USB ports. It narrows down the attack surface a lot, and makes anyone not using one a more attractive target.
>Yubikey owner. You have to physically insert the USB key and then interact with it (touch it) to do signing/auth/etc. If you hijacked the signing touch step, you'd notice that your signature wasn't generated by the touch and would know you're compromised.
as mentioned by a sibling comment this can be worked around by social engineering. some ideas:
* simulating software/hardware/connection error, forcing the victim to retry. bonus points if you only start doing it after the victim installs an update to gpg
* in cases where you know the signature doesn't have to be valid, substitute a legitimate signing request with your payload, and returning a fake signature for the legitimate request. for instance, the you coax the victim into sending a signed gpg email. you know that nobody would be checking the signature except for you, so you detect that case and use that opportunity to sign your payload, and return a fake signature to the email program.
* my favorite: causing gpg to fail (thereby forcing the victim to retry) by injecting typos into his terminal when he's invoking gpg from the terminal
I think a hardware chip would solve ‘crown jewels’ theft (eg I get rekt but at least my SSH key isn’t stolen for good), but there isn’t much you can’t do to my host if you have root, persistence and patience.
Yubikeys are silly and designed to sell rather than solve a problem effectively, IMO.
As much as I would like very much to have an open source hardware token, there’s a major downside to the nitrokey start and other STM32F103 gnuk devices. The microcontroller itself is not hardened at all in hardware. It would not be remotely infeasible to extract secrets from its hardware using relatively available tools. This is in contrast to a true smart card or a yubikey, which have tamper evidence.
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions.
I fully agree. It seems that the UNIX model is not very compatible with the macOS permission system, but one could imagine defining multiple types of shell sessions, each with its own set of permissions.
[1] https://www.nitrokey.com/ [2] https://salsa.debian.org/gnuk-team/gnuk/gnuk