How chip cards work

Long time back I wrote about magnetic stripe based cards and their working. Magnetic stripe cards are now on decline as many of standard bodies are pushing for chip based card and has been made mandatory in some of the regions (e.g Europe, USA etc).

Main reason to migrate to chip based cards is that they are more secure than magnetic stripe cards.Magnetic stripe store all customer information on card stripe. No protection is provide to this information and it is easy to read this information and create copy of card. Chip based cards provide better protection and can't be cloned easily.

A chip card is sometimes is also known as ICC (Integrated chip card) or EMV card or smart cards. I will use these terms interchangeably in this blog. ICC has a small inbuilt processor that can be used for mathematical calculation and processing. All ICC cards also have some type of OS installed on them (e.g. SECCOS).

Smart cards are tamper resistant and tamper responsive devices. Any attempt to forcefully extract data from smart card will erase all data from the card. This provides assurance that stored data indeed protected from outside attacks.


At the time of card issuance a.k.a. card personalization (i.e. issuance of card to customer),  customer data is stored on ICC card. Along with this data some cryptographic keys and certificates are also stored on card at the time of personalization. These  keys are required at the time of transaction.Smart card has capability to authenticate a valid user using a PIN. This PIN must be presented to card before any other transaction on card can be performed. To defeat brute force attacks on PIN, smart card are configured to lock itself if wrong PIN is presented certain number of times consecutively. Those who are interested to know more about smart cards can follow below link.

http://en.wikipedia.org/wiki/Smart_card


At the time of personalization process some customer data is written on smart card. Typically this data contains:
1. Primary account number
2. Expiry date
3. Issuer Parameter
4. etc.

Apart from customer data, keys are also written on smart card. These keys include symmetric and asymmetric keys. These keys are used to authenticate card by terminal, to authenticate card by issuer for data integrity and confidential. We will discuss each type of key and its purpose in detail. Authentication of card and user are performed at various level. 

1. Authentication of user by card

Before any transaction user enters PIN on terminal, terminal passes this PIN to card for authentication. Card declines transaction and access to any data when wrong PIN is entered.

2. Authentication of card by terminal

Terminal can also authenticate card before it proceeds with transaction. There are two methods to authenticate smart card by terminal

1. Static data authentication (SDA)
2. Dynamic data authentication (DDA)

Both static data authentication and dynamic data authentication use asymmetric key cryptography and certificates. There is a root CA called Payment System Certification Authority which is signs all other trusted certificate. Root CA has its RSA  public and private keys generated beforehand. We will call them PKca and SKca respectively. Each issuer generates its own public/private RSA key pair. Let's call them PKiss and SKiss. CA signs public key of issuer to make it trusted. PKca is loaded inside each acquirer terminal.

Static data authentication (SDA)

• Card Issuance

 At the time of card issuance, customer data is signed using issuer's private key (SKiss). Customer data and signature is stored on smart card along with PKiss signed using SKca.

• Card authentication at terminal

1. Card sends PKiss signed under SKca.
2. Terminal verifies PKiss using PKca already stored on terminal.
3. Cards sends customer data and signature to terminal. Terminal validates signature using PKiss.

At this point terminal knows that card data is authentic.
Since fixed data (static data) is already returned from card, replay attacks are possible when SDA is used.

Dynamic data authentication

In case of DDA each card also has its own public/private RSA key pair.

• Card Issuance

Each smart card is initialized with its own RSA key pair (PKic and SKic respectively). PKic is signed using SKiss and signature is stored on card. Following data is stored on card when DDA is used:

1. ICC private key pair
2. Signature on PKicc generated using SKiss.
3. PKiss and signature generated using SKca.

• Card authentication at terminal

1. Terminal sends an unpredictable number (UN) to card.
2. Cards return PKiss certified by CA, PKic certified by issuer and digital signature on UN and ICC dynamic data generated using SKic.
3. Terminal will validate PKic using PKiss certificate.
4. Terminal validated signature on UN and ICC dynamic data using PKic.

DDA can detect alteration of ICC data after the card has been personalized. This prevents replay attacks and ICC counterfeiting.

Once card has been validated by terminal, next step is verification of card by issuer bank.

3. Authentication of card by issuer

Once card has been authenticated by terminal and vice-versa. Next step is authentication and authorization of transaction by issuer. Card also authenticates issuer data in order to ensure that authorization is actually done by authentic issuer.

For this purpose multiple symmetric keys are store on smart card. As per EMV specification 4.2 these keys are double DES keys. Similarly keys are stored on issuer host system (inside HSM) to authorize transaction.

Lets first see which type of data can travel from card to issuer or from issuer to card.

Card to issuer :  Data that is sent from card to issuer is
1. Transaction details : date-time, amount, type of transaction etc.
2.  PIN : if issuer also wants to verify PIN at its end.
3   Card holder information : PAN, expiry data etc.

Issuer to card:
Issuer can also data to card to update some card parameters. These card parameters can be:
1. New PIN, incase issuer wants to change PIN on card
2. Unblock exiting PIN: when customer has forgotten exiting PIN and card gotlocked.  
Above data is just some example and issuer can send any data to card which card is able to understand.

