Security vulnerabilities in EMV standard

Data on the card The data that is required to complete the transaction is read terminal from the records of the payment application files by the READ command RECORD. But not all the data that the terminal may need, located in the file record. Some data is stored as separate objects and, if necessary, the terminal extracts them from the card using the GET DATA command.

Security concerns The most important property of the payment application is the use of cryptographic functions to enhance the security of financial operations’. The main tasks to improve the security of financial the tasks solved by the application are as follows.

• 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 the Bank, authorized to issue cards. In case of offline transaction the Issuer fully delegates to the card the decision-making function on the result of the operation. Obviously, you can only trust decisions of the card, the authenticity of which is proven. That’s why it’s so important. strong authentication. Authentication of the card is carried out by the terminal and (or) the Issuer. In offline transactions, the authentication the card is made only by the terminal and is called offline authentication. In the case of an online transaction authentication the card can be carried out by both the terminal and the Issuer. Card authentication performed by the Issuer is called online.
• 2. Providing Issuer authentication and integrity checks the sent data by verification of the signature data, formed by the Issuer.
• 3. Guarantee to the Issuer of impossibility of refusal of the holder of his card from the result of the performed operation. This is ensured by the fact that each completed transaction the Issuer receives from the card in its use the application cryptogram, which is signature of the most critical transaction data. Accordance the cryptogram of the transaction data confirms the fact of its execution.
• 4. Check the integrity of the critical data exchange between the card and terminal.
• 5. Ensuring data confidentiality in information exchange between the card and the Issuer of the card and the terminal.
• 6. Providing a mechanism for reliable verification of the cardholder with offline PIN verification. The payment application implements security features transactions based on the asymmetric algorithm used in the EMV standard RSA encryption and symmetric DES encryption algorithm. First, consider the RSA encryption algorithm. Aside from RSA terminology, which can sometimes only be confusing, is asymmetric encryption is based on the fact that there are two keys – public and private secret. If the data is encrypted on a public key, it can be decrypted on the secret key and Vice versa. Necessity application of asymmetric encryption algorithms in procedures security is caused by the fact that the terminal should not have card secrets (symmetric encryption always implies knowledge participants of information exchange of the General secret). In order for the terminal to be able to use asymmetric card keys to to implement security functions, it is necessary to create a PKI-Public Key Infrastructure. PKI infrastructure payment system in accordance with EMV standard

The root of the PKI infrastructure is the certification authority Authority-CA) payment system. The certification authority generates a pair of RSA keys (public and secret) and sends the public keys to the servicing banks for their loading into the terminals of the payment system. On the second at the level of the PKI-infrastructure tree there are certification centers of issuers – participants of the payment system. These centres also generate a pair of RSA keys and receive public key certificates from the CA. Certificate the public key represents the public key details (including and the public key itself), its validity, Issuer ID, etc., signed on the secret key of the payment system certification authority.One Finally, at the lower level of the infrastructure, there are open and private keys of the Issuer’s cards. Public keys of cards are signed in the Issuer’s certification authority on the certification authority’s secret key issuer’s. In the process of personalization of the payment application on the card are recorded the public key certificates of the Issuer and the public key of the card as well the secret key of the card. In order to get the public key of the card, the terminal reads from the card the public key certificates of the Issuer and the card. Then with the help the CA public key stored in the terminal, the terminal verifies validity of the Issuer’s public key certificate.Two After proving the validity of the Issuer’s public key certificate the terminal uses the recovered Issuer’s public key to verify the validity of the card’s public key certificate. If the certificate is correct, then the terminal accesses the public key of the card. Open the card key is used by the terminal to authenticate the application to card and encrypt sensitive data sent to the application (for example, PIN).

Application authentication is performed by checking the signature of certain data generated by the card on secret key of the card. If the signature of the card is correct, it means that it was made by the secret key of the card corresponding to its public key certified by the Issuer. This in turn means that the card was issued by the issuing Bank whose public key was certified by the payment system certification center. So thus, the fact of issuing the card by the Bank authorized by the issue payment system cards. To generate application cryptograms, data signatures, transmitted between the Issuer and the card, as well as to encrypt the exchange EMV the Sign function on the secret server is used to generate certificates key. This feature encrypts the certificate on a secret key and it can be decrypted only on the public key corresponding to the private key. The certificate is decrypted on the public key. In EMV terminology, this function it’s called Recover. As a result of decryption of the certificate, the terminal gets access to the Issuer’s public key, which is stored in the certificate. But in the certificate can be stored not all of the Issuer’s public key, but only part of it. The other part of the key is extracted from the object data, which is called the Issuer Public Key Remainder.

Sensitive information between them, using the symmetric the 3DES algorithm (ISO 11568-2). In this case, the participants of the information they share a secret-the 3DES secret key. Or rather, a set private keys, because for security purposes, the payment application and the Issuer uses multiple keys. It is fair to say that the set of secret keys in the payment application is determined by the developer. Therefore, to talk about some standards are not necessary. For example, you can give what the keys are used in an application built to EMV specifications CCD (Common Core Definitions): the key Ka (Application Cryptogram Key) – is used to calculate cryptogram applications the Ki key (MAC Key) is used for the computation of the signature data (Message Authentication Code – MAC) in script commands, the processing KC (Encryption Key) – used for encryption confidential data in script commands, the processing The Issuer stores only symmetric cryptographic master keys. algorithm, which in the process of personalization cards are transformed (diversified) into unique payment application keys (diversification of the Issuer’s master key can be done in several ways using Application PAN and Application PAN Sequence Number). Thus, every payment application uses a set of unique keys for cryptographic operations. What’s more, the payment app’s unique key is diversified for each transaction in the session key. To obtain a session the key is used Application Transaction Counter (ATC) – a counter that increases as each transaction is executed. As a result, for each transaction, the card and Issuer use a unique the key of a symmetric cryptographic algorithm, which is significantly improve safety.

Verification of the card holder Verification of the cardholder is performed in order to establish the fact identity of the person who received the card from its Issuer (Bank client), with the person performing the operation on the card. Key data object for the cardholder verification method is the Cardholder Verification Method object (CVM) List, which is stored on the card. This object defines a list methods and conditions of verification of the cardholder. One of the main methods of cardholder verification is PIN verification procedure. PIN verification though is only one of the possible methods of verification, but have become widespread in because of its reliability and efficiency. There are two different methods of offline PIN verification:

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

Offline PIN verification always starts with the terminal issues a 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 has attempts to enter the PIN code, then the terminal receives from the cardholder the value of his PIN-code (from 4 to 12 digits) and generates a PIN block from the PIN code in ISO Format 2 If the CVM specifies that the PIN must be presented to unencrypted, the terminal sends the VERIFY command to the card, in the data field which contains the value of the PIN block in an ISO Format 2. When The PIN must be presented in encrypted form, then first the terminal receives a random number from the card using the GET command The CHALLENGE, then generates a certificate PIN code, which contains PIN block and received random number, and encodes the certificate on public key of the card. The encrypted PIN certificate is submitted to the card as the VERIFY command data. The card compares the received PIN value with the value stored on the card (previously decoding certificate, a PIN on a secret key of the card and checking certificate when needed). If they match, the Pin code check is considered successful. Every time presented incorrect PIN, the number of remaining attempts to enter the PIN decreases by 1 (when zero is reached, the PIN will be locked). Online PIN verification has nothing to do with the card. Input device Pin requests a PIN from the cardholder and encrypts it by a special algorithm, usually using THE dukpt (Derived) algorithm Unique Key Per Transaction). Verification of the cardholder by the terminal on this completes because the pin value is verified by the Issuer, not the card.