SENSH: a blockchain-based searchable encrypted data sharing scheme in smart healthcare

Data owners (DO)

The data owner (DO), often a healthcare organization, patient, or individual, holds the reins as the data custodian in the application scenario. Distinguishing between sensitive and public categories based on privacy levels, encompassing personal information, electronic medical records, health monitoring data, and personalized treatment plans. The DO’s responsibility includes uploading raw public data to the cloud, with sensitive data encrypted using AES to safeguard privacy and ensure secure storage. This encrypted data is then re-encrypted in the cloud for double security and subsequently indexed through a searchable mechanism that allows authorized users to perform keyword-based searches without decrypting the data. Smart contracts delineate the permissions and query conditions for data access, ensuring only authorized users can query the encrypted data. Consequently, the DO is pivotal in forging a secure, transparent, and controlled data-sharing environment within healthcare systems.

Data users (DU)

The data user (DU), which may consist of doctors, research organizations, or insurance companies, is the entity that initiates data access and query requests. The DU employs the ciphertext search function to retrieve encrypted data associated with their privileges without decryption. The retrieved data is typically encrypted or processed, precluding direct access to plaintext. However, to perform a search, the DU must possess the appropriate permissions, including the acquisition of a token, prior to submitting the search request. This requirement significantly enhances data security and reinforces the effectiveness of access control measures.

Consortium blockchain (CB)

A consortium blockchain (CB) network (Li et al., 2018) established by organizations with shared interests allows nodes like hospitals, insurance companies, and research institutes to manage, store, and query data in a controlled environment. This network initializes the system and sets global data storage and access control parameters, enabling DO to regulate data user queries through intelligent contracts. Data labels and ciphertext hashes are stored on-chain, accessible only to authorized users, with all chain operations being tamper-proof and auditable, facilitating subsequent monitoring and tracking through contract-triggered event logs.

Cloud server (CS)

The cloud server (CS) serves as a proxy in the blockchain healthcare system (Wu et al., 2024), offering computation, storage, and proxy re-encryption services. It balances privacy protection with efficient data querying for organizations hosting data and managing keys. The CS’s primary responsibilities include proxy re-encryption, intermediating between DOs and users to grant access to authorized parties without DO involvement, streamlining key management, and enhancing privacy. It processes cryptographic keyword queries, matches tags, and returns re-encrypted results that meet authorization criteria without plaintext exposure, improving query efficiency and privacy. The CS also stores cryptographic tags and ciphertexts to support contract execution, tag generation, and updates, ensuring smooth permission verification and reducing the burden on the blockchain main chain. Overall, the CS bolsters data security management and enhances querying and data-sharing efficiency within the privacy-protected healthcare blockchain system.

The detailed description of each step in Fig. 4 is as follows.

Step (1): DO directly uploads public data to the cloud and stores it in plaintext.

Step (2): during the initialization of the federation chain system, the sensitive data is symmetrically encrypted off-chain using the global parameters generated by the system, and the generated ciphertext data and the tags generated by hash operation are stored in the cloud.

Step (3): the DO generates k′, and then the DO authorizes the CS as an agent to re-encrypt the data using the re-encryption key; and stores the tag and the re-encrypted ciphertext as a dictionary structure for subsequent retrieval.

Step (4): the re-encrypted ciphertext hash and label are stored synchronously in the chain for backup and tamper prevention.

Step (5): the DU initiates a request to the DO to share the medical data to obtain the data plaintext.

Step (6): DO returns relevant information that meets the scope of authorization based on the received request.

Step (7): the DU provides search keywords to the contract and initiates permission and query requests.

Step (8): the blockchain sends the search request to the CS immediately after verification.

Step (9): the blockchain returns the authorization information and token to the DU to facilitate subsequent authentication.

Step (10): CS returns the ciphertext matching the big token to DU according to the search operation.

