LQ'LVWULEXWHG,QIRUPDWLRQ6\VWHPV WKH,QWHUDFWLYH([HFXWLRQ0RGHO

1

6PDUW&DUGV,QWHJUDWLRQ

LQ'LVWULEXWHG,QIRUPDWLRQ6\VWHPV WKH,QWHUDFWLYH([HFXWLRQ0RGHO

Sébast ien J EAN,

Didier DONSEZ,

Sylvain LECOMTE,

Em ail : jean@lifl.fr

{donsez,lec om t e}@univ-valenc iennes.fr ,6$'6

2

Sum m ary

❚ Smart cards technology

❙ Overview, Architecture, Communication protocols, OS and applications

❚ Smart cards and information systems

❙ Execution models

❚ The Interactive Execution Model

❙ Motivations, use cases and requirements

❚ Perspectives

3

Sm art Card Overview

❚ History

❘ 1974 : Moreno ’ patent

❘ 1987-1999 : ISO normalization

❘ 1997 : JavaCard, OCF

❘ 1999 : Smart Card for Windows

❚ A smart card is a computer but …

❘ communication rate is 500 times slower

❘ memory amount is 100 000 times smaller

❘ CPU is 100 times less powerful

4

❚ Power supply and clock signal are external

&38 5$0 520

6HFXULW\

%ORFN ,QSXW

2XWSXW 3HUVLVWHQW

0HPRU\

8 bits (6805), 16 bits and

32 bits RISC (ARM 7) 128 Bytes to 1 KB

2KB to 64 KB

Maximum 64 KB

Sm art Card Arc hit ec t ure

5

Sm art Card Applic at ions

❚ Various smart card kinds :

❙ payment cards, access cards, portable data files

❚ Various application domains

❙ Phone : Prepaid cards, SIM/WIM cards

❘ UHTXLUHVZLGHVHUYLFHUDQJHFRVWGRHVQRWPDWWHU

❙ Bank : Electronic Purse, Bank card

❘ UHTXLUHVVHFXULW\EXW ORZFRVW

❙ Healthcare : Patient card,

❘ UHTXLUHVGDWDVHFXULW\

❙ Gambling, Loyalty, Computer Secure Login, ...

Sm art Card

c om m unic at ion fac ilit y

❚ Serial link, half-duplex, asynchronous

❙ ❙ 1 wire 1 wire comm comm . Link . Link

❙ ❙ commonly 19200 bit/s commonly 19200 bit/s

❚ ❚ 2 communication protocols 2 communication protocols

❙ ❙ "T= 0" : bytes oriented "T= 0" : bytes oriented

❙ ❙ "T= 1" : byte "T= 1" : byte - - blocks oriented blocks oriented

,2,2 Hello worldHello world !!

Sm art Card

c om m unic at ion fac ilit y

❚ OSI communication stack based model

❙ TPDU

❘ Transport Protocol Data Unit

❙ APDU

❘ Application Protocol Data Unit

❙ APDU are not encapsulated

but mapped on TPDU

APDU ex c hanges :

c om m unic at ion prot oc ol

Terminal Smart Card

Status word Input Data

APDU process

APDU command

« incoming data » Order (parameters)

Ack.

APDU ex c hanges :

c om m unic at ion prot oc ol

Terminal Smart Card

APDU command

« Outgoing data » Order (results)

Status word Output Data

APDU process

Ack.

Sm art Card

Operat ing Syst em s

-DYD&DUG$3,

Hardware Module

Resources manager (I/O, memory, files) ROM

-DYD90 Flash

Cardlets

❚ Data-oriented smart cards

❙ : FileSystem

❙ 6&4/ : RDBMS in a smart card

❚ Application-oriented smart cards

❙ provide an execution platform for multiple applications (cardlets)

❙ -DYD&DUG, 6PDUW&DUGIRU:LQGRZV, ...

Sm art Card

Operat ing Syst em s

❚ 6PDUW&DUG26DUHRSHUDWLQJV\VWHP

❚ EHFDXVH

❚ manage resources

❚ memory, storage

❚ organise resources (file systems, …)

❚ manage communication with terminal (card reader)

❚ execution support for multiple applications (cardlets)

❚ communication between cardlets

❚ security (authentication, privileges, …)

❚ %XW

❙ no multi-threading (time-sharing)

❙ no communication from a cardlet to an external server

Sm art Cards in Inform at ion

Syst em s : Realisat ions

❚ CQL

❙ element of a distributed database

❘ Portable relational database accessed via ODBC/JDBC drivers

❚ Corba

❙ card services as « corba objects »

