Finally, after a year of work, the new mobile and self-print barcode standard for UK rail tickets has been approved by the central railway standards body, RSP, a part of ATOC.
The following post intends to give a more detailed understanding than that provided by the general media coverage.
It means that mobile ticket systems have the chance to come out of the limited scale "Advanced Purchase" projects that they have been providing so far. Train companies can now being to offer instant ticket purchasing that will bring a step change in user convenience.
Until now all of the UK rail mobile ticketing trials have used proprietary barcode formats, eligible for "advanced ticket" purchases only. These were valid on a limited set of single-operator routes, limiting their scope enormously.
Previous systems also had ticket scanning restrictions - the scanning device would either have to check all tickets against a central database using a WiFi or GSM connection, or carry a local database of valid tickets which had to be synchronised for every journey. Both of these methods have drawbacks - it is difficult to guarantee a network connection on a moving train, and obtaining one can take time slowing the scanning process; if a local database is used, the time that it is synchronized before a journey represents the last time that a mobile ticket may be purchased.
The new barcode standard has changed all of that. Firstly, one barcode format can now be used across all RSP/ATOC rail franchises. Secondly, by adding proven PKI security, scanners can check the validity of tickets without needing to be online. This is critical for any mass transit system - even after a total failure of the central server systems, thousands of travellers can still have their tickets scanned and pass through gates or guards without any delays (assuming the gates still have power!).
The Oyster system uses vulnerable symmetric cryptography, where the security keys are stored in every card and every scanner. In contrast, the new barcode standard uses asymmetric public/private key cryptography, which prevents anyone changing the content of a ticket after it has been issued. The private key which actually signs the ticket is kept safe on the rail operator's central ticketing server; the public key, which verifies the private key but cannot sign anything, is then installed on the scanners and ticket gates of every rail operator in the scheme.
Even if hackers completely take apart a guard's scanner or a barcode they will only be able to retrieve the freely available public key - they cannot make their own tickets unless they are also able to break 1024bit RSA at the same time. One day this will doubtless be possible, but no-one has yet and it forms the backbone of the HTTPS standard which secures every purchase and financial transaction you perform through your web browser.
The more cunning readers of this blog are correct in seeing the opportunity to photocopy a printed barcode, and then distribute the copies to other travellers who show them to different train guards - as long as each guard's scanner is offline and cannot verify the ticket with the central database. One commenter cleverly suggested using a radio jamming device to ensure that the guard would definitely be offline!
The travellers will 'get away with' the fraud, in that they can continue their journey. When the scanner gets back online or is synchronised at the end of the day, the post-processing systems will identify the multiple uses of the ticket and place an alert against the credit card used to purchase the original, preventing further purchases.
Once the fraud has been detected it is up to the Rail Operator or merchant to invite the user to pay a penalty and unlock their credit card, or (in extreme cases) pursue the credit card holder for the value of the fraudulent travel. If the fraud is detected during the journey and transport police are available, they may even choose to catch the travellers red-handed.
Whatever happens, the window of opportunity for fraud is limited to the period that the scanner is offline for each credit card that you are willing to 'throw away'. A fraudster using a stolen credit card (that hasn't yet been detected by back-end anti-fraud systems) may as well buy two tickets, but the overall scope is limited.
Unfortunately not. It is based entirely on open, proven, royalty free algorithms and standards. We designed it this way to encourage rapid uptake by operators and passengers; we hope that the other mobile ticketing vendors already servicing other rail operators adopt this system as soon as possible - so that those rail operators can agree to accept each other's mobile tickets, and expand the choice of routes for mobile ticketing.
Masabi have two mobile ticketing options:
Masabi's new downloaded application provides the full "ticket machine in your pocket" experience, where a brand new user can instantly buy tickets without any prior sign-up. They can buy tickets through their mobile from the back of a long queue, when the ticket machine at their rural station is broken, or from the back of a taxi on the way to the station. First time users type in their credit card number and CV2; repeat users only type their CV2 to confirm each purchase, with absolutely NO usernames or passwords to get in the way. See our ticketing page for more details.
Thankfully the new fare simplification process is cutting down the number of fare options on each route, especially for the "walk-up-tickets" that you buy in the station immediately before travelling. The mobile application makes a seperate price check with the server the first time that the user requests a ticket, and then uses those stored prices for any future purchase until the server indicates that they have changed, sending back new prices.
Nope, the Masabi ticket sales application is a Masabi product that rail operators, or the operators' ticket supplier, can choose to make available to their customers - we do a quick graphics job, a server integration and they're ready.
As long as all operators involved agree to use the new shared ticket standard, you should be able to buy a ticket from Operator A and travel on a route served by Operator B.
When the volume of tickets is small, guards or stations can operate a manual ticket check system by typing in the ticket number and requesting ticket details from the server, either by SMS or via their portable ticket computer. If the volume of tickets increases guards should be issued with barcode scanners - either the standalone pocket-sized scanners or a scanner integrated with their normal carry-on ticket machines. When volumes of barcode tickets get even higher, scanners can be fitted to their gates. Check out pictures of the scanner options here.
Masabi are already working closely with Atos Origin, one of the dominant rail infrastructure providers in the UK, who supply most of those portable ticket machines that Rail staff carry on the trains; the integration process can be handled by Atos if the rail operator wants.
Operators that already have a mobile ticketing system will need to ask their supplier to change the barcode format, which should in most cases simply be a software change.
The new barcode standard has only just been defined and approved by RSP, so it hasn't been used anywhere yet in it's final form. The Chiltern and Heathrow Express mobile ticket systems were built with barcode formats that pre-date the standards work, but the National Express East Coast system is running the final precursor to the actual RSP standard.
If you would like to know anything else, please ask away in the comments!