IncreaseWKDUsage2021 bachelor thesis
Christoph Klassen is writing his bachelor thesis (at Intevation) about how usage of WKD can be furthered. Bernhard Reiter does the mentoring, see gnupg-devel@ for discussion and for contacting Christoph or Bernhard.
Started at 2021-10
End: 2022-02-18
Contents
Goal
In 2018 a survey was performed to find out how German think about encryption and if they are using it [1]. One question was: "Why are you not using end-to-end encryption yet?". The following graph illustrates the answers that were given:
As the result of this survey shows many people think that encryption is a complicated process. Web Key Directory (WKD) is a procedure, whose goal it is to simplify the process of retrieving public keys. Because the retrieval is part of the encryption process WKD is also helpful to make encryption easier.
This work wants to spread WKD. For that it wants to answer the question "Which measurements can be used to spread the WKD-standard?". To find the answer different measurements which come from the software engineering will be applied.
Use Cases
In the first tests for this work it became obvious that the usability of WKD in different products isn't satisfying. Sometimes it was complicated to make the product ready for WKD or it was difficult to find out how to enable it. That is why it is important to simplify these aspects.
To do so I created two use cases in the first step. In the first case a user wants to write an encrypted email. In the second a user wants to check the signature of an email. In both cases the user is a random person because encryption should be easier for every person.
The basic thought which affected the use cases was the one of Krug [1]: Products should reduce the effort of using these products as far as possible. Users shouldn't think much about how to use an application but about how to reach their goals. So, in the created use cases the user has to take only an amount of steps that is really necessary.
Note: In the first use case the process of retrieving the pubkey is started automatically by the application while in the second case the user has to start the process manually. The reason for this is that every request to a WKD-server can give potential attackers some information. Also, not every information that was sent by email has such high importance that it is necessary to check the signature.
These use cases were written by using Cockburns template [2].
Use Case UC1: Write an encrypted email
Hints:
- Person A is the person who wants to send an email
- Person B is the person who shall receive the email
Goal: Sending a confidential message.
Precondition:
- An email-client, which uses the OpenPGP-standard, was installed
- Person A does not have the pubkey of person B yet
- Person B did create a pubkey and made it available on a WKD server
- The pubkey of person B needs to be fetched automatically
Success: An encrypted email was sent
Failure:
- An unencrypted email was sent
- No email was sent
- The receiver cannot decrypt the encrypted email
Actors: A random person
Trigger: Person A wants to write a confidential message to person B in a way that no other person can read the message's contents.
Description:
- Person A opens the email-client
- Person A opens the area to compose an email
- Person A enters address, subject and message
- Person A sends the email
Extensions:
- Person A checks, if the pubkey is trustworthy
- Person A checks, how trustworthy the pubkey is
Use Case UC2: Validate the signature of an email
Hints:
- Person A is the person who wants to check the signature
- Person B is the person whose key was probably used to sign the email
Goal: Check, if an email was written by person B.
Precondition:
- An email-client, which uses the OpenPGP-standard, was installed
- Person B created a pubkey and made it available on a WKD-server
- Person A does not have the pubkey of person B yet
Success: The signature of the email could be checked
Failure: The signature of the email could not be checked
Actors: A random person
Trigger: Person A receives an email with important information and wants to know, if it was really written by person B.
Description:
- Person A opens the email-client
- Person A opens the area with all received emails
- Person A opens a signed email
- Person A starts the verification of the signature
- Person A sees if the signature of the email is valid
Extensions:
- Person A checks, if the pubkey, which was used to check the signature of the received email, is trustworthy
- Person A checks, how trustworthy the pubkey is, which was used to check the signature of the received email
Activity diagram for use case #2:
Criteria for implementing WKD with a good usability
After finishing the use cases it is now possible to establish criteria which developer can use to improve the usability of their products.
WKD have a basic trust because they are fetched from WKD-servers that belong to email-providers. Reasons for that are that email-provider know that a pubkey belongs to an email-address and that email-providers usually have a higher security level than private persons who maintain a server. The criteria reflect this basic trust of WKD-keys.
- K1: The product is compatible to the last draft of the WKD-standard
- K2: The product is ready for WKD without any preparations after a clean installation
- K3: WKD is offered in the area where users enter an email-address. To fulfill this criterion it's sufficient that there is a button to start a key lookup. It's not necessary that WKD will be executed automatically. But, users shouldn't have to open more than one additional window.
- K4: WKD is offered in the area where users check the signature of an email. Like for K3 users shouldn't have to open more than one additional window.
- K5: The product uses WKD automatically when users enter an email-address in the area where they can compose an email. The users do not have to press a button to retrieve a key via WKD.
- K6: When the product has access to keys which were directly imported and don't contain any information about their trust and a WKD-key it should automatically use the WKD-key (in the area to compose an email).
- K7: When the product has access to keys which were directly imported and don't contain any information about their trust and a WKD-key it should automatically use the WKD-key (in the area to check the signature of an email).
- K8: The product distinguishes between keys without any information about their trust and keys that have at least a basic trust (e.g. WKD-keys or marginal valid keys in the web of trust) and displays this difference in the area to compose an email. In this criterion it doesn't matter, how the trust is calculated.
- K9: The product distinguishes between keys without any information about their trust and keys that have at least a basic trust (e.g. WKD-keys or marginal valid keys in the web of trust) and displays this difference in the area to check the signature of an email. In this criterion it doesn't matter, how the trust is calculated.
- K10: Displays that WKD-keys have a basic trust (compose).
- K11: Displays that WKD-keys have a basic trust (check of signature).
- K12: Displays different levels of trust (compose).
- K13: Displays different levels of trust (check of signature).
Tests
This section describes the results of the tests. The tested products are only free software that is under active development and I tried to choose the most relevant products. The following table summarizes how far the products fulfill the criteria that were explained above.
Overview
| Criterion\Product | Claws Mail | FairEmail | K9Mail | KMail | Mailvelope | Thunderbird |
|---|---|---|---|---|---|---|
| K1: The product is compatible to the last draft of the WKD-standard |  yes |
 no |
