0G Tapp: Securing TEE Deployments Without SSH

Traditional TEE setups have a critical blind spot that attestation can't catch. 0G Tapp's three-layer defense architecture closes the gap between confidential computing theory and production reality.

TL;DR 0G Tapp removes SSH from TEE deployments, replaces it with a whitelisted gRPC API, and verifies the system image with dm-verity. Attestation checks boot integrity, but Tapp adds runtime controls and keeps keys inside the TEE today, with distributed key management planned.

Trusted Execution Environments like Intel TDX are hardware-protected vaults for sensitive computation. 0G Tapp builds on this foundation with a security model that goes beyond what standard TEE deployments offer. The hardware encrypts memory, isolates workloads, and generates cryptographic attestation reports. On paper, it sounds airtight.

But there's a problem most teams don't talk about.

The vault has a back door. And it's wide open.

SSH: the backdoor hiding in plain sight

When you deploy an application inside a TEE, the hardware creates what Intel calls a "Trust Domain." The hardware automatically encrypts all TD-private memory. External processes can't read it. The hypervisor and host operating system are locked out.

But your application still needs maintenance. Developers need to deploy updates. Operators need to check logs, restart services, debug issues. So what do most teams do?

They install SSH.

That decision weakens the TEE's security model.

What SSH actually opens up

Think about what SSH is: a tunnel from the untrusted external environment into the trusted internal environment, with the ability to execute arbitrary commands.

Once inside via SSH, an attacker or malicious insider can:

• Steal encryption keys directly from memory
• Modify configuration files to redirect funds or data
• Install persistent backdoors for future access
• Exfiltrate sensitive data without triggering alerts
• Edit logs to cover their tracks

Here's the catch: the TEE's security measurements see nothing wrong.

Why remote attestation misses this

TEE attestation works by measuring the system at boot time. The hardware calculates cryptographic hashes of loaded software and stores them in secure registers (Intel TDX calls these RTMRs). Remote parties can verify these measurements to confirm expected code is running.

But by default, measurements capture what was loaded, not what happens after.

SSH is part of the system image. Attestation confirms the image was loaded correctly, but it says nothing about what anyone does through SSH after boot. The report reads "this is the expected system image." Not "someone just used SSH to steal all the private keys."

Runtime actions don't update measurements. The attestation quote looks identical whether the system is pristine or completely compromised.

The dilemma every TEE team faces

This creates a real problem for teams building production systems on confidential computing infrastructure:

Keep SSH? Operators can maintain the system and respond to incidents. But anyone with SSH credentials (or anyone who steals them) can do anything inside the secure enclave. You've built an expensive vault and left the key under the doormat.

Remove SSH? No unauthorized access is possible, but neither is authorized access. When something breaks at 3 AM, you can't fix it. When a critical security patch needs deployment, you can't deploy it. Secure but unmanageable.

Neither option works.

How 0G Tapp fixes this: three layers of defense

0G Tapp takes a different approach. We redesigned the architecture so security and operability coexist.

The core idea: unrestricted access is the problem. SSH gives operators a full terminal inside the TEE. 0G Tapp replaces that with a controlled service window.

Layer 1: Remove all backdoors

The first step is removing every component that could enable unrestricted entry from the external environment into the TEE.

From the 0G Tapp system image, we strip out:

• SSH daemon (sshd)
• Interactive shells (bash, sh, zsh)
• Debugging tools (gdb, strace)
• Service controllers (systemctl)
• Text editors (vi, nano, vim)
• Package managers (apt, yum)

What remains is a minimal runtime: Linux kernel, essential libraries, Docker engine, and the Tapp gRPC service.

Layer 2: A controlled API instead of a terminal

Removing SSH would make the system impossible to operate if we stopped there. The second layer replaces unrestricted access with a controlled gRPC API.

With SSH, an operator gets a terminal and can do anything. With the Tapp API, they get a defined set of operations. Key examples include:

Allowed:

• StartApp / StopApp
• GetAppInfo / GetAppLogs
• GetEvidence (remote attestation)
• ListAppMeasurements
• GetAppKey / GetAppSecretKey

Not possible:

• ExecuteCommand
• GetShell
• ModifyFile
• AttachDebugger

The full API is defined in the Tapp proto file. SSH provides unrestricted terminal access. The Tapp API exposes a fixed set of operations.

For sensitive operations like starting or stopping applications, the API enforces multi-signature authorization using an M-of-N threshold scheme. A deployer initiates the operation, but the system requires M out of N authorized parties to sign before it executes. For example, 3-of-5. If the threshold isn't met, the operation is rejected. A single compromised operator credential is useless on its own.

Every API call is logged in a tamper-proof audit trail. There's no way to interact with the system without leaving a record.

Layer 3: Cryptographic integrity verification with dm-verity

The first two layers assume the Tapp software itself hasn't been tampered with. The third layer verifies it.

dm-verity is a Linux kernel feature that provides cryptographic verification of the entire block device. 0G Tapp uses it through the open-source Cryptpilot library. Here's how it works:

At build time:

• The complete system image is created
• A Merkle tree hash is calculated over every block
• The root hash is recorded and published

At boot:

• The kernel receives the expected root hash as a parameter
• TDX hardware measures this hash into the RTMR registers
• dm-verity sets up the block device as a read-only target

At runtime:

• Every block read is verified against the hash tree
• If any byte doesn't match, the read fails with an I/O error
• Tampering is detected immediately, not eventually

The system image block device is mounted read-only, which makes tampering detectable and significantly harder. An attacker who somehow got code execution inside the TEE would face cryptographic verification on every block read, making persistent undetected changes impractical.

