split-gpg2

[HW42]

Hi,

I developed (a prototype of) split-gpg for GnuPG 2.1 (simply called
split-gpg2).

Since the newly released (see [0]) GnuPG version 2.1.0 the private keys
are manged by the gpg-agent.

For split-gpg this enables some nice new features:

- you import public keys in the client domain. So no untrusted data in
the server domain.
- since you use the "real" gpg2-binary (not the split-gpg wrapper) you
have (nearly [1]) the full feature set. This includes:
- no restriction to enigmail (split-gpg never worked with libgpgme)
- singing git commits [3]

(see also ticket #474)

You can get it from here (only via git. no gitweb):
https://git.ipsumj.de/hw42/qubes/split-gpg2.git (tag v0.1)
(see [2] for code verification)

I hope the README is useful. If I have missed to mention something
simply ask.

WARNING: You should consider this a beta release. So don't use it for
sensitive things without reviewing it.

There are two design decision where I am unsure (see XXX marks in
split-gpg2.rb):

1. gpg-agent has only access to the "keygrip" (some hash which is not
the fingerprint) therefore it can't display useful messages when asking
for the passphrase. In the normal setup gpg2 provides this string via
the SETKEYDESC command. But since this comes from the client domain this
is untrusted. I currently sanitize this string. I think this is
uncritical but maybe somebody has a better idea?

2. From my viewpoint more critical is that currently the D inquire
command (D = data) is not sanitized. This is used for different data
(key param, ciphertext). These are always libassuan S-expressions so you
could verify that it is a valid sexp - but is this useful? Any ideas?

Some side notes (@Marek):

A qrexec-client-vm option which connects the RPC stream to stdin/out
instead of execute a new program would save two socats in
split-gpg2-client-wrapper and is probably useful in other cases.

When I start two client domains in parallel (mostly after boot up) I
often have the problem that the first client domain the rpc call blocks
fine until the server domain is started. But in the second client domain
the rpc call fails since the server domain is still in transient state.
Is there a I nice solution for this problem?


HW42


PS: You obviously need a 2.1 version of GnuPG to use split-gpg2. For
Debian you can get this from experimental. But for fedora I found no
source - so you probably have to build it from source. Therefore the
gnupg2 dependency is currently commented out in the rpm.

[0]:
http://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000358.html

[1]:
Of course some commands will (and must) not work.
For example --export-secret-keys

[2]:
Bottom of message <54585251...@ipsumj.de> on this list.
https://groups.google.com/d/msg/qubes-devel/0nd2-Frb0Mk/5L8esiKRMC8J

[3]:
You must make sure that git uses gpg2 (and not gpg):
git config --global gpg.program gpg2

[Jason M]

Awesome!  I will check it out.

I started to try to get split gpg to work with git about a month ago.  I finally got it working and my computer crashed hard that night.  I could not recover from some btrfs errors (3rd time this happen to me in 2 years on 3 different platforms) so I had to reload and lost those configurations.  Never did get back to it, but this approach sounds interesting.

Thanks.

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

HW42 wrote:
> Hi,
>
> I developed (a prototype of) split-gpg for GnuPG 2.1 (simply
> called split-gpg2).
>
> Since the newly released (see [0]) GnuPG version 2.1.0 the private
> keys are manged by the gpg-agent.
>
> For split-gpg this enables some nice new features:
>
> - you import public keys in the client domain. So no untrusted
> data in the server domain.

So, does this finally allow for signing other people's keys without
having to import untrusted public key data into the trusted backend
domain?[4]

If so, how does that work, given that gpg-agent can never have access
to the public key data?

(I'm assuming that gpg-agent, which you say runs in the trusted
backend VM, can never have access to the public key data, since that
would imply importing the untrusted public key data into the trusted
backend VM, which is what we want to avoid. If this assumption is
faulty, let me know.)

[4] https://wiki.qubes-os.org/ticket/474#comment:8

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU+lL6AAoJEJh4Btx1RPV8XuwQAN6PED//RIEI/geJHUjmhBs5
Ly1aKT+3lanM2wY55rQrOB1gRWyEI6rxHtDv2AcQSoMfl6E3KV6A3zrKeCLE3dA0
Wu8M2QgHBzSfkqGa5qhGhixy3lRDBP1xptvEQdm+gNMy3MR61zMLBuQms9Ol69qM
SfgGEABLU7Vwj+NjwaSyanKktrB8Y3h3ykdJdiIdLGgnCWNXV2Hu6BIONIWWwHOJ
D+QZjps0Xmx0LK826nlFSKLkQmRpZixINXMVt728cVNwcBtrcAUrtltZ/k8Wu1Cv
kHT3OEh1NB4V97k7yx+9uW+coeCPiCgMexNug6fRyYlVCSLyVXzyIMjPEj37D77O
ooDst3vP0AkORAd0gTzrsJLTVAZs8cCaf8f+0cmJHLN1Zgm9Z72IFHBc13PkYPmj
IwpqQxybskwrxSFReaOPXgo+X3u/FJ0FfZ22Yh6qj+PnGgv4gPbGoSjb/u1MdGLw
N8bxGMWSAgI6qzdjIQ6RTCGtHzt7cUR+Xk18+q9pm2+U5V3uQEWhbbVic4DRMhch
KX6p6vBgwoBqGtjnB5ZBKZ7/9SYj4NhQ6GwkwfY8cI2c0BDucmb6MLyLoZ3kSFwM
/0p7kONMyWHv+GO8b3mOysKrHGjLyizrNH61bW1M6xaTvkOuWjo9dKoLYSqTMxCi
DKVl2hHvQlRkI4+7XMiX
=oW0i
-----END PGP SIGNATURE-----

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Axon:

> HW42 wrote:
>> Hi,
>
>> I developed (a prototype of) split-gpg for GnuPG 2.1 (simply
>> called split-gpg2).
>
>> Since the newly released (see [0]) GnuPG version 2.1.0 the private
>> keys are manged by the gpg-agent.
>
>> For split-gpg this enables some nice new features:
>
>> - you import public keys in the client domain. So no untrusted
>> data in the server domain.
>
> So, does this finally allow for signing other people's keys without
> having to import untrusted public key data into the trusted backend
> domain?[4]

Yes.

> If so, how does that work, given that gpg-agent can never have access
> to the public key data?

The key get imported in the frontend domain. I.e. the PGP-packet parsing
etc. is done there. Only the cryptographic operation that requires the
secret key is done in the backend domain. This is similar like
Smartcards/HSMs are working.

The communication looks like this (frontend >>> backend):

Select key which should be used to sign the hash.
>>> SIGKEY XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<<< OK

Set the hash which should be signed.
>>> SETHASH 8 YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
<<< OK

Sign the hash.
>>> PKSIGN -- ZZZZZZZZZZZZZZZZZZZZZZZZ
<<< D (7:sig-val(3:rsa(1:s256:....

For more details see the documentation of the gnupg-agent protocol. It
might also be helpful to look at the log option of split-gpg2 and the
test.rb in the source repo.

iQIcBAEBCgAGBQJU+ly7AAoJEOSsySeKZGgW0mQQALWmSaIXYY5AlYbJGyC0rTM1
JIwg4+hrUauY4iLFEUTbo7/J32OqfuEGvTTxfq530cQbjFpDgbwi+AkL0jrgkYuU
TIXf9W1xXaIaAf6pH5tcKx4uSPBN1/nJ8t4LnZ0buBznrrndf64dwl3x9u7qnMO0
8x2/48rlP2Iy6FQ/klsS5mfxsUq0tiYz4+e7G3NTrjuhJ3gwd3d3/KoR30iqm8j2
vGi9qLDx9zGhB1W62KHJJYrJYCI7b40Uqfn0m/qII2Hz8E+insTb6DMTwvBmwWKP
27wMiaYh/XIvSdkjSdAWreh2haR6oUNHILcJiWKaLz+9QEjHRMFoSWInIrZC4O5f
VDzBhz4ugwI3cT6jh3JlBw0h6CyLxwKTYan1bCPIjqJ3L86dJTVycuBMkzR/3m+F
NownuzS2K1O7a5GGx0oYQfUIAMEVsNUfZRy5hZklMqnPXof3S0AwN++x0m9BB3tX
oYfGII+aDo1DWYSk4AW8V6DscQexXQvgEYnVDYPoLtpGs38+GQ+HfvJgfqC/eHG1
SvX2vi0ke2uxetKvHmTv3ci07D33roHdok4B4rhQQp7qlzOgFpFuquJDyQ0Jrpzh
U1GJeS+H7CqjH5vtrUZHUIds8YpfCULECs80fg7ZtjOO8y9betvPz/yog2Q55I+e
2ndwbnZ3JHByx9+IQ0qb
=mZtJ
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Great! Thank you for doing this!

>> [...]
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU+nobAAoJEJh4Btx1RPV81f8P/RQXSjpaLNTkmnPjJJcqM1Y9
464Bx888rKsljhnNEahyGzam78pb5Iu+rp1sSXGj+a3KMqMsnJ25cfLmyBDDqmyV
2DaeAgzVwKwSbVtbeSyUxi1DRmmLPWdl4/Ji+opYMGCTq8sVC7i/ILbkdRUfWzr8
Z/iZ/CoqMMu+OlXf89P3BpTaiXiEmmymYlbUVSad1ZKFUaCRrrbrFxbFVtrFUHs6
5diaf08LZP7KvyafrisCmZW1dh8iojzwTrpVPxbObA7V+bDrz1qmCF+CNeb2x1j4
erpHKtOOxxBqH7Xwa4JwzG5qT7aEKgf7sc7TCxMkar4qzyi07pCFg5XxeqxaxMla
GEztSub2eykEsr6C/j195gPhLUe87hMLBt79FSfhY6IftooB9H9yKLpe4KgB5Uag
Wn8IRy4NgBtfQoUZ4vhWVv8yq+lVaXdQ8Bt0c6caM29fXUnfngvS3TmK4uft2nVJ
6GK60A5a6Qj/5GsKlXbVaoeE9XHXzvfqh1dfjxmXn55QTO3Zb67u4CiDscRP/1jY
sep10TggrOO3JqGdJbVzYCVM9NuRj5zA7Kla9YUXuw+GcVcVj3p2a2lWBf3W4AAt
S6N3j3+gSjZxwwFJXnz3fj8FOk9MJZRJ9UqJDOLiPCuplr5IM4eTLTNUKOE2fTUl
siOEMccn+Wu16F6r/DlD
=Ja3k
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

There is, however, one advantage of sticking to the current Split GPG
architecture (which requires import of all the untrusted keys into GPG
backend VM) over this GPG v2.1 fully split model --

Namely in the current Split GPG architecture the backend VM sees the actual
document before it gets signed (as well as it sees the document once it got
decrypted). This allows this backend VM to display it to the user, or
generate a somehow meaningful log of events (for audit) of what documents
have been signed and/or decrypted. The backend VM might use Disposable VMs to
present documents-to-be-signed to the user (via qvm-open-in-dvm) to given
even better control over what the keys are used for to the user. (This
obviously would not work for git tags signing though).

This is currently not implemented, but I've been thinking of adding this at
some point, i.e. when-have-more-time (TM). And we can't have this when using
the new, fully split model, because than the backend VM only sees the hash,
which is really meaningless.

joanna.

[Joanna Rutkowska]

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

On Sat, Mar 07, 2015 at 04:10:10AM +0000, Axon wrote:

[Resending using inline PGP signature, so Google Groups don't break it]

There is, however, one advantage of sticking to the current Split GPG
architecture (which requires import of all the untrusted keys into GPG
backend VM) over this GPG v2.1 fully split model --

Namely in the current Split GPG architecture the backend VM sees the actual
document before it gets signed (as well as it sees the document once it got
decrypted). This allows this backend VM to display it to the user, or
generate a somehow meaningful log of events (for audit) of what documents
have been signed and/or decrypted. The backend VM might use Disposable VMs to
present documents-to-be-signed to the user (via qvm-open-in-dvm) to given
even better control over what the keys are used for to the user. (This
obviously would not work for git tags signing though).

This is currently not implemented, but I've been thinking of adding this at
some point, i.e. when-have-more-time (TM). And we can't have this when using
the new, fully split model, because than the backend VM only sees the hash,
which is really meaningless.

joanna.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJU+sh1AAoJEDOT2L8N3GcY1DwP/iLQAM9FcTkYdooxQhk4I/9N
+xSwFgXRx2JdxFHKdqb6+lMUYpimO5tJ+6LKa0jGmtCrwQZQCCSrMfBwTiE2xCWh
GCpK2lUA8eGN6FnlCkb8Fdpq3HXW8zt/O3kYfleMcNdtRw9ld9e+b81OJ7VKK4RH
Ot+KIpCzbO4RfqdHDUJgM3xXSpuVtuc8K3cvZle504bx7Do6NKG1Iqy1rjPbtvmx
L21LLHDiYUB2KdCn8kA5DUSAebZpoLXz/rxaR9TLnHyporEYTgxXL2coZW+spZi6
345Fb2e5dVi7YuxBaaoI7496/iHmGeLaQGi8N6ddqEkudtCk9XgVY6V0q5Qb2Ioe
9zUMP03Uypst96cMN2D/Nelm/jcBa5E6hJOttIpO0a4MBJ5E3dTfUx1bWhLFGqcT
grw1ows27MD3n5QNZqR+7wGRF1Nou+sx1m078k4zpIbpH1wyNLmCbDd0keP1/Aw8
92UTxau4IX7x3kKdVihgD5cm7k+PhT5hPHwuMgoVUd6HEQLGxbK+gJnnghpPnShS
rbvb0PpYD0cGc56Fy+AzLCI5BOqmh+hqibxYQ0BnpFyZ8/c3lvkvKTw+0o7xlAin
sm8CA3vt3mJ7ZlNc79+hTtqJPfuFrs0jVzGX3SoT3NySHfnP9LytfpzMUqAurGr5
ZDp/CeU//DJI2/Oey6LF
=EbEj
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Joanna Rutkowska wrote:
> On Sat, Mar 07, 2015 at 04:10:10AM +0000, Axon wrote:
>> HW42 wrote:
>>> Axon:
>>>> HW42 wrote:
>>>>> Hi,
>>>
>>>>> I developed (a prototype of) split-gpg for GnuPG 2.1
>>>>> (simply called split-gpg2).
>>>
>>>>> Since the newly released (see [0]) GnuPG version 2.1.0 the
>>>>> private keys are manged by the gpg-agent.
>>>
>>>>> For split-gpg this enables some nice new features:
>>>
>>>>> - you import public keys in the client domain. So no
>>>>> untrusted data in the server domain.
>>>
>>>> So, does this finally allow for signing other people's keys
>>>> without having to import untrusted public key data into the
>>>> trusted backend domain?[4]
>>>
>>> Yes.
>>>
>>>> If so, how does that work, given that gpg-agent can never
>>>> have access to the public key data?
>>>
>>> The key get imported in the frontend domain. I.e. the
>>> PGP-packet parsing etc. is done there. Only the cryptographic
>>> operation that requires the secret key is done in the backend
>>> domain. This is similar like Smartcards/HSMs are working.
>>>
>>> The communication looks like this (frontend >>> backend):
>>>

>>> [...]

>>>
>>> For more details see the documentation of the gnupg-agent
>>> protocol. It might also be helpful to look at the log option of
>>> split-gpg2 and the test.rb in the source repo.
>>>
>
>> Great! Thank you for doing this!
>
>
> [Resending using inline PGP signature, so Google Groups don't break
> it]
>
> There is, however, one advantage of sticking to the current Split
> GPG architecture (which requires import of all the untrusted keys
> into GPG backend VM) over this GPG v2.1 fully split model --
>
> Namely in the current Split GPG architecture the backend VM sees
> the actual document before it gets signed (as well as it sees the
> document once it got decrypted). This allows this backend VM to
> display it to the user, or generate a somehow meaningful log of
> events (for audit) of what documents have been signed and/or
> decrypted. The backend VM might use Disposable VMs to present
> documents-to-be-signed to the user (via qvm-open-in-dvm) to given
> even better control over what the keys are used for to the user.
> (This obviously would not work for git tags signing though).
>
> This is currently not implemented, but I've been thinking of adding
> this at some point, i.e. when-have-more-time (TM). And we can't
> have this when using the new, fully split model, because than the
> backend VM only sees the hash, which is really meaningless.
>
> joanna.
>

One kind of hash value which isn't entirely meaningless is a PGP key's
fingerprint, which is in fact the SHA-1 hash of a subset of the key
data.[1][2] We already rely on these fingerprints to uniquely identify
keys, so if this were the hash value which the backend domain sees,
and if the user could verify that this fingerprint is correct (by
viewing it in the backend domain before signing), she could be
confident that she's signing the correct key.

In fact, this could be taken a step further. There could be a GPG
command which accepts a key fingerprint as an argument, signs it with
a private certification key of the user's choosing, and outputs a
public "detached key signature" file. Anyone who then imports this
file to their public keyring will be adding the signature of the
signing key to any key which bears the fingerprint which was signed.
(Ex hypothesi, there will exist at most one such key.)

This functionality would allow for key signing to occur in isolated
vault VMs as well as on physically air-gapped machines. (It is,
therefore, of interest not only to Qubes users, but to everyone tasked
with safeguarding valuable certification keys.[3])

The best part of this scheme is that absolutely no copying or
transferring of any data onto the secure machine is required (no
qvm-copy, no inter-vm clipboard). In fact, we don't even have to use
split-gpg for this, which makes it ideal for use with a subkey
setup,[4] where the certification key isn't present in the split-gpg
backend domain anyway. The only required input is the target key's
fingerprint, which is manually verified and entered by the user.


[1] https://tools.ietf.org/html/rfc4880#section-12.2
[2] https://tools.ietf.org/html/rfc4880#section-5.5.2
[3] Of course, users of physically air-gapped machines don't have the
option of simply using qvm-copy to securely copy the resultant "key
signature" file out of the secure machine. If they use USB drives,
they jeopardize the secure of the air-gapped machine, but if they
write the file to blank disposable media, the situation looks better.
[4]
https://wiki.qubes-os.org/wiki/UserDoc/SplitGpg#Advanced:UsingSplitGPGwithSubkeys

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU+vY7AAoJEJh4Btx1RPV844cQAO7EN8XyBOMOEUVRU5Ee7/mg
9LU/pLe9O5uzajdL9q7Ps+ZdMLcDCZMe6OZLlApc6HZC0ohDCVxTolJMHzRstY+u
INJa/IOewHPTUSIC7hy6/senC3jIHmYJEMjx2kahjBoj72XyWaMFv0a14ZYKPjGv
hIZzHGG5m/xbKt0eVj4A+czDrzgFmxjDunmZOBlDXV5HzYh/KmYW0agsm6Aqezg6
jddwr+/4aR5DETlvY/ruNcmJ8wwVJkpKVy8kIeM3OYjet+dT+II8hbbIfyVy3e5k
ZMjzPyKlE48IImJSZWzCpoTsrnsWhKHwlYs1zBa3U+LLCx40mvp4NVh6iTnwhR/T
c6zuXdR/AzfW81Uz0pHi1E4AITIXZu5Dkr25Dii6sxZMa6Wsvgjfbb8d3C/dUoId
cTUTdFZ8ww9POUnwZsjoo0JNuadZFaDFSfEK6hD41B+Yg5+nI8kurTd+Np3QVWmx
7/GHpLujR3tJpRVH8ZXxJEri0PazLDUJdUnJA75t8ogKGYRWO5M8JfBVurWLyOXl
3FGONPqA5RdP+nvC6O47iTOy/PZDV5YddBwC0/Gw3GtCJ5v1QYEUA7DVsld4phQy
GOS9GPPUWivxUXVKDB8r5G/m3bBko/vLsr+1FHwszmIljLYl1hLnAQsyXbxcK8n7
+HzJ1Tu5bMwIOJV22o0B
=XWoI
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

Actually we can have the feature of document preview before signing in
new model. This will be just somehow more complicated to implement, but
still doable and IMO more secure.

If you want to sign the document, you can send:
- the document to the DispVM, using some new qrexec service
(qubes.GpgDocumentPreview)
- its hash to the gpg backend domain (as part of gpg-agent-like
protocol
Then qubes.GpgDocumentPreview service in DispVM will calculate the hash,
send it to the gpg backend domain and display the document.
Gpg backend domain will receive hash from two places:
- source domain (inside the gpg-agent-like connection)
- DispVM used to preview the document
It those two hashes match, service in a gpg backend domain will ask the
user for confirmation and then sign the hash.

One advantage of this approach is that gpg in a backend domain will not
parse the whole gpg file (which you've seen is a quite complex process).

Practically it would still require some wrapper at the client side to
actually send the document for preview, but it could be much simpler
than current split-gpg client, because it doesn't need to understand all
the options, only --sign and where to look for the document path.

You can't do the same for decryption though.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU/PioAAoJENuP0xzK19csJxMH/22B5gK67Y5L2O3Q0SjJGx9b
RguIsdqr2hA6qCXK7YqUYjVp7dDJFBpRbfkQs42kRmDfgWf9U7mBmd3aMUTI2uDW
EoRNL9xLbpVHwleXWdWHbwS91ln1CW67af9c6a+RDB1DC5PQs/zGJ0tdPBfYsBXT
MfHuk598T/qv/FLGlzoXyys/H0VsRq8jedCDwNhEL+t+VZKRpThh9Dc4aYtTphR0
RRGDBx2eNbKhU7ZrvAv3mGoCcrqPMx2IRVzCdtS3g8sNLXfTtrTXHzY5CY+1D+xT
Rz/FxIPzykaJ1nU+7r9S76f4r/X4MngNRV1Jw0+yaZc/ppzlfzovTx/B8/C8JO8=
=jRdg
-----END PGP SIGNATURE-----

[HW42]

Marek Marczykowski-Górecki:

What is your thread model in this scenario? Do you want to verify that
the signed document matches exactly the document you want to sign (I
think this is in reality hard for anything larger than a short mail). Or
is your intention to make sure you don't sign a completely different
document than you assume.

As Marek already pointed out this can achieved with both setups.

> Actually we can have the feature of document preview before signing in
> new model. This will be just somehow more complicated to implement, but
> still doable and IMO more secure.
>
> If you want to sign the document, you can send:
> - the document to the DispVM, using some new qrexec service
> (qubes.GpgDocumentPreview)
> - its hash to the gpg backend domain (as part of gpg-agent-like
> protocol
> Then qubes.GpgDocumentPreview service in DispVM will calculate the hash,
> send it to the gpg backend domain and display the document.
> Gpg backend domain will receive hash from two places:
> - source domain (inside the gpg-agent-like connection)
> - DispVM used to preview the document
> It those two hashes match, service in a gpg backend domain will ask the
> user for confirmation and then sign the hash.
>
> One advantage of this approach is that gpg in a backend domain will not
> parse the whole gpg file (which you've seen is a quite complex process).
>
> Practically it would still require some wrapper at the client side to
> actually send the document for preview, but it could be much simpler
> than current split-gpg client, because it doesn't need to understand all
> the options, only --sign and where to look for the document path.
>
> You can't do the same for decryption though.

When actually implementing this you should keep in mind that by default
every VM can run anything in a DispVM. This means the user can't
distinguish qubes.GpgDocumentPreview and qubes.VMShell (later could show
any document).

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[This time with inline PGP]

Marek Marczykowski-Górecki:

What is your thread model in this scenario? Do you want to verify that
the signed document matches exactly the document you want to sign (I
think this is in reality hard for anything larger than a short mail). Or
is your intention to make sure you don't sign a completely different
document than you assume.

As Marek already pointed out this can achieved with both setups.

> Actually we can have the feature of document preview before signing
> in new model. This will be just somehow more complicated to
> implement, but still doable and IMO more secure.
>
> If you want to sign the document, you can send: - the document to
> the DispVM, using some new qrexec service
> (qubes.GpgDocumentPreview) - its hash to the gpg backend domain (as
> part of gpg-agent-like protocol Then qubes.GpgDocumentPreview
> service in DispVM will calculate the hash, send it to the gpg
> backend domain and display the document. Gpg backend domain will
> receive hash from two places: - source domain (inside the
> gpg-agent-like connection) - DispVM used to preview the document It
> those two hashes match, service in a gpg backend domain will ask
> the user for confirmation and then sign the hash.
>
> One advantage of this approach is that gpg in a backend domain will
> not parse the whole gpg file (which you've seen is a quite complex
> process).
>
> Practically it would still require some wrapper at the client side
> to actually send the document for preview, but it could be much
> simpler than current split-gpg client, because it doesn't need to
> understand all the options, only --sign and where to look for the
> document path.
>
> You can't do the same for decryption though.

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[Sorry for spaming. But my MUA failed to properly sign the last mail.
I hope this time this works as expected]

Marek Marczykowski-Górecki:

What is your thread model in this scenario? Do you want to verify that
the signed document matches exactly the document you want to sign (I
think this is in reality hard for anything larger than a short mail). Or
is your intention to make sure you don't sign a completely different
document than you assume.

As Marek already pointed out this can achieved with both setups.

> Actually we can have the feature of document preview before signing in
> new model. This will be just somehow more complicated to implement, but
> still doable and IMO more secure.
>
> If you want to sign the document, you can send:
> - the document to the DispVM, using some new qrexec service
> (qubes.GpgDocumentPreview)
> - its hash to the gpg backend domain (as part of gpg-agent-like
> protocol
> Then qubes.GpgDocumentPreview service in DispVM will calculate the hash,
> send it to the gpg backend domain and display the document.
> Gpg backend domain will receive hash from two places:
> - source domain (inside the gpg-agent-like connection)
> - DispVM used to preview the document
> It those two hashes match, service in a gpg backend domain will ask the
> user for confirmation and then sign the hash.
>
> One advantage of this approach is that gpg in a backend domain will not
> parse the whole gpg file (which you've seen is a quite complex process).
>
> Practically it would still require some wrapper at the client side to
> actually send the document for preview, but it could be much simpler
> than current split-gpg client, because it doesn't need to understand all
> the options, only --sign and where to look for the document path.
>
> You can't do the same for decryption though.

When actually implementing this you should keep in mind that by default
every VM can run anything in a DispVM. This means the user can't
distinguish qubes.GpgDocumentPreview and qubes.VMShell (later could show
any document).

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU/awIAAoJEOSsySeKZGgWtCIQALMmXyoMUNiP3c05jION9gnI
K3PGuroZyLc7vaGg+SE0uXEImJ5of6SNsryEgPBQLQ6owAaehqpJJ1Vt6bR8cSUx
CEn6Sv9DOWsk3NPl6Ffo5fc467uGNtfsugJMuJAFpzPJJwnpbmuk7hH+celnQMkI
x/nty6o69xC79YwZGxJFHeYmoVmMLTPV8qhWCp0cEdDMDiZpreb3dDc6sOfXV8hL
RUmPh6y+98SSyv0C0E75l1rXq7e7TDAKu0w5n7Wi+7n0ohCZJhw2asyMadSi3IOK
/4iRirWYVyLQP6Xn1RavK9V5dCQKyq5G2LgBJ4ykV0Hhls4DUv2oI6uR1mnNgmEx
ab1oLs3qV6IerBQl/2h9pIsm+t/M3Ndf+cBq4Y0y1KnZIZmyRAPF+57LRjE3AUQ2
Zb3YrbnSsZSyWmJ/RkWd6TU5D2/6jGpMla4OnCesKVrK7VxKw8y4AwaMekBftwfi
WiHVJKLEub48c1F2NQPeQVvFT8PEjeuqqkW8GC97jbEudsK1eW1/onTAVOVUD8uK
KffuVmXxYu+3nXP4e35VyRmg1ljMGjk4siR3nC0moJ/3KeEB2mNnuQNobXX5EFHy
LsfNwD5j96+S41YD5BNssBY3VWrDZwtBvofS/VYuHggRZ3ZvDChgG7FtflsSjiBo
jHjIZcAiRDP/j1GmOX+s
=4gHi
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2014-11-12 19:35, HW42 wrote:
> Hi,
>
> I developed (a prototype of) split-gpg for GnuPG 2.1 (simply

> called split-gpg2). [...]

Hi HW42,

What's the current status of this, and what more needs to be done? Are
you still working on it?

Issue: https://github.com/QubesOS/qubes-issues/issues/474

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXWejVAAoJENtN07w5UDAwBnoP/iAm9QzNxgj+CH3OWxbnQVpx
uSPD4U6+1kb2pxLQHWJyP5lQYCJbZJSPfBmqNqGVT8n8PiPXg7kWAoXcOrd1IoFO
d6YIPYsZ6pPcHordgQIZ97lBkkXOr6Sa7uOHVSGpl1qXAyqXoEMJP6aIBfuGBfUx
pzHywG1fQMsNpk/dXUsY5Nn12T1GtXO0Rdi8Rn7WqHpHKYsYSCiJlw+AgzjuDhfZ
4Gxm8zrABS/b7Ky7ox61I8u6pdataWsAhJJKFF1G10sy7aHujHSraZz1IJUvU41I
PwH1KNx8LA7u3WCH0woGw3qa2dgwtquJjoZarxr8hfpQY/e1QmRU8w7SCTppEs7W
PGCgBDGV7MnUTfbALSiZVPBAQNfjKS2Wq/cE95+HLCQrVNzfSdT0qhVRtG+Lw3Nb
nXv1WRnMjI6ys3GVMa8lSYhgcTS3TLGyNQDjew4HCV2pnWJfulWeGTrMTjwYnGa1
RbzzavXOrAx5aNetctNYLr7xdLGp4mxPyBJKyuSy153UGFDvwitrqA03YQhH/IR9
G4b9nYpsRSzlVErejwJatv1Z1oLOdZvazMmJwwl0i+7EIEcLoyT4GkTuVpD9aWxw
BqiGg0foq5AMqInFn4lsRo4XqAk5+dgoroateTk985plBxuf8GZm2Z1LK17LnOwd
PMyi1dZNPOpwRfp3HMlN
=zITZ
-----END PGP SIGNATURE-----

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Andrew David Wong:

> On 2014-11-12 19:35, HW42 wrote:
>> Hi,
>
>> I developed (a prototype of) split-gpg for GnuPG 2.1 (simply
>> called split-gpg2). [...]
>
> Hi HW42,
>

> What's the current status of this?

It's currently nearly unchanged since I created it. I have been using it
since then.

> and what more needs to be done?

I wan't to change the way how the gpg-agent replacement on the client
side is started and by the way fix the case when the user doesn't answer
the accept dialog.

Marek proposed to ask per key. Currently it asks only once for all
accesible keys.

A qubes-builder Makefile needs to be added (packaging it self should be
(mostly) done).

It might be useful to reimplement it in python so it better fits into the
Qubes environment (for example rubys regex behave a litlle bit different
then pythons).

> Are you still working on it?

As mentioned above it has been untouched since a while (especially the
last months I didn't had much time in general). But I'm still planing to
work on it.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXWfJyAAoJEOSsySeKZGgWeQYQAI56QtO73kea8Jd3JgY5mm7q
Cew9FyDEhfcimp1Gmq9oJDKpPU/mhSvj1PvCAYOmMpf76rtxfx4gY/QgFeMl9Epn
X425557yF5TnzOh2ad8vs664yamtwXt1XAv+FwNFpQFuvvKJBgsd2neUvjQtX7Ow
O0slQ5ZiVpaBWiijBcYUBkmAnM7uma17rVmA2VxQDGPlna4p23a2bXGIsGwJa5kk
sWZX3hEnmNGMd827Re+6ANdfpYD+BYoo4bxln+jlBLUqavG2d7j2/+15XMerqSbX
m7uXp79CwkAIeKsM5xpiWv1XnW5kzvPkVfqcnQTD9j7Fcrc9+fsvAyvwAnfa7yVb
wIe59PAys0wN01SAec8jgUAs9lwNTXxpe5XsDRgjCv6pjXoV4yk4dLsLBBmIQj5c
NbmTzcwRTt9UmseUEWKfrfFnKjTxB21N4N8hg9kHCV5rRoFGKV++sOzQVtIvosPU
Z/nFH8FbLowRn/dJR4dTGOdU+crFtY/W1C7zn0cBicw8Iv3iY+eOBL/fZYEDDDWK
MPU3KLAP6XhzMp+5AB9a4ugfHWunY5C62tOjdTImBh++n6ex+IIuUzut21ep45WY
DnlYjiobLrPeaNdESYFfjYTKRH8FfHTOgcfvMkjyQUvJw0E2tphmQk0/ZNDg7BGs
vPUGGWNYLGH64bDV9EQu
=TI7g
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Great! Thank you!

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXWfQMAAoJENtN07w5UDAw3MoP/3JRhn5OxHGDENgYy+T/9Nve
DhjeKT9GybW0F1sfUTu/S63jeTGqARHaWt1Ql523tthjzg9R+oW1v2XC9/piJvBs
Cw84aQ7AjERoc2C4N87PFWOwETIJlU27HEzgCuMmEjQ5M+d/ESBqAs14VCNFO031
2r5lzE64shy0aJUgAhqNBMBcwhgBKH1goO9VHj/JMWvf8FybZpzWIwpwc7QusK3y
qCheeoGHMRYGSON9IYG9vvTNGMLyaswHeX9Xfzg3gS3mgREs84mn7ucgsaoLbTra
prLfA1vA1PeQCc43X3oppeCxjTAlfXa4jqFAl9ST1xA95VXbJBvuWdvVykl1j8eh
XwWaj3KvOapjwCcBQ7G+vPliMRjewfSNV7sJATf3lDzdALPwcdlPpu/iHDdqmKwO
8Y7JdZZ5yWri5dwHDfQISBkQ89HUw/9+cJsiNUxNLAOwgwchpY3jhz/pM7yJ3oup
pbZvfH9UDHoBjZ04hv+oxD/voldZO5wgZvS+lrCD05AWAihLZ84fUPiYYU20wJSt
va7TpM5Sj7bZWQlIucdE7BX5jN4ZQgrawUaY5QDnDBoHslYRmYannY4f/eKIVyGv
fobRbVLnS28cjLYbv3QleT4qSqjdKqHTjr3PEdrRQWCUSKkyhZm6fTMpuOkrqttA
uucWu66ALnqAPJktdtL3
=W85W
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Jun 10, 2016 at 12:49:23AM +0200, HW42 wrote:
> Andrew David Wong:
> > On 2014-11-12 19:35, HW42 wrote:
> >> Hi,
> >
> >> I developed (a prototype of) split-gpg for GnuPG 2.1 (simply
> >> called split-gpg2). [...]
> >
> > Hi HW42,
> >
> > What's the current status of this?
>
> It's currently nearly unchanged since I created it. I have been using it
> since then.
>
> > and what more needs to be done?
>
> I wan't to change the way how the gpg-agent replacement on the client
> side is started and by the way fix the case when the user doesn't answer
> the accept dialog.
>
> Marek proposed to ask per key. Currently it asks only once for all
> accesible keys.

Especially when qrexec (in Qubes 3.2) got support for argument to which
you can apply policy:
https://github.com/QubesOS/qubes-issues/issues/1876
https://www.qubes-os.org/doc/qrexec3/#service-argument-in-policy

This would allow setting a policy to access one key but not some other,
without creating per-key backend VM. Somehow less secure than separate
VMs, but also much more resources effective.

> A qubes-builder Makefile needs to be added (packaging it self should be
> (mostly) done).
>
> It might be useful to reimplement it in python so it better fits into the
> Qubes environment (for example rubys regex behave a litlle bit different
> then pythons).

This is currently the main reason why it isn't included even in unstable
repository. I don't know ruby enough to review it...
Anyway, even if someone would review it, it would be better to not
have just another language in Qubes components, exactly for the reason
above - to make review easier (not require knowledge of all the
programming languages).

> > Are you still working on it?
>
> As mentioned above it has been untouched since a while (especially the
> last months I didn't had much time in general). But I'm still planing to
> work on it.
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQEcBAEBCAAGBQJXWfYGAAoJENuP0xzK19csInoH/ie+xdrhKpmSacUrnPgJPAqc
n59nKR3S8+4t+R2+WaihdIbgW80k67uBOX+hbnonGQBMgm8LJNplUjXewwBe0nUl
egBkbmcP14144Fl8qpjXFuwSdz9ux6Mq7pcfGPAsXsdm7vM+hFY3WXKhbN1k5rkm
yIqXMCtUXjZziS6LY2qKQBbOi61CSx6hm54JxYRzgWW+mNnOgXULHNMgXfDIFctJ
Mk8fwbM2XquBSTbyu7+aFFBbFc+jWXSUe8JutOe61cg4NBRWYxXR2zDt1QH3ZWNn
bqP6n2ktSBpceS0ZwS0LB8hAmrGhfAaukopFiNLyOaJarnfjXvn9J47/7vFyHCE=
=9l99
-----END PGP SIGNATURE-----

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> On Fri, Jun 10, 2016 at 12:49:23AM +0200, HW42 wrote:
>> Andrew David Wong:
>>> On 2014-11-12 19:35, HW42 wrote:
>>>> Hi,
>>>
>>>> I developed (a prototype of) split-gpg for GnuPG 2.1 (simply
>>>> called split-gpg2). [...]
>>>
>>> Hi HW42,
>>>
>>> What's the current status of this?
>
>> It's currently nearly unchanged since I created it. I have been using it
>> since then.
>
>>> and what more needs to be done?
>
>> I wan't to change the way how the gpg-agent replacement on the client
>> side is started and by the way fix the case when the user doesn't answer
>> the accept dialog.
>
>> Marek proposed to ask per key. Currently it asks only once for all
>> accesible keys.
>
> Especially when qrexec (in Qubes 3.2) got support for argument to which
> you can apply policy:
> https://github.com/QubesOS/qubes-issues/issues/1876
> https://www.qubes-os.org/doc/qrexec3/#service-argument-in-policy
>
> This would allow setting a policy to access one key but not some other,
> without creating per-key backend VM. Somehow less secure than separate
> VMs, but also much more resources effective.

Yes. There are two possible ways to separate per key in the backend VM.
One way is to run different gpg-agents in different GNUPGHOMEs (that's
already supported but you can only select based on the source VM name
due to the lack of policy arguments). The other possibility is to track
which key is select for the requested operation.

The solution with different GNUPGHOMEs has the advantage that it is more
secure since there is no risk that the filter and the gpg-agent
interpret the protocol differently in regard to which key is selected.

The downside of multiple GNUPGHOMEs is that gpg2 (running in the
frontend) can talk to only one gpg-agent. So you need to decide which
GNUPGHOME on the backend should be used. Therefore you can't
conveniently allow a VM access to multiple keys and get asked per key.

Both variants can be combined. For example allow access per GNUPGHOME
based on the policy argument and then ask in the popup per key in this
GNUPGHOME.

>> A qubes-builder Makefile needs to be added (packaging it self should be
>> (mostly) done).
>
>> It might be useful to reimplement it in python so it better fits into the
>> Qubes environment (for example rubys regex behave a litlle bit different
>> then pythons).
>
> This is currently the main reason why it isn't included even in unstable
> repository. I don't know ruby enough to review it...
> Anyway, even if someone would review it, it would be better to not
> have just another language in Qubes components, exactly for the reason
> above - to make review easier (not require knowledge of all the
> programming languages).

Ack.

>>> Are you still working on it?
>
>> As mentioned above it has been untouched since a while (especially the
>> last months I didn't had much time in general). But I'm still planing to
>> work on it.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXWf6RAAoJEOSsySeKZGgWtR0P/1BChNSSrSQ29/BV04uVnbgx
4BI6gmrBB2yYKAlBdQ3oOowxB6LXBJaFPBVPGxRdu4JFDVL/FPKDDwz27kHHamX1
NPh95hBTbbSglTQIu6xY2MJ0iuPGbPW6wjNJ8Dbea4V4KKOyywsntQAQdOOiRPe+
UadBOkE5bFqxnSxTdH8k0C/xwDpWNyKMTOQYSBqSH2KWDjgaPyxaQPkHJ0J6fSUh
0Kn6zBltSl4GezUT0tLUT6YTO+FZ0RhpCiOUT1Am2GdB45pFK1Mglf71D63I0mCT
gSj4eMK2PjqUElzyYpyauG6QDCveVe1kmr3QRig5GJ90i0wKH9LQib+LBrfwihd7
X8IKWTwagkxGPvuir9H3s49OBRsOt89YUrDtJCkTnjmyPgPHsFJphBCoA8XVkofW
erh1GZlhiJ2LbUPgHRSaSB/FsfCLXAkWIPL/L2fAvatnWFP44QIy7XQOlzhMj1co
QcNzqBI5s/W926TgqJyINzEkEBnF6Usjdxz3zkX4pAUG6JxqetzOdIqa5wbNPhA8
WgKBDksZOHearXRqyT0hhX8kynzlGmBhF+Hm0Cl+aUnQm57q1pe3BRk0LaqF59+h
GxPuSj7qcRKHZARWnK/V54z7GX54DJ2z4rMiljruApGiCWzb5h7wUhYlRxA0V3n7
znJNhFb2k7xAb0bXvZvm
=mtQV
-----END PGP SIGNATURE-----