no |
yes |
no |
no |
| K2: The product is ready for WKD without any preparations | no |
no |
no |
no |
yes |
no |
| K3: WKD is offered in the area where users enter an email-address | no |
no |
no |
yes |
yes |
no |
| K4: WKD is offered in the area where users check the signature of an email | yes |
no |
no |
no |
 no result |
no |
| K5: The product uses WKD automatically (compose) | no |
no |
no |
yes |
yes |
no |
| K6: Product prefers WKD-keys, when there are only keys without information about their trust else (compose) | no |
no |
yes |
no |
no |
no |
| K7: Product prefers WKD-keys, when there are only keys without information about their trust else (signature check) | no |
no |
no |
no |
no result |
no |
| K8: The product distinguishes between keys without any information about their trust and keys with basic trust (compose) | no |
no |
yes |
yes |
no |
no |
| K9: The product distinguishes between keys without any information about their trust and keys with basic trust (signature check) | yes |
no |
yes |
yes |
no result |
yes |
| K10: Displays that WKD-keys have a basic trust (compose) | no |
no |
no |
no |
no |
no |
| K11: Displays that WKD-keys have a basic trust (signature check) | no |
no |
no |
no |
no result |
no |
| K12: Displays different levels of trust (compose) | no |
no |
no |
no |
no |
no |
| K13: Displays different levels of trust (signature check) | yes |
no |
no |
no |
no result |
yes |
Mailvelope
Previous state (analyzed version 4.4.1)
- Does use WKD and WKD is used automatically
- The implementation is not up-to-date since it doesn't contain the advanced method
- There is an issue for the advanced method on Github: https://github.com/mailvelope/mailvelope/issues/774
- It should be possible to check the signature, but when sending signed emails from different email clients to an account on mailbox.org, there was no sign of a signature check
- Does not show information about the trust of a key
Measures
- As part of this work the implementation of the advanced method was added to Mailvelope
- The chapter "Implementation" explains how the background behind the implementation of the advanced method.
Claws Mail
Previous state (analyzed version 3.18.0)
- Integrated WKD since version 3.18.0 / 4.0.0
- Pubkeys can only be retrieved, when users get an encrypted email
- How to enable encryption and use WKD can be found on this wiki page
- When a user opens an email an presses "C" on the keyboard, the signature will be checked. Then the level of trust will be displayed at the bottom of the email
- No information about the trust level of a pubkey is shown when composing an email
Measures
- Request: In the compose window users can right-click on an email address to open a context menu, where they can e.g. add this address to their address book. To give users the possibility to retrieve keys of email addresses, from which they didn't receive an email yet, it was requested to implement another action to do just that. Optionally, this action could be shown only, if the user enabled a privacy system.
- Request: Automatically enable a privacy system as soon as an user adds one, when loading a plugin.
FairEmail/ K9Mail
Previous state
- Use OpenKeyChain to retrieve keys via WKD and encrypt emails
- It is necessary to open OpenKeyChain to retrieve keys. This step is not possible in the GUI of the products
- OpenKeyChain is not compatible with the last version of the WKD-standard because it uses the direct method, even if the subdomain "openpgpkey" exists
FairEmail
Previous state (analyzed version 1.1776)
- Heuristic Evaluation of FairEmail
- Does not show any information about the pubkey that was used to check a signature
- No information about the trustworthiness of a key is shown when composing an email
Measures
- Requested an easier way to open the OpenKeyChain app, so users can open it from FairEmail and don't have to go to the settings of the phone to start the OpenKeyChain app there.
- Reported a bug: When an encrypted mail was recieved and that mail was decrypted with FairEmail, a message appeared saying, that the mail isn't signed. But when the mail is decrypted there is an icon left of the lock icon and after a tap on it, a message appears, which tells that the signature is valid. So the first message seems to be incorrect.
- Was fixed in a newer version
- Recommended to edit the UI in the compose window. There are three icons. Two of them can be interacted with and one not, but all of them have the same style (no borders, no background, same color etc.). To be more consistent it was suggested to remove the icon without function or to adjust the style of the icons, so that the one, which can't be interacted with, has a different style.
- The icons got different colors in a newer version
K9Mail
Previous state (analyzed version 5.806)
- Shows, if a key for an email is available
- The icon for encryption changes in the composing window, when a key was signed in OpenKeyChain, but there are also only the same information as for the key that was used to sign an email
- When a received email was signed, an icon will be displayed:
- question mark = unknown pubkey was used
- check mark = a pubkey was used that is in the keyring of OpenKeyChain
- check mark with three dots = a pubkey was used that is in the keyring of OpenKeyChain and was signed there
KMail
- Serves as a reference in this work
- It was analyzed (version 5.18.3), but no measures were taken
- KMail implements the latest WKD-standard
- WKD is not enabled by default. How to change this can be found here.
- Pubkeys are fetched automatically in the composing window, if WKD is enabled.
- Pubkeys are not fetched automatically, when checking a signature
- The icons only differentiate between an ultimately trusted key and keys with less trust (composing and signature checking)
Thunderbird
- Was also only analyzed (version 97.0a1) because it will probably be difficult to contribute to such an extensive product
- Implements parts of the WKD-standard
- If a key is not available, the direct method will be used, even if the subdomain openpgpkey exists. This is not compliant with the standard.
- WKD is enabled by default...
- ...but the search has to be started manually.
- It is mentioned that Thunderbird uses WKD in the user documentation.
- WKD can not directly be used in the composing window. Users have to open a few windows beginning by pressing the "Security"-button in the composing window.
- There is a button (see Screenshot) to retrieve the pubkey to check the signature, but the search does not include WKD.
- Users can choose, if they accept a pubkey for encryption and tell, if they have verified the key (see Screenshot). When they write an email, they don't see any information about a pubkey. When they open a received signed email, they see an icon, which depicts, if they accepted the key. So, Thunderbird itself doesn't inform, if a pubkey is trustworthy, but the user has to decide, if that is the case.
- There is no additional information about the trustworthiness of a pubkey.
mail.de
The email-provider mail.de is a special case in this work because it represents the server-side of WKD and not the client-side as the other products.
Previous state
- It was found out that mail.de did offer a WKD-server, where users could upload their keys via the settings of mail.de
- A test with GnuPG 2.2.27 (gpg -vv --locate-keys --auto-key-locate clear,nodefault,wkd) showed that it was not possible to get the key via WKD
- Ingo Klöcker found the reason with dirmngr: Resolving openpgpkey.mail.de didn't end with an error, so GnuPG didn't use the direct method of WKD.
- Versions of GnuPG that were released before GnuPG 2.2.17 could receive keys from mail.de because they only supported the direct method. The advanced method was introduced in the 7th version of the WKD-draft, which was implemented in GnuPG 2.2.17)
Measures
- The contact form of mail.de was used to contact the support team and tell them about the problem
- After communicating with Michael Kliewe, the Chief Security Officer from mail.de, a TXT record was created for the domain openpgpkey.mail.de
- The result of another test showed that GnuPG now was using the direct method
- Michael Kliewe also gave the information that 165 accounts did upload 171 on the WKD-server since the server was available. That means that there are 171 keys, which can now also be retrieved by clients that are implementing the current WKD-standard
Implementation
This chapter explains, how it was decided, when to use the direct and when to use the advanced method in the new implementation for Mailvelope. Firefox offers the method browser.dns.resolve() to resolve a DNS-name. If the resolve was successful, the advanced method has to be used. In the other case it's the turn of the direct method. But, Chrome doesn't have this method. So, there has to be another way to decide between direct and advanced method. The alternative is to only use the method fetch().
On Chrome we try the advanced method at first (because it has the higher priority). If it's successful, we get a key and everything is fine. When there is an error, another decision has to be made. If the response contains a status code like 404, it is clear that the subdomain exists because the server does give an answer. But, there are also cases, in which a TypeError will be thrown and then we don't know, what the reason is. One option is that the subdomain exists, but the server is not reachable in that moment. Because we can't be sure, we just use the direct method.
The following image shows an activity diagram, where you can see the decisions that are made. 
Download of the bachelor thesis
Here you can download the bachelor thesis (German).
Sources
[1] S. Krug. Don’t make me think, Revisited: A Common Sense Approach to Web Usability, San Francisco, USA: Pearson Education, 2014.
[2] H. Balzert, Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, 3. Edition, Spektrum Akademischer Verlag Heidelberg: 2009