Design for sikkerhet

Under design med hensyn til sikkerhet må driftsmiljøet bestemme graden av robusthet som kreves. En sikkerhetsarkitektur må inkludere ikke bare måleenheten, men også alle endepunkter og brukere i hele systemet. Så lenge der er serienumre, MAC-adresser, hvitlister og svartelister, vil disse systemene ikke være idiotsikre. De fleste hackinger av innvevde systemer oppnås gjennom overvåking av nettverkstrafikk for å rekonstruere kommandoer, og så avspille den samme eller en modifisert versjon fra et annet sted.

Intet er sikkert
Innen IoT-verdenen er enhver en fremmed inntil det motsatte er bevist. Selv private nettverk er utsatt for datainnbrudd, og er like sårbare som internett. Gitt at ingen nettverk er sikre, må alle fjerntliggende endepunkter autentiseres før kommandoer og data kan aksepteres. I overgangen fra mennesker til datamaskiner er ekvivalenten til et hemmelig ord, en nøkkel. Design som anvender hemmelige nøkler kan være anvendelig i mindre miljøer, men etter som antall enheter øker, øker også kompleksiteten og kostnaden ved å beskytte disse nøklene. Dersom en hemmelig nøkkel avsløres som følge av at en enkelt enhet kompromitteres, vil alle de andre systemene i miljøet bli sårbare, og vil ikke kunne skille en fremmed fra et klarert (”trusted”) system.

Nøkler
Brukernavn og passord bidrar til å generere unike hemmelige nøkler dynamisk, og legges inn på kommando og trenger derfor ikke lagres i nonvolatilt minne, noe som reduserer risikoen for at de blir kompromittert. Mens dette fungerer i noen miljø, er det mange produkter som ikke har dette konseptet med brukere, og må fungere sikkert fra det øyeblikket de startes opp. Disse miljøene krever delte, hemmelige nøkler mellom begge endepunktene for autentisering og kryptering. Men hvordan legges nøklene inn i systemet? I militære miljø blir spesielle håndholdte datamaskiner, kalt nøkkelfyllere (”key fill devices”) brukt for fysisk lasting av hemmelige nøkler. Systemer designes med en ”fyllport” for å akseptere nøkler slik at de aldri er eksponert. Nøkkelfyllere og nøkkellhåndteringssystemer beskytter nøkler under distribusjon, inntil de er trygt lagret innenfor et sikkert område i enheten.

Kryptering
Kryptering av offentlige nøkler forenkler kompleksiteten for delte nøkler ved å ivareta hvert endepunkt med ett enkelt asymmetrisk nøkkelpar for bruk til kryptering og autentisering. Sikkerhetssystemer etter ”beste praksis” bruker aldri den samme nøkkelen for begge deler. Dersom et endepunkt blir kompromittert og den private nøkkelen eksponert, vil sårbarheten være begrenset til kun det systemet.

Asymmetrisk
Asymmetrisk kryptografi tillater endepunktene å kommunisere sikkert, uten behov for å forhåndsdele nøkler. Men hvordan kan en enhet vite om den kommuniserer sikkert til det rette endepunktet? Sertifikater benyttes for å forhindre såkalte man-in-the-middle angrep under utvekslingen av offentlige nøkler, og bevise identiteten til et fjerntliggende endepunkt. I sin mest grunnleggende form består et sertifikat av metadata som navn, serienummer, utløpsdata osv. – bundet til den offentlige nøkkelen ved en digital signatur fra en sertifiseringsmyndighet (Certificate Authority - CA). Gjennom bruk av gjensidig autentisering vil enhetene aldri forsøke å prosessere innkommende kommandoer, med mindre de kommer fra en gyldig kilde. Selskapets IoT-tjenester vil også være beskyttet, ettersom også de kun responderer på riktig legitimerte enheter.

Sertifikater
Når to systemer utveksler sertifikater, er offentlige nøkler kun klarert dersom begge er digitalt signert av den samme CA. Ettersom begge systemene støtter seg til CA, kan denne klareringen utvides til det fjerntliggende systemet under antagelsen av at private nøkler ikke blir kompromittert. Etter at det er autentisert og klarert, kan programvaren lese sertifikatet for å bestemme hva som skal utføres, eller hvilke systemfunksjoner som skal gjøres tilgjengelig. Dette tillater enheter å trigges for å gå i debuggingsmodus for en begrenset periode, basert på opplæringsnivået til teknikeren.

Hjelp å få
Det finnes flere sertifikatgenererings- og administrasjonsdesign som skal hjelpe designere av innvevde systemer å implementere digitale identiteter i sine produkter. Spesifikasjonen IEEE 802.1ar brukes i økende grad i innvevde produkter som nettverks- og industristyringssystemer. 802.1ar tar for seg administrasjon og bruk av ett enkelt iDevID og flere LDevID sertifikater. iDevID-sertifikatet er også kjent som ”fødselsattesten” – og brukes til å identifisere produsenten av systemet, kortet eller komponenten. Dette er typisk det første sertifikatet i systemet, og generert under produksjon. Hensikten med LDevID varierer, avhengig av miljøet.

