1

A good practice is verifying software with a team signing key, to ensure the software hasn't been tampered with.

The problem

When I verify a download, I usually stumble upon the following message:

$ gpg --verify keepassxc-2.3.3-src.tar.xz.sig
gpg: assuming signed data in 'keepassxc-2.3.3-src.tar.xz'
gpg: Signature made Wed May  9 19:40:24 2018 CEST
gpg:                using RSA key C1E4CBA3AD78D3AFD894F9E0B7A66F03B59076A8
gpg: Good signature from "KeePassXC Release <release@keepassxc.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: BF5A 669F 2272 CF43 24C1  FDA8 CFB4 C216 6397 D0D2
     Subkey fingerprint: C1E4 CBA3 AD78 D3AF D894  F9E0 B7A6 6F03 B590 76A8

I don't really like this part:

gpg: WARNING: This key is not certified with a trusted signature!

gpg: There is no indication that the signature belongs to the owner.

Each time I want to install the software on a new device, or each time a new version is released, I need to do the same tedious job: I need to find the official page where I can compare the key fingerprint, and cross-check it with multiple other sources to make sure the official website hasn't been compromised. Not a good UX at all.

One possible solution

One simple solution is to certify the key once and for all, so the check (i.e. the "tedious job", remember?) is done only once. Once I've certified the release key, I can just quick check the gpg output of my freshly downloaded file: no warning --> file OK. Simple.

Even Kleopatra suggests to certify a key by comparing the fingerprint from the official website:

Kleopatra suggesting to certify a key by comparing its fingerprint from the official website

The question

I've read that it is not a good idea to sign a key from someone who you haven't met in real life. But usually, the release keys are not held by a unique person, but by a team, so it's kinda difficult to meet the people in real life.

Is this a good idea to sign a release key (after having cross-checked multiple sources)?

Morgan Courbet
  • 270
  • 2
  • 11
  • I've have rollbacked the title edit proposal because my question is not about PKI or self-signed root certificate. I'm looking for a way to check once and for all the possible authenticity of the release key. That way, I don't need to do the same tedious job of cross-checking multiple sources displaying the release key fingerprint each time a new version is released on every single device I own. Sorry for the confusion. – Morgan Courbet Aug 20 '18 at 08:15
  • Let me see if I understand the question. You have several machines that do not trust a PGP software release key, and you want to use this release key to verify some downloaded software. Instead of going through manual checks every time, you want to sign the release key with your own key (which all of your machines trust), so that it will be trusted by your machines since it will be reachable through the web of trust? But the problem is that your signature of the release key has to be sent to a keyserver for it to work, and everyone else that trusts you will also trust the release key? – AndrolGenhald Aug 20 '18 at 15:55
  • It looks like gpg's --lsign-key could solve the problem of new releases, though it would still have to be done on each machine. As for publicly signing it, since the key says it's from keepassxc.org, if you verify it with a fingerprint from that website (retrieved over HTTPS), it sounds ok to me, but I'm not really an expert on PGP. – AndrolGenhald Aug 20 '18 at 16:00
  • That's it. You understood the question. 1) --lsign-key can be a good compromise; thanks to highlighting this option. But it's this not as seamless as I wish. As you said, I need to perform the same operation on my multiple devices. 2) Can you explain why it is a problem to send the signed key to a key server? Isn't it the purpose of the WoT? If I trust the release key, other people that trust me can trust it as well, right? Plus, Kleopatra suggests me to do it. But other sources claim I should certify keys from people I know personally (i.e. I've met IRL). I'm confused. – Morgan Courbet Aug 20 '18 at 16:35
  • I assumed that you weren't sure about signing the release key because you trust it yourself but you don't want others trusting you to trust it, which, looking back, was a pretty bad assumption (as I said, not a PGP expert here). – AndrolGenhald Aug 20 '18 at 17:46

3 Answers3

1

The idea is the same as a public key infrastructure. The Root certificate authority (self-signed) signs the signing key. Root CA --> signing key

