Utvikling av sikre IoT-systemer

 Å designe et innvevd system for Internet of Things (IoT) krever en annen tilnærming enn et klassisk innvevd-design, ikke minst på grunn av tilkoblingen til internett. Samtidig forventes en liten innvevd enhet å holde tritt med raske endringer i IT- og InfoSec-verdener, samtidig som den skal være like enkel å oppdatere som en PC og like sikker som et kontinuerlig overvåket datasenter. Vanskelig, ja, men oppnåelig med riktig systemdesigntilnærming.

Ian Pearson.

Om forfatteren
Ian Pearson har mer enn 20 års erfaring med design av innvevde systemer. I de siste 10+ årene har han jobbet med tilkoblede, innvevde systemer i utgangspunktet med fokus på Ethernet og TCP / IP, og har siden vært aktiv med å bringe Microchip Wireless Solutions innen Wi-Fi, Bluetooth og LoRa inn i det innvevde segmentet. Ian har vært aktiv innen IoT helt siden starten, og er en talsmann for design av sikre IoT-systemer.

Sikkerhet
Med et innvevd system for IoT er det viktig å se på hvordan enheten passer inn i hele systemet, utføre trusselmodellering og risikoanalyse for å bestemme ytelsen og hva den må være i stand til. Enten den er koblet til via kablet eller trådløs, kan enheten ha en levetid på ett til 20 år der den kan bli angrepet. For å motvirke dette er sikkerhet en viktig systemdesignprioritet, inkludert å gjøre det mulig å utføre alt av programvarevedlikehold og oppdateringer på en sikker måte.

Dette betyr at det i begynnelsen av designet er viktig å vurdere hvordan du vil koble enheten din til internett, hvordan systemarkitekturen din skal se ut, hvordan du vil administrere hendelser som oppstår og eventuelle problemer med det bredere systemet.

Definere behov
Fordi en IoT-enhet krever innspill fra flere parter - IT, markedsføring, utvikling, salg, ledelse, økonomi og juridisk - må de tydelig definere og forstå behov, forventninger, kostnader og leveranser i tilknytning til enheten. Problemene som skal vurderes inkluderer produktoverensstemmelse, ansvar, datainnsamling, lagring og bruk, samt hvordan man håndterer data- eller integritetsbrudd. Hva er forretningsmodellen for å dekke de langsiktige kostnadene ved å kjøre enheten i et skytilkoblet system, og hvilken brukerfordel gir den? Hvordan et produkt er designet og vedlikeholdt på lang sikt påvirkes sterkt av disse innledende beslutningene.

Regelverk
Situasjonen er blitt enda mer kompleks med ny lovgivning som General Data Protection Regulation (GDPR). Nyttige retningslinjer finner du i den britiske regjeringens 'Secure by Design' -tjeneste, European Union Agency for Network and Information Security (ENISA) og IoT Security Foundation.

Brukervennlighet
Brukervennlighet og behovet for å øke sikkerheten er ofte i konflikt med utformingen, det samme er komplekse passord og enhetsregistreringsprosesser. Dette betyr at det er viktig å utforme sikkerhet og enkelhet i produktet fra begynnelsen.

Viktige elementer
Hvis vi ser på et tilkoblet, innvevd produkt, består det av fire sentrale maskinvareelementer:

• Prosessering
• Minne
• Kommunikasjon
• Sikkert maskinvareelement

Det er også et viktig femte element – programvare.

Disse kjerneelementene er vanlige i alle systemer. Nøyaktig hvordan de implementeres, er et designvalg som skal tas basert på produktets nøyaktige brukstilfelle, vurdering av og holdning til risiko, kostnader, utviklingsmuligheter, sikkerhet og vedlikeholdsevne.

Systemdesignet
Målet bør være et systemdesign som er robust, pålitelig, fleksibelt, gjenopprettbart, sikkert, klarert, skalerbart, vedlikeholdbart, produserbart og anvendelig. Det bør opprettholde merkevareintegritet og oppnå et passende kostnadsmål som er relevant for kravene systemet vil møte. Det skal antas at kostnadene for å designe, utvikle og produsere en tilkoblet enhet vil være høyere enn for en frittstående, ikke-oppdaterbar klassisk innvevd enhet. Imidlertid, hvis den er utformet riktig, vil verdien produktet gir på lang sikt langt oppveie komponentkostnaden. Så det er økonomisk fornuftig å utvikle IoT riktig i stedet for å prøve å fikse ting senere, hvis det skulle gå galt.

Root of Trust
Et sikkert system krever en pålitelig måte å lagre hemmeligheter og godkjenne gyldighet samtidig som det sikres at selve hemmeligheten aldri blir avslørt. Et «tillitsanker», vanligvis i form av et sikkert element, vil gjøre dette. Disse enhetene innebærer flere fysiske metoder for å forhindre kjente maskinvareangrep mens de legger til funksjoner som RNG (Random Number Generators) av NIST SP 800-kvalitet og kryptografiske algoritmer som FIPS-kompatibel Elliptic Curve Digital Signature Algorithm (ECDSA-P256).

Et sikkert element bidrar til å ivareta:

• Autentisering av en enhet til skybaserte tjenester ved hjelp av velprøvde og forståtte PKI-metoder (public key infrastructure). Dette tillater forhåndsregistrering av enheter på systemet ved produksjon, med individuelle sertifikater per enhet, og generering av en QR-kode ved produksjon for å knytte sluttproduktet til et spesifikt sertifikat. Brukeren vil da knytte den samme QR-koden til kontoen sin ved igangkjøring, mens det sikre back-end-systemet knytter sertifikatene til kundekontoen, og sikrer en enkel, sikker igangkjøringsprosess mens de oppfyller myndighetskrav.
• Faktisk introduserte Microchip Technology nylig bransjens første forhåndsinnstilte sikre nøkkelløsning som er tilgjengelig i en lav minimumsordre (MOQ) på 10 enheter, og hjelper utviklere med å automatisere sikker skyautentisering for et prosjekt i alle størrelser. Dette tre-lags tilbudet er kjent som Trust-plattformen, og gir direkte forhåndsbestemte, forhåndskonfigurerte eller fullt tilpassbare sikre elementer, og det har muligheten til å autentisere til enhver offentlig eller privat skyinfrastruktur eller LoRaWAN ™ -nettverk.
• Autentisering av data. Ved å bruke tillitsankeret er det mulig å avgjøre om målingene er kun fra en bestemt enhet og ikke har blitt tuklet med. Dette hjelper også å oppdage uregelmessigheter i data gjennom skyanalyse, siden storskala fysisk inngripen er vanskelig å oppnå. 
• Sikker oppstart, som betyr å utnytte hemmeligheten som er lagret i det sikre elementet for å identifisere endringer i den kryptografiske signaturen til verts-MCU og lagrede fastvareoppdateringer. Ytterligere kjøretids-integritetskontroller, ved hjelp av metoder fra klasse B sikkerhetsbibliotekmetoder, kan også brukes.
• Sikker fastvareoppgradering gjennom luften (FUOTA), dvs. hemmeligheten som er lagret i det sikre elementet brukes til å kontrollere integriteten til kilden til oppdateringen, og også signaturen til databildet som sendes til enheten før opplastingen, for å bekrefte at bildet er gyldig.
• Anti-kloning, hvis produksjonen håndteres riktig, hjelper et sikkert element mot kloning og forfalskning av maskinvare.

Men å ha en metode for å lagre hemmelighetene til et enkelt produkt, i et maskinvaresikkert element, krever også at enhetene er programmert i et sikkert produksjonsmiljø. Dette medfører problemer rundt skalerbarhet og, i mange tilfeller, tillit knyttet til underleverandører. Produksjonsfleksibilitet og enkel igangkjøring sikres ved å kjøpe enheter som inneholder privat informasjon, forhåndsprogrammert av enhetsleverandøren, i et sikkert miljø, og med muligheten til å laste offentlig informasjon opp til skytjenesten din i en enkel, automatisert prosess.

Bulkminne
Fastvareoppdateringer utføres vanligvis med en kabel direkte til enheten ved hjelp av en seriell port. Dette har fungert i mange år, men hvordan kan denne tilnærmingen fungere med tilkoblede enheter, muligens på utilgjengelige steder, distribuert i stor skala?

