Author:
Mark Pitchford is technisch manager Emea bij Lynx Software Technologies.
Reading time: 7 minutes
De auto met internetverbinding brengt grote beveiligingsproblemen met zich mee. Door de beginselen van minimale toegangsrechten en scheidingskernels te koppelen aan de kerntechnologie van hardwarevirtualisatie zijn de problemen het hoofd te bieden, aldus Mark Pitchford van Lynx.
Iedereen die dit artikel leest zal wel doordrongen zijn van de ernst van de beveiliging bij ‘verbonden’ en potentieel zelfrijdende auto’s. De gevolgen van gedeeltelijke of onvolledige beveiliging werden onder meer vorig jaar gedemonstreerd, toen Charlie Miller en Chris Valasek op afstand een Jeep wisten over te nemen via het infotainmentsysteem.
Hun voorbeeld staat niet op zichzelf. De meeste voertuigen die vandaag de dag op de markt komen, bevatten verschillende draadloze technologieën, waaronder mobiel, wifi, bluetooth en nfc. Vaak is er een direct pad van deze draadloze technologieën naar de centrale communicatiebus van het voertuig, die niet alleen toegang geeft tot de navigatie en de beveiliging maar ook tot het rem- en stuursysteem en de cruisecontrol. Omdat internetverbinding nu de norm is, zijn bedrijven genoodzaakt bij te leren over de problemen en oplossingen.
Aanvalsoppervlak
De Iso 26262-norm biedt een specifiek op voertuigen gerichte en op risico gebaseerde benadering om de integriteitsniveaus te bepalen. De toewijzing van zo’n asil (automotive safety integrity level) aan de verschillende voertuigsystemen gaat ervan uit dat ze gescheiden zijn, zodat de meest essentiële onderdelen niet in gevaar kunnen worden gebracht door minder belangrijke functionaliteit elders.
Dit was van oudsher geen probleem. Traditioneel beperkten ecu’s zich tot een afgebakende lokale functie, zoals motorregeling of abs. De steeds holistischere aanpak van voertuigregeling bracht echter ook steeds meer interactie tussen de modules met zich mee.
Een simpel voorbeeld hiervan is de automatische schakelbak: de motor moet zijn snelheid doorgeven aan de transmissie, en die moet andere modules laten weten wanneer naar een andere versnelling wordt geschakeld. Traditioneel werden kabelbomen gebruikt voor deze communicatie, maar toen voorzieningen als cruisecontrol en antiblokkeersystemen hun intrede deden, werd de communicatie daar te complex voor.
Als oplossing hiervoor werden voertuignetwerken ontwikkeld, gewoonlijk in de vorm van een controller area network (can). Dit netwerk voorziet in een uniforme bedradingsarchitectuur voor gegevensuitwisseling, ongeacht de opties die het voertuig bevat. Alle modules kunnen hier gewoon op worden aangesloten.
Omdat het voertuig geen verbinding had met de buitenwereld, veroorzaakte deze connectiviteit tussen modules weinig tot geen risico voor de beveiliging. Zolang kon worden aangetoond dat de communicatiemechanismen geen invloed hadden op de integriteit van de systemen die er gebruik van maakten, werden deze systemen beschouwd als ‘gescheiden’ en bleven de principes van Iso 26262 gehandhaafd.
De auto met internetverbinding brengt hier verandering in. Aanvallers kunnen zich nu van buitenaf toegang verschaffen via de zwakke punten in het systeem. Zelfs de onbelangrijke of niet-essentiële componenten vormen een risico, want een zwakke plek hierin geeft toegang tot de missiekritieke asil-systemen. Met andere woorden: een hacker die toegang heeft gekregen tot de infotainment in een auto kan net zo makkelijk toegang krijgen tot het remsysteem.
Het wordt duidelijk dat een voertuig met internetverbinding nooit hetzelfde beveiligingsniveau kan bieden als een auto zonder. Voor de beveiliging en de naleving van de principes van Iso 26262 voor een verbonden voertuig, is het van belang het aanvalsoppervlak tot een minimum te beperken en de scheiding tussen systemen zo groot mogelijk te maken.
Problematische oplossing
Tesla gebruikt in zijn Model S een fysieke (lan-can-)gateway om het infotainmentsysteem te scheiden van de voor de veiligheid essentiële voertuigregeling (Figuur 1). De gateway implementeert een gestructureerde api die een beperkte reeks opdrachten tussen de twee netwerken ondersteunt. Een gedetailleerde kennis van die api is vereist om toegang te krijgen tot de veiligheidskritieke voertuigregelingen.
Het systeem van Tesla levert weliswaar een doeltreffende aanpak voor scheiding op, maar zelfs die blijkt niet volledig waterdicht, wat waarschijnlijk aantoont hoe moeilijk de uitdaging van de auto met internetverbinding is. Bovendien brengt de aanpak hoge hardwarekosten met zich mee.
Laten we als alternatief eens een systeem beschouwen dat vergelijkbaar is met dat van Tesla maar de scheiding baseert op een hypervisor in plaats van hardware. De hypervisor zou hierin net als bij Tesla communicatie tussen twee zeer verschillende apps (virtuele machines of vm’s) moeten kunnen beperken, bijvoorbeeld tussen de voertuigregeling en het infotainmentsysteem. Eenzelfde soort api als in de Tesla zou hier een goede keus zijn.
Vanuit een beveiligingsstandpunt is het echter essentieel dat de vm voor voertuigregeling niet kwetsbaar is wanneer de infotainment-vm wordt gehackt. De vm’s moeten werkelijk gescheiden zijn, in plaats van verbonden door de hypervisor. Het aanvalsoppervlak moet zo klein mogelijk worden gemaakt door zo weinig mogelijk hulpbronnen tussen de vm’s te delen.
Een goed voorbeeld van een problematische oplossing is KVM, een infrastructuur om de Linux-kernel in te zetten als hypervisor. Als we deze aanpak zouden verkiezen voor het voertuigsysteem, dan zou de beveiliging van de vm voor voertuigregeling afhankelijk zijn van een monolithische kernel die bijna vierhonderd interfaces blootlegt, met vele duizenden parameteropties, geïmplementeerd door 19,5 miljoen regels alsmaar veranderende code. De i/o-stack zou in de monolithische kernel van de hypervisor zitten en levert zo een toegankelijke aanvalsvector voor de vm’s.
KVM biedt dus wel de hypervisorfunctionaliteit die nodig is voor de systeemfuncties, maar als het scheiden van meer en minder veiligheidskritieke vm’s het hoofddoel is, is deze oplossing verre van ideaal. Hiervoor is het beter de primaire focus van de architectuur te richten op scheiding en het minimaliseren van het aanvalsoppervlak.
Hardwarevirtualisatie
Om inzicht te krijgen in hoe dit te bereiken, moeten we eerst de beginselen van minimale toegangsrechten en scheidingskernels nader bekijken. Het concept van een scheidingskernel werd in 1981 voor het eerst onderzocht door John Rushby. Die concludeerde dat zo’n kernel moet bestaan uit ‘een combinatie van hardware en software die meerdere functies mogelijk maakt op een gemeenschappelijke set fysieke hulpbronnen, zonder elkaar ongewenst wederzijds te verstoren’. En Jerome Salzer en Michael Schroeder opperden dertig jaar terug dat ‘elk programma en elke gebruiker van het systeem slechts de minimale toegangsrechten moeten hebben die nodig zijn om de taak uit te voeren’. Wanneer de beginselen van minimale toegangsrechten en scheidingskernels worden gecombineerd, zijn onderwerpen en hulpbronnen fijnmazig te beheren (Figuur 2).
Deze beginselen zijn dus duidelijk niet nieuw. Maar pas dankzij de opkomst van hardwaregebaseerde virtualisatie (Intel VT, Arm V7 en V8, NXP Virtualization Extensions, Mips Virtualization, enzovoorts), werd het mogelijk de aanpak zonder overhead toe te passen.
Met een scheidingskernel die hiervan gebruik kan maken, zijn de basisprincipes te realiseren. Elke afzonderlijke module kan als vm worden geïmplementeerd. Het uitgangspunt van minimale toegangsrechten wordt gerealiseerd door de kernel niets te laten doen dat logischerwijs in de gebruikersruimte kan worden gedaan, zoals stuurprogramma’s, vm-monitors en (kritieke) i/o-stacks.
Een dergelijke scheidingskernel kan zo in slechts 25 duizend coderegels worden geschreven, een stuk beter dan de 19,5 miljoen van KVM. Met deze aanpak krijgt elke vm een ‘virtueel moederbord’ met de hulpbronnen die de systeemarchitect tijdens de configuratie specificeert. Zo kan elk besturingssysteem dat door de onderliggende hardware wordt ondersteund, worden gehost door een scheidingskernel-hypervisor.
De scheidingskernel is niet de enige aanpak om het principe van minimale toegangsrechten toe te passen. In het tijdperk vóór hardwarevirtualisatie werd microkerneltechnologie met minimale toegangsrechten ontwikkeld, een voor die tijd bewonderenswaardige oplossing. Er waren hierbij twee niveaus van toegangsrechten: supervisor en gebruiker. Potentieel kwetsbare code, zoals stuurprogramma’s, werden uitgevoerd in de gebruikersruimte in plaats van in de supervisorruimte.
Met de ontwikkeling van hardwarevirtualisatie werd het toegangsniveau virtual machine monitor (vmm) geïntroduceerd, wat een dilemma veroorzaakte voor de microkernelarchitectuur. Bij het negeren van dit hogere rechtenniveau zou een kwetsbaar en krachtig aanvalsoppervlak compleet buiten beschouwing worden gelaten. Maar als de functionaliteit uit de supervisorruimte simpelweg naar dit nieuwe niveau zou worden verhuisd, zou een grote hoeveelheid code met meer rechten draaien dan nodig.
Sindsdien is het ontwerp van de microkernel verder ontwikkeld om rekening te houden met hardwarevirtualisatie en de bijbehorende niveaus van toegangsrechten, en sommige microkernels maken er nu zelfs gebruik van. Het is echter onvermijdelijk dat er toch code wordt uitgevoerd op een hoger niveau dan de beginselen van minimale toegangsrechten voorschrijven. In gebieden waar beveiliging cruciaal is, is dit geen aanvaardbaar alternatief. Wil een beveiligingskritieke scheidingsoplossing het aanvalsoppervlak optimaal minimaliseren, dan moet die ervoor zorgen dat elke softwarecomponent minimale toegangsrechten heeft om zijn functie te kunnen uitvoeren in deze ‘nieuwe wereld’ van hardwarevirtualisatie.
In de praktijk
Hoewel scheidingskernels gebaseerd zijn op goed onderlegde beginselen, hebben ze alleen nut als ze ook daadwerkelijk in de echte wereld kunnen beschermen tegen cyberaanvallen. Ze moeten dus gebruikt kunnen worden in de context van bestaande infrastructuur, die hoofdzakelijk uit het openbare internet bestaat. De verantwoordelijkheid voor de beveiliging rust hier op de gateway-apparaten in de auto. Een belangrijk uitgangspunt is om bouw en onderhoud van meerdere voertuignetwerken te vermijden, vanwege de hoge kosten.
Figuur 3 toont hoe een dergelijk systeem er in de praktijk uit kan zien. De netwerk- en gegevensverwerkingsfuncties worden geïmplementeerd als kleine vm’s met minimale toegangsrechten die worden uitgevoerd als bare metal-applicaties om hun footprint en kwetsbaarheid zo veel mogelijk in te perken. Daarnaast zijn er vm’s die de mogelijkheid bieden om apps uit te voeren. Die kunnen worden toegewezen aan de individuele kernen van een multicore processor wanneer hard realtime uitvoer wordt vereist.
Dit alles resulteert in een robuuste oplossing met veerkrachtige applicatie-interfaces om te voorkomen dat kwaadaardige software de virtuele softwarearchitectuur ondermijnt. De integriteit van kritieke applicaties blijft behouden door ze te beschermen tegen beschadigingen in andere delen van de toepassingen. De kosten blijven beperkt tot een minimum en tegelijkertijd wordt vertrouwelijkheid gegarandeerd door de toepassing van een enkele netwerkstructuur. Bovendien kan ervoor worden gezorgd dat de officiële voertuigapplicaties worden gebruikt en dat de netwerkencryptie niet kan worden omzeild.
