Introduktion
Det här dokumentet beskriver RTE:s referensarkitektur som utarbetats inom ramen för SCOTT-projektet, och den demonstrator (akvariet) som specifikt implementerats som en del i arbetet med att ta fram arkitekturen.
Internet of Things (IoT) är en generell benämning på saker som med inbyggd elektronik kan styras och utbyta data över nätet – allt från kylskåp och klockor till fordon och industriella maskiner.
RTE har som en del av det EU-finansierade forskningsprojektet SCOTT[1] (Secure Connected Trustable Things) designat en referensarkitektur för IoT-system. Centrala delar i SCOTT-projektet på EU-nivå är säkerhet och trovärdighet för uppkopplade saker. För projektet på RTE betyder det att fokus för referensarkitekturen är skalbarhet, generaliserbarhet, driftsäkerhet och cybersäkerhet.
Arkitekturen har för närvarande realiserats för två system, där det ena utgörs av SCOTT-projektets egna fysiska miljö och det andra av ett industriellt IoT-system i bruk hos en kund. Ett mål för utformandet av arkitekturen har varit att den ska vara lätt att återanvända för olika typer av IoT-implementationer och lösningar.
SCOTT-projektets fysiska miljö är ett uppkopplat akvarium, se figur 1, vilket även under arbetets gång fungerat som labbmiljö för att ta fram referensarkitekturen. Akvariet fungerar på så sätt som en demonstrator för plattformen i stort. Ur ett allmänt IoT-perspektiv symboliserar akvariet en installation – en byggnad, maskin eller mindre sak – där någon form av behov av datainsamling och styrning finns. Den insamlade datan kan sedan användas för att reglera olika tillstånd i installationen. I akvariet samlas data in via ett antal sensorer, och vi har möjlighet att kontrollera tillstånd i akvariet via ett antal aktuatorer[2].
Den funktionalitet som har implementerats i demonstratorn består av följande sensorer och aktuatorer:
- Vattentemperatur (“inomhusklimat”)
- Lufttemperatur (“utomhusklimat”)
- Ett relä för att slå på och av belysningen till akvariet (”automatisering”)
- Kamera för att ta bilder av akvariet (”övervakning”)
Det finns ett grafiskt användargränssnitt som visas i figur 2 nedan.
Grafen visar både nuvarande och historiska temperaturvärden. Det finns två larmgränser kopplade till vattentemperaturen (”inomhusklimatet”): ett maximum- och ett minimumvärde. Om temperaturen hamnar utanför dessa värden så kommer ett larm att visas i det grafiska användargränssnittet.
En bild skickas från kameran till det grafiska användargränssnittet varje minut, dygnet runt.
Driftsäkerhet i allmänhet och cybersäkerhet i synnerhet har varit fokusområden när systemet har designats och beskrivs i mer detalj i kommande avsnitt.
Systemöversikt
Den funktionalitet som har implementerats är:
- Möjlighet att accessa det grafiska användargränssnittet från var som helst i världen
- Avläsa nuvarande och historiska temperaturvärden för vattnet i akvariet
- Avläsa nuvarande och historiska temperaturvärden för luften i det omgivande rummet
- Sätta larmgränser – minimum och maximum – för vattentemperaturen
- Få en larmindikering om vattentemperaturen ligger utanför de angivna larmgränserna
- Ange ett dagligt schema för att slå av och på belysningen till akvariet
- Se den senast tagna bilden med kameran
- Ta en ny ögonblicksbild med kameran
Översiktlig systemarkitektur för RTE:s projekt visas i figur 3. Systemarkitekturen är formad med Google Cloud som molnlösning för IoT-systemet. Avsnittet “Molnöversikt” beskriver detta mer i detalj.
Figur 3. Generell systemarkitektur.
Här följer en kort beskrivning av de komponenter som utvecklats av RTE, med start uppifrån i systemöversikten.
- Webbläsare: tillhandahåller det grafiska användargränssnittet (GUI) för IoT-systemet. Här presenteras sensordata – både nuvarande och historiska värden. Via GUI kan användaren ändra schemat för en aktuator, exempelvis belysningen, eller ändra på tillståndet hos en aktuator, såsom att släcka eller tända belysningen. GUI visar också den senast tagna bilden med kameran. Eftersom GUI har implementerats med webbteknologier kan det accessas från var som helst i världen.
- Molnet: Fungerar som backend och hanterar alla anrop/meddelanden från Browser och Gateway vad gäller sensordata och styrning av aktuatorerna.
- Gateway: Består av processorhårdvara med olika mjukvarudelar tillsammans med operativsystemet Linux
- IoT-enhet: Olika sensorer och aktuatorer
Säkerhetsöversikt
En viktig aspekt av SCOTT-projektet är säkerhet. Att konstruera ett uppkopplat IoT-system som är skalbart, feltolerant, och enkelt att vidareutveckla och underhålla är bara en del av ekvationen. Antag t.ex. att systemet är säkerhetskritiskt. Då är det avgörande att en angripare inte kan få tillgång till systemet och antingen kunna läsa information som inte är publik, eller ännu värre, kunna redigera information eller påverka det fysiska tillståndet hos de anslutna sakerna.
Ett uppkopplat IoT-system är ett distribuerat system uppbyggt av komponenter. En komponent består oftast av någon form av hårdvara med mjukvara och kan kommunicera med en annan komponent. Den kan då önska att mottagaren utför någon tjänst. Innan mottagaren utför åtgärden genomförs två kontroller:
- Autentisering – mottagaren som ska utföra tjänsten måste på ett tillförlitligt sätt etablera vem det är som skickar förfrågan, och
- Auktorisering – efter att sändarens identitet har etablerats måste mottagaren avgöra om sändaren har tillstånd att begära att tjänsten utförs.
För att hantera autentisering etableras varje komponents identitet med ett publikt-privat nyckelpar. Idén är att varje komponent har en privat nyckel som den lagrar på ett säkert sätt, och motsvarande publika nyckel registreras tillsammans med komponentens identitet i en säker databas. När en komponent vill begära att en tjänst utförs så skriver den ett meddelande med förfrågan, och signerar meddelandet med sin privata nyckel. När den mottagande komponenten tar emot meddelandet så kan den verifiera att sändaren är vem den påstår sig vara genom att validera meddelandets signatur med hjälp av den motsvarande publika nyckeln som slås upp i den säkra databasen.
Auktorisering görs genom att det finns en auktoriseringsserver som lagrar policys för vem som får accessa vad. En komponent kan kontakta auktoriseringsservern för att få reda på om en viss avsändare har tillstånd att få en viss tjänst utförd. En viktig riktlinje är “principen om minst privilegium”, som säger att varje komponent ska ha så få rättigheter som möjligt för att kunna begära de tjänster den behöver. Målet med denna princip är att även om en komponents privata nyckel kommer på avvägar så ska den som kommit över nyckeln kunna utföra så få tjänster som möjligt.
Figur 4. RTE SCOTT sett från ett säkerhetsperspektiv.
För varje kommunikationslänk i systemet används kryptering. Det vanligast förekommande kommunikationsprotokollet är HTTPS som använder sig av Transport Layer Security (TLS) för kryptering, och så är fallet även för RTE SCOTT. Även protokollet MQTT som används av IoT-gateways för att ansluta till molnet (se figur 4) använder TLS för kryptering. För Bluetooth Low Energy (BLE)-länkar används kryptering[1] för att skapa en säker förbindelse. En säker förbindelse minskar risken för oönskad avlyssning och så kallade Man-In-The-Middle-attacker. Via en Man-in-The-Middle-attack kan en illvillig part skicka felaktiga sensordata som skulle kunna leda till att systemet beter sig på ett oönskat sätt.
Här följer en genomgång av hur de privata och publika nycklarna lagras för de olika kommunikationslänkarna:
- En användares webbläsare ansluter till en ingress-server[1] i molnet (dvs accesspunkten i molnet). Ingress-serverns privata nyckel lagras i en s.k. hemlighet (secret) i Kubernetes (se avsnittet “Molnöversikt”). Serverns publika nyckel lagras också i en Kubernetes-hemlighet, men i form av ett certifikat som är signerat av en Certificate Authority (CA).
- För att komponenterna i molnet ska kunna etablera användarens identitet (webbläsarens användare) så har användaren en s.k. YubiKey, se avsnittet om “Säker inloggning”, som innehåller en privat nyckel. Den motsvarande publika nyckeln lagras tillsammans med användarens identitet i en auktoriseringsserver. Vi använder Keycloak[2] som auktoriseringsserver.
- För att våra egenutvecklade tjänster ska kunna kommunicera med de tjänster som Google tillhandahåller skapas tjänstekonton (service accounts) i Google Cloud. De privata nycklarna för dessa tjänstekonton lagras som Kubernetes-hemligheter, och de publika nycklarna lagras i Googles auktoriseringsservrar.
- När en IoT-gateway ansluter till IoT Core används TLS (Transport Layer Security) för att IoT-gatewayen ska kunna validera att den kommunicerar med Googles servrar. IoT-gatewayen lagrar en privat nyckel lokalt i ett minne på enheten, och den motsvarande publika nyckeln lagras i en databas i IoT Core.
- Båda sidorna i en BLE-kommunikation lagrar en Long Term Key som används för symmetrisk kryptering av BLE-länken. Både IoT-gatewayen och IoT-enheten lagrar denna LTK i sina flashminnen.
Trådlös kommunikation
Bluetooth Low Energy (BLE) är en trådlös teknik som tillåter en snabb överföring av data som temperatur, luftfuktighet eller rörelser (närvaro) mellan sensor och gateway. Den har en två gånger längre batteritid än konventionell Bluetooth-teknik och räckvidd på upp till 100 meter.
Bluetooth Low Energy är känt under många namn: BLE, Bluetooth LE eller Bluetooth Smart. Det primära målet med standarden är att optimera energiförbrukningen. BLE-tekniken ger ett enkelt och pålitligt gränssnitt, vilket uppskattas av elektroniktillverkare och utvecklare av mobila applikationer. BLE har blivit en populär standard för Internet of Things (IoT).
Bluetooth använder samma frekvensområde som WiFi (2,4 GHz-bandet). Bluetooth och särskilt BLE-tekniken använder mindre ström jämfört med WiFi. Både räckvidden och hastigheten (runt 2 Mbit/s) är emellertid betydligt lägre än för WiFi. Idag är det närmare 25 000 företag som använder BLE och mer än 200 företag har dessutom deltagit i arbetet att ta fram denna standard. Bluetooth är från grunden designat för att vara betydligt billigare att använda än liknande system (WiFi).
Bluetooth stöder sedan version 4.2 även krypterade förbindelser samt även Ipv6. En gemensam säker nyckel används för kryptering och dekryptering (se avsnitt ”Säkerhetsöversikt”). Kryptering är viktigt för att förhindra s.k. man-in-the-middle-attacker. En man-in-the-middle attack går i korthet ut på att en tredje (illvillig) part agerar som både mottagare och sändare och på så sätt lurar den riktiga sändaren och mottagaren, se figur 5. Gateway tror då att den kommunicerar med IoT-enheten men i själva verket är det “Man-In-The-Middle”, därav namnet. IoT-enheten i sin tur tror att den kommunicerar med Gateway.
Figur 5. Man-In-The-Middle-Attack om kommunikationen är okrypterad.
Sensorer och aktuatorer
För att ett sakernas internet (IoT) ska existera måste sakerna vara uppkopplade. Vi har delat in saker i två olika kategorier:
- Sensorer
- Aktuatorer
Sensorer mäter eller på annat sätt samlar in information om sin omgivning. Det kan vara temperatur, närvaro, ljusförhållanden, etc. I vårt system använder vi oss av tre olika sensorer: en temperaturmätare för vattnet i akvariet, en temperaturmätare för luften som omger akvariet och en kamera som tar bilder av akvariet.
Aktuatorer, som också kallas ställdon, är i många fall ett relä som styr olika typer av utrustning såsom belysning och pumpar. I vårt fall använder vi oss av ett relä som styr belysningen till akvariet. Andra möjliga aktuatorer skulle kunna vara att styra vattenpumpen, uppvärmning av vattnet och matning av fiskarna.
Man kan förenklat säga att det är valet av sensorer och aktuatorer som avgör hur en användare kan övervaka och styra systemet, dvs akvariet i vårt fall.
Gateway
När vi pratar om IoT-enheter tänker vi ofta på små enheter som ibland inte har kapacitet att kommunicera med molnet själva. För att skicka och ta emot data till molnet så används då en IoT-gateway, som mindre kapabla enheter kan ansluta till med hjälp av t.ex. BLE.
En gateway kan, förutom att vidarebefordra information till molnet, tillhandahålla viss kontrollogik, och även ansluta direkt till vissa sensorer och aktuatorer. I vissa fall kan en IoT-gateway också agera som en IoT-enhet, vilket gör att det inte alltid finns en tydlig skillnad mellan dessa.
Hårdvara
Vi använder den inbäddade enkortsdatorn Nitrogen6X från Boundary Devices som gateway. Den baseras runt System-On-a-Chip-kretsen i.MX 6 från NXP, som innehåller fyra stycken ARM Cortex-9 CPU-kärnor. I många avseenden har Nitrogen6X likheter med Raspberry Pi som är en mer känd, och billigare, enkortsdator. En av fördelarna med Nitrogen6X över andra alternativ är att tillverkaren garanterar tillgänglighet för produkten under en längre tid, minst 10 år.
Operativsystem
För SCOTT är operativsystemet som kör på en gateway en anpassad distribution av Linux, som byggs med hjälp av Yocto[1]. Yocto är en samling verktyg och recept för att kunna bygga och sammanställa en fullständigt anpassad version av Linux, som innehåller precis de komponenter som vi har behov av. Den främsta anledningen till att använda en anpassad distribution av Linux istället för en standarddistribution är ökad säkerhet; genom att bara installera mjukvarukomponenter som vi har ett behov av så minskar den potentiella attackytan, och vi kan enklare hålla koll på att de senaste versionerna av komponenterna används. En annan anledning är att en anpassad version av Linux kan använda färre resurser såsom diskutrymme och RAM-minne.
Applikationsmjukvara
Gatewayen kör ett antal applikationer som vi har utvecklat inom SCOTT, se figur 6.
- controller är knytpunkten i gatewayen, och det är detta program som ansluter till och kommunicerar med Google Cloud IoT Core. Alla meddelanden som skickas och tas emot från molnet går via controllerd. Controllerd innehåller även logik för att slå av och på reläet som kontrollerar lampan, så att även om gatewayen skulle vara temporärt bortkopplad från nätverket så kommer lampan att tändas och släckas enligt schemat.
- bled är ansvarigt för att ansluta till och kommunicera över BLE med BLE-nodenheterna. Programmet ansvarar för att lagra och läsa in säkerhetsnycklar (LTK) som används för att kryptera BLE-länkarna.
- bled-pairing är ett kompanjonprogram till bled, som körs manuellt vid konfigurationstillfället för att para en IoT-enhet med gatewayen. Resultatet av parningen är en Long Term Key (LTK) som gör att de två fortsättningsvis kan ansluta på ett säkert sätt.
- camerad används för att kommunicera med kameran, som är ansluten via USB på Gateway. Controllerd skickar ett kommando till camerad när en ny bild ska tas, och camerad skickar ett resultat när en bild har tagits och laddats upp till Google Cloud Storage.
Arkitekturen hos applikationsmjukvaran i gatewayen gör det enkelt att lägga till nya applikationer och ny logik.
Figur 6. Mjukvaruarkitektur för Gateway.
Molnöversikt
Vi har valt att använda Google Cloud som molnplattform i SCOTT. I många avseenden är de tre stora publika plattformarna Amazon Web Services, Microsoft Azure och Google Cloud likvärdiga, men tillgängliga programmeringsgränss (APIer) och ett smidigt användargränssnitt gör att vi valt Google Cloud för vår tillämpning.
Tjänster som hanteras av Google
Vi använder ett flertal tjänster som Google erbjuder i Google Cloud. Där det är möjligt så använder vi färdiga tjänster istället för utveckla egna. Den främsta fördelen med att använda färdiga tjänster är att en kommersiellt tillgänglig molnplatform som Google Cloud tar ansvar för frågor som feltolerans, skalbarhet och säkerhet.
De Google Cloud-tjänster vi använder, se figur 7, är:
- IoT Core. Enheter ansluter via standardprotokollet MQTT över TLS på ett säkert sätt till IoT Core. Varje enhet registreras i IoT Core, och statistik om enheter lagras, så som när senaste meddelandet togs emot från enheten. Det går att skicka konfigurationsdata och kommandon till enheter, och enheter kan rapportera telemetri och tillstånd till IoT Core. Rapporterad information skickas vidare till Google Cloud Pub/Sub.
- Pub/Sub är en skalbar meddelandebuss där meddelanden buffras i väntan på att de ska tas emot och processas av andra tjänster.
- Firestore är en s.k. NoSQL-databas där stora mängder ostrukturerad data kan lagras enkelt. Datamodellen är samlingar av dokument, där varje dokument motsvarar ett JSON-objekt och kan ha godtyckligt antal fält.
- Storage används för att lagra större objekt som bilder eller andra större filer.
Figur 7. Komponenter i molndelen av SCOTT.
Mikrotjänster med Kubernetes
När det inte finns någon färdig tjänst som uppfyller ett visst behov är det enkelt att utveckla och drifta egna mikrotjänster med hjälp av orkestreringssystemet Kubernetes, som Google tillhandahåller med Google Kubernetes Engine. En mikrotjänst utvecklas i valfritt språk, t.ex. Python, paketeras som en Docker kontaineravbildning (container image) och laddas upp i Google Container Registry. Sedan registreras en mikrotjänst som refererar till denna kontaineravbildning, och Kubernetes kommer sedan att se till att ett visst antal kopior av denna kontainer körs i ett Kubernetes-kluster. Ett Kubernetes-kluster hanteras av Google Kubernetes Engine och kör ovanpå virtuella maskiner som i sin tur hanteras av Google Compute Engine.
Mikrotjänster tillsammans med kontainrar är en kraftfull kombination som gör det enkelt att utveckla, paketera, testa lokalt, och sedan driftsätta programkod i molnet. Det är enkelt att göra löpande uppdateringar, eller att rulla tillbaka en uppgradering om det visar sig att den nya versionen hade oönskade beteenden.
Att använda Google Cloud gör att det system vi utvecklar ärver flera önskvärda egenskaper såsom:
- Skalbarhet – när antalet enheter eller antalet användare i systemet växer så kan ytterligare datorresurser allokeras automatiskt.
- Feltolerans – en krasch hos en enstaka komponent i systemet kan inte göra systemet som helhet otillgängligt, och
- Säkerhet – alla ingående komponenter kommunicerar via krypterade kanaler och har en från grunden genomtänkt säkerhetsmodell.
Webbgränssnitt
Webbgränssnittet är en programvara som används för att observera och kontrollera systemet. Programvaran nås via en URL på webben, https://scott.rte.se, och körs i användarens webbläsare. Fördelen med detta är att alla enheter som använder en normal webbläsare kan användas för webbgränsnittet. Detta innefattar datorer, mobiltelefoner och surfplattor. Webbläsare av typen Edge, Chrome, Firefox och Safari stöds av webbgränssnittet.
När användaren ansluter via URL:en till den server där webbgränssnittet finns lagrat så laddas det ner i användarens webbläsare och körs sedan lokalt hos användaren. Webbgränssnittet är skrivet i Javascript och biblioteket React.js[2], och är en så kallad Single Page Application (SPA) som kör helt i webbläsaren. React.js togs ursprungligen fram av Facebook för just webbgränssnitt och är släppt som öppen källkod. React.js skapar en modulär programvara som gör det enkelt att ändra layout och flytta komponenter i webbgränssnittet. För symboler som av/påknappar har vi använt ett populärt designbibliotek som heter Material UI[3]. En del av webbgränssnittet visas i figur 8.
Figur 8. Webgränssnittet i SCOTT.
Säker inloggning
Eftersom det via användargränssnittet går att påverka systemet, t.ex. genom att tända och släcka akvariets belysning, så är det ett krav att bara behöriga användare har möjlighet att utföra sådana ändringar. För att implementera säker inloggning har vi integrerat Keycloak[4], som är ett öppet system för identitets- och åtkomsthantering.
I Keycloak registreras varje användare och dennes inloggningsuppgifter, samt vilka rättigheter varje användare har. Det är möjligt att specificera finkorniga rättigheter, exempelvis att en användare har rätt att styra belysningen, men inte ändra larmgränserna för vattentemperaturen, individuellt för varje akvarium.
Keycloak har stöd för flerfaktorsautentisering. En möjlig autentiseringsfaktor är en säkerhetsnyckel som t.ex. YubiKey[5], se figur 9. Yubikey ansluts via användarens dators USB-ingång och kan läsa av fingeravtryck.
Figur 9. Yubikey.
En säkerhetsnyckel kan användas som en ensam autentiseringsfaktor istället för ett lösenord, eller som en ytterligare faktor utöver ett lösenord, för att erhålla ökad säkerhet. Enligt en studie[6] gjord av Microsoft reduceras risken för attacker med 99,9% om man använder flerfaktorsautentisering.
[2] En aktuator (eller ställdon) är ofta ett relä
[3] s.k. AES-CCM kryptering, och vi använder BLE Low Energy Secure Connection (LESC) mod 1 nivå 4 för att etablera en Long Term Key (LTK)
[4] en ingress-server hanterar lastdelning
[6] https://www.yoctoproject.org
[10] https://www.yubico.com/product/security-key-by-yubico
[11] https://www.zdnet.com/article/microsoft-using-multi-
factor-authentication-blocks-99-9-of-account-hacks/