A novel privacy protection method of residents’ travel trajectories based on federated blockchain and InterPlanetary file systems in smart cities

Blockchain-based privacy protection for data in smart cities

Blockchain technology can provide data immutability to ensure the authenticity and accuracy of data in smart city management. Considering that users in smart cities require a wide range of services on a daily basis, which leads to a large amount of user personal information being collected and controlled by service providers, Mohammadinejad & Mohammadhoseini (2020) introduces an automatic access control manager based on blockchain networks without the presence of a third party, creating a secure channel between users and services and the possibility of their databases being misused or hacked. She et al. (2019) proposed a homomorphic federated chain for SHS sensitive data privacy protection (HCB-SDPP) based on traditional smart home systems. The model designs a homomorphic encryption algorithm based on pallier encryption to encrypt smart home data, and uploads sensitive data from encrypted all gateway nodes to the federated chain to ensure the security of sensitive data. The convergence of healthcare and smart cities can enable the use of health and medical data from around the world, which also poses challenges to the privacy of patients’ health information and the security of nearby mobile health users. Tripathi, Ahad & Paiva (2019) proposes a blockchain-based smart healthcare system framework to provide the inherent security and integrity of the system and ensure that the privacy of patient data is not compromised, Zhang & Lin (2018) proposed a PHI (private health insurance) data privacy protection scheme combining federated and private chains. In this scheme private blockchain is used to store the PHI of hospitals and the federated blockchain is responsible for recording the secure index of PHI and using public key encryption and keyword search to achieve data security and privacy protection on the federated blockchain. The Internet of Things (IoT), as a gas pedal for smart cities, requires the extensive use of distributed smart devices to collect and process data in smart city infrastructures. Kumar et al. (2021) proposes a specialized protection and security framework (PPSF) based on blockchain, which supports Internet-driven smart cities through two key mechanisms: privacy protection mechanism and intrusion detection mechanism.

IPFS in data privacy protection

IPFS, with its high security and efficiency, has also been heavily used in recent years in the area of data privacy protection. Liang et al. (2022) and Song et al. (2022) use an improved homomorphic encryption mechanism and SM4 homegrown commercial security algorithm to encrypt raw data, proposing a federal blockchain-based privacy protection scheme for personal data. The federated blockchain combined with IPFS to store encrypted data improves data transfer efficiency, safeguards user privacy and security, and proposes ciphertext policy attribute-based encryption to achieve fine-grained access control. In the IoT research, Hasan et al. (2022) proposes an advanced security model for IoT multimedia data sharing through blockchain combined with IPFS, which solves the security issues brought by centralized data storage. In the IoT research, Dhar, Khare & Singh (2022) proposes an advanced security model for IoT multimedia data sharing through blockchain combined with IPFS, which solves the security issues brought by centralized data storage. Kumar & Tripathi (2021) proposes a federated blockchain network with smart contract support to ensure security and privacy in the Internet of Medical Things (IoMT). The network integrates Interplanetary File System (IPFS) cluster nodes to secure and authenticate devices and provide secure storage management through IPFS cluster nodes. Gupta, Shukla & Tanwar (2020) proposed an approach called AaYusH (Ethernet Smart Contract (ESC) and IPFS-based TS system) to provide technical support for telesurgery systems, in which IPFS effectively reduces storage costs and provides reliable privacy protection of system data. In order to alleviate the problems of limited scalability and poor storage scalability brought by blockchain, which lead to the inability to directly combine blockchain with IoT under existing conditions. Li, Yu & Wang (2022) proposes a three-tier architecture blockchain (TBchain) architecture combined with IPFS to provide high performance privacy protection for IoT data stored on the blockchain. In the Dwivedi, Amin & Vollala (2021), IPFS is combined with blockchain to achieve car insurance driving data sharing for traffic congestion mitigation by applying it to a vehicle-based self-organizing network (VANET). In this scheme, the decentralized characteristics of blockchain and IPFS are used to achieve fully distributed storage of data and ensure the security of vehicle driving data. Focusing on EHR privacy protection in healthcare management, (Jayabalan & Jeyanthi, 2022) integrates the blockchain framework with the Interplanetary File System (IPFS) to enable healthcare organizations to maintain fail-safe and tamper-proof healthcare ledgers in a decentralized manner. Meanwhile, Lin & Zhang (2021) proposes a privacy protection method based on blockchain and improved IPFS to alleviate data privacy issues in IPFS by adding a data access mechanism to prevent potential privacy breaches during IPFS transmission.