For eksempel kan et LDevID sertifikat i ett produkt være skapt for å beskytte kundeprofiler og -data. I et annet eksempel kan et kort være solgt til flere integratorer, som hver ønsker kryptografisk separering fra konkurrentene. Kortprodusenten ønsker på sin side å sende sikre programvareoppdateringer og innhente telematikk, mens integratorer ønsker å beskytte deres intellektuelle eiendom. Et LDevID sertifikat kan genereres for hver enkelt integrator, slik at de kan kommunisere sikkert innen sine egne enklaver, og beskytte sine data uten å risikere at de blir kompromittert.

Vurderingspunkter
Ved implementering av sertifikater i et innvevd design, må utviklere og produsenter ta følgende i betraktning:

• Programmering av CA rotsertifikatet til et upåvirkelig minne – hindrer en angriper i å erstatte det med noe annet
• Generering av asymmetriske nøkkelpar – Private nøkler må aldri eksponeres utenfor enheten, forutsatt at riktig generering av tilfeldige tall er mulig
• Beskyttelse av private nøkler – Spoofing-angrep (dvs. under falske ID) er mulig dersom private nøkler blir kompromittert
• Sending av sertifikatsigneringsforespørsler til CA system – Dersom det benyttes et CA system som ligger et annet sted (”hosted”), hva vil være konsekvensen for produksjonen ved et nettverksbrudd?
• Mottak av sertifikat og beskyttet lagring – Hvordan blir sertifikater og nøkler beskyttet på enheten?
• Lasting av initielle tilbakekallingslister – Relaterer seg til hele innholdsbehandlingsprosessen og sporing av legitimasjonssystemer og RMAer

DLM
Et økende antall produktutviklere bygger sine egne infrastrukturer for offentlige nøkler (PKI) og genererer sertifikater direkte i monteringslinjen, der private nøkler kan forbli inne i hver enhet, og produksjonen er upåvirket av brudd på internettforbindelsen. INTEGRITY Security Services’ Device Lifecycle Management (DLM) System beskytter et selskap sine CA-nøkler mot IT-nettverk som er utsatt for datainnbrudd ved fjerntliggende og tredjeparts produksjonsfasiliteter for å ivareta høyt tilgjengelig sertifikatgenerering. DLM hjelper utviklere som ønsker å implementere sertifikater skreddersydde til deres design og leveringskjede, uten å måtte bygge og støtte deres egen PKI.

Hvordan stole på noen
Den aller viktigste betraktningen når man diskuterer autentisering, er hvordan vi kan stole på andre, dersom vi ikke kan stole på oss selv? Dessverre er ikke dette et filosofisk spørsmål. Dersom systemprogramvare kompromitteres, vil klareringskjeden være brutt fra starten av, og ingenting kan garanteres. Hacket programvare kan hoppe over verifikasjoner, akseptere ethvert sertifikat, og modifisere meldingsinnhold. Nøkler kan kompromitteres dersom de ikke er skikkelig beskyttet, og brukes til å angripe andre enheter ved å manipulere kommandoer og data. Bakdører kan åpnes for å samle inn eller sende data, og i praksis gjøre ethvert sikkerhetsdesign og autentiseringsmetode hensiktsløs.

Sjekk modifiseringer
Før et innvevd system kan være trygg på å kunne autentisere fjerntliggende endepunkter, må det sjekke at programvaren ikke er blitt modifisert. Dette oppnås gjennom en prosess kalt sikker oppstart («secure boot»), der systemprogramvare verifiseres før den eksekveres. Ved hver oppstart sjekker sikker oppstart autentiteten til hvert programvarelag før den tillater eksekvering. Dette sikrer at programvaren ikke er tuklet med, og kommer fra en gyldig kilde. En komponent vil aldri bli eksekvert med mindre det er bevist at den er klarert.

Autentisering
Hashtabeller og sjekksummer verifiserer bare integriteten til programvaren, ikke autentiteten. Så lenge en angriper modifiserer hashen sammen med koden, kan skadelig programvare fortsatt eksekveres uoppdaget. Autentisering kommer fra digital signering av hashen gjennom bruk av en asymmetrisk nøkkel. Sikkerhetsinfrastrukturen i et selskap beskytter den private nøkkelen, og signerer programvareversjonen digitalt. Den korresponderende offentlige nøkkelen er programmert inn i enheten under produksjon, og benyttes under verifikasjon. Dersom en angriper nå skulle endre både kode og hash, vil han fortsatt ikke være i stand til å oppdatere den digitale signaturen uten den korresponderende private nøkkelen som regenererer den digitale signaturen. INTEGRITY Security Services samarbeider med selskaper innen alle industrier for å implementere sikre oppstartsløsninger, inkludert infrastrukturer for digital signering med «null eksponering»-beskyttelse av private nøkler, og integrasjon i den hverdagslige programvareprosessen.

Ukjente trusler
Sikkerhetsarkitekturen i dagens nettverkstilkoplede IoT-produkter må ta høyde for flere ukjente faktorer enn noen gang. Med hver eneste ny enhet som legges til nettverket, kommer en ekstra, ukjent trussel og risiko for konflikter som kan forårsake støtte- og utviklingskostnader. Disse «ukjente» håndteres ved å styre kommunikasjonen til utelukkende klarerte endepunkter, gjennom autentisering. Ved å starte med maskinvare for å verifisere programvare før man utvider systemet til fjerntliggende punkter, ivaretar man en sikker kjede.

Starten på denne artikkelen er publisert i Elektronikk nr. 10/2018. Dette er hele artikkelen.
INTEGRITY Security Services er et Green Hills Software selskap.