EBSS: A secure blockchain-based sharing scheme for real estate financial credentials

Abstract

With the development of Internet finance, the real estate financial credentials have been extensively utilized in capital and trading markets. The extensive use of these private credentials, e.g., exchange, circulation or sharing on public clouds, can cause severe security and privacy problems. Existing security solutions for financial credentials may either introduce undesired overhead or fail to provide traceability and anonymity for data sharing. In this paper, we propose an enhanced blockchain-based secure sharing scheme for real estate financial credentials, providing the following three properties: credential confidentiality, anonymous authentication, identity tracking and transaction auditing. A comprehensive evaluation, including security analysis, efficiency analysis and simulation evaluation, is presented to show the security and feasibility of the proposed scheme.

1 Introduction

Real estate is regarded as a primary economic asset of human society [1]. Real estate financial credentials have been extensively used in domains such as capital market supervision, modern urban management, financial risk prevention, and so on [1, 2]. Since they involve the vital interests of the public, the management and utilization of real estate financial credentials have attracted close attention in recent years. With the development of Internet finance, it is necessary to establish standardized and unified real estate credential sharing mechanisms. Such a mechanism can not only improve the benefits of utilizing resources and assets, but also better protect the legal property interests of rights holders [3, 4].

However, from privacy and security perspectives, the sharing of financial credentials can raise critical issues [5, 6]. Some malicious behaviors are threatening the security of real estate financial credentials, such as theft, tampering, and forgery. Moreover, real estate financial credentials information, e.g., property information, rights status, and transaction records, is highly privacy and security sensitive. Without proper protection, serious security problems may occur.

Although the real estate financial credential is very security sensitive, most of current work on credential security has neglected to protect it efficiently. With respect to credential sharing, centralized storage architectures are widely adopted, and much of such work [7,8,9,10] focuses on data confidentiality and identity anonymity. Such an architecture, as widely known, leads to some prominent problems [11]. For example, ideally holders should be in charge of these credentials, but in most cases holders have to rely on third parties, such as banks or agents, to store, verify and validate their own credentials. On the other hand, some recent studies [5, 12, 13] have taken the secure credential sharing into consideration with the help of blockchain techniques. However, due to their public-transparent nature, such studies do not provide properties regarding circulation controllability and privacy-preserving.

To address above concerns, in this paper, we proposed an enhanced blockchain-based secure sharing scheme EBSS, particularly for real estate financial credentials. The main work and contributions of this paper include the following three aspects:

• (1) Our proposed scheme can provide confidentiality of real estate credentials. In this paper, we adopt hierarchical encryption and access control approaches, which together enable credential confidentiality storage and distinct privileges management. The protection of shared credentials, thus enhancing the confidentiality and integrity of credentials, is one of the key feature that distinguishes our design from others.

• (2) Our proposed scheme can achieve anonymous authentication. Authentication and commitment are the essential protection mechanisms for various security properties, i.e., integrity, authenticity, non-repudiation, and perfect hiding. Considering the strong requirements of identity privacy and transaction secrecy in blockchain financial services [14], anonymity is another essential security property that should be provided. In this paper, we adopt a combined group signature-based and commitment-based scheme to achieve anonymous authentication.

• (3) Our proposed scheme can support identity tracking and transaction auditing. To realize secure sharing of real estate finance credentials, it is desirable for users to ensure the authenticity and verifiability of credential content. We adopt a distributed ledger mechanism to record the origin of the credentials, as well as all variations during their storage and transmission processes. As evidence for tracking and auditing, these records are used in the consensus mechanism to improve auditing efficiency.

A comprehensive evaluation of the proposed scheme is provided. We first analyze the security of our design and then evaluate the simulation performance of the system implementation. Two general-purpose virtual simulators, i.e., Hyper ledger fabric and IPFS [15], are used in this work. We also compare our work with other related studies [16,17,18,19]. These evaluations show the effectiveness and feasibility of the proposed scheme. In addition, our scheme can be applied to many secure sharing scenarios, e.g., tickets management, accountability credentials, and private medical records.

The rest of this paper is outlined as follows. Related work is shown in Section 2. Section 3 briefly introduces security goals and threats, cryptographic tools, and the system model. Section 4 gives the detailed description of the proposed scheme. The security and performance evaluations are presented in Sections 5 and 6, respectively. The remaining issues and future work on the scheme are discussed in Section 7. Section 8 concludes this paper.

2 Related work

The security of real estate financial credentials has been a hot topic in recent years. Mani et al. [20] gave a comprehensive introduction on the security threats, awareness and risk management criteria for the existing security threats to real estate registration data. Kyle et al. [7] presented a physical network layout for preventing unauthorized access to real estate registration data. Deepa et al. [21] analyzed the potential threats to real estate registration information, especially for data storage and transmission. Kalia et al. [10] proposed a hybrid model of two-phase encoding with additive random noise value, which can protect private and sensitive information from leakage. Raymond et al. [22] proposed a threat assessment model, based on protective motive theory (PMT), for real estate information.

In terms of blockchain data sharing and protection, Liu et al. [23] proposed a blockchain-based and cloud-based traffic data sharing protocol, which can provide the security properties of anonymity and traceability. Li et al. [24] proposed a trusted big data sharing model based on blockchain and smart contracts. It can ensure the secure circulation of data resources. Several blockchain-based application schemes have been proposed, including data sharing model [25], real estate tokenization [26], and secure real estate transactions [5], respectively. None of such solutions provide traceability and anonymity of shared data, making it possible for attackers to compromise users’ privacy. Nyaletey et al. [15] proposed the BlockIPFS system for evidence collection and trusted data traceability. But this work does not consider the anonymity of user identity. Zhang et al. [27] proposed a group signature and authentication scheme for blockchain-based mobile-edge computing. This scheme is able to verify the validity of the block and provide anonymity for both parties in a transaction. Since signatures and verifications cannot be performed independently in the blockchain, it is generally not appropriate for the case of changing group membership. Hong et al. [16] proposed a blockchain-based scheme for secure and accountable data transmission. This scheme is difficult to resist typical attacks such as impersonation attacks, man-in-the-middle attacks, and replay attacks. Fan et al. [19] proposed an improved ID-based signature authentication and blockchain-based secure data transmission scheme, which can provide the properties of authenticity, integrality and confidentiality of information; however, this scheme does not take user privacy protection into consideration and the user’s identity may be compromised.

