Abstract
Recently, as interest in individualized health has increased, the Personal Health Record (PHR) has attracted a lot of attention for prognosis predictions and accurate diagnoses. Cloud servers have been used to manage the PHR system, but privacy concerns are evident since cloud servers process the entire PHR, which contains the sensitive information of patients. In addition, cloud servers centrally manage the PHR system so patients lose direct control over their own PHR and cloud servers can be an attractive target for malicious users. Therefore, ensuring the integrity and privacy of the PHR and allocating authorization to users are important issues. In this paper, we propose a secure PHR sharing system using a blockchain, InterPlanetary File System (IPFS), and smart contract to ensure PHR integrity and secure verification. To guarantee the patient’s authority over the management of his/her own PHR, as well as provide convenient access, we suggest a key aggregate dynamic searchable encryption. We prove the security of the proposed scheme through informal and formal analyses including an Automated Verification of Internet Security Protocols and Applications (AVISPA) simulation, Burrows–Abadi–Needham (BAN) logic, and security-model-based games. Furthermore, we estimate the computational costs of the proposed scheme using a Multiprecision Integer and Rational Arithmetic Cryptographic Library (MIRACL) and compare the results with those of previous works.
1. Introduction
With the increasing interest in and efforts to manage one’s health and prevent disease, the Personal Health Record (PHR) has attracted a lot of attention from various parties such as academia, industries, and the government. According to the International Organization for Standardization (ISO), a PHR is the representation of information related to health, which can be standalone or an integration of health information from multiple sources. The ISO also indicates that individuals should be allowed to manage, control, and access their own PHRs [1]. This means that the PHR is a patient-oriented system [2] and patients may want to share their PHRs with users such as medical professionals for prognosis predictions, accurate diagnoses, and health consulting. Due to the storage requirements and maintenance costs, patients often outsource their PHRs to third-party cloud servers. There are some cloud-based healthcare applications such as MTBC PHR [3], CapzulePHR [4], and My Medical [5]
However, cloud servers can be an attractive target for malicious users since a PHR contains the sensitive information of a patient [6]. If malicious users abuse or modify a PHR, the patient’s life could be put in danger or compromised due to misdiagnosis. Patients must be able to decide which users can access their PHRs. Attribute-based searchable encryption (ABSE), which is the integration of attribute-based encryption (ABE) and searchable encryption (SE), has been utilized to satisfy these requirements. ABSE provides fine-grained search control by regulating how authorized users acquire trapdoors to search for encrypted PHRs [7]. However, ABSE does not ensure patient-oriented sharing since it requires a trusted third party (TTP) to set up the system and allocate keys to entities. In addition, the decryption key size in ABSE is non-constant, which means that as the amount of data to be decrypted increases, the size of the decryption key increases [8]. To solve this problem, key aggregate searchable encryption (KASE) has been proposed for the data owner (e.g. patient), which generates system parameters and allocates decryption keys to users [9]. In addition, in KASE, the decryption key is a single constant aggregate key that has compacted the decryption keys corresponding to the data. Therefore, KASE is suitable for a PHR sharing system since it ensures the patient’s authority over his/her PHR and solves the key management problem.
Although cryptosystems are used in cloud-based systems for the privacy of patients, there are still non-negligible drawbacks. Storing PHRs on cloud servers means that patients delegate the management rights to the cloud server so patients lose their self-determined control over their personal information [10]. In addition, cloud servers are organized centrally, where storage is typically owned and managed by a single entity. Since cloud servers are usually not credible, they can steal or reveal PHRs by dishonestly performing malicious operations and can provide forged search results to users [11]. So, the existence of a centralized cloud server leads to the single-point-of-failure problem.
Researchers have considered a blockchain as a prospective solution to handle the problems in cloud-based systems [12,13,14,15]. A blockchain is a peer-to-peer (P2P) decentralized network that provides transparency, provenance, auditability, and security features, which are advantageous in data-sharing applications [16]. A blockchain eliminates the need for a third party by making the system secure and completely decentralized. However, there are limitations for managing all PHRs on the network since storing large volumes of data is expensive for a blockchain [17,18]. In addition, it does not guarantee scalability, which is an important challenge in blockchains. In order to alleviate the storage problem of blockchains, an InterPlanetary File System (IPFS) has been introduced. An IPFS is a distributed content-addressable file system, where for each uploaded PHR, IPFS allocates a unique hash as an identifier. By storing this identifier on the blockchain and using it as a pointer, the IPFS can overcome the storage limitations inherent in blockchains.
In this paper, we propose a secure PHR sharing system by applying a blockchain and an IPFS. We use KASE to ensure that patients retain authority over their records. However, existing KASE schemes do not consider dynamic data search sharing tasks, which can incur considerable computational costs since users must make repeated data request trapdoors. Therefore, we suggest a key aggregate dynamic searchable encryption using a Linear Secret Sharing Scheme (LSSS). The proposed system can ensure patient-oriented sharing.
1.1. Motivation, Methodology, and Contributions
A PHR contains the sensitive information of patients so it is necessary to restrict access to users. ABSE has been utilized as a solution but it does not ensure that patients maintain authority over data management. In addition, ABSE suffers from key management problems since the number of keys linearly increases depending on the complexity of the corresponding access policy. Researchers have utilized KASE as a countermeasure but their proposed schemes did not consider dynamic searches, which cause severe computational costs for data requests. In addition, they still depend on cloud servers for data management, which eliminates patients’ self-determined control over their personal information. Guaranteeing patients’ rights and reducing unnecessary communication between users in PHR sharing systems are indeed challenges. Therefore, we propose a secure PHR sharing system model. We utilize a blockchain and an IPFS to share the PHRs in a decentralized manner and handle the problems in cloud-based systems. We combine the KASE and LSSS to provide convenient keyword searches for users to obtain data. The proposed scheme provides essential security requirements such as the right to manage personal data, data integrity, transparency, and mutual authentication so our scheme has novel aspects compared to other previous works. The main contributions are summarized as follows.
- We propose a secure PHR sharing system that ensures patients’ authority over their personal records by suggesting a key aggregate dynamic searchable encryption. Thus, patients can manage and regulate access to their own PHRs.
- We provide dynamic searches for allowing users to obtain specific PHRs with low computational costs. We support dynamic searches using LSSS. In the proposed scheme, users can generate a trapdoor with various keywords at the same time to acquire a PHR.
- The proposed scheme utilizes a blockchain to provide data integrity and prevent the single point of failure. In addition, we utilize a smart contract to realize the secure and effective keyword searches and trapdoor verification.
- We store PHRs using an IPFS, which is a decentralized data storage system. Since the IPFS is a content-addressable protocol generating unique hash values for stored PHRs, it ensures the security of PHRs and avoids duplications.
1.2. Organization
The rest of the paper is organized as follows. We briefly cover previous works in Section 2. Section 3 presents the system models and interprets the conceptual aspect to assist with understanding this paper. Section 4 proposes a secure PHR sharing scheme. We prove the security of the proposed scheme in Section 5 and Section 6, including the BAN logic, AVISPA simulation tool, INDistinguishability against the Chosen Plaintext Attack (IND-CPA), INDistinguishability against the Chosen Keyword Attack (IND-CKA), and INDistinguishability against the Keyword Guessing Attack (IND-KGA). We analyze and compare the performance of the proposed scheme and existing schemes in Section 7. Section 8 presents the conclusions of this paper.
2. Related Works
Over the past few years, many studies have been conducted on secure PHR sharing using access control cryptosystems. In 2013, Li et al. [19] proposed a cloud-computing-based PHR sharing system using ABE since PHRs should only be available to authorized users. In 2015, Liu et al. [20] proposed a PHR sharing system based on cloud computing that employed ciphertext-policy attribute-based signcryption scheme. They suggested a method where the data owner signs the PHR with his/her own private key to protect the unauthorized modification of the PHR. They claimed that this scheme provided confidentiality through indistinguishable against chosen ciphertext attacks. However, Rao [21] proved that Lie et al.’s claim was incorrect and ccould not offer confidentiality in indistinguishability of ciphertexts under a selective encryption predicate and adaptive chosen ciphertext attack (IND-sEP-CCA2) security model. To supplement this problem, Rao proposed a cloud-based PHR sharing system that provides confidentiality using the IND-sEP-CCA2 model. However, these schemes [19,20,21] did not consider dynamic keyword search processes to access PHRs, which can cause considerable computational costs to users.
To address this problem, Zhang et al. [22] proposed a cloud-based PHR sharing system that provided dynamic keyword searches. However, Peng et al. [23] mentioned that Zhang et al.’s scheme was inefficient for queries since the ciphertexts of different data owners were matched against the same query. By considering these problems, Peng et al. suggested an enhanced scheme based on [22]; however, Sun et al. [24] mentioned that Peng et al.’s scheme was vulnerable to keyword guessing and equivalence test attacks. Liu et al. [25] presented an ABSE-based signcryption scheme for PHR sharing using LSSS. Xu et al. [26] proposed a PHR sharing system that used two cloud servers. They mentioned that privacy issues can occur in single-server system since cloud servers can compromise stored data using secret keys. However, they still suffered from the single-server problem since the whole system regarding or relevant to the sensitive PHR information was stored on a cloud server. This means that cloud servers can collude to abuse the stored PHRs. In addition, these existing schemes [22,23,25,26] managed PHRs on centralized cloud servers, thus they can also suffer from the single-point-of-failure problem.
To overcome this problem, Wang et al. [27] presented a blockchain-based PHR sharing system. They stored the verification values on the blockchain to match the search results from the cloud server. Zhang et al. [28] proposed a blockchain-based hierarchical PHR sharing system. They considered search result auditing and verification through the blockchain by regarding the cloud server and auditor as malicious entities. They also allowed the users to delegate decryption keys hierarchically to their groups for alleviating the burden of the key distribution task of authority. However, in this system, users delegated decryption keys to their groups without mutual authentication, which could lead to PHR leak problems. Zhang et al. [29] proposed a distributed PHR sharing scheme based on ABE and a blockchain. They adopted both a blockchain and cloud servers to overcome the limited storage capacity of the blockchain. However, these schemes [27,28,29] still used cloud servers to manage the enormous volumes of PHRs, thus the single-point-of-failure problem remained due to the centralized nature of the cloud server.
To mitigate these issues, Madine et al. [30] proposed a blockchain-based PHR architecture with an IPFS. In addition, Wang et al. [31] proposed a PHR sharing system using a consortium blockchain and an IPFS. They also utilized a smart contract to realize personalized access control. Wu et al. [32] suggested a blockchain-enabled PHR sharing system with access control. They considered mutual evaluation for the individual-centric transaction network and access control decisions. Hussien et al. [33] suggested a blockchain-based access control scheme for PHR sharing. However, existing PHR sharing schemes [30,31,32,33] rely on TTP to share PHRs, which does not guarantee a patient-centered system.
In 2020, Niu et al. [34] proposed a blockchain-based medical data sharing system using KASE in the Internet of Things environment. However, their scheme was vulnerable to privileged-insider attacks and did not provide secure mutual authentication. In addition, they did not consider dynamic keywords, which incurred significant computational costs to users. Niu et al. also relied on cloud servers to store data, which led to the single-point-of-failure problem. Thus, we propose a fully decentralized secure PHR sharing scheme that ensures patients’ self-determined control over their personal information. In addition, the proposed scheme realizes convenient PHR searches using key aggregate dynamic searchable encryption.
3. Preliminaries
In this section, we present the system models and cover the conceptual aspect referred to in this paper.
3.1. System Models
We consider the following network, threat, and security models to design and analyze the proposed scheme.
3.1.1. Network Model
The proposed secure PHR sharing model is depicted in Figure 1. In this figure, we have four entities: data owner, data user, IPFS, and blockchain.
Figure 1.
Network model of the proposed scheme.
- Data owner (DO): The manages his/her own PHR for self-directed health care. The generates the system parameters for his/her own PHR and controls the access rights of the using an aggregate key. The uploads the encrypted PHR to the IPFS and generates and uploads the smart contract to the blockchain for realizing the secure verification of the trapdoor.
- Data user (DU): The is the person that wants to access the PHR of the . To obtain the read rights of the PHR, the requests the aggregate key from the . The can obtain the aggregate key by mutual authentication with the . The can request and receive the PHR by communicating with the blockchain and IPFS. For the PHR decrypted using the aggregate key, the can verify the integrity through the received verification value from the blockchain.
- IPFS: IPFS is a P2P decentralized database. In the proposed system, the IPFS stores the encrypted PHR of the and returns a unique hash address for the stored PHR as an identifier. In addition, when the requests the PHR through the identifier, the IPFS returns the corresponding results to the .
- Blockchain: The architecture of the blockchain is a public permissionless blockchain since all network parties can access the smart contract in the blockchain. The proposed system employs the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm for the validation of transactions and generation of blocks. The blockchain implements the stored smart contract when the sends the trapdoor. Then, the blockchain transmits the identifier and verification value as a result.
The overall communication flows of the network are summarized as follows.
- 1
- The generates the system parameters for his/her own PHR and the and generate their own public and private key pairs with the system parameters. Then, the encrypts the PHR and uploads it to the IPFS.
- 2
- The IPFS stores the received PHR. Then, the IPFS generates and sends an unique hash address as an identifier for the received PHR to the . The calculates the keyword ciphertexts corresponding to the PHR and verification values. Then, the generates the smart contract using the keyword, identifier, and verification value, and uploads the smart contract to the blockchain.
- 3
- The requests the aggregate key for reading the ’s PHR by sending the ’s credentials.
- 4
- The verifies the ’s credentials, and if the is valid, the generates and sends the aggregate key and secret value to the .
- 5
- The generates the trapdoor using the keyword and received secret value. Then, the sends the trapdoor to the blockchain to obtain the identifier and verification value for the encrypted PHR.
- 6
- The blockchain checks the validity of the , and if the is validated, the blockchain sends the corresponding PHR’s identifier and verification values to the as a result.
- 7
- The sends a request for the PHR to the IPFS using the received identifier.
- 8
- The IPFS sends the encrypted PHR to the by matching the identifier in the database. The decrypts the received PHR using the aggregate key. Then, the checks whether the PHR is the data of the using the verification value. If it is correct, the process is successfully completed.
3.1.2. Threat Model
We adopt the broadly accepted Dolev–Yao (DY) threat model [35] to evaluate the security of the proposed scheme. In the DY model, each network entity communicates and exchanges messages through an insecure channel. This model also recognizes that an adversary can eavesdrop or intercept the transmitted messages between the network entities. With this message, can modify, forge, and insert the malicious content into the messages and delete or replay them during communication. can perform various attacks such as impersonation, replay, and man-in-the-middle (MITM) attacks [36,37].
3.1.3. Security Model
Under the threat model in Section 3.1.2, the scheme must satisfy the following security requirements:
- Data privacy: The PHR contains the sensitive information of the . If the PHR is leaked, the ’s life life could be put in danger or compromised. The PHR ciphertext does not reveal any information about the plaintext to the adversary. Thus, data confidentiality and integrity must be ensured in the PHR sharing system. We prove data privacy using the IND-CPA model.
- Ciphertext privacy: The keyword ciphertext does not expose any information about the corresponding keywords to the adversary who is the unauthorized user. We prove ciphertext privacy using the IND-CKA model.
- Trapdoor privacy: For secure PHR sharing, only the authorized can access the PHR, i.e., the trapdoor with the received secret values can be generated. The trapdoor does not disclose any information about the corresponding keywords to the adversary who is not authorized by the . Using the IND-KGA model, we demonstrate that the proposed scheme ensures trapdoor privacy.
In our scheme, games using the IND-CPA, IND-CKA, and IND-KGA models are defined as follows.
Definition 1
(Data privacy). We denote the semantic security for data privacy using the following IND-CPA model. In this game, the advantage of the adversary is defined as . This game is secure against IND-CPA if is satisfied for all attacks, where ε is a negligible probability.
- Init.Adversary selects a challenge set that wants to attack.
- Setup.Simulator executes the setup phase and sends the public parameters to .
- Phase 1. queries the aggregate key for set to . Then, performs the aggregate key request phase and sends to .
- Challenge. picks two plaintext and , where , from a set of possible plaintexts belonging to class and submits them to . flips the coin , encrypts in the data upload phase and sends the ciphertext to .
- Phase 2. repeatsPhase 1for , that is, the aggregate sets that contain data classes apart from those in the target set .
- Guess. outputs a guess of δ to . If , wins the game.
Definition 2
(Ciphertext privacy). Here, we demonstrate the game for ciphertext privacy using the IND-CKA model. The adversary’s advantage in this game is defined as . If is met, this game is secure against the IND-CKA model.
- Init.Adversary chooses a challenge set that wants to attack.
- Setup.Simulator executes the setup phase and returns the public parameters to .
- Phase 1.First, sends an aggregate key request query to . implements the aggregate key request phase and returns to . Then, transmits the trapdoor query for the keyword . If , executes the data request phase and responds with the trapdoor.
- Challenge. chooses two keywords and , where and of a challenge set , to . flips the coin and responds with the ciphertext for in the data upload phase to .
- Phase 2. repeatsPhase 1with the restriction that neither nor are used.
- Guess. outputs a guess of δ to . If , wins the game.
Definition 3
(Trapdoor privacy). Here, we demonstrate the game using the IND-KGA model to prove trapdoor security. In this game, is the advantage of . If , this game is secure against the IND-KGA model. This game for the proposed scheme is defined as follows.
- Init.Adversary gives to the simulator a challenge set .
- Setup. executes the setup phase and returns the results to .
- Phase 1. first sends an aggregate key request query to . executes the aggregate key request phase and sends to . Then, sends the ciphertext query for the keyword . If , executes the data upload phase and responds with the ciphertext.
- Challenge. submits two equal-length keywords and to within . flips the coin and responds with the trapdoor for in the data request phase to .
- Phase 2. repeatsPhase 1with the restriction that neither nor are used.
- Guess. outputs a guess of δ to . If , wins the game.
3.2. Bilinear Maps
A bilinear map is a pairing-based cryptosystem. Let and be the multiplicative cyclic groups with a large prime order q. The bilinear map satisfies the following properties.
- Bilinearity: For and , we have .
- Non-degeneracy: , .
- Computability: , can be computed in polynomial time.
3.3. Linear Secret-Sharing Scheme (LSSS)
A secret-sharing scheme [38] realizing access policies on a set of parties is linear over if the following conditions are satisfied:
- For each party, the shares of a secret form a vector over .
- There is an matrix called the share-generating matrix on and a function that maps each row of to a specific party in . During the generation of the shares, we give consideration to the column vector , where . Then, l shares a vector of s, which is equal to . In addition, the share belongs to , where is the jth row of .
We denote that is an authorized set of the access structure , , and I is defined as the set of rows where labels of I are in S, such as . Then, there exists coefficients that recover secret s by .
3.4. Computational Assumption
Let be a bilinear map, g be a generator of , and be chosen randomly. With this establishment, the assumptions used in this paper are defined as follows.
3.4.1. Decisional Diffie–Hellman (DDH) Assumption
The DDH assumption is that it is difficult for a probabilistic polynomial time adversary to distinguish from . The advantage of is defined as follows:
If there is no way that can decide whether , that is, deciding whether or with a non-negligible advantage, the DDH assumption holds.
3.4.2. Decisional Bilinear Diffie–Hellman (DBDH) Assumption
Under the DBDH assumption, an adversary cannot distinguish from in probabilistic polynomial time. The advantage of is defined as follows.
If cannot decide whether , which is determining whether or with a non-negligible advantage, the DBDH assumption is valid.
3.5. Blockchain
A blockchain is a distributed ledger technology that maintains a list of growing records. These records called blocks are chronologically linked using the cryptographic hashes of the previous blocks along with the timestamps and lists of transactions. Due to its chained structure, any included data cannot be changed unconstitutionally without the modification of all subsequent frames. In addition, each node of the blockchain network holds a copy of the chain to prevent a single point of failure. These properties make it difficult to change the transaction history, and the blockchain provides traceability, accountability, transparency, and provenance. Depending on the requirements and goals to be met, the blockchain can be classified into public/private and permissionless/permissioned types [39,40].
- Public permissionless blockchain: every node can participate in the consensus process, read and write the transactions, and maintain the ledgers.
- Public permissioned blockchain: the nodes are permitted to read or convert the state of the ledger with approved performing consensus, that is, only authorized nodes in the network can write in the ledger.
- Private permissionless blockchain: only authorized nodes are allowed to participate; the read and write abilities are owned by authorized nodes; all transactions can be conducted privately, and if necessary, the transaction can be opened for verification.
- Private permissioned blockchain: only authorized nodes can access, perform operations over the distributed ledger, and participate in the consensus process.
A smart contract is a computerized transaction protocol that executes the terms of a contract [41]. If a specific pre-defined condition is met, the smart contract is automatically implemented on the blockchain, and the contact with the smart contract is documented on the blockchain as a transaction. The smart contract can realize interoperability and flexible control over the blockchain system. Therefore, the proposed system adopted a blockchain and a smart contract to ensure the integrity of PHRs and provide secure verification mechanisms. The proposed scheme employed a public permissionless blockchain since anyone could access the blockchain. In addition, we adopted the PBFT consensus algorithm to realize consistency and synchronization in terms of transaction validation, block generation, and the voting process in the distribution network.
3.6. InterPlanetary File Systems
An InterPlanetary File System (IPFS) [42] is a P2P distributed file system for storing and accessing files. When content is uploaded to the IPFS, the IPFS returns a unique hash of content, called a content identifier (CID). The CID indicates the content address in the IPFS, which is based on the content itself, rather than the location of the content. Thus, anyone who has the CID can access the corresponding content. Since the IPFS connects all computing devices to share and access files, there are no authorized nodes, which eliminates the no single-point-of-failure problem and the nodes do not need to trust each other. Content-based addressing in an IPFS is constructed using the SHA-256 cryptographic hash, and this hash function creates an identifier for a certain file in the InterPlanetary Name System (IPNS). With this unique feature, the IPFS can maintain the same path for updated files with identifiers.
4. Proposed Scheme
We propose a secure PHR sharing scheme with key aggregate dynamic searchable encryption. The proposed scheme comprises six phases: the setup, key-generation, data upload, aggregate key request, data retrieval, and data request phases. The notations used in this paper can be found in Table 1 and the six phases are described in the following subsections.
Table 1.
Notation.
4.1. Setup Phase
The generates the bilinear parameters and sets the maximum number of PHRs and keywords as n and m, respectively. Then, the chooses a generator , a random number , and a hash function . The computes for . Finally, the publishes .
4.2. Key Generation Phase
In this phase, the and generate the private and public key pairs for secure PHR sharing. The and compute and , respectively.
4.3. Data Upload Phase
The uploads the PHR to the IPFS for health care. This phase is briefed in Figure 2 and the detailed steps are given below.
Figure 2.
Data upload phase.
- Step 1:
- The generates and computes , , for the . Then, the sends to the IPFS.
- Step 2:
- The IPFS stores in the database and computes the identifier . Then, the IPFS sends to the .
- Step 3:
- The selects , where , and matrix . The computes , and calculates , , for , where is the number of keywords about . Then, the generates the smart contract using and uploads it to the blockchain.
4.4. Aggregate Key Request Phase
The requests the aggregate key to the for reading the PHR. Figure 3 indicates this phase and the details are as follows.
Figure 3.
Aggregate key request phase.
- Step 1:
- The generates and . The computes , , , , , . Then, the sends to the through a public channel.
- Step 2:
- After receiving the message, the checks . Then, the computes , , and checks . If it is correct, the computes , , , , , , , , . Then, the sends to the .
- Step 3:
- Upon receiving the message, the checks . Then, the computes , , , and checks whether and . If it is valid, the obtains the secret values by computing .
4.5. Data Retrieval Phase
The requests the PHR’s location to the blockchain. The proposed scheme considers the dynamic search for the convenience of the PHR search so the sends the trapdoor to the blockchain only once. Figure 4 denotes this phase, and we interpret the detailed steps below.
Figure 4.
Data retrieval phase.
- Step 1:
- The generates and , and computes , for , where is the number of search keywords. Then, the sends to the blockchain, where .
- Step 2:
- With the received message, the blockchain checks and implements the smart contract. The blockchain computes satisfying and checks whether . If it is correct, the blockchain sends all matched and to the .
4.6. Data Request Phase
The requests the PHR to the IPFS with the received identifier. Then, the decrypts the encrypted PHR using the aggregate key. We denote this phase in Figure 5, and describe the detailed steps below.
Figure 5.
Data request phase.
- Step 1:
- The sends the identifier to the IPFS for the PHR that the wants.
- Step 2:
- The IPFS finds the encrypted document, which is matched with . Then, the IPFS sends to the .
- Step 3:
- After receiving the message, the computes . Then, the checks whether . If it is valid, the obtains the right PHR, and the process of the proposed PHR sharing system is successfully completed.
5. Informal Security Analysis
We indicate the security features of the proposed scheme, including impersonation, replay, MITM, and insider attacks. In addition, we prove that the proposed scheme ensures correctness, perfect forward secrecy, anonymity, and mutual authentication.
5.1. Impersonation Attack
An adversary tries to masquerade as the to obtain . In this case, needs and corresponding to . As mentioned in Section 3.1.2, can utilize the transmitted message. eavesdrops and . Then, attempts to send and to obtain and , respectively. However, it is impossible for since did not have knowledge about the ’s real identity and the secret key . Thus, the proposed scheme is secure against the impersonation attacks.
5.2. Replay Attack
With the ability described in Section 3.1.2, intercepts the transmitted messages. interrupts and and resends them to the and blockchain for obtaining the . However, the and blockchain check the transmission delay time and the freshness of the message, which is encrypted with random nonces so cannot obtain the . Therefore, our scheme has resistance against replay attacks.
5.3. Man-in-the-Middle (MITM) Attack
In this attack, interrupts the transmitted messages and and modifies them to and . Unfortunately, it is computationally impossible for since these messages are made up of the ’s identity , secret key , and aggregate key . Hence, the proposed scheme prevents the MITM attack.
5.4. Insider Attack
This attack supposes that is an insider that receives the authorization from the . attempts to impersonate another legitimate to know what kind of person the is by obtaining the . For this, endeavors to generate the messages and with the ’s and . However, cannot compute them since the corresponding values of the are unknown. Thus, the proposed scheme is secure against the insider attacks.
5.5. Correctness
5.5.1. Dynamic Keyword
In Section 4.5, the blockchain checks whether the sends the correct trapdoor using the aggregate key. We prove it arithmetically as follows.
5.5.2. PHR
As described in Section 4.6, the can obtain the PHR of the by decrypting with the aggregate key . Then, the compares the obtained PHR with to determine whether it is the correct value. For correctness, the can be obtained as follows.
5.6. Perfect Forward Secrecy
In this attack, can have the keys of the . With this value, tries to acquire the . For this, needs the aggregate key so makes effort to generate the message . Nevertheless, cannot calculate it since did not have knowledge about the ’s real identity and secret key . For this reason, our scheme provides the perfect forward secrecy.
5.7. Anonymity
In the proposed scheme, each entity cannot trust each other so they hide the real identity with and perform the mutual authentication through the pseudo identity . Although tries to obtain the real identity from the pseudo identity, it is computationally impossible because of the collision-resistant property of the hash function. Therefore, the proposed scheme ensures the anonymity of each entity.
5.8. Mutual Authentication
In Section 4.4, it was shown that the and check the validity of each other before issuing the aggregate key . The generates the signature that can represent the and sends to the . After checking the transmission delay time, the checks whether . If it is correct, the ’s validity is verified from the . Then, the sends with the signature . With the received message, the checks whether and . If this condition is approved, the validity of the is verified to the . Consequently, the and mutually authenticate so the proposed scheme provides mutual authentication.
6. Formal Security Analysis
In this section, we conduct a formal analysis to evaluate the security of the proposed scheme using the AVISPA simulation tool, BAN logic, IND-CPA, IND-CKA, and IND-KGA.
6.1. AVISPA Simulation Tool
AVISPA is a security analysis tool for protocols in security-sensitive wireless environments [43]. For confirming security, many authentication schemes have been widely used [44,45,46]. We simulated the proposed scheme with the AVISPA tool based on the DY threat model to identify the security issues against replay and MITM attacks. To analyze our scheme, we shaped the actions of each participant using High-Level Protocols Specification Language (HLPSL), a role-based language. The HLPSL2IF translator coverts HLPSL into Intermediate Format (IF) and inputs the IF into the back-end. Then, the back-ends outputs the Output Format (OF) as the security analysis results against four components including the On-the Fly-Model-Checker (OFMC), SAT-based Model-Checker (SATMC), CL-based Attack Searcher (CL-AtSe), and Tree-Automata-based Protocol Analyzer (TA4SP).
We simulated the proposed scheme on the OFMC and CL-AtSe back-ends since they provide bitwise exclusive-OR operations. The simulated results on the OFMC and CL-AtSe were identified as SAFE or UNSAFE by estimating the security issues against replay and MITM attacks. In Figure 6, the OF indicates that the proposed scheme is “SAFE” in both the OFMC and CL-AtSe back-ends. Therefore, our scheme completely attains the specific security goals and withstands the attacks in a wireless environment.
Figure 6.
AVISPA evaluation results.
6.2. Formal Security Analysis using BAN Logic
BAN logic is a mathematical proof method for secure mutual authentication, which is widely used in authentication schemes [47,48,49]. We proved that the proposed scheme provides mutual authentication in Section 4.4. We describe the notations of BAN logic in Table 2, indicate the goals of this analysis, present all considered assumptions, and provide corresponding proof.
Table 2.
BAN Logic Notation.
6.2.1. Rules
The rules of the BAN logic are as follows.
- Message meaning rule ():
- Nonce verification rule ():
- Jurisdiction rule ():
- Freshness rule ():
- Belief rule ():
6.2.2. Goals
We establish the goals for proving mutual authentication as follows:
- Goal 1:
- Goal 2:
- Goal 3:
- Goal 4:
6.2.3. Idealized Forms
The idealized forms in the proposed scheme are as follows:
- :
- :
6.2.4. Assumptions
The assumptions to achieve the BAN logic are as follows:
- :
- :
- :
- :
- :
- :
6.2.5. Proof
We prove the guarantee of mutual authentication by attaining the goals using notations, idealized forms, and assumptions. We execute the proof according to the following steps:
- Step 1:
- can be obtained from .
- Step 2:
- can be obtained by applying the with .
- Step 3:
- can be gained from the with and .
- Step 4:
- can be acquired by applying the with and .
- Step 5:
- can be obtained from .
- Step 6:
- can be gained from with and .
- Step 7:
- can be obtained by applying with and .
- Step 8:
- can be obtained from with and .
- Step 9:
- and can be obtained from and since .(Goal 3)(Goal 4)
- Step 10:
- and can be obtained by applying from , , , and .(Goal 1)(Goal 2)
Therefore, the and authenticate securely in the aggregate key request phase of the proposed scheme.
6.3. IND-CPA Security
Theorem 1.
When an adversary can win the game with a non-negligible advantage ε in a probability polynomial time, can solve the DBDH assumption’s difficult problem with .
Proof.
We prove this security game according to Definition 1 and Section 3.4.2. Assume there is that can break our scheme with advantage . Then, we build a simulator to play the DBDH game with advantage . The simulation process is as follows. Challenger randomly selects a random number and a generator . Then, randomly tosses a coin to obtain a random value . sets if , then , which is ; otherwise , which means . Then, sends the results to that plays the DBDH game.
Init. The simulator runs the adversary to create a challenge set that wants to attack. Then, sends it to .
Setup. computes the public parameters and sets the instance of the DBDH game as and . Then, sends the public parameters to .
Phase 1. requests an aggregate key for . computes . Then, sends to .
Challenge. submits two equal-length plaintext and to with . randomly flips a coin to obtain . We set if , then . In this case, we let be the instance of the DBDH game, then and . Otherwise, if , then and . computes , and sends to .
Phase 2. repeats Phase 1 to obtain the aggregate key, which is associated with the data sets .
Guess. guesses of . If , we set outputs 0, otherwise, it outputs 1. outputs 0 means that and can obtain the practical ciphertext. Then, the advantage is and we can obtain . outputs 1 means that and obtains invalid ciphertext. So, there is no advantage in guessing the correct and obtains . Therefore, the probability of a successful game is
Therefore, our scheme ensures IND-CPA security. □
6.4. IND-CKA Security
Theorem 2.
If an adversary can win the game with a non-negligible advantage ε in a probability polynomial time, can solve the DDH assumption’s difficult problem with .
Proof.
Let an adversary break our scheme with advantage . Then, we construct a simulator to play the DDH game with advantage . The simulation process is described as follows. Challenger randomly selects and a generator . Then, randomly tosses a coin to obtain a random value . If , then , which is ; otherwise , which means . Then, sends the results to that plays the DDH game.
Init. The simulator executes the adversary to create a challenge set . Then, sends it to .
Setup. generates the public parameters . Then, returns them to .
Phase 1. requests the aggregate key for . computes . Then, sends to . In addition, sends the trapdoor query for the keyword . If , executes the data request phase and sends to .
Challenge. submits two keywords and , where and of a challenge set to . randomly tosses a coin to obtain . If , then . In this case, we let , then and , . Otherwise, if , then and , . Then, computes and sends to .
Phase 2. repeats Phase 1 to obtain the aggregate key and trapdoor under the restriction that neither nor are used.
Guess. guesses of . If , outputs 0, otherwise, it outputs 1. In addition, outputs 0 is the representation of and can obtain the practical ciphertext. Then, the advantage is so we can obtain . outputs 1 is the indication that and obtains invalid ciphertext. So, there is no advantage in guessing the correct and can be obtained. So, the probability of a successful game is
Therefore, our scheme ensures IND-CKA security. □
6.5. IND-KGA Security
Theorem 3.
The difficult problem of the DDH assumption can be solved when an adversary can win the game with ε in a probability polynomial time. Then, a non-negligible advantage is .
Proof.
Suppose that an adversary can break our scheme with advantage . Then, we form a simulator to play the DDH game with advantage . The simulation process is described as follows. Challenger randomly selects and . Then, randomly tosses a coin to obtain a random value . If , then , which is ; otherwise which means . Then sends the results to that plays the DDH game.
Init. The simulator executes the adversary to create a challenge set . Then, sends it to .
Setup. generates the public system parameters . Then, returns them to .
Phase 1. requests aggregate key for . computes . Then, sends to . In addition, sends the ciphertext query for the keyword . If , executes Data upload phase and sends to .
Challenge. submits two equal-length keywords and to within . randomly tosses a coin to obtain . If , then . In this case, we let , then and , . Otherwise, if , then and , . Then, sends to .
Phase 2. repeats Phase 1 to obtain the aggregate key under the restriction that neither nor .
Guess. guesses of . If , outputs 0, otherwise, it outputs 1. In addition, outputs 0 is the representation of , and can obtain the practical trapdoor. Then, the advantage is , so we can get . outputs 1 is the indication that , and obtains invalid trapdoor. So, there is no advantage in guessing the correct , and it can be obtained . So, the probability of a successful game is
Therefore, our scheme ensures IND-KGA security. □
7. Security and Performance Analysis
In this section, we compare the security and performance of the proposed scheme to the related schemes [25,28,31] in terms of security features, computational costs, and communication costs.
7.1. Security Features
We present the security properties of the proposed scheme and existing schemes [25,28,31]. As shown in Table 3, the related schemes suffer from security vulnerability problems, including perfect forward secrecy and mutual authentication. In contrast, our scheme is secure against various attacks in DY threat model, and ensures perfect forward secrecy, anonymity, mutual authentication, correctness, access control, dynamic search, data verification, and the ’s authority over his/her own PHR. Therefore, our scheme provides more security features compared to the related schemes.
Table 3.
Security Features.
7.2. Computational Costs
We conducted a testbed experiment on cryptographic computation using MIRACL [50] on a personal computer (PC). The detailed performance of the PC was “Ubuntu 18.04.4 LTS with memory 8GiB, processor: Intel Core i7-4790 @ 3.60GHz × 4, CPU Architecture: 64-bit”. We measured the average run time of 100 runs for a hash operation 0.003 ms, a bilinear pairing operation 6.575 ms, a scalar point multiplication operation 2.373 ms, an exponentiation operation 0.819 ms, an addition operation 0.013 ms, and a symmetric key encryption/decryption 0.001 ms. Table 4 shows the measurement results. is the number of search keywords and is the size of the PHR dataset. The compared schemes provide a dynamic keyword search, and some schemes [28,31] do not consider data verification. Thus, to verify the performance of the dynamic keyword search, Figure 7 denotes the results obtained for different numbers of returned PHRs: , , , and . As shown in Figure 7, the existing schemes [25,28,31] exhibited higher computational costs than the proposed scheme. Furthermore, they did not satisfy some security features, such as mutual authentication and perfect forward secrecy. In contrast, the proposed scheme has lower computational costs and provides many security features that are not provided by the existing schemes.
Table 4.
Computational Costs Comparison.
Figure 7.
Computation costs comparison as the number of search keywords increases [25,28,31].
7.3. Communication Costs
The communication costs of the proposed scheme are compared with [25,28,31]. We set the bit size of the hash function, identity, timestamp, random number, index, an elliptic curve point, , , symmetric encryption/decryption, and attribute set to 160 bits, 128 bits, 32 bits, 160 bits, 32 bits, 320 bits, 512 bits, 1024 bits, 256 bits, and 32 bits, respectively. Table 5 indicates the comparison results of the communication costs. In the data retrieval and request phases, the exchanged messages , , , and needed 1088 bits, 320 bits, 160 bits, and 2048 bits, respectively. The existing schemes [25,28,31] had higher costs than the proposed scheme. Therefore, we have lower costs and ensure more security requirements than the existing schemes [25,28,31].
Table 5.
Communication Costs Comparison.
8. Conclusions
We proposed a secure PHR sharing system by applying a blockchain and an IPFS to ensure integrity and solve the single-point-of-failure problem. We suggested key aggregate dynamic searchable encryption using LSSS to provide the authority of data owners and reduce the unnecessary computation for users. In addition, we considered mutual authentication and data verification to realize securing sharing between network entities. With the proposed scheme, the data owner can encrypt and upload his/her own PHR with unique system parameters and assign the read rights to data users with an aggregate key through mutual authentication. The data user can obtain the encrypted PHR by communicating with the blockchain and IPFS, and the data user can verify the integrity of the decrypted PHR ciphertext with the aggregate key. We proved the security of the proposed scheme through information and formal analyses including BAN logic, the AVISPA tool and the IND-CPA, IND-CKA, and IND-KGA models. In addition, we performed a comparison of previous works using MIRACL. We demonstrated that our scheme provides more efficient and secure sharing compared to existing schemes. As a result, the proposed scheme provides essential security requirements such as rights related to personal data, data integrity, transparency, mutual authentication, and convenience of search so our scheme has novelty compared to other previous works. Therefore, the proposed scheme can be applied in a practical PHR sharing system and will ensure secure and efficient sharing by providing the authority of the patient and ensuring the confidence of the data user. Since the scope of the proposed scheme is how data owners share their PHR without TTP, we focused on the method of secure PHR sharing through mutual authentication. So, we have an issue to overcome in terms of verifying the identity before mutual authentication between the data owner and user. In the future, we will cover the identity verification for more systematic patient-oriented systems. In addition, we plan to test the proposed scheme on the blockchain and IPFS implementations. Then, we will evaluate the feasibility of the proposed scheme in a practical PHR sharing system.
Author Contributions
Conceptualization, J.O., J.L., and K.P.; software, J.L. and M.K.; validation, Y.P.; formal analysis, J.O. and M.K.; investigation, J.L. and M.K.; writing—original draft preparation, J.O.; writing—review and editing, Y.P., K.P., and S.N.; supervision, Y.P.; funding acquisition, K.P. and S.N. All authors have read and agreed to the published version of the manuscript.
Funding
This research was supported in part by the National Research Foundation of Korea (NRF) and funded by the Ministry of Education under grant 2020R1I1A3058605, and in part by the Korean Government through the Electronics and Telecommunications Research Institute—ETRI (Core Technology Research on Trust Data Connectome) under Grant 22ZR1330.
Conflicts of Interest
The authors declare no conflict of interest.
References
- ISO. Health Informatics—Capacity-Based eHealth Architecture Roadmap—Part 2: Architectural Components and Maturity Model; Technical Report (ISO/TRTR14639-2); ISO: Geneva, Switzerland, 2014; Available online: https://www.iso.org/standard/54903.html (accessed on 13 April 2022).
- Deng, F.; Wang, Y.; Peng, L.; Xiong, H.; Geng, J.; Qin, Z. Ciphertext-policy attribute-based signcryption with verifiable outsourced designcryption for sharing personal health records. IEEE Access 2018, 6, 39473–39486. [Google Scholar] [CrossRef]
- MTBC PHR: Personal Health Records for Patients. Available online: https://phr.mtbc.com/phrdefault.aspx (accessed on 13 April 2022).
- Capzule PHR: Your Family Health Data in One App. (Personal Medical/Health Records). Available online: https://www.capzule.com/ (accessed on 13 April 2022).
- My Medical—The Personal Medical Record for You, The Patient. Available online: http://mymedicalapp.com/ (accessed on 13 April 2022).
- Garg, N.; Wazid, M.; Das, A.K.; Singh, D.P.; Rodrigues, J.J.P.C.; Park, Y. BAKMP-IoMT: Design of blockchain enabled authenticated key management protocol for internet of medical things deployment. IEEE Access 2020, 8, 95956–95977. [Google Scholar] [CrossRef]
- Morales-Sandoval, M.; Cabello, M.H.; Marin-Castro, H.M.; Compean, J.L.G. Attribute-based encryption approach for storage, sharing and retrieval of encrypted data in the cloud. IEEE Access 2020, 8, 170101–170116. [Google Scholar] [CrossRef]
- Banerjee, S.; Roy, S.; Odelu, V.; Das, A.K.; Chattopadhyay, S.; Rodrigues, J.J.P.C.; Park, Y. Multi-authority CP-ABE-based user access control scheme with constant-size key and ciphertext for IoT deployment. J. Inf. Secur. Appl. 2020, 53, 102503. [Google Scholar] [CrossRef]
- Cui, B.; Liu, Z.; Wang, L. Key-aggregate searchable encryption (KASE) for group data sharing via cloud storage. IEEE Trans. Comput. 2016, 65, 2374–2385. [Google Scholar] [CrossRef]
- Kim, M.; Lee, J.; Oh, J.; Park, K.; Park, Y.; Park, K. Blockchain based energy trading scheme for vehicle-to-vehicle using decentralized identifiers. Appl. Energy 2022, 322, 119445. [Google Scholar] [CrossRef]
- Chen, CM.; Tie, Z.; Wang, E.K.; Khan, M.K.; Kumar, S.; Kumari, S. Verifiable dynamic ranked search with forward privacy over encrypted cloud data. Peer-to-Peer Netw. Appl. 2021, 14, 2977–2991. [Google Scholar] [CrossRef]
- Yu, S.; Park, Y. A robust authentication protocol for wireless medical sensor networks using blockchain and physically unclonable functions. IEEE Internet Things J. 2022, 9, 20214–20228. [Google Scholar] [CrossRef]
- Chattaraj, D.; Bera, B.; Das, A.K.; Rodrigues, J.J.P.C.; Park, Y. Designing fine-grained access control for software-defined networks using private blockchain. IEEE Internet Things J. 2022, 9, 1542–1559. [Google Scholar] [CrossRef]
- Chen, CM.; Deng, X.; Kumar, S.; Kumari, S.; Islam, S.K. Blockchain-based medical data sharing schedule guaranteeing security of individual entities. J. Ambient Intell. Humaniz. Comput. 2021. [Google Scholar] [CrossRef]
- Park, K.; Lee, J.; Das, A.K.; Park, Y. BPPS: Blockchain-enabled privacy-preserving scheme for demand-response management in smart grid environments. IEEE Trans. Dependable Secur. Comput. 2022; Early access. [Google Scholar]
- Son, S.; Lee, J.; Park, Y.; Park, Y.; Das, A.K. Design of blockchain-based lightweight V2I handover authentication protocol for VANET. IEEE Trans. Netw. Sci. Eng. 2022, 9, 1346–1358. [Google Scholar] [CrossRef]
- Kumar, P.; Kumar, R.; Srivastava, G.; Gupta, G.P.; Tripathi, R.; Gadekallu, T.R.; Xiong, N.N. PPSF: A privacy-preserving and secure framework using blockchain-based machine-learning for IoT-driven smart cities. IEEE Trans. Netw. Sci. Eng. 2021, 8, 2326–2341. [Google Scholar] [CrossRef]
- Kim, M.; Yu, S.; Lee, J.; Park, Y.; Park, Y. Design of Secure Protocol for Cloud-Assisted Electronic Health Record System Using Blockchain. Sensors 2020, 20, 2913. [Google Scholar] [CrossRef] [PubMed]
- Li, M.; Yu, S.; Zheng, Y.; Ren, K.; Lou, W. Scalable and secure sharing of personal health records in cloud computing using attribute-based encryption. IEEE Trans. Parallel Distrib. Syst. 2013, 24, 131–143. [Google Scholar] [CrossRef]
- Liu, J.; Huang, X.; Liu, J.K. Secure sharing of personal health records in cloud computing: Ciphertext-policy attribute-based signcryption. Future Gener. Comp. Syst. 2015, 52, 67–76. [Google Scholar] [CrossRef]
- Rao, Y. A secure and efficient ciphertext-policy attribute-based signcryption for personal health records sharing in cloud computing. Future Gener. Comp. Syst. 2017, 67, 133–151. [Google Scholar] [CrossRef]
- Zhang, W.; Lin, Y.; Xiao, S.; Wu, J.; Zhou, S. Privacy preserving ranked multi-keyword search for multiple data owners in cloud computing. IEEE Trans. Comput. 2016, 65, 1566–1577. [Google Scholar] [CrossRef]
- Peng, T.; Lin, Y.; Yao, X.; Zhang, W. An efficient ranked multi-keyword search for multiple data owners over encrypted cloud data. IEEE Access 2018, 6, 21924–21933. [Google Scholar] [CrossRef]
- Sun, J.; Hu, S.; Nie, X.; Walker, J. Efficient ranked multi-keyword retrieval with privacy protection for multiple data owners in cloud computing. IEEE Syst. J. 2020, 14, 1728–1739. [Google Scholar] [CrossRef]
- Liu, Z.; Liu, Y.; Fan, Y. Searchable attribute-based signcryption scheme for electronic personal health record. IEEE Access 2018, 6, 76381–76394. [Google Scholar] [CrossRef]
- Xu, C.; Wang, N.; Zhu, L.; Sharif, K.; Zhang, C. Achieving searchable and privacy-preserving data sharing for cloud-assisted e-healthcare system. IEEE Internet Things J. 2019, 6, 8345–8356. [Google Scholar] [CrossRef]
- Wang, S.; Zhang, D.; Zhang, Y. Blockchain-based personal health records sharing scheme with data integrity verifiable. IEEE Access 2019, 7, 102887–102901. [Google Scholar] [CrossRef]
- Zhang, J.; Yang, Y.; Liu, X.; Ma, J. An efficient blockchain-based hierarchical data sharing for Healthcare Internet of Things. IEEE Trans. Ind. Inform. 2022, 18, 7139–7150. [Google Scholar] [CrossRef]
- Zhang, L.; Zhang, T.; Wu, Q.; Mu, Y.; Rezaeibagha, F. Secure decentralized attribute-based sharing of personal health records with blockchain. IEEE Internet Things J. 2022, 9, 12482–12496. [Google Scholar] [CrossRef]
- Madine, M.M.; Salah, K.; Jayaraman, R.; Yaqoob, I.; Al-Hammadi, Y.; Ellahham, S.; Calyam, P. Fully decentralized multi-party consent management for secure sharing of patient health records. IEEE Access 2020, 8, 225777–225791. [Google Scholar] [CrossRef]
- Wang, Y.; Zhang, A.; Zhang, P.; Qu, Y.; Yu, S. Security-aware and privacy-preserving personal health record sharing using consortium blockchain. IEEE Internet Things J. 2022, 9, 12014–12028. [Google Scholar] [CrossRef]
- Wu, G.; Wang, S.; Ning, Z.; Li, J. Blockchain-enabled privacy-preserving access control for data publishing and sharing in the internet of medical things. IEEE Internet Things J. 2022, 9, 8091–8104. [Google Scholar] [CrossRef]
- Hussien, H.M.; Yasin, S.M.; Udzir, N.I.; Ninggal, M.I.H. Blockchain-based access control scheme for secure shared personal health records over decentralised storage. Sensors 2021, 21, 2462. [Google Scholar] [CrossRef] [PubMed]
- Niu, J.; Li, X.; Gao, J.; Han, Y. Blockchain-based anti-key-leakage key aggregation searchable encryption for IoT. IEEE Internet Things J. 2020, 7, 1502–1518. [Google Scholar] [CrossRef]
- Dolev, D.; Yao, A. On the security of public key protocols. IEEE Trans. Inf. Theory 1983, 29, 198–208. [Google Scholar] [CrossRef]
- Wazid, M.; Das, A.K.; Choo, K.-K.R.; Park, Y. SCS-WoT: Secure communication scheme for web of things deployment. IEEE Internet Things J. 2022, 9, 10411–10423. [Google Scholar] [CrossRef]
- Oh, J.; Lee, J.; Kim, M.; Park, Y.; Park, K.; Noh, S. A secure data sharing based on key aggregate searchable encryption in fog-enabled IoT environment. IEEE Trans. Netw. Sci. Eng. 2022; Early access. [Google Scholar]
- Beimel, A. Secure Schemes for Secret Sharing and Key Distribution; Technion-Israel Institute of Technology, Faculty of Computer Science: Haifa, Israel, 1996. [Google Scholar]
- Hunhevicz, J.J.; Hall, D.M. Do you need a blockchain in construction? Use case categories and decision framework for DLT design options. Adv. Eng. Inform. 2020, 45, 101094. [Google Scholar] [CrossRef]
- Tan, W.K.A.; Sundarakani, B. Assessing blockchain technology application for freight booking business: A case study from technology acceptance model perspective. J. Glob. Oper. Strateg. Sourc. 2021, 14, 202–223. [Google Scholar] [CrossRef]
- Szabo, N. Formalizing and securing relationships on public networks. First Monday 1997, 2. Available online: https://firstmonday.org/ojs/index.php/fm/article/view/548 (accessed on 13 April 2022). [CrossRef]
- IPFS is the Distributed Web. Available online: https://ipfs.io/ (accessed on 13 April 2022).
- Viganò, L. Automated security protocol analysis with the AVISPA tool. Electron. Notes Theor. Comput. Sci. 2006, 155, 61–86. [Google Scholar] [CrossRef]
- Lee, J.; Yu, S.; Park, K.; Park, Y.; Park, Y. Secure three-factor authentication protocol for multi-gateway IoT environments. Sensors 2019, 19, 2358. [Google Scholar] [CrossRef]
- Liu, X.; Guo, Z.; Ma, J.; Song, Y. A secure authentication scheme for wireless sensor networks based on DAC and Intel SGX. IEEE Internet Things J. 2022, 9, 3533–3547. [Google Scholar] [CrossRef]
- Kwon, D.; Park, Y.; Park, Y. Provably secure three-factor-based mutual authentication scheme with PUF for wireless medical sensor networks. Sensors 2021, 21, 6039. [Google Scholar] [CrossRef] [PubMed]
- Shashidhara, R.; Nayak, S.K.; Das, A.K.; Park, Y. On the design of lightweight and secure mutual authentication system for global roaming in resource-limited mobility networks. IEEE Access 2021, 9, 12879–12895. [Google Scholar] [CrossRef]
- Chen, CM.; Deng, X.; Gan, W.; Chen, J.; Islam, S.K. A secure blockchain-based group key agreement protocol for IoT. J. Supercomput. 2021, 77, 9046–9068. [Google Scholar] [CrossRef]
- Lee, J.; Kim, G.; Das, A.K.; Park, Y. Secure and efficient honey list-based authentication protocol for vehicular ad hoc networks. IEEE Trans. Netw. Sci. Eng. 2021, 8, 2412–2425. [Google Scholar] [CrossRef]
- MIRACL Cryptographic SDK: Multiprecision Integer and Rational Arithmetic Cryptographic Library. Available online: https://github.com/miracl/MIRACL (accessed on 13 April 2022).
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |
© 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).