I tilfelle det oppstår et problem som krever at en oppdatering distribueres raskt utenfor en rutinemessig vedlikeholdssyklus, bør en tilnærming som medfører fysisk inngrep unngås. Alternativet er å bruke FUOTA-oppdateringer, og ideelt sett, sikre FUOTA. Siden dette er en hands-off tilnærming, må systemet dra nytte av integriteten som er muliggjort av det sikre elementet for å forhindre useriøse oppdateringer fra en ukjent/ikke-klarert kilde.

Men hvordan utføre selve oppdateringen? Ideelt sett bør sikre FUOTA-oppdateringer utføres slik at driften til verts-MCUen holdes intakt. Å utføre en oppdatering direkte på enhetsprogrammets flashminne, uten lokal sikkerhetskopi, medfører risiko for det fryktede «bricking» -scenariet der en uopprettelig feil oppstår under oppdateringen.

Uavhengig av medium
Den valgte FUOTA-metoden bør være uavhengig av kommunikasjonsmedium. Det vil si at den samme prosessen skal være i stand til å takle ulik båndbredde, ventetid, utfall og tap på ethvert fysisk medium. På denne måten kan den samme back-end-prosessen på serversiden og den samme nedlastings-, lagrings- og integritetssjekkmekanismen på enhetssiden brukes og vedlikeholdes over en rekke forskjellige medier. Det vil uunngåelig nok være noen variasjoner for «en-for-alle» metode basert på en komplett systemdistribusjon, men å holde seg nær en standardtilnærming ved hjelp av modulære metoder, understøtter kodevedlikehold på lang sikt.

Kraftforsyning
Hvis du distribuerer enheter globalt, og sender ut selv en kontrollert oppdatering til grupper av enheter, er det vanskelig å vite nøyaktige kraft- og miljøforhold for hver enhet. Likevel forventer vi at den fungerer nøyaktig på samme måte som den ville gjort i laboratoriet under test, og garanterer at den vil holde enheten vår innenfor de ideelle driftsforholdene. Men hva om den ikke gjør det? Hva om en ESD-hendelse oppstår på én gruppe enheter og ikke på en annen. PSU-designet vårt bør også inkluderes i «hva om» scenariene, og bør integreres i en overordnet strategi for motstandsdyktighet og gjenoppretting.

Om det aldri skjer, og systemet ditt aldri blir hacket…

• Vær takknemlig. Du kan rett og slett ha vært heldig, eller din flittige planlegging og forebyggende designtilnærming gjorde utfordringen vanskelig nok til at den tilfeldige angriperen valgte å gå et annet sted. 
• Ingen sikkerhet er perfekt, og den vil bli utfordret før eller siden. Men vi kan bruke de beste teknikkene og mulighetene som er tilgjengelige i dag, og planlegge en rimelig mengde fremtidig ettersikring. Hvis systemet vårt er utviklet for å utnytte «root of trust» enheter og kan oppdateres på en sikker måte, kan vi bruke den mer fleksible skysiden av systemet vårt til å håndtere størstedelen av byrden - forutsatt at vi har designet med dette i tankene.
• Angrip designet ved hjelp av teknikkene som er tilgjengelige gjennom organisasjoner som IoT Security Foundation, Gov.UK Secure by Design, UL2900, ISA 62443 og ISA Secure og andre etter hvert som de dukker opp.
• Bygg tilstrekkelig takhøyde for å tillate den uunngåelige økningen i kodestørrelse. 
• Design for verste tilfelle, og gjør kognitive kompromisser i stedet for å designe for kostnad uten hensyn til «hva om» -scenariene. IoT-enheter utgjør en enorm potensiell angrepsflate for hackere, tvilsomme aktører, eller bare «smartinger» som er ute for å ha det gøy.
• Årsakene til at enheten din blir angrepet trenger ikke være spesielt fornuftige, men den potensielle skaden på mennesker, produkter, planter, merkevarer og selskaper kan være betydelig.

Husk... Å si «det skjer ikke meg» hjelper ikke når det først skjer.