ApplePay is here in the UK and can be used on Transport for London rail and buses to pay for travel, effectively replacing contactless payment cards with a mobile-based solution. The underlying technology (the ‘contactless interface’, ISO/IEC 14443) is the same across Oyster, ITSO and international contactless payment cards from the likes of Visa, MasterCard and American Express.
So, why have we not seen other mobile implementations of either payments or smart ticketing? The TfL Oyster mobile app about to emerge is only addressing account management and will not allow customers to travel without their card.
Secure e-ticketing models
There are various models used for electronic ticketing systems around the globe and more are emerging as we speak. For this article, we would like to consider just three security differentiators:
- Contactless smart card: This is the traditional transit model where a tamper-resistant smart card chip is used to secure assets such as stored value and authentication keys. The transport operator or the public transport authority usually control the smart card and also take the full burden of issuing them.
- NFC mobile device with secure element: This is the traditional mobile e-ticketing solution. The assets held in the contactless smart card are migrated to be held in the secure element inside the near field communication (NFC) mobile device. The secure element is usually (but not always) the SIM card and therefore controlled by the mobile network operator. Recent experience in the payments industry of using this model shows that the commercial issues are very difficult to resolve. Apple has bucked the trend by issuing phones with their own secure element which, currently, only they can use and there is no talk yet of using it for transport applications.
- NFC mobile device with HCE: A new generation of mobile devices have an application program interface (API) known as host card emulation (HCE), which allows the contactless interface to be used without needing a secure element.
The HCE model allows any app provider to provide e-ticketing on NFC mobile devices. It is incumbent upon the HCE app provider to ensure there is sufficient security for the service being provided. The rest of this article discusses how a ticket vendor plans to trial such an HCE app to work in place of ITSO smart cards. ITSO is a smart ticketing specification partly funded by the Department for Transport in the UK.
The secure-enough approach
When travelling using a smart ticketing system, particular assets are needed in order to convince a point-of-service terminal that you have a valid right to travel at the time of presenting the mobile device. They might typically include:
- secret cryptographic keys for authentication with the point-of-service terminal;
- rights to travel (tickets).
The conventional smart card model stores long-life assets in the tamper-resistant hardware. Security professionals are well used to requiring certain levels of certification for tamper-resistant hardware used in standard solutions to keep valuable information assets safe. However, if there is no secure hardware to use in the security solution, then we have to get creative.
Without secure hardware on the mobile device, one option might be to store the assets in the cloud and download them as needed after appropriate authentication. After all, it is far easier to secure things in the cloud than on mobile devices.
However, for transport ticketing, transaction speed is often vital and there is no time to wait for such downloads when approaching a gated station or boarding a bus. Furthermore, the validation might be required where there is no network coverage. Therefore, the assets must be stored on the insecure mobile device and the question becomes, how can we secure them against potential attacks?
The strategy that we have adopted is to shorten the lifetime of assets and to find ways of hiding them on the mobile device from attackers. Ultimately, an attacker could always find the assets, given enough time. But our approach is to find ways of making their discovery take so long that by the time they are found, they have expired and can no longer be used as proof of rights to travel.
Consult Hyperion’s experience of implementing mobile payments using HCE mobile devices tells us that assets should have a lifetime of around one day and efforts are made to ensure that they take approximately 10 days for an attacker to discover. Clearly, this is not an exact science, but in the payments industry this has been tested using security labs to carry out penetration testing on HCE implementations.
What’s the user experience?
The work to date has been focusing on providing ITSO weekly season tickets on rail using HCE. Our high level design provides for the following use cases:
- Provisioning: Making the mobile device ready with the HCE app to buy tickets and receive assets to allow travel. This is usually done once.
- Purchase: Purchase a ticket for travel using Trainline’s mobile app.
- Refresh: Update the data in the HCE app over the air so that the customer is ready to travel.
- Redeem: Use the HCE app at a point-of-service terminal to prove the right to travel.
- Inspect: Allow a revenue inspector to check the travel rights in the HCE app being used for travel.
Risk analysis
Having done the high level design, we performed an information risk analysis. The physical model focused on the following entities:
- Mobile device: This is an insecure device with no secure hardware. It is susceptible to loss, theft and malicious software.
- Point of service terminal (POST), revenue inspection device and ITSO secure application module (ISAM): These are part of the existing ITSO infrastructure and will be unchanged during the trial.
- Networks and communications: Data to and from the mobile device is transmitted over open networks.
- Ticket vendor servers: Trainline will have a public-facing entry point to accept connections from mobile apps. This will be a potential attack surface and will need to be secured.
- Development site and app store: A mobile app compromised here will impact multiple users.
The logical model focused on the following information assets:
- HCE app: Confidentiality of crypto-related routines and data.
- IPE (ticket): The ITSO product entity (IPE), or electronic authority to travel, is protected by a cryptographic signature.
- Cryptographic keys: Some of these keys prevent cloning, provided they remain secret. Others are used to allow data updates to the device in standard ITSO POST processing.
The risk analysis identified the exposures against which we are now implementing controls in the detailed design:
- Server and firewall configuration: Including secure channels for data and communications.
- Secure development lifecycle: Physical and logical security.
- Mobile app hardening: State-of-the-art techniques will be used to prevent the discovery of keys and/or secret data.
We decided to add the HCE app to the physical model. This allows for the consideration of a ‘secure storage’ protection zone around sensitive logical assets. The main concern with ITSO HCE implementation is to prevent cloning of the tickets to other devices.
As mentioned above, the trial high level design seeks to ensure that assets expire before an attacker can exploit them. This is the focus of the trial solution now being developed.
The way forward
We understand the information security risks for implementing ITSO tickets with HCE mobile devices. We have built a prototype in Consult Hyperion’s Hyperlab that shows this approach works technically. Software teams from Trainline and Consult Hyperion are now working together to produce a production trial design and implementation fit for a limited trial.
Three models for smart ticketing were presented at the beginning of this article. We expect all three models can co-exist and provide options for the ticket issuers and ticket vendors to offer to their customers in the near future.
Many lessons are being learned along the way. We expect many more lessons will be learned during the trial, particularly around the user experience and customer care. It is hoped that the feedback from the trial will lead to extensions to the ITSO specification and certification process to accommodate HCE solutions from any ITSO members.
Acknowledgements
The author would like to thank ITSO (Steve Wakeland) and Trainline (Michael Moir) for permission to publish this article. ITSO has been funded by the Department for Transport for this HCE work.
