P6V2G: a privacy-preserving V2G scheme for two-way payments and reputation

The number of electric vehicles (EVs) is steadily growing. This provides a promising opportunity for balancing the smart grid of the future, because vehicle-to-grid (V2G) systems can utilize the batteries of plugged-in EVs as much needed distributed energy storage: In times of high production and low demand the excess energy in the grid is stored in the EVs’ batteries, while peaks in demand are mitigated by EVs feeding electricity back to the grid. But the data needed for managing individual V2G charging sessions as well as for billing and rewards is of a highly personal and therefore sensitive nature. This causes V2G systems to pose a significant threat to the privacy of their users. Existing cryptographic protocols for this scenario either do not offer adequate privacy protection or fail to provide key features necessary to obtain a practical system. Based on the recent cryptographic toll collection framework P4TC, this work introduces a privacy-preserving but efficient V2G payment and reward system called P6V2G. Our system facilitates two-way transactions in a semi online and post-payment setting. It provides double-spending detection, an integrated reputation system, contingency traceability and blacklisting features, and is portable between EVs. The aforementioned properties are holistically captured within an established cryptographic security framework. In contrast to existing protocols, this formal model of a V2G payment and reward system allows us to assert all properties through a comprehensive formal proof.


INTRODUCTION
In an e ort to counter global warming and fossil fuel depletion, energy transitions from fossil fuels to renewable energy sources are expedited on a global scale. is change from time-independent, fully controllable power plants to highly volatile, seasonal and distributed renewable power generation poses many challenges. Foremost among them is balancing generation and demand to maintain stability of the energy distribution system and provide uniform power quality. is requires increased storage capacities and load exibility. One aspect of the energy transition-which has the potential to solve at least part of this problem-is the introduction of electric vehicles (EVs) as a means of private and public transportation. EVs do not require fossil fuels and can signi cantly reduce air and noise pollution, especially in urban areas. Most industrial nations have started to subsidize EVs as well as set concrete objectives on how many EVs they want to deploy by a certain year [25]. Target dates for complete bans on the sale of new cars with internal combustion engines are as early as 2020 in some countries-with many others planning to have phased them out by 2030 [11,20,39]. While EVs themselves pose a substantial and growing demand on the system, they also have the capacity to contribute to a solution. Privately owned vehicles remain parked for more than 95% of the time [35]. During this time the EV's ba ery can be utilized in a vehicle-to-grid (V2G) scheme, providing storage capacity and exibility in the recharging process to help balance power generation and demand in the grid [35]: Surpluses from volatile renewable power generation can be stored in parked EV's ba eries, which collectively provide substantial distributed energy storage. Conversely, energy stored in EVs can be used to mitigate peaks in demand and drops in generation. In contrast to the bene ts such a system provides it can also pose a signi cant threat to the privacy of its users [26,36]. e individual location data that may be gathered from identifying or linkable transactions is highly sensitive and can be maliciously exploited. To further participation in a voluntary V2G system, privacy guarantees can be just as important as low e ort usability, as concerns arising from loss of personal information as well as any e ort required from the user could discourage its use. Facilitating e ortless payment for EV charging at a public charging spot (EVSE) as well as rewards for ancillary services during the charging session while keeping transactions privacy-preserving, unidentifying, and unlinkable poses a big challenge.
is paper introduces a novel and privacy-preserving V2G payment system called P6V2G. It was developed by adapting the recently proposed cryptographic toll collection system P4TC [32] to a V2G se ing where multiple charging point operators provide publicly accessible EVSEs for EVs. P6V2G facilitates two-way transactions for EV charging, allowing both payment from the user to the operator for having their vehicle charged as well as rewards for providing the EV's ba ery as a bu er to the grid. P6V2G is a postpayment system where a user accumulates debt and rewards on a wallet and gets periodic, e.g., monthly, bills from their e-mobility operator (eMO). erefore, P6V2G o ers convenient low e ort usability, leading more people to make their EV's ba eries available for ancillary services. Our protocols are designed to be e cient even when performed on low performance hardware that is realistically present in EVs, EVSEs and wallets. 1 To further take realistic technology restrictions into account, EVSEs are not required to have permanent online capabilities; tasks can be conducted o ine without loss of any functionality. An integrated reputation scheme records how reliable the user is, e.g., in leaving their EV plugged in as long as they predicted at the start of a charging session. is enables EVSEs to be er plan the charging of vehicles and, e.g., o er cheaper/higher rewarded long term charging to reliable users. To ensure security, P6V2G provides a fraud detection mechanism that not only detects fraudulent behavior and identi es the misbehaving user, but outputs a publicly veri able proof of guilt to avert the possibility of false accusations. With consent of a designated authority, misbehaving users can have their wallets traced (contingency traceability), blacklisted, or their debt recalculated-for instance if the user fails to present their wallet for billing at the end of a billing period. In addition, our system implements a mechanism to blacklist EVs (independently of blacklisted wallets), so that stolen vehicles can be traced or even detained at an EVSE. Since EVs and wallets are modeled as two di erent entities in P6V2G, they may be combined arbitrarily, resulting in a portable system. is is particularly useful for users with multiple cars as well as for renting or sharing EVs. e whole system is formalized in a comprehensive security model and validated by a rigorous proof asserting system security as well as user privacy.

Related Work
In this section we rstly give a summary of di erent payment and reward systems that were proposed for, or can be adapted to a V2G se ing. is overview shows that while all of them have their respective merits, none so far provides solutions for all the challenges and restrictions posed by realistic V2G interactions. In a second part, we give a more detailed introduction of the two cryptographic systems (BBA+ [29] and P4TC [32]) that our own V2G system P6V2G is based on.
Other (V2G) Payment and Reward Systems. ere are several previously published payment and reward systems that can be deployed in a V2G scenario. Reward-only systems (without two-way payments) include TPP [44], and PRAC [43]. Both systems are not able to aggregate rewards. is results in linkability unless rewards are su ciently uniform and redeemed individually. Furthermore both systems require permanent online capabilities and very few properties are proven in any formal way. For the remainder of this paragraph we will focus on payment systems that o er two-way transactions. A terse comparison of the discussed systems, the common options of (Chip-and-PIN) Debit/Credit Card and Paper Cash, and our system is depicted in table 1. In a survey by Han and Xiao [28] another overview of several V2G payment and reward systems, as well as a general summary of challenges and methods associated with privacy in the V2G environment can be found. In 2012, Liu et al. [38] proposed a system designed to provide privacy at the "right" time (PRT), which has been further improved by Au et al. [4]. PRT facilitates two-way transactions between an EV and a single operator running multiple EVSEs. Further parties representing the operator include a grid management and a billing server. User's accounts are pre-paid and have to be topped up regularly. is excludes the possibility of problems arising from users who do not pay their bills (on time) but requires more e ort on the user side and leads to users being stuck at EVSEs if they do not have su cient balance on their account to charge an empty EV. Each EVSE needs a permanent connection to the operator's other parties as PRT is designed as an online system. In particular, all-time access to the central billing server is essential to prevent double-spending. Further assumptions are some read-only memory on the EV that can not be removed from the vehicle. PRT provides traceability that is facilitated by a judge authority and only possible with the user's consent. Via this traceability the system implements lost protection, dispute resolution and tracing of stolen vehicles. While neither [38] nor [4] provide any reputation system, [38] describes the possibility of facilitating a portable mode where the account is managed on some mobile device instead of the EV. is, however, excludes other features like correct tracing and the system still relies on a read-only memory that now has to be available on this mobile device. [4] includes two game-based proofs for cheating prevention and location privacy. Unfortunately these proofs only assert the impossibility of very speci c a acks on the system and do not give any guarantees for a acks that were not explicitly considered.
e International Electrotechnical Commission's V2G standard ISO 15118 [21,22] allows for contract based charging called "Plug & Charge" (PnC). In this system the EV shows a valid contract certi cate from its eMO to the EVSE at the start of a charging session. At the end of each charging session, the EV signs the service detail record (SDR) of this session and sends it to the EVSE. In an online phase, the EVSE sends the SDR to the respective eMO who collects and uses them to bill the contract owner at the end of each billing period. Since the certi cate includes the contract ID, this system is fully identifying. Furthermore-since the system is not portable between EVs-driver speci c billing within EV eets (like car sharing or company eets) is not possible while simultaneously preserving the drivers privacy from the operator of this eet: the corresponding eMO has to provide the eet operator with a detailed account of all the EV's charging sessions so they can match them to speci c drivers.
e PnC system facilitates semi online post-payments and provides blacklisting. Please also note that only minimal security is guaranteed in ISO 15118. While o -the-shelf cryptographic methods like encryption and signatures are employed for EV authentication and to guarantee privacy from eavesdropping but non-involved parties, EVSEs are essentially assumed to be trustworthy and very li le user security is o ered. Furthermore, no resulting privacy or security guarantees are formalized, formally discussed or proven. In addition to the PnC payment method, the ISO 15118 allows for alternative payment methods (like P6V2G) to be added in future. Although the ISO 15118 only deals with direct communication between the EV and SDR-this inherently represents only a small part of our system, namely Part I of Debt Accumulation (cf. gs. 1 and 2)-much of our protocol can be integrated into this standard in an intuitive way. Details of how this might be done can be found in appendix B.
A privacy increasing modi cation of PnC was proposed under the name POPCORN [31]. POPCORN employs anonymous group signatures and three di erent trusted third parties to achieve anonymous one-way payments as long as no parties collude. It does not hide individual transactions from the eMO, is not portable, its proofof-concept implementation is ine cient and no security or privacy proof is given. Some of POPCORN's privacy properties were later veri ed in ProVerif [9] by Fazouane et al. [24], who simultaneously identi ed several weaknesses.
Lastly, we consider the option of anonymous e-cash for V2G payments. One general drawback of e-cash is that it is a prepaid and primarily one-way system. Hence parties need to always have coins of exactly the right amount at hand for any transaction they might want to participate in-which limits either pricing exibility or e ciency. When trying to employ e-cash for two-way payments in a V2G scenario there are several technical roadblocks. In standard o ine e-cash (e.g., [14]), coins are not transferable without consulting the bank. When the user receives e-coins from the EVSE-which could be done by le ing the EVSE participate in the spending protocol as the payer and the user as the payee-they rst need to deposit those coins with the operator who originally issued them. In case this operator and the EVSEs collude they learn all the locations a user got rewards at. We also can not assume that a user receives freshly issued coins directly from the operator as rewards, as the corresponding e-cash withdrawal protocol is not anonymous; only spending a coin protects the privacy of the payer. Hence, the privacy guarantees that standard o ine e-cash provides do not t our needs. Transferable e-cash such as [7] does not achieve our goals either. Transferable e-cash schemes allow to anonymously transfer an e-coin multiple times between parties without consulting the bank. us, in our scenario an EVSE could transfer a coin received from the operator or another user to a user who is eligible for a reward. Unfortunately, there is an impossibility result regarding privacy that applies to this scenario. Canard and Gouget's work [15] implies, that if the parties representing the V2G payment infrastructure collude, payment and reward transactions of a user can be linked. BBA+ and P4TC. At its core, our proposed scheme P6V2G facilitates a black-box accumulator (BBA+) [29].
is building block implements a personal wallet for anonymous, unlinkable point collection and redemption. It ensures that a wallet can only be used by its legitimate owner, protects against manipulation of the wallet's true value, provides double-spending detection and comes with a mix of game-based and simulation-based proofs for user security and privacy as well as system security. Ho mann et al. [32] utilize BBA+ to build a system called P4TC which applies BBA+ to a toll collection scenario and o ers anonymous, unlinkable tolling with post-payments. In order to ful ll all desired properties of a toll collection scenario, the authors augmented BBA+ with additional features like blacklisting, selective tracing of misbehaving users and recalculation of debt in case of a dispute. Moreover, P4TC comes with a full simulation-based security and privacy proof.

