7.4 Multiapplication ICC

A cardholder requires the issuer to have full availability of his or her money anytime and anywhere , through a range of appropriate payment instruments, as far as there is enough money in the account and the credit history records no abuses .

To answer this requirement optimally, the issuer should provide a range of card applications that answer various payment behaviors, (e.g., credit, debit, and stored value), both within the boundaries of a country (domestic environment) and internationally. The payment service delivered by each card application can be implemented by another payment system.

The issuer could issue a separate ICC to the cardholder for each card application it offers. This approach has the advantage of simplicity of the application management in the card and of the personalization process, but it involves separate costs for the issuance of each card.

Alternatively, the issuer may chose to implement multiple applications on the same ICC. This would reduce the cost ratio ICC/card application, but would increase the application management and personalization costs. With the advance of the Java cards, however, these costs tend to decrease, making accessible the "one chip multiple applications" approach [14].

In this section we analyze some aspects of issuing multiapplication cards. First, we discuss design principles regarding the choice of a set of card applications that can be simultaneously accommodated in the same ICC. Then, we address design principles for the definition of a card layout, considering both the file structure and the functionality of a multiapplication card.

7.4.1 Choice of a set of card applications

If the issuer chooses the multiapplication approach, a set of card applications that can be accommodated by the ICC must be defined. Several elements are simultaneously considered when defining this set:

The types of retail financial services to be provided to a cardholder (e.g., ATM cash withdrawal, manual cash disbursement in a branch office of a bank, POS payments for goods and/or services with or without cashback possibility). Other services can be provided ”for example, a loyalty scheme, in case the issuer has established a suitable agreement with a chain of merchants .
The type of environment, domestic or international, where each service is available to the cardholder.
The payment behavior with which the service is associated (i.e., debit, credit, stored value).

The issuer maps card applications to triples (service, payment behavior, environment), such that there are no card applications offering the same type of service, for the same type of payment behavior, in the same environment. This design restriction guarantees the minimal cost of the overall ICC implementation. To this end the issuer can build allocation tables of the kind shown in Figure 7.2.

Figure 7.2: Allocation tables for card applications.

In the example described in Figure 7.2, the issuer provides the cardholder with an ICC containing a set of five applications allocated as follows :

Card application CA1 is a debit product available only in the domestic environment, providing ATM and POS payment services. CA1 implements the EMV ¢ debit/credit functionality as defined in Book 3ofthe EMV 2000 specifications.
Card application CA2 is a credit product available both in the domestic and international environments. At home the cardholder can use it only for payments at a POS, while abroad it can be used for ATM cash advance and POS payments. CA2 implements the EMV ¢ debit/credit functionality.
Card application CA3 is a domestic electronic purse. CA3 implements a different functionality than EMV ¢ debit/credit, but it is EMV ¢ compliant in the sense that the organization of the data objects of the card application and its visibility to the EMV ¢ application selection mechanism complies with Book 1 of the EMV 2000 specifications (see also Chapter 4).
Card application CA4 is a domestic loyalty scheme for a chain of merchants having adequate agreements with the issuer. CA4 implements non-EMV ¢ functionality and it is not EMV ¢ compliant in the sense that the terminal must apply a proprietary selection mechanism to execute this card application.
Card application CA5 is an international debit product for ATM cash withdrawal. CA5 implements the EMV ¢ debit/credit functionality.

For the same example, the ownership of the brands behind each card application is as follows:

CA1 and CA3 are brands belonging to the national payment system operator of the country where the issuer is located.
CA2 and CA5 are brands belonging to an international card association.
Both the issuer and the chain of merchants own CA4, from which the cardholder accumulates points from payment transactions effected with any of the card applications from CA1 to CA3.

The issuer has to fulfill the following business conditions in order to be able to accommodate in his ICC the card applications mentioned above:

The issuer is a subscriber to the services offered by the national payment system operator.
The issuer is a member of the international card association.
The issuer and the chain of merchants have established a bilateral business agreement concerning their participation in the loyalty program.

Not only must the issuer fulfill these business conditions but he must also observe the explicit rules of each payment system concerning the issuing of ICC cards including their brands. Therefore, the issuer has to take some restrictions into account:

An ICC should not accommodate card applications coming from two different electronic payment system operators or card associations, which do not mutually support their brands. The coexistence of brands on the same card has to make the object of bilateral agreements. As an example, if either the card association or the national payment system operator states that their brands cannot coexist with another operator's brands on the same card, then the issuer is compelled to store (CA1, CA3) on a different card than (CA2, CA5).
If explicitly stated by any of the payment systems, an ICC should not carry both debit and credit applications. For example, if the card association explicitly states this restriction, then CA2 cannot be included in the same set of card applications with any other debit card application, regardless of whether it is branded by the card association itself or any another payment system operator.
An ICC should not carry applications of the same payment system for which the coexistence of brands is not explicitly allowed. Let us assume that there is another international debit card application provided by the same card association, referred to as CA5', offering both the ATM and the POS service. Then, the card association could explicitly rule out the coexistence of both CA5 and CA5' in the same ICC, since CA5' covers the functionality of CA5.
In an open and interoperable environment, a registered AID, according to ISO 7816-5 [15], uniquely identifies a card application brand. If the issuer agrees to include in the ICC a card application belonging to a domestic electronic payment system that does not register its AID according to ISO 7816-5, then the issuer has to fulfill a supplementary condition. The issuer should take all the provisions of loading this card application with an AID different from any other AID coming from international payment system operators or card associations, without conflicting with these cross-border applications.

7.4.2 Card layout definition

In the definition of the card layout, the issuer has to define requirements both on the card's functionality and on the transaction files and data.

The issuer has to decide whether the ICC will accommodate only card applications implementing the EMV ¢ debit/credit functionality or card applications implementing other functionality than EMV ¢ . Considering the example discussed in Section 7.4.1, in the former case the ICC can only include the card applications CA1, CA2, and CA5, while in the latter case all five applications can be hosted in the ICC. In Figure 7.3, we present the card's layout in the latter case.

Figure 7.3: Card layout with EMV ¢ debit/credit and other functionality.

Considering the fact that the EMV ¢ functionality is used by several applications, the issuer may define a sharable applet, whose set of method signatures represents the API accessible to CA1, CA2, and CA5. The methods of the sharable applet implement the generation of the application cryptogram, the DDA, the enciphered PIN verified off-line by the ICC, the card risk management, and so on. This choice avoids repeating code for implementing EMV ¢ functionality in each separate applet CA1, CA2, and CA5, which can lead to saving EEPROM space.

Since only the application CA3 uses the functionality needed for processing stored value transactions, which is different than the EMV ¢ debit/credit functionality, then the issuer may require that all this functionality is implemented directly at the level of the applet CA3. The same observation applies to CA4.

In the remainder of the section we concentrate only on the management of files and data for the EMV ¢ debit/credit applications CA1, CA2, and CA5.

The issuer can define data objects that can be used in common by several EMV ¢ applications. These objects are referred to as card data objects. The objects that are accessible only to one application are referred to as application data objects. In Figure 7.3, application data 1 groups all the application data objects accessible to CA1, application data 2 groups all the application data objects accessible to CA2, and so on, while common data groups all the card data objects.

Among the card data objects and application data objects, one can distinguish between EMV ¢ defined objects and proprietary-defined objects.

EMV ¢ Defined Data Objects

Possible examples of EMV ¢ defined card data objects are the cardholder's name , track 2 equivalent data, and track 3 equivalent data. If DDA and/or enciphered PIN verified off-line by the ICC are implemented (for economy reasons of the EEPROM space), the issuer may decide ”if the regulatory framework of each payment system represented in the card does not rule out this possibility ”to keep the following cryptographic parameters as card data objects:

The ICC private key used for computing the card's signature in the DDA: This is a card secret data object accessible only to the processing performed by the applets.
The corresponding ICC Public Key Certificate, signed by the issuer, together with the other RSA public parameters ”namely, the ICC Public Key Exponent, and eventually the ICC Public Key Remainder. This is a card public data object that is accessible to the terminal application.
The ICC PIN encipherment private key, used for decrypting the RSA envelope containing the off-line enciphered PIN, could also be a card secret data object. This object is accessible only to the processing performed by the applets.
The corresponding ICC PIN Encipherment Public Key Certificate, signed by the issuer, together with the other RSA public parameters ”namely, the ICC PIN Encipherment Public Key Exponent, and eventually the ICC PIN Encipherment Public Key Remainder. This is a card public data object that is accessible to the terminal application.

Even though it is a good security practice to keep different cryptographic parameters for different security services, the issuer can decide for the reason of EEPROM economy that the same set of parameters can be commonly used by the DDA and the enciphered PIN verified off-line by the ICC.

Some examples of EMV ¢ defined application data objects are those related to the financial data, like the Application PAN, Application PAN Sequence Number, Application Expiration/Effective Date, Application Currency Code, Application Usage Control, and Application Version Number. Some security- related data objects like the Issuer Action Code “Denial/ On-line/Default, Card Risk Management Data Object Lists (CDOL1 and CDOL2), CVM List(s), and the Signed Static Application Data are also EMV ¢ -defined application data objects.

Proprietary-Defined Data Objects

The proprietary-defined card data objects are those objects defined by the issuer in connection with his specifically defined processing ”for example, the card risk management (see Section 7.10.3):

Card period (specify: day/month) accumulator , which represents the total amount spent by the cardholder with any of the applications hosted in the card, during a certain period;
Card last transaction day and the card last transaction month , which represent the date when the last transaction with any of the applications hosted in the card was effected.

Proprietary-defined application data objects can include specific data objects needed by the card risk management in relation to each application, like the application period (specify: day/month) accumulator, application last transaction day and the application last transaction month. The following proprietary-defined application cryptographic data objects can be included here as well: the cryptogram version number, key index, MAC keys and encryption keys for secure messaging in connection with issuer script processing, and the application PIN. Note that all the keys and PIN data objects are secret objects accessible only to the appropriate processing performed by the applet.

In addition to card and application data objects, the issuer might define sharable data objects, which are objects accessible only to a well-defined subset of applications. Included in this category are cryptographic parameters in relation to the SDA mechanism. To explain this we again use the multiapplication example presented in Section 7.4.1. The issuer must obtain two Issuer Public Key Certificates relative to the same pair issuer private key/issuer public key ( modulus and public key exponent):

The national payment system operator signs one Issuer Public Key Certificate for the use of the application CA1 and for the use of any other EMV ¢ application of this operator that may eventually be loaded in the future in the ICC. In the set of sharable objects for CA1, the issuer includes, besides this certificate, the Certification Authority Public Key Index corresponding to the national payment system operator, the issuer public key exponent, and eventually the issuer public key remainder. The presence of the last object is dependent on the byte length of the modulus used by the payment system operator.
The card association will sign another certificate for the use of the applications CA2 and CA5, and for any other EMV ¢ application of the card association that may eventually be loaded in the future in the ICC. In the set of sharable data objects for CA2 and CA5, the issuer includes, besides this certificate, the Certification Authority Public Key Index corresponding to the card association, the issuer public key exponent, and eventually the issuer public key remainder. This object may have a different value than that corresponding to the national payment system operator, in case the two organizations use RSA modulus of different length for signing certificates. The presence of this object is dependent on the byte length of the modulus used by the card association.

The issuer also has to decide whether the EMV ¢ applications in the card, namely CA1, CA2, and CA5, are visible from a payment system environment or this structure is not implemented. If the PSE is implemented, the issuer should appropriately define the AEF that keeps the PSE directory, the FCI of the PSE, and the FCI of each card application, observing the restrictions discussed in Section 4.3.1 and Section 4.3.4.

Considering the card layout presented above, a possible mapping of the card/application/sharable data objects into the card's file structure, which is publicly accessible to EMV ¢ terminals, is presented in Figure 7.4.

Figure 7.4: Card file structure corresponding to the proposed layout.

The directory file of the PSE is organized in the AEF01. The SFI of this file is indicated in the FCI of the PSE. The application elementary files AEF02 and AEF03 store the card data objects. These two files must be visible to all the card applications in the PSE. Each application in the PSE has its own application data objects mapped as follows:

The application data objects of CA1 are mapped to the application elementary files AEF11 and AEF12. The visibility of these files is limited only to CA1.
The application data objects of CA2 are mapped to the application elementary files AEF21 and AEF22. The visibility of these files is limited only to CA2.
The application data objects of CA5 are mapped to the application elementary files AEF51 and AEF52. The visibility of these files is limited only to CA5.

Concerning the sharable data objects among applications, these are mapped as follows:

The sharable data objects of the applications managed by the national payment system operator (e.g., CA1 and any other application of this operator that can be loaded in the future) are grouped in the application elementary file denoted AEFsh1(CA1). The visibility of this file is limited to CA1.
The sharable data objects of the applications managed by the card association (e.g., CA2, CA5, and any other application of the card association that can be loaded in the future) are grouped in the application elementary files denoted AEFsh1(CA2, CA5) and AEFsh2(CA2, CA5). The visibility of these files is limited to CA2 and CA5.

The issuer reflects the visibility of these application elementary files in the AFL associated with each application, as follows:

The AFL of the CA1 includes AEF02, AEF03, AEF11, AEF12, and AEFsh1(CA1).
The AFL of the CA2 includes AEF02, AEF03, AEF21, AEF22, AEFsh1 (CA2,CA5), and AEFsh2(CA2,CA5).
The AFL of the CA5 includes AEF02, AEF03, AEF51, AEF52, AEFsh1 (CA2,CA5), and AEFsh2(CA2,CA5).

If the card layout is set up in this way, the READ RECORD command must be implemented following some supplementary requirements. Thus, whenever the SFI of an AEF is not in the realm of the currently selected ADF, the card must check whether there is an AEF with this SFI one level above in the card file structure. If this AEF is not found there, the card must check whether the current ADF has sharable files associated with it. In the affirmative case, the SFI of the AEF is searched among the sharable files associated to the current ADF.