Masaryk University Faculty of Informatics

PGP (GPG) for small and medium enterprises

Master’s Thesis

Zuzana Melšová

Brno, Fall 2016

Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Zuzana Melšová

Advisor: prof. RNDr. Václav Matyáš, M.Sc., Ph.D.

i

Acknowledgement

I would like to thank my supervisor, prof. RNDr. Václav Matyáš, M.Sc., Ph.D., for his valuable feedback on my writing. I would also like to thank Ing. Zbyněk Sopuch for his consultations on the practical part of this thesis.

iii Abstract

The aim of this thesis is to design and implement a prototype of end-to- end encryption system for small and medium-sized enterprises which minimizes interaction with the end user, is easy to deploy, and is also able to connect with another enterprise. This thesis provides an overview of the current state of email encryption software area and an evaluation of its suitability for deployment in enterprises. After analyzing problems regarding usability, security, and deployment, an email encryption solution is presented, and a proof-of-concept implementation for is provided.

iv Keywords

PGP, GPG, email encryption, usability, Microsoft Outlook, Active Di- rectory

v

Contents

1 Introduction ...... 1 2 Email encryption overview ...... 3 2.1 Email encryption standards ...... 3 2.2 Email encryption software ...... 6 3 Problem analysis and solution design ...... 13 3.1 Implementation goals ...... 13 3.2 Solution design ...... 14 4 Implementation ...... 19 4.1 Outlook add-in ...... 19 4.2 Active directory and key storage ...... 27 4.3 Administrator tool ...... 29 4.4 Future work ...... 29 5 Conclusion ...... 37 Bibliography ...... 39

vii

1 Introduction

Nowadays, when advanced security mechanisms exist to protect data, systems, and networks, are still surprisingly mostly sent un- encrypted. Since the email protocols that were designed many years ago without the security in mind are still in use, we have to use ad- ditional software to secure our emails. In spite of that a lot of email encryption software exists, it is not widely used because of its bad usability. The standards for email encryption employs a public-key cryptography, which needs the participants to exchange their public keys before they can communicate securely. These standards have not been designed with a focus on good usability for an average end user. Even though the software has a user-friendly interface for managing keys and encrypting messages, users still need to understand the con- cept of public-key cryptography to be able to exchange the right keys and verify whether the public key belongs to the person to which it is declared. This thesis focuses on bringing usable email encryption to small and medium-sized enterprises, where we can not count on large IT staff to be available to manage the system. Therefore the solution should be easily deployable and maintainable. We focus on mini- mizing user interaction with the system and automating as much as possible to take the responsibility to verify and use the correct keys from the user. On the other hand, we want the key management to be transparent for the enterprises. We aim to automatically encrypt all the internal communication and also make it possible to easily connect with another enterprise. This thesis provides an overview of the existing email encryption software. We have analyzed its usability, security, trust models and the suitability for the enterprise-wide deployment. Based on the analysis, we have designed a generic solution for automated key distribution and email encryption, and implemented a proof of concept as an add- in for Microsoft Outlook email client, using Active Directory to supply the internal infrastructure and to store the keys. The second chapter provides an overview of the current state of email encryption area. The third chapter consists of problem analy- sis with a focus on the deployment in enterprises and presents our

1 1. Introduction solution. It is followed by a chapter describing the proof-of-concept implementation for Outlook email client and proposing possible im- provements and extensions for the future.

2 2 Email encryption overview

This chapter provides an overview of the present state of the area of end-to-end email encryption. First, a high-level description of two most widely used email encryption standards is provided, which is needed to understand limitations of the systems that employ these standards. Since these standards have many issues regarding usability and also security, a group of researchers recently designed an email protocol suite including end-to-end security which solves some of these problems. We briefly describe the idea behind this protocol asit could be the future of encrypted email. The second part of this chapter provides an overview of existing email encryption software with a focus on its usability, security, key management, and suitability for deployment in enterprises.

2.1 Email encryption standards

Two main standards are currently used for the end-to-end email en- cryption and signing: S/MIME [1] and OpenPGP [2]. The encryption schemes are very similar, and both of them use a combination of symmetric-key cryptography, public-key cryptography and hashing. The messages are encrypted by a symmetric algorithm with a key which is newly generated for each message. This symmetric key is then encrypted with the public key of the recipient and enclosed to the encrypted message. To also provide an integrity of the email, the sender uses his private key to sign a hash of the message and encloses it to the email before the encryption. Therefore, to be able to perform an encrypted communication, the users must first exchange their public keys. The main difference between the two standards is in the way the public keys are distributed and verified. While the S/MIME uses a cen- tralized trust model based on Certification Authorities, theOpenPGP was designed to use a decentralized trust model known as Web Of Trust.

3 2. Email encryption overview

OpenPGP: The OpenPGP standard [2] was derived from the PGP () encryption software released by Philip Zimmer- mann in 1991 [3]. The standard is implemented in various projects including GnuPG (GNU Privacy Guard, also known as GPG) [4], the most widespread open source implementation. The notation PGP is often used with the meaning of the standard OpenPGP, and so we use it in the rest of this thesis as well. PGP was designed to use the decentralized trust model for public key distribution known as Web Of Trust in which each participant can certify the other participant’s public key by adding a signature to the key. The user decides whether the key is valid or not based on the signatures on the key. The validity of the key can also be verified by checking its fingerprint. For the key distribution, PGP has the concept of key servers. The user can upload his public key to the key server and others can then download it to be able to send him encrypted messages.

S/MIME: The S/MIME (Secure/Multipurpose Internet Exten- sions) [1] standard fundamentally provides users with the same func- tionality as PGP, just with different formats of encryption. The only significant difference is in the key management. The S/MIME uses the X.509 format of certificates and employs the centralized trust model based on Certification Authorities (CA) where the user has first to obtain a certificate from the CA which verifies and certifies his identity and then exchange the certificates with others.

Both of the trust models described above have many issues. The Web Of Trust does not scale well and nonexperienced users do not know which public key can be trusted or not. It brings a big complexity to the system and thus makes it insecure. In the centralized model, the verification of public keys is done automatically. However, it requires to place trust in a third party and there were many cases of compromised CAs. Moreover, obtaining the certificates is a burdensome process which brings additional costs. While both of these technologies bring , confiden- tiality, non-repudiation, and integrity for the emails, they still do not provide enough privacy for the email users. All the metadata including

