Accessing Enclave data in today’s world of virtualization

Conclave Dec 07 2021 By: Sneha Damle




Accessing Enclave data in Today’s world of virtualization
Sneha Damle
Sneha Damle Senior Developer Evangelist, Conclave
Share this post:

Cloud computation is a need of the day, where companies want to minimize the time to market by outsourcing computation to the cloud. This exposes them to security concerns of data being stolen from untrusted cloud/OS/hypervisor.

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 trusted system patched with the latest security updates.

Redeploying Intel SGX enclave on a different physical CPU
Redeploying Intel SGX enclave on a different physical CPU

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, need a reboot.

After putting up a lot of thought, research, and analysis, Conclave has come up with the novel Conclave KDS-Key Derivation Service 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 is, 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. 

There has been a lot of effort to find the best way to migrate the enclave data during this re-deployment phase 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 like the Teechan payment system. 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 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 enclave 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 mutually remote attest to each other before requesting and sharing data.

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

While I talk about KDS, persistence, and sealing, blog posts on how to handle rollback attacks, specific side-channel attacks, why we did not use SGX monotonic counters for rollback attacks would be my following targets. Finally, I will also discuss how you can use KDS in your Conclave application to retrieve a key for persisting enclave data storage.

Thanks to Roy and the Conclave team.

Sneha Damle
Sneha Damle Sneha Damle is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, Corda Enterprise, a commercial version of Corda for enterprise usage, and Conclave, a confidential computing platform.

Leave a Reply

Subscribe to our newsletter to stay up to date on the latest developer news, tools, and articles.