Inspired by the above-related work, this article proposes a privacy protection method for smart city residents’ travel trajectories based on federated blockchain and interstellar file system, which assists government departments in effectively controlling the spread of epidemics while ensuring the security of city residents’ trajectory data.

Residents’ travel trajectories data

A resident trajectory is a collection of data formed by a resident visiting a location at a certain time. When a resident visits a location at a certain time, the outbreak prevention and control department can obtain the resident’s geographic location in real-time through official location service providers including but not limited to GNSS, Bluetooth, cell towers, and WiFi.

As shown in Fig. 1, ( $l_1$, $t_1$) means that the resident visited location $l_1$ at time $t_1$, after which all the collected location information of the resident in 1 day is integrated to form the travel track data of the resident on this day. The complete resident travel trajectory data includes information such as personal name, cell phone number, file’s creation time, names of all visited locations, and specific geographic locations of visited locations. For the convenience of discussion, the travel trajectory data is simplified into three parts: user ID, visit location and visit time in this article. For example, the travel trajectories of residents $U_1$, $U_2$, and $U_3$ for 1 day are shown in Fig. 1, then the travel trajectory of $U_1$ for that day is expressed as $U_1=⟨(l_1,t_1),(l_3,t_2),(l_2,t_3),(l_4,t_4)⟩$, the travel trajectory of $U_2$ is expressed as $U_2=⟨(l_1,t_1),(l_5,t_2),(l_6,t_3)⟩$, and $U_3=⟨(l_4,t_1),(l_2,t_2),(l_3,t_3),(l_6,t_4)⟩$. The local epidemic prevention and control department collects the travel trajectories of all residents living in the area in 1 day, forming the travel trajectory data RTT = { $U_1$, $U_2$, $U_3$} of the residents in the area on this day.

Hyperledger Fabric

Hyperledger Fabric is a distributed ledger solution platform based on a modular architecture that provides a high degree of confidentiality, resilience, flexibility and scalability. Hyperledger Fabric is a non-fully public blockchain that helps protect the privacy of residential travel data, which is often highly sensitive. Hyperledger Fabric does not require expensive mining calculations to submit transactions through pre-specified membership and strict access policies, so it helps build blockchains that can scale with shorter latency of the blockchain. To ensure the security of communication, Hyperledger Fabric supports TLS for transport layer security for communication between nodes, and the ledger is only shared among organizations participating in the common bookkeeping, while other organizations do not have access to the ledger, setting strict permission control for accessing resources. In terms of privacy protection Hyperledger Fabric implements a private data mechanism to solve the problem of allowing certain private data to be shared among only a small number of organizations in a ledger with multiple participating organizations.

Interplanetary file system (IPFS)

IPFS is a distributed file storage system that assigns unique storage addresses to files uploaded to the system and the hash addresses of IPFS files cannot be changed, so IPFS is a tamper-proof storage mechanism. It differs from the HTTP protocol in that the data is stored in a distributed manner in the system built on IPFS, whereas the HTTP protocol places the data on the server side, which puts tremendous pressure on the server. IPFS addressing is based on the principle of content addressing, and when data is stored in the IPFS system, the system returns a hash value based on that data. According to the principle of the hash function, even if only minor changes are made to the information, a completely different hash value will be obtained. This feature will ensure that data on IPFS will not be tampered with. When requesting data from the IPFS file system, it will use the distributed hash table to find the node where the requested data is located and request the data back in that node. these features of IPFS make the perfect combination of blockchain technology at the application level to provide a distributed storage solution for traditional blockchain programs.

Entities and nouns

The system model framework of the proposed approach in this article is shown in Fig. 2, and the entities and terms involved in the system framework diagram are explained next in the following:

• 1) PKI/CA: Public key infrastructure (PKI)/certification authority (CA) is a trusted third party (in this system, it is a government department) that generates a CID corresponding to the identity of each user who joins the system. Based on the CID, the attribute authority sends the identity-related attribute set and key to the user.

