To run our applications in secure enclaves, we built QuorumOS: a minimal, immutable, and deterministic Linux unikernel build system for use cases that require high security and accountability. QuorumOS also contains an initialization and attestation framework for running applications within this environment.
Each instance of QOS is configured with a Quorum Set – A group of individuals who hold shares of a service’s master secret. This master secret is also called the Quorum Key.
After the service is launched, QOS responds to attestation requests and waits to receive key shares from QOS Operators or members of the Quorum Set. Once a threshold number of shares have been sent into the enclave it will reconstruct its core secret and launch the application it was provisioned with. This process is outlined in the images below:
Remote attestation is the process by which core attributes of a machine can be retrieved and verified from a remote location. The enclave’s secure co-processor, in this case AWS’s NSM, observes the enclave as it is being launched and records certain important values such as the hash of the enclave image, the hash of the kernel, and the hash of the boot filesystem. This means that each attestation request verifies that the code actually running in the enclave is only the code we expect to be running.
After initialization, a user of the system can request an attestation document from the enclave. This document will be signed by AWS PKI and can be validated using the process outlined here.
Every single artifact in our critical application infrastructure builds deterministically. Because of this, we can verify precisely what is running in every enclave in our infrastructure at any point in time. This is an area where Turnkey is completely differentiated.
As described above in the description of QOS, each enclave application is provisioned at launch with a set of key shares that, when a quorum is reached, is reconstructed into a master secret.
At Turnkey we actively use this remote attestation process during that enclave provisioning flow. After deploying a new release of any Turnkey enclave application, QOS Operators verify that an enclave is running a particular version of the application by actually building it themselves and verifying the value they received after building against those provided in the attestation document from the NSM. Once confirmed, they use a defined Production Laptop Provisioning Flow to post in their key share to the enclave application.
We hope to expose this functionality to clients directly soon, to create a new paradigm of transparency and verifiability in a SaaS product and encourage others to follow suit.