Wat zijn OCPP-beveiligingsprofielen?

OCPP-beveiligingsprofielen bepalen hoe een laadstation en een beheersysteem voor laadstations (CSMS of CPMS) hun OCPP-verbinding verifiëren en beveiligen. Ze hebben betrekking op de verbinding tussen het laadstation en het beheersysteem. Ze zorgen op zichzelf niet voor de beveiliging van het volledige laadstation, de backend, de mobiele app of het bredere netwerk.

 

OCPP 2.x maakt gebruik van drie benoemde profielen: profiel 1, 2 en 3. Sommige beveiligingsuitbreidingstools voor OCPP 1.6 verwijzen ook naar profiel 0 als een onbeveiligde starttoestand. Dit profiel beschikt noch over TLS-transportbeveiliging, noch over basisauthenticatie en mag niet worden beschouwd als een beveiligde veldconfiguratie. In het OCPP 1.6-beveiligingswhitepaper wordt uitgelegd hoe latere beveiligingsfuncties kunnen worden toegevoegd aan OCPP 1.6-J.

Beveiligingsprofiel 1: Basisauthenticatie zonder TLS

Profiel 1 maakt gebruik van een niet-versleutelde WebSocket-verbinding met HTTP Basic Authentication. Met het wachtwoord kan de laadpaal zich bij het CPMS identificeren, maar het CPMS wordt niet bij de laadpaal geauthenticeerd en het verkeer is tijdens de overdracht niet beveiligd.

 

De Open Charge Alliance vermeldt in haar OCPP Security Operations Guide dat Profile 1 op zichzelf niet veilig is. Het kan weliswaar achter een correct geconfigureerd privénetwerk of VPN staan, maar de beveiliging hangt dan af van dat netwerk. Voor implementaties die in verbinding staan met het internet, dient TLS te worden gebruikt.

Beveiligingsprofiel 2: TLS plus basisverificatie

Profiel 2 maakt gebruik van een beveiligde WebSocket-verbinding via TLS. De oplader controleert het certificaat van de CPMS-server, de verbinding is versleuteld en de oplader verifieert zich met een wachtwoord.

 

Elke oplader moet over unieke inloggegevens beschikken. Beheerders hebben bovendien behoefte aan een gecontroleerd proces voor de initiële configuratie, het rouleren van wachtwoorden, wijzigingen in de certificaatautoriteit en herstel bij verlies van inloggegevens. Een voor het hele wagenpark gemeenschappelijk wachtwoord doet afbreuk aan het voordeel van het profiel.

Beveiligingsprofiel 3: wederzijdse TLS met clientcertificaten

Profiel 3 voegt een clientcertificaat voor het laadstation toe. De lader controleert het CPMS-certificaat, terwijl het CPMS het certificaat van de lader controleert. Dit zorgt voor een sterkere wederzijdse identiteitscontrole dan alleen een wachtwoord.

 

De keerzijde is het beheer van de levenscyclus van certificaten. Het project heeft behoefte aan een infrastructuur voor openbare sleutels, een veilige opslag van privésleutels en beproefde processen voor registratie, verlenging, het verstrijken van de geldigheidsduur, intrekking en vervanging. Zelfs een sterker profiel kan in de praktijk nog steeds falen als die processen onduidelijk zijn.

Hoe dit van toepassing is op amina charging

Amina’s Documentatie bij OCPP 1.6j hierin staat dat LTE WebSocket-verbindingen gebruikmaken van TLS 1.2 of hoger, dat HTTP Basic Authentication wordt ondersteund en dat de inloggegevens van de charger tijdens de productie worden ingesteld. Het CSMS kan het wachtwoord later wijzigen via ChangeConfiguration met behulp van de AuthorizationKey instelling.

 

In de documentatie wordt ook melding gemaakt van support clientcertificaten support ondertekende OTA-firmware-updates. In de CSMS-integratiehandleiding staat dat certificaten en het gekozen CSMS-eindpunt vóór de levering kunnen worden ingesteld. Operators moeten echter nog steeds het ingeschakelde beveiligingsprofiel, de certificaatketen en het verlengingsproces voor de specifieke bestelling en firmware controleren. Deze gedocumenteerde bouwstenen bewijzen op zichzelf nog niet dat bij elke implementatie beveiligingsprofiel 3 wordt gebruikt.

Welk OCPP-beveiligingsprofiel moeten exploitanten verplicht stellen?

Voor een lader die met het internet is verbonden, is Profiel 2 in de meeste projecten het praktische minimum. Profiel 3 kan geschikt zijn wanneer wederzijdse certificaatverificatie vereist is en de exploitant of CPMS-aanbieder de levenscyclus van het certificaat op betrouwbare wijze kan beheren.

 

Voor OCPP 2.x-implementaties is het beveiligde verbindingsmodel vereist, in plaats van een onbeveiligde fallback. De Open Charge Alliance heeft bovendien Security Profile 2 opgenomen in de bijgewerkte certificeringseisen voor OCPP 1.6 Core. Certificering en support het profiel support de onzekerheid, maar geen van beide is een vervanging voor het testen van de exacte combinatie van lader, firmware en CPMS.

Wat moet er vóór de implementatie worden gecontroleerd?

  • de OCPP-versie en de beveiligingsuitbreiding die door de lader en het CPMS worden gebruikt;
  • het hoogste ondersteunde profiel en het profiel dat in de productieomgeving is ingeschakeld;
  • wie verantwoordelijk is voor het beheer, de verstrekking en de vervanging van wachtwoorden en certificaten;
  • hoe er wordt omgegaan met het verlopen van certificaten, intrekking ervan en klokfouten;
  • of de validatie van de hostnaam en het certificaat wordt afgedwongen;
  • of een mislukte beveiligde verbinding kan leiden tot een onveilige downgrade;
  • hoe beveiligingsgebeurtenissen en mislukte authenticatiepogingen worden geregistreerd; en
  • of firmware, diagnostische functies en andere gerelateerde kanalen beveiligd zijn.

Leg deze beslissingen vast in de integratiespecificatie. De vermelding „Ondersteunt OCPP” is niet voldoende om vast te stellen hoe de verbinding in de praktijk wordt beveiligd.