The general objective of the SERECA project is to build a platform able to protect the confidentiality and integrity of applications and services executed in the cloud. SERECA wants to protect against the most worrisome type of attacks, e.g. a malicious cloud employees that leverages the physical access to the servers and controls the system software of the computers, in particular, the hypervisor and the host operating system. The insider attacker could in principle access all data being processed by services running in the cloud. In this way, one could, for example, steal keys used to encrypt or decrypt data at rest or being transmitted via the network. In SERECA all data is encrypted in memory and only the CPU has access to the encryption keys. Therefore, even physical access to a machine does not help in gaining access to the data protected with SGX.

SERECA aims to build an infrastructure to execute reactive applications securely in public Cloud Providers (CPs). SERECA wants to improve the state-of-the-art in cloud security for interactive, latency-sensitive applications by developing innovative and effective mechanisms to enforce data integrity, availabilityconfidentiality, and localisation based on secure CPU hardware.  

SERECA integrates the innovative Intel's CPU security extension, namely Software Guard Extension (SGX) (, with a popular reactive framework, namely Eclipse Vert.x ( 

  • Intel SGX - Modern x86 Intel CPUs starting with the sixth Core-i microarchitecture support instruction set extensions called SGX which significantly improve application (ring 3) security. The focus of SGX lies on protecting confidentiality and integrity of code and data of applications. Using the SGX instruction set, a so called secure enclave can be created, which is an isolated range of memory within the application’s (virtual) address space to which the SGX security enhancements apply. When using SGX, even the main system memory will be encrypted and integrity protected. SGX permits to protect application state from the hypervisor and the operating system. The data and the computation inside of an enclave are protected from any accesses from the outside of the enclave. An application can create enclaves and transfer sensitive parts of the application code and data into the enclave. Besides protecting sensitive data, for example, encryption keys, enclaves also protect the confidentiality of data stored outside the enclave by encrypting and decrypting the data on demand.
  • Eclipse Vert.x - A toolset that helps developers in designing event driven, asynchronous, and micro-service based applications. Micro-services represents the state-of-the-art of cloud-based applications. Their intrinsic features, i.e., a well-partitioned architecture, allows to build highly available and scalable applications that perfectly fit for cloud environments. Services programmed with Vert.x are split in components (known as verticles) that can run in different address spaces and communicate with each other via an Event Bus.

 SERECA Final Architecture

SERECA Architecture

SERECA aims at supporting the execution of critical functionality inside of SGX Enclaves. Hence a central issue is the partition of applications. It is important to keep the code base inside the enclaves small as performance degradation and the Trusted Computing Base (TCB) are kept limited. The idea is to take advantage of the already well-partitioned micro-service design to run verticles partially inside of enclaves and partially outside enclaves much more easily. Vert.x micro-services typically need standard services like databases, key/value stores and coordination services. Within SERECA, several existing standard services are partitioned. In this way, the platform can ensure the confidentiality and integrity of data processed by these standard services. Moreover, another important aspect faced in SERECA is the secure communication between verticles, which is performed via an extension of the vert.x event bus. Enclaves depend on the untrusted operating system to perform I/O operations meaning that all messages must be encrypted. SGX allows to securely configure enclaves by providing hardware protected sealed storage. This means that only a trustworthy enclave is able to get access to keys to decrypt the sealed data. In this way, using asymmetric cryptography typically employed for key exchange can be avoided. Hence, symmetric keys for communication is used by the vert.x extended event bus.

 To deploy secure reactive applications, in SERECA,  Docker containers are used. A container is a lightweight alternative to virtual machines that isolates processes running on the same OS kernel. Docker engine offers a rich REST API that allows to manipulate containers both on local and remote hosts. SERECA aims to minimize the number of changes to the engine such that the API can be reused out-of-the-box. Our support of containers will be in a form of a lean runtime that allows to securely configure and execute enclave-enabled applications in containers.  The SERECA consortium anticipates that cloud providers will gradually introduce hardware that supports secure enclaves in their cloud platform offerings. One such offering may involve a Metal-as-a- Service (MaaS) hosted and Rancher managed Docker Swarm deployment infrastructure with a modified Docker Swarm scheduling backend that assigns SERECA application containers to hosts with secure enclave support.

Use Cases

