Muhammad Wasim Raad1 Smart Cards Operating Systems أنظمة التشغيل للبطاقات الذكية By: Dr Muhammad Wasim Raad Computer Engineering Department

Muhammad Wasim Raad 1

Smart Cards Operating Systems التشغيل أنظمة

الذكية للبطاقات

By: Dr Muhammad Wasim Raad

Computer Engineering Department


Smart Chip - 2001+

Co-Processor& 3-DES Engine

16/32-bit RISCProcessor

Contact:ISO 7816

and USB

ROM (96 KB)

EEPROM(64+ KB)FLASH(64 KB)

Power(1.8 Volt)

Ground

Clock

Reset

ISO7816 I/O

RAM (4 KB)

MMU

USB I/O DPA & SPAResistant Logic

Contactless: ISO 14443


تشغيل نظام ماهوالذكية البطاقة

What is a COS?


Card OS Role تشغيل نظام وظيفةالبطاقة


Transmission Protocol


File Architecture


File Architecture(Cont)


Command Sets


ISO 7816-4 Command Sets


Protocol Application LayerAPDU Format


Access Conditions


Access Conditions Examples


Access Conditions Examples


Smart Card Operating Systems

• Smart card operating systems (SCOS) have little resemblance to desktop OS.

• SCOS supports a collection of instructions on which user applications can be built.

• ISO 7816-4 standardizes a wide range of instructions in the format of APDUs.

• Most SMOS supports File Systems


• Very low amount of program code: 3-30KB

• ROM masks for OS need 10-12 weeks for correcting errors

• The secure state of EEPROM has noticeable influence on design of OS


• For example all retry counters must be designed such that their maximum value corresponds to the erased state of the EEPROM

• If this is not the case, it would be possible to reset counter to its initial value by intentionally removing the card during transaction


• This type of attack can be resisted by proper coding of the counter or by making the process of writing the retry counter an atomic process

• Trap doors must be avoided• Cryptographic functions must execute

in very short time


• OS can be loaded into EEPROM, but due to expensive EEPROM most OS is in ROM

• Almost all OS allow program code for additional commands or special cryptographic algorithms to be loaded into EEPROM during completion


• OS must be able to automatically recognize the size of the EEPROM

• Technical implementation involves OS routine reading the manufacturer’s finishing data

• Current Smart Card OS is not able to adapt itself to varyations in size of ROM or RAM


Primary tasks of Smart card OS

• Transferring data to and from a smart card

• Controlling execution of commands

• Managing files• Managing and executing

cryptographic algorithms

Muhammad Wasim Raad 21Source: Z. Chen, “Java Card Technology for Smart Cards”

Smart Card Communication Model

* The card sends out an ATR (Answer to Reset) immediately after insertion.** APDU stands for Application Protocol Data Unit (ISO 7816-4).


Smart Card File System (ISO 7816-4)

MF

DF

EF EF

DF

EF EF

EF EF

DF

MF Master File (root directory, must always be present)

DF Dedicated File (directory file, can contain directory and data files)

EF Elementary File (data file)


Smart Card File Names (ISO 7816-4)

Reserved FIDs3F00 MF root directory

0000 EF PIN and PUK #10100 EF PIN and PUK #2

0001 EF application keys0011 EF management keys

0002 EF manufacturing info0003 EF card ID info0004 EF card holder info0005 EF chip info

3FFF file path selection

FFFF reserved for future use

MF

FID File Identifier (2 bytes)

FID File Identifier (2 bytes)

DF

DF Name (1-16 Bytes)usually ISO 7816-5 AID

EF Short-FID (5bits) FID File Identifier (2 bytes)


EEPROM pages

100'000 write cycles

64 byte page size

Smart Card Internal File Structure

EF

Header

Body

–Header: file structure info, access control rights, pointer to data body content changes never or seldom, protected from erasure

–Body: data, content might change often, many write operations

pointer



MULTOS• A high security architecture

– Apps needing high security can reside next to apps needing low security

• Co-residence of multiple, inter-operable, platform independent applications

• Dynamic remote loading and deletion of applications over the lifetime of a card– Achieved using the language MEL (MULTOS

Executable Language)


