1.

INTRODUCTION

Imagine the power of a computer, the speed and security of electronic data,
and the freedom to carry that information anywhere on earth. Imagine a computer so
small it fits inside a plastic card like the credit card you carry in your wallet. Imagine
the Smart Card.

COMPUTER EVOLUTION

Information technology is evolving at an amazing pace. Personal computers,

fax machines, pagers, and cell phones are in the hands of millions of people
Worldwide. Similarly, interest in smart card technology has soared in the 1990’s, and
by the year 2000 the number and variety of smart card-based applications will
explode around the world.

SMART CARD EVOLUTION

The driving factors of the growing interest in smart cards include the declining
cost of smart cards and the growing concern that magnetic stripe cards can not
provide the protections necessary to thwart fraud and security breaches. This security
issue alone may propel smart card technology to the forefront of business
transactions.

What is a smart card?

The term Smart Card is loosely used to describe any card with a capability to
relate information to a particular application such as magnetic stripe, optical, memory,
and microprocessor cards. It is more precise, however to refer to memory and
microprocessor cards as smart cards.

 A magnetic stripe card has a strip of magnetic tape material attached to its
surface. This is the standard technology used for bank cards.

 Optical cards are bank card-size, plastic cards that use some form of laser to
write and read the card.

~ 1 ~
  Memory cards can store a variety of data, including financial, personal, and
specialized information; but cannot process information.

 Smart cards with a microprocessor look like standard plastic cards, but are
equipped with an embedded Integrated Circuit (IC) chip. Microprocessor cards
can store information, carry out local processing on the data stored, and
perform complex calculations. These cards take the form of either “contact”
cards which require a card reader or “contactless” cards which use radio
frequency signals to operate.

MICROPROCESSOR SMART CARD

For the purpose of this tutorial, we are focusing our discussion on the
microprocessor type of Smart Card defined as an IC chip contact card with a
microprocessor and memory. No bigger than a credit card, this smart card contains a
dime-sized microchip that can process and store thousands of bits of electronic data.
Unlike passive devices (such as a memory card or magnetic stripe card) that can only
store information, the smart card is active and able to process data in reacting to a
given situation. This capability to record and modify information in its own non-
volatile, physically protected memory makes the smart card a powerful and practical
tool. Smart cards are small and portable; they can interact with computers and other
automated systems; and the data they carry can be updated instantaneously.

~ 2 ~
2. OVERVIEW OF CHARACTERSTICS

• A "smart card" is also characterized as follows:

• Dimensions are normally credit card size. The ID-1 of ISO/IEC 7810 standard
defines them as 85.60 × 53.98 mm. Another popular size is ID-000 which is
25 × 15 mm (commonly used in SIM cards). Both are 0.76 mm thick.

• Contains a security system with tamper-resistant properties (e.g. a secure

crypto processor, secure file system, human-readable features) and is capable
of providing security services (e.g. confidentiality of information in the
memory).

• Asset managed by way of a central administration system which interchanges

information and configuration settings with the card through the security
system. The latter includes card hot listing, updates for application data.

• Card data is transferred to the central administration system through card

reading devices, such as ticket readers, ATMs etc.

Figure 1 : Scans of different types of contact pads on Smart Cards and SIMS

~ 3 ~
3. ELECTRICAL SIGNALS DESCRIPTION
A smart card pin out:

Figure 2 : Close up of contacts on a Smart card with signal names

VCC: Power supply input

RST: Either used itself (reset signal supplied from the interface device) or in
combination with an internal reset control circuit (optional use by the card). If internal
reset is implemented, the voltage supply on Vcc is mandatory.

CLK: Clocking or timing signal (optional use by the card).

GND: Ground (reference voltage).

VPP: Programming voltage input (deprecated / optional use by the card).

I/O: Input or Output for serial data to the integrated circuit inside the card.

NOTE - The use of the two remaining contacts will be defined in the appropriate
application standards

C1 – VCC, C2 - RST

C3 – CLK, C4 -

C5 – GND, C6 - VPP

C7 - I/O, C8 -

~ 4 ~
4. TECHNOLOGY REVIEW
MICRO MODULE

Smart cards are credit card-sized, often made of flexible plastic (polyvinyl
chloride or PVC), and are embedded with a micro module containing a single silicon
integrated circuit chip with memory and microprocessor. The micro module has eight
metallic pads on its surface, each designed to international standards for VCC (power
supply voltage), RST (used to reset the microprocessor of the smart card), CLK (clock
signal), GND (ground), VPP (programming or write voltage), and I/O (serial
input/output line). Two pads are reserved for future use (RFU). Only the I/O and
GND contacts are mandatory on a card to meet international standards; the others are
optional.

When a smart card is inserted into a Card Acceptance Device or CAD (such as
a point-of-sale terminal), the metallic pads come into contact with the CAD’s
corresponding metallic pins, thereby allowing the card and CAD to communicate.
Smart cards are always reset when they are inserted into a CAD. This action causes
the smart card to respond by sending an “Answer-to-Reset “message, which informs
the CAD, what rules govern communication with the card and the processing of a
transaction.

