Some problems while breaking ECC using CW-Lite and CW305

Embedded Security ChipWhisperer Hardware
1

Hello everyone,
I am a student who has just started learning about side-channel attacks. Recently, I received the CW-Lite and CW305, and I tried to break AES with good results. However, when I used the SCA204 course to attack ECC, I encountered some problems and would appreciate any answers.

When I used one trace to differentiate between zero and one, I observed several peaks(as shown in the figure below), which were consistent with the results of the provided pre-recorded traces.

bokeh_plot avg
bokeh_plot avg6000×1800 485 KB

When I further captured 30 traces to distinguish k bits that are ones from k bits that are zeros, I found that increasing the number of traces did not result in a “smoother" output. In the figure below, the blue line represents the result using just one trace, while the green line uses 30 traces. The lines are almost identical, which prevented me from successfully recovering the key in subsequent experiments.

bokeh_plot1
bokeh_plot16000×1800 916 KB

bokeh_plot30
bokeh_plot306000×1800 626 KB

Additionally, I found some issues in the SCA204 part 1 tutorial while using CW-Lite and CW305:

  1. In the get_traces function of CW305_ECC_setup.ipynb, the wave variable is not defined before it is used;
  2. The length of the wave collected using CW-Lite exceeds 1130000, causing the get_sums function in CW305_ECC_part1.ipynb to output incorrect results.

I have fixed the above issues in Jupyter, but it still does not work properly. I look forward to your response.
Li

2

I think I made a simple mistake. This mistake was related to the first issue where the wave variable was not defined before use, and I defined it in the wrong place, resulting in different captures returning the same wave. I corrected this mistake, but the results still seem insufficient, so I’m continuing to work on it.

By the way, I discovered another issue in the code. When using the target.capture_trace function on CW-Lite, if as_int=True is used, the returned data is in a floating-point format, like 349., which seems to require adjustment.

3

I have resolved this problem. I compared the current source code with Problem using offset to capture long traces and found that two lines were missing.

scope.adc.offset = 0 
wave = np.array([])

After I added them, the program ran very well.

1 Like
4

Thank you for the feedback, I will make the corrections! I’m not sure how or why this got broken, thank you for figuring out the problem and reporting the solution.