Trusted Execution Environments (TEEs) Attestation Management with the Klave SDK

In this article, we'll explore TEE attestation, why it matters for modern applications, and how you can now leverage this powerful capability directly through the Klave SDK. 

Understanding Trusted Execution Environments 

One of the key security aspects of the Klave platform is that all deployed applications run within a Trusted Execution Environment. But what exactly are TEEs, and why do they matter for your applications? 

TEEs are a cornerstone of Confidential Computing. Their role is to keep data and logic protected during processing, ensuring that the logic and data being computed cannot be accessed by anyone or be tampered with. Even privileged system operators cannot access or alter what happens within a TEE. 

TEEs provide four critical guarantees: 

• Data and code integrity - Your code and data remain unmodified 
• Data and code confidentiality - Your sensitive information stays private 
• Programmability - You can run complex applications securely 
• Attestability - You can cryptographically prove what's running 

Why Attestability Changes Everything? 

Here's where it gets interesting. TEEs aren't just secure-hardware that you need to trust blindly. They can provide cryptographic proofs and evidence of the loaded logic and the context of the platform upon request. This attestation capability is essential to zero-trust architecture and systems that rely on verifiable security. 

What is Attestation? 

Attestation is the process by which a TEE proves its authenticity and integrity to a verifier. It provides a cryptographically signed proof that includes: 

• A measurement of the enclave code and configuration 
• Platform security context 
• A challenge nonce to prevent replay attacks 
• Optionally, an ephemeral key for establishing a secure channel 

The evidence can then be verified by an attestation verification service. If valid, it provides assurance that the enclave is running trusted code on a secure platform. 

There are different workflows for TEE attestation: 

• Local Attestation: TEEs running on the same platform can attest to each other  
• Remote Attestation: An attestation report can be requested from the TEE remotely and validated by an external verifier  

For this post, we’ll focus on Remote Attestation (RA), as this is the workflow that enables a remote third party to verify Attestation reports (aka Quote). This is also how you will be able to get and verify Klave app attestations. 

How Remote Attestation Works 

The Remote Attestation process involves two distinct phases: getting a TEE Quote and verifying a TEE Quote. 

Requesting a TEE Quote 

The process involves several key players: 

• The Challenger: The entity requesting proof 
• Your Application: Your (Klave) app running within a secure hardware enclave 
• The Application Enclave: The TEE where your app executes 
• The Quoting Enclave (QE): A specialised enclave responsible for remote attestation 

The Quoting Enclave's mission is to check local attestation reports generated by other enclaves and convert them into remotely verifiable reports called "Quote". It does this by signing the report with its own asymmetric attestation key, ensuring the integrity and authenticity of the attested enclave. 

Here's how the process works: 

1. The challenger sends a nonce to your Klave application 
2. Your application requests an attestation report from its enclave 
3. The Quoting Enclave verifies and signs the report, creating a Quote 
4. The Quote is returned to the challenger for verification 

Verifying a TEE Quote 

To verify a Quote, the challenger uses an Attestation Verification Service that confirms the authenticity of the Quote and the report it contains. The service also provides a summary of the platform's security status, including any security advisories that might affect it. 

The attestation verification report, combined with recommendations from security advisories, helps the challenger assess whether to trust the platform and application enclave. 

Attestation Verification Options 

Several solutions exist for Attestation Verification Services: 

Self-hosted options: 

• Intel QVS - A stateless server endpoint that verifies attestation evidence from Independent Software Vendors 
• DCAP infrastructure - Similar to what we use on the Klave platform 

Managed services: 

• Intel Tiber Trust Authority - A higher-level zero-trust attestation service 
• The Klave Attestation Cluster (coming soon) 

The managed service landscape for attestation verification remains sparse, with Intel Tiber Trust Authority expected to become less widely available by the end of 2025. This scarcity highlights the importance of having reliable alternatives like self-hosted solutions or emerging services such as the Klave Attestation Cluster. 

Build Your Own Attestation Service with Klave 

Now you can manage attestation programmatically on Klave and even build your own attestation service! In the latest AssemblyScript and Rust versions of the SDK, you can: 

• Retrieve Intel SGX Quotes - Get cryptographic proof of your application's state 
• Parse and inspect Intel SGX & TDX Quotes - Examine attestation data programmatically 
• Verify Intel SGX & TDX Quotes - Validate attestation evidence within your applications 

We've made it easy for developers to utilise TEE attestation capabilities in a few lines of code. 

AssemblyScript:

1import { Notifier, Attestation } from '@klave/sdk';
2/**
3* @query
4*/
5export function getAndValidateQuote(input: QuoteRequest): void {
6    let quoteResult = Attestation.getQuote(input.reportData);
7    if (quoteResult.err) {
8        Notifier.sendJson<ErrorMessage>({
9            success: false,
10            message: quoteResult.err!.message
11        });
12        return;
13    }
14
15    let quote = Crypto.Utils.convertToU8Array(quoteResult.data!);
16    let time = Context.get("trusted_time");
17    let intValue: i64 = parseInt(time) as i64;
18
19    let verifyResult = Attestation.verifyQuote(intValue, quote);
20    if (verifyResult.err) {
21        Notifier.sendJson<ErrorMessage>({
22            success: false,
23            message: verifyResult.err!.message
24        });
25        return;
26    }
27
28    Notifier.sendJson(verifyResult.data!);
29}

Rust:

1fn get_and_verify_quote(challenge: &[u8]) -> Result<(), Box<dyn std::error::Error>> {
2            
3    // Generate attestation quote with provided challenge
4    let quote = klave::attestation::get_quote(challenge)
5        .map_err(|e| format!("Failed to generate quote: {}", e))?;
6    
7    // Get trusted timestamp for verification
8    let current_time = klave::context::get("trusted_time")
9        .and_then(|time_str| time_str.parse::<i64>().map_err(Into::into))
10        .map_err(|e| format!("Failed to get trusted time: {}", e))?;
11    
12    // Verify the attestation quote
13    let verification_result = klave::attestation::verify_quote(&quote, current_time)
14        .map_err(|e| format!("Quote verification failed: {}", e))?;
15    
16    // Send verification result
17    klave::notifier::send_json(&verification_result)?;
18    
19    Ok(())
20}

We have also built a template to help you get started quickly to generate and validate TEEs quote. 

Get Started Today 

Ready to implement TEE attestation in your applications? Check out our comprehensive documentation and start building. TEE Overview and Attestation Guide. 

With TEE attestation now available in the Klave SDK, you can build applications that not only protect data during processing but can also prove their integrity to any verifier. This opens up new possibilities for zero-trust architectures and confidential computing applications that require verifiable security guarantees. Discover the Trusted Execution Environment Attestation Management Template.