Managing trust in the Plug and Charge ecosystem

WHITE PAPER

Managing trust in the ISO 15118

Plug and Charge ecosystem

About Nexus

This white paper was sponsored and authored by Nexus.

Nexus, part of IN Groupe, is a pioneer and leader in the fields of PKI and cryptography. We have stayed ahead of the curve by always anticipating and preparing for the next technological transformation. Our future-forward solutions create a trusted society by helping governments defend their sovereignty, enabling enterprises preserve their integrity, and empowering citizens to exercise their rights.

We play a pivotal role in creating standards and interoperability frameworks that cater to the ever-evolving technology landscape. Some examples include projects aimed at promoting safety and security around emerging technologies such as connected and autonomous vehicles, connected healthcare, among others. Nexus operates the world’s first productive and compliant V2X and Plug and Charge (also called V2G) PKI services. With a close eye on the ongoing developments in the connected, autonomous, and electric vehicles segment, we are continuously developing our solutions and services to meet the challenges of tomorrow.

nexusgroup.com

About Hubject

This white paper was co-sponsored by Hubject.

Hubject’s mission is to accelerate EV adoption by ensuring the best possible charging experience for EV drivers. Due to its early investment in and commitment to ISO 15118, Hubject has become the leading Plug and Charge ecosystem service provider. Hubject has successfully led over 100 projects for Plug and Charge implementation and the company’s services are used by a plethora of notable partners, including Mercedes, VW, BMW, Renault, Ionity, BP, DCS, Greenlots, and Ultra-E.

Hubject offers an open platform for creating, provisioning, and managing eMobility contracts, which are verifiable and cross-recognized among all ecosystem members. Hubject further promotes interoperability and openness in the development of smart charging technology based on ISO 15118 by collaborating with market stakeholders. Headquartered in Berlin, Hubject was founded as a joint venture of the BMW Group, Bosch, Mercedes-Benz, EnBW, Enel X, E. ON, Siemens and the Volkswagen Group in 2012 to enable borderless charging.

hubject.com

Preface

Abstract

Plug and Charge (PnC) is the ultimate consumer-friendly technology for charging electric vehicles: It offers the frictionless experience of charging with an automated, cashless payment process. Plug and Charge sets the vision of an open and interoperable charging ecosystem, where any vehicle can charge at the charge stations of any operator, independently of geographical location and of the business party supplying the charging contracts. Payment is carried out seamlessly without the driver’s interaction.

In such an open ecosystem with many independent business entities, the electric vehicles, the charge stations, and the Internet-based backend systems must be able to trust each other’s equipment and data in the sense of communication and data security, so that the charging transactions are legally safe, and criminals are prevented from misusing the infrastructure.

The international standard ISO 15118 (more closely its Part 2, ISO 15118-2, and its recent update ISO 15118-20) specifies the technical implementation of the vehicle-to-charge-station communication and the handling of the charging contracts for PnC. Under the hood, the widely used and standardized technology called ‘Public Key Infrastructure’ (PKI) is used for secure identification, authentication, digital communication, and contract management.

Purpose and scope of the white paper

This introductory white paper explains the digital security design of Plug and Charge as defined in the ISO 15118-2 and -20 standards on more than 500 pages. We intend to provide a high-level overview of the V2G ecosystem roles, the main use cases, the security objectives and the respective technical provisions of the standards.

The paper is structured as follows:

• Introduction of the business roles within the Plug and Charge ecosystem.

• Analysis of the PnC charging use case and capturing the security objectives related to the electronic charging contract and the payment transactions.

• Understanding secure in-the-field provisioning of the charging contract and the respective security objectives.

• Gaining overview of the PnC infrastructure including PKI and other trust services, called Contract Signing Service, Contract Provisioning Service, and Certificate Pools.

• Evaluating what is new in ISO 15118-20 compared to ISO 15118-2, and how it affects the underlying PKI.

Target groups

This paper is aimed at technical decision makers, enterprise architects, PKI consultants, development leaders, interested developers, who:

– want to understand why a PKI is needed for operating the Plug and Charge infrastructure and how it enables secure transactions;

– want to get an overview and understanding of the provisions of ISO-15118-2 (or -20) on PKI;

– need to collect business requirements about the envisioned Plug and Charge operations in any of the ecosystem roles;

– need to decide about the operational infrastructure and operational model options;

1. Introduction

Plug and Charge (PnC) is the ultimate consumer-friendly technology for charging electric vehicles: It offers the frictionless experience of charging with an automated, cashless payment process.

The driver does not need to handle any payment card or app, nor an authenticator such as a smartcard or mobile phone, at the charge station. During charging, electrical power is transferred from a Charge Point Operator (CPO) to an electrical vehicle (EV), owned or operated by a consumer. PnC sets the vision of an open and interoperable charging ecosystem, where any vehicle can charge at the charge stations of any operator, independently of geographical location and of the Mobility Operator (MO), who supplied the charging contract. Payment is carried out seamlessly without the driver’s interaction.

In such an open ecosystem with many independent business entities, it is not trivial to make the charging transactions legally safe for the CPO and the contract owner. In order -to achieve that, the electric vehicles, the charge stations, and backend systems must be able to trust each other’s equipment and data in the sense of communication and data security. Trust means that the CPO must have evidence of having charged an EV and must be able to identify the charging contract to bill. Based on this evidence, it must not be possible to reject the bill.