MICRO MODULE COMPONENTS

5The micro module on board the smart card is made up of certain key
components that allow it to execute instructions supporting the card’s functionality.
Click each component in the diagram for an explanation.

The Microprocessor Unit (MPU) executes programmed instructions.

Typically, older version smart cards are based on relatively slow, 8-bit embedded
microcontrollers. The trend during the 1990s has been toward using customized
controllers with a 32-bit Reduced Instruction Set Computing (RISC) processor
running at 25 to 32 MHz’s

The I/O Controller manages the flow of data between the Card Acceptance
Device (CAD) and the microprocessor.

~ 5 ~
 Read Only Memory (ROM) or Program Memory is where the instructions are
permanently burned into memory by the silicon manufacturer. These instructions
(such as when the power supply is activated and the program that manages the
password) are the fundamentals of the Chip Operating System (COS) or, as often
called, the “Mask.”

Random Access Memory (RAM) or Working Memory serves as a temporary

storage of results from calculations or input/output communications. RAM is a
volatile memory and loses information immediately when the power supply is
switched off.

Application Memory, which today is almost always double E-PROM

(Electrically Erasable Programmable Read-Only Memory) can be erased
electronically and rewritten. By international standards, this memory should retain
data for up to 10 years without electrical power and should support at least 10,000
read-write actions during the life of the card. Application memory is used by an
executing application to store information on the card.

WHAT IS THE COS?

The smart card's Chip Operating System (frequently referred to simply as OS;
and sometimes referred to as the Mask) is a sequence of instructions, permanently
embedded in the ROM of the smart card. Like the familiar PC DOS or Windows
Operating System, COS instructions are not dependent on any particular application,
but are frequently used by most applications.

CHIP OPERATING SYSTEMS ARE DIVIDED INTO TWO FAMILIES:

 The general purpose COS which features a generic command set in which the
various sequences cover most applications, and

 The dedicated COS with commands designed for specific applications and
which can even contain the application itself. An example of a dedicated COS
would be a card designed to specifically support an electronic purse
6application.

THE BASELINE FUNCTIONS OF THE COS WHICH ARE COMMON ACROSS ALL SMART CARD

~ 6 ~
PRODUCTS INCLUDE:

 Management of interchanges between the card and the outside world,

primarily in terms of the interchange protocol.

 Management of the files and data held in memory.

 Access control to information and functions (for example, select file, read,
write, and update data).

 Management of card security and the cryptographic algorithm procedures.

 Maintaining reliability, particularly in terms of data consistency, sequence

interrupts, and recovering from an error.

 Management of various phases of the card's life cycle (that is, microchip
fabrication, personalization, active life, and end of life).

KEY FEATURES AND CHARACTERISTICS

Shown below are some of the key features and characteristics of smart cards.

Cost

Typical costs range from $2.00 to $10.00. Per card cost increases with chips
providing higher capacity and more complex capabilities; per card cost decreases as
higher volume of cards are ordered.

Reliability

Vendors guarantee 10,000 read/write cycles. Cards claiming to meet

International Standards Organization (ISO) specifications must achieve set test results
covering drop, flexing, abrasion, concentrated load, temperature, humidity, static
electricity, chemical attack, and ultra-violet, X-ray, and magnetic field tests.

Error Correction

Current Chip Operating Systems (COS) perform their own error checking. The
terminal operating system must check the two-byte status codes returned by the COS
~ 7 ~
(as defined by both ISO 7816 Part 4 and the proprietary commands) after the
command issued by the terminal to the card. The terminal then takes any necessary
corrective action.

7Storage Capacity EEPROM:

8K – 128K bit. (Note that in smart card terminology, 1K means one thousand
bits, not one thousand 8-bit characters. One thousand bits will normally store 128
characters, the rough equivalent of one sentence of text. However, with modern data
compression techniques, the amount of data stored on the smart card can be
significantly expanded beyond this base data translation.)

Ease of Use

Smart cards are user-friendly for easy interface with the intended application;
handled like the familiar magnetic stripe bank card.

Susceptibility

Susceptible to chip damage from physical abuse, but more difficult to disrupt or
damage than the magnetic stripe card.

Security

Smart cards are highly secure. Information stored on the chip is difficult to
duplicate or disrupt, unlike the outside storage used on magnetic stripe cards that can
be easily copied. Chip microprocessor and Co-processor supports DES, 3-DES, RSA
or ECC standards for encryption, authentication, and digital signature for non-
repudiation. First Time Read Rate ISO 7816 limits contact cards to 9600 baud
transmission rate; some Chip Operating Systems do allow a change in the baud rate
after chip power up; a well designed application can often complete a card transaction
in one or two seconds.

Speed of Recognition

Smart cards are fast. Speed is only limited by the current ISO Input/output
speed standards.

~ 8 ~
Proprietary Features

