According to the Confidential Computing Consortium, a Linux Foundation project, computing is moving to span multiple environments, from on premises to public cloud to edge. As companies move to these environments, they need protection controls for sensitive IP and workload data and are increasingly seeking greater assurances and more transparency of these controls. Current approaches address data at rest and in transit; confidential computing will address data in use.

Confidential computing

Confidential computing is a term defined by the Confidential Computing Consortium (CCC). The Confidential Computing Consortium is a Linux Foundation Project brings together hardware vendors, cloud providers, and software developers to accelerate the adoption of Trusted Execution Environment (TEE) technologies and standards.[1] The founding premiere members include Alibaba, Arm, Google Cloud, Huawei, Intel, Microsoft and Red Hat. General members include Baidu, ByteDance, decentriq, Fortanix, Kindite, Oasis Labs, Swisscom, Tencent and VMware.[2]

Confidential computing is defined as the protection of data in use by performing computation in a hardware-based Trusted Execution Environment.

–Confidential Computing Consortium, “FAQ - Confidential Computing Foundation,”

Let us take a brief detour to understand Trusted Execution Environment (TEE).

Trusted Execution Environment

TEEs are built on top of separation kernels.

A separation kernel is defined as “hardware and/or firmware and/or software mechanisms whose primary function is to establish, isolate and separate multiple partitions and control information flow between the subjects and exported resources allocated to those partitions”

–Information Assurance Directorate of the US National Security Agency (NSA) in the publication titled “U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness”

At its core, the separation kernel should provide:

Protection of all resources (including CPU, memory and devices) from unauthorized access
Partitioning and isolation of exported resources
Mediation of information flows between partitions and between exported resources

The separation kernel is what provides us with two isolated environments, i.e., the secure environment (TEE) and the real world (REE). It controls the information flow between the two environments and protects all resources in the secure environment.

Figure showing TEE, REE and the separation

Now that we know what a separation kernel is, let us look at TEEs. There are several definitions for TEEs that are available on the internet, the most complete among them is given below:

Trusted Execution Environment (TEE) is a tamper resistant processing environment that runs on a separation kernel. It guarantees the authenticity of the executed code, the integrity of the runtime states (e.g. CPU registers, memory and sensitive I/O), and the confidentiality of its code, data and runtime states stored on a persistent memory. In addition, it shall be able to provide remote attestation that proves its trustworthiness for third parties. The content of TEE is not static; it can be securely updated. The TEE resists against all software attacks as well as the physical attacks performed on the main memory of the system. Attacks performed by exploiting backdoor security flaws are not possible.

–M. Sabt, M. Achemlal and A. Bouabdallah in their paper titled “Trusted Execution Environment: What It is, and What It is Not”

At the core of any system that offers security is trust - Users must trust the system enough to use it, Engineers must trust the system enough to build applications around it.

Trust

In an ideal world, you would probably find a lab that is certified by other labs (or maybe even a Government agency) who can build and test a TEE. You would then take that TEE to a device manufacturer (that you trust) who can reproduce the sample TEE in production devices. But, the world we live in very far from ideal. Moreover, if one attempts the solution proposed above it will become very expensive, and hence it would become a limiting factor.

In the real world, we trust the manufacturer of the TEE and we make use of lot and lots of signature checks to establish trust during run time.

TEE establishes trust during the boot process using “hardware chain of trust”. In “hardware chain of trust” every image that is loaded and executed is cryptographically verified by the image loaded in the previous stage.

The first image that is loaded and executed (also known as the primary boot loader) is loaded from immutable read-only memory. This immutable read-only memory is burned into the chip by the manufacturer of the chip and it cannot be altered physically or otherwise.

The primary boot loader cryptographically verifies the signature of the next image that needs to be loaded and executed and this chain continues. All the signature checks are done using a set of private keys that are embedded directly onto the chip during the manufacturing process (hence the name “hardware chain of trust”). These private keys are stored using read only memory and they cannot be altered physically or otherwise. If during some stage of the boot, a signature check fails, then the TEE will not offer the services for which the signature check failed.

Once the boot is complete, the TEE can prove its validity by using a process called attestation. After the TEE has proved its validity, we trust the secure firmware that is loaded to execute trusted applications (TAs) in isolation, i.e., one TA can not affect other TAs that are running.

TEEs rely on the underlying separation kernel to prevent tampering of the executing TAs. The separation kernel employs various hardware-based mechanisms to protect the trusted applications from tampering. It prevents all resources (including CPU, memory and devices) from unauthorized access while ensuring partitioning and isolation of the exported resources and mediating the information flows between secure word (TEE) and the real world (REE).

