A Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain

Received April 15, 2020, accepted May 19, 2020, date of publication May 29, 2020, date of current version June 11, 2020. Digital Object Identifier 10.1109/ACCESS.2020.2998679 A Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain M. FRANCISCA HINAREJOS AND JOSEP-LLUIS FERRER-GOMILA , (Member, IEEE) Department of Computer Science, University of the Balearic Islands (UIB), 07122 Palma, Spain Corresponding author: M. Francisca Hinarejos ([email protected]) This work was supported in part by the European Social Fund through European Regional Development Fund (ERDF), and in part by the Spanish Government through the Ministerio de Economia, Industria y Competitividad (MINECO)-Agencia Estatal de Investigación (AEI)) Projects under Grant RTI2018-097763-B-I00 and Grant RED2018-102321-T. ABSTRACT In this article, we present the first solution for multi-party certified email that achieves fairness and confidentiality without the intervention of a TTP but with blockchain support when problems arise. Our solution preserves the confidentiality of the mail exchanged between the sender and the recipients even when the blockchain is involved. We provide a proof of concept implementation based on Ethereum smart contracts that shows it is feasible from a practical point of view. Because the functions of a smart contract are only executed on the blockchain in the case of conflict, costs are minimised compared to solutions that execute the functions on the blockchain in all cases (on-chain solutions). Moreover, the solution can be integrated into the existing email infrastructure. INDEX TERMS Blockchain, certified delivery, certified email, email security, fair exchange, nonrepudiation, electronic notifications. I. INTRODUCTION Certified mail is a value-added service provided by courier companies. The sender of the mail wishes to obtain proof that the recipient has received the message. Obviously, the recipient will only provide that proof (the acknowledgement of receipt) if he actually receives the mail. The security problem that underlies this service is the fairness of the exchange: neither the sender nor the recipient gets what she/he wants if the other party does not receive the expected item (acknowledgement of receipt and the mail, respectively). In the paper world, the problem is solved with the intervention of a trusted third party (TTP), the postal agent, and a face-to-face exchange between the agent and the recipient. This face-to-face exchange is not possible in the electronic world, but the intervention of a TTP is. In fact, the vast majority of solutions found in the literature base the security of the system on the existence, and possible intervention, of a TTP. However, this is not without problems, the main one being that the parties agree on a TTP that they both trust or, from a technical point of view, that the behaviour of the TTP is verifiable (that its bad behaviour can be demonstrated, if applicable). The associate editor coordinating the review of this manuscript and approving it for publication was Aniello Castiglione . Sometimes the sender wants to send the same certified mail to multiple (N) recipients. One solution would be to execute a protocol designed for a single recipient Ntimes. However, a solution specifically designed for multi-party certified mail could be more efficient. In recent years, new solutions have been proposed to classic security problems that require the intervention of a TTP based on the use of the blockchain. Some of these have completely eliminated the use of TTPs, and others have reduced their role. In the literature, we have found a solution [1] for multi-party certified mail based on the blockchain, and the authors show that a specific solution is more efficient than Nexecutions of a solution for a single recipient. In fact, the authors of [1] propose two solutions for multi-party certified mail. In one of these, the exchange does not require TTPs, but the confidentiality property is not achieved. The authors state that the confidentiality requirement is satisfied in the other proposal, but the existence and possible involvement of a TTP is necessary. However, we show that the confidentiality requirement is not truly met. Contributions: In this article, we propose the first scheme for multi-party certified email that, thanks to the use of the blockchain (and specifically thanks to Ethereum smart contracts), does not require the intervention of TTPs to meet VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ 102997 M. F. Hinarejos, J.-L. Ferrer-Gomila: Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain the fairness and confidentiality requirements. The proposal only requires the execution of blockchain functions in the case of conflict, and we demonstrate that if the execution of the functions is necessary, the cost is very reasonable. Finally, we want to highlight that we have designed our proposal considering easy integration into the standardised infrastructure of Internet email. Organisation: This paper is organised as follows. In section II, we define the security requirements for certified email. The related approaches found in the literature are analysed in section III. Section IV sketches our multi-party certified email protocol and specifies the assumptions under which the protocol is defined. Section Vis devoted to fully describing the new protocol for multi-party certified email, and it is followed by a definition of the smart contract execution logic in section VI and the security analysis in section VII. In section VIII, the usage cost of the proposed solution is analysed. Finally, the conclusions are presented in section IX. II. SECURITY REQUIREMENTS The security requirements that we contemplate in this article are fairness, timeliness, confidentiality, nonrepudiation of origin, and nonrepudiation of receipt. Obviously, the properties considered by many authors related to the TTP (effectiveness, TTP verifiability) do not apply in our case. However, we present a new property that we call bc-effectiveness (blockchain-effectiveness). We will start with the property that we consider to be the most important: fairness. The sender wishes each of the Nrecipients to only gain access to the content of the message if she (the sender) obtains the acknowledgement of receipt (by that recipient). A certified mail recipient wants the sender to only obtain the acknowledgement of receipt if he (the recipient) has access to the content of the message. If the execution of the protocol allows both parties to have what they want or neither of them to obtain the item desired from the other party, we will say that the protocol satisfies the requirement of (strong) fairness. In many proposals, a situation may arise in which one of the parties provides her/his item and does not receive the item expected in return, but they can demonstrate this breach and therefore demonstrate that the exchange has not occurred. In this case, we will say that the protocol satisfies the weak fairness requirement. This is related to the transferability of evidence. When the protocol satisfies the requirement of weak fairness (but not strong fairness), a third party (C) cannot decide whether the exchange has taken place in view of the evidence brought by only one of the parties. As we have said, it could happen that Ahas the element of B, but that B can prove that Adid not deliver its item in return. In this case, Ccannot affirm that Breceived his element based only on the information provided by A. We will say that the evidence is non-transferable: the intervention of Aand Bis necessary to affirm whether the exchange successfully occurred or not. The next property is timeliness. During the execution of the protocol, one of the parties may stop, deliberately or not, the execution. This could leave the other party in a situation where she/he does not know how (success or failure) or when the execution will end. Moreover, it could be the case that one of the parties already had his element and that the other party could not know whether he will receive his element in the future or not. Therefore, it is necessary that the protocols allow the parties to know that the execution of the protocol will end within a finite time period that has been decided/agreed upon by both parties, that is, that it satisfies the property of (weak) timeliness. Some authors provide a stricter definition of the previous property, which they call strong timeliness. Under strong timeliness, the authors state that the participants can require at any time the completion of the execution of the protocol and that at this moment, they can know the final state of the exchange. Without denying its usefulness, the weak timeliness requirement seems more than sufficient: if at the beginning of the exchange, one or more parties do not agree with the established deadline, they may refuse to participate. The message may contain information that should only be known by the sender and, where appropriate, by those recipients who agree to participate in the exchange. Therefore, the protocol must ensure that the different parties, the sender and the ‘‘effective’’ recipients, cannot obtain access to the message content due to bad protocol design (if one of the parties discloses the content to third parties, it is not a problem caused by the protocol). In other words, the protocol must be able to satisfy the confidentiality requirement. If the exchange is completed successfully for one or more recipients, the sender should not be able to deny having sent the message to those recipients afterwards, and the recipients should not be able to deny receiving the message. That is, the protocol must satisfy the properties of nonrepudiation of origin and nonrepudiation of receipt for successful exchanges. If the fairness and nonrepudiation of origin requirements are met, then the nonrepudiation of receipt requirement is met. Among the solutions with a TTP, there is a subset that is classified as including an offline TTP (or optimistic), since the TTP only intervenes in cases of conflict. This property is often called effectiveness: if the parties are honest and execute the protocol as intended, the TTP does not intervene in the execution. Our proposal does not require the existence of a TTP, and therefore, the effectiveness requirement does not make sense as defined. However, in our protocol, we do have the existence and possible intervention of Ethereum blockchain nodes. The intervention of these nodes will only be necessary in the event that the parties (sender and/or recipients) do not follow all the steps of the exchange subprotocol, which we will define later. By analogy to the case of protocols for off-line TTP, we call this new property bc-effectiveness. 102998 VOLUME 8, 2020 M. F. Hinarejos, J.-L. Ferrer-Gomila: Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain III. RELATED WORK The majority of solutions for multi-party certified electronic mail that we find in the bibliography [2]–[8] need the existence and possible intervention of a TTP to achieve compliance with the fairness requirement. On the one hand, the TTP can become a bottleneck. This problem can be relatively easily solved by properly sizing the TTP infrastructure. The second problem is that it can be very difficult for the N+1 parties to agree on a TTP that is trusted by all. This is aggravated in these solutions because in the face of dishonest TTP behaviour, the parties cannot demonstrate to other entities (for example, a judge) that the TTP misbehaved. From what we have explained above, we were interested in another way of achieving fairness without the participation of a TTP. In other areas (payment for a receipt, contract signing, certified electronic mail with only one recipient)that have also traditionally required TTPs, we find bibliographic references that used the blockchain to achieve fairness (without a TTP or with a reduced role for the TTP in the protocol). The blockchain, especially Bitcoin and derived cryptocurrencies, emerges (or more precisely, re-emerges) as a different way to solve the security problem of double spending electronic money. However, as we have already noted, other researchers have proposed alternative uses, taking advantage of the fact that the infrastructure created provides a public and ‘‘unalterable’’ registry. In addition, the public and ‘‘unalterable’’ registry has been complemented by proposals using smart contracts bound to the blockchain. In this way, we find in the literature some proposed blockchain approaches for the electronic signature of contracts (for example, [9]–[12]), payment by receipt (or product) (for example, [13]–[15]), proof of delivery (for example, [16], [17]), or certified electronic mail (for example, [18]). The solution presented in [18] could be used for multi-party certified email by performing Nexecutions of the protocol (one for each recipient). As we indicate in the introduction, other authors demonstrate that a specific solution designed for a multi-party environment can be more efficient. Furthermore, the solution in [18] can be classified as an on-chain solution, that is, the protocol requires the intervention of the blockchain in each execution, with the resulting economic cost (and possible delay). Moreover, in the terminology we have introduced in this article, the bc-effectiveness requirement is not met. In the case of multi-party certified electronic mail, we only find in the bibliography one reference [1] that provides two solutions using the blockchain. After the analysis of these two solutions, we find critical aspects that will be presented below. One of the two solutions presented by Payeras-Capellà et al. [1] does not require the use of TTPs but also does not achieve compliance with the confidentiality requirement (by design, not by mistake). That is, the message is ‘‘public’’, it can be read by any user, even if that user is not the sender or one of the intended recipients. The authors of [1] affirm that the other solution manages to meet the confidentiality requirement, but it requires the presence of a TTP in the protocol design. Analysing the protocol in detail, we observe that in the protocol described in the article, the confidentiality of the exchange is not guaranteed. This last protocol, described in [1], consists of 3 subprotocols: exchange, cancel and finish. In the exchange subprotocol, the sender sends the message encrypted with a symmetric cryptography key that only he knows, C=EK(M), and the key Kencrypted with the TTP public key (PUT), KT= PUT(K). In the third step, the sender sends the key K, encrypted with his private key (PRA), KA=PRA(K), to the recipients who have accepted receipt of the mail. Any attacker who intercepts the information in steps 1 and 3 will have access to the message content. The public key of Acan be known, and therefore anyone can perform the operation PUA(KA)=K. From this point on, the cryptogram intercepted in the first step can be deciphered, DK(C)=M, and therefore the message can be read. The previous defect would be easily remedied if the communications with each possible recipient were encrypted; for example, the key Kcould be encrypted with the recipient’s public key, PUBi(PRA(K)) (these operations must be performed in the proper order). In this way, only a recipient who knows the corresponding private key could retrieve the key K and thereby read the message. However, we have indicated that in the first step, the value KTis sent, and therefore, if the TTP has access to the information in the first step (gaining access while it is in transit or because it is provided by a recipient), the TTP will be able to recover the key, PRT(KT)=K, and therefore able to read the content of the message. In conclusion, we do not find solutions for multi-party certified electronic mail that meet the fairness and confidentiality requirements without involving a TTP. IV. PROPOSAL SKETCH AND ASSUMPTIONS In this section, we provide an overview of our multi-party certified email protocol to provide fairness and confidentiality between the sender and the recipients without the involvement of a TTP. The solution can be integrated into the existing email infrastructure, and the involvement of the blockchain is only required when problems during the message exchange arise. The solution requires the following participants: •Sender (A) is the sender of a confidential certified message addressed to a set of recipients. •Recipients (B) are the set of recipients of the confidential message sent by the sender. They must accept receipt of the message in order for the sender to provide them with the decryption key for the message. •Smart Contract (SC) is the software entity executed on the blockchain and used as a public registry for evidence and items (e.g., the decryption key) required to provide fairness when there are problems during the message exchange. The multi-party certified electronic mail protocol consists of three subprotocols (see Figure 1): exchange,finish and cancel. The exchange subprotocol consists of four steps, and VOLUME 8, 2020 102999 M. F. Hinarejos, J.-L. Ferrer-Gomila: Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain FIGURE 1. A sketch of the multi-party certified email proposal. it is the main part of the protocol. In the first step, the sender sends the message to the recipients, encrypted with a key that only she knows, along with evidence of nonrepudiation of origin proving that she has sent this message. In the second step, recipients wishing to receive the message must send the sender the first proof of nonrepudiation of receipt. The sender, in a third step, must provide the decryption key along with the second evidence of nonrepudiation of origin to those recipients who completed the second step. The decryption key is encrypted with the specific public key of each of the recipients who should receive the message. Thus, only the corresponding receiver can access the message. In the final step, these recipients must send the second evidence of nonrepudiation of receipt to the sender. Once the exchange subprotocol is completed, the sender has the acknowledgement of receipt from each participating recipient (the two pieces of evidence received from each recipient), and each participating recipient has the message and evidence of nonrepudiation of origin (the two pieces of evidence received from the sender). If the key provided by the sender to each recipient does not allow decryption of the message or the message does not make sense, the recipients can prove it with the evidence they are holding (provided by the sender). Note that if all four steps of this subprotocol are executed correctly, it is not necessary to execute any function of the SC, and the involvement of the blockchain is not required. If the sender does not receive the second evidence of the nonrepudiation of receipt from one or more recipients during the last step of the exchange subprotocol, then she must execute the finish subprotocol. This must be executed before the deadline set in the exchange subprotocol expires. She must invoke the finish function of the SC, providing the second part of the nonrepudiation of origin evidence and the encrypted key for any recipient who accepted the receipt of the message in the second step but did not provide the second evidence of the nonrepudiation of receipt. In this way, the SC records and makes available the key and the sender’s nonrepudiation of origin of the sender to recipients. This information can be used as evidence by the sender in case of dispute. Finally, if a recipient does not receive the decryption key after sending his acceptance of message receipt, he can execute the cancel subprotocol. This execution must be performed after the deadline expires (specified in the exchange subprotocol). The recipient must invoke the cancel function of the SC, providing all the evidence he has from the TABLE 1. Confidential multi-party certified email protocol parameters. exchange. With this information, the SC checks if it has data related to this message exchange (updated by the sender during the finish subprotocol). If no data exist, the SC stores this new data related to this particular recipient and message exchange. If data already exist for this recipient, he can recover the decryption key and the proof of nonrepudiation of origin from the sender as held by the SC. All the generated proofs are signed by the sender or the corresponding recipient; therefore, they need a valid key pair (public-private), and the public key must be trusted by the other parties. Since the protocol could require the use of a blockchain, some participants may need to invoke a function of the SC, requiring a public blockchain address. We also assume that the sender and the recipients use a resilient channel; that is, messages can be delayed, but they will arrive in a finite amount of time. As we have previously noted, to solve possible temporary problems, a deadline is established to ensure compliance with the timeliness requirement. V. SPECIFICATION OF THE PROPOSED MULTI-PARTY CERTIFIED EMAIL PROTOCOL In this section, we will explain in detail the steps and the content of each of the messages of the three subprotocols 103000 VOLUME 8, 2020 M. F. Hinarejos, J.-L. Ferrer-Gomila: Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain sketched in the previous section. Table 1shows the notations used along with the protocol description. A. EXCHANGE SUBPROTOCOL As explained above, the exchange subprotocol requires four steps that, if completed successfully, does not require the use of the blockchain (see Figure 2). FIGURE 2. 4-step exchange subprotocol between the sender and the recipients. Step I: In the first step, the sender, Alice, encrypts the message Mwith a secret key kthat only she knows, obtaining the cryptogram c(c=Ek(M)). Additionally, Alice establishes a deadline, t, which will only take effect in the event that the use of the blockchain is required. The purpose of this deadline is to guarantee the timeliness of the protocol. Finally, Alice signs the cryptogram, the deadline and the blockchain address of SC, and sends these data and the signature to the set of recipients (B). This signature is the first part of the NRO,nro1. Step II: Recipients who do not want to receive this certified message should simply ignore the message Alice has sent them. Recipients who want to receive it must send the first part of NRRbi,nrr1 bi, which consists of their signature on the data sent by A. The set of recipients that have provided nrr1 bi constitutes the set B0. Step III: Alice sends a message to the set of recipients B0 containing the key kencrypted with the public key of the corresponding member of B0(PUbi(k) for each bi∈B0) and the signature on each encrypted key. This signature ensures that Alice cannot deny having sent a specific key to each of the recipients and constitutes the second part of the NRO for each recipient, nro2bi. Step IV: At this point, each recipient of the set B0has the message Mand Alice’s nonrepudiation of origin evidence, NRO. Thus, they must send the signature on the information received from Alice in step III. This signature constitutes the second part of the evidence of nonrepudiation of receipt, nrr2 bi. With this evidence, they acknowledge that they have received the key kcontained in PUbi(k). Finally, Alice has the nonrepudiation of receipt evidence, NRRbi, for each recipient of set B0. B. FINISH SUBPROTOCOL If Alice does not receive the second part of the nonrepudiation of receipt evidence, nrr2 bi(Step IV), from one or more of the recipients of the set B0, she must invoke the finish function of the SC (see Figure 3). We call B00 the set of recipients who have not completed Step IV of the exchange subprotocol. The arguments of the finish function are the exchange identifier, idE, and three arrays with the following content: 1) the list of recipients that belong to B00 2) the secret key encrypted with the public keys of the recipients in B00 3) the first part of the NRRbireceived from each bi∈B00, that is, the evidence that each biwants to receive the message. The finish function verifies that the sender is the same entity that started the smart contract and that the deadline thas not expired. If the deadline has expired, the execution of the function ends. If the deadline has not expired, the SC updates the information so that it is available to those recipients and sets the status of the exchange to finished for each of those recipients. The sender must decide when to invoke the finish function. She should not take the risk of the deadline expiring, as she could be left without evidence. However, if she invokes the function too early, she may receive the recipients’ acknowledgments before the deadline expires, and they will be incurring unnecessary costs. C. CANCEL SUBPROTOCOL A recipient who has acknowledged he wants to receive the certified mail (he has sent nrr1 biin Step II) and has not received the decryption key (kin Step III) must invoke the cancel function of SC (see Figure 4). The reason is that Alice may have completed the exchange with this recipient through the finish function explained in Section V-B. The recipient must provide the exchange identifier, idE, the encrypted message, Ek(M), the deadline, t, and the first part of the NRO sent by A, (nro1), as arguments to the cancel function. If the deadline has not expired, the recipient must wait; otherwise, SC checks if there are data associated with this exchange (updated by the sender during the finish subprotocol). If no data exist associated with this exchange identifier, the SC stores this new data related to this particular recipient and message exchange. If data already exist for this recipient, he can recover the decryption key, PUbi(k), obtained from the blockchain. VI. SPECIFICATION OF THE SMART CONTRACT EXECUTION LOGIC We select Ethereum as the blockchain solution to deploy our multi-party certified email protocol defined in Sections IV and Vbecause Ethereum was designed as a platform to VOLUME 8, 2020 103001 M. F. Hinarejos, J.-L. Ferrer-Gomila: Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain FIGURE 3. A sketch of the finish subprotocol. Use of the blockchain by Alice. FIGURE 4. A sketch of the cancel subprotocol. Use of the blockchain by recipients. deploy smart contracts that run on the blockchain to facilitate, execute and enforce the terms of an agreement among parties [19], and is the second largest cryptocurrency by market share according to CoinMarketCap.1 Our proposal only requires the execution of the smart contract functions when problems arise during the exchange subprotocol. For these cases, a smart contract consisting of two main functions is provided: •finish function: for a given exchange identifier, the sender can call this function before thas expired to provide the required evidence for those receivers in B00 for whom the sender received email reception evidence (nrr1 bi) but not nrr2 bi. •cancel function: for a given exchange identifier, those receivers who have sent (nrr1 bi) can call this function to cancel the exchange after thas expired or to obtain both the evidence (nro2 bi) and the key to decrypting the message. To manage the data associated with each exchange, a data structure indexed by the exchange identifier (idM) is defined. This structure stores the evidence provided by the sender 1CoinMarketCap: Cryptocurrency Market Capitalizations. Data publication date: 2019/12/25. Source: https://coinmarketcap.com/ and/or each recipient, establishing the status of the exchange for each recipient. The finish function (see Listing 1) can only be executed by the sender of the email (Alice) before the timer expires (deadline specified in Step 1 of the exchange subprotocol). As input parameters to the smart contract, Alice provides the deadline, the list of recipients and, for each recipient bi∈B00, the key encrypted with the corresponding recipient’s public key (PUbi(k)). In addition, Alice also provides the email reception evidence received from each bi∈ B00. The smart contract checks both that Alice is the legitimate sender and that the deadline has not expired. If these are confirmed, the data structure for each recipient is updated (nrr1 bi,PUbi(k)). It should be noted that no confidential data are stored in the contract data structure, that is, the encryption key (k) can only be recovered by the corresponding recipient. The cancel function (see Listing 2) can be executed by any recipient who wants to know the final status of their exchange after the timer expires (deadline specified in Step 1 of the exchange subprotocol). As input parameters to the smart contract, a recipient provides the email data (exchange identifier, the deadline and the encrypted message) along with the received encrypted email evidence from Alice (nro1). The smart contract checks if the deadline has expired, the email data matches the message identifier, and the exchange was not 103002 VOLUME 8, 2020 M. F. Hinarejos, J.-L. Ferrer-Gomila: Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain Listing 1. Finish function of the smart contract. Listing 2. Cancel function of the smart contract. finished by Alice. If these are confirmed, the data structure for this recipient is updated (nro1). If the exchange was finished by Alice, the recipient can obtain the encryption key (PUbi(k)) provided previously by Alice (using the finish function). VII. SECURITY ANALYSIS In this section, we will demonstrate compliance with the requirements explained in Section II. We will start with the bc-effectiveness requirement. If the sender and the recipients (who wish to receive the certified mail) follow the four steps of the exchange subprotocol, at the end of the exchange, the recipients have the message M(together with the evidence of nonrepudiation of origin), the sender has the acknowledgement of receipt for these recipients, and the cancel or finish functions of the smart contract have not been executed. Therefore, our protocol satisfies the bc-effectiveness requirement. To demonstrate that the fairness requirement is met, we will analyse the possible situations that the sender may face if she is honest and that any recipient may face if he is honest: •When the sender has executed the first step of the exchange subprotocol, the recipients do not have access to the content of the message, and the sender does not have the nonrepudiation of receipt and cannot obtain it using the blockchain. •When the recipients have executed the second step of the exchange subprotocol, the sender can use the blockchain to execute the finish function (before the deadline), providing the key for each recipient who sent email receipt evidence and establishing the state of the exchange as finished. The recipients can call the cancel function (after the deadline) to obtain the key. If the recipient cannot obtain the key from the blockchain, this is reflected in the state of the exchange. •When the sender executes the third step of the exchange subprotocol, the recipients in set B0can already read the message, and if some recipients (set B00) do not send the key reception evidence, the sender can use the blockchain to execute the finish function (before the deadline), providing the key for each recipient in set B0 and establishing the state of the exchange as finished. The recipients in set B0can call the cancel function (after the deadline) to obtain the key (if the sender executed the finish function), or the blockchain will reflect that the recipient indicated he did not receive the key before the deadline. •If the recipients execute the fourth step of the exchange subprotocol, both parties have what they expected from the other party: the message (and evidence of nonrepudiation of origin) by acknowledgement of receipt (evidence of nonrepudiation of receipt). Therefore, at the end of the execution of the protocol, we can guarantee that all the parties can have the element they expected or neither entity will receive the expected item: the weak fairness requirement is fulfilled. If all parties are honest, the execution of the protocol ends after the fourth step of the exchange subprotocol. However, in any case, all parties have the guarantee that at instant t(the deadline set in the first step), the exchange will have reached a final state because before this moment, given conflict, the sender must have executed the finish function. Regarding the recipients who are in a situation of conflict, they know that they can execute the cancel function when they want at or following moment tto obtain the encryption key or to register VOLUME 8, 2020 103003 M. F. Hinarejos, J.-L. Ferrer-Gomila: Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain on the blockchain that they have not received the key. In short, the protocol satisfies the timeliness requirement because it allows the parties to know that the execution of the protocol ends in a finite time. The message Mis always transmitted encrypted with a secret key k. Only entities that know this key kcan read the message M. The key kis sent to each recipient encrypted with the recipient’s public key. Therefore, each recipient, and only that recipient, can use his private key to decrypt the corresponding encryption. In short, only the sender and the recipients who receive their PUBi(k) will have access to the message M. Neither attackers nor blockchain nodes will be able to access the content of the message (unless one of the entities above provides it outside of the protocol). In conclusion, the protocol meets the confidentiality requirement. Once the exchange is positively completed (with or without the execution of the blockchain functions), all parties have evidence of nonrepudiation. The sender has, for each honest recipient that completes the exchange, evidence of nonrepudiation of receipt that the recipient wanted to receive the certified mail and evidence that he received the decryption key. In the case of not receiving the second evidence from any recipient, the sender will have the evidence available through the blockchain after executing the finish function. This evidence shows that the recipient, who wanted to receive certified mail, can obtain the key in the blockchain. Therefore, the protocol satisfies the nonrepudiation of receipt requirement. In turn, the recipient can receive the evidence of nonrepudiation of origin directly from the sender (that from the first step and that from the third step) or can receive that from the first step and, if applicable (the sender has completed the exchange for him), that stored in the blockchain. Through one way or the other, the recipient receives the evidence of nonrepudiation of origin if he receives the message, so the protocol meets the nonrepudiation of origin requirement. VIII. COST EVALUATION OF OUR PROPOSAL As with other blockchain solutions, in Ethereum, the nodes validate blocks (composed of transactions) in exchange for rewards. In this case, the cryptocurrency unit is the ether. However, ether is traded on public exchanges, and its price fluctuates daily. To minimise this issue, Ethereum uses an internal currency known as gas that allows us to assess the cost of any transaction or smart contract execution. To evaluate the cost of our solution, we have developed a proof of concept (POC) that demonstrates the viability of implementing and deploying the proposed protocol. As transactions imply a cost, we tested our smart contract using Ganache [20], which allows us to create a private Ethereum blockchain to perform all the actions that the real Ethereum network allows but without a real cost. In addition, we need a development framework to easily deploy and test our smart contract. For this purpose, we use Truffle [20], which allows us to be configured to execute our contract on the created blockchain with Ganache. Figure 5shows the cost (measured in gas units) of the two main functions of our solution (finish and cancel) and the cost to deploy the contract. As we can see, and as expected, the cost to deploy the contract in the blockchain network is high compared to the other functions. However, the contract is deployed only once and used multiple times for different exchanges. In addition, considering the cost in US dollars (see Table 2), it would not exceed $2.41 in the case requiring a hasty deployment of the contract (considering a gas price of 8 Gwei2in approximately 17 seconds3), something that can be avoided. If the slowest case is considered (a gas price of 1 Gwei), it takes approximately two hours to deploy the contract with a cost of $0.30. This is a very low cost that could be assumed by any entity. FIGURE 5. Gas cost of our multi-party certified email proposal considering different recipients. If the sender needs to finish the exchange with one or more recipients, she must execute the finish function, which entails a different cost depending on the number of recipients. As shown in Table 2, to execute the finish function for one recipient, the sender should pay between $0.029 and $0.234, and for ten recipients, the cost is between $0.156 and $1.25. The cancel function is called by a recipient providing his data, so the execution cost does not depend on the number of recipients (same gas required by each recipient, Figure 5). Thus, considering a gas price of 8 Gwei, a recipient needing to call this function should pay $0.234 (fastest), and only $0.029 for a gas price of 1 Gwei. A. COST OVER TIME To assess the cost viability of the solution, we consider the past year. For this purpose, we use the dataset provided by [21], which includes the average value of the gas price paid each day, measured in Wei. Using the exchange rate between Ether and US dollars (per day), we evaluate the cost for each executed function. 2Wei refers to the smallest denomination of ether (ETH), the currency used on the Ethereum network (1 ether =1018 Wei) 3Considering the gas price required to publish a transaction. Data published on 06 February 2020. Source: https://ethgasstation.info 103004 VOLUME 8, 2020 M. F. Hinarejos, J.-L. Ferrer-Gomila: Solution for Secure Multi-Party Certified Electronic Mail Using Blockchain TABLE 2. Estimated cost (in US dollars) of our confidential multi-party certified mail using the Ethereum platform. Data publication date 02/06/2020. FIGURE 6. Estimated average cost of our protocol (in USD) over the last year. FIGURE 7. Estimated average cost of our protocol (in USD) over the last year removing the two peak days (02/19/2019 and 03/18/2019) from the dataset. Figure 6depicts the average cost that the sender or a recipient would have paid per day during the last year if the blockchain was required. Analysing the figure, we detect two clear peaks (two days: 02/19/2019 and 03/18/2019), which are basically due to congestion events and, in turn, to an impressive increase in the gas price required.4Excluding these two days, the gas price can be considered quite stable within reasonable limits (see Figure 7and Table 4). For example, the maximum cost to execute the cancel function during the last year was $0.92, considering a very high gas price (approximately 40 Gwei). Remember that to reduce the gas price, a transaction can be delayed, and in turn, the cost of any of the function in our proposal can thereby be reduced. If a gas price of approximately 7 Gwei is considered, the cost to execute a cancel is reduced to $0.16, and $0.46 is required to execute the finish function for five recipients. 4https://markets.businessinsider.com/currencies/ eth-usd TABLE 3. Estimated cost of our confidential multi-party certified mail vs the proposal in [1]. TABLE 4. Statistics for the maximum, minimum, average (and standard deviation) for the price (in USD) required by each of the functions executed in our proposal considering the last year. B. A COMPARISON WITH OTHER PROPOSALS In this section, we compare our proposal with other identified e-mail solutions that provide confidentiality and fairness and sufficient data for a comparison. First, we consider the certified e-mail solution for single exchanges presented in [18], where there is just one sender and one recipient. In our proposal, we have defined a solution to be used in a multi-party scenario, but this can also be used for single exchanges with one recipient. In a second comparison, we can apply [18] for use in a multi-party scenario, considering that in each exchange and by each recipient, the sender must publish data in the blockchain. Remember that in our proposal, the blockchain is only necessary when problems arise during the exchange. Thus, our proposal may be the solution to choose in both scenarios (single and multiparty). Another of the solutions that we use for comparison is one of the proposals presented in [1]. To compare both solutions properly, we will consider the required cost, measured in gas units,5for each proposal. In [1], there is a finish function that is executed by the TTP as an intermediary for any recipient, while in our solution, the sender can execute this action. Similarly, in [1], the sender can execute the cancel function, while any of the recipients can call this function in our solution. Considering the above discussion, Table 3shows a comparison of the cost between both proposals (our proposal and [1]), reflecting which participant performs each function. In [1], the operations of the recipients are centralised in a TTP, so involving a third party will require a cost that has not been considered in the data provided by the authors. 5We used the data published by the authors in [1] because the smart contract was not available to be downloaded and tested (we searched the GitHub repository indicated by the authors) VOLUME 8, 2020 103005