Faculty of Computer Science Chair of Privacy and Data Security
Protection of the User’s Privacy in Ubiquitous E-ticketing Systems based on RFID and NFC Technologies
Ivan Gudymenko
Status talk, 12 June 2013 Outline
Introduction
Privacy Issues in E-ticketing Systems
Academic Solutions: State of the art
A Privacy-preserving E-ticketing System with Regular Billing Support (PEB)
References
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 2 Outline
Introduction
Privacy Issues in E-ticketing Systems
Academic Solutions: State of the art
A Privacy-preserving E-ticketing System with Regular Billing Support (PEB)
References
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 3 Target Area
Ubiquitous Computing (UbiComp); • – Based on RFID/NFC;
Focus on electronic ticketing (e-ticketing). • Privacy protection. →
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 4 E-ticket Taxonomy and Dissertation Focus
E-ticket
Focus on public transport •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 5 E-ticketing in Public Transport
[Courtesy of M¨unsterscheZeitung.de]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 6 E-ticketing: A General Application Scenario
Travel Records E-ticket Trip Begin Distribution
- Event Storage Check-in Check-out - Distance Calculation - Billing - Customer Accounts Management
- Statistics
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 7 Fare Collection Approaches in E-ticketing
Fare collection approaches
Focus on CICO-based systems •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 8 E-ticketing: Technologies and Standards
RFID-based stack (proximity cards); • NFC stack (NFC-enabled devices); • Recently, CIPURSE by OSPT (Open Standard for • Public Transport).
Architecture (conceptual framework)
(logical level, abstract interface, security)
Data Interfaces (data elements) The NFC Forum
(commands, security) Architecture Communication Interface (parts 1-3 required) The NFC Forum RFID-based E-Ticketing Stack Specifications
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 9 Target Area: Summary
E-ticketing systems for public transport; •
”Smart ticket” (as opposed to online ticket); •
CICO for automated fare collection; •
Underlying technologies: RFID/NFC. •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 10 E-ticketing: Concerns
For transport companies • – High system development/deployment costs; – Lack of well-standardized solutions; – New infrastructure is a high risk investment; – Possibly low Return of Investment (ROI).
For customers • – Reluctance to using a conventional system in a new way; – Privacy concerns: Ubiquitous customer identification; • Customer profiling (esp. unconsented); • Increased surveillance potential. •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 11 Outline
Introduction
Privacy Issues in E-ticketing Systems
Academic Solutions: State of the art
A Privacy-preserving E-ticketing System with Regular Billing Support (PEB)
References
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 12 Privacy Protection: Motivation
Rising privacy concerns in public; •
Motivation to invest in privacy for transport companies; • A privacy-preserving solution is of mutual benefit for • both parties: – Higher acceptance among customers; – Transport companies retain competitiveness.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 13 Generic Privacy Threats in E-ticketing Systems
1. Unintended customer identification: a) Exposure of the customer ID: i. Personal ID exposure (direct identification); ii. Indirect identification through the relevant object’s ID. b) Exposure of a non-encrypted identifier during the anti-collision session; c) Physical layer identification (RFID fingerprinting).
2. Information linkage; 3. Illegal customer profiling.
A cross-layered set of countermeasures required. → TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 14 Protecting User Privacy: Problems
Customer privacy is not in primary focus of • standardization effort;
Several tailor-made solutions (in add-on fashion); •
No holistic approach treating privacy from an outset (in • real systems)
Privacy by Design is required. →
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 15 A Privacy-preserving E-ticketing System: Reqs
(1) Privacy Identification: no (a) Against terminals Correlation: no Identification: no (b) Against back-end Correlation: yes (c) Against observers PII Derivation: no
(2) Billing (a) Regular Billing Regular billing support (b) Billing Correctness In accordance with fare policy
(3) Efficiency Check-in/out events handling
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 16 A General System Architecture and Requirements: An Overview
Check-in/out Backbone Network E-tickets Terminals Back-end
1 1 2 2 n n Real-time Non-real-time
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 17 A General System Architecture and Requirements: An Overview (1)
(1) Privacy Identification: no (a) Against terminals Correlation: no
Check-in/out Backbone Network E-tickets Terminals Back-end
1 1 2 2 n n Real-time Non-real-time
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 18 A General System Architecture and Requirements: An Overview (2)
(1) Privacy Identification: no (b) Against back-end Correlation: yes
Check-in/out Backbone Network E-tickets Terminals Back-end
1 1 2 2 n n Real-time Non-real-time
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 19 A General System Architecture and Requirements: An Overview (3)
(1) Privacy (c) Against observers PII Derivation: no
Check-in/out Backbone Network E-tickets External Observer Terminals Back-end
1 1 2 2 n n Real-time Non-real-time
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 20 A General System Architecture and Requirements: An Overview (4)
(2) Billing (a) Regular Billing Regular billing support (b) Billing Correctness In accordance with fare policy
Check-in/out Backbone Network E-tickets Terminals Back-end
1 1 2 2 n n Real-time Non-real-time
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 21 A General System Architecture and Requirements: An Overview (5)
(3) Efficiency Check-in/out events handling
Check-in/out Backbone Network E-tickets Terminals Back-end
1 1 2 2 n n Real-time Non-real-time
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 22 Main Goals/Research Questions
RQ: How to build a privacy-preserving e-ticketing system with the following properties?
(1) Loose-coupling between front-end and back-end (scaling);
(2) Offline e-ticket validation at the terminal side: – Valid e-tickets remain anonymous to the terminal; – Invalid e-tickets must be rejected.
(3) Privacy-preserving travel records processing in back-end: – With regular billing support for personalized tickets; – Preventing direct identification (pseudonymization).
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 23 Outline
Introduction
Privacy Issues in E-ticketing Systems
Academic Solutions: State of the art
A Privacy-preserving E-ticketing System with Regular Billing Support (PEB)
References
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 24 Important Evaluation Criteria
Mutual authentication between terminals and e-ticket; •
E-ticket anonymity/untraceability against terminals; •
Trust assumptions (esp. concerning terminals); •
Back-end coupling (close/loose); •
Regular billing support. •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 25 Solutions Taxonomy: Outline
E-ticketing Systems
Close-coupled Loosely-coupled
Fully Offline Semi-offline
Asymmetric Symmetric Asymmetric Symmetric Asymmetric Crypto Symmetric Crypto Crypto Crypto Crypto Crypto
Linear Logarithmic Constant time Reader-specific Full DB on E-cash based E-cash based E-cash based O(n) ~O(log n) O(1) Tag Access Lists a terminal
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 26 Solutions Taxonomy: Detailed
E-ticketing Systems
Close-coupled Loosely-coupled
Fully Offline Semi-offline
Asymmetric Symmetric Asymmetric Symmetric Asymmetric Crypto Symmetric Crypto Crypto Crypto Crypto Crypto
Linear Logarithmic Constant time E-cash Reader-specific Full DB on E-cash E-cash based Ohnf ~Ohlog nf OhYf based Tag Access Lists a terminal based
Precomputation Secrets Precomputed (T-M Trade-off) Ordering Look-up table
HCDF OSK Bloom filters Tree structure Yptime Pseudop TanSL PAYG ALM [HvBenjamin et alv] [Okubo et alv] [Nohara et alv] [MWW] nyms [SWM ] [Tan et alv] [Baldimtsi et alv] [Avoine et alv]
SWM Protocol OSK Improved Matrix structv LpTier DB GR [SongWMitchell] [Avoine et alv] [Cheon et alv] [Alomair et alv] [GarciaWRossum]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 27 Solutions Taxonomy: Close-coupled Systems
E-ticketing Systems
Close-coupled
Asymmetric Crypto Symmetric Crypto
Linear Logarithmic Constant time E-cash based Ohnf ~Ohlog nf OhYf
Precomputation Secrets Precomputed (T-M Trade-off) Ordering Look-up table
HCDF OSK Bloom filters Tree structure Yptime Pseudop [HvBenjamin et alv] [Okubo et alv] [Nohara et alv] [MWW] nyms [SWM ]
SWM Protocol OSK Improved Matrix structv LpTier DB [SongWMitchell] [Avoine et alv] [Cheon et alv] [Alomair et alv]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 28 Okubo et al. (OSK Protocol)
E-ticketing Systems
Close-coupled
Symmetric Crypto
Linear OcnW
OSK [Okubo et alI]
[Okubo et al., 2003]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 29 Okubo et al. (OSK Protocol)
Hash chain-based; two hash functions: • – H(): used for secret refreshment; – G(): used for untraceability against eavesdroppers.
Hash chain for the i th tag: • F :(i, k) r k = G Hk−1 sinit . 7→ i i H H H Tag - si - si+1 - (E-ticket) G G ? ? Reader a ai+1 (Terminal) i [Okubo et al., 2003]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 30 OSK assessment
Mutual authentication: no • Untraceability against terminals: yes • Terminals must be trusted: no • Back-end coupling: tight • Regular billing support: not considered • Limited number of validations (by hash chain size k); • Stateless by design; • Serious scalability issues: O(kn). •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 31 Revised Song & Mitchel’s Protocol (RSM)
E-ticketing Systems
Close-coupled
Symmetric Crypto
Linear Oxnf
SAM Protocol [SongAMitchell]
[Song and Mitchell, 2011]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 32 Revised Song & Mitchel’s Protocol (RSM)
Each tag has a secret s and a pseudonym t : t = h(s); • A keyed hash function serves for tag identification and • authentication (with tag pseudonym t as a key);
The protocol is stateful; • Refreshment of tag pseudonym and tag secret on • successful mutual authentication.
[Song and Mitchell, 2011]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 33 RSM Assessment
Mutual authentication: yes • Untraceability against terminals: yes • Terminals must be trusted: no • Back-end coupling: tight • Regular billing support: not considered • Scalability issues remain: O(n). •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 34 RSM-based One-time Pseudonym Protocol
Precomputed look-up table of one-time pseudonyms for • tag identification: – Tag identification complexity O(1);
Tag authentication is performed similarly to RSM; •
Requires re-initialization when the pseudonyms pool is • exhausted.
[Song and Mitchell, 2011]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 35 Heydt-Benjamin et al. (HCDF)
E-ticketing Systems
Close-coupled
Asymmetric Crypto
E-cash based
HCDF [HvBenjamin et alv]
[Heydt-Benjamin et al., 2006]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 36 Heydt-Benjamin et al. (HCDF)
Based on e-cash, anonymous credentials, and proxy • re-encryption.
Explicitly considers public transport (a holistic • framework);
Two types of tickets: • (1) Temporally-bounded; (2) Stored-value.
[Heydt-Benjamin et al., 2006]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 37 Heydt-Benjamin et al. (HCDF), continued
On enter: • – For temporally-bounded tickets: one-show validity credential; – For stored value tickets: accept entrance cookie CE .
On exit: • – For temporally-bounded. tickets: the same; – For stored value: reveal CE , calculate price (TA), delete CE (T).
On-the-fly price calculation on exit (for stored value • ticket). [Heydt-Benjamin et al., 2006]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 38 HCDF Assessment
Mutual authentication: no (not explicit) • Untraceability against terminals: yes • Terminals must be trusted: no • Back-end coupling: tight • Regular billing support: no • Involves asymmetric crypto on tag (ZKP). •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 39 Close-coupled Systems: Summary
E-ticketing Systems
Close-coupled
Asymmetric Crypto Symmetric Crypto
Linear Logarithmic Constant time E-cash based Ohnf ~Ohlog nf OhYf
Precomputation Secrets Precomputed (T-M Trade-off) Ordering Look-up table
HCDF OSK Bloom filters Tree structure Yptime Pseudop [HvBenjamin et alv] [Okubo et alv] [Nohara et alv] [MWW] nyms [SWM ]
SWM Protocol OSK Improved Matrix structv LpTier DB [SongWMitchell] [Avoine et alv] [Cheon et alv] [Alomair et alv]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 40 Close-coupled Systems: Pros
Terminal simplicity. • Less trust in terminals. • Simple infrastructure. •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 41 Close-coupled Systems: Contras
Scaling issues. • Back-end must be online 24/7. •
Synchronization (statefulness, possibility of DoS • attacks).
Back-end is a bottleneck and single point of failure. •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 42 Other Solutions Are Necessary
Some kind of decentralization is required. →
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 43 Solutions taxonomy: Loosely-Coupled Systems
E-ticketing Systems
Loosely-coupled
Fully Offline Semi-offline
Asymmetric Symmetric Asymmetric Symmetric Crypto Crypto Crypto Crypto
E-cash Reader-specific Full DB on E-cash based Tag Access Lists a terminal based
TanSL PAYG ALM [Tan et alf] [Baldimtsi et alf] [Avoine et alf]
GR [GarciaFRossum]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 44 Loosely-Coupled Systems: Semi-offline
E-ticketing Systems
Loosely-coupled
Semi-offline
Asymmetric Symmetric Crypto Crypto
E-cash based
PAYG ALM [Baldimtsi et alf] [Avoine et alf]
GR [Garcia-Rossum]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 45 Avoine et al. (ALM)
E-ticketing Systems
Loosely-coupled
Semi-offline
Symmetric Crypto
ALM [Avoine et alI]
[Avoine et al., 2009]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 46 Avoine et al. (ALM)
Offline tag validation using challenge response; • Reader-specific tag identification/authentication tuple • sets (TS);
TS are precomputed by trusted back-end and uploaded • to readers;
[Avoine et al., 2009]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 47 Avoine et al. (ALM): Keys
Two key types: • – Long-term tag-specific key KT shared between back-end and a tag (is not known to readers); – Session key kTR is computed on-the-fly by a tag;
k = f (K , ID , c ) • TR T R R At the reader side, k resides in TS (precomputed); • TR k is bounded to a specific (reader, tag) pair. • TR
[Avoine et al., 2009]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 48 ALM Assessment
Mutual authentication: yes • Untraceability against terminals: no • Terminals must be trusted: yes • Back-end coupling: semi-coupled (counter sync) • Regular billing support: not considered • Scalability issues are shifted to the reader side: • – O(n) complexity to locally identify/authenticate a tag.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 49 Baldimtsi et al. (PAYG)
E-ticketing Systems
Loosely-coupled
Semi-offline
Asymmetric Crypto
E-cash based
PAYG [Baldimtsi et alI]
[Baldimtsi et al., 2012]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 50 Baldimtsi et al. (PAYG)
Based on e-cash and anonymous credentials; • Explicitly considers public transport; • Single trip tickets only; • Unique ID is encoded into the Trip Authorization Token • (TAT) against double spending. – The knowledge of the encoded ID must be proved in ZK on check-in.
[Baldimtsi et al., 2012]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 51 Baldimtsi et al. (PAYG): System Architecture
Online vending machines (TAT issuing, refund • reimbursement) Offline check-in terminals: • – TAT validity check; – Issuance of a Refund Calculation Token (RCT). Offline check-out terminals: • – Terminal-side fare calculation; – Refund top-up. Variable pricing by attribute encoding; • [Baldimtsi et al., 2012]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 52 PAYG: Issues to Consider
Refund-based system (refund aggregation into Refund • Token); Nuisance for users (additional effort for refund • reimbursement); All reimbursed refund tokens must be stored in back-end • to prevent refund double spending (for each single trip); Actual fare calculation during check-out (no complex • pricing schemes possible);
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 53 PAYG: Assessment
Mutual authentication: no • Untraceability against terminals: yes • Terminals must be trusted: no • Back-end coupling: semi-coupled • Regular billing support: no • Involves asymmetric crypto on tag (ZKP). •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 54 Loosely-Coupled Systems: Fully-offline
E-ticketing Systems
Loosely-coupled
Fully Offline
Asymmetric Symmetric Crypto Crypto
E-cash Reader-specific Full DB on based Tag Access Lists a terminal
TanSL [Tan et alp]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 55 Tan et al. (TanSL)
E-ticketing Systems
Loosely-coupled
Fully Offline
Symmetric Crypto
Reader-specific Tag Access Lists
TanSL [Tan et alp]
[Tan et al., 2007]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 56 Tan et al. (TanSL)
A basis for a more profound protocol • – ALM by Avoine et al.
Reader-specific tag access list (as in ALM); • Authentication is bound to a concrete (reader, tag) pair; • Fully offline tag identification and authentication; • No regular secret refreshment (unlike ALM); •
[Tan et al., 2007]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 57 TanSL: Assessment
Mutual authentication: yes • Untraceability against terminals: no • Terminals must be trusted: yes • Back-end coupling: fully offline • Regular billing support: not considered • Scalability issues are shifted to the reader side: • – O(n) complexity to locally identify/authenticate a tag.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 58 Loosely-coupled Systems: Summary
E-ticketing Systems
Loosely-coupled
Fully Offline Semi-offline
Asymmetric Symmetric Asymmetric Symmetric Crypto Crypto Crypto Crypto
E-cash Reader-specific Full DB on E-cash based Tag Access Lists a terminal based
TanSL PAYG ALM [Tan et alf] [Baldimtsi et alf] [Avoine et alf]
GR [GarciaFRossum]
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 59 Loosely-coupled Systems: Pros
Loosely coupled system components • – Better scaling (compared to close-coupled systems);
Terminal-side e-ticket validation (efficiency); •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 60 Loosely-coupled Systems: Contras
More intelligence at the terminal side is required; • Contradicting requirements: • – Validate e-tickets; – Without identifying/tracking them.
Terminals operate on the tag data containing • identifiable information;
Privacy – validation trade-off. → Decentralized infrastructure is harder to manage • (updates, uploads, etc.).
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 61 State-of-the-art: Final Overview
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 62 The most relevant approaches Reviewed Criteria PAYG[1] HCDF[2] SVW[3] GR[4] ALM[5] OSK[6] RSMP[7]
Explicitly cons. PT yes yes yes yes no no no
Anonym. against term. yes yesp no no yes yes
Untraceab. against term. yes yesp no no yes yes
Mutual authentication no no no no yes no yes
Symmetric no yes yes yes yes no yes Crypto Primitives Hash yes yes no yes no yes yes Used Asymmetric yes yes p no no no no
Tight – yes––– yes yes Back-end Coupling Semi-coupl. yes–– yes yes–– Loose – – yes––––
Tamp. resist. required p no no ∅ ∅ ∅ ∅ Regular billing no no no ∅∅∅∅ Involves extern. device no no/p yes no no no no
BE is trusted no no yes yes yes yes yes
ATs are trusted no no yes yes yes no no
Revocation is possible yes yes yes yes yes yes yes
Dynamic extensibility yes yes yes no no yes no The most relevant approaches Reviewed Criteria PAYG[1] HCDF[2] SVW[3] GR[4] ALM[5] OSK[6] RSMP[7]
Explicitly cons. PT yes yes yes yes no no no
Anonym. against term. yes yes p no no yes yes
Untraceab. against term. yes yes p no no yes yes
Mutual authentication no no no no yes no yes
Symmetric no yes yes yes yes no yes Crypto Primitives Hash yes yes no yes no yes yes Used Asymmetric yes yes p no no no no
Tight – yes – – – yes yes Back-end Coupling Semi-coupl. yes – – yes yes – – Loose – – yes – – – –
Tamp. resist. required p no no ∅ ∅ ∅ ∅ Regular billing no no no ∅ ∅ ∅ ∅ Involves extern. device no no/p yes no no no no
BE is trusted no no yes yes yes yes yes
ATs are trusted no no yes yes yes no no
Revocation is possible yes yes yes yes yes yes yes
Dynamic extensibility yes yes yes no no yes no State of the Art: Focused
The most relevant approaches Reviewed Criteria PAYG[1] HCDF[2] SVW[3] GR[4] ALM[5] OSK[6] RSMP[7]
Anonymity terminals yes yesp no no yes yes
Untraceability terminals yes yesp no no yes yes
Mutual authentication no no no no yes no yes
Close-coupling no yes no no no yes yes
Regular billing no no no ∅∅∅∅ BE is trusted no no yes yes yes yes yes
ATs are trusted no no yes yes yes no no
Legend: – not considered; p∅ – partially provided;
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 65 Outline
Introduction
Privacy Issues in E-ticketing Systems
Academic Solutions: State of the art
A Privacy-preserving E-ticketing System with Regular Billing Support (PEB)
References
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 66 Recall: System Requirements
(1) Privacy Identification: no (a) Against terminals Correlation: no Identification: no (b) Against back-end Correlation: yes (c) Against observers PII Derivation: no
(2) Billing (a) Regular Billing Regular billing support (b) Billing Correctness In accordance with fare policy
(3) Efficiency Check-in/out events handling
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 67 A Privacy-preserving E-ticketing System with Regular Billing Support (PEB)
Protect privacy while allowing various pricing schemes in • back-end;
Pricing schemes are fully independent of system • architecture;
A reasonable trade-off is allowed: • – In front-end. Different sessions between an e-ticket and terminal/s are completely unlinkable; – In back-end. Back-end may correlate different sessions to an e-ticket pseudonym.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 68 Attacker Model
(1) (Outsider) No PII derivation by external observers (front-end sessions). (2) (Insider) No tracking and identification of valid e-tickets by terminals. (3) (Insider) No direct identification by back-end.
Insider/outsider with respect to the involvement into → the system flow.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 69 PEB: System Architecture
Transport Authority (TA)
Check-in/out Backbone Network E-tickets Terminals Back-end
1 1 2 2
n n Real-time Non-real-time
y )
External TTP
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 70 PEB: Pseudonymization
For each e-ticket, TTP creates a static pseudonym PT ; • i – Mapping PT ID is kept secret by TTP; i 7→ PT is sent to TA; • i TA includes it into its static pseudonym set: PT PT ; • i ∈ TA, therefore, operates only on pseudonyms in PT ; •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 71 PEB: Pseudonymization (continued)
TA possesses an asymmetric key pair: k+, k−; • ta ta A T Front-end e-ticket pseudonyms: P = E + P • i kta i – Required for terminal-side black list checking.
E-tickets are parameterized with PA; • i E-ticket terminal: a session pseudonym on each • ↔ A interaction (anti-tracking): SPj = E + P rj . kta i ·
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 72 PEB: Pseudonymization (continued)
Transport Authority (TA)
Check-in/out Backbone Network E-tickets Terminals Back-end External TTP 1 1 ) D 2 2
n n Real-time Non-real-time
SP1 T T Pi Pi ID SP2 T (Bill, Pi ) (Bill, ID) SPj
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 73 PEB: Privacy-preserving BL Checking
Based on the inherent homomorphism of an encryption • A T scheme in use: P = E + P ; i kta i Malleability property: E(x r) = E(x)r ; • · On validation, an e-ticket presents a tuple to a terminal: • SPT E(x r), E(r); ← · Black list: y : y BL ; • { ∈ } Check SP against the BL: • j y BL, E(r) SPT : c E(r)y ∀ ∈ ∈ ← c =? E(x r) c C. · ∀ ∈
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 74 BL Checking: A Choice of a Suitable Encryption
Based on the discrete exponentiation function • E(x) = g x (mod p) • Malleability property: • E(x r) = g (x·r) · = g x r (mod p) = E(x)r .
Other inherently homomorphic deterministic schemes • possible.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 75 PEB: Discussion
Loosely-coupled system; • Mutual identification due to group signatures; • Revocation: black lists: • – Encrypted black lists possible; – Alternatively, dynamic accumulators can be used [8].
To enhance performance, anonymity set can be reduced • in a controllable way;
Our system fully satisfies the requirements. •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 76 State-of-the-art Overview and PEB
The most relevant approaches Reviewed Criteria PAYG[1] HCDF[2] SVW[3] GR[4] ALM[5] OSK[6] RSMP[7] PEB
Anonymity terminals yes yesp no no yes yes yes Untraceability terminals yes yesp no no yes yes yes Mutual authentication no no no no yes no yes yes Close-coupling no yes no no no yes yes no Regular billing no no no yes ∅∅∅∅ BE is trusted no no yes yes yes yes yes no ATs are trusted no no yes yes yes no no no
Legend: – not considered; p∅ – partially provided;
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 77 Current Progress
The first results were presented at PECCS-2013 in • Barcelona (see [9]);
The paper presenting the core architecture has been • accepted to the IFIP-2013 Summer School.
Contacts with industry: DVB are interested, Secunet; • Supervision of two students helping to validate the • concept.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 78 Outline
Introduction
Privacy Issues in E-ticketing Systems
Academic Solutions: State of the art
A Privacy-preserving E-ticketing System with Regular Billing Support (PEB)
References
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 79 ReferencesI
[1] F. Baldimtsi, G. Hinterwalder, A. Rupp, A. Lysyanskaya, C. Paar, and W. P. Burleson, “Pay as you go,” in Workshop on hot topics in privacy enhancing technologies, HotPETSs 2012, http://petsymposium.org/2012/papers/hotpets12-8-pay.pdf, 2012. [2] T. S. Heydt-Benjamin, H.-J. Chae, B. Defend, and K. Fu, “Privacy for Public Transportation,” in Proceedings of the 6th international conference on Privacy Enhancing Technologies, PET’06, (Berlin, Heidelberg), pp. 1–19, Springer-Verlag, 2006.
[3] A.-R. Sadeghi, I. Visconti, and C. Wachsmann, “User Privacy in Transport Systems Based on RFID E-Tickets,” in Workshop on Privacy in Location-Based Applications (PILBA 2008), vol. 5283 of Lecture Notes in Computer Sciences, Springer-Verlag, October 2008. Malaga, Spain. [4] F. Garcia and P. Rossum, “Modeling Privacy for Off-Line RFID Systems,” in Smart Card Research and Advanced Application (D. Gollmann, J.-L. Lanet, and J. Iguchi-Cartigny, eds.), vol. 6035 of Lecture Notes in Computer Science, pp. 194–208, Springer Berlin Heidelberg, 2010. [5] G. Avoine, C. Lauradoux, and T. Martin, “When Compromised Readers Meet RFID,” in Information Security Applications (H. Y. Youm and M. Yung, eds.), vol. 5932 of Lecture Notes in Computer Science, pp. 36–50, Springer Berlin Heidelberg, 2009. [6] M. Ohkubo, K. Suzuki, and S. Kinoshita, “Cryptographic Approach to ”Privacy-Friendly” Tags,” in In RFID Privacy Workshop, 2003. [7] B. Song and C. J. Mitchell, “Scalable RFID security protocols supporting tag ownership transfer,” Comput. Commun., vol. 34, pp. 556–566, apr 2011.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 80 ReferencesII
[8] J. Camenisch and A. Lysyanskaya, “Dynamic Accumulators and Application to Efficient Revocation of Anonymous Credentials,” in Proceedings of the 22nd Annual International Cryptology Conference on Advances in Cryptology, CRYPTO ’02, (London, UK, UK), pp. 61–76, Springer-Verlag, 2002.
[9] I. Gudymenko, “On Protection of the Users Privacy in Ubiquitous E-ticketing Systems Based on RFID and NFC Technologies,” in 3d International Conference on Pervasive and Embedded Computing and Communication Systems, PECCS-2013, pp. 86–91, feb 2013. [10] A. Juels and R. Pappu, “Squealing Euros: Privacy Protection in RFID-Enabled Banknotes,” in Financial Cryptography 03, pp. 103–121, Springer-Verlag, 2002. [11] T.-L. Lim, T. Li, and S.-L. Yeo, “Randomized Bit Encoding for Stronger Backward Channel Protection in RFID Systems,” in Proceedings of the 2008 Sixth Annual IEEE International Conference on Pervasive Computing and Communications, PERCOM ’08, (Washington, DC, USA), pp. 40–49, IEEE Computer Society, 2008. [12] W. Choi and B.-h. Roh, “Backward Channel Protection Method for RFID Security Schemes Based on Tree-Walking Algorithms,” in Computational Science and Its Applications - ICCSA 2006 (M. Gavrilova, O. Gervasi, V. Kumar, C. Tan, D. Taniar, A. Lagan, Y. Mun, and H. Choo, eds.), vol. 3983 of Lecture Notes in Computer Science, pp. 279–287, Springer Berlin / Heidelberg, 2006.
[13] T.-L. Lim, T. Li, and S.-L. Yeo, “A Cross-layer Framework for Privacy Enhancement in RFID systems,” Pervasive and Mobile Computing, vol. 4, no. 6, pp. 889 – 905, 2008. [14] I. Gudymenko, “Protection of the Users Privacy in Ubiquitous RFID Systems,” Master’s thesis, Technische Universitt Dresden, Faculty of Computer Science, December 2011.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 81 Thank you for your attention! Questions? Comments? Suggestions?
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 82 Backup Slides
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 83 E-ticketing: Main Advantages
For transport companies • – decrease in system maintenance costs; – significant reduction of payment handling costs; – fare dodgers rate improvement; – better support of flexible pricing schemes; – support of multiapplication/nontransit scenarios; – a high interoperability potential.
For customers • – faster verification of an e-ticket; – ”pay as you go”; – flexible pricing schemes; – increased usability.
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 84 Generic Countermeasures
Threats Countermeasures
1. Unintended customer identification: a) Exposure of the customer ID: i. Personal ID exposure (direct) Privacy-respecting authentication; ID encryp- tion/randomization; access-control functions [10] ii. Indirect identification ID encryption b) Unencrypted ID during anti-collision Randomized bit encoding [11]; bit collision mask- ing [12, 13] (protocol dependent) c) PHY-layer identification Shielding; switchable antennas [14] 2. Information linkage Anonymization (in front-end and back-end): threat 1 countermeasures; privacy-respecting data processing 3. Illegal customer profiling Privacy-respecting data storage (back-end); the same as in threat 1
Difficult to apply in a joint fashion. •
TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 85 Revised Song & Mitchel’s Protocol (RSM) [7]
S T [T : s, t, s,ˆ tˆ] [t] Generate r1 r1 − − − → Generate r2 M1 = t r2 ⊕ M2 = ft(r1 r2) r1,M1,M2 k ← − − − Find t in the DB s.t. M2 = ft(r1 (M1 t)) k ⊕
r2 = M1 t ⊕ M3 = s ft(r2 r1) ⊕ k r1,M3 − − − → sˆ s s = M3 ft(r2 r1) ← ⊕ k tˆ t If h(s) = t, ← s (s l/4) (t l/4) r1 r2 t h((s l/4) (t l/4) r1 r2) ← ⊕ ⊕ ⊕ ← ⊕ ⊕ ⊕ t h(s) ←
Figure 1: The revised SM protocol TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 86
The look-up table contains a number of entries for each tag, one for each • element of a tag-specific hash-chain. Elements from this hash-chain are used as tag identifiers (and as database keys to identify tags). A keyed hash function is used to generate each hash-chain, using a secret key shared by the tag and server. The hash-chain length, m, determines the number of tag identifiers that can be produced using any one key. The operation of the protocol (described in detail in section 5.3) can be • divided into three cases, as follows (see also Table 1): 1. Case 1: for each of the first m 1 queries of a tag, the protocol pro- cess only involves tag authentication− and requires just two messages. To authenticate a tag, the server searches a look-up table, taking constant time. 2. Case 2: on the mth query of a tag, the protocol updates the secrets shared by the server and tag, as well as providing tag authentication. This process requires an additional message. The server takes O(1) work to authenticate a tag, as in case 1. 3. Case 3: if a tag is queried more than m times, which should not nor- mally happen, then a revised version of the SM protocol is performed; this requires the server to perform a linear search with complexity O(n).
For server authentication (in cases 2 and 3), for each tag the server holds • a secret s that only it knows, as in the schemes presented in [12, 8].
11 HCDF: Session Description
Authorized Reader (F ) Ticket (TX)
t /
ln r R 0, 1 ∈S { t r} ← || C EK+ (S) ← TA o C
C0 RE(C) ← S DK (C0) ← F− E (transaction) o S / Fig. 2. Authentication of reader to ticket using re-encryption (RE) allows F to trans- Session key generation:+ S t r; late ciphertext encrypted with K to ciphertext which can be decrypted with K−. • TA ← || F Thus the privateExchange key of TA remainsS using offline. non-expired This re-encryption delegation can only happen key if F possesses an• appropriate non-expired delegation key. Proof of possession of this delega- tion key is the mechanism(re-encryption); by which F demonstrates that it is authorized. This protocol provides a secure channel while matching the resource constraints of the different de- vices. TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 87 demonstrates that it is authorized by using its delegation key to transform C into a form which it can then decrypt with its own private key. The fact that F is then able to reply to TX with a well-formed message encrypted with session-key S demonstrates that F is authorized (possesses a non-expired delegation key). Once TX is satisfied that it is talking to an authorized reader it updates its logical clock to value t. If it ever receives a communication with a timestamp less than t, the communication will be assumed to be adversarial, and the protocol will be aborted. TX also uses t to refuse to divulge any information about cookies it holds which have expired. Since t increases monotonically (which can be monitored by HPDs, and dis- crepancies will also be eventually caught by passive transponders) and r is chosen by TX, neither F nor TX can cheat at this protocol in such a way as to make a re-play attack possible. S can only be decrypted by a reader with an unexpired delegation key (up to the strength of the underlying public-key and re-signature cryptosystems). This suffices for the security (up to underlying primitives) of the challenge-response.
6.2 createT icket(TV,TX,U) TX → Once the session key S is negotiated as discussed above, a stored-value ticket can be created by calling CreateT okens(T V, T X, ν) resulting in a new wallet which is then stored on TX. The protocol for creation of a temporally bounded ticket is similar, except that in place of CreateT okens, F ormNym and GrantCred must be executed with respect to some time interval λ which the user has chosen Avoine et al. (ALM)
Reader R Tag T IdR,cR IdT , KT ,cT
IdT ,kTR = EKT (IdR,cR)
(1) IdR,cR,nR
−−−−−−−−−−−−E (n ,n )→ kTR R T (2)
(3) ←−−−−−−−−−−−nT − −−−−−−−−−−−−→ (4) Fig. 6. Authentication protocol. TS (ID , k ) T • T TR Back-End← { B } ∀ Reader R kIdTRR,IdT E,KKT ,c(IDB R , cR ) IdR,cR • ← T IdT ,kTR = EKT (IdR,cR)
Id ,c ,k (1) T up TRup (2) TU Dresden, 12 June 2013 Privacy Protection−−−−−−−−−−− in E-ticketing → slide 88 Fig. 7. Key update protocol.
Initialization. When the system is set up, each tag T is assigned with the following values:
– a unique identifier IdT , – a long-term key KT , – three counters cB, cR and cT , initially synchronized and all equal to zero.
And during this set up, each reader R is assigned with the following values:
– a unique identifier IdR,
– for every tag T , its identifier and an encryption of its secret: IdT ,kTR = EKT (IdR,cR).
B stores IdR, IdT , KT and cB.
R stores IdR, cR, IdT and kTR = EKT (IdR,cR). T stores IdT , KT , cT .
Authentication. The authentication protocol consists of four steps (see Fig. 6):
(1) The reader sends to the tag its identifier IdR, the counter cR and a nonce nR. (2) The tag checks the value cR it receives: – If c c , it computes the key k = E (Id ,c ). Then, it picks a nonce R ≥ T TR KT R R nT and answers the encryption EkTR(nR,nT ) to the reader. – If cR (3) The reader decrypts the received message with the symmetric key kTR, and verifies the value nR. Then, it sends to the tag the recovered value nT . (4) T checks the validity of nT :ifsoandcR >cT , it updates cT to the value cR (c c ). T ← R (5) For every entry T in L, the reader computes H = h(h(Id t ) n n ) with R|| T || R|| T H = Hb He , and checks if Hb matches with Hb : || b – If so and k −2 , it sends to T the answer ansR to the question quesR. ≤ 1 2 k Thus, ansR represents the actual bits in positions quesR, quesR,...,quesR of He . – Else it sends ansR = rand where rand is a random bit string of length k. 1 2 k In turn, it sends a question quesT =(quesT ,quesT ,...,quesT ), built like quesR. (6) The tag T checks if ansR is correct: Tan– If soet and al. (TanSL)x, y, quesx = quesy , it sends to R the answer ans to the {∀ R T } T question quesT . – Else it sends ansT = rand. (7) The reader R verifies the answer ansT . Reader R Tag T IdR,L=[IdT : h(IdR tT )] IdT , tT || (1) request −−−−−−−−−−−nT → (2) ←−−−−−−−−−− (3) IdR,nR −−−−−−−−−−→ Hb, quesR (4) (5) ←−−−−−−−−−−ansR, quesT −−−−−−−−−−−ansT → (6) (7) ←−−−−−−−−−−− Fig. 5. TanSL protocol. 4 Security Analysis We nowTU Dresden, study 12the June 2013 security ofPrivacy all Protection the previous in E-ticketing protocols in the differentslide scenarios 89 defined in Section 2. 4.1 Tag Impersonation As authentication protocols are designed by nature to be secure in the context of Scenario 1, we only focus in Section 4.1 on Scenario 2. Scenario 2. For SK-based challenge/response protocols, once the adversary com- promised a reader, she knows all the secrets stored by the reader. She is so able to impersonate any tag. For signature schemes and zero-knowledge protocols (including GPS), the private key used to answer to the challenges is only known by the tag. Thus even if the adversary compromises a reader, she does not know the tags’ private keys. She cannot impersonate them. Regarding WIPR, an adversary who compromised a reader R knows its public and private keys (n and (p, q)) and the tags’ identifiers. The result is that she will be able to impersonate any tag to every reader. For the TanSL protocol, an adversary can obtain from a compromised reader R its identifier IdR and the list L containing all (IdT : h(IdR tT )), for every tag T . The adversary will not be able to impersonate a tag T in front|| of any other non- compromised reader R . Indeed, she does not know the tag’s secret tT , thus she is not able to compute the symmetric key h(Id t ) shared between R and T . R || T Client-Side Fare Calculation: Toll Pricing Decentralized approach to fare calculation; • Privacy preservation by client-side fare calculation; • Enforcement through spot checks, ZKP of the validity • of the committed values, etc.; The price calculation flow may be fairly complex • (involves several noncolluding parties); Substantial computational and operational overhead for • users; Does not suit well for a target e-ticketing system. → TU Dresden, 12 June 2013 Privacy Protection in E-ticketing slide 90