5.9 Verifying the Signed Static Application Data


5.9 Verifying the Signed Static Application Data

The following steps describe the procedure followed by an EMV ¢ terminal for verifying the Signed Static Application Data stored in an EMV ¢ card since its personalization.

  • Step 1: Verify that the length of the Signed Static Application Data (tag 90) data object is N I .

  • Step 2: Apply the signature verification/recovery algorithm in Appendix F, Section F.3.2 (case 2), where S is the Signed Static Application Data, n S = n I and e S = e I . The length N of the modulus is N I .

    The data that is recovered X is parsed as X = B M R H E . The following processing is performed on these items:

    1. Check that E (last byte of X ), which is the recovered data trailer, equals BCh.

    2. Check that B (first byte of X ), which is the recovered data header, equals 6Ah.

    3. Consider the M R as the next N I ˆ’ 22 bytes after B . Parse M R according to the four fields identified in Section 5.8.3.

    4. Check that the signed data format read in field 1 of M R is 03h.

    5. Set up the value of the message M ² to the value represented by the Static Data to Be Authenticated byte string, as currently computed in Section 5.8.2.

    6. Create the message M , representing the static application data to be signed by the issuer, as the concatenation from left to right of the recovered part M R and of the computed part M ² (i.e., M = M R M ² ).

    7. Read the hash algorithm indicator from field 2 of M R . Note that at the moment this value is 01h, corresponding to the SHA-1 algorithm, the only approved hash algorithm in the EMV 2000 specifications (see Annex B3.1 in Book 2 [1]).

    8. Use the indicated hash algorithm to compute the hash code h of M .

    9. Check that h equals the hash result H , which represents the last 20 bytes in X before E .

If any of the verifications mentioned above failed, the verification of the Signed Static Application Data fails. The terminal rejects the authenticity of the financial data stored in the EMV ¢ card.



References

  1. EMVCo, EMV 2000 Integrated Circuit Card Specification for Payment Systems, BOOK 2 ”Security and Key Management , Version 4.0, December 2000.

  2. EMVCo, EMV 2000 Integrated Circuit Card Specification for Payment Systems, BOOK 3 ”Application Specification , Version 4.0, December 2000.



Chapter 6: Debit and Credit with EMV ¢

The goal of this chapter is to offer a tutorial presentation on the transaction profile of the EMV ¢ debit and credit payment application. This presentation should allow someone who has no time to read the entire specification to more easily understand the EMV ¢ payment method. It should be regarded as accompanying material that helps the reader get accustomed with this payment technology as quickly as possible. The chapter does not aim to replace the specifications , which should always be kept as the ultimate reference for any details. The presentation emphasizes the analysis of the protocol between the ICC and the terminal, rather than discussing the card and the terminal separately.

The remainder of the chapter is organized as follows . In Section 6.1 we give a high level description of the transaction flow for EMV ¢ debit/credit payment applications. Starting with Section 6.2, we describe in considerable detail the messages exchanged between the chip card and the terminal during each stage, the processing performed by the card, and the processing performed by the terminal. Matching the EMV ¢ transaction stages to the chapter sections is as follows: initiate application processing (Section 6.2), read application data (Section 6.3), card authentication (Section 6.4), processing restrictions (Section 6.5), cardholder verification (Section 6.6), and terminal risk management (Section 6.7). Section 6.8, corresponding to the terminal action analysis stage, considers the possible actions proposed by the terminal concerning the finalization of an EMV ¢ transaction at the point of service. Section 6.9 analyzes the on-line processing and issuer authentication stage. Section 6.10 describes the prescriptions of the EMV ¢ standard concerning the possibility of updating financial data in the card application through the issuer script mechanism after the card enters its utilization life stage.

6.1 Overview of the EMV ¢ debit/credit transaction

In this section we give an overall picture of the interchange between the ICC and the terminal (Figure 6.1) and between the terminal and the IH (Figure 6.2) in order to complete the protocol of an EMV ¢ debit/credit payment application. The reader can compare the processing in these two diagrams with the processing performed for the magnetic stripe cards, as schematized in Figures 2.1 and 2.2 (see Section 2.1). It can be noticed that the complexity of the protocol between the card and the terminal increases in the case of an EMV ¢ transaction, while the processing performed by the payment network and back-office is comparable.

click to expand
Figure 6.1: Interchange between the ICC and the terminal for an EMV ¢ debit/credit transaction.

