The Achilles' Heel of Partial Reconfiguration: Optical Side-Channel Leakage on the 7-Series ICAP

What it is

Proof-of-concept and attack from TU Berlin researchers (Saavedra, Marx, Renkes, Seifert) targeting a specific AMD-proposed scheme: the asymmetric-key bitstream encryption for 7-Series FPGAs described in AMD's Dynamic Function eXchange User Guide (UG909). The PoC and attack target an AMD XC7A200T device. Source code, including RTL design and host-side scripts, is public at github.com/JnCrMx/icap-probing-poc.

How it works

The scheme splits the FPGA into a static region (RSA/AES key generation and decryption logic, generated on-chip via ring-oscillator-based TRNG per Sunar et al.) and a dynamic region for user logic. A host requests the FPGA's public key over USB-UART (921600 baud), encrypts a random AES-256 key/IV pair with RSA-OAEP, then streams the bitstream encrypted with that AES key block-by-block. The FPGA decrypts each block and forwards it as 32-bit words directly to the ICAP for partial reconfiguration. The attack exploits the fact that this decrypted data must transit the ICAP in plaintext: researchers first used Photon Emission Microscopy to locate and map the ICAP's physical pins on the die, then used Electro-Optical Probing (shining IR light on the backside, measuring voltage-dependent reflectance changes, averaging many synchronized measurements for SNR) to recover the actual waveform/data traversing those pins during reconfiguration.

Preconditions / Affected

Applies to AMD 7-Series FPGAs performing Partial Reconfiguration through the ICAP — demonstrated on an XC7A200T. Requires physical backside access to the chip (decapping/backside prep) plus PEM/EOP lab equipment; this is an invasive, instrumented hardware attack, not a remote or software exploit. AMD was notified in May 2026 and acknowledged the finding but stated physical backside attacks are outside their threat model — i.e., no vendor fix is coming.

What to do

The paper states it "analyzed the security implications... and proposed practical countermeasures" but the fetched text does not enumerate them beyond the finding itself — no concrete mitigation steps, shielding specs, or detection method are given in the available excerpt. The actionable takeaway stated is architectural: any bitstream-protection scheme relying on PR/ICAP for decrypted data transfer (this includes other patchable schemes cited: PUF-based Zynq frameworks, self-authenticating two-stage boot designs) inherits this same exposure, since the ICAP is hard-wired and unpatchable.

Caveats

This requires physical possession of the device and backside optical access — not a remote or network threat. The paper positions itself as the first optical attack specifically on the ICAP interface (distinct from prior optical attacks on BBRAM keys or the main configuration logic's internal buses); no CVE is assigned, and resource-utilization/timing benchmarks for the 768-bit vs 1024-bit RSA PoC variants were cut off in the fetched excerpt.