These include Chip Operating System and System Development Kits.

Processing Power

Older version cards use an 8-bit micro-controller clickable up to 16 MHz with

or without co-processor for high-speed encryption. Current trend is toward
customized controllers with a 32-bit RISC processor running at 25 to 32 MHz’s

Power Source

Mostly 5 volt DC power source.

Support Equipment Required

For most host-based operations, only a simple Card Acceptance Device (that
is, a card reader/writer terminal) with an asynchronous clock, a serial interface, and a
5-volt power source is required. For low volume orders, the per unit cost of such
terminals runs between $100 and $250, the cost decreasing significantly with higher
volumes. More costly Card Acceptance Devices are hand-held, battery-operated
terminals and EFT/POS desktop terminals.

ISO 7816 Standards

Standards are key to ensuring interoperability and compatibility in an

environment of multiple card and terminal vendors. Integrated circuit card standards
have been underway since the early 1980’s on both national and international levels.
Basic worldwide standards for smart cards have been and continue to be established
by the International Organization for Standardization, which has representation from
over 70 nations. The ISO 7816 series is the international standard for integrated
circuit cards.

COS Standards

Although smart cards conform to a set of international standards, there is

currently no standard Chip Operating System, or anything as common as Microsoft’s
Windows, or UNIX. Each smart card vendor provides the market with a distinct

~ 9 ~
product. The key discriminator among smart card products is the proprietary operating
system each offers to the customer.

Work of Other Industry Standard Groups

Other standards groups and vendor consortia are working on standards

proposals and specifications that will have impact on smart cards. Shown below is a
review of their activities.

~ 10 ~
5. TYPES OF SMART CARDS

This section is designed to provide you with some basic information about
emerging card technologies. Referred to as electronic cards or simply "e-cards," these
cards contain from one to three different types of embedded chip technologies:
contact smart chip, contactless smart chip and proximity chip. E-cards that contain
two or more chip technologies are referred to as hybrid cards or combi cards.

CONTACT CARDS

Contact smart cards are the size of a conventional credit or debit card with a
single embedded integrated circuit chip that contains just memory or memory plus a
microprocessor.

Memory-only chips are functionally similar to a small floppy disk. They are
less expensive than microprocessor chips, but they also offer less security so they
should not be used to store sensitive or valuable information.

Figure 3 : Contact card

Chips that contain both memory and a microprocessor are also similar to a
small floppy disk, except they contain an "intelligent" controller used to securely add,
delete, change and update information contained in memory. The more sophisticated
microprocessor chips have state-of-the-art security features built in to protect the
contents of memory from unauthorized access.

~ 11 ~
 Contact smart cards must be inserted into a card acceptor device where pins
attached to the reader make "contact" with pads on the surface of the card to read and
store information in the chip. This type of e-card is used in a wide variety of
applications, including network security, vending, meal plans, loyalty, electronic cash,
government IDs, campus IDs, e-commerce and health cards.

CONTACTLESS SMART CARDS

In addition to the features and functions found in contact smart cards,

contactless smart cards contain an embedded antenna instead of contact pads attached
to the chip for reading and writing information contained in the chip's memory.

Contactless cards do not have to be inserted into a card acceptor device.

Instead, they need only be passed within range of a radio frequency acceptor to read
and store information in the chip. The range of operation is typically from about 2.5"
to 3.9" (63.5mm to 99.06mm) depending on the acceptor.

Figure 4 : contactless smart cards

Contactless smart cards are used in many of the same applications as contact
smart cards, especially where the added convenience and speed of not having to insert
the card into a reader is desirable. There is a growing acceptance of this type of card
for both physical and logical access control applications. Student identification,
electronic passport, vending, parking and tolls are common applications for
contactless cards.
~ 12 ~
COMBI CARDS

The combi card - also known as a dual-interface card - has one smart chip
embedded in the card that can be accessed through either contact pads or an
embedded antenna. This form of smart card is growing in popularity because it
provides ease-of-use and high security in a single-card product.

Figure 5 : Combo card

Mass transit is expected to be one of the more popular applications for the
combi card. In the mass transit application, a contact-type acceptor can be used to
place a cash value in the chip's memory and the contactless interface can be used to
deduct a fare from the card.

HYBRID CARDS

Hybrid card is the term given to e-cards that contain two or more embedded
chip technologies such as a contactless smart chip with its antenna, a contact smart
chip with its contact pads, and/or a proximity chip with its antenna - all in a single

~ 13 ~
card. The contactless chip is typically used for applications demanding fast
transaction times, such as mass transit. The contact chip can be used in applications
requiring higher levels of security. The individual electronic components are not
connected to each other even though they share space in a single card.

Figure 6 : Hybrid Card

Hybrid cards offer a unique solution for updating your existing badging
system. This e-card allows you to accommodate the infrastructure and card
technology of a legacy system while adding new applications and e-card technologies
- all in a single ID card.

PROXIMITY CARDS

