Elke werkdag behandelt Computable een onderwerp waarover lezers kunnen discussiëren. Vandaag over auto’s – zelfrijdend én gewone – die security hard nodig hebben.
Auto’s zijn al jaren doordrongen van elektronica en tegenwoordig steeds meer connected. Pas nu begint de wereld te beseffen dat de alomtegenwoordige vervoersmiddelen eigenlijk rondrijdende computers zijn. En dus hackbaar. En dus inzetbaar voor andere doeleinden dan wat de bestuurder en/of eigenaar wil. Dit geldt niet alleen voor futuristische zelfrijdende auto’s, maar ook voor gewone wagens.
Zo heeft de Amerikaanse autofabrikant Chrysler afgelopen zomer een recall-operatie afgekondigd voor 1,4 miljoen auto’s. De aanleiding was de ontdekking en onthulling (met schokkende demonstratie) van flinke kwetsbaarheden in de software. De oplossing was updaten, via een toegestuurde usb-stick. In de nazomer zijn nog eens bijna achtduizend auto’s ’herroepen’, die ook hackbaar blijken te zijn. Maar Chrysler is niet de enige. Auto’s hebben hard ict-security nodig. Wat vind jij?
Dat autofabrikanten IT innovatie op hun vlak teleurstellend slecht hebben uitgevoerd. Ze zullen terug naar af moeten gaan en vanuit een nieuwe optiek zaken weer moeten opbouwen. Meer losse autonome systemen (pun intended) ipv alles aan elkaar gekoppeld. Geen draadloze verbindingen mogelijk maken met vitale onderdelen van de auto en soortgelijke zaken.
Autobouwers hebben geen idee dat je aan diefstal via hacken moet denken. Dat is al jaren zo, nu het zelfs mogelijk wordt in de besturing in te breken, en het gevaarlijk wordt, komt er een sprankje licht zo dat er aan gewerkt wordt.
Wel erg laat, het probleem is al dik 20 jaar bekend.
Andy Rowland stipt in zijn artikel een aantal aspecten in de beveilig van ‘connected cars’ aan. Hij laat echter een fundamenteel basisaspect onderbelicht: fouten in de programmatuur. Hackers maken veelal gebruik van fouten in het dynamische gedrag van software. Hoewel er veel aandacht wordt besteed aan security in het ontwerp van software interfaces, gaat het vaak mis bij de implementatie. Met handmatige code reviews en tests spoor je slechts een deel van de fouten op. Een fout in het dynamische gedrag – zoals een ‘out-of-bound memory access’ – ontdek je niet door met veel ogen naar de code te staren. Maar dit is nu juist het soort fouten dat door hackers wordt misbruikt. Een van de bekendste voorbeelden is ‘Heartbleed’ bug in de OpenSSL library, eerder dit jaar.
De Barr Group die de software in de Toyota Camry analyseerde na het terugroepen van zo’n 8 miljoen auto’s, vond legio fouten in het dynamische gedrag: memory leaks, data races, illegal memory accesses, etc. Met zo’n 8 miljoen regels software in alleen al de web browser in Android, is het infotainmentsysteem van de auto de eerste plek waar hackers zich op richten, zoals Rowland ook aangeeft. De complexiteit en omvang van dit soort software is namelijk zo groot dat dit vol potentiele lekken zit.
De enige manier om echt secure software te maken is om dit bij de bron aan te pakken: het programmeerproces zelf. Een eerste reactie is dan vaak om over te stappen op modelgedreven ontwerp en het automatisch genereren van code. Dat heeft helaas geen zin als er sprake is van een grote, bestaande software stack. Je kan die niet zomaar weggooien om in een nieuwe taal helemaal opnieuw te beginnen. Krachtige analysetools zijn de enige oplossing om kritische fouten in bestaande software effectief en tijdig op te sporen. Hiervoor is een whitebox-aanpak nodig waarbij de analysetool in de programmacode zelf kan kijken. Vooruitziende organisaties die soort tools toepassen zullen op de lange termijn het verschil gaan maken.
Ik vind dat verhaal van Chrysler helemaal niet schokkend… Dit viel gewoon te verwachten. Zeker niet alles is vooruitgang, maar moet vooral als vooruitgang gepresenteerd worden omdat mensen anders niet snel genoeg hun op dat moment nog prima werkende elektronische apparaten inruilen voor “verbeterde”…