33

As an example, this project offers an *.asc file with a PGP signature to verify the contents of the download (as opposed to a checksum, you can see the empty column): https://ossec.github.io/downloads.html

How would I use this file? I tried gpg --verify and other variants, but it seems to be matching the name up to the file, however the filename as it is downloaded is not exactly the same... not sure how it is supposed to work.

SeeYouInDisneyland
  • 109
  • 5
user8897013
  • 443
  • 1
  • 4
  • 7

2 Answers2

33
  • Download the key file:
wget https://ossec.github.io/files/OSSEC-ARCHIVE-KEY.asc
  • Inspect the key file to confirm it has EE1B0E6B2D8387B7 as its keyid.
gpg --keyid-format long --list-options show-keyring OSSEC-ARCHIVE-KEY.asc
  • If correct, then import the key:
gpg --import OSSEC-ARCHIVE-KEY.asc
  • Download the software package
wget https://github.com/ossec/ossec-hids/archive/2.9.3.tar.gz
  • Download the signature file
https://github.com/ossec/ossec-hids/releases/download/2.9.3/ossec-hids-2.9.3.tar.gz.asc
  • Verify it
gpg --verify ossec-hids-2.9.3.tar.gz.asc 2.9.3.tar.gz

Output

gpg: Signature made Sat Dec 23 16:13:01 2017 UTC
gpg:                using RSA key EE1B0E6B2D8387B7
gpg: Good signature from "Scott R. Shinn <scott@atomicorp.com>" [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: B50F B194 7A0A E311 45D0  5FAD EE1B 0E6B 2D83 87B7
Aleksandr Levchuk
  • 2,415
  • 3
  • 21
  • 41
Евгений Новиков
  • 528
  • 5
  • 7
  • 3
    It seems that the --verify option expects the signature file – niahoo Feb 02 '19 at 15:17
  • 2
    I get `gpg: WARNING: "--show-keyring" is a deprecated option gpg: please use "--list-options show-keyring" instead` – Dan Dascalescu May 13 '19 at 04:45
  • @DanDascalescu I posted a refined answer that doesn't depend on that deprecated command. – aef Dec 09 '20 at 05:18
  • This answer uses potentially spoofable long IDs for verification. Full fingerprints should be used whenever possible to avoid attacks. See my refined answer for explanation. – aef Dec 09 '20 at 05:21
  • @Евгений Новиков as @niahoo says, it looks like `--verify` wants the signature file – robertspierre Jan 31 '22 at 17:55
10

This further refines Евгений Новиков's answer. It doesn't use deprecated GnuPG commands and avoids potentially spoofable key IDs for authentication:

Download the files

Acquire the OpenPGP certificate that the author uses to issue signatures:

wget https://ossec.github.io/files/OSSEC-ARCHIVE-KEY.asc

Then acquire the detached signature issued by the author:

wget https://github.com/ossec/ossec-hids/releases/download/2.9.3/ossec-hids-2.9.3.tar.gz.asc

Finally acquire the file that you intend to authenticate:

wget https://github.com/ossec/ossec-hids/archive/2.9.3.tar.gz

Display and thoroughly compare the fingerprint

Before importing the certificate, display the full 40 character long OpenPGP certificate fingerprint and make sure it fully matches the fingerprint of the authors certificate.

Attention: You should acquire the fingerprint through a secure channel from the author. Apart of meeting the author physically to exchange the fingerprint, the next best thing would be a fingerprint displayed on the author's website and accessed via an https: schemed URI. The author did publish one here.

Attention: If the author only displays a short ID (8 characters long, e.g. 2D8387B7) or long ID (16 characters long, e.g. EE1B0E6B2D8387B7) better be sceptical and ask the author to publish the full fingerprint, as both the short ID and the long ID have been demonstrated to be spoofable (read more here)

gpg --import --import-options show-only OSSEC-ARCHIVE-KEY.asc

Older versions of GnuPG didn't display the full fingerprint by default. Try to add the --fingerprint flag if it is not displayed.

The output is supposed to look like this:

pub   rsa4096 2011-03-10 [SC]
      B50FB1947A0AE31145D05FADEE1B0E6B2D8387B7
uid                      Scott R. Shinn <scott@atomicorp.com>
sub   rsa4096 2011-03-10 [E]

The OpenPGP certificate fingerprint in this case is:

B50FB1947A0AE31145D05FADEE1B0E6B2D8387B7

Sometimes fingerprints are displayed in segments of 4 characters each with whitespace to make it easier for humans to read. In this case it is safe to ignore the whitespace for comparison:

B50F B194 7A0A E311 45D0  5FAD EE1B 0E6B 2D83 87B7

Attention: Be sure not only to compare parts of the fingerprint, as this again opens up room for spoofing attacks.

For easy and thorough comparison just copy both fingerprints equally formatted in subsequent lines in a text editor of your choice and visually match them.

Import the certificate

If the full fingerprint is an exact match, import the certificate into your local GnuPG keyring:

gpg --import OSSEC-ARCHIVE-KEY.asc

Authenticate the file

Now you can cryptographically verify the file exactly matches the one published and signed by the author.

gpg --verify ossec-hids-2.9.3.tar.gz.asc 2.9.3.tar.gz

Attention: Be sure to always list both the detached signature and the file to authenticate here. Apart of detached signatures there are other types of signatures and not realizing this can lead to wrong assumptions of authenticity if only the signature file is listed.

The output is supposed to look like this:

gpg: Signature made Sa 23 Dez 2017 17:13:01 CET
gpg:                using RSA key EE1B0E6B2D8387B7
gpg: Good signature from "Scott R. Shinn <scott@atomicorp.com>" [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: B50F B194 7A0A E311 45D0  5FAD EE1B 0E6B 2D83 87B7

Attention: In case the file has been manipulated, you are supposed to see something like this:

gpg: Signature made Sa 23 Dez 2017 17:13:01 CET
gpg:                using RSA key EE1B0E6B2D8387B7
gpg: BAD signature from "Scott R. Shinn <scott@atomicorp.com>" [unknown]

If this happens you should not use or execute the contents of the file as a precaution and contact the author. If the author cannot be reached, raising awareness publicly is the next best thing.

Authenticating files published by the author time and time again

The warning displayed in the last step is a hint that it would be a good idea to certify the imported author's signing certificate with your own personal OpenPGP certificate after you made sure it is legit.

If you keep and maintain your GnuPG keystore over a long time you don't need to verify the author's certificate for each new file again and make the whole process both easier and less prone to attack in the future.

Attention: A personal OpenPGP certificate is mandatory for this. Instruction for creating one are not the topic of this answer.

Issuing a certification works like this:

gpg --lsign B50FB1947A0AE31145D05FADEE1B0E6B2D8387B7

It tells both GnuPG and yourself in the future that you already thoroughly verified this author's certificate.

Afterwards the output of gpg --verify ossec-hids-2.9.3.tar.gz.asc 2.9.3.tar.gz looks much more clean and assuring like this:

gpg: Signature made Sa 23 Dez 2017 17:13:01 CET
gpg:                using RSA key EE1B0E6B2D8387B7
gpg: Good signature from "Scott R. Shinn <scott@atomicorp.com>" [full]
aef
  • 1,705
  • 4
  • 24
  • 41
  • The link you give provides no evidence at all for spoofing 64-bit, and links to a now-gone Debian blog that Wayback shows only claimed collision for 64-bit and explicitly said collision is NOT sufficient for spoofing. Moreover, PGP signature packets use the 64-bit keyid, so if that WERE broken you couldn't trust any PGP signatures, including key updates, for anything. – dave_thompson_085 Dec 09 '20 at 09:06
  • @dave_thompson_085 https://mailarchive.ietf.org/arch/msg/openpgp/Al8DzxTH2KT7vtFAgZ1q17Nub_g/ https://nullprogram.com/blog/2019/07/22/ As far as I know, this doesn't compromise the whole system but makes all but the fingerprint unsafe for key identification. If I remember correctly this is because implementations only use the long ID as hint and have to cryptographically verify it by checking signatures anyway. – aef Dec 09 '20 at 11:50
  • Collision allows a malicious party to substitute one malicious key for another -- but if you trust _any_ malicious key (even without collision or substitution) you're already in trouble, and this doesn't really make it any worse, just more confusing. Your second link explicitly says: An important detail is that this technique doesn’t target any specific key ID. Cloning someone’s long key ID is still very expensive. – dave_thompson_085 Dec 10 '20 at 07:28
  • 2
    Finding random collisions is documented since 2013 at least and now we live in the age of ubiquitous cloud computing and stolen AWS accounts with immense computing power even for underfunded bad actors. Sure you can keep using long IDs if you want, but I honestly think this is reason enough to prefer fingerprints instead. At least people should know this and decide what they prefer and this is one reason I gave this refined answer. – aef Dec 10 '20 at 14:24