Fordonsindustrin håller på att genomgå en betydande omvandling, förmodligen den största på flera årtionden. Megatrender som nätverksanslutning mellan fordon och allt annat tänkbart, elektrifiering av drivlinor och autonom körning påverkar inte bara företag utan också processer, vilket ökar risken för att teknik används felaktigt. Företagsledningar måste därför förstå vikten av safety och security från både mjukvaru- och hårdvaruperspektivet på detta område.

Förändring är det enda beständiga i dagens fordonsindustri. Även i forna tider påverkade marknadstrender vissa teknikaspekter, men i modern tid kan ingen av de så kallade megatrenderna granskas enskilt. Med betydande inbördes beroenden leder trenderna så småningom till helt elektriska fordon som kör autonomt medan de är anslutna till andra fordon, infrastruktur eller molnet. Det slutgiltiga målet med denna process är att möjliggöra billig, säker och miljövänlig rörlighet för alla. Men fördelarna tills trots medför framtidsfordonen en enorm risk: slarv eller avsiktlig felanvändning kan ge konsekvenser som personskador, tappat förtroende för tillverkaren, eller attacker mot ett helt fordonsslag för utpressning eller för massförstörelse.

Därför är det inte bara rekommenderat utan absolut nödvändigt att ledningen förstår förhållandet mellan safety och security för både mjukvara och hårdvara, och förstår vad det betyder och vad som måste göras.

I denna artikel förklaras:

* Skillnaderna och kopplingarna mellan safety och security

* Varför dålig säkerhetsplanering är roten till allt ont

* Betydelsen av certifieringar

* Rättsliga implikationer

Fokus för den här artikeln är på specifika safety- och security-aspekter i mjukvara, men många av principerna kan tillämpas även vid val av rätt hårdvaruplattform för ett säkerhetskritiskt projekt. Naturligtvis skiljer sig tillvägagångssättet vid lämplighetsbedömning för varje given enhet. På en hög nivå handlar det om tre nyckelaspekter:

* Stöder enheten alla funktioner och innehåller enheten alla moduler som behövs för dess roll i ett säkert system, t.ex. säker bootkedja, lagring för kryptonycklar, HSM (hårdvarusäkerhetsmodul), MMU (minneshanteringsenhet)?

* Stöds enheten av säkra mjukvarulager högre upp? Eller krävs potentiellt osäkra anpassningslager?

* Kan säkerhet garanteras över hela leveranskedjan, dvs. halvledarfabrik, montering, paketering, testning, lagring, distribution, eftermarknadsservice?

De specifika kraven och därmed även detaljerna i varje fråga kan skilja sig från projekt till projekt, men ingen aspekt får ignoreras eftersom det påverkar den övergripande säkerhetsdesignen.

Safety och security
Först och främst är det värt att nämna att diskussionen om security (säkerhet) och safety (funktionell säkerhet) bättre hålls på engelska, eftersom båda betydelserna täcks av svenskans “säkerhet”.

Förenklat kan funktionell säkerhet (safety) sägas vara sannolikheten att en maskin, dvs. en bil, skadar en person. För att reducera denna sannolikhet sammanställs en detaljerad beskrivning av alla användningsfall (safety case), varvid en riskanalys resulterar i åtgärder som garanterar det förväntade beteendet.

Vanligtvis används flera tekniker för att säkerställa att systemet gör precis vad det är tänkt att göra. Exempelvis ska ett autonomt nödbromssystem (AEB) utföra ett nödstopp när vissa objekt finns i fordonets färdbana; dessa objekt inkluderar personer, bilar och byggnader men inte mindre objekt som ölburkar och papperskorgar. Vidare måste metoder som kravspårbarhet, design- och kodgranskningar och omfattande testning användas i utvecklingsprocessen.

Ett nätverksanslutet system kan inte uppnå safety om inte dess security har hanterats (Obs: security är också viktigt för icke-anslutna system, men antalet potentiella hot och mängden arbete som krävs är mycket lägre). Security är att ingen person kan, som ett resultat av en otillräcklig programvarudesign eller utvecklingsprocess, orsaka skada eller olovlig påverkan. Security ska skydda enheten eller systemet så att den kan fullgöra alla sina uppgifter utan att påverkas av en tredje part som försöker få systemet att fungera på ett farligt sätt.

Ta exempelvis ett framåtriktat kamerasystem som upptäcker trafikskyltar för hastighetsbegränsning. En hackare skulle kunna ändra referensdata som systemet använder för att jämföra med kamerabilden, vilket får bilen att misstolka den aktuella hastighetsgränsen, leverera dålig information till föraren eller farthållningssystemet och därmed dramatiskt öka risken för en olycka, eller till och med direkt orsaka en olycka. I ett korrekt designat system kan en utomstående hackare inte få tillgång till några safety-kritiska funktioner eller deras referensdata eftersom komponenterna är isolerade från andra icke-kritiska komponenter.