To ensure entity authenticity during communication, many related solutions have been proposed in recent years. Harbi et al. [17] proposed an ECC-based enhanced authentication scheme, which can resist known security attacks, e.g., replay attack, denial-of-service attack, and impersonation attack. Jia et al. [18] presented a three-way authentication key protocol based on bilinear pairing. This protocol only requires one round communication to achieve mutual authentication and key agreement, while enabling user anonymity and untraceability. Chen et al. [28] proposed a threshold anonymous authentication (TAA) scheme in which users can obtain anonymous certificates without revealing private information. TAA is adopted in our paper for anonymous authentication.

Inspired by the previous work [15, 27], we proposed a blockchain-based secure sharing scheme for real estate credentials, integrating techniques such as blockchain, IPFS, and group signature. Moreover, our proposed scheme can provide the following advanced security properties, such as tamper-resistance of real estate credentials, traceability of credential circulation, and anonymity of user identities.

3 Preliminaries

3.1 Security goals and threats

In this section, we briefly introduce the potential threats and security goals, on which we focus.

1) Potential Threats: The threats to real estate financial credential sharing involve multiple aspects, e.g., caused by external or internal attacks. Our scheme design focuses on the following four aspects.

• Credential forging/cheating: Attackers may either send fake credentials for malicious purposes, or may use fake identities to send malicious information, e.g., sharing phishing links or spreading fake credentials.

• Credential modification/replacing: Attackers may modify, corrupt, or replace legitimate credentials, causing users to be misled or sharing to be invalid.

• Credential plagiarizing: Attackers may plagiarize other users’ credentials or related private data. Such behaviors may compromise the confidentiality of these credentials or private data.

• Correlation analysis: Attackers may not know the true content of credentials. But they can obtain other related sensitive information by analyzing such credentials or private data, e.g., the user’s location, the number of communications, or the length of the credential.

2) Security Goals: In this work, we consider the natural security features of blockchain and achieve the following security goals.

• Authentication: Before the system provides the service, the user’s identity must be verified and authorized by a CA. Authentication can also be implemented between different users.

• Data tamper resistance: The system or user should be able to detect the modification or corruption of credentials. It may be caused by intentional or accidental factors during the credential transmission process.

• Data confidentiality: The secret data can only be revealed to authorized individuals, institutions or systems within a specific verification scenario.

• Non-repudiation: Any user cannot deny their past behaviors, such as signing, uploading or accessing credentials.

• Anonymity: During any information exchange process, a user’s true identity should not be revealed so as to avoid illegal exploitation or impersonation.

• Traceability: All important information related to credentials should be traceable, e.g., data sources or historical operations. This means that the system should keep records of alterations and circulation.

3.2 Cryptographic tools

Cryptographic tools are the fundamental building blocks for security scheme designs. Here, we briefly introduce the cryptographic tools used in our scheme.

1) Blockchain: A blockchain is essentially a distributed ledger database for recording transactions. The ledger in a blockchain is maintained by all network nodes together. It is a transparent and irreversible process to set up the ledger. The format of transactions recorded in the blockchain can be customized as required. In this paper, we use the distributed ledger to record the transactions between the network participants. Such network participants can update the records in the ledger according to the consensus mechanism. The transaction information to be recorded is defined as TB, including the file level f_level, file authenticity f_auc, block number BN, file serial number f_SN. Based on smart contracts in the blockchain, some predefined rules and terms can be automatically executed [29]. Without the participation of a third party, smart contracts can also support trusted transactions. Thus, such transactions are traceable and irreversible.

Blockchain applications are usually divided into three categories [30], including public blockchain, private blockchain, and consortium blockchain. A consortium-based blockchain is adopted by our scheme. Each node of such a consortium blockchain is usually affiliated with a specific entity or organization, such as banks, core companies, suppliers, regulators, and so on. Only authorized users can join this blockchain. In this paper, the consortium blockchain is used to verify the legitimacy of transactions and to record historical data. It also provides features for security auditing and authority confirmation.

2) Interplanetary File System (IPFS): IPFS is a flexible peer-to-peer file system [31] that facilitates the storage and sharing of large files. It supports content addressing, allowing users to quickly access and verify data. An independent hash value Content-ID (CID) is generated based on the file content to identify the file, so only one file with the same content exists in the system and thus storage space is significantly reduced.

Since the blockchain is initially designed as a public ledger for recording transactions, most of the existing blockchain systems are more appropriate to the smaller transaction sizes for ensuring network performance. Therefore, it is either infeasible or expensive to store big files directly in a blockchain system. To address this issue, in this paper, we combine IPFS with blockchain to effectively alleviate the performance bottleneck of big file storage. Specifically, big files uploaded by users will be stored in IPFS, while their file addresses are reserved in the blockchain. Users can retrieve the corresponding files from IPFS according to the reserved addresses.

3) Group Signature: The group signature scheme can provide anonymous authentication for group members [32]. Different from other anonymity techniques, group signatures can relieve the burdens, e.g., distribution and verification of public key certificates. In particular, as an identity verification scheme, group signatures can also provide the security properties of message integrity and non-repudiation. A general group signature algorithm involves the following five steps: (1) Setup: After inputting the system parameters k, the group manager generates the group public key pk_GM and his own private key sk_GM. (2) Join: The group manager issues a group membership certificate Cert for the new user. (3) Sign: For a given message m, the user generates an anonymous signature σ_m using his own certificate Cert_i and private key $sk_{u_{i}}$. (4) Verify: The verifier can use the group public key pk_GM to verify the signature σ_m. Such signature is acceptable if σ_m is a group signature on message m generated by a legitimate group member. (5) Open: The group manager can perform the Open algorithm to trace group signature σ_m.

In this paper, we adopt an effective group signature scheme as our anonymous authentication. It is a bilinear-map-based threshold anonymous announcement scheme TAA [28]. In terms of implementation features, it is essentially a group signature scheme, which can provide properties such as non-repudiation, anonymity, distinguishability and auditability. Such a scheme can achieve a better balance between hardware and software performance, thereby being adopted by Trusted Computing Group. In this paper, we tailor TAA specifically for blockchain services. Each legitimate user can obtain a valid identity credential through the Setup and Join algorithms. Anonymous signatures and message verification can be provided with the Sign and Verify algorithms.

4) Commitment: A commitment scheme is a two-party interactive protocol between a committer C and a receiver R. It consists of two main phases, i.e., the commitment phase and the open phase. In the commitment phase, the committer C sends a commitment comm with a secret message m to R. The commitment comm to m is generated with a parameter open and computation comm = Com(m,open). With regard to the open phase, the committer C sends the original message m with the parameter open to R. Then R can verify that the committed message in comm is indeed m. A commitment scheme usually has two essential properties, i.e., hiding and binding.

