Transcript GlobalPlatform Business Seminar Tokyo February 2002

Business Seminar Technical Overview & Roadmap
August 21, 2002 – Toronto
Marc Kekicheff
GlobalPlatform Technical Director
Agenda
GlobalPlatform Device Committee
GlobalPlatform Card Committee
GlobalPlatform Security Architecture
& Business Relationship Models
GlobalPlatform Systems Committee
GlobalPlatform Technical Road-Map
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
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
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
GlobalPlatform
Card Specification
2.1
GP Security Requirements Specification
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
 Choice of Operating System
Choice of Applications
 Choice of Chip Platform  Choice of Runtime Environment
Standardized Back-Office Procedures

e-Purse
Credit
GlobalPlatform
Card
Manager
e-Com
GlobalPlatform
API
Java Card
Java
VM
& Card
API
Proprietary
ProprietaryCard
CardVendor
Vendor
OS
OS
OR
Integrated Circuit Chips
Authent.
Access
WFSC
WfSC
VM
VM&&API
API
WFSC
WfSC
OS
OS
Loyalty
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
Card Manager =
On-card representative
of the primary Issuer
Card Issuer
Applet Y
Card Issuer
Applet X
Issuer
Security
Domain
GP API
OPEN
Runtime Environment
RTE API
Delegated Management Model
Application Provider
Security Domain
Application Provider
Security Domain
performs secure
load, install, deletion
of pre-approved
applets
Card Manager
Application Provider
Applet Y
Card Issuer
Applet X
Issuer
Security
Domain
GP API
OPEN
Runtime Environment
RTE API
Controlling Authority Model
Controlling Authority
Security Domain
Controlling Authority
Security Domain
verifies all loads of
all applets
Application Provider
Security Domain
Card Manager
Application Provider
Applet Y
Card Issuer
Applet X
Issuer
Security
Domain
GP API
OPEN
Runtime Environment
RTE API
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
4
P l a tfor m
De v e l op e r
P ro vid e RO M c o d e
f o r m a s kin g
Re q u e s t C a rd
E n a b le m e n t d a ta / k e ys
P ro vid e A P I
S p e c ific a t io n
P ro vid e In it ia l
tra n s p o rt k e y (O P )
P ro vid e I n itia l
tra n s p o rt k e y (M U L TO S )
11
P l a tfor m
K MA
P ro v id e
O rd e r C h ip s
I n it ia lise d C h ip s
5
P l a tfo rm
S p e c i fic a ti on
O w ne r
6
M a n ufa c tu re r
KM A
P ro vid e In it ia l
tra n sp o rt k e y
3
IC
M a n ufa c tu r e r
P ro vid e
P la t fo rm
S p e c ific a t io n
14
Ca r d E n a bl e r
P ro vid e Ca rd
E n a b le m e n t d a t a /k e ys
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 e
E n a b le d c a rd s
P ro vid e
C a rd s
P ro v id e
A p p li ca t io n
Co d e
1
C a rd
I s s ue r
R e q u e s t A u t h o rity t o
lo a d / d e le te
t o s p e c ific c a rd s
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
P ro vid e Ca rd
7
Ap pl ic a ti o n
P r ov i de r
Co n f irm
lo a d / d e le te
d e ta ils
12
Ca r dh ol de r
P ro v id e
A p p lic a t io n
L o a d / D e le te
Re q u e s t
A p p lica t io n
L o a d / De le t e
13
Ap p li c a tio n
Lo a d e r
S p e cif y
A p p lica t io n
R e q u ire m e n ts
P ro vid e S e cu rit y
Do m a in ke y s & d a ta (O P )
P ro vid e
A p p lica t io n
L o a d file s / u n its
O rd e r
Ca rd s
2
C a rd
M a n ufa c tu r e r
9
App li c a ti on
D e v e lo pe r
P ro vid e A p p lica t io n
L o a d file s / u n its & k e ys ,
& p e rs o n a lisa t io n d a ta
Re q u e s t
A p p lica t io n
L o a d f ile s / u n it s
P ro v id e
A p p lic a tio n
Key s
Re q u e st
A p p lica t io n
K e ys
10
App l ic a ti on
K MA
8
App li c a ti on
O w n er
Profile Specification Overview
 GP

GP 2.1
2.1
 Memory

Memory
Space
Space
 Chip

Chip Req.

GP2.1
2.1
 GP

Memory
 Memory
Space
Space
 Chip
Chip Req.
Req.