4 2. Email encryption overview

subject, recipient, and sender are not encrypted so an eavesdropper would still be able to trace who communicate with whom, when, and even guess at what they are talking about from the unencrypted sub- ject header. This could be only solved by introducing a whole new email system with a built-in security. However, a group of researchers including the author of PGP recently proposed new email protocols and architecture with end- to-end security which minimizes exposure of the metadata to the stations along the path between the sender and the recipient. The project named Dark Internet Mail Environment (DIME) [5] aims to make the email secure by default and also make it more secure than the existing approaches. It also focuses on a good usability which requires an automation of the key management including generation, distribution, and validation of the keys. The messages are encrypted on multiple levels so that the particular handling station has access only to the information it needs to see. Regarding the trust model, the service providers still have a trusted position in this system. However, the user can choose among three trust levels (Trustful, Cautious and Paranoid) determining the server’s access to the user’s private keys. In the Trustful Mode, the server handles all the privacy issues on behalf of the user. The keys are generated on the server, so the provider has direct access to the private keys protected only by a passphrase. It assumes that accounts operating in this mode will use traditional access via the SMTP protocol and receive messages using the POP or IMAP protocol over SSL. This mode requires the same level of trust in a service provider as in the old email architecture or the web-based email services which encrypt the messages on the server. It only gives protection to the messages in transit over the internet. The Cautious Mode represents a trade-off between the privacy and a good usability of the system. It minimizes the trust placed in the server, but the user still does not have to do anything to manage the keys. The key generation and encryption are done on the client side. The server only stores encrypted copies of user’s private keys and encrypted messages which allows the user access his from multiple devices without the need to manually transfer the keys. In the Paranoid Mode, the server never has access to the user’s private keys (not even in encrypted form). This mode requires the least amount of trust to be placed in the server but significantly limits

5 2. Email encryption overview the usability of the system as the user can not access his account from multiple devices without transferring the private keys manually which is also the reason why it is not possible to use this mode for the web-based email. The authors also discuss how it would be possible to add a perfect forward secrecy1 to the asynchronous messaging system that the email is, for the Paranoid Mode. Key agreement protocols providing perfect forward secrecy require an exchange of information between both parties to generate the session key, which is not possible to ensure for email communication. Authors say that by relying on a scheme for automatic key discovery and validation using the Paranoid Mode, users can achieve perfect forward secrecy by routinely updating their keys. Because the private keys would never be stored on the server, the user can be assured that the keys could never be recovered. Although it would bring a higher level of security, it does not seem to be a very efficient workaround. The DIME protocol suite aims mainly to provide tools that people can understand and use, and that do not require an installation of ad- ditional encryption software. It still requires to trust the email service provider, at least for public key distribution, but as discussed in the following section, the transparency of the key management just as in the PGP does not bring better security to the system as regular users do not know the concept of public key cryptography. It only brings complexity and therefore bad usability.

2.2 Email encryption software

In this section, we provide an overview of email encryption software. We focus on its architecture, user interface, and its usability as well as the key management and security model. We also discuss its suitability for deployment in enterprises. In last few years, many new implementations of email encryption were released, trying to improve the usability of email encryption so that everyone can understand it and use it easily. We present some representatives of the most widespread products of various types.

1. A protocol is said to have perfect forward secrecy if compromise of long-term keys does not compromise past session keys. [6]

6 2. Email encryption overview

We have found that the available email encryption software falls into three main categories. The first are client-only applications that supply or extend existing desktop email software, mostly with man- ual key management. These are typically add-on tools that encrypt messages using existing email infrastructure. The second are end-to-end encrypted email services which han- dle the encryption automatically and all the key management is also handled automatically on their servers. These are mostly web-based services and many of them provide special accounts for enterprises allowing administrators for example restoring lost keys. Another possibility to secure email communication for organiza- tions which run their own email server, are email encryption gateways. A big advantage of encryption gateways is that the responsibility of knowing which message to encrypt is taken from the user. Gateways provide control of message encryption based on a variety of attributes including subject line, recipient, sender, body content, attachments and a lot of other data. On the other hand, it could be complicated to set the policies properly to avoid any false negatives. But since we are focusing on the end-to-end encryption providing privacy also along the internal infrastructure, we will not discuss this option in more detail. Next, we present some of the PGP-based plugins for Microsoft Outlook and email clients.

Gpg4O: Gpg4O [7] is an add-in for Outlook using the Gpg4win [8] software for email encryption. The user interface for the manual key management requires many steps for the key generation and import of public keys and it allows the user to use wrong keys for encryption. The message encryption is not automated. It requires user interaction and makes it easy to unintentionally send the message unencrypted when the user forgets to click on the encrypt button before sending the message.

Enigmail: The encryption is better solved in [9], an add-on for the multi-platform email client Thunderbird. It allows the user to set automatic encryption when the recipients’ public keys are available and displays a warning message requiring user’s confirmation when

7 2. Email encryption overview the message is not encrypted before sending. It requires the GnuPG software [4] to be installed first.

Regarding the key management, both of these plugins provide com- plex tools allowing the public key distribution in any of these three ways:

∙ Attach the public key to an email and import it right from the attachment relying on the Trust On First Use principle2.

∙ Upload and retrieve public keys from a key server.

∙ Import a key from a file, when users exchange their keys in another way.

None of these methods is practical and secure enough for enterprise- wide deployment when users have to exchange keys with one another and somehow verify validity of the keys before they can start a .

Mailpile: The most intuitive user experience regarding both the encryption and the key management provides a PGP-based email client Mailpile [11] which currently exists in a beta version only. The keys are generated during the account creation on the client side, and the distribution of public keys is much more automated. It does not support features allowing the use of the principles of the Web Of Trust. Instead of this, it relies on the Trust On First Use principle with key servers and traditional fingerprint verification as a fallback strategy. When a new message is composed, it automatically searches for recipients keys. First, in sender’s local keyring and afterward on key servers or other external services when the required key is not stored locally.

