Trust Hardware Based Secured Privacy Preserving Computation System for Three-Dimensional Data

Abstract

Three-dimensional (3D) data are easily collected in an unconscious way and are sensitive to lead biological characteristics exposure. Privacy and ownership have become important disputed issues for the 3D data application field. In this paper, we design a privacy-preserving computation system (SPPCS) for sensitive data protection, based on distributed storage, trusted execution environment (TEE) and blockchain technology. The SPPCS separates a storage and analysis calculation from consensus to build a hierarchical computation architecture. Based on a similarity computation of graph structures, the SPPCS finds data requirement matching lists to avoid invalid transactions. With TEE technology, the SPPCS implements a dual hybrid isolation model to restrict access to raw data and obscure the connections among transaction parties. To validate confidential performance, we implement a prototype of SPPCS with Ethereum and Intel Software Guard Extensions (SGX). The evaluation results derived from test datasets show that (1) the enhanced security and increased time consumption (490 ms in this paper) of multiple SGX nodes need to be balanced; (2) for a single SGX node to enhance data security and preserve privacy, an increased time consumption of about 260 ms is acceptable; (3) the transaction relationship cannot be inferred from records on-chain. The proposed SPPCS implements data privacy and security protection with high performance.

1. Introduction

With the rapid development of internet technology, three-dimensional (3D) geometry models of real-world objects have been employed to collect anthropometric data for many application scenarios. 3D model reconstruction has become an important business method for merchants to attract customers [1,2,3,4,5]. Massive 3D data emphasizes challenges around storage, management and computation. In traditional, the related services of 3D data are deployed in high-performance centralized servers [6,7]. However, the trusted third party with a large capacity and powerful computation inevitably inherits the single-point attack problems, which cannot preserve the security and ownership of stored data. Without the data owner’s approval, such attacked data can be applied to proliferate huge commercial profits by unauthorized organizations [8]. Moreover, data owners have no awareness about how important their personal data is. For example, the refined 3D model reconstruction reveals personal information, including sex and appearance [9,10,11,12,13,14,15]. 3D sensitive data confirmation, security and privacy problems have attracted extensive attention. The cryptographic technique is considered as an effective scheme to relieve pressure from the demand of data privacy and security protection in traditional cloud scenes [16,17,18,19,20,21,22,23,24]. However, these methods have poor performance for centralized single point of failures and complex computation.

From the statement above, a distributed, security and privacy-preserving scheme should be designed for 3D sensitive data. A peer-to-peer distributed ledger technology blockchain has caused explosive development to solve the distrust problem in multi-parties [25,26,27,28]. Through a consensus mechanism, blockchain can ensure consistency, immutability and security of on-chain data. However, such technology does not set access barriers for any participating nodes, which inevitably brings privacy leakage problems. Combining the advantages of distributed blockchain and traditional privacy protection mechanisms, many privacy-preserving approaches based on blockchain have been proposed [29,30,31]. These proposals bring much performance loss in massive sensitive data computation, due to slow computing efficiency and expensive blockchain storage. Some blockchain-based methods with access control have been provided [32,33]. Assuming that data owners and users are honest, the blockchain framework with access control can realize data rights, data security and data confidentiality. However, it is impossible to avoid a data proprietary shift from a permitted user to a non-permitted user without the data owner’s consent for authorized users to access the raw data.

As a fully isolated hardware-level approach, trusted execution environment (TEE) technology has been integrated into large-scale usage to ensure the confidentiality of inner applications. The TEE technology makes data computation details invisible to non-secure areas and provides reliable correct execution proof through an inner crypto-mechanism. Compared with homomorphic encryption and zero-knowledge proof, TEE technology achieves similar privacy protection effects but an efficient execution with hardware support. Therefore, the hybrid architecture of TEE and blockchain technology is an effective way to solve the data privacy protection problems, which has been covered by many studies [34,35,36,37,38,39]. Although these methods guarantee that the raw data cannot be directly accessed, personal privacy leakage arises from analyzing the on-chain transaction data. Some research revealed that the real identity of accounts in the blockchain can be inferred by analyzing transaction relationships among different accounts and off-chain auxiliary information [40,41,42]. Once an account in historical transaction records is linked to the real world, all transaction information related to the account will be revealed.

Inspired by the scheme of hybrid architecture of TEE and blockchain, we design a secured privacy-preserving computation system (SPPCS) based on trust hardware. To the best of our knowledge, the SPPCS system is capable of sensitive data and transaction relationship protection. The key to this achievement is the combination of reputation management, decentralized storage system, blockchain technology and TEE mechanism. There are many mature solutions for reputation feedback management, which are not in the main focus of SPPCS system research [43,44]. Reputation feedback management provided by [43] is used in this paper. Along with proof of computation correctness from TEE execution, the fundamental rights of data can be guaranteed.

Thus, the main contributions of this paper are as follows:

• Hierarchical separation computation: The SPPC system adopts a hierarchical architecture: computation off-chain, storage off-chain and consensus on-chain. TEE performs critical data computation and attests to correct and complicated execution off-chain. Distributed data storage, independent from consensus and computation, provides secure and large-capacity storage. On-chain nodes are responsible for maintaining a consistent global state and performing consensus updates efficiently.
• Data leverage scheme: Data expectation matching is realized by similarity computation of registered data text attributes with a graph structure. According to reputation value, the graph structure could be altered. Moreover, the registered costs should affect data provider ranking in a similarity computation list. In this way, the SPPCS voids network resource consumption caused by invalid transactions effectively.
• Dual hybrid isolation model: To obscure the connection between the sender and receiver of a transaction, we design a transaction isolation model based on the TEE leader scheme. The TEE leader completes the transactions with the sender and the receiver asynchronously to cover up the direct relationship, which can avoid privacy exposure issues caused by individual identity disclosure. To prevent access the all the original data, we also construct another hybrid model based on non-accessible attributes of TEE. Data requesters obtain computation results instead of accessing original data to preserve data confidentiality.

The rest of this paper is organized as follows: we present the related work of privacy-preserving management in Section 2. Section 3 introduces the preliminaries throughout this paper. Section 4 details the architecture of SPPCS and specific implementation process. The experimental performance evaluation is conducted in Section 5. Section 6 analyzes the security and privacy of SPPCS proposed in this paper. Conclusions and discussions are presented in Section 7.

2. Related Work

2.1. Privacy with Principles

In the early stage when it was realized that privacy protection is necessary for 3D sensitive data, various rules and constraints imposed by humans have been proposed [45,46]. To alleviate the embarrassment from body data collected with 3D devices, Golden et al. [45] stipulated that 3D data acquisition and analysis should not be performed in the same space. Moreover, 3D data machines cannot store sensitive data to avoid privacy leakage problems. Mironenko et al. [46] described some countries that defined 3D data protection legislation in a formal way, including transparency, individual participation, purpose specification and limitations, minimization, data quality and integrity, security and accountability and auditing. However, these principles were performed through restricting people and should not be considered as a panacea in privacy protection.

2.2. Network Implementation in Privacy Protection

Methods were proposed to mitigate the invasion pressure of 3D sensitive data storage and transformation over a network. Zuo et al. [47] proposed a two-factor secret key protection mechanism combined with attribute-based fine-grained access control to protect the confidentiality of shared sensitive data. Madankar et al. [21] utilized a cryptography method to preserve the privacy of biometric data. Jung et al. [48] designed an accountability model, AccountTrade, to prevent dishonest behavior, such as reselling others’ datasets. Bindahman et al. [9] discussed the privacy problems produced by 3D body scanning technology and described the key points of a privacy-preserving framework. Wang et al. [10] proposed a time machine-like method to relive experiences with virtual reality and protect individual privacy in virtual worlds. Sekhavat et al. [13] utilized augmented reality devices to watch physical wearing with the human alternative mode. Compared with standing in front real cameras, this method can protect human body privacy.

