-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
[ Sorry for the previous mail with broken white space, hopefully fixed
now. Really annoying that Google Groups still prevents using PGP/MIME. ]
Demi Marie Obenour:
> split-gpg2 [1] is the planned replacement for split-gpg1 [2]. It has
> several advantages, such as much lower attack surface, support for all
> of gpg(1)’s options, and support for key management operations.
> However, the last is also a potential security concern.
>
> Right now, a compromised frontend VM can sign or decrypt messages with
> any key in the backend VM, but it *cannot* sign or revoke keys. This
> limitation is also useful, since a mail client (for example) has no
> need to perform these operations. However it is difficult for
> split-gpg2 to enforce this restriction.
>
> The technical reason for this restriction is that the “type” byte in
> an OpenPGP signature of a message is always 0 or 1, but other
> signatures use different types. The type of a signature is part of
> the signed data, so it is not possible to pretend that a signature of
> one type is a signature of another type. The type of a signature that
> GnuPG will generate depends on the options passed to it, but
> split-gpg1 only allows a subset of these options. The subset of
> options passed by split-gpg1 only allow signatures of type 0 or 1 to
> be created, and those are only valid as signatures of messages.
>
> Unfortunately, split-gpg2 does not see the data being signed! It only
> sees the hash of that data. Therefore, split-gpg2 has no idea what
> type of signature it is making: it could be a signature on a binary
> document, a signature of a key and user ID, or even something that is
> not an OpenPGP signature at all. For instance, gpgsm also uses
> gpg-agent, and so is also supported by split-gpg2. It generates CMS
> (Cryptographic Message Syntax, also known as S/MIME) signatures, which
> are different than OpenPGP signatures.
Correct. You need to think of split-gpg2 as a smartcard (that has one
acknowledge button). There are indeed things that are not possible with
the splt-gpg2 architecture that are possible with split-gpg1, for
example showing the data you are about to sign (only useful in a few
cases).
For such special cases I would recommend to use neither split-gpg
variants and instead use a dedicated qrexec service that just does the
needed operations. This also makes other things like for example an
audit log much easier. Of course you loose the "gpg drop-in" feature of
both split-gpg variants.
> The best solution that I have come up with is to not allow the
> frontend to use any key it wishes, but only allow it to use a subset
> of keys.
Exactly!
> Migrating from split-gpg1 to split-gpg2 would involve generating a
> subkey that is capable of signing data, but is *not* capable of
> certification (signing other keys, revoking keys, etc). split-gpg2
> would then be configured to only allow the frontend to use this
> subkey, *not* the main key. The frontend could still generate
> signatures of other keys with this subkey, but these signatures are
> not valid. If a program trusts these signatures, then either it has
> imported a key controlled by the frontend (in which case the frontend
> could have just generated its own key) or the program has a security
> vulnerability.
>
> Sadly, split-gpg2 does not have support for this — yet. There is no
> fundamental reason such support cannot be added, but right now
> split-gpg2 (like split-gpg1) either allows all access or denies all
> access.
That's not quite true. Yes they don't provide an option to filter keys,
beyond not importing them to your GNUPGHOME (I consider that a feature,
due to reduced complexity). But what you seem to have missed is that
GnuPG has native support for exactly this scenario, see the
- --export-secret-subkeys option.
- From the manpage:
--export-secret-keys
--export-secret-subkeys
[...]
The second form of the command has the special property to
render the secret part of the primary key useless; this is a GNU
extension to OpenPGP and other implementations can not be
expected to successfully import such a key. Its intended use is
in generating a full key with an additional signing subkey on a
dedicated machine. This command then exports the key without the
primary key to the main machine.
> There are various workarounds, but all of them are more complex than I
> would like.
>
> What are people’s thoughts on this issue? In the short term, one
> option is to use split-gpg2 as the backend for split-gpg1, which works
> fine. However, split-gpg1 is a maintenance hog with a lot of attack
> surface, so migrating entirely to split-gpg2 is definitely preferred.
>
> [1]: https://github.com/QubesOS/qubes-app-linux-split-gpg2
> [2]: https://github.com/QubesOS/qubes-app-linux-split-gpg>
-----BEGIN PGP SIGNATURE-----
iQJRBAEBCgA7FiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAmLOslMdHHNpbW9uQGlu
dmlzaWJsZXRoaW5nc2xhYi5jb20ACgkQkO9xfO/xly9jWRAApIFhQZ0hrOR7lm3z
ojy0cozG14GMEWmr2dh1rxWCxZEBJRQe4RmQCOBY3agp3jM9w7MGDzNlr3J3vIDm
ZM2rdptqNyOO2r2eT/HooWOMaxJXAj+obmSaNuBh2LL60s3ZI1NaqEWskFTqZt8D
8lNdy5W3/uPJIFIM/N6Tz0Y/n89x/2J7XzopyYw9iV634hYMWzAdgqU76tRNtCTi
xs67WTQNAUMo2KSZBmf/IOvoHEgJJAIXPUbguEiAQq/mLZnHMGkYp23TB5wRSs8w
VKd1zIKkZjfMQF3CWlw/RnnjG090gtYNZjp+uYFcwmAfIaUQwQKoyJ09Tol76Vql
WH2cz0CW8NLYPHaz6RHsz4bFOrLvrSOZHvP13yKUzj63W8v7CwOid9H90lskXL91
bWpcCxW/RNmiop1Zu5cehXR7QL6jGgWEpAyy4CDpL01VBKXIDlb1JINBWUCbmvYq
ITa+7gXn6Rqw9fpkmkQ2m/g+3KQnQ3kxNl6ojfYdBvenmoMVUHg+DTw1bu2zfbVQ
lbZ5L1jCqJ5Rj5jYC+0TyC/S9w4Ysjyty2zpJFWYtkYydiXJ4DBCm6hGelb7p60T
vQEiX4llCnbeG3hIiyHNCeTicXEJ40Kl6HDwmK/3n/wVoMEgRf3K3Ve6QJEp8Gow
qquXnRylc5fEqZeyy6gOQ6Z0TJM=
=5/ah
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/780d94c0-7ab4-99e2-94eb-a21f81c061cd%40invisiblethingslab.com.
