The loopback pinentry

[Bjarni Runar Einarsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello :)

Please accept my apologies for how long this is... again!

Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> The agent is essentially a convenient abstraction that
[...]
> 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.

Yes, and it's a great idea and a great feature. I would actually
much prefer Mailpile users be able to make use of this
architecture as much as possible, which is one of the reasons I'd
rather not run my own agent.

Unfortunately, Mailpile (and any network server) is incompatible
with complete isolation, since there is no standard out-of-band
way to request permission (a passphrase, pinentry) over the
network. It necessarily must be in-band in these cases, and I
think network servers are such fantastically useful things that
GnuPG shouldn't rule them out by default.

That does not render the other benefits and protections afforded
by the agent architecture worthless. You can still share keys
between apps, and you can still follow best practices to isolate
and protect the key material and crypto operations. The user can
still use other channels to revoke any granted permissions (by
changing the passphrase).

I want Mailpile users to have all of those things, so I don't
want Mailpile to have a dedicated agent. I want it to talk to the
shared GnuPG, trusting the distro to lock it down and secure it
as well as possible in each instance. Of course if it's locked
down and secured to the point that Mailpile can't function, then
I'll be sad... and that's what this discussion is about, I guess.


Regarding key access and passphrases:

The need for loopback pinentry could be lessened and better
managed if it were possible to specify per-key and per-app (or
per long-lived session) credentials (per-app passphrases for
example, or per-key pinentry policies). Does the current agent
support such things? Can an app request pinentry authentication
and get back a token which allows long-term access to that key
(and only that key), which the user can then revoke as needed?

I don't actually want Mailpile to know the user's passphrase
either, if I can avoid it. I just don't know of a way to avoid it
- - yet!

(An example of this sort of thing in the real world: GMail allows
the user to generate a per-device password for logging in to
IMAP, which means the IMAP access can be revoked for a single
device without the user needing to change their main credentials
(I hope to "borrow" this idea for Mailpile in various forms). A
network-service-friendly GnuPG agent could well offer similar
features.)


A different access-token idea:

A lesser, weaker access token implementation would be to require
a token in order to use the loopback passphrase mechanism itself.
Mailpile would need to request that token on setup, and the user
would need to grant permission using an out-of-band agent dialog.
This would require a bunch of new code in GnuPG, but would be a
middle ground between "default forbidden" and "default allowed":
"default ask".

I don't know if it's justified; my gut feeling would be that an
OS like Qubes would use "default ask", but a normal Linux distro
that doesn't really provide isolation anyway should still use
"default allowed", for the reasons I discussed in my last
message.


[isolated agent description snipped]

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

I think you captured it reasonably well. :-)

> 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.

Yes. My wording was imprecise; I tend to see signing and
encrypting as a single operation, since that is what I usually
do. I am also sloppy and talk about "encrypting" when I mean the
full cycle of encrypting and decrypting. One is worthless without
the other, after all. Sorry about the confusion.

> 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?

I don't *want* to run my own agent. Ever!

I had expected to run my own agent *anyway*, because I feared it
would be impossible to get the default GnuPG to cooperate. I
don't want to and I consider it a messy last-resort hack, but
that was where I was headed, and was asking Neal for advice on
how best to do it... when he (and Werner) talked me out of it.
:-)

They pointed out that the loopback pinentry feature could solve
the problem without resorting to agent proliferation and
GNUPG_HOME hacks, and here we are discussing whether the rest of
the community agrees.

I can still go back to my hacks if necessary.

> once as part of account setup, and does that configuration
> modification via well-documented interfaces like gpgconf, seems
> entirely sensible to me.

This *might* be safe in this particular case, but in general, if
apps make a habit of reconfiguring gpg.conf (with or without user
permission, users in general will have no idea what they are
agreeing to and will just click OK until the annoying popups go
away), then that sets the stage for apps breaking either user
security or the features other apps depend upon. As a matter of
principle, I just don't want to do this sort of thing.

Cheers,
 - Bjarni

- -- 
PageKite.net lets your personal computer be part of the web.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXGVTjAAoJEI4ANxYAz5SReT8IAItEQBFzTyMzlPgSi5QA9TRB
MrU4w5jG1+QjNA+L10UFNVvucFUtHhVh+miwiI1NsXCY+Sg0HXtE6AZqkwTzOcKp
6a7EbOKfxGlN0FsDl1/28lAUelY1RoYka8FlyzDnn28gZN/xnjx8zkw++uYZUqpp
C2KqY+dWLSktxANyOQuQVKaROfs9UPVdkYbf/ltxaFVbsHWWz5nDgrFtCLHjSu1V
N6KkTtlT+9vcC8+iFJ4REOEHMraH8djQ4hp5y3PvZX0HG7N/DLKRBibivo0BRNNw
f6kJmlDHWOSJRKL6EPiiVR6WoSx7uoLltLGVSLoIBGesv7vsPd46hD2/FuUA8Y0=
=RLeQ
-----END PGP SIGNATURE-----