Parking Tickets for Privacy-Preserving Pay-by-Phone Parking

Traditionally, the payment required for parking in regulated areas has been made through parking meters. In the last years, several applications which allow to perform these payments using a mobile device have appeared. In this paper we propose a privacy-preserving pay-by-phone parking system offering the same privacy as the traditional paper-based method even assuming an internal attacker with full access to all the information managed by the system servers. Drivers'privacy is preserved without requiring them to trust any party. Furthermore, the system can tolerate that the mobile devices of drivers fall out of coverage while their cars are parked.


INTRODUCTION
In the late 1920s, Roger W. Babson filed several parking meter patents [6]. In most proposals, after inserting coins into a pay station, a paper ticket to be placed on the dashboard of the car is issued.
The massive deployment of smart devices has facilitated the development of applications allowing such payments to be performed through the mobile phone [1][2][3][4]. Upon parking, the driver simply has to log into the mobile app and indicate the car license plate Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request  number, the area of the city she has parked in, and the expected duration. The amount to pay is then deducted from a pre-paid balance, or charged directly on driver's credit card.
Parking enforcement officers check the parking status of a car by typing its plate number in a mobile device which indicates whether a payment is in effect or not. This requires the presence of an online server, accessible from officers'devices, with access to the data allowing to determine the payment status of cars. This data is highly sensitive since it allows to infer private information about drivers like their work schedules, hobbies, or even health problems. To avoid unnecessary risks, the only information that should be managed by the system is that allowing a parking officer to check if an appropriate payment for a given parked car has been made or not.
Privacy is a key aspect in the design of secure systems and protocols involving the mobility of people and vehicles. That is the case for electronic transport tickets [11], pseudonym management in vehicular networks [14], management of parking space [10,16], or vehicle location proof systems [17].
To avoid security breaches from inside the service provider, payby-phone parking systems should be designed by considering it a party which might try to infer information about drivers' parking habits. This excludes checking the payment status of a car just from its plate number. In that case the service provider could simply query the system periodically with a targeted plate number and get accurate information about the time periods that the traced car has been parked. Hence, the payment status of a car has to be determinable only from one-time pseudonyms which can only be obtained by a parking officer located close to the car 1 . This forces the need to include some kind of on-board device providing one-time pseudonyms when requested by a parking officer [9,13].

Related Work
Nowadays there exist several pay-by-phone parking systems [1-4], but none of them addresses the privacy of drivers. These applications collect and store accurate data about each parking operation so that the generation of reports about parking habits can be done in a straightforward manner.
Recent research works [9,13] have proposed systems that consider the privacy of drivers. Both proposals share a similar system model. Pre-paid e-coins are used for anonymous payments. In addition, an RFID-enabled device is to be placed in cars and queried by parking officers when checking the parking status of cars.
In [13], when a driver parks her car, an anonymous e-coin payment for the expected parking duration is made. That payment is linked to a random identifier which is stored in the on-board RFID device. When a parking officer checks a car, he queries its on-board device to get the random identifier which is then sent to the system server to determine whether a payment linked to it has been done. At that time, the officer can link the car license plate number to the current identifier, and from the data stored at the system servers, that identifier can be linked to the start and end times of the parking operation. Hence, the exact start and end times of the parking operation of that car are determined.
The proposal in [9] provides better privacy: the parking officer, when checking the parking status of a car, only obtains a boolean indicating whether a payment for the checked car is in effect or not. That proposal performs periodic micropayments for short-time intervals while the car is parked. A payment can only be linked to a plate number after querying the on-board device. In that case, the car can only be linked to the payment performed for the current short-time interval so that the start and end times keep secret.
The system proposed in [9] is currently the most complete privacy-preserving pay-by-phone parking system. Unfortunately, if the driver's mobile device could not perform some of the micropayments due to a lack of coverage, low battery or any other cause, the driver could be fined. Our proposal provides all the features of [9] and, additionaly, solves the mentioned drawback.

