ShEF: shielded enclaves for cloud FPGAs

Renting an FPGA in the cloud to accelerate work on sensitive data means trusting the provider's whole stack — the CPU software, the interface logic wrapping your accelerator, even physical access to the chip — and unlike CPUs, cloud FPGAs had no trusted execution environment to protect you; this paper (Stanford and Tsinghua — Mark Zhao, Mingyu Gao, Christos Kozyrakis) presents ShEF, a TEE for cloud FPGAs that trusts none of that, bootstrapping a root of trust and remote attestation from the FPGA's own existing security hardware and adding a Shield between the accelerator and the provider's shell that encrypts and integrity-checks all data the accelerator touches, with the Shield made modular so each user tunes exactly the protection their access pattern and bandwidth need at minimal overhead.

The argument in one glance

Problem

Renting a cloud FPGA for sensitive data means trusting everything around it

Cloud providers rent out FPGAs — reconfigurable chips you program with your own hardware design — to accelerate applications, and increasingly those applications handle sensitive data like financial records and medical data. But when your accelerator runs on a provider's FPGA, it is surrounded by things you do not control: the CPU and its software, which move data to and from the FPGA; the provider's interface logic (the shell) that wraps your accelerator and mediates its access to memory and the network; and the physical machine itself, in a data center you cannot see. If any of these is malicious or compromised, your sensitive data is exposed. On CPUs, trusted execution environments exist to protect a computation from exactly this kind of untrusted surroundings, but cloud FPGA accelerators had no equivalent, so there was no way to run a hardware accelerator on sensitive data in the cloud without trusting the provider entirely.
What people did

Reuse CPU TEEs, or encrypt the data with software crypto

The obvious options are to lean on existing protections. You could route the FPGA's data through a CPU trusted execution environment like Intel SGX, or encrypt the data before it reaches the FPGA using homomorphic encryption or an ad-hoc cryptographic library, so the untrusted parties only ever see ciphertext.
Why it fell short

CPU TEEs do not cover the FPGA, and software crypto is too slow or too trusting

None of these actually protects an FPGA accelerator. A CPU TEE protects computation on the CPU, not on the FPGA, and it comes with a large trusted computing base that has been repeatedly broken by side-channel attacks like Spectre and Foreshadow — so tying FPGA security to it inherits both a coverage gap and those vulnerabilities. Homomorphic encryption, which would let the FPGA compute on ciphertext, is prohibitively slow for most real applications. And ordinary cryptographic libraries, even assuming they are correct, still depend on a large software stack controlled by the potentially malicious provider, and they do not defend the accelerator itself while it runs. What is missing is a trusted execution environment built for the FPGA — one that protects the accelerator and its data with confidentiality, integrity, and freshness even when the CPU software, the provider's interface logic, and physical access are all in the adversary's hands, and does so efficiently.
This paper's idea

Build an FPGA-native enclave with attestation and a customizable data shield

ShEF is a trusted execution environment for cloud FPGAs, independent of any CPU TEE, that holds under a threat model where the adversary controls all CPU software, has physical access to the FPGA, and can compromise the provider's FPGA interface logic. It has two parts. First, a secure boot and remote attestation process that relies solely on existing FPGA security mechanisms for its root of trust: FPGAs already support encrypted, signed bitstreams verified by an on-chip secure processor (with keys optionally protected by a physically-unclonable function), and ShEF's Security Kernel uses these to attest the device and bitstream to a remote party and establish keys, so a data owner can trust a specific FPGA and accelerator without trusting the provider. Second, a Shield component that sits between the accelerator and the provider's shell and provides secure access to data while the accelerator runs — encrypting and integrity-checking everything that leaves the trusted accelerator to DRAM or the host. The Shield is highly customizable: because accelerators differ in memory access pattern, bandwidth, and security needs, users configure its encryption, integrity (up to Merkle trees for freshness), parallelism, chunk sizes, and buffers to fit their accelerator at minimum performance and area overhead. The authors implement ShEF end-to-end on existing cloud FPGAs and demonstrate it on a secure storage application plus five more accelerators.

