Correlation Power Analysis on AES with an FPGA Sensor

A final-round correlation power analysis against an AES-128 implementation on a Lattice iCE40HX8K, using a delay-based on-chip sensor, BRAM-backed trace capture, and a bitwise inverse S-box leakage model.

Implementation security, not AES cryptanalysis

AES is not weakened here at the algorithmic level. The attack targets the physical implementation: while the circuit evaluates internal state transitions, its switching activity affects measurable quantities. Conventional power analysis observes supply current or electromagnetic radiation. In this design, the measurement channel is a delay-based sensor placed on the FPGA itself.

The objective is to determine whether repeated sensor measurements contain a component that is statistically dependent on an internal AES value. Correlation power analysis (CPA) provides the test. It combines known ciphertexts, a key-dependent leakage hypothesis, and many aligned traces. The correct key hypothesis should correlate more strongly with the measured signal at the sample where the modeled intermediate value affects the device.

Target	AES-128 final round
Platform	Lattice iCE40HX8K
Trace width	56 samples
Final dataset	100,000 traces

Leakage model

The analysis proceeds one ciphertext byte at a time. For a ciphertext byte C and a candidate round-key byte K, the state before the final-round S-box is reconstructed as:

InvSBox(C XOR K)

Rather than reducing the intermediate value to a Hamming weight, the implementation evaluates each of its eight output bits separately. For every bit and every one of the 256 key-byte hypotheses, a vector of predicted zero/one values is produced across all encryptions. That vector is then correlated with each sample position in the measured traces using the Pearson correlation coefficient.

The result is a correlation surface indexed by key hypothesis and sample position. A successful attack does not merely require a high numerical value; the expected key candidate must separate consistently from competing hypotheses at a physically plausible point in the capture window.

Establishing a known-good analysis path

Before evaluating measurements from the FPGA, the CPA implementation was validated with the reference dataset supplied for the task. This separates software-model errors from hardware-measurement problems. Byte ordering, ciphertext reconstruction, inverse S-box indexing, bit extraction, and correlation all have to agree before the physical experiment is meaningful.

For ciphertext byte 0 and inverse S-box output bit 1, the expected final-round key byte is 0xd0. Its score becomes distinguishable after roughly 2,000 traces.

Recovering the expected candidate from the supplied traces establishes a known-good analysis baseline. The same final-round model can then be applied to the noisier traces obtained from the physical FPGA.

Capturing the final AES round

The FPGA design integrates the AES core, the delay sensor, one block RAM, and a UART transport. The measurement logic is implemented in sense_module.v. A final-round indication from the AES core is synchronized into the sensor clock domain and converted into a bounded capture interval.

On the detected edge, the BRAM write address is reset and capture is enabled. The sensor value is then written once per sensor-clock cycle for addresses 0 through 55. After the final write, capture stops. This produces exactly 56 samples for each encryption without relying on host-side timing.

Once encryption and capture are complete, the design sends the 16-byte ciphertext followed by the 56-byte trace over UART. Keeping the ciphertext and measurement in the same transaction is important: a lost byte or an off-by-one read would associate a trace with the wrong cryptographic output and destroy the correlation.

Bring-up and trace acquisition

Bring-up starts with a known-answer test from NIST FIPS 197. The FPGA must return the expected ciphertext before any trace collection is accepted. The same transaction is also used to verify that 56 sensor bytes arrive and that the sensor is operating away from saturation.

Plaintext:  3243f6a8885a308d313198a2e0370734
Ciphertext: 3925841d02dc09fbdc118597196a0b32

The acquisition program then generates random 16-byte plaintexts, transmits them to the FPGA, and records the plaintext, ciphertext, and sensor trace in CSV files. A small 3,000-trace dataset was first used to verify framing, dimensions, and numerical variation. The final acquisition contained 100,000 encryptions.

python collect_traces.py -n 100000 -o measurements_100k

The measured traces used 56 samples and exhibited low-amplitude variation rather than rail saturation. That operating point is necessary but not sufficient for a successful attack: most of the observed variance may still be unrelated noise.

CPA over 100,000 FPGA traces

The complete hardware analysis evaluated 16 ciphertext bytes, eight inverse S-box output bits per byte, 256 key hypotheses, and all 56 sample positions. This corresponds to 128 independent bit-level CPA experiments.

The expected AES round-10 key was:

abc1d22842e631c999631f6db7805e94

For byte 0 and output bit 4, the expected candidate 0xab produced the largest absolute correlation at sample 8:

Key candidate: 0xab
Correlation:   0.021510
Sample:        8
Trace count:   100000

The other bit hypotheses did not produce stable first-ranked recovery. This result should therefore be interpreted as evidence of detectable key-dependent leakage, not as a full round-key recovery. The distinction matters: reporting one successful bit-level model is more defensible than presenting the maximum of many noisy correlations as a recovered key.

What limited the attack

The dominant limitation was signal-to-noise ratio. An on-chip delay sensor observes an indirect consequence of switching activity, and its response depends on placement, routing, clocking, local supply variation, and the chosen capture window. Only a subset of AES state transitions may couple strongly enough into that sensor to be distinguishable.

The sample positions associated with the strongest candidates also shifted across ciphertext bytes, which is consistent with serialized or time-distributed activity in the implementation. A more extensive attack would treat sensor placement and capture timing as experimental parameters rather than fixed constants.

Improvements would include repeated measurements across sensor configurations, tighter timing closure, multiple sensing locations, trace normalization, and a comparison of bit, Hamming-weight, and Hamming-distance leakage models.

Engineering conclusions

The useful result of the exercise is the complete measurement chain. The final-round event is captured in RTL, sensor values are stored in BRAM, ciphertext and trace framing remain synchronized over UART, and the host implementation evaluates the same leakage model on both reference and physical datasets.

This is the practical boundary between cryptographic correctness and implementation security. The AES core returned the correct NIST test vector throughout the experiment. At the same time, repeated physical observations exposed a statistically detectable dependency on one modeled round-key byte. Correct functionality does not imply resistance to side-channel analysis.

References and implementation

• NIST, FIPS PUB 197: Advanced Encryption Standard (AES).
• FPGA implementation, acquisition scripts, and CPA code