TaniRyotaro1
FukushimaYukinobu2
TarutaniYuya3
-
(Faculty of Engineering, Okayama University / Okayama city, Okayama, Japan)
-
(Natural Science and Technology, Institute of Academic and Research, Okayama University
/ Okayama city, Okayama, Japan fukusima@okayama-u.ac.jp)
-
(Interdisciplinary Science and Engineering in Health Systems, Institute of Academic
and Research, Okayama University / Okayama city, Okayama, Japan )
Copyright © The Institute of Electronics and Information Engineers(IEIE)
Keywords
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.
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.
Fig. 3. An example of Enigmail source code in JavaScript.
Fig. 4. Procedures at sender in GnuPG.
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.
Fig. 6. GUI window for generating key pairs.
Fig. 7. Processing flow in key pair generation by Enigmail.
Fig. 8. Part of the source code in generateKey().
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.
Fig. 10. Processing flow in procedures at receiver by Enigmail.
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).
Fig. 12. Modified keyring.jsm code (in bold).
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.
Fig. 14. Original GUI window to generate Enigmail key pairs.
Fig. 15. Modified GUI window to generate Enigmail key pairs.
Fig. 16. Enigmail security information at the receiver.
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.
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
GnuPG
Finney H., Donnerhacke L., Callas J., Thayer R. L., Shaw D., Nov. 2007, OpenPGP Message
Format, RFC 4880
Thunderbird
Enigmail
Katz J., Schneier B., August 2000, A Chosen Ciphertext Attack Against Several e-Mail
Encryption Protocols, in Proc. of SSYM, 7 pages
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-78
OpenPGP SEIP downgrade attack
Klima V., Rosa T., March 2001, Attack on Private Signature Keys of the OpenPGP format,
PGP programs and other applications compatible with OpenPGP
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-1028
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-1028
Farrell S., Jan 2009, Why Don't We Encrypt Our Email?, IEEE Internet Computing, Vol.
13, pp. 82-85
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-710
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 SOUPS
Li T., Mehta A., Yang P., June 2017, Security Analysis of Email Systems, in Proc.
of CSCloud, pp. 91-96
XUL:Home Page
MDN Web Docs
Author
Ryotaro Tani
Ryotaro Tani received his B.E. degree from Okayama University, Japan, in 2021.
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 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.