Secure E-Mail System Using S/Mime and Ib-Pkc

Although e-mail security solutions have been introduced for more than two decades, most of the e-mail messages are sent nowadays without being secured by any of these techniques. This is due to the complexity of using these secure e-mail systems and protocols. The complexity mainly arises from the difficulty associated with managing certificates and public keys. The main objective of this study was to find a solution that can make secure e-mail systems easier to use while maintaining the same level of security. This paper proposes a secure e-mail system that is based on the S/MIME standard where the public key and signature algorithms have been replaced by their Identity-Based Cryptography analogue algorithms. Using Identity-Based Cryptography has eliminated the need for digital certificates, and provided a solution to the usability problem present in the existing secure e-mail systems. Users can determine the public key of the recipient without having to contact any trusted third party, and can start encrypting or verifying messages as long as they have the public system parameters that can be publicly available. Users need to contact the Private Key Generator (PKG) only once in order to retrieve their private key before being able to decrypt or sign messages.


Introduction
E-mail is one of the most popular activities on the Internet.The ease of communicating over e-mail makes it the optimum communication medium for many people and businesses.In order for e-mail to be used in important communications, secure e-mail systems were developed.E-mail Security solutions such as PEM [1], PGP [2] and S/MIME [3] have been in place for more than a decade, and have been implemented by most e-mail clients.However, most e-mail messages are sent without being secured by any of the available solutions.This is mainly because of the complexity of using these secure e-mail systems and protocols.
In 1999, a study [4] was made to evaluate the PGP usability, and it proved scientifically that e-mail encryption is too hard.Twelve test participants were involved in that study, and were asked to create keys and to send digitally signed and encrypted messages.Only one third of them were able to use PGP to correctly sign and encrypt an email message.Furthermore, one quarter of them accidentally exposed the secret they were meant to protect in the process, by sending it in e-mail they thought they had encrypted but had not.But while the usability failings found in PGP 5.0 can certainly explain the failure of PGP 5.0 in the marketplace, these failings can't explain the similar failure of every other secure messaging system that implements public key cryptography [5].Such a failure can be explained by a common usability failure in the underlying certification model used by these systems [5].
The PGP key certification model is of a user-centric type that allows individuals to create their own public/private key pairs and then optionally have those public keys certified by one or more individuals, but this comes at the cost of added responsibility on the part of end-user.On the other hand, S/MIME was constructed with an eye toward integration with the Public Key Infrastructure (PKI).As such, S/MIME allows the use of certificates for both signing and encrypting e-mail, along with the integration with Certificate Revocation Lists (CRL) and cryptographically signed return receipts.Current PKI have several aspects that attracted criticism and controversy, some of which are: Difficulty in retrieving keys and certificates, certificate processing complexity, costly certificates, and naming semantics problem [6].Several solutions have been made in order to reduce this complexity; some of them were in the form of commercial security appliances that manages 648 the key processing for the users, while the others were academic solutions like "Safe Staging for Computer Security" [7] and "Enabling E-mail Confidentiality through the use of Opportunistic Encryption" [8].
In Identity-Based Public Key Cryptography (IB-PKC), the public keys are constructed from users' publicly available identities that are uniquely associated with them (like their e-mail addresses).The motivation for such a scheme was to simplify key management and eliminate the use of certificates.Since the introduction of the first successful Identity-Based Encryption (IBE) scheme, replacing the current PKI services with their equivalent IB-PKC techniques has become a very popular research area.This ranges from making some kind of combination between the PKI services and the IB-PKC algorithms to totally replacing some PKI services with their IB-PKC alternatives.Several studies have been made on the subject of securing e-mails with the IB-PKC principles.In 2002, a secure email system was developed that relied totally on IBE, where a Microsoft Outlook Add-in has been programmed.It allows the user to encrypt outgoing e-mail messages and decrypt incoming email messages [9].However, it doesn't provide signing services, and didn't use any existent secure e-mail standard.Another example of such research is the "Identity-Based Mediated RSA" [10] which is a simple variant of Mediated RSA that combines identity-based and mediated cryptography.In IB-Mediated RSA, users' RSA public key can be computed publicly from their e-mail address so that no individual certificate is needed.A Microsoft Outlook Add-in has been developed to demonstrate this method.This approach also does not make use of any existing secure e-mail standard.Also a "Lightweight Signatures for E-mail" was proposed in [11] which is a mechanism for Internet-wide distribution of identity-based public keys for the purpose of email authentication.Each e-mail domain becomes a master authority for an Identity-Based scheme of its choosing and generates a unique master key pair (MPK, MSK).Each MPK is distributed via the Domain Name System (DNS).It was later updated by Lightweight E-mail Signatures (LES) [12] which is an extension to DomainKeys Identified Mail (DKIM), a mechanism by which domains are made cryptographically responsible for the e-mail they send.While this solution works well for e-mail authentication, email encryption exhibits a different threat model that requires special treatment.
"Lightweight Encryption for E-mail" [13] was proposed to strengthen the security model by key splitting and distributed key generation.These latter approaches can be deployed with client or server updates.649 However, they were not concerned with specifying a standard secure e-mail message format as they were mainly describing methods for deploying an Identity-Based PKI.
In order for two e-mail users to communicate securely, it is necessary for them to use programs that are compatible with each other.Hence secure e-mail systems that utilize IB-PKC algorithms need to make use of existing e-mail security standards in order to be widely adopted and make secure messaging easier to use.In this paper, a secure e-mail system is proposed that is based on S/MIME standard where the public key and signature algorithms have been replaced by their IB-PKC analogue algorithms.We believe that our approach would result in a better usability of secure e-mail systems.The rest of this paper is organized as follows: Section 2 briefly introduces S/MIME and Identity-Based Cryptography.Some important design considerations are outlined in Section 3. The Specifications of messages used in the proposed system are described in Section 4, while the overall system architecture is presented in Section 5.Then, some notes on the implementation and performance are given in Section 6.Also, some possible extensions to existing system implementation are highlighted in Section 7. Finally, some important points are concluded in Section 8.

Preliminaries
This section briefly presents the basic building blocks of our approach to develop a better usability secure e-mail system.These are: S/MIME and IB-PKC.

Identity-Based Cryptography
The concept of Identity-Based Public Key Cryptography (IB-PKC) was first proposed by Shamir in 1984 [14], where it was shown that the authenticity problem in public key cryptography (PKC) can be solved without the use of certificates.What makes IB-PKC differs from the ordinary PKC is that the public key can be an ordinary string.For example, if Alice wants to encrypt a message to Bob at "bob@foo.com",then she simply encrypts the message using "bob@foo.com"as the public key.Thus, any user in the system can send encrypted e-mail messages to anyone, even if the recipient hasn't yet registered and created his/her own private key.Once a recipient receives the encrypted message, that recipient contacts the Private Key Generator (PKG) in order to request his/her private key that is needed for decryption, and it's the only time in which this user has to contact any Trusted Third Party (TTP) until he/she needs to update the private key later.
The primary advantage of IB-PKC is that a system participant can make a public key without having to contact any TTP.Moreover, it can be used for managing user credentials, delegation of decryption keys, or for implementing short lived public keys.It has also been used to build forward-secure encryption schemes.
While efficient solutions for Identity-Based Signature (IBS) schemes were quickly found, most IBE schemes proposed since 1984 were unsatisfactory because they were too computationally intensive, they required tamper resistant hardware, or they were not secure if users colluded.The first efficient and secure IBE scheme did not appear until 2001 when Boneh and Franklin [15] presented their IBE scheme.The Boneh-Franklin IBE scheme (BF-IBE) is based on bilinear maps between groups.The BF-IBE scheme has chosen ciphertext security in the random oracle model assuming a variant of the computational Diffie-Hellman problem.
Moreover, its performance is comparable to the performance of ElGamal encryption.
After that, several other identiy-based schemes were proposed based on the BF-IBE scheme.For example, the Cha-Cheon IBS scheme (CC-IBS) [16] shared the same system parameters with the BF-IBE scheme.Combining these two schemes yields a complete solution for of an Identity-Based Public Key system.In an IBE scheme there are four algorithms: • Setup: takes as input a security parameter and outputs params (system parameters) and the masterkey.The system parameters must include the description of the message space M and the ciphertext space C. The system parameters would be publicly known while the master-key is known only to the Private Key Generator (PKG).
• Extract: takes as input the system parameters (params), the master-key and an arbitrary string ID ∈ {0,1} *  The PKG also runs the algorithm Extract at the request of a user who wishes to obtain the private key corresponding to some string.The user should prove to the PKG that he/she is the legitimate owner of this string.The algorithms Encrypt, Decrypt, Sign, and Verify are run by the users to encrypt, decrypt, sign, and verify messages.

