Cannot observe the leak described in CCS18 paper Figure 12 about screaming_channels HOT 10 CLOSED

@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! ! !

from screaming_channels.

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.

from screaming_channels.

@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!

from screaming_channels.

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.

from screaming_channels.

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

from screaming_channels.

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

from screaming_channels.

@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 :-)

from screaming_channels.

@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.

from screaming_channels.

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"

from screaming_channels.

Thank you @itewqq!!!

from screaming_channels.