Mobile QR Code QR CODE

  1. (Faculty of Engineering, Okayama University / Okayama city, Okayama, Japan)
  2. (Natural Science and Technology, Institute of Academic and Research, Okayama University / Okayama city, Okayama, Japan fukusima@okayama-u.ac.jp)
  3. (Interdisciplinary Science and Engineering in Health Systems, Institute of Academic and Research, Okayama University / Okayama city, Okayama, Japan )



Email security, PGP, Unique cryptographic algorithms, Enigmail, Thunderbird

1. Introduction

Recently, cybercrimes targeting confidential information (e.g., clinical data for COVID-19 vaccines) have increasingly occurred. To cope with this threat, it is necessary to improve information security. In addition, it is necessary to ensure usability so that the confidential information can be easily shared among appropriate users. In this paper, we focus on email, which is widely used as a communication tool, and tackle realization of an email system that can securely send and receive confidential information.

GNU Privacy Guard (GnuPG) [1] has been used for securely sending and receiving messages using email. GnuPG, an implementation of Pretty Good Privacy (PGP), is free encryption software that is compliant with the OpenPGP standard (RFC4880) [2]. GnuPG provides 1)~digital signatures to prevent message tampering and spoofing, and 2) hybrid encryption (i.e., a combination of public-key encryption and symmetric encryption) to prevent eavesdropping. In GnuPG, only general cryptographic algorithms (e.g., RSA and AES) are used for digital signatures and hybrid encryption. These algorithms and their implementation libraries, however, may contain unknown vulnerabilities, and consequently, cannot always protect confidential information.

In this paper, we modify an email client so that it can use unique cryptographic algorithms instead of general cryptographic algorithms. We use Thunderbird email client [3], which was developed as open source software. Thunderbird uses an extension (add-on) called Enigmail [4] to use cryptographic algorithms implemented in GnuPG. Because Enigmail only allows us to use general cryptographic algorithms, we need to modify Enigmail to use unique cryptographic algorithms. To achieve this goal, we first dynamically analyze the source code of Enigmail and identify the parts related to processing with GnuPG. Then, we modify the identified parts so that Enigmail can use unique cryptographic algorithms, which are assumed to be implemented in GnuPG.

Our contributions are summarized as follows.

· We dynamically analyze the source code of Enigmail, clarify the processing flows of Enigmail in 1) key pair generation, 2) procedure at the sender, and 3) procedure at the receiver, and identify the parts related to processing using GnuPG.

· We modify the source code of Enigmail so that it can invoke unique cryptographic algorithms, which are assumed to be implemented in GnuPG.

· With the experimental evaluations, we show that 1) our modified email client securely exchanges email messages using pseudo-unique cryptographic algorithms, which have been already implemented in GnuPG but are not used in Enigmail, and 2) the processing overhead of our modified email client is negligibly small.

The remainder of this paper is organized as follows. Section 2 surveys the related works. Section 3 gives overviews of Enigmail and GnuPG. Section 4 shows the results of a dynamic analysis of Enigmail, and discusses its modification. In Section 5, we conduct experimental evaluations of the modified email client. Section 6 concludes the paper.

2. Related Work

Many studies focus on email security. Table 1 summarizes the related work. Many of those studies focused on vulnerabilities in email security protocols (e.g., OpenPGP and S/MIME). Reference [5] pointed out that these protocols are vulnerable to chosen ciphertext attacks. Reference [6] described that these protocols are vulnerable to surreptitious forwarding attacks that can re-sign and re-encrypt the original message and forward it to a third person. Reference [7] pointed out that a downgrade attack is applicable to these protocols. Reference [8] described an attack on the OpenPGP format that leads to disclosure of the private signature keys for DSA and RSA algorithms. Reference [9] described an attack that allows the attacker to modify email messages without violating signature validation.

Other studies focused on the usability of email security protocols. Reference [10] considered why many email users do not use end-to-end security (e.g., GnuPG and S/MIME) based on the difference between the implemented end-to-end security features and user requirements. Reference [11] suggested modifications to email clients and services for widespread use of end-to-end email security. Reference [12] evaluated the usability of Pretty Good Privacy (PGP) and suggested some design improvements for it. Reference [13] analyzed popular public email systems from the viewpoint of password management and multiple sign-ins, and revealed several security vulnerabilities in email systems.