The contract owner must have the assurance that the EV charges only at authorized, calibrated charging stations and that only those charging transactions can be billed that have indeed taken place towards the contracted EV. Criminals should be prevented from misusing the infrastructure, for example, use other consumers’ contracts or forged contracts, use stolen or manipulated EV components, manipulate charge point equipment, hijack and misuse messages sent between EV and charge point, etc.

The international standard ISO 15118-2 (more closely its Part 2, ISO 15118-2, and its recent update ISO 15118-20) specifies the technical implementation of the vehicle-to-charge-station communication and the handling of the charging contracts, so that identification and authentication

of the vehicle, the provisioning and verification of charging contracts, and the charging and billing transactions can be performed in an automated, yet secure, way. Under the hood, the widely used and standardized technology called ‘Public Key Infrastructure’ (PKI) is used for secure identification, authentication, digital communication, and contract management. These mechanisms enable trust among the technical components in an open PnC ecosystem.

During the past decade, PnC has established itself in the market and has become ‘the’ charging standard accepted by a growing number of major car manufacturers (OEMs), charge point operators (CPOs), electricity providers, and Mobility Operators (MOs). Ecosystem trust services connect these ecosystem parties at the backend and enable the truly open and yet secure digital ecosystem. Such services are offered as SaaS (cloud) services to ecosystem parties in a price-efficient way and ease the market entrance for new e-mobility businesses.

The further vision of PnC is to utilize the electricity storage capacity of electric vehicles for the temporary and local storage of unregularly available renewable energy within the electricity grid. This requires “bidirectional charging”, that is, the capability of the EV to feed electric power back into the smart grid if needed. On large scale, this would significantly contribute to the stabilization and load distribution in the electricity grid. Due to this utilization, the PnC infrastructure is also called Vehicle-2-Grid (V2G) infrastructure. In this white paper, we use the terms PnC and V2G as synonyms.

This technical white paper explains the security design of ISO 15118-2 (and -20): which use cases and digital threats are considered and how these are prevented with PKI technology. The reader will also learn about the new PKI features and enhancements introduced by the recent ISO 1518220 release of the standard.

2. Plug and Charge ecosystem roles

ISO 15118-2 defines the following main roles for the PnC ecosystem:

OEM: Manufacturer of electric vehicles (EVs) including full battery and hybrid vehicles, today mainly cars, but potentially also e-bikes, trucks, and other small and large utility vehicles. The OEM equips the EVs with a PnC-capable on-board charging unit called EVCC (Electric Vehicle Communication Controller).

Charge Point Operator (CPO), also called Charge Station Operator (CSO): The electricity provider that operates a network of charge stations. The charge stations (also called Electric Vehicle Supply Equipment, EVSE) are equipped with a PnC-capable unit, called the SECC (Supply Equipment Communication Controller).

Mobility Operator (MO), also called eMobility Service Provider (eMSP): This role is characterized by ISO 15118 as Secondary Actor (SA), since it is not directly involved in charging. Still, it has a very essential task: The MOs distribute EV-charging products and close contract with consumers; with individuals and organisations, for example, fleet operators.

2.1 Charging methods

Data related to the PnC charging transaction is exchanged between EVCC and SECC during charging. The data is transferred today via additional wires in the charging cable over Internet Protocol (IP). Charging over cable is called conductive charging. Wireless charging is being standardized by IEC and is expected to be introduced to the market in a few years. Wireless charging is in the scope of PnC. Obviously, it will need wireless data transfer.

Besides public charging station, PnC covers Private Environments (PE), such as wall-boxes in private households or in parking lots of organizations. The consumer’s experience is the same at public and private charge stations.

2.2 Charging contracts

The PnC contract is a digital document that can act on behalf of the consumer when charging an EV. Concretely, the contract is stored in the EVCC and holds the subscriber’s technical account data, similarly to a SIM-card in a mobile device.

During charging, the contract digitally signs the receipt for the power transfer (indicating the amount of power) on behalf of the consumer. This receipt acts as the acknowledgement of the power transfer and is the basis for the CPO to invoice the power transfer at the respective MO.

A business entity can play multiple PnC roles. For example, OEMs and CPOs may also act as MO. OEMs may a billig bil lso act as CPO, supplying their own charging networks.

Other parties, such as charging equipment vendors, power utilities, Trust Service Providers, which are part of the e-mobility business ecosystem, but are not directly involved in charging, are not handled in ISO 15118-2 (and -20).

Today, contracts are closed with a fixed tariff (that is, price/ kWh). In future, PnC will also work with dynamic tariffs to provide financial motivation and a control instrument for charging when power is abundant and discharging (feeding power back to the grid) when power is short in the smart grid.

Table 1. Plug and Charge roles as defined in ISO 15118-2

3. The scope of ISO 15118-2 (and ISO 15118-20)

ISO 15118-2 (or -20) specifies the communication between the electric vehicle (that is, the EVCC) and the charge station (that is, the SECC). ISO 15118-2 defines the application-level communication messages and sequence requirements for conductive charging that comprise the V2G Transfer Protocol (V2GTP). V2GTP messages include the “smart” charging contract. V2GTP is extended by ISO 1511820 to cover wireless charging and bidirectional power transfer. All V2GTP messages are transferred in XML/EXI-based data representation format.