Some filters and deep learning methods have been proposed to protect sensitive data privacy. Without image restoration, Wang et al. [49] proposed a coded aperture camera system with lens-free and a training mechanism to recognize human action in a privacy-preserving way. Sarwar et al. [50] designed an adaptive space exploration to configure the privacy filter automatically, which reduces face resolution to preserve privacy. Chriskos et al. [51] utilized the singular decomposition method and proposed image projection on hypersphere methods to identify the individual rather than accessing the face data for identification. Yu et al. [52] developed a feature-based approach with AlexNet and designed an object-based approach with a deep learning classifier. Through configuring fine-grained settings, the approach could protect data privacy. Li et al. [53] proposed a deep convolutional neural network with k-anonymity, l-diverse and t-closeness to protect face privacy. However, training data become available to be exposed for malicious users who can access these data. Li et al. [12] designed a deep convolution neural network to remove sensitive 3D information and utilized a GAN-based generative adversarial network framework to synthesis models for parameter extraction. Xue et al. [20] presented a privacy-preserving method through which sensitive data can be stored and analyzed on any untrusted device through bloom filters, which could defend the privacy leakage from original data at the storage level. Based on encrypted face features, encrypted machine learning parameters and additive secret sharing secret, Ma et al. [11] proposed a lightweight adaptive boosting face recognition method to protect facial data privacy.

Nevertheless, all the methods mentioned above are based on centralization, which neither solve the problem of privacy leakage caused by a single point of failure nor the data resale and repeated use without the knowledge of the data owner.

2.3. Peer-to-Peer Technology

Kim et al. [54] designed a decentralized data platform for 3D point clouds to share efficiently and securely through a Dat protocol and a discrete global grid system. However, this platform cannot ensure the confidentiality of data use. With peer-to-peer (P2P) technology, 3D sensitive data privacy protection research still needs to be explored in depth. However, there have been many research activities to solve the privacy of sensitive data problem with blockchain in other fields.

Wang et al. [55] proposed a fine-grained access control decentralized storage framework based on blockchain. The security and privacy of stored data are enhanced by a public key encryption mechanism. This general method is not fully suitable in 3D data privacy protection, due to the inevitableness of reselling and accessing original data.

In internet of things (IoT) data security field, Lu et al. [56] proposed a blockchain-based federated learning framework to maintain data privacy. However, the training sets could reveal some original data privacy, which is fatal to 3D sensitive data.

Howard et al. [29] proposed a decentralized computation platform, Enigma, to prevent accessing raw data, based on blockchain technology. Al-Zahrani et al. [8] used blockchain and Data as a Service (DaaS) to construct a privacy-preserving data sharing model, which preserved the data controllability for data owner. Thus, this model cannot guarantee the data traceability and quality estimation for the data user.

For electronic medical data privacy problems, Zheng et al. [57] introduced a wearable healthy data sharing system based on blockchain to enable users to easily control and securely share their sensitive data. Yaji et al. [58] presented MeDShare, a blockchain-based system to provide medical data provenance, auditing and access control on untrusted parties. MeDShare revoked offending entities rights to access data in case of violation activities detected, with minimal risk to privacy exposure. Al Omar et al. [59] proposed a blockchain-based privacy-preserving platform for healthcare data, which leveraged pseudonymity of cryptographic functions to protect sensitive data privacy. These solutions cannot avoid various problems caused by accessing raw data. In addition, when anonymity is no longer secure in the real world, it will lead to identity exposure and pose challenges for privacy protection.

Among digital currencies, Li et al. [30] provided a privacy data storage protocol to preserve identity privacy in blockchain applications, based on the complete anonymity of the ring signature. BlockMaze, proposed by Guan et al. [31], an account-model blockchain that hided the linkage between transaction amounts and the sender–recipient. Along with dual balance model implemented by zk-SNARKs, BlockMaze has strong privacy guarantees. Although these cryptography functions provide users with greater privacy, they are not suitable for massive 3D data with overhead computation.

The idea of combining blockchain and TEE has been focused on the privacy preservation in data computation. Cheng et al. [38] proposed Ekiden, a system combined blockchain with TEE technology to separate the consensus from heavy computation and preserve data confidentiality. Similarly, Zhang et al. [35] leveraged blockchain as information interaction medium on-chain and utilized TEE off-chain computation to design Cerberus, which can guarantee privacy and efficiency of data procession. Dai et al. [34] designed SDTE, a blockchain-based data trading ecosystem to prevent dishonest activities in trading platforms. In SDTE, only analysis results can be obtained and the raw data cannot be accessed. Based on the blockchain and TEE, Wang et al. [36] proposed Hybridchain to improve execution efficiency through decoupling smart contract computation from consensus. A secure key-value memory system has been designed in Hybridchain to mitigate TEE memory limitations. Maddali et al. [37] presented VerBlock, a blockchain-based framework combined with TEE technology, to reduce endorsements in enterprise blockchains. Zhang et al. [39] presented an electronic voting system to protect the privacy of voters and votes based on Ethereum, smart contracts and the TEE environment. These proposals did not notice the identity leakage of the IP address associated with the owner/requester of data, whereas the pitfall should be considered to design 3D privacy protection schemes.

Although blockchain has excellent performance in data security, data auditing and sensitive data privacy protection, some immature defects, such as low scalability, double-spending attack and quantum algorithms in breaking cryptographic cracking, limit the wide application of this technology.

3. Preliminaries

In this section, we briefly discuss the relevant background knowledge throughout this paper.

3.1. Blockchain

As a tamper-resistant distributed ledger technology, the blockchain is linked together through cryptographic hashes as blocks and chains. The block on-chain record batches of valid transactions and processes with an iterative hash value confirmation of the previous block to original genesis block, which defends data modification effectively. In the blockchain system, all members can trust each other in a non-secure environment. The blockchain technology has been applied in decentralized cryptocurrency successfully, such as Bitcoin, Ethereum, Zcash, etc. Moreover, the development of smart contracts over the blockchain, especially Ethereum, contributes to performing trust governance in medical, identity management, asset management, and supply chain fields, etc.

The smart contact is written by Turing-complete programming languages and executed transparently in accordance with the code written on all block nodes. Ethereum supports a stack-based Ethereum Virtual Machine (EVM) to execute smart contacts. A smart contract should be considered as a contact account, which can be executed similarly with users’ send transactions to the normal account. The GAS is introduced to limit the transaction overhead and avoid the infinite loop of smart contract execution.

Asymmetric cryptography, as the cornerstone of blockchain, contains a key pair public/private key. The data are encrypted with a public key and decrypted using a private key. The data signature is signed with a private key and validated by the corresponding public key. The public key is usually shared publicly, whereas the private key is only known to the owner. It is impossible for anyone to infer the private key from the public key and vice versa, which is guaranteed by the security of the encryption algorithm.

3.2. IPFS

An Inter Planetary File System (IPFS), as a decentralized storage structure, is a content-addressed distributed network that stores large amount of data easily without any central coordinators [60]. The file stored in IPFS is recognized with a unique cryptographic hash, which can be identified by version-control history to remove duplication. IPFS facilitates concurrent access to stored data with a high-throughput performance.

3.3. Trust Hardware with SGX

The trust hardware relies on chip isolation to create a trusted execution environment (TEE) to prevent unauthorized access from tampering with or learning the inside state. Software Guard Extensions (SGX) is integrated into CPU architecture designed by Intel and has to be the most prominent TEE technology [61]. SGX preserves the confidentiality, security and integrity of sensitive data operation by creating a secure container enclave. The interfaces of enclaves could be defined at the initialization phase, after which the internal content will not be modified. The access control of SGX is shown in Figure 1.

