Enhanced security for OCCP 1.6

[guido4096]

Curious to know if there already plans to implement "Enhanced security for OCCP 1.6" from here: https://www.openchargealliance.org/uploads/files/OCPP-1.6-security-whitepaper-edition-2.zip ?

Especially the requirement that an unique authentication per charging station is recommended is difficult to achieve and maintain outside the backend. For example maintaining a reverse proxy with authentication would cause quite some overhead.

Anyways I'm concerned on operating charging stations in an untrusted network. It means the CPO has to rely/assure that the charging station software does not leak the authentication key/certificate. And at the same time being able to operate from an untrusted network may have cost benefits.

[github-actions[bot]]

Welcome to your first issue in e-Mobility software

[LucasBrazi06]

If I'm not mistaken, this is the retrofit of the Plug & Charge of the ISO15118 standard in OCPP 1.6. It's not yet planned. We only accept WSS as connection to our backend, at least the communication is protected with TLS.

[guido4096]

No, this is not about Plu & Charge. This is just the authentication between a charging station and the backend. It is the retrofit of security parts of OCPP 2.0.1 to 1.6-J.

If you only rely on the information in the URL to authorize a charging station, it is easy to abuse the backend with a malicious charging system and send false data.

Short term I believe it should be possible to protect the backend from malicious charging stations by putting a reverse proxy in front of the WSS connection that enforces authentication.

Long term, especially when working OCCP 2.0.1, I believe this is better integrated in the backend to make management easier.

[LucasBrazi06]

Thanks for the info!

If you only rely on the information in the URL to authorize a charging station, it is easy to abuse the backend with a malicious charging system and send false data.

Yes if you have access to the charging station admin console! To mitigate this we put a token in the URL that the customer can change overtime which is check in every OCPP request.

We have currently an AWS Load Balancer for connecting the charging stations and in our new Kubernetes cluster we'll have NGINX. I would be glad to have you expertise in this area :-).

Yes, I agree, long term, we need this integration!!! We also experienced that charging station manufacturers are very slow to implement such enhancements.

[guido4096]

I have to setup an experiment with an nginx reverse proxy, I'll let you know the results. Might take a week or two.

In principle the authentication is claimed to be standard web protocol hence nginx should be able to do the authentication.

Even if you have the special token in the URL, this does not prevent against attacks. The token is a static token, a MITM attack can easily intercept this and can do whatever he wants.

Because the authentication is part of the header, it cannot be intercepted and at least prevents against MITM attacks. Alfen supports the authentication.

[LucasBrazi06]

@guido4096 Thanks for this precious information! You are much deeper in security that I will ever be :-). Let me know, we can check it on our QA system where we have an NGINX ingress. https://kubernetes.github.io/ingress-nginx/

[LucasBrazi06]

Closed for inactivity

[LucasBrazi06]

Closed for inactivity