Page MenuHome GnuPG
Create Task
Maniphest T4522

gpg-agent's EXPORT_KEY command does not tell its pinentry SETKEYINFO , preventing use of external passphrase cache
Open, LowPublic
Actions

Description

when sending the EXPORT_KEY command to gpg-agent, if gpg-agent encounters a "protected" secret key, it needs to prompt the user to decrypt it. It does this with pinentry.

When it invokes pinentry, it sends:

OPTION allow-external-password-cache

(as it should).

however, it also sends:

SETKEYINFO --clear

though i think it should be sending

SETKEYINFO n/$KEYGRIP

(for whatever the $KEYGRIP should be).

As far as i can tell, the right fix for this is:

 diff --git a/agent/command.c b/agent/command.c
index 4839ffebf..ea6bfa91d 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -2320,7 +2320,7 @@ cmd_export_key (assuan_context_t ctx, char *line)
      the passphrase so that we can use it to re-encrypt it.  */
   err = agent_key_from_file (ctrl, cache_nonce,
                              ctrl->server_local->keydesc, grip,
-                             &shadow_info, CACHE_MODE_IGNORE, NULL, &s_skey,
+                             &shadow_info, CACHE_MODE_NORMAL, NULL, &s_skey,
                              openpgp ? &passphrase : NULL);
   if (err)
     goto leave;

This would have an effect on the agent-transfer component of monkeysphere, as discussed on the monkeysphere list.

Details

External Link
2.2.15

Related Objects

Event Timeline

dkg created this task.May 19 2019, 10:43 PM
• werner added a subscriber: • werner.May 20 2019, 9:29 AM

That is on purpose. Exporting of a secret key should in theory not be possible at all via gpg. In practice we need a way to export a key, but that should be the exception and thus we do not want any caches for passphrases to have an effect.

dkg added a comment.May 20 2019, 11:38 PM

And yet, that interface is already being used by the agent-transfer utility in monkeysphere. The interface exists, it is not marked in any way as unusable or deprecated or off-limits, so it is used.

And of course, once the password is cached externally for decryption or signing, a malicious piece of software with access to both the external password cache and the agent can ask the passphrase cache for the passphrase associated with n/$KEYGRIP and then use that value with the agent for EXPORT_KEY. So none of this is a security measure against a dedicated adversary with access to these datasets, it's all about managing scoped authorization and user expectation, right?

So, given that the interface exists and is in use, and it's not a security measure, is there a specific reason that it should *not* be integrated into the user's preferred form of passphrase caching if the user chooses to do so?

One sensible reason is that you don't want someone using a key (which therefore caches the passphrase) to trigger the accidentally silent unlocking of a key export (which could reuse that same passphrase). So i think that means that we want a different cache_mode specifically for export.

I've pushed bf2724880fe54d0dbf34bfa9fef2f31fa6809f55 to branch dkg/fix-T4522 that includes a proposed fix. I welcome review here.

ctubbsii added a subscriber: ctubbsii.May 21 2019, 1:38 AM

Disallowing passphrase caching is likely to have the unintended consequence of users choosing weaker passphrases that are more easily memorized and/or typed. Caching should be permitted, IMO. This puts more decisions about passphrase management into the control of the user.

ctubbsii added a comment.May 21 2019, 2:03 AM

I spent a lot of time trying to figure out how to automate the interface between my preferred password store (gnome-keyring, via libsecret), but with the loopback pinentry mode changes in gpg 2.1, it is much harder (if not impossible) to do. Having passphrase caching is the only thing preventing me from choosing a weaker passphrase on my gpg keyring.

Luckily, I was able to use gpg-agent as my ssh-agent (instead of gnome-keyring), and that works for me for now... because gpg-agent used this way *can* cache passphrases. However, this isn't my preferred ssh-agent, and in general, I don't think there should be any restrictions on passphrase caching, because of the risk of encouraging weak passphrases. This is the same problem with banning password managers in general. It's bad for security.

Feel free to dig up the full conversation on the monkeysphere lists that resulted from my confusion over the breaking changes that prevented automation for me at: https://lists.riseup.net/www/arc/monkeysphere/2019-05/msg00003.html

• werner triaged this task as Low priority.May 21 2019, 7:45 AM
• werner edited projects, added Feature Request; removed Bug Report.