business seminar - technical overview & roadmap

Business Seminar - Technical Overview & Roadmap

Business Seminar - Technical Overview & Roadmap

August 21, 2002 – Toronto

Marc KekicheffGlobalPlatform Technical Director

August 21, 2002 – Toronto

Marc KekicheffGlobalPlatform Technical Director

GlobalPlatform Device Committee

AgendaAgenda

GlobalPlatform Card Committee

GlobalPlatform Security Architecture & Business Relationship Models

GlobalPlatform Technical Road-Map

GlobalPlatform Systems Committee

Device CommitteeDevice 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

GlobalPlatformDevice Framework

Specification2.0

http://www.stip.org/aboutstip.htm

Business Logic Layer

Select SIDService

CLC Services

Card DirectoryServices CLC Module 1 CLC Module n…

Utilities

Co

mm

un

icat

ion

s

Cry

pto

gra

ph

y

Pri

nte

r

Sto

rag

e

Use

r In

terf

ace

Car

d S

lot

Mag

. Str

ipe

PIN

Pro

cesi

ng

Environt.ServicesLayer

Platform Layer

Core Logic Layer

API for Environment & Platform

Independent Services

API for Environment & Platform

Dependent Services

GP Device FrameworkGP Device Framework

DeviceApplication

Card CommitteeCard Committee

GlobalPlatformCard Specification

2.1

GP Security Requirements Specification

GPCompliance

GPCompliance

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 ManagementMulti-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 & ChoiceFlexibility & Choice

Standardized Back-Office Procedures

Proprietary Card VendorOS

Proprietary Card VendorOS

WfSCOS

WFSCOSOR

Choice of Operating System

e-Com LoyaltyAuthent. AccessCredite-Purse

Choice of Applications

Integrated Circuit Chips

Choice of Chip Platform

WfSCVM & API

WFSCVM & APIJava Card

Java CardVM & API

Choice of Runtime Environment

GlobalPlatformCard

Manager

GlobalPlatformAPI

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 FrameworkSecure 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 ArchitectureGlobalPlatform 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 ModelIssuer Centric Model

Runtime Environment

OPEN

IssuerSecurityDomain

GP API RTE APICa

rd M

an

ag

er

Card IssuerApplet Y

Card IssuerApplet X

Card Manager manages secure

applet load, install, deletion

Card Manager = On-card

representative of the primary Issuer

Runtime Environment

OPEN


GP API RTE API

Application ProviderSecurity Domain

Ca

rd M

an

ag

er

Card IssuerApplet X

Delegated Management ModelDelegated Management Model

Application ProviderApplet Y

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

Runtime Environment

OPEN


GP API RTE API

Application ProviderSecurity Domain

Card

Man

ag

er

Controlling AuthoritySecurity Domain

Controlling Authority ModelControlling Authority Model

Application ProviderApplet Y

Card IssuerApplet X

Controlling Authority Security Domain verifies all loads of all applets

Business Relationship ModelsBusiness 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 CommitteeSystem Committee

SCMSSystem v. 3.4

Document

Card & App. Management System FlowCard & App. Management System Flow

6M a n ufa c tu re r

KM A

3IC

M a n ufa c tu r e r

2C a rd

M a n ufa c tu r e r

1C a rd

I s s ue r

1 1P l a tfor m

K M A

8App li c a ti on

O w n e r

1 3Ap p li c a tio n

Lo a d e r1 2

Ca r dh ol de r

P ro vid eC a rd s

O rd e rCa rd s

P ro vid eA p p lica t io n

L o a d file s / u n its

P ro v id eA p p lic a t io n

L o a d / D e le te

Re q u e s tA p p lica t io n

L o a d / De le t e

P ro vid e Ca rd

P ro vid e A p p lica t io nL o a d file s / u n its & k e ys ,

& p e rs o n a lisa t io n d a ta

P ro v id e A u t h o rit y to lo a d / d e le t e

t o s p e c ific ca rd s

R e q u e s t A u t h o r ity t olo a d / d e le te

t o s p e c ific c a rd s

Re q u e s tA p p lica t io n

L o a d f ile s / u n it s

Re q u e s t C a rdE n a b le m e n t d a ta / k e ys

P ro vid e Ca rdE n a b le m e n t d a t a /k e ys

P ro vid e In it ia l tra n sp o rt k e y

P ro vid e I n itia l tra n s p o rt k e y (M U L TO S )

P ro v id eI n it ia lise d C h ip s

O rd e r C h ip s

P ro v id e C a rd s,

p la t fo rm d a t a a n d ca rd ke y s

P ro v id eA p p li ca t io n