SERECA convincingly validate and demonstrate the benefits of the approach pursued by applying it to realistic and demanding industrial use cases. SERECA addresses this objective by running two industrial use cases with widely differing requirements on the SERECA platform.

  • First, a Water Supply Network Monitoring (WSNM) use case is hardened to provide integrity of monitoring data. With this use case the consortium wants to prove that the platform - through the advance security mechanisms - can empower the cloud migration of Critical Infrastructures (CIs) monitoring applications. In fact, CI administrators are still skeptical of moving their IT infrastructure to cloud environments as there are risks, e.g, that malicious cloud admnistrators leverage their privileged position to attack the integrity of sensitive data and so causing catastrophical events. Through the SERECA platform such a scenario would not be possible as SGX protects against those type of attacks. An existing SCADA application - useful to monitor key metrics of 7 dams in southern Italy - is extended to run securely on the SERECA platform. Data from sensors is sent to the cloud-based application to be securely processed, stored, and finally provided to the WSNM operators.
  • Second, an Application Performance Analysis Service (APAS) use case is hardened to provide confidentiality of monitoring data. The APAS use case, in fact, measures performance metrics of softwares service in the cloud (SaaS). It processes performance data from a variety of applications run by its customers to detect bottlenecks in the customer’s software stack. The data contains identifiers that could reveal the customers, which is why the performance data is confidential. The APAS use case represents a typical migration problem of a infrastructure monitoring system to a cloud platform, especially in regulated industries such as financial services and defence. This process of migration is difficult since security risks of cloud environments are not negligible, especially with regards to trusting the people and underlying systems software at the cloud provider / data centre. In SERECA – through the APAS use case – we demonstrate that the security mechanisms provided can mitigate some of the key security risks (around malicious attackers at the cloud provider / data centre).


Positioning of SERECA among realated initiatives

Other initiatives (e.g. , papers or European projects) are exploring the possibility of securing applications running in untrusted cloud with Intel SGX. What makes SERECA different from the others is the vast array of facilities SGX-enabled offered to a final developer, which can be leveraged in a semi-transparent way. 

A first remarkable difference with several other works is that in SERECA we do not use the SDK provided by Intel. In fact, Intel provides an SDK to facilitate the implementation of simple enclaves. It features an interface definition language together with a code generator and a basic enclave library. Unlike SERECA, the SDK misses support for system calls and offers only restricted functionality inside the enclave. We developed, instead, a libc library SGX enabled that support a shielded execution of system calls.

Haven [1] aims to execute unmodified legacy Windows applications inside SGX enclaves by porting a Windows library OS to SGX. Relative to the limited EPC size of current SGX hardware, the memory requirements of a library OS are large. In addition, porting a complete library OS with a TCB containing millions of LOC also results in a large attack surface. By using only a modified C standard library, in SERECA we target the demands of Linux containers, keeping the TCB small and addressing current SGX hardware constraints. GrapheneOS [3] is another example of a library OS ported in SGX. Unlike Haven, in this case the TCB is kept small as we do with our secure containers. However, the performances provided are still low and the usable functionalities are limited. Our secure containers developed in SERECA keep the overhead limited. Furthermore, it must be pointed out that secure containers are only a part of the facilities offered by the entire SERECA platform.

An additional initiative is VC3 [2], which uses SGX to achieve confidentiality and integrity as part of the MapReduce programming model. VC3 jobs follow the executor interface of Hadoop but are not permitted to perform system calls. In SERECA we focus on generic system support for container-based, interactive workloads but could be used as a basis for VC3 jobs that require extended system functionality.

Finally, it is worth to illustrate differences between SERECA and the SecureCloud project as they move in the same direction by using secure containers with SGX support. Figure 5.2 clearly shows the several architectural distinctions. First, in SERECA we provide support for a gcc-based cross compiler SGX-enabled while in SecureCloud this cross compiler is llvm-based. Second, In SERECA we want to harden applications running on top of a JVM while in SecureCloud applications are written in Go/Rust/Python. This means a completely different approach to the infrastructure development. Third, in SERECA we have support for a SGX-enabled secure coordination service, while in SecureCloud a different mechanism based on the bus ZMQ is used. Fourth, in SERECA applications are based on microservices written with vert.x while in SecureCloud applications exchange messages through the ZMQ bus.


[1] Andrew Baumann, Marcus Peinado, and Galen Hunt. 2015. Shielding Applications from an Untrusted Cloud with Haven. ACM Trans. Comput. Syst. 33, 3, Article 8 (August 2015), 26 pages.
[2] F. Schuster, M. Costa, C. Fournet, C. Gkantsidis, M. Peinado, G. Mainar Ruiz, M. Russinovich, Vc3: Trustworthy data analytics in the cloud using sgx, in: 2015 IEEE Symposium on Security and Privacy, 2015, pp. 38-54.
[3] Chia-Che Tsai, Kumar Saurabh Arora, Nehal Bandi, Bhushan Jain, William Jannen, Jitin John, Harry A. Kalodner, Vrushali Kulkarni, Daniela Oliveira, and Donald E. Porter. 2014. Cooperation and security isolation of library OSes for multi-process applications. In Proceedings of the Ninth European Conference on Computer Systems (EuroSys ’14). ACM, New York, NY, USA, Article 9, 14 pages.

Action acronym: SERECA
Action full title: "Secure Enclaves for REactive Cloud Applications"
Objective: ICT-07-2014: Advanced Cloud Infrastructures and Services
Grant agreement no: 645011