Unlike this paper, none of the above studies focused on introducing unique cryptographic algorithms for email.

Fig. 1. Relationships among Thunderbird, Enigmail, and GnuPG.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig1.png

Table 1. Existing studies related to email security.

Papers

Vulnerability of security protocols

Usability of security protocols

Introduction of unique cryptographic algorithms

[5-9]

Yes

No

No

[10-13]

No

Yes

No

3. Enigmail and GnuPG

3.1 Enigmail

Enigmail is an extension (add-on) for Thunderbird. Enigmail was officially released by Patrick Brunschwig in 2009 and has been developed as open source software. The main functions provided by Enigmail are 1) key pair management for digital signatures and public-key encryption, 2) digital signature creation/verification, and 3) message encryption/decryption. In order to realize these functions, Enigmail uses GnuPG on the backend. Fig. 1 depicts the relationships among Thunderbird, Enigmail, and GnuPG.

Enigmail is written in XML User Interface Language (XUL) [14] and JavaScript [15]. XUL is Mozilla’s Extensible Markup Language for building user interfaces for Mozilla applications. Enigmail uses XUL to describe window layouts. Fig. 2 shows an example of the Enigmail source code in XUL. Enigmail uses JavaScript to describe the processing part. Fig. 3 shows an example of Enigmail source code in JavaScript.

3.2 GnuPG

3.2.1 Outline

GNU Privacy Guard (GnuPG) is encryption software developed by the GNU Project and provides various functions related to digital signatures and encryption, including the three functions described in Section 3.1.

The procedure for securely sending or receiving email using GnuPG consists of 1) key pair generation, 2) procedures at the sender, and 3) procedures at the receiver. In the following subsections, we explain each of the procedures.

3.2.2 Key Pair Generation

Before using functions in GnuPG, it is necessary to create public/private key pairs for digital signatures and public-key encryption. The created key pairs consist of 1) a primary key pair for digital signature and 2) a subordinate key pair for public-key encryption. When creating the key pairs, the algorithm for digital signatures and the algorithm for public-key encryption to be used need to be specified.

3.2.3 Procedures at Sender

Fig. 4 shows the procedures for a sender to securely send an email message using GnuPG. The procedures consist of creating a signature and encrypting the message with hybrid encryption.

In the signature creation phase, the sender first enters his or her passphrase, obtains a decryption key, and decrypts his or her private key with the decryption key. Then, the sender creates a digital signature for the email message by using his or her private key. The created digital signature is combined with the email message.

In the encryption phase, the sender generates a session key, which is used as a symmetric key in hybrid encryption, and encrypts the signed email message with the session key using a symmetric encryption algorithm. Then, the sender encrypts the session key with the receiver’s public key using a public-key encryption algorithm. The sender combines the signed email message and the encrypted session key and completes the message to be sent.

Fig. 2. An example of Enigmail source code in XUL.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig2.png

Fig. 3. An example of Enigmail source code in JavaScript.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig3.png

Fig. 4. Procedures at sender in GnuPG.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig4.png

3.2.4 Procedures at Receiver

Fig. 5 shows the procedure for a receiver to securely receive an email message using GnuPG. The procedures consist of decrypting the message with hybrid encryption and verifying the signature.

In the decryption phase, the receiver first enters his or her passphrase, obtains a decryption key, and decrypts his or her private key with the decryption key. Then, the receiver decrypts the received and encrypted session key using his or her private key. The receiver decrypts the encrypted email message with the session key by using the symmetric encryption algorithm.

In the signature verification phase, the receiver first separates the decrypted message into the signature and the message. Then, the receiver verifies the signature using the sender’s public key. If the signature is successfully verified, the receiver obtains the email message.

4. Modification of Enigmail

4.1 Dynamic Analysis of Enigmail