Co d e

9App li c a ti onD e v e lo pe r

S p e cif yA p p lica t io n

R e q u ire m e n ts

1 0App l ic a ti on

K M A

Re q u e stA p p lica t io n

K e ys

P ro v id eA p p lic a tio n

K e y s

7Ap pl ic a ti o n

P r ov i de r

5P l a tfo rm

S p e c i f ic a ti onO w ne r

4P l a tfor m

De v e l op e r

P ro vid e RO M c o d ef o r m a s kin g

P ro vid eP la t fo rm

S p e c ific a t io n

P ro vid e A P IS p e c ific a t io n

1 4Ca r d E n a bl e r

P ro v id eE n a b le d c a rd s

P ro vid e S e cu r it yDo m a in ke y s & d a ta (O P )

P ro vid e In it ia l tra n s p o rt k e y (O P )

Co n f irmlo a d / d e le te

d e ta ils

Profile Specification OverviewProfile Specification Overview

ApplicationDeveloper

Card Manufacturer

SCMSApplication

Profiles

GP 2.1 Memory Space Chip Req.

VALIDFROM

GOODTHRU1989 00/00 CV

RELATIONSHIP CARD

VALIDFROM


RELATIONSHIP CARD

VALIDFROM


4000 1234 5678 9010

RELATIONSHIP CARD

VALIDFROM


RELATIONSHIP CARD

CardsApplications

Code

Compatible??

CardProfile


Compatible

CardConfiguration



Scripting Specification OverviewScripting Specification Overview

VALIDFROM


RELATIONSHIP CARD

VALIDFROM


RELATIONSHIP CARD

VALIDFROM


4000 1234 5678 9010

RELATIONSHIP CARD

VALIDFROM


RELATIONSHIP CARD

Cards

Issuer KMS

ApplicationProviders

Card Issuer

SCMS

Personalization

Processing??

App.Perso.Script

Issuer LoadScript

Processing

Issuer & App. Scripts

Interpret & Execute

ApplicationsCode

ApplicationsData

App. KMS

App. Database

Card Issuance and Post-Issuance ProcessCard Issuance and Post-Issuance Process

GP Application Profile + GP Load File ProfileGP Card Profile

Profiles

ApplicationDevelopment

Data Prep. Script

PersonalizationData

Preparation

Perso. Data File (i.e., P3 file)Perso. Data File (i.e., P3 file)

External Data

Card Creation Script

CardPersonalization

Personalized Smart Cards

Data Verification Script

PersonalizationValidation Personalized

Smart Cards

SCMS

CardManufacturer

GP Card Profile

GP Application Profile + GP Load File Profile

Updated GPCard Profile1

and/or Specific Card Information2

Updated GPCard Profile1

and/or Specific Card Information2

XML Parser

Interface

Card Configuration

GP Script Interpreter

Post IssuancePersonalization

Application Specific Scripts

Personalized Smart Cards

Card Customization Messaging3

Typical Card Issuance and Post-IssuanceTypical Card Issuance and Post-Issuance

IssuerCard ManagerMaster Keys

Personalization

Chip. Mfg.

(Mask)

EnablementProduction

Card ManufacturerApplication

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

AgendaAgenda

GlobalPlatform Technical Road-Map

GlobalPlatform Device Committee

GlobalPlatform Card Committee

GlobalPlatform Security Architecture & Business Relationship Models

GlobalPlatform Systems Committee

Activities InventoryActivities 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

ComplianceSpecificationsRequirements

Activities Road-Map (1)Activities Road-Map (1)

Activity Committee Date Description

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



Road Map Objectives


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

Card On-going

On-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 TBD Enhance v2.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



Road Map Objectives


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.

Card Oct-02 Develop Security Requirements according to Common Criteria & facilitate security evaluation of GP cards

Device Spec. v2.0

Device Jul-02 Update the OPTF v1.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



Road Map Objectives






CAMS model

SCMS Req.

Systems Feb-02 Define functional requirements for SCMS (incl. minimum req.)

Profile Spec. v1.0

Scripting Spec. v1.0

Systems Aug-02 Enhance & restructure CCSB spec. to include standard technology (XML, javascript) & other requirement

SCMS Message Exchange Spec.

Systems Oct-02 Define a messaging spec. applicable to back-office system interfaces (SCMS, Perso Bureau, Post-issuance Server, Legacy systems)



Road Map Objectives






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

THANK YOU

[email protected]

THANK YOU

[email protected]

business seminar - technical overview & roadmap

Documents

card applications

single card

application management

application dependent

range of card

integrity of application

card schemes interoperability

security featuresestablish