Will Open-Source SDKs Improve the Adoption of Confidential Computing?

If you have been following the Confidential Computing space, you would have noticed that many Software Development Kits (SDKs) that use Trusted Execution Environments (TEEs) are pursuing the open-source route.

It might seem counter-intuitive that the SDKs promoting privacy-first computing allow their source code to be visible for everyone to see. However, open-sourcing an SDK is essential to improve the trust and transparency of a privacy-enhancing technology. 

What Is Confidential Computing, and How Can Developers Get Started? 

Confidential Computing is a fast-growing technology that protects data at rest, in transit, and during processing. While traditional encryption techniques focus only on protecting data at rest or in transit, Confidential Computing goes the extra mile to protect the data being processed. One of the methods to implement Confidential Computing is to use Trusted Execution Environments (TEEs). TEEs use hardware-based techniques to secure a region of the CPU in which code and data are physically isolated and cannot be tampered with, not even by the cloud administrator or the system. Such secure regions are called enclaves.

With enclaves, use cases which were previously not possible are now possible. For example, insurance companies can detect multiple claims for the same bill without revealing customer data to their competitors. There are several other use cases in which an organization can develop internal applications that protect customer data.

Those driving the Confidential Computing movement are now ensuring the simplicity of development and deployment. For example, some SDKs provide powerful high-level APIs that can hide the low-level complexities of using TEEs from manufacturers like Intel and AMD. Thankfully, you can now develop enclaves using high-level languages such as Java, Kotlin, and JavaScript, making the coding of confidential applications easier. 

With such easy-to-use SDKs, you can concentrate more on your enclave’s business logic and applications. A few of these core SDKs also power cloud solutions to provide privacy-preserving SaaS platforms for deploying confidential, event-driven workloads. 

The Decision to Go Open Source

So, why would an SDK that promotes privacy-first computing reveal its source code to the world?  

Confidential Computing aims to remove the need to trust the different participants involved in application development. Using Confidential Computing, you can remove the need to trust your cloud service provider, application service provider, or any software stack. So, if you can't verify the source code of an SDK that simplifies Confidential Computing, how will you be able to trust that service? Open sourcing is, therefore, a critical choice, allowing users to verify and audit the service's source code, even removing the service provider from your trust model. If you use an open-source SDK to code your privacy-first application, the only source of trust, in many cases, is the CPU manufacturing company.  

Building and growing a community around any trust technology is also essential. Open sourcing-builds an active community of developers invested in the nuances of the technology. It also allows easier accessibility, improved transparency, collaborative development, innovation, and accelerated adoption of Confidential Computing technologies.

Making Confidential Computing Accessible to All Developers 

Some Confidential Computing technologies like Zero-knowledge proofs and homomorphic encryption need developers with advanced skills in cryptography to develop secure applications. However, if we intend to make data privacy the default for any business, it should be easy for most developers to work on a privacy-first application. SDKs that use TEEs are more user-friendly when compared to other Confidential Computing technologies. 

The following are the key factors that SDKs should focus on to improve their usability.    

• Developer friendliness: Provide high-level, intuitive APIs to help developers write secure applications.
• Platform Independence: Make it easy to work on different operating systems.
• Support multiple languages: Developers should be able to write code in Java, Kotlin, Javascript, Python, or any other language. 
• Remove Messaging Complexities: Implement easy-to-use, end-to-end encrypted messaging techniques to communicate securely with enclaves. 
• Cloud Support: Any core SDK solution must tightly integrate with a complementary cloud offering.
• Stability: Create stable applications that maintain security guarantees even when the enclave runs on multiple physical machines or when the enclave restarts.
• Enhanced security and performance: Use technologies like GraalVM native image for tight memory usage and fast start-up time.
• Cloud Deployment: Simplify the deployment of secure applications to the cloud.
• Auditability: Application developers or auditors should be able to verify the enclave’s source code remotely.
• Automate and Abstract: Use plugins to automate and abstract compiling, signing, and calculating the code hash of enclaves.
• Robust testing framework: Implement a comprehensive and easy-to-use framework for testing the application and verifying remote attestation. 

With a Small TCB Comes Greater Responsibilities 

Intel’s SGX (Software Guard Extensions) based CPUs have a very small Trusted Computing Base (TCB). You need to trust only the CPU and some support software if you implement a privacy-first application that works on SGX-based. An SGX-based secure application assumes that everything in the computer other than the CPU is malicious and defends against them using encryption and authentication.

While the small TCB strengthens the security model of SGX-based enclaves, it has some less-obvious implications. 

An enclave cannot directly access hardware. Like any other program, it must ask the operating system’s kernel to handle requests on its behalf, as the kernel is the only program that can control the hardware. However, inside an enclave, there is no direct access to the OS. Enclaves can communicate with the OS only by exchanging messages through the host code.

For example, the system clock falls outside of the TCB. Developers frequently use the current time for coding application logic. As a real-time clock chip outside the CPU maintains the current time, developers should consider the risk of an untrusted machine owner tampering with it. So, you should use the current time inside an enclave only if any errors in it are not detrimental to the security of the application. 

If any of the components (host software, kernel, the hardware itself) are malicious, there is a security issue when enclaves access hardware through exchanging messages with the host. All developers looking to start deploying their privacy-enhancing applications must remember that enclave protections do not apply to the entire computer. They are a feature of the CPU. 

Next Steps 

If you are hearing about Confidential Computing for the first time, it's an excellent idea to start with a hello world sample to see how easy it is to build enclaves in languages like Kotlin and Java. 

Happy coding!