Cannot get the accurate figure

[Qtarox]

Sorry to bother you again. We have some little trouble when doing the step of 'Configure Trace Collection'. According to your experiment's results, we should be able to see an obivious AES trace in the figure. However, we can just get the fig shown as above. As you can see, the first subplot is quite different from the right one, and the average of 100 traces is wrong too.

I would be grateful if you can help to solve this problem. Thank you!

[Qtarox]

And to achieve a better performance, I made some change in the config file below: { "firmware": { "mode": "tinyaes", "fixed_key": true, "modulate": true }, "collection": { "channel": 0, "hackrf_gain": 0, "hackrf_gain_if": 40, "hackrf_gain_bb": 32, "usrp_gain": 40, "target_freq": 2.528016205e9, "sampling_rate": 5e6, "num_points": 1, "num_traces_per_point":200, "bandpass_lower": 1.86e6, "bandpass_upper": 1.94e6, "lowpass_freq": 9.5e3, "drop_start": 0.44, "trigger_rising": true, "trigger_offset": 90e-6, "signal_length": 300e-6, "template_name": "templates/tiny_anechoic_5m.npy", "min_correlation": 0.00 } }

And I got the plots as below, which is still much worse than yours(espacially the first subplot): However, my antenna has to be put very close to the development-board(about 2 cm),
Here, I have two questions:

1. How can I make my images as precise and clear as yours?
2. How can I achieve accurate long-distance measurement?

I would be grateful if you can help to solve my problems. Thank you!

[giocamurati]

Hi @Qtarox

I am happy you managed to get something with the last configuration!

There is one thing I would like to make sure before going on with other hypothesis/idead, that is, transmission power. Did you set it manually to 4dBm?

If not, the default in the code is 0dB in the code (main.c:92 static uint8_t txpower_ = RADIO_TXPOWER_TXPOWER_0dBm;)

So, if you did not set the power to 4dBm manually, could you please try to run the sc-experiment code with the --max-power option? It will simply make sure to send p0 to the device before collection.

Of course, it is also possible that the nRF52840 leaks less than the nRF52832-based chips that we use. In that case, for similar distances you will need a better setup. To start, I would suggest:

1. Using a connection via cable to measure the leakage, compare it with the nRF52832, find optimal configurations without much trouble.
2. Using an external low noise amplifier before the SDR.

Some attack setups (often with images) are shown in our papers: CCS18 with BLE Nano v2 CHES20 with BLE Nano v2 and PCA10040 and also in this recent paper with a PCA10040 https://eprint.iacr.org/2020/1096.pdf There are also some examples of LNA models we used in the guide.

Out of curiosity, what do you see at 2.400GHz (adjusting the gain, the carrier there is stronger)?

EDIT: Another thing we can try: Could you please set the repetitions to a smaller number, and show me a zoom of the signal in the first plot? Maybe we can further improve the filters and template for extraction even with the current leakage.

[Qtarox]

In the experiment, I have already set the power of nRF52840 to the max value. And thank you very much for your suggestion. We will make corresponding improvements and contact with you later. Thanks again.

[giocamurati]

No problem. I think we a bit of tuning attacks are possible though not as easy as on the nRF52832-based chips. This recent paper at CCS2020 https://dl.acm.org/doi/pdf/10.1145/3372297.3417241 might interest / be useful for you regarding the nRF52840

[Qtarox]

This is first plot when the repetition is set to 10 times. By the way, is this part of the code generating trigger siganl?

[giocamurati]

Hi,

In your picture I can clearly see the packets, but could you please zoom on one of them to see the encryption more clearly?

Anyhow, in your picture you can already see the (small) spikes of the trigger signal (in orange) corresponding to the beginning of the encryptions. This trigger signal (orange) is computed by simply amplitude demodulating one frequency component that appears at the beginning of the encryptions.

The code that does that is https://github.com/eurecom-s3/screaming_channels/blob/master/experiments/src/screamingchannels/analyze.py lines 68-73

    trigger = butter_bandpass_filter(
        data, config.bandpass_lower, config.bandpass_upper,
        config.sampling_rate, 6)
    trigger = np.absolute(trigger)
    trigger = butter_lowpass_filter(
        trigger, config.lowpass_freq,config.sampling_rate, 6)

How to chose the frequencies for this step? Look at the second plot (the spectrogram). There you can visually observe some frequency components that can be used as trigger (there is an annotated image in the guide).

In your case, in your config you selected

"bandpass_lower": 1.86e6,
"bandpass_upper": 1.94e6,

Look at what it corresponds in the second plot, and adjust if necessary.

With

"lowpass_freq": 9.5e3,

you further low pass the frequency component you selected. You can adjust this too.