Step (11): the DU cannot directly decrypt the obtained ciphertext data. In order to protect the initial key, the DU needs to request a re-encryption key k′ from the DO.

Step (12): DO verifies the identity information of DU and returns k′ to DU after passing the verification.

Step (13): the DU decrypts the ciphertext and obtains the plaintext data by using the obtained ciphertext and k′.

User authorization and revocation

Upon receiving a user address, the system initiates the process by computing the hash value of the address, denoted as userHash. It then verifies whether this address is already present in the authorization filter. In cases where the user lacks authorization, the userHash is incorporated into the authorization filter, and the user’s address is appended to the authorizedAddresses list. Following this, the system activates an authorization event to document the newly authorized user address, thereby ensuring the integrity and traceability of the authorization process—revocation follows a similar procedure. This sequence of operations is outlined in Algorithm 1.

Generate label and update

The system crafts a unique Label by utilizing the keyword provided by the user to generate a hash value $k_1$. This hash is combined with the data value $Endata$ and hashed again to produce a distinct label. Subsequently, an EncryptedData structure is constructed, encapsulating the label, re-encrypted value, existence status, and timestamp, and this structure is stored in the LEDD map. Concurrently, the generated label is appended to the allLabels list and recorded in the label filter. A label generation event is initiated, capturing the label and the encrypted value for record-keeping. This process is detailed in Algorithm 2.

Generate token

Upon receiving the label, the system generates a unique token based on it, which incorporates the version number, a count, and a hash value. The process begins by retrieving the token information associated with the label, incrementing the counter by one, and then generating the hash value $tokenValue$ using both the label and a keyword $k_2$. The system then initiates a token generation event to log the label and the newly created $tokenValue$. This sequence of actions is depicted in Algorithm 3.

Search

Upon receiving a tag, the system conducts an initial check to determine if the tag is present within the filter. If the tag is confirmed to exist, the system creates a result dataset named searchResults, which designates the first position to either the actual tag or leaves it blank. Following this, random obfuscation results are generated using an obfuscationfactor to populate the remaining entries in searchResults, which house the encrypted values linked to the respective tags. In conclusion, the fully compiled searchResults are returned, as detailed in Algorithm 4.

Storage efficiency

The proposed framework’s main storage components include the authorized user list, label generation information, encrypted data, token information, and user query results. It relies on mapping structures and Bloom filters for efficient data storage, significantly reducing space requirements. The contract initializes with preset sizes for the Bloom filter bit array and the number of hash functions to optimize storage. The authorized user list, managed by the Bloom filter, stores authorized users’ hash values, ensuring high storage efficiency, low cost, and quick verification of user rights. The LEDD structure records each label’s encrypted data and status information, with labels indexed in the Bloom filter’s labels filter for efficient searchability. Each label generates a unique Token, storing token information through token mapping. The search function employs an obfuscationfactor to introduce dummy results, preventing query information leakage. These dummy results are used transiently to minimize long-term storage overhead.

Computational efficiency

The computational load is primarily distributed across the Bloom filter hash calculations, label generation, and the obfuscation involved in search queries. Bloom filters utilize multiple hash functions for the add and lookup operations, effectively avoiding the need to store data for all elements through these functions. While the incorporation of the obfuscationfactor in the search function does introduce additional computational complexity, it achieves an effective balance between performance and security. The specific implementation logic is as follows:

the total time cost $C_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}}$ consists of two parts. The cost of off-chain time $C_{\mathrm{o}\mathrm{f}\mathrm{f}}$ and the part of the contract implementation on-chain $C_{\mathrm{o}\mathrm{n}}$. Among these, the symmetric encryption AES cost is $T_{\mathrm{e}\mathrm{n}\mathrm{c}}$, where $\alpha$, $\beta$, and $M_{\mathrm{l}\mathrm{e}\mathrm{n}\mathrm{g}\mathrm{t}\mathrm{h}}$ represent the encryption time per byte, the fixed initialization time, and the length of the plaintext, respectively. The label generation logic in the scheme is $L=H(H(U||v||T))$, which involves two hash operations, denoted as $T_{\mathrm{t}\mathrm{a}\mathrm{b}\mathrm{l}\mathrm{e}}$. $T_{\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{c}\mathrm{a}\mathrm{t}}$ and $T_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}$ represent the overhead of concatenation hashing and the cost of the hash operation, respectively. The specific formulas are as follows:

(6) $$T_{\mathrm{e}\mathrm{n}\mathrm{c}}(n)=\alpha \cdot M_{\mathrm{l}\mathrm{e}\mathrm{n}\mathrm{g}\mathrm{t}\mathrm{h}}+\beta$$

(7) $$T_{\mathrm{l}\mathrm{a}\mathrm{b}\mathrm{e}\mathrm{l}}=2\cdot T_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}+T_{\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{c}\mathrm{a}\mathrm{t}}.$$Next, the obfuscation query cost $T_{\mathrm{o}\mathrm{b}\mathrm{f}\mathrm{u}}$ and search token $T_{\mathrm{t}\mathrm{o}\mathrm{k}\mathrm{e}\mathrm{n}}$ are related to the addition of d pseudo-labels. Here, the token construction time is reduced to a simple hash calculation (other time costs can be ignored), and the overall search time is $T_{\mathrm{s}\mathrm{e}\mathrm{a}\mathrm{r}\mathrm{c}\mathrm{h}}$. Additionally, the gas consumption generated by contract deployment and execution is a direct influence, but it can also be obtained through the difference in time between the start and end of the timestamp. It is worth noting that each time cost $T_{\mathrm{i}}$ is measured multiple times, and the average is taken for comparison with other schemes. The relevant formulas are as follows:

(8) $$T_{\mathrm{o}\mathrm{b}\mathrm{f}\mathrm{u}}(d)=d\cdot T_{\mathrm{t}\mathrm{o}\mathrm{k}\mathrm{e}\mathrm{n}}$$

(9) $$T_{\mathrm{t}\mathrm{o}\mathrm{k}\mathrm{e}\mathrm{n}}=T_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}+T_{\mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}}\approx T_{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}$$

(10) $$T_{\mathrm{s}\mathrm{e}\mathrm{a}\mathrm{r}\mathrm{c}\mathrm{h}}=T_{\mathrm{t}\mathrm{o}\mathrm{k}\mathrm{e}\mathrm{n}}+T_{\mathrm{o}\mathrm{b}\mathrm{f}\mathrm{u}}(d)=(1+d)\cdot T_{\mathrm{t}\mathrm{o}\mathrm{k}\mathrm{e}\mathrm{n}}$$

(11) $$T_{\mathrm{i}\mathrm{\_}\mathrm{a}\mathrm{v}\mathrm{g}}=\frac{1}{N}\sum _{i=1}^N{T}_i.$$The above formula provides a theoretical estimate of the computational complexity of key operations in the SENSH scheme. Detailed empirical evaluation results corresponding to these calculations are presented in subsequent sections, clearly demonstrating the efficiency of encryption, label generation, token generation, and search operations in actual environments.

Gas cost

This scheme involves uploading data to the cloud and blockchain after off-chain encryption and decryption, with the focus of this article being on the deployment of smart contracts on the blockchain and the invocation and execution of the application binary interface (ABI) code. These operations incur transaction costs, referred to as “gas” in the context of Ethereum (Park, Lee & Kim, 2023). Gas is a metric for the computational effort required to execute an operation, with more complex operations demanding higher gas consumption. Following the setup of Remix, Ganache, and MetaMask experimental environments, the framework’s operational cost, precisely the gas fee for the access control process, is assessed. The initial balance of all accounts is set to 100 Ether, and the gas price is configured as follows:

(12) $$\mathrm{g}\mathrm{a}\mathrm{s}\mathrm{P}\mathrm{r}\mathrm{i}\mathrm{c}\mathrm{e}=\text{20,000,000,000}\mathrm{w}\mathrm{e}\mathrm{i}=20\mathrm{G}\mathrm{w}\mathrm{e}\mathrm{i}.$$The transaction fee (gasFee) is calculated by the formula:

(13) $$\mathrm{g}\mathrm{a}\mathrm{s}\mathrm{F}\mathrm{e}\mathrm{e}(\mathrm{g}\mathrm{a}\mathrm{s})=\mathrm{g}\mathrm{a}\mathrm{s}\mathrm{U}\mathrm{s}\mathrm{e}\mathrm{d}\times \mathrm{g}\mathrm{a}\mathrm{s}\mathrm{P}\mathrm{r}\mathrm{i}\mathrm{c}\mathrm{e}.$$The time estimation (ET) is calculated by the formula:

(14) $$\mathrm{E}\mathrm{T}(\mathrm{s}\mathrm{e}\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{d}\mathrm{s})=\frac{gasUsed}{BlockLimit}\times BlockTime$$where $gasUsed$ indicates the amount of gas consumed to execute the transaction, $BlockLimit$ indicates the maximum amount of gas usage a block can hold, and $BlockTime$ is the average time per block. The following is a simulation applied to a smart medical health management system, where the consumption of calling each function throughout the execution is shown in Fig. 7.

Authorization management

User permissions are authenticated using a Bloom filter, with all sensitive operations safeguarded by the onlyAuthorized modifier. The authorizeUser function adds authorized users, recording their hashes in the authorizedUsersFilter. In revocation cases, the revokeUser function eliminates the corresponding user hash and expunges it from the authorizedAddresses array, ensuring the accuracy and traceability of the authorization process. To verify its practical effectiveness, please refer to the accuracy of the Bloom filter mentioned in the Permission mechanism subsection and the natural gas consumption experiment results shown in Fig. 7.

Data generation and storage

The generateLabel function derives a unique hash label from the user-provided key K and the data value, storing it alongside the encrypted data in the LEDD map and registering it in the labelsFilter, ensuring uniqueness and verifiability of the label. The content of a label, including its encrypted value and timestamp, can be refreshed using the updateLabel function. Before updating, the label in the labelsFilter is confirmed, and a LabelUpdated event is triggered post-update, facilitating dynamic data management.

Event logging

Every instance of generation, authorization, update, and revocation initiates the corresponding event—such as LabelGenerated or UserAuthorized—ensuring that all state changes are immutably logged on the blockchain. This approach provides tamper-proof record-keeping, essential for subsequent auditing and traceability.

Computation cost comparison

The specific computational costs of each parameter are shown in Table 3, while Table 4 compares the computational complexity of several schemes. It can be observed that the scheme proposed in this article follows a strict encryption mechanism in terms of data encryption and combines the signature and verification techniques, which effectively guarantees the security and integrity of the data, while Li et al. (2021b) and Xiang & Zhao (2022) have certain deficiencies in this aspect. In addition, Li et al. (2021b), Ali et al. (2022), Xiang & Zhao (2022), Liu et al. (2023) all perform a large number of transaction query operations on the blockchain, which undoubtedly aggravates the computational burden on the chain. In contrast, the scheme in this article utilizes Bloom filters to achieve a more efficient data search, which balances query speed and storage efficiency. It is worth noting that this article’s scheme adopts a strict permission control and authentication mechanism, so the communication overhead between entities is relatively high (10C), which is designed to meet the needs of data interactivity and sharing. At the same time, the number of transactions recorded on the chain is small (2Tr), which effectively reduces the computational burden of the blockchain. In order to show the computational consumption of each scheme more intuitively, Fig. 8 visualizes the relevant data.

Transaction throughput analysis