The Proposed System Design Considerations
The proposed secure e-mail system should securely transmit e-mail messages, be easy to use, make use of the existing secure e-mail standards, and it should be applied without making significant changes to the structure of the network.In order to achieve the previous goals, some decisions had to be made before designing have the system: • The first question to be answered is whether to apply security to both the e-mail client and server, or just one of them.Any change in the e-mail servers is not recommended, since this implies that all the e-mail servers around the world should be updated to implement the new changes.Hence, this design would apply security to email clients only, and this will allow any organization to apply this system without having to modify the underlying network architecture.
• The analysis of the current PKI [6] shows that different aspects of the PKI technology have attracted criticism, and shows that most of these aspects are related directly to the digital certificates' management complexity.On the other hand, IB-PKC provides a comparable security and an equivalent functionality, and does not need any digital certificates.Thus, IB-PKC represents an excellent replacement to the PKI technology, and it will be adopted in the design of this system.
• Distributing private keys to the users of the system is a main concern when designing any secure email system.There are three options to choose from: for any participant to start using the system is the public system parameters.These parameters can be stored in a file that would be publicly available.They are needed for using the Identity-Based Cryptography algorithms.These parameters are the result of combining BF-IBE scheme and CC-IBS scheme public system parameters (where the master key is s, and it is chosen randomly provided that s ∈ Z p *):

Secure Message Specifications
Since S/MIME is the basis for this system, the message format would follow the S/MIME message specifications [18] and the CMS standard [19] with slight modifications to some fields in order to add the functionality of the Identity-Based Cryptography.In this section, the modifications that have been applied to the CMS EnvelopedData and SignedData types are described.The CompressedData doesn't need to be modified.The Data content type also doesn't need to be modified since it only exists to contain the message content (like MIME body part) that is going to be processed by S/MIME.However, before continuing, it is important to notice that: • The CMS Version of the current S/MIME is 3.

EnvelopedData
The EnvelopedData content type consists of an encrypted content of any type and encrypted contentencryption key for a recipient.Fig. 1 shows the structure of the EnvelopedData content type after neglecting the optional fields.The EnvelopedData content type is composed of: • CMSVersion: it must be set to 5.

SignedData
The SignedData content type consists of a content of any type and one or more signature values.Fig. 2 shows the structure of the SignedData content type after neglecting the optional fields.The SignedData content type is composed of: • CMSVersion: it must be set to 5.

SYSTEM ARCHITECTURE
The proposed system is composed of three parts: the Secure E-mail Client, the Private Key Generator (PKG), and an E-mail Server as shown in Fig. 3.The e-mail server is represented in dotted lines since it is not affected by our system approach, and any existing e-mail server would work well when integrated with system.Thus, there is no need to re-design the e-mail server.

Secure E-mail Client
Secure E-mail clients are mainly used for viewing incoming e-mail messages, composing outgoing  generate the public system parameters, and the master key, and it does that only once.Then the PKG runs the extract algorithm for every request to generate the private key out of the public key (e-mail) supplied.The extraction process is carried out according to the protocol that is described in Subsection 5.3, where a request would be received from the e-mail client using a special e-mail message format.Then the PKG generates the private key, and sends it back to the e-mail client.
To accomplish these tasks, the modules needed by the PKG can be identified as follows: • Cryptography module should provide a set of functions that would be required to run the setup and extract algorithm according to the IBE Scheme, and to carry out the cryptographic operations needed by the secure message specification described in section 4. • Database module that should provide all the necessary data structures and the functions needed to interact with them.This can include an options' file structure, details of the rejected requests, a list of the public keys that has their private keys extracted, and a list of the allowed public keys (e-mail addresses) and domain names.
• Private Key extraction module should contain a set of function that would be required to check for any new request, check the e-mail address to see if it's in the allowed list, extract the private key, send it back to client that requested it, and record all the necessary information in the data structures.
• An easy-to-use graphical user interface (GUI) that would allow the user to easily configure the PKG and view the rejected requests, the executed request, and the application's log file.

Private Key Distribution Method
This subsection explains the method that the e-mail client can use to extract the private key associated with its public key (email address).It's an e-mail dependent method that is based on the E-mail Based Identification and Authentication (EBIA) method.EBIA uses an e-mail address as a universal identifier and the ability to receive e-mail at that address as a kind of authenticator [17].Mailing lists and forums subscription confirmations, Web password reminders, and e-commerce notifications all use this method.In our system, private keys, which are very sensitive data, are distributed using EBIA.This is why EBIA needs to be modified by the use of fine cryptographic principles in order to maintain its security.
This key distribution method is carried out between the Private Key management module in the e-mail client and the Private Key extraction module in the PKG as shown in Fig. 6.Before being able to extract its private key, the email client should obtain the public system parameters, a common information file that should be provided by the PKG.The user should also provide the e-mail address of the PKG.The steps needed to accomplish this task are (see Fig. 5):

