Alright, the first part of the series was about some theoretical basics. But before we start, there are a couple of practical tools and phrases that I'd like you to know and understand, e. g. how to verify downloads? How to use the console? What does all of this mean in the first place? This knowledge will help us to get things done quickly later on. So let's just dive in.
This article is part of our series “OpenPGP On The Job”. Would you like to continue with another article from this series? Here’s an overview.
Command Line Is Key
At least for some tasks, using the command line is never outdated, even not in 2018 and also not on Windows. It simply makes working faster and straight to the point. Lucky for us, it's not that hard to learn. Every IT employee should have some basic command line knowledge anyway just like every taxi driver knows how to drive a car. Of course, for the daily OpenPGP usage, especially with e-mail, there are mature GUI clients available.
Windows Basics: The Command Promp
There are two command lines (or shells) bundled with Windows: The PowerShell and
cmd.exe. We are going to use
cmd.exe, the so called Command Prompt also known as console.
In order to run it, just type WIN+R --> type cmd <ENTER> or use the start menu.
Windows Basics: Environment Variables
Some configuration settings of the operating system are stored in so called environment variables. These are key-value pairs that are either visible for all users (system wide a.k.a. global) or just for one particular user. For example the key windir holds the value C:\Windows on my machine.
You can print all pairs visible to the actual user with the command set.
Environment variables can be changed in the following way:
Recent Windows updates brought a shortcut into the system with which it is possible to quickly navigate to the user's environment variables:
Windows key → type "Environment"→ Edit environment variables for your account.
Windows Basics: Search Path For Executables
When commands are entered on the command line, Windows searches for a matching program (a.k.a. executable) in the background, e. g. when I enter gpg Windows searches for the file gpg.exe. Where to search for is decided by inspecting the environment variable Path. This variable contains a semicolon separated list of directories to search in, e.g: C:\Windows;C:\Programs.
If you want to add a new directory, you'll need to append it like this:
Be aware: The changes will take effect on command prompt only after restarting the console.
Download And Verification
It gets hotter by the minute. We are going to download the latest version of gpg4win. But hold your horses: Before continuing with the installation you should check the integrity of the file. That is, we are going to check if the file has the expected contents and does come from a trusted source. This makes sure, we are not going to install malware. Nowadays you should do this for virtually each and every download.
Many downloads are accompanied by a website holding so called integrity information. This may comprise certificates, file hashes or PGP signatures. gpg4win offers such a site.
Certificates? Digital Signatures?
A certificate does often come with digitally signed files. That is a file that has literally been signed digitally. The signature is confirmed by a trusted third party, a so called certification authority (CA) by the means of a certificate. Signatures and certificates are tightly bound to the file in a mathematical fashion and may be included into the file itself. This makes sure, any attempt of modification to the file does not go unnoticed.
How does Windows find out which CA (that is: which signature) is to be trusted? Simply put: The list of trusted authorities is publicly known and agreed upon by the big Internet companies and open boards of interests. Microsoft included this list into Windows and does update it regulary. The same holds for other operating systems. It is rather easy to check the validity (i. e. it has not been modified) if a file:
- Navigate to the file in the Windows Explorer and open its properties via right click -> Properties.
- Follow these steps:
Hash-Codes? SHA1? SHA256? MD5?
When it comes to non Windows specific content (videos or PDFs may also contain malware) there is another option for checking validity: Hash codes. A hash code is a sum that can be calculated out of a set of data, e. g. a file. Precalculated hash codes are often published along with downloadable content. The download is "legit", if the hash code is recalculated locally and is equal to the pre calculated one.
Tiny changes to the file lead to a huge change in the hash code. This makes sure, manipulation attempts can be discovered easily and fast because the hash code is almost always completely different. This is why such codes are often also called checksums.
A disadvantage of hash codes is that in rare cases unequal files may yield the same code. This is called a collision. The easier it is to create such a collision, the easier it is for an attacker to provide fake content that leads to a correct hash code of a trusted file.
SHA1, SHA256 and MD5 are designations of different methods of calculating such codes. The most important difference of them for us is the chance of successful collision attack. MD5 has a rather high chance nowadays and therefore is insecure. Pretty much the same holds for SHA1. SHA256 is said to be reasonable secure for the moment.
How to check these codes? On Windows I do use one of the following options:
- certutil - A command line util available with all recent Windows installations.
- sha1sum, sha256sum und md5sum - Tools from the Unix world which are available for Windows via one of the Unix shell emulations, e. g. git-bash.
Example with gpg4win-4.0.4.exe and certutil:
Assuming the file to check is located in the user's download directory, then just type on the console:
certutil gpg4win-4.0.4.exe -hashfile SHA256
Which results in
C:\Users\mosig_user\Downloads>certutil -hashfile gpg4win-4.0.4.exe SHA256
SHA256-Hash von gpg4win-4.0.4.exe:
CertUtil: -hashfile-Befehl wurde erfolgreich ausgeführt.
certutil supports hash algorithms MD2, MD4, MD5, SHA1, SHA256, SHA384 and SHA512.
Example with gpg4win-4.0.4.exe and sha256sum:Download and install git-bash. Assuming the file to check is located in the user's download directory, then on bash:
cd ~/Downloads # ~ is a shortcut for the user's home dir sha256sum gpg4win-4.0.4.exe
Which results in
Hash Code Best Practices
- If there are only MD5 and SHA1 available, a check for each sum respectively may be sufficient. Although both methods are insecure, faking a file in such a way that it causes collisions for both algorithms should be too much effort for most attackers. Thus, if both sums are correct, there is a high chance that the file is valid.
- Due to security reasons it is best to use SHA256 or SHA512.
- Because already tiny manipulation yields completely different hash codes, it is sufficient in most cases to check the first and last 4-8 characters of the sum. Be aware: Of course this is a poor man's shortcut that must not be executed for really important stuff.
- With the Unix tools it is also possible to automate the comparision check of sums. See sha256sum --help for details.
In the first part of the series, I noted that PGP is not only used for e-mail. The integrity check of downloaded content is a good example for such a non e-mail usage. PGP can not only be used to sign e-mails but any other kind of data, e. g. files, as well.
PGP signatures are a different kind of digital signatures. However, they are not confirmed by a well known certification authority but must be validated by the help of the public key of the signer. It is crucial how much trust this public key is attributed. If it is clear that it does realy belong to the signer, everything is ok. If this kind of trust cannot be established without doubt, even a technically valid signature may be a fraud, because it could have been created by an attacker who just pretends to be someone else. After all, PGP does not include a fool proof technical way of checking whether a key or signature belongs to a particular source. This is why it is crucial to convince yourself of the authenticity of this source.
Even though we have not set up PGP yet, I'm going to document how to check such a PGP signature with gpg on the console. First of all, download the signature file along with the download itself and store it into the same location as the original file. E. g for gpg4win-3.1.1.exe this file is called gpg4win-3.1.1.exe.sig. Now open a command prompt and do:
C:\Users\mosig_user\Downloads>gpg --verify gpg4win-3.1.1.exe.sig gpg4win-3.1.1.exe gpg: Signature made 05/03/18 13:11:15 Mitteleuropõische Sommerzeit gpg: using RSA key 13E3CE81AFEA6F683E466E0D42D876082688DA1A gpg: Can't check signature: No public key gpg: Signature made 05/03/18 13:11:25 Mitteleuropõische Sommerzeit gpg: using DSA key 61AC3F5EE4BE593C13D68B1E7CBD620BEC70B1B8 gpg: Can't check signature: No public key
So the signature check failed. But why?
- There exists two public keys that can be used to check the signature respectively.
- None of those keys do currenty exist in the local key ring. This is why the signature check failed.
This situation is very common. In order to fix it, we must first load these keys from a keyserver. This can also be done with gpg:
C:\Users\mosig_user\Downloads>gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys 13E3CE81AFEA6F683E466E0D42D876082688DA1A 61AC3F5EE4BE593C13D68B1E7CBD620BEC70B1B8 gpg: key 0x7CBD620BEC70B1B8: 121 signatures not checked due to missing keys gpg: key 0x7CBD620BEC70B1B8: public key "Intevation File Distribution Key <email@example.com>" imported gpg: key 0x42D876082688DA1A: 72 signatures not checked due to missing keys gpg: key 0x42D876082688DA1A: public key "Intevation File Distribution Key <firstname.lastname@example.org>" imported gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: next trustdb check due at 2019-01-28 gpg: Total number processed: 2 gpg: imported: 2
Both keys have been found and where imported. Every key comes along with signatures made by other OpenPGP participants who have certified its validity. The certifications may be checked with the public keys of the other participants. However, those keys do not get imported automatically and this is why gpg could not check them by itself. Let's try again validating the download:
C:\Users\mosig_user\Downloads>gpg --verify gpg4win-3.1.1.exe.sig gpg4win-3.1.1.exe gpg: Signature made 05/03/18 13:11:15 Mitteleuropõische Sommerzeit gpg: using RSA key 13E3CE81AFEA6F683E466E0D42D876082688DA1A gpg: Good signature from "Intevation File Distribution Key <email@example.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: 13E3 CE81 AFEA 6F68 3E46 6E0D 42D8 7608 2688 DA1A gpg: Signature made 05/03/18 13:11:25 Mitteleuropõische Sommerzeit gpg: using DSA key 61AC3F5EE4BE593C13D68B1E7CBD620BEC70B1B8 gpg: Good signature from "Intevation File Distribution Key <firstname.lastname@example.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: 61AC 3F5E E4BE 593C 13D6 8B1E 7CBD 620B EC70 B1B8
The signature is valid. The accompanying warnings can be ignored. They just point out (again) that from a technical point of view it cannot be made 100% sure that the public keys actually belong to the download provider.
Coming up next
Well that was quite a lot of information. Fortunately we now have everything together so that we can progress in the next parts fast. The series will continue with how to set up gpg4win and generate keys.