In this paper, a Pedersen commitment scheme [33] is adopted, which is based on the discrete logarithm problem (DLP). In the Pedersen commitment, the parameter open is set to $y \in \mathbb {Z}_{q}$. The commitment for message m can be defined as comm = Com(m,y) = g^mh^y, where g and h are security parameters. The receiver R can recompute $comm^{\prime }$ with m, y and check whether $comm^{\prime }$ is equal to received comm. The Pedersen commitment scheme has perfect hiding and computational binding properties. The commitment comm does not reveal any information about the message m. The success probability of any malicious committer finding another message with the same commitment is negligible. The receiver can be sure that m is the only message corresponding to the commitment.

3.3 Scheme model

The system model considered in this paper consists of three entities, as shown in Figure 1.

Figure 1

System model

• Certificate Authority (CA): CA is in charge of the registration of servers and users, generating public security parameters, distributing keys and issuing anonymous certificates, and tracing transaction disputes, and so on. In this model, CA also serves as a group manager of group signatures and is trusted by other entities.

• Server: The server mainly provides request verification, file uploading and downloading, and data storage services. There are two types of trusted servers involved in our model, i.e., IPFS server and blockchain server. IPFS server is in charge of storing copy credentials and providing file indexing; blockchain server is able to verify requests and perform requested operations, e.g., file uploading, updating, and accessing. To facilitate later retrieval, tracks of such file operations will be recorded by the blockchain server.

• Client: Each client or user has a unique identity authenticated by CA. Clients can invoke requests to the server for services. Such requests have to be verified before responding. In this model, the client may be a malicious entity and may launch an active attack on the real estate credentials.

4 Scheme design

In this section, we provide a detailed design of EBSS. In this scheme, security mechanisms, such as anonymous authentication, hierarchical encryption, access control, and IPFS with blockchain, are integrated with the blockchain to ensure the security of real estate credential storage and sharing. Any data transmission between the user and the server follows the protocol flow shown in Figure 2. There are four main algorithms involved in data transmission: Request Generation (Algorithm 3), Hierarchical Encryption (Algorithm 4), Transaction Submission (Algorithm 5), and Access Control (Algorithm 6).

Figure 2

Protocol flow

Anonymous authentication is mainly provided in Sign and Verify algorithms, i.e., Algorithms 1 and 2, respectively. For security concerns, each message has to be signed by the sender before being sent. The server will automatically drop messages that fail to be verified. To achieve confidentiality of data transmission, the commitment and hierarchical encryption techniques are embedded in Algorithm 3. In addition, distributed ledger and consensus mechanisms are adopted to perform identity traceability and data auditability, i.e., Algorithm 7. The properties of signature, commitment verification and identity tracking are also provided by Algorithm 7.

4.1 Protocol setup

The notations of our scheme are listed in Table 1. The specific cryptographic setup based on finite fields is as follows. First, three cyclic groups $\mathbb {G}_{1}$, $\mathbb {G}_{2}$ and $\mathbb {G}_{T}$ are chosen, all of which have sufficiently large prime order q. Two random generators $\mathbb {G}_{1}=\langle P_{1}\rangle$ and $\mathbb {G}_{2}=\langle P_{2}\rangle$ are selected along with a pairing $\hat {e}:\mathbb {G}_{1} \times \mathbb {G}_{2} \to \mathbb {G}_{T}$. The pairing $\hat {e}$ is a map from $\mathbb {G}_{1} \times \mathbb {G}_{2}$ to $\mathbb {G}_{T}$, which is bilinear, nondegenerate, and computable [34]. Two hash functions, i.e., $H_{1}: \{0,1\}^{*} \to \mathbb {Z}_{q}$ and $H_{2}:\{0,1\}^{*} \to \mathbb {G}_{1}$, are chosen to map an arbitrary-length binary string to an integer and a $\mathbb {G}_{1}$ element, respectively.

Table 1 Notations

Second, CA issues a certificate for each user to ensure valid authentication. CA holds a secret key (x,y) and a public key (X,Y ), where $x, y \leftarrow \mathbb {Z}_{q}, X=x \cdot P_{2} \in \mathbb {G}_{2},Y=y \cdot P_{2} \in \mathbb {G}_{2}$. The certificate (A,B,C) is a triplet and is constructed with the true identity $\lambda \in \mathbb {Z}_{q}$ of the user and the secret key (x,y) of CA. To be specific, $A \leftarrow \gamma \cdot P_{1}, B \leftarrow y \cdot A$, and $C \leftarrow (x \cdot A + \lambda xy \cdot A)$, where γ is a random number chosen from $\mathbb {Z}_{q}$. Therefore, such a certificate is unique for a specific user and is anonymous for other users.

Third, we adopt the Role-Based Access Control (RBAC) model and the “principle of least privilege” to achieve system access control and resource secure sharing [35]. Therefore, during user registration and file storage processes, the trusted server will construct a User-Role-Privilege (URP) table, so as to form a one-to-many mapping between user level u_level, file level f_level, and hierarchical key level k_level. To facilitate fine-grained management, the server keeps this URP table and assigns corresponding hierarchical keys by file level f_level; and restricts access to files depending on user level u_level. Furthermore, such access control can keep consistency among user level u_level, file level f_level and key level k_level.

4.2 Signing and verification

A group signature scheme is used to achieve anonymous authentication. All messages, both incoming and outgoing, need to be authenticated. It means that every sent message should be signed first, while every received message has to verify the signature first. In this paper, we deploy a group signature scheme similar to TAA [28].

Algorithm 1 signs on the message and generates a signature σ. In this algorithm, the triplet (R,S,T) is an anonymous certificate generated by shuffling (A,B,C). On the basis of anonymous certificates, each message is signed. The calculation of δ, s, 𝜃 and t provide the correlation credential between the anonymous certificate and the user’s true identity λ. They are based on bilinear pairing and modulo algebra, respectively. To resist the replay attack, a timestamp n_T is embedded in the message signature σ. During the signature and verification process, there are two versions of Sign and Verify algorithms, respectively. Version 1 is for normal usage, and Version 2 focuses on applications with high security requirements, where an enhanced security signature can be realized with the help of M, N and ν.

Algorithm 1

Sign.

Algorithm 2

Verify.

The verification of the signature is described in Algorithm 2. First, the validity of the timestamp n_T in the signature σ is verified, and such a check can help determine whether σ has been replayed. The integrity of the message is also provided by checking whether α≠H₂(u_level) and β≠H₂(msg), so that any corruption of the message can be detected. Then, a comparison of $\hat {e}(R,Y)$ and $\hat {e}(S,P_{2})$ is performed so as to check the internal relationship of R, S and Y, i.e., S = a ⋅ B = ay ⋅ A = y ⋅ R. Thus, $\hat {e}(R,Y)=\hat {e}(A,P_{2})^{ay} \equiv \hat {e}(S,P_{2})$. If the signature σ and the message msg are successfully transmitted without any corruption, τ should be equivalent to $\tau ^{\prime }$ and $\nu ^{\prime }$ should also be equivalent to ν. The correctness is as follows: $\tau ^{\prime }=(\rho _{b})^{s} \cdot (\rho _{c} / \rho _{a})^{-\delta }=\hat {e}(S,X)^{s} \cdot \hat {e}(T,P_{2})^{-\delta } \cdot \hat {e}(R,X)^{\delta }=\hat {e}(S,X)^{z} \equiv \tau$. Similarly, the equivalence of $\nu ^{\prime }$ and ν can be verified in this way. Furthermore, if msg, u_level and σ are also successfully transmitted, the correctness of δ and 𝜃 can be verified, as shown in line 7 and 12.

4.3 Secure transmission

The data transmission procedure is shown in Figure 2. Before data transmission, the user first generates a request message, i.e., rq in Algorithm 3, asking the server for a specific secure transmission. In case of an Upload request or an Update request, the server will perform a hierarchical encryption in Algorithm 4 to provide data confidentiality. These encrypted data will be stored in IPFS and their operation tracks are recorded on the blockchain, as shown in Algorithm 5, so that the server can implement related security audits and data traceability later. If it is an Access request, the server will execute the Access Control algorithm, as shown in Algorithm 6, to make a decision whether or not the protected data can be accessed. For different transmission requests, the receivers should verify their validity and each transmitted file should be encrypted, thereby ensuring confidentiality and integrity for the following data transmissions.

1) Secure request: Request generation procedure is shown in Algorithm 3. Such a request provides two main security properties: secure commitment and message confidentiality. Com(h_f,d) denotes a commitment transformation for the file hash h_f, where d is a random parameter and comm is a commitment. Similarly, Com(h_T,d) refers to a commitment transformation of the transaction hash h_T. To preserve confidentiality, the protected data, e.g., the file f, the transaction hash h_T, and the parameter d, should be encrypted using the public key pk_ser to generate the ciphertext ct, i.e., lines 4, 7, and 10. For three specific requests, the algorithm generates one corresponding message msg, i.e., lines 5, 8, and 11, respectively. These messages consist of different elements, including ciphertext ct, file level f_level, transaction hash h_T, and commitment comm. Finally, the message msg, user level u_level, and signature σ are sent back to the user as a request, i.e., lines 13-14.

Algorithm 3

Request generation.

2) Hierarchical encryption: Upon receiving an Upload or Update request, the server performs the hierarchical encryption algorithm as a response, i.e., Algorithm 4. Such hierarchical encryption mainly provides confidentiality for file storage. The algorithm, based on the received message msg, first derives the ciphertext ct, which can be decrypted to obtain the plaintext f, i.e., line 5. Then, the server makes a decision with respect to the request. For the Upload request, the server selects the corresponding hierarchical key key, i.e., line 7, which is consistent with the requested file level rq.f_level; however, for an Update request, the server, along with the transaction hash rq.h_T, retrieves the transaction record TR, and finds the appropriate hierarchical key key, i.e., line 9-10. Such a key level k_level depends on the file level f_level in TR. It should be noted that a query function Query is adopted to achieve information retrieval, i.e., line 9, particularly for file updating, access control and data tracking. For the purpose of ensuring data confidentiality, the algorithm encrypts the protected file f using the selected key, i.e., lines 12-13, so that a new ciphertext $\tilde {ct}$ is generated and stored in the server. In addition, TR retrieved by the Query(h_T) function refers to a transaction record on the blockchain. To be specific, a TR at least consists of transaction hash h_T, file level f_level, block number BN, file authenticity f_auc, file serial number f_SN, and so on. f_SN is generated by the server. Each file has a unique f_SN, even if it is a different version of this file.

Algorithm 4

Hierarchical encryption.

3) Transaction information integrity: To ensure that $\tilde {ct}$ is not tampered with, the transaction information has to be stored in the blockchain, e.g., the file storage address CID, the signature σ, and the commitment comm. Such transaction information provides proof for later retrieval and verification of $\tilde {ct}$. Algorithm 5 shows the process of transaction submission. Such an algorithm mainly keeps the traceability and integrity of the transaction information. The server needs to create an object TB for each transaction, which is used to integrate the transaction information. Typically, a TB contains elements such as file level f_level, file authenticity f_auc, block number BN, and file serial number f_SN. The information integration process in the algorithm is shown in lines 3-7. Here, blockchain.BN means the block number BN, which is obtained by calling the inline function of the blockchain. After the transaction information is integrated, the server submits the transaction object TB to the blockchain and generates the corresponding transaction hash h_T by blockchain.hash(TB), i.e., line 7. Once verified and validated by the consensus mechanism, such a transaction will be permanently recorded in the blockchain, i.e., line 8.

Algorithm 5

Transaction submission.

4) Access privilege verification: To achieve effective access control and data sharing, the server performs the Access Control algorithm, i.e., Algorithm 6, when receiving an Access request. With the basis of h_T, the algorithm first invokes the Query function to derive f_level and f_auc, i.e., line 5. Then, relying on the anonymous certificate contained in the user signature σ, the algorithm invokes Query(rq.σ.T) to find the user level u_level, i.e., line 6. Next, the server makes an access control decision by comparing u_level with f_level. If u_level is less than f_level, it means that the user does not have enough privileges to access the file; otherwise, the access is permissible. The server will extract the ciphertext $\tilde {ct}$ from IPFS and decrypt it into plaintext f, i.e., lines 8-11. To check if the file f has been tampered or corrupted, the server will generate a new commitment $comm^{\prime }$ by computing Com(h_f,f_auc.d). If $comm^{\prime }$ is equal to the verified f_auc.comm, it means that f is the correct one. Finally, the server will send the corresponding file f and signature σ to the user, i.e., line 15.

Algorithm 6

Access control.

4.4 Traceability and auditability

For preserving anonymity concerns, it is not desired to track the true identity of the signer from the signature. Moreover, the tracking and auditing features are not necessary for legitimate users, signatures and commitments. In particular, our scheme introduces specialized security mechanisms, e.g., anonymous authentication, hierarchical encryption, security commitment, and access control, which can provide sufficient security. However, the abilities of tracking and auditing by CA will still be reserved for effective management purposes. Algorithm 7 describes the tracking and auditing processes, involving three different functions: Identity tracking, Signature verification and Commitment verification. Note that the transaction record TR, request rq and signature σ are reserved information in the distributed ledger. For the case of identity tracking, since the CA knows the true identity λ and the secret key x of each user, it can verify the user’s certificate by matching the internal relationship of (R, T, S), i.e., σ.T = a ⋅ x ⋅ σ.A + a ⋅ λxy ⋅ σ.A = x ⋅ σ.R + x ⋅ λ ⋅ σ.S