SGX provides local attestation and remote attestation to help remote entities verify whether the particular code is executed inside the enclave securely and correctly. Local attestation is used by enclave A to prove its identity to enclave B directly, with the same platform key. The enclave uses remote attestation to provide proof to different platform enclaves. At first, the quota enclave encrypts its contents with a hardware-protected enhanced private ID (EPID) key to construct the QUOTE structure, which is attested by remote enclaves on other platforms. Then, the remote enclave verifies the validity of the quote through IAS, which only permits the legitimate entity to issue remote attestation requests. The content received from the remote enclave can be decrypted with a group public key. After checking the validation hash value which summarizes the code and initial data, the validity results will be sent back to the original enclave.

The enclave in SGX uses sealing instructions to store sensitive data outside or read sealed data into secure memory, which greatly reduces the overhead of secure memory. Two sealing strategies have been supported in SGX: sealing data with a platform key permit other enclaves to access data on the same platform; sealing data use a special key that prevents sharing data with other enclaves on the same platform.

3.4. Graph Sturcture

The semantic text clustering methods based on graph structure has been researched and developed in depth for decades [56,62,63,64]. In the graph structure, the weight-graph is considered as the most common way of representing a correlation in text content. A weight context graph $G=\left\{N,E,V\right\}$ consists of N, the set of nodes ($\{n_1,n_2,\dots ,n_m\}$), E, the set of edges ($E\subseteq N\ast N, \left\{e_{12},e_{13},\dots e_{ij},\dots ,e_{mn}\right\}$), and V, the weight adjacency matrix $\left\{v_{e_{12}},v_{e_{13}},\dots v_{e_{ij}},\dots ,v_{e_{mn}}\right\}$. The weight $V_{e_{ij}}$ of the edge denotes the correlation degree between the nodes $n_i$ and $n_j$. If $G^{\prime }=\left\{N^{\prime },E^{\prime },V^{\prime }\right\}$ is the sub-graph of G, denoted as $G^{\prime }\subseteq G$, $G^{\prime }$ meets $N^{\prime }\subseteq N$ and $E^{\prime }\subseteq E{\displaystyle \cap }\left(N\times N^{\prime }\right)$. For graph structure $G_1$, $G_2$ and $G_{*}$, if $G_{*}\subseteq G_1$, $G_{*}\subseteq G_2$, and no any other graph structure $|G_{\ast \ast }\left|>|G_{*}\right|$, the $G_{*}$ should be considered as the maximum common sub-graph between $G_1$ and $G_2$. The maximum common sub-graph contains information of nodes and edges, which can reflect the similarity in different graphs to cluster context categories into different groups.

4. The Proposed SPPCS Overview

In this section, we detail the scheme design of SPPCS. As described in Figure 2, the SPPCS contains five modules: Data Supplier (DP), Data Requester (DR), Ethereum Blockchain (EB), Distributed Storage (DS), and Trusted Computation Pool (TCP). The interaction operations of these modules include registering, requirement matching computation, hybrid transaction execution, data analysis and evaluation feedback in three phases.

Table 1. Abbreviations.

Notation	Description
3D	the three-dimension
TEE	the trusted execution environment
SPPCS	the secured privacy-preserving computation system
SGX	the Software Guard Extensions
P2P	the peer to peer
IPFS	Inter Planetary File System, a decentralized storage structure
IAS	the Intel Attestation Server
PRM	the preserved random memory
EPC	the enclave page cache
EPID	the enhanced private ID
DP	the identity provides some attributes data
DR	the entity requires some attributes data
EB	Ethereum blockchain
DS	distributed storage
TCP	trusted computation pool consists of trusted nodes
TN	trusted node with TEE
CN	consensus node
ECC	the Ellipse Curve Cryptography
CTNP	complex trusted node pool
USN	unique signature notion
SNN	the serial number notation
$dp\_word$	the keyword designated by DP
$Num\_T{N}_{req}$	the required number of TN
$ori\_data$	the DP original data
$loc\_index$	the DP original data storage location index
$Code\_est$	the quality evaluation code of required data
$Code\_comp$	the DR computation code
$Dat{a}_{pre\_est}$	the data matching value pre-estimated from DP
$prc$	the DP register contract
$rdrc$	the DR delegation register contract
$nrc$	the TN register contract
$pimc$	the DP information management contract
$timc$	the TN information management contract
$T_{attri}$	the DP data attribute, such as data type, data amount, unit price…
$T_{req}$	the DR requested data, such as data description, expected size, bid price…
$tran\_num$	the TN leader successful transaction number
$Ptyp{e}_{TN}$	the TN type and TN leader must be complex value
List_TN	the list produced by most selected TNs
Serialized_List_TN	the serialized List_TN
$item\_num$	the number of items in selected transaction list

and

Table 2. Role notation summary.

Notation	Description
$P{k}_{id\_role}$	the public key for $id\_role$, which can be one of DP, DR, TN, TN enclave and CN
$S{k}_{id\_role}$	the private key for $id\_role$, which can be one of DP, DR, TN, TN enclave and CN
$Re{p}_{id\_role}$	the reputation, $id\_role$ can be one of DP, DR and TN
$EPric{e}_{id\_role}$	the expected price for $id\_role$, which can be DP, DR and TN
$K_{id\_role}$	the symmetric key used for $id\_role$, which can be original DP data and DR computation code
$RMResul{t}_{id\_role}$	the requirement matching analysis result for $id\_role$, which can be normal result list and serialized result list
$Stor{e}_{id\_role}$	the storage methods of $id\_role$, which can be seal and unseal

summarize the abbreviations and role notations used in the paper.

4.1. System Framework

The corresponding description of each entity in Figure 2 is shown as follows:

• DP: The unity owns sensitive data. In our system, DP can register data attributes, individual reputation value and expected unit price with the smart contracts.
• DR: The users who require data from DP for their purposes perform three tasks in TCP to preserve data privacy. (1) After DRs broadcast demands on-chain, data matching analysis requirement should be delegated to TCP off-chain. (2) DRs obtain requirement matching list results from TCP and the results verification will be published on-chain. (3) DRs conduct hybrid transaction with DPs through TCP on-chain.
• EB: Consensus nodes of EB are responsible for maintaining the consistency of data transaction records on-chain and validating state updates with the TEE attestation. EB in SPPCS also acts as an interaction medium among DP, DR and TCP.
• DS: IPFS, as a typical representative of DS, provides a safe and large-capacity storage. SPPCS utilizes IPFS to separate storage from consensus and computation. The IPFS receives encrypted data and returns location indexes.
• TCP: Trusted computation nodes, with SGX-enabled CPU and bios, should be considered as the core of TCP. These trusted nodes conduct delegated requirement matching computations, hybrid transactions and data analysis computations with REE and TEE. REE supports interaction interfaces between on-chain and off-chain. TEE guarantees confidentiality in the data process with SGX remote attestation, SGX seal and unseal and cryptographic methods. The delegation request is sent to TCP and the trusted computation node queries related information and executes the corresponding analysis. The trusted computation node securely stores the results outside the enclave with SGX seal, otherwise the reads seal data into the enclave with SGX unseal. Simultaneously, the trusted computation node sends execution results to EB for verification by SGX remote attestation and cryptographic methods. A quorum of trusted computation nodes run a hybrid transaction protocol to complete transactions and obscure the relationship between DR and DP.

4.2. Data Leverage Scheme

DR can verify whether the potential data of DP meets expectations, through delegating a data requirement computation to trusted nodes of TCP. Inspired by [63], we convert data matching analysis to compute the similarity graph structures. We denote the attribute item of required data as text $T=\left\{t_1,t_2,\dots ,t_n\right\}$ and the data attribute of DP nodes registered on-chain as a set of text items $N=\{n_1,n_2,\dots ,n_m\}$, where $t_n$ represents the n index keyword to describe required data and $n_m$ represents the m index data attribute expression of a DP node. The value of $n_m$ is defined as the product of occurrence frequency in T and DP node reputation, calculated as Equation (1):

