THE EMV APPLICATION
Specifications and standards for using smart cards in a wide variety of application areas have been available for many years. However, there has traditionally been a strong concentration on telecommunications applications (telephone cards and GSM cards). This situation has changed markedly since the mid-1990s. The European electronic purse standard (EN 1546) is a good example of this trend, but the most important specification in the field of payment systems is the EMV specification. This specification, which is named after its three initiators (Europay, MasterCard and Visa), contains detailed descriptions of all aspects of credit cards containing microcontroller chips. A corresponding specification for matching terminals is also now available. In the autumn of 1993, the three internationally active credit card companies Europay, MasterCard and Visa started work on a specification titled ‘IC Card Specifications for Payment Systems’. Version 1 was published relatively soon afterwards, in October 1994. In mid-1995, a revised specification (Version 2) was completed. The final version of this specification, called ‘EMV ’96’, was released at the end of June 1996. It is backward compatible with Version 2. After ambiguities had been cleared up and small errors corrected, a completely revised and compatible version of theEMVspecification (Version 3) was published in the summer of 1998. At the end of 2002, the version number was increased to 4 with a few modifications. This is the presently valid version, and its official name is ‘EMV 2000’. It is also available via the Internet [EMV], and it can be recommended without reservation to interested parties as a worthwhile subject of study. Several factors motivated these credit card issuers to prepare a specification for credit cards with chips within such a short time. First, existing credit cards with magnetic stripes can be very easily forged. Nowadays, the only real obstacle is the hologram, which is still moderately secure against forgery. All other card features can be copied relatively easily. The second important factor is the value-added services that a microcontroller card can offer. Electronic purses, bonus points and telephone functions are only some of the possibilities.

The specification for credit cards with chips is divided into four parts, which are called ‘books’. Book 1, Application-independent ICC to terminal interface requirements, draws heavily on the ISO/IEC 7816-1/2/3 family of standards. It describes the electromechanical characteristics, logical interface and data transmission protocols, which are the application-independent parameters. According to this part of the specification, the smart card has an ID-1 format with ISO contact locations. It must have a supply voltage of 5 V ± 0.5 V, a maximum current consumption of 50 mA and a clock rate of 1–5 MHz, among other things. The contact force must not exceed 0.6 N per contact. Data transmission at the physical level is essentially identical to ISO/IEC 7816-3. This applies to the time interval for individual bits, the ATR and the two transmission protocols19 (T = 0 and T = 1). The specification of the APDU is identical to that in the ISO/IEC 7816-4 standard. The second part of the specification (Book 2, Security and key management) defines the security mechanisms and key management. Book 3, Application specification, contains the data elements, commands and processes needed for debit and credit transactions in accordance with the EMV specification. Book 4, Cardholder, attendant, and acquirer interface requirements, contains many general specifications for EMV-compliant payment systems that are related to users and merchants. Since typical credit cards are mass-produced articles, their manufacturing costs must naturally not be too high. As these costs predominantly depend on the embedded microcontroller, the credit card application was designed from the start to use a minimum amount of memory. A conventional EMV application without supplementary functions thus fits into a processor with 6 kB of ROM, 1 kB of EEPROM and 128 bytes of RAM. Even in the smart card area, these values represent the lower end of the range of available chips, but they do make for an inexpensive product. To a certain extent, the EMV specifications are basic documents that specify the minimum requirements for the various card issuers. The current version leaves a number of issues open. For example, risk management of the terminal and the smart card during transactions is not yet precisely specified. Consequently, the EMV application is only described here in outline, since many details must be specified by the card issuer.

Files and data elements
The specification for credit cards with chips only states that a tree structure must be used for the files.22 The actual application is located in its own DF, which is selected using an application identifier (AID) and which contains all of the data elements for the credit card application. These data elements are stored in EFs with standard file structures in accordance with ISO/IEC 7816-4. EFs can normally be selected implicitly using short FIDs. The main difference with respect to similar specifications is that no particular EFs or FIDs are specified. However, this is not necessary for the functions used for payments, since all of the necessary data can be processed using existing commands. There is only one file directly below the MF (EFDIR per ISO/IEC 7816-5), which contains all of the information related to the applications present in the card. All data elements in the terminal–card system are specified using unambiguous templates and tags. They can be addressed within the application using the specified commands, without any knowledge of their precise locations in the file tree or a particular file. This makes it possible to leave the definition of the file structure to the card issuer, since it does not affect the execution of the transactions.

Commands
Strictly speaking, only three commands are necessary for performing the actual payment functions. Additional commands are needed for personalization, management, special functions and value-added services, but they fall outside the scope of the EMV specification. According to the requirements of the EMV specification, the following commands must be available, with all return codes being similar to ISO/IEC 7816-4: 23
–APPLICATION BLOCK (specific to EMV)
–APPLICATION UNBLOCK (specific to EMV)
–CARD BLOCK (specific to EMV)
–EXTERNAL AUTHENTICATE (as a subset of ISO/IEC 7816-4)
–GENERATE APPLICATION CRYPTOGRAM (specific to EMV)
–GET CHALLENGE (ISO/IEC 7816-4)
–GET DATA (specific to EMV)
–GET PROCESSING OPTIONS (specific to EMV)
–PIN CHANGE/UNBLOCK (specific to EMV)
–READ RECORD (as a subset of ISO/IEC 7816-4)
–SELECT (as a subset of ISO/IEC 7816-4)
–VERIFY (as a subset of ISO/IEC 7816-4)

