Super Protocol and the Trusted Loader

Introduction

Super Protocol is a provider of services that use Confidential Computing, using remote attestation as a key tool underpinning the security of the solutions that they provide. In three previous articles, we looked at the importance of attestation, some of the advanced techniques it allows, and how Super Protocol uses attestation as the foundation for their technology. It’s worth reading those articles before starting on this one, as although we’ll provide a brief recap of key concepts addressed in those articles, having a good understanding of them will allow you to benefit more from the material in this article.

This article looks in particular at Super Protocol’s Trusted Loader, a component of the system which adds significant value to the solution and, without which, some of the most important properties of the solution would be impossible to provide.

Attestation - the underpinning

Attestation, as we discovered in the previous articles, is a two part process, whereby a measurement is made of the memory contents of a Trusted Execution Environment (TEE), and then verified by another, remote party (which is why we talk about “remote attestation”). The initial measurement is cryptographically signed, and one approach to extend the use of the measurement is to have the verification party - the Attestation Verification Service (AVS) - create a certificate using this data, signed by the AVS itself. This is the approach that Super Protocol takes, with a hierarchy of Certificate Authorities (CAs) allowing TEEs, once attested themselves to CAs higher up in the chain, to act as CAs themselves.

Why attestation isn’t enough

Remote attestation is a tool that, when used correctly, provides two primitives as part of a Confidential Computing implementation: uniqueness and identity. The TEEs that comprise the other parts of any Confidential Computing implementation provide two other primitives: confidentiality and integrity. Significantly, these primitives are not assured without attestation, and so it is only with the combination of these pieces that we can start building what we need.

There is one assurance that, maybe surprisingly, is not provided by default with Confidential Computing, even with a complete and verified attestation process: workload confidentiality. While we touched on this briefly in the final of the attestation articles, it is a key point in our discussion of the Trusted Loader - let’s look at it in detail.

First, let’s consider a standard approach to loading an application (the workload) and the data on which it is to operate, which we’ll assume is sensitive. We’ll also assume that we don’t trust the owner of the system - this is probably why we’re using a TEE in the first place!

A TEE is created by the system.
The workload is loaded into the TEE.
Before loading the data, which they don’t want the system owner to see, the data owner requests an attestation measurement.
The attestation measurement is created and then sent to an AVS.
The AVS checks the attestation measurement, which is good, and creates an attestation verification (a cryptographic certificate, in the case where the AVS is also a CA)
The certificate is presented to the data owner, who is now happy to send their data to the workload within the TEE, as they are happy that the integrity of the workload is assured, and the application is what they thought it should be.
The data is sent to the workload in the TEE. Since everything is in a TEE, the integrity and the confidentiality of the data is assured.

This all looks great, but there’s something that can go very wrong: what if the system, when requested to set up a TEE, created a false one? What if the workload was not actually loaded into a real TEE, but that the system owner spoofed a TEE and faked the attestation measurement? Well, step 5 should fail, of course, because the AVS will recognise that the TEE was not valid, and that means that the following steps (6 and 7) should never complete.

Well, in this case, the owner of the data is safe - they won’t send their data to the workload to process. But what about the owner of the application? What if the application itself is sensitive? If that’s the case, then there’s no way - using the process we’ve just described - to protect the confidentiality of the workload.

Using a Trusted Loader

This is where the Trusted Loader approach comes into play. This is a variation of the process where the initial application loaded into the TEE is not sensitive, but is a well-known (typically open source) application that it is trusted by the application owner. This slight change to the process provides us with the missing property that we need: workload confidentiality.

The difference from the previous process is that instead of loading the application directly into the TEE, the Trusted Loader is loaded instead. This is an application whose sole purpose is to be measured, verified and - assuming all is well - to load the workload that actually we want to run in the TEE. Super Protocol wasn’t the first to take this approach: it’s tried and tested and is considered a very safe technique. The job of the Trusted Loader is to load the real application, and then stay out of the way. In fact, it’s vital that the Trusted Loader does stay out of the way, because if it did not, then it might interfere with the operation of the real workload, including compromising the integrity and/or confidentiality of the workload or the data!

