The contributions in this paper are as follows: 1.

Ensure fairness: The proposed model promotes fairness by identifying dishonest behavior among participants utilizing commitment and signature techniques. Additionally, it enforces penalties and rewards through the implementation of smart contracts.

This paper is structured as follows: Section 2 presents the cryptographic techniques utilized in the proposed model, while Section 3 delineates the operational procedures of the model in a step-by-step manner. Section 4 discusses the implementation of the proposed model, along with the results and analysis derived from this implementation. Finally, Section 5 offers a conclusion to the paper.

Khan et al. [8] introduced BELIEVE, a blockchain platform based on multi-party computation (MPC) [9], which serves as a framework for efficient verification via location identification and encryption. BELIEVE employs an adaptive strategy that empowers data sources to autonomously ascertain the timing of verification and the specifics of their trajectories. Additionally, it utilizes smart contracts to facilitate the verification of mobility data. The platform also guarantees privacy through an MPC-based consensus mechanism among proximate mobile peers, thereby eliminating the need to share original data.

Li et al. [10] introduced a Blockchain-based Speed Advisory System (BSAS), which enhances the existing Consensus-based Speed Advisory System (CSAS) by integrating blockchain technology. This integration aims to establish a trustworthy framework that prioritizes user privacy. BSAS employs cryptographic primitives to safeguard the confidentiality of the CO2 emission cost function, thereby offering a reliable and fully decentralized vehicle speed recommendation system. Furthermore, it suggests an optimal speed that minimizes emissions and implements a value-driven incentive mechanism to motivate vehicle users to engage with the service.

Golob et al. [6] proposed a decentralized data marketplace that prioritizes input and output privacy within a blockchain framework. This marketplace guarantees payment fairness by automatically compensating data providers with cryptocurrency tokens. Additionally, it employs two privacy techniques—secure multi-party computation (MPC) and robust differential privacy guarantees—to facilitate a privacy-centric data exchange.

Yuan et al. [11] proposed TRUCON, a blockchain-based data sharing mechanism designed to facilitate congestion control and data deduplication within Internet of Vehicles (IoV) environments. TRUCON employs the Kademlia algorithm, enabling source vehicles to restrict the number of reference vehicles involved in the transmission of traffic data. Additionally, it incorporates a Cuckoo Filter-based deduplication technique to mitigate unnecessary data sharing. This approach enhances both the integrity and reliability of data sharing, while simultaneously improving network efficiency.

Sadiq et al. [12] proposed a data trading model based on the Internet of Vehicles (IoV) that guarantees secure data storage and the privacy of vehicles within a blockchain framework. The model employs a digital signature scheme grounded in elliptic curve bilinearity to ensure the authenticity and integrity of the trading data. Additionally, it utilizes smart contracts that are autonomously executed between trading parties to address payment disputes and ensure the fulfillment of payment obligations.

First introduced by Yao in the 1980s, secure multi-party computation (MPC) is a versatile cryptographic technique that enables multiple distributed participants to collaboratively compute arbitrary functions while maintaining the confidentiality of their private inputs and outputs [9]. This process ensures privacy, as each participant remains unaware of the input data of the other participants, and the output of the computation cannot be deduced from the input data of others. Additionally, consistency is assured in that honest participants will obtain identical computational results. The ORTHRUS employs Multi-Party Computation (MPC) grounded in the principles of Secret Sharing, facilitating participant interaction while maintaining data confidentiality. Secret Sharing is a method that protects confidential input data within various MPC frameworks, enabling the division of secret input data or multiple confidential inputs into several shares [14]. This paper adopts the SPDZ protocol as a representative technique based on Secret Sharing for the implementation of MPC.

SPDZ Protocol

In the SPDZ protocol, the values exchanged among all participants are shares produced through a secret sharing technique, which are subsequently utilized for circuit evaluation [15]. The SPDZ framework is comprised of three distinct phases: an offline phase, an online phase, and a phase dedicated to output and verification.

Offline phase: This phase, commonly referred to as the preprocessing stage, produces a set of shared random numbers utilized for the purpose of masking confidential input data [15]. Additionally, it executes a multiplication operation to create a predominant multiplication triple (<a>,<b>,<c>) and a random mask value.

Output and Verification phase: This phase involves the verification of all published numerical data and final output values through the use of Message Authentication Code (MAC). Verification can be conducted in batches utilizing a randomized linear combination. In the event of a discrepancy during the MAC verification phase, the protocol will be terminated.

The primary algorithms of the MOZAIK architecture are developed utilizing secret sharing techniques [13] and the AEAD (Symmetric Authenticated Encrypted with Associated Data) algorithm [16].