When issuer updates card information, data sent to card is sometimes called scripts( or Issuer scripts). Issuer can generate these scripts and send to cards.  This is also called secure messaging in EMV terms.


Typically following TDES keys are stored on issuer host system. They are called Issuer Master Keys . These keys are used to further derive other keys.

1. Issuer MKac : IMK for Application Cryptogram (AC) generation. This key is used to provide assurance of integrity of transaction data. In a layman's term keys derived from this key is used to verify or generate MAC on transaction data. We will see what is AC in a short while.
2. Issuer  MKsmc : IMK for secure messaging confidentiality. Any data send during secure messaging is encrypted by keys derived from IMKsmc.
3. Issuer MKsmi :IMK for secure messaging integrity. To provide assurance of integrity of data sent using secure messaging.
4. Issuer MKidn : This IMK is used to derive ICC dynamic number for use in DDA.

From each issuer master key ICC master keys (IMK) are derived which are unique for each card. These keys are stored on the card during card issuance. These keys are derived from Issuer master keys and card PAN and PAN sequence number.

Issuer MKac ---------derives--------> IMKac
Issuer MKsmc ---------derives------> IMKsmc
Issuer MKsmi ---------derives-------> IMKsmi
Issuer MKidn ---------derives-------> IMKidn

Each issuer can use different methods for IMK derivation or using standard method specified in EMV book. Since each card has unique PAN, IMK is also unique for each card.

It should also be noted that issuer can also choose other keys on smart card apart from above.

Next keys in this hierarchy are session keys which are unique for each transaction. Session keys are are derived using ATC(Application transaction counter) and unpredictable number. Session keys are derived from IMKac, IMKsmc and IMKidn. Session key for IDN is not generated. IDN is generated by performing straight encryption AC and UN under IMKidn.

Summary of keys
On issuer (inside HSM) following keys exist
1.Issuer MKac
2.Issuer MKsmc
3.Issuer MKsmi
4.Issuer MKidn
 

On each card following keys are stored
1. IMKac
2. IMKsmc
3. IMKsmi
4  IMKidn

Transaction processing

EMV supports two types of transactions 

1. Offline transaction : This transaction is performed when terminal is not connected to issuer (or is offline). Card can directly authorize this type of transaction.  This type of transaction might or might not be supported by card depending on card configuration and county specific rules and regulations. Transaction involving small transactions are generally supported in offline mode.
2. Online transaction : These transaction must be authorized by issuer.

We have already seen how terminal authenticates card.  Next is how transaction proceeds after that. Before that we will discuss what are different type of application cryptograms (AC) are generated by card and issuer system. All application cryptograms are generated using IMKac.

Following types of cryptograms can be generated by card:

1. Transaction Certificate (TC) : This application cryptogram is generated by card when a offline transaction is performed. Card generates TC which terminal can send to issuer whenever it comes online.

2. Application authentication cryptogram (AAC) : This cryptogram is generated when transaction is rejected by card.
3. authorization request cryptogram (ARQC) : Generated by card for online transaction. Used by issuer to ensure card is authentic.

Issuer can generate :
ARC : ARPC response code. This is generated by host after verifying ARQC.
Authorization Response Cryptogram (ARPC) : Generated by issuer in response to ARQC. ARPC is used by card to determine it is talking to issuer. ARPC is generated using ARQC and ARC.

Transaction flow

1. Terminal  creates data on which AC is to be generated. Sends data with unpredictable number (UN) to card.

2.  ICC calculates AC on terminal data (including UN) and ICC Data using SKac. SKac is derived using ATC which is maintained internally in the card. AC can be TC, AAC or ARQC. TC in case terminal has requested offline transaction. AAC if transaction is declined or ARQC which can be sent to issuer.

3. If TC is received, terminal authorizes transaction, in case of AAC transaction is declined. In  case of ARQC terminal proceeds to send data to issuer.

4. Issues received terminal generated data, ICC card data and AC. Terminal has Issuer Master Key stored on HSM. Terminal generates IMKac using ICC data (PAN) and then generates SKac using ATC and IMKac and verifies ARQC received from card. If ARQC is verified, it means terminal is taking to valid card. Additionally issuer can verify IDN at this step.

5. Terminal checks if transaction can be approved. Generates ARC and calculates ARPC  using SKac and ARC.

6. Terminal receives ARPC and ARC. Sends this data to ICC. ICC validates ARPC. This gives assurance that card it taking to authentic issuer. After verification ICC can decide to reject transaction (depending on ARC and other parameters). TC is returned for successful transaction. AAC for rejected transaction.

At step 4 issuer can also send issuer scripts to change or unblock PIN. Scripts are encrypted using SKsmc and signed using SKsmi. ICC will decrypt script data and take appropriate action.

It should be noted that each issuer can use different methods for key derivation, AC generation or verification.

This concludes my blog on how chip card technology works. Feel free to comment on this blog so that I can improve any shortcoming.