In this section we have shown how serverless applications could be secured using trusted execution. For this purpose we designed a prototype architecture of a trusted server-less platform which we called TSP, and implemented two variants of it using two dif-ferent JavaScript interpreters each with its own specific benefits and characteristics.
WithSeDukwe have shown, that a lightweight platform can be built upon the Duktape JavaScript interpreter, however, while featuring low general platform overhead this vari-ant can only achieve limited overall performance. In contrast,SeGoo, our second variant of the TSP based on the Google V8 JavaScript interpreter is much more heavyweight, but it achieves a much higher performance due to complex additional interpreter fea-tures such as a JIT compiler.
5.5 Summary
From a security point of view, theSeDukoffers the leaner TCB whileSeGoois relatively heavyweight as in our specific case it required the SGX-LKL project with LKL inside the enclave. Still this approach is valid in practice as the trusted code base does not comprise any of the business secrets of the cloud provider which would be problematic as all trusted code needs to be published to allow (remote) attestation.
Isolation of untrusted code from distinct entities is an additional crucial factor for a platform like TSP as it is important to prevent one cloud customer to interfere with applications of another one. In this regards, we consider theSeGooplatform more se-cure as the isolation mechanism used in this platform variant (Google V8 isolates) has been built from the ground up with security in mind. In light of recent CPU security vulnerabilities (e.g. Meltdown [68], Spectre [60]), isolation using software mechanisms withinone address space without hardware-based process isolation should be consid-ered risky. This is relatively critical for the initial use case of the Google V8 engine in the Google Chrome browser, as the threat model here is to isolate multiple potentially malicious JavaScript scripts to protect the user. In case of TSP which supposedly runs in the cloud, special measures could be implemented to enforce Spectre mitigations in the CPU and protect end users from such attacks solely through security-aware Lambda providers. For example a responsible Lambda provider could detect whether or not a vulnerable hardware platform has these mitigations in place (with a cryptographically protected proof during remote attestation) and refuse deployment of Lambdas on an unpatched hardware platform otherwise.
6 Conclusion
This thesis targeted achieving trust into a generally untrusted cloud. The main overall challenge thereby lies in managing the balancing act of using computing resources of an untrusted party (the cloud provider) while processing sensitive data with those resources without the cloud provider being able to access that data.
6.1 Research Challenges
The first building block for achieving this was enabling trusted execution in an un-trusted cloud setting in general. Therefore, we firstly investigated the ARM TrustZone technology as an example of a commonly available trusted execution technology in this thesis. In this context we have discussed the general issues and manyfold risks with trust in a cloud computing scenario as well as defined the requirements for achieving trust in such a setting. As a proof of concept and the first major contribution of this thesis, we designed and implemented the TrApps platform which allows execution of multiple trusted components isolated from each other in an untrusted cloud.
Next, in this thesis we examined the question how existing cloud-related applica-tions could be secured using trusted execution technology, either on top of our ARM TrustZone-based TrApps platform or using the at that time newly available Intel SGX technology for x86 architectures. Hereby, we investigated the porting process of exist-ing applications for trusted execution in an untrusted cloud environment by usage of trusted execution technology. In order to show the feasibility of this, the following con-tributions as part of this thesis were made: on the TrApps platform we designed and implemented the Secure Memcached application, while we presented the SecureKeeper and Dumbledore prototypes secured using the Intel SGX technology.
Finally, with serverless cloud computing we also investigated a modern software ar-chitecture and cloud computing paradigm. Hereby, we investigated how that newly popular paradigm of cloud computing could be secured using trusted execution and provided a generic Lambda platform that supports SGX-secured Lambda execution as the last major contribution of this thesis.
6.2 Enhancing Cloud Security with Trusted Execution
From the various presented prototypes we can conclude that integrity is an important basic requirement to build upon in order to create any kind of trust into a system re-motely. Without protecting the integrity of a software component including the under-lying hardware platform by means of remote attestation or a trusted boot, it could not be plausibly assured to a user that the intended and probably verified software stack is actually deployed and trust could not be established as a basic building block of sen-sitive data processing. Building on top of integrity, the confidentiality of application code is only optional while being desirable in certain cases, as scenarios are imaginable that can tolerate inspection of the code by the cloud provider as long as the secrecy of keys and user data is guaranteed.
The above hypothesis also implies that at least a very basic secret key storage is an-other crucial requirement for all trusted cloud platforms as without it no sensitive data processing is possible. As long as the cloud provides the means to store at least one key in a secret way, a secure vault containing more secret keys can be bootstrapped and secured with that single master key. Furthermore, in each trusted platform there must always be one key that initially establishes the root of trust where all trust is eventually derived from. In case of our ARM TrustZone-based TrApps platform there is the key that verifies the very first image booted on the hardware platform, while in case of SGX-based applications there is the key integrated into the SGX CPU during manufacturing.
The protection of this root key is crucial as all trust is eventually derived from it.
Once a basic level of trust into a platform in the cloud is established and the re-quirements like a secret key storage are met for running a secure application, the next challenge is the development of such applications running with the help of trusted ex-ecution in an untrusted cloud. In this regard we have shown that partitioning of appli-cations is feasible, but requires manual work for splitting the code base and identifying all sensitive code and data of an application. While approaches exist that try to automate that process, complete automation of this procedure has not yet been achieved.
Another approach, avoiding the partitioning of existing applications is the execution of complete applications unchanged on top of a trusted cloud platform. While this is arguably not feasible or at least not performing well for very large applications, we have shown for smaller components that running them unchanged without porting is pos-sible with Lambdas on our secure serverless cloud platform. While it surely implies noticeable performance penalties, this still shows that a transparent security layer is feasible and an application could—under several assumptions as described in Chap-ter 5—be secured by flicking a switch (and paying a lot more). As computing resources