Privacy-Preserving Electronic Toll System with Dynamic Pricing for Low Emission Zones

Abstract

Low emission zones (LEZs) aim to reduce pollution and traffic congestion in cities. Current proposals for managing LEZs introduce a significant error percentage in the detection of fraudulent drivers and represent a serious privacy threat for the honest ones. In this article, a new electronic toll system to improve both issues is proposed.

1 Introduction

Traffic congestion has become a significant problem for almost all major cities and governments have introduced toll systems to solve it. These systems have received a lot of attention [1–8]. The main reason behind the success of this approach is that it enables an authority to restrict the access to drivers willing to pay a certain amount of money. In this way, a Low Emission Zone (LEZ) is a restricted area that vehicles can access in exchange for a payment according to the vehicles’ carbon emissions. LEZs can adjust the variable prices to manage the flow of vehicles by increasing toll taxes in congested roads and suggesting drivers to take cheaper routes (i.e., they are dynamic).

In general, Electronic Road Pricing (ERP) systems calculate road usage pricing by considering the vehicles’ itinerary. Vehicles are equipped with e on-board units (OBU) to record their paths. Each OBU is enabled with GPS and wireless communication capabilities; they periodically collect their geographical position; and send them to a service provider. To avoid fraud, current proposals adopt control mechanisms with the use of checkpoints (Chps), which are equipped with cameras and are randomly located in the LEZs. Chps take pictures of all vehicles and, hence, their number plates are stored together with the corresponding geo-positions and time. These three items allow the ERP to build a partial path of all the vehicles moving around the restricted area and verify that a certain driver has not altered the set of positions recorded by her car’s OBU and provided to the SP during the billing period.

This fraud detection mechanism has a certain failure probability that directly depends on the number of Chps deployed in the restricted area. In addition, increasing the number of checkpoints directly affects drivers’ privacy due to the fact that, the more checkpoints there are, the bigger the set of registered real drivers’ locations will be; and therefore, the more accurate the drivers’ paths will be.

In this article, a new prepayment ERP system for Low Emission Zones (LEZs) is proposed. This system provides: (1) a non-probabilistic fraud control and (2) honest drivers’ privacy through revocable anonymity. The system is presented in Sect. 2. The protocol is introduced in Sect. 3. Security is evaluated in Sect. 4, and conclusions are presented in Sect. 5.

2 System Model

Driver D is the person who drives. Vehicle V is the means of transport registered by a unique D. V has an identifier, the vehicle plate. Each V has a Secure element SE (tamper-proof module) and an On-board unit OBU (which has location capabilities and wireless connections).

A LEZ is divided into a set of street stretches. A stretch is a one-way section of street where Vs have to pay every time they drive through it. Each stretch is divided into a payment area and a traffic restricted area. The prices of each stretch are dynamically set according to its traffic density. A Beacon is a device, placed at the payment area, which constantly warns the Vs entering the stretch. A Checkpoint Chp, placed at the entrance of the restricted area of a stretch, aims to control the access of vehicles that enter the stretch. Service Provider SP, which manages both component types, offers an ERP service for urban areas. Ticket Provider TP issues tickets to Vs.

A Vehicle Certification Authority VCA provides keys and certificates to Vs. A Payment Service PS enables Ds to pay. The electronic payment system is out of scope of this article. Finally, a Punisher authority PA knows the identity of the V owner and reveals it in case of fraud.

Anti-fraud Requirements. When a V enters a stretch of a LEZ through a Chp, it obtains a ticket $\zeta ^{*}$. This $\zeta ^{*}$ contains information to prove that a specific V has the right to enter at a specific time. This proof is considered valid when it has the following properties: integrity, authenticity, non-repudiation, single-use and temporality. Fraud is commited when a D drives in a stretch without a $\zeta ^{*}$, with an invalid $\zeta ^{*}$ or with a valid $\zeta ^{*}$ associated with another V/stretch. A SP cannot falsely accuse an honest D of fraud.

Authenticity Requirements. At the entrance of a stretch, V and Chp must prove their identity to the other part.

