Trigger not found in ADC data. No data reported!

Hi,

Running the PA_DPA_3-AES_DPA_Attack script on the XMega board I get the following warning when capturing traces, “Trigger not found in ADC data. No data reported!”. The script also fails to read the correct key. Only 2 or so bytes are correct.

Any help is appreciated.

Best regards,
Tom

Hi Tom,

Ah sorry I had a draft response I never hit “submit” on.

Is it happening on every iteration?

This normally happens if some problems with synchronization. Do the other examples capture oK (like the CPA example)?

-Colin

Hi Colin,

It doesn’t happen on every iteration. I just ran it and it happens on 25 out of 750 iterations.

I ran “Using CW-Analyzer for CPA Attack” and I didn’t see any errors or warnings.

Thanks and regards,
Tom

Hi Tom,

Alright thanks - hmm that is a little odd! FYI - the DPA attack on the XMEGA isn’t as reliable ( we had added a note to that effect at some point - you can see it online beside the supported platforms at https://github.com/newaetech/chipwhisperer-jupyter/blob/master/PA_DPA_3-AES_DPA_Attack.ipynb).

This might be a but with some specific settings of scope.adc.offset or similar. If you try bumping it around a bit does it still happen? Also if you can increase the scope.adc.samples (say set it to 3000) might help understand if it’s just some borderline problem.

Thanks,

-Colin

Hi Colin,

Thanks for your help. I tried scope.adc of 3000 and it still gives the same warnings, and it still does not get the correct key.

We have the lite 2-part board. Can you direct me at a target board that we can use that works for this attack?

Thanks and regards,
Tom

Hi Tom,

For some reason this attack works well on the arm boards. The CW308T-STM32F3 board for example is the normal one we use (which is same chip on CWLITEARM target). The CW308T-STM32F3 requires a base-board however, it doesn’t plug directly into the CWLITE Capture side.

The quick solution is if you pick up a CW308 Kit (part number NAE-CW308-04), this includes an CW308T-STM32F3 target with the “UFO Baseboard”. You can then run the build as the “CWLITEARM” (the CWLITEARM includes the same target as the STM32F3 target board).

Will try to replicate the no data message. Not sure why you see it there but not in other tutorials, could just be a problem with the firmware or something not sending trigger out as expected (but it should be the same firmware even between the DPA & CPA attack).

Thanks,

-Colin

Thanks Colin. We will look into purchasing the suggested board. Will this board work on all of the sample attacks?

Best regards,
Tom

Hi Tom,

Yes - the UFO board basically supports almost all sample attacks - it works a lot better with the glitching tutorials as well (in our experience).

As it has both the XMEGA & STM32F3 you can do tutorials that only work on Arm or XMEGA respectively. If you want to perform a hardware AES attack, you need an additional target such as the CW308T-STM32F4HWC (which has a hardware AES accelerator, the “normal” included targets don’t for export compliance reasons).

-Colin

Thanks Colin.

Best regards,
Tom

Hi Colin,

Is there a single part board that we can swap this one with instead of having to purchase an additional board?

Thanks and regards,
Tom

Hi Tom,

The single-board solutions have either the XMEGA or STM32F3 targets. Either way you’ll have some (but not all) tutorials possible - if you’ve got the 2-part now for example you can do the SPA attack on RSA that you wouldn’t be able to do with a STM32F3 board (NAE-CWLITE-ARM). With the 2-part you can later connect to external targets, so it has the advantage over the single-board solutions there.

We can check into the DPA attack on the XMEGA with your setup - it should work eventually but with more traces (it was working at one point for sure).

Thanks,

-Colin

Hi Colin,

Do you have a chart that shows which boards work on which attack?

Thanks and regards,
Tom

Hi Tom,

There is a (somewhat outdated) list at https://chipwhisperer.readthedocs.io/en/latest/tutorials.html but it doesn’t have some of the newer tutorials.

Also - I checked the DPA on an external XMEGA target. I think I’ve figured out what happened (and will update tutorial with more details). First, I think the compiler version may have changed which slightly affects the code location. This makes some of the defaults non-ideal.

Here i adjusted the scope.adc.offset and scope.adc.samples. On my board I noticed some clipping of the power waveform so reduced the gain (the max value is +/- 0.5 on the waveform). If you didn’t see clipping don’t adjust gain down (I was using UFO board and not the 2-part version, so the resistor is a little different):

elif PLATFORM == "CWLITEXMEGA" or PLATFORM == "CW303":
    scope.gain.db = 25
    scope.adc.samples = 2000
    scope.adc.offset = 2300
    N = 5000

The second change comes in the analysis section. Find this code:

    for tnum in range(numtraces):
        if (intermediate(textin_array[tnum][subkey], kguess) & 1): #LSB is 1
            one_list.append(trace_array[tnum])
        else:
            zero_list.append(trace_array[tnum])

That block needs to have a “window” that blocks out some of the early signal for later bytes. Basically we are seeing some ‘ghost peaks’ that are confusing the algorithm. If you run the attack with only updating the offset & sample number (leaving block above as-is), you can do the plots to see the peaks for bytes 0,1,…15. We actually want to window around some of those peaks. I took a bit of a guess at the windowing locations, I found moving ahead by 50 samples worked fairly well for each byte.

    for tnum in range(numtraces):
        if (intermediate(textin_array[tnum][subkey], kguess) & 1): #LSB is 1
            one_list.append(trace_array[tnum][subkey*50:])
        else:
            zero_list.append(trace_array[tnum][subkey*50:])

It wasn’t perfect still, I think the window isn’t actually ideal (I just ballparked the number). The “ghost peak” problem is fairly well-known, see for example https://eprint.iacr.org/2005/311.pdf .

-Colin

Hi Colin,

Thanks for your help. I tried your code changes. It still does not get the correct key, but it is much better than before. It fails to get 4 of the bytes, where before it only got one or two. Do you think we can eventually get a reliable way of getting a key on this attack for the XMEGA?

Thanks and regards,
Tom

Hi Tom,

Yup - should work fully! It needs more tuning on the window most likely - I’m going to work on updating that lab to explain how to do that (rather than just throw some “good numbers” in magically).

So will take a bit longer, but you can see with that change even how it made a much bigger difference!

-Colin

Hi Colin,

That sounds good. Please let me know when the new lab is ready.

Thanks again for your help.

Regards,
Tom

Hi Colin,

We are trying to determine how to connect our board to CW. I don’t see any information on the 2-part board. Could you please direct me at any documentation on how we can do this?

Thanks and regards,
Tom

Hi Tom,

Which board are you trying to connect to the ChipWhisperer? The pinout can be found here if you’re trying to connect to an external board. The CW308 has another 20pin connector on it that you can connect to the Lite via a 20pin cable if you’re using that. See the following picture for an example (replace the CWPro with the Lite):

Hi Alex,

Thanks for your help. We are trying to connect one of our parts to the CW-Lite 2-part board. What is the other connector? And, are there any instructions or specifications on how we can build our board for our chip?

Thanks and regards,
Tom

Hi Tom,

We’ve actually got a tutorial that uses a microcontroller dev board as a target that should be useful: https://wiki.newae.com/Tutorial_A9_Bypassing_LPC1114_Read_Protect. The CW308 platform is another example: https://wiki.newae.com/CW308_UFO_Target

In that case, this pinout tells you what each of the pins on the 20 pin connector does (power out, ground, communication lines, etc). You’ll also need an SMA connector on the other board for voltage measurement and/or glitching. The board will require the following:

  • 20 pin connector following the pinout linked earlier
  • Shunt resistor between V+ (3.3V from CW or regulator output) and Vcc of microcontroller
  • SMA connector connected to low side of shunt resistor
  • Capacitors only on high side of shunt resistor
  • A shared clock between the ChipWhisperer and the target. The ChipWhisperer can either output a clock or take one as an input.
  • All IO voltages need to be 3.3V

Of course, you also have the option of making a CW308 compatible board with a shunt resistor. See: https://wiki.newae.com/CW308T-STM32F for an example of a CW308 compatible board.

@coflynn Feel free to chime in if I’m forgetting anything.

Alex