The joint specification of Europay, MasterCard and Visa for smart cards used for financial transactions, EMV,10 specifies two commands especially designed for financial transactions. In principle, these two extremely flexible commands could be used to implement an electronic purse in a smart card. However, their intended use lies more in the realm of credit and debit transactions, which is why their use for these two applications is described here. We devote a separate section to these commands because credit and debit cards incorporating chips are expected to be produced in very large numbers in the future. Their significance is thus correspondingly large. The two commands GET PROCESSING OPTIONS and GENERATE APPLICATION CRYPTOGRAM are based on TLV-coded data objects in the data section of the command and response. This creates a considerable variety of possible variations and options, which can be exploited by each application as necessary. The GET PROCESSING OPTIONS command is used to initiate a payment transaction. It transfers the processing options data object list (PDOL), which contains TLV-coded data for processing the rest of the payment transaction, from the terminal to the smart card. This data could be the transaction amount, for example. The card returns a BER-TLV coded data object containing the application interchange profile (AIP), which describes the functions supported by the smart card, and the application file locator (AFL), which specifies the location of the application data. The second command for the payment transaction process in a credit card with a chip is GENERATE APPLICATIONCRYPTOGRAM.The data in the commandAPDUand response APDU of this command are TLV-coded. It transfers all of the data necessary for a payment transaction to the card, together with the desired application cryptogram. The card then determines how the rest of the payment transaction should proceed, based on the received and stored data. As a result, it returns an application cryptogram to the terminal. In the simplest case, this may be the transaction cryptogram. This concludes the payment transaction process. The application cryptogram returned by the smart card may contain an authorization request instead of a transaction cryptogram. In the process of determining how the payment transaction should proceed, if the smart card concludes that online authorization is necessary, the application cryptogram that it returns to the terminal contains a request to the authorization center superior to the terminal. After the authorization center has processed this request, the corresponding information is sent to the smart card using a second GENERATE APPLICATION CRYPTOGRAM command. The card can then generate the transaction cryptogram for the payment and send it to the terminal.

There are a large number of commands that are tailored to specific applications. They are mainly used to minimize memory space or processing time. The majority of these commands
are so specific that they are not included in any standard, or they are defined in a standard for use in a particular application area. A list of all application-specific commands would exceed the scope of this chapter. As a representative example of such commands, we present the RUN GSM ALGORITHM command, which is the only application-specific command in the GSM 11.11 specification. It is used to simultaneously generate a dynamic, card-specific key and authenticate the card with respect to the GSM background system. This function is so specific to the GSM application that it would make no sense to include it in a general smart card standard. The command uses a cryptographic algorithm specific to GSM, and the two initial values generated from the transferred random number would be useless in any other application.