The application-level messages are transferred via TLS (at OSI layer 5), TCP (at OSI layer 4), and IP6 (at OSI layer 3) between EV and charge station. Contracts and receipts are exchanged between charge points and MOs relying only on the application layer security. These provisions enable interoperability within the PnC charging infrastructure among arbitrary vendor equipment and contract services.

To cover the communication security challenges in the PnC data ex-

change, ISO 15118-2 (and -20) introduces security measures that are based on PKI. A PKI works with cryptographic keys and certificates that allow, in general, secure identification and authentication, encrypted communication, and digital signatures in large open ecosystems (like PnC). Within the PnC ecosystem, PKI enables EVs, charge stations, and contracts to communicate with each other in a random pattern: Any EV may charge at any charge point and present a contract from any of the MOs. Besides the communication protocol and messages, ISO 15118-2 (and -20) specifies the PKI, the certificates, and the digital signature procedures, which enable secure charging transactions.

Note that the charge-station-to-CPO communication, the communication of business entities within the e-mobility ecosystem (B2B), and other ecosystem roles (such as a power utility and battery manufacturer) are out of scope of ISO 15118-2 and -20.

4. Secure PnC charging

4.1 Contracting

Before an EV can “plug and charge”, the owner or operator of the EV needs to close a contract with an MO. Each PnC contract is bound to one EV of the operator. Contracting includes following steps:

Each manufactured EV or EVCC has a unique PnC identity, which is called the PCID. This ID is unique across all EVs produced by any OEM.

The manufacturer of the EV provides PCID to the EV owner or operator.

The owner or operator closes a charge contract with one of the MOs.

The MO creates the electronic contract, which contains the PCID.

The contract gets provisioned to the EV in some way that we discuss in the section ‘Contract provisioning’.

The contract is stored in the EVCC and is now available for PnC charging.

4.2 Charging and invoicing

Once the underlaying contracting is done, charging and invoicing processes with PnC can begin. It proceeds as follows:

The EV drives to the charge station, the driver connects the EV to the station with the charging cable.

Over the cable, the vehicle presents the digital charging contract, which tells the charge station, which MO and consumer account must be invoiced. The consumer account ID is called EMAID (E-Mobility Account Identifier).

The charge station connects to the CPO backend and sends the contract. In the normal case, the CPO recognizes the MO and gives the station a ‘GO’ to charge.

Figure 1. Contracting flow with PCID

Charging is performed, the charged power amount (the ‘metering information’) is displayed to the driver and sent to the EV. The EV creates a receipt and sends it back to the station as acknowledgement of the charging transaction.

The charging cable can be removed, the driver is free to drive away. The charge station sends the contract and the receipt to the CPO backend. The CPO backend invoices the respective MO.

4.3 Threats associated with the PnC

Without built-in security, criminals may misuse the PnC system. We list a few threats below.

Threats related to the charge stations

• A “pirate” charge station may not belong to an authorized CPO and may not have the necessary authority permissions. The EV is charged with stolen electric power, the “pirate” operator invoices that MO under the name of a trusted CPO with hijacked account numbers (EMAIDs).

• The charge stations are often located on exposed public places, so eavesdropping and manipulation of the exchanged messages cannot be excluded. An eavesdropper may capture a contract or a receipt on the cable and use it to charge another EV at the cost of the rightful contract owner. A criminal organisation may sell copies of contracts or receipts to a multiple of consumers, who would charge at zero cost until the fraud is detected.

• A criminal organisation may manipulate charge stations at public places not to measure the total charged electricity, but only a portion of it. In another form, the EVSE electronics is stolen, manipulated, and set up at a hidden location. The charge station is offered to consumers, who pay some fee for this ”discounted” offer.

Figure 2. The Plug and Charge invoicing flow

Threats related to the charging contract

• An EV or an EVCC unit can be stolen with a contract inside and used for charging on the costs of the contract owner, the MO, or the CPO, depending on how such a misuse is legally handled by the parties. To prevent this, there should be a mechanism to block the acceptance of the contract already at the CPO, so that charging cannot take place.

• A criminal organisation may also sell counterfeit contracts to consumers, who can charge with it at half the common price. To prevent this, the CPO must be able to securely identify the MO that issued the contract and rely on the uniqueness and authenticity of the contract.

• A criminal organisation may offer manipulating consumers’ contracts so that they hold another consumer’s EMAID. Without detecting the fraud, the wrong account would be charged.

Threats related to receipts or the acceptance of a charging transaction

• A criminal organisation may offer manipulated EVCCs, which create receipts that hold another consumer’s EMAID. Without detecting the fraud, the wrong MO account would be charged.

• The EV has charged at a charge station, the receipt is sent to the CPO, then to the MO. The consumer claims not having charged at the charge station, refers to fraud and rejects payment. The CPO has the burden of proof but cannot provide robust evidence of the EV having indeed charged.

4.4 Security objectives

Based on this threat analysis, we can deduce following security objectives:

Objective 1. There should be a way for the EV to securely authenticate the charge station and verify that it belongs to an authorized and trusted CPO.

Objective 2. It must be possible to block misused charge points.

Objective 3. The contract and the receipt must be safe against copying and replaying it when charging another EV.

Objective 4. The contract and the receipt must be safe against forgery and manipulation. Only authorized MOs must be able to create contracts that are validated successfully by a CPO. The CPO must be able to detect forged or manipulated contracts and receipts.

