EMV basics for those who wok in Electronic Payment field

1. Hypercom®, Europe.
Pitreavie Drive
Pitreavie Business Park
Dunfermline
Fife, Scotland
KY11 8PU
Tel. +44 (0) 1383 629800
Fax: +44 (0) 1383 629801
What is EMV ?
Ian Smith

2. Introduction
What is EMV?
EMV is a standard designed by Europay, Mastercard and Visa which lays
down the rules by which smart cards can be used to perform financial
transactions.
What is a Smart Card ?
For the purposes of this document, a smart card is a card containing a
chip, which is compliant with ISO standard 7816. The chip contains both
memory and a processor, and is capable of storing data, performing
calculations and making decisions.
What is the purpose of EMV ?
The principal purpose of EMV is to combat fraud associated with mag
stripe based transactions, with the ultimate objective being secure offline
transactions. EMV is also a global standard ensuring that a card issued
anywhere, will work in a terminal anywhere.
What is a secure transaction?
A transaction is considered secure when it contains sufficient protection
to ensure that a person monitoring terminal and/or card activity would be
unable to acquire sufficient data to replicate or falsify a subsequent
transaction.
The major challenge of EMV is to perform a secure transaction in a
terminal which may not itself a secure device, i.e. does not contain any
secret data or functionality.

3. What does an EMV Card look like?.
An EMV card looks like a normal mag stripe card with the addition of a
set of gold contacts on the front surface.
Front View Rear View
What are the contacts for ?.
There are 8 contacts on the card but only 5 are currently used and these
allow the EMV chip and terminal to be connected together. The contact
functions are 5V, 0V, Clock, Data and Reset.
What’s on the mag stripe ?.
The mag stripe contains the same data that is present on existing cards.
Eventually, the mag stripe will be phased out, but when this is to happen
has not yet been agreed.
Can I swipe an EMV card
Yes and No, in addition to the usual data, the mag stripe of an EMV card
also contains a service code which indicates to the terminal that a chip is
also present. Chip capable terminals will not accept the swipe and will
insist that the chip is inserted instead. Non chip capable terminals will
accept the mag swipe.
Why does an EMV transaction take longer than mag stripe ?
An EMV transaction is permitted to take up to 5 seconds longer than the
equivalent mag stripe transaction. The reason for this is that the two
transaction types are very different. An EMV transaction involves
considerably more processing, which is described in the remainder of this
document

4. What’s the difference between a mag stripe and EMV transaction ?
A Mag Stripe Transaction
In a mag stripe transaction, the card is swiped and a brief burst of data
flows from card to terminal. Having received the data, the terminal makes
a decision to accept the transaction, reject the transaction or go online for
authorisation.
Terminal
Authorisation Host
Terminal alone makes
Accept / Decline / Online Decision
Brief flow of data
Card to Terminal only
Authorisation
communications
Swipe
This transaction presents a number of security problems.
1. The data on the card is writeable and may have been modified
2. The card may even be a copy of another card.
3. The card does not “know” if the authorisation host is “real”
4. The host does now “know” if the card is “real”.
5. The card does not have to be present as manual keying is possible
6. A card holder can deny that a transaction ever took place.

5. A chip transaction
When a chip card is inserted into a terminal, a conversation between card
and terminal takes place throughout the transaction. The terminal and
card jointly make a decision to accept the transaction, reject the
transaction or go online.
Terminal
Authorisation Host
Terminal and card make joint
Accept / Decline / Online Decision
Continuous flow of data
in both directions
Authorisation
communications
Insert
Secret
Data
This transaction presents a number of security improvements.
1. The chip data is read only and cannot be modified.
2. It is impossible to make a complete copy of a chip as each contains
secret data which is not accessible to the outside world.
3. If data is copied to another card and modified there, this is easily
detected and impossible to conceal.
4. For online transactions, the card verifies that the host it is real.
5. For online transactions, the host verifies that the card is is real.
6. For each transaction, an encrypted certificate is created which proves
that the card was present and that the transaction actually took place.
7. PIN verification can be used for offline and online transactions