Why this problem is worth solving

FPGAs have become mainstream cloud accelerators, and much of what they accelerate is exactly the data that must be kept private.

A field-programmable gate array is a chip whose logic you configure yourself, loading a hardware design called a bitstream, so it can be shaped into a custom accelerator for whatever you need — signal processing, machine learning, databases, financial modeling. Cloud providers now rent FPGAs (for example on AWS F1) so anyone can use custom hardware acceleration without owning the chips, and these accelerators are increasingly applied to sensitive workloads like medical and financial records. On a cloud FPGA, your accelerator does not run in isolation: the provider supplies a shell — logic analogous to an operating system that virtualizes the FPGA’s peripherals, memory, and its connection to a host CPU — and your accelerator is loaded alongside it via partial reconfiguration. Data reaches your accelerator by passing through the host CPU’s software and the provider’s shell, and lives in the FPGA’s DRAM. Every one of those elements is outside your control and, in a strong threat model, potentially hostile. On CPUs, the industry answered this with trusted execution environments that give a computation confidentiality, integrity, freshness, and isolation even against a malicious operator; but nothing equivalent existed for FPGA accelerators. So an organization wanting to accelerate sensitive computation in the cloud faced a stark choice: trust the provider completely, or not use the accelerator. Closing that gap is what makes secure cloud FPGA acceleration worth building.

The reason it is hard is that the natural building blocks each fail against a realistic adversary.

Consider the tools you might reach for. A CPU trusted execution environment such as Intel SGX protects code and data on the CPU, but the FPGA accelerator runs on a different device entirely, so a CPU TEE simply does not extend its protections to the accelerator; worse, CPU TEEs have a large trusted computing base and a long history of being compromised by micro-architectural side-channel attacks, so anchoring FPGA security to them would import that fragility. Homomorphic encryption would, in principle, let the FPGA compute directly on encrypted data so the plaintext never appears, but it is orders of magnitude too slow for most real applications, defeating the point of using an accelerator. Rolling your own cryptography with standard libraries can protect data in transit and at rest, but assuming the crypto is even correct, it still relies on the provider’s multi-layered software to invoke and manage it, and that software is exactly what the threat model says can be malicious; it also does nothing to protect the accelerator’s working data as it computes. Meanwhile the adversary in a cloud FPGA setting is genuinely strong — able to control all CPU software, tamper with the provider’s interface logic, and physically access the chip. Defending against all of that requires a root of trust and a data-protection mechanism that live in the FPGA itself and assume nothing about the surrounding software or the operator, which is precisely the design point ShEF targets.

What people did before, and where it broke

Route FPGA data through a CPU TEE (Intel SGX). Use the CPU’s enclave to protect data before handing it to the FPGA. Where it broke. A CPU TEE does not protect computation on the FPGA, and it carries a large trusted computing base repeatedly broken by side-channel attacks, so it neither covers the accelerator nor is dependable.
Homomorphic encryption. Let the FPGA compute directly on encrypted data so plaintext never appears. Where it broke. It is prohibitively slow for most real applications, so it defeats the performance purpose of using an FPGA accelerator.
Ad-hoc cryptographic libraries. Encrypt data with standard crypto managed by the host software. Where it broke. Even assuming correctness, it depends on the provider’s large software stack — which the threat model treats as malicious — and it does not protect the accelerator’s data while it is in use.
Trust the provider and its shell. Rely on the cloud provider’s interface logic and operational security. Where it broke. The threat model explicitly allows a compromised shell, malicious CPU software, and physical access, so trusting the provider offers no guarantee against exactly those attacks.
The gap. No trusted execution environment existed for cloud FPGAs that rooted trust in the FPGA’s own hardware, protected the accelerator’s data confidentiality, integrity, and freshness under a strong adversary, and did so with low, customizable overhead.

How ShEF works

