EMV Training

Demystifying EMV and Chip Card

processing
Introduction
 EMV is the term used to denote the standards and
frameworks specified by EMVCo to support Chip card
based Debit/Credit Payment
 EMVCo is a company with EuroPay (now JCB),
MasterCard and Visa as equal stakeholders which
created the specifications for Chip Card payment
 EMV promotes the use of ICC/Chip Cards through
Payment systems mandates and a global timeline
 In this session, we will understand the functionality
of EMV transactions, risk management, offline and
online transactions, associated Cryptograms, Issuer
scripting and more.
Agenda
 Electronic Transaction basics 10 minutes
 Chip card – ICC basics 10 minutes
 EMV fundamentals 20 minutes
 EMV Transaction Flow 30 minutes
 EMV DE 55 20 minutes
 Cryptography in EMV 30 minutes
 EMV Cryptographic Keys 30 minutes
 CAM – Offline / Online 1 hour
 Issuer Scripting 30 minutes
 EMV Expert 10 minutes
 Wrap up and Q&A 30 minutes
Magnetic Stripe EFT limitations
 Limited amount of data can be recorded
 Easy for Fraudsters
 Does not protect against Skimming
 Lack of Risk Management in offline mode
means most transactions go online adding to
the transaction cost
 Greater Risk in MOTO, e-commerce
transactions
 Greater repudiability when used without
online PIN
Chip card – ICC basics
 Integrated Chip embedded into familiar Plastic card
 Increased Data Storage increases flexibility of card,
multi application support and storage of PINs and
Encryption Keys – prevent skimming in DDA and
online modes
 Chip means calculations can be performed on card
 Cryptography is supported leading to stronger
Authentication mechanisms
 EMV compliant Chip cards retain Magnetic Stripe for
use in fallback mode at Older terminals
 ICCs can be used at any Level 1 certified terminal or
IFD
 A copy of the Magnetic Stripe Image is also stored on
chip
EMV fundamentals
 EMV specifications published in Books 1 thorough 4
mandate and suggest (optional) mechanisms and
procedures for ICC-terminal interaction, Security and
Key Management, EMV payment applications and
participant (acquirer, cardholder, issuer) interactions
 Level 1 – hardware. ICC/Terminal interaction
specification
 Level 2 – software. Credit/Debit applications.
 EMV specifications promote interoperability to ensure
that any EMV compliant card can be accepted at any
terminal globally
 CCD or Common Core Definition ensures that
Payment Systems support basic common data
elements and functions
EMV fundamentals – cont.
 EMV transactions occur in both Offline as well as
Online modes based on the Risk Management of the
ICC and terminal.
 EMV includes some basic features and some optional
features. Payment systems may mandate some
optional features for increased risk management and
security
 Basic Features Include:
 Application Selection – through priority indicator or customer
selection at terminal. VSDC applications like Visa Electron,
Visa Classic or M/Chip applications like Maestro or
MasterCard.
 MSI on chip
 Random selection of transactions for Online processing
 Terminal Floor Limit Checking etc as in Magnetic Stripe cards
EMV fundamentals – cont.
 Optional Features include:
 Offline Data Authentication – SDA, DDA and CDA where the
terminal and the ICC interaction rather than an Issuer
authenticates the card
 Offline PIN – can be plain text or encrypted
 Offline Authorization Controls – Floor limit, velocity checks
etc
 Online CAM – using a dynamic online cryptogram passed to
the Issuer to validate the card ARQC
 Online Issuer Authentication – where the card validates that
the response came from a valid issuer by validating a
response cryptogram ARPC
 Issuer Scripts – Post Issuance updates can be performed on
the card like application block/unblock, PIN change, card
block etc by command scripts sent with the response
EMV Transaction Flow
 ICC is inserted into the IFD
 The terminal – ATM/POS activates the chip contacts
 Application is then selected for use by either the cardholder
selection method, or the cardholder verification method or
the Priority Application auto selection method
 Data Exchange happens between the ICC and the terminal
which determines based on ICC rules specified by the Issuer or
the Payment System what kind of Authentication
(Offline/Online) and CVM through PIN entry (offline plaintext /
offline enciphered) should take place
 In case all conditions for allowing an Offline Approval are
