Verifying digital signatures
Don’t install or use software without first verifying its digital signature.
1. Introduction
The verification of digital signatures ensures that a message wasn’t altered and that the sender is the one who ‘signed’ the message, the owner of the key pair.
Digital signatures use asymmetric cryptography: the signing process uses the private key and the verification process uses the public key from the same key pair.
If a message (or a file in any other format) has been modified in its origin or while in transit, the hashes will be different, and in this case (if the hacker published new hashes for the message), the hashes won’t have a valid digital signature.
Read a brief notion of cryptography to understand the basics of the process.
In other words: If the hacker modifies the executable, its hash will be different from the hash in the manifest; if they are equal (in case the hacker also modified the manifest, because both are stored in Github), the digital signature of the manifest will be invalid because the manifest was signed with Decred developers’ private key, inaccessible to the hacker. The hacker would have to change the public key in MIT servers, where Decred developers’ public key is stored, and also the Github webpage with the instructions to import the correct public key (because the ID will change if the hacker decides to use his own key). Even going through all this trouble, it would work only for those who import the public key after the hacker replaces it with his own.
Figure 1 — The process — Rebuilt from Microsoft Windows Dev Center, Digital Signatures
2. How does the digital signature work
2.1. Hash
It is the output of a mathematical function that always returns a fixed length sequence regardless of the size of the input.
Figure 2 - Cryptographic hash functions - Rebuilt from Wikipedia
Any modification in the input - the text, the length or the order of the characters - will produce a totally different output from what was expected.
2.2. Signature process
The digital signature process may occur with or without a manifest file. The manifest is a file that stores the hashes of other files, the ones for which the process is trying to secure the integrity and authenticity. With the manifest it is not necessary to ‘sign’ every file because the hashes of the files are in the manifest, so this is the only file that needs to be digitally signed. The digital signature will be stored in another file, one that usually has the file extension .asc or .sign.
Example of manifest.txt:
f19efd3bc998ad847e206e3eaf393182d2edc458a7329fafb3cd8d9b2cd7ab56 package-linux-386-v1.0.tar.gz
36375985df1ba9a45bc11b4f6cdaed4f14ff6e5e9c46e17ef6e4f70a3349aba2 package-linux-amd64-v1.0.tar.gz
683b80286f50bb2fb77d4d10ac43c736435264958f02f8ae3cbf1fdae31279ba package-windows-386-v1.0.tar.gz
964db2509dd9bb570f6e7b5e99dc81a7680fc98e1a9fcda8c17b63147648ca88 package-windows-amd64-v1.0.tar.gz
Example of manifest.txt.asc:
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcWcxoAAoJEG2Jft9RigMd7MQP/Atp002t+5iwtDVtC0rcO7Qc
elgFzpl/Jkjj/I0RTXDrubUEbFuyyvKXWoGYwqF2LBXqJimBjVPXqpm2p2cOMcWr
wVPtgGLt6cMOD8hP1FHGdj9jSFbqR1fWUR/tQPHZhMuBWh6ic6gndJVsWOkWf2rY
yYv2SbE3JMOT98aNBJKI8m+mYBzPtUednJG0MEt0MeWO33rIMyhjhhQHc5v8N2YL
4WsLM5MwjDiGrEtSrD2raVvcKh0VHDsMKJSaOLV+GESpZHewx91qCJe+VlRBLnyj
SJ5MusUJyEKjjVv9vre1g8ESMjnRV6sV8cQqjWKenpso69ZYSoewuEiiRgos9oFn
xtVGCEqDx/nZPwa4XKaJQWE7aVLeK+bklvFfmAcNkV3/Gs9+6jAvJUtX1IvmFBpH
jLIAAysrhECylyXBURPblL+IZkg2E3eM5wnWUhkNKw+D34ICBN90Lo7g/nEpJnHZ
bBNcIzxYeCJB2bLKXmSTrgUaNrEK+YSBSEg+t0NyuFlKsnKgY/1ZEdxFe2cF/uGs
yI0zhvSuSfhuzz4MJLV9f+qjlCOhiWgknN1C9gDixaKJHScspP4D/6LjNlIjw1zF
YYOtxBM5TK3N5wu+5OJjcxAEnlskxMlQnqhB+8RnLW25NIwVimgWXEqvqojVaOht
2Rlp+5ToMS7wAT4PE3/w
=P8Iv
-----END PGP SIGNATURE-----
2.2.1. With manifest (indirect)
a) The hash (digest) of the file (GZIP, in the schematic) is generated
b) The hash is stored in a text file manifest.txt, that contains the name of each file and its corresponding hash
c) The manifest manifest.txt is signed (encrypted) with the publisher’s private key. It means that the process will generate a hash for the manifest file and this hash will be encrypted using the publisher’s private key. This encrypted hash will be stored in another file, manifest.txt.asc. At the end of the process we have the files package.tar.gz, the manifest manifest.txt and the digitally signed manifest manifest.txt.asc.
Figure 3 - Digital signature with manifest
2.2.2. Without manifest (direct)
a) The file package.tar.gz (GZIP, in the schematic) is signed (encrypted) with the private key of the publisher. It means that the process will generate a hash for the file that will be signed and this hash will be encrypted using the publisher’s private key. This encrypted hash will be stored in another file package.tar.gz.asc.
b) The package and its corresponding signature (usually a file with the same name and one file extension more, like package.tar.gz and package.tar.gz.asc or package.dmg and package.dmg.sign) are ready to be used
Figure 4 - Digital signature without manifest
2.3. Signature verification
2.3.1. With manifest (indirect)
a) The verification process generates a hash of the manifest manifest.txt.
b) The signed hash (encrypted hash) manifest.txt.asc is decrypted using the sender’s public key and the original hash is obtained. If both hashes are equal, the message wasn’t altered and the sender is who we think he is, because this public key could not decrypt a hash encrypted with a private key from another pair. In asymmetric cryptography both keys from the same pair are used. The process started with one key and ended with the other one.
c) The user generates a hash of the file package.tar.gz (GZIP, in the schematic) and compares with the hash stores inside the manifest manifest.txt. If both hashes are equal, the file wasn’t modified.
Figure 5 - Digital signature verification with manifest
2.3.2. Without manifest (direct)
a) The verification process generates a hash of the downloaded file package.tar.gz (GZIP, in the schematic).
b) The signed hash (encrypted hash) is decrypted using the sender’s public key and the original hash is obtained. If both hashes are equal, the message wasn’t altered and the sender is who we think he is, because this public key could not decrypt a hash encrypted with a private key from another pair. In asymmetric cryptography both keys from the same pair are used. The process started with one key and ended with the other one.
Figure 6 - Digital signature verification without manifest
3. What are the risks?
The risks change accordingly to the software that may have been compromised. In the case of cryptocurrency wallets it is possible that the attacker copy the seed or the private key to transfer all the resources to other addresses. In other cases the threats include information leakage, unauthorized access to user-stored information and even remote access or privilege escalation depending on the malicious code inserted into the original software.
4. File verification
Don’t install or use software without first verifying its digital signature.
This recommendation is related to software in general. Even the most simple software, like calculators or text editors, that don’t need administrative credentials to install or execute, may contain malicious code that exploits a vulnerability in the operating system or kernel. The broader recommendation should be: do not install untrusted software in your device, and when you decide to install something, download it from official sources and verify its digital signature, if possible.
Learn more about the verification of digital signatures for Debian Linux.
These steps may be used to verify any downloaded software from the Internet. The user will have to import the developers’ public key (hopefully all this information will be displayed in the website). Usually public keys are imported once, then again only if the key pair is revoked or replaced.
Learn more about Debian Verifier, a shell script also ported to Python that automates the digital signature and hash verification process.
Learn more about this verification on macOS and Linux update process: