How to build a Jammer Detector

Imagine today’s world without wireless communications. No cell phones, no Wifi at home, no GPS, no bluetooth keyboard/mouse/earphones, etc. etc. etc. Clearly, we depend on wireless connectivity a lot more than we are aware of. So, what if these wireless signals could be affected in a way that they become useless and communication is completely lost? Would that be even possible? Well, in some cases, it is and it is quite easy to achieve… but luckily there are ways to identify these types of threat and I will show you one of them.

Jamming

As we said, we depend on wireless networking quite a lot. Wireless communication is like two people speaking. One of them speaks and then listens, and vice-versa. What if a third person gets close to them and starts shouting so loud that the other two cannot listen to each other anymore? In the beginning, they will try to continue the conversation but soon they will realise that it is not possible and they will stop speaking, waiting for the crazy guy to shut up. This is what happens to many communication protocols. When they notice that the channel is busy, they back off. Thus, message exchange between those devices is suspended. Even if they tried to communicate when the medium is not free, like some other protocols do, if the noise is too high then the messages would not be received correctly on the other side and no communication would be possible. This is what we call wireless jamming.

There are a large number of malicious wireless devices that aim to cause intentional interference in a wireless network. They are clearly illegal but nowadays, they could be bought online for a moderate price.

These jammers work in the following way. They generate a strong wireless signal that affects the physical layer of the wireless communication protocol that is being used. This means that they are able to affect any protocol at any given frequency band. They affect the first layer of the OSI stack, the medium. In consequence, any upper layer used for communication, will be affected. Wifi, bluetooth, 3G, 4G, GSM, GPS, you name it. It is like the crazy guy that starts shouting in the middle of the conversation. It doesn’t mind if the speakers are speaking in English or in Russian, they will not be able to talk to each other anymore.

There are different types of jamming signals but the most commonly used are these four:

Continuous wave: sinusoidal narrowband signal with constant amplitude and constant frequency

Frequency modulated: sinusoidal signal with constant amplitude and variable frequency that sweeps service band frequencies

Wideband: transmits a band of frequencies that is large with respect to the bandwidth of a single emitter

Pulsed signals: intermittent signal that has several harmonic components split in the entire service band

There are multiple types of signals that could be used to affect wireless communications. However, the commercial jammers that we could easily buy over the Internet, use pulsed ones, as it is the cheapest way to achieve a powerful and wideband jammer on a given band.

So, what do we do about this? How can we detect that there is some malicious device trying to affect regular wireless networking? Well, one of the solutions would be to build a Jammer Detector. Simple, right? :)

DoS Sensing — Jammer Detector

Today (the day I started writing this blog post) it has been 2 years since I joined Worldsensing. This is an IoT company that has been growing a lot lately and personally it has been a great experience for me so far to work here. I am part of a team that works mainly on Innovation projects, generally founded by the European Union. In the context of one of those projects called CIPSEC, we were requested to develop a tool that would allow us to detect wireless Denial of Service (DoS) attacks. After analysing the problem and doing a lot of research, we decided to build DoS Sensing, a Jammer Detector IoT device. After all, we are an IoT company!

The idea was to have a device that would be able to protect any wireless network, regardless of the frequency band. This means that it had to be able to detect anomalies on the physical layer and inform when there was an attack going on. This would allow us to use one single device to improve security of heterogeneous devices, such as WiFi routers, mobile phones or even Worldsensing’s Loadsensing dataloggers, which communicate through LoRa.

In consequence, what we wanted was a smart sensor that would not interfere the wireless signals but would just listen passively to them and analyze them in order to find an anomaly. In case there was such a thing, it should inform about the attack so that some action could be taken. It would help, of course, to have a visual tool in order to see the attacking signal strength in real time, as the attack would take place.

Solution’s architecture

But how do we build such a thing? Well, to begin with, if you are willing to be agnostic of the communication protocol and you will be analysing the physical layer, your best option would be to use an SDR (Software Defined Radio) module. These modules are mainly a multiple band radio only, while all other components which are generally implemented in hardware (filters, modulators, mixers, etc), run on software. This allows us the conversion of a wireless signal from its analog form to a digital one, no matter what the communication protocol is. Then, all we have to do is to analyze the type of signal and make sure it corresponds to one of the well-known jamming signals. It is like comparing the signature of the signal with the signatures that we know.