6. The principal differences between mag stripe and chip cards are;
• The chip is an active participant in a transaction and contributes to the
accept/decline/online decision. In fact, the chip has the final say and
can reject or force online a transaction, against the wishes of the
terminal.
• A chip transaction uses secret data, which is buried on the card and is
never revealed to the terminal.
• As the chip and terminal communicate throughout a transaction, the
chip card must remain in the terminal throughout, This usually
prevents the signature on the card from being viewed therefore
signature comparison cannot be performed until the transaction is
over. If the signature is then found to be unsatisfactory, the transaction
must be voided.
• A chip card can contain multiple functionality, i.e. Credit/Debit and
Purse. Each type of functionality contained on a card is known as an
application.
What is the extra chip/terminal communications for ?.
Part of the data, which flows from chip to terminal, is the same as that
which would previously have been read from mag stripe. However, this is
a small part of the overall data flow, and the majority is associated with
additional security, and the handling of multiple card applications.
The remainder of this document will describe the sequence of steps which
form an EMV transaction, concentrating on the data involved including
where it comes from and what happens if it goes wrong.

7. EMV Transaction Flow Summary
The steps involved in an EMV transaction are;
1. The user inserts a card into the terminal.
2. The terminal powers up the card.
3. The terminal looks on the card for an application which it
knows how to run. (If more than 1 is found, the user is given the
choice).
4. All of the data from the chosen application is read from the card
into the terminal.
5. The terminal verifies that the card data has not been modified
since the card was manufactured.
6. The user is then prompted to enter a transaction amount.
7. If supported the user is prompted to enter their PIN
8. The terminal and card make a joint decision to reject, authorise
offline or go online for authorisation.
8.1 Reject
The card is powered down
8.2 Authorise Offline
Card generates a unique encrypted certificate proving that on a
given date and time, a transaction for a particular amount was
performed by a particular terminal.
The card is then powered down
8.3 Authorise Online
Via the terminal, the card and host prove to each other that they
are real. If this process is successful, a certificate similar to that
described above is generated by the terminal.
At this time, the authorisation host, via the terminal may
optionally transmit one or more issuer scripts to the card. The
card is then powered down
Each of the above steps will now be covered in more detail.

8. Card Insertion
When a chip card is inserted into a terminal, the EMV standard requires
that the chip is handled with care. To operate, the chip requires DC power
a clock pulse train and a reset signal, but these must be supplied in the
correct timed sequence. When this is done, the card will respond by
powering up and transmitting a reply, containing the card’s
communications capabilities, back to the terminal.
This process is called Answer to Reset (ATR) and allows the terminal to
configure itself to match the capabilities of the card. This process is
typical of all EMV commands in that the card will only transmit data in
response to a command from the terminal and will never ‘speak out of
turn’.
When a card is inserted into the terminal, it is possible that the
initialisation process may fail because;
1. The card does not have a chip.
2. The card may have been inserted the wrong way round.
3. The chip may be ‘dead’
4. The terminal’s card coupler may be inoperative.
If any of the above happen, the user is invited to try again. If a second
failure occurs, the user is invited to perform a mag swipe instead.
Card Removal.
The user can remove a chip card from a terminal at any time. If this
should occur in mid transaction, the EMV standard requires that the chip
be shut down in a controlled manner. This is to ensure that the chip is not
left ‘hanging’ and will operate correctly when next used.
To do this, the card coupler is equipped with a sensor, which provides
advance warning of card removal. The terminal immediately responds to
this warning by performing the chip deactivation sequence before
electrical contact with the chip is lost. The transaction is then voided.
At the end of a normal transaction, the chip is also deactivated in a
controlled sequence.

