Introduction

1
Introduction Overview
A Framework Approachto Smart Card Services
CTST May 2000 Developers Workshop

• Christophe.Muller_at_research.gemplus.com
• Gemplus Research Lab

2
Presentation Content

• Part I Smart Card Framework Motivations
• OpenCard Consortium Technical Committee
• Part II Overview of the OCF Architecture
• CardTerminal and CardService layers
• System Services Files, Tables, Applets/Objects
• Other Services Signature, Authentication, etc.
• OCF 1.2 - Where to Go Now ?

3
Smart Card Applications

• Applications using Smart Cards are distributed
  applications

4
Why a Smart Card Framework ? (1)

• Smart Card-enabled applications are difficult to
  program and difficult to use
• Smart Card application proprietary solution
• Typically restricted to
• Limited subset of readers (proprietary reader
  specs)
• Limited subset of smart cards (proprietary OS)
• Limited numbers of issuers (gt1 is a major
  effort!)
• low-level OS-dependent serial APIs
• Very limited number of platforms, usually just
  win32

5
Why a Smart Card Framework ? (2)

• Smart Card standards are low-level
• complex protocols
• character or block protocols (T0, T1)
• low-level cards commands
• Complicated to maintain
• With JavaCardTM, WfSC, etc. cards become easy
  to program! Why not easy to use too ?
• Need of a framework for the developers of
  applications that are using smartcard services!

6
OpenCard to the Rescue

• The OpenCard Framework has been designed to make
  applications independent
• from card readers
• from smart card type (within a same category)
• from card issuer
• from the platform (Java based!)
• Flexibility through extensibility
• Ease-of-use by hiding low-level complexity

7
Requirements (1)

• Support any Card Reader device
• Provider architecture for reader layer (idem
  PC/SC)
• Support any Smart Card
• No mandatory support for files, or tables, or
  JavaCard objects, or etc. (any future tech.)
• BUT lots of optional APIs and useful modules
• Must be flexible (we dont know future apps.)
• Be easy to use
• Above APDU!
• Ready-to-use Components for popular Cards

8
Requirements (2)

• Provide Interoperability
• Open and Standard APIs. Allows portable apps.
• Provide Reusability
• Must allow to develop generic components
• Offer High-level features
• Dynamic component selection/creation
• Concurrent access management of resources
• Be Portable
• Applications using Smart Cards will run on
  ...PCs, but also on Unix servers, MacOS, PDA,
  Set-top, GSMs

9
The OpenCard Consortium

• Purpose of the OpenCard Consortium
• Extend, Promote, Distribute OCF Specs
• Contribute to the framework evolutions (through
  its Technical Committee)
• Provide guidance for creation of compliant
  products
• OCF OpenCard Framework
• OCC OpenCard Consortium
• TC Technical Committee

10
Organization of the OCC

• A non-profit US-based corporation
• Management Board
• General management in accordance w/ bylaws
• Chair Andy Streich (Sun)
• Secretary Neville Pattinson (Schlumberger)
• Treasurer John Stearns (UbiQ)
• Technical Committee
• Specification of the OpenCard Framework
• Chair Pierre Paradinas (Gemplus)

11
OCC Members
11 Founding members, 6 more in 98/99
Most recent members Siemens, American Express
12
Technical Committee Overview

• Manages the framework evolutions
• Process of work based on submissions of
• RFPs (Requests For Proposals), and then
• RFCs (Requests For Comments)
• Inspired by many standard organization processes
  (IETF, OMG, W3C)
• First results OCF 1.1.1 (May99), OCF 1.2
  (Jan2000)

13
TC RFP process

• Any member can submit an RFP

• RFPs are concerned with a What would it be
  nice to add or change this feature?

• A non-member submission can be sponsored by a
  member

• Active period 20 days

14
TC RFC process
www.opencard.org/work/

• RFCs are concerned with a How how can we
  design and implement this feature?

• Any member can submit an RFC

• A non-member submission can be sponsored by a
  member

• Active period 40 days
• Confirmed by the management board

15
Major releases - OCF1.2

• V1.2 Major breakthrough JavaCard, EMV, SCQL
  (7816-7), OCF for Embedded, etc.
• (TOCF implementation available from
  alphaworks.ibm.com)

16
Footprint statistics

• OCF 1.2 base-core 111 KB
• OCF 1.2 base-opt 191 KB
• OCF for embedded devices 25 KB
• Embedded CardTerminal layer 7 KB
• Gemplus Serial CardTerminal 90 KB
• GPK CardServices 144 KB