$$Value(n_m)=\frac{Num\left(n_m\right)}{T_{num}}\ast NR\left(n_m\right),$$

(1)

where $Num\left(n_m\right)$ is the number of $n_m$ occurrences times, $T_{num}$ is the number terms of $T$, $NR\left(n_m\right)$ is the normalized reputation of $n_m$.

The semantic relationship between two nodes of $N$ is represented as $E=\left\{e_{12},e_{13},\dots e_{ij},\dots ,e_{mn}\right\}$, where $e_{ij}$ is the edge of $n_i$ and $n_j$. With the weight value of edges being represented as $V=\left\{v_{e_{12}},v_{e_{13}},\dots ,v_{e_{ij}}\right\}$, the calculation formula is as Equation (2):

$$\{\begin{array}{ll}{v}_{e_{ij}}=\frac{Value\left(n_{i+j}\right)}{Value\left(n_i\right)+Value\left(n_j\right)-Value\left(n_{i+j}\right)},& if i\ne j\\ v_{e_{ij}}=1,& if i=j\end{array},$$

(2)

where $Value\left(n_{i+j}\right)$ is the co-occurrence of $n_i$ and $n_j$ in T.

All DP node attribute descriptions into are represented in the weighted graph $G=\left\{G_1,G_2,\dots ,G_n\right\}$, of which the maximum common sub-graph sets can be constructed. For $G_1$ and $G_2$, the maximum common sub-graph $S{G}_{12}$ consists of all co-occurrence nodes and their similarity nodes, where $v_{e_{ij}}$ exceeds the threshold weight value. The similarity of $G_1$ and $G_2$ can be calculated as Equation (3):

$$Similarity\left(G_1,G_2\right)=\frac{Num\left(S{G}_{12}\right)}{Nu{m}_{max}\left(G_1, G_2\right)},$$

(3)

where $Num\left(S{G}_{12}\right)$ is the number of co-occurrence nodes between $G_1$ and $G_2$, $Nu{m}_{max}\left(G_1, G_2\right)$ is the max number of nodes in $G_1$ and $G_2$.

We extend Equation (3) to obtain all nodes’ similarities in G, denoted as $SG=\left\{S{G}_{12},S{G}_{13},\dots ,S{G}_{ij},\dots ,S{G}_{mn}\right\}$, and leverage the k-means algorithm to cluster DP nodes into different attribute sets. The DR data matching list is composed of DPs above the similarity threshold value.

4.3. Workflow of SPPCS

The workflow of SPPCS is divided into three phases: register phase, requirement matching computation phase, and hybrid transaction execution phase. In this paper, we do not take pitfalls arising from TEE into consideration, since many mitigations have been proposed to protect the security and availability of TEE [65,66]. For simplicity, we implement the credible reputation scheme in [43] and assign tasks to selected trusted nodes.

1.

Register Phase

In SPPCS, the DP, DR and trusted node (TN) should register entity information on EB with a smart contract, respectively. DR data requirement, DP data attribute, DP reputation, DP data quality estimation, TN reputation, TN expected prices and TN type should have been recorded on-chain. The main activities of this phase are initialize attestation, leader selection, attribute and requirement description, data storage and pre-estimation and registration. The registration steps are detailed in Figure 3.

(a)

Initialize attestation: The Ellipse Curve Cryptography (ECC) key pair of the DP, DR, TN, TN enclave and consensus node (CN) are denoted as $<P{k}_{id\_role},S{k}_{id\_role}>$, where $Pk$ is the public key, $Sk$ is the private key and $id\_role$ is one of DP, DR, TN, TN enclave and CN. The TN initializes reputation $Re{p}_{TN}$, node type $Ptyp{e}_{TN}$, enclave public key $P{K}_{Enclave}$ and expected price $EPric{e}_{TN}$. Similarly, the DP initializes reputation $Re{p}_{DP}$ and estimates the quality of own data $Dat{a}_{pre\_est}$.

(b)

Leader selection: $Ptyp{e}_{TN}$ can be set that is normal or complex, with a normal default value. Different $Ptyp{e}_{TN}$ TNs have different $EPric{e}_{TN}$ ranges and only complex $Ptyp{e}_{TN}$ TNs can perform hybrid transactions and run a leader election protocol. Complex $Ptyp{e}_{TN}$ TNs, with much higher upper limit $EPric{e}_{TN}$ values, consist of a complex trusted node pool (CTNP), where the winner in each round of elections updates the leader management smart contract. The term of the leader node is determined by reputation and the successful transactions number. The leader reputation is influenced by DR comments and the successful transaction rate. The number of successful transactions increased by one with a smart contract triggered by the DR validation. The smart contract records the reason for leader re-election, which takes place in these scenarios: ① the number of successful transactions reaches a set value; ② the leader node reputation value is lower than the set value. When DPs notice the leader node is inconsistent with the DR transaction period, DPs can continue transaction for reason ① and reject it for reason ②.

(c)

Attribute and requirement description: DPs extract data characteristics into text-item sets $T_{attri}$, such as data type, data amount, unit price, etc. Moreover, DP creates a unique signature notion (USN), defined as DP signature of the keyword hash value $Si{g}_{S{k}_{DP}}\left(Hash\left(dp\_word\right)\right)$, where the keyword is designated by the DP. DR converts the demand into keyword sets $T_{req}$ including required data description, expected size, bid price, required number of TN $Num\_T{N}_{req}$ and unit delegation fee.

(d)

Data storage and pre-estimation: DP generates a one-time symmetric key $K_{store}$ to encrypt original data $En{c}_{K_{store}}\left(ori\_data\right)$ in each round of transactions. $En{c}_{K_{store}}\left(ori\_data\right)$ should be uploaded to IPFS and DP obtains the corresponding location index $loc\_index$. DR publishes the quality evaluation code $Code\_est$ of required data, based on which all DPs pre-estimate the data matching value $Dat{a}_{pre\_est}$.

(e)

Registration: DR releases the delegation register contract $rdrc$ designed in next Section 4.4 to broadcast $T_{req}$, $Hash\left(Code\_est\right)$ and $Code\_es{t}_{loc\_index}$. DP and TN complete registration by using the corresponding smart contracts. DP registers the contract $prc$ records $T_{attri}$ hash value $Hash(T_{attri})$, USN and $Dat{a}_{pre\_est}$. DP information management contract $pimc$ mainly contains $Re{p}_{DP}$ on-chain. TN register contract $nrc$ includes $P{k}_{enclave}$, $Ptyp{e}_{TN}$, $EPric{e}_{TN}$ and TN leader. $Re{p}_{TN}$ and the transaction number $tran\_num$ are registered in TN information management contract $timc$.

2.

Requirement Matching Phase

As the driver of SPPCS, data requirement contracts of DR are broadcast on-chain. Similar to SDTE [34], appropriate TNs need to be selected to conduct the requirement matching analysis. The main contents of this stage, shown in Figure 4, are as follows:

(a)

Delegation protocol: Corresponding to step 1 to step 4 in Figure 4, the DR broadcast requirement via blockchain starts the process of requirement matching analysis. The TNs first notice the DR demand contract $rdrc$ and establish secure channels to reply to DR with a TN signature $Si{g}_{S{k}_{TN}}\left(Hash(Re{p}_{TN},EPric{e}_{TN}\right),En{c}_{P{k}_{DR}}\left(Re{p}_{TN},EPric{e}_{TN}\right))$ pre-emptively. When DR receives a response node, it conducts an SGX remote attestation to validate TEE platform. Then, the DR verifies the signature of TN $Si{g}_{S{k}_{TN}}\left(Hash(Re{p}_{TN},EPric{e}_{TN}\right), En{c}_{P{k}_{DR}}\left(Re{p}_{TN},EPric{e}_{TN}\right))$ with $P{k}_{TN}$ and decrypts $En{c}_{P{k}_{DR}}\left(Re{p}_{TN},EPric{e}_{TN}\right)$ with $S{k}_{DP}$. Only if $Hash(Re{p}_{TN},EPric{e}_{TN})$ equals $Hash(De{c}_{P{k}_{DR}}(En{c}_{P{k}_{DR}}\left(Re{p}_{TN},EPric{e}_{TN}\right))$ can the node be a candidate. According to a combination strategy of higher $Re{p}_{TN}$ and lower $EPric{e}_{TN}$ with the shortest response time, the DR publishes $Num\_T{N}_{req}$ candidate nodes on-chain and deposits double either of the $Num\_T{N}_{req}$ TNs expected.

(b)

Requirement analysis off-chain: According to the $Num\_T{N}_{req}$ TNs selected by DR, these TNs first run an information synchronization protocol, such as Gossip, to maintain consistency of computation results. Step 5 in Figure 4 presents the potential DP and establishes a secure channel with any one of the selected TNs recorded on-chain to send $T_{attri}$ encrypted with $P{k}_{enclave}$, denoted as $Si{g}_{S{k}_{DP}}(En{c}_{P{k}_{enclave}}\left(T_{attri}\right))$. The selected TNs verify the identity of DP with $P{k}_{DP}$ and then $De{c}_{S{k}_{enclave}}(En{c}_{P{k}_{enclave}}\left(T_{attri}\right))$ to compare the consistency between $Hash(De{c}_{S{k}_{TN}}(En{c}_{P{k}_{encalve}}\left(T_{attri}\right)))$ and $Hash(T_{attri})$ in $prc$. In particular, $De{c}_{S{k}_{enclave}}$ ensure $T_{attri}$ is validated and executed in the TEE environment. If the previous two hashes have same value, TNs share validated $T_{attri}$ in ciphertext and then execute further computations in enclaves with the graph structure $Graph\left(N_{attr{i}_{text}},E_{attri},V_{weight\_attr{i}_{text}}\right)$. It is assumed that the requirement matching analysis result list and corresponding hash value are denoted as $RMResul{t}_{List\_TN}$ and $Hash\left(RMResul{t}_{List\_TN}\right)$. The $RMResul{t}_{List\_TN}$ contains $P{k}_{DP}$, $T_{attri}$, $EPric{e}_{TN}$ and $Re{p}_{TN}$. $Hash\left(RMResul{t}_{List\_TN}\right)$ published on-chain can not only protect the privacy of the requirement matching analysis result, but also makes it tamper-proof and provide verification. The serial number notation (SNN) is utilized to anonymize $P{k}_{DP}$ and is regarded as the representative item of the serialized result list $RMResul{t}_{serialized\_List\_TN}$ corresponding line. The $RMResul{t}_{serialized\_List\_TN}$ contains SNN, $T_{attri}$, $EPric{e}_{TN}$ and $Re{p}_{TN}$ and the hash value, which can be represented as $Hash(RMResul{t}_{serialized\_List\_TN})$. $RMResul{t}_{List\_TN}$, $Hash\left(RMResul{t}_{List\_TN}\right)$, $RMResul{t}_{serialized\_List\_TN}$ and $Hash(RMResul{t}_{serialized\_List\_TN})$ are encrypted with $P{k}_{enclave}$ and stored outside with the seal method. As described in step 6 in Figure 4, TNs send $Hash\left(RMResul{t}_{List\_TN}\right)$ and $Hash(RMResul{t}_{serialized\_List\_TN})$ on-chain. Then, TNs sign encrypted final results with $S{k}_{TN}$ and send $Si{g}_{S{k}_{TN}}\left(En{c}_{P{k}_{DR}}(<Hash(RMResul{t}_{List\_TN}\right),RMResul{t}_{serialized\_List\_TN}>))$ to DR through the OCALL method in step 7 of Figure 4. DRs are unable to obtain the information of DP from $RMResul{t}_{serialized\_List\_TN}$.

(c)

Execution result validation: Corresponding to step 6 in Figure 4, the smart contract recognizes the final computation result with $Num\_max$ of $<Hash(RMResul{t}_{List\_TN}), Hash(RMResul{t}_{serialized\_List\_TN})>$, where $Num\_max$ is the maximum occurrence number and is more than $Num\_T{N}_{req}/2$. When DR receives a response node, it conducts SGX remote attestation to validate the TEE platform, as shown in step 8 of Figure 4. Then, the DR utilizes $P{k}_{TN}$ to check whether $Si{g}_{S{k}_{TN}}\left(En{c}_{P{k}_{DR}}(<Hash(RMResul{t}_{List\_TN}\right),RMResul{t}_{serialized\_List\_TN}>))$ is from published TNs and validates the consistency between received $Hash(RMResul{t}_{List\_TN})$ and $Hash(RMResul{t}_{List\_TN})$ on-chain to ensure no tampering. In step 9 of Figure 4, the DR also considers the maximum occurrence number of $<Hash(RMResul{t}_{List\_TN}), RMResul{t}_{serialized\_List\_TN}>$ as the validation result. When the final computation result is recognized by the smart contract as the same with the DR validation result, the smart contract is triggered to provide TNs with the correct computation and return extra change for DR with the reputation feedback received.

3.

Hybrid Transaction Phase

In this phase, the essence characteristic can be presented as a proxy execution and pre-payment computation, as described in Figure 5. In step 1, DR sends a selected transaction SNN, USN and deposits double the ether of the (DPs + TN leader) expected value via smart contract, according to $RMResul{t}_{serialized\_List\_TN}$ and CTNP leader state registered on-chain. Moreover, DR places hash of computation code $Hash\left(code\_comp\right)$, encrypted code location $En{c}_{P{k}_{enclave}}\left(code\_com{p}_{loc\_index}\right)$, and encrypted symmetric key $En{c}_{P{k}_{enclave}}\left(K_{code\_comp}\right)$ on-chain with a computation contract. Leader REE retrieves information on-chain and utilizes ECALL to send each item, SNN, USN, $Hash\left(code\_comp\right)$, $En{c}_{P{k}_{enclave}}\left(code\_com{p}_{loc\_index}\right)$ and $En{c}_{P{k}_{enclave}}(K_{cod{e}_{comp}})$ into TEE, where the items are packed into an unvalidated transaction list. Step 2 and step 3 present corresponding DPs, which verifies the TN leader from TN register contract and creates a session key to transmit transaction identity proof $En{c}_{P{k}_{enclave}}(Si{g}_{S{k}_{DP}}\left(dp\_word)\right)$ to the leader node. Then, in step 4, the TN leader TEE verifies hash of $dp\_word$ with USN and the validated DP is noticed by the leader REE via the OCALL method. Step 5, the TN leader REE sends $En{c}_{P{k}_{DP}}\left(SNN,USN\right)$ and deposits a double DP expected price on-chain with a smart contract. In step 6, DP sends $En{c}_{P{k}_{enclave}}\left(loc\_index\right)$, $En{c}_{P{k}_{enclave}}\left(K_{store}\right)$, $Hash\left(loc\_index\right)$ and $Hash\left(ori\_data\right)$ on-chain for TN leader verification. Simultaneously, the TN computation contract pays a remuneration for DP. Then, the TN leader selects appropriate DP data for the DR code following these rules: ① One-time execution: the TN leader loads all DP data to conduct a computation and obtain all rewards at once, with all selected DPs responding. ② Multiple execution: According to the number of items in the selected transaction list, $item\_num$ is even or odd, the TN leader could load responding DP data in batches to process with the DR code. If $item\_num$ is even, the TN leader should select an appropriate even number of responding DP data each time, where the appropriate even number is less than $item\_num$. If $item\_num$ is odd, the TN leader first selects a responding DP data number greater than 1 (3, 5, 7…). These principles break the one-to-one transaction relationship, which protects the correlation privacy of transaction parties. From step 7 to step 9, the TN leader pays after the encrypted computation results and the corresponding hash value is published on-chain. The change scheme makes the TN leader give feedback on DP and DR to evaluate the TN leader to obtain an extra deposit.

4.4. Smart Contract and Algorithm Design

In this section, we introduce the smart contract related interfaces and algorithm logic implemented in this paper. The SPPCS contains seven smart contracts—namely, the DR delegation register contract, DR computation contract, TN information management contract, TN register contract, TN computation contract, DP information management contract and DP register contract. Then, as described in Figure 6, we detail the function and composition of these smart contracts.

The DR delegation register contract broadcasts data demands EB, which makes DP and TNs notice data requirement. The pre-deposit interface enables DR deposits to be double the expected ether to pay for selected TNs after data matching analysis. Result analysis management counts the analysis result and sets the highest occurrence result list as the final result. DR registers the contract and publishes selected TN information, stores the data matching list hash value and provides a feedback interface to make reputation comments on the selected TNs. Reward management is used to send appropriate ether to selected TNs’ addresses and return charge to encourage DR to give reputation feedback. The DR delegation register contract also provides an information query interface for DR and TN to retrieve related transaction information.

The DR computation contract broadcasts the selected transaction list on-chain and deposits enough value through the pre-deposit interface. The feedback interface is provided to make reputation comments on the TN leader. The DR computation contract utilizes reward management to pay for the leader and returns change to encourage DR to give reputation feedback. The information query interface is used to check related transaction information.

The TN information management contract stores TNs’ reputation values and leader successful transaction numbers, which are called a DR computation contract and new TN or new leader initialize phase in the TN register contract. The information query interface in this smart contract helps the prospective DP and DR select appropriate TNs according to the contract information.

The TN register contract records TN and leader TN specifications by TN list management and leader list management. The leader TN utilizes the deposit interface to deposit some ether, which is a penalty for a dishonest leader. Leader judgment management counts the negative vote number from TN list and call TN information management contract to clear the reputation value when the count number is greater than two-thirds of TNs.

The TN computation contract will not be detailed for the similar composition and function with the DR computation contract.

The DP information management contract maintains DPs reputation, which is called a TN computation contract and new DP initialize phase in the DP register contract. The information query interface makes TN recommend and select an appropriate DP to execute the transaction.

The DP register contract mainly records data quality pre-estimation value and stores data attribute descriptions. The information query interface is used to check DP data information for verification.

Off-chain computation involves a DR data matching process and results analysis provided by DR. We list the pseudo-code of data matching analysis off-chain computation in Algorithm 1.

Algorithm 1 Data Matching Analysis Algorithm
1	input: encrypted data attribute item, encrypted keyword, DP register contract id
	and DR delegation register contract id
2	output: encrypted data matching list with a correctness proof by TEE
3	begin
4	get selected TN list from blockchain and load into TEE
5	get data requirement demands from blockchain and load into TEE
6	if timestamp < set-time then
7	get data attribute hash from blockchain and load into TEE
8	parse $T_{req}$ as $G1\left(N_{attr{i}_{text}},E_{attri},V_{weight\_attr{i}_{text}}\right)$
9	validate $Hash(De{c}_{S{k}_{enclave}}(En{c}_{P{k}_{enclave}}\left(T_{attri}\right)))$ with data attribute hash
10	if data attribute hash is invalidated then
11	abort
12	else
13	if validated $T_{attri}$ is not new then
14	wait another $T_{attri}$
15	else
16	synchronization encrypted DP data with selected TNs
17	parse $T_{attri}$ as $G2\left(N_{attr{i}_{text}},E_{attri},V_{weight\_attr{i}_{text}}\right)$
18	perform $Similarity\left(G_1,G_2\right)$ calculation and obtain
19	$SG=\left\{S{G}_{12},S{G}_{13},\dots ,S{G}_{ij},\dots ,S{G}_{mn}\right\}$
20	else
21	cluster different attribute sets with k-means
22	send encrypted $<Hash(RMResul{t}_{List\_TN}), RMResul{t}_{serialized\_List\_TN}>$ to DR
23	send $<Hash(RMResul{t}_{List\_TN}), Hash(RMResul{t}_{serialized\_List\_TN})>$ on-chain
24	if contract verify result success then
25	receive payment and reputation comments from blockchain
26	else
27	abort
28	end

5. Implementation and Performance Evaluation

We implemented and tested the SPPCS prototype based on the Ethereum private chain for sensitive data management. In the SPPCS scheme, the main activities are conducted by DRs, DPs and TNs. The DR and DP nodes were run in ThinkPad X1 carbon notebook with I7-10710 CPU and 16 G memory. The TNs and TN leader candidates were executed in 32 G memory Dell 7080-MT that provides SGX support with I7-10700 CPU. The smart contracts were deployed on a test EB private chain and encoded with solidity language. The enclave computation code was written in C/C++. We used ECC asymmetric encryption, AES symmetric encryption and a SHA256 hash algorithm to protect interactive data among DRs, DPs and TNs outside of TEE.

In order to validate and evaluate the performance of SPPCS, we simulated the entire operating mechanism, which should include: (1) data encryption; (2) security attestation; (3) execution privacy; (4) transaction efficiency. Transaction efficiency depends on the consensus performance of Ethereum, which is open to all. The performance of data encryption and security attestation are easily tested by encryption technology and TEE hardware. However, in SPPCS performance section, we mainly focus on execution privacy evaluation. We created twelve enclaves to represent TNs on two machines, with three enclaves from different SGX are TN leader candidates. As in the data description listed in

Table 3. The DR data demand information.

Node Account	Data Demand Description		Delegation Contract Address
DR1:0xDF353A4B5B0FB8F29B33185FF63CE4986F1B6C0F	input:	two-foot cloud data	0x7CE6AF1006F0474FBA430E4B6E9ACE82ACA584AB
	output:	foot length
	expected unit size:	less than 6 MB
	expected resolution:	1 mm depth accuracy
	expected data acquisition:	Intel RealSense
	bid price:	1.87 Milliether
	required TN number:	3
	Delegation fee:	0.37 Milliether
DR2:0x24FFA197D6D002032343C4CE4FA3980DB167C398	input:	face cloud data	0x7CE6AF1006F0474FBA430E4B6E9ACE82ACA584AB
	output:	the distance between eyes
	expected unit size:	less than 10 MB
	expected resolution:	1 mm depth accuracy
	expected data acquisition:	Intel RealSense
	bid price:	0.75 Milliehter
	required TN number:	5
	Delegation fee:	0.1 Milliether

and

Table 4. The DP data attribute information.

Node Account	Data Attribute Description		Attribute Hash
DP1:0X7ECF438AED8B220900F9381FC3D317F26B176684	data:	two-foot cloud data	0XFEA958EF07F41B615C1B36760C4DF9D89CDEA34F27F43CECB8A0F60B4FE3E8DB
	data amount:	10 groups
	unit size:	2 to 5 MB
	unit price:	more than 1.5 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0X7CE6AF1006F0474FBA430E4B6E9ACE82ACA584AB
	hash of USN:	0X5B779E7EF4C7792E484B146CE224415F46727C9EEC21D2132DBFC5F753C44C4B
DP2:0x994CDD94D999F28293412FF9AE1F7BCEE8270BF6	data:	two-foot cloud data	0X32D26333AD8D7A725391DA6B8CCB131B21C856671AE809363D638C89DB73DED4
	data amount:	500 groups
	unit size:	2 to 6 MB
	unit price:	more than 0.2 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0X7CE6AF1006F0474FBA430E4B6E9ACE82ACA584AB
	hash of USN:	0X33FACA8AA322AFD9B47A49AE0BA8C0040AF5C989FA1CB0E4D089A42A376946FF
DP3:0x1B83F6F1EEC42A23CABD86BDC161D980BB425A55	data:	two-foot cloud data	0X0479180CA0C14869E132C0636BA6C874A5EABC7F533F822037FFD19D64F49F1D
	data amount:	1 group
	unit size:	10 MB
	unit price:	1 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0X7CE6AF1006F0474FBA430E4B6E9ACE82ACA584AB
	hash of USN:	0XC54786BCFEAF46FCD9D877DC04D726BC6D16B74BF741D487F9CB41D894DE6949
DP4:0x9E977724A12FAFD04F6190FCD8F9E50F97597128	data:	right foot cloud data	0X936C40C1802E74CE98A9E2CDA2A95F7A0B2358D26389B58B3BCC08CCC5F1070A
	data amount:	10 groups
	unit size:	3 to 5 MB
	unit price:	more than 1.2 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0X7CE6AF1006F0474FBA430E4B6E9ACE82ACA584AB
	hash of USN:	0XC4A47A582969241CBEA4124C3F1B41B987E84F69330F325961B19F1B3930C5B2
DP5:0xADB9A686AC0ED116F4139A71F163F1B67624ALE4	data:	right foot cloud data	0XDC62CB2395A000DE8F299DBF3C498FB792182F5D2B84DD08A8DB1B407EA0A1B6
	data amount:	5 groups
	unit size:	2 to 4 MB
	unit price:	more than 1 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0X7CE6AF1006F0474FBA430E4B6E9ACE82ACA584AB
	hash of USN:	0X66D0FD0872FAD652360A2CC950B3B68D20ED55BA563CF9871882C165F82E7DE8
DP6:0x238E262CE05A87E03CAB1E8CD2A5BFF472ED07CC	data:	face cloud data	0X2CF73EC50C44FEC18230D174CC6FD34BD05FA49A6523F96CE8E98AD7F21170F7
	data amount:	3 groups
	unit size:	2 to 7 MB
	unit price:	more than 0.5 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0xBB04015B84FEDE3F98270054BC21689DCDEF765B
	hash of USN:	0XFAFBE27F3718FA3B86D2390929E2D43973A3074AE9CF460B7BD5615B4A4F9C45
DP7:0x60E7E355A3883971836231436AF9230309FDC3AE	data:	two-foot cloud data	0X348BEFC97E10E337253922446C7CC729965B146E76F54FDE2398AC6E7D95D031
	data amount:	1 group
	unit size:	3 MB
	unit price:	1 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0X7CE6AF1006F0474FBA430E4B6E9ACE82ACA584AB
	hash of USN:	0X5A5C1BB6E46E8F4955DAA41CA4107F49D24111FD3B587C6CF89976E1E0906F96
DP7:0x60E7E355A3883971836231436AF9230309FDC3AE	data:	face cloud data	0X5F814EB245DC90C89C87CF7FA316B9E05879396BF417E3224F4A0E4B92F24BBC
	data amount:	2 groups
	unit size:	5 to 6 MB
	unit price:	more than 0.5 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0xBB04015B84FEDE3F98270054BC21689DCDEF765B
	hash of USN:	0XC43ED4200761EFA120176862DCD9DF4DBD623120C2273DFD758176349215AD2C
DP8:0xDE6372D2572404DB317F43AD49C5997EF46C3AAF	data:	face cloud data	0X7AD3F0B3C9AF4F836571D798CA6EF6A9F403C9B5508C7311369F101E91C4FDBA
	data amount:	10 groups
	unit size:	2 to 5 MB
	unit price:	more than 1 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0xBB04015B84FEDE3F98270054BC21689DCDEF765B
	hash of USN:	0XCCB75618F5EF3CBE5E1B8C3E7504FE4F98F70DBB9CF2050D5034DC8539A2A8EB
DP9:0xEC6E3D1BEB36FFDF6C0180D42EB17BE66EFA0885	data:	two-foot cloud data	0X35EBDD4367911A1DE45B31EF6011D1F3191F1F93B345B299E22EB4DD644FC67C
	data amount:	50 groups
	unit size:	1 to 4 MB
	unit price:	1.5 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0X7CE6AF1006F0474FBA430E4B6E9ACE82ACA584AB
	hash of USN:	0XA6C995A0FB7EF493337042F007255A22C14FC710C63143C81B02C30452406CC9
DP9:0xEC6E3D1BEB36FFDF6C0180D42EB17BE66EFA0885	data:	face cloud data	0X971F95007041CE9D7AF161BD5F917B4BF6EB161A27620C71153D7CA4DA325720
	data amount:	5 groups
	unit size:	3 to 6 MB
	unit price:	0.75 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0xBB04015B84FEDE3F98270054BC21689DCDEF765B
	hash of USN:	0X6A2808BEA0D390E0A755ED9644FD9E998E8CFACE696A02D47B0334FAB94DF84B
DP10:0xF67C41CD59F097C822A1CCFCDFBB61CF6FE28169	data:	face cloud data	0X03E88CF0BFD85868BE4D372CA7930C78DEE5EBAB3C8015FD0E44DE0DB1143D1B
	data amount:	8 groups
	unit size:	2 to 6 MB
	unit price:	more than 0.8 Milliether
	data resolution:	1 mm depth accuracy
	data acquisition:	Intel RealSense
	responding:	0xBB04015B84FEDE3F98270054BC21689DCDEF765B
	hash of USN:	0XA5F7F7DB06D75B3DE2FB61B3247AE748BAB88636A11DCED38A2D4877A3F019BA

, two DR (labeled as DR1 and DR2) nodes were set to publish demands and ten DP (labeled as DP1, DP2, …, DP10) nodes were assigned to supply data.

With the command line tool, we can view DP register contract. As shown in Figure 7, the data attributes were recorded as a <DP account: data attribute hash>. The cryptographic functions ensure the confidentiality of DP data attributes and provide a validated method.

5.1. SGX Execution Performance Evaluation

In the data requirement matching phase, the execution time performance is mainly affected by the number of SGX nodes. More SGX nodes need longer synchronization time to obtain a data matching list. For the same DR1 request, seven potential DPs were interested in providing data. Without consideration of time consumption in DP identity validation, we performed a data matching computation 500 times with different numbers of TNs and recorded the result acquisition time in Figure 8.

From Figure 8, we can conclude that when the number of TNs increases from 1 to 3 and then to 5, the time difference is basically maintained at about 310 ms. However, when the number of TN increases to 7 and 9, the time difference increases by about 490 ms. The reason for this is that we simulated five enclaves as TNs on the same machine and four extra enclaves as TNs on another machine during this experiment. Whether the TN number is 1, 3 and 5, the time difference mainly exists in SGX operations with the same machine. The increased time difference of 7 and 9 TNs is probability consumed in a network link transmission. We believe that when the SPPCS is running, the time consumption for data matching computation of every additional TN should be increased by more than 490 ms, and the reliability of computation has been improved. Therefore, DR needs to balance the system computation performance with the result list safety when setting the required TN number.

The time-consuming hybrid computation is decided by data transfer capacity, calculation size and SGX operations. In the same network environment and computing platform, fewer data should definitely allow for data transmission and calculation to be carried out more quickly. Then, in the same network environment and TN Leader, we mainly tested the time overhead of SGX operations. For the foot point cloud data of A about 4 MB (selected from DP1), B about 2 MB (selected from DP2), C about 4 MB (selected from DP7) and D about 5 MB (selected from DP9), we separately executed the same foot analysis algorithm 1000 times in the same hardware machine with SGX enabled/disenabled and recorded the corresponding average consumption times in Figure 9.

Whether in TEE or an ordinary execution environment, the calculation time becomes longer as the data capacity increases. However, the time-consuming difference with different execution environments subtly increased by about 260 ms, which is mainly produced by SGX operations: load encrypted data from untrusted space and output encrypted results from a trusted region. The time consumption cost of SGX security guarantee is acceptable.

5.2. Transaction Execution Privacy Evaluation

In SPPCS, DRs and DPs complete data transactions with the TN leader. The multiple DPs and DRs could, respectively, trade with the leader node at the same time, and the corresponding transaction records are shown in Figure 10. DR1 and DR2 deploy computation contracts correspondingly to selected data matching lists on-chain and deposit double the expected value of the TN leader and DPs, as recorded in blocks 157 and 160 of Figure 10a. In this test, the selected data matching list of DR1 contains DP1, DP2, DP7 and DP9. DR2 selects DP6, DP7 and DP9 as appropriate traders. The TN leader validates identity authentication information from multiple responding DPs (DP1, DP7 and DP6) and obtains original DP data whilst paying a remuneration. Although DP7 provides both DR1 and DR2 demand data at the same time, DP1 and DP7 follow the even-numbered list transaction rules, whereas DP6 and DP7 do not meet the odd-numbered list transaction rules. As presented in Figure 10b, according to the data selection rules described in in hybrid transaction phase, TN leader prioritizes DP1 and DP7 to perform calculation analysis for DR1. Then, the TN leader continues to validate DPs until the data transaction with DP6 and DP9 is complete through the smart contract. As DP6, DP7 and DP9 are in line with the odd-numbered list transaction rules, the TN leader selects DP6 and DP9 for DR2 computation at one time. After the TN leader validates the last DP2 and acquires corresponding data, DP2 is selected to complete the DR1 computation. Block 166, block 175, block 176, block 194 and block 204 in Figure 10c record DPs sending data to the TN leader in detail. Figure 10d records transactions between the TN leader and DRs (DR1 and DR2). The TN leader returns computation results to DRs (DR1 and DR2) and is paid by calling the corresponding contract.

From transaction process recorded in Figure 10, there is no correspondence between DP data and the TN leader computation data. The transaction relationship between DRs and DPs cannot be inferred directly. Even if a DP leaks private information in the real world, it is impossible to infer more information with records on-chain. Compared with general blockchain-based transaction systems, and although the extra cost is mainly focused to invoke smart contracts for data demand matching computation and TN leader status maintenance, the transaction privacy is highly guaranteed. Moreover, our SPPCS reduces the consensus burden by transferring complex computation off-chain to maintain a high performance.

6. Security and Privacy Analysis

The SPPCS, proposed in this paper, combines EB, smart contract technology, IPFS and TEE mechanism to guarantee data confidentiality. In this section, we analyze the security and privacy of this scheme from denial of service (DoS) attack, malicious fraud attack and data exposure.

6.1. DoS Resistance

TEE nodes are vulnerable to DoS attack by DRs and may repeatedly broadcast computation tasks without any following operations or DPs could continuously deliver data to waste network resources. Moreover, DR and DP nodes also deal with the problem of network bandwidth waste caused by deliberately frequently invoking smart contracts. The SPPCS sets some rules against these problems: additional certain fee to be paid for invoking a smart contract, maximum number limitation of matching authentication and restrictions on remote attestation range.

6.2. Malicious Fraud Resistance

In the register phase, attackers could intercept requests to prevent DRs, DPs and TNs from completing registration. As a random event, participants complete registration by releasing or invoking smart contracts according to their wishes. Unless an interception attack is launched against a specific node, there is a very small probability that attackers block the legal request to prevent registration. Network attacks on specific targets can be prevented by adopting some network security strategies. In the computation and transaction phases, dishonest attacks may occur in DRs, DPs and TNs. The DR intentionally refuses to recognize TN calculation results and avoids paying TNs. The DP sends redundant invalid raw data to TN for extra remuneration. The TN fraud has two main purposes: provide dishonest analysis results to defraud rewards and maliciously steal or leak the original DP data. Moreover, collusion attacks are carried out between any two roles of the DR, DP and TN to obtain more rewards or utilize computing resources for free. The SPPCS mitigates dishonest attacks through combing the reputation feedback mechanism with a smart contract. In the data attribute matching phase, the DR needs a pre-deposit value and the final calculation result is decided by a delegation register contract, which avoids DR refuse to pay and obtains the wrong results. The TN with inconsistent calculation results should receive low reputation comments from smart contract, which greatly reduces the probability of the TN being selected again. In the computation phase, the TN validates whether original data hash is in line with the value registered on-chain, which refuses DP supply inappropriate data. Additionally, the encrypted original data are pulled into the TEE enclave, which prohibits data processions to be accessed and guarantees that the computation results cannot be tampered with. The change mechanism encourages DR to objectively evaluate TN, and TN to honestly evaluate DP. Furthermore, the pre-deposit broke DRs conduct the collusion attack and the reputation scheme effectively resists the collusion attack between DR and TN.

6.3. Confidentiality and Consistency

In SPPCS, various encryption and signature technologies are utilized to resist crack ciphertext during transmission. Blockchain consensus technology ensures the consistency of data status. In particular, TEE guarantees that the original data, process data and intermediate operations are inaccessible, which fundamentally maintains data confidentiality and privacy. Moreover, combined with TEE and blockchain, the dual hybrid transaction model is designed to isolate potential inferred connections between transaction parties. The transactions between DPs and DRs are completed through the TN leader. After obtaining the data matching list, the DR publishes selected transaction items, DPs provide corresponding encrypted original data to the TN leader and the blockchain maintains DR/DP transaction records with the TN leader simultaneously. As the TN leader receives multiple DR transaction entries during the term, the association between DRs and DPs is impossible to infer, which enhances the privacy and security of the SPPCS system.

7. Conclusions and Future Work

At present, unconscious sensitive data (such as 3D data) usage in a confidentiality-preserving and benefit-reserved manner is still a challenge. In this paper, the SPPCS is proposed, a trust hardware-based blockchain system to enhance privacy protection during sensitive data flow processes. The SPPCS decouples analysis computation and storage from consensus to achieve hierarchical separation computation. With a graph structure, the data leverage scheme of SPPCS performs a similarity computation of data expectation description and data provider description. The registered reputation value and costs on-chain are adopted by SPPCS as an important indicator to adjust similarity computation results and influence the final data requirement matching list. Specifically, the difference between the selected matching data quality evaluation and registered quality pre-estimation should affect the data provider reputation. According to the reputation value, the SPPCS prevents dishonest participants and reduces invalid data transactions effectively. Moreover, with the TEE security guarantee, the SPPCS designs a dual hybrid isolation model to set restrictions on accessing raw data and transaction parties’ relationships. The analysis and experiments conducted on the Ethereum private chain and SGX demonstrates that (1) the SPPCS needs to consider the balance of enhanced security and more than 490 ms time consumption produced by two more TNs, whilst multiple TNs perform privacy computations; (2) the SPPCS can support execution security and privacy preservation with about extra 260 ms time consumption for SGX operations; (3) the SPPCS confuses the transaction direction between participants and prevents privacy disclosure of transaction relationship from on-chain records.

In the current SPPCS, we do not solve the problem of computation overhead increased by large-capacity data exceeding the enclave memory limit. Moreover, the threshold for TN leader candidates is difficulty, which needs to deposit a large value as a commitment. Future research should focus on two aspects: (1) a security memory expansion scheme should be designed to improve the applicability of SPPCS; (2) the TN leader operating mechanism should be optimized to attract more participants.