By Dr. Ivan Gudymenko, IT Security und Blockchain Architect at Telekom MMS and Mostakim Mullick, Security Engineer Working Student at Telekom MMS

In what follows, we would like to provide you with an overview of our innovation activities in the area of Confidential Computing. One of the use cases we are actively looking at is securing cloud encryption proxies against powerful adversaries. Certain results were summarized in form of a scientific paper, published in the UbiSec 2022 conference proceedings with Springer Communications in Computer and Information Science (CCIS).

„Encryption Proxies in a Confidential Computing Environment“, is published in Volume 1768 of the Communications in Computer and Information Science series.


The presentation video can be found here:

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

PGlmcmFtZSB0aXRsZT0iRW5jcnlwdGlvbiBQcm94aWVzIGluIENvbmZpZGVudGlhbCBDb21wdXRpbmcgRW52aXJvbm1lbnRzIiB3aWR0aD0iNTAwIiBoZWlnaHQ9IjI4MSIgc3JjPSJodHRwczovL3d3dy55b3V0dWJlLW5vY29va2llLmNvbS9lbWJlZC85VWlMWUYxVWttdz9mZWF0dXJlPW9lbWJlZCIgZnJhbWVib3JkZXI9IjAiIGFsbG93PSJhY2NlbGVyb21ldGVyOyBhdXRvcGxheTsgY2xpcGJvYXJkLXdyaXRlOyBlbmNyeXB0ZWQtbWVkaWE7IGd5cm9zY29wZTsgcGljdHVyZS1pbi1waWN0dXJlOyB3ZWItc2hhcmUiIGFsbG93ZnVsbHNjcmVlbj48L2lmcmFtZT4=

Confidential Computing: Enabler of Cloud Computing

Data security is crucial across the board for all three states of data, i.e., data in use, data in transit, and data at rest. After monolithic systems were replaced with elastic and loosely linked microservices deployed in a cloud environment, a user could select the services he needed from the application rather of taking all of the services in a bundle. As a result, a subscriber does not need any hefty equipment to host the application on premises, but merely a terminal to access the service and a steady network. This has undoubtedly made life easier because it cuts administration costs and time. However, all these advantages come at a cost. To achieve its privacy and security objectives, a company must now address new issues and challenges brought about by cloud computing. Ensuring the proper data protection and compliance is often crucial on the way to adoption of many cloud-based offerings. This is especially true in privacy-sensitive domains, such es e-health.   Numerous strategies and options are available, but these strategies must address three crucial factors: data usability, data control, and data protection. Usability takes into account how effectively cloud services and their features remain useable to the end-user without any limits in spite of data protection measures, such as encryption. Data control is concerned with data sovereignty, management supervision of the ownership and administration of cryptographic keys, which are required for encryption. Last but not least, data protection refers to how businesses and organizations manage personal data and adhere to legal requirements, which is especially challenging in the context of stringent EU regulation The adoption of a cloud-first architectural strategy has been dragged back by concerns about data security and the need to abide by regulatory requirements. Pseudonymization and encryption techniques have been employed by encryption proxies like the eperi Gateway to change sensitive and personal data into a format that can provide high confidentiality guarantees. This ensures the constant protection of both data in transit and data at rest but not necessarily data in use.

Source: eperi, Picture shows eperi Gateway workflow; Users connect to the eperi Gateway through their network and send data to it, which is then transparently encrypted before being transferred to the associated cloud application. As a result, the eperi Gateway serves as a transparent encryption proxy. In the other direction, the eperi Gateway operates as a proxy server by taking a data stream supplied by a cloud service and then decrypting the encrypted data before delivering the data to the clients in plain text over a secured connection.

