OCPP version 2.0.1 introduces encrypted secure communication between charging stations and management systems, making security one of the key improvements of 2.0.1 over previous versions.
Charging stations now have three options for connecting to a management system, in increasing levels of security they are; Profile 1, Profile 2, and Profile 3.
Three security profiles are defined in OCPP 2.0.1 with increasing levels of security as numbers are ascended from 1 to 3.
Profile 1 (No Security)Security profile 1 is the same as is used in vanilla OCPP 1.6, it involves no secure connection and communications are open to various methods of hacking.
The charging station is authenticated using a username and password which are included in the header of the websocket connection request. The CSMS then checks if this station has been registered already and decides whether to accept the connection. Once connected, all messages are sent using an unsecure basic websocket connection.
Connection URLs on profile 1 will always start with ws:// for websocket, whereas the other profiles use the secure version which is wss:// for websocket secure.
Profile 2 is where the connection is secured by the CSMS providing a certificate that the station trusts. This is called the CSMS Root Certificate and works in the same way as many websites do. The charging station is authenticated using a username and password as in profile 1.
Profile 3 is the highest security level and involves both CSMS and CS trusting each other using certificates. Because the CSMS must receive a certificate from the CS to trust, this security level is most commonly achieved by an upgrade process from Profile 2.
Profile 2 and 3 both require certificates to be stored on either the CS or the CSMS which can require some manual configuration. Another path to these profiles is by upgrading the security within OCPP, this requires a few steps;
Upgrading from 1→2:
1. CSMS sends an InstallCertificateRequest with the CSMS Root Certificate:
2. CSMS sends a SetNetworkProfileRequest with the profile set to 2 and the protocol set to wss://
3. The CSMS sends a SetVariablesRequest changing the NetworkConfigurationPriority to the one just loaded. The charger will then reboot and connect on profile 2
Upgrading from 2→3:
1. The CSMS sends a TriggerMessageRequest of type SignChargingStationCertificate
2. The CS sends a SignCertificateRequest
3. The CSMS sends a CertificateSignedRequest
4. CSMS sends a SetNetworkProfileRequest with the profile set to 3
5. The CSMS sends a SetVariablesRequest changing the Network Profile configuration to the one just loaded.
6. The charger reboots and connects on profile 3
Once connected on a security profile it is not permitted by the specification to reconnect on a lower security profile, so downgrading is not an option!
Security, certificate issuance and trust can be technical and complex subjects but worth the time to learn about in relative detail. The higher security profiles are typically not required for the early stages of a new project so it's best to start with profile 1 or even profile 0 (no security).
There are engineering and architectural decisions to make when implementing security profiles 2 and 3, especially on the CSMS side where certificates are hosted and managed. The overall goal is to implement a mutual TLS websocket server which conforms to the requirements set out in the security section in OCPP-2.0.1_part2_specification.pdf.