According to McAfee Labs, even in 2019, the eHealth sector is confirmed as one of the most critical in terms of cybersecurity incidents. It is estimated that more than 176 million patient records were target of attacks between 2009 and 2017, and with a single attack, in 2018, more than 1.4 million patient records were affected at UnityPoint Health. To cope with such a dramatic situation, one of the main strategic priority in the eHealth field is represented by the adoption of Blockchain. Specifically, according to a Deloittes survey, 55% of healthcare executives believe that blockchain technology will disrupt the healthcare industry. Unfortunately, while blockchain provides a valuable tool for enhancing the security of health applications and related data, it cannot be assumed as a panacea for data security. As an example, the so-called Endpoint Vulnerability issue is a well-known problem of Blockchain-based solutions: in such a case the attacker successful in gaining control of the end-point can tamper data off-chain during its generation and/or before it is sent to the chain. In this paper, we face such an issue by shielding the endpoint through the Intel Software Guard eXtension (SGX) technology. We demonstrate our solution for an auditing software belonging to the European eHealth management system (namely OpenNCP). We also discuss how our solution can be generalized to any other Blockchain-based solution. Finally, an experimental evaluation has been conducted to prove the actual feasibility of the proposed solution under the requirements of the real eHealth system.
The Blockchain technology is becoming pervasive in today's societies. It is not just a buzzword, it is the
hottest and fastest growing technological market in the IT sector. Statistical studies said that there are
approximately 44% of companies from different fields (e.g., banks, agriculture, governments, accountants)
that adopted a blockchain [
intrinsic distributed property of Blockchains ensures to health-related data more confidence in terms of integrity. A successful attack should be able to modify the data retained by the Blockchain in all the nodes belonging to the network. In spite of this, there are still open issues affecting the Blockchain such as the Endpoint Vulnerability where data off-chain is at risk before being sent to the chain. An attacker could tamper an audit trail in the endpoint during its acquisition and before its encryption. The ultimate goal of this paper is to protect patient's privacy and ensure integrity of patients' data, while keeping track of critical operations in order to provide secure traceability support. We propose a solution for a Blockchain-based logging system that leverages hardware-assisted trusted computing to address the Endpoint Vulnerability. Sensitive functionalities carried out before sending the health-related logs to the Blockchain are executed within the Trusted Execution Environment (TEE) of Intel Software Guard eXtension, i.e., the widely-accepted technology of trusted computing released by Intel. Our work demonstrates through a security analysis and a performance evaluation that the proposed approach results usable in real contexts. Using requirements coming from a real healthcare management system, we demonstrate that the overhead introduced in the system is acceptable and does not alter the compliance with time-related constraints.
The proposed approach has been validated in the context of the KONFIDO project1, whose main goal
is to enhance security of the European eHealth system for cross-border data exchange, better known
as OpenNCP [
The remainder of this work is organized as follows. Section 2 overviews other research papers that used SGX with blockchain in other contexts. Then, Section 3 presents the two core technologies we adopted. Afterwards, Section 4 describes the OpenNCP eHealth system and provides pillars on the blockchain-based auditing service. Section 5 defines the problem and the challenges we face in this paper. The design and implementation details will be reported in Sections 6-7. Finally, Section 9 concludes the document. 2
Other research works leveraged the security features of TEEs, in general, and of Intel SGX, in particular, for hardening blockchain-based services such as Bitcoin and Smart Contracts. Different security aspects of the blockchain have been covered by these works. To the best of our knowledge, this is the first research that faced the Endpoint Vulnerability and that propose the marriage of SGX and Blockchain in the eHealth sector. The security coming from their combination is extremely important in such a context where privacy and integrity requirements are particularly stringent.
Lind et al. [
Yuan et al. [
Hardjono et al. [
In the following, we present the core technologies used in this paper to build a trustworthy eHealth auditing system. 3.1
Blockchain is still an innovative technology which has yet to be properly sistematized. The current
definition from the ISO/TC 307 on "Blockchain and Distributed Ledger Technologies" [
A Hardware-assisted Trusted Execution Environment (HTEE) has started to be widely adopted [
and hashing { from any software outside the enclave, included privileged ones (e.g., OS or Hypervisor).
Only the enclave code can access any part of the address space, except those areas belonging to other
enclaves. The boundary between enclave and non-enclave sections is governed by the processor who
blocks any access attempt from unauthorized processes. An interface { defined in a domain-specific
C language { is declared by the programmer to establish entry points, i.e., calls to/from an enclave
(namely ECALLS and OCALLS). A HTEE such as SGX can be formalized as follows [
e = hinite;configei where confige includes the entrypoints confige:entrypoint, the virtual address range confige:evrange, the access permissions confige:acl, and other application-specific configuration data confige:app. While inite brings the initial state of SGX such as values of memory pages pointed by confige:evrange that contains code and data. We define the enclave state in some instant of time as Ee( ), which is a projection of the machine state. Finally, enclaves' inputs are specified as Ie( ), i.e., a partial map from virtual addresses (outside confige:evrange) to machine words. Enclaves' outputs are defined as Oe( ), i.e., a partial map from virtual addresses (outside confige:evrange) to words. The semantics of enclave execution is the set of execution traces, containing an execution trace for each input sequence, i.e., for each value of non-enclave memory.
[[e]] = fh(Ie( 0);Ee( 0);Oe( 0));:::ijinite(Ee( 0))g The determinism property of SGX programs entails that a specific sequence of inputs hIe( 0);Ie( 1);Ie( n)i uniquely identifies a particular execution trace of [[e]] under that sequence of inputs. An important feature of SGX is the remote attestation, which enables the integrity verification of an enclave residing in external domains via Intel's third-party server. Let (e)D be the quote of a generic enclave e generated in some domains D, we say that attestation is verified when:
Att([[e]])D , (Ee( ))I = (Ee( ))D where (Ee( ))I is the quote generated in Intel's Attestation Service of the enclave [[e]] in a determined state Ee( ). 4
The current deficiencies in security logging and analysis allow attackers to hide their location, malicious
software, and activities on victim machines. Even if the victims know that their systems have been
compromised, without protected and complete logging records they are blind to the details of the attack
and to subsequent actions taken by the attackers. Without solid audit logs, an attack may go unnoticed
indefinitely and the particular damages done may be irreversible. Logging records could also be the
only evidence of a successful attack. Moreover, many healthcare organizations keep audit records for
compliance purposes. Because of poor or nonexistent log analysis processes and log integrity, attackers
sometimes control victim machines for months or years without anyone in the target organization
knowing, even though the evidence of the attack has been recorded in unexamined log files.
Such issues also affected the logging system of the European eHealth management system, namely
OpenNCP [
OpenNCP acts as an ATNA [
OpenNCP SmartLog
Country A Enc.
Module
The distributed properties typical of the blockchain provide more security guarantees to the sensitive health-related logs acquired by the system previously described, which creates tamper-proof audit trails of the OpenNCP activities. More precisely, the distributed consensus and storage of the blockchain ensure that information cannot be modified unless it is agreed across the entire DLT. In a nutshell, several nodes have the same information, thus an attacker should be able to get access and change all these distributed data in order to launch an attack to the data integrity. Even identities are usually held on the DLT. When a user has to be authenticated, there is no more a centralised party that checks and verifies data of individuals. Thanks to the DLT, the credential information are distributed. The possibility that an attacker manipulates identification data is highly reduced.
Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License 5 Attribution 4.0 International (CC BY 4.0).
Even if a blockchain increases the resistance to considerable category of attacks, it does not make it
immune against security vulnerabilities, which are still considered today as the most critical open issues
of this technology [
Figure 3 shows the location of the SGX-enabled auditing system based on Blockchain in a typical healthcare dataflow such as a clinical document acquisition in OpenNCP. The prerequisite is the availability of the SGX hardware extension in each national gateway (i.e., the NCP node). When new events occur, e.g., a patient summary request or a document transformation, the auditing system has to securely store the activities in the Blockchain. The SmartLog and Encryption modules do not exist anymore. Instead, an SGX enclave responsible for the log generation is instantiated internally by OpenNCP. The audit record is securely built in the trusted execution environment with all the necessary information such as the event timestamp. In this regard, as explained below, our solution uses a trusted time source since a compromised timestamp could be harmful for the system. At this point, not even an attacker with root privileges can tamper the log during its generation. Then, the log must be sent to the Blockchain. Hence, the enclave encrypts and signs the audit record with a key stored in the SGX secure perimeter. From now on, logs content is confidential even off SGX and the integrity of the events as well as their order is ensured. The key management in terms of generation, distribution, and storage, is discussed further below. The cryptographic operations are shielded from any privileged insider thanks to the SGX hardware-enabled isolation features. Finally, in order to ensure the security of the communication channel, an SGX-secured TLS is established with the Blockchain. This means that the communication terminates directly in the enclave, which is also responsible of keeping the TLS private key. With our solution, we eliminate the risk of privileged attackers such as malicious insiders by enabling independent log integrity and time verification which cannot be backdated.
Query patient data
NCP Node Country A -Search for the document. -Register the query event
OpenNCP
SGX SGX --EGnecnreyrpatte&LSoiggn Log -Hold PK -Send Enc(Log)
NCP Node Country B
-Retrieve and
Transform the
document.
-Register the
document
acquisition
event
For security reasons, most of the fields of a log record are directly generated in the SGX enclave,
thus avoiding the risk of tampered entrypoints, e.g., malicious outputs returned to an OCALL (i.e.,
the function called from within the enclave). The only source of attack may be represented by the
timestamp. In fact, services such as timer and monotonic counters are not supported inside the Intel
SGX technology [
We implemented a dedicated approach for what regards the key management and distribution. The idea is to leverage the attestation features of SGX to avoid the use of a third-party key management server that could be potentially untrusted. At startup time, when the NCPs are setup, every enclave starts performing the remote attestation procedure to verify that all the other enclaves in the NCP nodes have not been tampered. Once completed this phase, keys are exchanged. Particularly, the way we do this is through the Diffie-Hellman scheme, which allows the exchange of keys over untrusted channels. At the end of this process, all the SGX enclaves will have a list of keys for all the involved countries. Keys are finally saved in a persistent storage after being ciphered.
It is important to notice that such an approach fits well for this particular case study where there is a limited amount of Blockchain endpoints involved. In a different situation, another possibility may be to Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License 7 Attribution 4.0 International (CC BY 4.0).
leverage a typical key management solution in which a third-party is responsible for the key generation and distribution. 7
Designing an SGX-based solution requires a fundamental decision, i.e., what should be placed inside and outside an enclave. Or better, which functions should be exposed to the outside world and to the enclave in the SGX interface. This is particularly important since the decision affects both the security properties in terms of Trusted Computing Base (TCB) size, and the performance overhead. The methodology pursued for porting the C++ SGX enclaves in the Java-based OpenNCP is the Ad-Hoc approach that requires manual and dedicated partitioning of the Java software. We used a Java Native Interface (JNI) bridge to link the trusted and untrusted worlds. The Java code runs outside the enclave, and uses the JNI bridge to interact with trusted code components running within SGX secure enclaves. While this approach entails a non-trivial development activity on the software to be secured, it ensures a much smaller size of protected code and, at the same time, a reduced number of transitions between secure and insecure worlds. Figure 4 shows a simplified call graph of the implemented solution in the extended OpenNCP system. When the user (e.g., a doctor) performs the query through the WebPortal, then the function query() is called in the endpoint node (PTA: the protocol terminator of the NCP A). The execution control will be directly moved into the SGX enclave via the init function sgx init() that launches the key exchange procedure, in case keys have not been assigned yet. Afterwards, the query is carried out by the enclave and the event is registered in the blockchain by the SGXLogger object.
class WebPortal{
void onSubmitButton(){ } } query(RSSMAR89P0J4aCv7a82)
1 class OpenNCP_PTA{
PSummary query(pID){ 2 sgx_init(); sgx_ps_q(pID);
3
Java }
} }
} class OpenNCP_PTB{
PSummary retrieve(pID){ sgx_init(); sgx_ps_r(pID); void sgx_init(){
if(first) key_exchnge(); } else readSK(); PSummary sgx_ps_q(pID){ //Perform the query … regActivity(“someEvnt”); } return result;4 C++ class SGXLogger{ void reg_activity(e){ t=sgx_trusttime(); log.time=t; log.event=e; … clog=cipher(log,sk); sgx_ssl_send(clog);
C++
Java } } Off-SGX
SGX
In this section, we present the evaluation activity conducted on the SGX-enabled auditing solution based on Blockchain, which has been realized using workloads typical of the OpenNCP eHealth system. We report the findings on transaction throughput and transaction latency measurements that we conducted using the Bit4id proprietary Blockchain Hylos. Our goal was to verify that the overhead introduced by the SGX component in terms of log generation and sending is acceptable and does not alter the compliance of the auditing system with OpenNCP requirements.
The experimental setup must include the OpenNCP endpoints and the Blockchain network. The former
was simulated in a single node, which is SGX-enabled. This is reasonable since the transmission latency between the two NCP nodes is not of interest for the purpose of this evaluation. Such a node has the following specifications: an Intel Xeon E3-1270 v5 CPU with 4 cores at 3.6 GHz with SGX extension enabled, 8 hyper-threads (2 per core), and 8 MB cache. The host has 64 GB of memory and runs Ubuntu 16.04 LTS with Linux kernel version 4.2. The Intel SGX PSW and SDK v2.6 have been used for implementing and launching the SGX enclave. Regarding the Blockchain, the proprietary Bit4id Hylos based on Proof of Work (PoW) consensus algorithm and configured with 20 peers has been used. All peers ran on hardware machines belonging to the Italian Veneto eHealth system. Each machine had 8 vCPUs (4 cores at 3.6 GHz) and 16 GB RAM.
Our goal is to observe the impact given by SGX to the processing phases occurring in the endpoint before
the data is sent to the Blockchain. To this end, we measure the throughput t of requests served per second,
and the service (or response) time s that represents the interval of time needed to perform the log-related
subroutines in the endpoint. The idea is to compare the performance of the native auditing system
with the solution using SGX. The goal is to characterize the level of system performance given a specific
workload that is typically the one expected for the immediate future. The workload in terms of events
arrival rate depends on the number of requests typically made to the NCP endpoints. Such a number
unfortunately is not available to the public, thus our approach is to start from EU statistics, similarly to
[
Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License 9 Attribution 4.0 International (CC BY 4.0). 9
This paper proposed a promising approach to address the well-known Endpoint Vulnerability affecting the majority of Blockchain-based services. It described a solution based on the Intel SGX technology in which data is protected from tampering within the SGX trusted execution environment. Sensitive phases of data acquisition and encryption | occurring in the endpoint before sending to the Blockchain | are realized in the SGX enclaves. We implemented the proposed approach for a Blockchain-based auditing system used in the context of the European eHealth system, namely OpenNCP. The performance evaluation demonstrated that the SGX-enabled logging introduces an overhead, which is acceptable for the specific eHealth system requirements. It is important to notice that our approach is easily usable to any other Blockchain-based service where the Endpoint Vulnerability could pose at risk the integrity of data.
This project received funding from the European Union's Horizon 2020 Framework Programme for Research and Innovation under grant agreement No 727528 (KONFIDO).