[ 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, …
 Main requirements
 Low infrastructure cost
 Ease of adaption/installation
 Secure: tamper-resistant, and ease of enforcement

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

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 Secure GPS
OBU Positioning Satellite
Transport &
payment card

Secure ID
Tra
v 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 A4, 4000m

2008-02-05T01:38 Z24, 200m
2008-02-05T01:40 A25, 30km
2008-02-05T01:55 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?
 Why three use cases?
 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

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
 Secure
 On the fly dynamic updates possible
 Statistics and value-add services possible

Good solution?
2. waypoints/time

 Clearly a privacy nightmare!

+ car ID

 Service provider gets all location & speed information

 Service provider knows personal details

5. Payment
Toll Service request
Provider Payment
Scheme
Provider
3. Map matching 7. Payment
4a. Tariff Look-up Proof
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

1. Collect waypoints
2. Map matching
3a. Tariff Look-up
3b. Fee Calculation
But at a cost
 Heavy processing/memory requirements
(increasing HW and license cost)
 Map and price updates!! Feasible?
 No anonymous statistics possible

Need for high OBU security (trust)

4. Car Identity +

(Fare & maps update)


+ OBU maintenance
Fee

Toll Payment
Service Scheme
Provider Provider
7. Payment
Proof

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 user-
relevant 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? Pro:
 Dynamic fee & map updates are
3c. Fee Calculation
managed @server
 Fee calculation (based on personal
details) done inside OBU
1. Anonymized  Low processing requirements for
Waypoints OBU (cost-optimized).
5. Car Identity + 3b. Tariffs
 Anonymous back-end info: value-
6. Fee + Toll Service add services possible
Account Number
Fee
Proxy

Privacy:
 Need to properly anonymize the
Payment
waypoints
Scheme Toll Service  Need to properly anonymize the
Provider Provider 2. Map matching network traffic
3a. Tariff Lookup
 If so: no private information leaves
8. Payment the OBU
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

{Waypoints, fees} + Time

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

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?
eSecurity WG Slide 20
 [ 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