18-06-2011, 02:52 PM
[attachment=14085]
An Enhanced Pretty Good Privacy (EPGP) System With Mutual Non-Repudiation
Enhanced Pretty Good Privacy (EPGP) is a new cryptosystem based on Pretty Good Privacy (PGP), used for the purpose of secure e-mail message communication over an open network. The idea of EPGP, introduced in this paper, addresses PGP's main drawback of incomplete non-repudiation service, and therefore, attempts to increase the degree of security and efficiency of e-mail message communication.
Keywords: PGP, EPGP, Non-Repudiation, NRO,NRR, MNR, Security.
1 Introduction
Since the beginning of the era of e-mail message communication over open networks, the security of electronic mail (e-mail) has been a growing concern [1]. There have been several protocols developed and implemented to assure the security of such communication. These protocols provide the security services of message confidentiality and message authentication for an e-mail message, basically.
Some e-mail security protocols that have been developed include: Simple Mail Transfer Protocol (SMTP) [2], Multipurpose Internet Mail Extension (MIME), and its enhancement, known as Secure MIME (S/MIME) [3]. Other protocols are: Certified Exchange of Electronic Mail (CEEM) [4], Secure E-mail Protocol (SEP) [5], Privacy Enhanced Mail (PEM) [6] and Pretty Good Privacy (PGP) [7].
Pretty Good Privacy (PGP) [7] is an integrated cryptographic system, invented by Phillip Zimmerman in 1991, in order to establish the integrity, authenticity, compactness, confidentiality, and compatibility of e-mail message communication. Since its invention, PGP has been one of the most successful cryptographic systems used for e-mail security [7], because it has come to offer a comprehensive system that covers a wide variety of security issues.
However, a major drawback of PGP can be seen in its unfair (incomplete) repudiation service, where there is a chance of false repudiation to occur [5]. False repudiation simply means the denial of such e-mailing service by one (or more) parts of e-mail communication [5]. This might be done in order to achieve an illegal benefit or deny a related commitment to such communication service.
Non-repudiation, on the other side, means providing evidence of such a delivery event, in order to protect against such occurring denial of it [8]. This can be done, for example, by providing the protected part by a receipt that serves as evidence of an action performed by the protected part of communication. In terms of e-mail communication, there are two basic types of e-mail non-repudiation services [9]:
(1) Non-Repudiation of Origin (NRO) provides the recipient of a message with evidence of sending the message by its sender, which protects against any attempt by the originator (sender) to falsely deny sending the message, in order to deny any related obligation to such performed action.
(2) Non-Repudiation of Receipt (NRR) provides the originator (sender) of a message with evidence of receiving the message by its receiver, which will protect against any attempt by the recipient to falsely deny receipt of the message, for the similar reason for which an originator would deny sending such an e-mail message.
NRO and NRR help to prevent the occurrence of denial-of-service attacks since every side of communication has evidence of a denied action, and therefore, assures the non-repudiation service of an e-mail communication to be complete, or fair. Although PGP does assure the NRO of e-mail message communication (as shown later) it does not assure its NRR, and its non-repudiation service is therefore, incomplete, or unfair.
Several protocols have been proposed to solve this problem, such as: Secure E-Mail Protocol (SEP)[5], Fair Non-Repudiation (FNP) [10], and its enhancement, a new Fair Non-Repudiation Protocol (FNRP) [9], Certified Mail Protocol (CMP) [11], and Certified Electronic Mail (CEM)[12].
In general, non-repudiation protocols are classified into two types whether is a Trusted Third Party (TTP) involved or not [10]. It is always desired to avoid the use of a TTP in the non-repudiation process [9], because this would decrease the number of trusted parties of communication, a thing which implies higher security within less cost and effort.
However, these protocols did not target the system PGP itself, but instead are proposed new protocols that would assure the fair non-repudiation of an email communication service. In this paper, an Enhanced PGP (EPGP) system is introduced with a new feature of NRR, plus PGP's original feature of NRO, and therefore, assuring the new security service of Mutual Non-Repudiation (MNR) for an e-mail message communication. Before EPGP is introduced, a clear and illustrated explanation of PGP itself is shown in the following section.
2 Summary of PGP
Although PGP is a quite long and sophisticated process, it is possible to summarize the steps of its procedure by considering that sender A, who would like to send an e-mail message of any size, M, to a receiver B. The e-mail message is to be transmitted over an open network, where it is not possible to assure the security of the whole communication line of the network itself. Therefore, the following stages are performed:
Stage I: To assure the integrity of message M, user A's e-mail software computes a digital hash (or digest), M1, from message M, as follows:
A: M1 = H(M) (1)
Where H(M) indicates the function of hashing the message M, using the Secure Hashing Algorithm-1 (SHA-1) to produce a digest for the message.SHA-1 is a strong hashing algorithm that was developed in 1993. It takes an input message with a maximum length of 264–1 bits, and processes it in 512-bit blocks, in order to produce a fixed-length output as a message digest of 160 bits [13].
Stage II: To assure the authenticity of message M, user A's e-mail software computes its digital signature from digest M1, and attaches it to the original message, M, as an authenticator. Therefore, M2 is computed as follows:
A: M2 = DSKRA[M1] || M (2)
Where [M] implies a message that would be encrypted or decrypted, and ║ indicates concatenation (attachment) to the preceding message. DSKRA[M1] indicates the function of producing a digital signature for message M1, by A's private key, KRA, using the Digital Signature Standard (DSS) scheme, as shown in figure (1). The RSA signature scheme may also be used as well.
DSS is a digital signature scheme that was developed in 1991. It computes a digital signature, or an authenticator, of a message in a quite similar way to SHA-1, considering the private key of the signer as part of the computation process of the digital signature to be attached to the message [13].
It is clear now that the NRO has also been achieved. Sender A cannot deny sending message M to receiver B, since its digital signature based on A’s private key (DSKRA[M1]) is attached to the message. This means that applying a digital signature on a message assures the receiver of: a) the authenticity of the sender, and b) the NRO.
Stage III: To assure the compactness of message M, user A's e-mail software compresses message M2 to produce a reduced-size message, M3, as follows:
A: M3 = Z(M2) (3)
Where Z indicates zipping the message by applying a strong ZIP compression algorithm, such as the Lempel-Ziv-1977 (LZ77) scheme [14].Compression is applied after signing the message digitally, so that sender A can store a detached signature of message M, DSKRA[M1], as an archive.
Stage IV: To assure the secrecy, or confidentiality, of message M, user A's e-mail software encrypts message M3, to produce message M4, as follows:
A: M4 = EKs[M3] || EKUB[KS] (4)
Where EKs indicates applying a symmetric black box Data Encryption Standard (DES) in encryption algorithm in the Cipher Block Chaining (CBC) mode, such as CAST-128, using a 128-bit secret session key, KS, which A generates using a PGP pseudo-random key-generator (PRKG).
Also, EKUB indicates RSA public-key encryption to the secret key KS, using user B's public key, KUB. The encrypted session key, EKUB[KS], is then attached to the encrypted e-mail message, EKs[M3], so that receiver B will be able to retrieve the secret key needed to decrypt the e–mail message later, as shown in figure (1).
