A new Conclave release finishes off the core feature set you need
Today we’re announcing a new beta release of Conclave, a platform that makes it easy to use secure hardware enclaves with Java. You can use enclaves to:
- Solve complex multi-party data problems, by running programs on a computer that prevents the hardware owner from seeing the calculations.
- Protect sensitive data from the cloud.
- Make your hosted service auditable and trustworthy.
- Upgrade privacy on distributed ledger platforms like Corda.
Good use cases might include analytics, auctions, order books, or verifying transactions.
In Conclave Beta 3 we have fleshed out the base feature set available in earlier releases by adding Mail, our communications API, and by integrating support for a new JVM: GraalVM Native Image. You can also now build enclaves on macOS, as well as Linux and Windows when using the Avian JVM.
What are enclaves?
Conclave gives an ordinary Java JAR some new security super powers. It can:
- Protect its memory from the owner of the computer where it runs, as well as the host JVM that loaded it.
- Prove its identity to third parties over the internet. Loading an enclave gives you a serialisable EnclaveInstanceInfo object that describes its code hash and code signer.
- Generate encryption keys that are only accessible to that enclave. Clients can then use the EnclaveInstanceInfo to exchange encrypted messages with the enclave, without the host computer or JVM being able to read them.
You can think of a Conclave enclave as a sub-JVM loaded into the same process as your host JVM. Once loaded both the host and remote clients can exchange data with it.
By encapsulating the core of your business logic in an enclave you can build perfectly auditable services which anyone can trust. How? If you share the enclave code with them under either an open source or, more commonly, a proprietary audit license then with just one command they can compile a byte-for-byte identical enclave to the one you are using. The code hash of that enclave can then be compared to the code hash in the received EnclaveInstanceInfo to be sure the code they are reading is the code that’s really running. The only party that needs to be trusted is the CPU manufacturer.
You can read more about enclaves, how they work and how best to use them in Conclave’s documentation.
What is mail?
Mails are what Conclave calls the encrypted messages you can send to and from an enclave. How mail moves around is up to you — you could use HTTP, plain TCP sockets, message queues, files, embed them in other protocols or anything else you wish. Conclave handles the cryptography and leaves transport up to you.
Mail is designed to solve a variety of different problems that enclaves face:
- How to communicate securely with clients, given the host is untrusted.
- How to avoid needing an external database, as regular databases are not designed to stop administrators accessing the administered data and enclaves themselves have a weak grip on time.
- How to stop the host dropping or re-ordering messages.
- How to stop the host snooping by measuring the size of the messages going in and out of the enclave.
- And other miscellaneous challenges.
The mail API is simple and presents you with an email-like interface. Behind the scenes Conclave can perform ordering checks, message padding, replay on restart and other
You can read more about mail in the documentation.
In beta 3 we’ve added support for truly cross-platform development. Even though enclaves only run on Linux, you can work on an enclave project on Linux, Windows and macOS. Cross-compilation support means you can compile an enclave either for upload to a server, or to reproduce a remote enclave and audit it, on any OS.
Client code can additionally run on any platform that supports Java. Enclaves can be loaded both into the protected environment and also the host JVM, allowing ordinary and convenient step-through debugging, full white-box unit testing and more. If there’s user demand we may also add support for non-JVM hosts and clients.
GraalVM Native Images
An enclave does not trust the host operating system, so it must carry everything it needs into the protected memory space. The GraalVM Native Image tool is ideally suited for this use case, as it produces small, self contained and ahead-of-time compiled native code from Java programs. An embedded JVM called SubstrateVM provides runtime services like garbage collection.
That’s why in beta 3 we’ve added support for using native images. The benefits over the alternative runtime are much better performance, reduced memory usage, and no warmup time. However, it comes at the cost of losing support for dynamic bytecode loading and for compiling enclaves on non-Linux platforms. If you want to use frameworks that do this, you will need to continue using the Avian runtime for now. In the long term we plan to phase out the use of Avian, as SubstrateVM gets better.
Using Native Image with Conclave is easy, you just specify you want it in your Gradle build and the rest is automatic.
Learn how to write an enclave, host and client
Conclave comes with a simple tutorial that takes you through the basics of enclave-oriented development. You write an enclave that simply reverses any strings sent to it, a host that loads the enclave and connects it to a raw TCP socket, and a client that verifies the identity of the enclave and then sends it encrypted strings for reversal.
Along the way you will learn everything you need to build enclave-oriented programs.
Download Conclave Beta and get started
Conclave Beta 3 is available for non-production and evaluation use. Just visit our web site and click “download”.