Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
As previously noted, the offline card authentication procedure is a key element of the security of operations performed using the IPC. The latest version of the EMV standard (v.4.2) distinguishes between three offline card authentication methods:
The choice of the authentication method is carried out by the terminal based on the AIP data (Application Interchange Profile, Tag '82') and terminal capabilities (see section 4.5). Let's start our overview of offline card authentication methods by looking at static authentication.
During the transaction, the terminal reads the signature of the most important Signed Static Application Data from the card and verifies it.
If the signature is correct, it is considered that the card has successfully passed the static authentication procedure.
Thus, static card authentication is not really card authentication (card validation). Static authentication is only a means of ensuring the integrity of some application-critical data cards, that is, the impossibility of modifying this data in such a way that their change would be unnoticed during transaction processing.
Application-critical data is determined by the card issuer. Such data usually include the card number, its validity period, data on the geography of the card service and the operations available on the card (Application Usage Control), the card usage profile (Application Interchange Profile), the list of cardholder verification methods supported by the card (CVM List), etc. An example of critical application data is shown in Table. 3.14.
When performing the static authentication procedure, sensitive data is taken from the Static Data to be Authenticated data object. This object is not stored on the card and is formed during the execution of the transaction using the AFL (Application File Locator) object and optionally the SDA Tag List object (see section 4.4).
At its core, static authentication is analogous to the CW / CVC check performed on magnetic stripe cards. The only difference is that the SDA method allows you to ensure the integrity of a much larger amount of data of the issuer's application, as well as to authenticate the card offline using the terminal of the serving bank (CW / CVC is checked by the card issuer). In order for static authentication to be performed by any terminal in the system, asymmetric encryption (RSA algorithm) and a two-layer PKI structure, shown in Fig. 3.11.
To perform static authentication, the card must store the following data objects:
Certification Authority
Acquirer
Card provides to terminal:
To describe the SDA method, we introduce the following notation:
MasterCard to A
Let's move on to the description of the Issuer Public Key Certificate (Tag '90') data object. Field Size Value of the object data is equal to N CA . Table 3.12 shows the data signed by the certification authority of the payment system to obtain the Issuer Public Key Certificate (Tag '90').
Tab. 3.12. Data signed by the certification authority of the payment system to obtain the Issuer Public Key Certificate
The card application data signed by the issuer are shown in table. 3.13.
Tab. 3.13. Data signed by the issuer to form the Signed Static Application Data element (Tag '93')
The 2 byte Data Authentication Code (DAC) element is a static characteristic of the card used by the issuer to verify that the terminal is performing static card authentication. The DAC element is either some random value stored for each card in the issuer's database, or it is calculated by the issuer, for example, by the card number (PAN) and PAN Sequence Number. As an algorithm for calculating DAC, the 3DES algorithm is usually used, using a separate, specially designed key of the card issuer. The DAC element is loaded onto the card as part of the personalization process.
In accordance with the EMV standard, the static application data signed by the issuer is defined in the Application File Locator object returned by the card to the terminal in response to the GET PROCESSING OPTIONS command. In the process of reading the card data, the terminal builds the Static Data to be Authenticated object, as described in p. 4.4. The list of data recommended by payment systems for inclusion in Static Data to be Authenticated is given in Table. 3.14.
Tab. 3.14. An example of critical application data
MasterCard to J
The end of the table. 3.14.
Table 3.15 lists the card data objects that are required to implement the static authentication procedure.
Tab. 3.15. Data Objects Needed for Static Authentication
The static authentication procedure is performed in three steps:
3) if all signature checks are successful, then it is considered that the verification of the issuer's public key certificate has been completed successfully. According to the data recovered from the issuer's key certificate (see Table 3.12), the leftmost bytes of the issuer's public key module are determined (N CA - 36). Then the module of the public key of the Issuer Public Key is obtained as a concatenation of these (N CA - 36) bytes and (N, - N CA + 36) bytes of the data field of the Issuer Public Key Remainder object (Tag '92'). The public exponent of the issuer's key is stored on the card as a separate data object (Tag '9F32').
After restoring the public key of the Issuer Public Key, you can proceed to the actual procedure of static card authentication - checking the signature of the critical data of the Signed Static Application Data card (step 3 of the authentication algorithm).
Signature verification of critical card data is performed according to the following rules:
To implement this authentication method, a three-tier PKI structure is used (Figure 3.12). As you can see from the figure, the dynamic authentication methods use the public / private key pair of the card itself. The length of the card's public key module, expressed in bytes, will be denoted by N IC .
There are two methods of dynamic card authentication:
Issuer
Certification Authority
Acquirer
Rice. 3.12. Dynamic card authentication diagram
The essence of the methods is that the terminal generates a random number, which is transmitted to the card along with some other data for signing. The card returns to the terminal the signed data of the terminal and if the terminal determines that the signature of the data received from the card, as well as the certificates of the issuer's key and the card key are correct, it concludes that the card is genuine.
Indeed, since the card did not know in advance the random number offered to it by the terminal, the fact that the terminal's random data was signed correctly means that the signature was made by a card that has a private key corresponding to the public key, the validity of the certificate of which is verified in the three-tier PKI infrastructure. This means that the card was issued by an authorized bank of a well-known payment system.
Note that the structure of the card's public key certificate is such that when this certificate is verified, the integrity of the card's critical data is automatically checked. It can be said that the dynamic authentication functionality of a card automatically includes its static authentication functionality.
To implement dynamic card authentication methods, the card must store the following data items:
In accordance with the EMV standard, the inequality N IC <<N, < N ca <248 is fulfilled. In reality, the lengths of the card's and issuer's public key modules are always strictly less than 248 bytes, and in the case of using the CDA method, they may not exceed 205 bytes (see p. . 3.16.3).
The data used to generate the ICC Public Key certificate and signed with the issuer's key are shown in table. 3.16.
Tab. 3.16. ICC Public Key data signed by the issuer
The end of the table. 3.16
In the dynamic authentication procedure, as well as in the static authentication procedure, one of the steps is the verification of the certificate and the extraction of the public key of the Issuer Public Key. This process has been detailed in 3.12.1. Therefore, in this section, we will focus only on the procedure for verifying the certificate and extracting the public key of the ICC Public Key card.
After successfully completing the verification of the Issuer Public Key Certificate (Tag '90') and extracting the Issuer Public Key from it, the terminal proceeds to the procedure for verifying the public key certificate of the ICC Public Key Certificate (Tag '9F46') and recovering the ICC Public key. Key according to the following algorithm:
After recovering the public key of the ICC Public Key, you can proceed to the actual procedure of dynamic card authentication.
Dynamic Data Authentication (DDA)
The terminal starts the implementation of the Dynamic Data Authentication (DDA) method by finding the Dynamic Data Authentication Data Object List (DDOL) object among the data read on the card, the tag of which is' 9F49'h. The DDOL object contains a list (tags and lengths) of those data objects that are required by the card to form the Terminal Dynamic Data field, which is part of the data signed by the card (see Table 3.18). Note that in accordance with the EMV standard, in DDOL, as in any other list of Data Object List, for example, PDOL, CDOL1, CDOL2, only tags of primitive data objects can be present. The presence of a composite object in the list is not a fatal error. In this case, in accordance with section 5.4 of book 3 of the EMV 4.2 specifications, the number of bytes corresponding to the length of the composite data object is placed in the Terminal Dynamic Data field,
The Terminal Dynamic Data field is formed in accordance with the rules described in section 5.4 of book 3 of the EMV 4.2 specifications, as a concatenation of the Value fields of all data objects whose tags are listed in DDOL. The Value fields are taken in the order of their corresponding tags in the DDOL list.
The only required data item in DDOL is the Unpredictable Number object (Tag '9F37', binary data format, size 4 bytes). An example of the DDOL structure is shown in table. 3.17.
Tab. 3.17. DDOL example
If the card does not contain a DDOL object, then the terminal forms the Terminal Dynamic Data field in accordance with the DDOL-Default object defined by the payment system and stored on the terminal.
DDA authentication is considered DDA Failed if:
Having received the DDOL object from the terminal, the card generates the Terminal Dynamic Data field, as well as other fields defined in table. 3.18.
MasterCard to J
Tab. 3.18. Data signed by card in case of DDA
One of the signed data fields contains an ICC Dynamic Data element. The size of this element is L DD bytes and satisfies the inequalities O - L dd <N IC - 25. The ICC Dynamic Data element consists of an ICC Dynamic Number Length element of 1 byte and an ICC Dynamic Number element (IDN, Tag '9F4C') of size 2 -8 bytes. The ICC Dynamic Number data element, as well as the DAC element encountered in the description of static card authentication, is used to confirm that the terminal has performed the card authentication procedure (in this case, dynamic card authentication).
The choice of the method for generating the IDN value is completely delegated to the card issuer. In practice, the IDN value is most often calculated as a function of the number of the current PBX transaction (Application Transaction Counter, Tag '9F36') - As a function, usually (for example, in the M / Chip 4 specifications) the 3DES algorithm is used with a specially defined MK card key IDN :
IDN = DES3 (MK 1dn ) [(ATC AND '00' || '00' || '00' || '00' || '00' || '00')].
Note that for a more reliable "binding" of the ICC Dynamic Number value to the current transaction when calculating the IDN, in addition to the PBX transaction number, we would like to use the random Unpredictable Number generated by the terminal during the operation. However, in general, it is not possible to use the Unpredictable Number value to calculate the IDN. This is because the random Unpredictable Number presented to the card by the terminal in the command
INTERNAL AUTHENTICATE is not valid for IDN calculation because the card issuer does not receive this number and therefore cannot verify the IDN value. The issuer receives the value of the last random number sent to the card in the GENERATE AC command. However, this value is not known to the card (except in the case of CDA authentication) at the time of the card authentication procedure (the GENEARTE AC command is executed after offline dynamic card authentication, except in the case of CDA). Hence it follows that in general it is not possible to use the Unpredictable Number value to calculate IDN.
After all the fields of the table. 3.18 are prepared with the card, the card encrypts the data of this table with its secret key (ICC Private Key) and sends the resulting Signed Dynamic Application Data result to the terminal in the data field of the response to the INTERNAL AUTHENTICATE command.
From this moment, the terminal starts checking the received Signed Dynamic Application Data value. Verification is performed using the ICC Public Key. To check the Signed Dynamic Application Data value, the terminal:
Combined DDA / Application Cryptogram Generation (CDA)
The CDA method not only verifies the integrity of important static application data and the authenticity of the card, but also ensures the integrity of critical data circulating between the card and the terminal. Implementing this card authentication method requires that it be supported by both the card and the terminal.
This card authentication method is not used if the card decides to generate an Application Authentication Cryptogram (AAC). To implement the CDA method, the CDOL1 and CDOL2 data objects must contain the tag and the length of the Unpredictable Number data object, which is a random number generated by the terminal. According to section 6.6.1 of Book 2 of the EMV 4.2 specifications, if at least one of these objects does not mention the Unpredictable Number element, CDA authentication is considered to be failed and the card must require completion of the operation with an AAC cryptogram (authorization denial).
Requiring the presence of an Unpredictable Number object (Tag '9F37') in both CDOL1 and CDOL2 lists ensures that the card receives a random number from the terminal and that the card can generate a cryptogram and generate a Signed Dynamic Application Data item. This requirement is not related to considerations of improving the safety of the operation, but is functionally necessary.
Indeed, when using the SDA and DDA methods, in the case when the CDOL2 list does not mention the Unpredictable Number object, as a cryptogram generated by the card in response to the second GENERATE AC command, the card can offer the cryptogram calculated in response to the first AC GENERATE command. The storage of the ARQC cryptogram value by the card is still necessary, since this cryptogram is used to authenticate the issuer (for ARPC verification regardless of the method used to calculate ARPC), and ARQC is usually used to output session keys used to ensure data integrity and confidentiality in Issuer Script commands Processing.
In the case of using the CDA method, it is not enough to know the meaning of the cryptogram. The card must also remember the random number used to generate the cryptogram. This is due to the fact that when using CDA, the same random number is used both for calculating the cryptogram and for generating the Signed Dynamic data item
Application Data. Since storage by the Unpredictable Number card is not regulated by the EMV standard in any way, in order to be sure that the execution of the second GENERATE AC command will complete successfully, it is necessary to include the Unpredictable Number object as a mandatory element not only in the CDOL1 list, but also in the CDOL2 list.
The emergence of the CDA method (the method first appeared in the EMV 4.0 version) is associated with its ability to ensure the integrity of data circulating between the card and the terminal. It is obvious that the absence of such a mechanism can lead to attacks by fraudsters modifying the data of this information exchange, which in turn can radically change the result of the transaction.
Let's give a simple example. The card decides to reject the transaction offline and in the data field of the response to the GENERATE command, the AC sends a Cryptogram Information Data (CID) data element corresponding to this decision. The fraudster intercepts the card message (how this can be done will be described below) and modifies the CID value in such a way that a decision is declared according to which the transaction is approved by the card. As a result, to the delight of the fraudster, the operation ends with the exact opposite of the decision of the card (card issuer).
In general terms, the essence of the CDA method is as follows. In accordance with CDA, card authentication is performed as part of the procedure for processing the AC GENERATE command, and not before executing this command, as in the case of card authentication using SDA and DDA methods. Since it is during the execution of the GENERATE AC command between the card and the terminal that the most critical transaction data are exchanged, when implementing a special mechanism, it is possible to simultaneously perform dynamic card authentication and ensure the integrity of critical transaction data. This combination of card authentication and transaction data integrity is implemented in the CDA method.
Table 3.19 shows the data signed by the card during the CDA authentication procedure.
Obviously, the L DD value satisfies the inequalities 0 <L DD <N IC - 25.
Comparison of table. 3.18 and 3.19 show that the external difference between the signed data in the DDA and CDA methods lies only in the fact that in the second case Terminal Dynamic Data degenerates into a mandatory data element Unpredictable Number, which is a random number generated by the terminal. However, this is an apparent similarity. In fact, the difference between the signed data lies in the different structures. 3.19. Data signed by card in case of CDA
round the ICC Dynamic Data field. In the case of CDA, the structure of the leftmost bytes of the ICC Dynamic Data field is shown in Table 1. 3.20.
Tab. 3.20. 32-38 leftmost bytes of ICC Dynamic Data field in case of CDA
In the case of using CDA, the data field of the response to the AC GENERATE command has the form shown in table. 3.21.
Tab. 3.21. The structure of the data field of the response to the command GENERATE AC
Card authentication in accordance with the CDA method consists in the terminal verifying the Signed Dynamic Application Data element. Before we consider the procedure for checking this data element, let us dwell on the description of the process of generating the value of the Transaction Data Hash Code data element present in ICC Dynamic Data (see Table 3.20).
To calculate the value of the Transaction Data Hash Code when forming a response to the first GENERATE AC command, the SHA-1 algorithm is used, which is executed on the data below, taken in the following order:
Next, the digital signature of Signed Dynamic Application Data is verified:
- SDA (Static Data Authentication, static authentication);
- DDA (Dynamic Data Authentication, dynamic authentication);
- CDA (Combined Dynamic Data Authentication / Application Cryptogram Generation, combined authentication).
The choice of the authentication method is carried out by the terminal based on the AIP data (Application Interchange Profile, Tag '82') and terminal capabilities (see section 4.5). Let's start our overview of offline card authentication methods by looking at static authentication.
- 3.12.1. Static data authentication
- (Static Data Authentication, SDA)
During the transaction, the terminal reads the signature of the most important Signed Static Application Data from the card and verifies it.
If the signature is correct, it is considered that the card has successfully passed the static authentication procedure.
Thus, static card authentication is not really card authentication (card validation). Static authentication is only a means of ensuring the integrity of some application-critical data cards, that is, the impossibility of modifying this data in such a way that their change would be unnoticed during transaction processing.
Application-critical data is determined by the card issuer. Such data usually include the card number, its validity period, data on the geography of the card service and the operations available on the card (Application Usage Control), the card usage profile (Application Interchange Profile), the list of cardholder verification methods supported by the card (CVM List), etc. An example of critical application data is shown in Table. 3.14.
When performing the static authentication procedure, sensitive data is taken from the Static Data to be Authenticated data object. This object is not stored on the card and is formed during the execution of the transaction using the AFL (Application File Locator) object and optionally the SDA Tag List object (see section 4.4).
At its core, static authentication is analogous to the CW / CVC check performed on magnetic stripe cards. The only difference is that the SDA method allows you to ensure the integrity of a much larger amount of data of the issuer's application, as well as to authenticate the card offline using the terminal of the serving bank (CW / CVC is checked by the card issuer). In order for static authentication to be performed by any terminal in the system, asymmetric encryption (RSA algorithm) and a two-layer PKI structure, shown in Fig. 3.11.
To perform static authentication, the card must store the following data objects:
- Certification Authority Public Key Index (Tag '8F');
- Issuer Public Key Certificate (Tag '90');
- Issuer Public Key Remainder (Tag '92'), this data object is present if the difference between the lengths of the modules of the system's public key and the issuer's public key is less than 36 bytes;
- Issuer Public Key Exponent (Tag '9F32');
- Signed Static Application Data (Tag '93').
Certification Authority
Acquirer
Card provides to terminal:
- - P1 certified by Certification Authority
- - Card data with digital signature
- - Uses Рсд to verify that Issuer's P ,, was certified by the CA
- - Uses P1 to verify the digital signature of the card data
To describe the SDA method, we introduce the following notation:
- N ca - length (in bytes) of the public key module of the payment system certification authority;
- N, - length (in bytes) of the card issuer's public key module.
- According to the EMV standard, the inequality N, < N ca <248 is fulfilled .
MasterCard to A
Let's move on to the description of the Issuer Public Key Certificate (Tag '90') data object. Field Size Value of the object data is equal to N CA . Table 3.12 shows the data signed by the certification authority of the payment system to obtain the Issuer Public Key Certificate (Tag '90').
Tab. 3.12. Data signed by the certification authority of the payment system to obtain the Issuer Public Key Certificate
| Field name | Length, bytes | Description | Format |
| Certificate Format | 1 | '02'h | B |
| Issuer Identification Number | 4 | Leftmost 3-8 digits from Primary Account Number | cn 8 |
| Certificate Expiration Date | 2 | Date (month and year) after which the certificate is invalid | n4 |
| Certificate Serial Number | 3 | A binary number unique to a given certificate, assigned Certificate Authority | b |
| Hash Algorithm Indicator | 1 | Identifies the hashing algorithm; in the current implementation EMV takes the value '01 b, corresponding to the SHA-1 algorithm | b |
| Issuer Public Key Algorithm Indicator | 1 | Identifies the digital signature algorithm; in the current implementation EMV takes the value '01 'h, corresponding to the RSA algorithm | b |
| Issuer Public Key Length | 1 | The length of the issuer's public key module in bytes - N, | b |
| Issuer Public Key Exponent Length | 1 | The exponent length of the issuer's public key in bytes | b |
| Issuer Public Key or its leftmost digits | N ca - 36 | If N, < N ca - 36, then this field shall contain the complete modulus of the issuer's public key, right-padded with bytes with the value 'BB'h. If N,> N ca - 36, then this field contains N ca - 36 most significant bytes of the issuer's public key module | b |
| Issuer Public Key Remainder | 0 or N, - N ca + 36 | This field is present, if N]> N ca - 36, and consists of N, - N ca + 36 least significant bytes of the issuer's public key module | b |
| Issuer Public Key Exponent | 1 or 3 | Value 3 or 2 16 + 1 | b |
The card application data signed by the issuer are shown in table. 3.13.
Tab. 3.13. Data signed by the issuer to form the Signed Static Application Data element (Tag '93')
| Field name | Length, bytes | Description | Format |
| Signed Data Format | 1 | '03'h | B |
| Hash Algorithm Indicator | 1 | Identifies the hashing algorithm; in the current implementation, EMV takes the value 'Ol'h, corresponding to the SHA-1 algorithm | b |
| Data Authentication Code | 2 | Card details calculated by the issuer during its personalization | b |
| Pad Pattern | Nj-26 | Consists of N1 - 26 bytes filled with 'BB'h value | b |
| Static Data to be Authenticated | Variable | Critical map data for which integrity is ensured | - |
The 2 byte Data Authentication Code (DAC) element is a static characteristic of the card used by the issuer to verify that the terminal is performing static card authentication. The DAC element is either some random value stored for each card in the issuer's database, or it is calculated by the issuer, for example, by the card number (PAN) and PAN Sequence Number. As an algorithm for calculating DAC, the 3DES algorithm is usually used, using a separate, specially designed key of the card issuer. The DAC element is loaded onto the card as part of the personalization process.
In accordance with the EMV standard, the static application data signed by the issuer is defined in the Application File Locator object returned by the card to the terminal in response to the GET PROCESSING OPTIONS command. In the process of reading the card data, the terminal builds the Static Data to be Authenticated object, as described in p. 4.4. The list of data recommended by payment systems for inclusion in Static Data to be Authenticated is given in Table. 3.14.
Tab. 3.14. An example of critical application data
| The magnitude | Format | Length, bytes | Tag |
| Application Effective Date | n6 | 3 | '5F25'h |
| Application Expiration Date | pb | 3 | * 5F24'h |
| Application Usage Control | b | 2 | '9F07'h |
MasterCard to J
The end of the table. 3.14.
| The magnitude | Format | Length, bytes | Tag |
| Application Primary Account Number (PAN) | Joint venture before 19 characters | Before u | '5A'h |
| Application PAN Sequence Number | n2 | 1 | '5F34'h |
| Cardholder Verification Method (CVM) List | b | Up to 252 | '8E'h |
| Issuer Action Code-Default | b | 5 | '9F0D'h |
| Issuer Action Code-Denial | b | 5 | '9F0E'h |
| Issuer Action Code-Online | b | 5 | '9F0F'h |
| Issuer Country Code | nz | 2 | '5F28'h |
| SDA Tag List | - | Variable | '9F4A'h |
Table 3.15 lists the card data objects that are required to implement the static authentication procedure.
Tab. 3.15. Data Objects Needed for Static Authentication
| Tag | Length, bytes | Meaning | Format |
| - | 5 | Registered Application Provider Identifier (RID) | b |
| '8F'h | 1 | Certification Authority Public Key Index | b |
| '90'h | N ca | Issuer Public Key Certificate | b |
| '92'h | N, -N ca +36 | Issuer Public Key Remainder, if present | B |
| '9F32'h | 1 or 3 | Issuer Public Key Exponent | b |
| '93'h | N; | Signed Static Application Data | b |
| - | Variable | Static data to be authenticated | - |
The static authentication procedure is performed in three steps:
- 1) the terminal, based on the Certification Authority Public Key Index and RID data read from the card (the first five bytes of AID), selects the public key of the payment system certification authority Certification Authority stored in it, corresponding to the private key of the Certification Authority, with which the issuer's public key certificate was calculated ... If the public key of the payment system is not found, it is considered that the static authentication of the card has failed (SDA Failed);
- 2) verification of the issuer's public key certificate is performed;
- 3) the signature of the critical data of the card is verified.
- 1) the Issuer Public Key Certificate element is considered as a digital signature calculated using the private key of the payment system corresponding to the public key of the Certification Authority Public Key, determined by the terminal at the first step of the static authentication algorithm. Next, the standard checks of the digital signature are performed, described earlier in clause 3.11.1. If at least one of the standard checks fails, the static card authentication is considered to have failed;
- 2) in the course of the previous step, the data listed in Table 2 are restored. 3.12. Additional checks are performed for the recovered data:
- certificate validity period - the current date should not exceed the certificate validity period;
- Certificate Format - must be equal to '02'h;
- Issuer Identifier - must be equal to the leftmost 3-8 digits of the card number;
- the fact that the terminal supports an asymmetric encryption algorithm, the type of which is determined by the Issuer Public Key Algorithm Indicator;
- the fact of absence in the list of revoked certificates of issuers of the aggregate corresponding to the certificate of the card issuer for which static authentication is performed. This check is optional.
3) if all signature checks are successful, then it is considered that the verification of the issuer's public key certificate has been completed successfully. According to the data recovered from the issuer's key certificate (see Table 3.12), the leftmost bytes of the issuer's public key module are determined (N CA - 36). Then the module of the public key of the Issuer Public Key is obtained as a concatenation of these (N CA - 36) bytes and (N, - N CA + 36) bytes of the data field of the Issuer Public Key Remainder object (Tag '92'). The public exponent of the issuer's key is stored on the card as a separate data object (Tag '9F32').
After restoring the public key of the Issuer Public Key, you can proceed to the actual procedure of static card authentication - checking the signature of the critical data of the Signed Static Application Data card (step 3 of the authentication algorithm).
Signature verification of critical card data is performed according to the following rules:
- 1) first, standard checks of the signature of the data listed in Table 1 are performed. 3.13. Checks are performed on the Signed Static Application Data object (see clause 3.11.1) - the signature length, header and end of data recovered from Signed Static Application Data, the value of the hash function are checked;
- 2) then a special check of the Signed Data Format element of the data recovered in the previous step is carried out, which should be equal to '03'h;
- 3) the card is considered to be successfully authenticated using the SDA method if and only if all of the above checks have been completed successfully. In this case, the terminal stores the DAC value recovered from the Signed Static Application Data element as a data object with Tag '9F45'.
- 3.12.2. Dynamic card authentication
To implement this authentication method, a three-tier PKI structure is used (Figure 3.12). As you can see from the figure, the dynamic authentication methods use the public / private key pair of the card itself. The length of the card's public key module, expressed in bytes, will be denoted by N IC .
There are two methods of dynamic card authentication:
- DDA (Dynamic Data Authentication, dynamic authentication);
- CDA (Combined Dynamic Data Authentication / Application Cryptogram Generation).
Issuer
Certification Authority
Acquirer
Rice. 3.12. Dynamic card authentication diagram
The essence of the methods is that the terminal generates a random number, which is transmitted to the card along with some other data for signing. The card returns to the terminal the signed data of the terminal and if the terminal determines that the signature of the data received from the card, as well as the certificates of the issuer's key and the card key are correct, it concludes that the card is genuine.
Indeed, since the card did not know in advance the random number offered to it by the terminal, the fact that the terminal's random data was signed correctly means that the signature was made by a card that has a private key corresponding to the public key, the validity of the certificate of which is verified in the three-tier PKI infrastructure. This means that the card was issued by an authorized bank of a well-known payment system.
Note that the structure of the card's public key certificate is such that when this certificate is verified, the integrity of the card's critical data is automatically checked. It can be said that the dynamic authentication functionality of a card automatically includes its static authentication functionality.
To implement dynamic card authentication methods, the card must store the following data items:
- Certification Authority Public Key Index (Tag '8F');
- Issuer Public Key Certificate (Tag '90');
- Issuer Public Key Remainder (Tag '92'), this data object is present if the difference between the lengths of the modules of the system's public key and the issuer's public key is less than 36 bytes;
- Issuer Public Key Exponent (Tag '9F32');
- ICC Public Key Certificate (Tag '9F46');
- ICC Public Key Remainder (Tag '9F48'), this data object is present if the difference between the lengths of the modules of the issuer's public key and the card's public key is less than 42 bytes;
- ICC Public Key Exponent (Tag '9F47');
- ICC Private Key.
In accordance with the EMV standard, the inequality N IC <<N, < N ca <248 is fulfilled. In reality, the lengths of the card's and issuer's public key modules are always strictly less than 248 bytes, and in the case of using the CDA method, they may not exceed 205 bytes (see p. . 3.16.3).
The data used to generate the ICC Public Key certificate and signed with the issuer's key are shown in table. 3.16.
Tab. 3.16. ICC Public Key data signed by the issuer
| Field name | Length, bytes | Description | Format |
| Certificate Format | 1 | '04'h | B |
| PAN | ten | PAN card number, right padded with 'F'h | cn 20 |
| Certificate Expiration Date | 2 | Date (month and year) after which the certificate is invalid | n4 |
| Certificate Serial Number | 3 | Binary number unique to this certificate assigned by the issuer | b |
| Hash Algorithm Indicator | 1 | Identifies the hashing algorithm; in the current implementation, EMV takes the value '01'h, corresponding to the SHA-1 algorithm | b |
| ICC Public Key Algorithm Indicator | 1 | Identifies the digital signature algorithm; usually takes the value '01'h, corresponding to the RSA algorithm | b |
| ICC Public Key Length | 1 | The length of the card's public key module in bytes - N 1C | b |
| ICC Public Key Exponent Length | 1 | The exponent length of the card's public key in bytes | b |
The end of the table. 3.16
| Field name | Length, bytes | Description | Format |
| ICC Public Key or its leftmost digits | N, -42 | If N IC <N, - 42, then this field must contain the card's public key module in its entirety, padded on the right by bytes with the value 'BB'h. If N IC > N, - 42, then this field contains the N, - 42 most significant bytes of the card's public key | B |
| ICC Public Key Reminder | 0 or N 1C -N, + 42 | This field is present if N IC > N, - 42, and consists of N IC - N, + 42 least significant bytes of the card's public key | B |
| ICC Public Key Exponent | 1 or 3 | Value 3 or 2 16 + 1 | B |
| Static Data to be Authenticated | Variable | Critical data whose integrity is guaranteed | B |
In the dynamic authentication procedure, as well as in the static authentication procedure, one of the steps is the verification of the certificate and the extraction of the public key of the Issuer Public Key. This process has been detailed in 3.12.1. Therefore, in this section, we will focus only on the procedure for verifying the certificate and extracting the public key of the ICC Public Key card.
After successfully completing the verification of the Issuer Public Key Certificate (Tag '90') and extracting the Issuer Public Key from it, the terminal proceeds to the procedure for verifying the public key certificate of the ICC Public Key Certificate (Tag '9F46') and recovering the ICC Public key. Key according to the following algorithm:
- 1) ICC Public Key Certificate element is considered as a digital signature calculated using the private key of the card issuer. The Issuer Public Key is used to perform standard digital signature checks described earlier in clause 3.11.1. If at least one of the standard checks fails, the dynamic card authentication is considered to have failed;
- 2) during the verification of the digital signature at the previous step, the data shown in Table 1 is restored. 3.16. Additional checks are performed for the recovered data:
- certificate validity period - the current date should not exceed the certificate validity period;
- Certificate Format - must be equal to '04'h;
- equality of the Application PAN element recovered from the ICC Public Key Certificate and the Application PAN element (Tag '5A') read by the terminal among the IPC application data;
- the fact that the terminal supports an asymmetric encryption algorithm, the type of which is determined by the ICC Public Key Algorithm Indicator value;
- 3) if at least one of the listed checks is unsuccessful, it is considered that the dynamic authentication of the card has failed;
- 4) if all signature checks are successful, then it is considered that the verification of the card's public key certificate has been completed successfully. In this case, the public key module of the ICC Public Key card is obtained as a concatenation of (N, - 42) bytes of the ICC Public Key field, recovered from the Issuer Public Key Certificate, and (N IC - N, + 42) bytes of the ICC Public Key Remainder element ( Tag '9F48', this data object is present on the card if the difference between the lengths of the modules of the issuer's public key and the card's public key is less than 42 bytes).
After recovering the public key of the ICC Public Key, you can proceed to the actual procedure of dynamic card authentication.
Dynamic Data Authentication (DDA)
The terminal starts the implementation of the Dynamic Data Authentication (DDA) method by finding the Dynamic Data Authentication Data Object List (DDOL) object among the data read on the card, the tag of which is' 9F49'h. The DDOL object contains a list (tags and lengths) of those data objects that are required by the card to form the Terminal Dynamic Data field, which is part of the data signed by the card (see Table 3.18). Note that in accordance with the EMV standard, in DDOL, as in any other list of Data Object List, for example, PDOL, CDOL1, CDOL2, only tags of primitive data objects can be present. The presence of a composite object in the list is not a fatal error. In this case, in accordance with section 5.4 of book 3 of the EMV 4.2 specifications, the number of bytes corresponding to the length of the composite data object is placed in the Terminal Dynamic Data field,
The Terminal Dynamic Data field is formed in accordance with the rules described in section 5.4 of book 3 of the EMV 4.2 specifications, as a concatenation of the Value fields of all data objects whose tags are listed in DDOL. The Value fields are taken in the order of their corresponding tags in the DDOL list.
The only required data item in DDOL is the Unpredictable Number object (Tag '9F37', binary data format, size 4 bytes). An example of the DDOL structure is shown in table. 3.17.
Tab. 3.17. DDOL example
| Meaning | Tag | Availability | Length, bytes | Format |
| Unpredictable Number | '9F37' | M | 4 | B |
| Terminal ID | '9F1C' | O | eight | an8 |
| Terminal country code | '9F1A' | O | 2 | nz |
| Transaction Date | '9A' | O | 3 | pb |
If the card does not contain a DDOL object, then the terminal forms the Terminal Dynamic Data field in accordance with the DDOL-Default object defined by the payment system and stored on the terminal.
DDA authentication is considered DDA Failed if:
- the card does not contain DDOL and the terminal does not contain DDOL-Default;
- DDOL object does not contain Unpredictable Number;
- the card does not contain DDOL, and the DDOL-Default terminal does not contain the Unpredictable Number.
Having received the DDOL object from the terminal, the card generates the Terminal Dynamic Data field, as well as other fields defined in table. 3.18.
MasterCard to J
Tab. 3.18. Data signed by card in case of DDA
| Field name | Length, bytes | Description | Format |
| Signed Data Format | 1 | Value '05'h | b |
| Hash Algorithm Indicator | 1 | Identifies the hashing algorithm; in the current implementation, EMV takes the value 01h, corresponding to the SHA-1 algorithm | b |
| ICC Dynamic Data Length | 1 | Length of dynamic data in bytes Ldd | b |
| ICC Dynamic Data | Dynamic data generated by the card or stored on the card | - | |
| Pad Pattern | Njc ~ L dd - 25 | (N IC - L dd - 25) bytes filled with 'BB'h value | b |
| Terminal Dynamic Data | Variable | Concatenation of DDOL-Defined Data Items | - |
One of the signed data fields contains an ICC Dynamic Data element. The size of this element is L DD bytes and satisfies the inequalities O - L dd <N IC - 25. The ICC Dynamic Data element consists of an ICC Dynamic Number Length element of 1 byte and an ICC Dynamic Number element (IDN, Tag '9F4C') of size 2 -8 bytes. The ICC Dynamic Number data element, as well as the DAC element encountered in the description of static card authentication, is used to confirm that the terminal has performed the card authentication procedure (in this case, dynamic card authentication).
The choice of the method for generating the IDN value is completely delegated to the card issuer. In practice, the IDN value is most often calculated as a function of the number of the current PBX transaction (Application Transaction Counter, Tag '9F36') - As a function, usually (for example, in the M / Chip 4 specifications) the 3DES algorithm is used with a specially defined MK card key IDN :
IDN = DES3 (MK 1dn ) [(ATC AND '00' || '00' || '00' || '00' || '00' || '00')].
Note that for a more reliable "binding" of the ICC Dynamic Number value to the current transaction when calculating the IDN, in addition to the PBX transaction number, we would like to use the random Unpredictable Number generated by the terminal during the operation. However, in general, it is not possible to use the Unpredictable Number value to calculate the IDN. This is because the random Unpredictable Number presented to the card by the terminal in the command
INTERNAL AUTHENTICATE is not valid for IDN calculation because the card issuer does not receive this number and therefore cannot verify the IDN value. The issuer receives the value of the last random number sent to the card in the GENERATE AC command. However, this value is not known to the card (except in the case of CDA authentication) at the time of the card authentication procedure (the GENEARTE AC command is executed after offline dynamic card authentication, except in the case of CDA). Hence it follows that in general it is not possible to use the Unpredictable Number value to calculate IDN.
After all the fields of the table. 3.18 are prepared with the card, the card encrypts the data of this table with its secret key (ICC Private Key) and sends the resulting Signed Dynamic Application Data result to the terminal in the data field of the response to the INTERNAL AUTHENTICATE command.
From this moment, the terminal starts checking the received Signed Dynamic Application Data value. Verification is performed using the ICC Public Key. To check the Signed Dynamic Application Data value, the terminal:
- retrieves the public key of the payment system certification authority (using the Certification Authority Public Key Index (Tag '8F') and RID);
- verifies the Issuer Public Key Certificate and restores the Issuer Public Key using it;
- verifies the ICC Public Key Certificate and recovers the ICC Public Key.
- 1) first, standard checks of the digital signature of table data are performed. 3.18 (the length of the signature is checked, the signed data is restored, and the header and end, as well as the value of the hash function, are checked in them);
- 2) then a special check of the Signed Data Format element is performed, which must be equal to '05'h.
Combined DDA / Application Cryptogram Generation (CDA)
The CDA method not only verifies the integrity of important static application data and the authenticity of the card, but also ensures the integrity of critical data circulating between the card and the terminal. Implementing this card authentication method requires that it be supported by both the card and the terminal.
This card authentication method is not used if the card decides to generate an Application Authentication Cryptogram (AAC). To implement the CDA method, the CDOL1 and CDOL2 data objects must contain the tag and the length of the Unpredictable Number data object, which is a random number generated by the terminal. According to section 6.6.1 of Book 2 of the EMV 4.2 specifications, if at least one of these objects does not mention the Unpredictable Number element, CDA authentication is considered to be failed and the card must require completion of the operation with an AAC cryptogram (authorization denial).
Requiring the presence of an Unpredictable Number object (Tag '9F37') in both CDOL1 and CDOL2 lists ensures that the card receives a random number from the terminal and that the card can generate a cryptogram and generate a Signed Dynamic Application Data item. This requirement is not related to considerations of improving the safety of the operation, but is functionally necessary.
Indeed, when using the SDA and DDA methods, in the case when the CDOL2 list does not mention the Unpredictable Number object, as a cryptogram generated by the card in response to the second GENERATE AC command, the card can offer the cryptogram calculated in response to the first AC GENERATE command. The storage of the ARQC cryptogram value by the card is still necessary, since this cryptogram is used to authenticate the issuer (for ARPC verification regardless of the method used to calculate ARPC), and ARQC is usually used to output session keys used to ensure data integrity and confidentiality in Issuer Script commands Processing.
In the case of using the CDA method, it is not enough to know the meaning of the cryptogram. The card must also remember the random number used to generate the cryptogram. This is due to the fact that when using CDA, the same random number is used both for calculating the cryptogram and for generating the Signed Dynamic data item
Application Data. Since storage by the Unpredictable Number card is not regulated by the EMV standard in any way, in order to be sure that the execution of the second GENERATE AC command will complete successfully, it is necessary to include the Unpredictable Number object as a mandatory element not only in the CDOL1 list, but also in the CDOL2 list.
The emergence of the CDA method (the method first appeared in the EMV 4.0 version) is associated with its ability to ensure the integrity of data circulating between the card and the terminal. It is obvious that the absence of such a mechanism can lead to attacks by fraudsters modifying the data of this information exchange, which in turn can radically change the result of the transaction.
Let's give a simple example. The card decides to reject the transaction offline and in the data field of the response to the GENERATE command, the AC sends a Cryptogram Information Data (CID) data element corresponding to this decision. The fraudster intercepts the card message (how this can be done will be described below) and modifies the CID value in such a way that a decision is declared according to which the transaction is approved by the card. As a result, to the delight of the fraudster, the operation ends with the exact opposite of the decision of the card (card issuer).
In general terms, the essence of the CDA method is as follows. In accordance with CDA, card authentication is performed as part of the procedure for processing the AC GENERATE command, and not before executing this command, as in the case of card authentication using SDA and DDA methods. Since it is during the execution of the GENERATE AC command between the card and the terminal that the most critical transaction data are exchanged, when implementing a special mechanism, it is possible to simultaneously perform dynamic card authentication and ensure the integrity of critical transaction data. This combination of card authentication and transaction data integrity is implemented in the CDA method.
Table 3.19 shows the data signed by the card during the CDA authentication procedure.
Obviously, the L DD value satisfies the inequalities 0 <L DD <N IC - 25.
Comparison of table. 3.18 and 3.19 show that the external difference between the signed data in the DDA and CDA methods lies only in the fact that in the second case Terminal Dynamic Data degenerates into a mandatory data element Unpredictable Number, which is a random number generated by the terminal. However, this is an apparent similarity. In fact, the difference between the signed data lies in the different structures. 3.19. Data signed by card in case of CDA
| Field name | Length, bytes | Description | Format |
| Signed Data Format | 1 | Value '05'h | B |
| Hash Algorithm Indicator | 1 | Identifies the hashing algorithm; in the current implementation, EMV takes the value '01 'h, corresponding to the SHA-1 algorithm | B |
| ICC Dynamic Data Length | 1 | Length of dynamic data in bytes L dd | b |
| ICC Dynamic Data | L-dd | Dynamic data generated by the map | - |
| Pad Pattern | Nic ~ L dd - 25 | (N IC - L dd - 25) bytes filled with 'BB'h value | B |
| Unpredictable Number | 4 | Terminal generated random number | b |
round the ICC Dynamic Data field. In the case of CDA, the structure of the leftmost bytes of the ICC Dynamic Data field is shown in Table 1. 3.20.
Tab. 3.20. 32-38 leftmost bytes of ICC Dynamic Data field in case of CDA
| Field name | Length, bytes | Format |
| ICC Dynamic Number Length | 1 | b |
| ICC Dynamic Number | 2-8 | b |
| Cryptogram Information Data | 1 | b |
| Applied cryptogram TC or ARQC | eight | b |
| Transaction Data Hash Code | twenty | b |
In the case of using CDA, the data field of the response to the AC GENERATE command has the form shown in table. 3.21.
Tab. 3.21. The structure of the data field of the response to the command GENERATE AC
| Name | Tag | Length, bytes | Need |
| Cryptogram Information Data | '9F27' | 1 | M |
| ATC | '9F36' | 2 | M |
| Signed Dynamic Application Data | '9F4B' | N IC | m |
| Issuer Application Data | '9F10' | up to 32 | O |
Card authentication in accordance with the CDA method consists in the terminal verifying the Signed Dynamic Application Data element. Before we consider the procedure for checking this data element, let us dwell on the description of the process of generating the value of the Transaction Data Hash Code data element present in ICC Dynamic Data (see Table 3.20).
To calculate the value of the Transaction Data Hash Code when forming a response to the first GENERATE AC command, the SHA-1 algorithm is used, which is executed on the data below, taken in the following order:
- data fields of objects defined in the Processing Data Object List (PDOL), taken in the same order in which they are listed in PDOL;
- data fields of objects defined in CDOL1, taken in the same order in which they appear in CDOL1;
- the values of the Tag, Length, Value fields of data objects (except for the Signed Dynamic Application Data object) returned by the card in response to the first AC GENERATE command, taken in the same order in which they are returned to the terminal.
- data fields of objects defined in the Processing Data Object List (PDOL), taken in the same order in which they are listed in PDOL;
- data fields of objects defined in CDOL1, taken in the same order in which they appear in CDOL1;
- data fields of objects defined in CDOL2, taken in the same order in which they appear in CDOL2;
- the values of the Tag, Length, Value fields of data objects (except for the Signed Dynamic Application Data object) returned by the card in response to the second AC GENERATE command, taken in the same order in which they are returned to the terminal.
Next, the digital signature of Signed Dynamic Application Data is verified:
- 1) first, standard checks of the digital signature of the data shown in Table 1 are performed. 3.19 (the length of the signature is checked, the signed data is restored and the header and end, as well as the value of the hash function are checked in them);
- 2) further special checks are made:
- Signed Data Format element, which must be equal to '05'h;
- equality of the CID values obtained from the signed data and from the data field of the response to the GENERATE AC command (see Table 3.21);
- equality of the Transaction Data Hash Code values obtained from the signed data and calculated by the terminal independently based on the data values at its disposal used to calculate the Transaction Data Hash Code.
