Are my traces jittery?

Hey guys, sorry for the spam but I am struggling really hard with this. I run 700 traces of aes simpleserial on cw308 board and record stuff with my oscilloscope (triggering is set to gpio4 and sma cable into j17). I can see the trigger on my oscilloscope view, even the aes rounds, although when I analyse that with CW Analyzer or the integrated Lascar, I get no correct result. Using the HS2. Could you tell me what I might need to check?

I used 3bit noise reduction here so you can see the rounds

here is the notebook 10 waveforms printed

With asynchronous sampling, you’ll always have jitter. That’s why the ChipWhisperer capture hardware using synchronous sampling. Have a look at

What sampling rate are you using on your oscilloscope, and what is your target’s clock rate? It may be that you need more traces. Is the attack guessing some key bytes correctly, or none at all?

Im using the CW308 Target Aurix TC233LP chip, measuring over SMA to BNC cable and trigger is measured on GPIO4 and the HS2 on J3 is set, maybe I should use the crystal setup? The target clock rate is around 7-8 Mhz. I wont have synchronous target in the future I guess, so learning on how to deal with asynchronous sampling would be helpful.

Im using real time sampling rate of 50MS/s with timebase mode on 100us, which yields 50k samples at 50MS/s, 20ns/pt for 1ms. Clock source on my oscilloscope is set to internal. The bandwidth on data channel is 100Mhz, AC Coupling with 1Mohm

I tried with many setups and a setup with 2bit noise filter guessed few keys correctly, but it may be just random luck, Ill check that again. Other setups I described in the post yielded no reasonable results.

Have a look at the paper I linked above. 50 MS/s is not much so it’s not surprising that 700 traces are not enough. Increase the sample rate if you can; otherwise try with a lot more traces. Changing to the crystal won’t help. For the attack, make sure that you’re only using the subset of samples when the IO4 line is high.

what do you mean with the last sentence? should I only record the samples where the first aes round is computed (after the trigger on aes simpleserial)? shouldnt cpa work even if I record much more, since it compares every sample with the theoretical data? I will try increasing the sample rate

Yes, CPA should work even if you feed it more data before/after the target operation. But the more data you throw at it, the longer it will take to crunch through all that data. Try it for yourself! :wink:

Hi, I zoomed in for the 1st round. Did 2000 trace recordings with a sample rate of 200MS/s and 200k samples, yet no reasonable result. The CWPro is using synchronous sampling, thats the reason why it works with few samples and low sample rate right? Do you know what could I improve aswell? Would recording in a sequence be better than real time sampling?

1- read the paper
2- you mentioned noise reduction; I wouldn’t do that since it may well eliminate the small changes that the CPA attack needs to succeed.
3- repeating my previous question: is the attack guessing some key bytes correctly, or none at all?
4- what leakage model are you using?

the attack is guessing no keys at all, once it found 3 key bytes when 2bit noise reduction was added, but it may be luck. I tested it even without noise reduction and no results at all. Im using the sbox leakage, it works perfectly over CWPRO. When I switch to an external oscilloscope, it doesnt work anymore. I just record the traces, transfer them to my PC, create a numpy array out of them in float64 type, rename the numpy file to the one from my actual project traces name, then I go to the folder with my traces and replace the current traces recorded by cw to the ones I just created with my scope, then I reopen the project (it loads the traces), I checked and plotted some waveforms and they look just as the ones from my scope, and then I use the analyzer to analyse and get no reasonable results (the analyzing process works fine)

Sounds like an issue with your scope?
I’d definitely stay away from noise reduction.
Maybe try more traces and higher sampling rate.
Resynchronizing your traces may also help; have a look at the material in the sca201 notebooks to see how to do this with ChipWhisperer.

I know noise reduction on recording layer may be not the best solution, but I tried it with 2bit noise reduction and its working better. I recorded 700 2000 and 5000 traces and the got almost all keys at 5000 traces. Maybe I am reducing some disruptive noise there by mistake? Can my SMA cable be faulty? I dont think its the scope.

