---
title: 'ChipWhisperer-Lite: Side-Channel Analysis Tool'
url: https://www.emergentmind.com/topics/chipwhisperer-lite
type: topic
---

# ChipWhisperer-Lite: Side-Channel Analysis Tool

ChipWhisperer-Lite is a specialized, low-cost hardware platform designed for side-channel analysis and fault injection, with documented applications in evaluating cryptographic implementations against physical attacks. In "Simple Power Analysis of Polynomial Multiplication in HQC" [2601.07634], the ChipWhisperer-Lite was employed to mount and evaluate a single-trace Simple Power Analysis (SPA) attack against the Hamming Quasi-Cyclic (HQC) cryptosystem—a scheme selected for the fourth round of the NIST Post-Quantum Cryptography (PQC) standardization project. The attack exploits power consumption leakage during polynomial multiplication routines in HQC decryption, using only standard ChipWhisperer-Lite hardware and open-source implementations.

## 1. Hardware Architecture and Experimental Setup

ChipWhisperer-Lite comprises two primary components: a main board ("scope") that captures and digitizes leakage signals, and a target board that executes the cryptographic algorithm. The experiment utilized the unmodified CW-Lite Rev. 5.x main board featuring a 12-bit ADC configured at 7.38 MHz, an on-board clock generator (clkgen) synchronized to both ADC and target system clock, and a low-noise amplifier (LNA) set to 24.84 dB gain. Communication with the host PC is established via a USB2 interface (Cypress FX2), running the ChipWhisperer Python API for acquisition and processing.

The target device is an STM32F303 (ARM Cortex-M4, 32-bit), programmed with the PQClean "Additional" HQC implementation. Power measurements are obtained through a small shunt resistor on the VDD line, routed into the scope’s ADC via the LNA. During each attack attempt, 7,500 ADC samples are acquired at 7.38 MHz, yielding a trace length of approximately 1.02 ms per decryption invocation. No modifications or supplementary filtering are introduced to the hardware beyond standard decoupling and probe attachments.

| Component            | Feature                 | Configuration/Comment                     |
|----------------------|------------------------|-------------------------------------------|
| Main board (scope)   | 12-bit ADC             | 7.38 MHz, full scale ±500 mV, ≈10 MHz BW |
| Target board         | STM32F303 Cortex-M4    | PQClean HQC implementation                |
| Signal path          | Shunt resistor (VDD)   | LNA probe input, no additional filtering  |

## 2. Measurement Methodology

The methodology involves full-trace acquisition for each HQC decryption event, without hardware pre-trigger or custom synchronization. The process is as follows:

1. The target is flashed with the HQC decryption firmware.
2. A ciphertext (u, v) is supplied via UART or GPIO to initiate decryption.
3. The main board captures the entire multiplication interval in a buffer of 7,500 samples.
4. Raw traces are transferred to Python scripts for post-acquisition cropping and analysis.

Since byte-cycle boundaries are not explicitly triggered, manual alignment and cropping are required. The operator identifies the offsets for each iteration of the base-case multiplication (Karatsuba routine) by eye or using a script parameter, segmenting the trace into regions corresponding to each 4-bit nibble processed in the algorithm.

No analog or digital filtering, averaging, or template matching is applied beyond inherent LNA amplification. Each trace is processed individually using peak identification algorithms.

## 3. Leakage Modeling and Side-Channel Extraction

Power leakage is modeled using textbook CMOS dynamic power consumption:

\[ P(t)\;=\;\alpha\,C\,V^2\,f \]

where $\alpha$ is the switching activity, $C$ is load capacitance, $V$ is supply voltage, and $f$ is operating frequency. The leakage correlates with the Hamming-weight or Hamming-distance when accessing lookup tables during polynomial multiplication. For the address $u[i]$, the leakage is approximated as:

\[ L(i)\;=\;\mathrm{HW}(u[i]) \;\approx\; \text{leaked amplitude at iteration }i \]

The relevant multiplication code executes a loop:

```
for j=0…15:
    tmp2 = (tmp1 – j)
    mask = (1 – ((tmp2|–tmp2)>>63))
    g ^= u[j] & mask
```

Only on the active iteration ($j = \text{tmp1}$) does the XOR operation affect the output; all others are masked no-ops. SPA identifies which iteration is active based on the distinguishing drop in leakage amplitude ("peak").

The practical extraction uses SciPy's `find_peaks` function within the following pseudocode (as supplied):

```python
function recover_key_nibbles(trace):
    for nibble_index in 0..15:
        segment = trace[offset[nibble_index] : offset[nibble_index]+window]
        peaks   = find_peaks(segment)
        // look for the first “drop” between adjacent peaks
        for k in 1..(len(peaks)-1):
            if peaks[k].amplitude - peaks[k+1].amplitude > Δ:
                recovered[nibble_index] = k
                break
    return concat_nibbles(recovered)
```

A plausible implication is that the trace segmentation and amplitude-difference threshold are critical for successful single-trace extraction, as the entire attack relies on isolating the correct peak among dummy rounds.

## 4. Experimental Results and Performance Metrics

Testing over 10,000 random instances yielded a 99.69% success rate (31 failures), with all failures occurring at the first nibble (bits 0–3) and only for true values 0 or 15; the remaining 15 nibbles were always recovered. The attack operates in approximately 2 ms per decryption (capture and analysis), resulting in about 20 seconds for 10,000 traces. No explicit SNR or correlation metrics are given, but the peak signature offered unambiguous classification of 4-bit values.

| Metric            | Reported Value        | Context/Comment                          |
|-------------------|----------------------|------------------------------------------|
| Success Rate      | 99.69% (10,000 cases)| Failures only at first nibble, value 0/15|
| Trace Duration    | ~1.02 ms (capture)   | 7,500 samples @ 7.38 MHz                 |
| Attack Time       | ~2 ms/decryption     | Includes script processing               |

A plausible implication is that practical attacks can be repeated on failing segments to achieve near-perfect recovery, given constant-time performance.

## 5. Configuration Insights and Methodological Considerations

Sampling rate and gain settings are tightly coupled to attack efficacy. The 7.38 MHz ADC rate permits resolution of the 16-loop structure (~200 kHz per iteration); lower rates may induce peak blurring. Optimal LNA gain (~25 dB) provides clean separation of active versus dummy peaks, suggesting practitioners should tune gain incrementally to avoid ADC saturation.

Triggering remains a methodological challenge: in absence of hardware pre-trigger (e.g., GPIO), manual calibration of cropping windows is mandatory and requires per-build adjustment. Though only demonstrated with gcc -Os, varying compiler optimization levels or alternative libraries may shift timings but do not mitigate vulnerability. In code, any constant-time loop iterating through all table entries (masking) leaks the active index unless dummy iterations are removed or the loop order is randomized; proper defense calls for index masking or permutation.

## 6. Generalization and Reproducibility

The documented attack, hardware configuration, and methodology are sufficient for direct replication using ChipWhisperer-Lite and the PQClean HQC implementation. The experiment demonstrates that SPA can compromise polynomial multiplication routines with negligible equipment modification or setup complexity. A plausible implication is that similar side-channel attacks may apply to a wide class of cryptographic routines that manifest iterative, index-dependent memory access patterns, especially absent robust algorithm-level masking or randomization.

Source: https://www.emergentmind.com/topics/chipwhisperer-lite