2. Trust On First Use (TOFU) is a security model which assumes the absence of an adversary on the initial connection and accept the initial key without verification. If a different public key is used in subsequent connections, it will be considered untrusted. [10]

8 2. Email encryption overview

Symantec Desktop Email Encryption: Probably the best solution regarding key management is Symantec Desktop Email Encryption [12]. This email client automatically searches for public keys of the recipients in the PGP Global Directory which is a key server set to be trusted by the client by default. The PGP Global Directory key server works as a certification authority. It verifies the user’s identity through email and signs his key to be trusted by other users. However, the user interface also makes it easy to send an un- ecrypted message since by default, if it cannot find a public key for some of the recipients, it sends that email unencrypted without any warning. This is possible to configure so that the user is notified when the key is not found and is given an option to cancel sending the message. As in the previous software, the automated encryption and signing can be turned on.

Mailvelope: A solution for encryption in web-based email clients provides the Mailvelope, an add-in for Chrome and browsers [13]. Because it is not possible to know what the client does with the message, if it, for example, saves the unencrypted copy of the message when typing, all private data like message content and keys are isolated from the webmail client. Mailvelope opens a separate window to type the message in, then sends the encrypted text back into the webmail client. The key management is done manually in a similar way like in the desktop client add-ins described above.

S/MIME in Outlook: While the PGP-based implementations are mostly available as add-ins to many email applications, S/MIME is integrated into nearly each of the most widely used email applications. One of the possibilities to use S/MIME is Microsoft Outlook S/MIME embedded functionality [14]. The user interface is not improved a lot here, compared with the applications described above. It is also possible to configure the client to encrypt messages automatically, and warning message requiring confirmation is displayed when the message is not encrypted before sending. The key management, in this case, is not better than in the PGP-based tools as users have to deal with obtaining and exchanging valid certificates. However, for enterprises having a Windows-based infrastructure, it is possible to

9 2. Email encryption overview use Active Directory Certification Services to automatically distribute the certificates to all the users so that everyone can send encrypted emails to each other. Although it still requires several steps for the user to import his certificate and publish it for the others, it is one of the most practical solutions when we need to establish a secure communication along the internal infrastructure only.

Web-based services: Nowadays, with the widespread use of mobile devices, it is important for users to have access to their email on every device they use, so they need a copy of their private key on each of them. With the encryption software described above, the users have to transfer the keys manually. This is solved by the last type of email encryption products, hosted email services providing end-to-end encryption with all the key man- agement handled on their servers. The keys are synced across user devices, so users do not have to transfer them manually. We present two interesting examples from this category: ProtonMail [15] and Tutanota [16]. For both these services, when an account is created, a pair of keys is generated on the user’s computer and both the private and the public keys are stored on the servers along with the user’s profile. Before the private key is sent to the server, it is encrypted with the user’s password. While ProtonMail is based on the OpenPGP standard, Tutanota uses its own encryption scheme, so it is not compatible with any other email encryption software. However, the reason why the Tutanota’s authors do not use any of the standards is that they aim to improve the privacy. Unlike the PGP or S/MIME-based systems, Tutanota also encrypts the subject line. These services also provide users with the best usability. The only thing user have to do is create a new email account and then all the messages are automatically encrypted for the users of the same service. Both services provide a workaround for secure communication with users who do not have an account for the same service. It sends a generic message into the recipient’s mailbox, providing him with a link to open the encrypted message. To decrypt the email, the recipient has to enter a unique password for the message with which the sender has to provide him beforehand.

10 2. Email encryption overview

Both of these services provide web-based clients as well as mobile applications for iOS and Android environments. Moreover, Tutanota provides an add-on for Microsoft Outlook and special accounts for enterprises with administrators accounts allowing resetting the users’ passwords. Disadvantage of these services is that it requires to trust to a third party to distribute the public keys without any possibility to verify the validity of the key.

Before we conclude this overview, we present some results of stud- ies done to evaluate the usability of PGP. In 1999, Alma Whitten and Doug Tygar released their study of the usability of PGP 5.0 [17] re- vealing that most people couldn’t figure out how to sign and encrypt messages using that version of PGP. Eight years later, another group of researchers published a follow-up study [18] saying that, although in a newer version of PGP the user interface was improved and au- tomatic message decryption was added, most people still struggled with encrypting and signing messages, finding and verifying other people’s public encryption keys, and sharing their own keys. Recently, a study evaluating the usability of the PGP-based browser plugin Mailvelope [19] was released with an attempt to see if the mod- ern PGP-based tools have improved to be usable enough to provide effective security for most users. Only one of ten participant pairs were able to exchange keys. The successful pair was the only pair of par- ticipants where one of the participants had previously learned about public-key cryptography. None of the pairs was able to encrypt and sign the message properly. The most common mistake was encrypting a message with the sender’s public key. One participant even exported his private key and sent it with his keyring password to his partner so that his partner could decrypt the message. While the user interface of the PGP-based tools have improved a lot, it follows from these results that the manual key management is the main problem preventing the secure use of systems based on public key cryptography. The best usability is provided by the web-based services like Tutanota as it has fully automated key management and email encryption. However, it requires to change the email provider and certain level of trust to a third party.

11

3 Problem analysis and solution design

In this chapter, we analyze the requirements for a PGP-based email encryption system suitable for deployment in small and medium-sized enterprises. The system should be easily deployable to existing email infrastructure which includes the local email server and desktop client applications. We need to encrypt internal emails as well as establish a connection with other organizations. The solution should be simple to use so that it does not bring any additional effort to sending emails and mainly so that it is impossible to misuse it in an insecure way which could lead to information exposure from the enterprise. First, we specify the goals which we want to achieve based on what we have learned from the previous chapter. In the second part of this chapter, we present a solution aiming to fulfill all these requirements.

3.1 Implementation goals

Automatic message encryption transparent to user: All the inter- nal email communication and also the communication between the connected enterprises should be encrypted automatically. The user should be clearly informed whether the message is going to be sent encrypted and signed and a user confirmation should be required when the message could not be encrypted so that no messages are un- intentionally sent unencrypted. The same should apply to the received messages. The user has to be clearly informed whether the message was encrypted and whether it has a valid sender signature.

