Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, Jul 20, 2022 at 03:34:24AM +0200, Marek Marczykowski-Górecki wrote: > On Tue, Jul 19, 2022 at 07:40:00PM -0400, Demi Marie Obenour wrote: > > On Wed, Jul 13, 2022 at 03:35:46PM +0200, Marek Marczykowski-Górecki wrote: > > > 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... > > > > Moving the public part around can be semi-automated, as you suggest. > > Generating the subkey is also easy if the key is stored in software, and > > it might even be possible to write a script to do it. > > > > The main problem is smart card support. OpenPGP smart cards typically > > have three key slots: one for signing, one for decryption, and the third > > for authentication (often SSH). If all three slots are in use, it will > > not be possible to generate or use the subkey on the card. Generating > > the key in software would work, but it loses the advantages of the smart > > card. > > That's a valid point. But also, if you have a smart card, you have > already more or less the functionality of split-gpg2 there. The main > difference being a confirmation prompt, but some security keys provide > this too. So, there is little (not zero, but little) point in combining > split-gpg2 with a smart card. IMO the main use of split-gpg with a smart card is to avoid having to expose the smart card to the (untrusted) frontend VM, which might try to do nasty things to or with it. This is especially true for YubiKeys and other multi-function devices. > And also, you can avoid the issue > discussed here the very same way - by having separate card with just > subkey(s) - instead of just separate homedirs. > In short - I wouldn't worry about slots availability too much. It is > something we should probably document in the migration guide, together > with workarounds (separate offline storage/card for the primary key, or > software storage for some subkey). > If many users will be affected by this limitation (and unable/unwilling > to use workaround), we may consider some alternative solution. But I > kind of suspect it won't be necessary. > > > To work around this problem, I think we could provide a split-gpg1 > > variant that only supports a subset of safe operations. > > --list-keys, --list-secret-keys, --export, and --sign (with hex UIDs) > > should be safe. --encrypt should also be safe, but it is not very > > useful without the (unwanted) --import. That said, these operations > > should enough for Thunderbird, which does encryption internally. > > Decryption can be handled via split-gpg2, with filtering to prevent > > attempts to decrypt with a signing key. Attempts to perform operations > > that the split-gpg1 subset does not allow would be handled via > > split-gpg2, by exec’ing GnuPG directly with the appropriate sockets set > > up. > > "should enough for Thunderbird" - that's exactly the thinking that got > us to the current situation with split-gpg1. Even if a static set of > options will be enough for all the future versions of TB (which I highly > doubt), there are other applications that users expect to work too. Note > the main issue about options filtering is not about the main command > options, but all the auxiliary options. Thunderbird is a special case for two reasons: - - It uses gpgme, which only uses a small subset of the possible options. - - It only performs private key operations with GnuPG, and handles the rest internally. Therefore, we could support Thunderbird quite easily. I personally have qubes-gpg-server invoke a Python wrapper that does some additional filtering, and this wrapper only understands 36 long options and 10 short options. Some of these options are actually not used by Thunderbird, but by my Mutt configuration, and at least one of them (--export-options) is not actually understood
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jul 19, 2022 at 07:40:00PM -0400, Demi Marie Obenour wrote: > On Wed, Jul 13, 2022 at 03:35:46PM +0200, Marek Marczykowski-Górecki wrote: > > 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... > > Moving the public part around can be semi-automated, as you suggest. > Generating the subkey is also easy if the key is stored in software, and > it might even be possible to write a script to do it. > > The main problem is smart card support. OpenPGP smart cards typically > have three key slots: one for signing, one for decryption, and the third > for authentication (often SSH). If all three slots are in use, it will > not be possible to generate or use the subkey on the card. Generating > the key in software would work, but it loses the advantages of the smart > card. That's a valid point. But also, if you have a smart card, you have already more or less the functionality of split-gpg2 there. The main difference being a confirmation prompt, but some security keys provide this too. So, there is little (not zero, but little) point in combining split-gpg2 with a smart card. And also, you can avoid the issue discussed here the very same way - by having separate card with just subkey(s) - instead of just separate homedirs. In short - I wouldn't worry about slots availability too much. It is something we should probably document in the migration guide, together with workarounds (separate offline storage/card for the primary key, or software storage for some subkey). If many users will be affected by this limitation (and unable/unwilling to use workaround), we may consider some alternative solution. But I kind of suspect it won't be necessary. > To work around this problem, I think we could provide a split-gpg1 > variant that only supports a subset of safe operations. > --list-keys, --list-secret-keys, --export, and --sign (with hex UIDs) > should be safe. --encrypt should also be safe, but it is not very > useful without the (unwanted) --import. That said, these operations > should enough for Thunderbird, which does encryption internally. > Decryption can be handled via split-gpg2, with filtering to prevent > attempts to decrypt with a signing key. Attempts to perform operations > that the split-gpg1 subset does not allow would be handled via > split-gpg2, by exec’ing GnuPG directly with the appropriate sockets set > up. "should enough for Thunderbird" - that's exactly the thinking that got us to the current situation with split-gpg1. Even if a static set of options will be enough for all the future versions of TB (which I highly doubt), there are other applications that users expect to work too. Note the main issue about options filtering is not about the main command options, but all the auxiliary options. > > (*) 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... > > It absolutely should for multiple reasons, not least of which being that > it allows for easily maintaining a shared public keyring. One can > maintain a shared collection of public keys in one qube, and other qubes > can import keys from it as needed. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmLXW6EACgkQ24/THMrX 1ywX+wf/YOC9+ITgbycY3ebCBuH00Pwe1tr13Bs/rxe1eNClwRnBSCdPpSKbYwcQ 2plQXFE7woIqw25diVYCWKnjAc6kQJdhpVCCkTrCOwntKSg/+54YmPXMzXr6Q3SJ p5uAvU9ej4RvQ+FZnviEQvIFEM5OmEFizabRssEwGrD7R8N5C6pvrRnbVBngMbCF I9XzVEo4PlgE/+lbm+erSm5AHf24JUvE9qwS6rkH9lO3tyRRARz1bPxxQwJwhybc EiyoiWqifWlo4CyaOQAs5xUpqlO6/BAOypmhV6Js27Gt2ksVd906iB7BkO6cKpdR dUhU0cHm5njGb26AEjYJ3Tl8dD9KSg== =mUrn -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, Jul 13, 2022 at 03:35:46PM +0200, Marek Marczykowski-Górecki wrote: > 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: > > > >
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-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 >
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-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
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-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-
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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/xly8FAmLOsMEdHHNpbW9uQGlu
[qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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. 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. 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. 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 - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLA9hgACgkQsoi1X/+c IsE4QQ/+Mrou3OjktLirktp3QsSB6SuINxoY+oSUScecz10SnQkyMORkn+D3xGZq Ed7xa8E1VIpws7KNHrqc01q5jW4OpccZSrHhnI2SMGdNGeo5r4BA+R7+YaSU40g2 iqJ1Blt15nT1QDl+fEwtO8bgWYrMiN5IYOiSKx+vrsBy83qnvWRp8CogO9Zr9JjW Bsg8qrWklsUT3/VCA+9zosBtjXx749NBZpdHMw/kK7ulhHvNrtcSMFDIx8Fyl5XH dMXV8Lj65zF/g70gOck/4EIfVuFzOFo3LmfiVXQgZFmn80q2hJe2Fr3G2N0troG5 V3+vg4+1ed1p3mPVhzZEfYkmBrEqKsma1CVTctmMMPLTdiHGojbjbd+U2zgqHM8w 8K/+aPL3/KCy6h9zIY0/aSyLgDueUfdgvsGwlA9GpumaX3lDjFF6SpnYPgrnysd/ 3bMSwXejSWpNwqIR5zmAllR5l23k1Oz0Y2fRMaHTeMhj/jqn/X9g1nNpCRckFkpu 899ihnmHl+otpyLavRusfctGFmnngBcjNJhIPrXAry5ECioOcIHC38GXX3xuLt30 ss6lNgGrMxQU/6pd89rRWlVGHiC3h6rkHI5v67bcOD9KPWNQEeQADRXYHgc8eDOi e5m7TFF/L1OGmZPwHChP4ae+pSXE7X791vOpnl9d7h3gfYQ3sKo= =wpg3 -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/YsD2GKbWSzVs8YYE%40itl-email.
