Hva er OCPP-sikkerhetsprofiler?

OCPP-sikkerhetsprofiler definerer hvordan en ladestasjon og et ladestasjonsadministrasjonssystem (CSMS eller CPMS) autentiserer og beskytter OCPP-tilkoblingen sin. De dekker koblingen mellom lader og administrasjonssystem. De sikrer ikke i seg selv hele laderen, backend-systemet, mobilappen eller det bredere nettverket.

 

OCPP 2.x bruker tre navngitte profiler: Profil 1, 2 og 3. Noen OCPP 1.6-sikkerhetsutvidelsesverktøy refererer også til Profil 0 som en ubeskyttet starttilstand. Den har verken TLS-transportsikkerhet eller grunnleggende autentisering og bør ikke behandles som en sikker feltkonfigurasjon. OCPP 1.6-sikkerhetsrapporten forklarer hvordan senere sikkerhetsfunksjoner kan legges til OCPP 1.6-J.

Sikkerhetsprofil 1: Grunnleggende autentisering uten TLS

Profil 1 bruker en ukryptert WebSocket-tilkobling med HTTP Basic Authentication. Passordet lar laderen identifisere seg overfor CPMS, men CPMS autentiseres ikke overfor laderen, og trafikken er ikke beskyttet underveis.

 

Open Charge Alliance oppgir i sin OCPP Security Operations Guide at Profile 1 ikke er sikker i seg selv. Den kan ligge bak et korrekt konfigurert privat nettverk eller VPN, men beskyttelsen avhenger da av det nettverket. For internett-rettet implementering bør TLS brukes.

Sikkerhetsprofil 2: TLS pluss grunnleggende autentisering

Profil 2 bruker en sikker WebSocket-tilkobling over TLS. Laderen validerer CPMS-serversertifikatet, tilkoblingen krypteres, og laderen autentiserer med et passord.

 

Hver lader bør ha unike påloggingsinformasjon. Operatører trenger også en kontrollert prosess for førstegangs klargjøring, passordrotasjon, endringer hos sertifikatmyndighet og gjenoppretting når påloggingsinformasjonen går tapt. Et delt passord for hele flåten svekker fordelen med profilen.

Sikkerhetsprofil 3: gjensidig TLS med klientsertifikater

Profil 3 legger til et klientsertifikat for ladestasjonen. Laderen validerer CPMS-sertifikatet, mens CPMS validerer ladersertifikatet. Dette gir sterkere toveisidentitet enn bare et passord.

 

Avveiningen er sertifikatlivssyklushåndtering. Prosjektet trenger en offentlig nøkkelinfrastruktur, sikker lagring av private nøkler og testede prosesser for registrering, fornyelse, utløp, tilbakekalling og erstatning. En sterkere profil kan fortsatt mislykkes driftsmessig hvis disse prosessene er uklare.

Hvordan dette gjelder amina charging stasjoner

aminas OCPP 1.6j-dokumentasjon angir at LTE WebSocket-tilkoblinger bruker TLS 1.2 eller høyere, HTTP Basic Authentication støttes og laderlegitimasjon klargjøres under produksjon. CSMS kan senere endre passordet gjennom ChangeConfiguration ved hjelp av AuthorizationKey innstilling.

 

Dokumentasjonen viser også klientsertifikat support og signerte OTA-fastvareoppdateringer. CSMS-integrasjonsveiledningen sier at sertifikater og det valgte CSMS-endepunktet kan klargjøres før levering. Operatører bør fortsatt bekrefte den aktiverte sikkerhetsprofilen, sertifikatkjeden og fornyelsesprosessen for den nøyaktige bestillingen og fastvaren. Disse dokumenterte byggeklossene beviser ikke i seg selv at hver implementering bruker sikkerhetsprofil 3.

Hvilken OCPP-sikkerhetsprofil bør operatører kreve?

For en internettrettet lader er Profil 2 det praktiske minimum i de fleste prosjekter. Profil 3 kan være passende der gjensidig sertifikatgodkjenning er nødvendig, og operatøren eller CPMS-leverandøren kan administrere sertifikatets livssyklus på en pålitelig måte.

 

OCPP 2.x-implementeringer krever den sikrede tilkoblingsmodellen i stedet for en usikret reserve. Open Charge Alliance gjorde også Security Profile 2 til en del av de oppdaterte OCPP 1.6 Core-sertifiseringskravene . Sertifisering og profil support reduserer usikkerhet, men ingen av dem erstatter testing av den nøyaktige kombinasjonen av lader, fastvare og CPMS.

Hva bør sjekkes før utplassering?

  • OCPP-versjonen og sikkerhetsutvidelsen som brukes av laderen og CPMS;
  • den høyeste profilen som støttes og profilen som er aktivert i produksjon;
  • hvem eier, klargjør og roterer passord og sertifikater;
  • hvordan sertifikatutløp, tilbakekalling og klokkefeil håndteres;
  • om validering av vertsnavn og sertifikat håndheves;
  • om en mislykket sikker tilkobling kan forårsake en usikker nedgradering;
  • hvordan sikkerhetshendelser og mislykkede autentiseringsforsøk logges; og
  • om fastvare, diagnostikk og andre relaterte kanaler er beskyttet.

Registrer disse beslutningene i integrasjonsspesifikasjonen. «Støtter OCPP» er ikke nok til å fastslå hvordan forbindelsen er sikret i praksis.