General Principles
Privacy, security and guarantees.
Before building applications for Nitro enclaves, let us first recap:
- What are AWS Nitro Enclaves?
- How we can use them to make guarantees about privacy and data security?
- How can we hide and expose information to achieve privacy criteria?
AWS Nitro Enclaves
Amazon Web Services (AWS) released their AWS Nitro Enclave offering at Ignite 2020. Unlike hardware based enclaves, AWS enclaves are managed mostly through software via the hypervisor of EC2s. While there was initially some skepticism from hardware-based enclave users as to this approach, Nitro offered the ability to provide very flexible resource allocation to enclaves. You can select how much RAM you require and how many CPUs. This is a dramatic improvement in terms of usability for many applications. While this approach still requires some trust in AWS themselves, it offers an excellent mechanism to broker trust between parties such as collaborators, API providers and queriers, between IT security/governance teams and application developers. At least in theory.
The challenge remains that building tools, even on Nitro, isn't easy. That's where Oblivious comes into play. Our tools intend to make using enclaves easy. We hope you'll agree.
Service Guarantees
Enclaves have two properties that are useful in keeping data protected through its usage. The first is that it has limited input/output. All communication is over virtual sockets (vsock) and thus all external communication has to be proxied via one mechanism or another, from virtual sockets to TCP/IP through the parent instance (that is to say the EC2 server that created the enclave).
The second property is called attestation. When the enclave is first created, the underlying hypervisor's Nitro security module (NSM) hashes the environment and source code of the enclave. These hashes are then set inside a document and digitally signed by the NSM. Programs in the enclave can request this attestation document along with some optional user data, public keys and nonces. As such, programs running inside of the enclave have the ability to "prove" what software is running in the enclave. Optionally, programs can also ask to add additional hashes to the attestation document as required by the application layer. This gives enclaves a powerful ability to create trust with other systems, guaranteeing how data is processed, safeguarded and dispensed of.
Hiding the Sensitive and Exposing the Guaranteed
As stated, attestations allows the application layer to prove the software and environment running in the enclave. What it does not necessarily expose is anything about data transmitted to the enclave once the enclave has been created. We use the cautious term "necessarily" simply because it depends on the application layers requests to the NSM and the user data, public key, additional hashes and nonce provided by the application layer. For example, if you wished to "prove" user input at a later date, perhaps sharing a hash of the run-time attained data may be useful. However, this is not the norm by default.
As a general rule of thumb, especially as you are getting started, when thinking about designing enclaves, we can think of everything put in the enclaves when it is being built and deployed is guaranteed by the attestation process, everything uploaded to the enclave at run-time is typically kept secret. The code in the application layer is what assures this in a specific deployment.