For the Signature verification process, a new signature σ^‡ can be generated based on the reserved request message (rq.msg^‡). Then, CA is able to compare σ^‡ with rq.σ^‡ and $TR.f^{\dag }_{auc}. \sigma$ to verify the correctness of the signature, i.e., lines 11-13. Once the Commitment verification function is executed, both a new f^‡ and d^‡ can be obtained by decrypting the previous request ciphertext (rq.ct^‡). Then a new commitment comm^‡ can be generated with such $h_{f}^{\dag }$ and d^‡, thus enabling the auditing of the commitment, i.e. lines 18-21. As long as the commitment $TR.f^{\dag }_{auc}.comm$ stored by the server has not been tampered with or corrupted, it should hold that comm^‡ is equivalent to $TR.f^{\dag }_{auc}.comm$.

Algorithm 7

Tracking and auditing.

5 Security analysis

In this section, we analyze the security of the proposed scheme in five aspects, with emphasis on the main security features involved in the algorithm implementation.

5.1 Security of the signature

The security of the signature in this scheme is guaranteed by the hardness of the bilinear LRSW assumption [36]. Suppose that the Setup(1^k) algorithm produces the three cyclic groups $\mathbb {G}_{1}$, $\mathbb {G}_{2}$ and $\mathbb {G}_{T}$, where two generators are P₁ and P₂, the order is q, and k is a security parameter. There exist $X, Y\in \mathbb {G}_{2}$, X = x ⋅ P₂, and Y = y ⋅ P₂. Let $\mathcal {O}_{X,Y}(\cdot )$ be an oracle with $\gamma , \lambda \in \mathbb {Z}_{q}$ as input and a triplet (A,B,C) as output, where $A \leftarrow \gamma \cdot P_{1}, B \leftarrow y \cdot A$, and $C \leftarrow (x \cdot A + \lambda xy \cdot A)$. For a probabilistic polynomial time (p.p.t.) adversary $\mathcal {A}$, it is impossible to construct the triplet (A,B,C) without knowing the secret key (x,y). v(k) is a negligible function for all $\mathcal {A}$, defined as follows:

$$\begin{aligned} &Pr[(\mathbb{G}_{1}, \mathbb{G}_{2}, P_{1},P_{2}, q, \hat{e}) \leftarrow Setup(1^{k});\;x \leftarrow \mathbb{Z}_{q}; y \leftarrow \mathbb{Z}_{q};\\ &X=x\cdot P_{2}; Y=y\cdot P_{2}; (\lambda, A, B, C) \leftarrow \mathcal{A}^{\mathcal{O}_{X,Y}}(\mathbb{G}_{1}, \mathbb{G}_{2}, P_{1},P_{2}, q, \hat{e}):\\ &f\in \mathbb{Z}_{q} \wedge A \in \mathbb{G}_{1} \wedge B = y \cdot A\wedge C = (x \cdot A + \lambda xy \cdot A)]\leq v(k). \end{aligned}$$

(1)

This means that given the system public parameters $(\mathbb {G}_{1}, \mathbb {G}_{2}, P_{1},P_{2}, q, \hat {e})$ and public key (X,Y ), it is impossible for an adversary $\mathcal {A}$ to construct a triplet (A,B,C) without knowing the secret key (x,y), the random number γ, and the secret true identity λ. Only the CA with the secret key (x,y) can construct a valid certificate for the user, which can guarantee the effectiveness of our authentication scheme. Moreover, with regard to the Sign algorithm, signature σ is constructed with the secret parameters a, z and r, the secret identity λ, and the shuffled credential (R,S,T) where R = a ⋅ A, S = a ⋅ B, and T = a ⋅ C. Any adversary cannot generate a valid anonymous signature σ without knowing (A,B,C) and λ [28]. Thus, the signed message cannot be forged or modified during the transmission processes, which can provide non-repudiation, authenticity, and integrity of the sent messages.

5.2 Security of identity anonymity

In our scheme, the anonymity of user identity involves four aspects: first, the true identity of the user λ and the secret key (x,y) of CA are encapsulated in the triplet credential (A,B,C), i.e., $C \leftarrow (x \cdot A + \lambda xy \cdot A)$. With the hardness of the bilinear LRSW assumption [37] mentioned above, it is impossible for a p.p.t adversary $\mathcal {A}$ to extract λ from C without knowing the private key (x,y). Second, the true identity λ is encapsulated into the credential computation of K, s and t. Due to the hardness of the discrete logarithm problem (DLP) [38], it is obvious that extracting the true identity λ from K, s and t is not possible. Third, since there is no isomorphism between $\mathbb {G}_{1}$ and $\mathbb {G}_{2}$ in the asymmetric pairing setting, it is not feasible to link (R,S,T) with the (A,B,C) without knowing the secret parameter a [39]. This also provides anonymity of the user identity. Finally, the true identity of the user λ is independent of the transaction information TR recorded in the blockchain. Hence, no one except the CA can trace the true identity of the signer, and the anonymity of the user’s identity can be effectively guaranteed.

5.3 Security of transaction records

As described in the hierarchical encryption Algorithm 4, two primitives h_T and f_auc are included in a transaction record of the blockchain, where h_T is a transaction hash and f_auc is a file authenticity label. h_T changes with each record. In general, the security of a hash function depends on three underlying properties, i. e., collision resistance, preimage resistance, and second preimage resistance. In our scheme, we adopt SHA-2 algorithm, which works on the Merkle-Damgåd structure and whose soundness has been proved [40, 41]. On the other hand, there are two primitives, signature σ and commitment comm, for constructing f_auc. As mentioned earlier, the security of the signature σ depends on the hardness of the bilinear LRSW assumption [38]. Any authorized user can access the file f and compute the commitment $comm^{\prime }=Com(h_{f},d)$, so as to verify the integrity of f. We adopt a Pedersen commitment scheme [33], which can provide the Perfect Hiding Property. It is computationally infeasible for any p.p.t adversary $\mathcal {A}$ to extract h_f from the commitment comm without knowing the random number d. To be specific, assuming that an attacker has the ability to tamper with the commitment comm, there exists different $d^{\prime }$ and $f^{\prime }$ such that $g^{f^{\prime }} h^{d^{\prime }} \equiv g^{f} h^{d} (\mod p)$, where p and q are security parameters. For the attacker, it is equivalent to solving the discrete logarithmic difficulty problem [42]. Therefore, the assumption that the attacker can successfully tamper with the commitment is invalid.

