Oblivious-based enclave services are currently hosted in AWS, with alternative cloud offerings being rolled out shortly. The architecture provided strives to achieve end-to-end data encryption.
Figure 1: Client to Enclave-Services: Infrastructure Architecture
Virtual Private Cloud (VPC)
Virtual Private Cloud or Cloud network on which enclave services resources will be deployed. The cloud network has public subnets, private subnets, and internet gateways. The public subnet is used for hosting the service gateway, whereas EC2 instances (where the enclaves live) are part of private subnets. Users can choose from 2 US and 2 European regions to deploy VPC for the services. This is helpful if any data residency requirements are required in the EU or US.
CLI & Proxy
The Oblivious client proxy is a listener which accepts HTTP traffic. It is started via a command-line interface (cli) and performs the necessary authentication and attestation when creating a secure connection from the client's machine to the enclave.
The client proxy is responsible for
- validating enclave services using the attestation process,
- performing a handshake with enclave service and retrieving a symmetric key,
- encrypting the user data using the retrieved symmetric key.
It is important to note that TLS is used to connect the client machine to the load balancer in front of the EC2. However, it is payload encryption which protects sensitive data from the owner of the EC2 itself. As such anything sent in the header fields of the HTTP1/2 traffic should be non-sensitive in nature.
Once the proxy is running, the client machine can send and receive traffic via their localhost with a specified port. The encryption, proxy and other related commands do not require any special behavior and as such the client can open a browser to a web page served by the enclave, or can have an application send requests directly.
Service gateway is the only enclave-infrastructure component exposed to the internet and accepts HTTPS connections only. The service gateway is the entry point of request to enclave services infrastructure and prevents certain attacks (such as DoS attacks) from non-authorized traffic. TLS encryption is offloaded at the gateway. Therefore, HTTPS traffic is transformed to HTTP traffic when the request reaches the traffic forwarder. It is the payload encryption which keeps the sensitive body of the request hidden from the infrastructure provider, but as header fields are exposed, information required for logging can be shared through these fields.
Traffic Forwarding within the EC2
The traffic forwarding simply listens to HTTP traffic received by the EC2 and forwards it over virtual sockets (vsock) to the enclave. The traffic forwarding cannot view user data since the user data is encrypted using a symmetric key exchanged during the attestation process. In fact, the traffic forwarding does not process the request, and it is only used to forward the HTTP traffic as it is to the enclave.
The enclave is an isolated computing environment that is hosted in a hardened hypervisor.
Enclave is similar to Virtual Machines (VM) except
- it does not have a network card and cannot make any network call outbound,
- it does not have persistent storage,
- it has minimal processes that are hardened for maximum security,
- it has the ability to request attestation documents from the hypervisor which "prove" the software and environment running in the VM.
Enclaves have other limitations which are handled by Oblivious proprietary components, so your software can run smoothly inside the enclave. There are multiple sub-services that run in the enclave which are discussed in detail in Internal Architecture section.
Oblivious provides three different offerings so that infrastructure can be either shared or dedicated, or deployed in users’ cloud network. Monitoring, manageability, and support from the Oblivious team also vary depending upon the offering user chooses.
1. Oblivious Managed
Oblivious managed offering reuses some of the infrastructure components. Data security and confidentiality are still maintained even though some cloud resources are shared. The Oblivious managed offering is suitable for experimenting, getting hands-on oblivious enclaves services, development purposes, and Continuous Integration pipelines.
2. Oblivious Dedicated
Oblivious dedicated offering deploys a separate cloud network for each service and does not reuse infrastructure components. Users can choose an Oblivious dedicated offering for the production environment of services. This offering also includes additional logging, monitoring, and infrastructure management.
3. Bring Your VPC
Users can bring their own cloud network, and Oblivious will deploy the services in users’ cloud network. Monitoring and management of the services are the responsibilities of the user. Architecturally, infrastructure is similar to Oblivious dedicated where components are not shared or reused, except deployed in users’ cloud network. Users who need more control over the infrastructure can choose this offering.
If you are using the free tier, your services will be deployed on the Oblivious Managed infrastructure.
Oblivious-based enclave services are designed to scale vertically. Scaling horizontally involves transferring data out of enclaves which can compromise confidentiality. Our team is working on scaling horizontally by moving the data in and out of the enclave confidentially. At present, users are recommended to choose a higher configuration for EC2 instances to scale vertically.
Oblivious-based enclave services are designed for higher throughput assuming the size of the requests are higher and the number of requests are fewer.
Achieving data security at REST and TRANSIT is common, and with the AWS Nitro enclaves, the Oblivious tooling and the attestation process, you can now achieve data security even at use. That is to say that the attestation process gives you the gaurentee of data privacy and security as the data is being used.
For security compliance and standards, please refer Cryptographic Operations