1 of 20

Using TEEs without trusting them

Fan Zhang

Assistant Professor, Yale University

@0xfanzhang

SBC MEV Workshop, August 6^th, 2024

completely

2 of 20

Trusted hardware: Isolated execution

SBC MEV Workshop 2024

2

Integrity

Other software and even OS cannot tamper with the control flow.

Confidentiality

Other sofware and even OS can learn nothing about the internal state.

Untrusted Operating System & Hypervisor

Untrusted Application Code

Untrusted Hardware

Trusted

Processor

Code & Data

“Enclave”

3 of 20

Trusted hardware: Remote attestation

SBC MEV Workshop 2024

3

attestation =

𝚺_SGX[ Hash(X) || Data ]

It’s indeed X running in a genuine TEE.

Remote user

Program X

(group) signature by a hardware protected key

Mental model: trusted third party!

4 of 20

Use cases in Web3

Oracles: e.g., Town Crier (CCS’16)
Bridges: e.g., Avalanche
Payment channels: e.g., TEEChain (SOSP’19)
Private smart contracts

Ekiden (EuroS&P’19), Oasis Labs, Secret Network

Private block builders
TEE-based one-time signatures
Web3 account encumbrance (e.g., Dark DAO)
Web2 account encumbrance
…

SBC MEV Workshop 2024

4

5 of 20

SBC MEV Workshop 2024

5

Draft by Team Encumbrance: https://tinyurl.com/web2encumbrance

6 of 20

Just a small problem: TEEs aren’t perfect

SBC MEV Workshop 2024

6

“SoK: Understanding Design Choices and Pitfalls of Trusted Execution Environments” (AsiaCCS’24)

Vulnerable design
Controlled side channels
Micro-architectural side channels
Speculative execution
Micro-architecture flaw
Hardware flaw

Most widely available TEEs had some vulnerabilities.
All vulnerabilities break confidentiality; some also break integrity (i.e., leaked attestation keys.)

7 of 20

If history tells us anything

Hard for me to say it but it’s a matter of time before our favorite TEEs get broken!
Building TEE is hard for several reasons

strong adversary model (e.g., malicious OS)
modern architecture is complex
close-source design (changing with open hardware)

There is hope: there has been invaluable effort towards secure-by-design TEEs
How to systematically hedge against the risks of TEE breaches?

SBC MEV Workshop 2024

7

8 of 20

Some cool ideas out there

“Trust less”

Sealed-Glass Proofs (2017): rely on TEE only for integrity, not confidentiality

somewhat justified by empirical evidence
Takeaway: transparent TEEs can function like zero-knowledge proofs

“Trust until failure detected”

Sting framework (2023): Injecting crafted inputs to TEEs so that leakage is detectable & verifiable.

Allow upper level protocols to handle failures.

(Incomplete list)

SBC MEV Workshop 2024

8

9 of 20

This talk: two more ideas

Idea #1: Trust TEE for liveness only

For systems easily DoS’able by clients, use TEE to prevent DoS.
→ liveness failures can be detected
Application: Dining Cryptographer networks (DC net)

Idea #2: insurance & bug bounty for TEE leakage

When secrets in TEE have economical values & leakage is verifiable, use smart contracts to automatically slash service provider & pay users
→ Disincentivize service provider from attacking
Application: TEE-protected key management systems (e.g., custodial wallets, Certificate Authority (CA))

SBC MEV Workshop 2024

9

10 of 20

ZIPNet: making DC nets cheap with (dis)Trusted Execution Environments.

SBC MEV Workshop 2024

10

https://eprint.iacr.org/2024/1227

11 of 20

Dining Cryptographers network (DC nets)

Anonymous Broadcast: broadcast while hiding the sender’s IP address.

SBC MEV Workshop 2024

11

Important for dissent, activism, whistleblower, etc

Private digital payments

Pretty much any privacy system

Privacy-preserving ML
Differentially private telemetry
Blockchain protocols
…

12 of 20

Tradeoffs in DC net systems

👍 DC nets are attractive for strong anonymity (e.g., immune to traffic analysis unlike Tor)
👍 “Anytrust” assumption (as long as one server is honest…)
👎 Brittle liveness: easily DoS’able by client

Cryptographical prevention is expensive

👎 Expensive to operate a server

high computation and bandwidth cost

Problem: few servers will exist → anonymity weakened

SBC MEV Workshop 2024

12

13 of 20

ZIPNet’s use of TEEs

ZIPNet introduces a few novel designs
For DoS prevention, run client code in TEE

