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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17. System Committee SCMS System v. 3.4 Document

18. Card & App. Management System Flow

19. Profile Specification Overview Application Developer Card Manufacturer SCMS Application Profiles  GP 2.1  Memory Space  Chip Req. VALID FROM GOOD THRU 198900/00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU 198900/00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU 198900/00 CV 4000 1234 5678 9010 R ELATIONSHIP C ARD VALID FROM GOOD THRU 198900/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.

20. Scripting Specification Overview VALID FROM GOOD THRU 198900/00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU 198900/00 CV R ELATIONSHIP C ARD VALID FROM GOOD THRU 198900/00 CV 4000 1234 5678 9010 R ELATIONSHIP C ARD VALID FROM GOOD THRU 198900/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

21. Card Issuance and Post-Issuance Process

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

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

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

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

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

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

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

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

30. THANK YOU kekichef@globalplatform.org THANK YOU kekichef@globalplatform.org