1. Introduction
This guide serves as a basis for understanding what security and processual measures need to be considered on the EVSE side in terms of enabling Plug&Charge and its associated certificates.
The statements resp. requirements listed are divided into the following sections:
1. security
2. processual 3. informative
For a successful EVSE audit, you must comply with the respective status in all chapters marked with (security).
For a successful EVSE CHECK, you must comply with the respective status in all chapters marked with (security) and (processual).
The handling, implementation or realizatdion of all stipulated requirements need to be documented and explicitly explained by the EVSE manufacturer.
2. Requirements for Hardware and Software in the EVSE/SECC
2.1 The SECC must protect the private key of the SECC Leaf Certificate (security)
This requirement can be fulfilled by using an HSM (hardware secure module), TPM (trusted platform module), soft-HSM (KeyStore, etc.) or similar technology to store the private keys securely. Software parts processing cryptographic operations need to access these keys in a secure matter.
2.2 Initial trust anchor installing (processual)
It is recommended to install the root certificates during the software flashing process during production and additionally the EVSE shall be ready to receive new Root Certificates during operation i.e., the installation of V2G Root and MO Root(s).
2.3 Creation of an EVSE Leaf Certificate Sign Request (security)
The EVSE needs to create a CSR to request an EVSE-Leaf-Cert via the CPMS at the V2G PKI. This CSR must follow the Certificate Profile on Annex F of ISO 15118-2 respectively the V2G Certificate Policy.
The SECC Leaf Cert must possess the SECCID in its Common Name (CN) as well as the Organization (O) and Country (C) of the CPO. Independently, the Domain Component (DC) must be “CPO”.
For the CPO to set these parameters, the EVSE manufacturer shall implement the OCPP configuration keys described in chapter 2.4 Required OCPP Configuration Key Names & Values.
Hubject is currently in discussions with Open Charge Alliance and other market participators to agree on common OCPP configuration keys and an automated way of configuring the EVSE.
2.4 Required OCPP Configuration Key Names & Values (security)
2.4.1 SeccLeafSubjectCommonName
|
Required/optional |
Required |
|
Accessibility |
RW |
|
Description
|
(Comma separated) Common Name(s) of the SECC (EVSE) leaf certificate(s). The CN must be a SECCID. The field can contain optional multiple SECCIDs if necessary. <SECCID> = <Country Code> <S> <EVSE Operator ID> <S> <ID Type> <S> <ControllerID> <S> <Check Digit> Example with missing SECCID for OCPP for connector 2 and 4: DE-ICE-S-Connector1X878675645330967543476-5, ,DE-ICE-S-Connector3X878675645330967543476-2, ,DE-ICE-S-Connector5X878675645330967543476-X |
2.4.2 SeccLeafSubjectCountry
|
Required/optional |
Required |
|
Accessibility |
RW |
|
Type |
string [2] |
|
Description |
County of the SECC (EVSE) leaf certificate. Indicates in which country the CPO operates. Example: DE |
2.4.3 SeccLeafSubjectOrganization
|
Required/optional |
Required |
|
Accessibility |
RW |
|
Type |
string [0..50] |
|
Description |
Organization of the SECC (EVSE) leaf certificate. Indicates which CPO operates this EVSE. Example: Hubject GmbH |
2.4.4 ConnectorEVSEID
|
Required/optional |
Required |
|
Accessibility |
RW |
|
Type |
string [7..36..144..200] |
|
Description |
Comma separated EVSEIDs for OCPP connectors starting with connector 1 in one string. Example with missing EVSEID for OCPP connector 2: DE*ICE*EidFORocppCONNECTOR1, DE*ICE*EidFORocppCONNECTOR3, DE*ICE*EidFORocppCONNECTOR4 |
2.5 Handling of SECC Leaf Certificate (informative)
The EVSE needs to store an SECC-Leaf-Certificate and its corresponding chain to establish secure communication between Charger and Vehicle; i.e., creating a keypair and certificate signing requests (CSR) upon request by CPMS (OCPP TriggerMessage) or automatically (in every 2-3 months) as configured in the corresponding key cf. chapter 2.4 Required OCPP Configuration Key Names & Values.
After receiving an SECC-Leaf-Certificate from the CPMS the EVSE shall perform a chain validation using the Sub CAs received and the previously installed V2G Root Certificate.
If the CPMS sends an SECC leaf certificate chain including the V2G root certificate, the SECC shall ignore the V2G Root Certificate sent with the chain.
The validation of the SECC leaf certificate shall always be performed against the previously installed V2G Root Certificates.
2.6 How to handle a CertificateSigned.req (informative)
In Using ISO 15118 Plug & Charge with OCPP 1.6 by Open Charge alliance description of the contend 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 Sub 1 CA |
The V2G Root Certificate must not be part of this chain. An example of CertificateSigned.req is as follows:
2.7 Securing the EVSE <-> CPMS Connection (processual)
It is strongly 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.
2.8 Performing OCSP requests via OCPP (processual)
2.8.1 Performing an OCSP Request sending OCPP Authorize.req or GetCertficateStatus
OCPP field name iso15118CertificateHashData and ocspRequestData are both requiring OCSPRequestDataType. This field type is defined in OCPP, containing all needed values for performing an OCSP requests. The EVSE must be able to extract, respectively calculate the following attributes out of a Contract-Certificate, its corresponding Sub2-/ and Sub1-CA.
- responderURL
-
hashAlgorithm
being used for the following attributes: -
issuerNameHash
-
issuerKeyHash
-
serialNumber
This information of the contract leaf, Sub2-/ and Sub1-CA must be sent to a CPMS as part of an OCPP GetCertificateStatus.req or Authorize.req . All three OCSP checks are needed to allow the CPMS to perform a chain validation of the OCSP signer certificate. Maximum four (4) iso15118CertificateHashData can be sent in one Authorize.req .
This allows the CPMS to perform a complete verification of all certificates involved in the contract certificate chain. Using OCSPRequestDataType is the recommended way of performing an OCSP request.
The certificate (chain) can be transmitted additionally to the CPMS using the certificate field as described in chapter 2.8.2. The two ways can be combined.
2.8.2 Performing an OCSP Request sending Contract Certificate
The EVSE could alternatively or additionally send the contract certificate chain (leaf, Sub2-/ and Sub1-CA) in the Authorize.req .
Based on this certificate, the CPMS can perform the OCSP request itself. This method is not favourable since it increases the data needed to be sent between EVSE and CPMS.
2.9 User Authentication with "ExternalPayment" with a PnC Vehicle (processual)
In order to respect and not overrule the explicit choice of the charging contract by the EV driver, the following requirement shall be fulfilled. Otherwise, the choice of charging contract would be ignored and the driver would no longer have price transparency.
If the EV driver uses External Payment (EIM) or other authentication methods at the EVSE for authorization purposes, the EVSE shall not offer “Contract“ (PnC) as payment/authentication method in the ServiceDiscoveryRes message.
[cf. ISO 15118 - 2]
ExternalPayment refers to the following authentication methods:
- RFID Card (UID)
- “RemoteStart” (SMS, CallCenter, eMSP-App, EV-HMI, etc.)
- Local authorization (debit/credit card)
It should be considered that this requirement can only be fulfilled if the authorization is done before the cable is plugged in. As soon as the ServiceDiscoveryRes Message has been sent, the Vehicle is free to decide.
The authorization-idToken presented for the ExternalPayment method is only used for billing if the Vehicle is asking for EIM (ExternalPayment). If the Vehicle chooses PnC (Contract), the Authorization and billing shall always be done with the EMAID of the contract certificate.
3. OCPP 1.6 with PnC use cases (informative)
OCPP 1.6J can be enabled to use PnC by back-porting the OCPP 2.x PnC-use cases. The OCPP 2.x specification describes these use cases representing the core functionalities that should be implemented for the communication between the CPMS and the EVSE to enable Plug&Charge.
Alternatively, OCPP 2.0.1 is natively capable of transferring all PnC relevant messages. Hubject recommends using OCPP-Plug&Charge Messages as defined by Open Charge Alliance.
3.1 OCPP 1.6 with PnC via DataTransfer (informative)
The Open Charge Alliance published an application note, which describes how OCPP 1.6J shall be used when enabling Plug&Charge using OCPP 1.6J as a communication Protocol. Since the release of that document, the OCA has also released a new Version of OCPP (2.0.1) and clarified in the Document Using ISO 15118 Plug & Charge with OCPP 1.6 (Open Charge Alliance, 2020) how the PnC related Messages shall be used.
This focuses 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:
https://www.openchargealliance.org/uploads/files/ocpp_1_6_ISO_15118_v10.pdf
or
https://www.openchargealliance.org/about-us/info-en-whitepapers/
3.2 Deviation from OCPP Message Get15118Certificate (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.
4. Technical Security Controls from the Hubject Certificate Policy (security)
4.1 Key Pair Generation and Installation
End-entity keys (such as the SECC-Leaf-Certificate) shall be generated in the subject device.
4.2 Public Key Delivery to the Certificate Issuer
Public keys generated by subscribers are delivered to the certificate issuer through the PKCS#10 Requests. Cf., Request for Comments: (RFC) 2986.
4.3 Transmission of Root CA Certificates to Trusting Parties
The public key and the certificate of the V2G Root CA(s) must be stored by each SECC. The subscriber shall use a second communication channel for validating the V2G Root CA Certificate fingerprint, before installing it at the end-entities resp. storing it in the SECC.
If retrieving the V2G or MO Root CA using Hubject’s Root Certificate Pool (RCP) the fingerprint does not need to be double-checked.
4.4 Distinguished Name, Attributes, and (extended) Key Usage
The EVSE/SECC-Leaf-Certificates keys and attributes must be used according to the appropriate certificate usage specified in the certificate profiles.
Especially the Common Name (CN) of the Subject must be the SECC-ID of the Charge point. The SECC-ID needs to follow the syntax of ISO 15118-20.
SECCID shall be an alphanumeric string with a length of minimum 39 and maximum 255 characters (i.e. A..Z, a..z, 0..9), including an optional check digit at the end.
<SECCID> = <Country Code> <S> <EVSE Operator ID> <S> <ID Type> <S> <ControllerID> <S> <Check Digit>
<Country Code> = 2 ALPHA; two-character country code according to ISO 3166-1 (Alpha-2-Code)
<EVSE Operator ID> = 3 (ALPHA / DIGIT); three alphanumeric characters, referring to the EVSE Operator
<ID Type> = “S”; one character “S” indicating that this ID represents a reference to a “Supply Equipment”
<ControllerID> = Minimum 32 (ALPHA / DIGIT) Maximum 248 (ALPHA / DIGIT) ; Alphanumeric characters referring to the specific communication controller
<Check Digit> = *1 (ALPHA / DIGIT); Used to verify valid SECCID
ALPHA = %x41-5A / %x61-7A; according to IETF RFC 5234 (7-Bit ASCII), case-insensitive (IETF RFC 7405)
DIGIT = %x30-39; according to IETF RFC 5234 (7-Bit ASCII)
<S> = *1 ( “-” ); optional separator, but advised not to use it between IT systems and only for visibility purposes.
Key usages are also specified in the key usage extension fields in the certificate profiles. Please see the certificate profiles (Annex F) in [ISO 15118 - 2].
4.5 OCSP Requests of CPO Sub2-/ and Sub1-CA and OCSP Multi-Stapling
According to requirement [V2G2-070] and [V2G2-875] in ISO 15118-2, the EVCC must verify the certificate chain of the SECC certificate and the OCSP responses (including OCSP Signer certificates) of the SECC certificate chain. The SECC must provide all necessary OCSP responses in the TLS initialisation response by means of OCSP stapling according to [RFC6961].
However according to ietf.org the status_request_v2 extension [RFC6961] is deprecated. This extension was intended to be used for the EVCC checking the OCSP response for the CPO Sub2-/ and Sub1-CA.
Feedback from the market is such, that currently no EV has implemented this check and no EVSE is currently allowing this check to be done due to the missing mechanisms in TLS 1.2
Hubject is currently suggesting to ignore this requirement.