Conclave Beta 4: Load enclave from Corda and more

There’s a new version of Conclave out and about, with a whole lot of exciting new features. Writing secure enclaves in JVM languages just got easier, so download the SDK and let’s go over what’s been added.

Easy deployment to Azure

Azure probably has the best support for SGX of all the clouds right now, and in Beta 4 we added full support for it. Conclave now works out of the box on Azure Confidential Compute VMs, and without any need to get an approved signing key: you can self sign enclaves and go straight to ‘release mode’ on Azure. With this new support you can go from code complete to fully encrypted RAM in the cloud in five minutes flat. Read how to deploy your app to Azure to see how simple it is.

This work is enabled by our new support for Intel’s new DCAP remote attestation protocol. DCAP comes with a variety of advantages, one of which is your server no longer has a dependency on Intel servers to start up. Instead your host will contact caching proxies run by your cloud provider to obtain the necessary data at first start, and thus has the same availability as the cloud itself.

JavaScript support

One of the great benefits of building on GraalVM is the support for a range of JIT compiled languages. Conclave can now embed the GraalJS engine which provides V8 quality speed and language support. Learn how to run JavaScript inside an enclave.

In Beta 4 a small bit of Java is required to load the JavaScript into the engine, but an obvious future direction to explore is a generic ‘native’ JS enclave that can be used by JavaScript developers without needing to write any Java or use Gradle. Although we haven’t done that in this release, watch this space!

Smoother developer experience

We’re fanatical about developer experience here at R3 Towers, so this release continues our tradition of polishing the usability of the SDK.

Enclaves are primarily a Linux thing, so you previously needed Linux to compile your enclave for deployment. In Beta 4 the Gradle plugin automatically creates and uses a Docker container for building the enclave, which means compiling them on Windows and macOS now works transparently. You don’t need to do anything except installing Docker, and no Docker knowledge is required. If you like you can re-use the same container to execute your app in a Linux environment for testing. An explanation of how to do that is in the docs, and making that even more automatic is another way we plan to polish the development cycle in future.

We’ve simplified the enclave calling API. The EnclaveCall interface was unnecessary complexity, so we eliminated it. The Mail API was tweaked to make it easier to bind to network connections. Finally, the new remote attestation support allowed us to simplify startup: “attestation keys” and “SPIDS” are no longer required. The Hello World tutorial has been refreshed with this now unnecessary complexity removed. You’ll still need to deal with the older EPID protocol and its requirements if you want to deploy to hardware that isn’t of the latest generation—Conclave continues to support that.

Finally:

System.currentTimeMillis now grants access to the host’s clock with enhanced side channel protections by avoiding an OCALL.
Our module dependencies are better isolated, so you can now use a different version of Kotlin and other libraries to the ones we use to develop the framework itself. This means you can now use Conclave with R3’s Corda blockchain platform. A sample showing this in action is under development.
A new EnclaveHost.capabilitiesDiagnostics API returns a wealth of detailed technical data about the machine CPUs useful for debugging deployments and filing support tickets with R3.
We’ve improved Math.random and related non-secure random number APIs. In standard Java these RNGs are initialized from the system clock, but in an enclave that’s controlled by the host. Conclave now initializes these RNGs from the secure on-chip source of random entropy. The SecureRandom API has already used this source for some time.
The usual assortment of improved error messages, better API naming etc.

Automatic blocking of downgrade attacks

Mail is Conclave’s solution for both async messaging and data storage. In beta 4 we upgraded it to transparently integrate with SGX’s defense mechanism against downgrade attacks (the ‘security version number’).

A downgrade attack occurs when a security problem is found either with your enclave or the support infrastructure and the problem is fixed, but nothing forces the host to stay upgraded. It means the host is able to run the latest secure version when the user is submitting data and then downgrade it to a vulnerable version afterwards to gain illegitimate access. The SGX key derivation function allows enclaves to calculate the keys for their own version and any prior version. That means old enclaves can’t calculate the keys for new enclaves, but vice-versa works.

Normally you would need to explicitly manage “sealing keys” and this downgrade mechanism. In Conclave beta 4 mail identifies which version it was intended for and the infrastructure automatically calculates the correct key to decrypt it.

This allows you to restart an enclave without disrupting conversations taking place with clients, but it’s especially useful when mail is used to store persistent data using the ‘mail to self’ pattern. New enclaves can decrypt old data, and as that data becomes steadily replaced with newly encrypted mails, the system’s security re-seals itself.

Better multi-threading

SGX protects the state of a thread so the host can’t tamper with it. For that to work the enclave must reserve the memory up front for a fixed number of ‘thread slots’, into which the CPU can save and restore thread data.

This raises some questions:

What happens if you run out of thread slots?
How to set the number of slots you have?
How are host threads mapped to enclave threads?

In Beta 4 Conclave handles this complexity for you. If a host thread tries to call into an enclave or deliver mail whilst all the slots are taken by other threads, the host will wait until a slot frees up.

In rare cases you may accidentally write software that can deadlock due to this limit on simultaneously active threads, e.g. a call into an enclave starts a second thread and then waits for it to complete, which may block forever if the enclave has run out of slots. Conclave will now detect such deadlocks and abort the enclave with a helpful error explaining how to add more.

Improved documentation

We re-read and refreshed the entire documentation website for this release, with new content and improvements on nearly every page. For example, we’ve not only made SGX threading significantly easier to use but also written new documentation on threads with diagrams to teach you what’s going on behind the scenes.

You can learn how to configure the threading support and many other things in our new configuration guide. This takes you through the different options available to tune the enclave at build time. The defaults are provided along with explanations of each setting.

The FAQ has new content based on questions we see often from new users: check it out!