Appearance of CDA methods in EMV 4.0

The static authentication procedure is performed in three steps:
The terminal uses the certificate Authority Public Key Index and RID data read from the card (the first 5 bytes of AID) to select the public key of the certification authority payment system certification center stored in it, which corresponds to the certificate Authority private key used to calculate the Issuer’s public key certificate. If the public key of the payment system is not found, it is considered that the static authentication of the card failed (SDA failed).
The Issuer’s public key certificate is verified.
The signature of critical card data is checked.
First, let’s take a closer look at step 2. Verification of the Issuer’s public key certificate and its recovery is performed by the terminal according to the following rules:
the issue 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 issue Public Key system defined by the terminal at the first step of the static authentication algorithm. Then the standard digital signature checks described earlier in clause 3.11.1 are performed. If at least one of the standard checks fails, the static authentication of the card is considered to have failed;
during the previous step, the data listed in the table is restored. 3.12. Additional checks are performed for the restored data:
the validity of the certificate;
the format of the certificate (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 set of data is not included in the revocation list of the Issuer Public Key Certificate. This check is optional.
If at least one of the listed checks failed, it is considered that the static authentication of the card failed;
if all signature checks were completed successfully, it is considered that verification of the Issuer’s public key certificate was completed successfully. In this case, the Issuer Public Key is restored as a concatenation of the leftmost digits of this key extracted from the Issuer Public Key Certificate (the latter minus the ending E=’BC’h (N[A – 36) bytes recovered from the Issuer Public Key Certificate), and (L/x-Nu+ 36) bytes of the Issuer Public Key Remainder element.
After restoring the Issuer’s public key, you can proceed to verifying the signature of critical card data Signed Static Application Data (step 3 of the authentication algorithm).
Verification of the signature of critical card data is performed according to the following rules:
first, standard signature checks are performed for the data specified in table. 3.13. Checks are performed on the Signed Static Application Data object (see clause 3.11.1)-the length of the signature, the header and ending of data recovered from Signed Static Application Data, and the value of the hash function are checked;
next, a special check is performed for the “Signed Data Format” element of the data restored in the previous step, which must be equal to ‘ 03’h;
the card is considered to be statically authenticated successfully if and only if all the listed checks were 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’.

Dynamic card authentication provides not only verification of the integrity of critical card data, but also confirms the authenticity of the card at the level of cryptographic stability of the asymmetric encryption algorithms used on the card (the fact that this card was issued by an Issuer authorized by the payment system). To implement this authentication method, a three-level PKI structure is used (Fig. 3.12). As you can see from the figure, dynamic authentication methods use the public/private key pair of the card itself. The length of the card public key module, expressed in bytes, will be denoted by NJC

There are two methods of dynamic card authentication:
DDA (Dynamic Data Authentication dynamic authentication);
CDA (Combined Dynamic Data Authentication/Application Cryptogram Generation).
The essence of these methods is that the terminal generates a random number that is passed to the card along with some other signature data. The card returns the signed data to 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’s key are correct, it concludes that the card is authentic. Indeed, since the card did not know in advance the random number offered to it by the terminal, the fact that the signature was correct means that the signature was made by the card. This in turn means that the card is the bearer of a secret-the private key (which was used to create the signature) corresponding to the public key, the validity of which is verified in the three-level PKI infrastructure.
Note that the structure of the card’s public key certificate is such that when checking this certificate, static authentication of the card is automatically performed, i.e. the integrity of critical card data is checked.
For the implementation of methods for dynamic authentication of the card it is necessary to card stored the following data elements:
Certification Authority Public Key Index (Tag ‘8F’);
Issuer Public Key Certificate (Tag’90’);
Issuer Public Key Remainder (Tag ’92’), present if the length difference between the system’s public key and the Issuer’s public key modules is less than 36 bytes;
Issuer Public Key Exponent (Tag ‘9F32’);
Signed Static Application Data (Tag ’93’);
ICC Public Key Certificate (Tag ‘9F46’);
ICC Public Key Remainder (Tag ‘9F48’), present if the length difference between the Issuer’s public key and the card’s public key modules is less than 42 bytes;
ICC Public Key Exponent (Tag ‘9F47’);
ICC Private Key.
The list below shows that it differs from the similar list for static authentication only by the last four data elements that define the public and private keys of the card.
In accordance with the EMV 4.1 standard, the inequality NK< L/,< / VM < 248 is fulfilled. In fact, the length of the card’s and Issuer’s public key modules is always strictly less than 248 bytes, and if the CDA method is used, the length of the card’s public key module may not exceed 205 bytes (see clause 3.16.3).
The data used to generate the ICC Public Key certificate and signed with the Issuer’s private key is shown in table.3.16.
In the dynamic authentication procedure, just as in the static authentication procedure, one of the steps is used to verify the certificate and extract the Issuer’s public key. This process was described in detail in clause 3.12.1. We will focus only on the procedure for verifying the certificate and extracting the public key of the ICC Public Key card.
Assuming successful completion of verification of the Issuer Public Key Certificate (Tag ’90’) and extraction of the Issuer’s public key from it, the terminal begins the procedure for verifying the public key certificate of the ICC Public Key Certificate (Tag ‘9F46’) and restoring the key of the ICC Public Key card in accordance with the following algorithm:
the ICC Public Key Certificate element is considered as a digital signature calculated using the card Issuer’s private key. The standard digital signature checks described earlier in clause 3.11.1 are performed using the Issuer’s public key. If at least one of the standard checks fails, dynamic card authentication is considered to have failed;
during digital signature verification, the data shown in the table is restored in the previous step. 3.16. Additional checks are performed for the restored data:
the validity of the certificate;
the format of the certificate (Certificate Format) — must be equal to ’04’h;
equality of the Application PAN element restored from the ICC Public Key Certificate and the element

ICC Public Key data signed by the Issuer

Name of the Length field,
byte Description Format
Certificate
Format 1 ‘ 04’h b
PAN 10 the pan card Number, supplemented on the right with the characters ‘F’h’ 20
Certificate Expiration Date 2 date (month and year) after which the certificate is invalid P4
Certificate Serial Number 3 a Binary number unique to this certificate assigned by Issuer b
Hash Algorithm Indicator 1 Identifies the hashing algorithm; in the current implementation, EMV takes the value ‘ Ol’h corresponding to the SHA-1 b algorithm
ICC Public Key
Algorithm
Indicator 1 Identifies the digital signature algorithm; it usually takes the value ‘ Ol’h corresponding to the RSA b algorithm
ICC Public Key Length 1 the Length of the card public key module in bytes – NIC.
ICC Public Key Exponent Length 1 The length of the card’s public key exponent in bytes b
ICC Public Key or its leftmost digits Nr 42 If NIC/V-42, this field contains the N-42 most significant bytes of the card’s public key.
ICC Public Key Reminder 0 or NK-Nt+42 this field is present if A/; C>L / -42 and consists of A/; g-A/;+42 least significant bytes of the card’s public key.
ICC Public Key Exponent 1 or 3 Value 3 or +1 b
Static Data to be Authenticated
critical data, the integrity of which is guaranteed.

Application PAN (Tag ‘5A’), read by the terminal from the MP memory To;
— the fact that the terminal supports an asymmetric encryption algorithm, the type of which is determined by the value of the public Key Algorithm Indicator;
if at least one of the listed checks failed, dynamic card authentication is considered to have failed;
if all signature checks were completed successfully, it is considered that verification of the card’s public key certificate was completed successfully. In this case, the ICC Public Key is restored as a concatenation of the leftmost digits of this key extracted from the CS Public Key Certificate (the latter minus the ending E=’BC (L/;-42) bytes recovered from the cs public Key Certificate), and (N]C – N{+ 42) bytes of the CS Public Key Remainder element (this data object is present on the card if the difference in the lengths of the Issuer’s public key modules and the card’s public key is less than 42 bytes). Note that since the data signed in the card key certificate contains the Static Data to be Authenticated element, certificate verification automatically includes static card authentication (checking the integrity of critical data in the card application).
After restoring the public key of the ICC Public Key card, you can proceed to the dynamic card authentication procedure itself.
The terminal starts implementing the Dynamic Dynamic Data method
Data Authentication (DDA) starts with the fact that among the Authentication (DDA) data read on the card, it finds a Dynamic Data Authentication Data Object List (DDOL) object with a tag equal to ‘9F49’. The DDOL object contains a list (tags and lengths) of the data objects that the card requires 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, DDOL, as in any other Data Object List, such as PDOL, CD0L1, CD0L2, can only contain tags of primitive data objects. 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.1 specifications, the Terminal Dynamic Data field contains the length of the composite data object and the corresponding number of bytes consisting of only zeros.
The Terminal Dynamic Data field is formed according to the rules described in section 5.4 of Book 3 of the EMV 4.1 specifications, as a concatenation of the Value fields of all data objects whose tags are listed in DD0L. the Value Fields are taken in the order of their corresponding tags in the DD0L list.
The only required data element in DD0L is the Unpredictable Number object (Tag ‘9F37’, binary data format, size 4 bytes). An example of the DD0L structure is shown in table. 3.17.

If the card does not contain a DDOL object, the terminal generates the Terminal Dynamic Data field in accordance with the DDOL-Default object defined by the payment system and stored on the terminal.
The DDA method is considered failed if:
the card does not contain DD0L and the terminal does not contain DDOL-Default;
the DD0L object does not contain an Unpredictable Number;
the card does not contain DDOL, and the terminal’s DDOL-Default does not contain an Unpredictable Number.
Data values defined in the DDOL list are passed to the card in the data field of the INTERNAL AUTHENTICATE command.
After receiving the DDOL object from the terminal, the card generates the Terminal Dynamic Data field, as well as other fields defined in the table.3.18.
Table 3.18
Data signed by the card, in the case of DDA

Name of the Length field,
byte 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 Olh value corresponding to the SHA-1 algorithm.
ICC Dynamic Data Length 1 the Length of dynamic data in bytes b
ICC Dynamic Data Dynamic data generated by the card or saved on the card –
Pad Pattern 4-4r25 25) bytes filled with the value ‘ BB’h
Terminal
Dynamic
Data Of Changes concatenation of data elements defined by DD0L

In one of the fields contains data that will be signed a new element of the ICC Dynamic Data. The size of this element is equal to LDD bytes and satisfies the inequalities 0 < LDD< NK-25. The ICC Dynamic Data element consists of a 1-byte CS Dynamic Number Length element and a 2-8-byte CS Dynamic Number element (IDN, Tag ‘9F4C’). The dynamic Number CS data element, as well as the DAC element encountered in the description of static card authentication, is used to confirm that the terminal has completed the card authentication procedure (in this case, dynamic card authentication). The choice of how to determine the IDN is fully delegated to the card Issuer. In practice, the IDN value is most often calculated as a function of the current PBX transaction number (Application Transaction Counter, Tag ‘9F36’). As a function, usually (for example, in the m/Chip 4 specifications)the 3DES algorithm is used with the MK/0L card key specially defined for this purpose/:
IDN=DES3(MK/d/v) [(ATC||’00’||’00’||j00’||j00’| I’O’h’o’)].
Note that for more “binding” of the ICC Dynamic Number value to the current transaction, in addition to the PBX transaction number, we would like to use a random number Unpredictable Number generated by the terminal. However, in General, it is not possible to use the value Unpredictable Number to calculate the IDN. This is because the number Unpredictable Number is passed to the card only in the data field of the GENERATE AC command, and the calculation of the ICC Dynamic Number is performed during the card authentication procedure, which in all cases, except for the case of CDA, is performed before the GENERATE AC command is processed. Note that when calculating the IDN number, the same random number that is used for calculating the cryptogram must be used, and, for example, not a random number generated by the terminal during dynamic card authentication. This is due to the fact that in the authorization request and clearing message, the last random number offered to the card by the terminal at the time of message formation is mandatory for submission. It follows that a random number presented to the card by the terminal in the INTERNAL AUTHENTICATE command is not suitable for calculating the IDN.
After all the fields in the card is prepared, the card encrypts the data of this table with its secret key (ICC Private RSA Key) and the resulting Signed Dynamic Application Data is sent to the terminal in the data field of the response to the INTERNAL AUTHENTICATE command.
At this point, the terminal begins checking the received Signed Dynamic Application Data element. Verification is performed using the public key of the CS card. To check the Signed Dynamic Application Data terminal:
retrieves the public key of the payment system certification authority (using the Certification Authority Public Key Index and RID);
verifies the Issuer’s public key certificate and extracts the Issuer’s public key from it;
verifies the public key certificate of the CS public Key card and extracts the public key of the CS Public Key card.

After all the above steps are completed successfully, the digital signature of Signed Dynamic Application Data is checked:
first, the standard checks for the digital signature of the table data are performed.3.18 (the length of the signature is checked, the signed data is restored, and the header and ending are checked, as well as the value of the hash function);
next, a special check is performed for the Signed Data Format element, which must be equal to ‘ 05’h.
The card is considered successfully authenticated if and only if all the listed checks were completed successfully.
In this case, the terminal stores the IDN value as a data object with the Tag ‘9F4C’.
Using the CDA method the non Combined DDA is performed/
only validating the integrity of important cryptographic data of the card and its authenticity, Generation (CDA)
but it also ensures the integrity of critical data that circulates between the card and the terminal. To implement this method of card authentication, it must be supported by both the card and the terminal.
This method of card authentication is not used if the card decides to generate the Application Authentication Cryptogram (AAC). To implement the CDA method, CD0L1 and CD0L2 data objects must contain the tag and the length of the Unpredictable Number data element, which is a random number generated by the terminal. In accordance with section 6.6.1 of Book 2 of the EMV 4.1 specifications, if at least one of these objects does not mention the Unpredictable Number element, the CDA authentication is considered failed and the card must require completion of the operation with the AAC cryptogram (authorization denial).
The requirement to have an Unpredictable Number object (Tag ‘9F37’) in both CD0L1 and CD0L2 lists guarantees that the card receives a random number from the terminal and that the card can perform the cryptogram generation procedure and generate the Signed Dynamic Application Data element. This requirement is not related to reasons for improving the security of the operation.
Indeed, when using the SDA and DDA methods, if the CD0L2 list does not mention the Unpredictable Number object, the card can offer the cryptogram calculated in response to the first GENERATE AC command as the cryptogram generated by the card in response to the second GENERATE AC command. Storing the ARQC cryptogram is not burdensome for the card, since this cryptogram is used for Issuer authentication (ARPC verification regardless of the method used for calculating ARPC), and is also often used for output of session keys used to ensure data integrity and confidentiality in Script Processing commands. If you use the CDA method, it is not enough to have a cryptogram, you must also have a random number that was used when forming it. This is because when using CDA, a random number is also used to generate the Signed Dynamic Application Data element. Since the storage of an Unpredictable Number by the EMV standard is not regulated by any standard, in order to be sure that the second GENERATE as command will be executed successfully, you must include the object as a mandatory element not only in the CD0L1 list, but also in the CD0L2 list.
The appearance of the CDA method (the method appeared only in EMV 4.0) is related to its ability to ensure the integrity of data that circulates between the card and the terminal. It is obvious that the absence of such a mechanism can lead to attacks by fraudsters who modify the data of this information exchange, which in turn can dramatically change the result of the transaction.
Here is a simple example. The card makes a decision to reject the transaction and sends the Cryptogram Information Data (CID) element corresponding to this decision in the data field of the response to the GENERATE command. The fraudster intercepts the card message (we will explain how this can be done later) and modifies the CID field so that the decision is declared that the card transaction is approved. As a result, to the delight of the fraudster, the operation ends with the opposite result to the Issuer’s decision.
In General terms, the essence of the CDA method is that card authentication is performed not as a separate stage of transaction execution, but as an element of the GENERATE AC command execution. Since it is when executing this command that the most critical transaction data is exchanged between the card and the terminal, when implementing a special mechanism, you can simultaneously perform dynamic authentication of the card and ensure data integrity. Indeed, both of these tasks are solved using cryptographic methods. Therefore, the mechanism must combine the dynamic authentication procedure, which always uses cryptography, and the processing of THE generate AC command. This combination is what the CDA method does.

Data signed by the card, in the case of CDA
Signed Data Format 1 Value ‘ 05’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.
ICC Dynamic Data Length 1 the Length of dynamic data in bytes
4 ” b
ICC Dynamic Data LDD Dynamic data generated by the card
Pad Pattern (A^r/jj-25) bytes filled with the value ‘ BB’h
Unpredictable Number 4 a Random number generated by the terminal b

Obviously, the value of LDD satisfies the inequalities ABOUT < LDD<NIC-25. Comparison table. 3.18 and 3.19 shows that the external difference between the signed data in the cases of DDA and CDA is only that in the second case, Terminal Dynamic Data degenerates into
required data element Unpredictable Number, which is a random number generated by the terminal. However, this is an apparent similarity. In fact, the difference between signed data is the different structure of the ICC Dynamic Data field. In the case of CDA, the structure of the leftmost bytes of the ICC Dynamic Data field

32-38 leftmost bytes of the ICC Dynamic Data field in the case of CDA
FIELD name Length, byte Format
ICC Dynamic Number Length 1 b
ICC Dynamic Number 2-8 b
Cryptogram Information Data 1 b
The application cryptogram TC or ARQC 8 b
Transaction Data Hash Code 20 b

Structure of the data field in the response to the GENERATE command.
Tag name Length, bytes Need
Cryptogram Information Data ‘9F27’ 1 M
PBX ‘9F36’ 2 m
Signed Dynamic Application Data ‘9F4B1 m
Issuer Application Data •9F10′ UP to 32 m

Card authentication in accordance with the CDA method consists of checking The signed Dynamic Application Data element by the terminal. Before we consider the procedure for checking this data element, we will stop at the description of the process of forming the Transaction Data Hash Code element present in ICC Dynamic Data (see table. 3.20).
To calculate the Transaction Data Hash Code in the case of generating a response to the first GENERATE command, the SHA-1 algorithm is used, which is performed on the following data taken in the specified order:
data fields of objects defined in the Processing Data Object List (PDOL), taken in the same order as they are listed in PD0L;
data fields of objects defined in the CD0L1 list, taken in the same order as they are listed in CD0L1;
the Tag, Length, and Value values of data objects returned by the card in response to the first GENERATE AC command are taken in the same order as they are returned to the terminal, with the exception of the Signed Dynamic Application Data object.
To calculate the Transaction Data Hash Code in the case of generating a response to the second GENERATE command, the SHA-1 algorithm is used, performed on the data below, taken in the specified order:
data fields of objects defined in the Processing Data Object List (PDOL), taken in the same order as they are listed in PDOL;
data fields of objects defined in the CD0L1 list, taken in the same order as they are listed in CD0L1;
data fields of objects defined in the CD0L2 list, taken in the same order as they are listed in CD0L2;
the Tag, Length, and Value values of data objects returned by the card in response to the second GENERATE AC command are taken in the same order as they are returned to the terminal, with the exception of the Signed Dynamic Application Data object.
To verify the Signed Dynamic Application Data element, the terminal must first, as in the case of DDA, verify the Issuer’s public key certificate and restore the Issuer’s public key from the certificate, verify the card’s public key certificate and restore the card’s public key from the certificate. These procedures were previously described in detail and are not provided here.
Then the digital signature is checked Signed Dynamic Application Data:
1) first, standard digital signature checks are performed for the data shown in table. 3.19 (length is checked signatures, the signed data is restored and the header and ending are checked, as well as the value of the hash function);
2) then special checks are made:
the Signed Data Format element, which must be equal to y05’h;
equality of the CID values obtained from the signed data and from the data field of the response to the GENERATE command;
equality of Transaction Data Hash Code values obtained from signed data and calculated by the terminal independently based on the available data values used for calculating the Transaction Data Hash Code.
The card is considered successfully authenticated if and only if all the listed checks were completed successfully. In this case, the terminal stores the IDN value as a data object with the Tag ‘9F4C’.

RS code encryption when checking it in off-line mode
For secure transfer of the PIN code value from the terminal to the card, asymmetric encryption is obviously used (currently the RSA algorithm). The encryption key can be either the public key of the card used for card authentication, or the public key of a special pair of PIN Encryption keys (PE) Private/Public Key intended for encrypting/decrypting the PIN code value. However, the PIN Encryption Public Key Certificate (Tag “9F2D’) has the same structure as the card public key certificate used for card authentication, except that the Static Data to be Authenticated element is not used when creating the certificate.
The PIN Encryption Public Key Certificate is created by signing the data card Issuer’s private key