The Enigmail source code consists of 993 files with 118,349 lines in total. In order to understand the processing flow of the source code, we dynamically analyze it using Mozilla’s JavaScript debugger. By stepping through the source code using the debugger, we clarified the processing flows of Enigmail for 1) key pair generation, 2) procedures at the sender, and 3) procedures at the receiver. In the following, we show the details.

Fig. 6 depicts the GUI window of Enigmail for generating key pairs. In this window, both sender and receiver individually generate their public/private key pairs for digital signatures and public-key encryption.

Fig. 5. Procedures at receiver in GnuPG.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig5.png

Fig. 6. GUI window for generating key pairs.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig6.png

Fig. 7. Processing flow in key pair generation by Enigmail.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig7.png

Fig. 8. Part of the source code in generateKey().

../../Resources/ieie/IEIESPC.2021.10.5.439/fig8.png

They can select Key type (i.e., the algorithms for the digital signature and public-key encryption). Fig. 7 shows a series of functions called during the procedure for generating key pairs. When Generate key button in the GUI window is clicked, the oncommand() function in enigmailKeygen.xul is first called, and the rest of the functions in Fig. 7 are called in turn. These functions prepare a command line for GnuPG’s execution (i.e., gpg command). Among these functions, generateKey() and spawn() play important roles. the generateKey() function constructs a command line for gpg command in accordance with the algorithms for digital signatures and public-key encryption. Fig. 8 shows the part of the source code in generateKey() where the command lines for digital signatures and public-key encryption algorithm pairs (RSA, RSA) or (EDDSA, ECDH) are constructed. the spawn() function executes gpg command using the exec function in the GNU C library.

Fig. 9 shows the processing flow of the Enigmail procedure at the sender. When the sender clicks Send button in Thunderbird, sendMessageListener() is called in a way that interrupts the Thunderbird sending process. After that, the subsequent functions in Fig. 9 are called in turn: encryptMsg() confirms whether to add a digital signature to the message and whether to encrypt the message; keySelection() selects the key pair to use, and encryptTestMessage() checks if the selected key pair is available; encryptMessageStart() prepares for the command line arguments to be passed to gpg command, and execStart() invokes call() to execute gpg command. The following processing flow of call() (i.e., to invoke spawn() function) is the same as the processing flow when the key pair is generated, so it is omitted here.

Fig. 10 shows the Enigmail processing flow of the procedure at receiver. When the receiver opens the received message in Thunderbird, onStopRequest() interrupts and calls decryptMime(). In function decryptMime(), if message decryption fails, exception handling is performed; otherwise, decrypt() is called, which prepares command line arguments to be passed to gpg command. The following processing flow until the gpg command is executed is the same as that at the sender, so it is omitted here.

4.2 Modification Policy

The dynamic analysis of Enigmail source code clarified the following.

· Enigmail depends on GnuPG for 1) key pair generation, 2) signature creation/verification, and 3) message encryption/decryption, by executing gpg command.

· The types of signature algorithm and the public-key encryption algorithm used in hybrid encryption are specified when the key pairs are generated.

· Enigmail gives different command line arguments to GnuPG when executing gpg command, depending on the type of signature algorithm and the public-key encryption algorithm.

· Enigmail uses only two combinations of signature algorithms and public-key encryption algorithms: (RSA, RSA) and (EDDSA, ECDH).

· The type of symmetric encryption algorithm used in hybrid encryption is not specified in the Enigmail source code, but is specified in a GnuPG configuration file.

From the above analysis, in order to use unique cryptographic algorithms, which are assumed to be implemented in GnuPG, with Enigmail, the following modifications should be applied to the Enigmail source code.

· In order to use a unique signature algorithm and a unique public-key encryption algorithm, we need to generate a primary key pair corresponding to the unique signature algorithm as well as a subordinate key pair corresponding to the unique public-key encryption algorithm in the key pair generation procedure.

· In order to use a unique symmetric encryption algorithm in hybrid encryption, we need to specify the type of the unique symmetric encryption algorithm in a GnuPG configuration file.