5.4 Security of access control

We adopt access control technique to make decisions based on user level u_level. Due to the consistency between user level u_level, file level f_level and key level k_level, for an authorized user, the corresponding key level is used to decrypt the file f, i.e. $f\leftarrow Dec(key,\tilde {ct})$. Note that in EBSS only a trusted server holds the hierarchical symmetric encryption key key. Additionally, the cryptographic strength of hierarchical symmetric encryption depends on the properties of the underlying symmetric encryption scheme. In this paper, we use the AES algorithm, which is well-known as a standard for symmetric data encryption [43]. Much studies [44, 45] have proven the practical security of AES, e.g., resistance to brute force attacks, differential attacks, and square attacks. Therefore, the confidentiality of the access data can be provided.

Moreover, the computational constraint property of Pedersen commitment relies on the discrete logarithm assumption (DLA) [46]: $Pr[g^{m_{1}}h^{r_{1}}$ modq]-$Pr[g^{m_{2}}h^{r_{2}}$ modq]| = 0, where g, h are generators of the group $\mathbb {G}_{q}$, q is a large prime, $m_{1}, m_{2}, r_{1}, r_{2} \in \mathbb {Z}_{q}$, and r₁,r₂ follow normal distribution. It means that, for any m₁≠m₂, there exists an r₁≠r₂ such that Com(m₁,r₁) = comm = Com(m₂,r₂). In other words, such Pedersen commitment is computationally binding [47] since the committer is unable to open a commitment to m₁ as m₁ = m₂, unless the Discrete Logarithm Problem (DLP) can be solved. In EBSS, this assumption guarantees that any adversary can only tamper with the commitment comm with negligible probability. In other words, on the basis of Pedersen commitment, it is infeasible for any two different files f and $f^{\prime }$ to generate the same commitment value comm. Thus, the authenticity of the accessed data can be guaranteed in our scheme.

5.5 Security of confidential transmission

The data data is encrypted with CA’s asymmetric key pk_ser before transmission, i.e., $ct=E_{pk_{ser}} (data \parallel d)$, where data may be a file f or a transaction hash h_T. In this scheme, we use the ElGamal encryption algorithm. The security of ElGamal encryption is guaranteed by the hardness of the Decisional Diffie-Hellman (DDH) Assumption [48]: Let $\mathbb {G}_{1}$, $\mathbb {G}_{2}$ and $\mathbb {G}_{T}$ be cyclic groups, q be a large prime order, P₁ and P₂ be two generators, and $\hat {e}:\mathbb {G}_{1} \times \mathbb {G}_{2} \to \mathbb {G}_{T}$ be a pairing. Let $X, Y, Z\in \mathbb {G}_{1}$, X = x ⋅ P₁, Y = y ⋅ P₁, and Z = z ⋅ P₁, where x,y,z are randomly and independently chosen from $\mathbb {Z}_{q}$. Then given the group parameters $(\mathbb {G}_{1}, \mathbb {G}_{2}, P_{1},P_{2}, q, \hat {e})$, for any probabilistic-polynomial time (p.p.t) algorithm $\mathcal {G}$, the advantage $\mathbf {Adv}_{\mathcal {A},\mathbb {G}_{1}}^{DDH}$ defined as follows is negligible:

$$\begin{aligned} \mathbf{Adv}_{\mathcal{A},\mathbb{G}_{1}}^{DDH}=&\vert Pr[x, y, z\leftarrow \mathbb{Z}_{q};\;X=x \cdot P_{1}, Y=y \cdot P_{1}, Z=z \cdot P_{1};\;\mathcal{G}(\mathbb{G}_{1},\mathbb{G}_{2}, \\ & P_{1},P_{2}, X, Y, Z, q)=1]- Pr[x, y\leftarrow \mathbb{Z}_{q}; X=x \cdot P_{1}, Y=y \cdot P_{1}, \\ & Z=xy \cdot P_{1}; \mathcal{G}(\mathbb{G}_{1},\mathbb{G}_{2}, P_{1},P_{2}, X, Y, Z, q)=1] \vert. \end{aligned}$$

(2)

Furthermore, both < X = x ⋅ P₁,Y = y ⋅ P₁,Z = xy ⋅ P₁ > and < X = x ⋅ P₁,Y = y ⋅ P₁,Z = z ⋅ P₁ > are computationally indistinguishable. It is equivalent to the semantic security in ElGamal encryption [39].

The Perfect Hiding Property is provided by the Pedersen commitment. It has been proved that, for any value r, the commitment is uniformly distributed and the parameters are chosen randomly and uniformly [42], i.e., |Pr[Com(m₁,r)] − Pr[Com(m₂,r)]| = 0, where Com(m₁,r), $Com(m_{2}, r)\in \mathbb {G}_{q}$, $m_{1}, m_{2}, r \in \mathbb {Z}_{q}$, and r follows the uniform distribution. In our scheme, the perfect hiding property guarantees that any adversary in the communication can only obtain data from rq with a negligible probability. Thus, in our scheme, comm can perfectly hide all the information about the data, including the file hash h_f and the transaction hash h_T. Thus, the confidential transmission of messages is provided in our scheme.

5.6 Security properties analysis

The security properties provided by EBSS are summarized in Table 2. Note that Encryption refers specifically to the hierarchical encryption and asymmetric encryption during the request process.

Table 2 Description of security properties

In the proposed scheme, Signature ensures that the signer cannot deny the signed data and other users can verify the correctness of the signature. The signature is accomplished by anonymous certificates and only CA can trace the true identity of the certificate. It further provides anonymity and traceability of user identity during system services. The proposed Commitment mechanism is perfect hiding and computationally binding, which can provide five security features for the transaction process, including confidentiality, integrity, verifiability, traceability, and resistance to collusion attacks. Encryption can ensure confidentiality and integrity during data transmission and storage. Moreover, the timestamp contained in the signature can prevent the transaction information from being replayed.

6 Performance evaluation

In this section, we evaluate the performance of the proposed scheme, which involves four aspects, i.e., computation overhead, communication overhead, simulation evaluation, and comparison with related schemes. We apply the proposed algorithms in simulations with real blockchain settings, where we show the feasibility and effectiveness of our scheme. All experiments are conducted on Ubuntu 18.04 LTS, with 2.8 GHz Intel i5 − 8400 CPU, 16 GB memory and 256 GB SSD.

