Pentimento: Data Remanence in Cloud FPGAs

Colin Drewes, Olivia Weng, Andres Meza, Alric Althoff, David Kohlbrenner, Ryan Kastner and 1 other

A cloud FPGA is rented to one user at a time and wiped clean before the next, so everyone assumes a departed user's secrets are gone — but this paper (UC San Diego and collaborators) shows that holding a value on a transistor for hours physically ages it in a way that depends on whether the value was a 1 or a 0, leaving a faint analog imprint that survives the logical wipe; a later renter can program a timing sensor onto the same chip, measure how the aged transistors slowly recover, and read back the departed secret — recovering an AES key on a real Amazon FPGA even though the original design and its data are long gone.

The argument in one glance

Problem

A wiped cloud FPGA is assumed to keep no secrets, but transistors remember

Cloud providers rent out FPGAs — reconfigurable chips you program to accelerate a workload — as an on-demand service. Because two tenants are never placed on the same FPGA at the same time, the chip is only shared over time: one user finishes, the provider wipes the chip's logical state, and later hands it to the next user. The accepted wisdom is that once the FPGA is correctly erased, nothing of the previous tenant remains — no computation, no logical data, nothing to leak. This paper shows that wisdom is wrong. When a value sits on a transistor for hours, the transistor physically ages, and it ages differently depending on whether it held a 1 or a 0. That aging is analog and physical; it is not part of the logical state a wipe erases, so it survives. The departed secret is still faintly imprinted in the silicon itself, the way a painter's earlier brushstrokes linger under the paint that covered them — a pentimento.
What people did

Wipe the FPGA's logical state between tenants

The standard defense is exactly what providers do: when a tenant relinquishes an FPGA, scrub its configuration and memory so no logical trace of the design or its data remains, then return the clean device to the pool for the next renter.
Why it fell short

A logical wipe cannot remove a physical, analog imprint

A wipe clears the bits, but transistor aging is not a bit — it is a slow physical change in how fast a transistor switches, caused by the value it held under voltage over time. Erasing the configuration does nothing to reverse it. And the aging is value-dependent and asymmetric: a transistor that held a logical 1 ages differently, and recovers differently, than one that held a 0. So the physical state of the silicon still encodes what the previous tenant's secret was, and no amount of logical scrubbing touches it. The information the provider believes is gone is sitting in the analog behavior of the chip, waiting for someone who knows how to read it.
This paper's idea

Program a timing sensor to read the aging back out

Pentimento shows a remote attacker can recover this residue. The physical effect is bias temperature instability (BTI, or burn-in): holding a value stresses transistors and slows them, and when the stress is removed they slowly recover toward their original speed, at a rate that reveals the value they held. A later renter of the same FPGA programs a time-to-digital converter — a sensor that precisely measures how long a pulse takes to travel through a wire — onto the exact routes that held the secret, watches the tiny propagation-delay changes as the transistors recover, and infers each bit. Knowing only the non-secret physical layout, or "skeleton", of the target design, the attacker reads back a secret that was logically erased, recovering an AES key on a real Amazon FPGA.

Why this problem is worth solving

The vulnerability lives in a physical effect that was known to reliability engineers but not treated as a leak.

Bias temperature instability, or BTI, is a well-known aging effect in transistors: when a CMOS transistor is held under voltage for a long time, its electrical characteristics slowly degrade, which shows up as a longer propagation delay — the transistor switches a little slower than when it was new. Crucially, the effect is value-dependent. Applying a logical 0 causes one flavor (negative BTI) and a logical 1 the other (positive BTI), and the two are asymmetric: the degradation from a 0 is typically larger, and it also recovers faster once the stress is removed. Recovery is the key: when the held value goes away, the aged transistor partially reverts toward its original, faster state, and the speed and magnitude of that recovery depend on what value it had been holding. So the history of a transistor — whether it stored a 1 or a 0 for hours — is written into the analog dynamics of how its delay changes over time. Reliability engineers have long guarded against BTI as a source of slow-down and failure; this work reframes the very same effect as a covert store of the data that caused it.

The reason it matters is that cloud FPGAs are shared exactly in the way that turns this residue into a cross-tenant leak.

A cloud FPGA is a reconfigurable chip a provider like Amazon rents on demand; users program it with a bitstream to accelerate workloads from machine learning to cryptography. Because letting two tenants occupy one FPGA simultaneously would create obvious isolation risks, providers share FPGAs only temporally: a chip serves one tenant at a time, is wiped when that tenant leaves, and is later re-rented. The security model rests entirely on that wipe removing everything — providers explicitly guarantee that a marketplace design’s internal code is not exposed and that FPGA state is scrubbed when an instance ends. Data remanence is the general phenomenon of information persisting in hardware after it is supposed to be gone; here the remanent information is not leftover bits but the analog transistor aging that a logical wipe never addresses. Because the same physical device passes from one tenant to the next, a later tenant is in the perfect position to measure that aging, making a previously theoretical reliability effect into a practical channel that leaks a prior user’s, or a design vendor’s, secrets across the boundary the cloud model depends on.