Contribution and Plan of this Paper
We propose a privacy-preserving pay-by-phone parking system in which, like in [9], payments are performed for short-duration time slots using pre-paid e-coins. In our proposal, a payment for each of the time slots composing the expected parking time is done at the beginning of the parking operation, eliminating the need to be connected all the time. Unused parking tickets can be revoked so that the driver recovers the money corresponding to unused time.
This first section has exposed the privacy concerns arising from the deployment of pay-by-phone parking systems. Next, Section 2 explains the system and adversary models together with the privacy requirements that the system should fulfill. After that, our proposal is detailed in Section 3, while Section 4 concludes the paper.

SYSTEM AND ADVERSARY MODELS
In the proposed system, payments are performed for short-duration time intervals (5 or 10 min). As a result of paying for a given time slot, the driver gets a parking ticket for that slot. When a parking operation begins, the driver pays and gets a parking ticket for each of the time slots composing the expected parking time. Parking tickets are paid using pre-paid e-coins 2 . Unused tickets can later be revoked in advance.
This section describes the system and adversary models. After that, the privacy requirements are detailed.

System Model
Our system is composed of the following actors: (1) Mobile application. It is run on the mobile device of drivers.
It allows to acquire pre-paid credit (in the form of e-coins), request parking tickets, revoke unused tickets, and provide a parking ticket when requested by a parking officer.
(2) System server. It is an on-line platform accessed by the mobile application to manage parking operations, and by parking officers to check the payment status of cars.
(3) On-board RFID device. It is placed inside cars and queried via RFID by a parking officer during an inspection. (4) Parking officer. He patrols regulated parking areas, queries the on-board RFID device of cars, and asks the system server about their parking status. (5) Timestamp authority: It issues timestamps upon request by the system server. Use cases involving communication are enumerated next: (1) Application set-up. When a driver installs the app she is asked to introduce the car plate number and a credit card required to acquire pre-paid e-coins. Then, the app transmits the plate number and the current time to the on-board device. The onboard device then generates an RSA key-pair and transmits the public key to the app. This communication must require authentication by the driver. It is performed via some shortrange system like NFC or Bluetooth.
(2) E-coin request. The app connects to the system server and requests for a certain amount of e-coins which are pre-paid via credit card. The price of each e-coin corresponds to the price of parking during a time slot. As it will be explained later, e-coins can be valued or no-valued 3 . (3) Parking ticket generation. The app connects to the system server and gets and stores parking tickets after performing the corresponding anonymous payments in e-coins. This communication is done through an anonymous channel to avoid linking parking payments from IP addresses [5]. (4) Parking inspection. A parking officer first queries the onboard device of a car which responds with a signed message containing the current time slot and its plate number. The officer forwards it to the system server which will connect to the corresponding mobile device via the "Parking ticket request" protocol. If the server gets a proper response, the officer will be notified. Otherwise, the car will be fined. (5) Parking ticket request. The system server employs a push notification service [7] to ask for a parking ticket to the app of a driver. If the mobile device is connected, the response is immediate. Otherwise the car will be fined. When connected again, if the mobile phone provides a parking ticket valid for the time the fine was issued, the fine will be canceled. (6) Parking ticket revocation. If a parking operation takes less time than expected, the driver can revoke unused parking tickets. The app connects to the server through an anonymous channel and revokes them receiving valued e-coins in exchange.

Adversary Model
The considered adversary model equals the one described in [9]: (1) The mobile application and the on-board device can not be corrupted.
(2) System servers and parking officers will follow the protocol steps as specified but may collaborate with an adversary by providing all the data they have access to. From the service provider point of view, drivers are untrusted parties which might try to get parking time without paying for it.

Design Objectives
In this section we describe the design objectives. Privacy requirements are equivalent to those in [9]. An additional requeriment regarding system tolerance to mobile phones getting out of coverage has been added.
(1) Parking tickets can only be linked to a car plate number as a result of a parking status checking performed by a parking officer located close to the car. (2) The information provided by a driver during a parking inspection only allows to determine whether a parking ticket for the current time does exist or not.
(3) During a parking operation, the mobile app only needs an Internet connection at the beginning and at the moment of revoking unused parking tickets.