click to expand
Figure 6.2: Payment network processing of an EMV ¢ debit/credit transaction.

We refer now to Figure 6.1. All the processing described below is performed if the EMV ¢ debit/credit application is correctly selected during the application selection mechanism (see Section 4.4).

First, the terminal performs the initiate application processing function. The terminal informs the ICC about the business environment at the point of service, which helps the card tuning its strategy according to the conditions of the current transaction. The card provides a roadmap on its public AEF(s) in the AFL (see Section 3.4.2), and a profile of the transaction interchange in the AIP (see Section 3.4.3).

Based on the information contained in the AFL, the terminal is able to perform the read application data function. With this function all the public information contained in the AEF(s) attached to the EMV ¢ debit/credit card application is read by the terminal. After reading the content of the card, the terminal decides whether it has all the necessary data objects to continue the transaction.

Then, depending on the information contained in the AIP, the terminal decides whether off-line data authentication must be performed to enforce the card authentication security service. If the answer is positive, the terminal determines whether off-line SDA (see Appendix D, Section D.6.2) or off-line DDA (see Appendix D, Section D.7.2) is the cryptographic mechanism to be used for implementing this security service.

Furthermore, the terminal performs the processing restrictions function, which evaluates whether the ICC is entitled to ask for a certain financial service at the point of service (cash withdrawal, payment at a POS). If the 6.1 Overview of the EMV debit/credit transaction 149 Card action analysis (card risk management) card is eligible for the kind of service required in the allowed environment (domestic or international), then the transaction interchange is continued or otherwise is aborted.

The terminal performs the cardholder verification stage if the ICC has proposed this function in the AIP. If this function is supported by the card application, the terminal determines a cardholder verification method that is mutually supported by the ICC and the terminal. Then, using this method, the terminal and the card establish the link between the user of the card and the legitimate cardholder.

The terminal also performs the terminal risk management function. This function allows the terminal to establish (from the point of view of the acquirer) whether the amount involved in the transaction is between some acceptable lower and upper floors. The terminal may also decide whether the transaction should be forwarded on-line following a large number of transactions that were completed off-line by the card.

At this stage of the processing, the terminal has a set of results from the completion of the previous functions. These results are accumulated in a 5-byte register called the Terminal Verification Results (TVR). The terminal compares this witness register against the Issuer Action Codes and the terminal action codes, which indicate the action to be performed by the terminal in case one stage in the transaction interchange did not complete as expected. Following this analysis, which is called the terminal action analysis, the terminal either denies or accepts the transaction. In the latter case, the terminal has the choice of completing the transaction locally (off-line) if no major risks are detected , or it can ask for the on-line assistance of the issuer. In either case, the card application is required to produce an application cryptogram, or even a digital signature, which will serve the dual purpose of authenticating on-line the card to the issuer or acting as a nonrepudiation proof of the card's participation in a certain transaction.

The ICC performs its own risk management procedure, according to the security policy of the issuer, within the function called card action analysis. Following the card risk management, the ICC could agree with the type of transaction finalization proposed by the terminal or it could ask for another type of finalization. For example, instead of accepting the off-line completion of the transaction, the card may ask the terminal to perform an online authorization request to the issuer. After performing the card action analysis, the decision about the off-line or on-line completion of the EMV ¢ debit/credit transaction is taken.

In case the terminal must contact the issuer on-line, the payment network has to perform its part of processing, as schematized in Figure 6.2.

The processing is similar to that performed in the case of magnetic stripe cards, with the observation that the payment message sent to the acquirer contains the supplementary information gathered by the terminal from the card during the processing explained in Figure 6.1. After receiving this information, the issuer can better assess whether the card is genuine or not, since the Application Cryptogram produced by the card is "fresh" for every new transaction. The authorization response that is sent back by the IH allows the terminal and the ICC either to deny or to accept the transaction, according to the indication transmitted by the issuer. To this end, the issuer must authenticate itself to the ICC, such that the ICC trusts that the finalization decision for the current EMV ¢ debit/credit transaction comes from the genuine IH.

It is important to note that the authorization response may also contain a sequence of commands to be transmitted by the terminal to the card, which were requested by the issuer. This is the issuer script processing function, through which the issuer can update the card application's parameters in the ICC during its lifetime, after the personalization stage is completed. In order to perform the issuer script processing, the authentication of the issuer must have been successful, such that the ICC can trust that the genuine issuer sends this sequence of commands through the terminal at the point of service.