1. ITSO using Host Card Emulation Update for OAG meeting – 1 October 2015 Steve Wakeland, General Manager steve.wakeland@itso.org.uk

2. Introduction Work has been ongoing since early 2015 to explore how Host Card Emulation (HCE) might be used on NFC mobile devices to replace ITSO cards. ‘Assets’ secured in smart card tamper-resistant chips are more vulnerable if stored on HCE devices without suitable countermeasures (controls). This work has progressed through options analysis, high level design and prototyping and plans are being made for a trial of the HCE on a live ITSO scheme. These slides contain summary details of the High-Level Design and Structured Risk Assessment (with added reference to the trial). The more detailed documentation is available to all members who wish to see it.

3. Proving the concept Options analysis: Considered the widest range of potential solutions for ITSO with HCE with minimal changes to ITSO infrastructure. High Level Design: Drawn up by Consult Hyperion for use in a trial on a live ITSO scheme led by The Trainline. Reviewed by an ‘ITSO with HCE Working Group’ (IHWG); representatives from DfT, ITSO, Consult Hyperion, Ecebs and The Trainline. Structured Risk Analysis: Carried out by Consult Hyperion and resulting in recommendations for controls that should be in place during the trial. The SRA was reviewed by the (IHWG).

4. Proving the concept (2) Lab-based proof of concept: Carried out by Consult Hyperion to show that the technical approach in the HLD is viable. The architecture employed for this work comprised the following: ITSO POST containing a test ISAM and the keys to authenticate a CMD2 and verify a TYP22 weekly season IPE. Android mobile device with an HCE app emulating sufficient CMD2 functionality to be able to allow an unmodified ITSO POST to carry out mutual authentication and verify the directory the IPE held within the CMD2 emulation. The HCE app allowed the customer to ‘purchase’ a weekly season ticket and to receive OTA updates to the ITSO shell (and keys), directory and IPE. MS Windows Laptop with processes representing the ticketing sales and fulfilment servers. There was no HOPS functionality implemented. Minimal security measures were implemented. In particular, ITSO data in the Android app was not protected against attacks. For convenience, a local WiFi network was used, rather than the mobile data network.

5. Production Trial Development Following the proof-of-concept, a joint development team (Consult Hyperion and Trainline) built the components for a production trial: Android App functionality: ITSO card emulation with functional scope and robustness for a production trial. User interface functionality to support a production. Back office integration as necessary to support the handset functions. Back-office functionality Services to carry out those back office functions for a production trial, implemented consistently with the High Level Design. This includes: Responding to fulfilment requests from handsets. Acting as a PERSO-post to generate valid ITSO shells as required. Generating valid ITSO IPEs as required. Delivering the Shells and IPEs to the handset OTA in the manner prescribed by the high-level design. Interaction with the HOPS as is appropriate given the functions being performed.

6. Production Trial Development (2) Development in the area is ongoing. Sufficient development work has been completed so that handset functionality can be demonstrated outside the lab environment in the form of a portable demonstrator. In parallel with development activity we have entered into discussions with a number of members with a view to identifying an appropriate ITSO scheme operator to participate as a partner in the trial process.

7. High Level Design

8. High Level Design – General Approach No secure element to store keys and other assets on the mobile. Customers need these to prove right to travel. So, limit the usefulness of the assets and the liability associated with their compromise. The ways of limiting the usefulness of the assets are: Shortening the lifetime of the assets so that by the time an attacker has found them they have low value. Making the assets hard to find so that they expire before an attacker is able to exploit them. For this HLD, it is not yet clear what constraints need to be put on allowed IPEs, but we propose that not all IPE types be allowed: Season tickets will be allowed since they can easily be translated into multiple daily tickets issued OTA each day. These could be implemented as TYP22. This is the only IPE type to be allowed for the trial (see Section 5). Further work is needed to determine what other IPE types to allow.

9. High Level Design – Use Cases/Constraints The use cases below cover all functionality included in the HLD, and are the ones expected to be used in the trial: Provisioning: Make device ready for ITSO ticketing: Purchase: Purchase and fulfil an ITSO ticket: Refresh: Refresh the travel rights periodically (roughly daily during the ticket validity): Redeem: Use ITSO ticket travel rights for daily train travel: Inspect: Revenue inspection on a train or platform These are the constraints that were known about when the HLD was created. Mobile device: HCE is currently only available on Android NFC mobile devices and so any prototyping and trials would make use of these devices Minimal changes to ITSO infrastructure: The aim was for the HCE HLD to work with existing ITSO infrastructure with minimal changes. The proposed trial requires no changes. CM type: The only CM type within the current ITSO specification that fulfils the requirements of HCE is CMD2, Generic Microprocessor.

