3.4 Interoperable payment application

The design principles explained in the previous section are not suitable for interoperability. The following business case for an interoperable payment application is now analyzed .

The proprietary card application described in Section 3.3 is referred to as C1 . The card hosting C1 is issued by the issuer I1 and is accepted at a terminal managed by the acquirer A1 , running the terminal application T1 . The whole payment scheme is managed by the payment system operator denoted O1 .

Assume that a cardholder has an ICC storing a card application C2 , providing the same functionality as C1 . However, the issuer I2 that manages the ICC containing C2 is not a subscriber of the payment system operator O1 . The issuer I2 is a subscriber of the payment system operator O2 , which did not establish any business agreement with O1 . The payment system operator O2 made its own design for the card application C2 and for the terminal application T2 . This basically means that:

The rules of encoding the data elements into data objects adopted in C2 could be different than the rules adopted in C1 .
It could be that the rules of encoding data elements into data objects adopted by both C1 and C2 are the same ”for example, according to ISO/IEC 7816-6 [7]. There is a high probability, however, that the mapping of data objects in elementary files is different from one card application to the other, since there is no standard that regulates this matter. Then the implicit identification of data objects in the two card applications is different.
The file organization in C2 is different than the file organization in C1 , since the file tree structure and the file identifiers adopted by the file organization in C2 are probably different than in the file organization adopted by C1 .
Both payment applications use interindustry commands as defined in ISO/IEC 7816-4 [5]. Because of the differences, however, in mapping data objects in files and in the file organization, the set of data objects to be transmitted with each command and the set of data objects expected to be received with each response are different from one card application to another. This determines two different transaction profiles for the two payment applications, which finally means two distinct terminal applications T1 and T2 .
It is also possible that the formulas for computing the dynamic authenticator differ from one card application to another, while the cryptographic keys involved in this computation are certainly proprietary to each payment system operator.

In case the acquirer A1 would like to broaden its financial services to cardholders of the issuer I2 , then A1 should establish a separate business relationship with the payment system operator O2 . Following this agreement, the acquirer A1 loads in its terminals another distinct terminal application T2 , which is proprietary to O2 . Moreover, considering that symmetric cryptographic technology is used, the terminal should be able to accommodate in addition to the security application module SAM1 used by T1 , a supplementary security application module SAM2 , which is exclusively used by T2 . Another possibility would be to cumulate the security functions and the corresponding cryptographic parameters of both SAM1 and SAM2 into one single SAM, with the condition that the payment system operators O1 and O2 have established a business relationship in this sense. In practice, this alternative is almost ruled out both by concurrency reasons between operators and for reasons determined by logistic problems related to key management and personalization of the SAM. As more and more system operators propose proprietary payment applications to acquirers , the management of the terminal applications and SAM(s) would become very difficult and the terminal more and more expensive.

A possible solution for interoperability would be that payment system operators create a consortium that specifies coproprietary card and terminal applications, with closed design solutions. As a result, everyone interested in being interoperable with this closed system would adhere to a memorandum of understanding proposed by the initial consortium. This policy, however, is not appropriate for the world of banking and financial services. Payment system operators, issuers , and acquirers would like to independently decide how the payment application would best match their interests.

A consortium comprised of Europay, MasterCard, and Visa (which is referred to as the EMV ¢ consortium) proposed an interoperable and open solution. In the framework of their solution each payment system operator, issuer, and acquirer can still customize a card/terminal application to its own business needs, providing they respect the basic negotiation mechanisms proposed by the EMV ¢ specifications. The rest of this section explains the principles of how this can be achieved.

3.4.1 Self-determined encoding of data elements

Instead of adopting a predefined fixed format for encoding data elements into data objects and an implicit identification of these data objects, the solution adopted by the EMV ¢ is to explicitly identify each data object. This is achieved with a tag, which can be regarded as a unique identification label. The data object has also attached the information about the length of the data element it encodes, such that there is no need of specifying beforehand a fixed length for each data element supported by an application. Thus, a data element is encoded following the tag-length-value (TLV) convention, described in the Basic Encoding Rules (BER) contained in the ISO/IEC 8825 standard [12]. Only the value field of the EMV ¢ data object actually conveys the useful information, while the tag and length fields convey the identification information. The BER-TLV encoding of the data elements in the card application C1 is listed in Table 3.3.

Table 3.3: BER-TLV Encoding of Data Elements
Name	Format	Tag	Length
Application Preferred Name	an 1-16	9F12	1 “16
Application Version Number	b	9F08	2
Application Expiration Date	n6 (YYMMDD)	5F24	3
Application PAN	cn 19 var. up to 19	5A	Var. up to 10
Cardholder Name	ans 2-26	5F20	2 “26
Issuer's operator, phone number	n16	To be defined	8
MAC-based dynamic authenticator (called Application Cryptogram in EMV ¢ )	b	9F26	8
Signed Static Application Data	b	93	The length of the RSA modulus of the issuer (for further details on RSA, see Appendix F)
Signed Dynamic Application Data	b	9F4B	The length of the RSA modulus of the card

