[ Telematics – Road Pricing

Security & Privacy Solutions

Stefaan Motte
Manager NXP Competence Center Crypto & System Security

eSecurity WG

Slide 1

[ Outline
 

Introduction: the telematics road pricing use case Road pricing in practice
 

Road pricing end-to-end system Data flow, storage policies and controllers depending on chosen solution Enforcement

Conclusions

eSecurity WG

Slide 2

[ Telematics road pricing

Big movement in Europe towards intelligent and diversified road taxation. Fee calculation, based on
    

Type of road, specific gantries, … Time, date, … Actual congestion Type of vehicle Personal details (?) : age, disabled, #Km/year, resident, …
Low infrastructure cost Ease of adaption/installation Secure: tamper-resistant, and ease of enforcement

Main requirements
  

eSecurity WG

Slide 3

[ Main requirement for end-user:
My latest skiing trip, according to my GPS-enabled cell phone, and Google

Privacy

eSecurity WG

Slide 4

[ Telematics road pricing – science
fiction?

eSecurity WG

Slide 5

[ Outline
 

Introduction: the telematics road pricing use case Road pricing in practice
 

Road pricing end-to-end system Data flow, storage policies and controllers depending on chosen solution Enforcement

Conclusions

eSecurity WG

Slide 6

[ Road pricing End-to-End System
Secure Payment
Transport & payment card

OBU

Secure Positioning

GPS Satellite

Tra v

Secure ID

el P ath

Vignette
Secure Physical Link

Secure Services

Services Server(s)
eSecurity WG Slide 7

[ Road pricing in action
GPS Data Reception, Map Matching & Toll Calculation

2008-02-05T01:32 2008-02-05T01:38 2008-02-05T01:40 2008-02-05T01:55

A4, 4000m Z24, 200m A25, 30km Y411, 2 km

eSecurity WG

Slide 8

[ So how to implement this, and
what are the information flows?

Three use cases
  

Thin client: store and forward Fat client: do everything internally Smart client: best of both worlds? Choice has not been made yet, countries and regions are still investigating their options Data flow, and privacy impact vary between the cases, as does cost and ease of maintenance

Why three use cases?
 

eSecurity WG

Slide 9

[ A very simple/naive solution –
Thin OBU
1. Collect waypoints

Pro:  Super light (i.e. cheap) OBU  All logic in controlled back-end environment
 

Statistics and value-add services possible

Secure On the fly dynamic updates possible

2. waypoints/time + car ID

Good solution?  Clearly a privacy nightmare!
 

Service provider gets all location & speed information Service provider knows personal details

Toll Service Provider

5. Payment request

Payment Scheme Provider
7. Payment Proof

3. Map matching 4a. Tariff Look-up 4b. Fee Calculation

(cfr sms parking in e.g. Leuven, and many major cities) eSecurity WG Slide 10

[ The other extreme – Fat OBU
Privacy:  No private information leaves the OBU But at a cost  Heavy processing/memory requirements (increasing HW and license cost)  Map and price updates!! Feasible?  No anonymous statistics possible

1. Collect waypoints 2. Map matching 3a. Tariff Look-up 3b. Fee Calculation

4. Car Identity + Fee

Toll Service Provider 7. Payment Proof

+ OBU maintenance (Fare & maps update)

Need for high OBU security (trust)

Payment Scheme Provider

eSecurity WG

Slide 12

[ The other extreme –Fat OBU
 

So no private information needs to leave the OBU… … but:
“8. Invoicing of individual EETS Users by EETS Providers shall clearly separate the service charges of the EETS Provider and tolls incurred, and shall specify, unless the user decides otherwise, at least, the time at which and the location where the tolls were incurred and the userrelevant composition of specific tolls. “
(commission decision on the definition of the European Electronic Toll Service and its technical elements)

Sounds like an opt-out approach? Privacy benefit compared to thin client is gone.

eSecurity WG

Slide 13

[ Third option: Meet in the middle –
Smart OBU?
3c. Fee Calculation 1. Anonymized Waypoints 5. Car Identity + Fee 3b. Tariffs Toll Service Proxy

6. Fee + Account Number

Pro:  Dynamic fee & map updates are managed @server  Fee calculation (based on personal details) done inside OBU  Low processing requirements for OBU (cost-optimized).  Anonymous back-end info: valueadd services possible Privacy:  Need to properly anonymize the waypoints  Need to properly anonymize the network traffic  If so: no private information leaves the OBU

Payment Scheme Provider

Toll Service Provider

2. Map matching 3a. Tariff Lookup

8. Payment Proof

7. Payment Transaction

eSecurity WG

Slide 15

[ Outline
 

Introduction: the telematics road pricing use case Road pricing in practice
 

Road pricing end-to-end system Data flow, storage policies and controllers depending on chosen solution Enforcement

Conclusions

eSecurity WG

Slide 18

[ Camera-based Enforcement

Enforcement request + Time + auth

{Waypoints, fees} Proof

+ Time

IP DSRC …
Toll Service Provider + Time + auth Toll Charger Enforcement

Confirmation + payment proof

Get OBU ID

eSecurity WG

Slide 19

[ Online versus offline system
  

Typically, data of non-offenders is not stored (e.g. speed control in tunnels based on trajectory measurements). Using DSRC, real-time check whether OBU is functioning. However, instant verification whether correct fee is being paid is only possible in on-line system, i.e. in thin client model. How to handle off-line systems, where fee aggregation and payment is deferred to a later time? Data needs to be stored!
 

OBU can store location/fee/invoice data as proof Does the Data Retention Directive apply to Road Tolling in general, only to a specific section or not at all What is an acceptable/appropriate retention time, both on the OBU as in the enforcement system Can enforcement access OBU data directly, or is there need to go via Toll Service Provider?
Slide 20

eSecurity WG

[ Outline
 

Introduction: the telematics road pricing use case Road pricing in practice
 

Road pricing end-to-end system Data flow, storage policies and controllers depending on chosen solution Enforcement

Conclusions

eSecurity WG

Slide 21

[ Conclusions
 

Many systems/solutions are possible, and the law does not bring clarity which system shall be adopted Level of privacy varies widely, depending on the type of system that is chosen Industry needs to be agnostic to the system that is chosen
 

Agnostic ≠ ignorant!! Be aware of all possible scenarios, and be able to secure them all. Privacy respecting solutions seem available for both smart and fat clients

eSecurity WG

Slide 22

[ Thanks

eSecurity WG

Slide 23

Sign up to vote on this title
UsefulNot useful