The secret sharing mechanism employed in the MOZAIK architecture is based on threshold-based secret sharing. This method involves partitioning a single source of data into n shares, which are then distributed among the participants. The original data can be reconstructed only when the number of gathered shares exceeds a certain threshold. Two algorithms that facilitate this process are the partitioning algorithm share(d)→[[d]]1,…,[[d]]n and the reconstruction algorithm Recon([[d]]1,…,[[d]]n)=d. Here, d are the original data, while n denotes the number of participants.

The AEAD [16] is a cryptographic technique that combines encryption of the original data with the generation of an authentication tag alongside the ciphertext. This authentication tag serves to verify both the integrity and confidentiality of the data. The underlying algorithm is represented by the encryption algorithm Enc(k,d)→(c,t) and the decryption algorithm DecAndVerify(k,Enc(k,d))=d. Where k is a symmetric key, c represents the ciphertext, and t signifies the authentication tag.

The main algorithms of the MOZAIK architecture based on this are the key generation algorithm keyGen(), the distributed decryption algorithm DistDec(), and the computation algorithm Infer().

KeyGen(): The algorithm uses the symmetric key k and the partitioning algorithm share() to generate the appropriate share of keys k1,…,kn for the number of compute nodes of MPC.

The proposed model applies the following cryptographic primitives. 1.

A cryptographically secure hash function H:{0,1}∗→{0,1}λ, where λ is the security parameter [17].

The ORTHRUS is built on top of a public blockchain, thereby inheriting security properties such as integrity, tamper-resistance, and others from the underlying blockchain platform that hosts the smart contracts. The system assumes a synchronous network model with authenticated peer-to-peer channels, which limits the adversary’s ability to manipulate communication [23]. Specifically, while an adversary may delay any message passed between honest parties by a known upper bound △, they cannot delete, reroute, or modify the message. The threat model considered in this paper is defined as follows:

The main components of ORTHRUS, DO, DR, and CN, do not trust each other and are assumed to act in their own self-interest and act rationally accordingly.

The ORTHRUS employs a reputation mechanism to enhance fairness and prevent Byzantine behavior [26]. The following studies exist on reputation mechanisms. Zhang et al. [26] proposed a blockchain-based Cyber Threat Intelligence (CTI) model combining consortium blockchains with distributed reputation management systems. This model prevents bribery attacks and offers faster performance than existing Byzantine Fault Tolerance (BFT) models. Liu et al. [27] proposed BtRal, a blockchain and trust-based reputation evaluation incentive mechanism. It introduced a multidimensional reputation evaluation method. It prevents malicious or pre-collusive evaluation attacks using multifactor moderation. It also designed and proposed rewards and penalties through reputation-based tokens. While reputation mechanisms themselves are an important research topic actively studied in the field of data marketplaces to enhance fairness and security, this paper focuses on secure and trustworthy data trading. Existing, well-established reputation mechanisms can be utilized to implement the proposed model. However, the specific details of the reputation mechanism itself are beyond the scope of this paper.

The ORTHRUS system begins with the deployment of the DO smart contract, followed by pre-processing, matching, and the actual computation steps for data trading. Since ORTHRUS accommodates two types of output data, the internal behavior during the computation phase is contingent upon the output data type requested by the DR. In this paper, the output data type refers to the specific data type requested by the DR, which can be categorized into two types: original data (flagXX=1) and the computation result for the requested function (flagXX=0). When a smart contract receives a request for dispute resolution from a DO or a participant in the transaction process, such as DR or CN, it initiates a dispute resolution step, and identifies the dishonest participant and penalizes them by confiscating their deposit and reducing their reputation score. The detailed process for each step in the ORTHRUS is discussed in Appendix A. Fig. 2 shows the processing flow of transactions and state variables handled by smart contracts in the proposed model.

In this paper, we designed ORTHRUS based on the Ethereum blockchain network environment with smart contracts. We utilized the Ganache test network to create accounts for participants and deploy smart contracts in ORTHRUS. In ORTHRUS, smart contracts perform transaction validation, dispute resolution steps, punishments, and rewards. We used the Solidity language to implement ORTHRUS’ smart contracts that operate in an on-chain environment, and JavaScript for the rest.

The ORTHRUS implementation consists of an off-chain part that generates signatures, a main smart contract part, and a smart contract part that performs dispute resolution steps. The smart contract part that connects to the Ganache environment and performs the main operation is deployed first, followed by the smart contract that performs the dispute resolution step. Various signature values used in the dispute resolution process are generated through the off-chain part using the Elliptic Curve Digital Signature Algorithm (ECDSA) method, and the smart contract uses them to perform verification. In addition, hash values for signatures in the main smart contract part are generated using keccask256.

This section describes the security of the ORTHRUS with the following lemmas and theorem.

Lemma 1. If all participants are honest, ORTHRUS satisfies completeness based on the assumptions and threat model in Section 3.1.

Proof. The completeness of the ORTHRUS is guaranteed when DO, DR, and CN follow the protocol with honesty.

