This post will show you how to use the R3 Conclave platform to run a relational database inside a secure enclave easily
Things to know is that using a TEE for loading the database inside an enclave makes data privacy secure, and that the latest Xeon’s Ice Lake enclaves can now protect up to 1 TB of code and data while in use.
Now, Conclave 1.2 provides you with several ‘side channel’ mitigations such as necessary persistent capabilities to ensure that the correct previous database state is loaded back into the enclave.
Modeling a database inside an enclave using Conclave SDK : All the file I/O operations from the Conclave enclave are mapped to a persistent file system represented by a single file in the host file system. This persistent file is saved in an encrypted format, and hence the host can’t access this file and Conclave even randomises the write patterns so the host can’t use statistical techniques to guess what the enclave is doing.
You can either use the root sealing key to encrypt this file or use a key provided by the Conclave KDS. Encrypting the file using the root sealing key ties the enclave code/data to a particular CPU. Whereas encrypting the file using a key derived from KDS lets you migrate your enclave data onto another physical system.
H2 database in an enclave, using Conclave SDK : Learn how to create a table in H2 loaded inside an enclave. Create a table, insert records into it and select records from the table. You will pass in the persistent file name while starting the host to run the sample. As a Conclave developer, you will focus on writing your application code, and you don’t have to deal with mapping the I/O calls to a persistent file as the Conclave SDK handles this. You can access the code snippet here.
For more information on the database building please visit R3’s blog post.