Anna, Antonios, Grissel, Peter, Petros, Robert and Vasileios from Team PRAVAG

Your home has a number of connected devices such as a smart TV or an IP Camera. The proposed solution intended to help determine whether or not these devices are being used by an attacker as a Botnet. A common example where such a solution would have been beneficial is the Mirai Botnet attack. The team divided themselves to work on three different tasks:

1. Data processing
2. Data visualising
3. Anomaly detection

They validated the approach by feeding a historic data set of real IoT traffic, provided by one of the team members, into existing professional tools for data processing. Then, they derived patterns of what is normal and namely in the existing datasets. At the end of the hackathon, they provided us with a proof of concept to detect malicious device behaviour to prevent or stop such as DDoS attacks.

The software they used was luminol and phrophet for comparing packet data to find unusal behaviour patterns.

Looking into the future, these findings could be fed to AI for anomaly detection. The team intends to continue their work will also have to compare their efforts with existing work such as SPIN. Incidentally, one of the team's members is actually working on this topic for her thesis.

Anup, Vladislav, Cristel, Marco, Philip and Randy from Team Maria

LoRawAN gateways are expensive. Using an RPi as the LoRaWAN gateway reduces cost for DIY users. Also, adding RIPE Atlas network measurements and monitoring capacities to an RPI helps leverage existing devices and thus helps benefit research users.

This can be used in all IoT scenarios in which the unlicensed band technology “LoRa” is being used for long-range, low data rate communication. The RPi can be deployed as a LoRaWAN gateway while serving as a RIPE Atlas probe, especially in developing countries where unlicensed spectrum deployment is preferred due to its low-cost and easy deployment.

During the hackathon, team Maria was able to port the RIPE Atlas to the RPi running Raspbian/Buster, and also older versions of Raspbian. They also managed to port that to the LoRa platform, which might lead to back-porting to Raspbian/Debian jessie. By the end of the hackathon, full Debian packages were available.

In the future, the packaging will enable all users to easily install the necessary software to integrate RIPE Atlas to an RPi. This work could be taken further by others by preparing similar packages for other distributions such as FreeBSD, CentOS etc. In addition to the RPi use case, the same principles could be applied in data centre networks on already installed servers.

The software they used to install the gateway on the IMST hardware can be found at: http://www.technoblogy.com/show?1XKI

Arman, Demian, Desiree, Pouyan, Renan and Tasos from Team Survival Layer

The current state of IP networks requires clients to know the location, i.e. IP address, of the desired data before fetching that. However, sometimes known hosts are not reachable due to network fragmentation or the client is not aware of the responsible hosts.

The aim of the project was to solve this problem through Information Centric Networking (ICN). In ICN, data is spatiotemporally decoupled from its producer and is identifiable solely by its name throughout the network. Such decoupling brings about advantages such as in-network caching and allows data to be mulled to the fragmented network without having to requiring access to its original producer. At the same time consumers retrieve data by its name without needing to know where it is stored. The ICN paradigm simplifies the networking stack because higher-layer services that we know from the current Internet are native on the network layer in ICN.

This functionality can be used shortly after a disaster of crises, therefore the name “Survival Layer”. In such a scenario, where the network is fragmented and civilians have no access to the broader global Internet, a drone could fly over isolated neighbourhoods and disseminate alerts, warnings, and other informative material. These are cached by a local ICN node and can be retrieved by the civilians, i.e. consumers.

At the hackathon, the team presented a basic dissemination scenario. In the future, they will be looking into addressing the problem of authentication.

Team Aethernauts’s project was inspired by a real use-case from the Deutsche Bahn! They wanted to use real low-end simple microcontrollers to test the Quality of Service (QoS) of users connected to their WiFi. To do so, they coded a WLAN probe to measure WLAN performance indicators. This can be used anywhere where a reliable measurement of a WLAN infrastructure is required.

 Christop, Craig, Michael and Cristian from Team Aethernauts

This project was actually initiated before the IoT Hackathon and the team arrived with several hundred lines code already in place! The team had two goals for the hackathon:

1. To visualise incoming data with Grafana, because until then, the probes were pumping data only to a MQTT broker. During the hackathon, they achieved this goal.
2. To refactor the existing code to enhance its capabilities to grow. This was harder to measure but they implemented the first tests and introduced a new way to handle measurement results in the code. The refactoring was not completed but they will keep developing it. They learned a lot about the importance of tested code and how much effort one needs to put into a smooth setup, especially with multiple hardware and software components.

To test this functionality, they used MicroPython on a ESP32.

This work will be continued by the team member from Deutsche Bahn. This is a classical case where the WiFi service provider wants to know the QoS provided by using cheap microcontrollers.