satisfied and Offline Authentication is successful, the terminal
itself Approves the transaction using Static Data Authentication
(SDA) or Dynamic Data Authentication (DDA)
EMV Transaction Flow – Cont.
• An EMV transaction can go online depending on whether offline
conditions are not satisfied or if 1 in N condition for online
transaction is met.
• In this situation, the ICC and terminal interaction creates an
online request TDES cryptogram (ARQC) using a session key
derived from the card Master key using transaction unique data
• The ARQC is sent with the Auth request through the Acquirer to
the Issuer
• The Issuer validates the ARQC to authenticate the Card by using
the same session key which is derived from the Issuer Master
Key
• The Issuer responds with an Approval / Decline along with an
Response cryptogram called ARPC along with an optional set of
post issuance commands called Issuer Scripts
EMV Transaction Example
EMV DE 55 - fields
 EMV or Chip transaction related data is transported
and manipulated as part of the Authorization Request
and Response within Data Element 55 which
supercedes the use of Extended third bit map
 DE55 is also required to be stored for sending in
Clearing and Settlement messages as well
 DE55 is also the carrier of the Online
Request/Response cryptograms – ARQC and ARPC as
well as Issuer Scripts
 DE55 data is identified using Tags which contain the
corresponding values for the transaction
 A detailed list of DE55 fields for Auth, Auth Response.
Settlement and Clearing is provided in the EMV SRS
for Soc Gen for easy reference.
Cryptography in EMV
 Additional security and fraud protection in EMV is
made possible with the use of Cryptography
 Cryptograms used in EMV serve two purposes –
Integrity (assure that the sender was indeed the
sender and that data was not modified in-between)
and Confidentiality (encrypt sensitive data to make it
impossible to decipher)
 EMV uses both Symmetric (Shared TDES key) as well
as Asymmetric (RSA private/public key pair)
mechanisms to achieve the above objectives
 EMV Issuers, Payment Systems generate, store and
securely propagate keys to Chip cards (during
personalization) and Acquirers (Payment CA public
key certificate for terminal injection)
Cryptography in EMV – cont.
 EMV specifications provide the guidance on the
security mechanisms using RSA and DES keys, key
management and algorithms to implement them
 All Keys in an EMV payment system should be
entered and stored in Hardware Security Modules
(HSM) – Atalla (and variant), Thales (Racal) already
support EMV TDES Application Cryptograms
 All keys are to be used within the published crypto-
periods which is determined by the length of the key
 Online Application Cryptograms use the TDES
mechanism of Cipher Block Chaining (8 bytes) with
Encrypt Decrypt Encrypt
 The various keys used by all the participants of an
EMV transaction are tabulated in the next slide
EMV Cryptographic Keys
Payment System Keys
Key Name Key Description Type

Payment System Private Key of RSA Key pair for Asymmetric Cryptography used in RSA
Private Key - SCA signing Issuer Public Key Certificate

Payment System Payment System Public Key made available to Acquirers for RSA
Public Key - PCA Terminal injection used in SDA, DDA and PIN validation. Used by
Issuers to verify correctness of their Public Key Certificate signed
with the SCA and the terminals to verify that the Issuer Public Key
Certificate, which is signed with the Payment System Private Key is
valid.

Terminal Keys
Key Name Key Description Type

Payment System Payment System Public Key injected into terminals by Acquirers. RSA
Public Key - PCA Used by terminals to verify that the Issuer Public Key Certificate,
which is signed with the Payment System Private Key is valid in SDA
mode, which in turn validates the ICCPK for DDA/CDA and the ICCPE
during Offline PIN Encipherment.
EMV Cryptographic Keys - Cont.
Issuer Keys
Key Name Key Description Key Type

Issuer Private Key - SI Private Key of RSA Key pair for Asymmetric Cryptography used in signing RSA -
ICC Public Key Certificate Asymmetric

Issuer Public Key - PI Issuer Public Key provided to Payment System for creating Issuer Public RSA –
Key Certificate Asymmetric

Issuer Public Key Issuer Public Key and Issuer data signed by Payment System Private key – RSA –
Certificate - PKIss This is stored on every ICC as part of Personalization in order to support Asymmetric
Offline SDA.

Issuer Master Double length Triple DES key that the Issuer generates and used to derive TDES –
Derivation Key - IDKAC the Card Master Keys, which in turn generate the Session Keys for use in Symmetric
Online Application Cryptograms – MAC.

Issuer Secure TDES key generated by Issuer used to derive Card Keys used to provide TDES –
Messaging for Integrity to Post Issuance Secure Messaging like Issuer Scripts Symmetric
Integrity - IMKSMI

Issuer Secure TDES key generated by Issuer used to derive Card Keys used to encrypt TDES –
Messaging for Post Issuance Secure Messaging data like PIN changes Symmetric
Confidentiality -
IMSSMC
EMV Cryptographic Keys - Cont.
ICC – Chip Card Keys for Offline transactions