9. Determine Supported Applications
Once a chip has been powered up, the next step is to determine which
applications are on board. An application is a discrete type of activity,
which the card ‘knows’ how to perform. Typical applications are;
Credit/Debit
Loyalty
Club Membership
Passport
Medical History
A terminal cannot assume that a card, which has been inserted, contains
an EMV compliant chip and must be able to handle anything, which the
user cares to insert, within reason. The terminal must therefore establish
which applications are present on the card and this is done using a
number, contained in each application, called the Application Identifier
(AID).
Each AID is made up of two parts, the first 5 bytes are called the
registered identifier (RID) and identify the organisation which created the
application. Typical RIDs are;
A000000003 Visa
A000000004 Mastercard
A000000025 American Express
The second (optional) part of an AID is called the PIX . It can be up to 11
bytes long and is used to differentiate between the applications created by
each issuer. Typical AIDs (including PIX) are;
A0000000031010 Visa Credit/Debit
A0000000031020 Visa Delta
A0000000041010 Mastercard Credit/Debit

10. When a card is inserted, the terminal must read from it the supported
AIDs. This list is then compared with the AIDs with which the terminal
has been configured.
Terminal
Terminal creates list of
mutually supported AIDs
Config Host sends
AIDs list to terminal
Terminal
reads AIDs
from card
Config
Host
Card
AIDs
A001
A002
A003
AIDs
A001
A002
A003
AIDs
A001
A002
A004
When comparing AIDs, the terminal must use two different matching
criteria. The simplest of these is exact matching and this requires the AID
in the terminal and card must match exactly. The second criterion
requires that all of the characters in the terminal AID must match those of
the card but that the card AID may have additional unmatched characters.

11. This is called partial matching, for example;
AID A00000002501 in the terminal is a partial match for
AIDA0000000250199 in the card.
Using the above rules, the AIDs supported by terminal and card are
compared and a list of mutually supported applications derived. There are
three possible outcomes from this process;
• No mutually supported AIDs exist.
The card is powered down and the card rejected. At present, the user is
then invited to perform a mag swipe, but this may change.
• One mutually supported AID exists
If the application requires user confirmation, this is requested
otherwise the application is run immediately.
• Multiple mutually supported AIDs exist.
The list of AIDs is offered to the user. The chosen application is then
run.
Note; The AIDs supported by a terminal are configured using
TermMaster and it is important that they are entered correctly. If they are
entered incorrectly, valid cards will be rejected by the terminal.

12. Application Selection
Once the user has chosen an application, the next step is for the terminal
to request that it be run by the card. This is done by transmitting the
appropriate AID, to the card, as part of a select command. The card will
normally respond by transmitting introductory data about itself back to
the terminal. If this happens, all is well and the transaction can proceed.
However, the application selection process can fail because;
1. The application advises that it is blocked.
The card issuer does this to prevent the application being used,
usually because the cardholder has not paid their bill.
2. The application’s conditions of use have not been satisfied.
Application is for ATM use only
Application cannot be used in foreign countries.
Application cannot perform this type of transaction.
(and many others)
If all is well, the terminal uses the data list provided by the card, to read
all of the data necessary to perform a transaction.
Terminal
2) Terminal reads
all data from card
Card
1) Terminal sends
select command to
card
3) Terminal stores data in
a database for later use
One all of the data has been read, the next step is to confirm that the data
on the card has not been modified, which is done using a process called
data authentication.

13. Data Authentication
EMV allows for two forms of data authentication, Static Data
Authentication (SDA) and Dynamic Data Authentication (DDA).
1. Static Data Authentication
This is a checking process which allows the terminal to confirm that the
data read from the card has not been modified since the card was
manufactured. Unfortunately this process cannot detect a card which is an
exact duplicate of another card.
2. Dynamic Data Authentication
This is a checking process which process can detect both modified and
duplicate cards. To do this, in addition to the checks performed
previously, the terminal and card must perform cryptography using secret
data on the card. This requires that the card contains a powerful
processor and at present, no real cards in circulation can perform DDA.
Test cards however do exist.
As data authentication failure is one of the most common reasons for
transaction failure, the process will be described in more detail, but
before doing so it is necessary to briefly go over the cryptography
involved.
Cryptography
EMV employs two forms of cryptography, DES and RSA, each of which
have different properties and are used for different purposes.

