2. Related Knowledge
2.1. Blockchain Technology
The blockchain utilizes a distributed data storage model with decentralization, transparency, tamper resistance, and traceability, and it records all transactions in a peer-to-peer network [
22]. In a blockchain system, each node maintains a blockchain replica.
Figure 1 demonstrates how the information of the transaction is publicly uploaded into the matching block with the
Merkle tree and how this block points to its previous block by recording its hash. Thus, the information on the blockchain cannot be altered. Additionally, millions of incentive-driven nodes are expected to confirm the legitimacy of transactions as they become publicly recorded. The consensus mechanism implemented in the blockchain system makes it mandatory for all nodes to follow uniform rules. Then, the consistency of the content of records belonging to different bookkeeping nodes is stored in a distributed accounting system.
2.2. Smart Contract
The smart contract is a digital contract based on blockchain technology, and it is a transaction protocol implemented by computer code provided to distributed participants to follow. A smart contract can be used to build a digital rule to automatically execute transactions under specific conditions. Specifically, a smart contract is a program created through contract transactions, and it allows participants to automatically execute transactions. With smart contracts, transactions can be completed automatically after specific conditions have been satisfied. As the contract code is stored on a public and tamper-proof blockchain, smart contracts are trustworthy and reliable. The smart contract in Ethereum can be regarded as an external account with a contract address. When a contract is invoked, the contract parameters are used as input, and then the transaction is sent to the contract address after paying the contract with ETH. Gas is the execution cost of each operation in Ethereum. Each process in the Ethereum Virtual Machine (EVM) consumes gas. The more data are computed and stored, the more gas is consumed. Each transaction invoking the contract must include a gas limit and a gas price, where the gas limit is the maximum gas consumed in a transaction, and the gas price is determined by the users and the nodes.
2.3. MA-HTLC
The HTLC protocol, derived from the lightning network [
23], facilitates decentralized conditional payments among multiple users, eliminating the necessity for a trusted third-party intermediary. It is widely used in atomic swap and cross-chain transactions. Hash locking entails that a commitment is valid if the pre-image for a given hash value H is provided; otherwise, it becomes invalid. In case of transaction failure due to various reasons, the implementation of a timelock allows all parties to retrieve their funds and mitigate potential losses arising from fraudulent activities or transaction failures. This protocol introduces an accounting system into the Fabric blockchain and integrates smart contract technology to facilitate secure and seamless asset exchange between Ethereum and the Fabric network. During the transfer, distinct intermediary accounts are established for asset custody and transfer purposes, which are promptly eliminated upon transaction completion, thereby preserving the original cross-chain transaction rate while ensuring transaction security.
Figure 2 demonstrates that the protocol process consists of the following steps.
Step 1. Client A creates a mid-account through a pre-image, receives the mid-account address and hash , creates a hash-lock transaction on Fabric, returns a transaction lock , and sends it to Client B.
Step 2. Client B receives the and time-lock T by querying the locked asset transaction and confirms the account balance through . Then, and are used to create a hash timelock transaction on Ethereum, and the transaction lock is returned and sent to Client A.
Step 3. After receiving , Client A will use , and S will take out the assets from Ethereum. If Client A does not retrieve the assets after , the transaction will be deemed as a failure, and Client B can retrieve the assets.
Step 4. Client B queries the locked asset status on Ethereum through . If the asset has been taken, the query result returns pre-image S. Then, Client B communicates with Fabric through S and to retrieve the assets that Client A has locked on it. If Client B fails to take out the asset within the time limit, it is deemed that the asset exchange failed, and Client A can retrieve the asset.
2.4. Paillier Homomorphic Encryption
The Paillier homomorphic encryption algorithm is an encryption algorithm based on public-key cryptography. By performing operations in the ciphertext domain and decrypting the ciphertext, it can match the operations in the plaintext domain and encrypt the plaintext. Therefore, data privacy can be protected while searching and calculating ciphertext. The relevant theoretical knowledge of the algorithm is provided in the following.
2.4.1. Encryption and Decryption Process of the Paillier Algorithm
- (1)
Key Generation
Two large prime numbers p and q are randomly selected such that , where denotes the greatest common divisor of a and b. and are calculated, where denotes the least common multiple of a and b. is selected, and is satisfied. It is ensured that divides the order of by checking the existence of the following modular multiplicative inverse: , where . The public key is , and the private key is .
- (2)
Encryption
Let
m be the plaintext; a random number
is selected.
m is encrypted to obtain ciphertext
c.
- (3)
Decryption
Let
c be the ciphertext, where
.
c is decrypted to obtain plaintext
.
2.4.2. The Additive Homomorphism Property of Paillier’s Algorithm
The value of can be calculated by multiplying and . The real value of can be obtained after decryption by the person who has .
In the Paillier algorithm, adding in the plaintext domain is equivalent to multiplying in the ciphertext domain.
3. ExchangeSC Design
To address the issue of inadequate security and client privacy in the MA-HTLC protocol, we developed ExchangeSC, an information security exchange system based on Paillier homomorphic encryption. Additionally, we incorporated a blockchain depository function to document any transaction-related disputes. Conceptually,
Figure 3 demonstrates that ExchangeSC implements a scheme for secure information exchange that safeguards client privacy. Clients are provided with an Application Programming Interface (API) for information exchange through the encryption API within ExchangeSC, which must interact with the smart contract via the authoritative node
. The authoritative node is either assumed or selected by the authoritative institution and possesses a reliable identity. The smart contract deployed on the blockchain serves as an incentive mechanism to ensure secure information exchange for all parties involved.
In this section, we describe the three-part structure of ExchangeSC. ExchangeSC implements a hybrid blockchain system that supports client information security exchange, client privacy protection, and exchange record supervision and storage through smart contracts and an information transmission scheme based on Paillier homomorphic encryption. In ExchangeSC, the three parts interact seamlessly; the client invokes the interface in the Paillier encryption API, and the algorithm in the Paillier encryption API is completed in the blockchain and through client participation.
3.1. Client Part
The client part is composed of Client A, Client B, and the interaction with the Paillier encryption API. This part connects two types of entities: Client A and Client B. Both Client A and Client B interact directly with local encryption rather than directly with the blockchain part.
Client A: This is the initiator of information exchange and hopes to initiate a regulated information exchange.
Client B: This is the receiver of the information exchange. After receiving and verifying the correctness of the information sent by A, Client B sends their information to A.
The client invokes the API interface, converts the hexadecimal hash value into a decimal number, decomposes the decimal number into two numbers, and adds them through Div; then, they obtain the public–private key pair through KeyGen, encrypt the two numbers through Enc, and encrypt the identity information with the private key for generation. Finally, the signature and ciphertext information is uploaded to the authoritative node in the blockchain. When receiving the ciphertext information, it is decrypted with Dec to obtain the original plaintext information.
3.2. Paillier Encryption API Part
The Paillier homomorphic encryption API aims to encrypt information and meet client requirements. In addition, encryption is directly associated with the authoritative node, so the API can participate in the calling of the smart contract through the authoritative node. When the cross-chain transaction starts, the APIs of both clients are deployed and synchronized by a Key Generation Center (KGC) to ensure that the KeyGen generates the same public–private key pair. Below, we will introduce the working principle.
- (1)
The signature information uploaded by the client is received and saved.
- (2)
A Div interface is provided. The client first inputs into the API, then invokes Div to convert the hexadecimal hash value into a decimal number, and randomly decomposes it into the following two numbers in the form of addition for the subsequent encryption.
- (3)
Clients are provided with the KeyGen interface to generate public and private key pairs () for Paillier encryption.
- (4)
An encryption interface Enc and decryption interface Dec are provided. Clients can encrypt to by invoking Enc, and they can decrypt to plaintext information by invoking Dec. Finally, the decimal plaintext information is converted into a hexadecimal hash value to obtain .
3.3. Blockchain Part
The blockchain is the most essential part of the system, as it is used to exchange information between the two parties in a secure manner and to store and supervise the exchanged information. Nodes in the blockchain network are recruited, and the smart contract is invoked to multiply the ciphertext pair and send the result to . The participating node will only receive the ciphertext pair encrypted by the Paillier algorithm and cannot receive any other relevant information or any client information. Smart contracts are used to record registration information and transparently execute services, which are finally recorded by the blockchain. The smart contract consists of the following five algorithms.
(1) Registration: In this part, we introduce the process of node registration (Algorithm 1). A node in the blockchain obtains rewards by providing services calculated on the ciphertext domain. It must register by paying a deposit to the smart contract and filling in the registration information. The deposit is used to punish the improper behavior of a node. If a node provides an incorrect answer or fails to provide an answer, it will lose part of the deposit. The registration information is as follows.
Registered deposit.
Node address.
The slowest service completion time.
The number of completed services (initially 0, +1 after correct service completion, and −1 after incorrect service completion).
The registration information is recorded in the smart contract, and each entity in the blockchain network must comply with the smart contract protocol, so the smart contract acts as the intermediary between an entity and the blockchain network.
Algorithm 1 Registration |
Input parameters: node address, deposit, slowest service time Output: RegistrationInfor
- 1:
function register (node address, deposit, slowest service time) - 2:
contract.sendDeposit (node address, deposit) - 3:
contract.registerNode (node address, deposit, slowest service time) - 4:
end - 5:
return RegistrationInfor
|
(2)
Request: In this part, we will explain the process of the node
requesting services (Algorithm 2). When the authoritative node receives the transaction information, it requests a service from the smart contract and submits a service request, which consists of ciphertext information, the number of participating service nodes, a registration deposit demand, a service completion time demand, and a slowest completion time demand. Then, according to the service request, the smart contract selects the nodes whose registration deposit is greater than the registration deposit demand, whose service completion times are greater than the service completion time demand, and whose slowest completion time is less than the slowest completion time demand to participate in this service, and it sends the ciphertext information to the selected node. If the slowest completion time of two nodes is the same, to select a more reliable node, the smart contract should select the node with more registration deposits and more service times. To ensure the efficiency of the service, when the deposit for registration is the same and the number of completed services is the same, the nodes with the slowest completion time will be preferentially selected for service. If the client has no requirements for service time, the smart contract should choose a node with higher integrity for service. To select a more secure and reliable node and complete the service request more quickly, a greedy algorithm is used as a solution to the problem. The request will be terminated if a qualified node cannot be found among the existing nodes.
Algorithm 2 Request |
Input: ciphertext, num participants, deposit requirement, service time requirement, slowest service time requirement
Output:
- 1:
function request(ciphertext, num participants, deposit requirement, service time requirement, slowest service time requirement) - 2:
nodes = contract.getNodes() - 3:
valid nodes = [ node for node in nodes if node.deposit deposit requirement node.service times service time requirement node.slowest service time slowest service time requirement] - 4:
valid nodes.sort(key= x:(x.slowest service time, -x.deposit, -x.service times, x.node address)) - 5:
if participants = valid nodes[:num participants] then - 6:
for i in range(len(participants)) do - 7:
node = participants[i] - 8:
contract.sendCiphertext(n.node address,ciphertext) - 9:
end for - 10:
end if - 11:
return
|
(3) Verification: In this part, verifies the digital signature of the clients to confirm their identity.
(4) Calculation: In this part, multiplies the ciphertext in the ciphertext field to calculate the result and sends the result to .
(5) Report: In this part, nodes that have not participated in the service but have paid the deposit can report the misconduct of the participating service nodes (Algorithm 3). Misconduct includes miscalculation and negative services (not calculated), which are rewarded through the smart contract. The two forms of misconduct are reported as follows.
To deal with the improper behavior of miscalculation, we designed a service mode. When a service request is received, the smart contract selects the with service number n. Assuming that the returns two different results to through calculation, both results will be sent to the client’s local API. The client first decrypts the results of a larger number of calculations and decrypts another result if this fails. When the client completes this exchange service, it will broadcast the ciphertext information to the blockchain network. The node that does not participate in this service but has paid the deposit will calculate and send the report information to the smart contract. The report information includes the registered deposit and misconduct of the nodes. Similarly, the registration deposit of the reporting node is also more than the requirement, thus reducing the behavior of malicious reporting. Then, the smart contract check results show that if the does have the improper behavior of miscalculation, part of its registration deposit will be deducted from the reporting node.
To deal with the improper behavior of providing a negative service, the nodes in the blockchain network can detect the service record and whether the returned the results within the shortest service time. If not, negative service behavior is found. The report information is sent to the smart contract, including the registered deposit and misconduct. Then, the smart contract checks the service record. If it is indeed as shown in the report information, the reporting node will obtain part of the deposit of the . Otherwise, it will deduct part of its deposit.
If a node in the blockchain network does not provide report information within a certain period of time, the will be rewarded. Note that the reporting process is carried out after the client obtains the ciphertext information, so it will not affect the efficiency.
The blockchain should meet the following three essential requirements to provide security, privacy, and fairness.
Privacy: The blockchain protects the privacy of the client’s identity, and ordinary participating nodes cannot obtain relevant client information.
Security: and in the blockchain cannot deduce any information related to plaintext information through ciphertext.
Fairness: The blockchain’s reward and punishment mechanisms ensure the calculation results’ correctness. Malicious nodes will be detected after service, and their deposit will be deducted. At the same time, the blockchain also has a Report mechanism, and the whole process is recorded in the blockchain network, which means that malicious nodes that fail to provide services correctly for any reason will be detected by the smart contract and punished.
Algorithm 3 Report |
Input: registration deposit, improper behavior
Output: reportInfor
- 1:
function report(registration deposit, improper behavior) - 2:
nodes = contract.getNodes() - 3:
report nodes = [node for node in nodes if node.deposit = registration deposit] - 4:
if improper behavior == “improper computation” then - 5:
for i in range(len(report nodes)) do - 6:
node = report nodes[i] - 7:
result1 = contract.getResult(node.node address, 1) - 8:
result2 = contract.getResult(node.node address, 2) - 9:
contract.sendReport(node.node address, “improper computation”, result1, result2) - 10:
end for - 11:
service records = contract.getServiceRecords() - 12:
for i in range(len(service records)) do - 13:
record = service records[i] - 14:
if record.finishT-record.startT = record.slowest service time and not record.resultprovided then - 15:
node = contract.getNode(record.provider address) - 16:
if node.deposit = registration deposit then contract.sendReport(node.node address, “passive service”, None, None) - 17:
end if - 18:
end if - 19:
end for - 20:
end if - 21:
return reportInfor
|
3.4. Workflow of ExchangeSC
The specific workflow of the system is divided into the following 11 steps.
Figure 3 demonstrates further details.
Step 1. Client A inputs and into the local API.
Step 2. The API divides as and uses the Paillier homomorphic encryption algorithm to encrypt and ; then, the ciphertext information and is obtained. The API uploads , , and to .
Step 3. Client B inputs into the local API, which uploads to .
Step 4. invokes Verify to decrypt and using their respective public keys, which verifies the identity of both.
Step 5. sends and to . invokes Calculate to calculate the result of the multiplication operation on the ciphertext domain for and and then transmits the result of the respective calculation to . After that, records the information of and sends to the local API for Client B.
Step 6. Client B uses the API to decrypt and verify the correctness of .
Step 7. Client A inputs into the local API.
Step 8. The API divides as and uses the Paillier homomorphic encryption algorithm to encrypt and ; then, it receives ciphertext information and . The API uploads and to .
Step 9. sends and to . invokes Calculate to calculate the result of the multiplication operation on the ciphertext domain for and and sends the result of the respective calculation to . Then, records the information of and sends to the local API for Client A.
Step 10. Client B uses the API to decrypt to obtain and verify the correctness of .
After the above steps are completed and no nodes participating in the service have invoked Report, the exchange process is considered to be completed, and the transaction information is packaged and uploaded to the blockchain for storage and supervision.
4. Correctness and Security Analysis
This section analyzes and demonstrates the correctness and security perspectives of ExchangeSC.
4.1. Correctness Analysis
The correctness of ExchangeSC is discussed in the following theorems.
Theorem 1. Client A can obtain by decrypting using Dec.
Proof. Select a random integer
g where
, so
and
. Then, select
, and let
. The private key
is used for decryption.
Substituting
into the above equation, we find that
□
Theorem 2. Client B can obtain by decrypting using Dec.
Proof. The proof is omitted, as it is the same as that in Theorem 1. □
Theorem 3. The client performs Div, , and encrypts in the plaintext domain. The node multiplies the ciphered and in the ciphertext domain and obtains the same result as that after decryption. Proof. Select a random integer
g where
, so
and
. Then, select an id and random numbers
. Here,
and
.
□
4.2. Security Analysis
ExchangeSC guarantees that only authenticated clients are entitled to ciphertext information through the blockchain node computing service.
Adversary Assumptions: We have made the following assumptions about the adversarial model.
The key of the encryption API is generated by the KGC, and both sides of the encryption API are deployed and synchronized by the KGC, which is a trusted party; the key is not disclosed to anyone after it is generated.
No party in the blockchain network can control the vast majority of computing power, i.e., no 51% attack can be launched, so all transactions and actions of nodes are publicly recorded in the blockchain and are tamper-evident.
The communication channel between the crypto API and the blockchain network is protected by SSL/TLS and cannot be tampered with or leaked to nodes in the blockchain.
Adversary model: It is considered that there are two types of attackers in the system: internal and external. We assume that the internal attacker could be every node in the blockchain network, while the external attacker has not paid a deposit to become a registered node.
(1) Internal Attackers: An internal attacker can participate in the smart contract to perform a service, and it can obtain . There are two ways to attack: committing misconduct in the service or reporting process but being rewarded and stealing the privacy of the client’s identity. The proposed system implements security against both of these types of attacks.
Since all actions of nodes are public in the blockchain network, their misbehaviors are recorded. The system’s reporting mechanism can detect these misbehaviors and punish nodes that have done so.
The client’s identity information is not made public to the blockchain network but is sent by the API, which verifies the identity information. Therefore, an internal attacker cannot distinguish who it is actually providing services to, which effectively protects the privacy of the client’s identity.
(2) External Attackers: An external attacker can eavesdrop on the ciphertext and access public transactions in the blockchain network. The goal of their attack is to obtain the ciphertext information and then decrypt it to gain and, thus, steal the assets that the client has locked on the chain.
The security of our system is based on the security of Paillier homomorphic encryption. The Paillier scheme meets the standard security definition of an encryption scheme: semantic security, that is, the indiscernibility of ciphertext under a chosen-plaintext attack (IND-CPA). The security of the scheme can be reduced to the decisional composite residuity assumption, which means that given a composite number n and an integer z, it is difficult to determine whether z is an nth-power residue under . So far, no polynomial time algorithm can break through, and the security of the Paillier encryption scheme is considered reliable. So, even if the attacker eavesdrops on the ciphertext information, they cannot make inferences from the ciphertext information.
The security proof is given as follows.
Theorem 4. If the original is divided into n fragments, the is indicated as a set , , . If are extracted from A, thus obtaining , then the following formula holds. Proof. Assuming that the original formula is not tenable, the following formula holds.
It follows from the correctness of the homomorphism that this formula can be reduced to ∼; this obviously contradicts the condition.
So, this assumption does not hold. □
Theorem 5. If the original is divided into n fragments, the is indicated as a set . For any , instead of , and is obtained; then, the following formula holds. Proof. This mimics a substitution attack by an adversary. The correctness of the Paillier algorithm makes the sufficient condition for successful decryption the use of the correct set A. So, the replacement of the correct fragment obviously cannot result in the correct decryption result being obtained. □
Corollary 1. If , , after deleting a certain , is obtained; then, the following inequality holds. Corollary 2. If , adding , is obtained; then, the following inequality holds. According to Theorems 4 and 5 and their corollaries, the safety of the newly proposed ExchangeSC was demonstrated. If a customer’s identity information is partially replaced, deleted, or added, it cannot be decrypted and verified. Thus, the security of the proposed ExchangeSC can be fully demonstrated in theory and application.