An FPGA-native enclave: attested boot plus a data shield

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Put the trusted execution environment on the FPGA, trusting nothing around it. The foundational choice in ShEF is to make the FPGA its own enclave rather than borrowing trust from the CPU. It assumes the CPU software, the provider’s shell, and physical access are all potentially hostile, and builds confidentiality, integrity, freshness, and isolation for the accelerator that hold anyway. This mirrors what CPU trusted execution environments do for CPU computation, but relocated to the reconfigurable device and decoupled from any CPU TEE. Providing a hardware-rooted enclave so a workload can run safely on infrastructure whose operator and software are untrusted is the same guarantee the work on a protected services framework for confidential virtual machines covered elsewhere on this site is built on, extending TEE assurances to a new execution substrate. ShEF extends them to cloud FPGA accelerators, which had no such protection at all.

Bootstrap trust from hardware the FPGA already has, verified by attestation. A TEE is only as good as its root of trust and its ability to prove to a remote user that the right code is running. ShEF avoids inventing new hardware by reusing the FPGA’s existing security features — encrypted, signed bitstreams verified by an on-chip secure processor, with keys optionally guarded by a physically-unclonable function — and layering a remote attestation protocol on top, so a data owner can confirm they are talking to a genuine FPGA running the intended accelerator, and only then release keys and data. Establishing, through remote attestation, that a remote environment is genuinely the trusted one before entrusting it with secrets is the same mechanism the work on information flow control for privacy-preserving data processing covered elsewhere on this site relies on, using attestation as the anchor a remote user can verify. ShEF grounds that anchor in the FPGA’s own silicon, so the trust does not pass through the provider.

Make the data protection customizable, because one scheme fits no accelerator. The insight that makes ShEF practical is that securing data in use has very different costs depending on how an accelerator touches memory, so a fixed protection scheme would be wasteful for most. A streaming accelerator needs only encryption and authentication over large chunks; one that revisits addresses needs Merkle trees for freshness; each has its own bandwidth and area budget. The Shield is therefore modular, letting users assemble exactly the encryption, integrity, parallelism, and buffering their accelerator requires, so security overhead is paid only where it buys protection that matters. This concern for cloud FPGA security under real, adversarial deployment — including physical realities of the device — is the same terrain the work on data remanence in cloud FPGAs covered elsewhere on this site maps, exposing how much can leak from a reconfigurable device an attacker can reach. ShEF answers on the defensive side, tailoring protection to the accelerator so it is both strong and affordable.

Following data through ShEF

Running a sensitive accelerator on a rented FPGA without trusting the provider

A trace, drawn from the paper, of how ShEF boots, attests, and protects data for a cloud FPGA accelerator.

Step 1 of 5

Keys are embedded and the bitstream is encrypted offline

Before deployment, the developer embeds the necessary keys into the FPGA and encrypts and signs the accelerator bitstream. The FPGA's on-chip secure processor will only load a bitstream it can decrypt and authenticate, giving a hardware root of trust independent of the cloud provider.

This reuses existing FPGA security hardware rather than requiring new silicon.

Why it works

An FPGA-rooted enclave needs no trust in the CPU or provider. A CPU TEE cannot protect the FPGA and is itself fragile → but rooting the enclave in the FPGA’s own hardware protects the accelerator directly → so security holds even when all CPU software and the shell are hostile.
Reusing existing FPGA security avoids new hardware. A TEE needs a trustworthy root, which would normally require new silicon → but encrypted, signed bitstreams and an on-chip secure processor already provide one → so ShEF works on commodity cloud FPGAs today.
Attestation lets the owner verify before trusting. A remote user cannot see what really runs on a rented FPGA → but a signed attestation protocol proves the device and bitstream are genuine → so data and keys are released only to a verified accelerator.
The Shield protects data the shell must still carry. Data inevitably leaves the accelerator to DRAM and the host through untrusted logic → but the Shield encrypts and integrity-checks it first → so a compromised shell or physical attacker sees only protected data.
Customization matches cost to the access pattern. One fixed protection scheme overpays for some accelerators and underprotects others → but a modular Shield fits encryption, integrity, and buffering to each → so every accelerator gets adequate security at minimum overhead.