By playing with these three values, you will change the orange signal. As of now it already shows some spikes. Maybe increasing a bit the low pass frequency will give you higher spikes.

You may want to decrease this a bit too to be sure to see all 10 encryptions.

"drop_start": 0.44,

Then, we need a threshold to detect the spikes. That is computed here:

    start_idx = 0
    average = np.average(trigger[start_idx:])
    maximum = np.max(trigger[start_idx:])
    minimum = np.min(trigger[start_idx:])
    middle = (np.max(trigger[start_idx:]) - min(trigger[start_idx:])) / 2
    if average < 1.1*middle:
        print ""
        print "Adjusting average to avg + (max - avg) / 2"
        average = average + (maximum - average) / 2
    offset = -int(config.trigger_offset * config.sampling_rate)

In the first plot, this is the yellow signal. As you can see, it falls above the lower values of the trigger, but below the spikes.

The code you pasted just computes the intersections between the orange and the yellow signals to find the index of the spikes. If you set

"trigger_offset": 0e-6,

you will see the red bar at the intersection between orange and yellow signals.

Then you can adjust

"trigger_offset": 90e-6,
"signal_length": 300e-6,

so that the red and green bar enclose an encryption. With the current zoom I cannot see well if this is ok in your plot.

[Qtarox]

Thank you very much! And I will apply the changes to my config file.

[giocamurati]

No problem, I hope by playing with the config parameters you can get a clean extraction.

I just remembered one thing. If you run the collection with the --raw option you can save the raw IQ data corresponding to the figure you sent me (it will be saved as "raw_0.npy" in the output folder). Sharing that will be easier than sharing only the picture.

[giocamurati]

One last thing:

Maybe you can start with a continuous wave instead of packests:

"modulate": false

It will make it easier to see the encryptions

[Qtarox]

OK, and if there is any progress in the follow-up, I will contact you immediately Thanks again!

[Qtarox]

Hi, I have changed the configuration, and the waveform is much better now. { "firmware": { "mode": "tinyaes", "fixed_key": true, "modulate": true }, "collection": { "channel": 0, "hackrf_gain": 0, "hackrf_gain_if": 40, "hackrf_gain_bb": 32, "usrp_gain": 40, "target_freq": 2.528016205e9, "sampling_rate": 5e6, "num_points": 1, "num_traces_per_point":100, "bandpass_lower": 1.818e6, "bandpass_upper": 1.92e6, "lowpass_freq": 4.9e3, "drop_start": 0.442, "trigger_rising": true, "trigger_offset": 122e-6, "signal_length": 300e-6, "template_name": "templates/tiny_anechoic_5m.npy", "min_correlation": 0.04 } } When I turned the modulate off, the waveform is as below:

and when I turn the modulate on, the waveform is :

However, I found that my spectrum graph is not as clear as yours. And I'm not sure if this is due to noise. Do we have to do the experiment in a noise-free environment？

And I don't understand how to find the right trigger_offser and signal_length, which are important for the alignment of traces. I would be grateful if you can tell me. Thanks!

[giocamurati]

Hi,

Nice, I see the the improvement!

Here are some answers:

1. I think the main problem is the signal is weaker on the nRF52840 than on the nRF52832. Going in a noise free environment could improve a bit. But I would suggest first to try: an external amplifier, different antennas and probes, and/or a connection via cable.
2. First, select trigger_offset to 0 and look at the position of the vertial red bars compared to the beginning of the trace. Then strat increasig trigger_offset to make the red line move, until it falls before the key schedule. Then, increase signal_length until the green vertical line falls after the end of the first round. Actually, I suggest you try to make it fall after the end of the last round. A longer signal might improve the alignment.

Another important point:

As now you modified the configuration a bit, and as you are on another chip model, using "templates/tiny_anechoic_5m.npy" is maybe not optimal for your case. That will be the case also if you change the length of the signal. You can try to generate a new one by running the --average-out "/path/templates/my_template.npy" option. The you can replace "templates/tiny_anechoic_5m.npy" with "templates/my_template.npy".

Note that if none is specificed "template_name": "", the first extracted trace will be used as baseline to align the other traces. The very first time you could try to set the template to "", extract only one or two traces (so no alignement problem), generate the tempalte with --average-out, then set that template, then increase the number of traces.

[Qtarox]

Hello！ I found out the cause of our problem. It is casued by the chip nRF52840 itself, the power of which is much smaller than nRF52832. Now, I have changed the chip and the traces is much better.

Thank you very much for your help!

[giocamurati]

Hi @Qtarox !

Thanks for letting me know! I am happy that you are now able to acquire good traces.

[giocamurati]

(Since collection works for both the nRF52840 and nRF52832, though the SNR is not very good on the former, I will close this issue)