Generic Architecture of MultiApplication Smartcard

1
Generic Architecture of Multi-Application
Smartcard
Satish Devane (99429401) Under Guidance of Dr.
Phatak D. B.
2
Introduction

• Smartcard Growth
• Need for Multi-Application
• Standards
• ISO 7816 Basic Standard
• PC/SC OCF
• Standards for OS Platforms

3
Operating System of Smartcard

• Need for Smartcard OS
• Types
• Multi-Function System
• Multi-Application System
• Application Isolation
• Interpreter
• Memory Manager

4
Issues involved in Multi-Application Operating
System

• Virtual Machine
• Functionality of VM
• Structure of VM
• Dynamic Application Management
• Loading / execution / locking / unlocking /
  deleting
• Issuer / Card Holder Involvement

5
Issues.

• How closely does the issuer need to be involved
  in the development Certification of
  applications that are going to be downloaded?
• Does issuer need to scrutinise each application
  or can he rely on the system to protect himself
  from program errors or malicious attacks?
• Does the Multi-Application OS allow the issuer to
  be in full control of his card?

6
Issues

• Can issuer delegate the operation to a third
  party?
• Can the cardholder tailor the application
  according to his need?
• What is the extent to which the cardholder can
  autonomously pick applications

7
Issues involved in Multi-Application Operating
System
Issues

• Security
• Security in between Application
• Guaranty about Application running on smartcard.

8

• Interoperability issues in different platforms
• Java Card Forum ----Java Card
• MAOSCO------------MULTOS
• Microsoft-------------WFSC

9
Javacard
10
JavaCard Architecture
11
JavaCard VM

• Support 187 out of 201 instruction
• Features not supported
• Dynamic Class loading
• 32 64 bit Integer
• Float and Double data Type
• Threads
• Cloning
• Garbage collection

12
JavaCard security

• No Pointers
• Error checking during compilation
• Class file verifier in VM
• Offline Class verifier in Java Card VM
• Model Checker Method
• B Formal Method

13
Security of applet

• Secure Download Digital Signature

14
JavaCard issues

• Dynamic application Management is possible
• Issuer centric User centric

15
Windows For Smart Card
16
WFSC

• Architecture is not known
• Application must be written in OS Dependent
  Language
• Only MS is able to write and download application
• Virtual Machine called Run Time Environment (RTE)
• Not a fully Multi-Application OS
• Because lack of context management Information

17
WFSM Virtual Machine Security

• Virtual Machine
• It is Optional
• Part of the OS made up of Library Function call
  VM
• Security
• Depends on How the Application is written
• If Application is compiled with OS Function
• Then security by code inspection
• else VM will take care of security

18
WFSC Dynamic Application Management

• Possible to load,delete Application
• No Secure Card Management !
• No Signature verification while
  loading/deleting/locking/unlocking
• Issuer/user involvement
• Issuer has to choose the functionality of OS
  depending on Application

19
MULTOS
20
MULTOS Architecture
Loyalty
Application Isolation
Payment
Identity
Application Program Interface(API)
Application Abstract Machine (AAM)
Virtual Machine
OS
OS
OS
Hardware
Hardware
Hardware
21
MULTOS VM

• Consist of API and AAM
• Application can be written in higher level
  Language viz. C, Java VB
• Compiled to MEL Byte code using SwiftC SwiftJ
  compiler

22
MULTOS AAM

• Application Abstract Machine
• Hide Underlying Hardware
• Consist of
• One Code Address Space
• One Data Address Space
• 7 Address Registers 2 Control Reg
• 2 Addressing Modes (Segment and tagged)
• 31 Instructions
• Mandatory Optional Primitives

23
MULTOS Security

• Application isolation is done through firewall
  a part of OS by
• allocating protected isolated memory area
• Locking the application in this new space
• Applications of different security ratings can
  co-reside on same card

24
Dynamic Application Download

• Possible
• Require Application Load/Delete Certificate for
  each application and card
• Mutual authentication of card and application is
  done before acceptance of the application.
• Issuer/User involvement
• exclusively issuer centric

25
OCAPI
26
OCAPI
AE
AE
OCAPI
PE
PE
Platform 1
Platform 2
27
OCAPI

• Open Chip Architecture Platform Interface
• Specifies the interface between Application
  Environment Platform Environment.
• Application Environment consist of application or
  OS
• Platform Environment abstracts the hardware for
  platform

28
Summary
29
Scope for Future Work

• Modify, change and add new OS function
• Modify and change key upper layer components such
  as loader and VM
• Down load application after initial card issuance
  through a generic system
• Rapid port the complete software on a new
  component

30
Scope for Future Work

• Compliance with the major industry standards
  (Javacard, Multos, Smartcard for windows, OCAPI,)
• Compliance of Common Criteria formal methods for
  security assurance
• User centric platform so that user can purchase
  card from any vendor and use it for any kind of
  application developed by any service provider.

31
Scope for Future Work

• MEDEAs is a group which is also working to
  tackle some of the above mentioned issues.