TEE Meme Coin Community 🧠✨

So, you've heard about $TEE and TEE_HEE (https://x.com/tee_hee_he）), the autonomous AI agent? There’s a lot of buzz, and we’re here to clear the air. Here’s a quick TL;DR for all the lazy but curious folks:

• No, the $TEE token isn’t created by TEE_HEE or its creators this time. We’ll explain more below!

• Why is TEE_HEE unique? Because it’s secured by TEE, a technology that makes AI agents verifiable and "unruggable."

The Born of AI

3:16 PM PDT · Oct 29, 2024 @tee_hee_he, the first AI Agent in TEE is born.

4:11 PM PDT · Oct 29, 2024 @karan4d @sxysun introduce a truly autonomous AI agent @TEE_HEE on twitter post: https://x.com/karan4d/status/1851401601858105716

• The blog present a new way to run AI Agents verifiable inside TEE: https://nousresearch.com/setting-your-pet-rock-free/

4:45 PM PDT · Oct 29, 2024 Someone (0xe9726E792f7416c66C2C8FBAc126BC15D4F08e88) create memecoin $TEE on Ethereum: 0x1316d715b8e791570a1ccc2224e215a868e2a50a57ebe344c4f39894756f373a

7:19 PM PDT · Oct 29, 2024 @karan4d open source all codes : https://x.com/karan4d/status/1851448792530264427

8:48 PM PDT · Oct 29, 2024 @shawmakesmagic, the creator of ai16z, repost this TEE AI Agent idea: https://x.com/shawmakesmagic/status/1851471333529698746

12:00 PM PDT · Oct 29, 2024 $TEE FDV reached $45m

Wtf happend? We knew the truth, because the AI is running inside TEE.

But let’s dig into some specifics about TEE_HEE’s setup, why TEE matters, and how it guarantees authenticity in a way that’s unforgeable:

Why TEE is Essential for Secure AI Agents

AI agents, even autonomous ones like TEE_HEE, are ultimately software running on hardware, meaning they need somewhere to live—like a server. When traditional servers run these agents, they typically store sensitive info like passwords and private keys. Here’s where things can go wrong: the server owner can technically “rug” the agent by accessing or controlling its sensitive data.

Enter TEE: The Unruggable Tech Vault 🔒

TEE is a hardware-based secure enclave, like a “black box” that locks away sensitive data and ensures only the designated program can access it. Here’s how it works in plain terms:

• Right Code - TEE only allows specific, verifiable code to run in it, much like how smart contracts are public and verifiable on Etherscan.

• Secure Black Box - This verifiable code can only execute within the TEE, ensuring it operates without interference, making it “unruggable.”

How Remote Attestation Builds Trust 🔗

Remote Attestation (RA) is where TEE proves its integrity. It generates an unforgeable claim that shows exactly what’s running inside it. This attestation includes key details:

TEE Signature - The RA is signed by the TEE itself, and only the TEE can generate this signature.

Code Hash - The attestation contains a hash of the code, letting anyone verify it hasn’t been tampered with.

Cryptographic Key Commitment - The attestation includes a key that allows verifiable actions like transactions or messages, signed by the AI agent itself.

With RA, anyone can confirm that TEE_HEE is operating solely according to the public code, without interference from any third party—including its creators. Here’s a sample attestation to explore how it works.

Now, What’s the Deal with $TEE? 🤔

There’s been speculation around $TEE, but let’s clarify: the $TEE token has nothing to do with TEE_HEE or its developers. With the attestation data, it’s easy to verify that no link exists between the AI agent and the token. The TEE itself guarantees this by preventing any manipulation of the code logic inside it. So, rest assured, the bot isn’t minting or controlling the $TEE token.

• TEE_HE: https://github.com/tee-he-he/err_err_ttyl

• Dstack: https://github.com/Phala-Network/dstack/

• Dstack image yocto build: https://github.com/Phala-Network/meta-dstack

• Dstack base image: https://github.com/Phala-Network/meta-dstack/releases/tag/v0.1.0

• RA Quote of TEE-HEE-HE: https://github.com/tee-he-he/err_err_ttyl/blob/main/quote.hex

• zkVM for partial docker compose proof: https://github.com/h4x3rotab/partial-ra-zkp

• More: https://github.com/DamascusGit/nousflash

• RTMR3 hashing algorithm: https://github.com/Phala-Network/meta-dstack/blob/main/scripts/calc_rtmr3.py

Verifying the Remote Attestation