14. DES
DES stands for Data Encryption Standard, and is a very traditional style
of code. It is used to convert a message from a readable form into one
which cannot be read.
To encrypt a message under DES, the message is fed into a DES
encryption engine and a key is supplied. The engine scrambles the plain
text using the key and outputs an encrypted version.
To decrypt a DES message, the encrypted text is fed into a DES
decryption engine along with the original key.
Encrypted Text DES
Decryption
Plain Text
DES Key
It is vital that the same key is used to both encrypt and decrypt the
message. It is also vital that the key remains secret or security is lost.
DES
EncryptionPlain Text Encrypted Text
DES KEY

15. RSA
DES is extremely powerful, but codes of this type have existed for
hundreds of years. RSA on the other hand is a new type of code named
after it’s authors, Rivest, Shamir and Adleman, who invented it in 1978.
Instead of being used to protect a message from ‘prying eyes’, RSA is
used to prove the authenticity of a message i.e. that the message
genuinely originates from the person or organisation who claims to have
sent it. RSA uses not one key but two, known as a key pair. The
following explanation assumes that a pair of keys (A and B) has been
created.
To encrypt a message under RSA, it is necessary to feed the plain text
into an RSA encryption engine along with Key A.
R S A
E n c r y p t
T e x t e n c r y p t e d
u n d e r K e y A
P la in T e x t
R S A K e y A
To decrypt such a message, it is necessary to use the other key.
RSA
Decrypt
Plain TextText encrypted
under Key A
RSA Key B
This also works the other way round, i.e. a message encrypted under key
B must be decrypted using key A. If decryption is attempted using the
original key, the result is gibberish.

16. When RSA is used, it is normal that one of the keys is kept secret and the
other openly published, with these being known as the private and public
keys respectively. Publishing a key might at first seem odd, but the reason
is as follows.
An organisation can send messages encrypted under a private key to any
body who has knowledge of the corresponding public key. Anyone in
receipt of such an encrypted message can prove it’s authenticity by
attempting to perform decryption using the known public key. If the
message can be successfully decrypted, this proves that the sender
encrypted using the corresponding private key and therefore that the
message is genuine.
Correspondingly, although knowledge of the public key allows the
authenticity of a message to be established, it does not confer the ability
to create false messages. Encrypting a message under the public key will
not succeed as others will be unable to decrypt it.1
Is is vital that the private key remain secret or security is lost.
It is also vital that public keys are obtained from a trusted source.
For example, if you expect to receive messages from organisation X, you
will need a copy of their public key. A fraudster may generate their own
key pair and persuade you that the public key actually belongs to
organisation X. If you accept this key, then the fraudster can then send
you messages, which you will believe to originate from organisation X.
1
Ironically, were a message to be encrypted under the public key, the only person who could read it
would be the legitimate owner of the corresponding private key.

17. Data Authentication (Once Again)
RSA is used in Data Authentication as follows. When a card is
manufactured, the issuer takes some of the important data (PAN
cardholder name etc) and encrypts it under RSA using a private key. The
original and encrypted data are then stored on the card.
RSA
Encrypt
Private Key
Original and
encrypted data
stored on card
Original
Data
During a transaction, the terminal reads the original and encrypted data
from the card.
Original and
encrypyed data
read from card
Original Data
RSA
Decryption
Terminal
compares
original and
decrypted
data
RSA Public Key
Using the corresponding public key, the terminal decrypts the card data.
If the decryption does not work, the card is suspect.
If the decryption works, but the encrypted data does not match the
original, then the card has been modified since manufacture.

