The loopback pinentry

[Daniel Kahn Gillmor]

Hi Bjarni--

thanks for the detailed response, and for all the quality engineering
you're putting into mailpile.  I think we still disagree but i can see
where you're coming from.  a few thoughts:

On Wed 2016-04-20 19:04:08 -0400, Bjarni Runar Einarsson wrote:
> tl;dr: Whenever an app *can* copy all the key material and do as
> it likes by changing GNUPG_HOME and writing out a custom gpg.conf
> (or edit gpg.conf directly), then it is it pretty clear that the
> current defaults for this setting provide no real security. They
> just making things inconvenient, driving developers like myself
> to hacky, dangerous workarounds or away from GnuPG entirely. I
> think everyone agrees that this scenario is the common case.
>
> Qubes would be an exception, if this changes for 2.2 we might
> want to reach out to them and make sure they are aware of the
> change. Are people aware of any other common cases where the
> agent is actually isolated and protected from other apps run by
> the same user?

in some sense, this isn't a question about the agent, but a question
about the entirety of $GNUPGHOME, right?  as long as the contents of
$GNUPGHOME/private-keys-v1.d/ is available to a process, that process
can mount a passphrase-guessing attack against the secret key material.

The agent is essentially a convenient abstraction that allows
well-behaving programs to remain ignorant of the specifics of
$GNUPGHOME/private-keys-v1.d.  It also happens that this same convenient
abstraction can be used to place the private-keys-v1.d in an a location
otherwise inaccessible to the processes that request access to those
keys, forcing all access through the agent.

This isolation is one of the main security promises offered by
cryptographic agents.  it's similar to the isolation you get from using
a smartcard or HSM, but based on operating system isolation instead of
hardware isolation.

We haven't been able to make use of that promise in gpg for OpenPGP
until the 2.1 branch moved all the secret key access into the agent.
We're on the cusp of being able to make that promise a reality (the
qubes approach is an example), and i'd really like to make sure it's
possible and we don't encourage people to deploy code that is hard to
use with this isolation..


Here's an attempt at writing a short description of the goals of an
isolated cryptographic agent:

--------
  A cryptographic agent should control access to secret key material.
  The agent permits use of the secret key material by a supplicant
  without providing a copy of the secret key material to the supplicant.
  
  An isolated cryptographic agent separates the request for use of
  secret key material from permission for use of secret key material.
  That is, the system or process requesting use of the key (the
  "supplicant") can be denied use of the key by the owner/operator of
  the agent (the "owner"), which the supplicant has no control over.

  One way of enforcing this split is a per-key or per-session
  passphrase, known only by the owner, which must be supplied to the
  agent to permit the use of the secret key material.  Another way is
  with an out-of-band permission mechanism (e.g. a button or GUI
  interface that the owner has access to, but the supplicant does not).

  The rationale for this separation is that it allows access to the
  secret key to be tightly controled and audited, and it doesn't permit
  the the supplicant to either copy the key or to override the owner's
  intentions.
--------

Does this make sense?  I'm happy to see suggestions for other ways to
describe the goals of an isolated agent.

> Mailpile is not implemented in a browser, it offers a web
> interface as one of its user interfaces. This means it can be
> accessed simultaneously from afar and/or locally, depending on
> the user. There's also a command-line interface which I use quite
> a bit. :-)

thanks for the clarification, i hadn't realized there was an additional
command-line interface.

> That's your choice. It is a choice that means you won't be able
> to do certain actions over the network (when you are away from
> the desktop, you won't be able to fill out the pinentry). For
> some users that is certainly the right thing, especially when we
> consider signing and encrypting to be rare, meaningful actions.

I think you mean signing and decrypting, right?  These are the two
primary actions that the user takes with their secret key material,
which is what is protected by the passphrase.

> Note that just because Mailpile wants loopback pinentry, that
> doesn't automatically mean it is going to default to sending
> passphrases over the network. It will frequently be used to
> manage passphrases within Mailpile itself and silently provide
> authentication as needed, without any user interaction at all.
> Especially for keys that were generated by Mailpile in the first
> place. I'd rather not generate them without a passphrase (so
> Mailpile generates a strong random one), so I still need a way to
> automate the authentication.

I'm a little confused by this -- if mailpile is generating the keys, and
selecting the passphrase, and hiding all of this from the user, then
surely mailpile will be operating its own gpg-agent, in which case you
can control the configuration.  right?

The case we're talking about is a case where mailpile is interacting
with an existing keyring and an existing agent, right?

> Since my goal is to get people encrypting and signing more and
> more, I want to make it as convenient as possible. This is why I
> care a great deal about use cases that differ from the one you
> have described and differ quite a bit from the common ways GnuPG
> is currently used. Maybe that's bad, maybe it's good, it depends
> on your goals. :-)

i share your goals! :)

> Incidentally, saying "the user can just edit their config if they
> want to use those apps" is tantamount to saying "non-technical
> users are not allowed to use this software"... so I really hope
> nobody says that! :-)

I definitely didn't say that -- i just observed that an application that
is incompatible with isolated agent use, which has access to the
configuration settings for gpg-agent, and which asks the user for
permission to modify the configuration once as part of account setup,
and does that configuration modification via well-documented interfaces
like gpgconf, seems entirely sensible to me.

(and of course, if the initial setup is entirely controlled by mailpile
and it's not interacting with an existing keyring, then setting that
configuration without asking is also reasonable)

              --dkg