Objective 5. The receipt must be non-repudiable by the contract owner. In simpler words, robust evidence must be created about the receipt having been indeed created by the respective EV and not by another party. This evidence can be used by the CPO or the MO, if the consumer unrightfully refuses an invoice.

Objective 6. It must be possible to block the acceptance of a misused contract by the CPO.

4.5 Achieving the security objectives with ISO 15118-2

ISO 15118-2 covers these security objectives by mandating a PKI system and digital signatures, as follows:

Objective 1. is covered by assigning a unique and secret cryptographic key (a PKI private key) to each charge station as well as a corresponding PKI certificate (the EVSE certificate) within a trusted V2G PKI. The EVSE certificate is issued by the operating CPO’s Certificate Authority (CA).

Based on key and certificate, the TLS handshake protocol ensures server authentication: In the TLS session opened by the EV when plugging to the station, the charge station – playing the role of a TLS server – must present the EVSE certificate and use its secret private key to authenticate. The vehicle verifies the authenticity of the certificate by means of a trusted V2G root CA certificate, which is stored securely in the EVCC by the OEM. Furthermore, the TLS handshake provides the proof that the CP owns the corresponding secret private key and hence, it is indeed the charge station entity stated in the charge point’s certificate. The EV can now trust the station to be operated by an authorized CPO.

– After the handshake, the TLS communication between EV and CP is encrypted, so that only the EV and the CP can interpret the exchanged data and an eavesdropper has no chance.

The EVSE secret key must be protected from being discovered by physical tempering of or cyberattack on the charge point. Best practice is storing and operating the EVSE private key in a security chip, called Embedded Secure Element (eSE) or Hardware Security Module (HSM). A Trusted Platform Module (TPM) is one common implementation. The use of a security chip is not mandated by ISO 15118-2 or -20. It might be required in future by an upcoming regulative policy.

Objective 2. is fulfilled in the V2G PKI by the revocation of the EVSE certificate. The revocation status is obtained via the EV using the Online Certificate Status Protocol (OCSP) service of the CPO’s CA. The OCSP information is provided by the EVSE to the EV during the TLS handshake (OCSP stapling, specified in RFC 6961), which relieves the EV from connecting additionally to the responsible OCSP responder. The revocation and OCSP services must be operated by the CPO’s CA entity.

Objectives are covered as follows: The TLS session between EV and charge point is encrypted 3 to 5. and safe against eavesdropping. Furthermore, ISO 15118-2 (-20) adds cryptographic security on the application level too: The contract is not simply a static document or certificate that is presented by the EV at charging. The contract contains a secret cryptographic key (a PKI private key) and a corresponding PKI certificate (the contract certificate) created by the respective MO. Before charging, the EVCC must present the contract certificate and digitally sign a random challenge with the private key, giving in this way robust evidence of owning the secret contract private key too, which exists only in the authorized EV of the rightful owner of the contract. Before charging, the charge station verifies both the contract certificate and the signature, which prove that the EV uses a valid and authentic contract, and it is the contract the EV is authorized to use. The receipt is created within the same authenticated and encrypted TLS session, and the receipt is tied to the contract certificate. Asserting another contract in the receipt is not possible.

The contract private key must be secret and only usable by the owner’s EV. Secrecy can be ensured by storing and operating the private key in a security chip in the EVCC. For the creation of the contract private key at the MO and the secure (encrypted) transfer of the key to the EV, ISO 15118-2 (and -20) make provisions, which will be detailed later in the section ‘Contract provisioning’

The individual objectives are covered as follows:

Objective 3. Copying and replaying data of a charging session in another session is prevented, on one hand, by using encrypted TLS communication. Additionally, the challengeresponse authentication of the contract and the digital signature of the receipt with the contract private key make it impossible to use another contract certificate than the one the EV is authorized to use and owns the private key of. Furthermore, the

receipts must also contain and match the Session ID provided by the charge point before charging. Hence, a replayed contract or receipt will not be accepted by the charge station. In case the EV presents another contract, authentication will fail, and charging cannot even be started.

Objective 4. Manipulation and forgery of the contract is prevented by the contract certificate, which is issued (that is, digitally signed) by the respective MO’s Certificate Authority (CA). With the help of the MO CA certificate, the charge points or, later, the CPO can verify the authenticity of the contract certificate.

Manipulation and forgery of the receipt is impossible due to the digital signature of the receipt data. A valid signature on a receipt can only be created with the help of the contract private key, which exists only in one EV of the rightful contract owner and is protected against discovery. The signature of a manipulated or forged receipts will fail to validate with the help of any contract certificate and can be refused by the charge point.

Objective 5. The digital signature on the receipts provides robust cryptographic evidence that the receipt was signed with the contract private key. This key exists only in one EV of the rightful contract owner and is protected against discovery. The proper protection of the private key in the EV and during the transfer from the MO to the EV is the foundation for the non-repudiation of the receipt. ISO 15118-2 says: “It (the signature) is not intended to confirm that the amount of energy indicated in the previous MeterInfo record is correct in the context of billing. However, the signed meter info record might be used by any mobility operator for billing purposes in general.” This means in clear terms that the digital signature is technical evidence and cannot be used at a court in a legal process. Legal applicability would need to be declared by legal regulation.

Objective 6. is fulfilled by revoking the compromised or misused contract certificate in the PKI. The charge point can check the revocation status of a contract certificate using the OCSP service of the issuing MO’s CA. The revocation and validation services must be provided by the MO CA business entity.

