1. Introduction
This document serves as a basis of understanding what security measures need be considered on the CPMS side in terms of enabling Plug&Charge and its associated certificates.
The statements resp. requirements listed are divided into the following sections:
- Security
- Processual
- Informative
For a successful CPMS audit, you must comply with the respective status in all chapters marked with security. For a successful CPMS CHECK, you must comply with the respective status in all chapters marked with security and processual.
The handling, implementation or realizatdion of relevant stipulated requirements need to be documented and explicitly explained by the CPMS manufacturer in written form.
2. Requirements for CPMS
2.1 Open Charge Point Protocol (informative)
The Open Charge Alliance (OCA) currently describes two ways of using ISO 15118 – Plug&Charge with OCPP:
-
OCPP 2.0.1
-
OCPP 1.6J with Messages of 2.0.1 inside the DataTransfer.req wrapper.
OCPP 2.0.1 possesses native messages for PnC use cases. Additionally OCA published an application note describing how to use PnC with OCPP 1.6. The Document Using ISO 15118 Plug & Charge with OCPP 1.6 (Open Charge Alliance, 2020) clarifies how the PnC related Messages shall be used in 1.6J. This Document focusses on the syntax and the wrapping of all PnC related Messages into the DataTransfer message.
The Open Charge Alliance application note can be retrieved through using this link or this link.
The CPMS need to support at least one of these OCPP protocols:
-
Initial trust anchor installation.
-
Handling of the EVSE certificate:
-
Triggering keypair generation and forwarding certificate signing requests (CSR) regularly (in every 2-3 months).
-
Sending CSRs to the CPO Sub 2 CA of the V2G PKI (Hubject API) to receive EVSE certificates and CA chain.
-
Handle OCSP requests from and for EVSEs
2.2 Deviation from OCPP Message Get15118EVCertificate (processual)
The value of the FIELD NAME exiRequest/Response in the OCPP Message Get15118EVCertificate is limited to 5600 characters. This limitation is too low.
The EVSE shall accept strings for exiRequest/Response being a maximum of 7500 characters long but must accept exiRequest/Response being 6100 characters long.
2.3 How to create CertificateSigned.req using the V2G PKI? (informative)
Using ISO 15118 Plug & Charge with OCPP 1.6 by Open Charge alliance (cf. chapter 2.1) description of the content of the certificateChain field has been given.
In the string “The signed PEM encoded X.509 certificate [and] [...] necessary Sub-CA certificates.” (i.e., Sub2-/ and Sub1-CA) are included. Further “[...] the order of the bundle should follow the certificate chain, starting from the leaf certificate.” This leads to the following schematical structure:
|
EVSE/SECC Leaf certificate CPO Sub2 CA CPO Sub1 CA |
How to create this structure as a CPMS?
Since the PKI-Interfaces of the Open Plug&Charge Protocol (OPCP) are following the RFC 7030 specifications, the SimpleEnroll and caCerts interface deliver back a container to the requester (CPMS). However, the EVSE will expect a string containing PEM files. This means the CPMS must perform two independent requests and extract PEMs out of the containers and rearrange the single PEMs to the mentioned structure above.
Step by Step explanation:
-
Perform caCerts call and obtain the container
-
Extract Sub1 CA out of the container and store it as PEM
-
Extract Sub2 CA out of the container and store it as PEM “on top” or “above” of the Sub1 CA
-
Ignore Root CA and discard the container
-
Perform simpleEnroll using the CSR received by the EVSE
-
Extract the leaf PEM out of the container
-
Store it as PEM “on top” or “above” the Sub2-/ and Sub1-CA stack.
-
Discard the container
-
Safe the string and make sure to double escape the line brakes inside the string.
You should now have a stack of three PEM certificates, beginning with the leaf followed by Sub2 CA and Sub1 CA.
This wrapped into a OCPP DataTransfer message should look like:
3. OCPP Security Profiles (informative)
It is recommended to secure the EVSE <-> CPMS connection. Thus, the handling of CPMS-certificates is advisable; cf. OCPP Security Profiles.
Alternatively, the EVSE and CPMS could use a private Network using private APNs, VPNs or similar.
OCPP Security Profiles to consider:
-
Basic Security with HTTP Basic Authentication
-
TLS with Basic Authentication
-
TLS with Client-Side Certificates
4. Technical Security Controls
4.1 Authorized Staff (security)
A procurator or authorised signatory of the partner company (CPO) must authorise trusted persons via an authorization letter. A template of the authorization letter can be obtained from Hubject. The person giving permission to the authorised staff must be traceable via commercial registry or similar. Only the person mentioned will be trusted by Hubject and will be able to request for change on the System.
4.2 Authenticity of an EVSE and forwarding of CSRs (security)
The CPMS must ensure that only EVSE Models which successfully passed an Audit or Hubject EVSE CHECK are allowed to ask for signature of its EVSE-Leaf-Certificate. Randomly connected EVSEs may not be allowed to ask for an EVSE-Leaf-Cert. If an unaudited EVSE sends a CSR to the CPMS, the Backend must reject the SignCertificate.req (or similar) from the EVSE. cf. Requirements for EVSE CHECK & Audit.
4.3 Enabling the enrolment in respect of the Registration Authority [RA] duties (security)
Due to a high level of security a list of the Common Names, respectively a list of the SECCIDs need to be transmitted to the V2G-PKI operator before the EVSE can request for a leaf certificate.
If the SECCID is not known to the V2G-PKI operator, the certificate request will be denied. Likewise, the request will be denied if the Syntax of the SECCID will be wrong or the mandatory extensions in the Certificate are missing.
This applies only to certificates issued on Prod-Stage and is not affective on QA- Stage. However, please keep in mind that the update procedure of the SECCID Lists will remain a manual process in the foreseeable future. Thus, it will take a while (up to a month) until the freshly onboarded EVSE will be able to obtain a Prod-Leaf-Certificate.
In addition, the sender of the list must be identifiably and authorised to do so. This leads to the two following steps:
-
The person needs to be named in the authorization letter (cf. chapter 4.1)
-
The authorised person needs to prove its identity by signing its email containing
the list of CNs using a personal email signing certificate. This certificate must be issued by a publicly trusted issuer such as D-Trust. Others can be allowed as well if the policy of the issuer ensures, that the identity of the person was properly checked before issuing the signing certificate for that person.
The demanded format of the “CN-List” will be communicated during the onboarding procedure.
4.4 Usage and accessibility of Client ID and Client Secret (security)
The CPMS manufacturer must state how the secrets are stored in the CPMS and how they get protected from tampering. The partner (CPO) needs to state who has access to the secrets, how they get their rights and how the group of accessors gets restricted.
4.5 Performing OCSP requests from and for EVSEs (processual)
4.5.1 Performing OCSP requests sending iso15118certificateHashData
To perform a complete validity check for a contract certificate, the EVSE needs to perform an Online Certificate Status Protocol before the usual check of an id token such as a EMAID or UID of a RFID token/card.
This requirement is further stipulated in VDE-AR-E 2802-100-1 Chapter 12 and DIN EN ISO 15118-2. Thus, it is a hard requirement to be fulfilled.
Since an EVSE itself is often not connected to the public internet and to ensure interoperability between varies EVSE manufacturers, a standardised way of sending a OCSP request was introduced by Open Charge Alliance using OCPP as communication protocol between EVSE and its respective CPMS.
It follows that EVSE does not perform the checks itself, but rather the connected CPMS on behalf of EVSE.
In case of an authorization the EVSE can send the data needed for an OCSP check already inside the Authorize.req message containing iso15118CertificateHashData besides the idToken or the certificate itself. The idToken (here EMAID) is just used for checking the authorization with a MO or Roaming platform. The OCSP check is unavoidable to check if the rights of the contract certificate weren’t withdrawn a second before.
It is strongly recommended for every EVSE or CPMS connected to the Plug&Charge Ecosystem and/or PKI to send OCSP requests based on OCPP 1.6 with PnC or 2.x.
Mandatory Messages:
- Authorize.req/conf
- GetCertificateStatus.req/conf
A CPMS must be able to receive these messages and perform a OCSP request based on RFC 6960. The following links can be helpful to build such OCSP requests:
-
https://www.gnutls.org/manual/html_node/OCSP-certificate-status- checking.html
-
A possible Library to look at is a Python Library (asn1crypto)
4.5.2 Performing an OCSP Request sending contract certificate
Alternatively, the EVSE can send the complete contract certificate to the CPMS and the CPMS will extract the needed information out of the contract certificate being sent for the OCSP check.