POSSIBLE EXTENSIONS
In this section we describe possible extensions to our system.These extensions allow preparing encrypted messages with multiple recipients (Subsection 7.1) and signed messages with multiple signers (Subsection 7.2).The previous two extensions permits the use of public keys that are not confined to e-mail addresses like (e-mail address || current-date || clearance-level).Subsection 7.3 presents the approach for Identity-Based PKI described in [12,13], and shows how to integrate it with our system.

Multiple-Recipient Encrypted Message
Another field should be added to the "OtherRecipientInfo" field (see Subsection 4.1) to make it possible to send encrypted data to more than one recipient.This field would contain the recipient's public key, and can be called "RecipientPublicKey".The content is encrypted using a random session key as usual.For every recipient, a separate "RecipientInfo" field is prepared that contains the encrypted session key and the public key that was used to encrypt the session key.

Multiple-Signer Signed Message
The "SignerInfo" type (see Subsection 4.2) contains a field that identifies the public key of the signer.It's the "SignerIdentifier" field, and it provides two alternatives for specifying the signer's public key.They are the "issuerAndSerialNumber" and the "subjectKeyIdentifier".
The "issuerAndSerialNumber" identifies the signer's certificate by the issuer's distinguished name and the certificate serial number.The "subjectKeyIdentifier" identifies the signer's certificate by the X.509 subject Key Identifier extension value.Both of these choices identify the signer's certificate (and thereby the signer's public key).However, certificates are not used in our system, so another way should be found to identify the signer's public key.Thus, if more than one signer wants to sign the content, a third option should be added to the "SignerIdentifier" field.This option field can be called "SignerPublicKey" and contains the signer's public key.For every signer, a separate "SignerInfo" field is prepared that contains the signature value and the public key of the person that used his/her private key to generate this signature.The problem with this approach is that it violates the CMS standard since it's not permitted to have user-created alternative choices in the "SignerIdentifier" field.

Identity-Based PKI
Using a single PKG from which all users request their private keys may not be practical in some situations.Each institution may want to have its own PKG and manage its users' keys.Moreover, a PKG's secret key must not exist on a single machine since it can be used to decrypt all the messages of this PKG's users.The Lightweight PKI, described in [12] and [13], can be used to solve these problems.In this Identity-Based PKI, each domain has its own PKG that extracts private keys for its users.The Master Public Key (MPK) of a domain is distributed via the DNS, as a TXT record associated with the hostname of the domain's Mail Exchange (MX) record.
In fact, a domain should maintain several PKGs that independently generate master key shares (MPK i , MSK i ).The Master Public Key shares are combined into a single MPK that is distributed via the DNS.Each server with Master Secret Key MSK i individually sends Alice secret key share SK Alice,i .Alice then can combine all shares into a single private key SK Alice .EBIA is used to distribute these secret key shares [13].
The integration of our system with the Identity-Based PKI, described above, can be carried out without modifications to our system.However, it's better to apply the changes presented in Subsections 7.1 and 7.2 first in order to exploit all the capabilities of the Identity-Based PKI, like allowing a user to extract his private key from a domain different than his original domain.
In [12], EBIA is used to distribute secret key shares, while our system uses a modified version of EBIA (Subsection 5.3) to distribute private keys.Our modified EBIA is more secure and can be used in the distribution of the secret key shares.A user can send request e-mail messages to all the PKG servers of a single domain.Each one of these PKGs receives a different session key in the request message, generates a secret key share, encrypts it with the received session key, and sends it back the user.The user then decrypts these secret key shares using the stored session keys.After that he/she can combine these secret key shares to form his/her private key.Thus, all the secret key shares would never be sent without encryption.

Conclusions
Our system provides a solution to the usability problem present in the existing e-mail security solutions.Anyone can start using the system after getting a copy of the common system parameters that can be publicly provided.When a user wants to get his/her private key, the only thing needed is the e-mail address of the PKG.The system is compatible with the S/MIME protocol.In fact, it's based on S/MIME to benefit from the structure of S/MIME that has gone through extensive testing and improvement for several years now.This also decreases the time and effort needed to add this system's functionality in the existing e-mail applications that implement S/MIME.The changes made by this system need to be applied on the e-mail clients only, while the e-mail servers stay intact.These changes to the e-mail clients don't need to be integrated into them.They can be provided in the form of Add-Ins to these applications.
In addition, as a future work, the PKG in our system can be enhanced further.The enhancement my include finding a method that enables users who have different PKGs to use the system while maintaining the same level of security and usability.This has been partially covered in Subsection 7.3.