The described security mechanisms are illustrated below.

Figure 3. Securing the PnC charging and invoicing process

5. Secure contract provisioning

In preparation of Plug and Charge, the consumer closes an agreement with an MO and provides the Provisioning Certificate ID (PCID) of the EV that shall carry the contract. The PCID is unique for the vehicle and is different from the Vehicle Identification Number (VIN). The PCID is created by and installed in the EV by the manufacturer OEM and provided to the owner or operator of the EV in an offline procedure.

We learned that the charging contract is an electronic document created by an MO. The contract private key and certificate shall exist only in one copy in only one EV, which is identified by the PCID and is indicated in the contract certificate.

The contract can be provisioned by the manufacturer OEM to the EV in the production or later using the telematic services of the vehicle. This is feasible, if the OEM acts as MO. For an independent MO, ISO 15118-2 defines a method for the EV to download the first or an updated contract at any charge station prior to the charging procedure. In the following explanation, we concentrate on this contract provisioning option, that is, contract provisioning at the charge point. Note that ISO 15118-2 foresees only one contract per EV, but ISO 15118-20 allows several valid contracts at any time.

5.1 Threats associated with contract provisioning

The following security threats appear in the ISO 15118-2 contract provisioning procedure:

• The charging contract contains sensitive information: the secret contract private key. Say, a criminal organisation succeeds to capture one, or better many, contract private keys and the corresponding contract certificates during transfer from the MO to the EV. The organisation can offer these stolen contracts to consumers, who would charge their EV for free and the MO account behind the original contract would be charged until detected. Damage to the MO’s reputation follows and the receipts lose their evidence to be the basis for billing.

• Say, a criminal succeeds to replace a contract that is sent by an MO to an EV with another valid contract and the EV does not detect that it received a contract not authorized to be used by that EV. The motivation may be to corrupt the system or, as above, to sell “charging for free” contracts.

• Say, a criminal succeeds to replace a contract that is sent by an MO to an EV with a forged or manipulated contract. The motivation may be to corrupt the system. If the EV does not recognize that it received a bogus or manipulated contract, charging would fail. The result is denial of the charging service and damage to reputation of the MO.

5.2 Security objectives

The threats discussed above are prevented by raising following security objectives:

Objective 7. The contract private key must be protected while transferred from the MO to the EV. Only the EV that is authorized by the contract owner shall be able to receive the contract private key and thus make use of the contract.

Objective 8. It must be possible for the EV to detect if a contract is not addressed to the EV, that is, for its PCID.

Objective 9. It must be possible for the EV to detect a forged or manipulated contract.

5.3 Achieving security objectives with ISO 15118-2

ISO 15118-2 specifies cryptography-based security mechanism to cover these objectives as follows:

Objective 7. Objective 7 is covered by encrypting the contract private key for the EV using an OEM provisioning certificate that is installed by the manufacturer OEM in each EV. Each EV has a unique and secret OEM provisioning private key and a corresponding unique certificate, which also holds the EV’s PCID. The OEM provisioning private key is stored securely in the security chip the EVCC and is thus protected from physical or electronic tempering and digital attacks. The OEM provisioning certificate holds only the OEM provisioning public key and the PCID of the EV. Only the EV that possesses the OEM provisioning private key can decrypt and install the contract private key in the EV. The transfer of the contract from the MO to the EV over public channels is thus secured.

Objective 8. is covered in two ways: 1) By indicating the PCID in the contract certificate. By comparing the PCID in the OEM provisioning certificate and the received contract certificate, the EVCC can verify it is authorized to use the contract. 2) By encrypting the private key. Thanks to encryption, only the EV authorized by the contract owner will be able to decrypt and use the private key for receipt signing.

Objective 9. is covered by the EVCC in two ways. 1) By verifying that the contract private key matches the public key in the contract certificate. This can be done by the EVCC using simple cryptographic operations. 2) By verifying the authenticity and integrity of the contract certificate. To achieve this, the standard certificate validation proce dure can be applied with a twist that we detail in the next section. According to ISO 15118-2, the revocation status of the contract certificate need not be checked.

6. Certificate Provisioning Service (CPS)

The verification of the authenticity and integrity of the contract certificate can be done in a PKI system by verifying the digital signature of the issuing MO CA in the certificate and then validating the CA certificate chain with the help of an authentic copy of the Root CA on top of the CA hierarchy. The EV securely stores V2G Root CA certificates.

According to ISO 15118-2 (and -20), the MO CA does not have to be a part of the V2G PKI. But if the MO CA certificate does not derive from a V2G Root CA certificate, the EV cannot verify the MO CA chain.

For the EV to be able to verify a contract in such a setup, ISO 15118-2 (and -20) introduces an additional digital signature of the contracts provided by an additional Certificate Provisioning Service (CPS) service. The CPS ”over-signs” the contract provisioning message with the help of the CPS private key and certificate. The CPS’ signature can be validated with the help of a V2G Root CA certificate available in the EVCC. The CPS service can be provided by an independent trusted party or by a V2G root CA organization.

The liberty of the MO CA chain not necessarily being part of the V2G PKI comes at the price of an additional infrastructure service (the CPS) and additional complexity in the EV validation software (verifying an XMLdSig-formatted signature). We found no rationale for this PKI design in the standard.

The security mechanisms supporting secure PnC contract provisioning at the charge point are illustrated below.

Figure 4. Secure PnC contract provisioning at the charge point