Att uppnå en viss safety-nivå för ett system är svårt men väl förstått i branschen, men för att nå en hög security-nivå krävs ett annat tillvägagångssätt. Det beror på att man måste identifiera och separera alla security-kritiska funktioner (t.ex. backkamera, instrumentpanel) från icke-säkra funktioner (t.ex. radio, MP3-media). I korrekt separerade och designade system kan hackare helt enkelt inte få tillgång till safety-kritiska system via öppna och icke-säkra (non-secure) system; detta tillvägagångssätt, som en vattentät behållare, behöver inte fixas eller uppdateras senare. Störningar begränsas till icke-kritiska delar i bilen.

Förutsatt att utveckling skett enligt gällande safety-standarder och med grundlig testning och verifiering kan ett system betecknas som säkert (så länge det inte sker någon större förändring i miljön som inte täcks av det ursprungliga safety-konceptet). För security gäller dock ständig förändring. Ökad anslutning av bilsystem med konsument- eller nätverksinfrastruktur öppnar dagligen nya dörrar för hackare att få tillgång till bilsystem. Dessutom kommer tillgången på beräkningskraft i framtiden att göra etablerade kryptografiska algoritmer föråldrade. Medan vissa grundläggande säkerhetstekniker kanske inte behöver uppdateras så kommer andra försvarsmekanismer och krypteringsmetoder att behöva det.

Ironiskt nog kan fjärruppdatering (OTA) – en förmåga som är nödvändig för safety, security och av ekonomiska skäl – också skapa security-risker om den inte implementeras korrekt. Detta är ett allvarligt hot mot miljoner befintliga fordon utan en tillförlitlig separations- och isoleringsstrategi.

Planering för safety och security
Safety-planering och security-planering delar en förutsättning: planeringen måste ske från början av designprocessen. Som redan diskuterats är en korrekt arkitektur avgörande för att uppnå de högsta nivåerna av safety och security. Det är extremt svårt, ofta helt omöjligt, att sent i ett projekt lägga till funktioner för att förbättra safety och security, och det medför betydande kostnader och risker.

Särskilt när man utvecklar system som kräver en hög security-nivå är tidig säkerhetsplanering avgörande för att projektet ska lyckas. Likna det vid att försöka lägga till en extra ECU till E/E-arkitekturen för ett fordon som redan är i produktion. I det här fallet är det inte bara den elektriska / fysiska integrationen som orsakar svårigheter (och omkostnader) utan också funktionella beroenden och den påföljande testningen. Ytterligare stress skapas av att modifieringar krävs i den mycket avancerade produktionsprocessen.

Två metoder har visat sig mycket värdefulla vid skapandet av en security-arkitektur: inifrån-ut-säkerhet och säkerhetslager.

Säkerhetslager kommer från en gammal beprövad militär försvarsstrategi som antar att varje försvarsmekanism kan komma att fallera och att det därför är nödvändigt med flera försvarslager (figur 1). Flera lager av olika säkerhetstekniker användas för att säkra den kritiska delen av systemet eller informationen.

Fig 1. Säkerhetslager

Inifrån-ut-säkerhet är en symbiotisk matchning till denna modell. Rekommendationen är att tänka på säkerhet inifrån och ut snarare än utifrån och in, dvs. börja i systemets kärna. Identifiera vilka delar av systemet som behöver skydd och vilka som inte behöver det. De säkra delarna separeras från de icke-säkra delarna med hårdvara eller mjukvaruseparation; vad som är tillgängligt beror på vilka specifika enheter och vilken mjukvara som används. Genom att bygga på separeringen med flera säkerhetslager skapas ett säkert system. Metoderna ersätter dock inte varandra, utan flera säkerhetslager bör användas utöver den grundläggande separeringsstrategin.

Det är nu uppenbart varför security inte kan läggas till ett befintligt system. Att försöka lägga till ytterligare lager påverkar kraftigt beroendeförhållandena i den övergripande strukturen och kan leda till betydande prestandafall eller totala fel.

Certifieringar
Varje bransch har utvecklat sin egen uppsättning standarder och certifieringar avseende olika segment, t.ex. ISO26262 för safety eller den kommande ISO/SAE21434 för security i fordonssystem. Det rekommenderas att respektera dessa certifieringar med två saker i åtanke:

* Ett system som är helt byggt med ASIL D-klassade komponenter och verktyg leder inte automatiskt till ett system som kan certifieras till ASIL D. Det är bra med färdigcertifierade enheter och mjukvara, men det är viktigare att systemet är korrekt designat. Fördelen med att använda färdigcertifierade delsystem och komponenter är att det underlättar certifieringen av det kompletta systemet, vilket gör att ASIL D kan nås snabbare och billigare.

* En certifiering kan användas för att verifiera påståenden och jämföra olika erbjudanden. Speciellt när man försöker bygga ett säkert system är det avgörande att hitta rätt komponenter. Standarder som Common Criteria ger bra riktlinjer, t.ex. vid val av rätt operativsystem. Det är mycket osannolikt att ett säkert system kan byggas med ett operativsystem certifierat enligt EAL 4+ (Evaluation Assurance Level) eller lägre (figur 2). För att nå de högsta security-nivåerna används en arkitektur med separationskärna, till exempel INTEGRITY-178 realtidsoperativsystem (RTOS) från Green Hills Software, som är det enda kommersiellt tillgängliga RTOS med EAL 6+ klassning, för att ge en säker grund för högre mjukvarulager.

Certifieringsnivåer enligt EAL

Att göra rätt val på de lägsta mjukvarulagen är avgörande för systemets totala säkerhet eftersom RTOS inte bara styr alla hårdvaruresurser i systemet, som minne och kommunikationsgränssnitt, det separerar och isolerar också olika funktioner och applikationer inom systemet vilket skyddar mot anfallare som redan har övervunnit säkerhetsåtgärderna inom en enskild funktion.

Rättsliga implikationer
När en olycka inträffar hålls generellt fordonets förare ansvarig (detta är anledningen till att obligatorisk försäkring infördes). Eftersom föraren är direkt ansvarig för mer än 90% av alla olyckor är detta vettigt. Men med utvecklingen mot autonom körning flyttas allt mer ansvar bort från föraren – om det finns en förare alls – till den OEM som tillverkade fordonet.

Detta är en svår situation för en OEM eftersom de inte nödvändigtvis har full insikt i den exakta implementeringen av en specifik funktion, särskilt om funktionen förlitar sig på stora mängder applikationsprogramvara. Naturligtvis hanteras mer och mer in-house, t.ex. kommunikationsstacken, för att upprätthålla interoperabilitet mellan ECU:er från olika tier-1-leverantörer, men i många fall är applikationsprogramvaran för en specifik funktion proprietär och delas inte ens med en OEM. Trots grundlig specifikation, testning och validering måste en OEM 1) lita på leverantörens kompetens, och 2) kunna skicka skadeståndskrav till leverantören i händelse av ett allvarligt fel.

Som skydd mot rättsliga åtgärder måste leverantörer välja hårdvara, programvara, processer och utvecklingsverktyg noggrant. Man måste skilja mellan praktiskt godkänd teknik, bästa tillgängliga teknik och spjutspetsteknik.

Dessa tre termer är inte utbytbara, trots att de ofta blandas ihop i juridiska argument. Hänsyn bör tas till detta när ett utvecklingsavtal skrivs.

* Konceptets lägsta nivå är praktiskt godkänd teknik, vilket i princip innebär användning av det verktyg eller den metod som används mest inom området. Det behövs inga vetenskapliga bevis för att det är det bästa sättet att lösa problemet.

* Bästa tillgängliga teknik är ett steg närmare vad som är teoretiskt möjligt. Det består av metoder och verktyg som, baserat på vetenskaplig forskning, är de mest effektiva och avancerade.

* Spjutspetsteknik är den högsta nivån och hänvisar till sådant som har uppfunnits utan att ta hänsyn till om tillämpningen är meningsfull rent tekniskt eller ekonomiskt.

Noggrann kravhantering rekommenderas starkt eftersom skillnaderna är något subtila. Särskilt inom områden där officiella riktlinjer och rättsliga ramverk saknas måste krav formaliseras på ett mycket distinkt sätt.

Sammanfattning
Det är allmänt känt att inga nya utvecklingsprogram kan genomföras framgångsrikt utan att ta hänsyn till safety- och security-aspekter. I många fall planeras dock inte safety och speciellt security redan från början. Även den enklaste komponent kan, trots att den inte bidrar till systemets faktiska funktion, bli livsfarlig när den hackas. Ökat beroende på mjukvara och bilarkitekturernas evolution mot mer IT-liknande system bidrar ännu mer till hotet. Företagsledningar har en nyckelroll i att förstå situationen och förbereda utvecklingsramverk där safety och security kan frodas redan från starten av ett utvecklingsprogram.

Stephan Janouch, senior chef för affärsutveckling EMEA, Green Hills Software

Filed under: Embedded, Fordonselektronik