17
Gemplus Components

• CardTerminal
• Serial Readers (GemplusCardTerminal)
• GemXpresso Simulator (GSECardTerminal)
• CardServices
• GemXpresso211 (VOPCardServices)
• MPCOS/GPK8000 (GPKCardServices)
• Prototypes GSM11.11/11.14, GemDB
• Tools
• Reader Manager, APDU Manager, Script Manager

18
Conclusion

• OCC A well established standardization body
• Open Source model of development
• Formal and Democratic Process of Work
• OCF Based on a reliable framework technology
• Interoperability, Portability, Extensibility
• TC Variety of ongoing enhancements in V1.2
• Support for JavaCardTM, EMV cards, DataBase
  cards, Embedded Version, etc.

19
Presentation Content

• Part I Smart Card Framework Motivations
• OpenCard Consortium Technical Committee
• Part II Overview of the OCF Architecture
• CardTerminal and CardService layers
• System Services Files, Tables, Applets/Objects
• Other Services Signature, Authentication, etc.
• OCF 1.2 - Where to Go Now ?

20
OCF Architecture (50,000 feet)

• Clear distinction between mandatory packages and
  optional packages

• opencard.core.
• Core functionality, Basic Infrastructure
• Guaranteed to be available

• opencard.opt.
• Optional functionality (availability depends on
  the reader or card that is used)
• Standardized APIs

21
OCF Architecture (30,000 feet)

• Two major Layers

• CardService opencard.core.service, it knows how
  to interact with a Card OS and/or application(s)

• CardTerminal opencard.core.terminal it manages
  access to a card reader (abstractions for ATR,
  APDU, reader, slot, I/O channel)

