EMV updates version 4.3

This blog is all about changes introduced in EMV version 4.3.

Anyone having little knowledge of cryptography now knows that days of TDES are limited and industry is moving towards AES. Though this movement is slow because cost of replacing old hardware is too high. The same has happened with EMV as well. The major change in EMV v 4.3 is introduction of AES algorithm. All Issuer Master keys IMKs can now be AES keys which also means Master keys and session keys can now be AES keys. I believe this is not going to impact smart cards since they already support AES algorithm for quite some time. There are some changes in session key derivation data used to derive session master keys and session.

In my opinion, EMV should have increased the length of RSA keys to match the cryptographic strength of AES 128 bit keys but it is missing. Probably they are planning to move to ECC soon.

For details refer to EMV 4.3 books which are freely available for download.

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.

derive unique key per transaction

Hello everyone....
It has been a long time since I have written anything on my blog. I always wanted to write some useful information on my blogs that I learn hard way...but got carried away by other tasks

In his blog I will talk about how unique key per transaction works in ATM transaction environment.

What is derive unique key per transaction  (DUKPT)?

1. This method ensures that in each ATM transaction a unique key (theoretically) is used to encrypt your PIN or data when you do any transaction on ATM/POS device.
2. The unique key used in a transaction must not disclose any information about a previous key or future key used in the previous or future transactions. (It should be infeasible to get any other key out of it)


 Entities involved:
1. Acquirer : This is the acquirer of the ATM typically a bank which has control over the ATM and can initialize the ATM.
2.  ATM device/PIN pad on ATM : This is the device that encrypt the PIN/data.

both the above devices must have a TRSM (Tamper resistant security module) to store any keys.

In the core of DUKPT lies the BDK (Base derivation key) that is used to derive any key used in DUKPT scheme. BDK is only stored in a HSM (Hardware security module) / TRSM or out of HSM encrypted using a key stored on HSM (KM/LMK) at acquirer end. It is never stored on ATM devices.

If BDK is stored in acquirer end, a unique Initial key (IPEK) is stored on each ATM which is derived from a particular BDK. Each ATM device (I will use ATM, PIN entry device oe POS device interchangeably ) will have a initial serial number fixed for the lifetime of that device. This ISN has information about the BDK used to derive IPEK for that ATM.

IPEK derivation

Initial key (aka IPEK) is derived using a 10 byte field called KSN (Key serial number). This field contains information about the BDK, ATM id (unique for each ATM of a particular acquirer) and transaction counter (set to all zeros for IPEK derivation). Using these fields IPEK is derived that is used to initialize that HSM. Since each ATM has a unique ATM id this IPEK is also unique for each ATM.Different methods can be employed to initialize an ATM. e.g. Manual loading of key, key loading using a key loading device, using symmetric key techniques, using asymmetric key techniques etc). IPEK generation is always done using an HSM at acquirer side.

Unique key per transaction: 

Once ATM is initialized with IPEK, this IPEK is used to derive a unique key for each transaction. Unique key is derived for each transaction using IPEK, KSN (consisting BDK, ATM id, counter value). Each time a  new transaction is initiated counter value at the  ATM is increased (changed). Since BDK id and ATM id always remain same for a ATM, this transaction counter changes for each transaction and new transaction key is generated for each transaction at ATM. This unique key can be used to encrypt PIN, any other data (PAN etc) or calculate MAC. Of course a different variant is used for each purpose. Those who know about the key variants is fine. those who doesn't know a key variant is used to functionally separate key used for different purposes.

The KSN mentioned above is not a secret data and passed by ATM device to the acquired along with encrypted data.

At the acquirer end HSM is used to first generates IPEK(using KSN but taking counter as 0) and then generated transaction key using IPEK and KSN using the same algorithm that were used at ATM. I have mentioned in the previous post that PIN never resides in clear form outside an HSM therefore HSMs must provide a functionality to verify PIN encrypted under DUKPT transaction key. HSM generally take encrypted PIN (or data), KSN and BDK id as input. They then generate transaction key then decrypt PIN or data (after applying appropriate variant) and verify (PIN) or decrypt (data) it.

