Restoring the Issuer’s public key

For a number of actions with the payment application (performing offline data authentication, presenting an encrypted PIN code), the terminal must have a public card key. To get the card’s public key from the payment application data, the terminal must first restore the Issuer’s public key from the Issuer’s public key certificate signed with the certification Authority (CA) secret key. The following is an algorithm for this process. The terminal performs the following steps to verify the Issuer’s public key certificate. 1. Checks the length of the Issuer’s public key certificate (it must be equal to the length of the CA – Nca public key module). 2. Decrypts the Issuer’s public key certificate on the CA public key (Pca) using the RSARPUB (Certificate, Pca) formula. The decrypted certificate must look like this:

  • Length
  • Content
  • The title of the certificate (0x6A).
  • Format ID (0x02)
  • Issuer ID (from 3 to 8 of the leftmost PAN digits, supplemented if necessary with hexadecimal F digits on the right)
  • Date of expiry of the certificate (n4 due MMYY)
  • Certificate serial number
  • The identifier of the hashing algorithm (0x01 – SHA1)
  • ID of the certificate generation algorithm (0x01 – RSA)
  • Length of the Issuer’s public key module (Ni)
  • Length of the Issuer’s public key exponent (1-3)
  • Nca-36
  • Nca-21
  • Hash function value for the Issuer’s public key and related information
  • Nca-1
  • ID end of certificate (0xBC)
  • The highest (leftmost) bytes of the Issuer’s public key module

If Ni <= Nca-36, the certificate contains the entire public key module of the Issuer, supplemented on the right by 0xbb bytes (the number of bytes of the extension is equal to Nca-Ni-36). Otherwise, the certificate contains the Nca-36 – byte of the Issuer’s public key module (the remainder of the Issuer’s public key is entered in the Issuer Public Key Remainder object).
▪ Checks the certificate end ID (must be 0xBC), the certificate header (must be 0x6A) , and the format ID (must be 0x02).
▪ Gets the value of the hash function using the SHA1 algorithm to concatenate the following data elements:
▪ format ID (0x02)
▪ the ID of the Issuer
▪ the date of expiry of the certificate
▪ serial number of the certificate
▪ the ID of the hashing algorithm (0x01)
▪ ID of the certificate generation algorithm (0x01)
▪ length of the Issuer’s public key module (Ni)
▪ length of the Issuer’s public key exponent (1-3)
▪ the Issuer’s public key module (the highest bytes of the Issuer’s public key module from the certificate, followed by the lowest bytes of the module from the Issuer’s Public Key Remnant data object received from the card, or the Issuer’s public key module from the certificate, padded to the right with 0xbb bytes, if the entire module fits in the certificate)
▪ Exhibitor of the Issuer’s public key

Checks that the Issuer ID corresponds to the first digits of the PAN (taking into account that the Issuer ID can contain from 3 to 8 of the leftmost digits of the PAN, supplemented, if necessary, by the hexadecimal digits F on the right). Checks that the certificate has not expired. Checks the ID of the certificate generation algorithm (must be 0x01)

If any of these checks are not performed, it is considered that the card authentication failed. Otherwise, the public key certificate is valid and the Issuer’s public key module is extracted from the certificate or obtained by concatenating the higher bytes of the Issuer’s public key module from the certificate and the lower bytes of the module from the Issuer Public Key Remainder data object.

Restoring the card’s public key
To perform offline data authentication and present an encrypted PIN code, the terminal must restore the card’s public key from the card’s public key certificate signed on the Issuer’s secret key. This requires the Issuer’s public key. The procedure for restoring the Issuer’s public key is described in detail in the previous section. After restoring the Issuer’s public key, the terminal restores the card’s public key using its certificate. The terminal performs the following steps to verify the card’s public key certificate.

  1. Checks the length of the card’s public key certificate (it must be equal to the length of the Issuer’s public key module-Ni).
  2. Decrypts the card’s public key certificate on the Issuer’s public key (Pi) using the RSARPUB (Certificate, Pi) formula. The decrypted certificate must look like this. Certificate end ID (0xBC). If Nic <= Ni-42, the certificate contains the entire public key module of the card, supplemented on the right by 0xbb bytes (the number of bytes of the extension is Ni – Nic-42). Otherwise, the certificate contains the Ni-42 senior bytes of the card’s public key module (the remainder of the card’s public key is entered in the ICC Public Key Remainder object)
  3. Checks the certificate end ID (must be 0xBC), the certificate header (must be 0x6A) , and the format ID (must be 0x04).
  4. Gets the value of the hash function using the SHA1 algorithm for concatenating the following data elements:
    ▪ format ID (0x02)
    ▪ Application PAN
    ▪ the date of expiry of the certificate
    ▪ serial number of the certificate
    ▪ the ID of the hashing algorithm (0x01)
    ▪ ID of the certificate generation algorithm (0x01)
    ▪ length of the card’s public key module (Nic)
    ▪ length of the card’s public key exponent (1-3)
    ▪ the card’s public key module (the highest bytes of the card’s public key module from the certificate, followed by the lowest bytes of the module from the ICC Public Key Remainder data object received from the card, or the card’s public key module from the certificate, padded to the right with 0xbb bytes, if the entire module fits in the certificate)
    ▪ Exhibitor of the card’s public key
    ▪ static data that must be authenticated
    (may not be available)
    ▪ for files with SFI in the range from 1 to 10, the record tag (70) and record length are excluded from the authentication process. All other data elements from the record are included.
    ▪ for files with SFI in the range from 11 to 30, the record tag (70) and record length, as well as other data elements, are included in the authentication process.

The static data that must be authenticated is determined by the elements of the AFL list (Application File Locator) in the order in which they appear in the AFL list and are read by the terminal. The data included in the authentication process depends on the Short File Identifier (SFI) file from which the records are read.

After all elements defined by the AFL are included in the static information to be authenticated, the Static Data Authentication Tag List is processed if it is defined in the data read by the terminal using the READ RECORD command. The Static Data Authentication Tag List, if set, can only contain the tag for the Application Interchange Profile (AIP). Thus, if the Static Data Authentication Tag List item is defined, the AIP value is entered at the end of the static data that must be authenticated (the AIP tag and length are not included). Compares the received value to the value specified in the certificate.
▪ Checks that the Application PAN defined in the certificate matches the Application PAN received from the payment application.
▪ Checks that the certificate has not expired.
▪ Checks the ID of the certificate generation algorithm (must be equal to 0x01) If any of the listed checks is not performed, it is considered that offline data authentication failed. Otherwise, the public key certificate is valid and the map public key module is extracted from the certificate or obtained by concatenating the higher bytes of the map public key module from the certificate and the lower bytes of the module from the ICC Public Key Remainder data object.