In this paper, we assume that unique cryptographic algorithms are implemented in GnuPG. Implementing unique cryptographic algorithms in GnuPG is outside the scope of this paper. We regard cryptographic algorithms that have already been implemented in GnuPG, but are not used in Enigmail, as unique cryptographic algorithms, which we call pseudo-unique cryptographic algorithms in this paper.

Table 2 shows the signature algorithms and public-key encryption algorithms supported by GnuPG. GnuPG supports RSA, ECDSA, EDDSA, and DSA for signature algorithms, and RSA, ECDH, and ElGamal for public-key encryption algorithms. Table 3 shows the signature algorithms and public-key encryption algorithms used by Enigmail, which are RSA and EDDSA as signature algorithms, and RSA and ECDH as public-key encryption algorithms. Among the algorithms supported by GnuPG, ECDSA and DSA for signature algorithms, and ElGamal for public-key encryption, are not used in Enigmail. In this paper, as shown in Table 4, we regard DSA and ElGamal as a pseudo-unique signature algorithm and a pseudo-unique public-key encryption algorithm, respectively.

Fig. 9. Processing flow in procedures at sender by Enigmail.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig9.png

Fig. 10. Processing flow in procedures at receiver by Enigmail.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig10.png

Table 2. Signature algorithms and public-key encryption algorithms supported by GnuPG.

Signature algorithm

Public-key encryption algorithm

RSA, ECDSA, EDDSA, DSA

RSA, ECDH, ElGamal

Table 3. Signature algorithms and public-key encryption algorithms supported by Enigmail.

Signature algorithm

Public-key encryption algorithm

RSA, EDDSA,

RSA, ECDH

4.3 Modification of Enigmail

4.3.1 Modification for the Unique Signature Algorithm and the Public-key Encryption Algorithm

We modify the Enigmail source code so that it can use the pseudo-unique signature algorithm (DSA in this paper) and the pseudo-unique public-key encryption algorithm (ElGamal in this paper). The types of signature algorithm and public-key encryption algorithm to be used in Enigmail must be specified when generating the key pairs. Therefore, we modify the following two parts in the Enigmail source code: 1) the GUI Window displayed when the key pairs for signature and public-key encryption algorithms are generated, and 2) generation of the command line argument to be passed to gpg command when generating key pairs.

The first modification is for the GUI window that is displayed when key pairs are generated. The layout of the GUI window is defined in enigmailKeygen.xul. Fig. 11 shows the part modified in enigmailKeygen.xul. This code displays a combo box for selecting a pair of signature and public-key encryption algorithms to be used. The <menuitem> tag represents a pair of algorithms the user can select. In the original enigmailKeygen.xul, only two types of algorithm can be selected—RSA (both algorithms are RSA) and ECC (a pair of EDDSA and ECDH). In Fig. 11, we add a third option: DSA (a pair of DSA and ElGamal).

The second modification is for generation of the command line argument to be passed to gpg command when generating key pairs. This command line argument is generated in generateKey() of keyRing.jsm. Fig. 12 shows the part modified in keyRing.jsm, which generates a command line argument according to the types of signature algorithm and public-key encryption algorithm to be used, storing it in the variable inputData. In the original keyRing.jsm, command line arguments for only two types of algorithm can be generated: RSA (both algorithms are RSA) and ECC (a pair of EDDSA and ECDH). In Fig. 12, we add a menu item for generating a command line argument for the third option: DSA (a pair of DSA and ElGamal).

Table 4. Signature algorithm and public-key encryption algorithm assumed to be pseudo-unique cryptographic algorithms in this paper.

Signature algorithm

Public-key encryption algorithm

DSA

ElGamal

Fig. 11. Modified enigmailKeygen.xul code (in bold).

../../Resources/ieie/IEIESPC.2021.10.5.439/fig11.png

Fig. 12. Modified keyring.jsm code (in bold).

../../Resources/ieie/IEIESPC.2021.10.5.439/fig12.png

4.3.2 Modification for using a Unique Symmetric Encryption Algorithm

