gpgme: Pre-loading keyrings?

[Marcus Brinkmann]

On Sun, May 18, 2003 at 09:23:44PM +0200, Jann Fischer wrote:
> is it, or could it by any means be, possible to "pre load" a keyring to
> use with gpgme?

No, GPGME doesn't do nor should do anything like this.

> The reason for this question is, to have an application
> run in a minimalistic chroot(2) environment without exposing the keyring
> in case an attacker could gain access through the application. I thought
> on something like:

GPGME is just a way to access the underlying crypto engine.  If you need a
secure environment for your crypto engine to run in, you need to provide it
yourself.  This includes setting up the data necessary for the crypto engine
to operate.  I am not sure what exact kind of secureness you have in mind
(your example was not specific enough to tell), so I can not say what kind
of environment you would need to setup.  You might be able to write your own
gpg wrapper in the chroot that can communicate to a secure encription
daemon).  Note that this is not just a matter of the keyring, but of the
whole environment for the engine process.

However, there might be a way for you to do what you want in the future.
With gpg v2 we will use the crypto engine through a socket rather than by
pipes, and the socket will be used for many operations instead one.  Then
you might be able to first create the context, and then chroot (after the
crypto engine has been started).  I can not say for sure that this will
work, and it certainly won't be officially guaranteed.

> I'm quite sure it's not possible already, yet I think it would be a
> pretty nice feature to have.

This is nice from the point where you stand, because you have this idea and
want an easy way to implement this.  From our perspective it's not good
behaviour, and the only committment we can make is that we try to make it
possible for you to implement something like this (ie, something, that has
the same effect in terms of functionality and security).  I am afraid though
that such a feature requires a lot more work than you suggest in your
example code.

Please have a look at the module overview on
http://www.gnupg.org/projects/aegypten/tech.en.html

It's for GgpSM (ie, CMS, not OpenPGP), but in fact the very same design is
used for Gpg (OpenPGP) and will be carried on in gpg v2.  As you can see,
there is a whole lot of layers, and something like the secret keyring is
actually, for example, on a smart card, and controlled by the smartcard
daemon (one process).  The smart card daemon is accessed by gpg-agent
(another process), which uses pinentry to unlock the key (yet another
process).  gpg-agent is used by gpgsm (and will be used by gpg) to perform
an operation with the secret key.  You application is yet another process.
So we have potentially 5 processes involved for a decrypt operation.  If you
now suggest we have a way to control the execution environment of all these
processes from your application, then this raises a lot of design and
implementation questions.

I hope this gives you an impression about the implications we have to
consider when discussing such features.  For a separation of the application
and the crypto engine, I would rather use a different scheme, where gpgme
doesn't start the crypto engine itself, but just uses an already running one
(in --server mode) over a socket.  This is something not readily supported
in the current code, but which might not be hard to hack in, and will only
get easier and more in line with the design in the near future.

Thanks,
Marcus



-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus at gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/