7. Overview of the ISO 15118-2 PKI hierarchy

For the issuing and lifecycle management of the different certificate types (OEM provisioning certificate, charge station certificate, contract certificate, CPS signing certificate), ISO 15118-2 proposes a three-tier hierarchy of CAs with Root-, a Sub1-, and a Sub2-tier as depicted in the PKI diagram below. The use of the Sub1-tier CAs is optional, that is, the “Sub1 CAs” in the diagram can be omitted.

Note that only the CAs of the CPOs and the CPS must be within the V2G PKI, that is, derived from a V2G Root CA. The CAs of the OEMs and the MOs may or may not be derived from the V2G Root CA. Hence, their relation to the V2G Root CA is displayed with dotted line.

When an EV connects to a charge station via TLS, the charge station presents its EVSE certificate and the CA certificates up to the V2G Root CA to the EV. The EV can verify the EVSE certificate because it stores an authentic copy of the V2G Root CA. Since an EVSE certificate can be revoked, the EV also needs information about the revocation status of the CPO CA certificates and the EVSE certificate.

ISO 15118-2 mandates the EVSE to provide revocation status information in form of OCSP responses during the TLS handshake. This TLS feature is called OCSP stapling, and it relieves the EVSE from additionally connecting one or more OCSP servers. It follows that CPO CAs need to provide OCSP responders, which digitally sign the responses. The respective OCSP Signer certificates are displayed in Figure 6.

The OEM provisioning certificates are verified and used only by the MOs to encrypt the contract private keys for contract provisioning. It follows that only the MO backend systems need to validate the OEM provisioning certificates. How the MOs obtain trusted OEM Root CA certificates, is out of scope of ISO 15118-2. An OCSP responder is not mandated by ISO 15118-2 for the OEM CAs either. This leaves it open for the MOs how to check the revocation status of the OEM provisioning certificates.

The EV must present the contract certificates before charging and the EVSE shall validate it. After charging, the EV signs the receipt. The EVSE may forward the contract certificate and the signed receipt to the CPO backend system, which may re-validate contract and receipt. How the charge

Figure 5. Secure PnC contract provisioning at the charge point

stations and the CPOs obtain trusted MO Root certificates is out of scope of ISO 15118-2. An OCSP responder is not mandated by ISO 15118-2 for the MO CAs either. This leaves it open for charge stations and the CPOs how to check the revocation status of the contracts and the MO CA certificates.

The ISO 15118-2 PKI design assumes the existence of one central V2G Root CA entity at least within a geographic region. It is important to note that even in this case, there may be several valid V2G Root CA certificates at any time. This is due to the regular rekeying of the V2G Root CA. According to ISO 15118-2, the EVSE must be able to store 10 V2G Root CA certificates. The EV is required to store only one V2G Root CA certificate. If the EVSE cannot present a certificate chain to the V2G Root certificate in the EV or if the EVSE cannot verify the contract presented by the EV, charging will fail.

Unfortunately, ISO 15118-2 does not define any method (for example, with the help link certificates) for creating trust among different generations of the V2G Root CA certificate. This must be considered by implementers and testers.

8. Certificate pools

The contract certificates are issued by an MO. The contract private key is generated by the MO too and, therefore, the contract can be prepared and encrypted for the EV without interacting with the EV. Contract creation is separated in time and space from contract provisioning.

In the last section we also learned that ISO 15118-2 does not mandate the OEM and MO CA certificates to be part of the V2G PKI, that is, derived from a V2G Root CA. This leads to, on one hand, the need to introduce the CPS service which is covered by ISO15118-2. On the other hand, ISO 15118-2 does not specify a standard method how trusted OEM and MO root certificates can be obtained by relying parties, that is, by MOs and, respectively, by CPOs. We can add that V2G Root CA certificates are also renewed from time to time and their distribution in the ecosystem is a regular need.

8.1 Interoperability objectives

Based on the above challenges, in summary, we can raise the following interoperability objectives:

Objective 9. The OEM provisioning certificates must be available for the MOs. An MO must be able to find and retrieve the (currently valid) OEM provisioning certificate based on the PCID of the vehicle.

Objective 10. Whenever an EV requests downloading a contract at a charge point, the charge point – respectively the operating CPO – must be able find and retrieve the contract based on the OEM provisioning certificate, respectively the PCID.

Objective 11. There should be a standard method and interface for relying parties within the PnC ecosystem to obtain trusted V2G, OEM, and MO root certificates.

8.2 Achieving interoperability objectives with certificate pools

ISO 15118-2 does not specify technical means to meet Objectives 9 to 11. To complement ISO 151182, the Technical Standard VDE-AR-E 2802-100-1 of the German Association of Electronics, Electrics, and Information Technology (VDE) proposes the implementation of searchable certificate pools (that is, certificate repositories) as follows:

Objective 9. The OEMs shall publish and maintain the currently valid OEM provisioning certificate for each produced EV in an OEM Provisioning Certificate Pool (OPCP). Each

authorized MO (without limitation) shall be able to search each OEM certificate pool using the PCID in the OEM provisioning certificate.

Objective 10. The MOs shall publish and maintain the currently valid charging contracts for each EV (encrypted with the OEM provisioning certificate of the EV and signed by a CPS) in a Contract Certificate Pool (CCP). Each authorized CPO (for download at a charge point) and OEM (for download through OEM backend) shall be able to search each CCP using the PCID in the OEM provisioning certificate (during initial contract download) or the EMAID (during contract update). The acceptable latency of downloading a contract to a charge point is specified at a maximum of 5 seconds.