Our Contribution
is work transfers, adjusts and expands P4TC to t the V2G scenario. e resulting system P6V2G allows for unlinkable and ecient V2G payments, rewards and reputation scores. It facilitates post-payment two-way transactions in a semi online and portable se ing and includes double-spending detection as well as features for blacklisting (of both EVs and users), recalculation of debt and contingency traceability. To the best of our knowledge it is the rst system o ering all these properties simultaneously and for some properties it is the rst to provide them at all. Furthermore, P6V2G is privacy-preserving and secure against malicious adversaries. is was asserted in a comprehensive formal model and proof within an established cryptographic framework, the Universal-Composability (UC) se ing [16,17]. 2 To achieve the above qualities we build upon the toll collection scheme P4TC [32]. Transferring this to the V2G scenario already provides several of the required functions and properties, e.g., privacy-preserving accumulation of debt, a veri able fraud detection feature and blacklisting for wallets. Some requirements of our system, like two-way payments, are not present in the toll collection scenario where users only have to pay toll and clear their wallet once, but do not collect rewards. Fortunately this important feature is still achieved by the employed black-box accumulator without any further modi cations. ere are, however, several characteristics of our se ing with either much simpler or no equivalent aspects at all in P4TC, which call for novel solutions. First and most challenging among them is the presence of multiple operators instead of just one operating party in P4TC. is introduces considerable complexity as it yields additional potential for security threats in the system which our protocols have to preclude. Similar challenges arise from the user side of the system. Other than in P4TC-where a user is represented by their car's xed on-board unit-our system is designed to be portable. Hence, the user's side is divided into two separate parties: user accounts, containing the users' wallets, and EVs represented by their communication controller. While user accounts have a similar role to on-board units in P4TC, EV communication controllers introduce additional complexity. Among other challenges, they require an additional but likewise privacy-preserving blacklisting mechanism to deal with stolen cars. Furthermore, P4TC does not include any reputation scheme for the reliability of users. While our formal model and proof largely follow the structure of [32], they are more complex due to the existence of arbitrarily many operators (instead of just one in P4TC) and EV communication controllers as entirely new parties.

SYSTEM DEFINITION
is section introduces the general type of V2G system we consider. In addition to the overall se ing this includes details on participating parties, required functions and desired features. An overview can be found in g. 1. We consider a se ing in which multiple charging point operators each provide publicly accessible EVSEs for EVs. Users can charge their EVs at EVSEs as well as o er their EV's ba ery capacity to provide ancillary services to the grid. For these bidirectional services each user gets an accumulated bill from their own eMO at the end of each billing period. We assume that charging point operators and eMOs cooperate in a way that every user may use any of the EVSEs. While the necessary information to manage operator accounting is included in our system, the nancial se lement between operators lies outside the scope of our system.

Parties
We now give a detailed description of the di erent parties and their roles. An operator (OPR) O is either the eMO of an EV, a charging point operator maintaining EVSEs, or possibly both. Each EVSE is represented by their supply equipment communication controller (SECC) C and is assigned to one speci c (charging point) OPR but may be used by any (e-mobility) OPR's customers. It is assumed to have the capabilities for occasional database synchronization with its OPR but does not require any permanent internet connection to other parties. Di erent OPRs are assumed to occasionally synchronize their databases as well in order to catch double-spenders. An EV is represented by its electric vehicle communication controller (EVCC) E. It needs to be registered to be able to participate in the protocols but is not associated with any other party, enabling multiple users to share the same car or one person using several di erent cars. A user account (UA) A is a low performance electronic device (we tend to think of it as a smart card) that is issued to a user upon registration with their OPR. It contains the user's wallet which is used to collect debt and reputation during charging sessions and is not bound to a speci c EV. In addition to these mandatory parties we assume existence of some regulatory dispute resolver (DR) D. is party mainly handles disputes and gives permission for any exceptional measures that either limit a party's access to the system (like being blacklisted) or detract from their privacy (e.g., recalculating the debt on an uncooperative UA). A user is a physical person using an EV, deciding where and when to charge it, owning a UA, picking their eMO and paying the bills. ey do not, however, participate as a separate party in our protocols. e only input needed from a user are the charge targets at the start of a charging session. As we assume this choice to be indicated via the EVSE's human machine interface, it is formally made by the SECC in our protocols. Other than this input the user is represented by a UA and an EVCC for the duration of a charging session.

Functions and Features
e remainder of this section gives an overview of the functions and features we require of a V2G system. In contrast to more cumbersome prepaid and cash options, our aim is a post-payment system where the user is able to charge their vehicle over the course of a billing period and gets a combined bill for all their charging sessions a erwards. Basic functions of a post-payment V2G system include the accumulation of debt on a personal wallet and clearance of this wallet's debt. Both should be conducted in a privacy preserving way, keeping transactions anonymous as well as unlinkable. As an additional feature, we want users to be able to gain (or lose) reputation for, e.g., adhering to their predicted behavior.
is way EVSEs might o er special tari s to reliable users while not trusting the predictions of users who regularly end their charging sessions sooner than promised. All other features of the system deal with fraud and misbehaving users: As explained in section 4.1, not all kinds of fraud can be prevented in the given se ing. But any fraud needs to at least be detected a er the fact. To protect users from false accusations, this fraud detection mechanism has to provide a publicly veri able proof of the user's guilt. To further protect the system from misbehaving users, we require the possibility to blacklist UAs as well as EVs (independently of each other) and a mechanism to recalculate the debt accumulated by an uncooperative UA or lost wallet with the consent of the DR. In extreme circumstances we also want the charging sessions of a UA to become traceable.

PROTOCOL DESCRIPTION
is section describes the main features and protocols of the P6V2G system on a high level. To make these explanations more accessible, we rst give an intuition behind the basic cryptographic building blocks utilized therein. But readers with a cryptographic background may want to skip section 3.1. A er going into detail on how wallets work in section 3.2, section 3.3 gives an overview of the di erent tasks P6V2G is composed of. Lastly, section 3.4 illustrates the e ciency of our system. For the complete protocol we refer the reader to appendix E.

