Encryption algorithms for chip card reading

Data on the card The data that is necessary for the transaction is read by the terminal from the records of the payment application files using the READ RECORD command. But not all the data that the terminal may need is located in the file records. Some data is stored as separate objects and if necessary, the terminal extracts them from the card using the GET DATA command. Security issues the most Important feature of a payment application is the use of cryptographic functions to improve the security of financial transactions. The main tasks for improving the security of financial transactions, solved by the application, are as follows.

1. 1. Provide application authentication on the card (or card authentication). Card authentication refers to the process of proving its authenticity, i.e. the fact that the card is issued by a Bank authorized to issue cards. In the case of an offline transaction, the Issuer fully delegates to the card the function of making a decision on the result of the operation. Obviously, you can only trust the decisions of the card, the authenticity of which is proven. That’s why its reliable authentication is so important. Card authentication is performed by the terminal and (or) the Issuer. In offline operations, card authentication is performed only by the terminal and is called offline authentication. In the case of an online transaction, the card can be authenticated by both the terminal and the Issuer. Card authentication performed by the Issuer is called online.
2. 2. Ensuring the Issuer’s authentication and verification of the integrity of the data sent to them by checking the signatures of the data generated by the Issuer.
3. 3. Guarantee to the Issuer that the cardholder cannot refuse the result of the performed operation. This is ensured by the fact that for each completed transaction, the Issuer receives from the card at its disposal the cryptogram of the application, which is a signature of the most critical data of the transaction. The correspondence of the cryptogram to the transaction data confirms the fact of its execution.
4. 4. Checking the integrity of critical data exchange between the card and the terminal.
5. 5. Ensuring data confidentiality in information exchange between the card and the Issuer, the card and the terminal. 6. Providing a mechanism for reliable verification of the cardholder using offline PIN verification. The payment application implements transaction security functions based on the RSA asymmetric encryption algorithm used in the EMV standard and the DES symmetric encryption algorithm.

First, consider the RSA encryption algorithm. Aside from the RSA terminology, which can sometimes be confusing, asymmetric encryption is based on the fact that there are two keys – public and secret. If the data is encrypted on a public key, it can be decrypted on a secret key and Vice versa. The necessity of using asymmetric algorithms in security procedures due to the fact that the terminal should not have secrets cards (symmetric encryption always involves knowledge exchange participants shared secret). In order for the terminal to use asymmetric card keys to implement security functions, it is necessary to create a PKI-Public Key Infrastructure. PKI-payment system infrastructure in accordance with the EMV standard

The root of the PKI infrastructure is the certification Authority (CA) of the payment system. The certification authority generates RSA key pairs (public and secret) and sends the public keys to the servicing banks for uploading them to the payment system terminals. At the second level of the PKI-infrastructure tree there are certification centers of issuers – participants of the payment system. These centers also generate RSA key pairs and receive public key certificates from the CA. The public key certificate represents the details of the public key (including the public key itself), its validity period, the Issuer’s ID, etc., signed on the secret key of the payment system certification center.
1 Finally, at the lower level of the infrastructure, the public and private keys of the Issuer’s cards are located. The public keys of the cards are signed in the Issuer’s certification center on the secret key of the Issuer’s certification center. In the process of personalization of the payment application, the Issuer’s public key certificates and the card’s public key, as well as the card’s secret key, are written to the card. In order to receive the card’s public key, the terminal reads the Issuer’s and the card’s public key certificates from the card. Then, using the CA public key stored in the terminal, the terminal verifies the validity of the Issuer’s public key certificate.
2 After proving the correctness of the Issuer’s public key certificate, the terminal uses the restored Issuer’s public key to verify the correctness of the card’s public key certificate. If the certificate is correct, the terminal gets access to the public key of the card. The card’s public key is used by the terminal to authenticate the application on the card and encrypt sensitive data sent to the application (for example, a PIN code). Application authentication is performed by verifying the signature of certain data generated by the card on the secret key of the card. If the card signature is correct, it means that it was made by the card’s secret key corresponding to its public key certified by the Issuer. This in turn means that the card was issued by the issuing Bank, the public key of which was certified by the certification center of the payment system. Thus, the fact of issuing the card by the Bank authorized to issue cards of the payment system is proved. To generate application cryptograms, signatures of data transmitted between the Issuer and the card, as well as to encrypt the exchange of EMV for the formation of certificates, the Sign function on the secret key is used. This function encrypts the certificate on a secret key and it can only be decrypted on the public key corresponding to the secret key. The certificate is decrypted on a public key. In EMV terminology, this function is called Recover. As a result of decrypting the certificate, the terminal gets access to the Issuer’s public key, which is stored in the certificate. However, the certificate may not contain the entire Issuer’s public key, but only a part of it. The other part of the key is extracted from a data object called the Issuer Public Key Remainder.

