Backing the Wrong Horse: How Bit-Level Netlist Augmentation can Counter Power Side Channel Attacks

TL;DR

The paper tackles power-based side-channel vulnerabilities in FPGA-implemented cryptography by introducing a bit-level leakage countermeasure that perturbs the correlation between observed power and $HD$-based leakage estimates. Instead of adding noise, it injects a fixed offset when a targeted bit does not toggle, degrading the CPA’s ability to correctly recover keys. The authors implement the concept with a ring-oscillator based offset generator and an XNOR LUT on a CW305 FPGA setup for AES-128, demonstrating substantially increased trace requirements for successful CPA attacks. This approach challenges the limits of hiding-based defenses and points to a new direction for low-overhead, bit-level countermeasures with practical security gains, albeit with future work needed to optimize hardware efficiency.

Abstract

The dependence of power-consumption on the processed data is a known vulnerability of CMOS circuits, resulting in side channels which can be exploited by power-based side channel attacks (SCAs). These attacks can extract sensitive information, such as secret keys, from the implementation of cryptographic algorithms. Existing countermeasures against power-based side channel attacks focus on analyzing information leakage at the byte level. However, this approach neglects the impact of individual bits on the overall resistance of a cryptographic implementation. In this work, we present a countermeasure based on single-bit leakage. The results suggest that the proposed countermeasure cannot be broken by attacks using conventional SCA leakage models.

Figures (2)

• Figure 1: Measured voltage drop of the power supply for byte 0 over the HD values. Blue are the values for the correct key while Red are the values for an incorrect key. Lines indicate the resulting fitted lines of the HD points. Dashed versions indicate the result of an augmented implementation. One can see that in the augmented case an incorrect key would yield a better correlation
• Figure 2: Correlation of for all possible values of key byte 0 with an increasing number of traces with and without countermeasure