Accessing Enclave Data in Today's World of Virtualization

Cloud computation is a need of the day, as companies want to minimize time-to-market by outsourcing computation to the cloud. However, this exposes them to security concerns of data being stolen from untrusted clouds, operating systems or hypervisors.

The Conclave SDK uses hardware-enabled security architectures like Intel® SGX to address this issue by running this computation in an isolated memory called an enclave. Remote attestation helps this enclave prove to the end-user that a specific code is running on a particular SGX-enabled system patched with the latest security updates.

Usually, enclave data is encrypted by a key known only to a specific CPU so that only this CPU can decrypt this data. This key is called the sealing key.

However, this conflicts with the cloud setting, where the cloud provider can select a different physical machine when redeploying the VM. This leads to enclave data not being accessible on other VM’s as the data is sealed using a key known only to a specific CPU. There can also be situations where systems crash and need a reboot.

After putting up a lot of thought, research, and analysis, the Conclave team has come up with a novel Key Derivation Service (KDS) to solve this problem. I will be talking about KDS in this blog, the thought process behind the proposal of KDS, and how we mitigate some of the issues when it comes to VM re-deployment in a cloud environment.

Thus the question remains: how do we always have access to the enclave data irrespective of which underlying physical machine the VM gets redeployed to? We need a way where the enclave data can be persisted and reloaded each time when the enclave is reloaded onto a new physical machine. To achieve this, we also need to think about enclave data persistence.

You even have to consider the best way to migrate the enclave data during this re-deployment phase, and yes, there has been a lot of effort to identify ways to achieve this in the market. However, there hasn’t been a lot of effort to provide persistent capabilities of the enclave to external storage. Not handling enclave state/data migration correctly could lead to data loss or attacks against the current secure systems available in the market. Hardly anyone has come up with a holistic solution until Conclave!

Real-world use cases do require enclaves to save their data onto persistent storage. Thus when considering enclave re-deployment/migration, it is critical to consider migration of the persistent state.

To support data persistence, migration, and re-deployment to a new physical system by the cloud provider, merely encrypting the enclave data using a sealing key (key known only to the CPU) will not make sense. We now need a way to obtain stable keys that can be used for persisting data regardless of what physical system the enclave is running on.

R3 developed the Conclave Key Derivation Service (KDS) that can be used to solve this problem. KDS fetches a key called Master Key from a Master Key Provider. KDS itself is architectured as a Conclave enclave that requests a key. Application enclaves can use the derived key obtained from the KDS for encrypting and saving data to the database. This architecture frees the KDS from the storage of private keys.

The KDS can derive keys from a number of different master key sources (like AWS KMS, HSM, peer to peer, etc.), which is up to the enclave developer, thus making the KDS MK provider agnostic. The KDS and application enclave can also mutually remote attest to each other before requesting and sharing data.

That was KDS, which is used internally within the Conclave SDK. From a developer perspective, you get the benefit of stable, persistent keys regardless of which physical machine the enclave is running on, thus also making it possible to migrate enclave state/data by maintaining SGX security guarantees without affecting the performance.

Want to learn more?

Below are some helpful resources to learn more about Conclave and Confidential Computing.

• Read the Conclave 1.2 release notes.
• Visit the Conclave docsite.
• Join the Conclave Discord channel.
• Join the Conclave mailing list, where you’ll have a direct line to the Conclave developer team.