Cannot observe the leak described in CCS18 paper Figure 12

[itewqq]

Hello, I am trying to reproduce your work in nordic nrf52840 pca10056, with a HackRF SDR. I made two nrf52840 bluetooth chips communicate with each other on a fixed 2.404GHz channel, and tried to get the leak situation illustrated in Figure 12 in your article, but nothing was found on the leaky frequency band mentioned in your article, which is 4.868Ghz=2*2.402Ghz+64Mhz.

In addition, when I observed the Bluetooth communication waveform, I found that the available frequency of each channel is very wide (22Mhz), so I also wonder how you got a sharp spike image on the frequency map.

I will be very grateful if you can answer my questions, thank you!

[giocamurati]

Hello,

Thank you for your interest in Screaming Channels!

I think the problem is due to the fact that Figure 12 was taken with a different setup. The easiest way to observe a screaming-channel leakage is to ask the device to continuously transmit a continuous wave at a given channel, while executing some software pattern. That is what we did in Figure 12, and that is why there is a single spike instead of a modulated signal over a larger bandwidth. Once you have a working setup and you can see the leakage on a continuous wave, you can start looking at real modulated packets or even real communications (CHES20 paper). In the last two cases it is harder to observe the leakage at the naked eye on the live spectrogram and it is easier to use the reception code (then plotting the results).

Therefore, I suggest you to follow this part of the guide https://eurecom-s3.github.io/screaming_channels/#TheSimplestExperiment that will lead you through the steps of first testing a continuous wave, and then extracting AES traces while transmitting real packets.

At this point, you can also try to look at two chips communicating on a fixed channel as you are trying to do.

We did a similar thing in the CHES paper. There the channel was not fixed (hopping enabled), but we used the channel map to reduce the number of channels to 2. To extract AES encryptions from real communications between two devices with hopping enabled you can follow this part: https://eurecom-s3.github.io/screaming_channels/#chess2020_traces_4.2

Since you are working on the PCA10056, you need to slightly adapt the code for compilation. It should be enough to replace PCA10040 with PCA10056 in FirmwareD (https://eurecom-s3.github.io/screaming_channels/#Firmware) Change

CFLAGS += -DBOARD_PCA10040
ASMFLAGS += -DBOARD_PCA10040

to

CFLAGS += -DBOARD_PCA10056
ASMFLAGS += -DBOARD_PCA10056

in the Makefile.

Please let me know if this answered you questions and if it helped you observing the leakage and extracting traces.

[itewqq]

@giocamurati Thank you very much for your reply! I will try to adapt the firmware you mentioned. But I am still curious how to do "ask the device to continuously transmit a continuous wave at a give channel." Is this achieved through hardware changes, or is it possible to implement this operation through programming? I am not an expert in Bluetooth, so if you can explain in more detail I will be very grateful!

[giocamurati]

Sorry I had not explained that in detail.

In general, radio transmitters chips offer a test mode to transmit a continuous wave. This can be very useful during testing. This is a hardware feature that can be enabled in software for testing. The nRF SDK has some functions for that.

We developed an example (e.g., FirmwareD) in which we can control the radio (e.g., turning on and off a continuous wave, turning on and off real packets) and run encryption (e.g. TinyAES). Commands are sent through a UART interface.

In the first experiments, you can connect to the chip and issue the commands by hand, there is a small menu. For example, to turn on the continuous wave you can press 'c' and 'e' to turn it off. You can choose channel frequency e.g. with 'a00' (2.400GHz). And the power e.g. 'p0' for 4dBm. (More details are here https://eurecom-s3.github.io/screaming_channels/#TheSimplestExperiment)

For the initial experiments with the continuous wave, it might be better to connect the HackRF to the PCA10056 via a cable (just be careful with the input ratings, if necessary lower the power with the 'p' option or add a dumper), you will have a better signal with less noise, and you will not actually transmit the continuous wave over the air on channels used by other BLE and WiFi devices.

[giocamurati]

If you want to use the cable: the guide at 8.10 describes the debug connection to connect a cable to the RF output instead of an antenna https://infocenter.nordicsemi.com/pdf/nRF52840_DK_User_Guide_v1.2.pdf using this probe: MXHS83QE3000 https://www.digikey.fr/product-detail/en/murata-electronics/MXHS83QE3000/490-4982-ND/1775923

[itewqq]

@giocamurati Thanks for your explanation, I will try these instructions. Your work is great, and I hope I can successfully reproduce it! 😄

[giocamurati]

@itewqq thank you very much, I am happy you like it! Don't hesitate to come back if you have more questions and good work :-)

[itewqq]

@giocamurati Hello, an error occurred when I tried to compile the firmware according to your instructions. The error message is as follows. I haven't changed the makefile. The SDK is based on the nRF5_SDK_14.2.0_17b948a version stated on your website. Is there anything I did wrong here? 😯

https://paste.ubuntu.com/p/VWjyxKPqBn/

Edit: replace the plaintext with a paste ubuntu post.

[giocamurati]

Hi @itewqq, could you please confirm that you did this:

cd $SC/firmware
wget https://developer.nordicsemi.com/nRF5_SDK/nRF5_SDK_v14.x.x/nRF5_SDK_14.2.0_17b948a.zip
unzip nRF5_SDK_14.2.0_17b948a.zip
rm nRF5_SDK_14.2.0_17b948a.zip
cp boards.h nRF5_SDK_14.2.0_17b948a/components/boards/
cp Makefile.posix nRF5_SDK_14.2.0_17b948a/components/toolchain/gcc
cp rblnano2.h nRF5_SDK_14.2.0_17b948a/components/boards/

and

export NORDIC_SEMI_SDK="/path/to/sdk"

[itewqq]

@giocamurati I realized this was because of a wrong character in my environment variables. I can now use your firmware successfully. Your innovative research and open source spirit are commendable, thank you! ! !

[giocamurati]

Thank you @itewqq!!!