Business Seminar Technical Overview Roadmap August 21

Business Seminar Technical Overview & Roadmap August 21, 2002 – Toronto Marc Kekicheff Global. Platform Technical Director

Agenda Global. Platform Device Committee Global. Platform Card Committee Global. Platform Security Architecture & Business Relationship Models Global. Platform Systems Committee Global. Platform Technical Road-Map

Device Committee l Release of version 2. 0 of Global. Platform Device Framework Specification l MOU with STIP Consortium announced at Cartes 2001 l Objective is to offer a complete solution with the GPDF framework l STIP endorses Global. Platform application management definition l Dynamic device application management will be integrated in next release of GPDF specification Global. Platform Device Framework Specification 2. 0

GP Device Framework Business Logic Layer Select SID Service CLC Services API for Environment & Platform Dependent Services Device Application Card Directory Services CLC Module 1 … CLC Module n Core Logic Layer PIN Procesing Mag. Stripe Card Slot User Interface Storage Printer Cryptography Utilities Communications API for Environment & Platform Independent Services Environt. Services Layer Platform Layer

Card Committee GP Compliance Global. Platform Card Specification 2. 1 GP Security Requirements Specification

Any Application, Any Time, Any Where l Multiple Applications on a single card: è Market Segment of One l Cross-industry and card schemes interoperability è Any type of Application l Multiple Application Providers on a single card: è Multiple business partnerships è Any type of business models l Dynamic pre-issuance or post-issuance load / removal of Applications: 1. Anytime, Anywhere Access 2. Freedom and choice for cardholders

Multi-Application Card Management l Portability of Applications across chip-cards: è “Write Once, Run Anywhere”TM è Lower costs and faster time to market l Issuer has ultimate liability and responsibility towards cardholder: è Minimum on-card Issuer Control l Standardization of Smart Card Management Systems (application load, personalization, issuance, etc. ) è Any type of Operating System/Platform è Lower costs and faster time to market l Backward compatibility with existing terminals & back -end systems 1. Interoperability

Flexibility & Choice n Choice of Operating System Choice of Applications n Choice of Chip Platform n Choice of Runtime Environment Standardized Back-Office Procedures n e-Purse Credit Global. Platform Card Manager e-Com Global. Platform API Java Card Java API VM & Card Proprietary Card Vendor OS OS OR Integrated Circuit Chips Authent. Access WFSC Wf. SC VM & API WFSC Wf. SC OS OS Loyalty

Application Management Framework l Portability across OS/Platforms – Standardized processes and commands for load, install, removal – Files and data structures are application dependent, independent of OS/Platforms l Application lifecycle independent of card lifecycle – Load, install, removal at any time l Application lifecycle independent of each other – Separate lifecycle status – Separate application files and data store – One Loader/Personalizer per application (or set of applications) è Manages the coexistence of multiple applications on the same card

Card Management Framework l Generic process for pre and post-issuance with: – Different level of security requirements – Different delivery channels l Allow Issuance and Personalization process – – è In Centralized Personalization Bureau In walk-in situations (“instant issuance”) Over open networks (at home over the Net, over the air, etc. ) By multiple entities and multiple Application Providers Define a range of card and application management models: – From: Issuer Centric Model – To: Application Provider Empowered Model (“Delegated Management”) – Incl. : Controlling Authority Model

Secure Management Framework l Augment the Platform Runtime Environment security features: – Secure communication to the card = Secure Channel Protocol – Can’t load/remove an application without proper authority – Authenticity and integrity of application code verified during loading l Treat on-card applications as untrusted – Applications deploy their own security features è Establish clearly roles and responsibilities on-card and off-card: – Card Issuer – Application Providers – etc.

Global. Platform Security Architecture Roles and Responsibilities for: l Card Issuer l Application Provider l Runtime Environment l Card Manager l Security Domain l Applications l Back-Office Systems Ø GP Security Requirements

Issuer Centric Model Card Manager = Oncard representative of the primary Issuer Card Manager manages secure applet load, install, deletion

Delegated Management Model Application Provider Security Domain performs secure load, install, deletion of pre-approved applets