18. This allows fake and modified cards to be detected but a card containing
an exact copy of the data from another would pass this test. Therefore
SDA authentication cannot be considered to be completely secure. This
final problem can be addressed by using Dynamic Data Authentication
(DDA).
Dynamic Data Authentication
In SDA transactions, the card contains data, which was encrypted using
the issuer’s private key, whilst in DDA transactions, the card actually
contains the issuer’s private key and can perform RSA encryption. When
DDA is performed, the terminal first performs SDA as described
previously before going on to do the following additional step.
The terminal generates a random number, which along with other
transaction related data is transmitted to the card. The card then RSA
encrypts the data using it’s private key, and returns the result to the
terminal.
Terminal Card
1) Terminal sends
message to the card
including date, amount,
and a random number
RSA
Private
Key
2) Card
encrypts data
then returns it
to terminal
RSA
Public Key
3) Terminal decrypts
data and compares it
with original message.
If they match, all is well
The terminal then attempts to decrypt the data using the corresponding
public key. If it can recover the original data (including the random
number) this proves that the card ‘knows’ the private key. Since the
private key is hidden, and cannot be copied, the card must be genuine.

19. As further security measure, the EMV public key system also includes the
concept of date expiry. The encrypted data contained on a card has an
expiry date after which the terminal decryption process is mandated to
fail. Data authentication can fail for the following reasons.
• The terminal does not contain the required public key
• The public key contained in the terminal is incorrect.
• The encrypted data certificate on the card has expired.
• The terminal date is set incorrectly and the terminal thinks that the
encrypted data certificate on the card has expired.
Hypercom terminals can store 60 RSA public keys which are loaded into
the terminal via TermMaster. To prevent fraud, when adding a new key,
to TermMaster, it is vital that that the authenticity of each key is
confirmed.
Once the authenticity of the card data has been confirmed, the transaction
can move on to cardholder verification.

20. Cardholder Verification
This is the process by which it is determined that the person presenting
the card is the legitimate user. To do this the card presents to the terminal,
a list of methods by which this may be done. Associated with each
method is a rule which determines what should happen if the method is
unsuccessful.
The available methods are:
• Signature
• Offline Plain Text PIN (PIN verified by the card)
• Offline Encrypted PIN (PIN verified by the card)
• Online encrypted PIN (PIN verified by authentication host)
• No CVM required
The available rules are
• Apply the next method if this is unsuccessful
• Fail cardholder verification if this method is unsuccessful
Using this system it is possible to build a CVM list such as:
1. Perform Encrypted PIN (If unsuccessful perform the next method)
2. Perform Plain Text PIN (If unsuccessful perform the next method)
3. Perform Signature (If unsuccessful, fail CV processing)
If the cardholder verification process is unsuccessful, the transaction does
not terminate immediately as the eventual outcome is determined by the
action analysis process.

21. Action Analysis
After cardholder verification has been performed, action analysis takes
place. This is the process by which the terminal and card jointly
determine if the transaction should be rejected, accepted offline or online
authorisation obtained. It is performed in two stages.
• The first part of the process is performed by the terminal which uses
it’s own built in rules to determine what it thinks should be done.
• The terminal’s recommendation is then transmitted to the card which
goes on to make the final decision.
• Once the final decision is made, for each transaction, the card
generates a unique certificate called an application cryptogram which
contains details of the transaction including date, amount, terminal and
card information. This data is encrypted by the card and can be used to
prove that a particular terminal performed a transaction, with a
particular card, for a certain amount, at a certain date and time.
When making the initial decision, the terminal makes use of data items
called Transaction Verification Result (TVR) and Action Codes.
Transaction Verification Result
The TVR is a 5 byte number, maintained by the terminal, in which each
bit represents the status of an event which may or may not have happened
during the transaction. e.g Data authentication failed, transaction
randomly selected for online processing, cardholder verification failed ,
offline transaction limit exceeded, floor limit exceeded etc.
Action Code
An action code is also a 5 byte number, in which the bits have similar
meanings to those of the TVR. Whilst the setting of a bit in the TVR
indicates that a particular event happened, the setting of the equivalent bit
in an action code indicates what the terminal’s response to the event
should be.

