How to Help Banks Move to Smart Cards | Electronic Commerce (Charles River Media Networking/Security)

In order to migrate to smart-card-based payment systems, banks will have to make a number of changes to their existing systems. Among these are:

Enhancements to the card issuing process
Enhancements to the card personalization process
Enhancements to the systems that handle card transactions^[1]

Enhancements to the Card Issuing Process

Existing systems were developed, often many years ago, to handle the types of data needed for magnetic stripe cards. Smart cards require considerably more data to be generated, including cryptographic keys for the cards themselves. In most instances, changing existing systems represents a major investment of resources.

Enhancements to the Card Personalization Process

Banks generally personalize their cards in one of two ways: either using an in-house facility or using an external personalization bureau. The choice is usually based on the size of the cardholder base, because setting up an in-house facility is an expensive exercise.

Enhancements to the Systems that Handle Card Transactions

Systems are in place today for handling a number of magnetic-stripe-based transactions, such as ATM cash dispensing, online card and PIN verification, and offline bulk transaction processing. By using smart cards, there is a need to extend these systems to handle the transaction verification mechanism used in smart debit and credit cards, or in the case of electronic purse schemes, like Visa Cash, to handle the secure loading of e-cash onto the card.

The Personalization Preparation Process (P3)

Today’s magnetic stripe cards are generally produced as depicted in Figure 21.1^[1]. The issuer host system embodies the database of all cardholder details and provides facilities to generate data to produce a new card.

click to expand
Figure 21.1: Magnetic stripe cards process.

The Existing Magnetic Stripe Process

Often, cards are produced in batches and it is the responsibility of the host system to assemble all data for a given batch of cards. A batch might be generated as a result of the normal replacement cycle (two or three years) or possibly to replace those cards that have been reported lost or stolen during the day. The host system produces the data in a series of records, one record per cardholder. The data is known as a Personalization Data File.

Each record of the Personalization Data File comprises a number of modules. These normally include:

Data to be embossed onto the card.
Data to be encoded onto the magnetic stripe of the card.
Data to be printed on a “paper carrier.” This carrier is used to hold the card, while in its delivery envelope, and is printed, for example, with the cardholder’s name and address.
Data for an ID photograph^[1].

Most of the information for these modules is held in the cardholder database. Some items in the magnetic stripe module need to be generated using a security module. These include a PIN Verification Value (PVV), or equivalent, and a Card Verification Value (CVV). Both these items are derived using a cryptographic process that involves the use of secret keys.

It is worth noting that although the data in the Personalization Data File is normally handled carefully, there is nothing inherently secret about it and, for that reason, it is not normally encrypted. It only becomes a useful commodity when it is combined with a real plastic card, which happens in the personalization bureau. Such facilities are highly secure establishments with tight access control procedures and many internal mechanisms to guard against finished cards being lost or stolen. Normally, cards in their paper carriers are inserted directly into envelopes and passed straight to the postal system. The PIN mailer for a card is normally produced in a separate establishment from the cards themselves, often as a separate output from the issuer host system. This separation of PIN mailer and finished card is normally an essential part of the card issuance process. Often, PIN mailers are not posted until the cardholder acknowledges receipt of the card.

With the arrival of the smart card, the issuer needs to produce an extra “module” of data, which is intended to be programmed into the chip itself. Of course, there will be many items of information in this chip data, which are common to the magnetic stripe and the embossing data. Examples of this are a Primary Account Number (PAN) and the cardholder name. However, there are some new items that are specific to smart cards. Some examples of these are:

Upper consecutive offline limit: This is a value held by the card that determines its spending limit. After this limit has been exceeded, the card forces the transaction to be completed online. This is part of the inherent risk management features of a chip card.

Signature of static card data: This is a value calculated using a public key cryptographic algorithm at the time the card data is generated. It can be validated by each terminal accepting the card and is used to give some confidence that the card is genuine.

Issuer certificate: This data is set up by the issuer in conjunction with the card association to which the issuer belongs (Visa or MasterCard). It is placed onto every card issued and contains the public key of the issuer. It is used by the terminal as part of the process to validate the signature in the second item in this list.

Unique Derived Keys (UDKs): These are DES keys, unique to each card, which are placed on the chip and used as part of the transaction validation process. Basically, the transaction details are passed to the card, which uses the UDK to generate a cryptogram (similar to a MAC) that is passed back to the issuer for validation. Using this technique, the issuer can be sure that the transaction was handled by a valid card^[1].

The various credit and debit specifications define in excess of 40 such data items, which need to be generated and placed on smart cards. It is the issuer’s responsibility to generate these items, something that existing card systems were never designed to handle.

Note

