Skip to content

Update fundamentals/certification-system #410

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
k3dz0r merged 1 commit into from
Jan 28, 2026
+64 −14
Merged

Update fundamentals/certification-system #410

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion docs/cli/Guides/tgwui.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -231,4 +231,8 @@ The most important statuses (see the [full list](/fundamentals/orders#compute-or
- **Processing**: The compute is executing the order inside a TEE. Your model is either already available or will be available soon.
- **In Queue**: The order is waiting for the compute to become available. This status appears only if the compute is overloaded with orders. If this status persists for a few minutes, place a new main order the same tunnel order and engine configuration but another compute offer.
- **Done**: The order is completed successfully and the model's UI is no longer available.
- **Error**: The order completed with an error. [Download the order results](/cli/commands/orders/download-result) to get more information about the error.
- **Error**: The order completed with an error. [Download the order results](/cli/commands/orders/download-result) to get more information about the error.

## Support

If you have any issues or questions, contact Super Protocol on [Discord](https://discord.gg/superprotocol) or via the [contact form](https://superprotocol.zendesk.com/hc/en-us/requests/new).
60 changes: 47 additions & 13 deletions docs/fundamentals/certification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,47 +5,81 @@ slug: "/certification"
sidebar_position: 6
---

Super Protocol uses a certification system for signing data, verifying signatures, and ensuring applications operate within a trusted confidential computing environment. Verified data is published on the blockchain on behalf of confidential containers, allowing anyone to validate application integrity and ensure confidentiality. End users only interact with issued certificates and verify signatures, while the complexities of Remote Attestation are seamlessly managed in the background.
The Super Protocol Certification System is a hierarchical infrastructure for managing trust in confidential computing environments. The main purpose of the system is to create a valid chain of X.509 certificates for any applications running in <a id="tee"><span className="dashed-underline">Trusted Execution Environments</span></a> (TEEs). The Certification System itself also operates within TEEs, ensuring the entire chain is rooted in hardware-based trust.

All the system components are open-source, ensuring transparency and verifiability.
The Certification System performs remote attestation under the hood, but exposes a familiar X.509-style certificate chain on the surface. This allows any verifier (a user, an auditor, or an automated service) to validate that:

- The execution took place within a TEE.
- The certificate chain leading to the workload is valid and trusted.

The Certification System can function as an independent, standalone service. In this capacity, it could serve external companies and users who need to establish certificate chains for their own confidential computing applications.

Note that the system is not responsible for validating what an application does internally. Its primary role is to issue certificates to trusted confidential environments, forming a cryptographically verifiable trust chain.

All system components are planned to be open-sourced, improving transparency and verifiability.

## Architecture

The backbone of the system is a hierarchical structure of <a id="ca"><span className="dashed-underline">Certification Authorities</span></a> operating inside <a id="tee"><span className="dashed-underline">Trusted Execution Environments</span></a> (TEE)—Intel SGX enclaves.
The Certification System is organized as a hierarchy of <a id="ca"><span className="dashed-underline">Certification Authorities</span></a> (CAs) that establishes trust for TEEs through a standard certificate chain. Every CA operates within a TEE—Intel SGX enclave.

<img src={require('./images/certification-system-architecture.png').default} width="auto" height="auto"/>
<br/>
<br/>

The Root Certification Authority (*Root CA*) is located at the highest hierarchical level. At the start, Root CA generates a self-signed certificate, embedding the SGX attestation quote.
The chain consists of three levels:

- Root CA is the top-level certificate authority that establishes the trust anchor for the entire system. At the start, it generates a self-signed certificate, embedding the SGX attestation quote.
- SubRoot CAs are intermediate certificate authorities. They submit their quotes and public keys to the Root CA and request certificates. The Root CA verifies these incoming requests and then issues and signs certificates for the SubRoot CAs. Once a SubRoot CA is certified by the Root CA, it can certify any TEE-backed environment that proves it is actually confidential.
- End certificates are issued to specific workloads, entire <a id="ca"><span className="dashed-underline">Confidential Virtual Machines</span></a> (CVMs) running in TEEs, and in some other cases. These certificates are not CAs and cannot be used to sign or issue other certificates.

Comment on lines +31 to +34
Copy link

@coderabbitai coderabbitai bot Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Fix the CVM anchor id to match the tooltip selector.
Right now the CVM link uses id="ca", which duplicates the CA anchor and breaks the #cvm tooltip.

🔧 Proposed fix 
-- End certificates are issued to specific workloads, entire <a id="ca"><span className="dashed-underline">Confidential Virtual Machines</span></a> (CVMs) running in TEEs, and in some other cases. These certificates are not CAs and cannot be used to sign or issue other certificates.
+- End certificates are issued to specific workloads, entire <a id="cvm"><span className="dashed-underline">Confidential Virtual Machines</span></a> (CVMs) running in TEEs, and in some other cases. These certificates are not CAs and cannot be used to sign or issue other certificates.
As per coding guidelines: Follow the established cross-referencing pattern with custom anchor tags.
🤖 Prompt for AI Agents 
In `@docs/fundamentals/certification.md` around lines 31 - 34, The anchor id on
the CVM link currently reuses id="ca", which conflicts with the CA anchor and
prevents the `#cvm` tooltip from working; update the anchor id to match the
tooltip selector (e.g., change id="ca" to id="cvm") on the Confidential Virtual
Machines link while preserving the existing span and
className="dashed-underline" and link text so cross-referencing follows the
established pattern.

Each level in the hierarchy receives its certificate from the level above, creating a chain of trust that ultimately traces back to the Root CA.

## Trusted Loader

SubRoot Certification Authorities (*SubRoot CAs*) are located at the next hierarchical level. These submit their quotes and public keys to the Root CA and request certificates. The Root CA verifies these incoming requests and then issues and signs certificates for the SubRoot CAs.
Trusted Loader is a special service that prepares and launches the workload associated with an <a id="order"><span className="dashed-underline">order</span></a> inside a CVM running in a TEE. It runs in a privileged position within the execution environment, allowing it to access the underlying attestation capabilities of the platform. Workloads themselves do not have such access.

The SubRoot CAs, in turn, issue and sign certificates for <a id="order"><span className="dashed-underline">orders</span></a> by request.
Trusted Loader also:

- Collects hashes of the workload and its components.
- Verifies workload integrity before execution starts.
- Requests end certificates.

All end certificates are requested and received by Trusted Loader. Other components do not interact directly with Certificate Authorities. Trusted Loader may request certificates in several cases:

- At startup. The certificate confirms that the confidential environment is correctly configured and that the attestation challenge (TDX, SEV-SNP, etc.) matches expectations.
- When generating session keys. The certificate is included in the session key structures used during execution.
- When forming a <a id="tcb"><span className="dashed-underline">TEE Confirmation Block</span></a> (TCB). The certificate is embedded into TCB, which also includes system information and measurements.
- When deploying an order. An order-specific certificate is issued and delivered, along with cryptographic keys, to the order's execution environment.

## Order certificates

The issuing of order certificates involves Trusted Loader—a software mechanism developed by Super Protocol to load and run applications within a TEE. Trusted Loader operates inside the Confidential VM that executes the order. This Confidential VM may be deployed within a CPU-based or CPU/GPU-augmented TEE using technologies such as Intel TDX, AMD SEV-SNP, NVIDIA Confidential Computing, or others, making the system TEE-agnostic.
Trusted Loader requests a dedicated order-specific certificate when an order is prepared for execution. This certificate includes order-specific data, such as the hash of workload information.

To receive an order certificate, the Trusted Loader sends a request to a SubRoot CA providing the quote and a public key. The SubRoot CA verifies the quote, issues the order certificate, and signs it with the provided public key.
Trusted Loader places the order certificate as a file into the order's execution environment. There, it can be used by the order itself to prove that it was launched within a confidential environment.

Note that the Certification System does not determine whether a CVM is correct or compromised. If a CVM runs in a confidential environment, it can obtain certificates. However, differences in hashes are visible in the certificate chain and can be detected by any verifying party.

### Order validation

Orders in Super Protocol are created with necessary input data. This execution environment is referred to as *Workload Info*.
Orders in Super Protocol are created with a workload description known as *Workload Info*.

The Workload Info includes an array called `runtimeInfo[]` with metadata about <a id="solution"><span className="dashed-underline">solutions</span></a> and datasets used in the order. Each such order component has an entry in this array, which includes:
Workload Info includes an array called `runtimeInfo`. It contains information about <a id="solution"><span className="dashed-underline">solutions</span></a> and <a id="data"><span className="dashed-underline">data</span></a> associated with the order. Each such order component has an entry in this array, which includes:

- Type
- Type (solution or data)
- Hash
- Size
- Signature key hash (optional)
- Hash of the input arguments (optional)

The hash of the Workload Info is included in the order certificate.

Trusted Loader generates and publishes a report in the blockchain, allowing anyone to validate the order. This order report includes:
Before order execution begins, Trusted Loader checks the integrity of the full workload composition (solutions, data, and configuration). The order proceeds only if this verification succeeds.

Trusted Loader also generates and publishes a report to the blockchain, allowing any verifier to validate the order. The report includes:

- The public components of all the certificates in the chain
- Workload Info:
- Order creation date
- The `runtimeInfo[]` array
- The `runtimeInfo` array

The immutable nature of blockchain prevents any further alterations to the report once it is published. The report enables verifiers to confirm what exactly was launched and that the certificate corresponds to that specific workload.
Binary file modified docs/fundamentals/images/certification-system-architecture.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
12 changes: 12 additions & 0 deletions src/theme/Layout/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,9 +87,21 @@ export default function Layout(props) {
ᐧ A <i>tunnel client</i> hosts a web server; it remains hidden behind the tunnel server and protected from external threats.
</Tooltip>

<Tooltip anchorSelect="#tcb">
<i>TEE Confirmation Block</i> (TCB) contains a unique device ID, equipment benchmark results, <br/>various hashes, device signature, and a certificate chain for signature verification.<br/><br/>

Trusted Loader generates and publishes TCB on the blockchain every 24 hours.
</Tooltip>

// Stabs and abbreviations
Copy link

@coderabbitai coderabbitai bot Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, examine the file at and around line 96
sed -n '90,105p' src/theme/Layout/index.js

Repository: Super-Protocol/docs

Length of output: 621

🏁 Script executed:

#!/bin/bash
# Also check if the file exists and its total line count
wc -l src/theme/Layout/index.js

Repository: Super-Protocol/docs

Length of output: 92

🏁 Script executed:

#!/bin/bash
# Search for the specific comment
rg -n 'Stabs and abbreviations' src/theme/Layout/index.js

Repository: Super-Protocol/docs

Length of output: 98

🏁 Script executed:

#!/bin/bash
# Check how comments are handled in the custom components mentioned in learnings
fd -type f -path 'src/theme/*' \( -name '*.tsx' -o -name '*.ts' -o -name '*.jsx' -o -name '*.js' \) | head -20

Repository: Super-Protocol/docs

Length of output: 233

🏁 Script executed:

#!/bin/bash
# List files in src/theme to find custom components
find src/theme -type f -name '*.tsx' -o -name '*.ts' -o -name '*.jsx' -o -name '*.js'

Repository: Super-Protocol/docs

Length of output: 425

🏁 Script executed:

#!/bin/bash
# Check for Biome configuration
find . -maxdepth 2 -name 'biome.json*' -o -name '.biomerc*'

Repository: Super-Protocol/docs

Length of output: 75

🏁 Script executed:

#!/bin/bash
# Search for Highlight, Imager, and Admonition components
rg -l '(Highlight|Imager|Admonition)' src/theme --type js --type ts --type jsx --type tsx

Repository: Super-Protocol/docs

Length of output: 90

🏁 Script executed:

#!/bin/bash
# Check for similar // comment patterns inside JSX in the file
rg -n '^\s*//\s+' src/theme/Layout/index.js

Repository: Super-Protocol/docs

Length of output: 98

🏁 Script executed:

#!/bin/bash
# Get broader context around line 96 to see full JSX structure
sed -n '85,106p' src/theme/Layout/index.js

Repository: Super-Protocol/docs

Length of output: 1007

🏁 Script executed:

#!/bin/bash
# Check Highlight.jsx for comment patterns
cat -n src/theme/Highlight.jsx

Repository: Super-Protocol/docs

Length of output: 500

🏁 Script executed:

#!/bin/bash
# Check Imager.jsx for comment patterns
cat -n src/theme/Imager.jsx

Repository: Super-Protocol/docs

Length of output: 349

🏁 Script executed:

#!/bin/bash
# Check biome.json configuration
cat -n biome.json

Repository: Super-Protocol/docs

Length of output: 2348

🏁 Script executed:

#!/bin/bash
# Check Admonition layout for comment patterns
cat -n src/theme/Admonition/Layout/index.tsx

Repository: Super-Protocol/docs

Length of output: 1904

Wrap the JSX comment in braces. A raw // comment inside JSX renders as text and triggers the lint error flagged by Biome.

🛠️ Proposed fix 
-      // Stabs and abbreviations
+      {/* Stabs and abbreviations */}
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
// Stabs and abbreviations
{/* Stabs and abbreviations */}
🧰 Tools
🪛 Biome (2.1.2)

[error] 96-98: Wrap comments inside children within braces.

Unsafe fix: Wrap the comments with braces

(lint/suspicious/noCommentText)

🤖 Prompt for AI Agents 
In `@src/theme/Layout/index.js` at line 96, The JSX contains a raw line comment
"// Stabs and abbreviations" which renders as text and trips the linter; update
that inline comment in the JSX to a proper JSX comment by replacing the raw //
comment with a wrapped comment like {/* Stabs and abbreviations */} so it
becomes a valid JSX expression (locate the JSX fragment containing "Stabs and
abbreviations" and change the comment syntax accordingly).


<Tooltip anchorSelect="#cvm">
Confidential Virtual Machine
</Tooltip>

<Tooltip anchorSelect="#tl">
Trusted Loader
</Tooltip>
</>
);
}