22. When performing this comparison, each bit in the TVR is compared with
it’s equivalent in the action code. In the example below, the least
significant bit is set in both codes.
0 0 0 0 0 1 0 1
Transaction verification result (TVR)
1 1 1 1 0 0 0 1
Action Code
1) The code is bitwise compared to
the transaction result
The first part of the action analysis process is performed by the terminal
and consists of comparing the terminals TVR result with three action
codes called denial, offline and default.
Denial
The TVR is first compared to the denial code. If any of the corresponding
bits are set, the terminal will recommend denial to the card.
Online
The TVR is then compared to the online action code. If any
corresponding bits are set, the terminal will recommend online
authorisation to the card. Otherwise it will recommend offline
authorisation.
Default
If a terminal has attempted to go online, but the host cannot be contacted,
this code determines if the terminal can authorise the transaction offline.

23. The bit settings of the action codes are very important and come from two
separate sources. The terminal (via Termmaster) is configured with denial
online and default codes, which are known as the Terminal Action Codes.
In the same way, each card is also configured with denial, online and
default codes known as the Issuer Action Codes.
The action code used during a transaction is derived by merging the
equivalent terminal and issuer codes together. The following example
shows how the denial action code is constructed.
0 0 0 0 0 1 0 1
Transaction verification result (TVR)
1 0 1 0 0 0 0 0
0 1 0 1 0 0 0 1
1 1 1 1 0 0 0 1
Terminal Denial Code
Card Denial Code
Merged Denial Code
1) The terminal and card codes are
merged together
2) The merged code is bitwise
compared to the transaction result
3) This transaction would be
denied
Note: The terminal action codes present in a terminal are configured via
TermMaster and it is very important that they are entered correctly.
As a consequence of the merging process described above it is very difficult to answer the
seemingly simple question “Why was my card rejected?

24. When the TVR/Action Code comparison process is complete, the
Terminal transmits it’s recommendation to the card along with certain
transaction related data, usually including the date, amount, PAN and
a random number. The card is permitted to agree with, or downgrade,
the terminal’s recommendation and the following table lists the
possible outcomes.
Terminal Recommendation Possible Card Decision
Reject Reject
Online Online
Reject
Accept Accept
Online
Reject
In reaching it’s decision, the card is permitted to employ scheme specific
rules, such as customer spending patterns, which are unknown to the
terminal. In addition to it’s decision, the card also returns a certificate,
encrypted under DES (using a key which is part of the secret data).
The type of certificate returned will depend if the transaction is to be
rejected, accepted or online authorisation requested.

25. Offline Approval
For an offline approval, the encrypted data, called the Transaction
Certificate, is stored in the transaction store. This certificate contains
proof that the transaction actually took place. As the certificate is
encrypted, alteration or forgery is not possible, therefore the cardholder
cannot deny that a transaction took place and the merchant cannot
subsequently alter any of the transaction details.
1) Terminal sends
message to the card
including date, amount,
and a random number
DES
DESKey
2) Card
encrypts data
then returns it
to terminal
3) Terminal stores
encrypted certificate
in transaction tank
Rejected Transactions
For a rejected transactions the procedure is very similar to that described
above. The encrypted data, called the AAC, which is returned by the card
is stored in the transaction store. This certificate contains proof that the
transaction actually took place but was rejected. As the certificate is
encrypted, alteration or forgery is not possible, therefore the merchant
cannot subsequently alter the transaction details to make it appear that a
valid transaction took place..

26. Online transactions
For online transactions, a similar process to that described previously
takes place with the exception the certificate returned from the card
contains an authorisation request certificate (ARQC). The terminal
forwards this to the authorisation host.
When the host receives the message, it attempts to replicate the
cryptology performed by the card. The response transmitted to the
terminal will depend if this is successful.
1) Terminal sends
message to the card
including date, amount,
and a random number
DES
DESKey
2) Card
encrypts data
then returns it
to terminal
3) Terminal sends
original and encrypted data
to authorisation host
DES
DES Key
4) Host attempts to
replicate encryption
performed by card.
4) Terminal receives
response fromhost.
(see next drawing)

