12

For example PGP keys imported to a program like Thunderbird. Is there any reason why Thunderbird, due to a rogue programmer or just a bug in the code, can't send your private key off to a malicious actor or make copies of it once imported?

Perhaps I am misunderstanding how such programs work?

Improve this question
1
  • Literal question can literally be answered with "naff all does!" :)
    – rackandboneman
    Commented Aug 22 at 23:53

4 Answers 4

Reset to default
40

You're absolutely right that Thunderbird – or any other application which gains access to the plaintext private key – could exfiltrate the key, make copies or take any other authorized action.

The solution is to keep the key on a smartcard (or any other suitable hardware) which performs all cryptographic operations itself and doesn't export the key. For example, there's the OpenPGP card, and some versions of the YubiKey also support OpenPGP functions. This way, Thunderbird can encrypt, decrypt, sign or verify mails using the smartcard, but it can never read the key.

If this is not an option, then the only way to deal with the risk is to carefully choose the programs that you allow access the your private key. Thunderbird is open-source and widely used, so it should be a relatively safe choice (assuming you've downloaded the correct file). But if you're dealing with more obscure applications, the only solution may be to not let them access the keys at all.

Note this problem isn't specific to PGP/GPG or private keys. As soon as an application can read sensitive data, there's a risk of misuse.

Improve this answer
7
  • @user20574 The additional work is nearly zero if you choose the right pieces. For example, I use S/MIME via PIV, all I have to do is leave the Yubikey plugged in when sending e-mail and enter a PIN. Drivers are built into Windows and applications that use Windows' certificate framework like Outlook handle it seamlessly.
    – user71659
    Commented Aug 20 at 22:28
  • 11
    Of course, this still only just limits the malicious actions to the window while the key is plugged in and unlocked. If it stays unlocked for 5 minutes after you enter the PIN, for example, a malicious app could send off thousands of signed emails in that time without telling you about it. And if the emails are stored unencrypted at rest then they can be exfiltrated at any time regardless of the key. There's always a requirement for trust somewhere.
    – Miral
    Commented Aug 21 at 0:14
  • @Miral: Smartcards are slow, so I highly doubt you can sign thousands of e-mails in a few minutes. But at a much smaller scale, an attacker can certainly misuse the card while it's unlocked. This could be fixed by showing the message (or its hash) in the card reader display and waiting for explicitly confirmation before it’s signed (like it’s common in online banking). But I don’t think that’s implemented anywhere.
    – Ja1024
    Commented Aug 21 at 0:29
  • 3
    This is not the only way. Just using separate privilege domains on the same computer & operating system is also completely valid.
    – R.. GitHub STOP HELPING ICE
    Commented Aug 21 at 15:01
  • 1
    Yubikeys and similar hardware security tokens often require "proof of presence" before they'll perform an operation using your private key, specifically to mitigate the "rogue software signs/decrypts stuff without your permission" risk. This is why you have to tap the token all the time. Some hardware tokens actually do a fingerprint check at that time, requiring not just proof of presence but of identity, such that even with the PIN, token, and physical presence, and attacker can't use the token unauthorized.
    – CBHacking
    Commented Aug 22 at 7:18
13

With a private key in a file, there is nothing preventing it from being copied, extracted, or sent to a third party.

It's also possible to have private keys in a TPM, HSM, or hardware key. These make it possible to use private keys without exposing them.

Improve this answer
8

The smart cards and HSMs were already described in different answers. These are the correct answers but the concerns in comment are good points as this wont fit to everyone as it might be expensive, slow ...

The good thing is that there are other measures implemented by the security applications such as GnuPG. They are using client/agent protocol. This means the calling process (client), which is either your CLI, Thunderbird or anything that needs to do the cryptographic operation will only have access to the limited set of API, allowing to do the specific cryptographic operations and not accessing the plaintext private key (as there is no legitimate reason why it should allow it).

The plaintext private key (usually encrypted on the disk and decrypted only in memory) will be in the different process (in theory could be on different machine), in case of gnupg it is gpg-agent, there is ssh-agent and other toolboxes will have similar mechanism. So even malicious clients can not simply access the plaintext private key.

Improve this answer
1
  • 5
    This is true - and IMO is the best solution because it does not give up on general purpose computing and user autonomy and possession of their own keys - but in order for it to really have this benefit, you need to have the key holding agent process live in a separate privilege domain from the client process. Otherwise the latter can just open the files on disk containing the key or ptrace the agent process or map and directly read from its memory.
    – R.. GitHub STOP HELPING ICE
    Commented Aug 21 at 15:03
-1

The encryption/decryption should be designed in such a way that only the device itself can access private keys, not individual applications. Whether this is possible may depend on your hardware.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .