Towards secure eHealth – The ASCLEPIOS Architecture

December 19, 2019 asclepiosadmin 0

A vision for eHealth

Imagine if users of a cloud-based e-Health service were able to store all their medical records online and get certain guarantees that no one else apart from their authorised doctor(s) would be able to see, edit and update their data.  

Back to Reality  

The main problem with cloud-based e-Health services is that once patients’ data is placed on the cloud in an unencrypted form or encrypted with a key that is known to the cloud service provider (CSP), data privacy becomes an illusion. As a result, many users are reluctant to use online healthcare services due to the fear of unauthorised access to their private data. It is worth mentioning that this is especially true in the healthcare sector, where stored and exchanged information is sacrosanct [1]. Furthermore, it has been observed [2] that failing to provide users of e-health services with proper cybersecurity and privacy-preserving mechanisms can slow down the overall adoption of e-health.  

From ideal to real – The architecture of ASCLEPIOS  

Building such a world is a core challenge – especially if you only rely on traditional cryptographic techniques. To overcome this challenge and pave the way for bringing this world to life, in ASCLEPIOS we study and combine several cryptographic techniques that can help us create a cloud-based e–Health framework that will protect users’ privacy against a plethora of malicious behaviour (including insider threats). The developed framework, illustrated in Figure 1, will provide enhanced data protection by combining two promising encryption techniques. Symmetric Searchable Encryption (SSE) [3] and Attribute-Based Encryption (ABE) [4], in such a way that will allow users to securely store files in a remote and untrusted location while at the same time will be able to efficiently share files between multiple users. SSE will allow users to encrypt their data locally with a key that will not be known to the cloud service provider, while ABE will control who can access the underlying decryption key by enforcing a policy bound to the corresponding ciphertexts. Additionally, ASCLEPIOS will leverage the power of Secure Hardware and will offer the ability to users to verify the integrity of their medical devices prior to using it along with obtaining an assessment of the trustworthiness of the CSP that will be storing their data. Finally, ASCLEPIOS will further enhance the privacy-preserving mechanisms offered by healthcare institutions by building a protocol through which authorised practitioners will be able to run statistical computations directly on encrypted data without revealing anything about the contents of the individual files – hence, ASCLEPIOS will pave the way for real privacy preserving analytics. To do so, a first practical implementation of functional encryption [5] will be implemented and combined with the functionality offered by secure hardware.  

Figure 1: A high-level overview of ASCLEPIOS architecture showing its main components as well as how they interact with each other 

Figure 1 illustrates a high-level overview of ASCLEPIOS architecture by showing its main components as well as how they interact with each other. The ASCLEPIOS architecture consists of the following discrete layers: 

  1. Trusted Cloud Provider: The CSP is based on the Infrastructure-as-a-Service (IaaS) model and is responsible for storing encrypted versions of users’ data (patients, doctors, healthcare practitioners, etc.) as well as for hosting other components of ASCLEPIOS if needed1. ASCLEPIOS CSP is considered as trusted in the sense that the overall integrity of the host will be verified before launch by using an attestation protocol similar to the one presented in [6]. In addition to that, the CSP will also host the KeyTray – a core component of ASCLEPIOS. The KeyTray is a key storage component responsible for storing ciphertexts of all the symmetric keys that have been generated by different data owners and have been used to encrypt medical records. Only registered users can contact the KeyTray directly and request access to the stored ciphertexts. KeyTray is running in a Trusted Execution Environment (TEE) and anyone can verify its integrity. 
  2. Crypto Layer: The crypto layer will be implemented as a collection of cryptographic algorithms and will form both one of the key components for security and the main functionality of ASCLEPIOS. This layer will provide a complete cryptography toolkit that will be used to protect stored data and secure the communication between connected components and entities in the system. The novelty of this layer is the implementation of three modern encryption techniques:  Dynamic Symmetric Searchable Encryption scheme, Attribute-Based Encryption scheme, a Functional Encryption scheme as well as a list of various standard cryptographic schemes and functions. 
  3. Analytics Layer: The project foresees that a massive volume of data will be generated and shall be processed with ASCLEPIOS framework, and therefore the analyses will result in insights with potential significance.To this end, a separate layer that will be responsible for conducting analytics based on a wide range of health data will complement the ASCLEPIOS architecture. The Analytics Layer will allow authorised stakeholders of a healthcare organisation to perform analytics based on stored medical data. 
  4. Policy Enforcement Layer: The policy enforcement layer will introduce the appropriate methods and tools to implement an efficient and flexible access policies enforcement middleware, adequate for modern cloud-enabled healthcare systems. 
  5. Registration Authority: This layer is responsible for the registration of medical personnel and patients to the underlying electronic healthcare service. Furthermore, the registration authority (RA) will be responsible for generating and distributing ABE keys to the registered users based on a set of attributes derived from its organisation or based on the set of personal attributes for individuals. In addition to that, RA will be responsible for the distribution of necessary public and private key parameters that will be used to establish secure communication channels between different components. Finally, RA will not just only distribute ABE keys to the registered users, but also secret functional keys sk_f that will be used from authorised users to perform privacy-preserving analytics. 
  6. Attestation Layer: The attestation server will allow certain users to validate the server’s integrity and identify possible unauthorised modifications. Therefore, the use of attestation will be the main tool that will be used in ASCLEPIOS to provide certain guarantees to users regarding the trustworthiness of the overall service that will be offered. 
  7. Revocation Layer: This layer is responsible for the revocation of users (users that might have been compromised or just lost their access rights). In ASCLEPIOS, the revocation layer will be running in a TEE and will maintain a list with a mapping of all the compromised users with the corresponding keys. 

References 

[1]   A. Michalas, N. Paladi, and C. Gehrmann, “Security aspects of e-health systems migration o the cloud,” in e-Health Networking, Applications and Services (Healthcom), 2014 IEEE 16th International Conference on, pp. 212–218, IEEE, 2014. C. Chatman, “How cloud computing is changing the face of health care information technology,” J Health Care Compliance, vol. 12, pp. 37–70, 2010. 

[2]  Kassaye Yitbarek Yigzaw, Antonis Michalas and Johan Gustav Bellika. “Secure and Scalable Deduplication of Horizontally Partitioned Health Data for Privacy-Preserving Distributed Statistical Computation”. Journal of Medical Informatics and Decision Making (BMC), 2017 

[3]   Rafael Dowsley, Antonis Michalas, Matthias Nagel and Nicolae Paladi. “A Survey on Design and Implementation of Protected Searchable Data in the Cloud”. Journal of Computer Science Review, Elsevier, 2017 

[4]  John Bethencourt, Amit Sahai, and Brent Waters. 2007. Ciphertext-Policy Attribute-Based Encryption. In Proceedings of the 2007 IEEE Symposium on Security and Privacy (SP ’07). IEEE Computer Society, Washington, DC, USA, 321-334. DOI: https://doi.org/10.1109/SP.2007.11 

[5]   Boneh, Dan, Amit Sahai and Brent Waters. “Functional Encryption: Definitions and Challenges.” TCC (2010). 

[6] Nicolae Paladi, Christian Gehrmann and Antonis Michalas. “Providing End-User Security Guarantees in Public Infrastructure Clouds”. IEEE Transactions on Cloud Computing, a special issue on “Cloud Security Engineering”, IEEE, 2016.