Forem: Max Jiang

(Part 5) Sealing Secrets: How to Survive a Reboot (And Why It's Dangerous) 💾

Max Jiang — Wed, 31 Dec 2025 02:58:17 +0000

Welcome back to the Confidential Computing Chronicles.

In Part 4, we learned how to prove our identity using Remote Attestation. We established trust. We are running securely in RAM. Life is good.

Then, the janitor trips over the power cord. 🔌

The server shuts down. The RAM is wiped. All your in-memory secrets—the session keys, the customer data, the AI weights—are gone forever.

Welcome to the problem of Persistence.
In a normal app, you just write to a file: f.write(secret).
In SGX, you can't do that. The disk belongs to the Untrusted OS. If you write plain text to disk, the OS reads it, and you fail.

You need to encrypt the data before it leaves the Enclave. But where do you store the encryption key?

On the disk? No, the OS will see it.
Hardcoded in the source? No, reverse engineers will find it.
Ask the user every time? Terrible UX.

The solution is a hardware feature called Sealing.

The Magic Key: CPU-Level Encryption

SGX provides a function called sgx_seal_data().
It asks the CPU: "Hey, give me a unique encryption key that ONLY I can use."

The CPU derives a key from hardware fuses and the Enclave's identity. The Enclave uses this key to encrypt the data and hands the blob to the OS to store on disk.

When the system reboots and the Enclave starts up again, it asks the CPU for the key again to Unseal the blob.

If ANYTHING has changed—if the hardware is different, or if the Enclave code has been tampered with—the CPU refuses to generate the same key. The decryption fails. The data is effectively trash to anyone else.

The Developer's Dilemma: MRENCLAVE vs. MRSIGNER

This sounds great until you release Version 2.0 of your app.

Remember MRENCLAVE from Part 4? It’s the hash of your binary.
If you fix a bug and recompile, your hash changes.
If you sealed data using the MRENCLAVE policy, the CPU says: "Sorry, you are a different binary. I cannot give you the old key."

Congratulations, you just bricked your user's data. You cannot decrypt the database created by Version 1.0.

To solve this, we use the MRSIGNER policy.

MRENCLAVE Policy: The key is bound to the exact binary hash.
- Use case: Ultra-strict security. Even the original developer cannot read the data with a new version.
MRSIGNER Policy: The key is bound to the Developer's Private Signing Key.
- Use case: Software updates. As long as Version 2.0 is signed by the same author (you) as Version 1.0, the CPU allows access to the old keys.

Pro Tip: Always use MRSIGNER for persistent data, unless you enjoy angry emails from customers who lost everything after an update.

The "Save Scumming" Attack (Rollback)

Sealing protects Confidentiality (OS can't read it) and Integrity (OS can't modify it).
But it does NOT protect against Time Travel.

Here is the "Rollback Attack" (a.k.a. Replay Attack):

Day 1: Your Enclave seals a file: Balance = $100. The OS saves it as data.blob.
Day 2: You withdraw $50. The Enclave updates the file: Balance = $50.
The Attack: The malicious OS administrator (who made a copy of the Day 1 file) simply overwrites the new file with the old one.
Result: The Enclave unseals the old file (the key is still valid!). It reads Balance = $100.
Profit: The hacker just duplicated money.

This is exactly like "Save Scumming" in video games—reloading an old save file to undo a mistake.

How to Fix It? (Monotonic Counters)

To prevent this, SGX provides Monotonic Counters. These are special counters stored in the hardware (or a secure replay-protected block).

Every time you write a file, you increment the counter in hardware (Counter = 5) and embed the number 5 inside the sealed file.
When you read the file back, you check:
if (File.Counter < Hardware.Counter) { Panic("Rollback Detected!"); }

It sounds simple, but utilizing Monotonic Counters is notoriously slow and limited in quantity. It’s one of the biggest bottlenecks in SGX storage design.

Up Next

We have covered the good parts: Security, Identity, Persistence.
Now it’s time to talk about the Nightmare Scenario.

What if the hardware itself is leaking secrets? What if the CPU is betraying you?

(Part 4) Remote Attestation: How to Prove You Aren't a Dog on the Internet 🐶

Max Jiang — Mon, 15 Dec 2025 06:59:32 +0000

Welcome back to the Confidential Computing Chronicles.

In Part 3, we learned how to optimize our code to fit inside the tiny memory limits of an Enclave. Now, we face a bigger problem: Trust.

Imagine I tell you: "Hey, send me your credit card number. I promise I'm running your payment code inside a secure Intel SGX Enclave. Nobody can see it."

You would be an idiot to believe me.

How do you know I'm not just running a printf() script on a hacked laptop in a basement? How do you know I didn't modify the code to email me your CC number before processing it?

This is the classic "On the Internet, nobody knows you're a dog" problem.
Remote Attestation is how we solve it. It is the cryptographic proof that I am not a dog.

The Problem: The Evil Twin

Let's say you compiled your secure Enclave. It has a specific binary hash (we call this the Measurement).

Good Enclave: Hash 0xABC... (Does honest math)
Evil Enclave: Hash 0x666... (Steals your data)

On the server, they look identical. They are both just binaries running in memory. The Operating System can't be trusted to tell you the truth, because the OS might be the attacker.

We need a way for the CPU itself to speak up and say: "I certify that the code running in this protected region has the hash 0xABC...."

The Solution: The "Quote"

Remote Attestation relies on a special digital signature called a Quote.

Think of the CPU as a Notary Public.

Measurement: When your Enclave starts, the CPU records a cryptographic hash of the initial code and data. This is called MRENCLAVE (The Enclave Identity).
The Challenge: The User (Client) sends a random challenge (nonce) to the Server.
The Report: The Enclave creates a "Report" containing:
- Its Measurement (MRENCLAVE).
- The User's challenge (to prevent replay attacks).
- Custom data (like a public key generated inside the Enclave).
The Signature: The Enclave asks a special architectural enclave (the Quoting Enclave) to sign this report using a hardware-fused private key that only Intel possesses.

This signed document is the Quote.

Interpreting the ID Card

So, the server sends you this "Quote". What do you do with it?

You (the Client) look at it and verify three things:

The Signature is Valid: This proves the code is running on genuine Intel SGX hardware (not a simulator, not an AMD chip).
The Measurement Matches: The hash inside the Quote matches the hash of the source code you audit and trust. This proves the code hasn't been tampered with.
The Data is Fresh: The nonce matches the one you sent.

If all three pass, you have established a Secure Channel. You can now encrypt your secrets with the Enclave's public key (embedded in the Quote) and send them over.

Congratulations. You have just established a root of trust that bypasses the Cloud Provider entirely. AWS, Azure, or Google Cloud physically cannot see your data, and you have mathematical proof of it.

The Two Flavors: EPID vs. DCAP

If you start Googling this, you will see two acronyms fighting each other.

EPID (Enhanced Privacy ID): The "Old School" way. You send the Quote to Intel's Attestation Service (IAS) to verify it.
- Pros: Easier to set up initially.
- Cons: Depends on Intel's servers being online. Slow.
DCAP (Data Center Attestation Primitives): The "Modern" way. You verify the Quote locally using a caching service (PCCS).
- Pros: Fast, works offline (mostly), scalable for data centers.
- Cons: Setup is a nightmare of configuration files.

For modern production systems, DCAP is the standard. But be warned: setting up the PCCS (Provisioning Certificate Caching Service) is a rite of passage for SGX developers. It involves API keys, confusing docs, and lots of caffeine.

Why This Matters for Web3 & AI

Why should you care?

Secret Network / Oasis Network: These blockchains use Attestation to prove that the nodes aren't peaking at private transaction data.
Confidential AI: When you use ChatGPT, you trust OpenAI. But if you want to run a model on sensitive medical data in the cloud, you need Attestation to prove the model is running in an Enclave and won't leak the patient info.

Up Next

Now we have a secure Enclave (Part 2), we know how to manage its memory (Part 3), and we have proved to the world that it's genuine (Part 4).

But what happens when the power goes out? RAM is volatile. When the Enclave dies, your data dies.
We need a way to save secrets to the disk without the OS reading them.

Part 5: Sealing Secrets & Data Persistence is coming next.

(Part 3) The Memory Wall: Why Your Enclave is Slow and How to Fix It

Max Jiang — Mon, 08 Dec 2025 04:30:53 +0000

Welcome to Part 3 of the Confidential Computing Chronicles.

In Part 2, we fought the SDK and won. We have a running Enclave. But if you’re trying to move beyond "Hello World" to something real—like running an image processing algorithm or a small database—you’re about to hit a literal, hardware-encoded brick wall.

It’s called the Memory Wall, and it exists because Intel is paranoid (for good reason).

The 128MB Problem (The EPC)

In a traditional app, you treat RAM like a vast, flat ocean. You malloc a gigabyte? The OS says "Sure, whatever."

In SGX, the CPU reserved a special, isolated region of RAM for Enclaves. This is the Enclave Page Cache (EPC). On older machines (pre-Ice Lake), this pool was strictly capped at 128MB.

But wait, it gets worse! After some administrative overhead, you only have about 90MB of usable space for your code, stack, and heap.

"90MB? My Node.js app consumes that just waking up!" Precisely. This is why SGX is for Confidential Computing, not for Lazy Computing.

The Performance Cliff: What happens when you leak?

If you exceed that 128MB limit, the hardware doesn't just crash. It starts Paging.

The CPU moves encrypted pages of your Enclave out to normal RAM. When you need them again, it pulls them back, decrypts them, verifies the integrity hash, and swaps them in.

This "Swapping" in SGX is roughly 10x to 100x slower than standard OS paging because of the constant encryption/decryption overhead. If your app frequently crosses that 128MB threshold, you will see a performance cliff that looks like a vertical drop into hell.

Pro-Tips for Tuning your Enclave

So, how do we survive inside a 90MB box? Here are the battle-hardened rules I follow:

1. Reuse, Don't Reallocate

Inside an Enclave, malloc and free are not just expensive—they are dangerous for memory fragmentation. If you have a 1MB buffer for processing data, allocate it once at startup and reuse it forever.

2. Stream, Don't Load

Don't read a 500MB database file into the Enclave memory. Keep it outside (Untrusted RAM), and pull it in chunks of 64KB, process it, and send the result back out via OCALL. Keep the Enclave as a "Processing Factory," not a "Storage Warehouse."

3. Check your Enclave Configuration

Every Enclave has a configuration file (Enclave.config.xml). If you don't adjust this, you're using default values that might be crippling you.

<EnclaveConfiguration>
  <ProdID>0</ProdID>
  <ISVSVN>0</ISVSVN>
  <HeapMaxSize>0x4000000</HeapMaxSize> <StackMaxSize>0x40000</StackMaxSize> <ReservedMemSize>0x1000000</ReservedMemSize> </EnclaveConfiguration>

Max's Golden Rule: Set your Heap to just under your machine's EPC hardware limit to avoid the paging trap.

Testing for the Cliff

If you want to feel the pain, try this exercise:
Write a loop that allocates 1MB blocks inside the Enclave and times each allocation. Watch the time stay steady until you reach ~90MB, and then watch the latency skyrocket.

Why this makes you a better engineer

Learning to code for SGX is like learning to code for a 1980s game console with 64KB of RAM. It forces you to think about data locality, buffer management, and overhead.

In a world where developers throw RAM at problems like it's free, being the person who can fit a secure machine learning model into 90MB makes you a unicorn in the security industry.

What's Next?

We've mastered memory. Now we need to prove to the world that our Enclave is actually running on real hardware and hasn't been tampered with.

Next up is the most mysterious and crucial part of SGX: Remote Attestation. This is how you prove your identity over the internet without trusting the guy holding the other end of the wire.

Part 4: Remote Attestation - The Digital Handshake of Trust

Hello World is Hard: Surviving the SGX Setup

Max Jiang — Fri, 05 Dec 2025 03:00:50 +0000

Welcome back to the Confidential Computing Chronicles.

In last post, we discussed why you should be paranoid about your cloud provider. Today, we stop philosophizing and start typing.

If you are a Python developer who complains when pip install takes more than 10 seconds, take a deep breath. Intel SGX (Software Guard Extensions) is not a library; it’s an architectural lifestyle change.

Building a "Hello World" in SGX isn't just print("Hello"). It involves:

Checking if your CPU even supports it (spoiler: it’s complicated).
Fighting with Linux Kernel drivers.
Signing cryptographic contracts. :D
Writing a "Bridge" between two worlds.

Let’s get into it.

Step 0: The Hardware Lottery (Do I have SGX?)

Here is the sad truth: Intel deprecated SGX on consumer CPUs (11th Gen Core and newer) to focus on Server CPUs (Xeon Scalable).

If you are on a new MacBook: You are on ARM. No hardware SGX for you.
If you are on AMD: Check out SEV (we'll cover that in Part I don't know).
If you are on a specialized Cloud Instance (e.g., Azure DC-series): You are golden.

"But Max, I don't have a Xeon server in my bedroom!"

Relax. Intel provides a Simulation Mode. It emulates the Enclave in software. It offers zero security guarantees (because the OS can see the emulated memory), but it lets you write and debug code. We will use Simulation Mode for this tutorial. So, yes, you can follow along on your standard Linux machine.

Step 1: Installing the SDK (The Toolkit)

We need the Intel SGX SDK for Linux. I’m assuming you are on Ubuntu 20.04 or 22.04.

Open your terminal and pretend you are a sysadmin:

# Install the prerequisites (The usual suspects)
sudo apt-get install build-essential python-is-python3

# Download the SGX SDK installer (Check 01.org for the latest version)
wget https://download.01.org/intel-sgx/sgx-linux/2.20/distro/ubuntu22.04-server/sgx_linux_x64_sdk_2.20.100.4.bin

# Make it executable and run it
chmod +x sgx_linux_x64_sdk_*.bin
./sgx_linux_x64_sdk_*.bin

It will ask you where to install. Just say "yes" to /opt/intel. Then, source the environment variables. Do not forget this, or nothing will work and you will cry.

source /opt/intel/sgxsdk/environment

Step 2: The Architecture of a "Hello World"

In a normal program, main() calls printf(). Simple.
In SGX, main() (Untrusted) cannot call printf() inside the Enclave (Trusted) because the Enclave doesn't have a screen, a keyboard, or an OS. It is a black box.

We need three files to make this happen:

App.cpp (The Untrusted Host)
Enclave.cpp (The Secret Logic)
Enclave.edl (The Contract)

The Contract: `Enclave.edl`

This is the Enclave Definition Language. It defines what functions can cross the boundary.

ECALL (Enclave Call): App calls Enclave (Entering).
OCALL (Outside Call): Enclave calls App (Exiting).

Create a file named Enclave.edl:

enclave {
    // Import standard C library types
    from "sgx_tstdc.edl" import *;

    trusted {
        // ECALL: The App will call this function to say Hello
        public void trusted_hello_world();
    };

    untrusted {
        // OCALL: The Enclave will call this to print to the screen
        void untrusted_print([in, string] const char* str);
    };
};

See what we did? We defined a trusted_hello_world function that we can call from the outside. But since the Enclave can't print, we also defined an untrusted_print that the Enclave can call to ask the App to print for it. It's like a prisoner asking a guard to mail a letter.

The Secret: `Enclave.cpp`

This code runs inside the protected memory.

#include "Enclave_t.h" // Auto-generated header (we'll see this later)
#include "sgx_trts.h"
#include <string.h>

void trusted_hello_world() {
    const char* secret_msg = "Hello from the Secure Enclave!";

    // We cannot use printf here! We must use the OCALL.
    untrusted_print(secret_msg);
}

The Host: `App.cpp`

This is the normal application that sets everything up.

#include <stdio.h>
#include "sgx_urts.h"
#include "Enclave_u.h" // Auto-generated header for untrusted code

// Global Enclave ID
sgx_enclave_id_t global_eid = 0;

// This is the OCALL implementation
// The Enclave calls this when it wants to print something
void untrusted_print(const char* str) {
    printf("Enclave says: %s\n", str);
}

int main() {
    sgx_status_t ret;

    // 1. Initialize the Enclave
    // "enclave.signed.so" is the signed library we will build
    ret = sgx_create_enclave("enclave.signed.so", SGX_DEBUG_FLAG, NULL, NULL, &global_eid, NULL);

    if (ret != SGX_SUCCESS) {
        printf("Failed to create Enclave. Error: %x\n", ret);
        return -1;
    }

    printf("App: Enclave created. Calling into the void...\n");

    // 2. Make the ECALL
    trusted_hello_world(global_eid);

    // 3. Destroy the Enclave
    sgx_destroy_enclave(global_eid);

    return 0;
}

Step 3: The Build Nightmare (Edger8r)

You can't just gcc App.cpp. Oh no.
You have to use a tool called sgx_edger8r. It parses your .edl file and generates "Edge Routines" (the glue code that handles the context switching between secure and insecure worlds).

sgx_edger8r reads Enclave.edl.
It generates Enclave_t.c (Trusted proxy) and Enclave_u.c (Untrusted proxy).
You compile the Enclave code + Trusted Proxy into a library.
You Sign the library using a private key (OpenSSL).
You compile the App code + Untrusted Proxy.
Link them together.

I won't paste the 50-line Makefile here because it looks like ancient hieroglyphics.

For now, just imagine running:

make SGX_MODE=SIM

Step 4: Run it!

If the gods of compilation smile upon you, you will see an executable app.

$ ./app

App: Enclave created. Calling into the void...
Enclave says: Hello from the Secure Enclave!

Victory.

Why was that so hard?

You might ask: "Max, that was 200 lines of setup for a print statement."

Yes. But think about what actually happened.
That "Hello" string was created in a region of memory that the Operating System could not read.
When untrusted_print was called, the CPU performed a hardware context switch, exited the protected mode, scrubbed the registers, and handed control back to the OS just to print those characters.

We just defied the laws of traditional OS hierarchy.

Up Next

Now that we have the environment, we need to talk about the Memory Wall.
In the next post, I will show you how to crash your Enclave by allocating too much RAM, and why "Paging" in SGX is a performance killer.

Part 3: The Memory Wall & Performance Tuning is coming soon.

I Don't Trust AWS (And Neither Should You): Dive into Intel SGX

Max Jiang — Wed, 03 Dec 2025 06:31:37 +0000

Let’s be honest for a second. We all deploy our code to the cloud. It’s easy, it’s scalable, and it’s someone else’s problem when the hard drive fails.

But here is the question that keeps me up at night (okay, maybe it's the caffeine, but this helps): Who owns the computer you're running on?

Jeff Bezos owns it. Or Satya Nadella. Or some sysadmin named Dave who hasn't had his coffee yet and has root access to the hypervisor hosting your Docker container.

If you are processing generic web traffic, you probably don't care. But what if you are handling biometric data? Or a bank’s private keys? Or a fine-tuned LLM weight matrix that cost $5 million to train?

Traditional security says: "Harden the OS, set up firewalls, trust root."
Confidential Computing says: "Trust no one. Not even the operating system. Especially not Dave."

Welcome to my series on Trusted Execution Environments (TEEs). Over the next few posts, I’m going to drag you through the mud of learning Intel SGX. Why? Because it’s painful, it’s powerful, and it might just be the future of cloud security.

The "God Mode" Problem

In the classic x86 architecture, the Operating System (Ring 0) is God. It can read any memory address, pause any process, and inspect any register. Your application (Ring 3) lives at the mercy of the kernel.

If a hacker gets root access, or if a malicious insider at the cloud provider decides to dump the RAM, your secrets are gone. Plain text. Game over.

This is where Intel SGX (Software Guard Extensions) flips the table.

Imagine you are staying in a hotel (the Cloud Server). The hotel manager (the OS) has a master key. They can enter your room anytime.
SGX is like bringing a titanium safe (the Enclave) into that hotel room.

The manager lets you into the room.
You go inside the safe and lock it from the inside.
You do your work inside the safe.
Even though the manager owns the building, they cannot see inside the safe.

If they try to drill into it (read the memory), the CPU literally returns garbage data (0xFF) or crashes the system. It’s hardware-level enforcement.

Under the Hood: The Enclave

So, how does this actually look in code? It's not magic, it's just... complicated.

When you write an SGX application, you split your brain (and your code) into two parts:

The Untrusted Part (App): This is your normal C/C++ code. It talks to the network, reads files, and prints to the console. It lives in the dangerous world.
The Trusted Part (Enclave): This is the fortress. It contains your secrets and the algorithms that process them.

The communication between them is strictly controlled. You can't just call a function. You have to perform an ECALL (Entering the Enclave) or an OCALL (Calling out of the Enclave).

It looks something like this (simplified for sanity):

// UNTRUSTED WORLD (Main App)
// "Hey Enclave, please take this encrypted data and process it."
sgx_status_t status = trusted_process_secret(eid, &encrypted_data);

// ---------------- THE HARDWARE WALL ----------------

// TRUSTED WORLD (Enclave)
// The CPU encrypts memory access here. Even the OS sees scrambled eggs.
void trusted_process_secret(char* data) {
    // 1. Decrypt data inside CPU cache (never hits RAM in plain text)
    // 2. Do the math
    // 3. Encrypt result
    // 4. Return
}

The crazy part? The data inside the Enclave is encrypted in RAM. It is only decrypted inside the CPU die. If you put a logic analyzer on the memory bus, you see encrypted noise.

Why is this relevant to our career?

You might be thinking, "I build React apps, why do I care?"

Because Privacy-Enhancing Technologies (PETs) are exploding.

Web3 & Blockchain: Many Layer 2 solutions use TEEs for off-chain computation.
AI Security: How do you let a hospital use your AI model on patient data without seeing the patient data and without the hospital stealing your model? SGX is the answer.
Regulation: GDPR and industry standards are pushing for "Data in Use" protection.

Knowing how to architect systems where you mathematically prove to a user that you can't steal their data? That’s a superpower.

The Catch (There's always a catch)

If SGX is so good, why isn't everyone using it?

Performance: Jumping in and out of an Enclave is expensive.
Memory Limits: For a long time, you only had 128MB of protected memory (EPC). Now with SGX2 we have more, but it's still precious real estate.
Complexity: Debugging inside an Enclave is a nightmare. You can't just printf. (Well, you can, but it requires an OCALL and it’s slow).
Vulnerabilities: Ever heard of Spectre or Foreshadow? We'll talk about those later. It’s an arms race between Intel and security researchers.

What's Next?

This was just the high-level pitch. In the next post, I’m going to open my terminal, and we are going to write a "Hello World" that requires a kernel driver, a signing key, and about 200 lines of boilerplate code.

It’s going to be fun. Or painful. Probably both.

Stay tuned for Part 2: Installing the Beast.

Forem: Max Jiang

(Part 5) Sealing Secrets: How to Survive a Reboot (And Why It's Dangerous) 💾

The Magic Key: CPU-Level Encryption

The Developer's Dilemma: MRENCLAVE vs. MRSIGNER

The "Save Scumming" Attack (Rollback)

How to Fix It? (Monotonic Counters)

Up Next

(Part 4) Remote Attestation: How to Prove You Aren't a Dog on the Internet 🐶

The Problem: The Evil Twin

The Solution: The "Quote"

Interpreting the ID Card

The Two Flavors: EPID vs. DCAP

Why This Matters for Web3 & AI

Up Next

Leave a Comment 👇

(Part 3) The Memory Wall: Why Your Enclave is Slow and How to Fix It

The 128MB Problem (The EPC)

The Performance Cliff: What happens when you leak?

Pro-Tips for Tuning your Enclave

1. Reuse, Don't Reallocate

2. Stream, Don't Load

3. Check your Enclave Configuration

Testing for the Cliff

Why this makes you a better engineer

What's Next?

Leave a Comment 👇

Hello World is Hard: Surviving the SGX Setup

Step 0: The Hardware Lottery (Do I have SGX?)

Step 1: Installing the SDK (The Toolkit)

Step 2: The Architecture of a "Hello World"

The Contract: Enclave.edl

The Secret: Enclave.cpp

The Host: App.cpp

Step 3: The Build Nightmare (Edger8r)

Step 4: Run it!

Why was that so hard?

Up Next

Leave a Comment 👇

I Don't Trust AWS (And Neither Should You): Dive into Intel SGX

The "God Mode" Problem

Under the Hood: The Enclave

Why is this relevant to our career?

The Catch (There's always a catch)

What's Next?

The Contract: `Enclave.edl`

The Secret: `Enclave.cpp`

The Host: `App.cpp`