❘ COA (Card Object Adapter) as proxy

❚ WebCard

❙ Web server Cardlet, IP/HTTP stack

❚ PNDS Card

❙ contains a directory accessed with a JNDI SPI

13

Application

7HUPLQDO 6PDUWFDUG

Services APDU

Sm art Card & I. Syst em s:

Server Ex ec ut ion Model

❚ Client / Server architecture

❚ Smart Card is always seen as a server

❙ for local client

❙ for remote clients

14

Application

5HPRWH+RVW 7HUPLQDO 6PDUWFDUG

Service

Service HTTP, IIOP

WAP, ...

Sm art Card & I. Syst em s:

Server Ex ec ut ion Model

❚ Client / Server architecture

❚ Smart Card is always seen as a server

❙ for local client

❙ for remote clients

Proxy

HTTP, IIOP APDU

15

❚ Smart Card is client only

❙ It drives the mobile phone GUI

6HUYLFH 6HUYLFH

$SSOLFDWLRQ

$3'8 60 6 : $3

5HPRWH6HUYHU 7HUPLQDO 6PDUWFDUG

6ORWV +DQGVHWV

$3'8

The SIM-Toolk it Case :

ProAc t ive Ex ec ut ion Model

❚ Limits :

❙ application logic fully predefined in the card

❙ bad performance for remote server access

16

Service

Application

5HPRWH+RVW 7HUPLQDO 6PDUWFDUG

The Int erac t ive Model

❚ The Smart Card is both

❚ Server and Client

❙ looks like a Corba service

proxy

17

Why an int erac t ive c ard

❚ What smart card is :

❙ an intrinsic secure component

❙ a mediator between its holder and Information Systems

❙ Smart card is the only device

that its holder accept to trust

❚ With the interactive model, external applications

take benefits of smart card security

Use Case :

Transac t ion Manager 1/3

❚ MultiPurpose Internet Shopping Basket

❙ Multiple purchases in several Web stores

❘ 1 sombr er o @ www.hat .com

❘ 1 poncho @ www.coat .com

❚ Purchase rules

❙ All baskets are managed by a client application

❙ No shared baskets between

www.hat.com and www.coat.com

❙ All or None items are purchased

Use Case :

Transac t ion Manager 2/3

At Of f ice

www.coat .com

3XUFKDVH

www.hat .com

3XUFKDVH

!"# $% &' (

1 sombr er o

W#ZZZKDWFRP

At Home

3XUFKDVH

!"# $% &' (

1 sombr er o

W#ZZZKDWFRP 1 poncho

W#ZZZFRDWFRP

3XUFKDVH 3XUFKDVH%X\7ZR

RUQRQH

Use Case :

Transac t ion Manager 3/3

❚ Multi-Basket application is embedded in the SC

❙ Requires secure transactional completion

❘ avoid repudiation

❘ Need of trust (holder point of view)

☞ Transactional Monitor embedded in SC

❙ Commit if all products are available

❙ abort and rollback else

❚ Pro-activemodel is enough for Multi-Basket application

❚ but interactive model is required for Transactional Monitor

Use Case :

Com ponent Deploym ent

❚ Adaptable Component-Based large scale applications for mobile users

❙ The smart card acts as a « bootstrap » for application deployment on heterogeneous platforms

❚ Some components algorithms have to be kept secret

❙ Some components are executed inside the smart card

❙ These components can be both client and servers

➘ So smart card has to be both Client and Server

22

Tow ard aut hent ic at ion flex ibilit y

❚ Static server-oriented approach

1- An external application authenticates itself 2- It asks the card for a service

3- The card gives the results

❚ Dynamic interactive-oriented approach

1- An ext. application asks for a service

2- The card requests it for authentication

3- If done, the smart card gives the results

23

Requirem ent s 1/2

❚ A Full-duplex protocol is required...

❙ Because interactive model needs 2-way requests emission

❚ But it might be "virtual full duplex"

❙ Real full duplex on 1 wire has to fight with collisions (Ethernet)

❙ “natural” handshaking

24

❚ Multi execution context

❙ 1 smart card / N remote hosts

❘ Several request (that are not related) have to be managed by the smart card simultaneously

❙ Loop Back

❘ Card C calls a remote service A

❘ and service A calls C

Requirem ent s 2/2

C C A A

$SSOLFDWLRQ

$SSOLFDWLRQ

25

Perspec t ives

❚ Communication Protocol required by the interactive model is specified

❚ Prototype and experimentation are in progress

❚ Part of the PhD Thesis of Sébastien JEAN

❚ Related work :

❙ CESURE project

❙ Hybrid smart card model