We modify Enigmail so that it can use unique symmetric cryptograph algorithms. As mentioned in Section 4.2 Modification Policy, the type of symmetric encryption algorithm used in hybrid encryption is not specified in the Enigmail source code, but is specified in a GnuPG configuration file called gpg.conf. Therefore, in order to use a unique symmetric encryption algorithm in Enigmail, gpg.conf must be modified. In gpg.conf, the personal-cipher-preferences option specifies a list of preferred symmetric encryption algorithms in descending order of preference. We can use a unique symmetric cryptograph algorithm by setting it at the top of the list.

5. Experimental Evaluation

5.1 Experimental Environment

Fig. 13 depicts the experimental network, which consists of an email sender, an email receiver, and two Gmail mail servers (smtp.gmail.com and imap.gmail.com). Both sender and receiver use Thunderbird with Enigmail and GnuPG as email clients. Table 5 lists the software versions.

In this experiment, we confirm the following.

1. The sender and the receiver can individually generate key pairs for the pseudo-unique signature algorithm (DSA) and the pseudo-unique public-key encryption algorithm (ElGamal).

2. The sender can send an email to the receiver using the pseudo-unique signature algorithm and pseudo-unique public-key encryption algorithm.

3. The processing overhead of our modified Enigmail is negligibly small.

Please note that the sender and receiver exchange and share their own public keys before using the pseudo-unique signature algorithm and pseudo-unique public-key encryption algorithm.

Fig. 13. Experimental network.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig13.png

Fig. 14. Original GUI window to generate Enigmail key pairs.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig14.png

Fig. 15. Modified GUI window to generate Enigmail key pairs.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig15.png

Fig. 16. Enigmail security information at the receiver.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig16.png

5.2 Result

We first confirm that the sender and receiver can individually generate key pairs for the pseudo-unique signature algorithm (DSA) and the pseudo-unique public-key encryption algorithm (ElGamal). Figs. 14 and 15, respectively, show the GUI windows for generating key pairs for the signature and public-key encryption algorithms in the original Enigmail and the modified Enigmail. The original Enigmail (Fig. 14) has only two options: RSA (both algorithms are RSA) and ECC (a pair of EDDSA and ECDH). In the modified Enigmail (Fig. 15), in addition to the two options, we can select a third: DSA (a pair of DSA and ElGamal). We confirmed that by selecting the third option, we can generate key pairs consisting of a primary key pair for DSA and a subordinate key pair for ElGamal.

We then confirm that the sender can send an email to the receiver using the pseudo-unique signature algorithm (DSA) and the pseudo-unique public-key encryption algorithm (ElGamal). First, the sender sends an email that is signed and encrypted using the key pairs for DSA and ElGamal, to the receiver. The receiver receives the email, verifies the signature, and decrypts the message. Fig. 16 shows the Enigmail security information for the received email, which can be output at the receiver. We confirmed that 1) the key pairs for DSA and ElGamal are certainly used, because Key ID in Fig. 16 matches that of the key pairs, and 2) the pair of the pseudo-unique digital signature and public-key encryption algorithms (DSA, ElGamal) is certainly used, because Used Algorithm in Fig. 16 matches DSA.

We evaluate the processing overhead of our modified Enigmail. Fig. 17 depicts the processing time at the sender for (RSA, RSA), (EDDSA, ECDH), and (DSA, ElGamal), as well as without encryption (i.e., no cryptographic algorithm was used in sending the email). The processing time at the sender is the delay from when the Send button is clicked to when the sending process is finished. The processing times for (RSA, RSA), (EDDSA, ECDH), (DSA, ElGamal), and without encryption are 5.61, 5.25, 5.26, and 5.15 seconds, respectively. The processing overhead of our modified Enigmail ranges from 0.1 to 0.46s.

We also confirmed that at the receiver, the email was displayed as soon as the receiver selected the email in the mail box for (RSA, RSA), (EDDSA, ECDH), and (DSA, ElGamal). Therefore, we can say that the processing overhead of our modified Enigmail is negligibly small.

Table 5. Software versions for the sender and receiver.

Name

Version

Operating System

Ubuntu Ver. 18.04.5

Thunderbird

Ver. 68.10.0 64-bit