6.1 Computation overhead

In our scheme, the introduced computation overhead is mainly related to two procedures, such as signing and verification and request generation.

For the signing and verification procedure, since all messages need to be signed before sending and verified after receiving, such a procedure will introduce some additional computational overhead. We use the existing implementation results in [49] as an evaluation reference, the operations with higher computation cost are the scalar multiplication in $\mathbb {G}_{1}$, the exponential operation in $\mathbb {G}_{T}$, and the pairing operation, respectively. In contrast, both the hash and arithmetic operations in $\mathbb {Z}_{q}$ introduce very little overhead. Owing to the bilinear property of the mapping $\hat {e}$, some exponential operations in $\mathbb {G}_{T}$ can be transformed into scalar multiplications in $\mathbb {G}_{1}$ for faster computation. On the basis of these preparations, the computation overheads of signing and verification are as follows: Sign v1, $7 \cdot \mathbb {G}_{1}+1 \cdot P$; Sign v2, $11 \cdot \mathbb {G}_{1}+2 \cdot P$; Verify v1, $4 \cdot \mathbb {G}_{1}+3 \cdot P$; Verify v2, $8 \cdot \mathbb {G}_{1}+6 \cdot P$. Here, $\cdot \mathbb {G}_{1}$ refers to a scalar multiplication on $\mathbb {G}_{1}$ and ⋅ P refers to a pairing operation. We evaluate these operations with the implementation results from [19]. On average, a scalar multiplication on $\mathbb {G}_{1}$ takes 2.165 ms while a bilinear pairing operation takes 5.427 ms. Hence, the computational overheads for signing and verifying are 20.582 ms (Sign v1), 34.669 ms (Sign v2), 24.941 ms (Verify v1), and 49.882 ms (Verify v2), respectively.

During the request generation procedure, i.e., Algorithm 3, the user needs to commit and encrypt the file f, as well as h_T. Compared to other operations, both the encryption and decryption operations take less time and thus are negligible [49]. The commitment computation may introduce some extra overhead. However, since such a commitment can be precalculated, it will not introduce extra computation overhead in practice. A commitment in this scheme involves two main computation overheads: the modular exponentiation M_e and the modular multiplication M_m. With the implementation results in [19], the module exponentiation operation takes approximately 0.339 ms and the modular multiplication operation takes approximately 0.001 ms. Therefore, the computational overhead required for a commitment operation is 2 ⋅ M_e + 1 ⋅ M_m, which is 0.697 ms.

6.2 Communication overhead

In our scheme, the communication overhead introduced is mainly related to two procedures: authentication and request generation. We set an element length in $\mathbb {G}_{1}$ to be 1024 bits, i.e., $\vert \mathbb {G}_{1}\vert$= 1024 bits; an element length in $\mathbb {G}_{2}$ to be 2048 bits, i.e., $\vert \mathbb {G}_{2}\vert$= 2048 bits; and an element length in $\mathbb {Z}_{q}$ to be 160 bits, i.e., $\vert \mathbb {Z}_{q}\vert$= 160 bits. The timestamp n_T is 32 bits in length, i.e., |n_T|= 32 bits. Since the signature is included in each message, the communication overhead of authentication is determined by the signature size. Specifically, the communication overhead introduced is approximately $6\vert \mathbb {G}_{1}\vert +2\vert \mathbb {Z}_{q}\vert +\vert n_{T}\vert$= 6.496 Kb for version 1 and $7\vert \mathbb {G}_{1}\vert +4\vert \mathbb {Z}_{q}\vert +\vert n_{T}\vert$= 7.840 Kb for version 2.

Each user request contains a signature. The communication overhead of the signature is given as in version 1 or in version 2 above. Besides the signature, there are also an asymmetrically encrypted ciphertext ct, a commitment comm, a file level f_level or a transaction hash h_T to be transmitted during such request procedure. In particular, the length of the asymmetric encrypted ciphertext ct depends on the data size that the user needs to upload. It is indispensable for every blockchain scheme. For example, such data size may be measured in Kb, Mb, or Gb in real applications. Thus, it is reasonable that such communication overhead is ignored in this scheme. A commitment comm in $\mathbb {Z}_{q}$ is 160 bits long, i.e., |comm|= 160 bits; a file level f_level or a transaction hash h_T, $f_{level}, h_{T} \in \mathbb {Z}_{q}$, is 160 bits long, i.e., |f_level|= 160 bits at most or |h_T|= 160 bits. We take these overheads into consideration, and the maximum communication overhead introduced is approximately 6.816 Kb for version 1 and 8.160 Kb for version 2.

6.3 Simulation evaluation

For a non-saturated network, since the introduced extra overheads are relatively small, it is hard to detect the performance impact of the proposed scheme. To better understand the impact of the security scheme, we measure the overall communication impact by increasing the data upload and download capacity, along with and without the security overhead for both versions. We use an abstract scenario to simulate the secure authentication process, with higher message generation counts and more intensive signing and verification. Such a simulation is only intended to help us better understand the impact of the security scheme under extreme conditions.

Our simulation is conducted on a common and open source blockchain simulator, i.e., Hyper ledger fabric 1.4.4 and IPFS 0.4.19 [15]. Such network simulation deployment can support image credentials storage and integrity verification without uploading all data to the blockchain. Our simulation dataset comes from “Zillow” [50], which is a public dataset on real estate transactions.

The simulation is conducted on five file sizes, as well as with and without the security scheme deployed, to measure the communication overheads for uploading and downloading, as shown in Figure 3. We set the file size to vary between 1 MB, 10 MB, 100 MB, 1 GB, and 10 GB, with 256 KB as the transmitted block size. Figure 3 shows that the uploading and downloading time improves with increasing data size. It is mainly caused by factors such as the increase of the block counts and security authentication. Since IPFS uses a decentralized storage mechanism, the larger the file, the more the file blocks will be, and the longer the time required to compute the CIDs. In terms of file uploading time, both EBSS v1 and EBSS v2 schemes are higher than a single IPFS configuration. This is caused by the fact that our EBSS scheme introduces extra communication overhead, involving signing, verification, encryption, and transaction submission. One communication overload introduced by EBSS v1 is 6.816 Kb in size and by EBSS v2 is 8.160 Kb in size. The increased communication overload depends on the number of blocked file. However, these security features introduced have only a small impact. For example, the file uploading time difference, between a single IPFS and EBSS v1, is only roughly 3.0 ms to 12.0 ms, and the difference with EBSS v2 is nearly 6.0 ms to 13.0 ms. In addition, as can be seen in the Figure 3, since the file retrieval only requires a block lookup in the IPFS by CID, the downloading time for each file is less than the corresponding file uploading time. EBSS access increases the commitment verification overhead only about 2.0 ms, so the file downloading time differs slightly from that of a single IPFS. Therefore, the security properties provided in this paper do not incur expensive communication and transmission overheads.