TEE checks client input and signs

In case of TEE breaches

Attacker can corrupt outputs
happily, corruption is easy to detect
Most importantly, anonymity is intact!

TEE can be realized by SGX, TDX, something on mobile, or even software-based solutions

SBC MEV Workshop 2024

13

14 of 20

ZIPNet uses TEEs w/o trusting them completely

Benefits in ZIPNet:

Much simplified server algorithm (only symmetric-key operations per message)
Performant at low cost (4x-7x faster than the state of the art at 20x lower cost (~$150 vs ~$3300))

Principle: Using TEEs without trusting them completely

When TEE works, things are well and fast.
TEE breach doesn’t harm the core property (anonymity)
TEE breach is detectable
Allows handling of TEE breaches: e.g., switching to a more expensive protocol.

May generalize to other protocols

SBC MEV Workshop 2024

14

15 of 20

This talk: two more ideas

Idea #1: Trust TEE for liveness only

For systems easily DoS’able by clients, use TEE to prevent DoS.
→ liveness failures can be detected
Application: Dining Cryptographer networks (DC net)

Idea #2: insurance & bug bounty for TEE leakage

When secrets in TEE have economical values & leakage is verifiable, use smart contracts to automatically slash service provider & pay users
→ Disincentivize service provider from attacking
Application: TEE-protected key management systems (e.g., custodial wallets, Certificate Authority (CA))

SBC MEV Workshop 2024

15

16 of 20

CrudiTEE: a Stick-and-Carrot approach to side channels (AFT’24)

Useful for TEE-based key management systems where

secrets in TEEs have economic values
leakage of secrets is detectable

Examples: custodial wallets, Certificate Authority (CA)

SBC MEV Workshop 2024

16

17 of 20

The Stick-and-Carrot approach

Service providers (SP) v.s. outsider attackers
SP have root access to TEEs so they can mount all forms of side channel attacks (they can exfiltrate keys easily)
Outsiders can only mount remote attacks (need more time and cost to exfiltrate keys)

Stick: SP funds an insurance that pays users for leaked keys

Goal: SP doesn’t benefit from attacks

Carrot: bug bounty for outsider attackers

Goal: incentivize outsider attackers to stop early

SBC MEV Workshop 2024

17

18 of 20

Protocol skeleton of a CrudiTEE wallet

Secret keys are generated within the TEEs and never exported outside.
Keys are secret-shared among multiple TEEs (a knot to turn)
Users use OAuth to authenticate

SP keeps all OAuth tokens (later)

Deploy insurance and bug bounty

SBC MEV Workshop 2024

18

Besides the main target of CDCC (e.g. data analytics, IoT, etc), employing distributed TEEs is a good solution for secret management.

Our framework, CrudiTEE, is primarily designed to manage secret keys for cryptocurrencies. Applications like cryptocurrency wallets require users to manage their secret keys, adding an extra burden. Many secret keys end up lost, resulting in cryptocurrencies being locked forever. One solution to lost keys is to use custodial wallets, enabling traditional recovery processes. However, current custodial solutions rely on the trust of a centralized party, which is undesirable from a security standpoint. CrudiTEE provides a solution for creating a more secure cryptocurrency wallet while maintaining user-friendliness.

To demonstrate the versatility of our CrudiTEE framework, we also apply it to another application: Certificate Authority (CA). Currently, in the event of an unauthorized certificate being issued, browsers typically just distrust a problematic CA without seeking further compensation. By utilizing TEEs to manage the CA key and handle the authentication process, along with incentive designs, we can enhance transparency in the trust placed in the CA.

19 of 20

Key design questions

Q: How to hold service provider (SP) accountable for leakage?
A: key accesses are logged on chain in transactions

SP needs to present an OAuth token for any TX upon challenge by users.
If she can’t, SP is slashed.

Q: How much collateral does SP need to put down in the insurance?
A: Ideally the same as the wallet balances, but rate limiting can reduce required collateral.

Q: How to incentivize attackers to stop early?
A: give rewards for partial success, and condition rewards on time

Details in paper: https://arxiv.org/pdf/2407.16473

SBC MEV Workshop 2024

19

20 of 20

Summary

How to systematically hedge against TEE breaches?
“Trust less”: ZIPNet: rely on TEE for liveness
“Trust until failure detected”: CrudiTEE framework: insurance and bug bounty for TEE leakage

SBC MEV Workshop 2024

20

https://eprint.iacr.org/2024/1227

https://arxiv.org/abs/2407.16473 (AFT’24)