Migrating from Magnetic Stripes to EMV Smart Cards: Key Considerations

Migrating from magnetic stripes to EMV based smart cards is a challenging endeavour for banks and their IT teams. Even for small banks, necessary card data preparation rapidly overshoots the level of millions of data entries. In the frame of the migration process, banks need new systems and new processes, interweaving additional external entities.There can be high levels of risk in the migration, including the risk of handling multiple independent service or solution providers without any overall ownership or responsibilities.

This article discusses the migration process of banks that shift from credit cards based on magnetic stripes to EMV based smart cards. It sheds light on the technology, the reasons for it, the involved players and what to plan for.

Urgency of adding more security measures to payment cards

When magnetic stripe cards were first introduced decades ago, they were considered a relatively safe and convenient way of handling transactions. But as time passed, more and more techniques were developed and used to commit various types fraudulent activity on the cards. Magnetic stripe cards are very limited in terms of the security measures that can be implemented to protect them from such activity. The attacks have now become so prevalent in recent years (especially in the U.S.), that it was imperative that a new type of payment card system be developed and implemented as soon as possible.

New technologies made available for adding security measures

As a potential replacement for magnetic stripe cards, advanced integrated circuit (IC) technologies were developed that would allow IC chips to operate at extremely low power levels, while providing much more processing capabilities in a smaller space. In addition, the costs of manufacturing these specialized integrated circuit chips on a mass production scale have dramatically decreased in recent years. Unlike the static unchanging cardholder and application data found on a magnetic stripe, the IC chip processors in EMV cards can generate its own “Dynamic” data that changes for each individual transaction using cryptographic techniques. Since the card data would be unique for each transaction, a thief wouldn't be able to do anything with it if this data was somehow stolen or intercepted during a transaction. This makes it virtually impossible to create a counterfeit form of the card. 

Processor on a chip card allows for many additional security measures

By generating “Dynamic data”, an EMV chip card can be verified as authentic (e.g. not a counterfeit) every time it is used for a transaction. In addition, the integrity of the cardholder and sensitive application data on a card can be checked to verify that it is original and hasn't been modified since it was issued.

By using the chip's processing capability, certain “terminal risk management” parameters (such as spending limit) can also be checked whenever the card is used to determine whether the transaction should be disallowed or should go online for further analysis. This can prevent a lost or stolen card from being used in certain instances.

Although such attacks can easily be prevented by using a cardholder verification method (CVM), such as online or offline PIN codes that chip cards sometimes require to verify identity. However, many cards still use the signature CVM, and possibly no CVM at all (for card not present (CNP) transactions). So a thief would still be able to use a lost or stolen card in such cases.

However, there is another method in development which would almost guarantee the identity of the cardholder, either online or offline. An alpha-numeric display and keypad would be embedded in the plastic card, so customers would type their PIN into the card whenever they make a POS or CNP (online) transaction. Cryptographic techniques are then used to create a single-use code that is sent to the website or terminal. This would prevent a thief from intercepting the PIN and card data for malicious use.

The use of multiple applications on one card as a driving factor

The other major driving factor to motivate the process to shift over to EMV chip card technology, is each card would have multiple application functioning capability. Unlike magnetic stripe cards, the processor on a chip card would allow several different types of applications to be stored and processed on one card. An example would be having a debit application for use at ATMs and a credit application for use at a POS terminal on the same card. In this way, a consumer wouldn't have to carry several cards, one for each application.

Other benefits in using an embedded chip processor on a card

Many other benefits become apparent as chip cards are used instead of traditional magnetic stripe cards, such as the ability to update the cards with new information as necessary, longer life span (the magnetic stripe tends to wear out), and the ability to perform contactless transactions, which are becoming popular with the latest smart-phones.

The challenging migration process

Why has the migration to EMV chip cards been so slow?

Even with all of these drivers and benefits, the migration from magnetic stripe cards to EMV chip cards has been progressing at a much slower rate than intended. This is mainly because of the many complexities involved in the process, such as cryptographic algorithms, key types, key management techniques, etc. There are also numerous entities that need to interact with one another in the process, including the issuer (bank), the Payment System CA (Certificate Authority), the data preparation system (Cryptomathic CardInk is an example), personalization system, card suppliers, application providers, and the authorization system. Each entity performs a specific function with the ultimate goal of having a new chip card in a consumers hand and ready to use.

How can the preparation process for EMV chip cards be summarized?

The main function of the various tasks and procedures related to issuing EMV chip cards is to retrieve customer information from a bank’s database, and then feed this data into the bank’s chosen data preparation system (either in-house or out-sourced), along with the appropriate cryptographic keys and digital certificates (which are obtained from the Certificate Authority). The data preparation system then creates and exchanges a few additional 3-DES keys for encrypting transaction data, and finally, all this data will be transferred onto the chip itself through the personalization system.

Involved Entities

The functions of the individual entities and how they interact with on another are explained in the following paragraphs:

Issuer

The issuer is the organization that actually issues the cards, which is normally a bank or a related financial institution. The main function of the issuer is to supply card holder data from its card management or host system to a data preparation system. The cardholder data includes the account number, brand of card, and other card parameters, such as spending limits. “Profile” information is also sent, which includes the type of cryptographic keys are to be used, settings for PINs, and other card specific settings, such as “risk parameters”. The issuer oversees the entire process as it exchanges this information with the data preparation system and other entities.

Certification Authority

One of the first steps in preparing EMV cards is exchanging the appropriate cryptographic keys and digital certificates between the data preparation system and a Payment System CA (Certificate Authority). Examples of Certificate Authorities are the MasterCard CA, the VISA CA, the American Express CA, etc. The Payment System CA is the institution that creates digital certificates and authenticates the issuer’s public RSA keys in the payment infrastructure. Each terminal in this infrastructure contains CA signed public keys corresponding to the payment card and its application.

The exchange method may vary for each system, but the basic steps in the process for each case are similar: The issuer starts by sending a “certificate-request” to the data preparation system, and from there it will generate an RSA key pair, of which the public key is added to a self-signed certificate, and sent to the CA as a certificate request. If this passes the CA's evaluation, an “issuer certificate” is sent back to the data preparation system that is signed by a private key corresponding with a CA RSA key pair. This contains the public key and other data originally sent from the issuer.

Another certificate is also sent that is self-signed with the associated CA public key. This is sent so the issuer can validate the source of the signature and the issuer certificate itself.

Data Preparation System

As soon as business is taken care of with the CA, and the issuer's RSA key pair is certified, the data preparation procedures can begin. The process starts by assembling all application data, keys, certificates, etc. from the CA and issuer, and to generate other cryptographic keys as necessary, while deriving new ones. Additional 3-DES keys are created, which are used to encrypt the actual transaction data.

All of this information and data is prepared and formatted in a way that matches the specifications of the personalization equipment and the card itself. These tasks are exactly what a system like Cryptomathic Cardink will perform.

By exchanging this data with the personalization system, the card manufacturing process is then completed as the personalization system generates and loads the chip with and magnetic stripe with the appropriate data.

Here the bank has a choice. Data preparation or rather bulk data migration and completion can be either: 

• outsourced or
• managed in-house.

Given that the EMV card comprises 50 additional data elements this process represents a substantial workload. For instance, if a bank has 100.000 customer, this means 5.000.000 data entries.

Card Supplier

The card supplier is the entity that supplies the empty smart card to the personalization system, and initializes it with a cryptographic key. The system can then replace this key with an issuer-specific key if it chooses, or it can continue using the card master key to encrypt data sent to the card during personalization. The card will then decrypt that data with the same key to secure the process.

Personalization Systen

The personalization system is the focal point of the card assembly process and it receives cardholder data from the issuer, transport keys and personalization data from the data preparation system, and the initialized smart cards and master key from the supplier.

All this information is used as inputs for the various machines and modules used to produce the final version of the chip card. The machines are controlled by a software program that can vary substantially between different card vendors, payment schemes, and applications.

The output of the data preparation system has certain restrictions in that certain key types must be used to encrypt the cardholder data, keys, and PINs. As the machines receive this encrypted data at run-time, it is decrypted using the same keys. Then the data is re-encrypted using a unique card storing key. This re-encrypted data is finally loaded onto the chip, which decrypts the data using the same card storing key.

Personalization can either be done in-house or in a personalisation bureau.

Authorization System

The authorization system is the entity that interacts with the smart card terminals and any equipment that can read chip card data. Each ATM/POS in the infrastructure has a copy of the CA RSA public key available, which is used to verify that the issuer’s CA certificate was properly signed, and the signature is correct. It compares the signed data with the actual data stored on the card to see that it is identical.

During the issuing preparation process, various 3DES type cryptographic keys are exchanged between the bank, the data preparation system, and the authorization system. The data preparation system uses an AC (Application Cryptogram) master key to create a unique 3DES key for each card. An AC card key is generated using the card's account number, and sent to individual cards. During a transaction, the card will use the AC card key to encrypt data, and sends it to the authorization system, which will use the AC master key to decrypt the data. The same method is used to send data back to the card. Only one transaction key is required for basic transactions. Advanced models require two or more keys for encrypting and MAC’ing online updates to the card.

How does this process vary for different payment card systems?

By making use of recent developments in technology, the complex process of producing chip cards can be organized into a well-defined set of standards and procedures involving the various entities described above. However, there may be slight variations in the standard sequence of tasks, depending on the card company, the application, and other factors. The larger banking systems mostly follow the standardized procedures, but for smaller systems, a slightly different type of production processing model is used, such as in cases where a card is personalized or updated in the field on a mobile system. Online tools are available for configuring the personalization and/or updates in the field, in those instances where an organization isn't equipped to handle the processing itself.