Cryptographic Background
In order to easily understand the following protocol descriptions, familiarity with a few cryptographic primitives is essential.
Public Key Encryption. Encryption enables two parties to exchange messages such that no other party can read them. For public key encryption, the party who wants to receive messages rst has to generate a public key and a secret key. e public key is then distributed to any prospective senders, while the secret key is kept secret. When a sender wants to send a con dential message, they encrypt the message with the public key of the recipient and send the resulting ciphertext instead. e recipient uses their secret key to decrypt the ciphertext and recover the message.
Digital Signatures. A digital signature is a means to verify the authenticity and integrity of a received message. Just like public key encryption, digital signatures use a public key infrastructure where two keys correspond to each party: a secret signing key and a public veri cation key. e sender uses their signing key to sign the message and sends the resulting signature along with the message to the receiver, who veri es the signature using the sender's public veri cation key.

Commitments.
A commitment scheme enables one party to commit themselves to a value towards another (receiving) party. e receiver is sent a commitment, inside which the value itself is safely hidden. At a time of their choosing, the sending party can reveal the value to the receiver by opening the commitment. But the sender can only open the commitment to reveal the value they initially commi ed to and not alter the content in retrospect.
NIZK Proofs. NIZK stands for Non-Interactive Zero-Knowledge. As with any proof, a NIZK proof enables one party (called the prover) to convince a verifying party that a speci c statement is true. e zero-knowledge property asserts that the receiver does not learn why the statement is true, only that it is. In fact, the receiver can infer nothing from the proof except the validity of the claim.
Non-interactive means only one message has to be send from the prover to the veri er-namely the proof itself. No further (back or forth) interaction between the parties is necessary.
Pseudo-Random Functions. A pseudo-random function, intuitively, is a function that is indistinguishable from one with truly random output. At the same time it is e ciently computable for anyone with knowledge of the right input information.
Dynamic Cryptographic Accumulators. e central idea of cryptographic accumulators is the representation of a set of elements in a single accumulation value of xed size. On one hand this accumulation value securely hides the elements within it. On the other hand it must be possible to e ciently prove that a given element is indeed contained in the accumulator. Cryptographic accumulators are called dynamic if elements can e ciently be added to and removed from the set over time.

