-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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. ]
Yeah, *especially* when one wants to attach files. > 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). In some ways, the situation might actually be worse. I am not sure if a smartcard will allow using a signing key for decryption or visa versa. I know that split-gpg2 will. > 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. I agree. I have just such a service that I use for signing git commits and RPM packages. I should clean it up and publish it at some point. It is only 60 lines of Python, and much of that duplicates what qrexec policy can already do. This *will* require an array of client-side wrapper scripts to adapt various programs, but this can be worked around. The wrapper script used for split-gpg1 might be a basis for some of these. > > 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. I do not consider this an adequate solution for two reasons. First, it makes migrating from split-gpg1 to split-gpg2 *much* harder than it would be otherwise. Not only does one need to generate a new subkey, but one also needs to create a new GNUPGHOME, configure split-gpg2 to use it, and make sure that only the subkeys have their secret parts in that GNUPGHOME. Second, I am not sure if --export-secret-subkeys can be used with keys that are on a (physical) smart card. It may be that in this case, there is no solution with split-gpg2 as it stands today. I do think that per-client GNUPGHOME is a good idea, as it makes using a single backend qube (often necessary anyway, due to memory limits) much easier and safer. However, I would like to see some built-in filtering. For instance, split-gpg2 could refuse to allow signing with a key that is not capable of signing, or which is capable of certification. It could also refuse to decrypt with a key not capable of decryption. The necessary information for such filtering is available in the output of gpg --list-secret-keys --with-colons. split-gpg2 already parses this output, so it should not be difficult to add such filtering. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLPAwgACgkQsoi1X/+c IsELPxAAsaxznd8SlfzMY0nyjKLJuCEbrNgcYcxhiWkfK7vO9VzlMg7dwQ9Z78O4 1MYmulpwtkGybYK/+O/xGrwZ8VjDFY86CtzLbLi0/jv1gDiQ9iU8FJ8lwEw05zCO uNSNMfyBMws40dxJZlsAIPj6lvc1FUDb9vkPi5z5G5KOTd6dVsXP1wRxall+6rXj pXTnS9EMi+9tXjIhpZat3hDHLrQbIoeZRVg7sfsb6S+r+izVMPOXpaT8pnCHXh4T 9cHFzTfmYnVA1S7sWP2Ad5q34UMOMuk9cMMMa+eQeEk6lnT9zbiB0WVdgM6mDImu 3C0U/B8zPUKiFRgnj+KJbKisOXCHTYj0WiQw1SXjNp6IgSu6F1L2fEp6S6E1ZjD+ grdrQ3uwGDxAVy80CT2PfFwk/kWHaeFRyAPylAwnItvR3r0rBsX8M1CeVFjt56A5 2FnGVQvPbmfirngT++QoFoTTE7Sp+NhLApjamT+pHayYSZ16hJj/xwek2+xRreUM aG/CNipeO/9Q9zIX8XAL3TYbpC9eaabmHDI4ZeZY+HykhAzhKMkzq1h6WgbzTWsI ky2V5h6IYHBt+iKlFOHkup7wEC1dBFwROkfbcUcUlGN+NFvawPsOYfOdpirNiK3G 4gSB2xg5eR5OAKPCtZSwICp45ZCX0zWYGm9dhsY5um1QnGvCl6c= =AwAx -----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/Ys8DCAFyBCAIzZ08%40itl-email.
