Most of the existent certified electronic mail proposals (found in scientific papers) have been designed without considering their deployment into traditional e-mail infrastructure (e.g., Internet mail system). In fact, there is not any implementation used for commercial purposes of those proposals. On the other hand, in different countries, private companies and public administrations have developed their own applications for certified electronic mail, but these solutions are tailored to their needs and present serious drawbacks. They consider the mail providers as Trusted Third Parties (TTPs), but without being verifiable (if they cheat or fail, users cannot prove it). In most cases, users (typically recipients) cannot choose their mail provider; it is imposed, and even worse, sometimes a message is considered to have been delivered when it has been deposited in the recipient’s mailbox (and perhaps, he will not be able to access it). In this chapter, the authors give a broad picture on the current state of certified e-mail, including a brief description of the current e-mail architecture and the need of certified e-mail services, and a definition of the security requirements needed for such a service. Next, they review the scientific and existent proposals. Finally, the authors give some guidelines for developing practical solutions for certified e-mail services that meet all the security requirements.
TopIntroduction
More than 200 billion e-mails are sent each day. Without doubt, e-mail is a core service of Internet. In the early days of Internet e-mail, only text messages (ASCII-7 bits) could be sent among users. That was a serious restriction and drawback. Users wanted to send video, audio, enriched text, files, etc., inserted or attached to e-mails. For this reason, Internet e-mail was enhanced in 1992 with MIME (Multipurpose Internet Mail Extensions). A second problem to be solved was the lack of security, and in 1998 S/MIME (Secure/MIME) was proposed to provide confidentiality, integrity, authentication, and proof of e-mail origin (a sender cannot deny having sent a message).
But in the paper world, people are accustomed to sending valuable documents in a secure and reliable way. This includes documents like deeds, contracts, bids, subpoenas, summons, notifications, etc. Regular mail has no security provisions and senders rely on the assumption of a correct and successful delivery. This is where registered mail and certified mail come into play. Registered mail is a useful vehicle in the postal world for secure mail delivery by providing extended tracking possibilities. The certified mail service provides the sender additional proofs of submission, delivery and reception. In the same way, it is necessary to provide a similar service in the electronic world.
Probably for that reason, Internet e-mail was enhanced providing to users some kind of receipt (MDNs, Message Disposition Notification, and DSNs, Delivery Status Notifications). These are useful services but with a poor evidential quality: users can decide not to send these receipts (or once sent, they can deny having done it).
Due to the previous gap, the research community has provided many protocols for secure messaging over the last two decades. They have been published as fair non-repudiation protocols or certified electronic mail protocols. The aim was to design security extensions for asynchronous communications providing similar added value as traditional certified mail does in the postal world. The term Certified Electronic Mail (CEM) is used when applying fair non-repudiation protocols in the context of electronic mailing systems, for example Internet e-mail. In a nutshell, the certified e-mail service is to ensure that if a recipient receives an e-mail (usually with a proof of origin), the sender receives an acknowledgment (not rejectable by the recipient).
Fair exchange basically means that each party gets its expected items (in certified e-mail, a message for a proof of receipt), or none party is in an advantageous situation. But how is this fair exchange ensured? In traditional postal systems, the postal service acts as Trusted Third Party (TTP) and ensures the fair exchange of a delivery for a signed receipt.
First approaches for certified e-mail proposed protocols without TTP. However, these protocols were not practical. Either they required a high amount of communicational and computational power or they ensured fairness only with a certain probability. These conditions are not desired in practice. Moreover, some protocols assumed equal computational power of participants, which is unrealistic, e.g., a single user vs. a large corporation. Protocols with TTP differ in the extent of the TTP's involvement: inline TTP, online TTP and offline TTP. Inline TTPs act as a proxy between sender and recipient, being involved in every protocol step. Meanwhile, online TTPs are involved in each protocol run, but not in every step. Finally, in the optimistic approaches the TTP is only involved if a dispute arises, which is expected to be an exceptional case (see Figure 1). First practical certified e-mail approaches used inline TTPs. However, these kinds of protocols require the users to put a great amount of trust in the TTP. Moreover, since the TTP participates in each protocol step, it supposes a great workload for the TTP and it may become a bottleneck. The research community worked towards better approaches by increasing efficiency and reducing the amount of trust in TTPs proposing online TTP protocols. Newer approaches make use of offline TTPs, which are only involved if a dispute arises. Therefore, they are called optimistic. Some additional properties, apart from fairness, have to be met (timeliness, verifiability of the TTP, non-repudiation, etc.), in order the solutions to be useful.
Figure 1. Trusted third parties configurations