Automatic key management hidden to user: According to the re- sults of studies mentioned in the previous chapter, regular users do not understand the concept of public key cryptography and are not able to maintain the keys correctly. Therefore, we need to automate the key management. The user’s local database of public keys should be regularly updated so that there always are the keys of all the other users available. The solution should also provide the automatic key exchange with other organizations.

13 3. Problem analysis and solution design

Automatic transfer of private keys between multiple devices: One of the crucial features for today email users is to have the possibility to access their email from multiple devices. Thus it is needed to transfer not only public keys among all the users but also transfer the private keys among all the user’s devices. Letting the users transfer the private keys manually would be neither practical nor secure.

Independence from any third party: Although we want to hide the key management for the end user, we do no want to rely on any third party to store or distribute the keys.

Easy deployment: It should be possible to deploy the solution to the existing email infrastructure easilly and further maintantenance should require minimal effort from administrators.

According to the findings in the previous chapter, there currently is not any encryption software that would meet all of these requirements. While the user interface for the message encryption is simple and intuitive in almost all of the products and also the message encryption is automated in most of them, none of the encryption systems provides the automated public key distribution, automated private key transfer among the user’s devices, and independence from a third party at the same time.

3.2 Solution design

Here we present a generic solution aiming to fulfill all the requirements specified in the previous section.

Key generation and distribution: All the key management includ- ing generating and revoking keys is performed by a system admin- istrator. The keys are generated and stored on the internal server by the administrator and a random passphrase to protect the private key is generated and later changed by the user. The benefits of storing the keys on the local server are that it could serve as a backup for lost or old revoked keys in order to be able to read old messages. The

14 3. Problem analysis and solution design

encrypted private keys are stored there so they can be distributed to every user’s device. It is more secure to distribute the public keys from the local server than using a public key server. In that case, we would have to somehow verify the keys downloaded from the public key server, which could be done by signing the users’ keys by some master key when uploading them to the public key server, but we would have to distribute this master public key to all the users first. Actually, we will use a similar approach for the enterprise connection discussed later in this chapter. The client application on the end user’s computer will download the user’s key pair and the public keys of all the other users and store them in the user’s local keyring. The application will update the keyring regularly to get the keys of new employees or to know which keys were revoked. It should be sufficient to do this update once a day. As the keys will be distributed through the local network, we do not have to add any certification to them before the transfer. There will be a simple tool for administrator to generate keys or revoke them for selected users and to store them on the server.

Email encryption: The emails along with the attachments are en- crypted and signed automatically if there is a public key of each re- cipient available in the local keyring. When some of the recipients’ public keys are missing, the client application first updates the local keyring from the server and if the key is still missing, a dialog appears requiring confirmation from the user that the email can be sent unen- crypted. While this confirmation is very important to prevent sending unintentionally unencrypted messages, it would be very annoying and maybe even confusing for the user to display this dialog also for emails sent to people out of the enterprise, considering the user is not supposed to have their public keys and therefore encrypt the commu- nication with them. To solve this problem, there has to be a possibility to configure in the administrator’s tool for what email domains itis mandatory to encrypt the communication. The administrator only sets the enterprise domain and the domains of the connected enterprises and the application displays the confirmation dialog only if some of the recipients belong to some of these domains.

15 3. Problem analysis and solution design

The messages are also automatically decrypted, and signature is verified when they are read. After the decryption, a message informing the user whether the message was received encrypted and whether the signature is valid is displayed in the user interface. The last problem to solve is how to store the emails. We can only decrypt them when reading and then store the original ciphertext. This is the more secure option, but it does not provide the possibility to search the messages. Regarding the sent messages and drafts, if we store them unencrypted, they could be synced back to the server for some protocols (for example IMAP [20]), and so expose the email on the server unencrypted. For this reason, we store all messages in encrypted form. Once we encrypt the message with the recipient’s public key and send it, there is not a possibility to display the email unencrypted again, so there should be a copy of the sent message stored, encrypted by the sender’s public key.

Connection of two enterprises: To be able to securely exchange the public keys over the internet with another enterprise, there will be a single master key for the whole enterprise. This master key will be used to certify the end users’ public keys exchanged between the organizations. Then we can use an arbitrary public key server to store the certified keys of all the users, and the other enterprise’s server can download them and verify the certificate. We will use the email domain to distinguish the keys we want to download. We generate the keys with the email address as the user identity. Also the master keys will be stored on the public key server and they will have a special name to be distinguishable for the enterprise’s server application. Now, the whole key management is fully automated except for the verification of the master key. So the only thing that the administrators have to do manually, is to exchange the fingerprints of the master keys to be able to verify them. This will be also managed through the administrator tool. The administrator will make the connection with another enterprise just by filling the name of its email domain, filling the address of thepublic key server where the keys of the other enterprise are stored. Then the application will download the master key of the enterprise, and a form

16 3. Problem analysis and solution design will appear in the administrator tool to fill in the fingerprint of the master key. The application verifies the fingerprint and if it is correct it sends this configuration to the local server with the master key and next time when the server will update the keys, it will also download keys for email adresses of this domain. It verifies the signature on all the public keys and store them on the local server to make them accessible to the end users. After the initial exchange, the keys will be regularly updated from the public key server, and their signature will be verified before they are stored on the local server. If the master key becomes compromised, the administrator has to revoke the old key and generate a new one and exchange and verify the fingerprints again. The overall key exchange is outlined in the Figure 3.1. The notation PKX denotes a set of public keys of all users from an enterprise X. The notation PKXSX denotes the set of public keys which are certified by the master key of the enterprise X.The notation FPmasterKeyX denotes the fingerprint of the administrator’s master key from the enterprise X.

17 3. Problem analysis and solution design

Public Key Server

PKASA PKBSB PKASA PKBSB

PKA+B PKA+B

PKA+B PKA+B

Internal infrastructure A Internal infrastructure B

Verify master key B Verify master key A

FPmasterKeyA

FPmasterKeyB System administrator A System administrator B

Figure 3.1: Key exchange.

18 4 Implementation

