Improving Secure Enclaves Interoperability 

With the Secretarium SDK v3, we have introduced a radical improvement in enclaves communication.

A brief primer

Confidential computing is all about getting business logic into Trusted Execution Environments (TEEs). These isolated environments within the CPU are known as secure enclaves and allow sensitive computations to be performed securely.


Intra-app and intra-enclave communication

We needed a means to easily connect applications within or between enclaves transparently, and call methods in each apps as if they were a local function. We wanted the complicated details of local and remote attestation to be made transparent to the application developer. The idea being that apps could call themselves, call other apps within the same enclave, call an app in a separate enclave or even an app outside of the Secretarium domain.


Introducing the Secretarium IDL

A Secretarium app is a set of APIs. Developers need to provide an interface specification that describes their APIs, and then Secretarium registers the app and makes these APIs accessible by web clients and other apps.

To make it easier, we have introduced an Interface Definition File (IDL), which is a concept that has been around at least as far back as the 1980s. An IDL is a type and function calling declaration language used for generating code for Remote Procedure Calls (RPC). Intel too uses this idea in their EDL files to define a list of functions that is callable by either side of the secure enclaves.

The most well-known implementation of this technology is Microsoft's COM/DCOM and the Object Management Group's CORBA. They both went out of favour when the internet took off and web developers wanted to use RESTful type API's. COM and CORBA failed on this as their respective transports were too opaque and/or inconsistent with http communication and security protocols of that era.

Our IDL is a separate, but almost identical file format from normal C++ headers. It needs additional attributes such as whether a function parameter is an inbound value or an outbound value. Custom attributes are also useful such as tagging a function to indicate it should run as a transactional function in a dedicated thread (Secretarium has total ordering of transactions when used over a cluster of machines).

Our IDL implementation supports namespaces, and we strongly recommend that when designing components, namespaces with versioning is used. Once an interface is in production, it cannot change. If a change is required, a new interface should be declared, and this way we can guarantee ABI compliance between different systems. This is also true inside Secretarium Core, as our regression tests guarantee that we do not break backwards compatibility. When an interface is designed, the Secretarium RPC (sRPC) code generator assigns the interface a unique fingerprint for that interface and related types.

With our CMake build system, the IDL code is transformed into a set of headers and other function marshalling code.


How it works in practice

We have introduced a helper-based template class called service::v3::route_reflection. With this variadic class, it is possible to enumerate all the functions that an app is supporting and their calling convention.

To communicate with other apps, we have introduced the get_service function. It supports IntelliSense and offers a great developer experience. The returned interface can then be called such as this:

auto err = sdk::v3::get_service<io::v3::i_io>("Secretarium.IO_SERVICE")->https_query(request, response);

Although one would normally write code defensively, for brevity this one liner does several things. First, it tries to connect to a service called "IO_SERVICE", and then interrogates it to see if it supports the interface io::v3::i_io. If successful, a callable shared pointer is returned.

The function https_query is then called on that interface function. If the service is running in a different location to the application, the sRPC library will serialise the output parameters into a byte array and send it to the destination service where it is deserialised and called. Once complete, the output parameters are then serialised and deserialised in the opposite direction back to the original caller.

The returned pointer from get_service is a rpc::shared_ptr, semantically identical to a std::shared_ptr but with additional features necessary for communicating with remote objects. For instance, there is an rpc::dynamic_pointer_cast function that will interrogate a remote object to see if it supports a particular interface, so identical in design intention to the STL.

Calling an enclave from another enclave can be messy in that it has to be routed via the host before being sent to the second enclave. If the call stack is too big, the caller will need to spawn a new thread to continue the call. If the enclave is talking to another enclave for the first time, then a local or remote attestation is used to verify the measurement, and a Diffie Helman exchange secures the communication. The sRPC library manages all these things to provide a seamless experience for the application developer.


Future plans

We already have SPSC queues successfully working between enclaves and their host for fire and forget messaging for telemetry. We are extending that to allow communication between enclaves which can share the same memory for more efficient communication.

We can then bypass the host, which will allow us to explore the use of executors and coroutines to increase aggregate throughput of non-transactional communication, scaling our platform considerably. Currently, we are running one function call per thread, when we could have thousands.

Finally, we plan to work on the integration of sRPC with Google RPC (gRPC) and further increase the interoperability of the confidential computing services we host.

Get in touch

If you want to know more about our technology, please don't hesitate to schedule a free demo with our experts.

Book a demo

Read next

We actively engage in highly innovative projects. Explore our latest publications featuring our cutting-edge technology.

Digital Asset

Secretarium Announced Swift Hackathon Winners

Secretarium is proud to announce our victory at the Swift Hackathon 2024! Our team tackled Challenge Statement 2, focused on developing innovative solutions to ensure data privacy in tokenised trades, and successfully built a fully functional prototype in only five days.

BoE
Digital Asset

Secretarium's Role in the Bank of England's Digital Pound Project

Explore how Secretarium contributed to the Bank of England's digital pound, highlighting the role of confidential computing in enhancing privacy and security.

BIS Win
Data Collaboration

Secretarium and FutureFlow Win BIS Innovation Hub Analytics Challenge 2025

Secretarium, in partnership with FutureFlow, has won the Bank for International Settlements Innovation Hub Analytics Challenge 2025. The solution enables public and private institutions to share data and intelligence while preserving user privacy.

Forking, cloning, and rollback attacks threaten application security in TEEs like Intel SGX. Secretarium mitigates these risks.
Technology

Preventing Forking, Cloning & Rollback Attacks

Forking, cloning, and rollback attacks threaten application security in TEEs like Intel SGX. Secretarium mitigates these risks.

Google Champions Secretarium
AI & AI Agents

Google Champions Secretarium

Secretarium has been recognised by Google as one of "16 startups using AI to make our world safer", highlighting our cutting-edge approach to secure and confidential computing.

Unicorn Factory
Technology

Secretarium Joins Cohort 7 of Unicorn Factory Lisboa’s Scaling Up Programme

Secretarium has been selected as one of ten startups worldwide for Cohort 7 of the Unicorn Factory Lisboa Scaling Up programme, an initiative supporting high-potential scaleups in their growth journey.

How advanced consensus mechanisms like Secretarium's BFT-RAFT are pushing the boundaries of distributed computing.
Technology

Engineering Resilience: Redefining Fault Tolerance

How advanced consensus mechanisms like Secretarium's BFT-RAFT are pushing the boundaries of distributed computing.

Honest Computing Image
Technology

Honest Computing

Systems that can't lie: Inside Secretarium's new "Honest Computing" technological solution.

Subscribe to Secretarium insightsGet short, sweet and brief product updates, company news, and more.