Current setup:
Bandwidth 100Mhz
5000 traces
2bit noise reduction which is -3dB @ 5.800 MHz
100k samples
200MS/s sampling rate

recovered key bytes 14 out of 16

Seems like the noise reduction worked somehow, but at 3bit noise reduction I get no result at all and with no noise reduction I get no result either.

I tried resynchronizing with the two methods, although none of them yielded better result.

So you’ve proved that synchronous sampling is better than asynchronous sampling!

5000 traces feels quite high, but at least you’re getting some success. In theory you should be able to achieve better results, but maybe that’s the best you can get from your scope? If you read the paper I’ve linked you’ll see results for a Picoscope 6403D.

Resynchronization can be hard to get right. Do the resynchronized traces look properly aligned?

I got a 12bit 2GS 400mhz lecroy scope, idk if its that bad? I heard of the picoscope, whats the biggest advantage of that scope over standard scopes?

I tried using the SAD resynchronization which is faster than time warp, since doing the time warp for 5000 traces takes ages.

How can I sample synchronously then? I know asynchronous needs more sampling rate, but I also wonder why does the noise reduction work here? Thats the biggest mystery right now, since I got nice results for 700 traces with only 50MS sample rate at asynchronous clock. So maybe if I extend it to 5000 traces Ill get the same result on 50MS as I got for 200MS, therefore increasing the sample rate wasnt the solution here?

The attack here worked only when I activated noise reduction, which makes no sense to me, since clear recorded signal should always be better due to more information, do you know what could be the reason for that?

With ChipWhisperer capture hardware, of course! Or, with an oscilloscope which allows you to provide its sample clock (I don’t have any recommendations for one).

I can’t help you further other than emphasizing my recommendation to disable noise reduction. Side-channel attacks work due to tiny differences in power consumption. I wouldn’t trust a noise reduction function to not mess that up, even if you did get better results with it.

Good luck!

thank you for the hints. I know its not the best idea to use noise reduction while recording, although it worked here and without it I wouldnt get any solution. Im just wondering what was the cause of that? Do you know any good methods or does CW provide such methods of noise reduction for given waveforms, if I record it without noise reduction and would like to add it later?

No, CW doesn’t have any noise reduction functionality.

A quick google search shows that others have looked into this, so if you want to pursue this I recommend you start from there: Noise Reduction in Side Channel Attack Using Fourth-Order Cumulant | IEEE Journals & Magazine | IEEE Xplore

hey, thanks. Currently the solution was to use noise reduction, but I wonder why do I get noise at all? When I record stuff with the CWPRO I get some clean traces where you can see the AES round, although with the scope I see just noise and when I use a noise reducing function I get to the point where I can see AES rounds. On CW I usually set scope.db to 20, when I had too much gain the signal was also too noisy, is this some kind of noise reduction option? That my scope might gain too much? Or can my SMA cable be broken somehow? Since the signal I got with noise reduction was 10 times smaller than the noisy signal.

Also if noise reduction is not a good option since I may delete some precious signals, then what would be a solution to this? Record few thousands more of traces? Somehow I need to get to the signal, but how?

From our documentation, scope.gain.db is:

 |      The gain of the ChipWhisperer's low-noise amplifier in dB. Ranges
 |      from -6.5 dB to 56 dB, depending on the amplifier settings.
 |      :Getter: Return the current gain in dB (float)
 |      :Setter: Set the gain level in dB
 |      Raises:
 |         ValueError: if new gain is outside of [-6.5, 56]
 |      Examples::
 |          # reading and storing
 |          gain_db = scope.gain.db
 |          # setting
 |          scope.gain.db = 20

You can get this either at Scope API — ChipWhisperer 5.6.1 documentation or by typing help(scope.gain) in a notebook.

As I said earlier ChipWhisperer has no noise reduction capability.

Do check that your gain is set properly, i.e. no clipping observed and reasonably good use of the available dynamic range, in other words the gain is neither too high nor too low. For ChipWhisperer, that means having the peaks of the trace approaching +/- 0.5. For your external scope you’ll have to consult its documentation.