Vad är OCPP-säkerhetsprofiler?

OCPP-säkerhetsprofilerna definierar hur en laddstation och ett laddstationshanteringssystem (CSMS eller CPMS) autentiserar och skyddar sin OCPP-anslutning. De omfattar länken mellan laddaren och hanteringssystemet. De säkerställer inte i sig själva hela laddaren, backend-systemet, mobilappen eller det övergripande nätverket.

 

OCPP 2.x använder tre namngivna profiler: Profil 1, 2 och 3. Vissa verktyg för säkerhetsutvidgningar i OCPP 1.6 hänvisar även till Profil 0 som ett oskyddat utgångstillstånd. Den har varken TLS-transportsäkerhet eller Basic-autentisering och bör inte betraktas som en säker fältkonfiguration. I säkerhetsrapporten för OCPP 1.6 förklaras hur senare säkerhetsfunktioner kan läggas till i OCPP 1.6-J.

Säkerhetsprofil 1: Grundläggande autentisering utan TLS

Profil 1 använder en okrypterad WebSocket-anslutning med HTTP Basic-autentisering. Lösenordet gör det möjligt för laddaren att identifiera sig gentemot CPMS, men CPMS är inte autentiserat gentemot laddaren och trafiken är inte skyddad under överföringen.

 

Open Charge Alliance anger i sin OCPP Security Operations Guide att Profil 1 i sig inte är säker. Den kan visserligen vara ansluten till ett korrekt konfigurerat privat nätverk eller VPN, men säkerheten beror då på det nätverket. Vid installationer som är anslutna till internet bör TLS användas.

Säkerhetsprofil 2: TLS plus grundläggande autentisering

Profil 2 använder en säker WebSocket-anslutning via TLS. Laddaren verifierar CPMS-serverns certifikat, anslutningen är krypterad och laddaren autentiserar sig med ett lösenord.

 

Varje laddare bör ha unika inloggningsuppgifter. Operatörerna behöver dessutom en kontrollerad process för initial konfiguration, lösenordsbyte, byte av certifikatutfärdare och återställning vid förlust av inloggningsuppgifter. Ett gemensamt lösenord för hela flottan minskar fördelarna med profilen.

Säkerhetsprofil 3: ömsesidigt TLS med klientcertifikat

Profil 3 lägger till ett klientcertifikat för laddstationen. Laddaren verifierar CPMS-certifikatet, medan CPMS verifierar laddarens certifikat. Detta ger en starkare ömsesidig identitetsverifiering än ett lösenord ensamt.

 

Nackdelen är hanteringen av certifikatens livscykel. Projektet kräver en infrastruktur för publika nycklar, säker lagring av privata nycklar samt beprövade processer för registrering, förnyelse, utgång, återkallande och ersättning. Även en mer robust lösning kan misslyckas i praktiken om dessa processer är otydliga.

Hur detta gäller för amina charging

Amina’s Dokumentation för OCPP 1.6j anger att LTE WebSocket-anslutningar använder TLS 1.2 eller senare, att HTTP Basic-autentisering stöds och att inloggningsuppgifter för laddaren tilldelas under driftsfasen. CSMS kan senare ändra lösenordet via ChangeConfiguration med hjälp av AuthorizationKey inställning.

 

Dokumentationen beskriver även support klientcertifikat support signerade OTA-firmwareuppdateringar. I integrationsguiden för CSMS anges att certifikat och den valda CSMS-ändpunkten kan konfigureras före leverans. Operatörerna bör ändå kontrollera vilken säkerhetsprofil som är aktiverad, certifikatkedjan och förnyelseprocessen för just den aktuella beställningen och firmwaren. Dessa dokumenterade byggstenar bevisar inte i sig att varje installation använder säkerhetsprofil 3.

Vilken OCPP-säkerhetsprofil bör operatörerna kräva?

För en laddare som är ansluten till internet är Profil 2 det praktiska minimikravet i de flesta projekt. Profil 3 kan vara lämplig i de fall där ömsesidig certifikatautentisering krävs och operatören eller CPMS-leverantören kan hantera certifikatets livscykel på ett tillförlitligt sätt.

 

OCPP 2.x-implementeringar kräver en säker anslutningsmodell istället för en osäker reservlösning. Open Charge Alliance har dessutom infört säkerhetsprofil 2 som en del av de uppdaterade certifieringskraven för OCPP 1.6 Core. Certifiering och support profiler support osäkerheten, men ersätter inte testning av den exakta kombinationen av laddare, firmware och CPMS.

Vad bör man kontrollera innan driftsättningen?

  • den OCPP-version och säkerhetsutvidgning som används av laddaren och CPMS;
  • den profil med högst prioritet som stöds och den profil som är aktiverad i produktionsmiljön;
  • vem som ansvarar för, tillhandahåller och byter ut lösenord och certifikat;
  • hur hanteringen av certifikatets giltighetstid, återkallande och klockfel sker;
  • om validering av värdnamn och certifikat krävs;
  • om en misslyckad säker anslutning kan leda till en osäker nedgradering;
  • hur säkerhetshändelser och misslyckade autentiseringsförsök loggas; och
  • om firmware, diagnostik och andra relaterade kanaler är skyddade.

Dokumentera dessa beslut i integrationsspecifikationen. Att ange ”Stöder OCPP” räcker inte för att fastställa hur anslutningen är säkrad i praktiken.