Smart cards, split GPG, and timing attacks
40 views
Skip to first unread message
Demi Obenour
Jan 7, 2019, 10:16:36 AM1/7/19
to qubes...@googlegroups.com
Looking through the GPG CVE list, it appears that GPG has a fantastic security record. This seems to jus Most of the recent vulnerabilities have been side-channel attacks.
Is it useful to use split-GPG with a hardware token to prevent side-channel attacks?
Also, is it best to use one signing key per project one is working on?
awokd
Jan 7, 2019, 8:15:57 PM1/7/19
to qubes...@googlegroups.com
Demi Obenour wrote on 1/7/19 3:16 PM:
the key by observing decryption leaks. So a hardware token wouldn't
affect that either way, because once the key is unlocked it still gets
processed the same.
> Also, is it best to use one signing key per project one is working on?
>
Again, not a crypto expert but if you're using the same development
workflow for all projects, don't see much security gain from separate
keys. If some demand a different, potentially less secure workflow,
those might benefit from subkeys. Hopefully someone experienced has more
insight!
> Looking through the GPG CVE list, it appears that GPG has a fantastic
> security record. This seems to jus Most of the recent vulnerabilities have
> been side-channel attacks.
>
> Is it useful to use split-GPG with a hardware token to prevent side-channel
> attacks?
I am far from a cryptographer, but IIRC those side channel attacks get
> security record. This seems to jus Most of the recent vulnerabilities have
> been side-channel attacks.
>
> Is it useful to use split-GPG with a hardware token to prevent side-channel
> attacks?
the key by observing decryption leaks. So a hardware token wouldn't
affect that either way, because once the key is unlocked it still gets
processed the same.
> Also, is it best to use one signing key per project one is working on?
>
workflow for all projects, don't see much security gain from separate
keys. If some demand a different, potentially less secure workflow,
those might benefit from subkeys. Hopefully someone experienced has more
insight!
Marek Marczykowski-Górecki
Jan 11, 2019, 8:06:52 PM1/11/19
to awokd, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Jan 08, 2019 at 01:15:39AM +0000, 'awokd' via qubes-users wrote:
> Demi Obenour wrote on 1/7/19 3:16 PM:
> > Looking through the GPG CVE list, it appears that GPG has a fantastic
> > security record. This seems to jus Most of the recent vulnerabilities have
> > been side-channel attacks.
> >
> > Is it useful to use split-GPG with a hardware token to prevent side-channel
> > attacks?
>
> I am far from a cryptographer, but IIRC those side channel attacks get the
> key by observing decryption leaks. So a hardware token wouldn't affect that
> either way, because once the key is unlocked it still gets processed the
> same.
Not really, if key lives on a hardware token, only it can perform
decryption/signing. So, if that hardware token is resistant against side
channel attacks, then split-GPG (or anything else) will not make it
worse.
> > Also, is it best to use one signing key per project one is working on?
> >
> Again, not a crypto expert but if you're using the same development workflow
> for all projects, don't see much security gain from separate keys. If some
> demand a different, potentially less secure workflow, those might benefit
> from subkeys. Hopefully someone experienced has more insight!
There is one more thing: if you use a single key for multiple projects,
then it's harder to distinguish those projects based on cryptographic
proof. Which means code signed in one project could potentially be used
in another.
An example: I have a qubes code signing key I use to sign my
qubes-related commits/tags. But I also contribute to other projects,
including also very simple patches, where I only fix one file and
definitely not review the whole repository. If I would use the same key
for both, then one could attack me like this:
1. Introduce a backdoor to some random software that I would likely
contribute to (or even create new one specifically for this purpose).
2. Wait for me to contribute there (all kind of social engineering will
help here).
3. Take my signed contribution and pretend the code belongs to qubes -
this may is quite tricky, and probably require breaking into my github account
(or github infrastructure) to place it under my (or QubesOS) account;
but even without it, it would help in other attacks.
With separate keys (having project name in key comment) that attack
wouldn't work, or would require significantly more social engineering -
depending whether you attack a machine or a human.
You may also take into account security of development environment for
each project. If one depends on a lot of software without reliable
integrity verification method (or, say, a lot of NodeJS package ;) ),
then such environment would be significantly easier to compromise, and
so the key used there (even if not leaked, then used from there to
sign/decrypt anything).
- --
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-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlw5PaQACgkQ24/THMrX
1yyotggAj6mbhIApmFSsajZ/Zjk1Lt49Lgnba5TXQDHgODwGp+i4QG3JqKVgHTma
QXvoTKsMZohuABe6wWiTxT/DvJJjUzpHAOEnj/XAzGm6mm8kJqZ/hih2pq7T7+qn
Oe+zOdLNPdS4olmLy/igw/V+CtjNhuWYKsSM7mCzSpRRIPGuG4IvhEX+WyHFDt6u
rMpCL2nNqRHcMo+Qve7/5e2IPnWFZPjDVsaeTiHpaAlFfzDVLUyg2qxGxamezuLo
fH6ZvUd1UOHntUCYWjeD7JpY05Y8P0dAPRsRlcW28eAKAeUy9cepQlLJeafRdYCo
b5e0pWhYe/DqZxMJKzVuSnJy2OpBeA==
=j4nW
-----END PGP SIGNATURE-----
Hash: SHA256
On Tue, Jan 08, 2019 at 01:15:39AM +0000, 'awokd' via qubes-users wrote:
> Demi Obenour wrote on 1/7/19 3:16 PM:
> > Looking through the GPG CVE list, it appears that GPG has a fantastic
> > security record. This seems to jus Most of the recent vulnerabilities have
> > been side-channel attacks.
> >
> > Is it useful to use split-GPG with a hardware token to prevent side-channel
> > attacks?
>
> I am far from a cryptographer, but IIRC those side channel attacks get the
> key by observing decryption leaks. So a hardware token wouldn't affect that
> either way, because once the key is unlocked it still gets processed the
> same.
decryption/signing. So, if that hardware token is resistant against side
channel attacks, then split-GPG (or anything else) will not make it
worse.
> > Also, is it best to use one signing key per project one is working on?
> >
> Again, not a crypto expert but if you're using the same development workflow
> for all projects, don't see much security gain from separate keys. If some
> demand a different, potentially less secure workflow, those might benefit
> from subkeys. Hopefully someone experienced has more insight!
then it's harder to distinguish those projects based on cryptographic
proof. Which means code signed in one project could potentially be used
in another.
An example: I have a qubes code signing key I use to sign my
qubes-related commits/tags. But I also contribute to other projects,
including also very simple patches, where I only fix one file and
definitely not review the whole repository. If I would use the same key
for both, then one could attack me like this:
1. Introduce a backdoor to some random software that I would likely
contribute to (or even create new one specifically for this purpose).
2. Wait for me to contribute there (all kind of social engineering will
help here).
3. Take my signed contribution and pretend the code belongs to qubes -
this may is quite tricky, and probably require breaking into my github account
(or github infrastructure) to place it under my (or QubesOS) account;
but even without it, it would help in other attacks.
With separate keys (having project name in key comment) that attack
wouldn't work, or would require significantly more social engineering -
depending whether you attack a machine or a human.
You may also take into account security of development environment for
each project. If one depends on a lot of software without reliable
integrity verification method (or, say, a lot of NodeJS package ;) ),
then such environment would be significantly easier to compromise, and
so the key used there (even if not leaked, then used from there to
sign/decrypt anything).
- --
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-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlw5PaQACgkQ24/THMrX
1yyotggAj6mbhIApmFSsajZ/Zjk1Lt49Lgnba5TXQDHgODwGp+i4QG3JqKVgHTma
QXvoTKsMZohuABe6wWiTxT/DvJJjUzpHAOEnj/XAzGm6mm8kJqZ/hih2pq7T7+qn
Oe+zOdLNPdS4olmLy/igw/V+CtjNhuWYKsSM7mCzSpRRIPGuG4IvhEX+WyHFDt6u
rMpCL2nNqRHcMo+Qve7/5e2IPnWFZPjDVsaeTiHpaAlFfzDVLUyg2qxGxamezuLo
fH6ZvUd1UOHntUCYWjeD7JpY05Y8P0dAPRsRlcW28eAKAeUy9cepQlLJeafRdYCo
b5e0pWhYe/DqZxMJKzVuSnJy2OpBeA==
=j4nW
-----END PGP SIGNATURE-----
demio...@gmail.com
Jan 12, 2019, 3:27:04 PM1/12/19
to qubes-users
That makes sense. How should one best handle GitHub accounts? One per project? GitHub does not seem to allow per-project SSH keys, sadly.
Marek Marczykowski-Górecki
Jan 13, 2019, 5:27:55 AM1/13/19
to demio...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Sat, Jan 12, 2019 at 12:27:04PM -0800, demio...@gmail.com wrote:
> That makes sense. How should one best handle GitHub accounts? One per project? GitHub does not seem to allow per-project SSH keys, sadly.
Actually, you can have separate per-repository key, called deployment
> That makes sense. How should one best handle GitHub accounts? One per project? GitHub does not seem to allow per-project SSH keys, sadly.
key. But you can't re-use the same key for multiple repositories, so if
you have a project with 5 repositories, you need 5 keys...
- --
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-----
1ywzWgf/c4ruiUidk5WARKvLGT0/2dM8Im17JJJy44+LaBw8EnK43YqxK9TK2fxz
kG9K7jwT7w5Ym8oi7mLDpTO0XmV4usf15Vvi2PUUQBIWdJNxJCIViwaFMY0zA79v
TKa/9EAbxi2JrZ16iP349yL1OWGxs2+bN+q7Mt3qd46BwQiUNHFJMKcxXXZ/iBGw
G11XgeB4bllW7HyjR9nfNUEVl38oTVlpoPoYq8NZuLC011TafMhRSFlEQQto+MkD
l9a600ifQCprSqWiUge9QiiJO3rtknTx7NnNdwgFnpfFMm2yIURGMVyJ9i3VxyE9
B0GWaB7FTzmISkNjnmIwuZOgA1niLg==
=+lka
-----END PGP SIGNATURE-----
demio...@gmail.com
Jan 13, 2019, 6:08:05 PM1/13/19
to qubes-users
That makes sense. Would it be okay to place them all in one VM and use QREXEC_REMOTE_DOMAIN to pick the key?
Reply all
Reply to author
Forward
0 new messages