Cryptographic mechanisms
The cryptographic mechanisms used in an application are naturally highly dependent on the associated general requirements. This can be seen especially well in the EMV application. A basic initial premise for the system design was that terminals do not necessarily contain security modules, depending on the system operator. This makes it impossible to use symmetric cryptographic algorithms, since the keys cannot be kept secret. The reasons for not using security modules are that they significantly increase the cost of the terminal, and that an international system for managing keys in terminals, some of which operate offline, would be very complicated and expensive. In order to make smart card authentication by the terminal possible under these conditions, an asymmetric cryptographic algorithm must be used.EMVuses static unilateral authentication with card-specific keys.24 This does not allow the card to check the authenticity of the terminal, but this is not essential in the EMV application, since debiting is not performed in the card. The card only generates a transaction certificate for the terminal. This transaction certificate is not anonymous with respect to the cardholder, and it can be submitted to the relevant card issuer only by an authorized (known) merchant. This largely excludes most possible forms of fraud, since a valid transaction certificate can be ‘converted’ into money only by an authorized merchant known to the card issuer. In principle, any desired cryptographic algorithm can be used, since both the associated data elements and the algorithm itself are unambiguously identified by TLV-coded data structures. Version 2 of the EMV specification allows either the SHA-1 (as per FIPS 180-1) or the ANSI X9.30-2 hash function to be used.25 The cryptographic algorithm used is not DSS, as might be expected from the use of SHA-1, but instead the RSA algorithm26 (ANSI X9.31-1). The length of the key can vary, depending on the card issuer, and it is indicated by an appropriate code (signature tag). Small numbers, such as 3 or 216 + 1, are recommended for the public key in order to minimize computation time. If the smart card has established an online link to the background system, it is possible to protect the data transmission by secure messaging27 as specified in ISO/IEC 7816-4. A symmetrical cryptographic algorithm is used for this end-to-end communication, namely triple DES. In this case, it is possible to do so without compromising system security, since both the background system and the card can securely store the secret key.

System architecture and transaction processes
Traditionally, a highly centralized system architecture is used for payment systems in the credit card sector. There are usually several background systems, which are either individually or collectively responsible for a certain region (such as Germany). The computer centers for the background systems, which are equipped with high-performance computers, are interconnected by the independent network of the card issuer. This network supports data exchanges for clearing and increases operational reliability, since if one center fails, its activities can be taken over by other centers. Individual terminals are connected to the background system via the public telephone system and data networks, such as ISDN and X.25. An acquirer, who routes and bundles transaction data, may be located between the terminals and the background systems. However, this strongly depends on the particular card issuer and country. At the terminal level, there are two different options: data may be exchanged directly with the acquirer, or a concentrator belonging to a merchant or chain of shops may be used. Both of these options are possible, and both are used in practice. The process of making a payment with a ‘smart’ credit card is not much different from making a payment using a traditional credit card. The customer presents his or her card to the cashier, and it is inserted into a smart card terminal. If a terminal is not available, payments can be made in the conventional manner using the magnetic stripe or embossed characters, which are still present on the card. However, even if a terminal is present, it is still possible to verify the identity of the card user by means of a signature. In this case, the associated transaction receipt has a marker that indicates that the card user has been identified in this manner. The other option is for the card user to enter a four-digit PIN. This can be checked online by the background system or offline by the smart card. If a PIN is used for identification, the transaction certificate indicates which type of PIN check was performed. At the detail level, the individual functions and the process of a successful payment transaction using a smart card are naturally somewhat more complicated. An example is shown in Figure 12.19, which illustrates the fundamental mechanisms. Both the card and the terminal determine the exact course of the transaction based on various transaction data, such as the amount involved. For instance, if the amount to be paid exceeds a certain sum, the card requests online authorization of the payment by the background system. The terminal must then establish a link to the background system and have the payment approved. Only after the background system has approved the request does the card generate a valid transaction certificate, which the merchant can submit for clearing. The purpose of online authorization is to minimize the financial risk to the card issuer. Since a ‘smart’ credit card must regularly report to the background system in accordance with a number of conditions, the maximum loss in the event that a card is stolen or manipulated can be held within precisely calculable limits.

Future developments
In terms of its structure and contents, the EMV specification allows the card issuer considerable room for individual initiative, which makes further developments and individual versions possible. This flexibility will doubtless be utilized extensively by various firms. For instance, each of the three credit card issuers involved in drawing up the EMV specification has generated a specification for an electronic purse 28 that can also be included in the smart card as necessary. Particularly with vending machines or small purchases, a prepaid electronic purse definitely has advantages, since the fee that is otherwise charged for a credit card payment is not applicable. In the near future, the increasing commercial use of international networks, such as the Internet, will require secure means of payment that are internationally available and widely accepted. Credit cards with chips and a few value-added services would be eminently suitable for this, since they have already achieved international acceptance and widespread use, independent of any particular country or currency.Work is presently being carried out in this area. The difference between this and the payment process described above is not great, since the Internet or the like could take the place of the acquirer. In principle, all that is necessary is that the customer has access to a smart card terminal. The EMV specification has achieved the same significance in the financial transactions field as GSM 11.11 has for smart cards used in telecommunications applications. There are no modern smart card operating systems on the market that do not claim to be EMV-compatible. Due to the number of credit cards with chips that can be expected to be in circulation in the future, this specification represents the minimum standard for all future applications.