Protecting the confidentiality, integrity and privacy of medical data is crucial for the further development and adoption of eHealth solutions, remote medicine and telecare. At the same time, cloud computing is increasingly used for managing electronic health records and other medical data (further referred to as medical records). However, ensuring privacy-preserving and secure handling of medical records in public clouds is not straightforward due to the large number of stakeholders involved. Besides the cloud providers themselves, other stakeholders include application developers, platform developers, and many third-party cloud sub-processors (consider the list of Google Platform Subprocessors as an example).
Confidential Computing: the solution towards a secure public cloud?
Many of these challenges can be tackled with the use of confidential computing [1], which is defined as the protection of data in use by performing computation in a hardware-based Trusted Execution Environment (TEE) [2].
Currently, several major hardware vendors – such as Intel, AMD and IBM – offer their implementation of TEEs for cloud computing. Examples include Intel SGX, AMD Secure Encrypted Virtualisation (SEV), IBM Protected Execution Technology (PEF). Several major cloud providers offer Virtual Machines (VM) with support for TEEs, for example Azure offers VMs with support for Intel SGX enclaves, while Google Cloud Platform recently introduced limited support for VMs running on platforms with the AMD SEV technology [3].
Challenges in TEE selection and cloud portability
Considering the diversity of implementations, developers face interoperability challenges when creating applications that are using TEEs. Currently, choosing a TEE technology implies that vendor specific changes will be made to the application to satisfy the requirements of an underlying TEE. Each TEE has its own runtime configurations and ways to manage the isolates entities. As new vulnerabilities are discovered, a certain TEE technology might not be suitable anymore and a move to a different vendor might be needed. This means that the choice of a TEE technology is a difficult task that requires thorough examination.
Several efforts aim to address workload portability across vendor implementations, most notably Asylo and Enarx. For applications using the Asylo API, the use of a different backend means simply re-compiling and re-packaging the application. Changes to the code are not needed as the Asylo API was created with main aim to work with various TEE technologies.
Enarx leverages WebAssembly to create “keeps”, which are isolated containers that can be run in a TEE regardless of the vendor implementation. According to a recent project maturity update [4] the Enarx team has produced demos for both AMD and Intel as well as a working binary application capable of running on top of both SEV and SGX.
What’s in it for ASCLEPIOS?
ASCLEPIOS has closely studied the interoperability of TEEs and reported its findings in the final report of Deliverable D4.3 [5] Furthermore, ASCLEPIOS partners are involved in the standardisation of TEE interoperability, conducted in the Trusted Execution Environment Platform (TEEP) Work Group (WG) of the Internet Engineering Task Force (IETF). In particular, ASCLEPIOS partners have contributed to the TEEP Architecture document [6] and have produced a prototype implementation of the TEEP Architecture, which will be integrated with other components developed within the project.