Figure 9 compares the trend of transaction throughput with the number of transactions for the proposed scheme in this article under two consensus mechanisms, Proof of Authority (POA) and Proof of Workload (POW) (Chen, Nguyen & Sekiya, 2022). The results show that the transactions per second (TPS) of POA exhibits significant fluctuation characteristics in the process of incrementing the number of transactions from 0 to 500, with the value oscillating frequently between 1,000 and 6,000, and the instantaneous peak reaches more than six times of POW. This feature reflects the fact that POA relies on the mechanism of pre-authorized authentication nodes to quickly exit blocks and has significant high throughput potential under specific network conditions. In contrast, POW’s TPS is always stable below 1,000, showing a smooth linear growth trend, and its stability stems from the latency constraint inherent in the mining competition mechanism in POW. The results further verify that the scheme proposed in this article can effectively reduce the burden of on-chain computation under the POA consensus mechanism and improve the throughput performance of the system in large-scale transaction scenarios while ensuring the security and integrity of data. This provides a feasible engineering paradigm for application scenarios with high real-time requirements, such as medical data sharing and cross-border payment, under the environment of the coalition chain.

Comparison of average time consumption of algorithms

Figure 10 shows the comparison of the average execution time of four algorithms with different numbers of attributes, including data encryption, label generation, token generation, and search algorithm. It can be found that the proposed scheme shows superior performance in all four test projects. The time cost of each algorithm is calculated by the timestamps in the smart contract; specifically, the execution time of the algorithm is determined by measuring the difference between the start and end timestamps of the transaction. As shown in Fig. 10A, in the data encryption part, the execution time growth trend of the proposed scheme with the increase of the number of attributes is significantly slower than that of Xiang & Zhao (2022), and the advantage is more significant especially when the number of attributes is large; it can be found from Fig. 10B that, for the table generation, the proposed scheme always maintains the execution time lower than that of Liu et al. (2023), which shows high efficiency; for the token generation, Fig. 10C, despite the optimal performance of Xiang & Zhao (2022), the functionality of this scheme is relatively homogeneous, and the proposed scheme strikes a better balance between functional completeness and execution efficiency, and significantly outperforms Liu et al. (2023); lastly, for Fig. 10D, the proposed scheme is close to Xiang & Zhao (2022) in terms of search operations for small-scale attribute scenarios and consistently stays lower than (Liu et al., 2023) when the number of attributes increases in the execution time, demonstrating strong stability and efficiency. In summary, the proposed scheme has obvious performance advantages in various aspects, especially when the number of attributes is large, and its execution efficiency advantage is more prominent.

Permission mechanism

Assuming that there are m positions and k hash functions, the probability of misjudgment P of the Bloom filter can be expressed as:

(15) $$P={(1-{(1-\frac{1}{m})}^{kn})}^k.$$This misclassification probability is adjustable and is usually reduced by increasing m and adjusting k. Suppose an M_U tries to bypass the Bloom filter and access unauthorized data. Since Bloom filters are inherently irreversible, if the Bloom filter does not return a “may exist” result, the malicious user cannot access the data. Even if the malicious user tries to “guess” whether the data exists multiple times, he or she cannot obtain useful information through the Bloom filter. Therefore, Bloom filters are effective in preventing unauthorized access. The SENSH scheme efficiently verifies user permissions using a Bloom filter. Experimental results show that even when the number of entries reaches 50,000, the false positive rate of the Bloom filter remains below 0.15%, ensuring high authorization accuracy. Additionally, Fig. 7 indicates that authorization-related functions in SENSH consume an average of approximately 30% of gas, reflecting lower on-chain costs.

Privacy protection