Enigmail

Ver. 2.17

GnuPG

Ver. 2.2.4

Fig. 17. Processing times at the sender.

../../Resources/ieie/IEIESPC.2021.10.5.439/fig17.png

6. Conclusion

In this paper, we have modified Enigmail so that it can use pseudo-unique cryptographic algorithms. We have dynamically analyzed the Enigmail source code, and identified the parts related to processing using GnuPG. Then, we have modified the code identified so that Enigmail can use pseudo-unique cryptographic algorithms. The experimental evaluation confirms that the modified Enigmail exchanges email messages using the pseudo-unique cryptographic algorithms.

ACKNOWLEDGMENTS

This work was supported by JSPS KAKENHI Grant Number JP20K20484.

REFERENCES

1 
GnuPGURL
2 
Finney H., Donnerhacke L., Callas J., Thayer R. L., Shaw D., Nov. 2007, OpenPGP Message Format, RFC 4880URL
3 
ThunderbirdURL
4 
EnigmailURL
5 
Katz J., Schneier B., August 2000, A Chosen Ciphertext Attack Against Several e-Mail Encryption Protocols, in Proc. of SSYM, 7 pagesURL
6 
Davis D., June 2001, Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML, in Proc. of USENIX Annual Technical Conference, pp. 65-78URL
7 
OpenPGP SEIP downgrade attackURL
8 
Klima V., Rosa T., March 2001, Attack on Private Signature Keys of the OpenPGP format, PGP programs and other applications compatible with OpenPGPURL
9 
Muller J., Brinkmann M., Poddebniak D., Bock H., Schinzel S., Somorovsky J., Schwenk J., August 2019, Johnny, you are fired! \textendash{} Spoofing OpenPGP and S/MIME Signatures in Emails, in Proc. of USENIX Security Symposium, pp. 1011-1028DOI
10 
Muller J., Brinkmann M., Poddebniak D., Bock H., Schinzel S., Somorovsky J., Schwenk J., August 2019, Johnny, you are fired!-Spoofing OpenPGP and S/MIME Signatures in Emails, in Proc. of USENIX Security Symposium, pp. 1011-1028URL
11 
Farrell S., Jan 2009, Why Don't We Encrypt Our Email?, IEEE Internet Computing, Vol. 13, pp. 82-85DOI
12 
Garfinkel S. L., Margrave D., Shiller J. I., Nordlander E., Miller R. C., Apr. 2005, How to Make Secure Email Easier to Use, in Proc. of CHI, pp. 701-710URL
13 
Sheng S., Broderick L., Koranda C. A., Hyland J. J., 2006, Why Johnny Still Can’t Encrypt: Evaluating the Usability of Email Encryption Software, In Proc. of SOUPSURL
14 
Li T., Mehta A., Yang P., June 2017, Security Analysis of Email Systems, in Proc. of CSCloud, pp. 91-96DOI
15 
XUL:Home PageURL
16 
MDN Web DocsURL

Author

Ryotaro Tani

Ryotaro Tani received his B.E. degree from Okayama University, Japan, in 2021.

Yukinobu Fukushima
../../Resources/ieie/IEIESPC.2021.10.5.439/au1.png

Yukinobu Fukushima received his B.E., M.E. and Ph.D. degrees from Osaka University, Japan, in 2001, 2003 and 2006. He is currently an associate professor of the Graduate School of Natural Science and Technology, Okayama University. His research interest includes knowledge-defined networking, edge computing and network virtualization. He is a member of IEEE, ACM, and IEICE.

Yuya Tarutani
../../Resources/ieie/IEIESPC.2021.10.5.439/au2.png

Yuya Tarutani received an M.E. and a Ph.D. in Information Science and Technology from Osaka University in 2012 and 2014, respectively. In October 2014, he was an Assistant Professor at the Cybermedia Center, Osaka University. From December 2018, he became an Assistant Professor at the Health the Graduate School of Interdisciplinary Science and Engineering in Health Systems, Okayama University. His research interests include virtual network configuration, data center networks, and IoT systems. He is a Member of IEICE and IEEE.