In the event the signing key is compromised, it can be revoked by the root CA, another signing key can be issued which is signed with the root CA. Then you can ensure the new signing key is issued by the vendor. It creates a chain of trust as we use with HTTPS. I am not saying a PKI does not have disadvantages, direct compromise (root CA) being one, but it allows for automation, easier validation and does not directly expose the self-signed certificate.

How to build your own PKI

Notice the Root CA is offline, which should greatly mitigate the risk of compromise.

is: is this a good idea to sign a release key (after having cross-checked multiple sources)?

This is quite a delicate answer. As the signing (release) key needs to be validated, otherwise, we could be downloading potential malware, and believe it was released by the vendor as the package is signed. My opinion is, the more sources we can validate from before using the signing key for long-term use, the better.

What happens if my signing subkeys are compromised? should give some insight.

safesploit
  • 1,867
  • 9
  • 19
  • Well, I am aware about the PKI, but it's not what my question is about. Let's take a concrete example. I've downloaded KeePassXC source code (a .tar.xz file). The team provides a digital signature with it (a .sig file). They provide a guide to verify the file as well, and no PKI is involved in this example. But you are right, the guide mentions an Authenticode signature for the Windows release, and Authenticode relies on PKI. I'm talking about a wider use case, not specific to Windows. – Morgan Courbet Aug 20 '18 at 08:01
  • I am unclear what your question is then, as "is this a good idea to sign a release key (after having cross-checked multiple sources)" is your initial question, and the comment does not ask a question, but rather I have interpreted it as a categoric list of instructions. – safesploit Aug 20 '18 at 13:41
  • Actually, with my comment, I was trying to illustrate what lead me to ask my initial question. But it confused more than it make my question clear. Are you still confused? – Morgan Courbet Aug 20 '18 at 13:49
  • Immensely, I am still unclear what your question is then. – safesploit Aug 20 '18 at 13:56
  • I've just updated the question. Thank you for your help :) – Morgan Courbet Aug 20 '18 at 14:50
1

Just to complement @safespoit answer.

Self-signed certificate challenge is no different than a region/country root-CA is not trusted by default by any operating system/browser. In such case, the user must go to the say domain to download the root-CA in order to validate certificate signed under the say root-CA.

If an organisation manage the self-signed certificate and import of the self-root CA, this is a safe and sound solution.

However, in the case of software distribution to the public, this is not recommended, as the mechanism is likely exploited by scammer to phish the public to import the phisher root-CA.

mootmoot
  • 2,407
  • 11
  • 16
  • 1
    "in the case of software distribution to the public, this is not recommended" is a particularly valid concern. Either you distribute a self-signed root CA and then ensure the communication channels you distribute it over are secure and have integrity, or sign the distribution of your root CA with a trusted root authority. Which then relies on you trusting the chain of trust. – safesploit Aug 20 '18 at 13:54
1

Yes, I think it makes perfect sense to sign the release key with your private key (though I'm not an expert on PGP).

I think your question really boils down to Is it okay to sign a PGP key without an IRL meeting?, but it's different enough that I'm not sure it should be closed as a duplicate.

I agree with Thomas Pornin's answer to that question, there's no real consistent definition of "identity" here, as you correctly point out:

release keys are not held by a unique person, but by a team, so it's kinda difficult to meet the people in real life

The point of signing a key is to say that you know the "identity" the key says it belongs to, and that you've verified that the key does actually belong to that identity. In the case of a software release key, you want to verify that the key belongs to the release team. Since control of the software's website should be (mostly) limited to the people making the software, verifying the fingerprint obtained from the website over HTTPS is probably an acceptable form of verification in most such cases.

AndrolGenhald
  • 15,696
  • 5
  • 45
  • 51
  • With the links you provided, I've just learned about the existence of trust signature levels and Policy for signatures. I think I can sign a release key if I set correctly these options. – Morgan Courbet Aug 21 '18 at 13:05