22
The Players
Cards Provider
Applications Provider
Public class PNDS extends Applet public void
auth( byte pin) throw new(UserExc
Solution
...
Applet SIM
Applet Purse
Readers Provider
Card Issuer
23
OCF Architecture (10,000 feet)
Portability
on diff. Platforms
, using diff. Readers
, and Cards
Application Provider
Improved time to market
Card Issuer
Card Provider
Lower developt. costs
Reader Provider
24
OpenCard vis-a-vis PC/SC
25
Generic PC/SC CardTerminal
26
Scope of OpenCard PC/SC

• PC/SC has DCOM APIs
• OpenCard portable on all Java platforms

Portability ? New requirements (for Embedded
devices) OpenCard could use CORBA, like PC/SC
uses DCOM!
27
API benchmark results
28
Related Standards

• DAVIC (Digital Audio Visual Council) and ISRF
  (Internet Screenphone Reference Forum)
• have adopted OCF in latest specification levels
• GCA (Global Chipcard Alliance)
• consideration of OCF in current interoperability
  work
• JavaPOS, ETSI GSM WG9 and OPTF (Open Terminal
  Framework) from GlobalPlatform
• intent to harmonize with OCF
• PC/SC
• interoperability through generic PC/SC
  CardTerminal
• STIP (Small Terminal Interoperability Platform)
• JavaCard Forum working group on embedded devices

29
OCF Architecture (10,000 feet)
Clear Interworking APIs
Factory Design Pattern.
Managed Concur- rent Access
30
CardTerminal Layer

• Core components (opencard.core.terminal)
• CardTerminal Abstract class, for reader devices
• CardTerminalFactory
• CardTerminalRegistry
• SlotChannel
• Optional Interfaces (opencard.opt.terminal)
• Power Management interface
• Display/Keyboard interfaces
• Support for PIN pad
• Factory/Registry Design Pattern
• Event Mechanism CardTerminalEvents

31
CardTerminal Layer (1,000 feet)
CardTerminal
CardTerminal
Dynamic
Dynamic
CardTerminalFactory
CardTerminalFactory
Static config.
Dynamic config.
CardTerminalRegistry
32
CardTerminal Events

• A CardTerminal has one or more Slots

SlotChannel

• SlotChannel unique comm. object for one
  card/slot
• Slot/Terminal locking (V1.2)
• Event Mechanism

CardTerminalEvent - CARD_INSERTED -
CARD_REMOVED
CardTerminal
33
CardService Layer

• Core components (opencard.core.service)
• CardService Abstract class, components that
  communicate with a card OS or application/applet
• CardServiceFactory
• CardServiceRegistry
• CardServiceScheduler, CardChannel
• Optional Interfaces
• File System (opencard.opt.iso.fs)
• Database (opencard.opt.database)
• Applets (opencard.opt.applet,
  opencard.opt.applet.mgmt)
• PK Signature Generation Import
  (opencard.opt.signature)
• Factory/Registry Design Pattern

34
CardService Layer (1,000 feet)
SmartCard
CardID
CardServiceScheduler
new
new
CardServiceFactory
CardServiceFactory
Static config.
Dynamic config.
CardServiceRegistry
35
CardService Access Management
CardService
CardService
P()
V()
CardServiceScheduler
sendCommand APDU(00 A4 )

• CardServices allocate/release CardChannels
• critical sections should be as short as possible
• Ready for ISO7816 logical channels

CardChannel
CardTerminal Layer
36
CardService utilizes CardService

• Modularity A CardService object can utilize
  other CardServices to provide its own service
• In this case, they share the same CardChannel

37
Smart Card Data Structures

• Applications using Smart Cards are distributed
  applications

Three types of data structures in Smart Cards
- Files - Tables - Objects
38
OpenCard and FileSystems

• java.io A JDK package that supports reading and
  writing (of files, strings, sockets, etc.)

• opencard.opt.iso.fs
• A file package similar to the Java I/O API

39
OpenCard and Databases

• Java database access framework JDBC

• JDBC Standard, Unified API
• ISO7816-7 Standard of DB Smart Cards.

• opencard.opt.database
• JDBC Driver for DatabaseCS

40
OpenCard and Objects (1)
41
OpenCard and Objects (2)

• RMI using RPC (Remote Procedure Call) techniques
  (CardServices generation)
• ProxyAPI automatic selection of applets (V1.2)
• opencard.opt.applet

JC2.1 server
Java client
rmic compiler
Stub generation
Skel generation
Proxy
T0 T1

• Generic Applet Management API (V1.2) a uniform
  way of selecting, installing... applets
• opencard.opt.applet.mgmt

42
Other Services

• Security Package
• Credentials, Key classes, etc.
• opencard.opt.security
• Signature Package
• Signature, KeyImport, KeyGeneration
• opencard.opt.signature
• Possible Extensions
• Better JDK1.2/1.3 compliance (new Key classes)
• PKCS11-like Java API ? (RFP4)
• JCA/JCE provider ? (JCA needs enhancements)
• Authentication (JAAS provider)

43
Requirements Checking (1)

• Support any Card Reader device
• Provider architecture for CardTerminal
• Support any Smart Card
• No mandatory support for files, or tables, or
  Javacard objects, or etc. (any future tech.)
• BUT lots of optional APIs and useful modules
• Must be flexible (we dont know future apps.)
• Be easy to use
• Above APDU!
• Ready-to-use Components for popular Cards

Terminal layer
Minimum Service layer
Java APIsFrameworks Basic System Services
44
Requirements Checking (2)
CardService Interfaces

• Provide Interoperability
• Open and Standard APIs. Allows portable apps.
• Provide Reusability
• Must allow to develop generic components
• Offer High-level features
• Dynamic component selection/creation
• Concurrent access management of resources
• Be Portable
• Applications using Smart Cards will run on
  ...PCs, but also on MacOS, Unix servers, PDAs,
  Set-top, GSM, etc.

CS utilizes other CS
Factory/Registry Pattern
CS-Scheduler
Java, Test Framework, TOCF
45
Presentation Content

• Part I Smart Card Framework Motivations
• OpenCard Consortium Technical Committee
• Part II Overview of the OCF Architecture
• CardTerminal and CardService layers
• System Services Files, Tables, Applets/Objects
• Other Services Signature, Authentication, etc.
• OCF 1.2 - Where to Go Now ?

46
OCF1.2 - Where to Go Now ?

• Architectural Enhancements
• Embedded devices Adaptation (TOCF, STIP?)
• Integration into other Java Framework(s) (e.g.,
  java.io, JDBC, RMI, JCA/JCE, JAAS,)
• CardServices Generation (RMI, SmartX)
• Component-ware (OCEAN, CESURE)
• Smart Card Servers (RPC/CORBA, UPI/HTTP)

• Normal High-level Usage

47
Q/A
opencard_at_opencard.org
www.opencard.org/
www.gemplus.fr/developers/technologies/opencard/
www.opencard.org/ SCJavaBook/
www.opencard.org/work/