Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

[Thomas Deutschmann]

Hi,

I am really unhappy with this addition.

Another example for something that was not thought to the end and which 
was rushed and pushed to our users. Sorry for being late to this but any 
addition should really add a benefit. What is the benefit verify-sig is 
adding?

When mgorny started to propose this in #-qa, he used the argument to 
improve security of Gentoo because we cannot know if every Gentoo 
developer is really verifying distfiles or just copying ebuild to new 
version and let `repoman commit` fetch the distfile and be done with the 
bump. While I agree with the idea in general, i.e. when you would be 
able to provide an automatism for that, that would be a great addition.

But there is a problem.

You cannot automate trust.

And anyone who is trying to do that shows that he/she does not 
understand how signing works and because of the fact he/she will claim 
security was improved, security was actually lowered due to that.

How is that?

Because the statement you can get from a signature depends on the trust 
in the used key. I.e. you assume that the key used to create that 
signature is only accessible by the designated owner and that nobody 
else have access to it. In the moment you learn that somebody else 
gained access to that key, i.e. can create signatures using the same 
key, you can no longer trust that key. More important, you should start 
questioning previously seen signatures (if you take it serious you will 
distrust any files signed by that key and demand on a new signature with 
a new key where you managed to establish a new trust).

Short excerpt:
Code signing is nothing new. It is an important layer in Microsoft’s 
security defense. Even Apple is relying on signatures for their sandbox 
they introduced some years ago. But does a signature prevent anything? 
Of course not. StuxNet was signed with a valid signature from Realtek 
Semiconductor Corp. and switched later to a signature which belongs to 
JMicron Technology Corp when Realtek’s signature got revoked. A 
post-mortem analysis suggested that cybercriminals compromised both 
organizations and have stolen their development certificates, including 
the private keys used to sign the executables. In 2014, when Sony 
Pictures got hacked, attackers had signed the malware with valid 
certificates from *Sony*. But that is only the tip of the iceberg, see 
https://attack.mitre.org/techniques/T1553/002/ for more examples. My 
point here is, and I believe we all agree on this, that signatures alone 
are meaningless.

To add a meaning to signatures you must trust the signer that he/she 
will immediately revoke the certificate once he/she gets aware that an 
unauthorized third party gained access to the certificate. If we, for an 
unknown reason, assume that this will happen, we will face another 
problem: We must receive this information. If we do not know that 
something has happened to the key, we will not take any actions.
I guess you all still remember how you created your GPG key for Gentoo, 
don’t you? Do you still have access to the revocation certificate you 
created during that process? I am sure you do. But do you know how this 
process works? Right, you need to upload that certificate to a key 
server. But then 2019 happened. Key servers are dead now. You can no 
longer rely on key servers, especially not that once you have uploaded 
your revocation certificate that it will spread and reach users. Just do 
an easy exercise: Check who committed to Gentoo repository in past 6 
months. Now try to fetch the GPG key of all committers without using 
*.gentoo.org. Good luck! And no, WKD cannot help you with that (revocation).

Coming back to my initial statement that it is all about automatization.

The whole idea started with assumption that not every developer will 
verify the distfile (an assumption I share). But why should we trust 
these developers that they will keep an eye on upstream’s used 
certificate instead? That does not make any sense for me.

Another point I just want to mention was patch 5 of 6 for 
net-libs/miniupnpc. Did you notice that the ebuild will fetch public key 
via HTTP instead of HTTPS? This will create a chicken-egg problem here: 
We will record key information metadata the same way we store 
information about distfiles which is temper proofed. But because this is 
happening in an automatic way there is not just a theoretical chance 
that we will store an attacker’s key in our metadata because who is 
going to verify they key? The same developer we distrust (or where we 
just want to avoid to trust) that he/she verified the distfile?

Do you see the contradiction?

Please do not get me wrong. I like the idea. But I also understand that 
you cannot implement it in a secure and really working way -- you will 
always require a human paying attention. But now that we pretend, we 
managed to implement that and even show a fancy green message that we 
verified (any) signature, we actually lowered security because more 
people will now stop paying attention:

   - Previous developers who carefully checked distfiles will stop
     doing that.

   - Nobody will question anything because there is a new passed
     check.

In worst case scenario, we are now emerging a signed malicious package 
we could be aware of if some human would have checked upstream and 
noticed that release key was revoked. But this will not happen anymore 
because we rely that once we have recorded a key in the metadata that 
some system will tell us in case there is a problem. And what do you 
expect what will happen when after the download something will tell us 
“Oh, this file is not signed with currently known key”? Right, that 
developer who we do not want to trust that he/she verified the distfile 
will just add a reference to the new matching key which will silence any 
warning.

No, sorry. Security required education. You need to understand where 
security is depending on so that you know when you need to take action.
Every attempt to move this away from the user will actually add needless 
complexity, allow for new attack vectors and will not improve security.

The purpose of this email is to get this addition removed ASAP.


PS: I assume that the "Arch Linux is using something similar" argument 
will appear. I am not going to make an in depth statement about what 
Arch Linux is doing here. But they have a total different security model 
which you have to take into account. And please don't forget that we 
already have that working Manifest mechanism which isn't promising 
anything it cannot do.


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5