Friday, 14 January 2011

A secure ticketing system for Melbourne

Or: MyPKI.

Actually, this is sufficiently general that it could probably apply to any city, but I have Melbourne in mind as I write this. Though it has its faults, it IS still a great city to live in!

A public transport ticketing system has to cope with a large number of possibilities. It has to handle:

  • Regular commuters, taking regular services every day, and knowing they're going to do so for the foreseeable future;
  • Periodic travellers who might use the train a couple of times a month, and want it convenient when they do;
  • Short-term visitors, using PT for a fixed period before departing the city;
  • One-off trips with no prospect of using the system again any time soon.


  • Each of the demographics should pay for their use of the system;
  • Each of the demographics should feel that they are not over-paying;
  • Fraud should be discouraged and/or made unprofitable;
  • Neither travellers nor staff should be put to unnecessary effort.

To keep the costs down (important for goal #2), existing technology should be used whereever feasible. A smart card of some description allows a convenient touch-on/touch-off pattern, high throughput in peak time, and can be easily implemented. The current MyKi system is a little slow in its definition of "touch" (hold your card on the reader for a few seconds), but this can be improved upon.

The four demographics can be served well by a dual system: the smart card for those who wish to keep their long-term costs down, and some other system for those who care only about this one trip. For the latter system, cost is important. Anyone should be able to buy a bus ticket on the bus they're about to ride, a train ticket from the station where they intend to board, a tram ticket on the tram; and they should not have to "buy into" a system they're not going to use. This can easily be dealt with by having very simple (possibly coin-only) ticket vending machines which, rather than providing a smart card, provide a simple token valid for a single trip - a uniquely-numbered, cryptographically-signed slip of fax paper would suffice. The slip can identify the date and time of issue, and the fleet number of the vehicle on which it was bought, making fraud difficult; in the unlikely event of deliberate, systematic fraud, the cryptographic signature can be used to verify its origin.

For the longer-term travellers, a smart card makes a lot of sense. Have some kind of up-front cost (possibly just that you must buy a minimum of, say, $10 of credit) to cover the cost of production, and then reduce the per-trip costs to the point where no sane person would regularly travel on single-trip tickets (goal #4: don't make bus drivers fiddle with coins all the time). The card itself should store a very small amount of information; a card identifier and an account identifier would be sufficient (or even just the card identifier, with account information centralized too). A single account could plausibly have multiple cards associated with it (a company could have a fleet of tickets, all paid for on one bill), or a lost/stolen card could be disabled and a replacement sent out at a reasonable cost.

The smart card does not need to store much information, but it may be beneficial to have it cache some information. However, this cache would be invalidated by fleet ticketing and external top-up, and should not be relied upon. Important: For security, the card itself must NOT be the primary location for any significant data, especially not financial data. Such data must be stored centrally, to prevent unauthorized modification. As the Boston/MIT ticketing hack demonstrated, storing financial data on the card itself is inherently insecure; even encrypted, it is accessible, and brute-force attacks are straightforward when there is nothing to prevent rapid testing of keys.

The obvious consequences of central storage of all data are the significant server load, and the communication requirement. Server load can be handled by industry-standard database engines*. Requiring that all validators be networked, though, may pose a problem. It would require that every bus, every tram, and every railway station have a way to query the server and get back a response in no more than 250ms; any more than that, and the passenger has already moved away from the validator and the next person is trying to touch on/off. The card need not remain in contact with the reader for the full quarter-second, however; if the server reports insufficient funds in that account, the reader can beep a warning. With validator-controlled barriers, the networking requirement is slightly tighter; ideally, 100ms response time.

For railway stations, the solution is simple: Run a wired network along with all the other railway infrastructure. This will give easily enough throughput for 100ms response time. Trams may also be able to add infrastructure. For buses, however, it's not as easy. One option would be to use the 3G (mobile phone) network; another would be to have points at every stop where the bus can communicate back with base. Either way, the system must cope with the possibility of dropouts, by queueing requests and delivering them when able. With touching on, this may permit small-scale fraud; it would be possible for someone to board at a place known to have no coverage - by the time the driver is aware that someone is on the bus without a valid ticket, he's moved on, and probably doesn't know who of his passengers it is. However, it would not be difficult to "blacklist" any card (by its ID) when it goes below, say, negative $10, and have the blacklist cached on each validator, so that it will be refused if it attempts to validate when there is no contact.

Adding money to a card is of course crucial to the utility of the system. People should be able to recharge their cards at any railway station, via the internet, and possibly other ways. Of utmost importance is that this process be secure; if a fraudulent recharge station puts money onto a card without accepting money, the entire system collapses. The simplest and best solution here is to use public/private key encryption; digitally sign and encrypt all communication, and have every recharge station use a unique key pair. If anything is found to be suspect, that station can be configured "down", and it will then deny and be denied. This encryption and verification will add load to the servers, but recharging is a far less common operation than validating, and the comparative load would be insignificant.

There are a number of ways in which a malicious person might attempt to subvert this system. With sufficient logging, all can be recognized before they become a major problem, and dealt with or undone.

  • Attempting to edit one's own smart card will merely result in the invalidation of the cached records.
  • Sending forged recharge requests will be impossible without a genuine recharge station's private key.
  • Tampering with a recharge station to make it give free recharges would be detected as soon as its money box is counted, and could result in it being administratively disabled.
  • Recharging ridiculously small amounts (eg 20c at a time) in order to clog the servers could be prevented with a simple minimum recharge amount.
  • Randomly "zapping" other people's cards (eg by passing a validator through a crowded train) with a direct-charge marker (eg one used for buying a daily newspaper, as per MyKi's proposal) would log entries with the vendor's identification, similarly to current behaviour with credit cards.
  • Failing to validate could be conveniently checked for with hand-held validators.

In conclusion, there is nothing required which is beyond the realm of current technology; Melbourne deserves better than either Metcard or Myki has delivered - so far.

* In peak time, there will be roughly 2000 validations/minute; each validation might result in 1-2 database updates. A good database engine, running on a well-built cluster server, should be able to handle this without problems; see for example in which MySQL and connected open source software achieves 200,000 TPS, which would be enough for probably 50,000 validations per second, or 300K per minute. This is an extreme, but even with simpler and cheaper hardware, 5000 queries per second is an easy target for any good database engine; it may even be possible to manage on a single (non-cluster) server.

1 comment: