6.4 Off-line data authentication

6.4.2 Off-line SDA

The off-line SDA requires two separate stages (as shown in Figure 6.5):

1. During the personalization stage of the card, the issuer computes the Signed Static Application Data certificate, according to the algorithm described in Section 5.8.3. Note that using the terminology adopted in Appendix D, Section D.6.2, the Signed Static Application Data certificate corresponds to the static authenticator Static_Auth . This certificate is a signature created with the issuer private key ( N _I , d _I )on the static data to be authenticated (referred to as the financial_data in Appendix D, Section D.6.2) in the card, which is formed according to Section 5.8.2. The issuer first proves knowledge of the appropriate credentials for obtaining writing rights in the card. Then, the issuer loads into the card the signed static application data, which is stored as the data object with tag 93, together with the certificate of the CA on the issuer public key ( N _I , e _I ), referred to as the issuer public key certificate.

2. During the utilization stage, when the off-line SDA is required by the EMV ¢ transaction profile, the card submits to the terminal the data objects it needs to first verify the authenticity of the issuer public key. If the authenticity of this key verifies correctly, the terminal can use it to check the authenticity of the signed static application data. If the verification passes , the terminal agrees on the authenticity of the financial data stored in the card.

Figure 6.5: Overview of the off-line SDA.

The processing needed to verify the authenticity of the data in the card is carried out completely by the terminal, while the card only stores those data objects needed for completing this verification.

Stage 1 The terminal verifies the existence of the following objects in the EMV ¢ data objects heap:

• Certification Authority Public Key Index (tag 8F);

• Issuer Public Key Certificate (tag 90);

• Issuer Public Key Remainder (tag 92), which is present only in certain conditions (see Section 5.4);

• Issuer Public Key Exponent (tag 9F32);

• Signed Static Application Data (tag 93).

If any of the objects mentioned above are not present in the card (except for tag 92), set up bit 6, "ICC data missing", of byte 1 of the TVR and consider that SDA has failed.

Stage 2 The terminal constructs the Static Data to Be Authenticated byte string. Note that for a multithread terminal this processing can be started since the read application data is performed, in parallel with the AFL processing, as described in Section 5.8.2. To this end, the terminal first considers the records indicated for authentication of all the AEF(s) registered in the AFL. Second, after all the records are read from the card and the EMV ¢ data objects heap is constructed , the terminal considers the data objects indicated in the Static Data Authentication Tag List to be concatenated at the end of the Static Data to Be Authenticated byte string.

If the terminal fails to process any of the records considered for authentication in the AFL, static data authentication has failed.

Stage 3 The terminal verifies the authenticity of the Issuer Public Key Certificate and recovers the issuer public key ( n _I , e _I ), following the algorithm presented in Section 5.7.1.

The terminal uses the Certification Authority Public Key Index (tag 8F) together with the RID to retrieve the CA public key ( n _CA , e _CA ) from the appropriate record of the terminal database of CA public keys (see Table 5.2 in Section 5.5). The RID is obtained from the AID (DF Name , tag 84) returned in the FCI of the currently selected ADF, which contains the EMV ¢ debit/credit application. The length of the modulus n _CA is N _CA .

If the verification of the Issuer Public Key Certificate does not pass, then the SDA has failed.

If the terminal manages a revocation list associated with the CA, which contains all the compromised issuer public key certificates, the terminal checks that the certificate serial number corresponding to the current Issuer Public Key Certificate is not blacklisted in this revocation list. If the certificate is blacklisted then the terminal sets up bit 5, "Card appears on terminal exception file", of byte 1 of the TVR register. In this case also, it is considered that the SDA has failed.

Stage 4 The terminal verifies the authenticity of the data objects personalized in the card by checking the authenticity of the Signed Static Application Data certificate received from the card with the authentic copy of the issuer public key ( n _I , e _I ) obtained in stage 3. This verification is performed according to the algorithm presented in Section 5.9.

If the verification of the Signed Static Application Data certificate fails, the SDA has failed.

Otherwise, the SDA processing is considered successful. The terminal stores the data authentication code, representing field 3 in the recovered part M _R of the static application data to be signed by the issuer (see Section 5.8.3), in the value field of a data object with tag 9F45 and length equal to 2 bytes.

If the terminal decides that SDA has failed in any of the four stages described above, the rest of the processing involved in the SDA stage from that point on is skipped .

