Waarom de cybersecurity van laadpalen een uitdaging blijft

De afgelopen vijftien jaar hebben Nederlandse bedrijven wereldwijd vooropgelopen in het uitbreiden van laadinfrastructuur voor elektrische voertuigen. Merken als Alfen, EVBox, Fastned en NewMotion — dat werd overgenomen door Shell — staan in binnen- en buitenland bekend als pioniers die ervoor zorgen dat bestuurders van elektrische voertuigen overal hun accu kunnen bijladen.

Deze commerciële successen worden geschraagd door succesvolle consortia en industriestandaarden. Misschien wel de meest succesvolle standaard is het Open Charge Point Protocol (OCPP), een netwerkprotocol waarmee laadpalen kunnen communiceren met de centrale beheersystemen van laadpaalexploitanten (CPO's). OCPP wordt ontwikkeld door een consortium genaamd de Open Charge Alliance, gevestigd in Arnhem.

Op 20 november 2018 bracht de Open Charge Alliance de eerste versie uit van een whitepaper getiteld "Improved Security for OCPP 1.6-J". Sindsdien is dit document twee keer herzien; de meest recente editie uit februari 2022 is hier te downloaden.

Hoewel dit security whitepaper zijn vijfde verjaardag nadert en het belang van beveiliging onmiskenbaar is, zijn de aanbevelingen uit dit whitepaper nog lang niet overal in de laadsector geïmplementeerd. Wij bij Infuse (een ihomer-bedrijf) krijgen regelmatig vragen van CPO's over wat dit security whitepaper voor hun business betekent. In dit artikel leggen we uit wat je met het security whitepaper moet doen en waarom het hoog tijd is om ermee aan de slag te gaan.

Het beveiligingsprobleem van OCPP

Laadpalen zijn vrijwel altijd verbonden met een serversysteem om de facturatie te beheren en de beschikbaarheid te tonen aan bestuurders van elektrische voertuigen in navigatie-apps. Goed doordachte cybersecuritymaatregelen zijn essentieel om de persoonsgegevens van EV-bestuurders te beschermen en fraude en misbruik door kwaadwillenden te voorkomen.

In ons dagelijks leven zijn maatregelen voor cybersecurity inmiddels heel gewoon. We letten op het hangslotsymbool in de adresbalk van de browser als we inloggen op onze bankrekening, en wanneer we met een bankapp een betaling doen via een QR-code op een nieuwe telefoon, vraagt de telefoon toestemming voor de app om de camera te gebruiken.

Voor de meeste laadpalen zijn beveiligingsmaatregelen echter allesbehalve vanzelfsprekend, ondanks de duidelijke noodzaak. In de onvolwassen markt van de jaren 2000 en 2010 had beveiliging geen hoge prioriteit. Daarnaast zijn niet alleen laadpalen relatief nieuw, maar ook het Internet of Things, waar deze laadpalen vrijwel altijd deel van uitmaken. Het Internet of Things bestaat uit alle "slimme" apparaten die verbonden zijn met digitale clouddiensten.

De technologie om apparaten met het Internet of Things te verbinden, is pas recentelijk volwassen geworden. Hilarische verhalen over "slimme" magnetrons die kapotgaan door een firmware-"update" en minder vermakelijk nieuws over criminelen die toegang krijgen tot beveiligingscamera's hebben het bewustzijn van de risico's vergroot. Fabrikanten doen meer hun best, en overheden beginnen veiligheidseisen te formuleren voor apparaten met een internetverbinding.

In 2017 was de situatie rond laadpalen en OCPP bedroevend. Op een congres van de Chaos Computer Club gaf ethisch hacker Mathias Dalheimer een presentatie waarin hij de beveiliging van een OCPP-laadpaal genadeloos onderuithaalde. Gelukkig zaten er veel vertegenwoordigers uit de laadsector in het publiek, die aangaven bereid te zijn aan verbeteringen te werken.

Wat het security whitepaper doet

Ruim anderhalf jaar later bracht de OCA haar security whitepaper uit. Het security whitepaper beschrijft hoe je verbindingen met versie 1.6 van OCPP beveiligt. De term "whitepaper" doet het document eigenlijk geen recht; het lijkt meer op een specificatie met eisen. Deze eisen sluiten grotendeels aan op de beveiligingseisen die later in OCPP-versie 2.0.1 zijn opgenomen.

Wat leveren deze eisen ons op? Ten eerste garandeert de implementatie de volgende vier eigenschappen van veilige communicatie tussen CPO's en laadpalen:

• Vertrouwelijkheid (confidentiality): alleen de afzender en ontvanger kunnen de inhoud van een bericht zien.
• Integriteit (integrity): het bericht komt bij de ontvanger aan zonder bedoelde of onbedoelde wijzigingen.
• Authenticiteit (authenticity): ontvanger en afzender zijn zeker van elkaars identiteit.
• Onweerlegbaarheid (non-repudiation): de afzender kan later niet ontkennen het bericht te hebben verstuurd.

Daarnaast bevat het security whitepaper eisen die twee extra beveiligingsfuncties aan OCPP toevoegen:

• Een logboek van beveiligingsincidenten dat de laadpaal moet bijhouden en op verzoek naar het beheersysteem moet versturen.
• Een nieuwe, veiligere procedure voor het uitvoeren van firmware-updates.

Op het world wide web werd eind jaren negentig de standaard Transport Layer Security (TLS) geïntroduceerd om deze vier eigenschappen van veilige communicatie te waarborgen bij communicatie tussen webbrowsers en webservers. Tegenwoordig wordt deze standaard ook breed toegepast voor het Internet of Things. Het is dan ook niet verwonderlijk dat OCPP ervoor heeft gekozen om TLS te gebruiken om communicatieverbindingen te beveiligen.

De keuze voor TLS stelt CPO's in staat om breed ingezette websoftware te gebruiken om de communicatie met de laadpaal te beveiligen, wat de benodigde investering en ontwikkeltijd vermindert.

Uitdagingen bij de implementatie

Als het security whitepaper zoveel verbeteringen biedt, waarom wordt het dan niet door alle CPO's gebruikt? Daar zijn verschillende redenen voor.

Ten eerste speelt technische schuld een rol. Veel van de partijen die nu actief zijn in het laden, zitten al tien tot vijftien jaar in het vak. In de begintijd improviseerden ze vaak oplossingen om hun laadnetwerken van de grond te krijgen. Dankzij die pioniersgeest loopt Nederland voorop in het laden van voertuigen, maar deze systemen zijn vaak niet veilig. Deze partijen willen nu veiliger werken, maar veel van hun laadpalen en softwaresystemen zijn onveilig gebouwd. Het ombouwen van deze bestaande, functionerende systemen naar een veilige staat is duur en tijdrovend. In de praktijk is het kostbaarder om een bestaand onveilig netwerk naar een veilige staat te upgraden dan om een nieuw, veilig netwerk te bouwen. CPO's maken zich zorgen over de kosten van het ontwikkelen van nieuwe, veilige firmware voor oude laadpalen en de risico's van het aanpassen van onveilige maar kritieke softwaresystemen.

Ten tweede wordt beveiliging vaak gezien als een technische aangelegenheid, terwijl het beveiligen van een laadpaalnetwerk ook aanpassingen vereist in de productie- en bedrijfsprocessen van de CPO buiten de IT-afdeling.

Als voorbeeld van een bedrijfsproces dat moet worden ingericht: het uitgeven en beheren van de secrets voor laadpalen.

Om een laadpaal veilig met een beheersysteem te verbinden, heeft de laadpaal een secret nodig, zoals een wachtwoord of een private sleutel. Een CPO moet een proces inrichten om deze secrets aan te maken, ze op de laadpaal te installeren, ervoor te zorgen dat ze door het beheersysteem worden herkend en — het belangrijkste — de secrets geheim te houden. Ze zullen moeten beslissen of de fabrikant van de laadpaal of de exploitant de secrets aanmaakt en op de laadpaal installeert. In beide gevallen moet worden nagedacht over hoe het beheersysteem de juiste secrets herkent, zelfs wanneer de fabrikant geen directe relatie met de CPO heeft en de laadpaal via tussenpersonen of overnames in het CPO-netwerk terecht is gekomen.

Als er iets misgaat met het beheer van zo'n secret, kan een laadpaal geen verbinding meer maken met het beheersysteem. De klantenservice en technische ondersteuning van de CPO moeten zo'n probleem kunnen herkennen en oplossen. Dat is extra lastig omdat de laadpaal niet langer via OCPP met het beheersysteem is verbonden, waardoor de meeste procedures voor probleemoplossing op afstand niet meer werken.

Kortom: als een CPO zonder nadenken beveiligingsfuncties aan zijn software toevoegt, zonder voorbereid te zijn op de operationele gevolgen en zonder bedrijfsprocessen buiten de softwareafdeling aan te passen, zullen deze beveiligingsfuncties tot operationele problemen leiden en al snel weer worden uitgezet.

Waarom je toch door de zure appel moet bijten

Hoewel er begrijpelijke redenen zijn waarom de adoptie van het security whitepaper langzaam verloopt, hopen en verwachten we bij Infuse dat het geen vijf jaar meer duurt voordat het gangbaar wordt voor CPO's om het security whitepaper te gebruiken, of OCPP 2.0.1, dat dezelfde beveiligingsfuncties biedt.

Deze verwachting wordt gedreven door meerdere elkaar versterkende ontwikkelingen. Ten eerste nemen overheden cybersecurity-eisen op in aanbestedingen en subsidieprogramma's. Ten tweede worden door fusies en overnames kleinere CPO's zonder gespecialiseerde cybersecuritykennis samengevoegd tot grotere, professionelere organisaties die zich beter bewust zijn van de risico's. Ten derde bieden nieuwere versies van standaarden, zoals OCPP 2.0.1, duidelijke beveiligingseisen en -aanbevelingen, in tegenstelling tot eerdere versies als OCPP 1.6 en met name OCPP 1.5.

Een vierde ontwikkeling is dat veel landen nu, zij het later dan Nederland, beginnen met de serieuze uitrol van publieke laadinfrastructuur. Deze landen zullen proberen de in Nederland ontwikkelde oplossingen te verbeteren. Ze zullen hogere eisen stellen aan niet-functionele aspecten zoals consumentenbescherming en cybersecurity dan we in Nederland gewend zijn. Dat blijkt in de praktijk al uit de Electric Vehicle Supply Equipment Standards Regulation in Californië en het NEVI-investeringsprogramma van de Amerikaanse federale overheid. Als Nederlandse laadpaalfabrikanten en -exploitanten zaken willen doen in Amerika, zullen ze aan de hoge Amerikaanse verwachtingen moeten voldoen.

Een vijfde reden dat CPO's beveiliging gaan aanpakken, is dat de technische implementatie steeds eenvoudiger wordt door de toenemende beschikbaarheid van kant-en-klare softwarecomponenten voor laadpaalbeheer en OCPP-communicatie. Op het moment van schrijven staan er 564 projecten op GitHub met code die gerelateerd is aan OCPP. Commercieel zijn er veel aanbieders van laadpaalbeheersystemen en kant-en-klare firmwaremodules, van gevestigde namen als Driivz en has.to.be tot relatieve nieuwkomers als Pionix.

Het security whitepaper en Infuse

Infuse en haar voorgangers zijn vanaf het begin betrokken geweest bij het security whitepaper. We hebben ervaring opgedaan met het implementeren van diverse functies uit het security whitepaper bij verschillende toonaangevende bedrijven in de Europese laadmarkt. Daarbij houden we ook rekening met de noodzakelijke operationele veranderingen voor een veilige en prettige klantervaring.

Wil je eens vrijblijvend met ons van gedachten wisselen over beveiliging en OCPP? Plan een gesprek via ihomer.nl/en/over-ons/contact.