So What Exactly Are AWS Nitro Enclaves?

Secure enclaves and trusted execution environments are becoming ever more popular. AWS released their AWS Nitro Enclaves. But what are they and do you really need them?

‍

Nitro enclaves by AWS are Amazon's approach to creating trusted execution environments (TEEs) which are intended to support functions on sensitive data. Amazon by no means invented the concept, and TEEs or secure enclaves have been growing in popularity over the past number of years. 

Hardware players like Intel and AMD have created physical chips which support TEEs, while cloud platforms like Google and AWS have developed theirs based on virtual machines. The latter is our focus today.

Nitro Enclaves Are Trusted Execution Environments

How exactly do Nitro Enclaves give trust to their users? Let's start by explaining what exactly they do and then we can dig into how they are useful.

‍

If you are familiar with EC2, you are likely familiar with the idea of running a virtual machine. When you spin up an EC2 instance, from your perspective Amazon gives you a server that you can access, configure and run programs on via ssh. 

‍

However, they don't actually give you a full physical computer (unless you are using a "bare metal" instance) they give you a virtual machine (VM) running on a server with other VMs. In essence, they carve out a number of CPUs and some RAM for your virtual machine to use. Their hypervisor runs under the hood and manages the VMs running on each server, providing security and access to the network and PCI devices like GPUs, volume memory, etc.

‍

Say you are running an EC2 with 4 cores (CPUs) and 8 GB of RAM, Nitro Enclaves allow you to give back to Amazon 2 cores and 4 GBs of RAM for example. More specifically, you tell AWS to take these resources and run a docker container with them. 

The docker container can run anything you like, but when you hand it over to Nitro you lose access to it other than a single socket connection using Virtual Sockets. You can't see any internal console messages, logs, or anything. Only the input and output of the sockets. 

Further, only the parent instance (ie the EC2 that created the enclave) can communicate with the docker container running inside the enclave.

‍

So basically this is just a worse EC2 instance inside an instance? Not quite. The enclave itself has two superpowers that make it exceptionally useful:

1. The enclave can speak directly to Amazon's KMS (key management service) over TLS. So if you encrypt data of any kind and the code running inside the enclave needs to decrypt, then it can do so without talking explicitly via the parent instance.
2. The enclave creates a hash of the docker container (called an attestation) inside the enclave when it communicates to the KMS. This allows you to create access rules within the KMS so only enclaves with a particular hash (ie a specific pre-agreed docker container, running pre-agreed code) get to decrypt data. This can actually be used to talk to custom KMS or equivalent too, proving what's running in the enclave.

‍

Admittedly neither of these superpowers sounds that impressive at first glance. But give it a minute or two and you begin to see the power it creates.

‍

Traditionally, when we use a KMS we create rules about who can encrypt and decrypt data based on IAM roles in Amazon. Basically, you can say Alice is allowed to encrypt and decrypt data with some key, or the EC2 instance with ID XYZ can use the key and so forth. The problem with this is that you are trusting Alice or the specified EC2 instance to only use the data for a particular use. You don't have any guarantees they will actually do that though. Alice may be malicious and the EC2 you chose may have been corrupted.

‍

You also don't really have any reasonable verifiable log of what the data was used for. Perhaps the EC2 is running some code from GitHub, but which version was it running on June 7th, 2020? Not always an easy question to answer. You may have tried to solve this with logs throughout your CI/CD pipeline but you don't actually have any guarantees.

‍

Now you do with Nitro Enclaves because only the version of code (and every other minute detail of how it runs in a docker container) will have the attestation (hash) that is required to decrypt the data using the KMS.

What Do Nitro Enclaves Empower Me To Do?

‍There are two main categories of benefits from Nitro enclaves; verified assurance of how data is used and multiparty computation. Let's discuss each in a little bit more detail:

‍

Verified Usage of Data

‍We've kind of alluded to this already, but suppose you have some sensitive data that you need to keep safe and you want to ensure that it is only used for pre-agreed purposes, then Nitro is your friend. 

