ITSO using Host Card Emulation Update for OAG meeting – 1 October 2015 Steve Wakeland, General Manager

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Customer First : Strategic Context and Opportunities Rory Mair.
Kerberos 1 Public domain image of Heracles and Cerberus. From an Attic bilingual amphora, 530–520 BC. From Italy (?).
HCE AND BLE UNIVERSITY TOMORROWS TRANSACTIONS LONDON, 20 TH MARCH 2014.
1 GP Confidential © GlobalPlatform’s Value Proposition for Mobile Point of Sale (mPOS)
The System Development Life Cycle
© 2005, QEI Inc. all characteristics subject to change. For clarity purposes, some displays may be simulated. Any trademarks mentioned remain the exclusive.
Smart Grid - Cyber Security Small Rural Electric George Gamble Black & Veatch
Security Controls – What Works
6/4/2015National Digital Certification Agency1 Security Engineering and PKI Applications in Modern Enterprises Mohamed HAMDI National.
Lesson 11-Virtual Private Networks. Overview Define Virtual Private Networks (VPNs). Deploy User VPNs. Deploy Site VPNs. Understand standard VPN techniques.
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
Iterative development and The Unified process
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
7.2 System Development Life Cycle (SDLC)
Computer Security: Principles and Practice
PCI's Changing Environment – “What You Need to Know & Why You Need To Know It.” Stephen Scott – PCI QSA, CISA, CISSP
©Ian Sommerville 2006Critical Systems Slide 1 Critical Systems Engineering l Processes and techniques for developing critical systems.
Software Life Cycle Model
Introduction to Network Defense
Release & Deployment ITIL Version 3
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
© 2012-Robert G Parker May 24, 2012 Page: 1 © 2012-Robert G Parker May 24, 2012 Page: 1 © 2012-Robert G Parker May 24, 2012 Page: 1 © 2012-Robert G Parker.
Solution Overview for NIPDEC- CDAP July 15, 2005.
SEC835 Database and Web application security Information Security Architecture.
Storage Security and Management: Security Framework
Pre-Project Activities Text Chapters 5 and 6. Pre-Project Activities 1.Contract Review 2.Development Plan 3.Quality Plan.
Remedies Use of encrypted tunneling protocols (e.g. IPSec, Secure Shell) for secure data transmission over an insecure networktunneling protocolsIPSecSecure.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Information Systems Security Computer System Life Cycle Security.
Slide 1 Using Models Introduced in ISA-d Standard: Security of Industrial Automation and Control Systems (IACS) Rahul Bhojani ISA SP99 WG4 Meeting.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
Integrating Security Design Into The Software Development Process For E-Commerce Systems By: M.T. Chan, L.F. Kwok (City University of Hong Kong)
Chapter 6 of the Executive Guide manual Technology.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Network Security Lecture 9 Presented by: Dr. Munam Ali Shah.
© 2013 Cisco and/or its affiliates. All rights reserved. This document is Cisco Confidential. For Channel Partners only. Do not distribute. C
Web Security for Network and System Administrators1 Chapter 2 Security Processes.
1 Chapter 5 Project management. 2 Project management : Is Organizing, planning and scheduling software projects.
1 Unit 1 Information for management. 2 Introduction Decision-making is the primary role of the management function. The manager’s decision will depend.
Eliza de Guzman HTM 520 Health Information Exchange.
Modernising Government Conference 29 October 2004 Mike Eastham Head of Technology ITSO Ltd.
PLANNING ENGINEERING AND PROJECT MANAGEMENT By Lec. Junaid Arshad 1 Lecture#03 DEPARTMENT OF ENGINEERING MANAGEMENT.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
Lecture 24 Wireless Network Security
Lesson 19-E-Commerce Security Needs. Overview Understand e-commerce services. Understand the importance of availability. Implement client-side security.
Security fundamentals Topic 5 Using a Public Key Infrastructure.
PNISG Update June Xoserve’s UKLP Assessment Principles 1.Maintain current delivery plans where possible and appropriate e.g. don’t just push all.
Software Engineering Lecture # 1.
Software Development Life Cycle (SDLC)
Risk Identification and Risk Assessment
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
Introduction to ITIL and ITIS. CONFIDENTIAL Agenda ITIL Introduction  What is ITIL?  ITIL History  ITIL Phases  ITIL Certification Introduction to.
E-Commerce E-Commerce Security?? Instructor: Safaa S.Y. Dalloul E-Business Level Try to be the Best.
Installation and Maintenance of Health IT Systems Unit 8a Troubleshooting; Maintenance and Upgrades; and Interaction with Vendors, Developers, and Users.
Chang, Wen-Hsi Division Director National Archives Administration, 2011/3/18/16:15-17: TELDAP International Conference.
© NALO Solutions Limited NALO Solutions, presents the – Revenue Collector App Using Mobile Phones to gather Revenue SOFTWARE ENGINEERING.
Impact Research 1 Deploying Wireless LANs for Business Benefit Summary Document.
OUTCOMES OBJECTIVES FUNCTIONS ACTIONS TERRITORIES LOCATIONS MARKET SEGMENTS TIME LINESCHALLENGE IMPACT RESOURCESACTIVITIESCHANNELS RELATIONS PARTNERS CUSTOMERS.
Computer Security Sample security policy Dr Alexei Vernitski.
Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu.
The System Development Life Cycle
Software Project Configuration Management
Transforming business
Control system network security issues and recommendations
Software Requirements
The System Development Life Cycle
LO2 - Be Able to Design IT Systems to Meet Business Needs
Strategic Environmental Assessment (SEA)
Presentation transcript:

ITSO using Host Card Emulation Update for OAG meeting – 1 October 2015 Steve Wakeland, General Manager

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.

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).

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.

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.

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.

High Level Design

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Any other questions