Timeouts when sampling trigger signal

Embedded Security
1

Hello, at the moment I am writing a master thesis where I am exploring FI using the CW-Lite and the PicoEMP. I am targeting a third-party device. I am having some trouble with the CW mechanism that is sampling the trigger signal sent from the target(GPIO pin on target is set high when we enter code we want to glitch).

The problem:

Here are the errors/warnings that are causing me some troubles:

|(ChipWhisperer Scope WARNING|File _OpenADCInterface.py:951) Trigger not found in ADC data. No data reported!|
|(ChipWhisperer Scope ERROR|File OpenADC.py:781) Received fewer points than expected: 0 vs 5000|
|(ChipWhisperer Scope WARNING|File _OpenADCInterface.py:642) Timeout in OpenADC capture(), no trigger seen! Trigger forced, data is invalid. Status: 02

For the last warning I also get statuses: 03, 08 and 88. I tried looking into the CW code, but I were not able to understand what the status codes mean.

Also, the error that says it received fewer points than expected, can have varying numbers of captured points, but most often more than 4000.

Setups
I have two experimental setups:

  1. VFI: CW-Lite detects trigger signal from target(GPIO pin on target is connected to IO4 on CW). The crowbar/glitch output is connected to the decouple line of the targets digital logic. After trigger signal is detected, crowbar is activated.
  2. EMFI: CW-Lite controls the PicoEMP(HS2 on CW is connected to HVP on PicoEMP). CW-Lite detects trigger signal from target(GPIO pin on target is connected to IO4 on CW). After trigger signal is detected, HS2 is set, and PicoEMP is activated. The CW also checks that the PicoEMP is sufficiently charged for a new attack(IO3 on the CW is connected to the CHG pin on the PicoEMP). The CHG pin is checked before the CW starts looking for a new trigger signal from target.

The CW sends a command to the target, and the target will then run the corresponding application to that command. In the following observations a counter application was run.

Observations
For VFI I get more or less none of the above errors while running with a CW freq of 190MHz(maybe 1/1000). While at 200MHz, that number increases significantly.

EMFI is the one that is causing the most trouble. Seemingly independent of frequency of the CW, I can get a lot of the above errors. When I run a glitch campaign with parameters that cause no unusual behavior(normal execution of target application), I get little of the above errors. But when a glitch campaign that can cause resets and successful glitches run, the above errors are prevalent(maybe 1/4). This results in the glitching campaign running quite slow.

I don’t have the exact number of how prevalent each of the independent errors are, but I believe from memory that the “Received fewer points than expected:” error is occurring most. I can provide some numbers if necessary.

Thoughts

As I understand, the ADC of the CW-Lite has a limit of 105MS/s. Could it then be that by running the CW with a very high frequency(200MHz), the ADC will not “keep up”? I guess this is not the total truth, as I have seen forum posts here(by you guys at NewAE) stating that you run your attacks at 200MHz.

For EMFI, it is of course interesting that the ADC seems much more unstable when the target is being reset and glitched successfully. I make sure that the target is reset if no trigger signal is seen(as it could be that the target was reset/locked during the last glitch). Should I always just reset the target? Even if I got a normal/successful response from target?

Considering I get much less errors with my VFI setup than my EMFI setup, could this be the result of the CW sampling signals on both IO3 and IO4 with EMFI? I would guess not, as they are not sampling at the same time.

If anyone have any insights to share I would appreciate to hear them. Thanks!

2

Hi,

This is expected behaviour. All the glitch logic stuff should work at 200MS/s and beyond, but capturing power traces, which is what your errors are related to, isn’t guaranteed to work beyond 105MS/s. Usually devices will have a good bit of headroom above this, but it varies pretty heavily per device and often depends on things like temperature and power supply stability.

This could be talking about the new Husky, which has a 200MS/s ADC, but it could also be talking about things that only use the glitch hardware. We’ve got a glitch example for an LPC1114 bootloader that usually runs the ChipWhisperer at 200MHz.

Alex

3

The definitions are buried in the Verilog here:chipwhisperer/openadc/hdl/hdl/openadc_interface.v at develop · newaetech/chipwhisperer · GitHub

Before getting into the definition of the error bits, I’d try to understand why CW is not seeing a trigger. If you have a logic analyzer or oscilloscope, can you confirm that the trigger is actually occurring? And is it wide enough to be seen by CW (wider than one clock cycle of scope.clock.adc_rate)?

There are two things to consider. First is the ADC itself, which is a discrete chip that’s rated for 105 MS/s. If you care about the quality of the power samples, then going beyond 105 is “at your own risk”. Second is whether the FPGA logic can keep up. When you go beyond its rated frequency, it will start to malfunction at some point. Looks like you run into this when you go beyond 190 MHz. That’s not to say that staying under 190 MHz guarantees correct operation. Sometimes things work correctly beyond the rated clock frequency but that’s not something we can guarantee or support.

Are you able to run your setup at a slower clock? If so then that would make it much easier to iron any bugs out of your setup; once that’s done you can cross your fingers and crank up the clock.

Another option is our new CW-Husky, which is rated for 200 MHz operation: Overview & Comparison - NewAE Hardware Product Documentation

4

Thank you for all the responses! Very useful for understanding the total system even more. Looks like I found the problem, unfortunately nothing more interesting than sloppy code…

With my VFI setup I had set scope.clock.adc_src = "clkgen_x1". While for my EMFI setup this was not done, so instead the default value of "clkgen_x4" was used. Then, when setting scope.clock.clkgen_freq to lower values, I had a higher scope.clock.adc_rate than what I thought. Also when the frequency was set high enough, say 150MHz, the resulting adc_rate became very low(about 0.1MS/s). I guess this comes from some sort of overflow.