Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: devel

Splitting encryption/signing between two gpg processes?

 

 

GnuPG devel RSS feed   Index | Next | Previous | View Threaded


joanna at invisiblethingslab

Feb 22, 2012, 8:18 AM

Post #1 of 5 (606 views)
Permalink
Splitting encryption/signing between two gpg processes?

Hello,

In our Qubes OS (www.qubes-os.org) we have implemented a little proxy
for gpg that allows apps running in one VM to transparently use gpg in
another VM.

So, I can setup Thundrbird/Enigmail, which runs in my 'work' domain, to
use this gpg proxy, which would automatically talk to the gpg server
running in my 'keys' domain, where my private key(s) are kept (the
communication is done over Xen-based shared channel, but could be easily
modified to work over network as well, so it's nothing Xen/Qubes
specific in principle).

This is obviously to prevent the attacker, who might have compromised my
'work' domain, e.g. by exploiting a hypothetical flaw in my Thunderbird,
from stealing my private keys. This is equivalent to using a smart card
for storing the keys (assuming VM escapes on Qubes are hard(TM)).
Additionally, however, because the gpg server (which essentially is a
wrapper around /usr/bin/gpg) running in the 'keys' VM can be configured
to prompt the user for permission to use the key each time (or every N
seconds), this setup goes a step further than a smartcard, as it also
attempts to prevent the attacker from selectively decryption/signing
(too many) messages.

Unfortunately the above setup has the following drawback -- in order to
encrypt messages to other people, and/or to verify other people's
signatures, one would need to import all those people's keys into the
'keys' domain. This is something we would like to avoid, as it
represents some non negligible attack surface on the gpg process running
there (processing untrusted input, resolving trust relations, etc). So,
ideally, we would like to keep all the public keys in the client VMs
(where our gpg proxy runs), and to use a local gpg to
encrypt-to-others/verify-signature-from-others, and only use the gpg in
the 'keys' domain to perform decryption/signing which requires the use
of user's private keys.

Do you have any suggestions how to best split such operations? So, e.g.
how to best split the following operation:

gpg -se -r Bob1 -r Bob2 -r Bob3 msg.txt

so that gpg -e executed in one gpg process, while the gpg -s in the
other one, and then how to combine the resulting outputs? And similarly
for decryption/verification of signature?

Thanks,
joanna.

ps. Here's the Qubes Split GPG code:

http://git.qubes-os.org/?p=mainstream/addons.git;a=tree;f=gpg-split;h=eeae4a0c3b245cba852b905184cebdbf537bc49c;hb=HEAD
Attachments: signature.asc (0.44 KB)


wk at gnupg

Feb 22, 2012, 8:44 AM

Post #2 of 5 (546 views)
Permalink
Re: Splitting encryption/signing between two gpg processes? [In reply to]

On Wed, 22 Feb 2012 17:18, joanna [at] invisiblethingslab said:

> Unfortunately the above setup has the following drawback -- in order to
> encrypt messages to other people, and/or to verify other people's
> signatures, one would need to import all those people's keys into the
> 'keys' domain. This is something we would like to avoid, as it

Did you consider to use GnuPG-2? You would run gpg-agent in your
trusted VM and gpg in the work VM. GnuPG-2 has been designed to
separate private key and public key operations. Currently gpg-agent and
gpg run on the same machine using a Unix domain socket for IPC. However
there is nothing which prevents the use of another communication
channel. In fact, when I ported GnuPG-2 to WindowsCE I modified our
libassuan IPC library to allow TCP connections for easier testing.

The 2.0 branch implements this design only for GPGSM (S/MIME), but the
2.1 development version fully implements the design and keeps the
OpenPGP keys solely under the control of the gpg-agent. I am using 2.1
for more than a year now.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


flameeyes at flameeyes

Feb 24, 2012, 1:06 PM

Post #3 of 5 (542 views)
Permalink
Re: Splitting encryption/signing between two gpg processes? [In reply to]

Il giorno mer, 22/02/2012 alle 17.44 +0100, Werner Koch ha scritto:
>
> Did you consider to use GnuPG-2? You would run gpg-agent in your
> trusted VM and gpg in the work VM. GnuPG-2 has been designed to
> separate private key and public key operations. Currently gpg-agent
> and
> gpg run on the same machine using a Unix domain socket for IPC.

Do you think it would be feasible to get ssh to implement a similar
forwarding for what they do already for X and SSH Agent? It would be
veeeery nice to have.

--
Diego Elio Pettenò <flameeyes [at] flameeyes>


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


jerome at jeromebaum

Feb 24, 2012, 3:02 PM

Post #4 of 5 (545 views)
Permalink
Re: Splitting encryption/signing between two gpg processes? [In reply to]

On Fri, Feb 24, 2012 at 22:06, Diego Elio Pettenò <flameeyes [at] flameeyes>wrote:

> Do you think it would be feasible to get ssh to implement a similar
> forwarding for what they do already for X and SSH Agent? It would be
> veeeery nice to have.
>

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148 and the
references from there.

--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
--
No situation is so dire that panic cannot make it worse.
--
Please encrypt sensitive information before emailing it:
https://jeromebaum.com/pgp/encrypt.html


wk at gnupg

Feb 25, 2012, 4:10 AM

Post #5 of 5 (538 views)
Permalink
Re: Splitting encryption/signing between two gpg processes? [In reply to]

On Sat, 25 Feb 2012 00:02, jerome [at] jeromebaum said:

> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148 and the
> references from there.

Forwarding of Unix Domain Sockets is problematic because they assume that
sender and receiver are on the same machine. BTW, their modern name is
PF_LOCAL and not anymore PF_UNIX.

Nevertheless, a transport channel via ssh makes sense.

Shalom-Salam,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

GnuPG devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.