In addition to the features and functions found in contact smart cards,

contactless smart cards contain an embedded antenna instead of contact pads attached
to the chip for reading and writing information contained in the chip's memory.

~ 14 ~
 Figure 7 : Proximity Cards

Contactless cards do not have to be inserted into a card acceptor device.

Instead, they need only be passed within range of a radio frequency acceptor to read
and store information in the chip. The range of operation is typically from about 2.5"
to 3.9" (63.5 mm to 99.06 mm) depending on the acceptor.

Contactless smart cards are used in many of the same applications as contact
smart cards, especially where the added convenience and speed of not having to insert
the card into a reader is desirable. There is a growing acceptance of this type of card
for both physical and logical access control applications. Student identification,
electronic passport, vending, parking and tolls are common applications for
contactless cards.

6. SMART-CARD OPERATING SYSTEM WITH CONTACT-

LESS INTERFACE (SCOSTA-CL)

The operating system interface for the multi-purpose Smart Cards intended to
be used in the context of the applications in India. It covers the interface details of the

~ 15 ~
smart card operating system. However the implementation of the operating system,
processor for the smart card and other such details are not covered in this
document and are out of its scope. The physical communication interface details
between the ICC and IFD are out of scope of this document. In general SCOSTA-
CL compliant OS based ICC may work with an IFD with T=0, T=1, or ISO14443-
type A, or type B, or similar protocols. Certain examples included here are for
illustrative purposes only for better understanding and do not suggest any particular
implementation on the applications.

The SCOSTA-CL describes the minimum support for the application using the
Smart Cards. Operating systems with extra features not listed here will be
SCOSTA-CL compliant only if they support all the features listed in this
document and the extra features are non-conflicting with the functionality as
provided in this document. A SCOSTA-CL compliant operating system will also
be compliant to the ISO7816-4, -6, -8, -9. The physical communication interface
may be compliant to ISO7816-3, ISO14443-3 and -4 standards.

APPLICATION PROTOCOL DATA UNIT (APDU)

For the sake of this document, we shall define the following two kinds
of APDU. APDU for interface to the transport layer (T=0, T=1, or contact-less type
A or type B as defined in ISO/IEC 7816-3 and ISO/IEC 14443-3/-4). We shall call
this as transport APDU or tAPDU in this document. The application level
APDU (or just the APDU as referred to in this document) will represent the
interface between the application and the OS. tAPDU will have a command
header, an optional data field and an option expected length parameter. The
command tAPDU will contain the following.

 tCLA: CLA byte for the transport APDU

 tINS: INS byte in the transport APDU

 tP1: P1 byte in the transport APDU.

 tP2: P2 byte in the transport APDU

~ 16 ~
  tLc: Lc byte related to the transport APDU. Will be present only
when

 the tAPDU needs command bytes.

 tDATA: Transport layer data bytes (of size 1..tLc).

 tLe: Field in the transport APDU to indicate number of bytes

expected in the response tAPDU (transport layer response APDU).

Related fields in the application level command APDU are CLA, INS, P1, P2, Lc,
DATA (1...Lc) and Le.

The response tAPDU in the transport layer will contain the following fields.

 tRESPONSE: Transport layer response (of size 1..tLe or less)

 tSW1, tSW2: transport layer status bytes.

Related fields in the application level response APDU are the

following. RESPONSE (1...Le or less), SW1, SW2.

tAPDU and APDU will have relationship based on certain parameters.

If the

Secure Messaging is not used; the tAPDU shall be identical to the APDU. If
the secure messaging is used, tAPDU shall encapsulate the confidentiality and
integrity of the application APDU as is indicated by tCLA. From the application view
point, the maximum size of the Lc and tLc will never exceed 255. The maximum size
of the Le and tLe will never exceed 256. All such fields shall be coded in one byte
only. The ICC therefore must support short-field Lc and Le and optionally may
support extended-field Lc and Le.

TRANSPORT PROTOCOL DATA UNIT (TPDU)

Transport Protocol Data Unit (TPDU) shall be used to carry the tAPDU
from the IFD to the ICC for command and from ICC to the IFD for the
response. Conversion from tAPDU to the APDU shall be carried out completely by
the ICC (for the commands) and IFD (for the response) locally. The conversion

~ 17 ~
from APDU to the TPDU shall be based on the transport protocol. For T=0 and T=1
protocols, such conversions are defined in the ISO/IEC 7816-3 and for contact-less
protocols, such conversions are defined in the ISO/IEC 14443-3/-4 and ISO7816-
3.

BASIC DATA STRUCTURES

SCOSTA-CL will support the following two categories of the files.

• Dedicated Files (DF)

• Elementary Files (EF)

The structure of the file system will be that of a tree with depth restrictions, if
any, not less than 4 (including the MF and EF). Thus it will be possible to have at
least one MF, at least one DF under the MF, at least one DF under this DF and one or
more EFs under the last DF. At each node of the tree, there can be several children
nodes, either of type DF, or of type EF. The root of the tree is the Master File (of type
DF). At any node it should be possible to create any number of children nodes (both
DF and EF put together). The restrictions on the tree structure may be put only
because of the limited size of the memory. Under this condition, a CREATE FILE
command may fail with an error.

The size of the files will be static and will depend upon the values provided
implicitly or explicitly through the File Control Parameters (FCP) declared at the time
of CREATE FILE command. Initially there will be no MF in a blank SCOSTA-CL-
compliant ICC. At this time, the ICC shall execute no commands except the
following. CLA=00, INS = ‘E0’, P1 = 00, P2 = 00. Data field for the command shall
indicate the FCP related to the MF. All commands except CREATE FILE (MF)
shall return identical error conditions and fail to execute till the MF is created. MF
once created, can not be deleted.

The ICC will support data layout for multiple applications each of which may
be identified by a DF. The files under the MF will be global for all applications. The
files specific to an application shall be stored under a DF node in the file system tree.
An application may have sub-applications each represented by an individual DF

~ 18 ~
under the parent DF. In such a case, the application may organize the files as
global within the application and local for each sub-application.

ELEMENTARY FILES

The elementary files (EF) will be used to keep the data pertaining to an
application. An EF can be one of the following types.

• Transparent EF (as defined in ISO/IEC 7816-4)

• Linear EF with fixed size records (as defined in ISO/IEC 7816-4)

• Linear EF with variable size records (as defined in ISO/IEC 7816-4)

• Cyclic EF with fixed size records (as defined in ISO/IEC 7816-4)

The OS will use some EFs internally as well. A few pre-determined and fixed
short EF identifiers may be used to identify such EFs. There is however no restriction
on the 16-bit identifiers for the same. In particular the OS uses short EF identifiers 1
and 2 internally. Section 10 of this document describes their use. A file whose
contents may be used by the OS internally will be declared as INTERNAL EF.

FILE REFERENCING METHODS

Each file (an EF or a DF) will have one 16-bit file identifier. The
following restrictions will apply on the 16-bit file identifiers.

• ‘0000’ and ‘FFFF’ shall be reserved and shall not be used as

identifiers.

• ‘3F00’ will be reserved for the MF and will not be used for any other
file.

• ‘3FFF’ will be reserved to indicate the current DF and will not be used
for any file.

~ 19 ~
 • ‘2F00’ and ‘2F01’ will not be used for any general file under
the MF where they are reserved for specific use as defined in ISO7816-
4.

• 16-bit File Identifiers will be unique among the identifier for EFs
and DFs under a single DF.

The EFs can also be referenced using another short EF identifier (5-
bits) given at the time of CREATE FILE command. The following restrictions will
apply on 5-bit short file identifiers.

• Short EF identifiers shall be used only for the files under the currently
selected DF.

• Short EF identifier of ‘00’ and ‘1F’ will be reserved and will not be
used for any EF. In particular, short EF identifier of 0, when used, will
refer to the currently selected EF. Short EF identifier of ‘1E’ under
the MF will also be a reserved one as per ISO/IEC 7816-4 and shall
not be used for any other general file by the applications.

• Short EF identifier may not be unique among the EFs under a DF.

• Short EF identifiers will not be assigned to a file when tag ‘88’

with length 0 is used in the FCP for the file during CREATE FILE
command.

• Short EF identifier will be assigned to the file when tag ‘88’ with
length 1 is used in the FCP and the value field indicates a number
between 1 and 30. If the value field is a number other than
between 1 and 30 (both inclusive), an error shall be returned by
the CREATE FILE command.

~ 20 ~
 • Short EF identifier will be assigned to an EF, when tag ‘88’ is not used
in the FCP, as a value given in the least significant five bits of the 16-
bit file identifier provided it falls between 1 and 30 (both inclusive). In
case,this value is 0 or 31, the short EF identifier shall not be assigned.

• While selecting a file using short EF identifier, the results will

be unpredictable if two or more files exist with the same short EF
identifier.

• Under any DF, there can be a maximum of one EF which is of

type internal and has an SFID=‘01’. Same restrictions will also apply
for an internal EF with SFID=‘02’.

Each DF in the file system may also have a DF name that shall be
unique among all DFs in the file system. This DF name can be specified in the FCP
during the CREATE FILE command. It will be possible to refer to a DF with its name
irrespective to its location in the file system when the name was specified
during the CREATE FILE command. When the DF name is not specified, it will
not be possible to refer to that DF by its name. Files can be referenced using the
following four methods as described in the ISO/IEC 7816-4 section 5.3.1.

• Referencing by the file identifier. The values ‘3F00’, ‘3FFF’ and

‘FFFF’ are used for special purposes as given in ISO/IEC 7816-4
standard. In addition to this, the file IDs ‘2F00’ and ‘2F01’ under the
MF will also be reserved.

• Referencing by path. The path starting with ‘3F00’ shall refer to