This chapter describes a proof-of-concept implementation of the email encryption for Microsoft Outlook email client. As the entire system that we have designed is quite complex, we have implemented the email encryption with only the internal automated key exchange which is, however, sufficient to demonstrate the ease of use ofthe whole system. We have developed an add-in for Outlook which encrypts emails and communicates with an internal server of the enterprise to retrieve and update the encryption keys. To supply the internal infrastructure, we use Active Directory (AD) as a central key storage with authenticated access. To manage the keys, we have developed a tool for administrator communicating with the AD. The administrator tool will be used to generate new keys, revoke compromised keys and also to establish a connection with another enterprise to exchange the public keys automatically. Although the feature enabling connection with another enterprise is not implemented, the user interface of the administrator tool is out- lined to demonstrate the steps which would be needed to establish the connection. Using Active Directory also in a real-world imple- mentation would require an additional simple server application for retrieving and uploading the public keys to a public key server, veri- fying the master key signatures on the users’ keys and storing them to the Active Directory.

4.1 Outlook add-in

The add-in has two primary functions. It automatically encrypts emails and also automates the key management retrieving the keys from the Active Directory. In this section, we will briefly describe objects, properties, methods, and events from the Outlook object model [21] which we used to automate all these operations and outline the logic behind the automatic encryption and decryption. The Outlook add-in is a project with a ThisAddIn class that has two methods, Startup and ShutDown. Microsoft Office add-ins can be created by using an extension for Microsoft Office development tools in

19 4. Implementation

Microsoft Visual Studio. To automatically encrypt and decrypt emails on particular events, event handlers are registered in the Startup method which is called when Outlook loads the add-in [22].

Email encryption logic: Emails along with the attachments are au- tomatically signed and encrypted after clicking on the send button if the local keyring contains public keys for all the recipients. To achieve this, we have registered a handler for the ItemSent event. Whenever this event occurs, the application looks for keys of all the recipients in the local keyring and updates the keyring from AD if needed (see Section 3.2 for the logic regarding updating the keys). If some of the keys are missing, a dialog requiring confirmation whether the message can be sent unencrypted appears (see Figure 4.1). As we already mentioned in Section 3.2, this dialog should appear only if the sender is supposed to have the public key of the recipient, which means that the recipient is from the same or connected organization. This is recognized by the recipients’ email domain. A list of the domain names for which the users should encrypt emails are also updated from AD when updating the keys. We also encrypt the messages with the public key of the sender, so that we do not have to store the sent messages unencrypted but the sender still has access to them.

Email decryption logic: Emails are decrypted and signature is veri- fied automatically at the time they are read. An information message is attached to the beginning of the message saying whether the email was encrypted and whether it has a valid signature of the sender (see 4.3). The message is never stored unencrypted. When the user reads the email, the property MailItem.Body is rewritten and the unencrypted message is displayed, but when closing the window the changes are discarded. In the Outlook object model, the window in which the Outlook MailItem is displayed is represented by an Inspector object. It is recommended to write wrappers for the Outlook Inspectors according to the pattern provided by Microsoft [23]. Thanks to the wrappers, we can programmatically identify the window that the user clicked on, handle memory clean-up correctly, handle Inspector objects for

20 4. Implementation

different Outlook items independently and ensure that no events get lost. To write an Inspector wrapper, it is needed to create a base class which has a globally unique identifier (GUID) property that is required to identify each of the Inspector instances. The class has also an Inspector property that provides access to the Inspector instance, and is required for the correct handling of Inspector events. Then we register each Inspector event with a proper method of the Item object. For our application, we needed to write an Inspector wrapper for the MailItem class. Overriding three methods of the Mailitem class: Open, Write1, and Close, we are able to handle the automatic decryption of all emails, and also encryption and decryption of drafts. The Open method is overriden to decrypt the message. In this case, we need to distinguish between opening an inspector for composing a new email and opening an inspector to read emails. For this purpose, we use MailItem.Sent property. If it is set to true, we know that we are reading a message that was already sent. For the current user, it can be either a received message or sent message. To know what key we need to decrypt the message, we also distinguish between the sent and received ones by comparing the sender’s email address with the current user’s. Then we call the method TryDecrypt which decrypts the message if it is encrypted. When the MailItem.Sent property is set to false, than we are opening either the new window or a draft, so when there is a not empty email body or an attachment, we also call the method TryDecrypt here, using the current user’s key. We encrypt the drafts overriding the Write method. In this case we encrypt the message only with the sender’s key when the property MailItem.Sent is set to false. The Close method is overriden to discard the changes made to the message before calling the original Close method, so that we store the original cyphertext. In the Close method, we also have to clean up the memory and references that we have acquired in code.

To sum it up, all the emails which are supposed to be sent encrypted are stored encrypted on the user’s computer including the received messages, sent messages and drafts. The sent messages are encrypted

1. This method is called when the MailItem is saved.

21 4. Implementation also by the sender’s public key to have the possibility to access them later, and so are the drafts when storing them. The add-in brings a small limitation of the usage of Outlook besides the searchability which we discussed in Section 3.2. The Outlook user interface allows to preview messages without opening them, but the Open event is triggered after the Inspector (the new window with the email) is opened. So now, the emails will be displayed in encrypted form in the preview (see Figure 4.2). For this reason,the user also have to forward and reply to messages only through the separate window. Alternatively, the messages could be decrypted right after receiv- ing, registering a handler for the NewMailEXEvent, and stored locally unencrypted to be searchable and able to preview, however, that would be less secure.

Cryptographic operations: For the encryption, we have used the Bouncy Castle PGP library. We have used its C# implementation as all the other used technologies have also their APIs written in C# language. The library provides a high level API for PGP encryption. The encryption, signing and key generation is handled mainly by the following classes: PGPEncryptedDataGenerator, a generator for encrypted objects, PGPSignature, a PGP signature object, and for generating keys, there is a class PGPKeyRingGenerator, a generator for PGP master and sub-key ring. As it is recommended to use different key for signing and encryp- tion (each key from a separate key pair), we are generating one master key used for encryption and one sub-key used for signing. Other- wise, if one of the operations gets compromised, it can break security properties of the other operations where the same key is used. In this library a PGP key ring consists of a master key and a collec- tion of sub-keys associated with it. The public and secret key rings are handled by the PGPPublicKeyRing class and the PGPSecretKeyRing class respectively. The secret key ring contains both, the public and private keys. The classes PGPSecretKeyRingBundle and PGPPublicKeyRingBundle serve for reading a file which has multiple key rings in it [24].

