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

arXiv:2610.01736 · cs.CR · Submitted 2026-10-01 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "The Achilles' Heel of Partial Reconfiguration".

Elias: Major FPGA manufacturers have incorporated bitstream encryption to protect sensitive configuration data,

Nadia: First, who's behind it and why it matters.

Paper summary: Nadia: So, we're diving into "The Achilles' Heel of Partial Reconfiguration: Optical Side-Channel Leakage on the seven-Series ICAP," and it sounds like this paper is really digging into a known weakness in how big FPGA manufacturers are trying to secure their configuration data. Elias, could you give us the rundown on what they're actually proposing with this work?

Elias: Certainly, Nadia. The core thesis of "The Achilles' Heel of Partial Reconfiguration: Optical Side-Channel Leakage on the seven-Series ICAP" is that even when major FPGA manufacturers put bitstream encryption in place to safeguard sensitive configuration data, there are still vulnerabilities in how they implement these protections, specifically through the hard-wired configuration interfaces. The paper presents a proof-of-concept of an AMD asymmetric key encryption scheme used for seven-Series FPGAs involving partial reconfiguration from the Programmable Logic. What matters most is their demonstration that even these patchable protection schemes can be bypassed or completely broken by optical side-channel attacks exploiting those hard-wired configuration interfaces during dynamic reconfiguration.

Priya: That sounds intense, Elias. From my perspective on measurement research, what exactly is the paper claiming they can recover when they talk about "plain-text data" during the dynamic reconfiguration process? Is this just some random bits or something more meaningful to the configuration itself?

Nadia: Exactly, Priya. The authors claim their attack enables them to recover plain-text configuration data by leveraging Photon Emission Microscopy and Electro-Optical Probing. They're not just looking at noise; they are mapping the vulnerable structures on the configuration logic using PEM first, and then using EOP to extract actual signals from that interface. This means they can read out data that is supposed to be protected by their encryption scheme.

Elias: And what's fascinating about the mechanism described in "The Achilles' Heel of Partial Reconfiguration: Optical Side-Channel Leakage on the seven-Series ICAP" is how they tie this together; it shows that because the configuration logic needs plain-text data from the programmable logic when performing partial reconfiguration with custom decryption cores, that interface becomes a major leakage point. This isn't just a theoretical weakness; it's tied directly to the operational necessity of partial reconfiguration itself.

Paper summary: Priya: So, if I understand correctly, the paper is showing that the physical hardware design of how an FPGA handles dynamic reconfiguration creates a pathway where sensitive data leaks through light emission and probing techniques? That really puts a spotlight on the physical layer of security that we usually focus on in software-level attacks.

Nadia: Precisely, Priya. It's about showing that no matter how clever the cryptographic scheme is, if the interface itself allows for plain-text data exposure via optical channels, then the entire protection structure falls apart. The implication here is significant because it suggests that relying solely on encryption to protect configuration data isn't enough when you have these kinds of physical access vectors available.

Elias: I agree with Nadia on the vulnerability aspect, but I want to emphasize the cryptographic setup they are testing; they implemented an AMD-proposed asymmetric key encryption scheme based on partial reconfiguration. They showed how this specific combination of asymmetric key generation and dynamic process is susceptible to this optical attack vector. The proof hinges on the fact that the private key, for instance, is stored in CLBs registers and gets lost upon power loss, forcing regeneration when reprogramming.

Priya: It's interesting how they link the key storage mechanism to the attack; if those keys are transient or require physical access during operation, that makes sense why probing would be effective in this scenario. Does the paper mention what kind of key material they were able to extract using this PEM and EOP approach?

Nadia: They demonstrate that with a malicious host, they can generate a periodicity in the target data and align it with a trigger signal to synchronize the EOP measurements. This synchronization allows them to binarize the resulting waveforms, which then reveals plain-text configuration data like NOPs or synchronization words, proving they can read out actual operational instructions.

