Architecture

The ASCLEPIOS project will investigate, customize and apply new cloud orchestration technologies for the cloud deployment hosting its demonstrators.

ASCLEPIOS ARCHITECTURE

  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. 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.