In the next blog I will describe how chip cards work... They are the future anyways.. I also wanted to talk about HSMs and there working but it might have to wait..

Feel free to write to me for any queries..

How ATM work

Prologue

I still remember the old days when one must go to its bank to take out money from ones account and stand in a long queue before one can do that. Sometimes it used to be very frustrating if money is needed urgently.

Then came the plastic cards, ATM, Point of sale (POS) terminal that gave consumer relief from going to the bank and liberty to use their money anytime/anywhere. But as the saying goes "There are no free lunches", plastic money also got its own problems. e.g. online fraud, loss of card etc.

Anyways in this blog post I am only going to describe the banking infrastructure that enables user to purchase things or withdraw money on the fly. Probably we can leave the fraud stuff for the later. The real motivation to write a blog on this came from the fact that every one in now a days using cards but not aware of the internals. Even if someone tries to search (as I tried) , There is not much information available on internet. So I decided to write this in my blog.

What is PIN?

Every card has an associated number that is called PIN (Personal Identification Number). This number can be 4-12 digit long (depending on the banks, most of the time it is 4 digit). This number must not be shared with anybody.

Why PIN?

Propose of providing a PIN is two fold:

1. This is used to authenticate the cardholder as it is supposed to be known to him only.
2. One can argue why a separate PIN is needed when cardholder can be authenticated using the card. The rationale behind this is called two way authentications. Any authentication can be based on following parameters

What you have

What you know and

What you are.

If only card is used for authentication then authentication is only based on what you have. The drawback of this approach is anybody that holds the card can use it. To avoid this extra factor (what you know) is added to the security. Now anybody that has the card must also know the associated PIN in order to use it, only having card or knowing PIN is not adequate.

Banking Infrastructure

Before we go into details of banking infrastructure we must know what are the different entities involved. For a functional point of view banking infrastructure comprises of following three entities:

1. Acquirer: Acquirer is the organization that installs ATM. This can be a bank (ICICI, HSBC etc) who installs ATMs or some other institutions (VISA etc).
2. Issuer: Issuer is the institution that issue ATM cards to its customers.
3. Switch: Switch is an institution that facilitates communication between acquirer and issuer when both are different. When both acquirer and issuer are same (when a card issued by a bank ‘B” is used in B’s ATM) there might not be a need for switch. Examples of switch are MarsterCard, Visa etc.

Apart from above mentioned entities sometimes manufacturer of ATMs is also mentioned in some banking standard ( but its role is limited till the initialization of ATM).

Sequence involved in transactions

ATM transaction starts the moment customer inserts his card in ATM. Complete steps are listed below in chronological sequence:

1. Customer inserts his card.

2. Customer is asked to insert PIN on a PINPAD.

3. Customer is asked to enter the service he wants to avail and other information related to service chosen (like amount in case of withdrawal).

4. PIN along with other customer data written on magnetic stripe on card is sent to ATM acquirer (How data is stored is out of scope for now. I might add it later).

5. ATM acquirer determines from the data if it needs to be forwarded to a switch (If card belongs to different banks) or can be processed by acquirer. This can be determined by the information written on magnetic stripe.

6. Customer entered PIN is verified by the bank. If verification is successful, bank checks if customer has enough balance in his account to withdraw and sends response back to ATM using the same route from where the request has come.

7. Customer can take the money.

Where PIN appears in clear

Primary concern of a customer is secrecy of the PIN because if an attacker gets hold of the PIN along with the card then he can use utilize it to withdraw money or for Point of Sale(POS) transactions. The reason why I didn’t say that card must be secured because it is an physical entity that anybody can duplicate or steal but PIN is supposed to be memorized (at least theoretically).

To the relief of customer, PIN never appears in clear in the entire transmission in host computer. It can be seen in clear only inside a hardware security module (during translation and PIN verification). Amazingly, Even the card issuer bank doesn’t store customer PIN in their database. You might be wondering, if a bank doesn’t know user PIN how it can be verified. The verification is done using PIN verification algorithms (Visa PVV or IBM 3624 ) and reference to these algorithms can be found in the reference section.

To be Cont..

Next:

Online shopping (how??)