Wallets
e concepts of wallets and wallet states are central for our P6V2G system. At the beginning of each billing period, the UA and corresponding OPR create a new wallet for the UA. is wallet is used for one billing period and then cleared and exchanged for a new one at the beginning of the next billing period.
A wallet is identi ed by its wallet ID λ and its current status described by a wallet state τ . is wallet state is altered with each transaction. It does not only store the current balance and reputation of the wallet, but rather all information needed to conduct a successful update a er the next charging session. To be more formal, a (simpli ed 3 ) wallet state τ is of the form It consists of an updatable part s b, r x next cert C that changes with each transaction and a xed part λ, a λ , pk O λ that is created once along with the wallet and stays the same for the whole life cycle of this wallet. e components of the updatable part are the last used serial number s, the current balance b and reputation r , the transaction counter x next for the upcoming transaction and the certi cate cert C of the last SECC that updated the wallet (containing the SECC's a ributes and OPR ID). e components that pertain to the xed part are the wallet ID λ, the wallet a ributes a λ and the public key pk O λ of the OPR that issued this wallet. At the beginning of a new billing period each UA A and its OPR O create a new wallet by performing the task Issue Wallet (see section 3.3). e wallet's initial state is e certi cate cert C O and public key pk O correspond to the issuing OPR, who also assigns the initial reputation r (probably choosing the reputation the UA had accumulated on their last wallet) and wallet a ributes a λ (for details about the choice of wallet a ributes see section 4.2). e wallet ID λ and serial number s are jointly computed randomness. Note, however, that λ is only known to the UA and the OPR does not learn it. Each time the user charges their EV, the wallet is updated via the task Debt Accumulation (see section 3.3). Suppose at the beginning of a charging session with an SECC C the wallet's state was en a fresh random serial number s is jointly computed by the UA and SECC and the transaction counter increased by one. Balance and reputation are updated by respectively adding the total cost (price minus rewards) p of the conducted charging and reputation gain d. is forms the new wallet state which the UA saves at the end of the charging process. At the end of each billing period, the wallet is turned over to the UA's OPR for billing purposes. is is handled via the task Debt Clearance (see section 3.3). e OPR learns the nal balance and reputation of the wallet and can use this information to bill the user accordingly. When this task is nished, the UA discards the wallet and initiates the task Issue Wallet again to get a new one.
So far we only described the wallet's state and life cycle, but not how they are used to guarantee several of our system's properties. On one hand, whenever a UA communicates with an SECC to update a wallet, they do not want to be identi ed or disclose the content of their wallet. On the other hand, the SECC has to be assured that the wallet they help updating is actually valid and does not, e.g., contain a balance or a ributes that were illicitly manipulated by the user. is is achieved by utilizing commitments, digital signatures and NIZK proofs. Although the actual process is a li le more complicated, it generally works like this: Instead of disclosing the old wallet state to the SECC, the UA proves the (hidden) state's validity by showing that the xed part was created and signed by its OPR (and could therefore not have been altered since the wallet was issued) and that the updatable part was updated and signed by a properly certi ed SECC. Note that this previous SECC is not identi ed in the process. A er checking these proofs, the SECC provides the UA with the necessary information to update the wallet in exactly the right way and signs the (still hidden) new wallet state so the UA can assure the next SECC of its validity. is way, both privacy and system security can be achieved.

Tasks
is section illustrates the di erent tasks (like registering parties or issuing wallets) our V2G system is composed of. While most of our tasks have similar counterparts in P4TC, some are entirely new (like Certify EVCC and Blacklist EVCC), and some tasks (like Debt Accumulation) contain a core part that is similar to the corresponding task in the toll collection se ing but have been modi ed and extended to encompass the additional requirements of our scenario. Due to space restrictions, we describe the main task of Debt Accumulation in detail but sketch the other tasks on a high level only. Figure 1 depicts an overview of the tasks and the parties involved in them. e only tasks missing in g. 1 are the registration task every party conducts on their own before participating in the system and the task Guilt Veri cation, which can be performed by anyone (even from outside the system) as our double-spending proofs are publicly veri able.
Registration. Before participating in the system, every party has to register. is registration entails the generation of their respective cryptographic keys (used for encryption, digital signatures, etc.).
Certi cation. Each SECC has to get a certi cate from its OPR. Main part of this certi cate are a digital signature on the public key and the a ributes of the SECC. It is renewed each billing period and used to ensure that the SECC is not corrupted. In addition to the actual SECCs, each OPR certi es themselves as an SECC as well. 4 EVCCs have to also be certi ed, but by the DR. e core part of their certi cate is a revocation value rev. is value is drawn randomly and stored by the DR. In case the EV containing the EVCC gets, for example, stolen, the DR adds the corresponding revocation value to a blacklist bl EVCC that each SECC has access to. Apart from the revocation value, the certi cate contains a digital signature from the DR on the EVCC's revocation value, a ributes and public key. Issue Wallet. e task Issue Wallet is executed by a UA and its OPR at the start of each billing period. e UA obtains a new wallet λ, allowing it to take part in the task Debt Accumulation, and the OPR obtains a hidden trapdoor htd λ , allowing the DR to blacklist the wallet and recover its debt if necessary.
Debt Accumulation. e Debt Accumulation task is special in that it requires the interaction of three di erent parties (all other require at most two). An SECC, UA and an EV represented by its EVCC interact to realize the charging process of the EV. Note that the task is only identifying for the SECC while the identities of the UA and EVCC remain hidden from the SECC. Since Debt Accumulation is the main task and in many ways representative of our system, we describe it in some detail. e task can be split into two parts: e rst part, prior to charging the EV, consists of the SECC interacting with the EVCC to determine its authenticity, ba ery characteristics and the user's charging choices. In the second part-reminiscent of P4TC's Debt Accumulation-the SECC and UA facilitate the billing a er charging took place. Overviews of both parts can be found in gs. 2 and 3 respectively. e rst part starts with the SECC sending a list bl EVCC of blacklisted EVCC's revocation values to the participating EVCC. e EVCC computes a NIZK proof that shows its own revocation value is not contained in this list. Additionally, it sends its ba ery's characteristics β, its a ributes a E , and a NIZK proof that these a ributes are correct. e SECC veri es both proofs and selects charge targets 5 based on this information. For bookkeeping purposes and dispute cases, information about the selected targets is sent to the EVCC, which marks the end of the rst part. e second part starts with the SECC authenticating itself to the UA by sending its certi cate cert C . e UA checks this and  calculates the proper next fraud detection ID φ. Fraud detection IDs are similar to a transaction's serial number and essential for the detection of double-spending in the task Double-Spending Detection. ey are computed by applying a pseudo-random function PRF to the UA's wallet ID λ and current transaction counter x, taken from the latest recorded wallet state τ * , i.e., φ := PRF(λ, x). is assures that fraud detection IDs are random and unique if and only if no double-spending is commi ed. e UA sends φ over to the SECC, together with its wallet a ributes a λ and a NIZK proof that the wallet state which all this information was taken from was valid. e SECC veri es that the UA is not blacklisted by checking φ against the UA blacklist bl UA and veri es the NIZK proof. Note that since the UA has to stay anonymous, it can not simply send its wallet state over in the clear. Instead, it proves the wallet state's validity without revealing anything about the state itself. In particular, the so far accumulated debt b * and reputation r * stay secret, as this information could infringe upon the UA's anonymity and privacy. en both parties jointly choose a fresh random serial number s using a Blum coin toss. 6 A double-spending tag t (see task Double-Spending Detection) is jointly computed as well. e SECC then sends all information that the UA needs to correctly update its wallet. is update information includes the price p and reputation gain d. e UA ensures that its new wallet state τ is valid and saves it. e SECC creates two database entries ω bl := (φ, p, d) and ω ds := (φ, t), where ω bl is used again in the task Blacklist UA to recompute the overall debt and reputation of a blacklisted and uncooperative UA and ω ds is used again in the task Double-Spending Detection to convict a UA of double-spending. We assume that each SECC periodically sends these database entries to the corresponding OPRs.
Debt Clearance. e task Debt Clearance is executed between a UA and its OPR at the end of each billing period. It is similar to the interaction of an SECC and a UA in Debt Accumulation. e main di erences are that the UA is not anonymous in Debt Clearance, no new wallet state is created and the OPR learns the balance and reputation accumulated on the UAs wallet. e goal of this task is for both parties to calculate the debt the user owes its OPR, so that they can be billed out-of-band.
Double-Spending Detection. e task Debt Accumulation and Debt Clearance are always conducted with the assumption that the UA presents its most recent wallet and wallet state. Due to the semi online se ing of the SECCs, this can not be enforced during the tasks themselves, but any misbehavior has to be detected a erwards.
is kind of fraud that consists of the UA reusing and old wallet state is called double-spending (see also the paragraph on security in section 4.1). During the Debt Accumulation task, the SECC learns a unique fraud detection ID φ. If an OPR detects two entries ω ds , ω * ds in his database (which the SECCs regularly send their collected data to) featuring the same fraud detection ID φ, doublespending occurred. e OPR can now calculate the identity of the UA by combining the two (otherwise non-identifying) database entries that contain the same fraud detection ID φ, because they will contain di erent double-spending tags t, t * . e output of this algorithm is the identity of the UA along with a proof of guilt π that shows the UA is indeed guilty of double-spending. A er learning the identity of the fraudulent UA, appropriate measures can be taken by the OPR out-of-band.
Guilt Veri cation. Whether a UA is guilty of double-spending can be veri ed using the Guilt Veri cation task. is algorithm may be run by any party. Essentially, the algorithm checks if a proof of guilt π asserts the guilt of a given UA's identity.
Blacklist UA. An OPR and the DR cooperate in the scope of the task Blacklist UA to provide the OPR with the data necessary to blacklist a certain UA. e OPR loads the set HTD λ of hidden trapdoors from its storage and selects the entries htd λ for all wallets of the UA that is to be blacklisted. e DR is the only party able to decrypt the ciphertexts contained in hidden trapdoors and is assumed to only cooperate in blacklisting tasks if the OPR has valid reason (such as proven fraud) to suspend the users privacy.
e DR veri es that the htd λ originate from the UA it wants to be blacklisted to ensure the OPR handed over the correct hidden trapdoors. Using htd λ , the DR can calculate the (as of yet secret) wallet ID λ. Since the UA uses a pseudo-random function PRF to calculate the fraud detection IDs φ from the wallet ID λ in each run of Debt Accumulation, the DR can use its knowledge of λ to precompute all fraud detection IDs the UA might use in the current billing period.
is yields fraud detection IDs {φ 0 , . . . , φ x bl } = {PRF(λ, 0), . . . , PRF(λ, x bl )} for each wallet which are collected in a set Φ A . By adding Φ A to the blacklist bl UA , this wallet is not able to partake in a successful run of Debt Accumulation again. e OPR can use the set Φ A to identify the corresponding entries of his database Ω bl and recompute the current overall debt and reputation of the blacklisted UA.
Blacklist EVCC. With the help from the DR an OPR is able to revoke the access of a speci c EVCC. To this end they run the task Blacklist EVCC. Note that we require our system to be able to blacklist EVCCs independently from any UAs they might conjointly be used with and that the Blacklist UA method-disclosing otherwise unpredictable fraud detection IDs-is not applicable to EVCCs. Hence the design of a separate and di erent mechanism was required to complete our P6V2G system. Using cryptographic accumulators we were able to achieve this in a way that makes adding EVCCs to the existing blacklist very e cient: e OPR sends the EVCCs public key pk E to the DR who assures itself that this EVCC should legitimately be banned from the system. e DR then uses pk E to look up the EVCC's revocation value rev and returns it to the OPR. is value can now be added to the blacklist bl EVCC on which the cryptographic accumulator is computed during Debt Accumulation.

E ciency
To obtain a practical real world system it is paramount protocols perform e ciently under the hardware restrictions of the given se ing. In this section we show this to be the case for P6V2G. Instead of discussing each task of the system in turn, we present the runtime analysis for the task Debt Accumulation in detail. Not only is this by far the computationally most extensive task of our system, but it is (partly) conducted in the presence of a waiting user and therefore time-sensitive. e e ciency of our protocols is heavily determined by the cost of cryptographic operations, i.e., creating commitments, signing messages, computing NIZK proofs and so on. Any other factors only contribute to a negligible fraction of the overall runtime and are therefore not considered in our analysis. e individual cryptographic operations are constructed from atomic operations in the underlying pairing group se ing. More precisely, every cryptographic operation is a combination of G 1 /G 2 exponentiations and pairing evaluations. is enables us to computationally determine a reliable upper bound on the runtime of our protocols: We calculate an upper bound on the number of respective atomic operations performed by each party, measure runtimes of single operations on the type of hardware parties would realistically employ, and combine those values to a ain an overall runtime estimation. Another relevant aspect for the runtimes of our system are precomputations. From the detailed protocol description in appendix E it is apparent that many of the more complicated operations can easily be precomputed before the start of the actual protocol. We therefore distinguish between online and o ine operations: Operations that can be conducted before the start of the actual protocol are denoted as o ine operations. For Part I of Debt Accumulation, these may be performed at any point before the EV is plugged into an SECC; for Part II the parties compute them during the charging process itself, before the user returns to retrieve their car. All operations that depend on inputs of the protocol and can therefore only be computed at the proper time are denoted as online operations. By precomputing as much as possible the online runtime of the actual protocol can be signi cantly shortened and o ine runtimes exibly scheduled to convenient time slots. Table 2 shows the number of atomic operations in the Debt Accumulation task, di erentiated by parties and o ine and online computations.
Here, j := |a λ |, := |a E |, z := |a C | and := |bl EVCC |. For the veri cation of NIZK proofs, we assume batch veri cation techniques from [30] to signi cantly speed up the veri cation process. Also note, that the number of operations needed for verication was generously estimated. erefore, the values in table 2 are upper bounds for the computational costs rather than exact gures.
To get a more tangible measurement of runtimes, we need to make assumptions about the hardware used in a realization of our system. For an EVCC we consider a conventional on-board unit, like the Savari MobiWAVE-1000 [42], to be a realistic choice. We therefore measured the runtime of G 1 /G 2 exponentiations and pairing evaluations on the type of processor present in this onboard unit: An i.MX6 Dual-Core processor running at 800MHz with 1GB DDR3 RAM and 4GB eMMC Flash. e processor runs an embedded Linux and is ARM Cortex-A9 based (32-bit). For the bilinear group se ing, we use the Barreto-Naehrig curves Fp254BNb and Fp254n2BNb [8,34] (with 254-bit order) and the optimal Ate pairing [40]. e resulting benchmarks for single exponentiations in G 1 and G 2 and for pairing evaluations are 6.07 ms, 15.52 ms and 32.19 ms respectively.
For use in SECCs the Sitara AM335x processor-based on an ARM Cortex-A8 (32-bit) running at up to 1GHz-has been suggested [33]. Since this processor has a similar core to the ones of the i.MX6, we use the same benchmarks to estimate runtimes for the SECC. 7 To realize UAs we propose to use either smart phones or a smart card plugged into the EVCC to utilize its computing power. Since the la er yields slower runtimes, we choose this option to obtain an upper bound on the realistic runtime. We therefore use the above benchmarks to calculate the runtimes for the EVCC and SECC, as well as the UA. Combining the gures from Here, j := |a λ | = 4, := |a E | = 1, z := |a C | = 1 and := |bl EVCC | = 50. ese results show that the only time-critical part-the online part of Part II-takes signi cantly less than one second to complete. All other parts do not compel the user to wait for completion and with roughly 2, 6 and 13 seconds they lie well within acceptable timeframes. Although these times are already su cient to not impede a user's experience with our system, we note that they are still upper bounds in several ways: ey were obtained assuming a very naive implementation without any computational optimizations, the number of group operations for proof veri cation was generously overestimated and runtimes were calculated using a single core only, when realistically multiple cores would be available. Hence, we assume real runtimes to be even be er than the gures given in this section.

SECURITY AND PRIVACY
is section discusses the security and privacy properties of our P6V2G protocol. A er reviewing the inherent limitations implied by the underlying scenario, we individually detail the security and privacy properties our protocol was proven to provide. Finally we sketch how the formal proof was conducted.

Inherent Privacy and Security Limitations
To assess the level of security and privacy our protocol provides, we rst discuss which security limitations and privacy losses are inherent in the chosen se ing and what levels of security and privacy an optimal solution might be able to yield.
Privacy. Although ideally we would like OPRs to learn nothing at all, there are things we can not hope to hide from them due to their control over the EVSEs. Information they will always obtain for a charging session are the ID and location of the EVSE, time and duration of charging, charge targets put in by the (anonymous) user, the EV's ba ery properties, and the actual SDR 8 of the session. A privacy-optimal solution would not give away anything more than those parameters.
Security. Some security limitations are imposed by post-payments paired with the semi online se ing of SECCs. Facilitating this in a privacy preserving manner requires users to collect their debt on a wallet instead of trusting the OPR with their information. In this se ing it is always possible for a user to reuse an old wallet state for upcoming charging sessions. Without instant synchronization the participating SECC has no way of knowing the old wallet state has already been used before. is kind of misbehavior is called double-spending and is a widely accepted drawback of semi online payment systems like bitcoin or e-cash-regardless of application. An optimal solution will detect this unavoidable fraud a er the fact, identify the misbehaving user if required, and be able to recalculate the debt missing from the user's wallet. is feature is also required in case a fraudulent user refuses to present their wallet for billing or claims to have lost it, which can not be prevented either. Another inherent limitation is that a maliciously colluding user and SECC are always able to agree on updating the wallet in a way that is not re ective of any charging session that physically took place. Due to this gap between the digital communication captured by our model and the real, physical world, we had to omit the case of collusions between the user side (UA, EVCC) and operator side (OPR, SECC) from our security proof. We suggest mitigating the e ects of corrupted SECCs by adding timestamps to their a ributes so that keys of corrupted SECCs expire. Note also that the corrupt behavior of a colluding user and SECC (or OPR) has no more consequences for the security and privacy of honest users than if only the SECC/OPR were corrupted, which is covered by our proof.

Proven Privacy Properties
A er listing some scenario speci c impossibilities, let us discuss how P6V2G can yield nearly optimal privacy in this se ing. Our proof of user privacy asserts that in addition to the necessary information listed in section 4.1, the only thing SECCs (and therefore OPRs) learn from each charging session are the wallet's, EV's and previous SECC's a ributes as well as the certifying OPRs. Content of these a ributes is a subject of choice in implementation and fully determines the level of privacy provided by the system. While empty a ributes yield complete privacy, it would also be possible to, e.g., include the users/EVs/EVSEs identities in their respective a ributes, and hence implement a fully identifying system. e important point is that this level of privacy is explicit and easy to check upon registration and charging. 9 Realistically, wallet's a ributes might contain the billing period (e.g., month) they are valid for and information on whether the user has a business or private contract with his operator. EV's a ributes might di erentiate between standard cars and busses. An SECC's a ributes should consist of the current billing period only, leaving all honest SECCs with the same a ributes. Simple properties like these yield that any recorded transaction can only be a ributed to a group of k di erent and indistinguishable pairs of UAs/EVs-with k being the number of UAs with the same wallet a ributes and OPR multiplied by the number of EVs of the same type-but not to any speci c user in this group.
Assuming this kind of a ributes we formally prove the following privacy properties, even under participation of malicious OPRs/SECCs or UAs/EVs in the system: on UAs/EVCCs colluding with SECCs/OPRs, see section 4.1). Any corrupted party may maliciously deviate from the protocol instead of just acting in an honest-but-curious manner. Under this kind of corruption we prove the following security properties:

Proven Security Properties
(S1) A UA can only use wallets that were legitimately issued to this UA. (S2) If a UA commits double-spending (see section 4.1), it will be identi ed. (S3) A UA which does not commit double-spending can not lie about or modify the debt or reputation on its wallet. (S4) An OPR is able to blacklist a speci c UA with cooperation from the DR. An SECC will know that a UA is blacklisted before its wallet is used for payment. (S5) An OPR is able to recalculate a speci c UA's debt with cooperation from the DR. (S6) A UA that does not clear its wallet's debt will be detected. (S7) Only registered EVs can take part in Debt Accumulation. (S8) An OPR is able to blacklist speci c EVs with cooperation from the DR. An SECC will know that an EV is blacklisted at the start of a charging session. (S9) No party can lie about or modify their a ributes.

Proof Sketch
We conducted a simulation-based proof following the real/ideal paradigm. For this type of proof the execution of the real world protocol is compared to the execution of an ideal model where all computation is done by an uncorruptible ideal functionality. e idea is for the ideal functionality to be designed in a way that it obviously guarantees the desired security and privacy properties. A proof of indistinguishability of the real world and ideal model yields that the protocol provides these properties as well. e advantage over game-based approaches is that all security properties and restrictions are explicit. However, the traditional notion of simulation-based security only captures security requirements in a standalone se ing, where a single protocol instance runs in isolation. If multiple protocol instances run concurrently, this approach fails to guarantee security. e Universal Composability (UC) framework [16] on the other hand does not only capture parallel execution of multiple protocol instances, but also the use of protocols in an arbitrary context. For our protocol π P6V2G , we prove in the UC {F CRS , G BB }-hybrid model (cp. [18,19]) that it securely realizes the ideal V2G functionality F V2G under common hardness assumptions for cryptographic building blocks. Further information on the ideal functionality is provided in appendix C while additional details of the proof can be found in appendix D.

CONCLUSION AND FUTURE WORK
Based on the cryptographic toll collection framework P4TC [32] we were able to develop the privacy-preserving V2G payment and reputation scheme P6V2G. Our system facilitates two-way transactions between EV users and EVSEs as well as reputation scores. In o ering post-payment functionality-with, e.g., monthly billing-P6V2G is a highly convenient system with low e ort usability. We achieve real world practicality by o ering double-spending detection and guilt veri cation features, contingency traceability (with the consent of a designated authority) as well as blacklisting of EVs and users. All the systems functions are subject to explicit and formally proven privacy and security guarantees. Furthermore SECCs do not require permanent online capabilities, as P6V2G is designed to be operated in a semi online se ing. Our runtime analysis demonstrates the P6V2G protocols to be e cient enough for the low performance hardware that is realistically present in the V2G setting. With EVs and users modeled as two separate entities, the system is fully portable between EVs and hence supports users with multiple cars as well as car sharing between multiple users. Although the P6V2G system is a complete and practical V2G payment scheme, there are several directions where further expansion might prove bene cial. Modelling the EV and the actual charging process in more detail could yield additional features, e.g., an automated pricing check and continuous monitoring of the SECC's charging instructions. Another direction with potential for further development would be the nancial se lement between charging point and e-mobility OPRs. At the moment each SECC needs to learn the user's eMO during a charging session to realistically provide OPRs with the means for nancial se lement between them. Appending P6V2G with a cryptographic protocol for nancial settlement between OPRs could remove the need for this information and thus further improve privacy.

ACKNOWLEDGMENTS
We would like to thank Max Ho mann (Ruhr Universität Bochum) for providing us with benchmarks for single group exponentiations and pairing evaluations. Tables 4 and 5 provide an alphabetically ordered look-up table for  Message content (from party P) µ

