TrustHealth: Enhancing eHealth Security with Blockchain and Trusted Execution Environments

: The rapid growth of electronic health (eHealth) systems has led to serious security and privacy challenges, highlighting the critical importance of protecting sensitive healthcare data. Although researchers have employed blockchain to tackle data management and sharing within eHealth systems, substantial privacy concerns persist as a primary challenge. In this paper, we introduce TrustHealth, a secure data sharing system that leverages trusted execution environment (TEE) and blockchain technology. TrustHealth leverages blockchain to design smart contracts to offer robust hashing protection for patient s’ healthcare data. We provide a secure execution environment for SQLCipher, isolating all sensitive operations of healthcare data from the untrusted environment to ensure the confidentiality and integrity of the data. Additionally, we design a TEE-empowered session key generation protocol that enables secure authentication and key sharing for both parties involved in data sharing. Finally, we implement TrustHealth using Hyperledger Fabric and ARM TrustZone. Through security and performance evaluation, TrustHealth is shown to securely process massive encrypted data flows at a rate of 5000 records per second, affirming the feasibility of our proposed scheme. We believe that TrustHealth offers valuable guidelines for the de-sign and implementation of similar systems, providing a valuable contribution to ensuring the privacy and security of eHealth systems.


Introduction
The rapid digitization of healthcare services has led to the widespread adoption of electronic health (eHealth) systems.These systems are pivotal in streamlining operations, from patient data management to diagnostic processes, thereby significantly improving the quality of healthcare [1].However, this digital transformation also introduces substantial security risks, particularly regarding the privacy and integrity of electronic health records (EHRs).The vast volumes of sensitive data managed by eHealth systems are attractive targets for cyber threats, ranging from data breaches to unauthorized data manipulation.EHR data are used in a variety of scenarios related to healthcare management and patient care, such as early detection of disease [2].Outsourcing EHR to the cloud is a common solution to these challenges [3,4].This has the benefit of making eHealth system services more convenient, efficient, and flexible, but there are certain issues with data security and privacy.Once a healthcare provider uploads a patient's EHR to a cloud server, the patient no longer retains physical control over their data [5][6][7].Moreover, current cloud service providers merely offer assurances to protect data privacy to the extent that minimizes their own risk [8].Additionally, many instances of medical malpractice regarding the leakage of patients' medical records have occurred [9,10].From the perspectives of both patients and healthcare organizations, the privacy of medical data must be inviolable, as EHRs represent some of the most sensitive and critical data.Furthermore, the COVID-19 pandemic also highlights the need to protect the privacy of healthcare data [11].As a result, eHealth systems are eager to innovate with new technologies to ensure the security and privacy of healthcare data.
Recently, the emergence of innovative technologies such as blockchain [12] and trusted execution environment (TEE) [13] has offered a promising avenue for enhancing data security and protection.The immutability, auditability, and transparency of blockchain can protect data in distributed network work as compared to traditional centralized solutions [14].Due to its decentralized, tamper-proof, and distributed nature, blockchain ensures that each operation on EHR is recorded as a transaction, making it immutable and resistant to tampering.Thus, any patient can check the access record by checking the onchain transactions.Numerous studies have investigated the application of blockchain and smart contracts to bolster the security of eHealth systems [1,15].Compared to traditional centralized approaches, these studies use blockchain as a decentralized platform to provide functions such as storage, sharing, and auditing of healthcare data, which has many benefits but still has some drawbacks.Firstly, compared to traditional database solutions, blockchain-based electronic health systems exhibit lower efficiency in data retrieval [16].Secondly, the inherent limitations of blockchain technology result in high storage costs for large datasets.The decentralized and distributed nature of blockchain requires each participating node to maintain a complete copy of the entire blockchain.As the volume of data grows, the storage requirements for each node increase significantly, leading to substantial costs.While redundancy enhances fault tolerance and immutability, it also introduces significant storage overhead [17].Moreover, storing plaintext data on the blockchain raises serious privacy concerns, especially for sensitive information like EHRs [18].Fortunately, TEE focuses on runtime protection and secure storage of data [19].To protect the confidentiality and integrity of data, traditional cryptographic primitives have been widely adopted by cloud service providers, such as public key encryption [20][21][22][23], digital signatures [24,25], and message authentication codes [26].However, devices are easily exposed to various attacks in an open environment.Compared to software-only data protection solutions, those that integrate TEE can protect private data with enhanced security, leveraging robust hardware isolation mechanisms.With the combination of blockchain and TEE, the security and privacy of EHR in the eHealth system can be further improved.Thus, we can integrate blockchain and TEE into eHealth systems to achieve a high-level data privacy protection framework.
This paper introduces TrustHealth, a robust eHealth security framework that harnesses the strengths of both TEE and blockchain technology.The blockchain records fingerprints of operations, including data summaries, ensuring their immutability, while the TEE is employed to store EHR.We extend the functionalities of the open portable trusted execution environment (OP-TEE) [19], a widely used, open-source, trusted operating system designed for TrustZone.This extension not only ensures the confidentiality and integrity of the database but also establishes an isolated environment for the execution of sensitive operations during the processing of EHR.Our key contributions can be summarized as follows:

•
A secure database design atop TrustZone hardware ensures the confidentiality and integrity of EHRs.

•
We designed a TEE-empowered secure session key generation protocol to create a secure data-sharing channel between TEE and hospitals or healthcare institutions.

•
We performed a thorough security and performance analysis, demonstrating that TrustHealth is both efficient and practical.Experimental results indicate that Trust-Health can securely handle a large volume of encrypted data flows at a rate of 5000 records per second.
The remainder of this paper is organized as follows: Section 2 discusses related work.Section 3 presents Preliminaries.Section 4 describes the system design of TrustHealth, emphasizing the architecture and key components.Section 5 details the implementation.
In Section 6, the evaluation of the proposed system is presented.Section 7 discusses the security analysis.Finally, Section 8 presents the conclusion and future work.

Related Work
Recently, blockchain technology has been widely adopted to decentralize data management, thereby reducing the inherent risks associated with centralized systems.Blockchain's immutable ledger and consensus mechanisms ensure that all transactions are transparent and tamper-proof, making unauthorized data alterations easily detectable.Zhou et al. [27] introduced a human-in-the-loop-aided approach that employs a block design technique for privacy preservation in smart healthcare settings.However, the scheme requires training multiple machine learning models, which may increase computational costs and delays.Li et al. [28] introduced a novel public audit scheme that utilizes blockchain technology to verify data integrity.This scheme aims to tackle the issue of tampering with remote data stored in the cloud.Similarly, Yang et al. [4] implemented a shared medical record solution in the cloud using vertical partition of healthcare datasets.However, in cloud storage environments, there is usually a lack of trust between data owners and cloud service providers, so a mechanism is needed to ensure that cloud service providers do not leak or tamper with data.The HealthDep scheme [29] minimized server storage costs and enhanced healthcare data security through an efficient and secure encrypted EMR deduplication strategy.However, while these schemes focus on securing remotely stored data in the cloud, patients still lack real control over their medical data due to the distrust of cloud providers and open operating systems.
Recent studies have leveraged blockchain technology to empower patients with enhanced control over their medical data.The transparent and immutable nature of blockchain enables patients to dynamically manage access permissions to their EHRs, allowing them to grant or revoke access to various parties involved in their healthcare.This level of granularity and flexibility is pivotal in safeguarding sensitive health information and addressing the trust concerns associated with traditional cloud providers.MeDShare utilized blockchain technology to enhance medical data sharing among large data entities by offering data provenance, auditing, and control mechanisms [30].In another major study, MedBlock highlighted the need to propose a blockchain-based information management system that exhibits high information security while enabling efficient EMR access and inspection in a distributed ledger [31].Huang et al. [32] provided an in-depth analysis of zero-knowledge proof and the proxy re-encryption technology, showing that the blockchain-based privacy-preserving scheme satisfies confidentiality, integrity, and availability.Collectively, these studies employ either permissioned or public blockchains, depending on the specific requirements of their respective applications.Azaria et al. [33] introduced MedRec, an innovative record management system that leverages blockchain technology and smart contracts to effectively manage the EMRs of patients.MedRec not only supports patient-defined access control rules but also provides a unique reward system.The former enables access to medical information between different institutions, and the latter incentivizes medical stakeholders to actively participate in the network as "miners".Jiang et al. [34] proposed an IoT access control model CcBAC based on blockchain and cryptocurrency and supported by trusted execution environment technology.This model offers fine-grained, robust auditability and access process control, and its practicality has been verified through theoretical analysis and experimental evaluation.Cao [3] centered their research on blockchain technology, proposing a robust cloud-assisted eHealth system designed to safeguard outsourced EHRs against unauthorized tampering.Mandarino et al. [18] propose a hybrid storage strategy, where medical records are stored on users' devices, and blockchain merely manages the index of these data, thereby enhancing security and cost-effectiveness.Patients can set authorization policies through smart contracts, ensuring that only authorized entities can access their medical records.However, this system's reliance on the storage and computational capabilities of user devices may lead to data availability and security issues in the event of device failure or loss.However, its access control mechanism is somewhat coarse and lacks transparency.Although these studies have made considerable advancements, they still present certain limitations that require addressing.One of the main issues is the increased transmission, computation, and storage burden associated with blockchain, which needs to be considered when storing large amounts of data in practical scenarios.Additionally, the storage of significant amounts of data on the blockchain is very resource-intensive and is not considered from the perspective of hardware-assisted security.
Table 1 shows a summary of the comparison among several EHR solutions.Most blockchain-based EHR systems focus on addressing access control and ensuring the security of both on-chain and off-chain data.Access control is typically implemented using smart contracts, while data encryption is employed to protect the security of medical data.However, relying solely on encryption is insufficient to ensure the security of data during its use.It is crucial to ensure that medical data are both accessible to authorized entities and protected from unauthorized access during processing.In this study, we propose TrustHealth by integrating TEE with blockchain technology to address this critical issue.The use of TEE ensures that data remains secure even during its use, providing a secure environment for processing sensitive medical information without exposing it to potential threats.By leveraging TEE, TrustHealth ensures that medical data are not only protected at rest and in transit but also during computation, thereby enhancing the overall security framework of EHR systems.Furthermore, TrustHealth mitigates the risks posed by cloud service providers and operating systems.Traditional cloud environments and open operating systems may expose medical data to unauthorized access and tampering.However, with TEE, even if the cloud service provider or the operating system is compromised, the medical data processed within the TEE remain secure and confidential.This approach significantly reduces the risk of data breaches and unauthorized data manipulation by isolating the execution of sensitive operations within the TEE.On-chain: access control policies, Off-chain: IoT data

Blockchain
Blockchain is a decentralized, distributed ledger technology that ensures data integrity and transparency.There is no central node in the network, and all nodes are equal, using distributed ledger and consensus mechanisms.The failure or exit of a single node does not affect the entire system, providing good fault tolerance and robustness.All transaction data on the distributed ledger is public and transparent, and anyone can query and verify it.Confirmed transaction data are linked into blocks using cryptographic techniques, making subsequent data tamper-proof and ensuring the authenticity and immutability of the data [35].
Blockchain employs various consensus mechanisms to allow nodes to reach a consensus on the correctness of the data.Common consensus mechanisms include Proof of Work (PoW), Proof of Stake (PoS), Proof of Authority (PoA), Practical Byzantine Fault Tolerance (PBFT), and Raft [12].PoW requires nodes to solve complex mathematical problems to validate transactions and add them to the blockchain, which ensures security but is energy-intensive.PoS, on the other hand, allows nodes to validate transactions based on the number of coins they hold and are willing to "stake" as collateral, which is more energy-efficient.Raft is a consensus algorithm designed for managing replicated log consistency, ensuring high throughput and low latency, making it suitable for permissioned blockchain networks where nodes are known and trusted.These consensus mechanisms avoid the risks of single-point failures and data tampering that are common in centralized systems.Additionally, blockchain supports the deployment of smart contracts that automatically execute various application logic.Smart contracts are immutable, and their execution process is transparent and auditable [36].
Blockchain technology can be categorized into three main types based on its access permissions: public, private, and consortium chains.Each type of blockchain has its unique advantages and limitations, and the choice of which type to use depends on the specific requirements of the application, such as the need for transparency, security, and efficiency.Table 2 compares various types of blockchain platforms and their characteristics.

ARM TrustZone
ARM TrustZone is a hardware security extension integrated into ARM processors.It provides a secure environment known as the TEE that isolates sensitive operations and data from the rest of the system.TrustZone creates two separate worlds: the secure world and the normal world.At the hardware level, system resources (CPU, memory, peripherals, etc.) are divided into two logically isolated execution environments [37].The secure world has higher execution privileges and can access all system resources without interference from the normal world.The normal world can only access non-secure resources and cannot directly access secure world resources, ensuring the isolation and protection of critical data and code.The secure world provides the foundation for creating a trusted execution environment where security-sensitive code and data processing can be executed.Hardware-assisted security mechanisms ensure that code and data within the trusted environment are protected from theft, tampering, and other attacks.Additionally, the secure world can offer system-level security services such as key management, device authentication, and secure boot.Applications in the normal world can obtain encryption, authentication, and other security capabilities through the security service interfaces provided by the secure world [38].
OP-TEE is an open-source project that operates within the ARM TrustZone, a hardware-based security technology that creates an isolated execution environment.This separation, known as the secure world, is used for handling sensitive operations, while the normal world runs the standard operating system.OP-TEE enhances security by providing secure storage, supporting a range of cryptographic operations, and enabling the development of trusted applications that can perform critical tasks securely [39].These features make OP-TEE a crucial component for enhancing security in embedded systems by ensuring that sensitive operations are protected from potential threats in the normal world.

Threat Model
In TrustHealth, doctors and medical institutions can be trusted only during the treatment period, and they can violate the rules to manipulate EHR after the diagnosis period for different purposes, such as liability for medical disputes or increasing profits.Meanwhile, the cloud server providing various services is a rational entity, as commonly assumed in the existing literature [3,29].It is important to note that this study does not delve into behavior-related trust issues.Our primary focus is on ensuring data confidentiality, integrity, and authenticity using TEE and blockchain technology.For discussions on behavior trust, readers are referred to the following works [40,41].
Hardware.Assuming that an attacker manages to intrude on the device, we can rely on the hardware-enforced protection provided by the ARM TrustZone security extensions.Rollback attacks are out of our consideration, as they can be mitigated with hardware monotonic counters [42].
Normal world (NW).At the software level, the commodity operating system (COS) is typically considered insecure and susceptible to potential compromises.We consider that a powerful user can obtain permission to operate the file system, including reading, writing, and modifying the database file of SQLCipher.However, we make no assumptions about the NW in a rich execution environment (REE), which includes COS and user space.We note that the Linux kernel supports the OP-TEE driver and works properly.
Secure world (SW).We consider the software components of TEE, such as the security monitor, bootloader, and trusted operating system (TOS), to be secure and immune from vulnerabilities that could compromise the TEE.The trusted application (TA) uses the GlobalPlatform-defined API to interact with OP-TEE OS and cross-world communication channels.Side-channel attacks [43][44][45] are also beyond the scope of this paper.

Design Overview
This section provides an overview of our system's approach and key features of TrustHealth before diving into the details.There are five different entities: the patient, hospital, doctor, blockchain platform, and TEE-assisted server.
Patient.The patient, in search of medical services, utilizes a variety of computing devices, including personal desktops and wireless-enabled portable devices, to communicate with the hospital and the TEE-assisted server.
Hospital.The hospital includes multiple departments, such as Surgery, Internal Medicine, Pediatrics, Obstetrics and Gynecology, and more.While hospitals can be considered authorized users who may be curious about the data, they will not operate on patients' private data in an unauthorized or harmful manner.
Doctor.A licensed healthcare professional, the doctor is authorized to offer an extensive array of medical services to patients.
Blockchain platform (BP).The blockchain platform is composed of various nodes that collectively maintain an immutable evidence platform through the operation of a specific consensus algorithm.This platform supports the automatic execution of Turing-complete smart contracts and stores the hash of EHR.
TEE-assisted server (TS).The TS operates as the dedicated data storage server for hospitals, guaranteeing the secure storage and management of EHRs.In response to authorized patient requests for EHR access, the TS is responsible for retrieving and delivering the patient data.
The system architecture is shown in Figure 1.Now, we describe the steps involved in conducting a medical consultation within TrustHealth.The patient initiates identity registration, supplying supplementary information and symptom-related data.These data serve as the basis for generating diagnostic information.The diagnostic information includes essential details regarding the doctor, the appointment's timing, and location.It is protected through a shared diagnostic key, fostering data security between the hospital and the patient.Subsequently, the patient engages in a scheduled diagnostic and treatment session with the doctor.At the end of the diagnosis, the doctor creates the patient's EHR and corresponding hash value.This EHR hash is then securely stored on the blockchain to uphold data integrity and immutability.A trusted channel is established between the hospital and the TEE-assisted server.This channel enables the doctor to securely outsource the EHR data to the TEE-assisted server for secure storage.Ultimately, patients can readily authenticate the integrity of their EHR data by accessing both the blockchain and TEE-assisted server to retrieve and compare the stored EHR hash value with the corresponding EHR data.To better illustrate the functionalities and use cases of TrustHealth, consider a patient, Bob, who uses TrustHealth for the first time and grants his doctor, Alice, the necessary permissions to access and update his EHR.Bob then visits Alice for a medical consultation due to some symptoms he is experiencing.During the consultation, Alice accesses Bob's EHR stored on the blockchain.She retrieves the relevant medical history and diagnostic information, ensuring that all access requests are logged and verifiable.In TrustHealth, both patients and hospitals act as clients inter-acting with the blockchain.Patients use their devices to manage and access their medical records, while hospitals update and maintain patient records.Both types of clients leverage Hyperledger Fabric SDK for Go [46] to perform operations such as querying patient records, updating medical information, and managing access permissions.As part of the treatment, Alice updates Bob's EHR to include new diagnostic results and treatment plans.She securely stores these updates by interacting with the TEE-assisted server.The TEE-assisted server ensures that all sensitive operations, such as encryption and decryption of EHR data, are performed in a secure and isolated environment.This process guarantees the confidentiality and integrity of Bob's EHR, protecting it from unauthorized access and tampering.
In TrustHealth, the blockchain stores encrypted EHRs, hash values of EHRs for integrity verification, access control policies, and transaction logs.The TEE-assisted server, utilizing SQLCipher, stores encrypted EHRs, patient data, and cryptographic keys used for data encryption and decryption.The SQLCipher database supports common database operations such as CRUD (INSERT, SELECT, UPDATE, and DELETE), ensuring efficient data management and retrieval within the secure environment provided by the TEE.

Construction of TrustHealth
In TrustHealth, we assume that each patient completes registration at the hospital to ensure better access to care.In addition, patients are provided with a treatment key before diagnosis, facilitating the establishment of secure communication channels among the patient, hospital, and diagnosing doctor.All diagnostic information is protected by the treatment key.
Initially, the patient schedules an appointment with the hospital and acquires relevant diagnostic information.Before treatment, the patient generates a warrant to delegate the doctor to perform the treatment.The doctor generates an EHR for the patient after the diagnosis is completed.Patients may receive treatment from one or multiple doctors, resulting in multiple EHRs.In either case, each doctor is responsible for the EHR they generated.Subsequently, the hash of the EHR is recorded on the blockchain as a transaction, while the encrypted EHR, along with auxiliary information specific to the doctor, is stored on a TEE-assisted server.
A set of patients {P1, P2, …, Pn}, a TEE-assisted server, a set of doctors {D1, D2, …, Dx}, and a hospital H are involved in TrustHealth.TrustHealth consists of the following stages, as explained below.
Registration and Setup.Each doctor registers a new blockchain account and shares it with others, allowing patients to access information about the doctor, including basic details and diagnostic privileges.The TEE-assisted server also registers a new account on the blockchain and sends it to everyone, enabling medical institutions and individuals to access its public information.Additionally, the TEE-assisted server and the hospital store their identity certificates and public keys on the blockchain platform to facilitate secure authentication.During the initialization process, the TEE-assisted server securely stores all the information of the doctors in the hospital.For a patient, Pi, the hospital randomly assigns a treatment key, Ptk.
Appointment and Delegation.The patient and hospital make an appointment, and the hospital assigns a doctor to the patient.The interaction between the patient and the hospital is protected by the treatment key.The hospital sends the appointment details to the patient and the treatment key to the doctor through a secure channel.The patient decrypts and extracts the appointment information to obtain the doctor's IDD, the valid period TimePeriodP, and some auxiliary information AuxP, such as specialty and introduction.During delegation, there are two scenarios: (1) a single doctor is responsible for diagnosing and generating, uploading, and storing the EHR, and (2) a group of doctors is responsible for diagnosing the disease, with each doctor generating and uploading their EHR and the last doctor storing the entire EHR.
Case DI creates a transaction Tx(DI), which contains the following data:

H(IDP)||H(IDDI)||H(ehrP,I). DI sends CP,I to TS. TS will verify DP,I's identity by querying the database, and if the verification passes, TS accepts (DI, CP,I, WP,I).
Data Sharing.To protect the security of the data sharing phase, we designed a TEEempowered session key generation protocol combined with blockchain.The TEE-assisted server and hospital establish a key negotiation with authentication, ensuring the establishment of a shared secret key and verifying the authenticity of the communicating parties.The TOS kernel utilizes the Diffie-Hellman (DH) key exchange algorithm provided by the OP-TEE encryption library (either Libtomcrypt [47] or Libmbedtls [48]) to securely generate shared secret keys.The data-sharing mechanism is depicted in Figure 2 and can be briefly summarized as follows.
Step 1: The hospital generates a DH key A = g a and sends the public key A to the TEEassisted server.
Step 2: The TEE-assisted server transfers A to the TOS.TOS kernel also generates its own DH key B = g b and computes the shared secret key SK based on <A, B>.To ensure the integrity and authenticity of the exchanged information, the TEE-assisted server signs both A and B, resulting in SignAB.TOS sends B, SignAB, and SK to TA.
Step 4: The hospital receives the data from the TEE-assisted server and begins the verification process.It verifies the validity of SignAB by accessing the blockchain to obtain the public key of the TEE-assisted server.The hospital then computes the shared secret key SK based on <A, B>.Similar to TA, the hospital derives the session key SKsess using the HKDF function.
Step 5: The hospital signs A and B using its signing key PrivH and sends Sign(A||B) to the TEE-assisted server.
Step 6: The TEE-assisted server uses the hospital's public key obtained from the blockchain to verify Sign(A||B).Once the verification is successful, a trusted channel is established between the TEE-assisted server and the hospital using the derived session key SKsess.Subsequently, data are securely transmitted from the TEE-assisted server to the hospital through this trusted channel.

Blockchain Platform
Hyperledger.TrustHealth is built on the permissioned platform Hyperledger Fabric.We selected Hyperledger Fabric due to its suitability for permissioned networks [49], where participants are known and trusted entities, making it ideal for medical institutions.Hyperledger Fabric offers a highly modular and configurable architecture, allowing customization of various components such as the consensus mechanism, membership services, and smart contracts [50].Furthermore, Hyperledger Fabric is designed to handle high transaction throughput, which is essential for a system like TrustHealth that needs to process numerous transactions efficiently.The technology and modularity of Hyperledger Fabric simplify the development process by separating the core system from the application domain, allowing applications to choose transaction rules, govern access permissions, and select consensus algorithms.Additionally, being part of the Hyperledger framework, it is developed and maintained by the Linux Foundation, ensuring robust support and continuous improvement.
Consensus.Considering the low possibility of malicious nodes within medical institutions and the fact that the whole system uses mechanisms such as digital proofs and cryptographic algorithms to enhance security, we chose the Raft consensus mechanism [12].Raft is a leader-based consensus algorithm that is simpler and more efficient compared to more complex algorithms like PBFT.This simplicity helps in reducing the system's complexity and operational costs.Furthermore, Raft enhances system throughput by minimizing the communication overhead required for consensus, making it wellsuited for environments where high performance and low latency are critical.
In TrustHealth, we utilize the Hyperledger chaincode as the smart contract.The smart contract is responsible for defining and executing the logic related to handling data hashes on the blockchain.In the context of a proposed transaction, other applications can invoke the smart contract to read and modify data on the blockchain.The primary functions of the smart contract involve querying and updating the hash of the EHR.The logical flow of the smart contract is presented in Algorithm 1.In the following, we describe the smart contract implemented to manage patient records within the TrustHealth system.The code is written in Go language, utilizing the Hyperledger Fabric SDK.This section details the primary functions of the smart contract, which include creating, querying, and updating patient records.
Create: This function is called to create a new patient record.
• patientID: The unique identifier for the patient.• create_Time: The timestamp when the patient record is created.• status: The current status of the patient.

•
EHR_Type: The type of electronic health record.

•
EHR_Hash: A hash value associated with the patient's EHR, used for data integrity verification.

•
Hospitals: The list of hospitals associated with the patient's care.
Query: This function is called to retrieve a patient record using their unique identifier.
• patientID: The unique identifier for the patient.
Update: This function is called to update the patient's status, EHR hash, update time, EHR type, and associated hospitals.

Secure Database Services
To ensure the secure operation of EHRs, we integrate SQLCipher within TEE [51].SQLCipher is a widely used, lightweight, portable, low-memory relational database written in ANSI-C with a simple and easy-to-use API.Specifically, SQLCipher is based on SQLite [52] with added encryption and decryption features.This approach offers several advantages.Firstly, it supports AES encryption and decryption of database files, increasing the security of data stored on the disk.Secondly, it allows TEE to support the secure relational database, which enriches the application scenarios.However, it is not enough to protect data in memory, as data can be lost after a power failure, which is unacceptable for doctor and patient privacy data.Therefore, we implemented data persistence for SQLCipher running in TEE.Moreover, we extended OP-TEE to provide the same file system calls as SQLCipher.By introducing a customized set of file system calls based on secure storage, we enable SQLCipher to run as it does in REE.
Encryption/decryption interface.In SQLCipher, we implemented an encryption and decryption layer based on the Libmbedtls library.The modifications primarily encompassed the integration of encryption and decryption interfaces and the addition of specific system calls.These changes involved the adaptation and substitution of the OpenSSL library (version 1.1.1f)with the Libmbedtls library, thereby enhancing the security and encryption standards within the TrustHealth framework.Moreover, key functions such as the random, hmac, kdf, and cipher were implemented to seamlessly incorporate SQLCipher into TrustHealth.Each database is stored as an individual encrypted file (*.db), and AES-CBC encryption and decryption are performed using the Libmbedtls library.
File system calls.OP-TEE originally only provided secure storage interfaces and lacked comprehensive file operation interfaces.To ensure the consistency of file operations and the security of disk operations using SQLCipher, we have implemented a more extensive set of encrypted file interfaces based on the native secure storage design of OP-TEE.These interfaces include read, write, and open operations, which encrypt file blocks and inter-act with the disk through RPC requests, ensuring the security of file operations within a trusted environment.Specifically, we have reimplemented the file system API in OP-TEE, which comprises 17 system calls.These system calls encompass various aspects of file and directory operations, such as hardware-protected directory creation, directory deletion, access checks, synchronization, and the configuration of file permissions and masks.The functionality interfaces and features are detailed in Table 3.Additionally, we added the new instruction CFG_NEW_FS to the compile instruction set in our prototype, simplifying the process of enabling, compiling, and disabling new file system features.To support SQLCipher in TEE, we made some adjustments to the SQLCipher, but these modifications only need to be performed once and are not dependent on a particular OS version, ensuring their reusability.We believe that the advantages of supporting a secure database in the TEE compensate for this limitation.Synchronization Hardware protection, flushing file data from memory to disk.20

Experiment Setup
We developed TrustHealth using TEE and Hyperledger Fabric (v2.3).We integrated the secure database SQLCipher into a TrustZone-enabled development board equipped with the Kylin V10, a 3 GHz ARM 64-bit CPU, and 16 GB of RAM.The development board served as an ideal environment for running both SW and NW applications, and it provided the essential infrastructure for conducting all experiments related to TrustHealth.It is worth noting that TA was written using C language.To implement the cryptographic algorithms within TrustHealth, we leveraged the cryptographic libraries provided by the OP-TEE framework, including Libtomcrypt [47] and Libmbedtls [48].These libraries support various cryptographic operations, such as hash functions, digital signatures, and key exchange, ensuring robust security for our system.
To comprehensively evaluate the effectiveness of TrustHealth, we define the following key performance and security metrics.These metrics ensure the system meets the necessary standards for secure and efficient eHealth data management.
1. Data Confidentiality: Ensures that all sensitive healthcare data are protected during transmission and storage, preventing unauthorized access.This metric evaluates the system's ability to keep data confidential.2. Data Integrity: Ensures that healthcare data are not tampered with.This metric evaluates the system's ability to detect and prevent unauthorized modifications to the data.3. Resistance to Forgery and Tampering: Measures the system's ability to prevent unauthorized entities from generating or modifying EHRs.This metric evaluates the system's defenses against forgery and tampering attempts.4. Response Time: Measures the time taken for various operations (create, query, and update) to ensure the system remains responsive.This metric evaluates the system's performance under different levels of load and concurrency.5. Communication Overhead: Calculates the time from sending a request to receiving a response, including connection setup and data transmission times.This metric evaluates the efficiency of data transmission in the network.6. Secure Database Performance: Analyzes the time overhead for database operations, including CRUD operations, to ensure operational efficiency.This metric evaluates the impact of data management on overall system performance.

Performance of Blockchain
We rigorously tested the performance of three smart contracts, namely create, query, and update.To achieve this, we utilized http_load [53], a widely recognized tool for conducting load tests.Our experiment included setting the number of concurrent users to 500, and the duration of the test was set to one minute.The results indicated that http_load achieved a 100% success rate.Figure 3 shows the performance of the three smart contracts under 500 concurrent users.Our findings indicate that query functions exhibited relatively faster since they did not modify existing data.In contrast, the create and update functions modify the data, thereby requiring modifications to the underlying database of the blockchain.Comparing the two sets of data, we can observe that the second set of data generally has higher response times across all three operations compared to the first set of data.This indicates that response time is directly proportional to the number of concurrent user visits.

Communication Overhead
The communication overhead for different operations (create, query, and update) was measured to evaluate the performance of TrustHealth.Figure 4 shows that the create operation has a communication overhead of approximately 2.05 s.This overhead is primarily due to the initial setup required for creating new entries, which involves multiple steps such as generating keys, storing data securely, reaching consensus, and updating the blockchain.The query operation is significantly faster, with an average communication overhead of approximately 7 ms, indicating that querying existing data from the blockchain is an efficient process, as it primarily involves retrieving and verifying the stored information.The update operation also has a high communication overhead of around 2.04 s, similar to the create operation, because modifying existing entries involves similar steps, including updating the data, ensuring its integrity and security, and reaching a consensus to validate the changes.The higher overhead for write operations suggests potential areas for optimization.Future work will focus on improving the efficiency of these operations to reduce latency and enhance overall system performance.

TrustZone Latency
In developing TA, it is crucial to consider the potential overhead resulting from frequent switching between the NW and the SW.This is especially important because the trusted application needs to be able to actively serve client applications by relying on the NW invoke mechanism.To light on this issue, we conducted a series of experiments and analyzed the switching time between the NW and the SW, as shown in Figure 5.To ensure accurate measurements, we configured the heap and stack of the trusted application to 2 MB and 32 KB, respectively.We recorded the elapsed time before and after the TA invocation, and our results demonstrate that the average time required to call a function in the SW is approximately 57 μs, while the time to return is around 13 μs, consistent with findings reported in prior research [54].These results provide valuable insights into the performance of trusted applications and highlight the importance of optimizing the switching process between the NW and SW to minimize overhead and ensure optimal system performance.

SQLCipher Benchmark
The performance evaluation of TrustHealth-ported SQLCipher v4.5 was conducted using the built-in benchmark suite Speedtest1 [55].Each benchmark in Speedtest1 evaluates an aspect of the database engine.We allocated the heap size of 800 MB for a single TA, which was sufficient to test the performance of Speedtest1.The experiments were conducted by instantiating an in-memory database and a disk database to run tests with the full dataset in the benchmark, respectively.The results of the experiments, which ran 10 times and were normalized, are presented in Figure 6.While read queries had a small impact on performance, the results of write-intensive experiments (e.g., experiments 100-120, 180, 190, 210, 290, 300, 400, and 500) showed a significant difference compared to SELECT, which had a greater impact on database performance.Overall, the experiments analyzed the correlation between the in-memory database and the disk database, with experiments 130-145, 160-170, 260, 310, 320, and 520 used to analyze the performance of database reads.It is important to note that memory limitations are not caused by TrustZone, and as long as OP-TEE addresses the limitation of a maximum of 1024 MB of memory for a single TA, memory will not be a significant factor for TrustHealth performance.We allocated a significant amount of shared memory to enhance the communication performance between ROS and SQLCipher.Specifically, we set the shared memory configuration, CFG_SHMEM_SIZE, to 768 MB, which enabled efficient data transfer between ROS and SQLCipher.We conducted experiments with varying data sizes and found that data transfer between ROS and SQLCipher was efficient, as demonstrated in Table 4, thus guaranteeing high communication efficiency.

CRUD Performance
To enhance the security of sensitive healthcare data stored in the cloud, traditional encryption methods typically employed by cloud services are insufficient to protect data during its usage.TrustHealth offers high data security but comes with tradeoffs in system usability and performance.To accurately evaluate CRUD performance, specifically IN-SERT, SELECT, UPDATE, and DELETE, corresponding evaluations need to be conducted.We compare the time overhead to execute CRUD commands in two scenarios: (1) CRUD operations on plaintext without any encryption, and (2) CRUD operations on ciphertext using TrustHealth.We created two tables, test1 and test2, with four columns each: id (integer type), t1 (integer type), t2 (float type), and t3 (string type).The only difference between them is that all data in test1 are encrypted at all times.This experiment is performed on both plain and encrypted disk databases.We compare the overhead for plaintext and ciphertext for four common operations.The INSERT involved inserting 10,000 records into two tables.The SELECT involved retrieving all records if t1 matched a specific value.The UPDATE involved updating t1 if its data matched a random value.Finally, the DE-LETE operation deleted all data in both tables.Each test was repeated 100 times, and the average time results are presented in Figure 7.The findings revealed that the INSERT and UPDATE operations took 2 s and 5.8 s, respectively, while the SELECT and DELETE operations could be completed within 100 ms.We conducted a detailed analysis of the execution process for an SQL statement, including the INSERT operation, which involves several steps such as initialization, random number generation, cipher, and hmac check.To assess the performance impact of these operations, we used AES-256-CBC to encrypt the data during the INSERT operation.Table 5 illustrates the experiment configuration, where all the data in test1 are encrypted.The primary operations in the encryption process are random number generation, cipher, and hmac check.Normally, cipher takes 69 μs, whereas random number generation and hmac check take 167 μs.Hence, encryption overhead is not a major factor affecting database performance.Figure 8 depicts the results of each phase of the experiment.Furthermore, the reason for the large time overhead of UPDATE is that it calls random number generation, cipher, and hmac check multiple times.Overall, from the discussion of the experiment results, it can be concluded that TrustHealth can provide CRUD services at an acceptable cost.