Figure 3

Communication overhead comparison

To measure the storage throughput for EBSS with different numbers of consortium chain nodes, we perform a simulation based on different number of data upload requests. We set the number of nodes to be 4, 8, 12, 16, 20, and 24, and the number of data upload requests to be 100, 500, 1, 000, 2, 000, 5, 000, and 10, 000, respectively. The simulation is conducted based on the EBSS v1 scheme, and the results are shown in Figure 4. Since the communication overhead introduced by the EBSS v2 scheme is slightly higher than that of the EBSS v1 scheme, the throughput of the EBSS v2 scheme is bound to be lower than that of the EBSS v1 scheme. In general, the throughput variation trends of EBSS v2 and EBSS v1 are consistent. As seen from Figure 4, when the number of nodes is 4 and the number of requests is between 100 and 500, the system throughput increases rapidly. In contrast, when the number of requests exceeds 5,000, the throughput fluctuates around 359 transactions per second. This means that the server performance reaches a bottleneck in this interval. For the case of 4 nodes, the upload throughput is up to 359 transactions per second. It should be noted that the transaction processing efficiency of EBSS v1 is negatively correlated to the number of nodes. In case of 24 nodes, the maximum upload efficiency of EBSS v1 is 203 transactions per second, which is 43.45% lower than that of 4 nodes. It is due to the fact that the data written to the blockchain requires all nodes to update the records in the ledger according to the consensus mechanism. As the number of nodes increases, the information exchange between nodes becomes frequent and the time consumption for validating block transactions increases accordingly. Therefore, the more the number of nodes in the consortium chain, the lower the transaction efficiency and throughput will be.

Figure 4

Storage efficiency with different number of nodes

6.4 Comparison with related works

We compare EBSS with four recently proposed schemes [16,17,18,19]. All of the schemes focus on satisfying the security services for the blockchain system, including authentication, integrity and provable security. Considering the differences in implementation details and actual deployment, we mainly compare their computational overhead and communication overhead during the authentication process. The detailed computation overhead is compared in Table 3. Schemes [16, 19] use hash-to-point calculation, denoted by H₂, each of them will introduce a computation overhead with 5.493 ms. As shown in Table 3, the computational overhead in EBSS under version 1 is significantly lower than that of the schemes [16, 17, 19], and only slightly higher than that of [18]. In our scheme, anonymous authentication does not require the two parties to interact to calculate and verify the identity information multiple times, but only performs one signature-verification process on the information to complete the authentication. Therefore, the anonymous authentication proposed in this paper is efficient, and it can ensure that the user’s identity privacy is not leaked. In fact, the computational overhead of our version 2 is the highest in all schemes. Since version 2 is an enhanced security scheme, it inevitably introduces some extra overhead. In our scheme, M_e and M_m refer to the communication overhead introduced by the commitment process, which can be avoided by pre-computation.

Table 3 Computation overhead comparison

Table 4 shows the detailed computational overheads for these five schemes. It should be noted that an asymmetric ciphertext denoted by |ct_asy| is 800 bits; a symmetric ciphertext denoted by |ct_sy| is 128 bits; and the user identity λ is 32 bits [19]. The communication overheads shown in schemes [16,17,18,19] are 7.552 Kb, 5472 Kb, 7360 Kb and 4480 Kb, respectively. It can be seen from Table 4, the communication cost of our scheme under version 1 is significantly lower than the scheme of [16, 18], and only slightly higher than the scheme of [17, 19]. Since version 2 is an enhanced security version, the communication cost of our scheme is the highest among all schemes. Even though the communication overheads are roughly similar for all five schemes, pursuing more security properties, e.g., identity anonymity, perfect hiding, tracking and auditing, hierarchical privilege management, are the key features that distinguish our scheme from others.

Table 4 Communication overhead comparison

7 Further discussions and future work

As mentioned above, EBSS shows some desirable security properties, including confidentiality, anonymity, identity tracking, and so on. For further improvements, there are some issues worth exploring.

First, one possible concern is about reducing the workload on the server, e.g., during the signing and verification, secure transmission, traceability and auditability processes. In our current solution, some specific mechanisms such as anonymous authentication, commitment, and access control are deployed, which inevitably introduce additional server workloads. If considering minimizing these workloads, our proposed scheme can be further optimized. There are two versions of the signature algorithm in this scheme. If only the signature algorithm of EBSS v1 is considered, it will significantly reduce the computational load during the signing and verification process. For example, the calculations of M,N,ν,t and 𝜃 in the signature algorithm can be omitted; meanwhile, the calculations of $\nu ^{\prime },N^{\prime }$ and the verification of 𝜃 in the verification algorithm also can be omitted. Such optimizations do not change the existing security properties in EBSS. In addition, other possible improvement approach is to use periodic tracking and auditing, or to adopt lightweight hash computation instead of bilinear pairing in this paper.

Second, in this proposed scheme, we do not take the revocation mechanism of transaction records into consideration. The blockchain system will continuously generate new blocks, which means that all transactions will be recorded in the blockchain. Those invalid or useless transaction information will occupy the blockchain for a long time, which may have an impact on the storage performance of the system later. However, it will be our future interest to investigate appropriate security techniques to enable a blockchain solution with revocable transaction records.

Moreover, the proposed authentication approaches in our scheme can effectively defend against most external attackers, but do not investigate mechanisms to resist attacks from internal attackers, e.g., black-hole attacks and Sybil attacks. We assume that the proposed scheme is for trusted and honest internal users. However, if this assumption does not hold, we should integrate other secure mechanisms to achieve corresponding protection. Although not the focus of this paper, such mechanisms have been well studied in the literature [51, 52], and they are relatively independent from our proposed scheme. However, we believe that effective internal attack detection mechanisms are feasible and will be of interest to us for future work.

8 Conclusion

The secure sharing of financial electronic credentials is a promising research topic. Personal property and private information have been extensively utilized in real estate financial credentials. In this work, we focus on their secure sharing and circulation controllability, and thus propose a blockchain-based secure sharing scheme. Other than the basic security properties such as confidentiality and integrity, our scheme can also provide anonymous authentication, access control, traceability and auditability. We have conducted a comprehensive evaluation to further show the security and feasibility of the proposed scheme. Our future work will focus on fast similarity checking, hierarchical access control, and reduced authentication overhead to enable more efficient blockchain-based secure sharing.