Then, all we need is an SDR module? Well, only the SDR module will not allow you to make the analysis. It will just transform your analog data to digital samples. Oh, by the way, we also need an antenna, of course. How are we going to capture the wireless signals without it? Right. But antennas depend on the frequency. You cannot use the same antenna for all frequencies. Right, but there are some antennas that cover a wide range of frequencies which we can use.

OK, we will need an antenna, an SDR module and something to process the data generated by it. That will compose our sensor, our IoT device. It should be capable of capturing the wireless spectrum and transforming it to detection events. Those events should be the type “there is indeed a jammer” or “there is no jammer here” and that should be communicated periodically as we want the solution to run real time. Those events may include information such as the type of attack going on, the signal power of the attacking signal, the frequency where the attack was found and of course a timestamp.

Good. At this point, the only thing left is the software that will allow us to visualize those attack events in real time. Usually, applications like this run on the Cloud and provide a web interface to access it. In addition, the software running on the cloud should also provide means to store data in case we wanted to see historical events.

OK, then! Our architecture is something like this:

The wireless signals are received by the antenna. Then transformed to digital samples by the SDR Module. Those are processed by the Processing Board and once the board decides if there is an attack going on or not, the result is communicated to the Monitoring Server, which receives and stores the data. Then, the Visualization Tool can be used to show those events in real time and historically.

The sensor (Hardware)

Now we need to build the sensor. Let’s begin with the antenna. We know that there are some antennas that cover multiple bands, for example, this one, which we have actually tested with good results. We could use something like this in order to cover several frequency bands and protect multiple protocols. Nevertheless, to start with, we focused mainly on having a prototype to protect the Wifi band, so a 2.4 Ghz — 2.5 Ghz antenna was enough. We will see why later on.

We also need an SDR module. Which one? There are several products in the market. After some research and discussion with experts, we decided that for this prototype we would opt for the HackRF One. This device offers a good price-quality relationship and it covers 1 MHz to 6 GHz frequencies! Its drivers are open source and you can easily install them via package manager for most Linux distributions.

Good, this is starting to take shape. Now we need a machine that is able to process the digital samples generated by the SDR module, our Processing Board. Here things become a little tricky. If we want to analyze the stream of data real time, then we need to have significant processing power. Having a decent sampling rate (such as 5 Msps) gives us a total of more than 300 Mbps data rate! This is a lot of data if we wanted to analyse it all. Fortunately, we don’t really need to process it all but at least a few bunches of data per second, in order to have a real time solution. In this case, a laptop would be great but you cannot create an IoT device with a laptop. You definitely need something smaller. Then, we thought of a Raspberry Pi but even version 3 may not be enough for our purposes in some cases (even though, it could work if you do not mind about having some latency on the results). This is why we decided to go for the Odroid C2. This board is quite powerful for its price and can run ubuntu-minimal, which helps a lot. Dependencies are really easy to install if you want to connect a HackRF One to it, and it is a quite robust board.

Perfect. Anything else? Well, yes. If you want to build an IoT device and you want it to look nice, you will need a box. Moreover, if you want to install that device outdoors, you better make sure that the box is waterproof! Let’s use something that we already know. Worldsensing has a product called Bitcarrier which has an embedded antenna on its box and serves perfectly for our purposes in case we are only going to the detector on the Wifi band. So this is why we decided to reuse the Bitcarrier box and focus mainly on detection of attacks in that band.

The sensor (Firmware)

This is probably the most complex part of the building process. The software that is used on the embedded device (we call it Firmware) has to process the digital samples coming from the SDR Module and make a decision about the presence of a jammer or no jammer. Fortunately, there are tools that simplify the job a lot and they are even open source! For this purpose, we use GNU Radio.

GNU Radio is a free software development toolkit that allows us to use signal processing blocks of different kinds in order to implement signal processing systems and software defined radios. You can use the blocks that do the signal processing in software and connect them among each other in order to transform the signal and generate an output. There are a lot of pre-defined functions, such as filters, equalizers, decoders, etc. And the best part is that you can also develop your own blocks and use them to connect with the rest. The applications can be written in C++ or Python. GNU Radio allows you to use an SDR module to visualize cool things like this:

This is the FFT of a signal. Which means that you have your own spectrum analyzer running on your computer!

On the other hand, you can do other things like connecting a signal source to different blocks that transform the samples to something else. There is a graphical user interface for this called GNU Radio Companion and it looks like this:

This tool ends up generating a Python script that connects the blocks together and runs the application, generating some output. In this case, what we want to build is a flow of samples that goes through some customized blocks that able to analyse them so that a certain pattern or signature is found on the signal. If this happens, we send a message saying that we found it, we identified a jammer. The architecture of the SDR Jammer Detection (SDRJD) application on the Processing Board is the following:

