The Open Charge Alliance is a strong supporter of transparency and encourages everyone to check for issues within OCPP that could potentially harm users or otherwise breach security.
Recently, it was brought to our attention that The SaiFlow Research Team recently discovered such issues. We have analyzed their findings and we checked if they were relevant and what we could do about it.
SaiFlow mentioned two ‘vulnerabilities’: mishandling of multiple chargers’ connections and weak authentication policy. Before we dive into the details, we would like to note that the first issue can indeed occur when older OCPP versions are not equipped with the proper security additions. We also need to note that both issues do not apply for OCPP 2.0.1 which has security built in.
Additional authentication layer
OCPP 1.6 was published in 2015. The original version did not include security requirements. These were added later with and published with the OCPP1.6 Security Whitepaper in 2018 (“Improved security for OCPP 1.6-J"). OCPP 1.6J can be insecure if an additional authentication layer – as mandated in the whitepaper - is not used. In that case, it would be theoretically possible for a user to pretend to be a certain CP while communicating with the back-end. This action could lead to a denial-of-service (DOS) and that could end a session or provide free charging. The reason this can happen with older versions without the extra authentication layer, is that a potential hacker only needs an existing CP serial number to send it to the back-end.
The OCA doesn’t know how many charging point in the fieldhave not implemented the OCPP1.6 security whitepaper. In OCPP 2.0.1 it is not possible to do an attack like this. In that case the system will ask for a username and password or provide client-side certificates.
The OCA advises everyone to use OCPP 2.0.1 or to update their OCPP 1.6 implementation with at least the additions in the Security White Paper.
OCPP 1.6 including security additions and OCPP 2.0.1 are safe
The claim that OCPP 2.0.1 would also be insecure, is not true. SaiFlow states that it may not be safe if it isn’t implemented properly and that is correct. OCPP 2.0.1 is only a valid implementation if security, either username/password or client-side certificates, is used.
OCPP 1.6 also supports the use of username and password or client-side certificates, but it depends heavily on the way it is implemented. According to the OCPP 1.6J standard, it is allowed not to require additional authentication. This can therefore deviate, making it possibly unsecure. It is therefore not the case that OCPP itself is unsafe, but by consciously choosing a lower security level (or incorrect implementation) you do run the risk of a security breach.
The OCPP Conformance Testing Tools and the OCPP Certification program both test the correct implementation of the security features in OCPP1.6 and OCPP2.0.1.
Continuing testing security
The OCA appreciates the work and effort of The SaiFlow Research Team. We kindly take their findings at heart and will further test the security limits of OCPP. We also take this opportunity to stress that it is very important to implement the additions from the Security Whitepaper “Improved security for OCPP 1.6-J” for your OCPP 1.6 implementation or to use OCPP 2.0.1 instead.
If you have any questions regarding security in general or this subject specifically, please let us know.
Download: OCPP 1.6 Security Whitepaper (3rd edition).