The advent of chip cards has meant that for the first time, some of the data passing from issuer to personalizer is now secret and must only be sent in encrypted form. The UDKs previously described are an example of such secret data.

The Personalization Preparation Process (P3) System

There is a need for a product that is able to generate the new data required by the various smart card schemes. This means that a card issuer can migrate to smart cards without having to make changes to an existing cardholder database host system. As noted before, this can be a costly and time-consuming exercise and often proves to be a major barrier for a bank in moving to smart cards.

P3 is a compact name for personalization preparation process, which goes some way to describing what the system achieves. Its main objectives are:

To take an existing Personalization Data File in an industry-accepted format and add to it the extra data required for the smart card scheme concerned. Currently, P3 supports the Visa Cash scheme (Public Key or DES-based variants), the Visa “Easy Entry” scheme, the Visa Smart Debit/Credit scheme, and the UKIS scheme. P3 will be enhanced to support other schemes in the future.
To achieve this, it securely stores all the cryptographic keys and certificates required by the preceding schemes.
To generate issuer public and private key sets (RSA public key algorithm), and to get the public key into a form in which it can be sent to the scheme’s CA so that it can produce the issuer certificate. The certificate so produced can be imported back into the P3 system and stored for use in the personalization preparation process.
To produce the output data in a format that can be used by most card personalization bureaus around the world. Sensitive card data, such as keys, is encrypted in the output stream.
To store details about regularly performed jobs, so that record processing can be performed with the minimum of user intervention.
To provide a security environment with controlled access that aligns with the operating procedures found in many personalization bureaus. Using the security features of Windows NT, a P3 user can set up system managers, administrators, and operators to perform the required tasks for normal operation^[1].

The P3 system fits into an existing card issuing process, as shown in Figure 21.2^[1]. There are two possible configurations of P3. It could belong to and be co-sited with the issuer host system. Alternatively, P3 could be operated by a Personalization Bureau who may act on behalf of several issuers.

click to expand
Figure 21.2: Card issuing process.

In order to perform its job, P3 needs to be able to interface with a number of external parties. These interfaces are shown in Figure 21.3^[1].

click to expand
Figure 21.3: P3 interface.

The parties that P3 shares information with are:

Scheme Certification Authorities (CA): Part of the security of the various smart card schemes includes the need for an issuer to generate an RSA public/private key pair. The private key is retained securely in a Host Security Module and used to “sign” card data to produce a signature that is placed on the card. The public key is transmitted to the scheme provider (Visa, Europay, or MasterCard), where it is certified using the “scheme private key” to produce the issuer certificate. This is transmitted back to the issuer, where it is stored so that it can be placed on every card. The certification process is slightly different for each of the scheme providers, but the principle is the same.

Issuer host system: P3 receives personalization data from the existing issuer host system, as described in other parts of this document.

Personalization system: P3 adds the appropriate smart card data to the cardholder record before passing the combined data to the personalization system^[1].

After cards have been issued, they may be used to obtain goods or services. If the card is a credit or debit card, it is generally used at a point of sale or at an ATM. As part of the transaction, the card generates an Authorization Request Cryptogram (ARQC) using unique keys held on the card. This is passed back as part of the transaction message to be validated by the bank’s host validation system. The host system is able to validate the ARQC and produce an Authorization Response Cryptogram (ARPC), which is sent back to the card. The card can validate this ARPC. This mutual authentication process gives a very high assurance that the card is genuine, and that the bank with which it is in communication is the one that originally issued the card.

If the card is an electronic purse card, normal purchases are carried out as offline transactions. However, there is a need to go online when the card is to be reloaded with funds. In the case of Visa Cash, a card generates a Load Request, which involves a cryptographic signature known as S1. This is validated by the host system, which then generates the Load Authorization signature (S2). The card validates this and finally produces a Load Completion Signature (S3), which is sent back to the host system to confirm that funds have been loaded.

Both of the preceding online transaction processes involve cryptographic keys. These keys have to be shared between the online host system and P3. Facilities are provided in P3 to allow this.

At the time of writing, the P3 system is able to support the following applications. Work is in progress on other applications, which will be announced in the 5th edition of this book.

Visa Cash (DES-based)
Visa Cash (Public Key)
Visa Easy Entry
Visa Smart Credit Debit
APACS UKIS application^[1]

Smart Card Credit, Debit, Visa Cash Load, and Unload Processing HSM Functions

Finally, as outlined previously, an online host system handling credit and debit transactions from smart cards needs to be able to process the ARQC/ARPC values. To be able to handle the Visa Cash Load (and Unload) functions, the online host system must be able to handle the S1, S2, and S3 signatures as previously described.