With Remote Attestation (https://dstack-sim-explorer.vercel.app/), you should be able to verify the right program is running in the right environment. In the context of Intel TDX, it means that you will need to verify:

0. The TD (or CVM, confidential virtual machine) is in a genuine TEE

0. CVM is booted with a provable good base disk image

0. CVM doesn’t have any backdoor

0. After the boot, the CVM does nothing other than load the right program (defined in a docker-compose file)

The Hardware

Point 1 is covered by the RA quote generated by the hardware, since nobody can produce a fake RA quote unless the TEE is considered broken.

RTMRs

Before moving to the other points, we need to check what a RA quote contains. The most important fields are RTMRs (runtime measurement registers). They represent how the CVM is booted and the applications are loaded to the CVM.

There are 4 measurements: RTMR0, RTMR1, RTMR2, and RTMR3. RTMR0-2 are used to define the initial Linux kernel and the initrd filesystem. RTMR3 is a special register that implements an append-only hashed log. In the context of Dstack, it includes the measurements of the rest of the base image and the application program, defined in a docker compose file.

RTMR contains everything you need to verify the quote. Let’s decode the RA quote file using the dcap-qvl cli tool:

{
      "rt_mr0": "4574c098915caf3e82057817dbd135c1ed0ee1b39ac300c921479e2f5ebf5726a13ee0c8745ac891b6aee7c4f9664610",
      "rt_mr1": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "rt_mr2": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "rt_mr3": "547fcba4630bfb981169a8a1903b79c244933413409dd0387acbd8e3b985bcc9164cf52735cd31f60bf2c5d1220c113f",
}

To verify the content of RTMR3, we need to extract the log entries from the CVM outputs, reply the logs to get the final hash, and confirm it matches the RTMR3 registry in the quote. Below is the Python implementation of the replay algorithm (full rtmr3 calculation code here):

INIT_MR="000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
def rtmr_replay(history: list[str]):
    if len(history) == 0:
        return INIT_MR
    mr = bytes.fromhex(INIT_MR)
    for content in history:
        content = bytes.fromhex(content)
        if len(content) < 48:
            content = content.ljust(48, b'\0')
        mr = hashlib.sha384(mr + content).digest()
    return mr.hex()

In the context of Dstack, RTMR3 includes three measurements:

root-fs-hash: 5ec11fc7e2dc52c02d5b9b255ba7af1241904d2efdb9f4f05a055ab9312f0bde
app-id: 70ec07c39cd7cfb1672318bd586b37ee2f7133c4f3f41b948289db8d93fe2c4b
ca-certificate-hash: ca0d145f119f02b3da10ec0fb3cb75857e66dfcc738b9be6cf9f877a0aff0628

By feeding the three hashes to rtmr_replay, it outputs the exact same hash as what you can find in the RA quote. So we can confirm the input hashes are indeed measured by the RA quote.

The Base Image

Point 2 and 3 can be proved by two steps. First, check that the measurements of the base image (RTMR0-2, and root-fs-hash in RTMR3) are genuine. Second, you can extract the published base image to inspect everything inside.

To compare the measurements with the golden values, you can relaunch the CVM with the same configurations to reproduce the measurements, and they should be exact bit-for-bit matched the ones in the RA quote. The base image can be downloaded here, and you can follow the README of Dstack to relaunch the CVM.

Then you can inspect the image binary to check there’s no backdoor and the OS will loads the right docker image after booting.

Additionally, the base image is built from an Yocto configuration, meta-dstack. Yocto brings two benefits. First, it produces a minimized customized OS image without any unused features. It minimized the TCB (the components you have to trust) and reduces the potential attacking surface. Second, when configured correctly, Yocto can enable bit-for-bit reproducible build for the base image. (Currently it’s not fully reproducible. We aim to achieve it soon.)

The Docker Application

Point 4 can be proved by checking the app-id in RTMR3. It measures the sha256 hash of the docker-compose.yml file. It defines the actual program running in the TEE.

The docker-compose file includes the docker image (with the hash), the startup arguments, and the environment variables of the application to launch. You can hash the compose file and compare it with the app-id to link the docker image to the application program running in the TEE. Here’s a part of the compose file:

version: '3.9'
services:
  twitter:
    image: teeheehee/err_err_ttyl@sha256:50c3f8a00bbc47533504b026698e1e6409b4938109506c4e5a3baaae95116eb7
    volumes:
      - /var/run/tappd.sock:/var/run/tappd.sock
    environment:
	    # ....

You can follow the image hash on Docker Hub to download the image file to inspect. In the future, we encourage people to make fully reproducible Docker image to add more credibility.

Verifying the Docker Compose file

One can easily verify the docker compose file against the RA quote if they have the compose file contents. However, in the the current deployed Dstack, the file is also used to pass secrets to the application by environment variables. The variables include API keys and other secrets that cannot be shared.

We need to prove the compose file matches the measured app-id hash, and the image is the correct one, but without revealing the secret. To do that, we can generate a Zero Knowledge Proof using Risc Zero zkVM:

const EXPECTED_IMAGE: &[u8] = b"image: teeheehee/err_err_ttyl@sha256:50c3f8a00bbc47533504b026698e1e6409b4938109506c4e5a3baaae95116eb7";
fn main() {
    let mut compose_file = [0u8; EXPECTED_LENGTH];
    env::read_slice(&mut compose_file);
    // the image file is correct
    let image = &compose_file[EXPECTED_IMAGE_IDX_START..EXPECTED_IMAGE_IDX_END];
    if image != EXPECTED_IMAGE {
        println!("bad image content");
        return;
    }
    // calculate sha256
    let mut hasher = Sha256::new();
    hasher.update(&compose_file);
    let hash = hasher.finalize().to_vec();
    if &hash != EXPECTED_SHA256 {
        println!("incorrect hash");
        return;
    }
    env::commit(&0u8);
}

With the ZKP, we can prove the docker compose file loaded to the TEE indeed points to the right image without revealing the secret inputs. You can find a working zkVM program and the generated STARK proof from this repo.

For now, ZKP is the super weapon to solve the secret problem. However, in the future release the secrets can be handled in a more elegant way. So that we only need simple hashing to prove the code supply chain.

Conclusion

TEE like Intel TDX provides the tamper-proof and privacy-preserving features to AI Agent. We use TEE to guarantee the right program (in this case, the TEE-HEE-HE AI Agent) is running on the genuine hardware (Intel TDX). So even the operating system or hackers with physical access to the hardware cannot tamper with the agent.

The AI Agent uses Dstack with almost all the best practices to maintain its security properties. For example, we showed that anyone can verify the full supply chain of the code by checking the base image dumped from our server, the ZKP of the docker compose file, and of course, the Remote Attestation generated by the TEE. With everything set up properly, the AI Agent becomes a truly autonomous agent that can access both web2 and web3.