OCPP-beveiliging: securityprofielen 1, 2 en 3 uitgelegd

De drie securityprofielen

Profiel 1 — alleen binnen een gesloten netwerk

Profiel 1 stuurt gebruikersnaam en wachtwoord onversleuteld over de lijn via HTTP Basic Authentication. Iedereen die het verkeer kan meelezen, ziet de inloggegevens in leesbare vorm en kan zich daarna voordoen als die laadpaal.

Dit profiel is alleen verdedigbaar binnen een fysiek afgeschermd netwerk waar geen ander verkeer op zit — bijvoorbeeld een eigen VLAN op een bedrijfsterrein. Zodra er een router met internetverbinding tussen zit, is het onvoldoende.

Profiel 2 — het praktische minimum

Profiel 2 zet dezelfde gebruikersnaam en wachtwoord binnen een TLS-verbinding. Het verkeer is daarmee versleuteld en de laadpaal controleert of hij met de juiste server praat, aan de hand van het servercertificaat.

Voor de meeste bedrijfsopstellingen is dit voldoende en is het ook realistisch haalbaar op bestaande 1.6-hardware. De zwakte blijft dat het wachtwoord in de laadpaal staat opgeslagen: wie fysiek toegang heeft tot het apparaat, kan het uitlezen.

Profiel 3 — wederzijdse certificaten

Profiel 3 vervangt het wachtwoord door een client-certificaat, waarbij paal en server elkaars identiteit controleren. Dit heet wederzijdse TLS (mTLS) en is de sterkste variant die OCPP kent.

Het voordeel is dat certificaten intrekbaar zijn en aflopen. Raakt een laadpaal kwijt of wordt er geknoeid, dan trek je één certificaat in zonder alle andere palen aan te passen. De prijs is beheerlast: je hebt een certificaatinfrastructuur nodig die uitgifte en vernieuwing regelt.

Wat er misgaat zonder beveiliging

Een onbeveiligde OCPP-verbinding is niet alleen een privacyprobleem. De verbinding is bidirectioneel, wat betekent dat wie zich als CSMS kan voordoen ook opdrachten naar de paal kan sturen.

• Sessies meelezen: wie laadt wanneer, met welke pas en hoeveel. Dat is herleidbaar naar personen.
• Gratis laden: door de identifier van een geldige laadpas te hergebruiken uit meegelezen verkeer.
• Palen op afstand uitschakelen via ChangeAvailability of Reset, met een hele locatie plat als gevolg.
• Firmware vervangen via UpdateFirmware, waarmee een aanvaller permanente controle over het apparaat krijgt.
• Laadprofielen manipuleren, met overbelasting van de aansluiting als gevolg.

Wat je concreet moet regelen

1. 1Controleer welk profiel je nu draait. Begint het serveradres in de laadpaalconfiguratie met ws:// in plaats van wss://, dan draai je profiel 1 zonder versleuteling.
2. 2Zet minimaal profiel 2 aan. Dat vraagt een geldig TLS-certificaat op je CSMS en een aanpassing van het serveradres in elke laadpaal.
3. 3Geef elke laadpaal een eigen wachtwoord. Eén gedeeld wachtwoord over het hele park betekent dat één gecompromitteerde paal het hele park opent.
4. 4Controleer of de paal het servercertificaat daadwerkelijk valideert. Sommige firmware accepteert elk certificaat, waarmee TLS zijn belangrijkste bescherming verliest.
5. 5Beperk wie firmware mag pushen. Leg vast welke URL's zijn toegestaan en log elke UpdateFirmware-opdracht.

Stap één levert vaak een onaangename verrassing op. In veel bestaande installaties staat nog een ws://-adres uit de begintijd, omdat er destijds geen certificaat beschikbaar was en het daarna nooit is aangepast.

Certificaatbeheer in OCPP 2.0.1

OCPP 2.0.1 bevat berichten om certificaten op afstand te beheren, wat in 1.6 volledig ontbreekt. Daarmee wordt profiel 3 pas echt werkbaar op grotere schaal.

Met deze berichten kan een laadpaal zijn eigen certificaat vernieuwen voordat het verloopt, zonder dat er iemand ter plaatse hoeft te komen. Op een park van honderd palen is dat het verschil tussen beheersbaar en onwerkbaar.

Daarnaast kent 2.0.1 SecurityEventNotification, waarmee een laadpaal beveiligingsgebeurtenissen meldt: een mislukte inlogpoging, een gewijzigde configuratie of een firmware-installatie. Die meldingen horen in je monitoring, niet alleen in een logbestand.