Better Safe Than Sorry? Trust Levels in GpgOL Explained

Posted on 29. Juni 2020 by Heike Jurzik

You're using our Outlook add-in for secure email communication, so you can send and receive encrypted and signed emails. But how secure is that, really? And can our software help you assess that? The answers are "it depends" and "yes" — keep reading to find out more.

To get a better idea of what this blog article is all about, let's first think about what can go wrong in email communication:

• Eavesdropper alert: Even with encryption, an attacker might still manage to read a message (in plain text) that wasn't meant for them.
• Fake message: An attacker intercepts a message and replaces it with their own altered version. The recipient doesn't notice, even though it's signed, and ends up getting a fake message from an impostor.

How does this happen? The math behind encryption and signatures ensures that, with GnuPG, only the holder of the private key can decrypt a message encrypted with the corresponding public key. Likewise, using a public key, it's possible to accurately verify that a signature was created with the associated private key.

So, what's causing the issues we've mentioned? Assuming private keys aren't lost or stolen (say, after a break-in), it usually comes down to one thing: the key pairs being used don't actually belong to the person you're trying to communicate with. Instead, an attacker has inserted themselves into the conversation, acting as a so-called "Man in the Middle".

Man in the Middle

To understand how this works, here's an example: Berta and Edward use the same mail server for sending and receiving emails. Enter Moriarty: He controls the mail server, so he can intercept messages and inject his own (with any fake sender he wants). Moriarty steps in right in the middle of the email transfer—that's why he's the "Man in the Middle".

Moriarty sends an email to both Berta and Edward, pretending to be the other person—so he acts like Edward to Berta and like Berta to Edward. In the email, he claims to have lost his private key, attaches a new public key, and asks them to use that key from now on.

Berta and Edward believe Moriarty and update the keys for each other in their key management software. At this point, Moriarty has already won—all he has to do now is wait for more emails to roll in.

Berta writes to Edward. She signs the message with her own private key and encrypts it with the fake key for Edward (the one Moriarty sent). The message then begins its journey. Moriarty intercepts the message and stops it from being forwarded. Since he has the private key, he's able to decrypt it.

Moriarty reads Berta's email (eavesdropper alert) and changes it however he likes (fake message). He then creates a signature using the fake private key he made for Berta and encrypts the message with Edward's public key. After that, Moriarty sends the message off to Edward. Edward decrypts it and checks the signature: it matches.

Check Twice, Encrypt Once

The problems arise because someone (incorrectly) assumes that a certain public key belongs to a specific person. That's why, in the world of PGP/GnuPG encryption, the recommendation is to always verify keys. The best way to do this is for two communication partners to meet in person, exchange their public keys, and verify each other's identity—for contacts they don't know personally, this could involve showing identification documents. If this identity verification is done correctly (forging IDs is a whole different ball game), it guarantees nearly perfect security.

Often, though, a slightly lower level of security is sufficient. If two communication partners have a mutual contact who can vouch for both of them, the trust in that contact leads you to also trust the communication partner (or more specifically, the provided key).

By signing public keys, you're essentially confirming this trust. At key-signing parties, users show each other their ID documents and, after verifying identities, sign each other's public keys with their own private keys. This creates a "Web of Trust".

This process leads to the following trust levels:

• There are keys you trust completely (because you've exchanged keys personally with someone you know well).
• There may be keys you don't trust at all.
• Then there are the in-between levels: someone else has vouched for the key—the question is, how much do you trust that other person?

Make Emailing Simpler, Not Harder

Our GnuPG add-in, GpgOL, is here to make your life easier (specifically, the process of determining whether you can trust a key). To help with that, just check the GpgOL icon in the ribbon of a received email—it shows one of five security levels:

Security Level 0: Insecure/Encrypted; no validation

The key of the communication partner is unknown, or the email isn't signed: it's unclear whether the communication partner possesses this key and can decrypt or sign messages with it. By default, GpgOL does not use such a key to avoid a negative user experience if the recipient is unable to decrypt the message.

Security Level 1: Validation via Email Address

You've received an email signed with this key. At this level, GpgOL makes no trust claims about the sender's identity, but it will use the key for automatic encryption, assuming the recipient can decrypt the message. This level is primarily designed to protect against passive attackers who might automatically eavesdrop on the message traffic. It does not offer protection against active "Man in the Middle" attacks.

Security Level 2: Limited Identity Validation

The key was automatically delivered by the mail domain owner (the provider) via HTTPS. This is only possible if the provider uses the WKD (Web Key Directory) service (more on this in a future article). There's a basic trust that the sender controls the email address from which the message was sent. From this level onward, GpgOL switches to a green icon to indicate that there is a certain level of trust in the sender's identity.

Security Level 3: Identity Certification

This level uses the same icon as Level 2 but protects against active attackers. This means that a trusted "third party" (via the Web of Trust in OpenPGP or S/MIME) has certified the key with a trusted certificate. Organizations should aim for this level, especially those that have established central, trusted "certifiers". For example, an organizational rule might state that employees must follow email instructions that have at least Level 3 trust.

Security Level 4: Validation by Direct Trust

This level means that you or an ultimately trusted person have verified the key's fingerprint and signed it directly. This level also applies to your own key. If you have a very high security need, you can use this level to ensure that you only trust keys that you have personally certified, marking them as trusted in the system.

Additional note for Security Level 2:

If you've also enabled trust based on communication history (the "TOFU + PGP" feature), a key will automatically move to this level after extended communication with the contact (always using the same key). This assumes that you've been communicating with the same person all along. If there are no irregularities, the key is likely "genuine" with a reasonable degree of confidence. However, an active attacker who compromises both HTTPS and email traffic could still reach this level. For private users, though, this protection is usually sufficient and achievable without ever needing to deal with "certificate management".

What Are You Waiting For?

For Windows users who use Outlook as their email client, Gpg4win offers the fastest and easiest way to add GnuPG support. Simply click the green button Download Gpg4win to download the software. When installing the gpg4win-<version>.exe file, you'll need to allow the app to make changes to your computer, as is typical with Windows applications.

Flexible Email Security with GpgOL: How to Tailor Trust Levels

With GpgOL, you can tailor security to your needs by choosing a minimum trust level that makes sense for you (or have this set centrally for your entire organization). Emails that show the appropriate or a higher level in GpgOL can be trusted without further verification.

This gives you the right tools from GnuPG.com to protect your organization against targeted attacks, such as so-called "spear phishing" or CEO Fraud (German article).