• 2) Departments: Departments are the epidemic prevention and control departments in different regions. The epidemic prevention and control departments in each region collect the travel data of residents through the base stations and WIFI connected to the residents’ cell phone signals and share the trajectory data with the epidemic prevention and control departments in other regions in the system.

• 3) Users: Users in this system refer to the staff of the epidemic prevention and control department, who is responsible for uploading, querying, and downloading the specific operations of the residents’ travel trajectory data.

• 4) Block_Index: To relieve the storage pressure of the blockchain and ensure the security of the travel track data, the system only stores the easily searchable Block_Index on the blockchain. Block_Index consists of the storage address of residents’ travel trajectory in IPFS, AES encryption key, Location_ID, and CreateTime. The storage address of IPFS and the AES key is encrypted by the public key of the data recipient, and the geographic location of the resident’s travel track data and the CreateTime are not encrypted for the convenience of the query.

• 5) IPFS: Due to the practical limitations of cost, storage capacity, and other factors, a large amount of residents’ travel track data is stored encrypted outside the blockchain. IPFS can assist the blockchain to store the cipher text of residents’ travel track uploaded from the client by the staff of the epidemic prevention and control department to reduce the storage pressure of the blockchain.

• 6) Federated Blockchain: Blockchain can be considered a secure distributed database ledger. The federated blockchain network in this system consists of different regional epidemic control authorities, which store the encrypted index on the blockchain to ensure security.

Method implementation

In general, our method uses AES encryption for residents’ travel trajectory data in advance, uploads the encrypted data to IPFS network and obtains the corresponding storage address in order to relieve the storage pressure of blockchain, and stores the address and AES key, Location_ID and file creation time to form an index to the federated blockchain network, through which users can query the data. At the same time, through the private data mechanism of the federated blockchain, it achieves that the travel trajectory data is only shared among a few organizations in the ledger of the participating organizations to exclude the risk of privacy leakage. The proposed approach is described in detail in the following four aspects: data encryption, data upload, data sharing, and data query. To simplify the description, the meaning of some special characters are shown as Table 1.

Staff U of the epidemic prevention and control department sends an application to the system, the PKI/CA generates an ID corresponding to its identity, and according to the ID, the attribute authorization authority sends the identity-related attribute set S and the public key $P{K}_{id}$ and private key $S{K}_{id}$ to the staff.

As shown in step 1 of Fig. 2, the local epidemic prevention and control department cooperates with official operators to obtain the location information of residents in real-time through the base stations accessed by residents’ cell phone signals and connected WIFI and integrates them to obtain the complete travel trajectory data RTT of all residents in the area (a detailed description of travel trajectory data can be found in Fig. 1).

Data sharing

The proposed method uses physical deployment as shown in Fig. 3 to share data among each other. The figure mainly includes Fabric nodes, IPFS nodes, WEB Service, and PostgreSQL database for system functions and interactions, and each epidemic prevention and control department joining the network maintains two types of nodes, Fabric nodes, and IPFS nodes. In this article, the epidemic prevention and control department maintains the endorsement node and the orderer node in the Fabric node in the system. Epidemic prevention and control departments in the network store the index data of residents’ travel trajectories at the endorser node, the endorser node runs the smart contract and endorses the result of smart contract execution and stores the data, then the ordering node collects the data and packages the transactions that satisfy the endorsement strategy into blocks to be distributed to each epidemic prevention and control department in the blockchain network. The IPFS cluster consisting of IPFS nodes runs between the epidemic prevention and control departments to store the cipher text of residents’ travel track data after AES encryption to reduce the pressure of blockchain storage. Finally, the WEB server is responsible for communicating with the fabric nodes, IPFS nodes, and business database servers to connect all epidemic prevention and control departments, break the data silos, and realize the sharing of residents’ travel track data among all epidemic prevention and control departments, to achieve the purpose of collaborative prevention and control of the epidemic by all departments while effectively protecting the privacy and security of residents’ travel track data. Algorithm 3 is the specific implementation of data access in the data-sharing process, the user sends a request to access the data, and the user first authenticates through the POI, and the corresponding Block_Index of the CRTT to be accessed to verify whether the correct trajectory data is being accessed. If the above verification is passed, the user decrypts Block_Index with his private key $S{K}_R$ and obtains the storage address, AES encryption key, Location_ID, and CreateTime returned by IPFS. Through the returned IPFS storage address, the IPFS network is accessed, and the nodes in the IPFS node group first verify the user’s identity and then retrieve the complete resident travel track encrypted data at the corresponding storage location in the system’s private IPFS network to send to the user after the verification is passed. After receiving the encrypted resident travel track data, the user decrypts the cipher text by using the AES key obtained when decrypting the Block_Index. Assuming that the AES decryption function used by the staff of a regional epidemic prevention and control department is $AE{S}_d$ and has AES key K, the user obtains RTT by decrypting.