• The terminal will set bit 8, "Off-line data authentication was performed", in byte 1 of the TSI register.

• The terminal will also set bit 7, "Off-line static data authentication failed", in byte 1 of the TVR register.

6.4.3 Off-line DDA

The off-line DDA guarantees the authenticity of the data personalized in the card by the issuer, as well as that of the card itself. This is possible because the card has processing power and can actively compute an asymmetric cryptogram on an Unpredictable Number coming from the terminal. A genuine card is able to produce a correct cryptogram for each new unpredictable number. When the terminal assesses off-line the correctness of this cryptogram, it accepts that the card is genuine. This is true with overwhelming probability, unless a powerful attacker has broken the tamper resistance of the chip to read the private key of the card or has solved the "heavy" mathematical problem on which relies the computation of the asymmetric cryptogram. This is a big step forward when compared with cards implemented with magnetic stripe or SDA-only EMV ¢ cards. The asymmetric cryptogram computed by the card consists of a digital signature produced on data received from the terminal with the ICC private key. In order to verify this signature, the terminal has to obtain an authentic copy of the corresponding ICC public key, which is recovered traversing the EMV ¢ certification chain CA/issuer/ICC public key (see Figure 5.1 in Section 5.5). It is important to note that the terminal has similar requirements in terms of computation power as in the case of off-line SDA. However, the card has to be able to compute an RSA operation, which requires the presence of a cryptographic coprocessor in the architecture of the card (see Section 3.4.4 and Appendix D, Section D.1.2). Correspondingly, the price of the card increases . The actual ratio between the price of an EMV ¢ chip card with and without cryptographic coprocessor may vary in the range 1.25 of to 2. This ratio depends on whether a card producer offers "on-the-shelf" EMV ¢ cards with coprocessors or rather the developing price for this type of card is shared with the issuer. In the latter case, the bigger the number of ordered cards, the lower the aforementioned ratio. We can expect that this ratio will decrease over the next 5 years , proportionally with the increase of the chip's CPU computation power. At the limit, one can expect that this ratio will become 1, when the CPU will incorporate numerical units for long arithmetic.

This section will first outline the DDA mechanism implemented with digital signatures. Second, the processing performed by the terminal to verify the authenticity of the ICC public key based on traversing the EMV ¢ certification chain consisting of the Issuer Public Key Certificate and the ICC Public Key Certificate is described. Next, the processing performed by the card for computing the digital signature on the data objects sent by the terminal is presented. Finally, how the terminal assesses the correctness of the digital signature generated by the card is explained.

6.4.3.1 Overview of the DDA As can be seen in Figure 6.6, the off-line DDA requires two separate stages:

1. During the personalization stage the issuer loads the Issuer Public Key Certificate in the card. The issuer also generates the pair ICC private key/ICC public key and produces the ICC Public Key Certificate with the issuer private key (Section 5.6). The issuer loads in the card both the ICC private key (using a confidential channel) and the ICC Public Key Certificate.

   Note that the card could generate the pair ICC private key/ICC public key by itself and forward only the ICC public key for certification to the issuer's personalization terminal (using an authentic channel). In this case, the issuer will compute only the ICC Public Key Certificate for downloading it in the card. The generation of the RSA key pairs by the chip card itself would better enforce the nonrepudiation security service during an EMV ¢ transaction, with no supplementary costs related to the chip card.

2. During the utilization stage the card supplies both the Issuer Public Key Certificate and the ICC Public Key Certificate to the terminal. The terminal verifies the authenticity of the Issuer Public Key Certificate with the corresponding CA public key and retrieves an authentic copy of the issuer public key (Section 5.7.1). Using this copy, the terminal can verify the authenticity of the ICC Public Key Certificate and the authenticity of the data personalized in the card by the issuer. If all the verifications are successful, the terminal recovers an authentic copy of the ICC public key (Section 5.7.2). The terminal asks the card with an INTERNAL AUTHENTICATE command to produce a digital signature on a byte string constructed from data objects in the terminal. This byte string is formatted according to the indications of the Dynamic Data Authentication Data Object List (DDOL) provided by the card. For implementing the DDA, the DDOL must include the Unpredictable Number (tag 9F37) data object, which is a random number generated by the terminal for each new EMV ¢ session. After receiving the INTERNAL AUTHENTICATE command with the byte string from the terminal, the card produces a digital signature on this byte string as well as on other data from the card. This signature is referred to in the card as the Signed Dynamic Application Data object with tag 9F4B. The card sends this signature back to the terminal, which will verify it with the authentic copy of the ICC public key. If the verification passes, the terminal accepts that the card is genuine.