Objective 11. The V2G Root CA entity shall publish V2G, OEM, and MO root certificates that it classifies as trustworthy in the Root Certificate Pool (RCP). Relying parties can access the RCP at no cost.

The VDE-AR-E 2802-100-1 standard is meanwhile widely recognized, and the necessity of the certificate pools is understood in the e-mobility industry. As there can be many OPCPs and CCPs in the ecosystem, the VDE standard proposes the concept of a central request broker operated by the V2G Root CA that would direct certificate or contract download requests, based on the PCID or the EMAID in the request, to the right certificate pool.

The role of the Certificate Pools is illustrated below.

Figure 6. Certificate Pools make OEM, contract, and root certificates available with low latency

9. What is new in 15118-20?

In 2022, an improved and extended version of ISO 15118-2 was released as part No. 20 of the ISO 15118 series. ISO 15118-20 does not automatically replace 15118-2, and vendors and ecosystem role holders are free to choose which version they use and when they intend to upgrade their products. An upcoming regulation may mandate a roadmap for the migration, but as of today, no such regulation exists in any geographical region.

ISO 15118-20 brings along provisions in support of new PnC features, such as bidirectional charging, wireless power transfer, dynamic charging, etc. In this white paper, we only concentrate on changes of the ISO 15118 PKI scheme, which we briefly summarize below.

The analysis of the impact of these new features and options on the implementation and on the governance of the PKI requires an additional paper and is omitted here for the sake of brevity.

9.1 Multiple contracts in an EV

15118-20 removes the limitation that an EV can hold only one contract. The handling of multiple contracts in the EV raises requirements on both the EVCC and the user interface of the vehicle. The latter should provide means for the driver to select the charging contract to be applied. OEMs are expected to design their EVs so that they present available contracts from potentially different MOs in an unbalanced way.

9.2 Update of cryptographic algorithms

Cryptoanalysis (the science of algorithms for “breaking” cryptographic algorithms and protocols) and the capabilities of computers have advanced since 2014, the release year of ISO 15118-2. The future advances cannot be predicted for the lifetime of EV and charging products. Rather, the EVs and products must be prepared to upgrade cryptographic algorithms, which is commonly called cryptographic agility, or crypto-agility, in short.

ISO 15118-20 addresses these issues in following ways:

• The minimal strength of cryptographic algorithms (encryption, signature, and hash functions) has been updated; 512-bit elliptic and hash algorithms shall be used in place of 256-bit ones. New algorithms, such as Edward curve based ECC, have been added to the list of accepted algorithms.

• The maximal size of the certificates is raised from 800 bytes to 1600 bytes.

• The connection of the EV to the charge point shall be based on TLS 1.3 instead of TLS 1.2.

• For the sake of crypto-agility, the V2G PKI shall be able to operate two CA hierarchies with different algorithms. All PKI-related components, including EVCCs and SECCs, shall be able to work with keys and certificates of two different algorithms. It is, however, not mandated that the two sets of keys and certificates are continuously available, but it shall be possible to switch to the second set of keys and certificates any time. How and in which order the rollout shall be performed is not specified. The standard seems to look for a compromise between security and technical complexity of EVs and charge points. It remains to be seen if a practical balance has been found.

9.3 Vehicle authentication

According to ISO 15118-2, the TLS connection between EV and charge point is established with server authentication, where the charge point (that is, the SECC) plays the role of the TLS server. ISO 15118-20 adds the requirement of client authentication of the EV, which contributes to cybersecurity by preventing connections that are initiated by a non-authorized or revoked EVCC or by other component or software, such as an attempt from the Internet to connect to a charge point’s Plug and Charge interface.

For TLS client authentication, the EVCC must use a separate private key and certificate, called the vehicle key and the vehicle certificate. The vehicle certificate must be issued under a separate chain of Vehicle Sub-CAs either under the OEM’s Root CA or under the V2G Root CA as an anchor. The technical price for client authentication is high, and the charge point is required to handle an additional CA chain with two root CA options.

9.4 Support for secure elements (TPMs)

ISO 15118-2, in vehicle and EVSE certificates, the use of an embedded secure element (often called an HSM or TPM) can be marked in the respective EVCC or EVSE certificate. The use of a secure element is not mandated.

9.5 The use of OCSP

According to ISO 15118-2 and -20, OCSP is mandatory only for the EVSE certificates and the CA certificates in their CA chain. A charge station (that is, the EVSE) in a public area must present the corresponding OCSP responses to the EV as part of the TLS ‘Server hello’ response. This is called OCSP stapling. As an alternative to OCSP, Certificate Revocation Lists (CRLs) may be provided for the certificates issued by other CAs (that is, by MO and OEM CAs).

ISO 15118-20 promotes, while still does not mandate, the use of OCSP in relation to vehicle OEM provisioning and contract certificate chains. However, either OCSP or CRLs must be provided by the respective CA.

The CPS signing certificate needs no revocation mechanism and, hence, neither OCSP nor CRL needs to be supported, but they are still optional. If the CPS signing certificate is compromised and its revocation is not supported, the V2G Root CA must revoke the CPS Sub-CA certificate and announce this via the V2G Root OCSP responder. This is an unusual method, and we recommend the classical revocation of the CPS leaf certificate instead.

9.6 Cross-certification

We have pointed out that the MO and OEM certificate chains may be, but need not be, part of the V2G PKI. This fact leads to inherent potential issues with certificate validation. On one hand, the validation of the contract certificate by the EV (the EVCC) during provisioning is solved in ISO 15118-2 at the price of additional complexity of the CPS signing service. On the other hand, the validation of the contract by the SECC and the CPO is left open by ISO 15118-2. We have shown that VDE-AR-E 2802-100-1 solved the issue with introducing the Root Certificate Pool that CPOs can rely on.

ISO 15118-20 does not define a mandatory and interoperable solution either for solving the trust issue of the decoupled OEM and MO root CAs. In fact, with the introduction of the vehicle certificate, which may be validated only with the help of an OEM Root Certificate, it adds to the problem.

ISO 15118-20 introduces the technical option for the V2X Root CA to cross-certify the Sub-CA certificates and OCSP signer certificate of MOs and OEMs, and to provide a trusted certificate path to a V2G Root CA. Appendix H of ISO 15118-20 describes many possible setups.

We provide one setup for illustration below. In our opinion, the inherent issue is not solved in this way, but only further technical options are added to building a trusted CA chain, which raises the complexity of the validation algorithm and adds risks to interoperability.

9.7 Multiple V2G Root CAs

ISO 15118-2 was designed with the vision of having one V2G Root CA entity in a geographical region. While this leads to the least technical complexity, there are business and robustness arguments that demand multiple V2G Root CA entities.

ISO 15118-20 enables operating multiple V2G Root CAs. There are different proven technical models to provide mutual trust among separate V2G Root CAs, such as trusted certificate lists (CTL), bridge CA solutions, or cross-certification. ISO 15118-20 promotes cross-certification to establish this link. Note that N root CAs would need to maintain N x N cross-relations for technically expressing mutual trust. If each of these root CA has M valid root certificates at any time, the number of root certificates easily rises to an unmanageable number in the order of (N x M)2. At the same time, trust between different certificate generations of one Root CA is still not addressed in ISO 15118-20.

Figure 7. ISO15118-2 introduces vehicle certificates and makes Sub1 CAs optional

In this white paper, you were introduced to the security design of ISO 15118-2 (and -20). The standard incorporates security by design and establishes high security for secure identification, authentication, digital communication, and contract management based on Public Key Infrastructure (PKI) technology. The Technical Standard VDE-AR-E 2802-100-1 complements the ISO standard by defining relevant requirements and respective backend services.

We analysed the relevant Plug and Charge processes (charging, invoicing, contract creation and provisioning) in view of security threats and explained how the PKI-based mechanisms specified by the standard prevent these threats. Plug and Charge is a mature and secure technology with established vendors and service providers in the market.

We have pointed out a few weak points of ISO 15118-2, which were only partially closed or improved ISO 15118-20. In general, the number of technical options has grown with ISO 15118-20, which implementers need to pay attention to and consult with industry partners. If and how cryptoagility and multiple V2G Root CAs, introduced by ISO 15118-20, shall be supported, seems to be incompletely specified. eMobility vendors and service providers are recommended to follow the preparations and wait for the provisions of the related upcoming European Regulation and the corresponding Delegated Act, planned for the coming years.

10. Summary 11. Glossary

CA – Certificate Authority

CCP – Contract Certificate Pool

CPO / CSO – Charge Point Operation, a.k.a. Charge Station Operator

CRL – Certificate Revocation List

EMAID – eMobility Account ID

eMSP – eMobility Service Provider, a.k.a. Mobility Operator (MO)

eRoaming / EV Roaming – The “charge anywhere” experience: EV owners can charge on the road, across regions and borders on any CPO’s EV charging network.

EV – Electric Vehicle

EVCC – Electric Vehicle Control Circuit; the PnC control unit inside the EV

EVSE – Electric Vehicle Supply Equipment; in this paper equivalent to charge station

MO – Mobility Operator, a.k.a. eMobility Service Provider (eMSP)

OCSP – Online Certificate Status Protocol

OPCP – OEM Provisioning Certificate Pool

PCID – Provisioning Certificate ID

PKI – Public Key Infrastructure

RCP – Root Certificate Pool

SECC – Supply Equipment Control Circuit; the PnC control unit inside the charge station

V2G – Vehicle-to-Grid: The term is used as a synonym to the EV charging infrastructure. More closely, it refers to Plug and Charge and the charging features defined ISO 15118-2 (-20), including bi-directional charging that will contribute to the equalization of load in the power distribution network, also titled as “smart grid”.

12. References

[ISO-2] ISO 15118-2:2014; Road vehicles – Vehicle-to-Grid Communication Interface – Part 2: Network and application protocol requirements; https://www.iso.org/standard/55366.html

[ISO-20] ISO 15118-20:2022; Road vehicles – Vehicle to grid communication interface – Part 20: 2nd generation network layer and application layer requirements; https://www.iso.org/standard/77845.html

[VDE] VDE-AR-E 2802-100-1 EN 2019-12: Handling of certificates for electric vehicles, charging infrastructure and backend systems within the framework of ISO 15118; https://www.vde-verlag.de/standards/0800642/vde-ar-e-2802-100-1-anwendungsregel-2019-12.html

”

Our commitment to excellence and innovation drives us to build a secure tomorrow with trusted identities ”