22 4. Implementation

Key management: Each user has a public key ring with all the public keys of the others stored locally on his computer. The add-in commu- nicates with the Active Directory to retrieve and update the local key ring. It updates the public keys of the others, and also the key pair of the user. As we discussed in the previous chapter, the keys should be up- dated regularly at least once a day. The Outlook add-in does it in the following way. The keys are updated when the Outlook is started. Then, every time the user needs to send an encrypted message, it checks if the keys were already updated this day and updates them if needed. When the keys were already updated, and there is still a missing public key of some recipient, it also updates the key ring for the case that the administrator generated the key for the user in the meantime. When some public key is still missing even after the update, it displays a dialog to confirm that the message can be sent unencrypted. The user’s key pair is checked and updated similarly when opening the email for reading.

Application design: As we already mentioned, the Outlook add- in contains a ThisAddIn class that has two methods, Startup and ShutDown. The ShutDown method serves for cleanup of all resources when closing the application. In the Startup method, we register handlers for events and inspector wrappers. Beside that, this class also serves for other Outlook API related tasks as handling the Mailitem object and retrieving the recipients’ or sender’s email adresses. The class PGPCrypto handles the encryption, decryption, signing and verification of given data. The KeyManager class updates the local key rings and uses the class ActiveDirectorySyncService to retrieve the keys from the Active Directory. The InspectorWrapper class im- plements the wrapper for the MailItemInspector according to the following pattern provided by Microsoft [23]. TheAddInConfig class holds the configuration data for the add-in which for example contains the enterprise’s email domain name.

23 4. Implementation

Figure 4.1: Confirmation dialog. Here we have configured the add-in to encrypt all emails for the recipients from the domain .com. When we try to send a message to the recipient from this domain and we do not have his public key, this dialog appears requiring a confirmation that the message can be sent unencrypted.

24 4. Implementation

Figure 4.2: Message preview. The add-in brings also some small limitations of Outlook usage. One of them is that in the preview, the messages are still encrypted, because the Read event which we use for decryption is triggered only when the email is opened in a new window.

25 4. Implementation

Figure 4.3: Decrypted message. After opening the email in a separate window, the message is automatically decrypted and an information message is added to the beginning of the email, saying whether the message was encrypted and the signature veri- fied.

26 4. Implementation 4.2 Active directory and key storage

In our proof-of-concept implementation, we use Active Directory to supply the internal infrastructure to store the keys for each user and to authorize access to them. We access the AD from the Outlook add-in to retrieve the keys and also from the administrator tool to store there the newly generated keys for users. Since this thesis is mainly focused on small and medium-sized enterprises, while the Active Directory is mostly used in large organizations, it could be replaced by a simple server application with a database for the keys. Active Directory (AD) [25] is a directory service for Windows domain networks. It is a set of processes and services that automates network management of user data, security, and distributed resources. One of them is for example the Certificate Services [26] which can be used to distribute certificates for the embedded S/MIME encryption support in Outlook as we mentioned in the second chapter. The most important service is the Active Directory Domain Service (AD DS) which stores information about members of the domain, including devices and users, verifies their credentials and defines their access rights [27]. The server running this service is called domain controller. In our implementation we use this services to store the PGP public and private keys of the users in the User object. To access the objects in the AD DS database, the Lightweight Directory Access Protocol (LDAP) is supported. The objects managed by the AD DS are available via Active Directory Service Interfaces (ADSI) [28]. To easilly access the objects in code, there is a wrapper library for ADSI, namespace System.DirectoryServices [29] and even more high-level library, System.DirectoryServices.AccountManagement [30], which wraps the System.DirectoryServices for an ease of use. Through the System.DirectoryServices.AccountManagement namespace, we can perform basic operations like retrieving the prop- erties of the objects very easilly. The properties are exposed directly within the classes (and typed accordingly). However this namespace does not provide everything we need. It exposes only a small number of the LDAP fields.To access our custom attributes, we have to use the low level System.DirectoryServices namespace. The namespace contains two component classes, DirectoryEntry and DirectorySearcher, which use the Active Directory Services Inter-

27 4. Implementation faces (ADSI) technology. The properties of the AD objects are all held in an array which can bring a lot of problems involving a lot of iteration and use of casting since they are all generic objects. Therefore, this approach is very complicated for retrieving users for example. However, we can use the high-level API to get the UserPrincipal object, and then access the underlying LDAP object with the GetUnderlyingObject method. The following code shows how we use these APIs to retrieve all the users with their public keys. ... var group = GroupPrincipal.FindByIdentity(Domain, "pgpUsers"); foreach (var user in group.GetMembers()) { //using the low level API to get the custom //attributes of the User object var userEntry = (DirectoryEntry)user.GetUnderlyingObject();

var publicKeyString = userEntry.Properties["pgpPublicKey"][0];

using (var inputStream = new MemoryStream( Encoding.UTF8.GetBytes(publicKeyString)))

using (var pgpStream = PgpUtilities.GetDecoderStream(inputStream)) { var pgpPulicKeyRingBundle = new PgpPublicKeyRingBundle(pgpStream); var pgpPublicKeyRings = pgpPulicKeyRingBundle.GetKeyRings(); ... } } ... For our implementation, two new custom attributes for the User object must be introduced in the Active Directory schema: pgpPri- vateKey and pgpPublickey. These will be created as multi-valued

28 4. Implementation

attributes because we need to have stored also the old revoked keys as a backup for access to old emails. For the pgpPublickey attribute we have to permit access to all the users. But for the pgpPrivateKey attribute the access have to be permitted to the owner only.

4.3 Administrator tool