Case 1: If DR requests the original data as the final result and all the participants are honest, DR will obtain Di′ during the validation of the actual computation step of the proposed model. The DR collects and reconstructs the obtained Di′ above the threshold to obtain D^′, and delivers {DTrueTx} to the SC as a result of hash value verification. The DO receives PriceO for the data, and each CN receives a share of Inc as a reward for computing the data correctly.

◻

Lemma 2. Assuming that the random leader selection technique applied in ORTHRUS is secure, based on the assumptions in Section 3.1 and the threat model, ORTHRUS is secure against prior collusion attack between the attacker and each participant.

Proof. In a proposal model, an attacker can only compromise a participant before executing the protocol in that model. Therefore, in order to perform a pre-collusion attack, the attacker must select the blockchain nodes to perform the collusion attack before the proposal protocol is executed. Furthermore, the selected blockchain node must be selected as a CN participant in the actual computation of the proposed protocol. However, based on the unpredictability of the output of the hash function and the signature technique applied in the proposal protocol, it is computationally difficult for an attacker to predict which blockchain nodes will be selected as CNs before the proposal protocol is executed. Furthermore, the collusion attack among CNs during the execution of the proposal protocol is based on the security of Algorand [22], the random leader selection technique used for the selection of CN. In other words, if the hash function, signature technique, and Algorand [22] are secure, the probability of success of the attacker’s collusion attack with the blockchain nodes in the proposed model is negligible. ORTHRUS also allows collusion between CNs and DOs and collusion between CNs and DRs.

Case 1. CNi,i∈{1,…,N} and DO colluding in advance.

During the validation of the commit value in the preprocessing phase, it can try to manipulate the validation results of ComED and ComEKi. However, CNi cannot decrypt EKi and ED during the distributed decryption process, so a collusion attack is not possible.

As such, the probability of such a pre-collusion attack succeeding against ORTHRUS is negligible if the applied hash function, signature technique, and random leader selection technique Algorand [22] are secure. ◻

Lemma 3. ORTHRUS assumes that the cryptographic techniques underlying the proposed model are secure, given the assumptions in Section 3.1 and the threat model. Thus, ORTHRUS satisfies fairness even if DO or DR is compromised by a nonadaptive P.P.T. adversary.

Proof. Fairness satisfies both DR fairness and DO fairness. •

DR fairness: DR fairness means that even in the presence of dishonest DOs, honest DRs only pay for validly acquired data. We assume that an attacker can compromise the DOs that provide data to the honest DR and the CNs that help in the computation. The following are scenarios in which an attacker compromises DO or CN. 1.

To disrupt the normal flow of the protocol, an attacker may attempt to corrupt CNi,i∈{1,…,N} to intentionally send dispute resolution requests {FailEDTx}i or {FailEKTx}i. However, SC that receives the dispute resolution request can determine that the dispute resolution request was intentionally sent by CNi by generating and comparing the commit values. Therefore, fairness is ensured by SC penalizing CNi.

As long as the cryptographic primitives applied in the proposed protocol, such as secure hash functions, public key ciphers, etc. cannot be compromised by an attacker, the fairness of the DO is guaranteed.

◻

Lemma 4. ORTHRUS satisfies confidentiality for non-adaptive P.P.T. adversaries based on the assumptions and threat model in Section 3.1.

Proof. The secret key share Ki is stored in IPFS in encrypted form EKi, and the stored location URIEK−Com is included in the transaction and published on the blockchain. An attacker can obtain EKi via URIEK−Com and attempt to decrypt it. However, the attacker does not know the private key of CNi, which is required to decrypt EKi, that is, in order for P.P.T attackers to compromise the confidentiality of D, they must compromise the public-key cryptographic algorithm applied to the proposal model. Therefore, if the cryptographic mechanism applied to the proposal model is secure, the confidentiality of the proposal model is guaranteed. In another case, an adversary can attempt to obtain D by compromising CNi above a threshold. However, since the proposal model inherits the fundamental property of MPC that the presence of malicious participants does not affect the protocol, the attacker cannot obtain D from an honest DO in the proposal model. ◻

Lemma 5. Based on the assumptions and the threat model in Section 3.1, if the proposal protocol operates in the case where ORTHRUS output data is the result of a function computation, the original data provided by DO is not disclosed to any participants, that is, the proposal model guarantees input privacy.

Proof: In the trading process of the proposed protocol when the output data is the result of the function computation, an attacker may try to obtain D, from participants without paying the rightful price. 1.

If the attacker wants to obtain D via ED and EKi,i∈{1,…,N}: The attacker can obtain ED and EKi through URIED−Com and URIEK−Com, but cannot decrypt EKi because he cannot obtain the private key CNi^′ SKCNi, which is needed to decrypt EKi. Even if the adversary wants to compromise CNi to obtain meaningful data, the proposed model inherits the basic characteristics of MPC, making it difficult to compromise CNi above a threshold, so the adversary cannot obtain meaningful data D.

