Business Seminar - Technical Overview & Roadmap August 21, 2002 – Toronto Marc Kekicheff GlobalPlatform Technical Director August 21, 2002 – Toronto Marc Kekicheff GlobalPlatform Technical Director

GlobalPlatform Device Committee Agenda GlobalPlatform Card Committee GlobalPlatform Security Architecture & Business Relationship Models GlobalPlatform Technical Road-Map GlobalPlatform Systems Committee

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

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

Card Committee GlobalPlatform Card Specification 2.1 GP Security Requirements Specification GP Compliance GP Compliance

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

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

Flexibility & Choice Standardized Back-Office Procedures Proprietary Card Vendor OS Proprietary Card Vendor OS WfSC OS WFSC OS OR n Choice of Operating System e-Com LoyaltyAuthent.Access Credite-Purse n Choice of Applications Integrated Circuit Chips n Choice of Chip Platform WfSC VM & API WFSC VM & API Java Card VM & API n Choice of Runtime Environment GlobalPlatform Card Manager GlobalPlatform API

Application Management Framework Portability across OS/Platforms –Standardized processes and commands for load, install, removal –Files and data structures are application dependent, independent of OS/Platforms Application lifecycle independent of card lifecycle –Load, install, removal at any time 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 Generic process for pre and post-issuance with: –Different level of security requirements –Different delivery channels 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 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 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.

GlobalPlatform Security Architecture Roles and Responsibilities for: Card Issuer Application Provider Runtime Environment Card Manager Security Domain Applications Back-Office Systems  GP Security Requirements

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

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 Allow a multiplicity of trust models: –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 Application Developer Card Manufacturer SCMS Application Profiles  GP 2.1  Memory Space  Chip Req. VALID FROM GOOD THRU /00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU /00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU /00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU /00 CV R ELATIONSHIP C ARD Cards Applications Code Compatible ?? Card Profile  GP 2.1  Memory Space  Chip Req. Compatible Card Configuration GP 2.1 Memory Space Chip Req. GP 2.1 Memory Space Chip Req.

Scripting Specification Overview VALID FROM GOOD THRU /00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU /00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU /00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU /00 CV R ELATIONSHIP C ARD Cards Issuer KMS Application Providers Card Issuer SCMS Personalization Processing ?? App. Perso. Script Issuer Load Script Processing Issuer & App. Scripts Interpret & Execute Applications Code Applications Data App. KMS App. Database

Card Issuance and Post-Issuance Process

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

Agenda GlobalPlatform Technical Road-Map GlobalPlatform Device Committee GlobalPlatform Card Committee GlobalPlatform Security Architecture & Business Relationship Models GlobalPlatform Systems Committee

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

Activities Road-Map (1) ActivityCommitteeDateDescription Road Map Objectives Meet the needs of Issuers Define and promote cross- industry inter- operability Ensure adoption of the specs Promote open standards and infrastructure Remain relevant by improving technologies Business Requirements Collation & Evaluation Planning UnitOn-goingGather & screen business & functional requirements for future releases of GP specifications Product & Version Management Process Planning UnitOn-goingUpdate & maintain a product & version management process Compliance Process Planning UnitTBDDefine & maintain a compliance program and its procedures Cooperation with external organizations (ETSI, Sun, JCF, etc.) CardOn-goingPromote GP specifications and gather new technical & functional requirements

Activities Road-Map (2) ActivityCommitteeDateDescription Road Map Objectives Meet the needs of Issuers Define and promote cross- industry inter- operability Ensure adoption of the specs Promote open standards and infrastructure Remain relevant by improving technologies Card Spec. v2.1 maintenance v2.1 Q&A, Errata, FAQ CardOn-going Maintain v2.1 Card Specification & release any updates if needed Manage Q&A, release Errata & FAQ as needed Card Spec. v2.2/3.0 Card TBDEnhance v2.1 Card Specification w/ new Business & Technical Requirements Card Compliance Program & Compliance Kit CardApr-02Define a compliance program with the Card Specification (incl. procedures & tools) SCOPE Spec. Card Nov-02Define a basic OS functional framework supporting any secure runtime environment

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

Activities Road-Map (4) ActivityCommitteeDateDescription Road Map Objectives Meet the needs of Issuers Define and promote cross- industry inter- operability Ensure adoption of the specs Promote open standards and infrastructure Remain relevant by improving technologies CAMS model SCMS Req. SystemsFeb-02Define functional requirements for SCMS (incl. minimum req.) Profile Spec. v1.0 Scripting Spec. v1.0 SystemsAug-02Enhance & restructure CCSB spec. to include standard technology (XML, javascript) & other requirement SCMS Message Exchange Spec. SystemsOct-02Define a messaging spec. applicable to back-office system interfaces (SCMS, Perso Bureau, Post- issuance Server, Legacy systems)

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

THANK YOU THANK YOU