10. Risk Analysis - models The physical model is used to determine where the vulnerabilities lie: Mobile device: inherently insecure since secure hardware cannot be assumed. It is susceptible to loss, theft and malicious software. POST/RID and ISAMs: These are part of existing ITSO infrastructure. Networks & communications: Transmitted over open networks - assumed insecure. Ticket vendor servers: Vendors will have a public-facing entry point on their servers to connections from ITSO-with-HCE mobile apps. These are potential attack areas. Development site/app store: Mobile app compromised here will impact multiple users. The logical model assets considered for the risk analysis: HCE App: By including the HCE App itself, we were able to consider providing a secure storage protective zone around assets: Confidentiality of crypto routines & data: prevent discovery of keys and/or secret data. Integrity of app: prevent unauthorised modifications. IPE (ticket): IPE is protected by a seal; the main concern is to prevent cloning. MA/SM keys: These keys prevent cloning, provided they remain secret. Derived from the ISSN and other data using a secret master key in the ISAM. Passkeys: Allow data updates in standard ITSO processing. Derived from the ISSN and other data using a secret master key in the ISAM, and then used as passwords to allow writing of sectors. IIN/OID, ISSN, Shell expiry: Not critical in themselves, but may feed into the security mechanisms chosen.

11. Risk Analysis: countermeasures for trial The risk analysis lead to the following controls to implement HLD: Appropriate server & firewall configurations: Including TLS communications and secure data channels when delivering Shell and IPE data (including MA keys and passkeys) OTA to the device. Secure development life cycle: physical and logical security Mobile app hardening: Addition of secure storage. Obfuscation of the compiled code in the app to make recovery of sensitive data (e.g. keys) sufficiently time consuming. Changing ISSN for each IPE (or set of IPEs): Ensures that the MA keys (and passkeys) change regularly (daily). Limited CMD2 emulation: Designed to refuse all updates from a POST except for transient tickets. Other controls planned for use in the trial include: Using a separate HOPS to minimise the risk of impacting on live ITSO scheme business as usual. Using a separate OID to separate out all the ITSO-with-HCE IPEs, shells and transactions from all other live ITSO scheme transactions. Analysis of transactions collected at the HOPS and reporting to identify anomalies, whether these be related to security or otherwise. This will also allow the rapid detection of fraud and controlled response should that become necessary.

12. Risk Analysis: future changes after trial The HLD required the Shell to be replaced every day that a ticket is valid since this is the only way to expire the MA keys without changing the specification for CMD2. Issuing new Shells every day for each customer with a valid ticket is not convenient and also impacts the way that customers are managed in the HOPS. The following modifications to ITSO have been proposed to solve these problems: New Key Strategy Code (KSC): By including the MA key expiry date within the key derivation, it will be possible to retire keys without having to change the ISSN. This could be implemented either as a new KSC for CMD2 (minimal change to ITSO) or as a new CM type (see below). This would require an update to the ISAM and probably to the POSTs as well. New CM type: In the future, ITSO might also want to define a new CM type for HCE. If this happened it would probably be a completely new design for HCE, rather than an incremental change from CMD2.

13. Trial - Objectives Primary objectives would be as follows: To establish the viability (or otherwise) of using an HCE-based solution, with current technology, to emulate selected functionality of an ITSO smartcard in a production environment. Through conducting the trial, to learn as much as we can, in a controlled environment, with a view to incorporating those learnings into a subsequent architecture and design which is suitable for open and broad adoption within the rail industry.

14. Trial - Approach Start within a very limited and controlled environment Progress through various phases of trial expansion, based on lessons learned and the extent to which identified challenges have been appropriately addressed. Parameters can be managed at each phase to ensure an appropriate balance of risk and learning. These include: The hardware being used. Specific trial handsets may be supplied for early phases, but then opened up to users own devices during later phases. In the same way the range of posts and/or validators can be broadened over time through route selection. Route selection. The range of routes, and value of the tickets in the trial can be managed. Users. The number and nature of participants can be managed, from TOC staff through to a selected number of public participants. Duration. The duration of the trial can be managed.

15. Trial – Approach (2) Based on discussions to date, the proposed phases are as follows: Phase 1 – Staff only: a small number of staff with trial-specific handsets, useable on very limited routes, perhaps for a period of four weeks Phase 2 – Public participation – supplied handsets: members of the public (perhaps 10) who normally commute on the selected routes will be provided with handsets Phase 3 – Public participation – user handsets: trial will be progressively opened to a larger volume of public users (eventually greater than 100) who make use of their own handsets (within a defined group of supported handsets) Appropriate checkpoints and reviews will take place before progressing from one phase to the next. On completion of Phase 3 the results and analysis will be collated and distributed to a wider audience, with this material then being made available to appropriate groups. At this point also the key stakeholders will be asked to determine the future of the trial from that point forwards.

16. Trial – Success Measures The ideal outcome for the trial would be to identify and address all presenting challenges, and to ultimately validate that current handset HCE implementations, with an appropriate solution architecture and operational support, can be used in a secure, practical, and economically viable way as an ITSO smartcard alternative. The measure of success for the trial will be to reach a point where a realistic assessment can be made of the employed technologies, architecture, and operations, so that the findings are instrumental in defining enhanced HCE-supporting standards as soon as the technologies are sufficiently mature.

17. Other Factors to consider This project is generating considerable interest and we’ve had numerous offers from members who want to participate in early trials. However, we have to manage trials carefully to ensure that they are properly controlled. We need to consider how to draw more of the HOPS providers into the discussions so that they can deliver for a broader membership base. We are considering whether we should have a ‘white-label’ cardlet and mobile app for those operators who do not want to (or have the resources to) develop their own

18. Any other questions