Elias: That part about synchronizing the measurements with a trigger signal is key because it shows that the attack isn't just random noise collection; it requires a level of timing control over the target device's operations to succeed. This speaks directly to how sensitive timing information can be leaked via optical channels during critical configuration steps.

Priya: So, if we look at the practical impact, what does this mean for a designer or a security team building systems that rely on partial reconfiguration for sensitive functions? Are they telling us to abandon these interfaces entirely?

Paper summary: Nadia: Not necessarily abandoning them, but it definitely forces a reevaluation of the security posture around those interfaces. The paper suggests that countermeasures could involve clocking the ICAP interface with an irregular clock source or adding random delays between ICAP writes to make synchronization harder for an attacker.

Elias: Those are practical suggestions, but I'm concerned about the fundamental issue they identify; it points to a flaw in the design where configuration logic still requires plain-text data from the programmable logic even when using custom decryption cores. That dependency is what makes it an Achilles' Heel, and that's a deep architectural problem rather than just a simple implementation bug.

Priya: I wonder about the cost of implementing these countermeasures; are we talking about adding significant overhead to the FPGA fabric just to mitigate this optical leakage? The paper mentions some limitations related to measurement time, which I assume ties into that overhead.

Nadia: Yes, Priya, measurement time is a clear limitation mentioned in "The Achilles' Heel of Partial Reconfiguration: Optical Side-Channel Leakage on the seven-Series ICAP"; recovering the full bitstream takes a significant amount of time. Furthermore, they also flag that they are only considering these attacks on sixty-nm FPGA devices for their probing capabilities.

Elias: And the scope is limited by what the authors themselves acknowledge; they disclose their findings to AMD in May two thousand twenty-six but they state that AMD does not consider physical backside attacks within their threat model. This suggests that while the PoC shows a path, the larger industry response might be slower than what this paper implies.

Priya: That distinction between what the authors tested and what manufacturers are currently modeling is really important for understanding where this research sits in the broader security conversation. It highlights a gap between theoretical attack vectors and current threat modeling practices.

Nadia: So, to wrap up on this paper, "The Achilles' Heel of Partial Reconfiguration: Optical Side-Channel Leakage on the seven-Series ICAP," it successfully demonstrates that combining PEM for location and EOP for extraction allows for the recovery of plain-text data traversing the ICAP. This finding strongly implies that patchable encryption schemes are not entirely safe when there's a hard-wired interface leaking information through optical channels.

Paper summary: Elias: It really underscores the necessity of looking beyond just the encryption layer and examining the physical interaction points between logic and configuration, especially in complex processes like partial reconfiguration. The implications are that we need to consider side-channel leakage through optical channels when designing any system that involves dynamic reconfiguration on FPGAs.

Priya: It’s fascinating how this moves the discussion from purely software or cryptographic analysis into the physical realm of how light interacts with silicon structures during operation. This research gives us a clearer picture of the persistent threat surface that exists even in seemingly secure hardware implementations.

Nadia: Indeed, Priya, and that’s what we need to communicate: these findings necessitate a serious reevaluation of how we approach securing configuration data on FPGAs moving forward. We have to think about those hard-wired interfaces as inherent vulnerabilities rather than just easily patched ones.

Elias: I think the most significant implication is that the architecture itself, specifically the dependency on plain-text data during PR with custom cores, is a fundamental weakness that needs to be addressed at the design level, not just by adding more layers of encryption.

Priya: I think what sticks with me is how these optical probing techniques are relatively low-cost compared to some other invasive physical attacks, which makes this a very tangible threat for specific sections of sensitive bitstreams. It shows that confidentiality can be breached through non-invasive means if the target interface is accessible.

Nadia: That's exactly the point, Priya; it’s about finding ways to secure those configuration interfaces against these kinds of non-invasive probes, which is a much harder problem than just hardening a cryptographic key. We have to focus on mitigating that physical leakage path.

Elias: So, as we conclude this discussion on "The Achilles' Heel of Partial Reconfiguration: Optical Side-Channel Leakage on the seven-Series ICAP," it confirms that optical side-channel leakage through hard-wired interfaces poses a risk even to advanced, patchable encryption schemes.

Priya: It's clear that the path forward involves combining architectural changes with physical hardening techniques to address these very specific measurement vulnerabilities. This paper gives us a solid foundation for discussing those kinds of physical security considerations in future work.

Conclusion: Nadia: So, to wrap up our discussion on this paper titled "The Achilles' Heel of Partial Reconfiguration: Optical Side-Channel Leakage on the seven-Series ICAP," it successfully proves that even advanced encryption schemes for FPGA configuration data can be bypassed using optical side-channel attacks targeting the hard-wired interfaces. Elias, what do you think about the authors and their approach to testing this?

Elias: I'm really interested in how they set up the test because they use an AMD-proposed asymmetric key encryption scheme specifically designed for partial reconfiguration; it makes sense that they'd target that specific setup, Nadia. The authors are showing that this particular combination of a custom cryptographic engine and the way keys are stored inside CLBs registers is what creates the vulnerability.

Priya: From my side, I'm still focused on the specifics of the data they recovered; I wonder what kind of actual configuration information they managed to pull out using those PEM and EOP techniques. Does it reveal proprietary logic or something more abstract?

Nadia: That’s exactly where I want to focus next, Priya; we need to talk about how accessible this exploit is and what the real-world impact could be on hardware security across the board. Elias, you mentioned the specific parameters that break the scheme; can you tell us if this vulnerability is general or tied only to certain key lengths or algorithm choices?

Elias: It appears pretty specific because they are targeting an implementation detail where configuration logic needs plain-text data when performing partial reconfiguration with custom decryption cores; that dependency is what makes it exploitable, regardless of how strong the RSA-OAEP encryption is.

Priya: I think the real implication here for privacy researchers is that this isn't just about breaking a single key; it suggests that any system relying on dynamic reconfiguration for sensitive tasks has a physical data leakage pathway we haven't fully accounted for yet.

Nadia: That’s a huge shift, Priya; it moves the threat model away from purely digital attacks and into the realm of physical access and measurement, which means mitigation strategies have to change fundamentally.

Elias: And from a cryptographic standpoint, if we have to consider optical probing as a valid attack vector against these specific key storage mechanisms, then we need to start thinking about integrating physical countermeasures directly into the hardware design phase.

Priya: So, what’s the immediate impact on how we design new systems that use FPGAs for complex logic? Are we looking at completely redesigning how those configuration interfaces are physically laid out?

Nadia: We're definitely looking at re-evaluating the entire security architecture around those interfaces; this paper makes it clear that hard-wired access points aren't just passive components, they’re active attack surfaces.

Elias: It really pushes us to consider the physical layer of security much more seriously than we usually do when we talk about software patches.

Priya: I think the next step is understanding how these non-invasive probes could scale up if someone gains access to even a limited number of devices in a specific environment.

Nadia: Exactly, Priya; that scaling potential is what makes this research so important for anyone looking at the future security of embedded systems.

Antonio Saavedra, Jan Caspar Marx, Lars Renkes, Jean-Pierre Seifert

Technische Universität Berlin

cs.CR

Submitted: 2026-10-01

Updated: 2026-10-01

Comments: Accepted for publication in the 29th Euromicro Conference on Digital System Design (DSD 2026)

Code: https://github.com/JnCrMx/icap-probing-poc

License: http://creativecommons.org/licenses/by-nc-nd/4.0/

Importance score: 70/100

The gist: Major FPGA manufacturers have incorporated bitstream encryption to protect sensitive configuration data, but this work presents a proof-of-concept implementation of an AMD-proposed asymmetric key

Key concepts

