Preparations for Conclave 1.2 release
Let’s have a quick peek at what the Conclave has been cooking up! The flavors and the aroma are giving a promising picture of the final dish. The work being carried out for the next Conclave update is exciting and promising. This blog should give you an idea about what to expect in the next chapter of Conclave.
Conclave is a very effective framework, primarily focusing on protecting data in use. For those who haven’t heard about it yet, let’s review the key concept:
The goal of the upcoming update is to smoothly accelerate our customer’s journey to production. Any timely input from your previous experience will allow us to address your issues promptly. Any input about changes to Conclave will be invaluable to us as we strive to make Conclave a better product for you.
For Conclave 1.2, we are focusing on these areas of enhancement:
- How can an enclave which is loaded on one VM be migrated to another instance/physical machine?
- What will happen if the host application stops the running enclave?
- How do we re-start an enclave from a correct previous state?
- How do we prevent a malicious actor from rollback attacks/swap state attacks, i.e. how do we prevent a malicious actor from violating the integrity of a protected application state by replaying old persistently stored data or by starting multiple application enclave instances?
- How can we make it easy for conclave developers to quickly get started with writing Conclave applications?
In the scenarios mentioned above, once the enclave stops running, the enclave’s data memory is lost and there is no way to return to the previous state. Enclaves should therefore have the ability to persist data.
Sealing is a technique that allows the enclave to encrypt the enclave’s data using a sealing key known only to the enclave and which is bound to the current CPU. Using this key, the encrypted data can be securely stored in persistent storage outside the enclave. The sealed data can later be retrieved by this enclave and decrypted.
But providing persistent capabilities alone will not be sufficient. We also need a way to ensure the sealing key used to encrypt enclave data is not bound to a specific CPU. This will help us to easily migrate enclave data from one system to another.
We also need a way to restore the enclave’s latest and correct persistent state in case of enclave restart. We need a way for the enclave or the client to ensure the last restored state has not been modified, and it is genuinely the latest state and not an old state. We would love to get your feedback/recommendations on the above-mentioned scenarios. Feel free to reach out to us on our conclave Slack channel or write to us on groups.io. To learn more, make sure to visit conclave.net.