the absolute paths (i.e. starting from the MF) while the paths starting
from any other file id will refer to the relative paths (i.e. starting
from the current DF). Paths starting from ‘3FFF’ will also refer
to the paths starting from the current DF. ‘3F00’ and ‘3FFF’ can
occur only in the beginning of a path. For example, a path such as
‘3F00 3F00’ shall be considered as a wrong path.
~ 21 ~
 • Referencing by short EF identifier. Valid SFID will be a value in the
range 1 to 30 (i.e. ‘01’ to ‘1E’) and will be coded appropriately in the
commands. A SFID of 0 will refer to the currently selected EF. There
may be multiple files with the same SFID.

• Referencing by DF name. DF name referencing will be possible only

for the DFs which were created with the name given in the FCP. The
file name shall be unique among all DFs in the ICC. In case, two DFs
are given the same name, the behavior of the OS is not specified.

DATA REFERENCING METHODS

A SCOSTA-CL compliant operating system shall implement at least the

following data referencing methods as defined in ISO/IEC 7816-4 section 5.3.2.

• Record referencing

• Referencing by one byte record number

• Referencing by one byte record identifier

It is implied in this document that the maximum size of a record shall not
exceed 255 bytes.

Data Unit referencing The data unit referencing shall be available for the
transparent EF. The operating system may implement data unit referencing
mechanism for the record structure files as well primarily intended to debug
the applications.

However in such a case, the data returned may include the structural
information (meta-data) as well. SCOSTA-CL compliant applications will make no
assumptions about the structure of the meta-data.

The ICC may support variable data unit size (among these support for 8-bits
wide data units is mandatory for all SCOSTA-CL compliant ICC) as defined in the
table number 87 of ISO/IEC 7816-4.

FILE CONTROL INFORMATION.

~ 22 ~
 SCOSTA-CL compliant OS will support at least the FCP templates to
be returned to the application during the SELECT FILE command execution. In
information should be supplied if the other templates are not supported. Case
SELECT FILE command demands other templates; meaningful default information
should be supplied if the other templates are not supported.

7. CRYPTOGRAPHIC INFRASTRUCTURE IN SCOSTA-CL

7.1. SESSION KEY DERIVATION

SCOSTA-CL will maintain at least two session keys, one for the
confidentiality and another for the integrity. In case the derived keys are to be used
for the authentication purposes as well, these may share space with the session keys
for the confidentiality (i.e. there may be only one derived key for authentication and
confidentiality). When the keys are derived, the OS shall have to maintain the
~ 23 ~
usage for which the key is derived and permit only that use. It will be possible for a
SCOSTA-CL compliant operating system to be able to derive the session keys using
one of the following methods.

7.2. Authentication along with Session Key Derivation

Session key can be derived along with the authentication using GET
CHALLENGE and MUTUAL AUTHENTICATE command. This has been
described in the next section, in more details when the Algorithm Reference is 0 or 1.
Two keys shall be derived in this manner, one for the confidentiality and
another for the integrity. The confidentiality key shall be usable for encryption and
decryption (this can be restricted further by the CRT usage tag ‘95’ in the CT
template in the current SE). The integrity key shall be usable for the computation and
verification of cryptographic checksum (this can be restricted further by the CRT
usage tag ‘95’ in the CCT template).

7.3. SESSION KEY DERIVATION USING MANAGE SECURITY ENVIRONMENT

COMMAND.

The MANAGE SECURITY ENVIRONMENT can be used for the key

derivation of the session keys. For this tag ‘94’ in the appropriate CRT shall be used.
For example, if the CT template of the current SE is selected, the key shall be
derived for the confidentiality as per the key usage qualifier in that SE. The key
derivation method shall use the tag ‘84’ (in the appropriate CRT) to find the key
reference of the master key. It shall also check if the key is permitted as a master key
in the key repository. The derived key shall be taken as a 3DES encryption of 16-byte
data (tag ‘94’) using a 16-byte master key. For this encryption, the IV shall be taken
as 0 (and it shall not modify the IV for confidentiality/integrity maintained separately
by the OS). The encryption mode will be CBC as shown in figure 9. The resulting
16-byte number shall be treated as a 3DES key. The key shall be subjected to the key
usage based on the key type parameter in the key repository. Thus a key
derived using the CT template for example, can be made to work only for
encryption or only for decryption or for both.

7.4. Key Derivation for Authentication

~ 24 ~
 Keys may be derived for the authentication purposes if the
corresponding master key reference is provided in the AT template in the
current SE. The algorithm for the key derivation is the same as that for the
session key derivation using MANAGE SECURITY ENVIRONMENT command
as described in the previous section.

7.5. CRYPTOGRAPHIC ALGORITHMS IN SCOSTA-CL

A SCOSTA-CL compliant OS shall support all cryptographic algorithms as

described in Part I.8.4. In this section, the algorithms are described in details.

Algorithms for Confidentiality

Algorithms for the confidentiality include algorithms for Encryption and