Digital samples come from a source, which is the SDR module. However, thanks to GNU Radio and its block oriented architecture, the SDR Module as a source can be replaced by other possible sources, as long as there is a block for it. For example, the source could be a file. This is very useful, as it allows us to record a signal (a jammer for example), dump it to a file (using a sink block that writes to a file) and then reuse it as many times as we want for testing.

We will also use a signal conditioner to prepare the samples to be analyzed by the jammer detection algorithms. There are four of them (one per type of jammer) and they process the data in parallel (in fact, every GNU Radio block runs on its own thread). Once the algorithms decide, they communicate this decision to the Detector Message Receiver, which aggregates the decisions, making the final decision of which jammer is present or not, and puts a message into a Linux queue.

The SDRJD application has a very complete configuration file, which allows us to configure sampling frequency, input gains, signal source, center frequency and a lot of other parameters. There are even some parameters to adjust and calibrate each detection algorithm, as they may change depending on the environment where the sensor is installed. Very noisy environments may need readjustment of the thresholds and the Tong algorithm parameters.

The Tong algorithm is an interesting procedure that was developed to improve false positive results and refine the decisions taken by each jammer detection algorithm. It consists of making several decisions to come to a conclusion. We start with a counter K=B. If the decision is positive, we increment K. If K is equals to A, then the result is positive. If the decision is negative, we decrement K. If K equals to 0, then the result is negative. As we could be iterating infinitely, we also count a maximum number of iterations, until declaring a negative result.

All the firmware described here is open source and can be found here.

As we said, detection messages are put into a Linux queue. Another process is in charge of reading the messages from the queue and transferring them to the Monitoring Software, running on the Cloud.

Monitoring Software

Regarding the software, we were researching about different tools that could be used to present data in real time and would be easy to use to prepare dashboards. We discovered that the combination of InfluxDB, Kapacitor, Grafana was great to fulfill our needs. The Monitoring Software architecture ended up looking like this:

The sensor communicates with a python script that inserts the data to the InfluxDB database. Here is where Kapacitor does some magic in order to refine the detection messages coming from the sensor and reinserts the attack entries to a database that is used by Grafana to present the attacks real time and show some statistics. Whenever there is a positive attack, Kapacitor will also communicate that to a separate process that will write a syslog entry to the ATOS XL-SIEM. This SIEM was developed and tested in the context of the CIPSEC project.

Kapacitor plays a very important role here. We have seen that even if we can adjust the sensor’s detection thresholds and parameters, there might be a few sporadic false positives or detections that do not necessarily mean an attack. In these cases, we did not want to show that a “mini-attack” was taking place, as we knew it was not the case. This is why we added a refinement layer of the detection messages coming from the sensor and that layer is implemented by Kapacitor. The algorithm is the following:

• If _positiveRatio_ % of the last _windowDuration_ jammer detection decisions coming from the sensor (in the raw decisions table) are positive and the JNR (Jammer to Noise Ratio) is greater than _jnrThreshold_, then declare a positive attack event. If not, declare a negative attack event.
• Slide _jammerUpdateWindowDuration_ more seconds the _windowDuration_ sliding window

Currently we have set the parameters to the following and have seen good results:

• _jnrThreshold_ : 1 dB
• _positiveRatio_ : 90
• _windowDuration_ : 5 seconds
• _jammerUpdateWindowDuration_ : 1 second

Front-End

The latest part of the solution consists of the Visualization Tool. This tool is built using Grafana and provides a dashboard to visualize the attacks and other statistics. It provides a real time graph of the JNR vs time of each type of detectable attack. Moreover, it shows the number of attacks per type during the last day (this timeframe can be changed). It also has a widget that shows the current status of the jammer detector device, where blue means sensor is active, red means under attack and grey means that the sensor is inactive. This is how it looks like:

Wrap up

We have seen that building a jammer detector is not an easy procedure. It takes time to develop the firmware and software, and also to refine them both so that the results provided by the sensor are coherent. Nevertheless, the result is a very nice prototype that can be used as a proof of concept of the feasibility to detect such type of attacks, which affect significantly our wireless environment.

If you feel like trying the sensor yourself, go ahead, get an SDR module, download the firmware repository, follow the README instructions and run the jammer detection yourself!

Disclaimer

This project (Cipsec) has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 700378. Any dissemination of results here presented reflects only the consortium view. The Research Executive Agency is not responsible for any use that may be made of the information it contains.