Können LoRaWAN nodes eigentlich durch "Denial of Sleep Attacks" kompromittiert werden?

Gerhard Peter

Initiator of TTN Berlin and Community Happyness Manager

Posted on 02-12-2020

translate this article in all Google supported languages

Bei einer Video Conference über IoT, smart city, Personenflusszählung, edge computing und TinyML (schlankes Maschinenlernen) dieser Tage wurde, aus dem Auditorium, die Frage aufgeworfen, ob LoRaWAN nodes durch sog. Denial-of-Sleep Attacks (DoSL) , bisweilen auch EDA ("Energy Depletion Attack") genannt, kompromittiert werden können.

Radio Eriwan würde -wie stets gewohnt- darauf antworten mit: "Im Prinzip ja. Doch, es kommt darauf an." - Mit solchen Antworten zeigt man, dass man um keine Antwort verlegen ist.

Was sind "Denial-of-Sleep Attacks (DoSL)/EDAs" eigentlich?

Schlaflosigkeit ist nicht nur beim Menschen ein -wenn dort auch nur ein scheinbares- Problem [PS.: jeder Mensch schlummert ein, wenn er genügend lange wach gewesen ist. Mal früher, mal später. Nicht immer nach eigenen Vorstellungen und übrigens schon gar kein Grund sog. "Schlafmittel" zu konsumieren.]

Denial of Sleep Attacks (DoSL/EDA) sind Angriffe, die auf die Stromversorgung von LoRaWAN stand alone nodes abzielen. Diese Attacken sollen eine Änderung des Betriebszustandes bewirken und die nodes dazu nötigen vom, Energie sparenden, sleep mode in den active mode zu wechseln.
Dieser unnötige Energieentzug sorgte für eine vorfristige Entladung der dezentralen Energieversorgung, verringerte die Lebensdauer der Komponenten und führte zu einem höheren Ausfallrisiko, besonders dann, wenn die nodes komplex verbaut und schwer erreichbar sind, so dass ein vorfristiger Wechsel der Energiequellen unverhältnismässigen Aufwand erforderte.

Wie also sieht es nun aus?

Betrachten wir zunächst einen in das LoRaWAN integrierten node, der einfach die Zimmertemperatur in unser System sendet.

Werden die Messwerte ohne aknowledge mit einem LoRA Node ohne adaptive rate configuration gesendet, so besteht niemals die Gefahr einer DoSL Attacke, da niemand den node auf dem downlink Weg erreichen kann. Er schreit seine Werte nach dem ALOHA Prinzip einfach in die Welt hinaus.

Ab der nächsten Stufe allerdings werden die Dinge schon komplexer:

Werden die Messwerte mit Empfanqsbestätigung, also quasi mit "Rückschein", gesendet, so besteht (wen auch gering) Gefahr, da das Verfahren standardisiert ist. Zumindest ist mir davon noch nichts bekannt geworden.

Die Gefahr steigt deutlich an, wenn Nodes durch downlinks frei parametriert werden können, zB Ferneinstellung von Sendeintervallen. Durch intelligente Programmierung muss man ausschliessen, dass hier andere, als die zulässigen Informationen durch das Hoftor einfahren.

Es werden, den LoRa Spezifikationen gemäß, jedoch zwischen den nodes und dem dahinter liegenden System regelmässig weitere Informationen ausgetauscht, beispielsweise die Adaption der Datenrate. Hier kann auf der MAC Layer Ebene Schadcode injiziert werden.

Wird FOTA, also Firmware Update Over The Air, welches sich zunehmender Beliebtheit erfreut, benutzt, so kann natürlich, wie bei jedem update, auch dort Schadcode, und das ggf. unerkannt, "beigemischt" werden. Das ist aber dann kein LoRaWAN spezifisches Problem. Point to multipoint updates würden das Problem natürlich noch schneller als Corona verteilen.

Eine rein praktisch orientierte Methode wäre beispielsweise, auf erschöpfliche Energiequellen völlig zu verzichten und auf das fortschrittliche Energy Harvesting zu setzen. Klar auch dann kann man Systeme überfordern.... Security by Obscurity hilft eben nix.

DoSL ist Gegenstand intensiver akademischer Ermittlungen.

Beispielsweise hier:
https://hal.inria.fr/hal-02060608/document
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8691738