Decryption. The SCOSTA-CL compliant OS shall support at least the 3DES
algorithm. This algorithm shall be subjected to padding (as defined in ISO9797-1
padding method 3) as well as CBC mode of encryption/decryption. The algorithm
reference of 0 and 1 in the CT template in a CRT shall mean the 3DES algorithm as
described here. The 3DES basic block encryption shall use a 16-byte key data
structure as per ISO 11568-2 standard. This shall be considered as two 8-byte wide
keys for DES algorithms. The IV for the algorithm and the method to update the IV at
the end of encryption/decryption can be set by MANAGE SECURITY
ENVIRONMENT command. Only one IV need be maintained by the OS for the
confidentiality which shall be different from the IV maintained by the OS for the
integrity. The 3DES algorithm is explained pictorially in figures 8 and 9.

~ 25 ~
 Figure 8 : Basic encryption and decryption mechanisms in 3DES algorithm

Figure 9 :3DES Encryption of large messages using CBC mode.

Depending upon the value of the IV related tags, the new value of the IV may
be set automatically to cn (the last cipher-text block) when the chaining mode is used
for the IV. The IV must be initialized whenever the current SE is changed (for
example, because of SELECT FILE command or by MANAGE SECURITY
ENVIRONMENT command).

Algorithms for Integrity

~ 26 ~
 The SCOSTA-CL compliant OS shall support two algorithms for the integrity.
The first algorithm (known as 3DES based CBC residue) shall be indicated by
algorithm reference of 0 in the CCT template of the CRT. ISO/IEC 9797-1 algorithm
2 for MAC shall be indicated by algorithm reference of 0 or 2. The algorithms may
need an IV which shall be taken as IV for the integrity.

CBC Residue based integrity

In this mode, the 3DES algorithm shall be used for large messages.
The integrity code (or cryptographic checksum) shall be derived from the cn (the last
block of the encryption as shown in Figure 9). It is recommended that an
application should not use identical keys for confidentiality and integrity. The
cryptographic checksum (or the integrity code) shall be at least 4 bytes long and at
most 8 bytes long (the size of the cn in 3DES). In case, smaller than 8 bytes are used
for the integrity code, those many bytes from the least significant bytes onward shall
be returned out of the CBC residue. The IV and the method to update IV shall be
governed by the appropriate tags in the CCT template of the CRT. The operations
will be similar to the ones described earlier.

ISO/IEC 9797-1

This algorithm shall be indicated by the algorithm reference of 02 in the CT

template of the CRT to a SCOSTA-CL compliant OS. In this mode, IV shall be first
incremented by 1 and shall not be updated at the end of the computations. This
algorithm is represented in figure 10.

~ 27 ~
Algorithms for Authentication

There shall be at least two algorithms for cryptographic authentication

(INTERNAL, EXTERNAL and MUTUAL AUTH).

The algorithm reference of 0 or 1 shall refer to the 3DES based

challenge response method. In this method, a challenge of 8 bytes shall be given by
the challenger (IFD or ICC) to the subject (ICC or IFD). The subject shall encrypt the
challenge using the indicated key and provide 8-byte response obtained as cipher-text
from the 3DES encryption as described in figure 8.

The algorithm reference of 2 shall refer to the 3DES based authentication as

well as session key establishment of ISO/IEC 11770-2 key establishment
mechanism.

~ 28 ~
8. ADVANTAGES OF SMART CARDS
The key advantages of smart card technology include:

1. The capacity provided by the on-board microprocessor and data capacity for

Highly secure, off-line processing.

2. Adherence to international standards, ensuring multiple vendor sources and

competitive prices.

3. Established track record in real world applications.

4. Durability and long expected life span (guaranteed by vendor for up to 10,000

Read/writes before failure).

5. Chip Operating Systems that support multiple applications and secure

Independent data storage on one single card.

BARRIERS TO ACCEPTANCE OF SMART CARDS

The current obstacles to acceptance of smart card technology include:

• Relatively higher cost of smart cards as compared to magnetic stripe cards.

(The difference in initial costs between the two technologies, however,
decreases significantly when the differences in expected life span and
capabilities--particularly in terms of supporting multiple applications and thus
affording cost sharing among application providers--are taken into account.)

• Present lack of infrastructure to support the smart card, particularly in the

United States, necessitating retrofitting of equipment such as vending
machines, ATMs, and telephones.

• Proprietary nature of the Chip Operating System. The consumer must be

technically knowledgeable to select the most appropriate card for the target
application.

~ 29 ~
• Lack of standards to ensure interoperability among varying smart card
programs.

• Unresolved legal and policy issues, such as those related to privacy and
confidentiality or to consumer protection laws.

~ 30 ~
9. APPLICATIONS OF SMART CARDS

The first chip cards were simple prepaid telephone cards implemented in
Europe in the mid-1980s, using memory cards. Today, the major active application
areas for microprocessor-based smart cards include: financial, communications,
government programs, information security, physical access security, transportation,
retail and loyalty, health care, and university identification. These are intersecting
areas in that the smart card may carry applications from more than one area (for
example, combining information and physical security access, or financial and
retail/loyalty).