You can keep your data encrypted at all times and only allow it to be decrypted within enclaves that are running a particular pre-approved program. This really helps to achieve internal standards towards GDPR's Data Minimisation philosophy.

‍

Multiparty Computation‍

This is one of our big focuses at Oblivious. Multiparty computation is any computation that requires input from multiple parties that they are unwilling to share in plain text (ie they won't let the other parties see their data or software). 

There are typically three approaches to performing multiparty computation: 

1. find a trusted third party to facilitate the joint computation, 
2. apply a specific cryptographic handshake, or 
3. use a secure enclave 

In the context of Nitro enclaves, the multiparty computation can be performed provided all parties have access to the Amazon KMS. Each party encrypts their data and sends it to the party who is hosting the enclave. A pre-agreed docker image is running in that party's EC2 and the enclave attests this when requesting the keys to decrypt the data within the enclave. 

This is a game-changer for secure SaaS, whereby you trust the security of AWS, but not necessarily the counterparty you are working with.

‍

Are There Any Drawbacks of Nitro Enclaves?

‍Yes, more than a couple! Amazon Nitro is a great step forward for AWS users but there are a few things you should probably also know:

1. The security model is very much tied to that of Amazon's EC2s. This is pretty robust and has more certifications than you can count, nevertheless, Nitro Enclaves are still a new technology and you should be aware that new technologies always bring some potential unforeseen risks.
2. Enclaves generally, albeit Intel's chips through to Nitro enclaves, don't protect against many obvious side-channel attacks. For example, imagine we used it to make predictions to say if an image contained a picture of a cat or a dog. Hypothetically it took 1.2s to run whenever there was a dog in it and 1s whenever there was a cat, then the parent instance could simply log the run times and know exactly what was contained on encrypted images being sent in.
3. Memory is in RAM. To keep the enclave extra safe, all of the resources required by the docker container need to be stored in RAM and RAM is expensive. You can of course pass larger chunks of data in and out of the enclave as required, but encryption and decryption must be performed in each direction to keep that data safe.
4. No PCI device access. If you were hoping to start crunching lots of data on an NVIDIA GPU, you'll be a little frustrated as you can't use any compute other than the CPUs delegated to the enclave at build time. 
5. Debugging can be a real pain too. As we've been working a lot with Nitro we've developed some tools that make our life a lot easier, but at the very beginning of our journey with Nitro, the debugging was a pain.
6. If security is your number one concern, there are a lot of ways to break the security of the code contained in the docker image is insecure in the first place. All the enclave guarantees is the container specified is what's running, not that it's in any way safe.
7. The enclaves only have that direct connection to Amazon's KMS, not Google's or Azure's for example. So if you are hoping to do multiparty computation you need all parties to be using the Amazon KMS to encrypt their data.

So Why Has Oblivious Been Tinkering with AWS Nitro Enclaves?

Multiparty computation (MPC) and privacy technologies are what we build at Oblivious. We started the company focussing on building very specific MPC cryptography protocols but as we began to engage with a larger number of customers we realised there was an ever more pressing challenge to balance security, privacy, and flexibility. Enclave technologies offer a different set of trade-offs to purely cryptographic protocols. Not better or worse, just different.

‍

We found that while some large organisations can afford to pay for bespoke crypto, 99% of businesses cannot. Enclaves offer a very flexible alternative approach for mainstream companies, especially those who already have the software they wish to secure as prototypes or which leverage other larger frameworks and libraries. 

Unfortunately, it is still not trivial to implement software on enclaves, manage access to the enclaves, and assign roles and users to code running within enclaves in the context of multiparty computation.

‍

That's why we built OBLV Deploy, which includes an enclave management system (EMS) for AWS Nitro. This allows every AWS user to take advantage of Nitro enclaves for data analysis, machine learning, and differentially private data access control.

If you are interested in learning more about how you can implement secure enclaves, in your organisation, contact us via our website or drop us a line at hello@oblivious.com.