Algorithm 3:

Data access.

Input: input Proof-of-Identity(PoI),Block_Index,SKR

Output: output Algorithm result

1 if PoI is valid and SKR is right SK then

2    Get HashCRTT,K from Block_Index;

3    M = HashCRTT;

4    N = Get Hash Value from IPFS;

5    if (M == N) and K is right AES_Key then

6       Return RTT;

7    else

8       Return Data access failed;

9    end

10 else

11    Return Access failed;

12 end

DOI: 10.7717/peerj-cs.1495/table-5

(3) $$RTT=AE{S}_d(K,CRTT).$$

RTT is the travel track data of the residents in that geographical location, and the user can download the data for use.

Data query

The specific process of data encryption, index construction, and data query by users is shown in Fig. 4. When the user sends a data query request, the user’s identity is first verified through the POI. Algorithm 4 is the query process of the encrypted index of the residents’ travel trajectory data. After the user passes the authentication, he enters his private key $S{K}_q$, and the system returns the encrypted index of all the data related to the user through the smart contract deployed for query within the system, which includes the $CRT{T}_s$ of encrypted residents’ travel trajectory data sent by the user to other epidemic prevention and control departments and the $CRT{T}_R$ of encrypted residents’ travel trajectory data received by the user. First, the user receives the Block_Index of these data returned by the system, and the user queries the Block_Index of the travel trajectory data he wants to get by Location_ID and CreateTime, and if the query is successful, the user gets the data index $Block\mathrm{\_}Inde{x}_{querry}$. The user decrypts $Block\mathrm{\_}Inde{x}_{querry}$ by $S{K}_q$ to obtain the storage address, AES encryption key, geographic location of resident travel track data, and CreateTime returned by IPFS, and finally obtain the complete residents’ travel track data by the Algorithm 3.

Algorithm 4:

Block_Index querry.

Input: input Proof-of-Identity (PoI),Location_ID,CreateTime,SKq

Output: output Algorithm result

1 if Peer node is Valid and SKq is right SK) then

2    BOD = Get Block_Indexs of CRTTs and CRTTR;

3    if Location_ID and CreateTime are in the BOD then

4       Return $Block\mathrm{\_}Inde{x}_{querry}$;

5    else

6       Return Query failed;

7    end

8 else

9    Return Access failed;

10 end

DOI: 10.7717/peerj-cs.1495/table-6

Security analysis

Our proposed method ensures the integrity and privacy of residents’ travel trajectory data.

Integrity

The proposed approach in this article uses a combined blockchain and IPFS storage structure, where the user integrates Block_Index into the blockchain transactions and stores CRTT within IPFS. As shown in Fig. 5 either changes to Block_Index or CRTT will result in a change in the hash value, thus ensuring that the stored data is immutable and traceable. If an illegal user wants to modify the hash of the current data stored in the blockchain system at the same time, it must mimic the master chain like the source chain so that the corresponding transaction can be accepted by most nodes, which is almost impossible to achieve due to the limitation of computing power. According to the hash rule, the hash values obtained by hashing two different files are different; therefore, the forged CRTT and Block_Index will not be shared and accessible. For tampering attacks, the data stored in the blockchain is immutable unless the blockchain is threatened by a 51% attack.

Privacy

