EMV Card Basics: Seminar On Demand: Study Guide
EMV Card Basics: Seminar On Demand: Study Guide
by FSD Learning
__________________________________________________________
Duration: 21 minutes
Updated: August, 2009
__________________________________________________________
Abstract:
__________________________________________________
(Slide 1)
Hi I’m Ian Davidson and in a series of
seminars originally written by Neil Esler I
will be providing you with an introduction to
the EMV Integrated Chip Card technology
which you will need for debugging
messages if you are implementing EMV in
the NDC environment, or will form the basis
of an EMV solution in the programmable
world.
(Slide 2)
This is the first technical presentation in a
series of 5 seminars outlining the EMV
standards and we start with Smart Card
Basics.
We are going to cover Card Composition
where we will examine how a smart card is
put together, its architecture and the typical
life-cycle of the card.
Then we will look at the 4 ISO 7816
standards that EMV uses as a basis for
Integrated Chip Card technology.
Firstly ISO 7816-1 & 2 specify the physical
structure of the card, what goes where and
the external connections.
Next ISO 7816-3 defines the electrical
aspects of a smart card and finally ISO
7816-4 defines chip functionality such as
how to transfer data between the terminal
and the ICC.
(Slide 3)
During manufacture the chip is first
mounted onto a circuit board and then has
an electrical contact block bonded to it, with
wires connecting the individually isolated
pads. This combined unit is then glued to
the plastic card to make the final item. The
card is now ready for personalisation and
eventual issuing.
The inset diagram shows you how the chip
and its contacts sit in a cavity in the card.
(Slide 4)
The chip that makes the card smart
consists of five principal components:
• The Central Processing Unit (or
CPU) which executes the operating
system and application software
onboard; typically this is an 8 bit
RISC type processor.
• The Control Logic provides support
to the CPU to allow it to access the
ROM, RAM, EEPROM and outside
world.
• Some Read Only Memory (or ROM)
is used to store the operating system
which manages the data access on
the card as well as the critical key
manufacturing information.
• Random Access Memory (or RAM) is
the workspace for the CPU where
the dynamic parts of operating
system and application functionality
can be executed.
• Electrically Erasable/Programmable
Read Only Memory (EEPROM) is
half way between ROM and RAM
(Slide 5)
The first chapter in the card’s life-cycle is
the fabrication phase where the chip is
fabricated and the ROM is pre-loaded with
the manufacturer’s information and the
operating system; the content of the Read
Only Memory is also referred to as a ‘mask’.
Once the ROM is preloaded access to the
operating system and manufacturer
information is locked, preventing any
amendments. Having created a basic chip
and loaded the operating system we enter
the pre-personalisation phase where the
chip is mounted in to the plastic card.
The chip is tested at this point to ensure that it is fully functional after the mounting
process. Additional fabrication information is loaded at this stage and access to memory
is shutdown to logical only i.e. you must make a request through the operating system to
change any values, there is no way to directly access any memory location.
The personalisation phase is where they take the basic ‘white plastic’ and print on to it the
issuers preferred colours and logos, emboss it with the card numbers and load the
applications onto the chip. Finally the smart card is ‘locked down’ so that the card can be
used by the end cardholder.
(Slide 6)
Having produced and personalised the card
it is ready for use by the cardholder. This is
called the utilisation phase.
In the utilisation phase data can still be
accessed, as it is needed for processing,
however access is now restricted within
security parameters defined by the
application. When updating data on the
card (if the terminal is permitted to) the
security is maintained through the use of
RSA cryptographic keys.
Eventually the card will reach the end of its
life and will be invalidated; this phase could
be reached through the natural expiry of the
card (an expiry date is electronically stored
on the chip) or through predefined events
such as illegal access, issuer intervention to
lock the card or just too many wrong PINs
etc.
At this point the card is effectively no longer
usable and a new card will need to be
issued.
(Slide 7)
EMV haven’t written their own standards for
the Integrated Chip Cards, instead they
opted to use the existing ISO 7816 standard
which specifies the characteristics and
functionality for plastic cards containing
integrated circuit chips, or in other words,
smart cards.
ISO 7816 has been in existence for a long
time and is well understood by the industry
which means that the standard is
reasonably stable.
The wide acceptance of the ISO 7816 standard within numerous markets (not least the
mobile phone industry), allows the EMV specification to achieve one of the key goals of
interoperability, as well as ensuring a readily available source of hardware and software
systems capable of producing and processing them.
EMV utilises ISO 7816 and its constituent parts as the corner stone of both its EMV level 1
and level 2 specifications.
As ISO 7816 is so important to EMV, the rest of this seminar is dedicated to looking at the
first four parts, which define physical and functional attributes of a ISO 7816, and therefore
EMV, compliant smart card.
(Slide 8)
ISO 7816 parts 1 and 2 deal with the
location of the chip, the contact profile, size
of contact, contact uses and some electrical
attributes.
Also on the physical side these parts
specify how resilient the chip should be to
flexing, twisting, impact and general
environmental conditions such as ultra
violet light, x-rays, electromagnetic
interference and temperature fluctuations or
extremes.
Dwelling on the electrical contacts for a moment; all contacts are electrically isolated from
each other and are expected to be resilient, within practical limits, to electrical damage
from static or application of the wrong voltages.
The Vcc and Gnd contacts set up the power supply which allows the smart card to
operate.
Vpp is defined by ISO 7816 – but is not required for EMV cards.
CLK is the clock which synchronises communications which pass through the I/O contact.
RST is a reset line for restarting the smart card, a bit like a reset button on a PC.
(Slide 9)
Part 3 of ISO 7816 identifies the electrical
operating parameters and physical
communications attributes.
Electric characteristics such as supply
voltage (Vcc) and clock frequency are
defined; for example when the card is first
powered up the supply voltage must be
between 4.75 and 5v, 200mA.
The chip must then set its clock output to an
initial value of between 1 and 5 MHz,
although once communications have been
established this can be increased to values
between 5 and 20MHz for normal use.
As a rule of thumb lower voltages and
higher clock frequencies tend to mean
better performance.
The frequency used for the clock is
variable, but generally it is the same as TV
sets, because this provides a cheap and
ready supply of ‘crystals’ which regulate the
clock ticks.
On the communications attributes side, part
3 defines transport layer communications
protocols. The main two are referred to as
T=0 and T=1 which define character and
block transmission protocol respectively.
The first piece of data seen is the Answer to
Reset (ATR) which is provided by the card
the moment power is applied.
The ATR is the mechanism by which the
chip and the reader device establish an
agreement on card class, protocol,
communications speed, programming
voltages and currents.
The ATR also provides historical data which
can contain proprietary information such as
a electronic purse balance or ISO defined
application level information.
(Slide 10)
ISO 7816 Part 4 is the main component
which is utilised for EMV level 2 purposes
i.e. the terminal application.
Part 4 defines many important things, the
first of which is the filing system structure.
The file system is similar to the PC disk
operating system architecture.
There are several folder like components
called Definition Files (DF) which bring
together collections of data kept in
Elementary Files (EF) These Definition
Files (DF) files can be for either an
Application or a Directory.
If the DF is a Directory Definition File (DDF)
then the elementary file will contain entries
identifying the directory’s contents, i.e. an
application or further directory definition
files.
If the Definition File (DF) is an Application
Definition File (ADF) then the elementary
file will contain data components associated
with the ICC application selected.
This tree structure has a hierarchy which
starts with the Master File (MF), this is the
root Directory Definition File along side
which there will be one or more Elementary
Files (EF) that hold the ATR data and DIR
data.
The DIR can contain directory information
and proprietary data, for example, under the
MULTOS operating system this root
Elementary File would contain a list of all
the ICC applications present on the card.
(Slide 11)
The next thing of importance in 7816 part 4
is the definitions for how commands and
responses will be formatted for transmission
to the card by the transport layer.
When you send a command to the card,
you basically send a string that is made up
of;
• Class,
• the Command (or Instruction),
• Parameter 1,
• Parameter 2,
• the Length of the data to come,
• the data itself and
• the Expected Length of the
response.
Whether you need to send all of these parameters depends on the command that you are
running. You must always have the class, the command and the two parameter bytes.
If a reply is expected back from the card then you should specify the length of the
response that the terminal is expecting.
And finally, if you are sending data to the card then you need to specify the length of the
data followed by the data itself.
Basically the command cases revolve around whether data is being sent as part of the
command and whether data is expected back from the card.
This may not seem important in something like the NDC environment where the solution
takes care of all this for you, but when you are debugging a failed command, this is the
kind of data that will be printed to the journal and optionally sent back to the host.
(Slide 12)
Also under part 4, a number of commands
are defined.
The first of these gives you access to the
directory structure of the chip; the Select
File command allows you to access an
Application or Directory Definition File.
Then there are several data access and
management commands that allow you to
access the content of the Definition and
Elementary files. These include Read,
Write, Append and Update commands for
both Binary and Record formats.
The authentication commands allow the ICC card, the cardholder and a third party host
(normally the issuer) to be authenticated using RSA cryptography techniques.
Finally, when the terminal submits a command, such as Read Record, to the ICC without
knowing the length of the reply it should expect in response, the ICC will respond with just
the length of the data it wishes to send.
The terminal then uses the GET RESPONSE command to retrieve the specified amount
of data.
(Slide 13)
Whenever a command is submitted to the
smart card we expect a response of some
kind.
As a minimum, the card will respond with
two bytes of data called Status Words 1 and
2; these indicate the status of the command
in terms of success or failure; for example
90 00 indicates the command was OK
where 62 81 says that the data sent to the
card was not recognised by the ICC
application.
The Status Words are mandatory, but the
card may also respond with variable length
data; this is optional and depends on the
command it is replying to.
There are two common mistakes made when talking about Status Words 1 and 2.
Firstly many believe that they indicate just errors, this is not true, the status words are
used to drive processing in the terminal, along with other indicators contained within
command response data.
Secondly, Status Words 1 and 2 are each 1 byte. Instead “Status Word” would be better
thought of as “Status Byte”.
(Slide 14)
Finally, ISO7816 part 4 defines a method
for encoding data both when you are
submitting data to the card with a command
as well as receiving the response data from
the card.
This encoding is called BER-TLV, Basic
Encoding Rules, Tag Length Value.
Under EMV the tag is either 1 or 2 bytes
that uniquely identifies what the following
data refers to, for example tag 9F 35 says
that the following data is the Terminal Type.
If bits 1 to 5 in the first byte are all 1s, then the Tag is two bytes long, otherwise it is a
single byte. Bit 6 in the first byte identifies whether the encoded data is ‘primitive’ or
‘constructed’. A primitive data item is a single piece of data, whereas a constructed data
item is made up of one or more pieces of primitive data.
Tag values are administered by the ISO administrative body - ISO 7816 part 6 defines a
large collection of standard data objects, which are also utilised in EMV specifications as
well as some EMV specific ones.
The length is just that the length, in bytes, of the data to follow.
And then you have the ‘value’ which is the data itself. In a constructed data object the
value field is one of more BER-TLV data objects.
(Slide 15)
So in the examples above, the first BER-
TLV object is a primitive data object that
has a tag of 9F35, which identifies the data
as being the Terminal Type.
The data is 1 byte long, so the length is 1,
and finally the terminal type is 14, which
indicates an ATM.
Remember that a primitive object is just 1
piece of data.
The second example is a constructed
object, one that can contain one or more
data objects, so instead of having to issue
multiple commands to get all of the data, it
can be packaged into a single piece of data
which can then be split up into it’s individual
pieces.
77 identifies that it is a constructed object, then the 09 says there are 9 bytes of data.
But when you look at the next 9 bytes, these can be split into; tag 9F 1A, Terminal Country
Code, length 2 bytes, 08 26 which is the UK; then another tag 9F 35 which you know from
the first example is Terminal Type, length of 1 byte which is 14 i.e. an ATM.
Again, understanding this format is important when debugging failed commands to a card,
because this is the format used both when submitting and receiving data between the
terminal and the card.
(Slide 16)
Well that concludes our introduction to
Integrated Chip Cards, their life-cycle,
architecture and the specifications defining
them.
You should now continue to look at the
Candidate List Building, Terminal and Card
Processing and the Verification seminars to
complete the overview of EMV smart cards.
//End of Presentation//