Key Name Key Description Key Type

Issuer Public Key Stored on every ICC as part of Personalization in order to support Offline SDA. RSA –
Cert - PKIss Used in offline DDA/CDA/Pin Encryption in an indirect chain fashion by Asymmetric
validating the ICC public key certificates ICCPK.

ICC Private Key - Private key of RSA key pair generated by Issuer and stored onto the ICC during RSA –
ICCS personalization. Asymmetric

ICC Public Key - Public Key of ICC RSA key pair generated by Issuer and stored on ICC during RSA –
ICCP personalization Asymmetric

ICC Public Key ICC Public Key Certificate digitally signed using Issuer Private key used by ICC RSA –
Cert for by providing to terminal for use in DDA and CDA. May be used for offline PIN Asymmetric
Authentication - encryption.
ICCPK
ICC Public Key ICC Public Key Certificate digitally signed using Issuer Private key used by ICC RSA –
Cert for PIN by providing to terminal for use in offline PIN encryption to separate the key Asymmetric
encryption - ICCPE usage.
EMV Cryptographic Keys - Cont.
ICC – Chip Card Keys for Online transactions

ICC Master Key - Double length Triple DES key derived from the IDKAC Issuer Master TDES –
MDKAC Derivation Key using the ICC PAN and PAN sequence number. This in Symmetric
turn generates the Session Keys for use in Online Application
Cryptograms – MAC. Stored on the card during Personalization.

Card Master Key TDES card master key derived from the IMKSMI and used to provide TDES –
for Issuer Secure Integrity to Post Issuance Secure Messaging like Issuer Scripts Symmetric
Messaging for
Integrity -
MDKSMI

Card Master Key TDES card master key derived from the IMSSMC and used to derive Card TDES –
for Secure Keys used to encrypt Post Issuance Secure Messaging data like PIN Symmetric
Messaging for changes
Confidentiality -
MDKSMC
Offline Data Authentication
 EMV allows for the flexibility of transactions
to be approved offline – by the terminal itself
due to the increased security of the ICC as
well as the improved Risk Management
 Conditions for Offline transaction
authorization are specified by Payment
Systems or Issuers and are personalized on
the ICC as well as subject to Terminal Risk
Management
 Offline Data Authentication is accomplished
by validating Card data securely through the
use of RSA keys
Static Data Authentication SDA
 In SDA, the terminal verifies a static signature of ICC card data
– this is a 2 layer scheme
 The Issuer creates a digital signature of key application data
including PAN, Exp Date, Transaction control or Card risk
management data signed using the Issuer Private Key and
personalizes the card with this information referred to as SSAD
 During an offline SDA transaction, this SSAD is passed to the
terminal where the terminal verifies the Signed data using the
Payment System CA public key to verify the Issuer Signature
 Then based on the card risk management and payment
system/acquirer defined risk rules, the terminal can either
approve or decline the transaction without going online to the
issuer
 SDA uses Static data and is prone to Electronic Skimming
attacks
Dynamic Data Authentication DDA
 In DDA, after the terminal verifies the static data
 The ICC card generates a dynamic signature of the transaction
unique data from the terminal and card using the RSA ICC
Private Key
 The terminal validates the Dynamic Signature to prove that the
card is valid – a 3 layer scheme
 DDA dynamic signature computation should include other ICC
data elements like ATC as well as from the terminal like the
“Unpredictable Number” which is a MUST and transaction
Amounts
 DDA involves the use of the following ICC RSA keys
 Issuer Public Key Certificate
 Card Private Key
 Card Public Key and Certificate
 For DDA support, it is important for ICC cards to include an
on-chip crypto processor
Offline PIN CVM
 In all the above offline modes, offline PIN validation can also
be supported for plaintext as well as enciphered PIN
 Cardholder entered value sent back to the ICC is compared
with the reference PIN stored on the card by means of a
VERIFY command. The ICC informs the terminal the success or
failure of the VERIFY command by means of a “response to
verify” and also optionally by inspection of the CVR
 Two types – plaintext and enciphered
 Offline PLAINTEXT PIN where the cardholder entered value in
the VERIFY command is sent in the clear.
 Offline Enciphered PIN where the cardholder entered value is
RSA encrypted by the terminal using the ICC PIN encryption
public key. The ICC uses its corresponding Private Key to
decipher and compare the PIN – the DDA RSA key pair can be
optionally used to reduce the key management
Online Application
Cryptograms – ARQC & ARPC
 Online Card Authentication Method is invoked when either the