Partial Reconfiguration: This is a technique where different parts of an FPGA can be reconfigured independently while the rest remains operational. The paper focuses on how this process, when combined with custom cryptographic engines, creates a vulnerability because the reconfiguration relies on hard-wired interfaces that are susceptible to physical attacks.
Photon Emission Microscopy (PEM): PEM is a technique that uses light emitted from electron-hole recombination during switching events to map and locate specific hardware components. In this attack, it helps find the exact location of the internal ICAP interface where configuration data flows, acting as a precise locator for the target.
Electro-Optical Probing (EOP): EOP involves focusing infrared light onto an active device area to measure voltage changes. This allows researchers to extract waveform data representing the voltage over time at a specific probing location. It is used here to capture and analyze the plain-text configuration data transmitted through the identified interface.

Terminology

Partial Reconfiguration — 28× in this paper
Elias — 17× in this paper · explained in 2 episodes
Nadia — 17× in this paper · explained in 2 episodes
Core — 10× in this paper · explained in 2 episodes
Programmable Logic — 8× in this paper
Electro-Optical Probing — 6× in this paper
Photon Emission Microscopy — 6× in this paper
Alignment — 2× in this paper · explained in 1 episode
Trace — 2× in this paper · explained in 2 episodes
AES-CBC Initialization Vector — 1× in this paper
Advanced Encryption Standard — 1× in this paper
Frame Address Register — 1× in this paper
Post-Quantum Cryptography — 1× in this paper
Verification — 1× in this paper · explained in 2 episodes

Summary

Major FPGA manufacturers have incorporated bitstream encryption to protect sensitive configuration data, but this work presents a proof-of-concept implementation of an AMD-proposed asymmetric key encryption scheme for 7-Series FPGAs and demonstrates that even patchable protection schemes are vulnerable to optical side-channel attacks exploiting the hard-wired configuration interfaces.

The core finding is that advanced encryption schemes utilizing Partial Reconfiguration and custom cryptographic engines are vulnerable to optical attacks because reconfiguration is only possible via hard-wired, vulnerable configuration interfaces.

How it works

The attack leverages two primary techniques: Photon Emission Microscopy (PEM) to locate and map the target ICAP interface, and Electro-Optical Probing (EOP) to extract the plain-text data. PEM relies on photon emission originating from electron-hole recombination during switching events, which is proportional to switching activity and current density. This technique is used first to locate and then contactlessly extract the plain-text data from the ICAP interface. Once located, EOP is employed; infrared light is focused onto the active device area, where voltage-dependent freecarrier effects modify optical properties, allowing for the recovery of a waveform representing the voltage over time at that specific probing location.

The implementation and scheme under attack

The proof-of-concept (PoC) implementation targets an AMD XC7A200T device using the asymmetric key encryption scheme proposed in UG909 [9]. This scheme splits the FPGA into a static part and a dynamic user space, where the static part handles key generation and decryption logic, and the dynamic space handles user logic. The process involves:

Key Generation: RSA key pair generation takes place on the FPGA itself using random bit values from multiple ring oscillators in the reconfigurable partition. The private key is stored in CLBs registers and is lost upon power loss, forcing regeneration upon reprogramming.
Encryption: A host generates a random AES-256 key and IV, encrypts them with RSA-OAEP using the FPGA’s public key to create an encrypted key block.
Decryption and Programming: The host sends the encrypted key block to the FPGA, which decrypts it, initializes its AES decryption module, and then sends bitstream blocks one by one to the ICAP after decrypting each block.

The attack methodology

The attack is executed in two sequential steps requiring a malicious host. First, PEM is used to identify the ICAP interface by injecting switching activity into the interface using an FPGA design that writes alternating 32-bit words of all 1s and 0s to both interfaces, revealing photon emission hotspots. Second, EOP is used on the identified interface. The malicious host must then generate a periodicity in the target data and a trigger signal aligned to it to synchronize the EOP measurements with the data transmission through the ICAP. The resulting EOP waveforms are binarized using a thresholding algorithm, which reveals plain-text configuration data, such as synchronization words or NOPs.

