A while ago we discussed cryptographic hashes (such as MD5 and SH1 checksums), and how they help ensure that a file you download is the same file that its creator intended you to download by creating a unique ‘fingerprint’ of the file that can be checked against the original.
The ability to verify the integrity of just about any file is important, but when we download privacy and security software from the internet, it is absolutely critical. After all, what is the point of trusting your privacy and security to a program that may contain a virus, especially when you consider that such software and its users are without any doubt high priority targets for the NSA and its ilk?
Even when you download software directly from a vendor or developers’ website, you might fall victim to a Man-in-the-Middle (MitM) attack, or the website itself might be compromised in various ways.
Using cryptographic hashes is an attempt to solve this problem, but unfortunately the technique has a major weakness - for example, a developer’s website may be hacked to display the hash of a compromised file rather than the original, or mathematical vulnerabilities can make them insecure. Hashes are therefore useful in verifying that a file has not been corrupted, but are only of limited use in ensuring that the file you download is the same file its developers intend you to download.
To provide greater assurances of this, developers can sign their files with digital signatures, which employ a form of asymmetric cryptography (public keys and private keys) to verify that a file is exactly what it claims to be.
A diagram showing how a digital signature is applied and then verified.
PGP digital signatures
Different cryptographic systems use different mechanisms to create and validate digital signatures. Windows, for example, uses the Microsoft public key infrastructure (PKI) technology to automatically validate signatures when software is first installed.
Open-source software cannot use the propriety Microsoft PKI, and so uses PGP digital signatures instead. Which must then be manually authenticated. These work very much like the key pairs used to authenticate PGP emails, and as we shall see, verifying PGP digital signatures requires using a PGP-compatible mail program.
Unfortunately, this also means that like using PGP to secure emails, using PGP digital signatures is overly complex.
How to verify a digital signature using Kleopatra GUI
To verify a file’s PGP digital signature you must use a PGP client (or more accurately GnuPG - its open-source clone). Versions of GnuPG are available for Windows (Gpg4win), Mac OSX, and Linux (usually pre-installed).
In this tutorial, we will verify the digital signature of Pidgin + OTR using Gpg4win, but the process is very similar for other versions of GnuPG.
We have a two-part article on using Gpg4win, and we strongly recommend reading at least Part 1 of it to familiarise yourself with key concepts that will be used below.
The Gpg4win download is itself digitally signed with a key that has been verified by a recognized certificate authority (CA), and which can be independently checked for verification using a trusted older copy of GnuPG (an SHA1 hash is also available). You should never trust a copy of Gpg4win that you have not verified.
Once GnuPG is installed, we need three things to verify a digital signature:
- The file we want to verify (duh!) e.g. the pidgin-otr-4.0.1.exe installer
- The PGP/GPG signature file (.asc) e.g. pidgin-otr-4.0.1.exe.asc
- The public key/PGP Certificate used to create this signature e.g. gpgkey.asc
These files should all (hopefully) be provided by the developer whose digitally signed files you wish to verify. Public key/PGP Certificates are often stored on a keyserver, but the devs should provide instructions for accessing them.
Kleopatra
Kleopatra is a key management program bundled with Gpg4win.
1. You will need a personal private key to certify the PGP certificate. If you have created one before (for example using GPA), then you can import it (File -> Import Certificates…), or you can create a new key pair (File -> New Certificate…).
Wizards will guide you through the rest of this process
2. Import the public key/PGP certificate into Kleopatra - using either ‘Import Certificates’, or right-clicking on the file and selecting ‘Import keys’.
3. Certify the PGP certificate using your private key - this tells GnuPG that you trust the person who signed the certificate.
a) In Kleopatra right-click on the key and select ‘Certify Certificate’.
b) Select the certificate, and confirm that you have verified its fingerprint (hopefully this will be published on the developer’s website).
c) Unless you are very sure about the authenticity of the certificate then you should Certify only for yourself (certificates work on the principle of a web of trust - the more people who trust them, the surer you can be they are genuine).
d) Enter your private key passphrase to finish verifying the certificate.
4. Now that you have certified the Certificate used to make the signature for the file you have downloaded (whew!), you can use it to verify the signature.
a) In Kleopatra go to File -> Decrypt/Verify files and browse to the signature file, or right-click on it and go to MoreGpgEX options -> Verify.
b) Ensure ‘Input File’ is the signature file, and that the ‘Signed data’ field contains the program or file you wish to verify, then hit ‘Decrypt/Verify’.
c) All being well, Kleopatra will declare the signature valid.
How can I trust a Certificate?
The simplest way to verify that a PGP Certificate is valid is to check the website of the person who is supposed to have signed the certificate... with a bit of luck, it will publish the fingerprint of the certificate.
However, although easy, this does not guarantee the authenticity of the signature, as the website may have been hacked or forced by a government to display a fake fingerprint (the same problem that plagues cryptographic hashes).
This is where the web of trust comes in, where users vouch for a certificate. In practice, this is an arcane process that is both too complex and too obscure for most users, so the best that most of us can hope for is that the certificate has been vouched for by a recognized Certificate Authority, or is signed by known developers who publish their signing keys (as the Tor developers do, for example).
Pidgin + OTR is in some ways a bad example of how digital signing should work, because the OTR webpage comes with almost no instructions on how to use its published keys, and its PGP Certificate was not only very difficult to locate but other than being available from https://otr.cypherpunks.ca/gpgkey.asc there is no easy way to verify its authenticity (the fact that uses a 1024-bit RSA key is also poor show in this age when the NSA can probably crack such weak encryption).
Conclusion
As you can see, verifying a digital signature really is a pain, so it is little wonder that even those who understand the jargon-heavy arcane process rarely bother. The issue is made even worse by many devs failing to explain how to verify their files, and/or issuing sloppy PGP Certificates that are very hard to verify are genuine (OTR-team, we are looking at you!)
The fact that digital signatures remain the only meaningful way to guarantee that files you download are the ones you intended to download (or that their devs intended you to download), does not bode well for internet security.
However, until someone invents a better, more user-friendly system, our best hope is to encourage devs to provide clear instructions on how to use their digital signatures, and to publish meaningful guarantees as to the authenticity of their PGP Certificates… (sigh)
"Digital Signature diagram" by Acdx - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:Digital_Signature_diagram.svg#mediaviewer/File:Digital_Signature_diagram.svg