For persistent application data, 0G Tapp uses a separate /data partition protected by dm-integrity (a related kernel feature for read-write integrity) and encrypted with keys from the KBS. So the system image stays immutable via dm-verity, while application data stays encrypted and integrity-checked via dm-integrity.

Remote attestation ties it all together. Users can call the GetEvidence API to receive a TDX Quote containing the RTMR values. By comparing these against the expected hashes of the official 0G Tapp release, they can verify the exact code running inside the TEE hasn't been modified.

How 0G Tapp handles key management

Access control and integrity verification cover the runtime. Keys are a separate problem.

Current approach: TEE-isolated keys

Today, 0G Tapp stores keys inside a single TEE instance. Nothing outside the TEE can read them: not the host OS, not the hypervisor, not even the cloud provider.

But single-TEE storage has limits. If that hardware fails, the keys are gone. All keys live in one place, so one breach exposes everything. And keys bound to specific hardware can't be migrated.

What's coming: distributed key management

The next version of Tapp's Key Broker Service (KBS) will eliminate single points of failure with two planned architectures:

Shamir Secret Sharing with TEE reconstruction. A KMS Tapp cluster splits keys into shares using Shamir's scheme. No single node holds the complete key. When a Tapp needs a key, it collects enough shares (for example, 3-of-5) and reconstructs it inside its own TEE. The complete key only exists briefly, in hardware-isolated memory.

True MPC (Multi-Party Computation). Multiple Tapps each hold a key share. Signing and decryption happen through MPC protocols where each node contributes its share without ever sending it anywhere. The key is never reconstructed, not even inside a TEE.

Both approaches mean nodes can fail without key loss, compromising a single node is useless, shares migrate independently across hardware, and no single party, including 0G, can access keys alone.

0G Tapp vs. traditional TEE

A traditional TEE gives you strong walls but leaves a door anyone can walk through. 0G Tapp removes the door, installs a controlled service window, puts tamper sensors on the walls, and keeps your valuables in hardware-isolated storage.

Where 0G Tapp is running today

0G's Aristotle Mainnet launched in September 2025. Tapp is already integrated across the stack:

0G Compute Network: Distributed computing infrastructure where node operators can't access or manipulate the computations they're hosting. For a deeper dive, see Revolutionizing AI Fine-Tuning with the 0G Compute Network.

0G Tee Oracle: The TEE-based oracle for ERC-7857 iNFT transfers. When an iNFT changes hands, the oracle decrypts the AI agent's metadata inside a TEE, generates a new encryption key, re-encrypts for the buyer, and produces an attestation proof, all without exposing the data to anyone.

0G AIverse (testnet, login required): A no-code iNFT marketplace where users create AI agents and trade them as iNFTs. TEE protection ensures model inference runs as specified. Currently in testnet with mainnet launch planned. Background: Introducing AIverse: The Marketplace for iNFTs.

For cross-chain operations, 0G uses Chainlink CCIP as its canonical cross-chain infrastructure, while Tapp handles the secure computation layer.

Open source and verifiable

0G Tapp is fully open source:

• 0G Tapp: github.com/0gfoundation/0g-tapp
• Tapp Verifier: github.com/0gfoundation/0g-tapp-verifier

Security and operability only conflict when you use blunt tools like SSH that can't tell the difference between a legitimate operation and an attack. 0G Tapp removes unrestricted access, replaces it with a controlled API, verifies system integrity with cryptographic proofs, and isolates key material inside hardware-protected memory.

FAQ

What is 0G Tapp?

0G Tapp (Trusted Application Platform) is a TEE-based secure operations solution that removes SSH and other backdoor tools from the system image, replacing them with a controlled gRPC API and cryptographic integrity verification using dm-verity.

How does dm-verity protect the system?

dm-verity builds a Merkle hash tree over every block in the system image. At runtime, every block read is verified against this tree. If even a single byte has been modified, the read fails with an I/O error. The root hash is measured into the TDX hardware registers, so users can verify the exact image running via remote attestation.

What's the difference between SSH access and the Tapp API?

SSH gives operators a full terminal with unrestricted access to the TEE interior. The Tapp API provides a fixed set of whitelisted operations (start/stop apps, view logs, get attestation evidence) with no ability to execute arbitrary commands, open a shell, or modify files directly.

What is multi-signature governance in 0G Tapp?

Sensitive operations like starting or stopping applications require M-of-N multi-signature authorization. Instead of a single operator acting alone, the system collects signatures from multiple authorized parties (for example, 3 out of 5) before executing the request. If the threshold isn't met, the operation is rejected and logged. This prevents a single compromised credential from causing damage.

How does key management work in 0G Tapp?

Currently, keys are stored inside the TEE's hardware-isolated memory, protected from the host OS and hypervisor. The roadmap includes a distributed Key Broker Service (KBS) with two approaches: Shamir Secret Sharing (key split into shares, reconstructed inside a TEE) and true MPC (key never reconstructed anywhere). Both eliminate single points of failure.

This post describes 0G Tapp's current architecture and planned improvements. Users should conduct their own security assessment before deploying in production.

Ready to build on 0G Tapp?

• Documentation: docs.0g.ai
• GitHub: github.com/0gfoundation
• Compute Network: docs.0g.ai/concepts/compute
• AIverse Demo: aiverse.0g.ai

Sources

• Intel TDX: Trust Domain Extensions Overview, TME-MK
• dm-verity: Linux Kernel Documentation
• Cryptpilot: github.com/openanolis/cryptpilot
• 0G Tapp: github.com/0gfoundation/0g-tapp
• ERC-7857: 0G iNFT Architecture Docs