From Internal JTAG to Hardware Ransomware

The Silicon Heist study’s second escalation matters because it changes the kind of state a tenant can reach. ICAP access lets a running design reconfigure reachable fabric; internal JTAG can expose the device’s security and identity controls. This chapter follows that transition on the evaluated AMD UltraScale+ devices and explains why one-time-programmable eFuses can turn a runtime breach into a persistent recovery problem. The central judgment is evidence-sensitive: the researchers demonstrated the access path and non-destructive cloud reads, but they validated the irreversible lockout scenario locally rather than damaging an Amazon FPGA.

JTAG is the bridge to device security state

JTAG is widely used as a test and debug interface. It can provide a way to inspect or control low-level device functions that are deliberately hidden from ordinary application logic. In a cloud FPGA, the customer normally reaches the device through the provider shell and the assigned reconfigurable region. Physical distance from the board is supposed to reinforce the boundary: a tenant has no cable leading to the chip’s debug pins and no reason to expect access to the test infrastructure.

The Silicon Heist finding shows why physical absence is not the same as logical absence. The AMD devices contain an internal MASTER_JTAG element that can be reached from within the design when it is instantiated and connected. AWS’s normal verification path blocked a direct instantiation because it triggered a design-rule error. That would be an effective barrier if the checked customer image were the only way to activate hardware. The earlier ICAP result changed the condition. Once the running design could submit configuration changes, the researchers could activate the JTAG element after deployment, outside the original netlist check.

The sequence is important. A regular customer did not begin with a JTAG privilege. The customer first obtained a configuration-engine path through ICAP. That path allowed changes in a reachable secondary SLR. One of those changes could make a MASTER_JTAG primitive operational and connect it to a controller in the customer design. The paper therefore describes a chain of increasing authority: ordinary customer access, configuration-engine access, and then internal JTAG access. Skipping the intermediate step would make the result sound like a direct remote debug port exposed to every tenant, which is not what the study reports.

The researchers’ controller communicated with MASTER_JTAG through the shell and could send command sequences and capture responses. At a systems level, this created a new relationship between the tenant design and the device’s security infrastructure. The shell was still present, and the customer was still remote, but the customer design now had a path to functions that the provider intended to reserve for device management and debugging. The control plane had moved inward: instead of asking the cloud service to load an image, the running hardware could address the machinery that governs the image and the device’s persistent state.

That relationship exposed eFuse memory. On the studied AMD UltraScale+ devices, eFuses are non-volatile cells that can be programmed in only one direction. They are organized into registers that hold security settings and cryptographic material. “Non-volatile” means the state survives ordinary power cycles and resets.