This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
Confidential Computing with Serverless Functions
By Roy Hopkins, R3
Serverless functions are a cloud-native development model that allows customers to build applications and services without having to manage infrastructure. Services such as Azure Functions automatically scale based on demand and charge only for the actual time spent executing the application code.
The simplicity of provisioning, managing, and scaling serverless functions makes them extremely popular and provides a compelling reason to move workloads to the cloud. However, there are downsides and concerns when working with Function as a Service (FaaS) platforms which can prevent some enterprises from migrating to the cloud. How can we help address those concerns?
Trust in serverless functions
Let's take a look at a diagram that shows how a FaaS platform might be architected so we can better understand some of these concerns.
Firstly, the developer's code that is used to implement the serverless functions must be handed over to the platform for storage in a database, ready to be invoked by the user. For some highly sensitive applications, service providers may want to keep their code intellectually property private from normally trusted entities such as the cloud service provider (CSP).
Even if we do trust our CSP, what happens if an attacker uploads a modified version of the service code, designed to manipulate results, or even steal data sent to the service?
When it comes to invoking a function there is a fairly complicated pipeline and set of services involved. The user makes a request which is then queued and subsequently allocated to a container that can run the request. The code is then provisioned into the container from storage, parsed and the function is executed. Any return value or result from the function is then sent back to the user. This whole process increase the attack surface.
In summary, there are a number of areas that can be hardened in order to provide a higher level of trust in FaaS implementations:
- Privacy of developer code, protecting it from the FaaS platform.
- Integrity of the developer code: ensuring the code that is provisioned by the developer to provide a higher level of trust.
- Privacy and integrity of user-provided data: Increasing the level of protection so that the data provided by the user can only be accessed and processed by the developer code and cannot be observed or modified by any other entity.
- Privacy and integrity of the result: Protecting data returned by the service so that it can only be seen by the user and that it cannot be modified by any other entity.
Can end-to-end encryption help?
Some messaging services use end-to-end encryption to secure users' conversations. This means that when a new conversation is established, the parties agree upon an encryption key using a secure key exchange which allows that only the approved parties have access to the key, and not the developer.
Whenever a message is sent over the network between parties, the message is encrypted on the sender's device and decrypted on the recipient's device. The solution is designed to prevent unauthorized parties to decrypt or see the plaintext contents of the message: not the developer or the CSP hosting the service. This works because all of the parties that require access to the decrypted data (the sender and recipient) are all trusted. The developer and CSP are untrusted, but they also do not need access to the decrypted data in order to provide the service.
So, can we apply a similar approach to serverless functions? Who is the sender and the recipient in this case? Looking back at the FaaS architecture diagram above, can we identify which actors need to be trusted?
The model is slightly more complicated as we need to consider different levels of trust - different actors need to be trusted with different data as is shown in this table.
Data they are trusted with.
Data they want to send to the service. Response data from the service.
The service code.
The service code. The user's data. The response data.
There are a few things to note here. The developer is not trusted with the user's data. And vice-versa, the user is not trusted with the developer's code. Although in order for the user to trust that the developer's service performs the actions they expect, the developer may choose to trust the user with their code.
Confidential computing to the rescue
Let's take a look at what confidential computing offers us:
- Protection of confidentiality and integrity of data using Trusted Execution Environments (TEEs).
- Integrity of the code that is executing within the Trusted Execution Environment.
Trusted Execution Environments (TEEs) use hardware to provide a secure processor in which code and data are physically isolated from processes outside the TEE. There are a number of different vendors that provide TEE implementations, with the most relevant ones for server workloads being Intel's Secure Guard Extensions (Intel SGX) and AMD's Secure Encrypted Virtualization (SEV)-Secure Nested Paging (SNP).
When we write code to target a TEE, we call it an 'enclave'. When an enclave is running in the context of a TEE, the initial codebase of the enclave is running a known, exact version and that any data processed in the enclave cannot be observed or modified from the outside. We can run our enclave on a server that supports TEEs in the cloud and still get these same protection, even in the presence of an untrusted firmware or kernel on the host server.
So now we know about enclaves we can readdress the list above of areas that need to be hardened:
- Privacy of the Developer's code can be maintained by securely sending it to an enclave, which is designed not to disclose the service code to actors outside the enclave.
- Privacy and integrity of user data can be maintained by only processing the data within the boundaries of the TEE hosting the enclave.
- Privacy and integrity of the result can be maintained by encrypting it within the TEE using a key accessible by the end user.
Using attestation to prove integrity
The final piece of the puzzle is attestation - the evidence provided by the TEE to prove that an enclave is genuinely running within a hardened context. Without this, there is nothing to stop the FaaS platform from saying they are running inside a TEE when they are not, allowing to break the protection by a confidential computing platform.
Both Intel SGX and AMD SEV-SNP include architecture to provide the required attestation, giving cryptographic evidence bound to the CPU hardware that a genuine TEE is hosting a particular configuration of an enclave, including the initial code that is executing within the enclave. Further, a cryptographic public key can be bound to this attestation that allows any data encrypted with the key to be decrypted by that exact enclave running in a valid TEE.
With all the confidential computing components in place we can finally build our hardened serverless platform.
Conclave Functions - a Hardened FaaS running on Azure
R3's Conclave Cloud is a platform for hosting privacy-preserving applications. Built on top of the R3's Conclave SDK, which in turn is built to take advantage of Intel SGX hosted on the Azure confidential computing infrastructure, Conclave Cloud is a platform that gives customers the tools necessary to ensure that access to data is provided only to authorised parties.
This diagram shows how all the concepts we have talked about fit together to provide this service.
Try it out!
All of this is available today! You can create a free Beta account to try Conclave Cloud here, and experience a hardened serverless platform for yourself taking advantage of infrastructure provided by Azure confidential computing!
For a demo, please check out the Conclave webinar.
For more information, please check out the documentation.