The BER-TLV representation is suitable from the point of view of interoperability. Since every EMV ¢ data element is completely characterized by the tag and the length fields, the EMV ¢ terminal application can identify each data element and retrieve the conveyed information in the value field, indifferent of their "position" in the card (which EF and on which position). Therefore, the EMV ¢ terminal application has no need to know in advance the structure of the EMV ¢ files in the ICC to retrieve financial data needed for the completion of a payment transaction. As it will become evident in the next paragraph, it is sufficient that the terminal application knows the references of all the publicly available elementary files of the card application and the indexes of all the retrievable records from these files. The terminal application, however, has no need of previous information about how data is organized in these records. This allows complete freedom for the issuer of the EMV ¢ cards about the modality of mapping data objects into elementary files. No business relationship has to be established in advance between the issuer of the ICC and the acquirer responsible for the terminal, except that they are members of the same payment system operator/card association. The mapping of data objects in application elementary files (AEF) is illustrated in Figure 3.10.

Figure 3.10: EMV ¢ mapping of data objects in elementary files.

An elementary file can be regarded as a sack where the data objects can be located in any position. Once the elementary file is read in the terminal, the sack is emptied. The terminal recognizes data objects in the heap according to their tags and not according to their relative position in the elementary file from which they were downloaded.

The price paid for interoperability is a lower efficiency of the BER-TLV encoding. Every data element needs more bytes for its representation because of the addition of the tag and length fields besides the actual information conveyed in the value field of the data object.

3.4.2 Customized file system organization

The file system of an EMV ¢ card is also compatible with ISO/IEC 7816-4 [5]. A possible EMV ¢ file system is presented in Figure 3.11. The file system is divided into application definition files (ADF) and directory definition files (DDF), allowing several card applications to be simultaneously accommodated in the card. A separate ADF corresponds to each card application present in the card. An ADF is referenced with an AID (see Section 3.2.2.1). Each ADF encompasses one or more AEF(s). An AEF is a linear variable file containing the public information of the card application available to the counterpart terminal application. From this perspective an ADF can be regarded as an application data container. Inside the ADF each AEF is referenced with a SFI, which is a number in the range 1 to 30 (see Section 3.2.2.2). The SFI can be used as the handler of the AEF, once the ADF container is selected and known to the terminal. This handler can be directly used by the card commands performing file operations.

Figure 3.11: File system in an EMV ¢ card.

A DDF encompasses a group of related ADF(s). Each DDF in the card's file system is also referenced with an AID.

The nature of the applications can be the criteria for grouping the ADF(s) in a DDF. For example, all the payment card applications in an EMV ¢ card could be gathered in the same DDF. The DDF that groups them is called the payment system environment (PSE) and has a special AID represented by the string 1PAY.SYS.DDF01, which is a reserved AID.
The ADF(s) can be also grouped according to the payment system operator that proposed them. In the example of Figure 3.11, DDF2 gathers all the payment card applications of a national payment system operator.

A DDF can also include other hierarchical inferior DDF(s). For example, the PSE can further contain a DDF dedicated to loyalty card applications, denoted DDF1 in Figure 3.11. The DDF can be seen as a container of card applications.

The organization of files in an EMV ¢ card is more flexible, such that the EMV ¢ terminal is not compelled to know this organization in advance in order to perform a transaction profile. The terminal has to be aware only about the AID of the DDF applications containers in the card and of the ADF data containers that are not included under a DDF. Thus, the acquirer has to set up in the terminal a list of all the acceptable applications (ADFs) or of all the acceptable groups of applications (DDFs).

Once the selection of a DDF applications container is performed, the terminal can find the table of contents of the DDF. This table of contents is organized in a directory file, containing as entry points the AID of all ADF data containers and the AID of all the other hierarchical inferior DDF applications containers. For example, the directory file at the level of the PSE contains the AID of ADF2 and DDF1, and the directory file at the level of DDF1 contains the AID of ADF3. By reading a directory file, the terminal is able to learn the file organization in that DDF.
Whenever the terminal has selected an ADF container, it is further able to read another table of contents, which this time lists the AEF(s) that are publicly readable from a card application. This table of contents is referred to as an Application File Locator (AFL).

3.4.3 Variable formats for commands and responses

In an EMV ¢ setup the card application and the terminal application can be designed by different roles, within the limits established by the EMV ¢ specifications. The roles do not have to agree in advance on the list of meaningful data objects to be transmitted from the terminal application to the card application within a command. These data objects are needed by the card to perform its processing. This means that the set of data objects to be transmitted within a command can be different from one card application to another.

Therefore, the card must instruct the terminal about the data objects acceptable to be transmitted in a command. To this end the card application sends to the terminal application a data object list (DOL). This contains the list of all the tag-length identifiers of the data objects to be included by the terminal application in a command body.

For each command accepting a variable data input, the EMV ¢ specifications have defined a separate type of DOL, which is transmitted to the terminal application before the invocation of the command. The list of items (TL)1, (TL)2, (TL)3, included in each DOL type contains compulsory data objects specified by the EMV ¢ specifications and also chosen data objects of each issuer. The DOL(s) are personalized in the card application by the issuer before the card is operated during the utilization life stage.