Shown below are examples of smart card applications. Click each application
for an explanation.

Financial Applications

• Electronic Purse to replace coins for small purchases in vending

machines and over-the-counter transactions.

• Credit and/or Debit Accounts, replicating what is currently on the

magnetic stripe bank card, but in a more secure environment.

• Securing payment across the Internet as part of Electronic Commerce.

Communications Applications

• The secure initiation of calls and identification of caller (for billing

purposes) on any Global System for Mobile Communications (GSM)
phone.

• Subscriber activation of programming on Pay-TV.

Government Programs

• Electronic Benefits Transfer using smart cards to carry Food Stamp and
WIC food benefits in lieu of paper coupons and vouchers.

• Agricultural producer smart marketing card to track quotas.

~ 31 ~
Information Security

• Employee access card with secured passwords and the potential to

employ biometrics to protect access to computer systems.

Physical Access

• Employee access card with secured ID and the potential to employ

biometrics to protect physical access to facilities.

Transportation

• Drivers Licenses.

• Mass Transit Fare Collection Systems.

• Electronic Toll Collection Systems.

Retail and Loyalty

• Consumer reward/redemption tracking on a smart loyalty card, that is

marketed to specific consumer profiles and linked to one or more
specific retailers serving that profile set.

Health Card

• Consumer health card containing insurance eligibility and emergency

medical data.

University Identification

• All-purpose student ID card, containing a variety of applications such as

electronic purse (for vending and laundry machines), library card, and
meal card.

~ 32 ~
APPLICATIONS IN THE U.S

Because of the significant investment in an extensive magnetic stripe-based

infrastructure, and the availability of reliable and low cost on-line telecommunication
services, the U.S. has thus far represented a limited smart card market. Smart card
projects implemented in the U.S. have been primarily closed systems deployed on
military bases, universities, and corporate campuses. The exception to this has been
the movement by the Federal Government to use smart cards in Electronic Benefits
Transfers for food stamps and other similar social programs nationwide.

The Federal Government’s ultimate goal is to adopt a limited number of multi-

application smart cards that will support a wide range of Government-wide and
agency-specific services. It is envisioned that eventually every Federal employee will
carry smart cards that can be used for multiple purposes such as identification,
building access, network access, property accountability, travel, and other
administrative and financial functions.

The U.S. Smart Card market comprises six major industries. Financial service
lead it off with 32% of the market. Followed by retail with 27%, government with
22%, education with 18%, and a tie for last between transportation and phone; both at
1%.

This completes Smart Card Technology, an on-line multimedia presentation,

presented by the General Services Administration. We hope you have enjoyed this
presentation and you will take time to explore the Smart Gov Web site where you will
find the latest in smart card news and information.

~ 33 ~
10.CONCLUSION

Most available smart card readers rely on the fact that less-than-optimal data
transfer rates to and from the card are acceptable due to the current state of smart card
technology. However, at the rate this technology is progressing, smart card readers
will soon have to offer higher transfer rates to keep response times within acceptable
limits.

The ISO 7816 standards for smart cards and smart card readers do allow for
increased data transfer rates that will cater for the needs of future smart card
technology. The majority of readers available are unable to support this aspect of ISO
7816 due to their microprocessor-based designs featuring a crystal oscillator. This
limitation can be overcome through the use of a CPLD-based design.

The CPLD allows the smart card interface device to optimise its
communication speed with the smart card, making the device particularly suited to
applications requiring the transfer of large amounts of data (for example, biometric
applications). It also enables the smart card interface device to achieve full
compliance with ISO 7816. The problems introduced by the use of a CPLD are easily
overcome through programming and the addition of simple hardware (such as a buffer
IC), making CPLD-based design both viable and attractive.

11.REFERENCES
~ 34 ~
1. "Schlumberger Shipments of Java Card Development Kit Demonstate Rapidly
Growing Market", Schlumberger Press Release, 25 September 1997
http://www.slb.com/ir/news/et-newcyber0997.html.
2. "Smart Card Technology: Introduction To Smart Cards", Dr D. B. Everett,
Smart Card News
http://www.linuznet.com/smartcard/docs.html.
3. S. Guthery, T. Jurgensen, "Smart Card Development Kit", Macmillian
Technical Publishing, 1998, pages 57 - 81.
4. D. Corcoran, "Muscle Flexes Smart Cards into Linux", Linux Journal, August
1998, page 49.
5. P. J. Ashenden, "The VHDL Cookbook", First Edition, pages 1-5.
http://www.ece.uc.edu/~rmiller/VHDL/intro.html.
6. K. Skahill, "VHDL for Programmable Logic", Addison-Wesley, 1996, pages 3
- 23.
7. D. Pellerin, "An Introduction to VHDL for Synthesis and Simulation"
http://www.acc-eda.com/h_intro.htm.

~ 35 ~