We have designed the administrator tool to facilitate key management, connection establishment with other enterprises and other configura- tion of the system. In our prototype application, we have implemented simplified key management functionality that is sufficient for thein- ternal use of the system only. The application communicates with the Active Directory to retrieve information about users and their keys, and allows the administrator to generate new keys for selected users and store them in the AD. Although, only a part of the designed application functionality is implemented, we have created a user interface for the whole applica- tion to demonstrate the steps needed to establish a connection with another enterprise. See Figure 4.4 and 4.5 for user interface regarding the key management. Figure 4.6, 4.7 and 4.8 presents interface for the enterprise connection establishment.

4.4 Future work

In the previous chapter we have designed a complete generic system for automatic email encryption and key exchange among all the users in multiple organizations which also provides the users with access to their private keys from multiple devices. So far, we have provided a proof-of-concept implementation of the internal automated email encryption and key exchange working on computers on a Windows domain using AD DS. Now we will discuss how the rest of the features could be implemented for this environment and how one can extend the solution to be able to utilize all the applications related to Outlook client. For the Outlook users, a mobile application and a web-based email client are also available to access their account. It is undoubtedly important for users to also have access to their encrypted email from a

29 4. Implementation

Figure 4.4: Administrator tool. The application provides the administrator with information about all users and their keys. After clicking on user’s GUID, a user detail window is opened, displaying a table with all user’s keys. See Figure 4.5.

30 4. Implementation

Figure 4.5: User detail. All keys that were generated for the end user are stored in the AD as a backup to access old emails. The newest key-pair is used for encryption and signing. If the key becomes compromised, the administrator would revoke it and generate a new key.

31 4. Implementation

Figure 4.6: Connected enterprises.

32 4. Implementation

Figure 4.7: Adding new domain. To establish a connection with another enterprise, the administrator would just fill in the enterprise’s email domain and a public key server address, and the application would download the master key of the enterprise. Then, the administrator would enter a fingerprint of the master key for verification.

33 4. Implementation

Figure 4.8: Verifying master key. If the fingerprint corresponds to the public key, the application store this setting to the local server.

34 4. Implementation

mobile phone as well as from a webmail when they for example need access their work email from their personal computer at home, where they do not have the Outlook client installed.

Mobile application: With the add-in support for Outlook mobile application [31] it will be easy to implement the solution similar to our add-in for Outlook desktop client. The add-in would update the keys in the same way, communicating with the AD DS through LDAP. Moreover, in this case, we would have to also configure to which domain controller the application connects as the device is not a part of the domain. Another problem is that we would need to establish a secure channel to transport the keys over the internet as we also transport the private keys which are protected only by a passphrase. Otherwise, we would have to permit updating the keys only in the local network. In our implementation for the Outlook desktop client, we have used the fact that we connect the AD in the local network. In this case, we would have to expose the AD DS externally, but it is not a good practice as it could be insecure. A more secure solution would be to use a VPN to connect the local network.

Webmail: Encrypting emails in a web-based email client could be also quite easy as the Mailvelope project proves 2.2. But to automate the key management, we would have to deal with many issues. We would probably not want to store the private keys locally on each computer where the user access his mailbox through the webmail. For this reason, we would have to send a request to retrieve the keys from the server each time when accessing the mailbox. And here comes the same problem with exposing the private keys and whole AD DS through some web service on the internet. In this case, we assume that when the user access his work email account through the webmail, he access it mostly from his private computer, where he does not have set the access to the enterprise network through the VPN. Moreover, the user would have to set the connection to the AD DS by himself.

Enterprise connection: To be able to store also the keys of the users of the other enterprise, we would have to create one more new attribute somewhere in the AD schema to hold the keys. For updating keys

35 4. Implementation from the public key server, uploading new keys, and verifying the master key certificates, we would have to implement additional server application which could be installed right on the domain controller. The administrator tool would send the configuration regarding the connection establishment to this server application after he verifies the master key of the other enterprise by its fingerprint.

Revoked keys: The last problem is with the revoked keys. As the key management is fully automated and the key rings are updated after some period, there is a possibility that a user will send an email encrypted with the recipient’s public key which has been already revoked. For this reason and also to be able to decrypt old messages, we need to add functionality to the Outlook add-in, which would allow the user to decrypt the message with the old keys. When the message would not be displayed correctly, which prob- ably means that we have used the wrong key for decryption, there should be an information message, saying that the user should first restart Outlook (to ensure the problem is not that the sender has already the new key of the recipient, but the recipient still has not updated his keyring) and if it not helps, there would be a button to change the keys to the old ones trying to decrypt the message with them.

36 5 Conclusion

In this thesis, we have provided an overview of the email encryption software area and analyzed its usability and suitability for deploy- ment in enterprises. We have found that the existing end-to-end email encryption software can be divided into two main categories. The first one includes mostly add-ins for existing desktop email clients with manual key management. The second one are web-based email services that provide the user with the automatic key management which is, however, not transparent for the end user, and also requires the change of an email provider. None of these solutions is suitable for deployment in enterprises as according to several studies users struggle with the manual key management, but on the other hand, we do not want to place trust in any third party to distribute the keys. Based on the analysis, we have proposed a generic solution which automates the email encryption and also the key management. The proposed system is easily deployable to existing email infrastructure which includes the local email server and desktop client applications. It is also easily maintainable so it is suitable for small enterprises without large IT staff to manage the system. The distribution of keys does not rely on any third party. The keys are generated by the system administrator and stored on the enter- prise’s local server and distributed through the internal infrastructure to the users. In our solution, we have used the fact that in an enter- prise, the trust model could be a bit different than it is for a single user. We can rely on the administrator to manage the keys centrally, so we can employ kind of centralized trust model which is much easier to maintain. The key management remains hidden to the end user, but is still transparent to the administrator. The only thing the users are informed about is whether the message is going to be encrypted or not and confirmation is required if the message cannot be encrypted when the recipient’s key is missing. We have designed an administrator tool for generating the keys and establishing a connection with another enterprise with a simple user interface which does not require any deep knowledge about the public key cryptography.

37 5. Conclusion

We have implemented a proof of concept of the email encryption as an add-in for Microsoft Outlook email client. The add-in automatically encrypts emails and retrieves other users’ public keys which are stored in Active Directory. We have also implemented a simple tool for system administrator that facilitates the generation of keys for the end users and their storage in the AD. In the proposed solution, we have fulfilled all the requirements which we specified in Section 3.1. The particular implementation ofthe add-in for Outlook email client brings only few negligible limitations of the Outlook usage.

