-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Jul 13, 2022 at 01:56:54PM +0200, Simon Gaiser wrote:
> [ 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.
My primary concern is a case like this:
1. Somebody either uses split-gpg1 or simply wants to protect their
private keys from being extracted and used without authorization.
2. With split-gpg2, an attacker controlling client VM can generate own
key and get it signed with your primary key.
3. They can then push new subkeys to some keyserver to have them
distributed.
At this point, it isn't that helpful that you still control your primary
key, attacker have a subkey they fully control and you may be not even
aware of that. If they manage the key distribution part, nobody else
will see anything suspicious.
> > 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.
This indeed makes migration easier, and is exactly the thing we should
recommend. I think we should adjust defaults to make the scenario
described earlier unlikely to happen by mistake.
What about something like this:
1. Make default gpg homedir for split-gpg2 backend something else than
~/.gnupg.
2. In the migration guide include step to generate subkey for signing
(the one for encryption should be already there).
3. In the migration guide include step like:
gpg --export-secret-subkeys | gpg --homedir /default/split-gpg2/gpghome
--import
4. Maybe even consider an option (default enabled, but possible to
disable) that does the step 3 automatically. Either if the split-gpg2
homedir doesn't exist or if secret keys in the default keyring are newer
than in split-gpg2's.
I'm not sure about the last point - it may make key management a bit
easier (for example for those preferring to create new subkeys instead
of extending expiration of existing ones). But on the other hand, one
still need to move public part around(*), so it doesn't eliminate all the
manual steps...
(*) Maybe split-gpg2 should include a separate qrexec service that just
exports all the public keys from the backend? It could save the user one
qvm-copy call...
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmLOyjIACgkQ24/THMrX
1ywntwf9Fh6CObD3ZZRFWm08bkXJYld8C4oap2FqVJ2UuHJfO8GG1LWC+l8TDeCi
duXaHxHK/BfCdxhiMDxrpPL63wam64s56PFjSalr51ranEyCLlm+GF3Qgp7PE+av
xgblUBg9IqbqOGyFrcWELa9667OxS5Uq5JTmiisNJfwToBRBVgSfw0rzxcbNpErU
Nej/dO7eCrw0YL9L7unbvyLj/Gk6Z833Tn446wfa0UAd2TK1oB5tvcoF9umLleCn
pXN+RJuoKDYgatsF4txh3+OO8qufn/wPyUmnspFMeOJ+x3NjpUSt+GaTyKdljaBm
pEH3M1mvvmTj2QhRcuHitAtLnACq+Q==
=28dJ
-----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/Ys7KMlhEYz9e3CFx%40mail-itl.