Controlling Authority Model Controlling Authority Security Domain verifies all loads of all applets

Business Relationship Models l Allow a multiplicity of trust models: – – l Controlling Authority Model Issuer Centric Model Application Provider Empowered Model Optional on-card “global” Cardholder Verification Method(s) Allow a multiplicity of privacy models: – Centralized back-office systems (SCMS, transactions, data capture, etc) – Distributed back-office systems (SCMS, transactions, data capture, etc) – Separation of applications by default (lifecycle, transactions, etc) – Limited secured on-card registry è Open to a multiplicity of business relationships – Card Issuer <-> Application Providers – Card Issuer / Application Providers <-> Cardholders

System Committee SCMS System v. 3. 4 Document

Card & App. Management System Flow

Profile Specification Overview ü GP 2. 1 q GP 2. 1 ü Memory q Memory Space ü Chip q Chip Req. q GP 2. 1 ü GP 2. 1 q Memory ü Memory Space q Chip Req. ü Chip Req. SCMS Card Profile Application Profiles Card Configuration Card Manufacturer Application Developer T RELAIONSHIPARD C VALID FROM 1989 VALID FROM GOOD THRU T RELAIONSHIPARD C 00/00 CV 1989 GOOD THRU T RELAIONSHIPARD C 00/00 CV 4000 VALID FROM 1989 VALID FROM 1234 GOOD THRU 5678 T RELAIONSHIPARD C 00/00 CV 1989 GOOD THRU 00/00 9010 Compatible ? ? CV Cards Applications Code

Scripting Specification Overview Issuer Load Script App. Perso. Script SCMS Card Issuer Personalization Issuer KMS T RELAIONSHIPARD C VALID FROM 1989 VALID FROM GOOD THRU T RELAIONSHIPARD C 00/00 CV 1989 GOOD THRU T RELAIONSHIPARD C 00/00 CV 4000 VALID FROM 1989 VALID FROM 1234 GOOD THRU 5678 T RELAIONSHIPARD C 00/00 CV 1989 GOOD THRU 00/00 9010 Applications Code Processing ? ? App. KMS CV Cards Issuer & App. Scripts Interpret & Execute Application Providers Applications Data App. Database

Card Issuance and Post-Issuance Process Application Development Card Manufacturer Updated GP Card Profile 1 and/or Specific Card Information 2 GP Application Profile + GP Load File Profile GP Script Interpreter GP Card Profile XML Parser Card Configuration SCMS Interface GP Application Profile + GP Load File Profile GP Card Profile Card Creation Script Card Personalization Personalized Smart Cards Data Verification Script Personalization Validation Card Customization Messaging 3 External Data Perso. Data File (i. e. , P 3 file) Profiles Updated GP Card Profile 1 and/or Specific Card Information 2 Data Prep. Script Personalization Data Preparation Application Specific Scripts Post Issuance Personalization Personalized Smart Cards

Typical Card Issuance and Post-Issuance Card Manufacturer Application Production Enablement Loading Chip. Mfg. (Mask) Issuer Post issuance load Integrity of on Card is cards, volume Depending theselects Ordersisenabled by There thenlicense no can be done by the application that personalized by loading appropriate andto add or delete applications and has fee application gets the Issuer using the loaded service isthe partner Issuer keys. Issuer stability, provider or by the optioninsured the to The applications from by Card Manager keys the manufacturer. card other to Issuer can also opt has option. Service withdelegatedhave / for Issuer’s Card or can be delegated management features Delegated applications masked Application Providers to an Application of Global. Platform Management of into ROM. Provider using Specification certain applications. Security Domains. Personalization Card Manager Master Keys Post Issue load Application Provider

Agenda Global. Platform Device Committee Global. Platform Card Committee Global. Platform Security Architecture & Business Relationship Models Global. Platform Systems Committee Global. Platform Technical Road-Map