Privacy Requirements. The system must (1) assure the privacy (the identity of D or V cannot be linked to any itinerary); (2) avoid the linkability between itineraries; and (3) provide revocable anonymity to D.

3 Protocol Description

3.1 Setup

Before starting the system, the next entities are initialized as follows:

• 1. PA obtains from authorities: (1) An asymmetric key pair ($Pk_{PA}, Sk_{PA}$), (2) its public key certificate $cert_{PA}$, and (3) a certificate repository of the authorities.

• 2. SP and VCA obtain from authorities: (1) An asymmetric key pair ($Pk_{SP}, Sk_{SP}$) and ($Pk_{VCA}$, $Sk_{VCA}$), (2) its public key certificate $cert_{SP}$ and $cert_{VCA}$, and (3) a certificate repository of the authorities.

• 3. VCA:

  • i. Defines: (1) A set of vehicles $V$ = $\left\{ v_{1}, ..., v_{n_{V}} \right\}$, where $n_{V}$ = $|V|$; (2) a collection of sets $K$ = $\left\{ C_{1}, ..., C_{n_{K}} \right\}$ partition of V, where $n_{K}$ = $|K|$, with $\left| C_{i} \right|$ = $n_{C}$, $\forall i$

  • ii. Generates and associates a certification entity $VCA_{C_{i}}$ to each element of the subset K ($C_{1},...,C_{n_{K}}$): (1) An asymmetric key pair ($Pk_{VCA_{C_{i}}}$, $Sk_{VCA_{C_{i}}}$), $\forall i \in \left\{ 1, ..., n_{K} \right\}$ and, (2) a CA certificate $cert_{VCA_{C_{i}}}$, $\forall i \in \left\{ 1, ..., n_{K} \right\}$, which has an expiration time $c_{exp}$

• 4. TP and each Chp apply the following steps:

  • i. Obtain a certificate repository of the authorities and entities

  • ii. Generate an asymmetric key pair ($Pk_{TP}, Sk_{TP}$) and ($Pk_{Chp}, Sk_{Chp}$)

  • iii. Securely obtain a public key certificate $cert_{TP}$ and $cert_{Chp}$ from SP. $cert_{Chp}$ contains an extension $cert_{Chp}.loc$ with its location coordinates and a stretch identifier $cert_{Chp}.str$

• 5. Each Beacon is initialized by SP with a warning advise information-of-stretch ${\beta _{str}}^{*}$ = ($\beta _{str}$, $\overline{\beta _{str}}$), where $\overline{\beta _{str}}$ is the signature of $\beta _{str}$ ($Sign_{SP}$($\beta _{str})$), and where $\beta _{str}$ contains information of: (1) the street stretch (str and GPS cord.); and (2) the TP connection (it defines how to access TP)

• 6. VCA certificates the Vs (it is assumed that the SE of each V has been previously initialized with a certificate repository of the certification authorities, identifying information of the vehicle $V_{id}$ and its technical specifications): (1) Register V in an element of the subset K (in a $C_{i}$) and (2) download the certification entity $VCA_{C_{i}}$ ($Pk_{VCA_{C_{i}}}$, $Sk_{VCA_{C_{i}}}$ and $cert_{VCA_{C_{i}}}$) associated to $C_{i}$ by a secure channel in the SE.

3.2 Price Generation

Every fixed period of time $\tau$, SP establishes the prices of each stretch str, depending on its traffic density, by performing the next operations:

• 1. Set the prices per emission category (i.e. European Emission Standards), searching a balance between supply and demand.

• 2. Compose information-of-prices $\alpha _{str}$ = ($str$, $prices$, $p_{exp}$, $acc_{d})$, where $p_{exp}$ is the expiration time of the prices and $acc_{d}$ identifies the SP destination account of the electronic payment system assumed.

• 3. Sign $\alpha _{str}$: $Sign_{SP}(\alpha _{str})=\overline{\alpha _{str}}$, send ${\alpha _{str}}^{*}$ = ($\alpha _{str}$, $\overline{\alpha _{str}}$) to TP.