SCMS
Card
Profile
Application
Profiles
Card
Configuration
Card
Manufacturer
Application
Developer
RELATIONSHIPCARD
VALID
FROM
1989
VALID
FROM
GOOD
THRU
RELATIONSHIPCARD
00/00 CV
1989
GOOD
THRU
RELATIONSHIPCARD
00/00 CV
4000
VALID
FROM
1989
VALID
FROM
1234
GOOD
THRU
5678
9010
RELATIONSHIPCARD
00/00 CV
1989
GOOD
THRU
00/00
Compatible
Compatible
??
CV
Cards
Applications
Code
Scripting Specification Overview
Issuer
Load
Script
App.
Perso.
Script
SCMS
Card Issuer
Personalization
Issuer KMS
Applications
Code
Application
Providers
RELATIONSHIPCARD
VALID
FROM
1989
VALID
FROM
GOOD
THRU
RELATIONSHIPCARD
00/00 CV
1989
GOOD
THRU
RELATIONSHIPCARD
00/00 CV
4000
VALID
FROM
1989
VALID
FROM
1234
GOOD
THRU
5678
9010
RELATIONSHIPCARD
00/00 CV
1989
GOOD
THRU
00/00
Processing
Processing
??
App. KMS
CV
Cards
Issuer & App.
Scripts
Interpret & Execute
Applications
Data
App. Database
Card Issuance and Post-Issuance Process
Application
Development
Card
Manufacturer
Updated GP
Card Profile1
and/or Specific
Card Information2
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
Messaging3
External
Data
Perso. Data File
(i.e., P3 file)
Profiles
Updated GP
Card Profile1
and/or Specific
Card Information2
Data Prep.
Script
Personalization
Data
Preparation
Application
Specific Scripts
Post Issuance
Personalization
Personalized
Smart Cards
Personalized
Smart Cards
Typical Card Issuance and Post-Issuance
Card Manufacturer
Application
Production Enablement
Loading
Chip. Mfg.
(Mask)
Personalization
Issuer
Post issuance load
Integrity
Orders
Depending
There
Card
isiscards,
enabled
then
of
nothe
on
license
selects
volume
by
can be done by the
applications
and
loading
fee
personalized
application
to
application
add
appropriate
or
that
and
delete
bygets
has
the Issuer using the
the option
stability,
Issuer
applications
service
loaded
keys.
is
provider
the
insured
toIssuer
from
partner
Theorthe
byby
Card Manager keys
withdelegated
has
Issuer
Issuer’s
card
the
option
other
manufacturer.
can
Card
Service
also
to have
opt/
or can be delegated
Application
applications
for
management
Delegated
Providers
masked
features
to an Application
into
Management
of
GlobalPlatform
ROM.
of
Provider using
certain applications.
Specification
Security Domains.
Card Manager
Master Keys
Post Issue
load
Application
Provider
Agenda
GlobalPlatform Device Committee
GlobalPlatform Card Committee
GlobalPlatform Security Architecture
& Business Relationship Models
GlobalPlatform Systems Committee
GlobalPlatform Technical Road-Map
Activities Inventory
Requirements
Planning Unit
(Business Committee)
Card Committee

ETSI + 3G SCP
Cooperation

Sun MOU + Java Card
Forum Cooperation


Device Committee
Systems Committee
Business Requirements
Collation & Evaluation


GlobalPlatform Card
Specification v2.1
maintenance

GlobalPlatform Card
Security Requirements
Specification
Eurosmart + SCSUG
Cooperation

Business & Technical
Card Requirements
SCOPE Specification
(ex-Open Kernel)

GlobalPlatform Card
Specification v2.2/3.0

GlobalPlatform Device
Specification v2.0

STIP Cooperation

Device Application
Management Req.

CAMS model

SCMS Requirements

KMS Requirements
Compliance
Specifications

Product & Version
Management Process

Compliance Process

Card Compliance
Program

Card Compliance Kit

v2.1 Q&A, Errata, FAQ

Export File for Java
Cards

Application Developers
Guidelines

Device Compliance
Program

Device Application
Management Specification

GlobalPlatform System
Profile Specification v1.0

GlobalPlatform System
Scripting Specification v1.0

Card Customization
Guide

KMS Specification


SCMS Message Exchange
(incl. Perso Bureau, Postissuance Server)
Systems Compliance
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.
v2.1
maintenance
Committee
Card
v2.1 Q&A,
Errata, FAQ
Date
Description
On-going
Maintain v2.1
Card Specification
& release any
updates if needed
On-going
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
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.
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
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 (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.
v1.0
Scripting
Spec. v1.0
SCMS
Message
Exchange
Spec.
Description
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 (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
interoperability
Ensure
adoption
of the
specs
Promote
open
standards
and
infrastructure
Remain
relevant by
improving
technologies
THANK YOU
[email protected]