## Introduction Super Protocol's platform is based on Confidential Computing and Confidential Computing, as defined by the **Confidential Computing Consortium**, requires attestation. We at Super Protocol have woven attestation into our platform, making it an important underpinning of the security that we provide for all users and stakeholders. The two previous articles in this series [Attestation and Confidential Computing – a Technical Introduction](/confidential-computing/attestation-technical-intro) and [Advanced use cases for Confidential Computing – a Technical Introduction](/confidential-computing/advanced-use-cases-attestation) looked at how attestation provides the cryptographic assurances we need to be able to use Trusted Execution Environments (TEEs) for actual use cases, and how the use of certificates brings those use cases into the real world of deployments and consumer computing. This article brings together all that we looked at in those articles, addresses some final issues and examines how attestation fits into the platform designed and deployed by Super Protocol. ## The costs of attestation Certificates based on attestation verifications provide valuable assurances, but not without complexities - particularly the requirement to perform a full attestation process each time. We saw in the previous two articles that certificates based on attestation verifications provide some very useful assurances, enabling use cases that support both complex processes and multiple stakeholders. This is not without its complexities, however. **The most important is the requirement to perform a full attestation process - both measurement and verification - each time that you wish to create one of these certificates.** This can be very time-consuming, with latencies possible at: - The measurement stage - During network transfer of the attestation measurement - During the attestation verification process itself It may be able to reduce these latencies somewhat - or at least control them - if you are performing attestation verification yourself, rather than using a third-party attestation verification service (AVS), but this comes with its own technical challenges and also constrains the business models that you can adopt. Few people are likely to wish to run their own AVS, particularly in conjunction with an internal Certificate Authority, and a requirement to do so severely restricts opportunities for wider adoption of Confidential Computing, particularly at the consumer level. What other options are there if we want to make the most of the benefits presented by certificates based on attestation verification but wish to simplify and/or increase adoption? The rest of this article provides one answer: that provided by Super Protocol as a commercial service to customers right now. Let us step our way to the details with further discussion of the steps we need to address. ## Who to trust?

Before answering "who to trust," we must understand which parties need protection.

Leaving aside the provider of the hardware system on which we are planning to run our application (and who we assume will have their own isolation protections in place above and beyond those of the TEE if they require them), let us consider possibly the most complex set up: after all, if we can provide a solution in this case, all others should be tractable. This is a case - common in the Web3 dapp world but not restricted to it - where there are quite a number of parties who care about both the outputs of the application but also the inputs and isolation of execution. We compiled a list in the [previous article](/confidential-computing/advanced-use-cases-attestation), but didn't go into detail about what protections these parties might be looking for. It turns out that for most of them, the assurances that we have already outlined already meet their requirements very easily. Being able to use certificates based on attestation verification to assure yourself that the application to which you are supplying or sending data is the one you expect is simple, as uniqueness and identity are primitives that arise from the certificate. We can be assured that the data being acted on has appropriate confidentiality and integrity protections, as well.

Key Stakeholder Concerns:

Stakeholder Primary Concern Application Creator Intellectual Property protection Data Provider Data confidentiality and integrity Application Deployer Application integrity Cloud Service Provider Resource isolation

There is one final piece of the puzzle: what about the application itself? In many use cases – not just in Web3, but in many other situations – we are worried not only about the integrity of the application (assurances that it has not changed), but also about its confidentiality. There are, in other words, many types of deployment where details about the application itself should remain secret from some or even all of the stakeholders (with the exception of its creator, an owner, of course!). In the first article, we considered the case where you (the deployer of an application) didn't trust the Cloud Service Provider (CSP) who was about to run it. But what if you are not the deployer of the application, but its creator, and have spent days, months, even years of work creating this application, putting all of your Intellectual Property (IP) into it. You don't want either the CSP or the deployer of the application to be able to look at the application: its confidentiality is really important. What we are looking for here is the property of **confidentiality of the application from all non-trusted stakeholders**. ## Trusted loaders This may seem like a difficult property to be created, and it is in fact not one which is provided by default by Confidential Computing. The good news, however, is that it is possible, with the creation of a **Trusted Loader**. Rather than load the application that we want to run directly into the TEE, what we can do instead is deploy a loader application, which in turn loads the actual application, in a mechanism sometimes called *chaining*.

Trusted Loader Process:

1. Deploy a trusted loader application into the TEE 2. Perform attestation of the TEE and environment 3. Verify attestation measurement **before** loading the actual application 4. Once verified, load the actual application while maintaining its confidentiality How does this help, though? Well, let us assume that this loader application is one which is known and trusted by all of the relevant stakeholders to do nothing other than do the job we have just outlined for it: load the actual application. In this case, as long as we have pre-known measurement of the loader application, we can perform an attestation of the TEE (and environment) after the loader application has been loaded, but before it has proceeded to load the actual application. Before the actual application is released to the loading application, the attestation measurement is verified, and only after attestation verification is the actual application loaded. The loading application must have some mechanism such as storage or a network connection to download or receive the actual application, but as long as this is not activated until attestation verification has taken place, we can now have strong assurances that the confidentiality of the actual application has been maintained. This was the final piece in the puzzle: we can now proceed to an explanation of how Super Protocol have put all of these together and created a platform using certificates based on attestation verifications, combined with a trusted loader, to provide cryptographic assurances to all of the stakeholders that the properties they care about are met. ## Super Protocol's trusted CA approach