3.3 Certificate Generation

When V enters a LEZ, its SE generates new credentials. Its SE:

• 1. Computes an asymmetric key pair ($Pk_{{V_{q}}}$, $Sk_{{V_{q}}}$)

• 2. Generates a public key certificate $cert_{{V_{q}}}$ with the next attributes: (1) An extension $cert_{{V_{q}}}.idS$ containing the probabilistic encryption of the vehicle identifier $V_{id}$ with the public key of PA: $Enc_{Pk_{VCA}}(V_{id})$; and (2) an extension $cert_{{V_{q}}}.em$ containing its pollutant emission category.

3.4 Purchase

When a V enters a payment area, the purchase protocol is applied:

• 1. Beacons send information-of-stretch ${\beta _{str}}^{*}$

• 2. The SE of the V, with the help of the OBU, has to:

  • i. Verify the signature $\overline{\beta _{str}}$: $Verif_{SP}$($\beta _{str}$, $\overline{\beta _{str}}$) and its GPS location

  • ii. Establish with TP a secure and secret communication channel

  • iii. Extract str from $\beta _{str}$ and send TP a request for the prices of str

• 3. TP sends ${\alpha _{str}}^{*}$ to V 

• 4. The SE of the V, with the help of the OBU, has to:

  • i. Verify the signature $\overline{\alpha _{str}}$: $Verif_{SP}$($str$, $prices$, $p_{exp}$ $acc_{d}$, $\overline{\alpha _{str}}$), and the freshness of ${\alpha _{str}}^{*}$:$|p_{exp}$-current time $|<\tau '$ (a fixed time)

  • ii. Obtain the amount to pay, according to its pollutant emissions.

  • iii. Compose a payment order $\gamma$ = ($acc_{s}$, $amount$, $acc_{d}$), where $acc_{s}$ is the source account of the user, and $acc_{d}$ is the destination account

  • iv. Sign $\gamma$: $Sign_{{V_{q}}}(\gamma ) = \overline{\gamma }$ and send $\gamma ^{*}$ = ($\gamma$, $\overline{\gamma }$) and its certificate $cert_{{V_{q}}}$ to PS. $\gamma$ includes additional information, which indicates the source account and authenticates its owner in front of PS.

• 5. PS has to: (1) Perform the actions belonging to the used payment system; and (2) compose $\delta$ = ($trans_{id}$, $hash(\overline{\gamma })$), sign $\delta$: $Sign_{PS}$($\delta$) = $\overline{\delta }$, and send $trans_{id}$ and $\overline{\delta }$ to V;

• 6. The SE of the V, with the help of the OBU, has to:

  • i. Compute $hash(\overline{\gamma })$, recompose $\delta$ and verify $\overline{\delta }$: $Verif_{PS}$($\delta$, $\overline{\delta }$)

  • ii. Compute $hash(\overline{\delta })$ and compose a ticket request $\epsilon$ = ($str$, $ts$, $hash(\overline{\delta })$), where $ts$ is the current time

  • iii. Sign $\epsilon$: $Sign_{{V_{q}}}(\epsilon ) = \overline{\epsilon }$, and send $\epsilon ^{*}$ = ($\epsilon$, $\overline{\epsilon }$) and its $cert_{{V_{q}}}$ to TP

• 7. TP has to:

  • i. Verify the certificate $cert_{{V_{q}}}$ and the signature $\overline{\epsilon }$: $Verif_{{V_{q}}}$($\epsilon$, $\overline{\epsilon })$

  • ii. Verify the freshness of $ts$:$|ts-$ current time $|<\tau '$, where $\tau '$ is a fixed time

  • iii. Compute $hash(\overline{\epsilon })$ and the fingerprint $fing_{{V_{q}}}$ of $cert_{{V_{q}}}$

  • iv. Compose a ticket $\zeta$ = ($str$, $ts$, $fing_{{V_{q}}}$, $hash(\overline{\epsilon })$), sign it: $Sign_{Chp}$($\zeta$) = $\overline{\zeta }$, send $\zeta ^{*}$=($\zeta$, $\overline{\zeta }$) to V, and send $\epsilon ^{*}$ and $\zeta ^{*}$ to SP

• 8. The SE of the V, with the help of the OBU, computes $hash(\overline{\epsilon })$, and verifies the signature $\overline{\zeta }$: $Verif_{TP}$($str$, $ts$, $fing_{{V_{q}}}$, $hash(\overline{\epsilon })$, $\overline{\zeta }$)

3.5 Entrance

When a Chp detects the V, the protocol is applied:

• 1. Chp generates a nonce $N_{A}$, and sends $N_{A}$ and the $cert_{Chp}$ to V

• 2. SE of the V, with the help of the OBU, has to:

  • i. Verify the certificate $cert_{Chp}$, $cert_{Chp}.loc$ and $cert_{Chp}.str$ = $str$

  • ii. Generate a nonce $N_{B}$ and compute the $fing_{Chp}$ of $cert_{Chp}$

  • iii. Compose an entrance request $\eta$ = ($N_{A}$, $fing_{Chp}$, $N_{B}$, ${\zeta }^{*}$) and sign it: $Sign_{{V_{q}}}(\eta ) = \overline{\eta }$

  • iv. Generate a digital envelope of $\eta ^{*}$ = ($\eta$,$\overline{\eta }$) with the Chp’s public key

  • v. Send the digital envelope and its $cert_{{V_{q}}}$ to Chp

• 3. Chp has to:

  • i. Open the digital envelope with its secret key obtaining $\eta ^{*}$

  • ii. Verify the certificate $cert_{{V_{q}}}$ and the signature $\overline{\eta }$: $Verif_{{V_{q}}}$($N_{A}$, $fing_{Chp}$, $N_{B}$, ${\zeta }^{*}$, $\overline{\eta })$ and generate timestamp $ts'$

  • iii. Verify the signature $\overline{\zeta }$: $Verif_{TP}$($\zeta$, $\overline{\zeta }$)

  • iv. Verify $cert_{Chp}.str$ = $str$ (extracted from $\epsilon$, included in $\zeta$) and verify the freshness of $\zeta ^{*}$:$|ts-ts'|<\tau ''$, where $\tau ''$ is a time which is fixed according to the traffic volume of the stretch.

  • v. Compute the $fing_{{V_{q}}}'$ of $cert_{{V_{q}}}$ and verify $fing_{{V_{q}}}'$ = $fing_{{V_{q}}}$

  • vi. If one of the verifications fails or $\zeta ^{*}$ has not sent, Chp performs the following operations: (1) Generate an incidence number of entrance $in_{i}$; (2) Take a photo ph of V and extract the plate number $plt$; (3) Compose a proof-of-entrance incidence $\theta _{i}$ = ($in_{o}$, $plt$, $ph$, $ts'$, $\eta ^{*}$, $cert_{{V_{q}}}$); (4) Sign $\theta _{i}$: $Sign_{Chp}(\theta _{i}) = \overline{\theta _{i}}$ and send ${\theta _{i}}^{*}$ = ($\theta _{i},\overline{\theta _{i}}$) to SP.

  • vii. If the verifications performed in 3ii–3v are correct, the Chp has to: (1) Compose proof-of-entrance $\iota$ = ($ts'$, $\eta ^{*}$, $cert_{{V_{q}}}$); (2) Sign $\iota$: $Sign_{Chp}(\iota )=\overline{\iota }$, and send $ts'$ and $\overline{\iota }$ to the V

• 4. If the verifications performed in 3ii–3v are correct, SE of the V, with the help of the OBU, verifies the certificate $cert_{Chp}$ and the signature $\overline{\iota }$: $Verif_{Chp}$($ts'$, $N_{A}$, $fing_{Chp}$, $N_{B}$, ${\zeta }^{*}$, $\overline{\eta }$, $cert_{{V_{q}}}$, $\overline{\iota }$)

3.6 Payment Verification

TP sends SP ticket requests $\epsilon ^{*}$ and tickets $\zeta ^{*}$ periodically. Each Chp sends proof-of-entrances $\iota ^{*}$ and proof-of-entrance incidences ${\theta _{i}}^{*}$. SP then forwards the incidences ${\theta _{i}}^{*}$ to PA. Moreover, SP verifies a posteriori the payment performed by each V according to the following operations:

• 1. Define a set of proof-of-entrance $I = \left\{ {\iota _{1}}^{*}, ..., {\iota _{n_{\iota }}}^{*} \right\}$ and a set of ticket request $E = \left\{ {\epsilon _{1}}^{*}, {\epsilon _{2}}^{*}, ..., {\epsilon _{n_{\epsilon }}}^{*} \right\}$, where $n_{\iota }$ is the number of proof-of-entrance and $n_{\epsilon }$ is the number of ticket request sent to TP

• 2. Select a subset $E'$ from $E$ (each ${\epsilon _{i}}^{*}$ has been used by some D)

• 3. Verify that there is a unique $\epsilon$ in the set $E'$ with the same $hash(\overline{\delta })$

• 4. For each proof-of-entrance $\iota ^{*}$:

  • i. Extract $str$, $ts$ and $hash(\overline{\epsilon })$ from ticket $\zeta$

  • ii. Recover the prevailing information-of-prices ${\alpha _{str}}^{*}$ of the stretch str at time $ts$, and extract $prices$ from $\alpha _{str}$ and $cert_{{V_{q}}}.em$ from $\iota$

  • iii. Obtain from prices the $amount'$ to pay according to $cert_{{V_{q}}}.em$

  • iv. Verify whether the transfer, referenced by $hash(\overline{\epsilon })$, was successful, and recover the amount of money paid

  • v. Verify that $amount=amount'$

  • vi. Verify that ${\zeta }^{*}$ is unique in the set $I$

• 5. If one of the verifications fails, SP then needs to:

  • i. Generate an incidence number of verification $in_{v}$

  • ii. Compose proof-of-verification incidence $\theta _{v}$, including $\iota ^{*}$ concerned: $\theta _{v}$=($in_{v}$, $\iota ^{*}$). In the case of a reused ${\zeta }^{*}$, add ${\iota ^{*}}'$ to $\theta _{v}$ = ($in_{v}$, $\iota ^{*}$, ${\iota ^{*}}'$). Moreover, when a $hash(\overline{\delta })$ is reused, $\theta _{v}$ is supplemented with both ticket requests of the proof-of-entrances proving it: $\theta _{v}$ = ($in_{v}$, $\iota ^{*}$, ${\iota ^{*}}'$, $\epsilon ^{*}$, ${\epsilon ^{*}}'$)

  • iii. Sign $\theta _{v}$: $Sign_{SP}(\theta _{v})$=$\overline{\theta _{v}}$ and send ${\theta _{v}}^{*}$=$(\theta _{v}$, $\overline{\theta _{v}}$) to PA.

3.7 Sanction

For each received $\theta$, PA performs the following operations:

• 1. In the case of $\theta _{i}$, PA verifies the signatures and extracts the number plate plt from the photograph ph, included in $\theta _{i}$

• 2. In the case of $\theta _{v}$ PA has to:

  • i. Verify all the signatures included in $\theta _{v}$ and the signatory of $\iota$

  • ii. Verify the right payment by repeating steps 4i–4v of phase Sect. 3.6

  • iii. In case of a reused ${\zeta }^{*}$, verify that it is the same in $\iota$ and $\iota '$

  • iv. In case of a reused $hash(\overline{\delta })$, verify the $hash(\overline{\epsilon })$ of ${\zeta }^{*}$ (included in $\iota$ references $\epsilon ^{*}$) and the $hash(\overline{\epsilon })'$ of ${{\zeta }^{*}}'$ (included in $\iota '$ references ${\epsilon ^{*}}'$), and verify that both $\epsilon ^{*}$ and ${\epsilon ^{*}}'$ have the same $hash(\overline{\delta })$

  • v. If the incidence is confirmed, recover the identifier $V_{id}$ of ${V_{q}}$ by opening the extension $cert{{V_{q}}}.idS$ of the certificate $cert{{V_{q}}}$, included in $\iota$: $Dec_{PA}(cert{{V_{q}}}.idS)=V_{id}$. In the case of a reused $hash(\overline{\delta })$, the identifier $V_{id}'$ of the second vehicle ${V_{q}}'$ is also recovered in the same way from $\iota '$

• 3. Notify the owner of V, using $plt$ or $V_{id}$, about the sanctioning procedure and request her contrary evidences to refute her accusation.

• 4. Verify the contrary evidences presented by the owner of the V. In the case of a reused $hash(\overline{\delta })$, the evidences should include the hashes, which allow to evaluate the pre-images of the hash chain, and the first value of the hash chain $\overline{\gamma }$, which proves the signature authorship.

• 5. Fine the owner of the V if the presented evidences are not valid.

4 Security and Requirement Analysis

The system preserves authenticity, non-repudiation, integrity, single-use and temporality for the tickets to be considered valid since:

• The creation of fraudulent tickets is computationally unfeasible nowadays without the knowledge of $Sk_{TP}$ in the signature.

• TP cannot deny their emission, the issuer’s identity is linked to the proofs, and for the properties of the electronic signature scheme, it cannot deny its authorship.

• The modification of the content of the tickets by Vs is computationally unfeasible nowadays since the hash summary function used in the signature scheme is collision-resistant, and without the knowledge of the TP secret key.

• A ticket cannot be reused to enter a stretch without being detected because it is considered unique. A ticket can only be created by TP, only one ticket at the same time.

• Tickets cannot be used to enter a stretch after their expiration because each ticket cannot be modified and contains the time $ts$ of its emission, which is verified by the $TP$.

The toll system is resistant to fraud since users who enter a stretch without a ticket (in step 3vi of Sect. 3.5), with no valid ticket, or with a valid ticket associated with another user or stretch, are detected (in step 3v of Sect. 3.5). Otherwise, the system protects users against false accusations since the protocol execution generates records signed by the involved entities, which prove the user has entered the stretch without committing fraud. She will then be able to retrieve some of these records and provide them to PA in order to prove its own honesty.

The system preserves anonymity and traceability between user itineraries (an itinerary starts each time V enters a LEZ) to honest drivers since: (1) The information that can identify a user ($cert_{{V_{q}}}.idS$, which contains $V_{id}$) does not reveal the user’s identity because this information is encrypted using the public key of PA. The certificate $cert_{{V_{q}}}$ can be neither identify them thanks to the fact that the CA, is shared with several users and because each user is registered in an element of the subset $K$ together with other users; and (2) the SE generates a new $cert_{{V_{q}}}$ for the vehicle in each new LEZ entrance. Nobody can neither relate the identity of the V of this itinerary with any other nor know whether two certificates belong to the same user, as there are $K$ different CAs.

The system provides anonymity revocation for dishonest drivers according to how fraud is detected:

• In case of a reused ticket, the amount paid does not correspond to the tax determined for $\tau$, or emissions of V, or a reused transfer reference $hash(\overline{\delta })$ are detected, SP sends $\theta _{v}$ to PA. PA verifies the incidence and identifies the user by opening the field $cert{{V_{q}}}.idS$ of the certificate with its private key. Obtaining $V_{id}$ allows the identification and punishment of the dishonest user.

• In other cases of fraud, the user is identified when she is photographed by the $Chp$ at the entrance of a stretch. The user then loses her anonymity as the vehicle number plate is captured.

5 Conclusions

This paper has presented an ERP system for urban areas with an enhanced dynamic pricing, which provides a robust fraud control system and a high level of privacy. The entrance process of a LEZ is controlled so that the legitimate tax is dynamically computed depending on the traffic volume while the anonymity of the user is preserved. However, if a user commits fraud, she will then be identified by the picture of the number plate taken by the checkpoint in conjunction with the anonymity revocation system of the protocol.