38 Bibliography

[1] Ramsdell B. and Turner S. Secure/Multipurpose Internet Mail Ex- tensions (S/MIME) Version 3.2 Message Specification. 2010. url: : //tools.ietf.org/html/rfc5751 (visited on 12/25/2016). [2] Callas J. et al. OpenPGP Message Format. 2007. url: https:// tools.ietf.org/html/rfc5751 (visited on 12/25/2016). [3] Zimmermann Philip. Why I Wrote PGP. 1999. url: http://www. philzimmermann.com/EN/essays/WhyIWrotePGP.html (visited on 12/25/2016). [4] GnuPG. 2016. url: https://www.gnupg.org (visited on 12/25/2016). [5] Levison L. et al. Dark Mail Aliance. 2015. url: https://darkmail. info/downloads/dark-internet-mail-environment-march- 2015.pdf (visited on 12/25/2016). [6] Menezes Alfred J., Vanstone Scott A., and Van Oorschot Paul C. Handbook of Applied Cryptography. 1st. CRC Press, Inc., 1996. isbn: 0849385237. [7] Giegerich and Partner GmbH. Gpg4O Manual. 2016. url: http:// download.giepa.de/gpg4o/latest/release/Manual_gpg4o_ EN (visited on 12/25/2016). [8] The Gpg4win Compendium. 2016. url: https://www.gpg4win. org/doc/en/gpg4win-compendium.html (visited on 12/25/2016). [9] Raffo Daniele et al. Openpgp email security for mozilla applica- tions. The Handbook. 2016. url: https://www.enigmail.net/ documentation/Enigmail_Handbook_1.8_en.pdf (visited on 12/25/2016). [10] Wendlandt D., Andersen D.G., and Perrig A. Improving SSH- style Host Authentication with Multi-Path Probing. url: https:// www . usenix . org / legacy / events / usenix08 / tech / full _ papers/wendlandt/wendlandt_html/index.html (visited on 12/25/2016). [11] Mailpile. 2016. url: https : / / www . mailpile . is/ (visited on 12/25/2016). [12] Symantec Encryption Desktop for Windows. User’s Guide. 2016. url: https://symwisedownload.symantec.com/resources/sites/ SYMWISE/content/live/DOCUMENTATION/6000/DOC6205/en_ US/symcEncrDesktop_103_win_usersguide_en.pdf?__gda__=

39 BIBLIOGRAPHY

1482385619 _ f559f527cc4f57335a19ef5b87b5611a (visited on 12/25/2016). [13] Mailvelope. 2016. url: https://www.mailvelope.com/en/help# (visited on 12/25/2016). [14] Microsoft. S/MIME for message signing and encryption. 2015. url: https://technet.microsoft.com/en-us/library/dn626158(v= exchg.150).aspx (visited on 12/25/2016). [15] Protonmail. 2016. url: https : / / . com (visited on 12/25/2016). [16] Tutanota. 2016. url: https://tutanota.com (visited on 12/25/2016). [17] Whitten A. and Tygar J. D. “Why Johnny Can’t Encrypt: A Usabil- ity Evaluation of PGP 5.0”. In: In Proceedings of the 8th USENIX Security Symposium. 1999. [18] Sheng S. et al. “Why Johnny Still Can’t Encrypt: Evaluating the Usability of Email Encryption Software”. In: In Proceedings of the Second Symposium on Usable Privacy and Security. 2006. [19] Ruoti S. et al. “Why Johnny Still, Still Can’t Encrypt: Evaluating the Usability of a Modern PGP Client”. In: (2016). arXiv: 1510. 08555v2. [20] Crispin M. Internet Message Access Protocol - version 4rev1. 2003. url: https : / / tools . ietf . org / html / rfc3501 (visited on 12/25/2016). [21] Microsoft. Outlook Object Model Overview. 2016. url: https:// msdn.microsoft.com/en-us/library/ms268893.aspx (visited on 12/25/2016). [22] Microsoft. Walkthrough: Creating Your First VSTO Add-In for Out- look. 2016. url: https://msdn.microsoft.com/en-us/library/ cc668191.aspx (visited on 12/25/2016). [23] Microsoft. Developing an Inspector Wrapper for Outlook 2010. 2016. url: https://msdn.microsoft.com/en-us/library/office/ ff973716(v=office.14).aspx (visited on 12/25/2016). [24] Package org.bouncycastle.openpgp. 2016. url: http://www.bouncycastle. org/docs/pgdocs1.5on/index.html (visited on 12/25/2016). [25] Microsoft. Active Directory. 2016. url: https://msdn.microsoft. com/en-us/library/bb742424.aspx (visited on 12/25/2016). [26] Microsoft. Active Directory Certificate Services Overview. 2016. url: https://technet.microsoft.com/en-us/library/hh831740(v= ws.11).aspx (visited on 12/25/2016).

40 BIBLIOGRAPHY

[27] Microsoft. Active Directory Domain Services Overview. 2016. url: https://technet.microsoft.com/en-us/library/hh831484(v= ws.11).aspx (visited on 12/25/2016). [28] Microsoft. About Active Directory Service Interfaces. 2016. url: https: //msdn.microsoft.com/en-us/library/aa772161(v=vs.85) .aspx (visited on 12/25/2016). [29] Microsoft. System.DirectoryServices Namespace. 2016. url: https: //msdn.microsoft.com/en-us/library/system.directoryservices(v= vs.110).aspx (visited on 12/25/2016). [30] Microsoft. System.DirectoryServices.AccountManagement Names- pace. 2016. url: https://msdn.microsoft.com/en-us/library/ system.directoryservices.accountmanagement(v=vs.110) .aspx (visited on 12/25/2016). [31] Paul Thurrott. Office Mobile Apps to Gain Add-In Capabilities in 2015. 2015. url: https://www.thurrott.com/office/3256/ office- mobile- apps- to- gain- add- in- capabilities- in- 2015 (visited on 12/25/2016).

41