PC/SC• Architecture designed to ensure the

following work together even if made by different manufacturers:– smart cards– smart card readers– computers

• Differs from OpenCard because it offers API interoperability rather than uniform API

• Designed for Windows environment with development in Visual C++


Java card • The Java Card specifications enable Java technology to run on

smart cards and other devices

• Multi-Application Capable - Java Card technology enables multiple applications to co-exist securely on a single smart card

• Dynamic: - New applications can be installed securely

• Secure: - relies on the inherent security of the Java programming language to provide a secure execution environment. - platform's proven industry deployments and security evaluations ensure that card issuers benefit from the most capable and secure technology available today.


Java Card• Platform

independent

• Does not support issuer control

• Not secure enough for finantial applications


Java Card Architecture Components




ap

ple

tap

ple

tap

ple

tap

ple

t

Java Card I/O with APDUs

Java Card platformJava Card platformap

ple

tap

ple

t

ap

ple

tap

ple

t

terminalterminal

smartcard hardwaresmartcard hardware

command APDU,incl. applet ID

OS selects applet

and invokes itsprocess method

Applet sendsresponse APDU

appletexecutes


How can the SMART card help in new channels?

Earning and redeeming

rewards with Virtual

Merchants

To store personal data

for covenience

on-line

To Secure Virtual World Shopping with Credit (Chip

SecureCode) or e-Cash

To Managing Finances Securely and Conveniently

Virtual Health, Govt or other

Services

Entertainment on Demand


Proprietary Smart Card Operating Systems

Chip Hardware BChip Hardware BChip Hardware AChip Hardware A

Proprietary OS AProprietary OS B

Native EMV Code

Native LoyaltyCode

Data Data

RO

ME

2

Native EMV Code

Native EMVCode

Native LoyaltyCode

Data Data

RO

ME

2

Proprietary Chip OS developed in “native” code - specific to underlying silicon - to access chip functions. OS often dedicated to performing a single specific function – e.g. EMV OS code is fixed in the ROM of the chip, and cannot be changed after the chip is made.

Limited number of programmers able to make adaptations to proprietary OS – impact on time to market if changes / new functions required. In order to multi-source silicon, native code must be redeveloped from scratch for new chip.

Chip Hardware BChip Hardware BChip Hardware AChip Hardware A


KILLER Applications


MULTOS

• The only OS obtaining ITSEC(E6)

Very secure• Multi-application

support• Requires

Coprocessor for RSA makes it expensive

Muhammad Wasim Raad

MULTOS VM

MULTOS API

MULTOS: The OPEN STANDARD smart card operating system

Infineon SiliconInfineon Silicon

RO

M

MULTOS VM

MULTOS API

Renesas SiliconRenesas Silicon

RO

M

C CompilerJava Compiler

/ TranslatorMEL Editor

MULTOS defines a standard CHIP HARDWARE INDEPENDENT Smart Card Operating System: Portable:

Develop applications ONCE and run on ANY MULTOS chip.

Open: Develop in C or Java and Compile. API FREELY available.

EMV

PKI ApplicationA

E2

PR

OM

EMV

PKI ApplicationA

E2

PR

OM

Highest Hardware and OS Security Assurance:

ITSEC E6 High evaluated

MULTOS SCHEME facilitates management of multiple applications

Advanced Asymmetric Cryptographic mechanism


Open Platform (Card Manager & Security Domain) APIOpen Platform (Card Manager & Security Domain) API

Windowsfor

Smart Cardby

Microsoftand

GlobalPlatform

Java Cardby

Sun Microand

GlobalPlatform

Multos

Credit/DebitCredit/DebitWIMWIMSIMSIM

Logical &Logical &Physical Physical AccessAccess

LoyaltyLoyaltyE-PurseE-Purse

oror oror

Operating System Options

MULTOSby

MondexInternational

andMAOSCOCouncil



Documents

Muhammad Wasim Raad1 Smart Cards Operating Systems أنظمة التشغيل للبطاقات الذكية By: Dr Muhammad Wasim Raad Computer Engineering Department