Now that have a fair understanding of TEEs, let us jump back into confidential computing.

Applications of Confidential Computing available right now

Some of the many applications of confidential computing that you can try out right now include:

Multiparty machine learning
Trusted networks
SQL Server Always Encrypted Technology

Multiparty machine learning

In many cases, multiple parties will benefit from sharing of data, but currently they are not able to share data while preserving privacy.

Consider the example of hospitals that are using machine learning models to diagnose diseases early. Every hospital will have its own silo of data and it will train and run machine models on that silo. We know that the accuracy of any machine learning model depends entirely on the amount and accuracy of the data that is fed to it. With confidential computing, all hospitals can confidentially run a machine learning model on the combined dataset, thereby improving the model itself and benefiting all hospitals and by extension their patients.

Similarly, if a bank is using machine learning models to detect fraud and money laundering; multiple banks can make use of confidential computing to build a combined machine learning model benefiting everyone.

Olga Ohrimenko, Felix Schuster, Cedric Fournet, Aastha Mehta, Sebastian Nowozin, Kapil Vaswani and Manuel Costa published a paper titled “Oblivious Multi-Party Machine Learning on Trusted Processors” where they propose data oblivious machine learning algorithms for support vector machines, matrix factorization, neural networks, decision trees, and k-means clustering.

Trusted networks

Another application of confidential computing is the creation of trusted networks. The Confidential Consortium Framework (CCF), a joint project with Azure Engineering, is an open-source framework for building a new category of secure, highly available, and performant applications that focus on multi-party compute and data. While not limited just to blockchain applications, CCF can enable high-scale, confidential blockchain networks that meet key enterprise requirements — providing a means to accelerate production enterprise adoption of blockchain technology. [3]

CCF enables enterprise-ready computation or blockchain networks that deliver[3]:

Throughput and latency approaching database speeds
Richer, more flexible confidentiality models
Network and service policy management through non-centralized governance
Improved efficiency versus traditional blockchain networks

You can read more about CCF in the paper titled “CCF: A Framework for Building Confidential Verifiable Replicated Services” by Mark Russinovich, Edward Ashton, Christine Avanessians, Miguel Castro, Amaury Chamayou, Sylvan Clebsch, Manuel Costa, Cedric Fournet, Matthew Kerner, Sid Krishna, Julien Maffre, Thomas Moscibroda, Kartik Nayak, Olga Ohrimenko, Felix Schuster, Roy Schuster, Alex Shamis, Olga Vrousgou and Christoph M. Wintersteiger.

Code for CCF can be found on GitHub here

SQL Server Always Encrypted Technology

People familiar with SQL Server would have heard of the “Always Encrypted” technology that was introduced with SQL Server 2016. This technology allowed users to control the access of encrypted data, but, it had some limitations. Some of the limitations include: the only operations that SQL server could perform on a “Always Encrypted” column was equality comparisons (only available with deterministic encryption). All the other operations must be performed on the client side and not on the database server. Say, if the user wanted to perform pattern matching, the user would have to move all the data outside the database and then perform these operations on the client side.

With SQL server 2019 and later, Microsoft announced the “Always Encrypted with Secure Enclaves”. This makes use of confidential computing to address the limitations described above. Read more about it here.

Who is offering Confidential Computing?

Earlier this week, Mark Russinovich from Microsoft announced the general availability of the DCsv2-series VMs that has support for confidential computing. You can read the announcement here. IBM also has a similar offering that you can read about here.

How do I develop trusted apps that make use of Confidential Computing?

Microsoft and Google are offering SDKs that help developers get started with developing application that make use of confidential computing.

You can check out the SDKs here and here.

Conclusion

With more and more confidential workloads moving to the public cloud and edge devices, it is becoming more and more important to secure data not only while it is in rest or transit, but also while it is in use. At the time of writing this article, confidential computing is gaining momentum. It shows a lot of promise for securing data while in use and has a tremendous potential to do good.

References

[1]	Confidential Computing Consortium, “FAQ - Confidential Computing Foundation,” [Online]. Available.
[2]	Linux Foundation, “Confidential Computing Consortium Establishes Formation with Founding Members and Open Governance Structure,” [Online]. Available.
[3]	Microsoft, “Confidential Consortium Framework,” [Online]. Available.

Confidential Computing: Securing data while it is in use