What people did before, and where it broke

Rely on temporal-only sharing plus a wipe. Never co-locate tenants; scrub the FPGA’s configuration and memory between users so no logical trace remains. Where it broke. The wipe removes logical state but not the physical transistor aging a held value induces, so an analog imprint of the previous tenant’s data survives erasure.
Trust marketplace design encryption to hide vendor IP. Distribute proprietary FPGA designs as encrypted images so renters cannot read the internal design or its embedded secrets. Where it broke. A renter who runs the design long enough burns its embedded constants into the routes, then measures the aging to extract keys or weights the encryption was meant to protect.
Assume physical attacks need co-location. Treat FPGA side channels — power and timing sensors that steal keys from active computation — as requiring the attacker and victim to run on the same device at the same time. Where it broke. Pentimento needs no simultaneous co-location: it targets a victim who has already left, reading a residue that persists after the victim relinquishes the device, so temporal sharing is enough.
Regard BTI purely as a reliability concern. Manage transistor aging as a cause of slowdown and eventual failure, mitigated for performance and lifetime, not treated as information leakage. Where it broke. The very same value-dependent, asymmetric aging that reliability engineers track is a readable record of the data that caused it, so ignoring its confidentiality implications left the channel open.
The gap. No one had shown that logically-erased cloud-FPGA data persists as an analog physical imprint recoverable by a later remote tenant, nor demonstrated it end to end against a commercial cloud platform. Establishing that this remanence is real, measurable, and exploitable — down to recovering a cryptographic key on real hardware — is what Pentimento contributes.

How the Pentimento attack works

From a held secret to a recovered key on a wiped FPGA

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

The idea

Digital data leaves an analog fingerprint the wipe never touches. The security model assumes a chip has exactly one kind of state — the logical configuration and memory that a wipe clears. Pentimento’s core insight is that there is a second, hidden state: the physical condition of the transistors themselves, which a held value slowly and permanently reshapes through aging. A wipe operates on the logical layer and is blind to the analog one, so the imprint of the previous tenant’s secret persists in the silicon after every bit is erased. Recognizing that information deliberately erased from the digital domain can survive in the analog physical substrate of a device, readable by anyone who knows how to look, is the same insight the SRAM analog-domain work covered elsewhere on this site is built on, exploiting the fact that a memory cell’s physical behavior carries information beyond the clean digital abstraction that everyone reasons about.

Turn a value-dependent physical effect into a readout with a timing sensor. An imprint is only a leak if it can be measured, and the elegance here is that BTI writes the secret into a quantity an FPGA can measure with its own fabric: propagation delay. Because a held 1 and a held 0 age a transistor asymmetrically and recover at different rates, the delay of a route and how that delay changes over time carry the value it stored. The attacker programs a time-to-digital converter — sending a pulse through the target route into a carry chain and recording how far it gets — to read those tiny delay changes directly, converting the analog aging into digital samples from which the bit follows. Extracting an on-chip secret by measuring a physical side effect of the hardware, rather than reading the secret through any logical interface, is the same physical-side-channel strategy the on-chip power-domain attack work covered elsewhere on this site uses, stealing data that is never logically exposed by observing the analog signature the computation leaves behind.

Exploit temporal sharing, not co-location, to cross the tenant boundary. Prior FPGA side channels needed the attacker and victim active at the same time on the same chip, which cloud providers avoid by never co-locating tenants. Pentimento sidesteps that entirely: the victim is gone: it targets a residue that outlives the victim’s tenancy, so the attacker only needs to be assigned the same physical device afterward, which temporal sharing routinely arranges. This makes the wipe-and-reuse workflow itself the delivery mechanism for the leak, breaking the isolation the cloud model relies on without ever violating the one-tenant-at-a-time rule. Leaking a secret across the boundary between successive users of shared cloud hardware, by reading state one tenant left behind for the next to find, is the same cross-tenant threat the public-cloud cache side-channel work covered elsewhere on this site studies, showing that sharing a physical resource over time, not just in space, is enough to carry information between mutually distrusting users.

Following a secret key through the attack

Recovering an embedded key from a marketplace design

A trace, from the paper, of the design-data extraction threat model, where a malicious renter targets a secret baked into a third-party encrypted FPGA design (validated on AWS F1, including AES key recovery).

Step 1 of 5

Learn the skeleton and take a baseline

