Fakulteta za raˇ cunalniˇ stvo in informatiko
Nino Brezac
Uporaba protokola MQTT v avtomobilih
DIPLOMSKO DELO
UNIVERZITETNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : izr. prof. dr. Mojca Ciglariˇ c
Ljubljana, 2021
besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.
Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita program- ska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/
licenses/.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Vrsta naloge: Diplomska naloga na univerzitetnem programu prve stopnje Raˇcunalniˇstvo in informatika
Mentor: izr. prof. dr. Mojca Ciglariˇc
Opis:
Sodobne avtomobile lahko gledamo kot mnoˇzico povezanih naprav interneta stvari, ki med seboj med voˇznjo intenzivno komunicirajo. Za takˇsno ko- munikacijo so sploˇsni internetni protokoli pogosto manj primerni. Preuˇcite primernost protokola MQTT za scenarije uporabe v avtomobilu. Najprej raziˇsˇcite delovanje MQTT in specifiko avtomobilske komunikacije, nato se osredotoˇcite na varnostne mehanizme protokola in njegove morebitne ran- ljivosti. Navedite nekaj tipiˇcnih primerov uporabe in moˇznih posledic var- nostnih incidentov avtomobilu ter predlagajte, kako lahko zagotovimo veˇcjo varnost. Izbrani primer napada tudi dejansko izvedite in komentirajte.
Title: Usage of MQTT protocol in automobiles Description:
Modern automobiles can be seen as a set of connected Internet of Things devices, that communicate intensively while driving. Standard internet pro- tocols are often not fit for this scenario. Research the suitability of the MQTT protocol for automotive purposes. First provide an overview of the inner-workings of MQTT and the specifics of automotive communication, then focus on the security mechanisms of the protocol and its potential vul- nerabilities. Specify some common use cases of MQTT in automobiles as well as the possible consequences of security flaws, and also suggest some good security practices. Execute and discuss the possible exploits.
gospodu Dejanu Podgorˇsku za posojeno strojno opremo.
Povzetek Abstract
1 Uvod 1
1.1 Motivacija . . . 1
1.2 Znaˇcilnosti sodobnih avtomobilov . . . 1
1.3 Struktura dela in uporabljene metode . . . 2
2 Osnove MQTT protokola 5 2.1 Namen in osnovne informacije . . . 5
2.2 Tipiˇcni primeri uporabe . . . 5
2.3 Arhitektura . . . 6
2.4 Format sporoˇcil . . . 7
2.5 Scenarij komunikacije . . . 14
3 Prednosti in slabosti protokola MQTT 15 3.1 Prednosti . . . 15
3.2 Slabosti . . . 16
3.3 Alternative MQTT protokolu . . . 16
4 MQTT avtomobilski sistemi 21 4.1 Vzdrˇzevanje vozil . . . 23
4.2 Spremljanje prometa . . . 26
4.3 Hitrejˇsi prihod reˇsevalnih vozil . . . 27
4.6 Parking . . . 29
4.7 Izposoja vozil . . . 30
4.8 Primeri v industriji . . . 32
5 Varnostni vidik protokola MQTT, ter MQTT avtomobilskih sistemov 35 5.1 Pomen varnosti . . . 35
5.2 MQTT varnostni mehanizmi . . . 36
5.3 Varnostni mehanizmi . . . 37
5.4 Kako se ustrezno zaˇsˇcititi? . . . 41
6 Praktiˇcni primeri 43 6.1 Zaznavanje trkov . . . 43
6.2 Neustrezna avtentikacija . . . 49
6.3 Neustrezna avtorizacija . . . 53
6.4 Napad z vrivanjem . . . 56
6.5 Napad zavraˇcanja storitev . . . 63
6.6 Komentar . . . 64
7 Zakljuˇcek 67
Clanki v revijahˇ 71
Clanki v zbornikihˇ 73
Celotna literatura 75
kratica angleˇsko slovensko MQTT Message Queuing Telemetry
Transport
telemetrijski transport vrste sporoˇcil
IoT Internet of Things internet stvari M2M machine to machine stroj proti stroju QoS quality of service kakovost storitve
HTTP HyperText Transfer Protocol protokol za prenos hiperte- ksta
IP Internet Protocol internetni protokol MSB most significant bit najbolj pomemben bit
GPS Global Positioning System globalni sistem pozicioniranja TCP Transmission Control Proto-
col
protokol za nadzor prenosa REST representational state transfer reprezentativni prenos stanja UDP User Datagram Protocol nepovezovalni protokol za
prenaˇsanje paketov
TLS Transport Layer Security varnost transportne plasti SSL Secure Sockets Layer sloj varnih vtiˇcnic
CoAp Constrained Application Pro- tocol
omejeni aplikacijski protokol SMS Short Message Service sistem kratkih sporoˇcil CAN Controller Area Network obmoˇcno omreˇzje krmilnika LCD liquid crystal display zaslon s tekoˇcimi kristali ARP Address Resolution Protocol protokol za loˇcljivost naslova MAC Media Access Control nadzor dostopa do medija VPN Virtual Private Network navidezno zasebno omreˇzje SMQTT Secure Message Queueing Te-
lemetry Transport
zavarovani telemetrijski tran- sport vrste sporoˇcil
Naslov: Uporaba protokola MQTT v avtomobilih Avtor: Nino Brezac
Sodoben avtomobil je mnoˇzica IoT naprav, tj. naprav s specifiˇcnimi nalo- gami, ki jih opravljajo ˇcim bolj uˇcinkovito. ˇCetudi je protokol HTTP do- bro znan in standarden, je dejstvo, da ni optimiziran za komunikacijo v IoT mikrokozmosu. Bolj kompatibilna alternativa z IoT svetom je protokol MQTT. Predstavlja reˇsitev, ki zmanjˇsa reˇzijo in komunikacijo poenostavi na sistem objave in naroˇcanja preko centralnega upravljalca – brokerja. Pred- nosti MQTT-ja uporabljajo tudi ˇstevilna svetovna podjetja, ki s pomoˇcjo MQTT jedra implementirajo pestre in zmogljive sisteme. To diplomsko delo se osredotoˇca na osnovni pregled MQTT-ja, predstavitev njegovih moˇznosti v avtomobilski paradigmi, ter pregled kljuˇcnih nevarnosti in teˇzav, tako var- nostnih kot ostalih.
Kljuˇcne besede: MQTT, protokol, avtomobili, IoT, varnost.
Title: MQTT protocol in automobiles Author: Nino Brezac
A modern car is a set of IoT devices, devices with specific tasks that need to be performed as efficiently as possible. Although the HTTP protocol is well known and standardised, it is clear is that it is not optimized for communi- cation in the IoT microcosm. An alternative that is more in line with the IoT world is the MQTT protocol. It is a solution that reduces overhead and simplifies communication to a publish-subscribe system, through a central manager - broker. The advantages of MQTT are also used by many global companies that implement diverse and powerful systems with the help of the MQTT core. This diploma focuses on a basic overview of MQTT, a presen- tation of its capabilities in the automotive paradigm, and an overview of key dangers and problems, regarding its security and others.
Keywords: MQTT, protocol, automobiles, IoT, security.
Uvod
1.1 Motivacija
Danes smo priˇce eksponentnemu razvoju avtomobilske industrije in digita- lizacije avtomobila. Avtomobili bodo v prihodnosti postajali ˇse bolj kom- pleksni. Napredek in priljubljenost podjetij, kot so Tesla, Rimac, HiveMQ, je neke vrste potrditev aktualnosti te teme. Oˇcitno je da se Karl Benz leta 1886 ni zavedal, da bo njegov izum zrasel iz premikajoˇcega stroja v inteli- gentno, odzivno, nekateri se celo hvalijo, avtonomno oz. samovozeˇce vozilo!
Tehnologija v ozadju avtomobila sˇcasoma postaja bolj in bolj kompleksna, obenem pa tudi bolj zanimiva in privlaˇcna. Zelo teˇzko je pogledati sodobni avtomobil in ostati ravnoduˇsen. Glavni namen dela je bil predstaviti komu- nikacijsko ozadje novih visoko-tehnoloˇskih avtomobilskih sistemov ter kako in kaj dejansko omogoˇca privlaˇcne funkcije prihodnosti.
1.2 Znaˇ cilnosti sodobnih avtomobilov
Lahko reˇcemo, da so minili ˇcasi ”ˇcistokrvnih”avtomobilov brez digitalne opreme. Sodoben avtomobil je, med ostalim, tudi mnoˇzica IoT naprav. Kot vemo je vodilno naˇcelo IoT sveta uˇcinkovitost – ”opravi svojo nalogo ˇcim bolj gospodarno in efektivno”. ˇCe pa pogledamo karakteristike, s katerimi se
1
hvalijo avtomobilski proizvajalci, lahko sklepamo, da pogosto slonijo na neki vrsti komunikacije.
Sledenje dobaviteljski verigi, dinamiˇcno vzdrˇzevanje, komunikacija z me- hanikom, izboljˇsana uporabniˇska izkuˇsnja, kontekstno odvisno svetovanje, so zgolj del ˇstevilnih novitet v svetu avtomobilov. Zavedati se moramo tudi, da takˇsnih opravil ni mogoˇce opravljati na standardne, vsem znane naˇcine, preko protokola HTTP.
Ceprav je HTTP del spletne hrbtenice, je dejstvo, da ni najbolj primerenˇ za majhne naprave, saj zahteva preveˇc reˇzije in resursov. V naˇsem delu se bomo zato ukvarjali z eno od alternativ, ki je bolj v soglasju z IoT svetom v avtomobilu – protokolom MQTT.
Podrobnosti protokola so opisane v poglavju 2. Opisana je njegova zgradba in naˇsteti argumenti v prid njegovi uporabnosti v IoT sistemih. V poglavju 4 pa so opisani ˇstevilni funkcijsko razliˇcni primeri uporabe protokola. Primeri so bodisi raziskovalna dela drugih bodisi obstojeˇci poslovni sistemi.
1.3 Struktura dela in uporabljene metode
V nadaljevanju smo v poglavju 2 podrobno opisali osnove protokola MQTT in njegov princip delovanja. Nato smo v poglavju 3 povzeli njegove glavne prednosti in slabosti ter ga primerjali s konkurenˇcnimi protokoli in tehnolo- gijami. Ko smo protokol spoznali, smo se lotili opisovanja ˇstevilnih primerov uporabe v poglavju 4. Temu je sledil varnostni pregled – poglavje 5. V njemu smo pisali o pomembnosti varnosti v IoT paradigmi, kaj konkretno grozi protokolu MQTT in kako se lahko zaˇsˇcitimo.
Za konec smo v poglavju 6 predstavili nekaj praktiˇcnih primerov. Za nji- hovo izhodiˇsˇce je sluˇzila izˇcrpna dokumentacija in spletni MQTT vodiˇci, ˇse posebej od vodeˇcega svetovnega podjetja, ki se ukvarja z MQTT komunika- cijo v avtomobilih – HiveMQ.
Praktiˇcni primeri so izvedeni v Kali Linux distribuciji, saj ta privzeto vkljuˇcuje nekatera orodja, ki nam pomagajo. Prviˇc smo naˇcrtovali ”grobi”
MQTT avtomobilski sistem. Opisali smo in preizkusili verigo, ki nas pripelje od senzorja v avtomobilu do namiznega raˇcunalnika, vse s pomoˇcjo protokola MQTT. Koda je napisana v programskem jeziku Python. Do MQTT posre- dnika se je dostopalo s pomoˇcjo znanega orodja Mosquitto. Podatke smo shranjevali v podatkovni bazi SQLite3. Vse slike in grafi, ki niso oznaˇcene kot lastniˇstvo tretjih oseb, so ustvarjene z orodjem LucidChart.
Nato smo se osredotoˇcili na varnost, poudarili pomen avtentikacije in avtorizacije. Spremljanje prometa smo izvajali v programu Wireshark, s programom Ettercap pa preizkusili napad z vrivanjem (angl. man in the middle).
Diplomsko delo naj bi koristilo osebam, ki ˇzelijo bolj globoko spoznati komunikacijsko ozadje sodobnih avtomobilskih sistemov, katere funkcional- nosti omogoˇcajo, kakˇsne priloˇznosti ponujajo ter seveda, kakˇsne nevarnosti grozijo takˇsnim sistemom. Predstavili smo mnoˇzico primerov uporabe, od idej in doseˇzkov raziskovalcev in laikov, do velikih podjetij, ki s hrbtenico MQTT implementirajo kompleksne in zmogljive sisteme.
Praktiˇcni primeri v diplomskem delu imajo dvojni pomen. Bodisi nare- kujejo pomen implementacije varnostih mehanizmov bodisi lahko sluˇzijo kot osnova za podobne IoT sisteme v avtomobilu.
Osnove MQTT protokola
2.1 Namen in osnovne informacije
MQTT (Message Queuing Telemetry Transport) je omreˇzni protokol aplika- cijske plasti. Prvo verzijo sta razvila Andy Stanford-Clark in Arten Nipperi iz IBM-a leta 1999, namenjena pa je bila nadzoru naftovodov. Naprave naf- tovodov so bile do takrat povezane preko satelitskih povezav, posledica ˇcesar je bil zelo drag prenos podatkov. Zato so ˇzeleli razviti nov protokol, ki je bolj prilagojen IoT napravam, torej uˇcinkovito uporablja pasovno ˇsirino in varˇcuje z elektriˇcno energijo.
2.2 Tipiˇ cni primeri uporabe
Kot je ˇze omenjeno, protokol MQTT temelji nauˇcinkovitosti in enostav- nostiter je zato zelo priljubljena reˇsitev za M2M komunikacijo IoT naprav.
Nekateri primeri njegove uporabe so:
1. pametne hiˇse;
2. pametni avtomobili;
3. nadzor industrijskih strojev;
5
4. oddaljeni nadzor/monitoring;
5. sploˇsne medicinske funkcije;
6. IoT sistemi omejenih zmogljivosti;
7. IoT sistemi.
2.3 Arhitektura
Slika 2.1: Arhitektura MQTT [7].
Zgradba MQTT sloni na treh kljuˇcnih konceptih:
• principu objave in naroˇcanja;
• temah (angl. topic);
• delu posrednika.
Glavna akterja MQTT-ja sta odjemalec (angl. client) in streˇznik (angl.
server). MQTT streˇznik se imenuje posrednik (angl. broker), odjemalci pa stranke ali vˇcasih tudi povezane naprave. Streˇznik obravnava zahteve, medtem ko odjemalci ustvarjajo zahteve za prejemanje in poˇsiljanje podatkov med seboj. Grafiˇcen prikaz arhitekture lahko vidimo na sliki 2.1.
Ko ˇzeli naprava (odjemalec) posredovati podatke posredniku, to operacijo imenujemo ”objava”(angl. publish). Ko pa ˇzeli prejeti podatke od posre- dnika, pa temu reˇcemo ”naroˇcnina”(angl. subscribe). Entiteta, ki povezuje objavo in naroˇcnino, je tema.
Tema je niz (angl. string), ki je znakovno obˇcutljiv in predstavlja neke vrste ponor, naslov za MQTT sporoˇcila. Odjemalci bodisi objavo novih sporoˇcil naslovijo na temo bodisi se naroˇcijo na temo in preko posrednika dobijo nova sporoˇcila. Pri tem oˇcitno MQTT ni omejen na konvencionalno komunikacijo od toˇcke do toˇcke, temveˇc omogoˇca tudi komunikacijo one-to- many (eden poˇsiljatelj, veˇc naslovnikov) ali many-to-one (veˇc poˇsiljateljev, eden naslovnik).
Denimo, da odjemalec objavi sporoˇcilo in ga naslovi na doloˇceno temo, posrednik to zazna in obvesti vse naroˇcnike, odjemalce, ki so naroˇceni na prav to temo. Intuitivno sklepamo, da se stranke lahko ustvarjajo in naroˇcajo na nove teme, za kar skrbi posrednik. Pomensko torej velja, da odjemalci niti ne poznajo IP naslovov ostalih, ki komunicirajo zgolj preko teme. Za vse ostalo, tudi za naslove IP, pa skrbi posrednik.
Zaradi tega se pogosto reˇce, da ima MQTT prostorsko, ˇcasovno in sinhronizacijsko neodvisnost (angl. space, time, synchronization decou- pling), saj odjemalci ne poznajo naslovov (prostor), ne rabijo biti istoˇcasno aktivni (ˇcas), poˇsiljanje pa ne prekinja ostalih operacij (sinhronizacija) [28].
Lahko reˇcemo da vsako MQTT omreˇzje vsebuje vsaj:
• enega posrednika
• enega naroˇcnika
• enega poˇsiljatelja
2.4 Format sporoˇ cil
MQTT sporoˇcilo ima tri dele: fiksno glavo, spremenljivo glavo ter telo sporoˇcila.
Fiksna glava
Fiksna glava zajema (vsaj) prva dva bajta in je prisotna v vsakem MQTT sporoˇcilu, medtem ko telo in spremenljiva glava nista obvezna.
Prvi bajt doloˇca tip MQTT sporoˇcila (4 bite) ter zastavice (4 bite), med- tem ko drugi bajt, polje ”remaining length”, oznaˇcuje dolˇzino spremenljive glave in telesa sporoˇcila. ˇCe je preostala dolˇzina sporoˇcila prevelika za zapis v enem bajtu, se lahko polje remaining length razˇsiri do ˇstirih bajtov. Deluje po principu, da opiˇse dolˇzino v sedmih bitih, potem pa v najbolj pomemb- nem bitu (angl. MSB) doloˇci nadaljevanje polja remaining length, ˇce je to potrebno oz. ˇce je dolˇzina veˇcja in se ne more zapisati v sedmih bitih.
V nadaljevanju je prikazana tabela 2.1, ki ponazarja strukturo fiksne glave, tabela tipov sporoˇcil 2.2 ter tabela moˇznih zastavic 2.3.
Bit 7 6 5 4 3 2 1 0
1. bajt tip sporoˇcila MQTT zastavice 2. bajt preostala dolˇzina
Tabela 2.1: Struktura fiksne glave sporoˇcila MQTT.
Ime Vrednost Smer Opis
Rezervirano 0 Ni dovoljeno Rezervirano
CONNECT 1 Odjemalec→Posrednik Zahteva vzpostavljanja zveze CONNACK 2 Posrednik→Odjemalec Potrditev povezave
PUBLISH 3 Obe Objavi sporoˇcilo
PUBACK 4 Obe Potrdi objavo sporoˇcila
PUBREC 5 Obe Potrdi prejetje objave
PUBREL 6 Obe Opuˇsˇcanje objave
PUBCOMP 7 Obe Objava uspeˇsna
SUBSCRIBE 8 Odjemalec→Posrednik Zahteva naroˇcnine SUBACK 9 Posrednik→Odjemalec Potrditev naroˇcnine UNSUBSCRIBE 10 Odjemalec→Posrednik Zahteva preklica naroˇcnine UNSUBACK 11 Posrednik→Odjemalec Potrditev preklica naroˇcnine PINGREQ 12 Odjemalec→Posrednik Zahteva PING
PINGRESP 13 Posrednik→Odjemalec Odgovor PING
DISCONNECT 14 Odjemalec→Posrednik Zahteva prekinjanja zveze Rezervirano 15 Ni dovoljeno Rezervirano
Tabela 2.2: Tipi sporoˇcil MQTT.
Zastavice fiksne glave veˇc ali manj koristi samo sporoˇcilo PUBLISH, kjer oznaˇcimo ˇce je sporoˇcilo podvojeno, ˇce ˇzelimo njegovo zadrˇzevanje in defini- ramo zahtevani nivo reˇzije (veˇc o teh konceptih v nadaljevanju). Pri ostalih veljajo zgolj rezervirane vrednosti (bodisi 0000 ali 0010). V tabeli vidimo
pomen zastavic po tipu sporoˇcila. Za ostala sporoˇcila, ki niso navedena velja da imajo vse zastavice vrednost 0 [43].
Tip paketa Zastavice Bit 3 Bit 2 Bit 1 Bit 0 PUBLISH uporabljeno v MQTT 3.1.1 DUP QoS QoS RETAIN
PUBREL (Rezervirano) 0 0 1 0
SUBSCRIBE (Rezervirano) 0 0 1 0
UNSUBSCRIBE (Rezervirano) 0 0 1 0
Tabela 2.3: Zastavice v fiksni glavi sporoˇcila MQTT.
Spremenljiva glava, telo
V spremenljivi glavi lahko najdemo informacije, ki so specifiˇcne za ta tip sporoˇcila. Npr. CONNECT vsebuje verzijo MQTT zastavice, ki signalizirajo uporabniˇsko ime in geslo v telesu, PUBLISH pa ime teme in najbolj/najmanj pomembne bite imena teme. Telo seveda predstavlja koristno vsebino, infor- macijo, ki se prenaˇsa. V tabeli 2.4 je prikazan celoten pregled vsebovanosti spremenljive glave in telesa po tipih MQTT sporoˇcil.
Tip sporoˇcila Spremenljiva glava Telo
CONNECT ! !
CONNACK # #
PUBLISH ! opcijsko
PUBACK ! #
PUBREC ! #
PUBREL ! #
PUBCOMP ! #
SUBSCRIBE ! !
SUBACK ! !
UNSUBSCRIBE ! !
UNSUBACK ! !
PINGREQ # #
PINGRESP # #
DISCONNECT # #
Tabela 2.4: Vsebovanost telesa in spremenljive glave v sporoˇcilih MQTT [8].
2.4.1 Zagotavljanje kakovosti storitev - QoS
QoS ali zagotavljanje kakovosti storitev je mehanizem, ki narekuje pomemb- nost sporoˇcil, z drugimi besedami koliˇcino reˇzije, ki bo uporabljena za za- gotovitev uspeˇsnega poˇsiljanja sporoˇcila. Odjemalec, ki objavlja sporoˇcilo, posredniku definira svoj ˇzeljeni nivo kakovosti storitev, a to naredi tudi drugi odjemalec, ki je naroˇcen na ta sporoˇcila. Pri tem ima prednost odjemalec
”naroˇcnik”, in sicer ˇce on zahteva niˇzjo kakovost storitev, bo ta tudi upora- bljena. Nivoji QoS pri protokolu MQTT so trije:
• kveˇcjemu enkrat (angl. ”at most once”). Ta nivo je privzeti in ne zahteva nobene dodatne reˇzije ali ponovnega poˇsiljanja. Pogosto se mu reˇce, da je ”poˇslji in pozabi”(angl. ”fire and forget”). Sporoˇcilo bodisi prispe bodisi ne prispe na ponorno vozliˇsˇce. Nivo je preprost, kar tudi vidimo na sliki 2.2.
Slika 2.2: nivo kakovosti ”at most once”[15].
• vsaj enkrat (angl. ”at least once”). Pri tem nivoju posrednik za vsako objavo sporoˇcil (PUBLISH) zahteva tudi ustrezno potrditev (PU- BACK). ˇCe te ne dobi v natanˇcnem ˇcasovnem intervalu, potem ponovi sporoˇcilo in nastavi zastavico DUP, zato tudi ime ”vsaj enkrat”, ker se sporoˇcila lahko podvojijo. Ta princip lahko vidimo na sliki 2.3.
Slika 2.3: nivo kakovosti ”at least once”[16].
• natanko enkrat (angl. ”exactly once”). Je najviˇsji nivo in doloˇca na- tanko enkratno poˇsiljanje sporoˇcila. Vsebuje ˇstirikratno rokovanje, kar vidimo tudi na sliki 2.4. Poˇsiljatelj objavi sporoˇcilo (PUBLISH), nato od prejemnika dobi tudi ustrezno potrditev (PUBREC). Podobno kot pri prejˇsnjem nivoju, ˇce potrditve ne dobi, ponovi sporoˇcilo in nastavi zastavico DUP. ˇCe pa jo dobi, lahko odstrani originalno sporoˇcilo in poˇslje neke vrste ”potrditev prejetja potrditve”(PUBREL). Prejemnik po prejetju PUBREL paketa poˇslje ˇse PUBCOMP, ki signalizira tudi konec komunikacije [14].
Slika 2.4: nivo kakovosti ”exactly once”[17].
2.4.2 Zadrˇ zevanje sporoˇ cil – Retain
Naslednji znaˇcilni mehanizem je mehanizem zadrˇzevanja sporoˇcil. Odjema- lec lahko pri poˇsiljanju sporoˇcila zahteva njegovo shrambo ali ˇzadrˇzevanje”pri posredniku. To naredi s ponastavljanjem posebne RETAIN zastavice v sporoˇci- lu PUBLISH. Potemtakem bo to sporoˇcilo shranjeno, dokler ga ne zamenja
novejˇse sporoˇcilo, naslovljeno na isto temo, ki prav tako zahteva zadrˇzevanje.
Torej shranjevanje vrste sporoˇcil ni podprto, shranimo lahko zgolj eno.
Vsak novi naroˇcnik na temo na zaˇcetku dobi shranjeno sporoˇcilo za to temo. To je koristno predvsem za aˇzuriranje novih naroˇcnikov ali pa kadar ˇzelimo doloˇciti zaˇcetno stanje novih naroˇcnikov. ˇCe se, na primer, naroˇcimo na posrednika, ki enkrat dnevno objavi vrednost temperature ali veˇckrat dnevno vrednost GPS koordinat, bi bilo smiselno ob vklopu dobiti zadnjo vrednost, ne pa ˇsele ob novi objavi [21, 43].
2.4.3 Oporoka in ˇ cista seja – Will, Clean session
MQTT ponuja solidno zaˇsˇcito pred izpadom oz. odpovedjo komunikacijskih akterjev. Oporoka (angl. will) je funkcija, s katero odjemalec pri povezovanju s posrednikom doloˇci oporoko, poslovilno sporoˇcilo, ki se poˇslje ob njegovem izstopu iz omreˇzja. Oporoka je vsekakor podobna navadnim sporoˇcilom, saj prav tako vsebuje naslov oz. temo ter ˇzeljeni nivo QoS.
Oporoka je koristna, saj predstavlja vsaj delno podporo in zaˇsˇcito pred zasilnim zapuˇsˇcanjem omreˇzja.
Privzeto posrednik ob izstopu odjemalca shrani mnoˇzico podatkov [42].
Shrani:
• odjemalˇcevo sejo;
• vse njegove naroˇcnine;
• prejeta nepotrjena sporoˇcila (QoS nivo 1 ali 2);
• prejeta sporoˇcila po izstopu odjemalca (QoS nivo 1 ali 2);
• poslana nepotrjena sporoˇcila (QoS nivo 2).
Ce pa odjemalec tega ne ˇˇ zeli, lahko pri povezovanju izrecno zahteva ”ˇcisto sejo”(angl. clean session). S ponastavljanjem zastavice ˇciste seje v sporoˇcilu CONNECT odjemalec za vsako vnoviˇcno komunikacijo zahteva nov zaˇcetek,
brez pomnjenja podatkov. Posrednik sporoˇcil CONNACK sporoˇci novemu odjemalcu prisotnost stare seje (zastavica session present).
Moˇznost ˇciste seje nam koristi predvsem takrat, kadar imamo odjemalca, ki veˇcinoma objavlja sporoˇcila, ki redko ali pa sploh ne prejema sporoˇcil.
Priroˇcna je tudi, ko nam uspeˇsnost sporoˇcil ni bistvena.
Z druge strani se ˇcista seja odsvetuje, kadar ˇzelimo zanesljivo prejetje vseh sporoˇcil ali ko so odjemalci tehnoloˇsko omejeni in raje pomnimo podatke na posredniku [21, 43].
2.4.4 Nadomestni znaki
Odjemalci posluˇsajo ali oddajajo sporoˇcila, vezana na doloˇceno temo. Teme so sestavljene nivojsko z vmesnimi poˇsevnicami, npr. /sluˇzba/pisarna/stik alo1.
Moˇzna je tudi uporaba nadomestnih znakov (angl. wildcard). Namesto da teme referenciramo absolutno, referenciramo le obvezni del, za ostanek uporabimo nadomestni znak.
Obstajajo:
1. enonivojski nadomestni znaki (+), ki zamenjajo zgolj eden nivo v imenu teme. Npr. ˇce ˇzelimo dostopati do vseh stikal v sluˇzbi s ˇstevilko 1, se lahko naroˇcimo na temo sluˇzba/+/stikalo1;
2. viˇsjenivojski nadomestni znaki, ki zamenjajo eden ali veˇc nivojev v imenu teme. Npr. ˇce ˇzelimo dostopati do vseh stikal v sluˇzbi, se lahko naroˇcimo na temo sluˇzba/#.
Posrednik poskrbi, da se vsako sporoˇcilo, povezano z doloˇceno temo, poˇslje vsem posluˇsajoˇcim odjemalcem. Dolˇzan je tudi obvestiti naroˇcene odjemalce o spremembah tem. Odjemalec se lahko prijavi na veˇc tem, lahko pa tudi poˇsilja na veˇc tem.
Poslano viˇsjenivojsko sporoˇcilo prejmejo tudi odjemalci, prijavljeni na niˇzjih nivojih. Nivoji si sledijo z leve proti desni, z najviˇsjim nivojem na levi ter vmesno poˇsevnico [35].
2.5 Scenarij komunikacije
Slika 2.5: Scenarij komunikacije.
Na sliki 2.5 vidimo poenostavljen proces komunikacije. Vzpostavi se povezava TCP, potem odjemalec zahteva sejo MQTT s sporoˇcilom CONNECT, kar mu potrdi posrednik s sporoˇcilom CONNACK. Odjemalec se nato naroˇci na ˇzeljene teme s sporoˇcilom SUBSCRIBE, kar je spet potrjeno, tokrat s sporoˇcilom SUBNACK. Potem sledi cikel objavljanja in prejemanja vsebine, s sporoˇcili PUBLISH. Naroˇcnina se konˇca podobno kot se zaˇcne, s sporoˇciloma UNSUBSCRIBE in UNSUBACK. Cela seja se zakljuˇci, ko odjemalec poˇslje posredniku zahtevo za izklop – DISCONNECT.
MQTT sporoˇcila so zelo kratka in hitra ter delujejo po protokolu TCP na vratih 1883 (v ˇsifrirani komunikaciji na vratih 8883). Za vsako poslano sporoˇcilo poˇsiljatelj prejme povratnico o pravilni in uspeˇsni dostavi. Posre- dnik hrani vse trenutno povezane naprave in periodiˇcno poˇsilja sporoˇcilo, s katerim zahteva njihov odziv, sicer bodo izbrisani s seznama povezanih naprav.
Prednosti in slabosti protokola MQTT
3.1 Prednosti
Glavne prednosti protokola MQTT so:
• ima enostavno zgradbo, omogoˇca hitro in preprosto razvijanje lastnih reˇsitev;
• vsebuje vgrajeno kontrolo kakovosti storitev (QoS), ki je zaˇsˇcitena tudi pred odpovedjo komunikacijskih akterjev;
• ima prostorsko, ˇcasovno in sinhronizacijsko loˇcenost akterjev;
• je lahek, sporoˇcila so kratka (nekatera so dolga samo 2 bajta) in zato primerna za IoT naprave;
• podpira veˇc podatkovnih formatov;
• je priljubljen, obstajajo ˇstevilne tako poslovne kot odprtokodne reˇsitve [9].
15
3.2 Slabosti
Glavne slabosti protokola MQTT so:
• podpira zgolj objavo in naroˇcanje na sporoˇcila, ni tokov (angl. stream processing);
• podpira odprte konfiguracije, ki niso zavarovane;
• uspeˇsnost je zelo odvisna od posrednika. Posrednik diktira ska- labilnost sistema. Je tudi enotna toˇcka odpovedi, saj po vdoru na posrednika napadalec dobi kontrolo nad celotnim prometom omreˇzja.
Zato so priljubljeni tudi oblaˇcni posredniki od tretjih strank, ˇceprav s tem lahko pride do teˇzav z zakasnitvijo oz. latenco;
• ˇceprav se gre za lahek protokol, ga ne podpirajo v najboljˇsi meri neka- tere zelo tehnoloˇsko omejene naprave.
3.3 Alternative MQTT protokolu
MQTT seveda ima tudi ustrezne alternative, ki jih bomo predstavili v tem poglavju. Ogledali si bomo dva glavna tekmeca v svetu IoT komunikacije - protokol CoAp in Websocket.
3.3.1 Websocket
Slika 3.1: Protokol websocket [11].
Websocket je prva in verjetno manj ustrezna alternativa, ki jo bomo izpo- stavili. Nastala je kot izboljˇsava HTTP/1. Namesto arhitekture zahteva- odgovor zahteva enojno TCP povezavo, razliko vidimo na sliki 3.1. Na tej povezavi ustvari dvosmerni (angl. duplex) tunel med streˇznikom in odje- malcem in tako olajˇsa komunikacijo, saj odstrani potrebo po nenehno novih zahtevah. Dvosmerna narava tega protokola je idealna za IoT sisteme, kjer majhne naprave poroˇcajo o spremembah v okolju, vendar dvosmernost nove HTTP/2 razliˇcice nekako odstranjuje potrebo po Websocketu.
Ce primerjamo direktno z MQTT-jem, je prednost Websocketa njegovaˇ niˇzja latenca, saj ni centralnega posrednika, sporoˇcila potujejo od toˇcke do toˇcke. Toda MQTT prevladuje v ostalih segmentih, ker ima bistveno manj reˇzije (manjˇsi overhead), podpira poˇsiljanje na veˇc naslovov hkrati, ima me- hanizme zagotavljanja kakovosti itd. Zaradi oˇcitne premoˇci MQTT-ja se tudi ne bomo preveˇc ukvarjali z Websocketom [29].
3.3.2 CoAp
Slika 3.2: Protokol CoAp [24].
Protokol CoAp (angl. Constrained Application Protocol) je druga, bolj kon- kurenˇcna alternativa protokolu MQTT. Je aplikacijski protokol, ki manj zmo- gljivnejˇsim IoT napravam omogoˇca interaktivno, dvosmerno komunikacijo.
Komunikacija sledi principom REST. Za razliko od MQTT-ja njegov komu- nikacijski princip standardni, zahteva-odgovor. V ozadju ne uporablja TCP, ampak UDP povezavo in ponuja tako sinhrono kot asinhrono komunikacijo z uporabnikom. Tipiˇcen videz omreˇzja CoAP vidimo na sliki 3.2.
Res je, MQTT ima manjˇso glavo od 2 bajtov, CoAp vsebuje 4, vendar ravno narava UDP povezave, tj. dejstvo, da ne potrebuje stalne TCP seje, daje prednost CoAp na polju reˇzije.
Zaradi protokola UDP varˇcuje tudi na latenci, saj ga ne ovira TCP-ov poˇcasni zaˇcetek (angl. slow start). Ni rokovanja, komunikacija se izrodi po dveh paketih. CoAp nima niti potrebe po centralnem posredniku, ki upravlja s komunikacijskim procesom.
MQTT omogoˇca veˇcjo zanesljivost, saj privzeto omogoˇca veˇc nivojev QoS. CoAp tukaj ponuja alternativo – delitev sporoˇcil na tista, ki nujno zahtevajo potrditev, in sporoˇcila, ki je ne zahtevajo (angl. confirmable and non-confirmable messages).
Pomembna prednost CoAp-a je tudi njegova boljˇsa enkripcija. MQTT moˇcno sloni na enkripciji na drugih plasteh, recimo preko transportne (TLS), in ima sam po sebi zgolj mehanizme uporabniˇskega imena in gesla. CoAp ima dve metodi – DTLS in IPsec, s katerima zagotovi osnovni tip avtentikacije, celovitost in enkripcijo sporoˇcil.
Pri CoApu komunikacija poteka od toˇcke do toˇcke (angl. point to point), kar pomeni, da ni moˇznosti komunikacije veˇc proti veˇc. Kljuˇcne podobnosti in razlike so ˇse enkrat navedene v tabeli 3.1: [43, 25]
MQTT CoAP
leto izida 1999 2010
arhitektura odjemalec - posrednik odjemalec – streˇznik/odjemalec - posrednik princip komunikacije objava – naroˇcnina zahteva – odgovor
sinhronost komunikacije asinhrono sinhrono/asinhrono ˇstevnost komunikacije M : N 1 : 1
protokol TCP UDP
velikost glave 2 B 4 B
zanesljivost 3 nivoji QoS potrjevanje sporoˇcil
je ”RESTful” ne da
poraba energije malo ˇse manj
reˇzija (overhead) malo ˇse manj
varnost TLS/SSL DTLS, IPSec
Tabela 3.1: Razlike protokolov MQTT in CoAp
MQTT avtomobilski sistemi
Avtomobilska industrija se bliskovito razvija. Sodobni avtomobili so inteli- gentni sistemi, sestavljeni iz mnoˇzice zanimivih naprav. Zmoˇznost in naloga danaˇsnjih avtomobilov ni zgolj pripeljati osebo od toˇcke A do toˇcke B. Od avtomobila se zdaj priˇcakuje 360 stopinjski pregled okolice, dinamiˇcno sve- tovanje, spremljanje stanja vozila, avtomatsko kontaktiranje proizvajalca, mehanika, reˇsevalnih sluˇzb in podobne olajˇsave.
Avtomobil je neke vrste ekosistem tesno povezanih IoT naprav. Eden od najbolj popularnih naˇcinov povezovanja IoT naprav je prav z uporabo protokola MQTT. Trend MQTT-ja v avtomobilizmu je posebej aktualen v zadnjih ˇcasih. Svetovni giganti kot su BMW, Daimler, Audi se za implemen- tacije najbolj sodobnih sistemov radi zanaˇsajo na MQTT hrbtenico. Neka- tera podjetja, kot so HiveMQ, flespi in Solace se celo aktivno fokusirajo na to niˇso, in so povsem osredotoˇceni na industrijsko uporabo protokola MQTT.
MQTT glede na sploˇsno rabo v avtomobilih delimo na tri loˇcene tipe sistemov:
1. Telemetrijski sistemi (slika 4.1) – ki se osredotoˇcajo na zbiranje podat- kov iz avtomobila in njegove okolice, potem pa jih posredujejo v analizo in obdelavo.
21
Slika 4.1: Arhitektura telemetrijskih sistemov [39].
2. Interaktivni sistemi (slika 4.2) – ki vozniku predstavijo avtomobil v obliki interaktivnega grafiˇcnega vmesnika in mu omogoˇcijo pestre funk- cionalnosti.
Slika 4.2: Arhitektura interaktivnih sistemov [37].
3. Sistemi nujnih opozoril (slika 4.3) – ki se sproˇzijo ob nevarnostih, da npr. opozorijo voznika na bliˇzajoˇco se nevihto, ali pa sproˇzijo varnostni sistem, da se je zgodila prometna nesreˇca.
Slika 4.3: Arhitektura sistemov nujnih opozoril [38].
V nadaljevanju predstavljamo najbolj pogoste in najbolj zanimive primere uporabe MQTT-ja pri avtomobilih.
4.1 Vzdrˇ zevanje vozil
Ko govorimo o uporabi protokola MQTT v avtomobilski industriji, je osrednji primer nedvomno pametno vzdrˇzevanje vozil.
Vzdrˇzevanje motornih vozil je cikliˇcen proces. Na sploˇsno je priporoˇcljivo avtomobil servisirati letno oz. pribliˇzno vsakih 10 000 km. To je tudi pogla- vitni problem klasiˇcnega vzdrˇzevanja avtomobila. Tudi, ˇce je naˇs avtomobil brez okvar, to z gotovostjo lahko izvemo samo po opravljenem servisu. Av- tomobil pa bi ˇzeleli servisirati samo takrat, kadar je to res potrebno (s pou- darkom na pregovoru ”bolje prepreˇciti, kot zdraviti”). Poleg tega je obˇcasno pomemben del avtomobila pokvarjen, le da to zvemo, ko je ˇze prepozno – ni povratne informacije. To pa nasprotuje naˇcelom sodobnega avtomobila, saj bi ˇzeleli, da avtomobil samostojno opravlja doloˇcene diagnostiˇcne funkcije.
Eno izmed moˇznih zdravil za predhodno opisano teˇzavo je povezan sistem IoT senzorjev. Sistem zbira podatke avtomobila preko senzorjev, posreduje zalednem delu na procesiranje in analizo in na koncu obvesti konˇcnega upo- rabnika, ˇce je poseg res potreben.
Seveda, glede na IoT naravo problema, stremimo k vedno najbolj go- spodarni in uˇcinkoviti reˇsitvi. Protokol MQTT je zaradi svojih lastnosti,
porazdelitve bremena, principa objave in naroˇcanja ter lahke zgradbe zelo primeren kandidat za povezovanje takˇsnega sistema [9].
Slika 4.4: Arhitektura pametnega vzdrˇzevanja avtomobila (G. Panga in so- delavci) [27].
Povzeli bomo zgradbo takˇsnega sistema, opisano v ˇclanku G. Pange in sodelavcev [28]. Grafiˇcen prikaz sistema je na voljo na sliki 4.4.
• senzorji, aktuatorji in ostale naprave poˇsiljajo rezultate elektronski kr- milni enoti (angl. ECU) preko standardiziranega vodila za vozila (angl.
CAN bus);
• enota za nadzor in krmiljenje (angl. MCU) te podatke prestreˇze in jih surove posreduje Raspberry Pi napravi (v vlogi MQTT odjemalca) preko serijske povezave (RS232 ali Bluetooth);
• Raspberry Pi podatke objavi MQTT Mosquitto posredniku;
• spletni streˇznik je naroˇcen na podatke vozila in jih naloˇzi s posrednika;
• podatke dekodira v ˇcloveku berljivo obliko;
• konˇcni uporabnik lahko dostopa do streˇznika ter dobi vpogled v more- bitne teˇzave v svojem vozilu.
Slika 4.5: Arhitektura pametnega vzdrˇzevanja avtomobila (R.Dhall in V.Solanki) [40].
Podobno implementacijo lahko vidimo v delu R. Dhalla in V. Solankija [9], katerih zgradbo vidimo na sliki 4.5.
• podatki senzorjev se posredujejo Eclipse Kuri (IoT gateway), bodisi preko mobilnih podatkov bodisi Wi-Fi omreˇzja;
• IoT gateway podatke objavi MQTT posredniku v oblaku (v tem pri- meru Eclipse Mosquitto);
• MQTT posrednik obvesti naroˇcnike o novoprispeli objavi;
• naroˇcniki so obveˇsˇceni preko Eclipse Paho vmesnika, izvedejo validacijo in elementarne pretvorbe;
• potem se izvede obdelava podatkov, analiza in obveˇsˇcanje;
• postopek se lahko naredi poljubno kompleksen. Lahko se vpelje sporoˇcilni sistem (Apache Kafka), sistem za obvladovanje tokov sporoˇcil (Apache Storm), sistem za obvladovanje podatkov (Hadoop) . . .
Konstrukcija ni brezhibna. Potrebno se je zavedati, da aktivna uporaba mnoˇzice senzorjev ˇse poveˇca ceno avtomobila. Prenos podatkov je lahko pro- blematiˇcen, saj so vˇcasih podatki zakonsko zaˇsˇciteni in se ne morejo hraniti v oblaku. Komunikacijski kanal mora biti ves ˇcas zavarovan, ker se prenaˇsajo visoko zaupni podatki.
Ce povzamemo, je moˇˇ znost samodiagnostike in dinamiˇcnega vzdrˇzevanja motornega vozila danes skoraj predpogoj pri avtomobilskih podjetjih. Veˇcina proizvajalcev avtomobilov danes praviloma vkljuˇcuje takˇsne in podobne sis- teme v svoje izdelke. Protokol MQTT je prav za te namene izjemno primeren in je zato tudi pogosta izbira pri implementaciji takˇsnih sistemov.
4.2 Spremljanje prometa
Slika 4.6: Spremljanje prometa s pomoˇcjo protokola MQTT [20].
Funkcionalnost, ki se lahko bistveno olajˇsa z uporabo MQTT-ja je spremlja- nje prometa (angl. traffic monitoring). Povzeli bomo zgled raziskovalcev, ki so primerjali uˇcinek spremljanja prometa z MQTT arhitekturo ter jo primer- jali z CoAp arhitekturo.
Zgled je sestavljen iz veˇc postaj, ki so v kontekstu MQTT-ja posredniki in naroˇcniki, in veˇc avtomobilov, ki so poslediˇcno odjemalci. Ko avtomobil spelje mimo postaje, objavi svoje parametre (npr. hitrost). Hitrost se posre- duje posredniku (postaja), ki potem obvesti naroˇcnika (postaja). Naroˇcnik pridobi vrednost hitrosti in jo potem obdela na poljuben naˇcin. Proces lahko vidimo na sliki 4.6.
Cilj je bil izmeriti zakasnitev, deleˇz izgubljenih sporoˇcil ter porabljeno moˇc za oddajo sporoˇcil. Zgled je tudi imel dva parametra – nivo QoS ter ˇstevilo avtomobilov, ki spelje mimo postaje v 10 sekundah.
MQTT se je izkazal kot zelo zanesljiv, brez kakrˇsnih koli izgub paketov. V povpreˇcju je porabil tudi obˇcutno manj energije, kar se lahko pripiˇse njegovi zgradbi in principu delovanja brez konstantnih zahtev. Vendar je pomembno tudi omeniti, da je imel v tem primeru CoAp v povpreˇcju krajˇse zakasnitve [31].
4.3 Hitrejˇ si prihod reˇ sevalnih vozil
Ko je kdo ˇzivljenjsko ogroˇzen, so lahko minute ali celo sekunde usodne. Sku- pina raziskovalcev iz Juˇzne Afrike je predloˇzila sistem, ki omogoˇca takojˇsnje posredovanje v prometno signalizacijo. Mikrokrmilnik je priklopljen na se- mafor. Z modemom GSM je omogoˇcena povezava do zunanjega sveta, v tem primeru s poenostavljeno mobilno aplikacijo.
Z aplikacijo lahko uporabnik, denimo reˇsevalec, v ˇcasu velike gneˇce zah- teva preklop in spremembo prometne signalizacije. Vsi okoliˇski semaforji na kratko postanejo rdeˇci, potem pa se vklopijo samo tisti, ki jih je zahteval reˇsevalec. Po uspeˇsni uporabi reˇsevalec semaforje resetira na prvotne nasta- vitve. MQTT pa zanesljivo in dovolj hitro izvede prenos zahtev (reˇsevalec – mobilni telefon – mikrokrmilnik – semafor) [22].
4.4 Sistem proti puˇ sˇ canju otroka v vozilu
Obstajajo tudi sistemi MQTT, ki odpravljajo ˇzivljenjske nevarnosti. Na ˇzalost je realnost, da ˇse vedno obstajajo neodgovorni starˇsi, ki puˇsˇcajo majhne otroke same in nenadzorovane v vozilu. Prav zaradi tega so raziskovalci z Univerze v Michiganu naˇcrtovali sistem, ki prepreˇcuje takˇsno dejanje.
Sistem vsebuje registracijski vmesnik, ki pred uporabo zahteva povezo- vanje uporabnika z vozilom. Vozilo vkljuˇcuje mnoˇzico senzorjev, ki lahko zaznajo, kdaj je otrok sam v vozilu, v ˇcasu visoke zunanje temperature (delo drugih neodvisnih raziskovalcev). ˇCe je zaznana nevarnost, se poˇslje nujno MQTT sporoˇcilo v oblak. V oblaku je pa program, ki je preko MQTT-ja naroˇcen na vsa registrirana vozila. Ko program-naroˇcnik prejme obvestilo, takoj poˇslje SMS konˇcnemu uporabniku in ga tako opozori na nevarnost [32].
4.5 Pametni prometni znaki
Pametni prometni znaki so v bistvu logiˇcno nadaljevanje digitalnih prometnih znakov. Podobno kot pri digitalnih prometnih znakih je znak prilagodljiv in ima spremenljivo vsebino, le da ima dodano vrednost, da se hkrati prilagaja tekoˇcem dogajanju v realnem ˇcasu (zastoji, prometne nesreˇce, neurje) in sprejema tudi ukaze zunanjega uporabnika.
A. Shaout in A. Hassani sta naredila prototip takˇsnega sistema. Sistem je hipotetiˇcen, namiˇsljen oz. zgolj simuliran. Naˇcrtovan je mikrokrmilnik (pametni znak), ki je povezan z zunanjim svetom, ima senzorje, s katerimi lahko izmeri temperaturo in vlago, ter zaslon LCD. Poleg tega je zahtevano MQTT omreˇzje, pri ˇcemer bo posrednik shranjeval in stregel izraˇcune.
Vozila so generirana psevdo-nakljuˇcno z izraˇcunanim potovalnim ˇcasom.
Pri izraˇcunu upoˇsteva tudi stare potovalnih ˇcase drugih vozil, ki jih pridobi z MQTT poizvedovanjem. Ko izraˇcuna lastni potovalni ˇcas, ga tudi poˇslje posredniku MQTT. Na koncu osveˇzi zaslon LCD z najnovejˇsimi podatki.
Mikrokrmilnik izvaja tudi klasiˇcne meritve. Medtem ko raˇcuna potovalni ˇcas, izmeri temperaturo in vlago ter spet posodobi zaslon LCD.
Zadnja funkcionalnost pametnega znaka je ta, da je odprt zunanjem upo- rabniku. Zunanji uporabnik (operater, opazovalec prometa, redar) lahko vnese ˇzeljeno opozorilo za voznike. Opozorilo je posredovano kot sporoˇcilo MQTT, na katerega je naroˇcen pametni znak. Po prejetju tega sporoˇcila se naloˇzi nova vsebina na zaslonu LCD [33].
4.6 Parking
ˇSe eno moˇzno podroˇcje uporabe protokola MQTT je na parkiriˇsˇcih in v par- kirnih hiˇsah. Velika parkiriˇsˇca so, ˇse posebej v ˇcasu guˇzve, nepregledna in nejasna. Voznik nima celoten pregled nad njimi in se ne zaveda prostih mest.
Z ˇzeljo, da bi poveˇcali uˇcinkovitost velikih parkiriˇsˇc so izdelani sistemi, ki olajˇsajo njihovo uporabo.
Sprva so ti sistemi uporabljali infrardeˇce senzorje in Wi-Fi omreˇzje. ˇCeprav so uspeˇsno opravljali osrednjo nalogo, imeli so pa dve kljuˇcni pomanjkljivosti:
• uporabljali so protokol HTTP. Kljub svoji svestranskosti na sploˇsno, HTTP ni idealna izbira za to nalogo. Enostavno zaradi svoje zgradbe ni dovolj gospodaren v IoT reˇsitvah, niti dovolj skalabilen. Pogreˇsani so tudi mehanizmi QoS.
• imeli so dokaj visoke zakasnitve v predstavljanju podatkov konˇcnem uporabniku
Slika 4.7: Arhitektura parking sistema [30].
P. Dhar in P. Gupta sta predloˇzila zdravilo tema izzivoma. HTTP hrb- tenico je treba zamenjati z MQTT-jem. Sistem zajema mikrokrmilnik, in- frardeˇce senzorje ter aplikacijo z grafiˇcnim vmesnikom. Grafiˇcni vmesnik slikovito ponazarja konˇcnem uporabniku stanje parkirnih mest. Sistem je videti pribliˇzno kot slika 4.7.
Uporabnik lahko zahteva posamezno parkirno mesto. Mnoˇzica infrardeˇcih senzorjev skrbi za dejansko potrditev zapolnjenosti parkirnega mesta. To potrditev objavi mikrokrmilnik nadleˇznemu posredniku MQTT. Posrednik obvesti aplikacijo, s tem pa je zapolnjeno parkirno mesto vneseno v sistem, poslediˇcno pa grafiˇcni vmesnik posodobljen. Ob zapuˇsˇcanju parkirnega mesta je na podoben naˇcin to posodobljeno in prikazano kot prosto [10].
Podobno implementacijo lahko najdemo v delu K. Hantrakula in sode- lavcev, le da so se oni odloˇcili za ultrasoniˇcne senzorje [12].
4.7 Izposoja vozil
Ceprav so sodobni avtomobili bolj in bolj navdihujoˇˇ ci, je dejstvo, da so ˇse vedno izjemno dragi izdelki. Mogoˇce kot posamezniki vˇcasih rabimo veˇcjo mobilnost, a ne ravno ves ˇcas. Poleg tega s postopno urbanizacijo mesta postajajo masivna, prometna gneˇca je v popoldanskih urah na glavnih cestah in obvoznicah skoraj nepogreˇsljiva.
Vse naˇsteto je zagotovo pomagalo hitri popularizaciji storitev izposoje vozil (avtomobili, elektriˇcni skiroji in pod.). Danes so na voljo porazdeljeni sistemi, ki za sorazmerno malo denarja omogoˇcajo uporabniku zaˇcasno iz- posojo, v veˇcini primerov elektriˇcnega avtomobila ali elektriˇcnega skiroja.
Uporabnik se prijavi in zasede vozilo. Po uporabi elektronsko plaˇca stori- tve, se odjavi in, skoraj kjer koli, pusti vozilo, ki je potem na voljo drugim uporabnikom za izposojo. Princip je enostaven, izpeljava pa je lahko dokaj kompleksna. Na kratko bomo izpostavili primer – Boltov sistem izposoje vozil.
4.7.1 Bolt
Slika 4.8: Arhitektura Boltovega sistema za izposojo vozil [45].
Bolt je estonsko podjetje, ki se ukvarja z mobilnostjo. Osredotoˇceni so na dostavo hrane in izposojo vozil. Prvotno je njihov sistem izposoje vozil te- meljil na standardnem protokolu HTTP, vendar je s poveˇcanim ˇstevilom uporabnikov natanˇcno sledenje vozil postalo zelo teˇzavno in zamudno. To jih je tudi opogumilo k naˇcrtovanju nove arhitekture s protokolom MQTT, saj je MQTT, kot smo razloˇzili v prejˇsnjih poglavjih, veliko bolj primeren za skaliranje.
Namesto nakupa tujih IoT naprav so sestavili lastno, ki pretvori elektriˇcni skiro v odjemalca MQTT. Za vse odjemalce MQTT skrbi centralni MQTT posrednik, kar je konkretno node.js implementacija posrednika s poudarkom na zmogljivosti in stabilnosti – Aedes.
Posrednik je potem ”multipliciran”in porazdeljen na veˇc posrednikov, s tem je prepreˇcena enotna toˇcka odpovedi sistema. Za reˇzijo instanc posre- dnika poskrbi Redis (QoS, potrjevanje sporoˇcil, ”medposredniˇsko”poˇsiljanje).
Cel sistem je zapakiran kot enotna storitev in pred njim je postavljen program za uravnoteˇzenje obremenitve (angl. load-balancer) AWS-NLB, ki pribliˇzno enakomerno porazdeli obremenitev na posamezne MQTT posre- dnike [46]. Strukturo sistema vidimo na sliki 4.8.
4.8 Primeri v industriji
4.8.1 BMW
Od leta 2014 je podjetje HiveMQ strateˇski partner podjetja BMW. BMW vsako svoje novo vozilo poveˇze s svojimi BMW Mobility storitvami. BMW Mobility storitve so mnoˇzica izdelkov, ki omogoˇcajo upravljanje flote. Moˇzno je izvajati oddaljene ukaze, npr. zakleniti/odkleniti vozilo, zbirati analitiˇcne ali pa diagnostiˇcne podatke. Vsako vozilo je loˇcen MQTT odjemalec, ki komunicira z osrednjim BMW/HiveMQ posrednikom. Poˇsilja mu razliˇcne referenˇcne podatke, ki so potem natanˇcno agregirani in obdelani.
BMW se je tudi preizkusil na trgu izposojanja avtomobilov, kar se lahko vidi v njihovem produktu DriveNow (danes je zdruˇzen z Daimlerjevimcar2go).
Spet je vsak avtomobil loˇceni MQTT odjemalec. Stranka izrazi namen iz- posoje avtomobila, potem se zahteva posreduje od posameznega avtomobila do BMW-jevega centralnega posrednika, ki jo obdela in bodisi potrdi bodisi zavrne [41].
4.8.2 Daimler
Tudi znano nemˇsko avtomobilsko podjetje Daimler ima v ospredju protokol MQTT. Daimlerjevi inˇzenirji so namreˇc, pionirji v polju telematike.
Slika 4.9: Podatki vozil, ki jih zbira Fleetboard ter njihova grafiˇcna uprizo- ritev v aplikaciji [1].
Njihova reˇsitev Fleetboard je bistvena olajˇsava pri vsakem upravljanju flote. Grobo gledano s senzorji opremi veliko ˇstevilo avtomobilov, najpogo- steje tovornjakov. Ti nenehno poˇsiljajo relevantne podatke zalednem delu sistema. Podatki se hranijo in jih je moˇzno grafiˇcno prikazati in analizi- rati preko grafiˇcnega vmesnika. Nekaj tipiˇcnih podatkov in videz aplikacije Fleetboard vidimo na sliki 4.9.
Poslediˇcno imajo skrbniki sistema skoraj ves ˇcas vpogled, kje se nahajajo vozila v lasti podjetja, v katero smer gredo, kako hitro se gibajo, maso, ki- lometrino in podobno. Zelo pomemben parameter je tudi poraba goriva.
Takˇsen sistem omogoˇca nagrajevanje tistih z bolj varˇcnim stilom voˇznje.
Skratka, ti podatki najbolj pogosto minimizirajo stroˇske, vnaprej naˇcrtujejo popravila vozila in na sploˇsno nudijo dober pregled logistiˇcne operacije.
Poleg tega se ukvarjajo z razvojem interaktivnih aplikacij, s katerimi je avtomobil direktno povezan s konˇcnim uporabnikom. Pravi primer je apli- kacija Mercedes Me, vidna na sliki 4.10. Za razliko od prejˇsnjega primera je tukaj komunikacija dvosmerna; uporabnik poˇsilja zahteve v eni smeri, ampak avtomobil podaja informacije tudi v drugi smeri.
Slika 4.10: Izgled aplikacije Mercedes Me [36].
Prej so bili takˇsni sistemi omejeni in aktivni samo takrat, ko je avtomobil deloval. Toda s prihodom 5G omreˇzja in boljˇsih baterij je avtomobil lahko skoraj nenehno povezan s konˇcnim uporabnikom, tudi takrat, ko je ugasnjen.
Podobno kot Fleetboard, spremlja uˇcinek in delovanje kljuˇcnih avtomobilskih delov. Ko so ti pokvarjeni, je uporabnik pravoˇcasno obveˇsˇcen in potencialno naroˇcen na servisni pregled. Z aplikacijo Mercedes Me je avtomobil moˇzno oddaljeno odkleniti, zagnati ali ugasniti. Tlak v pnevmatikah zgolj prebe- remo iz aplikacije, ˇzeljeno temperaturo nastavimo pred vstopom v avtomobil.
Aplikacija nam lahko iz mnoˇzice podatkov celo analizira stil voˇznje in nam svetuje, ˇce smo dovolj pogumni, pa tudi parkira vozilo.
Varnostni vidik protokola MQTT, ter MQTT
avtomobilskih sistemov
5.1 Pomen varnosti
Neredko sta raˇcunalniˇska varnost in koristnost gledana kot dve loˇceni kate- goriji. Cilj vsakega raˇcunalniˇskega sistema je maksimizirati obe, oz. najti ustrezno ravnovesje, sistem mora uspeˇsno opravljati naloge, a hkrati mora biti varen [19]. Raˇcunalniˇska varnost IoT naprav, tehnologij in protokolov zaradi eksponenˇcne popularizacije IoT naprav hitro postaja kljuˇcna razvijal- ska preglavica. Zavarovati limitirano napravo, kateri je, ˇce malo pretiramo, vsaki bit in procesorski cikel kljuˇcen, lahko predstavlja kar izziv.
Varnost protokola MQTT je eno kljuˇcnih vpraˇsanj, ki se pojavi pri nje- govi uporabi. Privzeto je protokol MQTT odprt, nima direktno vgrajenih kompleksnih varnostnih mehanizmov, ki bi prepreˇcili komuniciranje s posre- dnikom, objavo sporoˇcil na teme ali pa njihovo branje.
Celo uradna dokumentacija protokola pravi: ”MQTT je transportni pro- tokol in je zadolˇzen samo za poˇsiljanje sporoˇcil. Implementacija ustreznih varnostnih mehanizmov je odvisna od konteksta in je razvijalˇceva odgovor-
35
nost”[4]. Torej se je potrebno zavedati, da varnost ni eden od temeljev pro- tokola MQTT.
Edini vgrajeni varnostni mehanizem je uporaba uporabniˇskega imena in gesla, toda sta oba posredovana v neˇsifrirani obliki, kot ˇcistopis (angl. clear- text). Zato MQTT svojo varnost v glavnem zagotovi na drugih komunikacij- skih plasteh, kar je tudi smiselno, saj je danes veˇcplastna zaˇsˇcita predpogoj raˇcunalniˇski varnosti.
5.2 MQTT varnostni mehanizmi
V nadaljevanju so predstavljeni osnovni varnostni mehanizmi, ki se upora- bljajo skupaj z MQTT-jem: [18]
• uporabniˇsko ime in geslo;
• enkripcija sporoˇcil SSL/TLS;
• uporaba navideznega zasebnega omreˇzja (VPN) za oddaljen dostop;
• uporaba certifikata za komunikacijo.
5.2.1 Aplikacijska plast
Priporoˇceno je, da se pri vsakem sistemu z MQTT uporabi vsaj uporabniˇsko ime in geslo, kar predstavlja osnovni tip zaˇsˇcite in osnovo za ostale. Toda ob privzeti povezanosti z omreˇzjem sporoˇcil MQTT res ni teˇzko prestreˇci.
Z enostavnim posluˇsanjem sporoˇcil preko orodij, kot je Wireshark, lahko napadalec ujame prenos uporabniˇskega imena in gesla v ˇcistopisu. S tem je v celoti prizadeta zaupnost podatkov.
5.2.2 Transportna plast
MQTT povezava poteka na podlagi povezave TCP. Praviloma je pametno namestiti standardno enkripcijo za TCP povezave – SSL/TLS, ki sporoˇcila MQTT zakriptira na poˇsiljateljevi strani ter odkriptira na prejemnikovi strani.
Teˇzava nastane, ker veˇcina krmilnikov ni dovolj zmogljiva in hitra za ˇsifriranje sporoˇcil MQTT ali za uporabo certifikata pri komunikaciji. SSL ni lahek standard, doda nekaj reˇzije.
5.2.3 Omreˇ zna plast
Za izboljˇsano varnost je potrebna uporaba certifikata za komunikacijo.
Ce bi pa ˇˇ zeleli imeti ˇse boljˇso varnost, npr. za neki oddaljen dostop do sistema, je priporoˇcljivo dodati ˇse navidezno zasebno omreˇzje VPN (angl.
Virtual private network) [35].
5.3 Varnostni mehanizmi
Najpomembnejˇsi varnostni mehanizmi vkljuˇcujejo zaupnost podatkov, raz- poloˇzljivost, celovitost in zasebnost. Trenutna izvedba MQTT zagotavlja samo avtentikacijo in avtorizacijo, zaˇzeljena bi pa bila ˇse vsaj enkripcija [3].
5.3.1 Avtentikacija
Avtentikacija je proces preverjanja identitete uporabnika pred uporabo sis- tema. Avtentikacija je zagotovljena znotraj protokola MQTT. Odjemalci pri svojem posredniku zahtevajo povezavo do posrednika s paketom CONNECT in se mu predstavijo z uporabniˇskim imenom in geslom. Teˇzava avtentikacije, je da je popolnoma neobvezna ter da ni privzeto ˇsifrirana [3].
5.3.2 Avtorizacija
Avtorizacija je postopek dodeljevanja ustreznih pravic avtenticiranemu upo- rabniku. Izvirni MQTT privzeto ne doloˇca mehanizmov avtorizacije, naloga je spet prepuˇsˇcena razvijalcu. To pomeni, da se s privzeto konfiguracijo vsak avtenticirani odjemalec lahko naroˇci na poljubno temo in tudi na njo objavi poljubno vsebino, kar je lahko izjemno nevarno.
MQTT odjemalci niti nimajo velike mnoˇzice moˇznih pravic/zahtev. Lahko objavljajo in se naroˇcajo na sporoˇcila, lahko zahtevajo trajno sejo, lahko zahtevajo nivo QoS, lahko zahtevajo oporoko ter lahko ustvarjajo nove teme.
Posrednik implementira avtorizacijo, onemogoˇci oz. delno ali v celoti omogoˇci storitve in se predvsem osredotoˇca na dodeljevanje pravic za objavo in naroˇcanje na temo, saj je to dejavnost, ki lahko povzroˇci najveˇc ˇskode.
Pri tem je ena izmed dobrih praks omejevanje odjemalca na teme, ki vsebujejo njegovo identifikacijsko ˇstevilko (angl. ID). Npr. odjemalec z ID- jem 123 se lahko naroˇci samo na njegove ”podteme” client123/car/speed, client123/car/temperature[3, 13].
5.3.3 Potencialne nevarnosti
Glavni vzroˇcnik varnostnih teˇzav danes, zlasti v IoT paradigmi, je pomanj- kljiva ali privzeta konfiguracija. Streˇznik MQTT s privzeto, nezavarovano konfiguracijo, je zelo slaba praksa, lahko tudi reˇcemo, da gre za odprto va- bilo napadalcem. V tem primeru lahko kdor koli, ki ima dostop do streˇznika, dobi dostop do prav vseh sporoˇcil, ki teˇcejo preko njega. V nadaljevanju predstavljamo par tipov napadov.
Razpoloˇzljivost - Napad zavraˇcanja storitev (angl. DoS)
Slika 5.1: Prikaz napada zavraˇcanja storitev.
Razpoloˇzljivost je tudi pomembno naˇcelo – podatki naj bi bili dostopni, kadar jih uporabniki ˇzelimo. Razpoloˇzljivost MQTT omreˇzja lahko direktno ovirajo dobro znani napadi zavraˇcanja storitev (angl. denial of service, DoS).
Napadalec preplavi posrednika MQTT s ˇstevilnim zahtevam CONNECT.
Cilj je obremeniti posrednikov medpomnilnik in tako upoˇcasniti komunikacijo dejanskih uporabnikov MQTT omreˇzja do te mere, da je neuporabna.
Posrednik bo skuˇsal zadovoljiti vse CONNECT zahteve ter vsem poslati potrditveno CONNACK sporoˇcilo, saj ne more razloˇciti med resnimi in zlona- mernimi CONNECT zahtevami. ˇCe napadalec ˇzeli ovirati toˇcno doloˇcenega uporabnika, potem se bo ˇstevilˇcno naroˇcil na iste teme in s tem upoˇcasnil najprej posrednika, nato pa ciljanega uporabnika [5, 3]. Napad je slikovito prikazan na sliki 5.1.
Celovitost - Napad z vrivanjem (angl. Man in the middle)
Slika 5.2: Prikaz napada zavraˇcanja storitev.
Celovitost naˇsega sporoˇcila pomeni, da je v celoti ohranjeno od izvora do ponora ter da ni priˇslo do sprememb s strani tretjih oseb. Zaradi privzete odprte strukture se lahko naruˇsi tudi celovitost, npr. z napadi z vrivanjem.
Tipiˇcni princip napada ostaja isti – med dva komunikacijska akterja, ki se pogovarjata, se vrine tretji – napadalec. Oba mislita, da komunicirata med seboj, vendar v resnici komunicirata zgolj z napadalcem, ki se predsta- vlja kot drugi akter. ˇCe pa nam uspe ostale odjemalce prepriˇcati, da smo njihov posrednik MQTT, potem smo v celoti prevzeli nadzor nad doloˇcenim omreˇzjem MQTT.
Poenostavljen potek napada lahko vidimo na sliki 5.2. Napadalec prviˇc izve IP naslove odjemalca in usmerjevalnika. Za tem izvede t. i. zastru- pitev naslovov ARP (angl. ARP poisoning). Poˇsilja ponarejena sporoˇcila
ARP in prepriˇca odjemalca, da je usmerjevalnik, usmerjevalnika pa, da je odjemalec. Nato lahko vsak paket ˇzrtve preusmeri na dejanski MAC naslov usmerjevalnika, medtem pa lahko nemoteno prisluˇskuje prometu, ne da bi se ga opazilo.
5.4 Kako se ustrezno zaˇ sˇ cititi?
Za zaˇcetek bi bilo smiselno vkljuˇciti vse omenjene varnostne mehanizme.
Torej, govorimo o uporabniˇskih imenih in geslih, enkripciji SSL, omreˇzjih VPN in certifikatih. Namesto privzetih vrat 1883, uporabimo vrata 8883, ki podpirajo SSL/TLS. Uporabimo ˇse odprtokodni MQTT posrednik po lastni izbiri: Mosquitto, VerneMQ, emqtt in podobno. ˇZe pri tem imamo dovolj zaˇsˇciteno omreˇzje za domaˇco uporabo.
Ce gre za komercialno uporabo, potem postane kljuˇˇ cna konfiguracija MQTT posrednika. Pri poslovnih reˇsitvah je priporoˇcljivo uporabljati ˇze te- stirane in uspeˇsne poslovne MQTT posrednike, ki so po navadi tudi plaˇcljivi.
Med njih sodijo HiveMQ, Bevywise, CrystalMQ in podobni.
Kot vidimo je varnost MQTT-ja pogosto difuzija odgovornosti, nalogo prepustimo drugim plastem, ali programom.
Po mnenju nekaterih strokovnjakov to ne zadoˇsˇca navadnim varnostnim zahtevam za protokole.
Po R. Neissu, G. Steriju in R. Baldiniju mehanizmi varnostnega krmilje- nja, ki jih ponuja MQTT, niso zadostni. Pravijo da IoT omreˇzja nujno rabijo anonimizacijo in zakrivanje podatkov ter dinamiˇcno, spremenljivo varnostno politiko. Obenem tudi ponujajo lastno reˇsitev, modelno-usmerjen varnostni dodatek protokolu MQTT, imenovan SecKit. Ta skrbi za zaupnost in zaˇsˇcito podatkov [26, 23].
Drugi strokovnjaki, M. Singh, M.A. Rajan in sodelavci so naredili izpe- ljavo oziroma izboljˇsavo protokola MQTT – SMQTT. SMQTT je enostaven in temelji na atributni enkripciji preko eliptiˇcnih krivulj. SMQTT izpusti TLS certifikate, saj zahtevajo preveˇc reˇzije za doloˇcene IoT reˇsitve [34, 23].
Praktiˇ cni primeri
6.1 Zaznavanje trkov
Ogledali si bomo tipiˇcen primer uporabe protokola MQTT v avtomobilskem svetu. Ideja tega dela je na ”grobo” pokazati, kako bi bila videti diagno- stiˇcna funkcionalnost zaznavanja avtomobilskih trkov – od senzorja do po- srednika do konˇcnega uporabnika. Programska implementacija primera, z vidika Python programov, je dostopna v Github repozitoriju [6].
Moramo opozoriti, da bistvo tega primera ni v konkretni uporabnosti, saj to niti ni bila tema dela. Bistvo dela je samo predstaviti tipiˇcen tok podatkov MQTT verige. Primer bomo tudi oplemenili s kratkim varnostnim pregledom.
Uporabljeni algoritem za zaznavanje trkov je moˇcno poenostavljen in se ne more zanesljivo uporabiti v resniˇcnem ˇzivljenju. ˇCe bi pa ˇzeleli bolj sofisti- cirano zaznati trk, bi se obrnili k resnejˇsemu algoritmu, kot je npr. algoritem s Kalmanovim filtrom M. Amina in sodelavcev [2].
Za zaˇcetek si pripravimo razvojno okolje. Uporabili bomo Kali distribu- cijo Linux operacijskega sistema. Z znanim ukazom apt-get update poso- dobimo vso obstojeˇco programsko opremo. Potem si namestimo programski paket Mosquitto, in sicer tako posrednika kot pomoˇzne programe za objavlja-
43
nje in naroˇcanje na sporoˇcila. Programsko orodje za spremljanje omreˇznega prometa Wireshark je privzeto vkljuˇceno v Kali distribucijo, poslediˇcno nam le-tega ni potrebno izrecno namestiti. Podobno velja za program Python.
sudo apt-get update
sudo apt-get install mosquitto
sudo apt-get install mosquitto-clients
6.1.1 Arhitektura omreˇ zja
Slika 6.1: Arhitektura senzornega sistema.
Slikovit prikaz naˇcrtovanega sistema vidimo na sliki 6.1. Naˇs senzorni sistem vsebuje 5 naprav, in sicer:
1. SensorTag CC2650 (B0:B4:48:C9:B9:01) – je varˇcljiva naprava, ki jo proizvaja ameriˇsko podjetje Texas Industries. Vsebuje mnoˇzico senzor- jev: pospeˇskometer, ˇziroskop, senzor za temperaturo, pritisk, svetlobo itd. Vse zaznane podatke naprava preko Bluetootha poˇsilja mobilnem telefonu oz. aplikaciji SensorTag (avtorji aplikacije so prav tako podje- tje Texas Industries).
2. Mobilni telefon Xiaomi Mi A2 (192.168.43.28) - zaradi dejstva da po- datki prihajajo iz avtomobila, je povezan na internet preko 4G tehnolo- gije. Na njemu teˇce aplikacija SensorTag. SensorTag slikovito prikazuje prihajajoˇce podatke in omogoˇca njihovo posredovanje preko MQTT-ja.
V naˇsem primeru to tudi naredi in jih posreduje prenosniku Lenovo.
3. Lenovo T550 (192.168.43.47) - prenosnik, ki dostopa do interneta s pomoˇcjo Wi-Fi dostopne toˇcke (angl. Wi-Fi hotspot), ki mu jo deli tele- fon. Na njemu teˇce navidezni raˇcunalnik Kali, v njemu pa posrednik in odjemalec MQTT, oba napisana v programu Python. Ob prihodu po- datkov odjemalec jih shrani v lokalno podatkovno bazo SQLite3. Med shranjevanjem se tudi izvede ” zaznavanje trkov”na najbolj poenosta- vljen naˇcin. V primeru suma na trk, se posreduje opozorilo oddalje- nemu posredniku.
4. Oddaljeni posrednik HiveMQ (7db78138fe46481fac320cc9911d3275 .s1.eu.hivemq.cloud) - enostavni, zasebni, brezplaˇcni posrednik MQTT, ki ga ponuja nemˇsko podjetje HiveMQ. Posrednik je javno dostopen na spletu, za dostop je pa nujna avtentikacija ter uporaba SSL-a.
5. Namizni raˇcunalnik (192.168.22.169) - je ponor verige MQTT podat- kov. Na njemu je prav tako zagnan odjemalec MQTT, ki je naroˇcen na oddaljenega posrednika. Ob prihodu sporoˇcila sproˇzi opozorilo.
6.1.2 Princip delovanja
Slika 6.2: Naprava SensorTag CC2650 in pripadajoˇca aplikacija SensorTag.
Veriga se zaˇcne pri napravi SensorTag. Kot je ˇze opisano v prejˇsnjem po- glavju, bere podatke iz svoje okolice in jih preko Bluetootha posreduje mo- bilnem telefonu.
Mobilni telefon stik do svetovnega spleta ustvarja s 4G povezavo. Svoje omreˇzje potem deli s prenosnikom Lenovo (deluje kot dostopna toˇcka). Na mobilnem telefonu je zagnana aplikacija SensorTag, katere nastavitve vidimo na sliki 6.2. Aplikacija slikovito ponazarja vse prihajajoˇce podatke v obliki grafov ter ponuja povezavo do prenosnika preko protokola MQTT.
Slika 6.3: Zagon posrednika MQTT in posluˇsanje podatkov senzorja.
Na prenosniku si pomagamo s programom Mosquitto in z njim zaˇzenemo lokalnega posrednika MQTT. Ukaz, ki to naredi je mosquitto -v -c
/etc/mosquitto/mosquitto.conf.
Potem, ker ˇzelimo podatke senzorjev shranjevati, inicializiramo podat- kovno bazo z izvajanjem preprostega programa initialize.py. Zgradbo baze vidimo na sliki 6.4.
Kar se tiˇce odjemalca je uporabljen programski jezik Python, in sicer knjiˇznicapaho-mqtt. Program listen.pyustvari odjemalca MQTT, ki ima neke vrste administratorsko vlogo in je naroˇcen na vse teme konˇcnih upo- rabnikov tega omreˇzja. Rezultati zagona ukazov so vidni na sliki 6.3. To- rej najprej vklopimo posrednika, nato incializiramo podatkovno bazo z uka- zompython3.9 initialize.py, na koncu pa vklopimo posluˇsalca z ukazom python3.9 listen.py.
Ob prihodu senzoriˇcnih podatkov so ti zapisani v podatkovno bazo SQLite3.
Gre za klic metod iz pomoˇznega programa store.py.
Slika 6.4: Zgradba podatkovne baze ter prikaz opozorila ob nevarnosti.
Med shranjevanjem nas konkretno zanimajo vrednosti ˇziroskopa. Prav te vrednosti primerjamo s prejˇsnjimi. ˇCe smo presegli empiriˇcno doloˇceno razliko od 100, sumimo na nepriˇcakovano, sunkovito gibanje, denimo da je mogoˇce priˇslo do trka. V tem primeru se sproˇzi funkcija pomoˇznega programa hivemq.py, ki ustvari odjemalca MQTT ter na ustrezno temo (tisto ki se tiˇce naˇsega uporabnika), poˇslje opozorilo oddaljenemu posredniku HiveMQ.
Primer opozorila vidimo na sliki 6.4.
Slika 6.5: Oddaljeni posrednik HiveMQ.
Oddaljeni posrednik je brezplaˇcen in javno dostopen. Njegove osnovne podatke vidimo na sliki 6.5. Potrebno je pojasniti, da ne gre za globalni po- srednik podjetja HiveMQ,broker.hivemq.com, temveˇc za osebni posrednik, ki je prav tako javno dosegljiv, a zahteva SSL povezavo in nujno avtentika- cijo. Njegov naslov je viden samo posamezniku, ki ima ustvarjen HiveMQ raˇcun.
Veriga se konˇca pri namiznem raˇcunalniku, denimo napravi skrbnika sis- tema. Na njemu v ozadju teˇce odjemalec MQTT, ˇze omenjeni program mosquitto_sub, ki je naroˇcen na vsa obvestila oddaljenega posrednika. Glede na to, da oddaljeni posrednik zahteva varno SSL povezavo, mora odjemalec skupaj z zahtevo posredovati svoj certifikat. V primeru nevarnosti se v ukazni vrstici izpiˇsejo podrobnosti in s tem opozori skrbnika sistema.
6.2 Neustrezna avtentikacija
V nadaljevanju bomo izpostavili privzete, surove nastavitve MQTT-ja ter njihov pomen v naˇsem konkretnem primeru. Privzeto se na posrednika lahko poveˇze kdorkoli, avtentikacija je popolnoma neobvezna. Izpostaviti omreˇzje MQTT navzven in ga pustiti brez avtentikacije je lahko resna nevarnost, ˇse posebej ˇce razmislimo o tipiˇcnem spektru uporabe MQTT-ja.
Prav to bomo pokazali. V ozadju zaˇzenemo program Wireshark in iz- beremo snemanje vseh omreˇznih vmesnikov. V prvi ukazni vrstici vklopimo posrednika z ukazom mosquitto. Ta bo privzeto posluˇsal na naslovu local- host in nekriptiranih vratih 1883. V drugi ukazni vrstici se naroˇcimo na poljubno temo s pomoˇcjo pomoˇznega programa mosquitto_sub. Podobno naredimo v tretji ukazni vrstici, kjer objavimo poljubno sporoˇcilo na temo, ki smo jo uporabili v prejˇsnjem koraku.
wireshark &
mosquitto -v
mosquitto_sub -t ’/avtomobili/uporabnik1’
mosquitto_pub -t ’/avtomobili/uporabnik1’ -m "test"
Sporoˇcilo uspeˇsno prispe kljub temu da vsebina sporoˇcila ne ustreza priˇcakovanem formatu, in dejstvu da nismo uporabnik1.
6.2.1 Moˇ zne posledice
Kaj to pomeni v kontekstu naˇsega primera? S tem smo odprli vrata mar- sikateri zlorabi akcij zalednega sistema. Naˇs primer se zanaˇsa na to, da se skrbnik na drugi strani opozori le takrat, ko je to potrebno oz. ko je verjetno priˇslo do trka.
V omreˇzju imamo dva toka sporoˇcil MQTT. Preko lokalnega posrednika, od senzorja odjemalcu in preko oddaljenega posrednika, od odjemalca skrb- niku. Lokalnega posrednika, v primeru brez avtentikacije, lahko kompromi- tiramo z objavo neresniˇcnih senzoriˇcnih podatkov.
