CDA method for offline data authentication

CDA method

  • The method of offline data authentication, called CDA (Combined Data Authentication), is now the most common for card products. This is the most complex of offline authentication methods, so analyzing a payment application that uses the CDA method can be difficult. In this regard, a description of the operations that the card and terminal must perform in order to provide offline data authentication using the CDA method is provided. The CDA signature (the certificate provided in the Signed Dynamic Application Data object) is generated by the card using a specific algorithm. During the certificate generation process, the following actions are performed. First, The signed Dynamic Application Data certificate data is generated. The data is represented as a fixed-length field, the size of which is equal to the length of the card key (Nic). The field has the following format:
  • Offset
  • Length
  • Content
  • The title of the certificate (0x6A).
  • Format ID (0x05)
  • The identifier of the hashing algorithm (0x01 – SHA1)
  • Length of dynamic data in bytes (38). In the table, dynamic data is highlighted in color.
  • The length of the ICC Dynamic Number (8)
  • ICC Dynamic Number
  • Cryptogram Information Data (CID)
  • The cryptogram (TC or ARQC)
  • Transaction Data Hash Code
  • Nic-63
  • Bytes with the value 0xBB
  • Nic-21
  • Dynamic Application Data Hash
  • Nic-1
  • ID end of certificate (0xBC)

You need to provide a few explanations for the data elements used by the payment application to generate the certificate.

  1. ICC Dynamic Number is a cryptographic function from the ATC value that is defined by the developer of the payment application.
  2. Transaction Data Hash Code-the value of the SHA1 hash function for concatenating the following data elements:
    ▪ values of elements specified in PDOL1
    ▪ values of elements specified in CDOL1
    ▪ values of elements specified in CDOL2 (only for the second GENERATE AC command – this field is omitted for the first GENERATE AC command)
    ▪ a Cryptogram Information Data object with tag 9F27 and length 1, an ATC object with tag 9F36 and length 2, and an Issuer Application Data object with tag 9F10 and length 322 3. Dynamic Application Data Hash-value of the SHA1 hash function for concatenating the following data elements:
    ▪ format ID (0x05)
    ▪ the ID of the hashing algorithm (0x01)
    ▪ the length of the dynamic data in bytes (38)
    ▪ dynamic data ▪ bytes with the value 0xBB (NIC – 63 length)
    ▪ 4-byte random terminal number passed to the card in the CDOL1 or CDOL2 list

The prepared data is signed (encrypted) on the card’s secret key (ICC Private Key – Sicc) using the RSASPRV (Data, Sicc) formula, resulting in the Signed Dynamic Application Data certificate. After receiving the Signed Dynamic Application Data certificate from the card, the terminal performs the following steps to verify the provided certificate (card authentication).

  1. Checks the length of the provided certificate (it must be equal to the length of the ICC Public Key – Nic module).
  2. Decrypts the certificate on the card’s public key (ICC Public Key – Picc) using the RSARPUB (Certificate, Picc) formula.
    ▪ If the PDOL list is not used, the field must be omitted.
    ▪ These are objects that are returned in response to the GENERATE AC command in the order in which they are presented in the response (except for the Signed Dynamic Application Data object).
  3. Checks the certificate end ID (must be 0xBC), the certificate header (must be 0x6A) , and the format ID (must be 0x05).
  4. Compares The cryptogram Information Data from the certificate with The cryptogram Information Data value returned by the GENERATE AC command.
  5. Calculates the Dynamic Application Data Hash using the same algorithm as the card and compares the resulting value with the value defined in the certificate.
  6. Calculates the Transaction Data Hash Code using the same algorithm as the card, and compares the resulting value with the value defined in the certificate.
    If any of these checks are not performed, it is considered that the card authentication failed.

Example of a Protocol
This section provides an example of a payment application research Protocol that meets MasterCard specifications. It is recommended to pay attention to the following features of the study:
▪ the transaction was completed in contact mode
▪ offline authentication of card data using the CDA method was successfully completed
▪ the verification method of the cardholder “Presenting a pin Code for transmitting it to the Issuer” was performed, since the presentation of the PIN code to the card failed due to an incorrect PIN code value
▪ GET DATA commands are issued to get information about payment application objects
▪ the first GENERATE AC command returned the ARQC cryptogram and emulated online processing
▪ a second GENERATE AC command was issued to complete the transaction.
▪ the transaction was completed in contact mode
▪ offline authentication of card data using the CDA method was successfully completed
▪ the verification method of the cardholder “Presenting a pin Code for transmitting it to the Issuer” was performed, since the presentation of the PIN code to the card failed due to an incorrect PIN code value
▪ GET DATA commands are issued to get information about payment application objects
▪ the first GENERATE AC command returned the ARQC cryptogram and emulated online processing
▪ a second GENERATE AC command was issued to complete the transaction.