The attacker rents the target design and, knowing its skeleton — the physical placement of the routes that will hold the secret, derivable from a public design like the OpenTitan root of trust that ships a prebuilt bitstream — measures those routes' delays before any burn-in to establish a baseline.

In this model the attacker controls loading and unloading, so a clean pre-burn-in reference is available, unlike the harder previous-user model.

Why it works

Aging is physical state a logical wipe cannot reach. Providers erase configuration and memory, which is all logical → but transistor aging is a slow physical change in switching speed, not a bit → so the imprint of a held secret survives every logical scrub and remains in the silicon.
The effect is value-dependent and asymmetric, so it encodes the data. If a 1 and a 0 aged transistors identically the residue would be uninformative → but negative and positive BTI differ in magnitude and recovery rate → so the delay signature of each route reveals which value it held.
The FPGA can measure its own delays precisely. An analog imprint is useless if it cannot be read → but a time-to-digital converter built from a carry chain measures nanosecond propagation changes on the target routes → so the aging is converted into digital samples the attacker can analyze.
Recovery over time strengthens the readout. A single static delay is ambiguous → but watching each route recover after the stress is removed exposes the value-dependent recovery dynamics → so the attacker distinguishes held 1s from 0s by how the delay changes, not just its instantaneous value.
Temporal sharing delivers the victim device to the attacker. Classic FPGA side channels need simultaneous co-location, which providers prevent → but Pentimento reads a residue that persists after the victim leaves → so being assigned the same wiped device later, which reuse routinely does, is all the access the attacker needs.

What it costs (trade-offs and scope)

The attacker must know the skeleton. Both threat models assume the attacker knows the physical placement of the routes holding the secret — the non-secret structure, not the contents. This is realistic for designs whose layout is public (the paper points to the OpenTitan root of trust, distributed as a prebuilt bitstream users fill with keys), but it is a required assumption, and a design whose asset placement is unknown to the attacker is harder to target.
It needs sustained holding to burn in. The imprint accrues over hours of the secret being held statically under stress; short-lived or rapidly-changing values leave a weaker signature, so the attack is strongest against long-running designs that keep a secret fixed in place, such as an embedded key.
The previous-user model is harder than the design model. Extracting a prior tenant’s runtime data forgoes a pre-burn-in baseline, because the attacker did not control when the victim’s design loaded, making it more challenging than the design-extraction model where the attacker can calibrate against clean routes first.
Mitigation is costly and shifts the burden. Because the leak is physical, no logical erasure removes it; the paper’s countermeasures are to leave FPGAs idle long enough for BTI to recover before re-renting (which reduces provider utilization and revenue), or for manufacturers to add architectural BTI mitigation (added complexity, and thermal mitigations are already pursued for other reasons). There is no cheap software fix.
It is an attack demonstration, and the target is specific. The contribution is establishing that the channel is real and exploitable, validated on AWS F1 with AES key recovery under one model; the difficulty, reliability, and reach of the attack across other designs, secrets, devices, and cloud platforms depend on route lengths, holding times, and measurement conditions that vary case by case.

The evaluation

What a wiped cloud FPGA leaks to the next tenant

Property	Conventional assumption	Prior FPGA side channels
What is assumed to remain after a wipe
When the attacker must be present	n/a
What is measured	n/a	Live power or timing of active computation
What the attacker must know	n/a	The victim's live behavior
Demonstrated result

From the paper. Pentimento shows that a logically-wiped cloud FPGA retains an analog imprint of a prior tenant's data through bias temperature instability, recoverable by a later tenant with a time-to-digital converter, and validates the threat on Amazon's F1 platform including recovering an AES key under one threat model.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

The contribution is a demonstrated attack that overturns a load-bearing assumption of cloud FPGA security: that wiping a chip between tenants removes a departed user’s data. Pentimento shows a second, physical form of state — value-dependent transistor aging from bias temperature instability — persists through the logical wipe, and that a later tenant can read it back by programming a time-to-digital converter onto the routes that held the secret and measuring their recovery, recovering an AES key on Amazon’s F1 platform. Read that with its scope. The attacker must know the design’s skeleton (its route placement, not its secret contents), realistic for public-layout designs like a distributed root of trust but a genuine requirement. The secret must be held long enough to burn in, so long-running static secrets like embedded keys are the natural target. The previous-tenant variant is harder than the design-extraction one because no clean baseline is available. And because the leak is physical, mitigations are expensive — idling FPGAs to let them recover, at a cost to provider utilization, or architectural changes by manufacturers — with no logical fix. As a security result, its value is precisely in being real and validated on commercial hardware, forcing cloud FPGA providers and users to treat analog remanence, not just logical state, as part of the threat model.

Background