This is why it is very important for the Trusted Loader to be what it says it is: trusted. Anyone who wishes to should be able to check its code and ensure that it is not going to perform any malicious actions. The simplest way to do this is to make the code open source, which is what we at Super Protocol have done with our Trusted Loader, and provide publicly available hashes of the compiled code. These, of course, will be part of the attestation measurement and must be verified by the AVS - but if they are, and the verification is successful, then everyone in the system can have very high assurance not only that the Trusted Loader is not malicious, but also that it will load the appropriate real workload and run it as expected.

On the Super Protocol platform, the SubRoot CA acts as both an AVS and Certificate Authority, backed by the Root CA (see the article Super Protocol: making attestation work for more details). This component (including the Root CA) is known as the Certification System.

Here, then, are the steps in the process we looked at before, modified to make use of the Super Protocol’s Trusted Loader.

A TEE is created by the system.
The Trusted Loader (which is open source) is loaded into the TEE.
The Trusted Loader requests an attestation measurement.
The Trusted Loader creates a certificate request and sends it with the attestation measurement to the Certification System (the SubRoot CA).
The Certification System, checks the attestation measurement, which is good, and creates the certificate from the Trusted Loader (which is, at this point, an attestation verification and sends it to the Trusted Loader
The Trusted Loaders signs the TCB (TEE Confirmation Block)
The TCB (TEE Confirmation Block) is presented to the application owner, who checks the integrity of the workload, including a known good hash value for the VM. The application owner also checks the certificate validity.
If the verification is valid, the application owner is now happy to send their workload to the TEE, as they are happy that the Trusted Loader will behave as expected.
The TCB is also presented to the data owner, who checks the integrity of the workload, including the hash of the application and is now happy to send their data to the workload within the TEE, as they are happy that the integrity of the workload is assured, and the application is what they thought it should be. The data owner also checks the certificate validity.
The data is sent to the workload in the TEE.
The Trusted Loader checks the workload integrity before running it.
Since everything is in a TEE, and all executable code has been checked, the integrity and the confidentiality of both the workload and the data is assured.

Additionally to these steps, which relate to attestation and Trusted Loader, the Trusted Loader has some other roles, including, for instance, creating a report about the workload (which is sent for signing by the Certification System) and placing it on the blockchain.

Super Protocol’s Trusted Loader

We saw this diagram in one of the previous articles, but in this case, it’s not the CA hierarchy that we’re interested in, but the Trusted Loader component. The process used in this system is somewhat more complex than that presented in the previous section, but makes use of the same premise: that a Trusted Loader can provide further security. It also, in fact, provides further benefits, which we will visit briefly in the section Benefits below. Within the context of this system, the Trusted Loader leverages the capabilities provided by the VM Subroot CA (see the previous articles for more details) to allow the system to be self-contained, without requiring an external AVS.

In the case of the Super Protocol solution, the Trusted Loader creates a public-private key pair and creates a certificate request. This is submitted, with an attestation measurement, to the SubRoot CA (the Certification Service), which checks it against a known good hash of the Trusted Loader, and signs the certificate if this is found to be valid. This then acts as the basis for processes used by Super Protocol for completing the broader process of choosing and executing workloads, which we will examine in further detail in a later article.

The key point, however, is that this approach provides confidentiality and integrity protection for any and all later components added to the TEE. In the simple example we’ve briefly described, that was only a single application workload and a data set, but these assurances can be extended to any components within the Confidential VM provided by Super Protocol. This, combined with the Certificate Authority hierarchy that underpins the solution, allows complex interactions between mutually untrusting parties, whilst giving cryptographically-based assurances to all concerned.

Benefits

Let’s look, finally, at some of the main benefits offered by this approach and the solution that we offer at Super Protocol.

Security - TEEs with attestation provide confidentiality and integrity for data, but when combined with a Trusted Loader such as that provided by Super Protocol, those assurances can be applied to any components loaded into the Confidential VM.
Data transfer security - the system handles secure data transfer using TLS.
CA hierarchy - a CA hierarchy, by definition, relies on a centralized root of trust, but the control of that root of trust can itself be based in a known and broad set of parties. The CA hierarchy itself allows for scalability, further security (by removing the root CA from day-to-day operations) and speed.
Reduced workload management - with the CA hierarchy and Trusted Loader approach, there is no need for AVS instances to maintain, update, delete and revoke multiple application versions, nor for users to have the overhead of managing these.
Future flexibility - with a Trusted Loader, workloads can be introduced to the Confidential VM even if they are not necessarily known at the time of creation.
Blockchain integration - what all of the above benefits add up to is the ability to make firm offers on the blockchain which are backed by cryptography. These offers can include assurances aimed at all stakeholders, including system owner, application owner, data owner and the party wishing to run the server, without any of these parties needing to trust each other - or even know each other.

Summary

Trusted Execution Environments (TEEs) provide a number of strong protections for workloads around confidentiality and integrity when combined with attestation. However, simple implementations run the risk of unauthorized parties being able to view applications as they are being loaded: in other words, workload confidentiality is not assured. We at Super Protocol have implemented a technique known as a Trusted Loader, whereby a well-known, open source application with limited capabilities is initially loaded into the TEE, and the actual planned workload only ever loaded once attestation has been completed.

Glossary

Attestation - the process of creation of an attestation measurement and its validation.

Attestation measurement - a cryptographic hash that captures the state of a system or component at a specific point in time. This includes not only the contents of the TEE itself, but also measurements of the boot process, firmware, operating system, hypervisor, and application code. These measurements are typically stored in hardware registers (such as TPM PCRs) and collectively form a chain of trust from the hardware root of trust up to the running workload.

Attestation validation - the checking of an attestation against particular known good hash values, according to predefined policies.

Attestation Validation Service (AVS) - a component in a system that performs attestation validations. It is generally remote from the system on which the TEE is running.

Certificate Authority (CA) - a trusted third-party entity that issues digital certificates to verify the identity and authenticity of parties in a cryptographic system. The CA validates the identity of certificate requesters through various means, then creates and digitally signs certificates that bind public keys to verified identities. In the context of attestation, a CA may issue certificates that attest to the trustworthiness of a TEE or the validity of attestation evidence, enabling relying parties to make trust decisions.

Certification Service - the core signing component within Super Protocol's Certification System that combines the functions of an Attestation Verification Service with a Certificate Authority to issue certificates based on attestation evidence.

Certification System - Super Protocol's comprehensive infrastructure for managing trust and verification in confidential computing environments, encompassing the Certification Service, policy management, CA hierarchy, and integration mechanisms.

Confidential Computing - Confidential Computing is the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment.

Confidential VM - a Trusted Execution Environment that is executing as a Virtual Machine.

Evidence - cryptographic proof generated by a TEE during attestation, containing measurements, signatures, and metadata that demonstrates the TEE's current state and integrity. Evidence is consumed by verification services to make trust decisions.

Hardware Root of Trust - a tamper-resistant hardware component (typically embedded in the CPU or a dedicated security chip) that provides the foundation for all cryptographic operations and attestation measurements in the system.

Host - a computer system which is running applications, often for other parties.

Policy - a set of rules and criteria that define what constitutes a trusted or acceptable state for a TEE. Policies specify which measurements, configurations, and attestation evidence are considered valid during the verification process.

Relying Party - an entity or service that depends on attestation results to make trust decisions about whether to interact with or provide services to a TEE.

Remote attestation - attestation should almost always be performed remotely - that is, on a different system to that on which the Trusted Execution Environment is running. For this reason, attestation within the context of Confidential Computing is sometimes specifically referred to as remote attestation.

Trusted Execution Environment (TEE) - a hardware-based isolation mechanism to protect applications and their data from other processes or entities on a host (whether compromise or malicious). A TEE should always be subject attestation before being considered trusted.

Trusted Loader - a mechanism to allow workloads to be loaded by a trusted component (typically open source, as in the case of Super Protocol), preserving confidentiality of the workload.

Workload - an application to be run on a host, for instance within a Trusted Execution Environment.