Security implications and limitations

The vulnerability is not limited to this specific PoC; it is claimed that even advanced encryption schemes utilizing Partial Reconfiguration and custom cryptographic engines are vulnerable to optical attacks. The ICAP interface presents an Achilles’ Heel because the configuration logic requires plain-text data from the PL when performing PR with custom decryption cores. Limitations include measurement time, where full bitstream recovery takes significant time, and the necessity of specialized equipment like PEM and EOP. However, the exposure of confidential data remains a viable threat for specific sections of sensitive bitstreams.

Countermeasures and future directions

Potential countermeasures include clocking the ICAP interface with an irregular clock source or adding random delays between ICAP writes to hinder proper alignment of subsequent EOP traces. Manufacturers could also incorporate sensors to detect physical changes due to probing attacks or protect the backside with a reflective coating. Future work is proposed to enhance security by checking the addresses of configuration frames transmitted through the ICAP and incorporating countermeasures like random delays into protection mechanisms, while also studying this attack surface in newer devices like Spartan UltraScale+.

Conclusion

The work successfully demonstrates that combining PEM to locate and map the internal configuration interface with EOP to perform contactless probing allows for the recovery of plain-text data traversing the ICAP, bypassing the encryption scheme entirely. This finding necessitates a reevaluation of patchable encryption schemes for FPGAs due to the inherent optical side-channel leakage through hard-wired programming interfaces. The available resources in this user space are noted as "51% of the total LUTs and FFs, as well as 88% of the BRAM and 44% of the DSP Slices.

Improvements for AI systems

Here are the specific improvements and capabilities that an AI system could derive from this research:

The ability to perform high-fidelity, non-invasive side-channel analysis on hardware security modules (like FPGAs) using optical techniques (PEM/EOP). An improved AI system could autonomously design and execute probing sequences tailored to specific ICAP interfaces based on structural maps derived from PEM data.
The capability to detect and localize hidden configuration data within encrypted bitstreams during dynamic reconfiguration processes, even when sophisticated asymmetric encryption schemes (like the AMD UG909 scheme) are in place.
The ability to identify and exploit Achilles' Heel vulnerabilities in patchable security mechanisms by specifically targeting the hard-wired interfaces (ICAP) that connect configuration logic to partial reconfiguration, bypassing software/firmware-level encryption entirely.
The development of automated countermeasures for hardware security systems, such as implementing irregular clock sources or random delays in ICAP writes to disrupt the signal alignment required for optical probing attacks.
The creation of a comprehensive vulnerability assessment tool that combines structural analysis (mapping pins via PEM) with probing (EOP) to generate precise, actionable exploit paths against FPGA configuration interfaces.

Abstract

Major FPGA manufacturers have incorporated bitstream encryption to protect sensitive configuration data. However, for the most widely used FPGA families, multiple attacks against unpatchable protection schemes hard-wired into the devices can bypass or fully break them, making patchable schemes desirable. In this work, we present a proof-of-concept implementation of an AMD-proposed asymmetric key encryption scheme for bitstream protection for 7-Series FPGAs, using partial reconfiguration from the Programmable Logic. We analyze the security implications and hardware overhead of this implementation. We then propose and demonstrate an optical side-channel attack that is able to recover plain-text configuration data during the dynamic reconfiguration process. This attack leverages Photon Emission Microscopy and Electro-Optical Probing to first locate and then contactlessly extract the plain-text data from the ICAP interface, which internally connects the Programmable Logic with the configuration logic. We located the ICAP buses in an AMD XC7A200T device and show that the data on it can be extracted with Electro-Optical Probing. We claim that even advanced encryption schemes utilizing Partial Reconfiguration and custom cryptographic engines are vulnerable to optical attacks, as reconfiguration is only possible via hard-wired, vulnerable configuration interfaces.