As such, if the cryptographic mechanisms and MPC techniques applied in the proposed model are secure, the likelihood of an attacker compromising input privacy is negligible. ◻

Lemma 6. Based on the assumptions and threat model in Section 3.1, the ORTHRUS satisfies Timeliness if either DO or DR is honest and the SC is secure.

Proof: Timeliness means that an honest component can always reach a point in the protocol where it can stop in a finite amount of time with guaranteed fairness. For a proposal model with an SC and at least one honest participant, the following termination cases exist:

No abort: The proposal model ends when {DFailTx} or {DTrueTx} is received if all parties are honest and the final output of the proposal model is the original data, or when {FfinalTx} is received if the final output of the proposal model is the result of a function computation, or when Tfinish expires. In this case, DO and DR are guaranteed to have obtained what they want, and the proposal model is terminated.

◻

Theorem 1: If the cryptographic primitives underlying ORTHRUS are secure and the blockchain and smart contracts are secure, then ORTHRUS satisfies completeness, resistance to pre-collusion attacks, fairness, confidentiality, input privacy, and timeliness.

Proof: Guaranteed by Lemma 1, 2, 3, 4, 5, and 6. ◻

The ORTHRUS is secure against second-resell attacks. A second reselling attack occurs when a malicious buyer purchases data from the blockchain and then resells the same data for their own profit. If duplicate data are found, the seller is verified to be the owner of the original data and the seller is verified to be the buyer in the previous transaction. If the current seller was the buyer in the previous transaction, the resale transaction can be invalidated. In ORTHRUS, DO^′s activities are recorded on the blockchain using transactions. In addition, commitment techniques, signature techniques, hash functions, etc. are applied to verify the values shared between each participant in the ORTHRUS transaction process. Based on the techniques applied, ORTHRUS prevents secondary resale within the platform. However, it does not prevent the resale of the data in other ways or on other platforms for personal gain.

In this section, we compare three of the existing studies mentioned in Section 1 with the ORTHRUS based on the security analysis criteria.

Li et al. [10] proposed a BSAS to recommend a consensus speed for a group of vehicles based on a blockchain. The BSAS computes a polynomial to obtain the optimal rate, where each user’s secret value is unknown to the others. BSAS randomly selects operators, but it does not guarantee against collusion attacks among other users. Therefore, if collusion among users is successful, the secret value used to compute the polynomial can be known. In other words, if the trustworthiness of the polynomial or the trustworthiness of the computation participants is not guaranteed, the security of the secret value is not guaranteed. Yuan et al. [11] proposed TRUCON, a blockchain-based data sharing mechanism with congestion control in IoV environments. TRUCON has a trust factor and there is no punishment or reward process. In addition, message forwarding is done between vehicles and RSUs, but it does not consider detailed privacy issues and malicious behavior of dishonest participants. Sadiq et al. [12] proposed a vehicle data transaction model based on a consortium blockchain with trusted authorities. It stores unencrypted original data in IPFS and utilizes the same unencrypted original data for data transactions. It does not take into account the existence of dishonest participants, and there is no mechanism for punishment and reward.

In contrast, ORTHRUS is designed on a public blockchain with no trust factor, ensuring full decentralization. In addition, the nodes that participate in the actual computation process are selected using a randomized leader selection technique, making it difficult to predict the probability that a node that has colluded in malicious behavior in advance will participate in the computation process. This prevents collusion attacks. Since ORTHRUS inherits the security of the applied cryptographic techniques, if the final output is the original data, participants other than DR who have paid a reasonable amount of money are not permitted to access D. If the final result is the result of a function computation, then all participants cannot access and obtain the original data D. The ORTHRUS enforces punishments such as deposit forfeiture and reputation score reduction through smart contracts to participants who engage in malicious behavior. Conversely, if the transaction is terminated legitimately, they receive a share of the data payment and incentives, and their reputation score increases. Finally, the ORTHRUS supports both original data and function computation result as final outputs, overcoming the problem of existing vehicle data trading methods that depend on the type and delivery method of final outputs supported by the registered trading platform. The ORTHRUS allows data owners to provide their own data in the type and manner they want. At the same time, when the data transaction process begins, the rights to the data provided by the data owner are not transferred, and the data owner retains control over the original data. In other words, the data owner sets the type of data provision and the transaction method, ensuring data sovereignty. In this way, ORTHRUS, which supports two types of data as the end result and guarantees data sovereignty, presents a revolutionary way to trade vehicle data, enabling users to obtain all desired data types within a single platform, instead of using multiple platforms to obtain the desired data types. Table 1 below shows a comparison of features with existing studies.