The proposed approach in this article ensures the privacy of RTT from two aspects: 1. Pre-encrypted RTT using AES algorithm to form CRTT stored in IPFS, without the key K and $Has{h}_{CRTT}$ is unable to access the CRTT. And the Block_Index containing K and $Has{h}_{CRTT}$ is stored in the blockchain system, and the index cipher cannot be decrypted without the private key $S{K}_R$ of the data receiver. This ensures that only the designated data receiver can access the resident travel trajectory data sent out by the user2. As shown in Fig. 6, the Hyperledger Fabric federated chain architecture used in this article has a unique channel mechanism, and the data in different channels are isolated from each other and cannot be accessed arbitrarily, which means that all the data in Channel1 can only be accessed by Department1 and Department3. This enables the data sharing of residents’ travel trajectory data only among related epidemic prevention and control departments, ensuring the privacy of the data.

Performance analysis

Our system is deployed on a virtual machine with a 2-core CPU, 4GB RAM and Ubuntu 18.04 operating system, and we use the travel trajectory data of COVID-19 infected persons in Beijing, China in 2019, which is legally disclosed, as our test dataset. The performance testing consists of two main parts: (1) we first tested the upload/download time of files on IPFS and compared it with traditional cloud storage regarding the upload speed. (2) Querying and updating in smart contracts are the key operations of this system, and we used the Hyperledger caliper tool to test the performance performance of system queries and updates regarding the throughput rate and latency. The proposed method refers to the uploading of encrypted index of residential travel trajectory data and the query operation refers to the querying of encrypted index of residential travel trajectory data. We used Hyperledger caliper tool to test the performance of system queries and updates in terms of throughput and latency.

In the first experiment, we conducted an IPFS storage performance test, we selected files of sizes 1 MB, 5 MB, 10 MB, 50 MB, 100 MB, and 500 MB respectively, and tested the time required to upload files to IPFS and the time required to download files from IPFS, the test results are shown in Fig. 7A, from the figure we can find that the time required to upload files to IPFS is several times longer than the time required to download the file from IPFS. To prove that IPFS has a faster transfer speed, we compared the upload speed with traditional cloud storage. From Fig. 7B, we can see that when the file size is less than 10 MB, the upload speed of cloud storage is slightly faster than IPFS, but as the file size keeps getting larger, the upload speed of IPFS far exceeds that of cloud storage, and we have reason to believe that IPFS has better performance than cloud storage when transferring massive files.

Transaction latency is the average time elapsed from the time a transaction is submitted to the time it is added to the ledger and confirmed on the blockchain, and throughput is the number of valid transactions submitted per second (tps) on the blockchain in the second experiment, we fixed the number of transactions at 5,000 and obtained the average latency and throughput of the system by varying the send rate, and used this to analyze the performance of the system. We first tested the system query function for 10 rounds, increasing the send rate by 50 tps each time until 500 tps. Figure 8 shows the performance of the system query operation, from which the relationship between the performance of the chain code query function and the frequency of sending can be seen. From Figs. 8A and 8B, it can be seen that as the send rate value increases, both the throughput and the average latency increase. The system throughput reaches a maximum of 203 tps when the send rate reaches 300 tps, and the average delay increases with the send rate, and the delay increases significantly above 250 tps, indicating that the system can handle more than 250 tps, leading to transaction blocking.

Similarly, we test the system update function by increasing the send rate by 25 tps each time until 200 tps: Fig. 8 shows the performance of the system update operation. From Fig. 9A, we can see that as the send rate increases, the throughput rate also increases, and the system throughput reaches a maximum of 119 tps when the send rate reaches 150 tps, after which the system throughput decreases when the send rate increases further, and from Fig. 9B, we can see that the system average latency increases sharply when the Send Rate exceeds 125 tps. This situation indicates that the processing capacity of the fabric node reaches its maximum at around 125 tps.

Finally, we measure the performance metrics as the number of transactions to be processed by the blockchain increases from 200 to 2,000 tx. As shown in Fig. 10, we find that increasing the number of transactions leads to a linear increase in throughput, which starts to gradually decrease and flatten out when the number of transactions increases to 1,200 tx, which is the saturation point determined by the capacity of the nodes used in the test. In Fig. 11 the response time of the system query operation vs. the update operation is shown when the number of transactions goes from 200 to 2,000 tx, we can see that in the system the update operation takes more time than the query operation, at 2,000 tx it takes about 19s, but considering the performance of virtual machines we used for testing, we consider this to be within acceptable limits.