27. If the host cannot replicate the original cryptology, it generates a rejection
certificate (ARPC) which is transmitted to the terminal. The certificate is
stored and the transaction terminated.
4) Terminal stores
rejection certificate
DES
DES Key
1) Host fails to replicate card encryption.
3) Terminal receives
reject response from host.
2) Host encrypts rejection certificate and
sends it to terminal
5) Terminal shuts
down the card

28. If the host is able to replicate the card’s cryptology then it knows that it is
dealing with a genuine card. However the host must now prove to the
card that it is also genuine, and this is done by performing a further
encryption of the original data, which is then sent back to the terminal.
4) Terminal receives
response fromcard.
(see next drawing)
DES
DESKey
2) Card tries to
replicate host
cryptology
3) Terminal sends
challenge to card
DES
DES Key 1) Host replicates card encryption
2) Host encrypts DES card
challenge and sends to terminal
What happens next depends if the card is able to replicate the cryptology
performed by the host.

29. If the card is able to replicate the cryptology performed by the host, then
it knows that the host is real. The transaction may now be completed and
to do this, the card then generates a transaction certificate (TC) which is
transmitted to the terminal and stored as before.
3) Terminal receives
and stores transaction
certificate
DES
DESKey
2) Card encrypts transaction
certificate and sends to
terminal
1) Card
replicates
host
cryptology

30. If the card is unable to replicate the cryptography performed by the host,
then the card will assume that the host is not ‘real’. If this should happen ,
the transaction must be voided and to do this, the card generates a
rejection certificate (AAC) which is transmitted to the terminal. When
this certificate is received by the terminal it is stored as previously.
There is however an additional step to be performed as the authorisation
host must be advised that the transaction did not succeed. To do this, the
terminal may create a reversal record or immediately go online for a
second time (protocol specific).

31. 3) Terminal receives
and stores reject
certificate fromcard.
DES
DESKey
1) Card fails to
replicate host
cryptology
4) Terminal goes
online and tranmits
certificate to host
2) Card encrypts reject
certificate and sends to
terminal
Host voids transaction

32. Issuer Scripts
Once the transaction has been completed, EMV has one more trick up it’s
sleeve. As part of the authentication message, a host can include one or
more issuer scripts scripts. The terminal, which does not understand the
script contents, simply forwards them to the card, which executes the
instructions contained. Scripts can be used to perform such tasks as
blocking applications or updating card data. This scripting operation is
‘invisible’ to the user.
Security Summary
The security status of the various combinations of data authentication and
on/offline authentication is as follows.
Authentication/Mode SDA DDA
Offline Not fully secure Secure
Online Secure Secure
PIN Entry Mode Plain Text Encrypted
Offline Not fully secure Secure
Online -------- Secure
From this table it can be seen the offline SDA transactions are not fully
secure. It for this reason that offline authorisation is currently restricted to
low risk transactions involving low amounts etc. Although full security
could be obtained by sending all transactions online, this is unacceptable
from both the merchant acquirer and network loading standpoints.
For this reason, the objective of fully secure offline transactions will not
be realised until cards supporting both DDA and Encrypted offline PIN
are in general use.

33. Appendix: Additional FAQs
What do the terms ‘EMV3’ and ‘EMV3.1.1’ mean
There have been several versions of the EMV standard. EMV3 was
released in June 1996 and has since been superseded by EMV3.1.1,
released in January 1998. A new version of the standard, called EMV4
was released in December 2000.
What is type approval ?.
Type approval is the testing process by it is proved that a representative
terminal complies with the requirements of the EMV standard. Type
approval is awarded by an organisation known as EMVCo There are
separate EMVCo approval processes for EMV levels 1 and 2.
What do the terms ‘Level 1’ and ‘Level 2’ mean ?.
EMV level 1 is the part of the EMV specification which deals with the
mechanical, electrical and communications interface between card and
terminal. For example, it dictates physical card size limits, current
consumption and the rules under which card to terminal communications
take place.
EMV Level 2 is the part of the EMV specification which deals with the
functionality required to support financial transactions. Principally this
involves application selection, transaction processing and cryptography.