Discussion
Our experiments confirmed that TrustHealth provides robust data confidentiality by encrypting all sensitive healthcare data using AES-256-CBC during transmission and storage.This ensures that unauthorized access is prevented, meeting the data confidentiality criteria.Additionally, the system effectively utilizes blockchain to store data hashes integrity verification, and hmac checks ensure that any tampering with the data is detectable, thus maintaining data integrity.By integrating TEE and blockchain, TrustHealth offers strong resistance to forgery and tampering.The hash verification process ensures that any unauthorized attempts to generate or modify EHRs are identified and prevented.Performance metrics indicate that TrustHealth maintains acceptable response times, with create and update operations for smart contracts averaging approximately 2 s, and query operations averaging 6.6 ms.The communication overhead is reasonable, reflecting an efficient data transmission process.
Moreover, the INSERT operation processed 10,000 encrypted data records in just 2 s, showcasing SQLCipher's ability to sustain efficient write performance alongside robust data security.The database performance analysis revealed that TrustHealth efficiently handles CRUD operations, despite the overhead introduced by encryption.

Security Analysis
Data Confidentiality.Consider a scenario in which an attacker gains access to the REE OS and attempts to tamper with the database files.However, all patient EHRs are securely encrypted and stored on the TEE-assisted server, and an attacker cannot access the TEE to obtain the encryption key.Since the encryption key is inaccessible to attackers, the encrypted data remain unintelligible, preventing access to plaintext form.Although Singh et al. [56] found that there is no difference between using TEE and traditional encryption algorithms in the process of protecting private data, TrustHealth still offers datain-use protections by using TEE.Most importantly, TrustHealth never exposes EHR in plaintext, and decrypted data can only be displayed and processed within the TEE.
Data Integrity.In TrustHealth, data are divided into two types: on-chain data and offchain data.The integrity of on-chain data is guaranteed by the immutability of the blockchain.Previous studies [3] have highlighted the risk of collusion between cloud servers and doctors to modify or delete EHRs.Suppose the attacker modifies the database file so that the integrity of the database is damaged.TrustHealth effectively utilizes blockchain to store data hashes for integrity verification.When a patient queries their EHR, the system compares the hash of the queried data with the pre-stored hash.This guarantees the correctness and integrity of the outsourced EHR, making any modifications detectable.
Resistance to Forgery and Tampering.TrustHealth's integration of TEE with blockchain technology offers robust protection against forgery and tampering attacks.To forge an EHR within TrustHealth, an adversary would need to alter the hash value of the EHR on the blockchain and manipulate the corresponding EHR stored within the TEE.This is an extremely challenging task as it involves tampering with both the immutable blockchain and the secure TEE, which is impractical due to the substantial cost and complexity involved.Furthermore, the encryption and decryption keys are securely stored within the TEE, safeguarding them from unauthorized access.This ensures that even if an attacker gains access to the external system, they cannot retrieve the keys necessary to decrypt or modify the EHR data.This robust security mechanism guarantees that the integrity and authenticity of EHRs are maintained, preventing unauthorized modifications.

Limitations
TrustHealth demonstrates robust security and performance.However, there are areas for improvement, particularly in its resistance to physical attacks.While TEEs provide strong protection for data in use, static data remain vulnerable to physical attacks.In some cases, the data themselves can be falsified and rendered unreadable due to encryption; an attacker could significantly restrict availability in this way.Future work will focus on enhancing the encryption and access control mechanisms for static data, mitigating the risks associated with physical attacks.

Conclusions and Future Work
While healthcare data enhances diagnostic convenience, the paramount concern of data security cannot be ignored.In this paper, we propose TrustHealth, a solution designed to enhance the data security and privacy of EHRs.TrustHealth leverages TEE to design a secure database, and it incorporates a secure session key generation protocol to establish secure communication channels between healthcare providers and the TEE.A consortium blockchain is employed to securely store EHR hashes on-chain, providing immutability and transparency.Comprehensive experiments evaluate the throughput of the blockchain system, the performance of the secure database, and the overhead of encryption and decryption.Our performance evaluation shows that TrustHealth can securely process massive encrypted data flows at a rate of 5000 records per second, demonstrating that TrustHealth can ensure security and privacy without incurring significant overhead.In the future, we will focus on improving data availability to ensure that encrypted data remain accessible under adverse conditions.Additionally, we will conduct extensive realworld testing to validate TrustHealth's practicality and effectiveness.

Figure 4 .
Figure 4.The communication overhead for different operations.

Table 1 .
Comparison of existing blockchain-based EHR solutions.

Table 2 .
Comparison of different types of blockchain.
creates a structured data object (e.g., JSON) containing the above information.Subsequently, P sends Enc(Ptk, WP) to D1, where Enc() is a secure symmetric encryption algorithm, such as AES.Case 2: P is diagnosed by a group of doctors {Di}(i ∈ I).There are multiple doctors taking turns diagnosing; P generates a warrant WP,i for a set of doctors {Di}(i ∈ I) to diagnose and generate EHR, where WP = IDP||IDDi||TimePeriodP,i||AuxP,i.P sends Enc(Ptk, WP) to Di, i = 1, 2, …, I. Upload and Store.Case 1: When D1 completes P's diagnosis, D1 generates the EHR ehrP for P. D1 hashes ehrP and uploads it to the blockchain.Then, D1 encrypts the ehrp with Ptk of P: D1 sends Cp to TS. TS will verify D1's identity by querying the database, and if the verification passes, TS accepts (D1, CP, WP).Case 2: The first doctor D1 generates an EHR ehrp,1 for P. D1 hashes ehrp,1 and encrypts it with Ptk.

Table 3 .
File system calls in TrustHealth.

Table 4 .
Data communication performance.

Table 5 .
Experimental configuration for INSERT.