The terminal uses the tag-length identifiers (TL) of the data objects in the DOL to retrieve the corresponding objects from its application heap. The data objects in the heap correspond to the current business environment: amount, TerminalID, Time/Date , and so on. The terminal retains the field value of the data objects identified in the DOL and concatenates them in a byte string, which is given as a data input to the corresponding command. The mechanism is depicted in Figure 3.12.

Figure 3.12: Variable command data input with DOL mechanism.

Moreover, the transaction profile is also variable, since the sequence of commands depends on the capabilities of the card concerning the implementation of some basic security mechanisms. Included among these mechanisms are the card authentication method (CAM), the cardholder verification method (CVM), and the decision as to whether the terminal performs risk analysis or if everything must be judged on-line by the issuer.

The Application Interchange Profile (AIP) is the data element stored in the card since the personalization, which instructs the terminal concerning the acceptable sequence of commands from the card's viewpoint.

3.4.4 Asymmetric cryptographic support

In the beginning of Section 3.4 we saw that implementing the off-line card authentication service using symmetric cryptographic techniques requires each payment system operator to provide the acquirer with a dedicated SAM. This impacts negatively on the complexity of the terminal and of the key management process.

Openness of design and interoperability imply the use of asymmetric cryptographic techniques for implementing the off-line card authentication service. Thus, in order to prove the authenticity of the financial data personalized in the card, as well as the fact that the card is genuine , instead of using the MAC-based DDA mechanism, one has to use the digital signature “based DDA mechanism, as presented in Appendix D, Section D.7.2. In this case there is no need for the distribution of sensitive secret cryptographic parameters by the payment system operator, which is a considerable advantage. Correspondingly, the hardware structure of the terminal is simplified, as is the key management overhead. The chip card, however, must be able to produce a digital signature, which requires an RSA operation in the case of EMV ¢ chips. Therefore, the hardware structure of the chip includes a cryptographic coprocessor for speeding up the computations performed by the card (see Appendix D, Section D.1.2). Moreover, there is need for more EEPROM space in the chip card to keep the private key used for signature generation as well as of the corresponding public key with the accompanying issuer certificate to be forwarded to the terminal for signature verification. These extra facilities are expensive both in terms of computation power and permanent storage space. They significantly increase the cost of the chip card supporting asymmetric cryptography when compared to the chip card supporting only symmetric cryptography. When considering also that the latter card is several times more expensive than the magnetic stripe card, we can see that the former card is around 10 times more expensive than a magnetic stripe card. One can also understand a card manager's reluctance in asking the issuer's administration board for a dollar amount with an added zero at the end (read $1,000,000 instead of $100,000) for paying for the chip migration. As one can see, in relative terms the effort of the issuer increases spectacularly.

The normal reaction of the issuer's administration board would be to cut it in half. In the given circumstances, the card manager remembers past experiences with magnetic stripe cards. In that case the card authentication service was implemented with a MAC-based static data authentication (SDA) mechanism (see Section 2.5.3 and Appendix D, Section D.6.1). The issuer computes the static authenticator and writes it on the magnetic track during the personalization stage. Since the static authenticator in this case is computed with symmetric cryptographic techniques, the same limitations on openness and interoperability would be encountered as explained in the beginning of Section 3.4. Consequently, the EMV ¢ proposes the cheap solution that mirrors somehow the security protection with static authenticator but in an interoperable way. The issuer can compute this time a static authenticator using the signature-based SDA mechanism (see Appendix D, Section D.6.2). In this case the chip card would compute nothing (no need for a coprocessor) but only store some more bytes corresponding to the signature-based static authenticator. However, the security is also drastically reduced if the EMV ¢ transaction is concluded off-line and no on-line support is demanded from the issuer. The static authenticator would prove the authenticity of the financial data personalized in the card but would provide no protection against counterfeit. There is the impression that cloning the public information of the chip is more difficult than cloning the magnetic stripe. Cloning this public information, however, is still feasible for a hacker appropriately equipped (more details on this attack in Section 7.7.4).

Thus, while spending $400,000 for chip cards supporting symmetric cryptography on top of the costs of magnetic stripe implementation, the issuer loses the benefit of high security against counterfeit in small value transactions concluded off-line. Moreover, the issuer will not be able to implement the asymmetric enciphered PIN cardholder verification method (see Appendix D, Section D.5.5). This method would improve the security of the cardholder's PIN at the point of service, which is a very sensitive asset. Finally, the issuer is not able to implement on a multiapplication chip card other "heavy" cryptography card applications, like the interoperable electronic purse CEPS, electronic brokerage, and electronic administration applications for tax paying. Thus, it appears more and more that it is better for chip migration to be done with support of asymmetric cryptographic techniques.

It is also important to note that the payment system operator escaped from the burden of organizing symmetric key generation and distribution processes, but it must operate a public key infrastructure instead. This is an equally difficult task, if not even more difficult. The operator, however, is motivated by the same hope of being able to diversify its services towards its subscribers.