There are also cases where “Instant Issuance” is needed, where a branch office of a bank can issue a card immediately upon request. This method is mainly used for banks wishing to offer a more personal service in the local community and for regions where distributing cards via postal service is not recommended.

Planning of the bulk migration process

The transfer process from a magnetic stripe system to a chip card system requires careful and meticulous planning because of its complexity. But also to be able to accomplish it in a stream-lined and highly automated and effective process.

Strategic and operational decision making

• Will the existing data structure be simply expanded or will it be remodelled in order to cater for additional security and the new production topology?
• Evaluation of cost, internal or external skills.
• Internal or external key management.
• Definition of card portfolio. Diversifications include debit/credit, platinum/gold/business, domestic/international, contact/contactless/mobile.

Agreements

• Agreements with payment brands for issuing the cards. Subject of discussion are getting the actual permission and ensuring conformity with payment brand regulations (such as cryptographic key sizes, usage of pins and setting card risk management parameters).
• Agreements with payment processors for acquiring (i.e. picking up the transaction and processing it).

Interfacing and data exchange

• Interfacing with the certificate authority. Each payment scheme provides a proprietary communication protocol for exchanging RSA keys and digital certificates between the bank’s EMV data preparation system and the payment scheme’s certificate authority.
• Interfacing with the host system. Data needs to be supplied from the host system to the EMV data preparation system. The data supply may be either direct or via intermediate data processing systems e.g. a card management system.
• Interfacing with the payment processor. Transactions originating from the chip card need to be processed. Interfaces needs to be built to connect to those systems such as payment processors who pick up and route the transaction.

Card portfolio

• Defining profiles based on existing customer segmentation. This step will allow to auto-fill the additional data elements based on the card profiles. Comparing the number of data elements on an EMV card versus a magnetic stripe card, there are many more possible variations for card behaviour and hence card products. Each card product is represented by a profile detailing spending limits, verification methods, risk parameters, security level and although some issuers begin with continuing the existing card products but in a chip version diversity soon appears. EMV introduces new cryptographic keys and different keys are used for different BIN ranges. Contact cards use different data values than contactless cards and others for mobile.
• Implementing the batch programs for autofill. With new card products and keys, the systems requesting EMV data preparation need more complexity and granularity in selecting profiles and providing input data. Considerations on key and card expiration dates apply, BIN range profile selection, the additional EMV data elements and the recipient personlisation systems, each of which requires different transport encryption keys, all necessitates changes to the card management system.

CONCLUDING THE BULK MIGRATION PROCESS

The migration process is completed with three final steps:

• Test bed implementation
• Sample data submission and approval
• Live production

Test bed implementation of each card type

• Verify data preparation and personalisation by personalising cards and running them through dedicated test software.

Sample data submission and approval

• Submitting samples of each card type to the payment schemes‘ test laboratories for approval.
• Some payment schemes provide standard profiles in correspondence with which banks can construct their card portfolio.
• When submitting a sample card for approval the process is quick. Cards based on non-standard profiles take longer time to approve.

Live production

Finally, the live production can begin. Recurring processes will benefit from

• implemented processes in alignment with the corporate strategy as well as the security and key management policy
• established interfaces and data exchange structures with the certificate authorities and payment processors
• existing (batch) data preparation programs for new customers or cards with predefined fields

In-house data preparation and (potentially) card production is now an error-proof standardized and effective process optimized on

• process security and compliance to the bank's security policies as well as corporate goals
• control, data visibility and analytics as well as data accessibility to the bank's decision makers at any time
• ownership over the complete process by the bank
• minimization of human resources required

CONCLUSION

This article described the new valuable features of EMV-based cards, the entities and systems required, the planning and the implementation process. Given the many steps required and entities involved, one major risk is that migration might not run smoothly, and if something goes wrong, nobody is willing to take ownership and responsibility for damage and recovery. For the bank, the process is even riskier as it is not regularly operating such migration processes.

Cryptomathic always advocates turn-key migration by experienced partners, where the banks benefit from existing implementation experience across the whole process, including strategic planning, system and network implementation, data-preparation and bulk migration.

Contact us to discuss your migration process, to estimate effort, time and cost and to suggest one of our experienced turn-key implementation partners, operating the complete migration with and for you, with defined costs and process during, process ownership and responsibility, and an optimized outcome for your and your end-customers.

References

• EMV Key Management – Explained (2015) by Cryptomathic
• Cryptomathic CardInk Product Sheet (2015) by Cryptomathic
• Cryptomathic EMV CA 2.1 System Architecture (2015) by Cryptomathic
• CardInk Case Study – S2M (2015) by Cryptomathic
• EMV Payment Security – A Brief Overview (2014) by Dan Boneh, Stanford University
• Visa tests cards with built in PIN machine (2008) by Nicole Kobie

Image: "Group of happy business people clapping their hands" courtesy of tec-estromberg, Flickr (CC BY 2.0)