It is concerning when unauthorized persons get access to Personal Identifiable Information (PII). The GDPR does not consider anonymized and properly pseudonymized data to be PII, hence the stringent data protection requirements can be relaxed in this case. To handle encrypted data, a cloud application must first have access to the respective cryptographic keys or get the decrypted data from a dedicated encryption proxy. The processed data can be seen in clear text by, for example, an infrastructure or platform administrator possessing root rights who may be acting maliciously. Therefore, a workable and secure solution is required to safeguard data in use.

Trusted execution environments (TEE) have been widely used to launch secure programs, enabling data to be secured in all three states (at rest, in use, and in transit). TEEs are a promising technique for confidential computing and most prominently include Intel SGX and AMD SEV (along with Intel TDX and ARM TrustZone as emerging technologies). A processor with SGX support isolates the code and data of the enclave from the outside world, including the operating system, hypervisor, and hardware devices connected to the system bus. This preserves the integrity and secrecy of the computation occurring inside the enclave. Enclaves are secure hardware-based TEEs used by Intel SGX. Enclaves are secure and trusted segregated memory areas in which the code running is isolated from other untrusted programs, including privileged code. Enclave code and data are stored in a secured physical memory section known as the enclave page cache (EPC). When data on EPC pages is migrated to DRAM, it is protected at the granularity of cache lines. In its initial iteration, SGX used to support EPC of up to 128 MB, but now 3rd Generation Intel® Xeon® Scalable Processors support 512 GB of EPC size, which adds up to 1 TB on a two-socket platform. Intel SGX shifted to utilize Advanced Encryption Standard – XEX Tweakable Block Cipher with Ciphertext Stealing (AES-XTS), allowing a larger EPC, from using the Memory Encryption Engine (MEE), which requires on-die capacity for a Merkle Tree that is difficult to extend. An on-chip MEE encrypts and decrypts the EPC’s cache lines written to and retrieved from DRAM. In addition to being integrity secured, enclave memory also detects memory changes and rollbacks. Additionally, Intel SGX offers a function for remote attestation, which is one of the core principles in trusted computing This makes it possible for a challenger to confirm the TEE’s reliability and remotely attest software and code running inside an enclave without gaining access to it in clear text. Please check the images below to understand better about SGX.

Isolation of sensitive data in a protected CPU enclave during processing
Protection of data in use via application isolation technology. An external user/process has no access to the trusted part of an application

Secure container technologies like SCONE, which execute the binary code inside SGX and offer SGX-enabled security assurances inside cloud environments.  The remote attestation, which is encased in SCONE and anchored to Intel SGX attestation, satisfies the secrecy and integrity standards. This guarantees the security of any active data. In order to offer a thorough, safe data privacy approach, our Proof of Concept builds on the data privacy techniques employed in conjunction with the eperi Gateway and Intel SGX. In this blog, we emphasize the following key contributions of our work related to running encryption proxies in confidential computing environments based on Intel SGX:

  • make use of the privacy-preserving capabilities of the eperi Gateway and expand the privacy-preserving needs with the Intel SGX TEE,
  • employ a „lift and shift“ method to convert the encryption proxy into a trusted image using Intel SGX and the secure container platform SCONE,
  • compare the overhead to the native execution without SGX and assess the effectiveness of the suggested proof of concept using benchmarks.

Proof of Concept

The purpose of the PoC is to defend the cloud provider and strong attackers with access to the infrastructure by securing the instance of a cloud encryption proxy (eperi Gateway) deployed in a cloud environment. In this approach, we want to create a reliable data encryption pipeline where client information is constantly secured against the cloud service provider. This means that parties outside the secure enclave where the encryption gateway is running are unable to access sensitive data in plain text. Our PoC was deployed in our MS Azure tenant using DC Series VMs from Microsoft configured to host SGX workloads.

Eperi Gateway is built using Java, although the Intel SGX SDK only supports C/C++. So here we use Scontain or SCONE that supports Java, which is used to convert this Java application application into a confidential application powered by SGX. In order to create the confidential version of the program, SCONE presents a lift and shift transformation strategy called Sconification. Automated single step command to achieve this:

For further details, please refer to SCONE documentation.

Image depicts goal of the Sconified eperi Gateway procedure is to deploy the eperi Gateway in a secure manner utilizing the SCONE platform, with all essential configuration and services operating. In this technique, the user only needs to run the provided script and utilize the gateway’s admin page as usual, with no database configurations or source code modifications required within the eperi Gateway. On its journey to the cloud application, the eperi Gateway transparently encrypts the data. In contrast to the native eperi Gateway setup, the processed customer data as well as encryption keys in use are safeguarded via SGX.

Experimental setup

In order to obtain results, an eperi Gateway benchmark was established. A web page of Official Microsoft 365 site is requested from behind the eperi Gateway proxy. We have used wrk2 as our load generator. After deploying both the native eperi gateway and the sconified version. The HTTP benchmarking program generates two experimental assessment metrics: continuous throughput load and high percentile accuracy latency information. Benchmark runs for two minutes with two threads and 50 HTTP connections active at a constant rate of 100 requests per second. Our client load generator, the eperi Gateway with Microsoft Outlook Exchange under a custom domain as a back-end, and the services deployed as docker containers on the Microsoft Azure platform comprise the setup. The virtual machine has 10 vCPUs and 32 GiB of primary RAM. Because all of the services fit within memory, the disk configuration is immaterial.

The line graphs below represent the outcomes of our designed confidential application besides the native application to establish the results and conclusion of our research study.

The graph depicts the percentile distribution of latency for HTTP queries from clients to Microsoft Outlook via eperi Gateway native and sconified implementations. We may disregard the final spike in the graph as the result of stragglers. In the sconified version, about one-third of requests are provided within 450 milliseconds and 90% within 1.2 seconds, whereas 90% of HTTP requests are handled within 500 milliseconds in the native deployment of eperi Gateway.

The graph indicates that both systems function similarly until 100 requests per second, at which time the latency of the Sconified deployment substantially increases. The native eperi deployment outperforms, hitting 110 requests per second.

Under maximum throughput, both the native and Sconified deployments achieve a maximum CPU usage of 790% and 910%, respectively.

Summary

According to our research, generic confidential computing can be used as an additional measure to solve compliance and security issues in cloud computing. This may be done using a variety of cloud computing technologies, including Intel SGX and AMD SEV.  AMD-SEV-SNP could be employed as an alternative technology to Intel SGX, promising transparent confidentiality. In the Microsoft Azure environment, Confidential Virtual Machines (CVM) provide access to this technology allowing the eperi Gateway to be installed and configured without special considerations. To establish trust in such a CVM, one would rely on Microsoft Azure Attestation and implement the gateway to only launch in case of successful attestation which comes in the form of a Microsoft-signed JSON Web Token (JWT) that can be verified. Additionally, it is possible to manage the distribution of the eperi MasterKey protecting the cryptographic material in the gateway database in a CVM-based Centralized Secrets Manager. This Secrets Manager would only release the MasterKey once the confidentiality of the gateway VM is proven via relying-party handshake. A future segment of work might compare the deployment of the secret eperi Gateway on various TEEs such as Intel Trust Domain eXtensions (TDX), and Google Kubernetes Engine (GKE) to create a cluster of confidential VMs.

Get to know more about:

Other MMS Blog Posts


Dr. Ivan Gudymenko, IT Security and Blockchain Architect at Telekom MMS

Dr. Ivan Gudymenko is an IT security and blockchain architect, an expert in the field of technical data protection and a consultant on various projects focusing on IT security and blockchain-based systems. His activities also include technical team management, business development in the innovation area and technical development of innovation topics in the field of IT security, blockchains and self-sovereign identity.


Mostakim Mullick, Security Engineer Working Student at Telekom MMS

Mostakim Mullick is working as a Security Engineer in the field of innovation and technical development and IT security.