Embed Size (px)
Citation preview
POPCORN: Privacy-Preserving Charging for eMobility
Christina HöferUniversity of Twente,
The Netherlandsc.n.hofer@alumnus.
utwente.nl
Jonathan PetitUniversity of Twente,
Robert K. SchmidtDENSO AUTOMOTIVE
Deutschland GmbHr.schmidt@denso-
auto.deFrank Kargl
University of Ulm, Germany& University of Twente, NL
ABSTRACTUpcoming years will see a massive deployment of electricvehicles and, combined with this, of charging infrastructure.This will require protocols and standards that will controlauthentication, authorization, and billing of electric-vehiclecharging. The ISO/IEC 15118 protocol that addresses thecommunication between the charging station and the vehicleis going to play an important role, at least in Europe. Whileit foresees security protection, there are no significant mech-anisms for privacy protection in place. In this paper, we in-vestigate the privacy protection of ISO/IEC 15118 and thesurrounding charging and payment infrastructure by meansof a Privacy Impact Assessment (PIA). Based on this wepropose modular extensions of the protocol applying state-of-the-art Privacy Enhancing Technologies like anonymouscredentials to come to a system with maximum privacy pro-tection. We conducted a second PIA to show the benefitsto privacy protection that our POPCORN protocol providescompared to the original ISO/IEC 15118. We also describea proof-of-concept implementation of our system based ona model of electric vehicle and charging station that showsthe feasibility of our approach and allows a first preliminaryanalysis of performance and other issues.
Categories and Subject DescriptorsC.2.0 [COMPUTER-COMMUNICATION NET-WORKS]: General—Security and protection
General TermsDesign, Security
KeywordsElectric vehicle charging, ISO/IEC 15118, security, privacy,privacy enhancing technologies
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full cita-tion on the first page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-publish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from [email protected]’13, November 4, 2013, Berlin, Germany.Copyright 2013 ACM 978-1-4503-2487-8/13/11 ...$15.00.http://dx.doi.org/10.1145/2517968.2517971.
1. INTRODUCTIONMobility in the future has to become more eco-friendly.
Especially, in urban scenarios the move towards electric mo-bility is already starting to become visible. This will bringalong a fundamental transformation of the way how ourtransportation systems work, especially as electric vehicleswill have to recharge much more often compared to the refu-eling of traditional cars. Charging of Electric Vehicles (EVs)is a central aspect of the electric vehicle introduction and alot of attention is given to fast and widely available charg-ing opportunities. Ideally, for the driver charging an EVwill be as simple as parking – just park, plugin, and charg-ing begins. Still, for charging control, authorization, andbilling purposes, a lot of information has to be exchangedautomatically between the EV and the Electric Vehicle Sup-ply Equipment (EVSE), also simply known as charging sta-tion/spot (CS). Especially the multitude of di!erent vehicletypes and their electrical characteristics and requirementsrequire a thorough setup of the EVSE. Moreover, frequentcharging will also include frequent payments. The paymentshould be done without user-interaction for maximum con-venience. In the context of ongoing international standard-ization e!orts like ISO TC 22/IEC TC 69, it is manifestingthat in the future certain roles of actors in the backend sys-tem will be concerned with security and privacy-related pro-cesses. Particularly, for the charging management of EVs,the draft standard ISO/IEC 15118-1 [7] defines actors andprotocols to perform load management, billing and clearing,as well as certification. While security is already consideredin the standards, privacy protection has not been investi-gated so far. In this paper we present a detailed privacyanalysis of ISO/IEC 15118 and propose modular privacy en-hancements that lead to a fully privacy-preserving chargingprotocol for electric vehicles.
Next, we first briefly summarize the charging scenario andoutline the relation between the di!erent actors as follows.The ISO/IEC 15118 standard already defines a number ofdi!erent payment options. Assuming the user wants to bene-fit from the most user-friendly charging management definedby ISO/IEC 15118, a contract with a so-called Mobility Op-erator (MO) has to be concluded in advance. In its simplestform, the MO can be the utility provider of the user thatwill collect charging fees together with the monthly energybill. However, the MO can also be a separate entity that
37
Figure 1: ISO/IEC 15118 application layer protocol:Protocol operations.
charges the fees to the user’s account. Signing up with anMO involves issuing of cryptographic X.509 certificates tovehicles or drivers. After each charging session the MO re-ceives a Service Detail Records (SDR) containing the infor-mation required to pay the Charging Spot Operator (CSO)and in turn the energy provider (EP). A CSO maintainsa number of charging spots and may be the actual energyprovider. For simplicity, we will consider the CSO and theenergy provider as one entity and refer to both as the energyprovider (EP). To allow flexible charging while traveling, weassume that the MO has roaming agreements with a largevariety of di!erent EPs similar to roaming agreements be-tween cellphone operators. Assuming that many di!erentEPs will be active in the market, roaming may become tonorm rather than the exception.
The charging spot informs its energy provider about eachcharging session by sending the EV-signed meter receipts.These receipts can be used by the energy provider in case ofdisputes. At the end of a certain period, say one month, theMO provides a bill to the contracted user for the receivedSDRs. Ideally, if the MO is at the same time also the utilityprovider of the user, the bill for EV charging will be addedto the user’s domestic energy bill.
The ISO/IEC 15118 draft standards already define de-tailed communication protocols and corresponding applica-tion layer messages in ISO/IEC 15118-2 [8] including se-curity mechanisms based on TLS and XML Security. Assummarized in Fig. 1, there are a series of messages that areexchanged between the EV client and the charging stationserver. These messages are sent as sequences of messages infive phases as described in the following.
After exchanging IDs (EVSE ID, Session ID) included inthe Session Setup, the Service Discovery lists available ser-vices. Next, the EV will choose the desired charging service.The EV can request more information with Service Detail
messages. The selection is done via the Service and PaymentSelection message. Payment Details list available paymentoptions. For our discussion, we assume that the user selectsthe contract-based payment which then requires ContractAuthentication. Other payment options use credit, debit, orprepaid cards. These methods require interaction and areprivacy-invasive when tied to the user. Before entering theactual charging, specific charging parameters are exchanged.On the one side, these include the EV’s desired departuretime and requested amount of energy. On the other hand,the charging spot returns a schedule describing maximumavailable power at specific points in time in the future. TheEV then confirms a certain charging profile in the PowerDelivery step and the charging loop is entered. Periodic ex-change of Charging Status and Metering Receipt messagesprovide updates about the progress of the charging. Oncefinished, the session is terminated by the Session Stop.
Throughout these message sequences, security services andoperations take place. Fig. 2 describes the security oper-ations performed during the di!erent phases, i.e., sessionsetup, payment arrangement, charging and session end. Dur-ing the connection establishment, a TLS session is initi-ated which ensures confidentiality. Initial TLS authentica-tion is done only on unilateral base, i.e. the EV (knownas Electric Vehicle Communication Controller (EVCC) inISO/IEC 15118 standard) can verify the authenticity of theCS (known as Supply Equipment Communication Controller(SECC) in the ISO/IEC 15118 standard). After a secureTLS connection is established and contract-based paymenthas been selected, the CS or the MO verifies the validity andauthenticity of the contract certificate through a challenge-response process and, if successful, authorizes the chargingand payment process. During the charging loop, the EV hasto periodically provide digital signatures for the cumulativemeter readings provided by the CS.
While these security measures may be appropriate to en-sure security, the standard does not explicitly address pri-vacy. The ISO/IEC 15118 standard actually raises privacyas a concern, but there are no specific measures taken for pri-vacy protection. With this paper we aim to provide a thor-ough privacy analysis of the protocol and provide a seriesof privacy enhancements based on state-of-the-art Privacy-Enhancing-Technologies.
2. PRIVACY IMPACT ASSESSMENTAlready an initial informal glance at the electric vehicle
charging infrastructure and specifically the ISO/IEC 15118protocol reveals the possible privacy issues. As can be seenfrom Figure 1, the EV and the charging stations exchangea lot of potentially personally identifiable information (PII).The vehicle authenticates to the charging station and be-comes thus directly identifiable. Depending on the paymentmodel, this information is not only accessible to the chargingstation and energy provider, but the information may alsobe forwarded to the mobility operator, instantiated, e.g., bythe home electricity provider who will add the charges tothe home electricity bill.
This leads to scenarios where an energy provider maylearn the home location of a vehicle, esp. if the vehicleis registered with a small mobility operator that operates,
38
Figure 2: ISO/IEC 15118 application layer protocol:Security operations.
e.g., only within a city. Beyond, the vehicle uses a specificcertificate to authenticate and thus becomes trackable. Asa result, a vehicle may be tracked and its home locationidentified wherever it travels. Likewise, the mobility opera-tor learns the IDs of all charging spots where its customerscharge.
The ISO/IEC 15118 draft standards foresee a variety ofpayment alternatives like paying with cash, prepaid card,credit card, and RFID card. The standard also foresees theoption of contract-based payment via a MO or home electric-ity provider. While cash allows fully anonymous paymentsand prepaid cards may not require information to be com-municated beyond the CS, contract-based payment alwaysrequires an interaction between the CS and MO. In this case,the CS will learn the identity of the vehicle and the MO andthe MO will learn the identity of the CS leading to evidentprivacy concerns.
While ISO/IEC 15118 foresees security measures based onTLS and XML-security, these privacy concerns are not con-sidered by the draft standards. While anonymous paymentalternatives exist, we expect that the convenience to simplydrive to a charging stations, plug-in the electricity cable, andthen find the charge added to the home utility’s electricitybill will make many drivers choose this option. This moti-vated us to investigate the privacy aspects of electric vehiclecharging and design a fully privacy-friendly solution.
As a first step, we have conducted a Privacy Impact As-sessment (PIA) [15] of the current standard draft with thecontract-based payment option. Our PIA approach includesthe following steps: 1. Scope and purpose definition, 2. Stake-holders, 3. Information assets, 4. Information requirementsand use, 5. Information handling and other considerations,6. Evaluation.
While the full PIA is described in Annex A for reference,we explain here only the resulting privacy invasions (PI) thatwe have identified as a result.
PI 1 Excessive use of PII (e.g., contract ID): The contractID that uniquely identifies the electric vehicle and/orthe driver is used in almost all phases of the communi-cation, starting even at service discovery and is madeavailable both to the CS, the EP, and the MO. We haveidentified that most of these protocol steps do not nec-essarily mandate revealing the contract ID as long asthere are no disputes over the payment. Further iden-tifiers exist that uniquely identify the EV, such as theEVCC ID, the Provisioning Certificate and Cert ID,the Identity Certificate and the Customer ID (see Ap-pendix A for detail). Overall, the protocol uses mul-tiple PII in di!erent protocol steps, which jeopardizesthe privacy.
PI 2 Revealing the MO in conjunction with an EV-identifier:The CS can deduce the MO by considering the Con-tract ID, which contains the MO identifier [4]. In casethe MO is a small local energy supplier, the ID mayreveal in which city or area the EV user lives.
PI 3 Revealing the CS in conjunction with an EV-identifier:During contract validation the charging station includesits own identifiers (Spot Operator and Power OutletID) when communicating with the backend. The MOwill be able to link the EV and the CS, thus revealingexact location and time of the charging e!ectively al-lowing to track the vehicle. This is especially true forthe MO who will receive all charging records that a ve-hicle creates. So the MO will have a complete recordof the places where its customers charge.
PI 4 Revealing the EP in conjunction with an EV-identifier:Analogue to the above case with the MO, if the EP isa small local energy provider, this will also reveal therough location of a vehicle to recipients, esp. to theMO.
So even though the ISO/IEC 15118 standard states that“Private information and user data shall only be readableby the intended addressees” and “Private information shallbe transferred only when necessary” [7], the privacy impactassessment has shown that significant privacy risks exist inusing these protocols in combination with contract-basedcharging. In the remainder of this paper, we will use amulti-step approach to design a privacy-enhanced versionof the ISO/IEC 15118 protocol called POPCORN. Usingthe POPCORN protocol, none of the eMobility stakehold-ers, e.g., the charging station, energy provider, or mobilityoperator, can track an EV, and hence the user, or obtainother private information during a charging process. This isour privacy requirement. In addition, the protocol takes intoaccount the privacy principles as summarized by the Organi-zation for Economic Cooperation and Development (OECD)[10]. In particular, the “Collection Limitation Principle”,and the “Use Limitation Principle” are used as protocol re-quirements.
In a first step, we will minimize the use of PII in theprotocol. In step 2, we will replace some mechanisms likecertificate-based contract authentication with privacy-preser-ving functional alternatives like anonymous credentials. In
39
step 3, we will introduce a privacy-preserving informationflow where privacy intermediaries are introduced that willreveal certain PII only in case of verifiable disputes. Step 4will finally introduce a privacy-preserving payment processfor even more enhanced privacy protection.
3. ENHANCING PRIVACY PROTECTIONThis section discusses the
proposed privacy-preservingcharging protocol – thePOPCORN protocol. First,the process which is usedto develop the protocol, thetechnologies and the addi-tional charging infrastruc-ture are described. Finally, the complete POPCORN pro-tocol is discussed.
3.1 The ISO/IEC 15118 enhancement stepsThe POPCORN protocol is developed as step-wise mod-
ifications of the ISO/IEC 15118 protocol, based on the re-sulting recommendations of the privacy impact assessment.The step-by-step privacy enhancements ensure that all pri-vacy concerns are systematically removed from the ISO/IEC15118 protocol, while preserving the functionality of theISO/IEC 15118 charging protocol.
3.1.1 Step 1: Minimizing PIIThe first step reduces the use of personally identifiable in-
formation to the minimum required for operation. Uniquevehicle identifiers that are not used for charging authentica-tion, such as the EVCC ID, do not need to be communicatedto the charging station. Furthermore, the charging stationcan perform contract authentication locally without commu-nicating information to the backend. The ISO/IEC 15118protocol requires that each charging station has the rootcertificates installed. This eliminates the need for privacy-sensitive contract authentication with the backend.
3.1.2 Step 2: Privacy-preserving functional alterna-tives
The second enhancement is to replace privacy-sensitiveISO/IEC 15118 procedures with privacy-preserving ones.
Contract authentication.The uniquely identifying Contract ID and Certificate that
is used by the ISO/IEC 15118 protocol for charging au-thentication are replaced with anonymous credentials in thePOPCORN protocol. Anonymous credentials allow selectivedisclosure of credential attributes, while hiding the other at-tributes. In addition, anonymous credentials can be used todisclose properties of credential attributes without revealingthe actual attribute value. As concrete implementation forthe POPCORN protocol, the Idemix anonymous credentialsystem [2, 6] has been chosen. The Idemix anonymous cre-dentials o!er multi-show unlinkability and attribute prop-erty proofs.
The charging contract details, including the expirationdate and tari! information, are stored in an anonymouscredential. For authentication the vehicle proves that itscontract is valid based on an equality proof over the expi-ration date and the current date. Similarly, special tari!s
and conditions can be communicated to the charging sta-tion without revealing the vehicle’s identity. The chargingstation can locally verify the contract proof, so that o"inecharging is also possible. The anonymous credentials can beset to have a short lifetime independent of the expirationdate of the contract, so that no other revocation strategiesare required. When the lifetime has expired, the vehicledownloads a credential update and applies it to the expiredcredential to reactivate it. The ISO/IEC 15118 standard al-ready defines messages for certificate updates. One of thedescribed methods provides a communication link to the is-suer of the credentials. This approach can be used, so thatno additional update methods are required. If this is tohappen online before charging, it is required that this com-munication link does not reveal the location of the vehicle.
Meter receipts.The ISO/IEC 15118 protocol requires the electric vehi-
cle to sign the meter readings during the charging loop asprotection against cheating vehicles. These commits directlyreveal the identity of the vehicle. For the POPCORN proto-col, the charging commits are created using group signatures.Short group signatures [1] o!er a suitable implementation forthe POPCORN protocol.
Using group signatures the identity of the signing elec-tric vehicle remains hidden from the charging station andthe energy provider, while the signatures are verifiable byall parties. The created signatures of all vehicles are indis-tinguishable from each other; only the group manager canreveal the identity of the vehicle. The POPCORN protocoladds a trusted dispute resolver (DR) to the charging infras-tructure to fulfill the group manager role. In case of dis-putes, e.g., if a charging bill has not been paid, the disputeresolver can be contacted to verify and solve the dispute.The dispute resolver will uncover the vehicle’s identity andcontact the responsible mobility operator to resolve the dis-pute. The energy provider will not be informed about thevehicle’s identity. At contract establishment, each electricvehicle obtains its group signing credentials.
3.1.3 Step 3: Privacy-preserving information flowThe third enhancement makes the information flow privacy-
preserving, breaking up the direct interaction between theCS /EP and the MO. This is achieved by either redirectingthe messages via non-privacy-sensitive routes or by usingprivacy-preserving communication means, e.g., via privacy-proxies and TOR networks [13]. For example, one option isto send the charging service detail record from the vehicle tothe mobility operator rather than via the charging stationto the mobility operator.
3.1.4 Step 4: Privacy-preserving paymentThe final enhancement aims to make the payment privacy-
preserving. A trusted payment handler (PH) is added to thecharging infrastructure to forward the payment from the mo-bility operator to the receiving energy provider. The recip-ient details are encrypted and unknown to the payee; onlythe payment handler can decrypt the information. The re-ceiver is not informed about the payee. A charging sessiontransaction number is used to link the payment to the spe-
40
Table 1: Content of the SDR for the POPCORN.Field Special properties
Amount of electricity received —Chosen tari! (if applicable) —Amount payable —Recipient of the payment (EP) Encrypted for pay-
ment handlerSession/transaction number —Contract identifier Appended by vehicle,
encrypted for MOEV signature over completeSDR
Appended by vehicle,encrypted for MO
the payment is correct.
In addition to these enhancement steps, the format of theservice detail record that is used to send the charging billto the mobility operator has been redefined as specified inTable 1.
3.2 The POPCORN protocolIn the following the POPCORN protocol steps are ex-
plained in detail: contract establishment and installationof credentials, contract authentication, meter receipts, pay-ment, and dispute resolution. Since the POPCORN protocolis based on the ISO/IEC 15118 standard, it uses the samemessage sequence, structure and general trust and securityrequirements, unless otherwise stated.
Phase 0 of the POPCORN protocol is only required whenthe EV user signs a new mobility contract. The phases 1-4occur during every charging session. Phase 5 is only requiredin case of disputes.
Phase 0: Mobility contract establishment.The contract establishment including the anonymous cre-
dential and group membership certificate installation is il-lustrated in Fig. 3. At vehicle production the OEM installsa Provisioning Certificate (also referred to as Bootstrap Cer-tificate) in the vehicle (Step (a)). To charge using contract-based payment, the EV user signs a mobility contract witha mobility operator and registers the vehicle with the mobil-ity operator (Step (b)). The mobility operator asks a globalcertificate authority to generate the anonymous credentialsfor the vehicle. The Idemix system allows the mobility op-erator to hide the contract attributes from the certificateauthority, so that no private information about the user isrevealed.
Before the first charging session using the mobility con-tract, the anonymous contract credentials and the group sig-nature credentials have to be installed in the electric vehi-cle. The electric vehicle contacts the mobility operator forcredential installation, for example, using the user’s homeInternet connection or the cellular network (Step (c)). Theanonymous credentials including any other relevant contractattributes, e.g., special tari!s, are installed in the vehicle(Step (d)).That way, the electric vehicle also receives the certified pub-lic key of the mobility operator, which is used later to en-crypt the SDRs. To obtain the group membership certifi-cate, the vehicle generates a secret key for the group mem-bership (Step (e)) and contacts the group manager, i.e.,
the dispute resolver, to obtain the group signing credentials(Step (f)+(g)). Now the electric vehicle can charge usingthe automated billing feature.
Figure 3: The POPCORN contract establishment.
Occasionally, the vehicle has to check for updates for itscredentials. The anonymous credentials have a short lifetimein order to avoid having to use more complex revocationstrategies. Similarly, the group membership has to be up-dated when vehicles leave the group. The charging stationwill refuse a signature and stop the charging session, if thevehicle has outdated group credentials. Most updates arenon-interactive and can be downloaded by the vehicle whenit has an online connection like a home access point or usingan update method already defined by the ISO/IEC 15118standard. If necessary, the mobility operator may contactthe vehicle to inform it about a necessary update, e.g., toupdate the public key of the mobility operator.
The following POPCORN protocol phases 1-5 are depictedin Fig. 4.
Figure 4: The POPCORN protocol for chargingwith automated payment.
Phase 1: Contract authentication.When the electric vehicle is plugged into a charging sta-
tion, the electric vehicle and charging station establish acommunication link as defined in ISO/IEC 15118. The stan-dard requires server-side TLS authentication to enable anauthenticated and encrypted channel between the vehicleand the charging station. Also, the POPCORN protocol re-
41
cific charging session, so that the receiver can verify whether
quires this. Next, for contract authentication, the electricvehicle proves to the charging station that it has a valid con-tract using its anonymous credentials (Step (1.1)). To showthat the contract is still valid the vehicle applies an attributeoperation to compare the contract end date with the currentdate. The vehicle does not disclose any other contract at-tributes. The vehicle also has to prove that the anonymouscredentials’ validity period has not expired to show that thecredentials have not been revoked. The charging station canlocally verify the validity of the proof (Step (1.2)) and hencethe charging contract (Step (1.3)). If the vehicle is eligibleto special tari!s, the electric vehicle can use its credentialsto prove this to the charging station by performing anotherattribute proof.
Phase 2: Charging loop with meter receipts.During the charging loop, the charging station sends the
current meter reading to the electric vehicle after some fixedamount of energy has been delivered (Step (2.1)). Theelectric vehicle then generates a group signature over thereading and sends the resulting payment commitment back(Step (2.2)). The charging station verifies the signature withthe group’s public key (Step (2.3)). If the signature is valid,the charging cycle continues, otherwise the charging stationaborts the charging session.
At the end of the charging session, the charging stationgenerates a partial SDR and sends it to the electric vehicle(Step (3.1)+(3.2)). Now the connection between the electricvehicle and the charging station is terminated. The charg-ing station anonymously forwards, e.g., via a TOR network,the group-signed commitments and the partial SDR to theenergy provider. The energy provider can link the chargingsession to an incoming payment using the transaction num-ber contained in the SDR (Step (3.3)). Since the informationis transferred anonymously, the energy provider cannot linkthe charging session to a specific charging station.
Phase 3 and 4: SDR delivery and payment.The electric vehicle probabilistically encrypts its Contract
ID and appends it to the partial SDR. The electric vehi-cle then signs the complete SDR. When the electric vehiclehas access to an Internet connection, e.g., using the cellu-lar network or the user’s home Internet WLAN, the com-plete encrypted SDR is submitted to the mobility operator(Step (3.4)). The vehicle should not use the charging sta-tion’s Internet service for this forwarding, as this may revealthe charging location based on the source IP address. Inthis case, the vehicle has to make use of a privacy proxy.The mobility operator verifies the signature and uncoversthe Contract ID. The mobility operator now knows whichuser the bill belongs to and can inform and bill the userfor the charging session (Step (4.3)). The mobility opera-tor will, however, not learn the charging station or energyprovider identities.
In order to complete the processing of the SDR the mobil-ity operator sends the payment with the encrypted energyprovider value and the transaction number (both containedin the SDR) to the payment handler (Step (4.1)). The pay-ment handler decrypts the identity of the energy providerand forwards the payment and transaction number accord-ingly (Step (4.2)+(4.3)). Finally, the payment handler sends
a receipt to the mobility operator, to confirm the payment(Step (4.4)).
Phase 5: Dispute resolution.If the payment of a charging session does not arrive within
the defined payment period, the energy provider can contactthe dispute resolver with the group-signed meter readingsand the partial SDR (Step (5.1)). The dispute resolver hasaccess to the group’s secret key and can uncover the vehicle’sidentity from the commits (Step (5.2)). As a first step, thedispute resolver contacts the mobility operator of the vehiclein questions and requests the payment receipt (Step (5.3)).The mobility operator has to check his records for the givenSDR.If the mobility operator cannot send the matching receipt,the mobility operator has to fulfill the missing payment.In addition, the mobility operator may verify with his cus-tomer why no SDR was submitted for the charging session(Step (5.5)). The dispute is resolved when a valid receipt forthe transaction in question is shown to the dispute resolver(Step (5.4)).
It should be noted that the above consideration assumedthat energy provider and mobility operator are di!erent le-gal entities. In case the energy provider is the same as themobility operator, the protocol still ensures privacy. Anycharging station anonymously sends the charging details tothe energy provider, so that the combined MO-EP cannotdeduce where the electric vehicle was charged.
Table 2 summarizes the major modifications of POPCORNcompared to ISO/IEC 15118.
4. EVALUATIONIn this section, we evaluate our privacy-preserving charg-
ing protocol (POPCORN) with respect to privacy and fea-sibility. First, the PIA as conducted on the initial ISO/IEC15118 protocol (see Section 2) is repeated with the POP-CORN protocol to compare the two and identify the addedprivacy protection that we have reached. Then, a proof-of-concept prototype is presented to demonstrate the feasibil-ity. Finally, we end this section with some conclusions.
4.1 PIA of the POPCORN protocolThis Privacy Impact Assessment (PIA) analyzes the POP-
CORN eMobility system, as described in Section 3. Asfor the PIA of the ISO/IEC 15118 protocol (see Section 2and Appendix A), we focus on the privacy protection of theelectric vehicle user in the contract-based charging scenario.The purpose of this assessment is to evaluate the enhancedprivacy-preserving properties of the POPCORN protocol.
4.1.1 StakeholdersPOPCORN introduces two new stakeholders: the dispute
resolver and the payment handler. The description of theelectric vehicle user, charging station, CS’s energy provider,and EV’s mobility operator remain unchanged (cf. Section1 and Appendix A.2).
Dispute resolver (DR): The dispute resolver is a trustedparty of the POPCORN eMobility system. The DR is thegroup manager for the meter reading commitment creden-tials. It manages the joining and leaving of group members,and distributes keys for signing the meter reading commit-
42
Table 2: Comparison of ISO/IEC 15118 and POPCORN protocol.Activity ISO/IEC 15118 POPCORN
Contract authentication Certificate and Contract ID Anonymous credentials with contract attributes, incl.Contract ID
Determine tari!s Contract ID or attribute certificate Anonymous credentials attributesContract establishment Provisioning Certificate registered
with mobility operatorIdentical to ISO/IEC 15118
Credential installation /update
EV obtains: Contract Cert. andID, CRLs
EV obtains: Anonymous credentials, Contract ID, groupmembership certificate
Contract authentication EV shows Contract Cert. and ID,CS verifies with backend
EV proves contract validity with anonymous credentials,CS verifies locally
Meter reading commit-ment
EV signings with its signing key, CScan verify signature, sent to EP
EV generates group signature, CS can verify signature,sent to EP
SDR delivery CS generates and delivers SDR CS generates partial SDR, EV appends extra values,signs and delivers SDR
Payment MO reads SDR and pays EP MO reads SDR and sends payment and encrypted re-ceiver value to PH, PH decrypts receiver and forwardspayment, PH sends receipt to MO
Dispute EP uncovers EV identity from sig-nature and contacts EV/MO
EP submits dispute with DR, DR verifies and uncoversEV identity from group signature, DR contacts MO/EVand obtains payment receipt to resolve dispute
ments. The electric vehicle may have to contact the DR toobtain its signing credentials, but this may also be initiatedby the vehicle’s mobility operator. The dispute resolver iscontacted by the energy provider in case of disputes aboutoutstanding payments. The DR verifies the dispute and mayuncover and contact the concerned mobility operator andelectric vehicle.
Payment intermediary/handler (PH): The paymenthandler is used to handle the monetary flow between themobility operator and the energy provider. The PH receivesthe charging payment from the mobility operator and sendsit to the rightful energy provider. The stakeholders trustthe PH to deliver the payment correctly.
4.1.2 Information assetsNext, the messages of the POPCORN protocol are in-
spected for important information assets. We have identifiedthe following assets as Personally Identifiable Information(PII), i.e., assets that uniquely identify the electric vehicleand hence the user:
• Contract ID• Anonymous contract credentials• EVCC ID• Signed meter readings (only towards DR; DR can link
EV to EP and MO)• Service detail record with appended EV data (only to-
wards MO; MO cannot link EV to CS/EP)
4.1.3 Information requirements and useDuring the EV contract authentication (see Fig. 3), the
vehicle creates a zero-knowledge proof using its anonymouscontract credentials to prove that it owns a valid chargingcontract. The actual anonymous credentials are not sent tothe charging station, so the CS does not learn the identify ofthe vehicle. The charging station verifies the proof locally,removing the need to use the backend for contract credentialverification.
After charging, the charging station anonymously sendsthe (group-)signed meter readings and the partial SDR tothe energy provider. The partial SDR is also sent to theelectric vehicle which appends extra information includingits contract ID to the SDR and submits it to the mobility op-erator. The mobility operator has now all the information toinform/bill the EV user for the charging session and to paythe energy provider based on the encrypted EP identity inthe SDR. The payment is handled by a payment intermedi-ary, so that the mobility operator does not learn the identityof the energy provider. The group signature on the meterreadings hides the identity of the vehicle from the chargingstation and the energy provider. If there is a dispute, thedispute resolver has the means to uncover the identity.
4.1.4 DiscussionThe goal of the POPCORN protocol is to o!er complete
privacy-preserving charging while using a mobility contractfor payment. The protocol was designed to be privacy-preserving using technical means.
All personally identifiable information assets were exam-ined in this PIA. While there still exist personally identi-fiable information assets, their use and disclosure has beenlimited to a required minimum. The privacy-invasive Con-tract ID is only used by the electric vehicle to inform itsmobility operator about which vehicle has been charging, sothat the mobility operator can inform and bill the EV user.In addition, the signed meter readings no longer reveal theelectric vehicle identity to the charging station or energyprovider as a group signature is being used.
In accordance with our initial analysis of the informationrequirements, contract verification with the backend is nolonger required. The monetary information flow has beenhidden, o!ering more privacy than the PIA suggestion. Alink between a specific charging and payment process canonly be created by the dispute resolver and only in case theEP provides commits and SDRs. In such case, either the
43
MO or the DR can contact the user and enforce paymentwithout the EP needing to learn the identity of the user.
In summary, all initial PIA recommendations for minimiz-ing the information use have been implemented in the POP-CORN protocol. We conclude that the privacy-invasionssummarized in Sec. 2 have been reduced to a required min-imum. PI2 is avoided altogether. PI1 still occurs when theEV provides its contract ID together with the SDR to theMO. This cannot be avoided when using a charging contractas the MO needs to know which EV customer to charge. Adispute resolution results in PI3. The dispute resolver learnsthe EV identity together with the MO (PI3) and the EP(PI4). For accountability and abuse protection this cannotbe prevented. Here, it is important that the dispute resolveris a trusted party that does not collude with any of the otherstakeholders, e.g., an energy provider.
It is even possible to avoid the PI4, by requiring the en-ergy provider to submit the dispute anonymously. Then, thedispute resolver only learns that the vehicle is a customerof some mobility operator. However, using this approachmeans that the dispute resolver is not able to detect abuse ofthe dispute resolution feature, e.g., an energy provider thatrequest dispute resolution for every charging session. Whilethis form of abuse does not o!er any benefits to the energyprovider, it can be considered as a denial-of-service attackon the dispute resolver. Further, the payment intermedi-ary learns about the mobility operator to energy providerlinks, however without any EV identifier involved. Hence,this does not result in any privacy-invasion. Nevertheless,the payment intermediary has to be a trusted party that willhandle the payment correctly.
The PIA applied to the POPCORN protocol shows thatthe protocol is fully privacy-preserving and the recommen-dations resulting from the initial ISO/IEC 15118 PIA wereapplied. However, as for any protocol, it is important thatall credentials and key material is kept secret. The vehiclehas to protect its anonymous credentials and group signingkey, and these credentials have to be securely transferred tothe vehicle. In addition, the mobility operator should not bethe issuer of the anonymous credentials, because the issueris revealed during the contract authentication proof. A cer-tificate authority should issue the credentials on behalf of anumber of mobility operators. Preferably, the certificate au-thority is a large global organization responsible for a largepart of the eMobility infrastructure, since using small cer-tificate authorities to issue the anonymous credentials willreduce the anonymity set size.
4.2 POPCORN proof-of-conceptIn order to evaluate the feasibility of POPCORN and to
demonstrate the protocol, a proof-of-concept, shown in Fig-ure 5, has been implemented using an electric toy vehicle.This section discusses the implementation setup, the testedscenarios and the results.
4.2.1 Software setupThe proof-of-concept is implemented using the Java Open-
JDK [9]. The six stakeholders are implemented as separateJava processes. All stakeholders operate TCP servers andcan also start outgoing connections. The electric vehicle only
acts as client. All communication exchanges consist of oneor more request-response pairs. A simple message structurehas been defined, consisting of a message identifier, whichspecifies the purpose of the message, such as “SDR Deliv-ery” and a data body, which may be empty or contain anundefined number of relevant data, e.g. a meter reading.
The anonymous credentials are implemented using Idemix[11], and group signatures are implemented using the Camenisch-Groth algorithm [16].
4.2.2 Hardware setupThe proof-of-concept hardware setup is depicted in Fig. 5.
The electric vehicle and the charging station processes areeach run on a Raspberry Pi computer. A Raspberry Pi isa credit-card-sized computer that uses a 700 MHz ARM11processor and supports the ARMv6 instruction set [12]. Thissingle-board computer was chosen, because it can be fittedinto a toy electric car for the physical demonstration of thecharging protocol. Further, it has GPIO pins, which canbe used to indicate the connection status, the status of thepower delivery and to actually charge the toy car’s batter-ies. Finally, the Raspberry Pi has a low-resource processorwhich more closely resembles the low-resource hardware ofthe electric vehicle’s or charging station’s communicationcontroller. The backend processes are run on an old laptop(Dell Inspiron 6400).
All stakeholders are on the same IP subnet and are con-nected to each other via Ethernet. The electric vehicle addi-tionally has a wireless networking adapter to contact the mo-bility operator and dispute resolver for credential and certifi-cate installation and updates. During the charging session,the electric vehicle and the charging station are connectedto each other with a modified Ethernet cable. The cablehas been fitted with a custom plug and uses only two wirepairs of the four-pair Ethernet cable for 100 Mbps Ethernetcommunication. The other cables are used for charging andfor detecting the physical connection between the chargingstation and the electric vehicle.
4.2.3 Scenarios
Figure 5: The proof-of-concept hardware setup.
44
The proof-of-concept considers the charging scenario withautomated billing of a single vehicle and the communica-tion between the electric vehicle, the vehicle’s mobility op-erator, a charging station and the charging station’s energyprovider. The following scenarios were tested with the proof-of-concept:
1. Normal charging : First, the anonymous credentialsand membership certificate are installed/updated. Then,a normal charging session with subsequent SDR deliv-ery and payment is performed.
2. Expired contract : The mobility operator installs ex-pired contract credentials and the electric vehicle triesto charge at the charging station.
3. Cheating EP : After a normal charging session, the en-ergy provider request for dispute resolution for an al-ready paid SDR.
4. Cheating EV : During the charging session, the electricvehicle disconnects the charging cables and leaves.
4.2.4 ResultsThe proof-of-concept fulfilled its purpose of evaluating the
POPCORN protocol in a practical manner. The implemen-tation clarified the details of the dispute resolution and im-proved the protocol to o!er better accountability.
Overall, the POPCORN protocol performs well and wasable to handle all scenarios. In order to get an idea how thePOPCORN protocol performs on low-resource hardware,the time it takes for the cryptographic operations has beenmeasured when running all stakeholder processes on the lap-top, and when running the electric vehicle and the chargingstation on the Raspberry Pis. The default key length val-ues of the two cryptography libraries were used. It shouldbe noted that these measurements cannot be seen as final,since no enhancing measures were taken. The results aresummarized in Table 3.
Computation Time taken in sec.Laptop RaspberryPi
Installing anonymous cred. 1.5 35Updating anonymous cred. 0.62 - 2 5.5Installing group cred. 0.1 0.85Creating contract proof 0.95 105Verifying contract proof 1.05 90Signing meter reading 0.070 8Verifying signature 0.072 8.5
Table 3: Time measurements of the cryptographicoperations.
While most operations take a reasonable amount of time,creating the contract proof and verifying it takes a long timeon the Raspberry Pis. One of the factors that significantlyslows down these steps is the use of the Java Virtual Ma-chine (JVM) on top of the Raspbian operating system. Acomparison between the default Java cryptography libraryand native code within Java shows that using optimized Javalibraries already increases the speed of modular exponentia-tion by a factor of three [3]. However, in a real deploymentof POPCORN all computations will be implemented usingnative code that has been optimized for the low-resource
hardware. Hence, the software-related speed issues can beignored.
To use the idle time while the charging station is verify-ing the proof, the vehicle can already prepare the batterymanagement module for power delivery. In addition, duringthe charging cycle the charging station requests the vehicleto sign the cumulative meter reading of the previous charg-ing cycles. If the vehicle aborts the charging prematurely,the charging station will miss the signature of the last cy-cle’s power delivery and will not receive the payment for thiscycle. If the proof verification takes less time than a charg-ing cycle, the power delivery could already be started whilethe charging station is still verifying the contract. Thenthe economic risk is the same as during a charging cycle.The duration of a charging cycle has to be short enough tomake charging the vehicle by only obtaining power duringthe proof verification infeasible.
A charging session generally takes at least a few minutes,so that an order of magnitude within the few seconds doesnot a!ect the overall performance of the charging. The speedof installing and updating contract credentials and member-ship certificates is less important, because these operationscan be done overnight while the vehicle is not in use.
The results and findings for each scenario are described inthe following.
Scenario 1 shows a feature of Idemix that is the possibilityof hiding attribute values from the issuer. For the proof-of-concept, this is not required since the mobility operator isthe one who decides the values. However, in a real deploy-ment of the POPCORN protocol, this can be used to hidethe information from the certificate authority who issues thecredentials on behalf of the mobility operator.
Scenario 2 demonstrates another benefit of Idemix. In-deed, the electric vehicle is not able to create a proof if thecontract has expired. Therefore, the contract authentica-tion already fails on the vehicle’s side and it is unlikely thata vehicle will approach the charging station with an invalidcontract. To check if the contract is valid, the vehicle cangenerate a nonce itself and try to create a proof. If proof cre-ation fails, the vehicle can inform the user that an Internetconnection is required to update the credentials. However,depending on how the expiration date and the anonymouscredentials itself are stored in the vehicle, it may be easier tosimply check the expiration date in the contract credential.
Scenario 3 shows that it is necessary to be able to iden-tify charging sessions, e.g., with a transaction number. ThePOPCORN protocol includes this number in the SDR.With-out a transaction number the energy provider and mobilityoperator have no means to identify a specific session in caseof disputes. Also in the case that the charging station isoperated by the mobility operator, the mobility operatorcannot link the partial SDR from the charging station withthe complete SDR sent by the vehicle, because the chargingstation is required to transfer the data anonymously.
In Scenario 4, the electric vehicle leaves and never receivesand forwards the SDR, and thus, triggers a dispute. This
45
scenario demonstrates the benefit of group signature.
The evaluations show that the privacy requirements havebeen fulfilled and that a fully privacy-preserving electric ve-hicle charging with contract-based payment is possible. Theprototype implementations shows that this can even be im-plemented on resource-limited hardware.
5. CONCLUSIONIn this work we have highlighted the privacy invasion that
electric vehicle charging based on ISO/IEC 15118 may in-troduce. As our privacy impact assessment of this protocolhas shown, drivers may unnecessarily reveal details abouttheir whereabouts to charging station and mobility opera-tors. Using our PIA results, we designed modular enhance-ments of the protocol based on state-of-the-art PETs, show-ing that PET technology allows to implement comfortableand fully functional Authentication, Authorization and Ac-counting (AAA) for eMobility and electric vehicle chargingwithout sacrificing privacy. This claim was corroborated bya second PIA analysis and a prototype implementation.
By taking a modular approach to extend the originalISO/IEC 15118 protocol, POPCORN can even be intro-duced in a gradual way, if industry is not willing to initiallyintroduce a dispute resolver or payment handler. Of coursethis goes at a reduced privacy protection. Still it wouldallow an immediate introduction of better privacy protec-tion to the current protocols and infrastructures. We are inthe process of submitting our POPCORN proposal to therespective ISO working group to discuss the potential foractual consideration in the standard.
We have the hope that our work will provide a signifi-cant contribution to the introduction of privacy-preservingand still functional and convenient electric vehicle charg-ing infrastructures. At the same time, it provides a lessonhow today’s PETs in combination with thorough PIA canbe used to build and deploy privacy-enhancing systems thatintroduce only modest additional e!ort but fully retain sys-tem functionality and security.
ISO/IEC 15118 will mainly a!ect the European market.In the U.S., SAE J2836/2847 will play a similar role. Weplan to investigate the security protection of this protocolas a next step in our e!ort to bring privacy-preserving eMo-bility closer to reality.
6. ACKNOWLEDGEMENTSThe research leading to these results has received funding
from the European Union’s Seventh Framework Programmeproject PRESERVE under grant agreement n!269994.
7. REFERENCES[1] D. Boneh, X. Boyen, and H. Shacham. Short group
signatures. In Advances in Cryptology—CRYPTO2004, volume 3152 of Lecture Notes in ComputerScience, pages 41–55. Berlin: Springer-Verlag, 2004.
[2] J. Camenisch and E. Van Herreweghen. Design andimplementation of the idemix anonymous credentialsystem. In Proceedings of the 9th ACM conference onComputer and communications security, CCS ’02,pages 21–30, New York, NY, USA, 2002. ACM.
[3] N. Desmoulins, S. Canard, and J. Traore (Orange LabsR&D, France). 3rd International Conference on Trustand Trustworthy Computing: Java Implementation ofGroup and Blind Signatures. http://www.trust2010.org/slides/Desmoulins.pdf (slides), Jun 2010.
[4] Deutsches Institut fur Normung. DIN SPEC91286:2011-11: Electric mobility – Schemes ofidentifiers for E-Roaming – Contract ID and EVSEID. http://www.beuth.de/en/technical-rule/din-spec-91286/145915787, Nov 2011.
[5] R. Housley, W. Polk, W. Ford, and D. Solo. RFC 3280- Internet X.509 Public Key Infrastructure Certificate.Technical report, IETF, 2002.
[6] IBM Research Zurich, PrimeLife, and PRIME.Identity Mixer – Download. https://prime.inf.tu-dresden.de/idemix/, 2012.
[7] ISO. Road vehicles – Vehicle-to-Grid CommunicationInterface – Part 1: General information and use-casedefinition (Draft). 2012.
[8] ISO. Road vehicles – Vehicle-to-Grid CommunicationInterface – Part 2: Technical protocol description andOpen Systems Interconnections (OSI) layerrequirements (Draft). 2012.
[9] Oracle Corporation. OpenJDK. http://openjdk.java.net/, 2012.
[10] Organisation for Economic Co-operation andDevelopment (OECD). OECD Privacy Principles.http://oecdprivacy.org, 2010.
[11] PrimeLife Project. PrimeLife - bringing sustainableprivacy and identity management to future networksand services. http://primelife.ercim.eu/, Oct 2011.
[12] Raspberry Pi Foundation. Raspberry Pi - An ARMGNU/Linux box. http://www.raspberrypi.org/,2012.
[13] Tor Project. Anonymity online. https://www.torproject.org/, 2012.
[14] I. T. Union. ITU-T Recommendation X.509 | ISO/IEC9594-8: ”Information Technology - Open SystemsInterconnection - The Directory: Public-Key andAttribute Certificate Frameworks”. Technical report.
[15] United States Government Department of HomelandSecurity. Privacy o#ce - privacy impact assessments(PIA). http://www.dhs.gov/privacy-office-privacy-impact-assessments-pia (Accessed Aug.2012), 2012.
[16] Universita degli Studi di Brescia. PP2db: APrivacy-Preserving, P2P-based Scalable StorageSystem for Mobile Networks. http://www.ing.unibs.it/ntw/tools/pp2db/, 2011.
46
In Scenario 4, the electric vehicle leaves and never receivesand forwards the SDR, and thus, triggers a dispute. This
APPENDIXA. ISO/IEC 15118 PIA
This section summarizes the Privacy Impact Assessment(PIA) of the ISO/IEC 15118 charging protocol (see Sec-tion 1).
A.1 Scope and purpose definitionThis PIA analyzes the privacy risks of the eMobility sys-
tem. The complete eMobility system forms a vast distributedinfrastructure with several stakeholders. The focus of thisPIA is on potential privacy invasions from the point of viewof the user, i.e., the driver or owner of the EV. To representthe eMobility system the ISO/IEC 15118 charging protocol[8, 7] is used. The PIA concentrates on the specific use-case of charging with automated billing via the eMobilityinfrastructure (i.e. contract-based payment). The assess-ment is conducted without contact with the developers ofthe ISO/IEC 15118 charging protocol. Hence, it is limitedto the study of the available documents and public informa-tion.
The purpose of the assessment is to systematically identifythe privacy risks of the ISO/IEC 15118 standard. Further,we hope to identify areas of the protocol where less privacy-invasive approaches can be used and would like to suggestalternatives if possible.
A.2 StakeholdersIn the following, the role of each stakeholder is introduced
based on the ISO/IEC 15118 protocol.
Electric vehicle (EV) user.This is the legal entity using the vehicle, i.e., the EV owner
and in most cases the driver of the EV. The user has signed amobility contract with the mobility operator. The chargingparameter negotiation and payment is automatically han-dled via the charging protocol.
Charging station (CS).The CS is the EV’s communication partner in terms of the
charging protocol. The CS communicates with the vehicle tonegotiate the charging parameters, manage power deliveryand to handle the payment.
CS’s energy provider (EP).The EP operates the CS and receives the payment for
the energy use. For accountability, we assume that the EPwants to link the energy consumption to a payment. Forthis PIA, we assume that the EP has access to the datarecorded by the charging station unless it is protected bysecurity measures or the protocol explicitly states that thedata remains only accessible to the charging station.
EV’s mobility operator (MO).The MO has a charging contract with the EV user. The
mobility operator may be the same energy provider as theone operating the CS, a di!erent one or a third party. Forthe PIA we assume that the MO is di!erent from the charg-ing station’s EP (EV is roaming) and that the MO is theuser’s home domestic supplier.
A.3 Information assets
To determine the information assets the usecase descrip-tions [7] and messages of the ISO/IEC 15118 protocol [8]are examined to find out what information exists in the sys-tem, where it comes from and with whom it is shared. Theprotocol describes several usecases ranging from vehicle au-thentication to charging schedule negotiation and chargingspecific actions. For this analysis we are most interestedin the identification, authentication, authorization and pay-ment communication, as these are likely to contain vehicleidentifying information.
Information assets can come in di!erent forms, such asidentifiers, certificates, meter readings, timestamps and sig-natures. Privacy risks are caused by information that uniquelyidentify the EV (and hence its user) and information thatindirectly reveals information about the vehicle. The prob-lematic information assets are described in Table 4. Emptycells indicate that no information is given in the standard.
After analyzing the information assets described in Ta-ble 4, it can be concluded that the following certificatesand identifiers are personally identifiable information: Con-tract ID and contract certificate, identity certificate and anyattribute certificate linked it, customer ID, EVCC ID andMAC address, signed meter readings, and the service detailrecords. The following information assets may reveal privacysensitive information when linked with a personally identi-fiable information asset: Mobility operator ID (Provider),EVSE ID and Power outlet ID, EVSE operator ID (Spotoperator), and timestamps.
For example, if the EVSE ID is linked to a Contract IDduring a charging session, the receiver of this informationknows that the EV has been charged at the charging stationwith the EVSE ID. Together with a timestamp the receiverof the information will know exactly when the EV user hasbeen at that location. The Provisioning certificate and CertID are not used during the charging process. However, theyuniquely identify the vehicle and may be sent to the chargingstation to install or update the Contract certificate and ID.
A.4 Information requirements and useNext, the ISO/IEC 15118 protocol’s steps and the min-
imum information requirements are examined to identifyparts in the protocol that can be made less privacy-invasive.The analysis focuses on the communication for the (i) mobil-ity contract establishment, (ii) EV authentication and (iii)charging payment including dispute resolution. These partsof the protocol are selected since the assets discussed aboveare used in these scenarios.
(i) Mobility contract establishment.During the EV contract establishment the vehicle trans-
mits its Provisioning/ Bootstrap Certificate and the CertID to its new mobility operator. The mobility operatorthen creates a Contract Certificate and Contract ID andsends it to the vehicle. During these steps, information thatuniquely identifies the EV is passed to the charging station.The ISO/IEC 15118 standard states that other forms of cer-tificate installation/update that do not involve the CS couldbe used, but such methods are outside the scope of the stan-dard.
(ii) EV (contract) authentication.To show that the EV has a charging contract it sends its
Contract Certificate, Contract ID and the Mobility Operator
47
Table 4: Identified problematic information assets. Assumptions are printed in italics.Asset name Origin Use(s) Issue(s)
Provisioning/boot-strap cert., CertID [8, 7]
Installed by OEM inproduction process.
Links vehicle to contract when conclud-ing mobility contract. Not used forcharging communication.
Unique for each vehicle.
Contract ID (asdefined in [4])and contractcertificate
Obtained from MO /CH, updated via CS.May be part of an at-tribute certificate.
Identifies vehicle’s charging contract.EV sends it to CS for authentication.CS sends it to the backend (MO/CH)for validity check.
Unique for each vehicle-contract.Reveals the home country and mo-bility operator of the contract.
Attribute cer-tificate (Publiccertificate asdefined in [14, 5])
Obtained from MO,CH or an Attribute Au-thority. Can be boundto identify certificate.
Guarantees that EV is equipped with apre-established contract, which enablesauthorization for charging even in CSo"ine scenarios.
Unique, contains Contract ID.
Identity certificate Obtained from a CA. Used at transport layer for mutual au-thentication of EV and CS. OCSP usedfor validating the certificate.
Uniquely identifies the EV. Notsent to third parties except as partof OCSP.
Customer ID For identification, can be ID, certificateor PIN.
CS may learn customer identity.
EVCC ID Installed during man-ufacturing of EVCCcomponent.
The EV’s identifier. Contains the MACaddress of the EVCC, used during ses-sion setup with the CS.
The MAC is unique.
E-Mobility opera-tor ID same asProvider ID
Unique identification of MO. Identifiesthe issuer of Contract ID. May be usedfor roaming. Is sent to CS with Con-tract ID for EV (contract) authentica-tion.
Reveals MO of the EV to partieswho receive the ID (e.g., CS andCH).
EVSE ID (as de-fined in [4]) andPower outlet ID
EVSE operator will fixthe power outlet ID.
Unique identification of charging spot.Power outlet ID is sent to backend dur-ing EV authentication process.
Identifies charging location.EVSE ID reveals the CS’s coun-try and EP. Links EV to CS whenidentifiers are sent together.
EVSE operator IDor Spot OperatorID (the EP’s ID)
Sent with Power Outlet ID, EV’s Con-tract ID and Provider ID to secondaryactors for online EV authentication.
Identifies charging location of thevehicle. Links EV to CS whenidentifiers are sent together.
Signed meterreadings
EV signs the meterreading of the CS.
Used as proof that EV consumed saidamount of energy. CS sends it to EP.
Reveals EV to EP and likely toalso reveal CS to EP.
Service detailrecord
Either generated by CSat end of (charging)session or by a CH.
Sent to MO and possibly EV. Con-tains enough information (details un-specified), so that MO can pay EP andcharge EV.
If involved, CH learns charging de-tails. Reveals EP to MO. May re-veal the CS to MO.
Timestamps Added by CS to somemessages.
Used during SessionSetupRes, for Me-terInfoType and PaymentDetailsResmessages.
Can reveal exact time of charg-ing to backend when included withdata.
ID to the charging station. If the charging station is online,then it verifies the validity of the contract by contactingthe mobility operator or a clearing house. The chargingstation also sends its own identifiers to the verifier. An o"inecharging station can validate the certificate using the globalroot certificate. However, the standard does not explicitlystate this. Instead the standard describes that the chargingstation may still transmit the same information as in theonline case at a later point in time. Therefore, the onlydi!erence between online and o"ine CS scenarios is that inthe online case the validation, and hence the transmissionof the information, is real-time. In addition, for most EVrequests, the vehicle has to be identified and authenticated.For this the ISO/IEC 15118 standard suggests to use theContract ID, since it uniquely identifies the EV, which is aprivacy risk.
(iii) Charging payment incl. dispute resolution.The payment process is not clearly explained in the ISO/IEC
15118 protocol. Only part 1 of the standard gives hintsabout the procedure. After the charging session, the charg-ing station sends the signed meter readings to the energyprovider, proving that the EV has consumed energy at thecharging station. Further, the charging station creates aservice detail record (SDR) and sends it to the mobility op-erator. The SDR may also be created by a clearing house.
Sending the signed meter readings to the EP is an account-ability measure. If the payment does not occur the energyprovider can use the singed meter readings to prove that theEV has consumed the energy and request the payment. Thisprocedure is privacy-invasive for the EV user.
48
