The Netherlands uses a nationwide, smart card based, public transport ticketing system called “OV chipkaart“. This system logs all trips made by all people travelling by public transportation in the Netherlands in one central database. This is even the case for the so called anonymous OV chipcard, which gave rise to a court case recently asking the judge to order the Dutch data protection authority to start enforcing the GDPR. And that in turn got me thinking about how to implement public transport ticketing in a privacy friendly way.

The tricky part is to make the system both privacy friendly, secure, auditable and user friendly. I believe this is possible, and sketch two possible approaches below. If you want to know the details, read the full report.

Basic ingredients

The basic ingredients are so called partially blind signatures and attribute based credentials.

A partially blind signature allows a user to obtain a signature on a message from a signer, without the signer actually learning the message being signed, while at the same time allowing the signer to add some known and agreed upon data to this message as well. After the blind signature protocol, the user has a valid signature from the signer on the whole message consisting of both the secret user-provided attributes and the known signer-provided attributes (and these cannot be separated, nor can any of the attributes be changed without invalidating the signature). Moreover, this signature is untraceable: the signer cannot tell when and to who it issued that signature.

We also refer below to an attribute based credential (ABC) scheme, where users can request credentials containing attributes from issuers, and can use such credentials repeatedly afterwards to securely show a subset of these attributes to relying parties at a later time. Multiple showings of attributes in a credential are unlinkable to one and the same credential (provided the attributes themselves are not uniquely identifying or linkable). This in particular prevents the issuer to link subsequent showings of the credentials it issued. This distinguishes ABCs from partially blind signatures that can only be used once.

Assumptions

This note is for a large part based on our experiences with the Dutch OV chipcard system. In particular we assume a system that supports many modes of transportation. This means we distinguish

  • public transport operators (PTOs) that offer public transport services,
  • users travelling by public transport, making trips that may consist of several legs each using a different mode of transportation offered by a different PTO.
  • a central clearinghouse providing the public transport ticketing infrastructure.

We assume fares are course enough to ensure that the price associated with a trip does not reveal the actual trip itself.

We furthermore assume that users are willing or even prefer to use their smartphone to pay for public transportation (even though in privacy terms an ill configured smartphone is like having a never sleeping Stasi agent in your pocket).

The underlying idea is that from a privacy perspective it is better to collect personal data locally on the user device, instead of centrally on the servers of the service providers. But this only holds water if the system is designed in such a way that an untrusted smartphone can be used as the ‘token’ to carry tickets or travel credit. This allows third parties to provide the apps for that purpose, which should increase the (perceived) trust of the overall system. At the very least it offers users a real choice.

Solution 1: Emulating paper tickets

Of course one way to achieve privacy in public transport ticketing is to emulate the traditional use of paper public transport tickets. The basic idea is to first buy the ticket online, and subsequently use it for public transport later, in such a way that the account used to pay for the ticket cannot be linked to the actual trip being made. As the online payment infrastructure is identifying (revealing to the payee who paid), the issuing of the ticket must be done in a privacy friendly fashion. The idea is as follows

  • The user selects the trip to make using the app, and pays the associated fare.
  • The PTO issues the ticket using a partially blind signature where trip start, trip end, trip date and a random serial number are the blind attributes provided by the user, while the price paid is public and added by the PTO.

The blind signature ensures that the PTO cannot link identifying information (from the payment, or the online connection used to order the tickets) with the actual trip being made. Conductors can verify that people travelling have valid tickets, and in particular must (!) check that the fare mentioned on the ticket corresponds to the other trip details on the ticket. PTOs immediately receive financial compensation for the tickets issued.

To support subscriptions or season tickets is tricky. As the smartphone is essentially an untrusted device we cannot use attribute based credentials to represent them: they could be cloned between devices. The easiest and most secure as well as privacy friendly approach is probably to stick to a traditional physical pass with a picture of the holder (with certain security features that make counterfeiting hard enough) that travellers need to show in order to prove they have a certain subscription and are eligible for a reduced fare.

The level of privacy protection is quite good but not perfect. In the setup described, the PTOs and the bank could learn how many tickets you buy, and for which amount (ie for which distance), but cannot link actual trip details to users due to the blind signature used.If you usually buy your tickets on the same day or the day before your trip, your PTO could learn when you travel. The PTO could learn whether you are using public transport a lot, or not. Many short trips on the same day may reveal you are in a city; certain patterns of distances may correspond to popular tourist routes (and hence reveal the city you are in). This may already be a threat for people that engage in civil disobedience, like the Hong Kong protesters or Extinction Rebellion activists. All these problems can be avoided if users can use cash to buy tickets, at special digital kiosks.

Solution 2: Pay as you go, with credit on device

Another approach to achieving privacy in public transport ticketing is to pay as you go, where you have some stored value or credit securely kept on your device to pay for your trips. The idea is to check in to record the location where you start your trip and to check out to record the location where you end your trip. When you check in, the system verifies that you have enough credit to make a trip. The actual fare is calculated and automatically deducted from your device as soon as you check out.

To turn this idea into a privacy friendly architecture, the credit on the device needs to be stored in such a way that the device itself no longer needs to be trusted. This obviates the need for tamper proof or tamper evidence features, and more importantly scraps the need for fixed identifiers and additional centralised bookkeeping. Again we use partially blind signature scheme to allow the central clearinghouse to sign a so called credit token containing the credit as the known value, and a random serial number generated by the device as the blindly signed value (which is used to prevent double spending). The central clearinghouse keeps a record of all used credit serial numbers.

To check in:

  • The user device sends the credit token to the check-in device.
  • The check in device verifies the credit the token, and sends the serial number to the central clearinghouse server to mark it as used. It also checks whether the credit token contains enough credit to pay for a possibly long trip.
  • The check in device returns a check in token (signed by the PTO) which contains the current location, time, and the serial number in the credit token.

To check out:

  • The users device sends the check in token and the credit token to the check out device.
  • The check out device verifies both tokens, and in particular checks that the serial number in the credit and check in token are the same.
  • The fare is calculated based on the check in location and the current location the check, and is subtracted from the credit in the credit token.
  • A new credit token with the updated credit is issued by the clearinghouse, using a new blind random serial number generated by the user.
  • The PTO also issues a check out token.

The blind signature ensures that spent credit tokens cannot be linked to when they were issued. Users receive a fresh credit token whenever they check out.

The level of privacy offered is probably better compared to the previous solution. If you top up the credit on your device with larger amounts, there is much less correlation between the times you top up credit and the time you travel by public transport. PTOs learn less, and are no longer able to track when and how often you travel. The banks still learn how much you travel, in terms of the amount of money you spend on public transportation, unless you use cash. Only check ins and check outs are linked (through the same serial number in the credit token). Fresh credit tokens are issued with new random serial numbers, that are kept secret when the credit token is issued. This breaks the link between past and current credit tokens. Unfortunately there is one issue that complicates the analysis: the actual credit on your token stays the same between check out and check in. This allows the PTO to link a check in with a particular credit to an earlier check out with the same credit. Now the number of possible credit values is not so large (10.000 if we assume a credit between 0 and 100 euro, measured in cents), and the number of people travelling large (in the order of millions). Moreover, a certain credit value at check out may occur many times over a larger period of time, and there is no way to tell for a PTO which of these previous check outs corresponds to the current check in with that same credit value. We suspect therefore that the privacy impact is insignificant.

Remarks

One meta conclusion of this work is that we need an efficient, frictionless, way to provide sender anonymity on the Internet, similar to the use of randomised MAC addresses that can be used on local networks. A VPN is too weak (the VPN provider sees everything its users do), yet Tor is too strong (there is no need to protect against a NSA like adversary). If randomised client IP addresses could be used by default to set up a TCP connection between a client and a server, that would already provide a tremendous boost in privacy on the Internet as servers can no longer trace their users based on their IP address.

The second meta conclusion of this work is that there is a need to make apps (or data in apps) uncloneable, so that they can be used in similar contexts and with similar properties as smart cards. Moreover, there should be a secure way to establish that the person holding the phone and/or using the app is indeed the owner of the phone (and not someone that uses the phone with permission of the real owner). These properties are also mandatory to increase the security of attribute credentials, in particular to prevent the attributes in them being pooled or shared. This seems challenging if at the same time we want the apps to be open source… One idea is to use either the SIM card present in most smartphones (but this requires cooperation with the mobile network operators), or to use the secure modules present in most smartphones.