Why cloud FPGAs invite a new kind of attack

It helps to see why FPGAs in the cloud are such fertile ground for novel attacks. An FPGA is not a fixed processor but a fabric of programmable logic and routing that the tenant configures into whatever circuit they like, which is exactly what makes it powerful for accelerating machine learning, video, genomics, and cryptography — and exactly what makes it dangerous when rented out. Because the tenant defines the hardware, they can build sensors out of the fabric itself: circuits that measure voltage, temperature, or, as here, the precise timing of signals, turning the accelerator into an instrument for observing the chip’s physical state. Ordinary cloud processors do not hand users that level of physical access. So cloud FPGAs sit at an unusual intersection: they are a shared physical resource, and the sharer is invited to program low-level measurement circuits directly onto the silicon. That combination — putting a reconfigurable, sensor-capable substrate into a multi-tenant cloud — is the same setting the cloud-FPGA prototyping-platform work covered elsewhere on this site operates in, standing up large FPGA systems as a shared cloud resource. Pentimento is a reminder that when the shared resource is programmable hardware, isolation has to account for the physics of the device, not just its logical state.

If you remember only three things

1. Cloud FPGAs are shared only over time — one tenant at a time, with a logical wipe between users — and the accepted security model assumes the wipe removes everything a departed tenant left; Pentimento shows this is false, because holding a secret value on the chip's transistors for hours physically ages them through bias temperature instability (burn-in) in a value-dependent, asymmetric way, leaving an analog imprint of the data that a logical wipe cannot erase.
2. A later tenant assigned the same physical FPGA can recover the imprint: knowing the design's skeleton (the non-secret placement of the routes that held the data), they program a time-to-digital converter — a carry-chain sensor that precisely measures a route's propagation delay — onto those routes and sample how the aged transistors recover over time, and from the value-dependent recovery signature deduce whether each route held a 1 or a 0, reconstructing the secret bit by bit without any logical access to it.
3. The attack needs no live co-location, only temporal reuse, so the wipe-and-re-rent workflow itself delivers the victim's device to the attacker; it is validated end to end on Amazon's F1 cloud FPGAs, recovering an AES key under one threat model, and it targets both secrets baked into marketplace designs and data left by a prior user. Because the leak is physical, there is no logical fix — mitigations mean idling FPGAs until burn-in recovers (costing provider utilization) or architectural BTI mitigation by manufacturers — so cloud FPGA security must now account for analog remanence, not just logical state.

Check yourself

Check your understanding

1. Why does wiping a cloud FPGA between tenants fail to remove a previous user's secret?
2. How does the attacker read the imprint back out?
3. Why can this attack succeed even though cloud providers never place two tenants on one FPGA at the same time?
4. What are the attack's key assumptions and limits, and why does mitigation matter?

Sources

The paper is “Pentimento: Data Remanence in Cloud FPGAs” by Colin Drewes (Stanford University and UC San Diego), Olivia Weng, Andres Meza (UC San Diego), Alric Althoff (ARM), David Kohlbrenner (University of Washington), Ryan Kastner (UC San Diego), and Dustin Richmond (UC Santa Cruz), published at ASPLOS 2024, DOI 10.1145/3620665.3640355.

This explainer is written from the full text of the authors’ arXiv version (arXiv:2303.17881). Everything above comes from the paper’s own sections: the introduction framing the cloud-FPGA sharing model (temporal-only sharing with a logical wipe between tenants) and the pentimento analogy (analog residue of previous digital data, like painted-over brushstrokes revealed by infrared); the background on bias temperature instability (value-dependent, asymmetric transistor aging from held logical 0s and 1s, with negative BTI larger and recovering faster than positive, and recovery revealing the prior value); the threat models (Threat Model 1 extracting Type A design data such as an embedded key from an encrypted marketplace design, where the attacker controls loading and can take a pre-burn-in baseline; Threat Model 2 recovering a previous tenant’s Type B runtime data, which is harder without a baseline), both violating stated AWS F1 guarantees that internal design code is not exposed and that FPGA state is scrubbed on instance termination; the skeleton assumption (the attacker knows the physical placement of the target routes, derivable from a public design or bitstream, illustrated with the OpenTitan hardware root of trust and its prebuilt-bitstream flow and its twenty security-critical assets); the time-to-digital converter sensor (a tunable dual-polarity TDC using a carry chain to measure nanosecond propagation-delay changes on a route under test); and the experimental validation, characterizing burn-in on an UltraScale-plus development board and demonstrating the threat on the AWS F1 platform, including successful AES key recovery under one threat model, along with the discussion that logical erasure cannot mitigate the physical burn-in and that mitigations require idling FPGAs to allow recovery or architectural changes by manufacturers.