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 asdata.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?
Top comments (1)
To gamers, it's called "Save Scumming" to beat a boss. To security engineers, it's called a "Replay Attack" to steal a million dollars.
Same mechanic, different stakes. 🎮💸
(Also, a reminder: Don't lose your private signing key. If you do, your MRSIGNER policy creates a digital paperweight that no one can ever open again.)