Data transmission exists in almost all the Internet-based applications, while few of them consider the property of nonrepudiation as part of data security. If a data transmission scheme is performed without the endorsement of a trusted third party (TTP) or a central server, it is easy to raise disputes while transmitting valuable data, especially digital goods, because a dishonest participant can deny the fact of particular data transmission instance. The above problem can be solved by signing and encrypting. However, digital signature schemes usually assume public key infrastructure (PKI), increasing the burden on certificate management and are not suitable for distributed networks without TTP such as blockchain. To solve the above problems, we propose two new schemes for nonrepudiation data transmission based on blockchain (we call it BNRDT): one for short message transmission and the other for large file transmission. In BNRDT schemes, nonrepudiation evidence of data transmission is generated and stored on the blockchain to satisfy both the properties of nonrepudiation (including nonrepudiation of origin and nonrepudiation of receipt) and data confidentiality. We implement and test the schemes on Hyperledger Fabric. The experimental results show that the proposed schemes can provide appealing performance.
An overwhelming majority of Internet-based applications are inseparable from data transmission, may be short messages, videos, or even confidential government documents. In most cases (e.g., online chatting and video-on-demand service), data transmission processes rely on a trusted third party (TTP) or a central server, which acts as a data source (or a transmission relay station) and the security provider. With such a trusted platform, data security including confidentiality, integrity, authenticity, and even nonrepudiation when required are easily implemented. However, in some specific scenarios, such as P2P (Peer to Peer) digital goods trading, schemes are in lack of endorsements by trusted platforms; thus, nonrepudiation is no longer easy to achieve. Concretely, we consider that a digital goods seller needs to transmit the commodity over the Internet to an online buyer. Since the data transmission instance affects the parties’ own interests, thus both the seller and the buyer want to ensure that the whole process can be undeniable, if they are honest. In other words, the buyer cannot deny having received the data so as to refuse to pay for it, and the seller cannot deny having sent it to the buyer so as to refuse to refund or be responsible for it if any problem arises after purchasing.
Nonrepudiation services [
Summarily, although lot of work [
Based on our observation, what function we want to realize in most cases is that the data can be transmitted in a secure manner, in which no TTP is required, fairness is provided equally to any participant, data is transmitted in ciphertext that only desired recipient can get it, and all behaviours throughout the process of data transmission cannot be denied. In order to realize our goal and make our work more adaptable, we give two data transmission schemes based on the characteristics of blockchain. In the first one, a short message can be transmitted securely and undeniably, which does not require TTP, provides fairness equally to any participant, and every behaviour is undeniable. While in the other scheme, which is an extended version of the first one, we can transmit large files undeniably with supporting the same properties.
Similar to the previous work in the research of nonrepudiation property, we consider the following nonrepudiation types [ Nonrepudiation of Origin (NRO): it provides evidence that the transmission data is originated from the specified sender Nonrepudiation of Receipt (NRR): it provides evidence that the recipient has received the correct transmission data
Note that we focus on the malicious cases that the participants deny having done something. Therefore, the NRO evidence is generated for the recipient to prove the behaviour of the sender, and the NRR evidence is generated for the sender to prove the behaviour of the recipient. The NRO and NRR evidence should always appear in pairs to guarantee the fairness of generating nonrepudiation evidence.
The remainder of this paper is organized as follows. Section
Nonrepudiation protocols, being as a solution to the problem of accountability in the distributed communication environment, has gained a lot of attention. As mentioned above, most of existing nonrepudiation solutions rely on TTP to generate and judge the evidence [
A typical way to achieve nonrepudiation without introducing TTP is to increase the interactions and release the secrets gradually [
In addition to the problem of relying on TTP and low efficiency, the existing traditional nonrepudiation solutions still have an unsolvable problem, that is, the storage of the evidence is accomplished by the participants themselves or the TTP. Considering the constraint of storage space, business migration, or human error, these records of evidence are generally not permanent. Once the record disappears, there will be hidden trouble in accountability.
Blockchain technology emerged as the low-level technology of the Bitcoin cryptocurrency system [
Besides its wide application in cryptocurrency systems, there are two main strands of the nonfinancial application of blockchain technology. One is to use blockchain to store data (e.g., Merkle Tree [
More recently, Xu et al. [
Summarily, although there are numerous nonrepudiation supported protocols or schemes, we still cannot find a suitable solution for transmitting some data from a sender to a recipient while supporting nonrepudiation, fairness, data confidentiality, and tolerance of malicious cases at the same time. Therefore, we urgently need such a non-TTP-based nonrepudiation solution for distributed environments.
We put forward the construction on secure data transmission problems with nonrepudiation property. To avoid introducing TTP, we exploit blockchain technology to verify the behaviours of participants and promote the execution of the scheme. So, we call our scheme as Blockchain-based Nonrepudiation Data Transmission (BNRDT) scheme. To fit more scenarios and the feature of the blockchain technology, we propose two BNRDT schemes, the original one is for short message transmission (data size less than 1 KB) with fewer interactions, and the other improved one is for large file transmission (data with MB or GB level size). We can choose any scheme according to the environment when transmitting mid-size data. Both the schemes provide nonrepudiation of data transmission process with fair nonrepudiation evidence generation. Meanwhile, the two BNRDT schemes can protect the confidentiality and integrity of the transmitted data and handle all the possible malicious cases.
We put forward the desired properties of a nonrepudiation secure data transmission scheme to analyze the security of our schemes. In detail, we combine all the necessary security properties we want from both the data transmission and nonrepudiation, including data security, requirement to resistant to malicious cases, nonrepudiation of both the sender and the recipient, and the fairness of nonrepudiation evidence generation. Based on this, we give a detailed security analysis of our schemes.
We give a prototype implementation of our nonrepudiation data transmission schemes based on Hyperledger Fabric blockchain. Furthermore, we evaluate the implementation and prove the applicability of the proposed schemes.
In this section, we will introduce some preliminaries including the security model to better describe and analyze the schemes in later sections.
The main notations used in this paper are shown in Table
Notations used in this paper.
Notation | Meaning |
---|---|
Sender of the message or file | |
Recipient of the message or file | |
The smart contract deployed on the blockchain | |
Blockchain account identifiers of | |
Temporary key pair for asymmetric encryption | |
The short message that needs to be undeniably transmitted | |
The large file that needs to be undeniably transmitted | |
The randomly generated key for symmetric encryption | |
Ciphertext obtained by symmetric or asymmetric encryption | |
Hash values | |
com | Commitment value of secret |
The deposit paid by the participant | |
A unique label that identifies a BNRDT instance | |
The state of protocol instance labelled with |
Hash function is used to compress an arbitrary length input string into short and fixed-length string output. An unkeyed hash function can be written as
We say that a hash function is collision resistant, that is, colliding pairs are unknown and computationally infeasible for a probabilistic polynomial-time (PPT) adversary to find even though they exist [
Take the discrete-log problem-based implementation (e.g., the Pedersen commitment [
The commitment scheme have to satisfy two properties including
Classically, only algorithm ComGen is executed by the recipient and both Com and Open of a commitment instance are executed by the committer. While, in this paper, we redesign and implement the commitment scheme based on the blockchain and the smart contract. We let the recipient execute the opening operation in order to confirm that he has received the secret. Besides, both the committer and the recipient will interact with the smart contract rather than each other. For implementation details, we refer the reader to the Section
Both the symmetric and asymmetric encryption schemes are introduced here.
A symmetric encryption scheme is a tuple of PPT algorithms (SymGen, SymEnc, and SymDec) such that SymGen takes as input a security parameter
We say that the symmetric encryption scheme has indistinguishable encryptions under a chosen-ciphertext attack, i.e., the scheme is IND-CCA (Indistinguishability Chosen-Ciphertext Attack) secure if for any PPT adversary who chooses a pair of messages
Similar to the above definitions, we define and denote the three PPT algorithms of asymmetric encryption scheme for key generation, encryption, and decryption as (
We also define the security of asymmetric encryption schemes. We say that the asymmetric encryption scheme has indistinguishable encryptions under a chosen-ciphertext attack, i.e., the scheme is IND-CCA secure if for any PPT adversary who chooses a pair of messages
Before introducing the construction of our scheme, we present the security properties that we want to achieve and the reasonable trust assumptions here.
To formally describe the security of the scheme, we first give the security objectives we want a nonrepudiation data transmission scheme to achieve.
First, the scheme should provide sufficient data security and transmission fairness, as described in Property Property
Furthermore, as a nonrepudiation scheme, the nonrepudiation properties described by Property Property
Now, we give the security definition of a nonrepudiation data transmission scheme.
If a nonrepudiation data transmission scheme satisfies properties
We also give some trust assumptions which are necessary. First, we assume that both the sender and the recipient of a data transmission instance are possible to cheat the other party due to their self-interests, but neither of them will perform abnormal behaviours that are detrimental to their own interests, such as revealing their own private key to the adversary. Second, we assume that the blockchain (including the smart contract) is a trusted component. Once the transaction is confirmed by enough nodes, the data on the blockchain is trusted and immutable. For the smart contract, the adversary cannot modify its internally deployed algorithms. We think the last assumption is also reasonable because adversaries have to pay a great price to modify the historical data on the blockchain. In addition, we point out that data on the blockchain will be open to all scheme participants, so there will be no secrets on the blockchain.
In this section, we will introduce the construction of the original BNRDT scheme for short message transmission. Regularly, the BNRDT scheme involves three parties including a sender
Our BNRDT scheme requires that the recipient submits the deposit in the first message of an instance, which ensures the smart contract to force the recipient to open the commitment submitted by the sender, thus to get the deposit back. If the recipient misbehaves, he will never get back the deposit. On the contrary, if the sender misbehaves, we guarantee that the deposit will be returned to the recipient in the last phase of the scheme.
Now, we outline how we use the smart contract and the mentioned cryptographic building blocks to undeniably transmit a short message from
While initializing the scheme, our smart contract
Also note that there is a publicly available blacklist maintained by the smart contract, which records all the blockchain identity IDs of the malicious participants of any BNRDT instance. Any participant with its ID in the blacklist is no longer allowed to use the scheme in the future. This blacklist can also provide a reference for the honesty of the blockchain IDs for other blockchain applications.
The detailed workflow of the BNRDT scheme is shown in Figure
Workflow of the original BNRDT scheme for short message transmission.
Upon receiving a tuple (Terminate,
The uploaded In contrast, if all the above statements are negative, which means If
We now examine some crucial details of the above BNRDT scheme. First of all, we point out the reason why the recipient is required to generate a temporary public/private key pair rather than using its long-term key pair. The generated key pair is used for asymmetric encryption to protect the message from being obtained by any other third party. There is no problem using the recipient’s key pair when both the participants are honest. However, if a malicious sender publishes a commitment
We would also like to explain why we take the hash value of the message
Besides, we point out that the algorithm
Although the proposed BNRDT scheme can securely transmit the message between two blockchain users with the support of nonrepudiation property (we prove it in Section
As mentioned before, the proposed BNRDT scheme is qualified for short message transmission but not suitable for large files, mainly because the message is directly encrypted by an asymmetric key and the message is transmitted on-chain. In order to support large file transmission, in this section, we give an improved version of the original BNRDT scheme which uses symmetric encryption scheme to encrypt data and transmits data through an off-chain channel.
In order to transmit and protect a large file, we can use an efficient symmetric encryption scheme (e.g., AES) to encrypt the file under a randomly generated symmetric key
The detailed workflow of the improved BNRDT scheme is shown in Figure
The improved BNRDT scheme for large file transmission.
In phase 2, the symmetric encryption key
In phase 3,
Finally, if
In this section, we give the detailed security analysis of our BNRDT schemes based on the security properties described in the security model. To prove that our schemes satisfy Definition
If the hash function is modelled as a random oracle, the asymmetric and symmetric encryption schemes provide IND-CCA2 security, the commitment scheme provides secure hiding and binding properties, and the blockchain as well as the smart contract is trusted and immutable, and the proposed BNRDT schemes are secure data transmission schemes.
We begin our proof by considering five types of attacks: A malicious outsider attempts to obtain the transmission data through the published parameters of a BNRDT instance, while both the scheme participants are honest (Lemma A malicious participant of any BNRDT scheme attempts to cheat the other side by performing malicious behaviours (Lemma A malicious sender attempts to deny the fact that he has sent the data to the recipient through any BNRDT scheme (Lemma A malicious recipient attempts to deny the fact that he has received the data from the sender through any BNRDT scheme (Lemma A malicious participant of any BNRDT scheme attempts to generate nonrepudiation evidence for himself while also prevent the other one to generate it (Lemma
We start with Lemma
The data transmitted through BNRDT schemes is confidential against any probabilistic polynomial-time (PPT) adversary
In our original BNRDT scheme for short message transmission, when scheme ends normally, that is, when the scheme ends after phase 3 and the state variable
Since the asymmetric encryption scheme provides IND-CCA2 security, any PPT adversary
In our improved BNRDT scheme for large file transmission, we exploit the original scheme to transmit the symmetric encryption key, and we use an off-chain channel to transmit the ciphertext of symmetric encryption. In this case, two more parameters including the symmetric encryption ciphertext and its hash value are revealed to the adversary. However, with the assumption of IND-CCA2 security of symmetric encryption scheme and random oracle of the hash function, the adversary still cannot obtain any information about the original data. With the above analysis of the original BNRDT scheme, the adversary is also impossible to obtain the symmetric encryption key. Therefore, the adversary can neither recover the original data through the symmetric encryption ciphertext nor obtain the key to decrypt the ciphertext.
To conclude the proof of Lemma
We point out that the assumption that the hash function is modelled as a random oracle is reasonable in the blockchain environment since the security of the PoW consensus protocol on many existing blockchain platforms such as Bitcoin and Ethereum also relies on this assumption.
The BNRDT schemes guarantee that the malicious participant cannot obtain any advantage over the other party through performing any malicious behaviour if the integrated commitment scheme in BNRDT provides secure hiding and binding property, the encryption schemes provide IND-CCA2 security, and the blockchain as well as the smart contract is trusted and immutable.
Recall the design of the two schemes, the behaviours of a malicious participant can be divided into two categories, one is refusing to respond to the smart contract or the other participant, and the other is uploading incorrect parameters to the smart contract. For the first type, we have an algorithm inside the smart contract called Terminate for the honest participant to terminate the scheme when needed. Precisely, Terminate can be called in Phase 2 by the recipient in both the original and the improved BNRDT schemes when the sender refuses to make the commitment, in Phase 3 of the improved BNRDT by the sender when the recipient refuses to open the commitment, and in Phase 4 of the improved BNRDT scheme by the recipient when the sender refuses to make the commitment about the key. Through algorithm Terminate, the schemes can handle all of these cases easily. A problem comes to an honest sender that once he publishes the ciphertext of the message in phase 3 of the original BNRDT scheme (or ciphertext of the key in phase 5 of the improved scheme), and the recipient will be able to decrypt the asymmetric ciphertext and then obtain the original data, whether the recipient opens the commitment or not. However, since the recipient has not redeemed his deposit
Furthermore, since the commitment scheme provides secure
Phase Complain handles the above cases. In this phase, the honest recipient uploads the temporary private key to the smart contract; thus, the smart contract can reproduce the process of decryption and hash calculation and help the recipient to prove his innocence. If any BRNDT instance comes to phase Complain, the scheme ends abnormally and the original date will be available publicly due to the malicious sender, which goes beyond the protection of data confidentiality.
Note that the IND-CCA2 security assumption of the symmetric and asymmetric encryption schemes is also required, thus to guarantee that the recipient cannot directly recover the plaintext of the ciphertext and terminate the scheme without initiating the opening transaction in the following cases: The recipient receives the symmetric encryption ciphertext of the original data in phase 3 of the improved BNRDT scheme The sender publishes the asymmetric encryption ciphertext of the key in phase 4 of the improved BNRDT scheme The sender publishes the asymmetric encryption ciphertext of the original message in phase 2 of the original BNRDT scheme
We point out that the analysis above is based on the immutability of and the trust against the blockchain. To conclude the proof of Lemma
The BNRDT schemes guarantee that once the scheme ends normally rather than being interrupted by any malicious behaviour, any recipient of the BNRDT instances cannot deny the fact that he has received the data from the specific sender if the hash function integrated in BNRDT is modelled as a random oracle, the commitment scheme provides secure hiding and binding property, and the blockchain as well as the smart contract is trusted and immutable.
When an instance of the BNRDT scheme ends normally, to prove the fact that the recipient has received the data from the specific sender, we need to prove that The data is originated from the sender The recipient has received the correct data
If the participants transmit a large file through the improved BNRDT scheme, the sender will make two commitments: one is the hash of the symmetric encryption ciphertext and the other is the hash of the key. And the recipient is required to open the two commitments by decrypting and hash calculating. Since the commitment scheme provides secure
Similar to the origin of the data, since the hash function is modelled as a random oracle, and the commitment scheme provides secure hiding and binding property, the scheme ensures that the recipient can only open the commitment through calculating hash and uploading the correct parameters. And the algorithm
Now, we talk about how the behaviour of receiving data can be proved. We still assume that the data is transmitted through the improved BNRDT scheme. In this case, The judge initiates a transaction of The judge obtains the parameters in The judge obtains the parameter The judge checks that
These necessary checks guarantee that the data
The BNRDT schemes guarantee that once the scheme ends normally rather than being interrupted by any malicious behaviour, any sender of the BNRDT instances cannot deny the fact that he has sent the data to the specific recipient if the hash function integrated in BNRDT is modelled as a random oracle, the commitment scheme provides secure hiding and binding property, and the blockchain as well as the smart contract is trusted and immutable.
To prove the fact that a sender has sent the data to the specific recipient, the proof that the data is originated from the sender and the recipient has received the correct data are also required, please check it in proof of Lemma The judge initiates a transaction of The judge obtains the parameters in The judge obtains the parameter The judge obtains the parameter
Similarly, these necessary checks guarantee that the data
The BNRDT schemes guarantee that the generation of the nonrepudiation evidence of the finished data transmission instances is fair, which means either all the participants receive the evidence of the other party’s behaviour or none of the participants gets any valid evidence, if the blockchain as well as the smart contract is trusted and immutable.
In the improved BNRDT scheme, only when the recipient successfully opens the hash value of the symmetric encryption key, the state variable
Note the original BNRDT scheme for short message transmitting is included in the improved one, and the analysis will be completely similar, so we omit it when proving Lemma
In this section, we first make a comparison between our BNRDT schemes and some typical nonrepudiation approaches proposed before in many aspects. After that, we will discuss the implementation details and evaluate the performance of our schemes deployed on Hyperledger Fabric blockchain.
In this section, we compare our BNRDT schemes with some typical nonrepudiation approaches including [
The comparison is shown in Table
Feature comparison of BNRDT and BNRDT-based data transmission scheme and typical nonrepudiation approaches.
Approaches | Application | Fairness | Confidentiality | TTP-independence | Malicious participant tolerance | Interactions |
---|---|---|---|---|---|---|
[ | Data transmission | ✓ | ✕ | ✕ | ✓ | 5 |
[ | Data transmission | ✕ | ✓ | ✓ | ✕ | 2 |
[ | IIoT program delivery | ✓ | ✕ | ✓ | ✓ | 6 |
Original BNRDT scheme | Short message transmission | ✓ | ✓ | ✓ | ✓ | 3 |
Improved BNRDT scheme | Large file transmission | ✓ | ✓ | ✓ | ✓ | 5 |
“✓
To benchmark the performance of our schemes, we implemented and evaluated our BNRDT schemes based on Hyperledger Fabric (version 1.4.1) and a blockchain benchmark framework, Hyperledger Caliper [
The blockchain benchmark framework, Hyperledger Caliper, is introduced here to measure the performance of our protocol. Variables that can be manually controlled when testing include the size of data transmitted using the BNRDT scheme and the send rate of the blockchain transactions. By changing these two parameters, we observe the performance of the BNRDT algorithms on transaction throughput and average transaction latency. In theory, the size of the transmitted data will significantly affect the size of a single Fabric transaction, thereby affecting the time for transaction distribution and block synchronization (which can be called the transaction consensus time), and finally affect the transaction throughput. When the data size is fixed, the maximum throughput of the deployed Fabric network to this particular size of transactions will be fixed. The send rate of transactions identifies the rate at which the Fabric client sends transactions to the blockchain network. When it becomes larger, the blockchain network will eventually be unable to process all transactions in time, resulting in an increase in the average latency of transactions.
We performed the measurements on a five nodes Hyperledger Fabric network with an orderer node and 2 organizations, 2 peer nodes in each organization. Every node is deployed in an Ubuntu 16.04 virtual machine with 1 CPU and 4 GB RAM. Virtual machines to deploy peer nodes of one organization are created in one host physical personal computer with an Intel(R) Core(TM) i5-8400 CPU @2.80 GHz and 16 GB RAM, running Windows 10 (64 bit). Different peer organizations as well as the orderer node are deployed on different host machines, such deployment makes the node topology closer to the real application context of Fabric blockchain.
The Caliper benchmark results are shown in Figure
Caliper transaction throughput and latency benchmark of BNRDT algorithms deployed on Hyperledger Fabric. The blockchain network consists of 1 orderer node and 2 peer organizations with 2 peer nodes in each organization.
As can be seen from Figures
Turning now to the performance benchmark of algorithm
In terms of algorithm
To avoid performance degradation caused by the increase in data size, we recommend that users use the improved BNRDT scheme for transmitting data with large-size data. In the improved BNRDT scheme, the length of the data to be asymmetrically encrypted is always short and fixed (less than 150 bytes in hexadecimal encoding). Specifically, the parameter
Overall, these benchmarks indicate the availability of our BNRDT scheme in a practical Hyperledger Fabric network. The original BNRDT scheme we designed can be used to efficiently transmit short messages such as passwords or notifications, and the entire process only needs to initiate three blockchain transactions. Moreover, the scheme provides strong evidence of transmission nonrepudiation. However, when transmitting some big-size data, the direct transmission based on the blockchain will cause unacceptable transaction latency and even result in submission failure of the transaction. In such cases, users can use the improved BNRDT scheme for data transmission by performing two more transactions.
In this paper, motivated by the new requirement of nonrepudiation on secure communication, we start with the propose of a novel data transmission scheme based on blockchain technology and named it as BNRDT, which can get rid of the dependence on TTP and the PKI, and provide data security and nonrepudiation properties at the same time. The original BNRDT scheme requires only 3 interactions to effectively transmit some data in a secure and undeniable manner, but its application is limited by the size of the data. Furthermore, we propose an improved BNRDT scheme based on the original one to support large file transmission at the cost of two more interactions, which is still efficient. Compared with existing work on related topics, our application provides fairness, nonrepudiation, and free of TTP and PKI, as well as the complete security guarantee, i.e., the data is protected against outsiders. For any data transmission instance of the BNRDT schemes, the nonrepudiation evidence is generated and stored directly on the blockchain to realize the properties of Nonrepudiation of origin (NRO) and Nonrepudiation of receipt (NRR) at the same time. Through our experiment on Hyperledger Fabric, we also show the applicability of our schemes. Since data transmission is quite a basic function required in so many scenarios, we firmly believe that the proposed schemes are meaningful.
No data were used to support the findings of the study.
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Xiao Lan and Xingshu Chen contributed equally to this work.
The authors would like to thank the financial support in part by the Program National Natural Science Foundation of China (NSFC) under Grants U19A2081 and 61802270 and Fundamental Research Funds for the Central Universities under Grants SCU2018D018 and 2019SCU12069.