Activities Inventory Requirements Planning Unit (Business Committee) § Sun MOU + Java Card Forum Cooperation § Eurosmart + SCSUG Cooperation § Business & Technical Card Requirements § STIP Cooperation Device Committee Management Process Collation & Evaluation Cooperation § Device Application Management Req. Compliance § Product & Version § Business Requirements § ETSI + 3 G SCP Card Committee Specifications § Compliance Process § Global. Platform Card Specification v 2. 1 maintenance § Global. Platform Card Security Requirements Specification § SCOPE Specification (ex-Open Kernel) § Global. Platform Card Specification v 2. 2/3. 0 § Card Compliance Program § Card Compliance Kit § v 2. 1 Q&A, Errata, FAQ § Export File for Java Cards § Application Developers Guidelines § Global. Platform Device Specification v 2. 0 § Device Application § Device Compliance Program Management Specification § Global. Platform System Profile Specification v 1. 0 § CAMS model Systems Committee § SCMS Requirements § KMS Requirements § Global. Platform System § Card Customization § KMS Specification § Systems Compliance Scripting Specification v 1. 0 § SCMS Message Exchange (incl. Perso Bureau, Postissuance Server) Guide Program

Activities Road-Map (1) Road Map Objectives Activity Committee Date Description Business Requirements Collation & Evaluation Planning Unit On-going Gather & screen business & functional requirements for future releases of GP specifications Product & Version Management Process Planning Unit On-going Update & maintain a product & version management process Compliance Process Planning Unit TBD Define & maintain a compliance program and its procedures Cooperation with external organizations (ETSI, Sun, JCF, etc. ) Card On-going Promote GP specifications and gather new technical & functional requirements Meet the needs of Issuers Define and promote crossindustry interoperability Ensure adoption of the specs Promote open standards and infrastructure Remain relevant by improving technologies

Activities Road-Map (2) Road Map Objectives Activity Card Spec. v 2. 1 maintenance Committee v 2. 1 Q&A, Errata, FAQ Description On-going Maintain v 2. 1 Card Specification & release any updates if needed On-going Card Date Manage Q&A, release Errata & FAQ as needed Card Spec. v 2. 2/3. 0 Card TBD Enhance v 2. 1 Card Specification w/ new Business & Technical Requirements Card Compliance Program & Compliance Kit Card Apr-02 Define a compliance program with the Card Specification (incl. procedures & tools) SCOPE Spec. Card Nov-02 Define a basic OS functional framework supporting any secure runtime environment Meet the needs of Issuers Define and promote crossindustry interoperability Ensure adoption of the specs Promote open standards and infrastructure Remain relevant by improving technologies

Activities Road-Map (3) Road Map Objectives Activity Committee Date Description Card Security Requirements Spec. Card Oct-02 Develop Security Requirements according to Common Criteria & facilitate security evaluation of GP cards Device Spec. v 2. 0 Device Jul-02 Update the OPTF v 1. 5 Specification to include STIP services & other requirements Device Application Management Requirements Device Oct-02 Define a structure for managing deployment of applications to various devices Device Compliance Program Device Oct-03 Define a program for testing compliance with the Device Specification Meet the needs of Issuers Define and promote crossindustry inter -operability Ensure adoption of the specs Promote open standards and infrastructure Remain relevant by improving technologies

Activities Road-Map (4) Road Map Objectives Activity CAMS model Committee Date Systems Feb-02 Define functional requirements for SCMS (incl. minimum req. ) Systems Aug-02 Enhance & restructure CCSB spec. to include standard technology (XML, javascript) & other requirement Systems Oct-02 Define a messaging spec. applicable to back -office system interfaces (SCMS, Perso Bureau, Postissuance Server, Legacy systems) SCMS Req. Profile Spec. v 1. 0 Scripting Spec. v 1. 0 SCMS Message Exchange Spec. Description Meet the needs of Issuers Define and promote crossindustry inter -operability Ensure adoption of the specs Promote open standards and infrastructure Remain relevant by improving technologies

Activities Road-Map (5) Road Map Objectives Activity Committee Date Description KMS Spec. Systems Oct-02 Define functional & technical requirements and develop a specification for key management systems System Compliance Program & Compliance Kit Systems Oct-03 Define a program for testing compliance with the System Specifications Meet the needs of Issuers Define and promote crossindustry inter -operability Ensure adoption of the specs Promote open standards and infrastructure Remain relevant by improving technologies

THANK YOU kekichef@globalplatform. org