A NOTATION
Choice of charging program  In addition to the PnC payment method discussed in section 1.1, the international standard ISO 15118 [21,22] allows for alternative payment methods to be added in future. In this section we will discuss the integration of our P6V2G system into this standard, following its communication structure of functional groups A-H. e elementary use cases needed for P6V2G within those functional groups follow the examples of use cases de ned for a similar purpose in the post-payment method PnC.
As ISO 15118 only deals with communication between EVCC and SECC, the only part of our system it inherently applies to is Debt Accumulation Part I-which would naturally be implemented as an elementary use case of functional group D "Identi cation, Authentication and Authorisation". It is, however, possible to integrate the complete tasks of Certify EVCC, Issue Wallet, Debt Accumulation and Debt Clearance into the ISO 15118 in an intuitive way. Note that apart from EVCCs and SECCs, these tasks are conducted with participation of the DR, OPRs and UAs, so there is a party mismatch to be considered. Certify EVCC. is task is executed by the EVCC and DR to obtain a certi cate containing vehicle a ributes and a revocation value for blacklisting. It is conducted only once and has to take place prior to the rst charging session that is to be payed for with a P6V2G contract. We therefore propose this to be done at the original equipment manufacturer (OEM), who should be in direct contact with the DR to have all their vehicles certi ed. In this case it would behave like the bootstrap or OEM provisioning certicate, but without the need to be replaced by a contract certi cate later on. Alternatively-to remove the need for trusting the OEM with anything more than provisioning certi cation-we propose to conduct the protocol for this task within an elementary use case C3 "EVCC Certi cate Installation" in functional group C "Certicate Handling", resembling the current example of C2 "Certi cate Installation".
is elementary use case C3 would only apply to the situation where the EVCC has not been certi ed before and is connected to an SECC controlled by the DR. Debt Accumulation. is task is the most complicated to integrate into ISO 15118, because parts of it are conducted prior to and other parts a er charging. Our system's portability, with UAs separated from EVCCs, further complicates the ma er. While ISO 15118 provides the possibility for external identi cation methods like our UA in functional group D "Identi cation, Authentication and Authorisation", it does not allow for keeping this identi cation method physically xed to interact with again a er charging. By plugging the UA (as a smart card) directly into the EVCC, however, and having the EVCC relay (encrypted) messages between SECC and UA, this shortcoming could be bypassed without loosing portability of our system. Hence the UA could be construed as part of the EVCC for the duration of the charging session. For Part I of the Debt Accumulation protocol (communication between EVCC and SECC), we propose an elementary use case D5 "Authorization of EVCC performed at the EVSE" in functional group D "Identi cation, Authentication and Authorisation" following the example of D1 "Authorization using Contract Certi cates performed at the EVSE". Part II of the Debt Accumulation protocol (communication between UA and SECC) needs to be split up between two functional groups: Authorization of the UA 10 should be conducted within an elementary use case D6 "Authorization of UA performed at the EVSE", again resembling D1. e remainder of the protocol would then form an elementary use case G3 "Wallet Update" within functional group G "Value-added Services" resembling the elementary use case G2 "Charging Details" which is used for creating the SDR for PnC.
Issue Wallet and Debt Clearance. In addition to an external method (e.g., direct communication between the UA smart card and the user's eMO via an NFC reader at the users home computer), the tasks Issue Wallet and Debt Clearance could be conducted in the scope of a charging session. 11 Even though they are more complicated and provide more functionality, wallets in P6V2G ful ll a similar role to contract certi cates in PnC. We therefore propose to realize the Issue Wallet and Debt Clearance protocols as use cases C4 "Issue Wallet" and C5 "Debt Clearance" within functional group C "Certi cate Handling"-resembling the use case C1 "Certi cate Update" for PnC. C4 and C5 should be conducted automatically within the rst charging session of a new billing period.

C IDEAL FUNCTIONALITY
For a simulation-based proof following the real/ideal paradigm we need an ideal model to compare our protocol to. is type of ideal model comes in the form an ideal functionality F , which can be thought of as an imaginary trusted third party incorruptibly performing all functions we desire in the given scenario. If a protocol π is proven to be indistinguishable from the ideal functionality F , it necessarily yields the same properties and guarantees. Before explaining the extensive and more complicated ideal V2G payment and reputation functionality F V2G , we want to illustrate the workings of an ideal functionality with a small example.
Example. Imagine a scenario where two mutually distrusting parties P 1 and P 2 want to jointly compute the result of a function f . Each party P i is allowed to choose a part x i of the input that f is supposed to be evaluated on. While both parties want to learn the output f (x 1 , x 2 ) and be sure that what they learn is actually the correct result (security), neither wants the other to learn anything more about their respective input than the result itself discloses (privacy). e ideal functionality F f in this context would know the function f , get the inputs x 1 and x 2 from P 1 and P 2 respectively, compute f (x 1 , x 2 ), and send this result back to both parties.
F f guarantees security since it is uncorruptible and f is xed within its description. No party can in uence the computation of the result f (x 1 , x 2 ) in any other way than by choosing their own input. Due to its outputs, F f also yields obvious privacy. All any party learns in an execution of F f is the result f (x 1 , x 2 ) as there are no other outputs the ideal functionality makes (note that in the ideal model no party can read, intercept or otherwise meddle with message between the ideal functionality and another party).
In particular, no further information about the other parties input is obtained. is example illustrates three main ways an ideal functionality is able to yield security and privacy guarantees: Firstly, any information that is needed, but that no party should be able to choose, lie about or unduly in uence (e.g., the function f ) is stored within the ideal functionality. Secondly, All computations are correctly performed by the ideal functionality, not by any party. And thirdly, the ideal functionality only outputs information to a party that this speci c party is supposed to learn and nothing else.
In the rest of this section we illustrate how the above principles can be applied to get an ideal functionality F V2G for the scenario described in section 2.
We divide the description of F V2G up into two parts. e rst part consists of the state of the ideal functionality (containing all information parties should not be able to lie about), the second details its behavior in all the di erent tasks of a V2G payment system. An overview can be found in g. 4 and we will explain both in more detail below.
Functionality F V2G I. State e ideal functionality F V2G records: • (Partial) Mapping a that maps a parties ID a id P to their respective a ributes a P . • (Partial) Mapping O that maps a UA's or SECC's ID id P to their respective OPR's public key O P . • (Partial) Mapping f rev that maps an EVCCs ID id E to a revocation value. • Transaction database TRDB = {trdb} with entries trdb = (s prev , s, φ, x, λ, id A , id C , b, r, p, d).
• (Partial) Mapping f Φ that maps a wallet ID λ and a counter x to a fraud detection ID φ. • (Partial) Mapping f Π that maps a proof π to a UAs ID id A . a For UAs, potentially di erent a ributes are assigned to each wallet rather than the UA.

C.1 State
To assure the right information (e.g., a parties' a ributes or previous amount of debt) is used in computations, the ideal functionality F V2G stores everything parties should not be able to freely choose or lie about during the tasks of this system. It keeps track of all conducted charging sessions by maintaining a comprehensive database TRDB and several (partial) mappings for parties' a ributes, OPRs, revocation values, fraud detection IDs and double-spending proofs (cp. g. 4). is global state is used and amended when conducting individual tasks with participating parties.
Information on all conducted charging sessions is kept in the database TRDB. Its entries trdb = (s prev , s, φ, x, λ, id A , id C , b, r , p, d) are uniquely identi ed by a serial number s. Another serial number s prev links back to the logically previous charging session that was payed for with the same wallet. Each database entry contains all information pertinent to one charging session. It notes the identities id A and id C of participating parties as well as the wallet ID λ. Balance b and reputation r give the state of the wallet λ a er charging, price p and reputation gain d indicate by how much these values changed during this charging session. e counter x indicates the number of charging sessions conducted to arrive at the current state of the wallet. Lastly trdb contains a fraud detection ID φ which is a random number assigned to each pair (λ, x) of wallet ID and counter and is used to detect double spending by misbehaving users. is value is (slightly redundantly) stored in the mapping f Φ as well: For every entry trdb with values λ, x and φ the equation φ = f Φ (λ, x) holds.
In addition to this basic information, F V2G keeps track of some information that is only relevant to feature tasks: e mapping f Π stores proofs π that indicate double spending by a UA id A = f Π (π ) has been detected. e mapping f rev stores a revocation value for every registered EVCC that can be used to blacklist this car, e.g., because is was reported stolen.

C.2 Behavior
An overview of the tasks provided by our system was given in section 3. e ideal functionality F V2G o ers the same tasks with the same interfaces (otherwise the protocols could not be indistinguishable from the ideal world): A number of setup tasks, three basic tasks (Issue Wallet, Debt Accumulation and Debt Clearance), and four additional feature tasks. In this section we explain the ideal version of them by mostly summarizing what F V2G does, but to be er illustrate the inner workings of the ideal functionality, the central task of Debt Accumulation is shown in more detail.
Setup Tasks. Setup tasks include registration and certi cation of parties. Upon registration, the ideal functionality checks a party has not been registered before and supplies it with the necessary keys to participate in the system. Registered EVCCs and SECCs have to be certi ed as well. Certi cation of an EVCC by the DR entails a check if this EVCC has already been certi ed or even blacklisted before and otherwise assigns a revocation value to the EVCCs ID to enable blacklisting in the future. Each SECC is certi ed by the OPR maintaining it to provide it with the credentials necessary to participate in charging sessions and update balance and reputation of wallets in the name of this OPR.
Issue Wallet. In the task Issue Wallet F V2G creates a new wallet for a UA and OPR. It checks the UA against the OPRs whitelist and initializes a new wallet λ with an entry trdb = (⊥, s, φ, x, λ, id A , id O , 0, r , 0, r ).
e mappings a and f Φ are appended as well. A ributes and initial reputation are provided by the OPR. e OPR only receives the serial number s as output, the UA obtains its new wallets a ributes and reputation and the OPR's ID as well.
Debt Accumulation. e ideal functionality's behavior during the Debt Accumulation task can be found in g. 5. 12 Again, F V2G checks blacklisting and looks up the EVCC's a ributes before facilitating the exchange of the EV's ba ery a ributes β and the charging choice µ between the SECC and EVCC. In the second part, F V2G looks up the transaction trdb prev corresponding to the wallet state s prev that the UA indicates they want to continue from. 13 It correctly computes s, φ, x, b, and r for the new transaction entry which is inserted into TRDB. Price p and reputation gain d are provided by the SECC.
As output the SECC receives the transactions serial number s, fraud detection ID φ and the a ributes and OPR IDs of the wallet and the previous SECC. e UA on the other hand learns the serial number s, its wallet's current balance b and reputation r as well as the price p and reputation gain d of this charging session.
Debt Clearance. e Debt Clearance task in the ideal model works very much like the second part of Debt Accumulation. Di erences are that the price of the new transaction entry is set to p = −b bill and there is no reputation gain. e OPR additionally learns the UA's ID and the nal balance b bill and reputation r bill of the cleared wallet. e UA in turn only learns this balance and reputation, but does not get any further information. is ensures the UA can not use it's wallet again (without commi ing double-spending) a er it has been cleared.
Feature Tasks. e most important feature task is Double-Spending Detection. On request of an OPR the ideal functionality checks its database TRDB for double-spending, i.e., for two separate entries with the fraud detection ID φ. If such entries exist, the corresponding UAs ID and a proof of its guilt are appended to f Π as well as output to the OPR. If any party wants to check the validity of such a proof, they can do so by means of the task Guilt Veri cation. On input (id A , π ) the ideal functionality checks if it previously recorded f Π (π ) = id A and returns the result. e other two feature tasks pertain to blacklisting and are joint tasks of an OPR and the DR. In both cases the DR only has to give its permission while the OPR has to supply the ID of the party that is supposed to be blacklisted. For EVCCs the ideal functionality returns its recorded revocation value, for UAs all used and upcoming fraud detection IDs are returned as well as the current balance and reputation of the UAs wallet. is information can then be added to the respective blacklists as well as being used for billing the UA in question. 12 Please note that for ease of presentation, some special behavior in case of various corruption cases has been omi ed from this gure. 13 Cp. double-spending in section 4.1. Without the o ine se ing, it would be su cient to look up the last transaction of the UA's wallet.
Functionality F V2G II. Behavior -Task Debt Accumulation 2. Upon receiving (bl UA , bl EVCC ) from C: -Leak bl EVCC to the adversary. 5. Upon receiving (β ) from E: -If f rev (id E ) ∈ bl EVCC , Output blacklisted to both parties and abort. -Look up the EVCCs a ributes a E .

Upon receiving (OK) from E:
-Look up the SECC's a ributes a C and OPR id O C . 13. Upon receiving (s prev ) from A: -Select entry from the database TRDB.
Output blacklisted to both parties and abort. -Look up the wallet's a ributes a λ and OPR id O λ .
-Look up the previous SECC's a ributes a C prev and OPR id O C prev . 16. Upon receiving (p, d ) from C: to TRDB.
C A E

D PROOF
Following the example of [32], we conducted our proof in three di erent stages. Firstly, the database maintained by the ideal functionality is construed as a transaction graph and several structural properties of this graph are shown. Secondly, for each corruption case a simulator is constructed with which we can, thirdly, prove indistinguishability of executions of the real protocol and ideal functionality.

D.1 Transaction Graphs
e database TRDB maintained by the ideal functionality F V2G can be visualized as a directed graph. We call this graph the ideal transaction graph of the system. Each node in the graph corresponds to the state of the participating wallet a er a transaction. erefore nodes are labeled with the tuple containing all information relevant to the wallet's state. e serial number s serves as a unique identi er of the node, so we o en think of the nodes being the set of all serial numbers with the other information a ached to it. e directed edges (s prev , s) of the Ideal Transaction Graph describe the link between a wallet's state before and a er a single transaction. Hence edges correspond to transactions themselves and, are labeled with the information (id C , p, d). An example for an ideal transaction graph can be seen in g. 6; node s 2 and s 3 illustrate what happens if double-spending occurs.

P . A directed graph is a forest if and only
if it is cyclefree and every node has in-degree at most one. We prove these properties by induction. On initialization of the system the graph is empty and the statement trivially satis ed. Now consider how each task modi es the graph. Tasks that insert a new entry into TRDB create a new node. e only tasks to do so are Issue Wallet, Debt Accumulation and Debt Clearance. Assuming that TRDB is a forest before inserting a new node, we can assert that TRDB is still a forest a erwards by looking at these tasks in detail. Issue Wallet adds an entry trdb = (⊥, s, . . .) to TRDB and hence adds a node s but no new edge. Note that s is indeed a new node as it is chosen from the set of idle serial numbers. erefore s is the root of a new tree and TRDB is still a forest. Debt Accumulation and Debt Clearance insert a new entry trdb = (s prev , s, . . .) each. Again s is chosen from the set of idle serial numbers and hence a new node in our graph. e only edge inserted is (s prev , s) which gives s in-degree one, does not change the in-degree of any other node and can not close a cycle as s has no outgoing edges yet. Hence TRDB remains a forest. Every other task only queries the ideal transaction graph, but does not change it.
ere are several other statements we prove about the ideal transaction graph. At this point we will only list them and omit the proofs.
L D.2. (1) On each tree of TRDB, the UA id A is constant. (2) ere is a one-to-one and onto correspondence between trees in TRDB and wallets.
(4) Let s be a node in TRDB with counter x a ached to it. en s has depth x with respect to its tree in TRDB. (5) Every node with the same depth in the same tree of TRDB has the same fraud detection ID φ. Conversely, nodes with the same fraud detection ID are in the same tree and have the same depth.
In a next step, we add in and out commitments, decommitments and commitment contents from the real protocols to each node in the ideal transaction graph. ese commitments are from the xed and updateable part of the wallet state before and a er the transaction that created this wallet state (cp. section 3). is information gives a second set of edges where two nodes s * and s are connected if and only if the outinformation of s * matches the in-information of s: We call the resulting graph the augmented transaction graph (cp. g. 7). L D.3. e graph structures of the ideal and the augmented transaction graph coincide with overwhelming probability.

D.2 Simulator
In this section we rst explain the function of a simulator in the ideal/real paradigm, before showing the simulator for the task of

Figure 7: Entry of an Augmented Transaction Graph
Debt Accumulation with corrupted OPRside as an example of the simulators in our proof. e general idea of a simulator is that it functions as the ideal world counterpart of a malicious real world adversary. We show that for every real world adversary a acking the real protocol, there exists a simulator in the ideal world achieving the same things in an execution of the ideal model. But since the ideal model is trivially secure and privacy preserving, the simulator can not gain any advantage and so neither can a real world adversary. "Achieving the same things" in this case means that an outside party can not distinguish between a protocol execution in the real world with the real adversary and the ideal model with the simulator, not even if it may choose parties inputs and learns their outputs. is rather complicated setup is simpli ed by combining the real world adversary and the distinguishing outside party to form one entity, the so-called environment Z . 14 is environment controls all corrupted parties completely-including malicious deviations from the protocol-and chooses inputs for all honest parties as well as learning their outputs. Now either all parties run an instance of the real world protocol π P6V2G (see g. 8), or all honest parties participate in the ideal model and the simulator has to provide the interface between the ideal functionality F V2G expecting inputs from the corrupted parties and the corrupted parties who still run the real protocol and expect protocol messages from the honest parties in return (see g. 9). Now the protocol π P6V2G securely realizes the ideal functionality F V2G , if we can construct a simulator S in such a way that the environment Z can not distinguish between the two cases, i.e., between the real world and the ideal model in gs. 8 and 9 respectively.
To do this we need to de ne a separate simulator for every corruption case and their behavior in each of our systems tasks. As an example we take a closer look at the simulator for user security and privacy performing the task Debt Accumulation (see g. 10). In this case, the participating EVCC and UA are honest, while the SECC may be corrupted. erefore the simulator S has to provide a SECC's input to the ideal functionality F V2G and protocol messages the SECC expects from an EVCC and UA running the real protocol π P6V2G . To achieve this, it utilizes the SECC's output it gets from the ideal functionality, the real protocol messages the SECC sends to the EVCC and UA as well as its ability to, e.g., extract commitments or simulate proofs with the trapdoor td it knows from choosing the CRS.
14 Note that this simpli cation gives the adversary more power and therefore only strengthens our security and privacy statement. P · · · P P · · · P π P6V2G Z Figure 8: Real World P · · · P P · · · P F V2G S Z Figure 9: Ideal Model

D.3 Indistinguishability
As a last step we have to prove that the environment's views in the real world and ideal model (cp. gs. 8 and 9) are actually indistinguishable. is is done by de ning a series of hybrids between those two worlds. e rst hybrid H 0 is equal to executing the real protocol while the last hybrid H max equals an execution of the ideal model. Each hybrid is of the form where π i and S i are incremental modi cations of π i−1 and S i−1 respectively. While π 0 = π P6V2G is our real world protocol, the last version π max equals the ideal functionality F V2G . e simulator progresses in the other direction with S max = S being the original simulator de ned in appendix D.2 and S 0 being a dummy simulator

Simulator S Task Debt Accumulation
If the SECC is honest, do nothing, else do: • Load the recorded pk sig D , pk acc D for id D . • Upon receiving (bl EVCC ) from Z in the name of C: -Call F V2G in the name of C with input (∅, bl EVCC ).
-Output (β, a E , c rev , π 1 , π 2 ) to Z as message from E to C. • Upon receiving (µ) from Z in the name of C: -Output (OK) to Z as message from E to C.
-Call F V2G in the name of C with input (µ, pk cert O C ). - .
-Call F V2G in the name of C with input (p, d ). Figure 10: User Security Simulator for Debt Accumulation that does nothing but relay all messages. Instead of proving indistinguishability between the real protocol and ideal model in one go, it is now possible to do this stepwise by proving indistinguishability between each pair of consecutive hybrids.
As an example lets look at one of the hybrid hops in our proof of user security. e incremental di erence between the hybrids H 9 and H 10 in this case is the following: H 10 modi es the task DebtAccumulation. S 10 replaces c C in the message to the SECC (cp. g. 32) by a commitment containing only zeros. Everything else remains the same. e proof of indistinguishability between the hybrids H 9 and H 10 is a reduction to the cryptographic properties of the commitment scheme used for c C and its underlying hardness assumption; assuming we had an environment Z that could distinguish between H 9 and H 10 , we construct an adversary who would be able to e ectively violate the hiding property of the commitment scheme.

E P6V2G PROTOCOL
is section contains our concrete instantiation and complete protocol π P6V2G . Firstly, we show how the abstractly used cryptographic building blocks (e.g., encryption and commitments) may be instantiated to implement our system. Secondly, our protocol π P6V2G is given.

E.1 Instantiation
Our P6V2G protocol π P6V2G uses cryptographic primitives like commitments and digital signatures in an abstract fashion. Our security proofs state what properties they need to have, but another requirement is only stated implicitly. e languages for which NIZK proofs are generated contain statements about primitives. erefore these statements need to be compatible with the NIZK proof system that is used. In the following paragraphs we provide an example for an instantiation of the protocol π P6V2G . e security of the instantiations relies on the SXDH assumption [27], the q-strong DH assumption [5] and the n-DDHI assumption [10].
NIZK Proof System. e proof systems P1, P2, P31, P32, P4 and P5 can be instantiated with the SXDH-based variant of the Groth-Sahai (GS) proof system [27]. It is de ned for languages L gp that contain statements described by the conjunction of pairing-product equations, multi-scalar equations over G 1 , multi-scalar equations over G 2 and quadratic equations over Z q . e GS proof system is perfectly complete, perfectly sound and F gp -extractable for the language F gp that maps group elements to group elements and elements x ∈ Z q to g x i . Moreover, it is known to be composable zero-knowledge under certain restrictions. ese are met by the language considered in the protocol. e language L (1) of P1 contains range proofs to show that ey can be implemented using the signature-based technique of Camenisch and Chabounni [12].
Commitment Schemes. Two di erent commitment schemes are used throughout our protocol. e shrinking l-message-commitment scheme from Abe et al. [3] with message space Z l q , commitment space G 2 and opening value space G 1 is correct, statistically hiding, additively homomorphic, equivocal and F gp -Binding for under the SXDH-assumption. It has to be F gp -binding, because statements about commitments from this scheme are proven and the GS proof system is only F gp -extractable. We use instantiations of this scheme for C1, C2, C3 and C6 with l equal to two, ve, two and one respectively. e extractable commitment scheme introduced by Groth and Sahai [27] has message space G 1 commitment space G 2 1 and opening value space Z 2 q . It is correct, hiding, equivocal, extractable and binding under the SXDH assumption. We use this to instantiate C4.
Cryptographic Accumulator. We instantiate the cryptographic accumulator with a construction that has originally been proposed by Nguyen [41] for symmetric pairings. It can accumulate up to k ACC elements, with k ACC being a public, pre-determined system parameter. Au et al. [6] extended this construction with proofs of non-memberships and Lin and Hopper [37] adopted it to asymmetric pairings. Security holds under the q-SDH assumption. e accumulator is sound for any choice k ACC ≤ q. e space of accumulatable elements is Z q \ {−sk acc } with sk acc ∈ Z q denoting the accumulator's trapdoor. e value space of the accumulator equals G 1 .
Pseudo-Random Function. e PRF used to generate the fraud detection IDs can be instantiated with the PRF introduced by Dodis and Yampolsky [23]. It is an algebraic, group-based construction and allows to prove that the function was evaluated correctly. is function, de ned by with key λ ∈ Z q , is secure for inputs x ∈ {0, . . . , n} ⊂ Z q under the n-DDHI assumption.
Asymmetric Encryption. e protocol uses an adopted variant of the structure-preserving, IND-CCA secure encryption scheme by Camenish et al. [13]. e original encryption scheme is formalized for a symmetric Type-1 pairing, but we need a scheme that is secure in the asymmetric Type-3 case. For the conversion we followed a transformation procedure as proposed by Abe et al. [2] with some additional, manual optimizations. e transformed scheme can encrypt vectors in G 1 and is secure under the DLIN assumption.
e scheme is used as E in the task Issue Wallet to encrypt the hidden trapdoor of the wallet. Some explanations are in order on this choice. Ideally, one would want to encrypt the wallet ID λ ∈ Z q in order to enable blacklisting. Moreover, the wallet must prove to the OPRthat it honestly encrypted the correct wallet ID. For practical reasons the Groth-Sahai NIZK is used (see g. 39). erefore an encryption scheme with message space Z q that is compatible with the Groth-Sahai NIZK-scheme is required. As we are not aware of such a scheme, the encryption scheme with message space G 1 is used instead. But if the wallet would only encrypt g λ 1 , the DR would not be able to recover λ from the decryption of e, because the CDH-assumption holds in G 1 . To get around this obstacle, the wallet picks its own share of the seed λ by randomly picking a "digit representation" λ i in the base-base system: If base is chosen in a way that it is e ciently possible to compute the discrete logarithm for the elements λ i < base, it is possible to recover λ (see g. 36). e wallet encrypts all λ i chunks, the OPR's share λ and its own public key pk id A inside a single vector. As the OPR's share λ is known to the OPRanyway, it can additionally be stored in the clear alongside the encryption and thus does not need to be split into chunks. Nonetheless, it is still required that the OPR's share λ is part of the encryption such that none of the components of the wallet ID is malleable. Otherwise an malicious OPRcould try to evaluate the PRF at ineligible points and thus blacklist a di erent (innocent) user. For the same reason, the wallet's public key must be bound to the encryption.

E.2 Full Protocol
Finally, we include our complete P6V2G protocol π P6V2G in this section. An overview of each party's locally saved state as well as all tasks supported by the system can be found in g. 11. For readability purposes most tasks are then given in two parts: a wrapper and a core protocol. In the wrapper protocol the participating parties mainly load and save internally stored information needed for the current task. All interaction between parties is conducted in the core protocol which is invoked by the wrapper. Lastly, if a protocol includes a NIZK proof, the corresponding language (i.e., properties this proof asserts) is given at the very end.
UC-Protocol π P6V2G I. Local State e DR D internally records: • Its public and private key (sk D , pk D ).
• A mapping pk E → (a E , rev).

An OPR O internally records:
• Its public and private key (sk O , pk O ). • A self-signed certi cate cert C O .
• A mapping pk C → a C .
• A set HTD λ of hidden trapdoors for wallets.
• Sets Ω bl and Ω ds containing blacklisting information and doublespending detection information.
A SECC C internally records: • Its public and private key (sk C , pk C ).
• Its certi cate cert C validated by an OPR.
• Sets Ω bl and Ω ds containing blacklisting information and doublespending detection information.
An EVCC E internally records: • Its public and private key (sk E , pk E ).
• Its certi cate cert E validated by the DR.
A UA A internally records: • Its public and private key (pk id A , sk id A ). • A set {τ } of all its recorded tokens.
Party output: (pk P ) Figure 12: Protocol for Task Register Party UC-Protocol π P6V2G -Task Certify SECC SECC input: (certify) OPR input: (certify, a C ) (1) For the SECC side: • Load the internally recorded pk sig C . • Retrieve pk cert O from G BB for ID id O . (2) For the OPR side: • Load the internally recorded (pk cert O , sk cert O ). • Retrieve pk sig C from G BB for ID id C .
• Check that no mapping pk sig C → a * C has been registered before, else ouput ⊥ and abort.
(3) Run CertifySECC (see g. 27) for the SECC and the OPR: 4) For the SECC side: • Record cert C internally.
For the OPR side: • Record pk sig C → a C internally. (1) For the EVCC side: • Load the internally recorded (pk id E , sk id E ). • Retrieve pk sig D from G BB for ID id D .
(2) For the DR side: • Load the internally recorded (pk sig D , sk sig D ). • Check that no mapping pk id E → (a E , rev ) has been registered before, else ouput ⊥ and abort.
(3) Run CertifyEVCC (see g. 28) for the EVCC and the DR:  (1) For the UA side: • Load the internally recorded (pk id A , sk id A ). • Retrieve pk enc D from G BB for ID id D .
(2) For the OPR side: • Load the internally recorded sk   (1) For the UA side: • Load the internally recorded (pk id A , sk id A ). • Load the internally recorded τ prev for s prev .
• Retrieve pk sig D , pk acc D from G BB for ID id D . (3) Run CheckEVCC (see g. 31) for the EVCC and SECC: For the SECC side: • Conduct charging.
• Determine p and d .
• Load the internally recorded (pk C , sk C ).
• Load the internally recorded cert C . (5) For the UA side: • Load the internally recorded (pk id A , sk id A ). • Load the internally recorded τ prev for s prev . (4) Run DebtAccum (see g. 32) for SECC and UA: For the SECC side: • Record ω bl and ω ds internally.
• Retrieve id O λ from G BB for public key pk sig O λ . (7) For the UA side: • If VerifyWallet(pk id A , τ ) (see g. 35) returns NOK, output ⊥ and abort.
(2) For the OPR side: • Load internally recorded set HTD λ and set HTD A (3) Run BlacklistUA (see g. 36) for OPR and DR: For the OPR side: • Load the internally recorded set Ω bl .
• Let Ω A bl be the subset of blacklist database entries (φ, p, d ) ∈ Ω bl with fraud detection ID φ ∈ Φ A . (1) For the DR side: • Load the mapping {pk id E * } → ({a E * } × {rev }) and call it f rev .