The SENSH scheme ensures data confidentiality and query non-linkability through AES-based encryption and search token generation. In particular, sensitive health data is encrypted off-chain before being sent to the blockchain, and search tokens are generated through a combination of hashes of tags, versions, and other parameters, effectively preventing the leakage of sensitive information. As shown in Figs. 10A–10C, the execution time for data encryption, label generation, and token generation is significantly lower than other schemes, indicating that privacy protection operations are lightweight and suitable for real-time medical applications. Additionally, Fig. 7 demonstrates the end-to-end performance advantage of encrypted search operations in terms of gas consumption, while Table 4 confirms that the cryptographic operations involved (i.e., symmetric encryption and hashing) have acceptable computational complexity. These results confirm that SENSH achieves strong privacy protection while incurring only minimal performance overhead.

Anti-tampering

One of the defining attributes of blockchain technology is its tamper-evident nature (Moore et al., 2023). Each block is linked to its predecessor through the inclusion of the previous block’s hash, making any attempt at tampering evident as it would alter the hash values of all subsequent blocks. Additionally, Bloom filters exhibit an “insert-only” characteristic: once an element is added to a Bloom filter, it remains there permanently, precluding subsequent deletions. This design guarantees that once authorization records or encrypted labels are written to the chain, they cannot be modified or removed. Furthermore, our system leverages the blockchain’s immutable ledger, and this behavior is observable in deployment logs, where any unauthorized attempt to modify stored records is rejected or results in a new appended transaction rather than overwriting the existing one.

Anti-replay attacks

Each authorized user is authenticated by its hash identity. Assume that user U interacts with the system by generating a unique identifier $H(U)$ through a hash function H. The hash function H generates a unique identifier $H(U)$ for each user. An attacker cannot do this by replaying the sent requests because each request is timestamped or randomized with a random number N, making each request unique. In addition, timestamps T and user hash identifiers $H(U)$ are used in generating labels to prevent duplicate requests with the same content from being submitted. Any duplicate request is recognized and rejected because of different timestamps or unique identifiers. This mechanism has been validated in system testing, where duplicate queries with the same content but different timestamps are treated as independent requests, and attempts to reuse old requests are successfully identified and rejected by the contract logic. These behaviors confirm that SENSH can effectively defend against replay attacks in real-world applications.

During testing, we simulated multiple transactions where the attacker attempted to resend previously used requests. The system accurately detected duplicate tags or tokens and rejected these transactions. This validation was achieved through contract-level tag uniqueness checks and time randomization, ensuring that previously submitted queries cannot be reused. These behaviors confirm SENSH’s effectiveness against replay attacks in actual deployment environments.

Anti-DDOS attack

In this article, the scheme takes comprehensive defense measures from various aspects, such as request screening, cost control, and query obfuscation, to ensure the stability and availability of the system during the surge of malicious traffic. First, the introduction of Bloom filters for fast screening before data queries on the chain can effectively intercept forged requests or duplicate queries, avoiding the consumption of resources on the chain by invalid requests, thus alleviating the system load. Second, the scheme utilizes the blockchain’s inherent gas fee mechanism, and the cost per transaction constraint significantly increases the economic cost for attackers to launch invalid requests on a large scale, further reducing the feasibility of DDoS attacks (Tushir et al., 2021). At the same time, the scheme introduces an obfuscation factor into the query results to disrupt the attacker’s speculation on the access pattern of the data on the chain, avoiding the implementation of more targeted attacks through traffic analysis. The above mechanisms work in conjunction with each other to enhance the system’s ability to resist DDoS attacks. These mechanisms demonstrate through experimental results that forged or duplicate requests are rejected before consuming significant amounts of gas, while query obfuscation techniques prevent pattern-based inference.

In testing, we simulated transactions by sending a large number of invalid or duplicate queries. The results showed that the Bloom filter effectively filtered over 95% of duplicate or unauthorized requests before they reached resource-intensive on-chain operations, thereby saving gas and maintaining system responsiveness. As shown in Fig. 9, SENSH maintains stable transaction throughput under POA consensus, even under simulated stress, indicating its ability to withstand high-traffic query loads. Additionally, the gas-based cost model further demonstrates the effectiveness of this solution in defending against DDoS attacks by significantly increasing the economic cost of initiating large-scale invalid requests.