What it costs (trade-offs and scope)

It relies on the FPGA’s existing security mechanisms being sound. ShEF’s root of trust is the FPGA’s encrypted-bitstream and secure-processor hardware (and optionally a physically-unclonable function); the guarantees are only as strong as those mechanisms, and a flaw in them, or in the offline key embedding, would undermine the enclave.
Data owners must trust an IP Vendor for attestation. The attestation protocol involves an IP Vendor the data owner chooses; the model moves trust off the cloud provider but onto that attestation party and the correctness of the protocol, rather than removing trust entirely.
Security is not free; it must be configured well. The Shield adds encryption, integrity, and (for freshness) Merkle-tree machinery, which cost performance and area; the overhead is minimized by customization, but that means users must configure the Shield correctly for their access pattern and security needs to get both safety and speed.
It secures the accelerator’s data path, not everything. ShEF protects the accelerator’s computation and its data in use, at rest, and in transit through the shell, but it depends on the CPU for networking and data transfer and does not defend against every possible attack (for example it targets the stated threat model rather than, say, all conceivable side channels within the FPGA).
It targets current commodity cloud FPGAs. The prototype is built for existing cloud FPGA deployments and devices; the exact mechanisms and overheads are tied to that hardware, and portability to other reconfigurable platforms would require re-establishing the equivalent root-of-trust and shield mechanisms.

The evaluation

Securing computation on a cloud FPGA

Property	CPU TEE / software crypto	Trust the provider	ShEF
Protects the FPGA accelerator itself
Holds if CPU software is malicious
Holds if the shell is compromised
Withstands physical access
Performance and overhead

A qualitative comparison of ways to secure cloud FPGA computation. ShEF provides a TEE that protects the accelerator and its data under a strong adversary (malicious CPU software, compromised shell, physical access), with low, customizable overhead, demonstrated on a secure storage application and five additional accelerators.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s full text (arXiv:2103.03500). The mechanism described is the paper’s: ShEF is a trusted execution environment for cloud FPGAs, independent of CPU TEEs, secure under a threat model where the adversary controls all CPU software, has physical access to the FPGA, and can compromise the provider’s FPGA interface logic (the shell); it provides secure boot and remote attestation rooted solely in existing FPGA mechanisms (encrypted and signed bitstreams verified by an on-chip secure processor, keys optionally protected by a physically-unclonable function, with a Security Kernel running a signed attestation protocol with a data-owner-chosen IP Vendor); and it includes a Shield component between the accelerator and the shell that provides confidentiality, integrity, and freshness for data in use, customizable in its encryption, integrity (up to Merkle trees), parallelism, chunk sizes, and on-chip buffers to fit an accelerator’s access pattern, bandwidth, and security needs at minimum overhead. The paper implements ShEF end-to-end on existing cloud FPGAs, maps it to a secure storage application, and evaluates customizable security on five additional accelerators. Exact protocol details, the Shield’s engine internals, and the quantitative overheads should be read from the paper.

Background

Why trust keeps migrating into the hardware

It helps to see ShEF as part of a long migration of trust downward, into the hardware, as computing moved into clouds we do not own. When you run on someone else’s machine, the traditional trust boundary — the operating system, the hypervisor, the operator — is exactly what you may not be able to trust, so the industry has increasingly pushed the root of trust and the protection mechanisms into the silicon itself, where a remote user can anchor guarantees that software cannot subvert. CPU trusted execution environments were the first big wave of this, and their turbulent history of side-channel breaks also taught a hard lesson: putting the protection in hardware is necessary but not sufficient, because the hardware must be designed and used carefully. As acceleration spread to GPUs, FPGAs, and custom chips, each new kind of accelerator inherited the same exposure — sensitive data running on a device inside an untrusted, physically-accessible, multi-tenant cloud — and needed its own hardware-rooted answer. Cloud FPGAs are a sharp case because the user literally programs the hardware, the provider’s logic sits right beside theirs, and the device can be physically reached. The broader reality that shared, multi-tenant cloud infrastructure is an adversarial place where isolation must be earned, not assumed, is what the work on co-location attacks against public cloud serverless platforms covered elsewhere on this site lays bare. ShEF brings the hardware-rooted-trust response to reconfigurable accelerators, so FPGA users can finally get enclave-grade guarantees.

If you remember only three things

1. Cloud FPGAs accelerate applications that often handle sensitive financial and medical data, but they had no trusted execution environment, so a user had to trust the provider's entire stack — the CPU software, the shell (interface logic) wrapping their accelerator, and physical access to the chip. CPU TEEs like SGX do not cover FPGA accelerators and carry a large, repeatedly-broken trusted computing base; homomorphic encryption is far too slow; and ad-hoc crypto still leans on the provider's software and does not protect the accelerator in use.
2. ShEF is a CPU-independent TEE for cloud FPGAs, secure even when the adversary controls all CPU software, has physical access, and can compromise the provider's shell. It has two parts: a secure boot and remote attestation process rooted solely in existing FPGA hardware (encrypted, signed bitstreams verified by an on-chip secure processor, keys optionally protected by a physically-unclonable function, with a Security Kernel attesting to a data-owner-chosen IP Vendor); and a Shield between the accelerator and the shell that encrypts and integrity-checks all data the accelerator touches, providing confidentiality, integrity, and freshness even against a tampering shell or physical attacker.
3. The Shield is highly customizable — users tune its encryption, integrity (up to Merkle trees for freshness against replay), parallelism, chunk sizes, and on-chip buffers to fit their accelerator's access pattern and bandwidth at minimum performance and area overhead. ShEF is implemented end-to-end on existing cloud FPGAs and demonstrated on a secure storage application plus five more accelerators. It relies on the FPGA's security hardware being sound, requires trusting an attestation IP Vendor, and must be configured well to balance security and speed.

Check yourself

Check your understanding

1. Why is running a sensitive workload on a cloud FPGA hard to secure?
2. Why don't existing tools (CPU TEEs, homomorphic encryption, ad-hoc crypto) solve this?
3. What are ShEF's two main components?
4. Why is the Shield made customizable, and what did ShEF demonstrate?

Sources

The paper is “ShEF: Shielded Enclaves for Cloud FPGAs” by Mark Zhao, Mingyu Gao, and Christos Kozyrakis (Stanford University and Tsinghua University), published at ASPLOS 2022, DOI 10.1145/3503222.3507733. It is licensed CC BY.

This explainer is written from the paper’s full text (arXiv:2103.03500). The paper presents ShEF, a trusted execution environment for cloud-based reconfigurable accelerators that is independent of CPU-based TEEs and secure under a threat model where the adversary can control all software running on the CPU connected to the FPGA, has physical access to the FPGA, and can compromise the FPGA interface logic (shell) of the cloud provider. ShEF provides a secure boot and remote attestation process that relies solely on existing FPGA mechanisms for its root of trust — encrypted and signed bitstreams verified by an on-chip secure processor, with an AES key optionally protected by a physically-unclonable function, and a Security Kernel that performs a signed key exchange and attestation with a data-owner-chosen IP Vendor to establish keys and verify the device and bitstream. It also includes a Shield component that provides secure access to data (confidentiality, integrity, and freshness) while the accelerator is in use, sitting between the accelerator and the shell; the Shield is highly customizable and extensible, letting users craft a bespoke security solution — encryption, integrity up to Merkle trees, parallelism, chunk sizes, and on-chip buffers — that fits their accelerator’s memory access patterns, bandwidth, and security requirements at minimum performance and area overheads. The paper describes a prototype implementation of ShEF for existing cloud FPGAs, maps ShEF to a performant and secure storage application, and measures the performance benefits of customizable security using five additional accelerators. No numbers beyond the paper’s own have been introduced; exact protocol details, the Shield’s internals, and the quantitative overheads should be confirmed in the paper.