Figure 6.6: Overview of the off-line DDA.

6.4.3.2 Verifying the authenticity of the card data and ICC public key

First, the terminal verifies the authenticity of the data personalized in the card and of the ICC public key traversing the EMV ¢ certification chain composed of the Issuer Public Key Certificate and the ICC Public Key Certificate. This processing is carried out completely by the terminal, while the card only conveys those data objects needed for completing this verification.

Stage 1 The terminal verifies the existence of the following objects in the EMV ¢ data objects heap:

• All the data objects needed by the terminal for performing the off-line SDA (stage 1 in Section 6.4.2), except for the Signed Static Application Data (tag 93);

• ICC Public Key Certificate (tag 9F46);

• ICC Public Key Remainder (tag 9F48), which is present only in certain conditions (Section 5.4);

• ICC Public Key Exponent (tag 9F47).

If any of the objects mentioned above are not present in the card (except for tag 9F48 and tag 9F49), set up bit 6, "ICC data missing", in byte 1 of the TVR and consider that DDA has failed.

Note that if the terminal does not identify the DDOL (tag gF49) in the EMV ¢ data objects heap, the terminal should use a default DDOL personalized in the EMV ¢ terminal application by the acquirer. If the default DDOL is also missing, the DDA has failed.

Stage 2 The terminal constructs the static data to be authenticated byte string as it was described in Section 5.8.2. If the static authentication tag list contains any tags other than those accepted (note that there are some differences between the EMV'96 and the EMV 2000 specifications), DDA has failed.

Stage 3 The terminal verifies the authenticity of the Issuer Public Key Certificate (tag 90) and recovers the issuer public key ( n _I , e _I ) according to the algorithm described in Section 5.7.1.

Stage 4 The terminal verifies the authenticity of the ICC Public Key Certificate (tag 9F46) received from the card with the authentic copy of the issuer public key, ( n _I , e _I ), which was obtained in stage 3. N _I denotes the length of the modulus n _I .

If any of the verifications mentioned above failed, DDA has failed. The terminal stores the ICC public key ( n _IC , e _IC ) to subsequently verify the Signed Dynamic Application Data produced by the card. The terminal proceeds with the next stage.

Stage 5 The terminal initiates the computation of the Signed Dynamic Application Data in the card with an INTERNAL AUTHENTICATE command.

• Step 1: The terminal generates a random number of 4 bytes, the value of which is assigned to the Unpredictable Number data object (tag 9F37). Its role is to guarantee the uniqueness of the digital signature computed by the card, countering potential replay attacks.

• Step 2: The terminal creates the terminal dynamic data byte string, concatenating the value fields of all the data objects whose tag-length identifiers are listed in the DDOL. The DDOL should contain at least the tag-length identifier of the unpredictable number, but may also include the identifiers of other data objects from the terminal like the Terminal Identification (tag 9F1C), Terminal Country Code (tag 9F1A), and (tag 9A).

  • If the DDOL received from the card does not have the identifier of the Unpredictable Number among its identifiers, the DDA has failed.

  • If the card did not send the DDOL, the terminal must use the default DDOL. The terminal must check that the tag-length identifier of the Unpredictable Number is among the items listed in the default DDOL. If this is not the case, the DDA has failed.

• Step 3: The terminal creates the C-APDU corresponding to the INTERNAL AUTHENTICATE command. This C-APDU is summarized in Table 6.3 (according to Table I-19 in Book 3 [1]).

The control parameter P1 encodes the reference of the algorithm for computing the signed dynamic application data, from the terminal's viewpoint. The actual value accepted for P1 is 00, which means that no information on the algorithm is given through P1. At present, the algorithm used by the card for generating the Signed Dynamic Application Data is the RSA algorithm. After formatting the C-APDU of the INTERNAL AUTHENTICATE command, the terminal sends it to the card.

Note that if the combined dynamic data authentication/Application Cryptogram generation is chosen for implementing the off-line data authentication service (choice 2 in Section 6.4.1), all the processing described above is performed except for step 3 in stage 5. In this case, the terminal does not send a separate INTERNAL AUTHENTICATE command to the card.

6.4.3.3 Signature generation by the ICC

Before computing the signature, the card checks that the parameters P1 and P2 of the INTERNAL AUTHENTICATE command are equal to 00. It then checks that the issuer did not previously block the currently selected application through a post-script command. The card also checks that in the current session the execution of the GET PROCESSING OPTIONS command was successfully performed and no other INTERNAL AUTHENTICATE C-APDU was sent to the card. Otherwise the card returns SW1SW2 = 6985, "Command not allowed; conditions of use not satisfied" (see Table I-4 in Book 3 [1]).

Then the card computes the ICC Dynamic Number (tag 9F4C). This is a time-variant parameter generated by the card. When receiving this parameter in an authorization request sent on-line or even in a payment capture message during the clearing, the issuer can check the freshness of this parameter. Thus, the issuer verifies whether the terminal performed the DDA stage or not, when this is required by the EMV ¢ transaction profile. The parameter can be a sequence number incremented each time the INTERNAL AUTHENTICATE command is sent to the card, for which the issuer keeps a synchronous counter in the IH. The parameter can also be a symmetric cryptogram, which is unique for each card and for each transaction. This cryptogram can be a MAC computed by the card on the ATC, which is incremented at every transaction. This MAC is computed with a unique key diversified for each card from a unique master key of the issuer assigned for the purpose of computing the ICC Dynamic Number.

Note that the issuer could have required that the terminal send the entire Signed Dynamic Application Data to the IH for verification. But this could overload the authorization request message with N _IC bytes, which can amount to 248 bytes instead of the 3 to 9 bytes needed by the ICC Dynamic Number. When non-repudiation is not a security feature required by the issuer, the use of the ICC Dynamic Number is more economical.

The ICC applies the digital signature scheme giving message recovery implemented with the RSA algorithm, as described in Appendix F, Section F.3.1 (case 2). This algorithm is applied on the message M = M _R M ² with the RSA parameters n _S = n _IC and d _S = d _IC to obtain a signature S , which is referred to as the signed dynamic application data, stored in the card with the tag 9F4B.

The message M = M _R M ² is referred to as the dynamic application data to be signed (see Table 11 in Book 2 [2]).

• The part M ² consists of the terminal dynamic data byte string, as received in the INTERNAL AUTHENTICATE command from the terminal.

• The part M _R consists of five fields:

  1. Field 1 ”signed data format (1 byte): it has the fix value 05h.

  2. Field 2 ”hash algorithm indicator (1 byte): it identifies the hash algorithm used to produce the hash code H . This value is used in step 1 of the algorithm described in Appendix F, Section F.3.1 (case 2). At the moment, SHA-1 is the hash algorithm recommended by the EMV ¢ 2000 specifications in Annex B3.1 of Book 2 [2]. Thus, the value of the hash algorithm indicator is set to 01h.

  3. Field 3 ”ICC dynamic data length (1 byte): It specifies the bytelength L _DD of the ICC dynamic data in field 4. This parameter has to satisfy the relation 0 ‰ L _DD ‰ N _IC ˆ’ 25.

  4. Field 4 ”ICC dynamic data ( L _DD bytes): It consists of L _DD bytes, of which the leftmost byte encodes the length of the ICC Dynamic Number (between 2 and 8 bytes), and the following 2 to 8 bytes represent the ICC Dynamic Number. The rest of the ICC dynamic data, until L _DD bytes, can be used by each issuer in a proprietary manner.

  5. Field 5 ”pad pattern: It contains a number of N _IC ˆ’ L _DD ˆ’ 25 bytes of value BBh.

After the successful completion of this computation, the card sets up an internal flag to mark that DDA was completed. The card can elaborate the R-APDU to be returned to the terminal in two formats:

1. Response Message Template Format 1: This is a primitive data object with tag 80 whose length is N _IC . The value field of this data object contains only the value field of the signed dynamic authentication data.

2. Response Message Template Format 2: This is a constructed data object with tag 77, which may include several data objects encoded in a BER-TLV format, but which will always contain the signed dynamic authentication data. The other data objects, when they are included, are proprietary to each issuer.

The R-APDU includes at the rightmost position the status words SW1SW2 = 9000.