Confidential data between them, using a symmetric algorithm 3DES (ISO 11568-2). In this case, the participants of the information exchange have a common secret-the secret key 3DES. Rather, a set of secret keys, because for security purposes, the payment application and the Issuer use several keys. In fairness, it should be said that the set of secret keys in the payment application is determined by the developer. Therefore, we do not have to talk about any standards. For example, you can see which keys are used in an application created using EMV CCD (Common Core Definitions) specifications: ka key (Application Cryptogram Key) – used to calculate application cryptograms Ki key (MAC Key) – used to calculate data signature (Message Authentication Code-MAC) in script processing commands KC key (Encryption Key) – used to encrypt sensitive data in script processing commands

The Issuer stores only the master keys of the symmetric cryptographic algorithm, which in the process of card personalization are converted (diversified) into unique keys of the payment application (diversification of the Issuer’s master key can be performed in several ways using Application PAN and Application PAN Sequence Number). Thus, each payment application uses a set of unique keys for cryptographic operations. Moreover, the unique payment application key is diversified for each transaction into a session key. To get the session key, use the Application Transaction Counter (ATC), which is a counter that increases with each transaction. As a result, for each transaction, the card and the Issuer use a unique key of a symmetric cryptographic algorithm, which significantly improves security.

Verification of the cardholder Verification of the cardholder is performed in order to establish the fact of identity of the person who received the card from its Issuer (the Bank’s client) with the person performing the transaction on the card. The key data object for cardholder verification is the Cardholder Verification Method (CVM) List object, which is stored on the card. This object defines a list of cardholder verification methods and conditions. One of the main methods of cardholder verification is the PIN verification procedure. Although PIN verification is only one of the possible verification methods, it is widely used because of its reliability and efficiency. There are two different methods for offline PIN verification:

• check the PIN code transmitted to the card in clear form
• verification of the PIN code transmitted to the card in encrypted form

Offline verification of PIN-code always starts with the fact that the terminal issues the GET DATA command to retrieve a data object for the PIN Try Counter. The value of this object is the number of remaining Pin attempts. If the cardholder still attempts to enter the PIN code, the terminal receives from the cardholder the value of its PIN code (4 to 12 digits) and produces the PIN code, the PIN block in an ISO Format 2 If CVM indicated that the PIN code must be presented in clear text, the terminal sends a VERIFY command, a data field which contains the value of the PIN block in an ISO Format 2. When the PIN code is to be presented in encrypted form, the terminal first receives a random number from the card using the GET CHALLENGE command, then generates a PIN certificate that contains the PIN block and the received random number, and encrypts the certificate on the card’s public key. The encrypted PIN certificate is fed to the card as the VERIFY command data. The card compares the received PIN value with the value stored on the card (first decrypting the PIN certificate on the card’s secret key and checking the certificate when necessary). If they match, the Pin code check is considered successful. Each time an incorrect PIN code is presented, the number of remaining attempts to enter the PIN code is reduced by 1 (when zero is reached, the PIN code will be blocked). Online PIN verification has nothing to do with the card. The PIN input device requests the PIN code from the cardholder and encrypts it using a special algorithm, usually using the DUKPT (Derived Unique Key Per Transaction) algorithm. Verification of the cardholder by the terminal is completed at this point, since the value of the PIN code is checked by the Issuer, not the card.