ICC or the terminal deems that an offline authentication would
not suffice due to the risk management parameters or acquirer
terminal rules not being met, or due to randomness of online
transaction on the ICC being met
 In such a scenario, the transaction is sent ONLINE to the Issuer.
The Generate AC command from the terminal results in the ICC
generating an ARQC (Application Request Cryptogram) from
important transaction data using TDES algorithm, which
implies a secret key usage
 The ARQC cryptogram is generated by the ICC using a session
key derived from the Card Master Key, which is personalized
on the ICC after being derived from the ISSUER Master Key
 ARQC = MAC(SKAC)[Input] where SKAC is the session key derived
from the Card Master Key.
ARQC – DE55 TAG 9F26
 The required data input to create an ARQC cryptogram which is
part of DE55 as TAG 9F26 are shown below:
 Amount, Authorized
 Amount Other
 Terminal Country Code
 Terminal Verification Result
 Transaction Currency Code
 Transaction Date
 Transaction Type
 Unpredictable Number
 Application Interchange Profile
 Application transaction counter (ATC)
 Issuer Application Data (IAD)

 The ARQC generation TDES Algorithm is a CBC Mode EDE

(Encrypt Decrypt Encrypt) scheme using a session key derived
using the Card master key and the ATC or Application
Transaction Counter
ARQC Validation
 The Issuer gets the Online request along with the
ARQC
 The Issuer uses the ISSUER Master Key to arrive at
the same Session key derivation knowing the ICC
PAN and PAN sequence Number and creates its own
ARQC using the same data elements as input
 The Issuer is able to validate the ARQC by
comparing the two – Hardware security modules
from Atalla or Thales/Racal do this behind the
scenes and validate the ARQC
 Once the ARQC is validated, the Issuer processes the
transaction resulting in an Approval or Decline
ARQC Flow
ARPC Generation by Issuer
 In case Issuer Verification is also required, an ARPC
(Authorization Response Cryptogram) cryptogram is
to be generated and returned to the ICC, which
includes the Authorization Response Code (ARC)
 The ARPC is generated as follows:
 Input = XOR of ARC (right padded with 0 bytes) and the
ARQC
 ARPC = TDES(SKAC) [Input]
 The ARPC is returned to the ICC where the ICC
verifies the Issuer authenticity assuring the ICC that
a valid issuer responded to its online request
 Again, the HSM devices mentioned earlier create a
valid ARPC using the same session key used to
validate the ARQC
Issuer Scripting
 Issuer Script Processing enables issuers to change
personalized data on cards without re-issuing the
cards
 The issuer transmits commands in issuer scripts
contained in the authorization response message
 The terminal passes these commands to the card
where they are executed if security requirements
are satisfied
 Commands are supported for:
 Updating card parameters
 Blocking or unblocking the application
 Blocking the card
 Resetting the PIN Try Counter
 Changing the offline PIN
Issuer Scripting – Cont.
 Issuer Scripts are encrypted using separate keys
than the ones used for Online Authorization requests
and responses. There are 2 key sets used here, one
for MACing the ISSUER SCRIPT commands (Integrity)
and the other to encipher/encrypt any confidential
data (Confidentiality) within the script such as a PIN
change
 Issuer scripts are received by the ICC within the
Authorization Response Data as shown:
 Issuer Script Template – Template 2 in tag 72 is for Payment
system use. Template 1 in tag 71 is for Issuer Specific scripting
which is out of scope of EMV.
 Issuer Script Identifier – number used by issuer to uniquely
identify the script being sent to the card.
 Issuer Script Commands – BER-TLV encoded format
with tag 86
EMV Expert – More Info
 This course was aimed at demystifying EMV –
explaining the components of an EMV transaction
 More detailed information can be found by referring
the the EMV Specifications books 1 –4 EMV 2000 ver
4.1
 Aspects of Card Personalization, Issuer and Acquirer
Certification have not been included in this course
 Terminal Manufacturer and Payment Applications
Level1 and 2 certification process is also not covered
Wrap up and Q&A
 EMV is here to stay – ICC cards (especially
Hybrid) are gradually replacing Magnetic
Stripe everywhere
 Payment systems are mandating by region,
all Issuers and Acquirers to comply with EMV
specifications for transaction processing
 VSDC and M/Chip implementations are
getting closer to true interoperability by
adhering to CCD or Common Core Definitions
laid down by EMV
 Any Questions….?