OUR PROPOSAL
This section describes the procedures that compose the proposed system.
(1) System parameters generation. This procedure must be run by the service provider before deploying the service: (a) Generate an RSA [15] key pair for the system server. Let V S be the private key (only known to the server) and let P S be the public key. (b) Generate an RSA key pair for the timestamp server. Let V T SA be the private key (only known to the timestamp server) and let P T S A be the public key. (c) Generate a tuple (p,q,д) of DSA [12] public set-up parameters which are stored at the system server. Rationale. The system server will use its key pair to (blindly) sign e-coins and parking tickets during their issuance preventing, in this way, malicious drivers from being able to forge them. Timestamps will be issued to avoid disputes regarding the revocation status of parking tickets.
(2) Application setup. A driver must install the app into her mobile device and enter the car license plate number and a credit card number (necessary to pay for the purchased e-coins). The app will then connect to the on-board device and send the plate number and the current time. The onboard device then sets its internal clock and generates an RSA key pair: V D (private) and P D (public). The public key P D is transmitted to the mobile app.
Rationale. The on-board device key pair will be used to generate signed messages which are returned to parking officers after being queried by them. Possession of such a signed message proves that a parking officer was located close to the car when a parking inspection took place. (3) E-coin request. The app includes a wallet which stores e-coins that are generated through a protocol run between the app and the system server. A valued e-coin has a price while no-valued ones are free of charge. (a) A valued e-coin is generated as follows: (i) The mobile app performs a credit card payment for the requested e-coin 4 . (ii) The app generates a DSA key pair V C /P C over the (p, q, д) parameters. (iii) The app generates an even number x ∈ [0, (q − 1)/2)]. (iv) The app computes H (P C ||д x ) and asks the server to compute an RSA blind signature on it. Rationale. The difference between valued and no-valued ecoins is the parity of x. The system server, before issuing a no-valued e-coin must check that the corresponding x is odd through the described cut-and-choose technique. E-coins are blindly signed so that their issuance and spending can not be related. Regardless of being valued or no-valued, for each issued e-coin, the app stores a tuple: (4) Parking ticket generation. The driver has to issue a (valued) parking ticket for each of the time slots that compose the expected parking period. To hide its duration, the app always requests the same amount, R, of tickets (embracing the maximum allowed parking time). The tickets for slots in which the driver expects to be parked are paid with valued e-coins. The remaining ones are issued with no-valued ones so that no-valued dummy tickets are generated. This procedure is run through an anonymous channel: (a) The app takes a (valued or no-valued) e-coin {Siдn S (H (P C ||д x )), V C , x }, and spends it by computing P C = д V C and G = д x , and sending Siдn S (H (P C ||G)), P C , and G to the server. Then, employing the secret key V C the app signs a bitstring representing the current time and sends the resulting signature Siдn C (H (CurrentTime)) to the server. (b) The server verifies the RSA signature Siдn S (H (P C ||G)) using its public key P S , the signature Siдn C (H (CurrentT ime)) under the e-coin public key P C and checks that the e-coin has not been spent before. (c) The app determines the current time slot, Slot. Then it generates N random keys {K i } 0≤i <N , and computes the set {I D Slot i = H MAC K i (Slot ||License)} 0≤i <N . It also generates N even numbers {x r i } 0≤i <N ∈ [0, (q − 1)/2)] and computes {G ′ i = д x ′ i = д x +x r i } 0≤i <N . (d) The app next computes the following N hash digests {H (Slot ||I D Slot i ||G ′ i )} 0≤i <N , blinds each of them with a different blinding factor r i , and sends the blinded results to the server. (e) The server randomly chooses an index j ∈ [0, N − 1] and sends it to the app. (f) For each i j, the app sends r i , x r i , Slot and ID Slot i to the server. (g) The server unblinds the N − 1 hash digests H i , computes G ′ i = G · д x r i , and checks whether each H i is equal to H (Slot ||I D Slot i ||G ′ i ). It also verifies that each x r i is even and falls in the [0, (q − 1)/2)] range, and checks that Slot corresponds to a future time slot.
(h) If all the checkings are satisfied, the server blindly signs the remaining blinded hash and returns the result to the app. Also, the server stores: {P C , G, Siдn S (H (P C ||G)), CurrentT ime, Siдn C (H (CurrentT ime))}.