A simple architecture built on complex foundations

The architecture that we are about to lay out is, at the level we will be discussing it, fairly simple. This may seem surprising, but it is a very important point: while the implementation details of Super Protocol's approach are much more complex, the basic relationships between the key parties are not. They build on the properties that we have identified and explained in this and the previous two articles. Earlier in this article, we noted that the attestation process is costly – in terms of time and in terms of resources. While we want to ensure that each attestation measurement is verified, that does not mean that a central attestation verification service (AVS) must perform each attestation. Super Protocol have designed and implemented a hierarchy of Certificate Authorities (CAs) which allow certificates based on attestation verifications to be created without a requirement for each attestation verification to be performed centrally.

Hierarchy of Certificate Authorities (CAs)

Figure 1: Hierarchy of Certificate Authorities showing the relationship between Root CA, SubRoot CAs, and VM SubRoot CAs

In this hierarchy, there is a central AVS-enabled root CA that issues certificates to sub-CAs which themselves run within attestation verified TEEs which will be running the actual applications. This means that any party that relies on these SubRoot CAs can have the same trust as in the root CA, as they have the important property of assured integrity. These SubRoot CAs act as the authorities to which application TEEs then apply for certificates when they are created; these applications can be termed – VM SubRoot CAs as they are running within virtual machines and are themselves subordinate CAs to the root CA (though another level of hierarchy down the chain). These application TEEs, once attested, are issued with certificates based on the attestation verification carried out by the SubRoot CAs, and can now act as Certificate Authorities themselves for applications that will run within them. We have, then, a three-tier hierarchy, from root CA to SubRoot CA to VM SubRoot CA, with trust running up the chain to the root CA. The root CA is generally off-line after the creation of the SubRoot CAs, which stay online to service requests from newly created application TEEs. The root CA is (as in all CA-based hierarchies) a single point of trust, but with a federation of providers behind it and careful following of well-established best practices for Certificate Authorities and associated oversight and auditing, we can provide an authority which removes operational reliance on real-time attestation verification services. The root certificate for this root CA is a candidate for eventual inclusion within browser certificate stores, meaning that we could extend trust from TEEs all the way to consumer browsers. ## Trusted Loader (and why it's trusted) Super Protocol's design means that every application is always subject to remote attestation. The hierarchical approach taken means that it can scale whilst maintaining strong cryptographic assurances based on hardware. It is time to combine it with the final component that we showed that we need for application confidentiality: a loader application. This, of course, needs to be trusted, but, through the Certificate Authority that we have just described, we have a mechanism by which we can allow users and stakeholders to have appropriate levels of trust in this loader application and, by extension, in the applications that it will be loading and chaining into execution.

Architecture of the Certification System

Figure 2: Architecture showing the certification system with loader application and application TEEs

When the application TEE is created and the VM subroot CA is set up (having been signed by one of the subCAs), one of the first things it does is to ensure that it has a loader application already within the TEE. It then performs a measurement of this loader application (there is no need for an attestation measurement as the integrity of the TEE application is already assured) and checks this against known good values. Assuming it passes, the VM SubRoot CA can then issue a certificate allowing anyone wishing to deploy an actual application that the loader application, now termed a Trusted Loader can be trusted with the task of loading and chaining the application while safeguarding the latter's integrity and confidentiality. We have now assembled all of the pieces that we set out to create in order to give us a system with the key properties required by all of the stakeholders: our work here is done! ## Summary

This article demonstrated how Super Protocol has created a distributed execution platform for mutually distrusting parties through:

A hierarchical Certificate Authority approach
Trusted loader applications for maintaining confidentiality
Strong cryptographic assurances based on hardware attestation

This article, with its two companions, showed what properties are required to be able to build a distributed execution platform to be employed by mutually distrusting parties. We have concentrated on the part that cryptographic remote attestation must play within such a system, and there are other parts of the system that we have not touched on, that Super Protocol has designed and implemented. These are the subjects of other articles, but we hope that this set of articles has given you enough information – and piqued your interest enough! – to try out what we at Super Protocol have created. For further information, visit [our documentation site](https://docs.superprotocol.com/) or [contact our team](mailto:support@superprotocol.com). export function CCBenefits() { return (

Benefits of Super Protocol's Attestation

Enhanced Security

Cryptographic assurances based on hardware TEEs provide unparalleled security guarantees.

Scalability

Hierarchical CA approach allows the system to scale while maintaining strong security properties.

IP Protection

Trusted loaders ensure application confidentiality, protecting valuable intellectual property.

Trust Ecosystem

Enabling mutual trust between parties who would otherwise distrust each other.

) } export const CustomCallout = ({ type, title, children }) => (

{title}

{children}

)

Confidential ComputingConfidential Computing

Confidential Computing