Abstract
Patient location sharing is an important part of modern smart healthcare and mobile medical services. Blockchain has many attractive properties and is suitable for managing patient locations in telecare medical information systems (TMIS). Recently, Ji et al. proposed a blockchain-based multilevel privacy-preserving location sharing (BMPLS) scheme for TMIS. In this paper, we show that Ji et al.’s BMPLS scheme does not achieve confidentiality and multilevel privacy-preserving. An adversary outside the system can use an ordinary personal computer to completely break the system within a dozen hours and obtain the location of any patient at any time. The adversary inside the system can use an ordinary personal computer to obtain the location of the designated patient within tens of seconds. Using salting technology, we propose an improved BMPLS scheme to fix our attacks. We also optimized the BMLS scheme to make it correct and executable. The security analysis shows that the improved BMPLS scheme achieves decentralization, untamperability, confidentiality, multilevel privacy-preserving, retrievability, and verifiability. The simulation shows that the improved BMPLS scheme is practical, the computational overhead of the location record phase is within 10 ms, and the computational overheads of the location sharing and location extraction phases are both within 30 ms.
1. Introduction
Blockchain is a new decentralized infrastructure and distributed computing paradigm, and it is one of the most revolutionary emerging technologies [1]. In a narrow sense, blockchain is a decentralized shared general ledger that combines data blocks in a chain into a specific data structure in chronological order and uses cryptography technology to ensure that data are untamperable and unforgeable. In a broad sense, blockchain technology is a new decentralized computing paradigm. It uses an encrypted chain block structure to store and verify data, consensus algorithms to update data, and smart contracts to manipulate data. Blockchain has the advantages of decentralization, trustless, anonymity, and untamperability. It can break through the limitations of traditional centralized systems and find important applications in a wide range of fields. More meaningful applications will appear with the further integration of blockchain with cloud computing, edge computing, and the Internet of Things [2–6].
With the rapid development of information technology, medical management has become more intelligent and real-time. Wireless mobile networks and wearable technology enable mobile medical services and telemedicine to be realized. For example, IBM has integrated a real-time asset locator (RTAL) for mobile medical and telecare medical to track the location of patients, equipment, and medical staff. Location management plays a significant role in remote patient service and monitoring, such as monitoring particular patients, handling emergencies, and analyzing epidemic distribution. Blockchain has many attractive properties and is suitable for managing patient locations in telecare medical information systems (TMIS).
Based on blockchain technology, Zyskind et al. [7] proposed a data storage scheme to protect sensitive data such as user’s location. In their scheme, user data needs to be encrypted before being stored on the blockchain to achieve confidentiality. Amoretti et al. [8] proposed a blockchain-based location proof scheme. Different from [7], in this scheme, the location information is signed before being put on the blockchain to achieve verifiability. Ji et al. [9] comprehensively analyzed the security requirements of blockchain-based location sharing for TMIS and proposed a blockchain-based multilevel privacy-preserving location sharing scheme (BMPLS). They claim that their scheme achieves decentralization, untamperability, confidentiality, multilevel privacy-preserving, retrievability, and verifiability. Unfortunately, we found that their scheme is insecure in practice. The adversary can recover any user’s location effectively. Recently, Lee et al. [10] proposed a blockchain-based medical data preservation scheme for TMIS. Their scheme consists of a medical sensor area authentication protocol and a social network information transfer protocol.
1.1. Related Works
With the development of Internet technology, telemedicine has gradually replaced the traditional treatment model. Electronic medical records (EMR) and electronic health records (EHR) are generated in large quantities and frequently exchanged and shared among legitimate users. The protection of electronic medical information is related to patients’ privacy and related to their life safety. Therefore, the security and privacy protection of electronic medical records are significant for the development of telemedicine.
Blockchain technology has the potential to improve the medical ecosystem. It provides a novel, efficient, and secure model for exchanging EMRs and EHRs and enhances medical data security, privacy, and interoperability [11, 12]. Using blockchain technology, Cao et al. [13] proposed a secure cloud-assisted electronic health system to protect outsourced electronic health records from illegal modification. Wang et al. [14] proposed a blockchain-based eHealthcare system interoperating with wireless body area networks. Using proxy reencryption, Huang et al. [15] proposed a blockchain-based decentralized medical data sharing scheme with privacy-preserving. Zhuang et al. [16] proposed a patient-centric health information exchange framework. Shamshad et al. [17] proposed a novel blockchain-based privacy and security preserving EHR sharing protocol. Huang et al. [18] proposed a blockchain-based eHealth system, in which the manipulation of EHRs can be audited. Zhu et al. [19] proposed an improved convolution Merkle tree-based blockchain electronic medical record secure storage scheme. Uddin et al. [20] proposed a blockchain leveraged decentralized eHealth architecture. Tanwar et al. [21] explored several solutions that use blockchain technology to improve the current limitations of medical systems, including frameworks and tools for measuring the performance of such systems. Using off-chain and on-chain blockchain system design, Miyachi et al. [22] proposed a modular hybrid privacy-preserving framework. Chen et al. [23] proposed a complete medical information system model based on blockchain technology to realize the goal of safe storage and sharing of medical data. Hossein et al. [24] proposed a novel blockchain-based privacy-preserving architecture for IoT healthcare applications. A summary of related works is shown in Table 1.
1.2. Motivation and Contributions
Among the previous blockchain-based location sharing schemes, Zyskind et al.’s scheme only provides decentralization, untamperability, and confidentiality [7], while Amoretti et al.’s scheme only provides decentralization, untamperability, and verifiability [8]. These are far from enough. Ji et al. [9] considered decentralization, untamperability, confidentiality, multilevel privacy protection, retrievability, and verifiability, but their scheme is insecure in practice. The adversary can recover any user’s location effectively. Thus, it is of great significance to propose secure and practical blockchain-based multilevel privacy-preserving location sharing schemes. The comparison of previous blockchain-based location sharing schemes is shown in Table 2, where “√” means satisfied, “×” means dissatisfied, and “−” means uninvolved.
The main contributions of this paper are as follows:(1)We analyze the security of Ji et al.’s BMPLS scheme [9] and show that it has fatal flaws in confidentiality and multilevel privacy-preserving. An adversary outside the system can use an ordinary personal computer to completely break the system within a dozen hours and obtain the location information of any patient at any time. The adversary inside the system can use an ordinary personal computer to obtain the location information of the designated patient within tens of seconds. In addition, in some cases, their scheme cannot be executed.(2)Using salting technology, we propose an improved BMPLS scheme to fix our attacks. We add Setup and Key generation phases to the scheme to provide the foundation for other phases and replace the Location verification phase with the Location extraction phase. We also optimized the BMLS scheme to make it correct and executable. The security analysis shows that the improved BMPLS scheme achieves decentralization, untamperability, confidentiality, multilevel privacy-preserving, retrievability, and verifiability. The simulation shows that the improved BMPLS scheme is practical, the computational overhead of the location record phase is within 10 ms, and the computational overheads of the location sharing and location extraction phases are both within 30 ms.
1.3. Organization
The rest of this paper is organized as follows. Section 2 presents preliminaries. Section 3 presents the architecture of BMPLS and reviews Ji et al.’s BMPLS scheme. Section 4 analyzes the scheme of Ji et al. Section 5 proposes an improvement to fix our attacks with security and performance analysis. Section 6 concludes this paper.
2. Preliminaries
2.1. Order-Preserving Encryption
Order-preserving encryption (OPE) is deterministic encryption that can preserve numerical ordering on their plaintext space [25].
An order-preserving encryption scheme consists of the following algorithms and :(1) is the key generation algorithm, takes as input the security parameter , and outputs a secret key .(2) is the encryption algorithm, takes as input a secret key and a plaintext interpreted as a numerical value , and outputs ciphertext interpreted as a numerical value .
They satisfy that for all
For with , a function is order-preserving if for all , iff . If an order-preserving encryption scheme is secure, then is a pseudorandom order-preserving function [25].
2.2. Merkle Tree
Merkle tree [26] provides efficient data authentication. A Merkle tree is based on a binary tree and a one-way hash function. The value of its leaf node is the data, and the value of its nonleaf node is the hash of the values of its two child nodes. If the Merkle tree has n leaf nodes, it only needs at most data to authenticate a leaf node, not all n data.
In our improved scheme, we need to calculate the Merkle tree of and Figure 1 is an illustrative example. In order to authenticate , we only need to provide and , then calculate and in sequence, and finally verify whether = .
3. Review of Ji Et Al.’s BMPLS Scheme
This section reviews the architecture of BMLS and Ji et al.’s scheme.
3.1. Architecture of BMPLS
BMLS can be used as a module of TMIS to manage and share patient location information. The architecture of BMPLS is shown in Figure 2. There are two types of entities in the system: location data owner (LDO) and location data requestor (LDR). LDOs, such as infectious disease or chronic disease patients, record their location information in the blockchain. LDRs request LDOs’ location information in different levels according to their trust levels and actual needs. For example, mobile clinics need to know the precise location of patients to provide them with on-site services; the medical center also requires an exact location to deliver the medicine. In contrast, infectious disease investigators only need to know the range of the patient, not the precise location.
3.2. Ji Et Al.’s BMPLS Scheme
Ji et al.’s BMPLS scheme consists of the following three phases [9].
3.2.1. Initialization
The location data owner (LDO) represents his visit region as a coordinate region , runs Algorithm 1 to generate the registration record , and puts it into the blockchain.
|
In Algorithm 1, the partition function . is the encryption algorithm of an order-preserving encryption scheme and is a hash function. denotes the function of using leaf nodes to generate the complete Merkle tree, denotes the function of converting the location record into the actual geographic location, and denotes the LDO’s signature.
3.2.2. Location Record
The LDO runs Algorithm 2 to generate a location record and puts it into the blockchain.
|
In Algorithm 2, is the encryption algorithm of the symmetric encryption scheme.
3.2.3. Location Sharing
The location sharing phase consists of the location sharing stage and location verification stage.
(1) Location Sharing. When the location data requestor (LDR) wants to obtain the location corresponding to , he generates a request and sends it to LDO.
The LDO returns location with corresponding granularity according to the trust level of the LDR. (1) If the LDR is fully trusted (level ), the LDO returns an accurate location. (2) If the LDR is semitrusted with level , the LDO returns a rectangular border with side length . See Algorithm 3 for details.
|
In Algorithm 3, is the encryption algorithm of a public-key encryption scheme. , and are the subscripts of , and , respectively. and are the Merkle tree data subsets required to authenticate and , respectively.
(2) Location Verification. After receiving the response , LDR runs Algorithm 4 to verify it.
|
In Algorithm 4, is the decryption algorithm corresponding to . denotes in and denotes the function that uses a Merkle tree data subset to calculate its root value.
4. Cryptanalysis of Ji Et Al.’s BMPLS Scheme
Ji et al. [9] claim that their BMPLS scheme achieves decentralization, untamperability, confidentiality, multilevel privacy-preserving, retrievability, and verifiability. Unfortunately, we find that their scheme has fatal flaws in confidentiality and multilevel privacy-preserving. In addition, in some cases, their scheme cannot be executed.
4.1. On Confidentiality
The adversary can recover any LDO’s location effectively.
Ji et al.’s BMPLS scheme uses the one-way property of the hash function to protect location. It is feasible and secure in the case of infinite (enough) locations. However, it is insecure in current practical applications because the amount of user locations is not enough to resist brute force attacks. The attack is as follows:(1)Calculate the coordinate hash table of all possible locations of the LDO’s visit region.(2)Obtain a record from the blockchain, and extract the hash value Loc .(3)Find out the location corresponding to in table .
We take the commonly used Global Positioning System (GPS) as an example to evaluate the feasibility of the above attack. In the GPS, the longitude and latitude output formats are dddmm.mmmm and ddmm.mmmm, respectively. So there are only positions in a square area of 1° in longitude and latitude. If estimated by 40°’ north latitude where New York City is located, 1 degree of longitude and 1 degree of latitude are equivalent to 85 and 111 kilometers, respectively, and a square area with 1 degree of longitude and latitude is 9,435 square kilometers. The land area of New York City is 789 square kilometers, so the number of available GPS locations is about .
We experiment on a personal computer using Python-3.9.7 and PyCharm Community Edition 2021.2.2 (64 bits). The configuration is CPU: Intel(R) Core(TM) i9-10900 CPU @ 2.80 GHz∼2.81 GHz, RAM: 64 G, and OS: Windows 10 Home (Chinese) 64 bits (10.0.19041). As in [9], we also choose SHA-256 as the hash function. The simulation result shows that the time cost to calculate the hash values of position coordinates is 27.01 minutes, and the size of the coordinate hash table is 77.20 GB. Therefore, using such a personal computer can calculate the hash value of all locations of New York City in about 13 hours and 33 minutes.
The above analysis and experiments show that if Ji et al.’s BMPLS scheme is used for New York City, the adversary can completely break the system in about 13.55 hours using a personal computer.
If we use supercomputers or adopt distributed computing or cloud computing technology, we can break the system with very little time overhead.
4.2. On Multilevel Privacy-Preserving
Semitrusted LDR Can Obtain Accurate Location. Ji et al. claim that, in their scheme [9], semitrusted LDR is impossible to reduce the privacy protection region. Unfortunately, we found that semitrusted LDR can recover the LDO’s accurate location effectively. This is a more severe attack than reducing the privacy protection region. The attack is as follows:(1)Obtain a record from the blockchain, and extract the hash value .(2)Run Algorithm 3 interactively with LDO to obtain the response .(3)Run Algorithm 4 to verify the response and extract the rectangular border .(4)Search for the location where the hash value is equal to in the rectangular border ; that is, run Algorithm 5 to obtain the accurate location information .
|
Take as an example to illustrate how to make traverse . Because order-preserving encryption requires the plaintext to be a positive integer, the format of the location needs to be changed from ddmm.mmmm to ddmmmmmm. Note that there are no location coordinates like , … , and must be divided into and . Then, the former is expressed as “” and the latter as “.”
We evaluated the feasibility of this attack in the above environment. Assume that the rectangular border is a square area with a longitude and latitude of 0.5 minutes each. This is a rectangular area with a length of 928 meters and a width of 710 meters. The simulation result shows that the average cost to calculate the accurate location in such an area is 20.75 seconds.
If a supercomputer is used or distributed computing or cloud computing technology is adopted, the time for LDR to find the accurate location will be milliseconds.
4.3. Other Weaknesses
(1)In [9], the coordinates and may not be integers. But in Definition 1 of [9], the plaintext space is clearly defined as the integer set . Therefore, it will not be feasible to encryptandin Algorithm 1(lines 3 and 4).(2)The LDO’s location coordinate or may happen to be a position grid coordinate or . If it happens, multilevel privacy protection will not be achieved. For example, if , then we have or for any trust level n. Then, the inequality in line 15 of Algorithm 4 will not hold, so LDR will not accept any rectangular border provided by LDO. Further, because or , LDR will determine that the x-coordinate of LDO is or .(3)The n-level rectangular border must be in the form of , to ensure that the privacy protection region will not be reduced. If the LDO’s location coordinate or satisfies or , then have or . In this case, both Algorithms 3 and 4cannot be executed.(a)Because 0 is not in the plaintext space of order-preserving encryption, Algorithm 3 cannot generate the ciphertext (or ) of (or ) (see Definition 1 of [9]).(b) and are used when calculating and , but they are not used when calculating and , which will make neither nor holds.
5. Improvement
We present an improvement to fix our attacks in this section and optimize the BMLS scheme to make it correct and executable.
5.1. Ideas for Improvement
The main improvement ideas are as follows:(1)Add Setup and Key generation phases to the scheme to provide the foundation for other phases.(2)Replace the Location verification phase with the Location extraction phase. The original location verification algorithm only returns the verification result but not the location, while our extraction algorithm returns the location with the verification result.(3)Use “Salt” to prevent brute force attacks. When calculating the hash value of the location , select a random number (salt) and let . As long as the length of the random number is large enough, the brute force attacks in Sections 4.1 and 4.2 cannot be implemented, even with supercomputers or cloud computing.(4)Use integer steps to generate grid coordinates to ensure that the coordinate values are positive integers.(5)When the LDO’s location coordinate or is equal to the grid coordinate or , we make a minimum positive disturbance to the location coordinates to ensure they are not equal. In GPS, the minimum positive disturbance is 0.0001 minutes. This disturbance is only 18.5 cm and does not affect the actual performance of the system.
5.2. Improved Scheme
The improved BMPLS scheme consists of the following five phases.
5.2.1. Setup
(1)Choose an order-preserving encryption scheme and set up public parameters [25].(2)Choose a public-key encryption scheme , such as RSA1024 and RSA2048, and set up public parameters.(3)Choose a signature scheme , such as DSA1024 and DSA2048, and set up public parameters.(4)Choose a symmetric encryption scheme , such as AES128 and AES256, and set up public parameters.(5)Choose a one-way collision resistance hash function , such as SHA256 and SHA512.(6)Set up and deploy a membership service provider (MSP) to maintain the identity of all users in the system and issue certificates for authentication and signature verification [27].(7)Set up and deploy a trust level service provider (TLSP) to maintain the trust level of all users in the system and provide trust level query services [28].
5.2.2. Key Generation
(1)LDO runs ’s key generation algorithm twice and obtains his x-coordinate encryption secret key and y-coordinate encryption secret key , respectively.(2)LDO runs ’s key generation algorithm and obtains his public-key and signing key .(3)LDO chooses his secret key for (4)LDR runs ’s key generation algorithm and obtains his public-key and private key .
5.2.3. Initialization
LDO selects the origin , step lengths , and partition level such that can cover his visit region properly. Assume that and have all been converted into positive integers. For example, convert and into and , respectively. We choose the order-preserving encryption scheme that allows the plaintext to be 0.
Denote the visit region as . LDO executes Algorithm 6 to generate the registration record and puts it into the blockchain.
|