With the advent of microprocessor payment cards on the market, along with the well-known and well-known method for verification of the PIN Online cardholder by that time , when the PIN value is checked by the card issuer at its host, the PIN Offline method began to be widely used.
Despite the fact that both verification methods have been used in parallel for 15 years, one still sometimes hears questions: which method provides higher security when processing a transaction - PIN Online or PIN Offline? And in general, is it possible for the issuer (the bank that issued the card) to do with only one of the specified PIN verification methods? For example, using the PIN Online method. Obviously, from the point of view of the issuer, this method is simpler than the PIN Offline method when implementing procedures for personalizing the card, changing the PIN by the cardholder, controlling the limit on the number of attempts to enter incorrect PIN values, since in this case the listed procedures are performed only on the issuer's host and do not require additional actions. on the side of the payment application of the card.
It is clear that the above questions may be asked by people familiar with card technology. For an ordinary cardholder, both methods of his verification are indistinguishable, and he may not even be aware of their existence. Regardless of the method used, the cardholder simply enters the PIN value on the terminal's keyboard, and the cardholder is of little interest in how this PIN is then verified.
The easiest way to answer the question is whether in practice it is possible to do with one verification method. More versatile for use is the PIN Online method, which is supported by almost all terminals that provide verification of the PIN code. An exception is terminals that can function only in offline mode (Offline Only terminals).
Note that refusal to use the PIN Offline method does not lead to refusal to use offline operations. For offline transactions, alternative methods of cardholder verification can be used - signature and / or biometric verification (in fairness, we note that biometrics on cards are practically not used today).
The PIN-offline method is not used in ATMs and in transactions using contactless cards - a situation may arise when the card is blocked due to exceeding the limit of unsuccessful attempts to enter a PIN, and the client does not even know about it. In addition, due to the need to encrypt the PIN block with the public key of the card, the operation time is significantly increased, which is badly reflected in contactless payments performed in Tap & Go mode. Therefore, it is impossible to use only the PIN Offline method to process card transactions.
Maybe it makes sense to limit yourself to using the PIN Online method?
This idea seems bad.
Thus, both methods of cardholder verification are in demand in card technologies, and we can return to the first question: what method of PIN verification provides higher security for card transactions?
When using the PIN Offline method, the PIN verification is delegated by the issuer to the card. Unlike the PIN Online method, when the PIN is encrypted at an ATM / POS terminal and encrypted (after several re-encryptions on the way to the issuer's host) is sent to the issuer for verification, in the case of PIN Offline, the issuer does not verify the PIN value and can only use card and terminal information regarding the results of cardholder verification. Note that the issuer can use this data only in case of online authorization of the operation. In an offline transaction, all decisions on its authorization are delegated by the issuer to its card (more precisely to the payment application on the card).
Below we will consider two threats that may arise with such delegation of PIN verification, i.e. when using the PIN Offline method. Note again that we are talking about threats of the second order of smallness. In practice, the implementation of these threats was not recorded, and they are mainly of an academic nature. Their implementation is too expensive and difficult compared to other known fraudulent methods ...
The first threat is associated with an attempt by a fraudster who had a card with an unknown PIN to bypass the PIN check. To do this, the fraudster "implants" a special microprocessor (the so-called wedge device) into the card, which, on the one hand, is connected to the contact pad of the card, and on the other hand, it works with a real chip of the card, fully controlling the terminal's APDU commands and the card's responses to these commands (Man-in-the-Middle attack). As a result of the constructed structure, all terminal commands are sent to the card's chip through the wedge device. To check the PIN Offline, the terminal sends a Verify command to the card with an encrypted PIN value, which is sent to the wedge device. The PIN value is entered by a fraudster, and therefore with a high probability it does not coincide (the fraudster does not know the PIN value) with the reference value stored on the card.
Further, we will show that on the "correct" card, which is, for example, the "Mir" card, bypassing the PIN verification is possible only by the decision of the issuer, who is ready to take on the risks associated with the lack of PIN verification or even with knowledge of the fact of a failed PIN verification. Offline. I will not bother the reader here with the byte and bit numbers of the data and terminal objects used for this, as well as with a detailed description of the checks performed by the card.
To understand further, the reader will need minimal knowledge about the following data objects:
Card Verification Results (CVR) - a card data object, including fixing the fact of verification by a PIN Offline card, as well as the result of PIN Offline verification (successful / unsuccessful). In addition, the CVR object contains the least significant 4 bits of the binary representation of the number of offline PIN checks available to the cardholder;
Terminal Verification Results - a terminal data object, including indicating the result of cardholder verification, the fact that the PIN Online method was used when processing a transaction, and the fact that the limit for entering incorrect PIN values has been exceeded;
CVM Results - terminal data object indicating the method of cardholder verification (for example, PIN Offline, PIN Online, Signature, CVM no.) And the verification result.
All the listed data objects go to the issuer in an authorization request and are used by it when making a decision on authorizing a transaction.
Note that a number of special checks performed on the card side and the card's support for the combined offline authentication method of the CDA card also play a key role in preventing the PIN Offline verification attack.
The CDA method ensures the integrity of the data transmitted to the card in the commands of the AC terminal and the data returned by the card to the terminal in response to the Generate AC command (a command that requires the card to decide on how to continue processing the operation and a cryptogram (cryptographic signature) of the transaction data and the terminal on which the transaction was initiated).
Further, depending on the malicious behavior of the wedge device, the following cases are possible.
Case 1. The wedge device does not change the content of the Verify command, the PIN Offline check fails. This fact will be recorded in the CVR and CVM Result object, and the card issuer is unlikely to decide in this case to authorize a transaction for a significant amount. Most often, in such cases, the issuer rejects the transaction, regardless of the size of the transaction.
Therefore, in all the cases described below, the wedge device tries to change the dialogue of the terminal with the card in order to deceive the issuer and not demonstrate to him that the cardholder does not know the PIN.
Case 2. The wedge device responds to the Verify command to the terminal with confirmation of the fact of successful PIN verification and does not transmit the command to the card. After that, the options ac described below are possible.
2a. The Generate AC command does not contain a CVM Results object (this object is required for the World map). In this case, the card, based on the fact that the PIN Offline check was not performed, generates an ARQC cryptogram requiring online processing of the operation, or an AAC cryptogram (operation rejection) if the terminal is of the Offline only type (functions only in offline mode).
The issuer, having received an authorization request, compares the flags CVR (PIN Offline not performed) and CVM Results (PIN offline successful) and rejects the transaction due to data inconsistency in these objects.
2b. The Generate AC command contains CVM Results and the wedge device transmits it to the card without distortion (PIN offline successful).
The card detects a contradiction with the CVM Results data (the terminal mistakenly considers the PIN offline check to be successful) and either rejects the operation if the terminal is Offline Only, or sends an authorization request to the issuer to resolve it. The Issuer makes a decision based on its risk management procedures. Of course, the data of the card PIN Offline not Performed and the fact that there was an attempt to cheat the card when making a decision are taken into account.
2c. The Generate AC command contains CVM Results, and the wedge device transfers this data object to the card as modified (for example, specifies Signature as the verification method of the cardholder).
If the card supports CDA (the World card always supports the CDA method), the terminal will reject the offline operation because the CVM Results object has been changed, and this will be detected after decryption of the data signed by the card.
If CDA is not supported, then the transaction will go to the issuer or will be rejected offline for Offline Only terminals. Here there is a complete analogy with item 2a.
Case 3. The wedge device informs the terminal in response to the Get Data command with the PIN Try Counter object tag (9F17) that the PIN is Try Limit Exceeded. The Get Data command is always used by the terminal before starting the PIN Offline check to find out if this check is possible - if the PIN Try Limit is exceeded, the PIN Offline check is not possible and is not performed.
The card must respond with a refusal due to a contradiction in the data of the TVR (PIN Try Limit Exceeded) and CVR (PIN Try Counter is not 0) objects.
The wedge device cannot change the TVR value, because an attempt to do this will either fail CDA (if the card supports CDA, as in the case of the Mir card), or the ARQC check on the issuer's side will fail if the CDA card does not support it.
Case 4: The wedge device sends a series of Verify commands to the card with an invalid PIN until it receives a Try Limit Exceeded PIN in response to the Get Data command.
In this case, the card will require online authorization by the issuer. In all fairness, the chances of the issuer getting the transaction approved in this case are not much higher than in the case when the PIN Offline verification failed. But in theory, when processing a transaction for a negligible amount, such an event could occur.
Another way to bypass PIN Offline verification is to use virtual card cloning. The essence of this fraud scheme is as follows.
Fraudsters control the terminal in some trade and service enterprise (for example, a restaurant). In addition, they manufacture a special microprocessor card that has a standard contact interface ISO 7816 and a radio interface operating in accordance with one of the communication protocols that provide communication at a distance from several tens of centimeters to several meters (for example, ISO 15693, ISO 18000). Using such a radio interface, the card can exchange data with special equipment, which, in addition to supporting communication with the card, provides the organization of a remote radio channel (for example, in accordance with the Wi-Max protocol (IEEE 802.16)) with a terminal controlled by fraudsters.
A fraudster, armed with the card described above and special equipment, comes, for example, to a jewelry store and chooses a piece of jewelry worth 200,000 rubles. At this time in the restaurant the unsuspecting holder of the card finishes his lunch, which he presents to the waiter to pay for the lunch worth 200 rubles. The waiter is an accomplice of our jewelry lover. He calls him and warns that he has a valid visitor card in his hands.
Then the scammers act in the following coordinated way. A fraudulent waiter inserts a visitor's card into a fraud-controlled terminal and enters the cost of the meal into the terminal. At the same time, a fraudster in a jewelry store hands over his counterfeit card to the cashier to pay for the jewelry, which the cashier inserts into the real terminal. Further, all the commands of the terminal installed in the jewelry store, through the fraudster's card, his special equipment and the fraudulent terminal, are transmitted to the real card of the gentleman who had dinner at the restaurant. In this case, the responses of the real card to the commands of the real terminal along the same route, but in the opposite direction, are returned to the real terminal.
However, some commands require transformation of the data they contain. For example, if a real card requires a PIN check, then a fraudster in a jewelry store will enter a random sequence on the terminal. After the VERIFY command from the real terminal is broadcast to the fraudulent terminal, now this terminal will request a PIN from the restaurant visitor, who will enter it at the fraudulent terminal. Then the fraudulent terminal will send the VERIFY command to the real card with the PIN value of its holder, and the card's response will be sent to the real terminal in the jewelry store. It is important to note that the VERIFY command with the correct PIN value must be brought to the card in order for the fact of the PIN Offline verification to be recorded in the CVR object intended for the issuer.
Obviously, even online authorization of the operation will not interfere with the successful completion of the operation according to the scheme described above. In this case, in response to the GENERATE AC command of the real terminal, the real card will generate an ARQC cryptogram, which will be returned to the jewelry store terminal and then transmitted to the issuer host. On the contrary, the issuer's response containing the Issuer Authentication Data will be broadcast with the real card inserted into the fraudulent terminal.
As a result, the operation can end up badly for the visitor of the restaurant and jewelry store. The visitor's bank account can be reduced by 200,000 rubles. In this case, a restaurant visitor will receive a check for the cost of lunch and, most likely, will be in the dark about what happened until he receives a certificate on the status of his bank account or an SMS-notification from the issuer about the online transaction performed by the fraudster. Moreover, it is possible to make it so that a part of his card number will appear on a check issued to a fraudster in a jewelry store, so that a vigilant seller of a jewelry store will not see any problems with the security of the operation here either.
We will not dwell on how the dispute, initiated by the cardholder on the occasion of his deception, will end. We only note that if there is no servicing bank behind the terminal in the restaurant, then formally neither the jewelry store, together with its bank, nor the cardholder, together with its issuer, are to blame for anything. All parties acted in accordance with the rules of the PS. The disadvantage of the EMV technology used is evident - in this case, the authentication of the terminal with a card is not enough.
Obviously, the above scheme does not work when using the PIN Online method. If we analyze the fraud described above, it becomes clear that it turned out to be possible due to the lack of direct interaction (dialogue) between the cardholder and the card. Between the holder and the card there is an intermediary in the form of a terminal, capable of distorting information about the transaction in such a way that the cardholder does not see this distortion during the processing of the transaction. This intermediary, among other things, can steal important information of the card, including the PIN of its holder.
It should be noted that the CDA offline authentication method for combating data corruption by the terminal does not help, since it ensures the integrity of the information sent by the terminal to the card, but does not verify this data. It is also clear that a cryptogram is a means of proving the fact that the cardholder has performed an operation with an accuracy to the degree of trust in the terminal - the card signs the data provided to it by the same terminal.
Nevertheless, in conclusion I would like to say a few words in support of the PIN Offline method. It turns out that if the issuer uses the Visa PVV method to verify the PIN using the PIN Online method (the most common case in practice), then the fraudster's probability of guessing the correct card PIN is higher than the same probability when using the PIN Offline method.
Below we will consider PIN codes with a length of 4 digits. Let us denote by N and M-respectively the cardinalities of all possible values of PIN and PVV, respectively. Obviously, N = M = 〖10〗 ^ 4. In addition, we denote p = 1 / M = 〖10〗 ^ (- 4) and q = 1-p.
Obviously, the probability that the card's PVV value corresponds to exactly k values of different PINs (obviously, this number of PINs is a random variable, which we denote by θ) is equal to
P {θ = k│θ≥1} = (P {θ = k }) / (P {θ≥1}) = (C_N ^ kp ^ kq ^ (Nk)) / (1-q ^ N), whence the probability of guessing the PIN in one attempt is p / (1-q ^ N) ≈ p (1 + q ^ N) ≈ 1.368 ∙ 〖10〗 ^ (- 4).
When using the PIN Offline method, the probability of using m attempts to guess the PIN is mp = m 〖∙ 10〗 ^ (- 4), and when using the PIN Online this probability is approximately mp (1 + q ^ N) = 1.368 〖∙ 10〗 ^ (-4) ∙ m, i.e. 0.0368% higher than in the PIN Offline method. This, of course, is a ridiculous increase in the likelihood of compromising IDUs, but nevertheless, it can be attributed to a value of the second order of smallness.
Despite the fact that both verification methods have been used in parallel for 15 years, one still sometimes hears questions: which method provides higher security when processing a transaction - PIN Online or PIN Offline? And in general, is it possible for the issuer (the bank that issued the card) to do with only one of the specified PIN verification methods? For example, using the PIN Online method. Obviously, from the point of view of the issuer, this method is simpler than the PIN Offline method when implementing procedures for personalizing the card, changing the PIN by the cardholder, controlling the limit on the number of attempts to enter incorrect PIN values, since in this case the listed procedures are performed only on the issuer's host and do not require additional actions. on the side of the payment application of the card.
It is clear that the above questions may be asked by people familiar with card technology. For an ordinary cardholder, both methods of his verification are indistinguishable, and he may not even be aware of their existence. Regardless of the method used, the cardholder simply enters the PIN value on the terminal's keyboard, and the cardholder is of little interest in how this PIN is then verified.
The easiest way to answer the question is whether in practice it is possible to do with one verification method. More versatile for use is the PIN Online method, which is supported by almost all terminals that provide verification of the PIN code. An exception is terminals that can function only in offline mode (Offline Only terminals).
Note that refusal to use the PIN Offline method does not lead to refusal to use offline operations. For offline transactions, alternative methods of cardholder verification can be used - signature and / or biometric verification (in fairness, we note that biometrics on cards are practically not used today).
The PIN-offline method is not used in ATMs and in transactions using contactless cards - a situation may arise when the card is blocked due to exceeding the limit of unsuccessful attempts to enter a PIN, and the client does not even know about it. In addition, due to the need to encrypt the PIN block with the public key of the card, the operation time is significantly increased, which is badly reflected in contactless payments performed in Tap & Go mode. Therefore, it is impossible to use only the PIN Offline method to process card transactions.
Maybe it makes sense to limit yourself to using the PIN Online method?
This idea seems bad.
Thus, both methods of cardholder verification are in demand in card technologies, and we can return to the first question: what method of PIN verification provides higher security for card transactions?
When using the PIN Offline method, the PIN verification is delegated by the issuer to the card. Unlike the PIN Online method, when the PIN is encrypted at an ATM / POS terminal and encrypted (after several re-encryptions on the way to the issuer's host) is sent to the issuer for verification, in the case of PIN Offline, the issuer does not verify the PIN value and can only use card and terminal information regarding the results of cardholder verification. Note that the issuer can use this data only in case of online authorization of the operation. In an offline transaction, all decisions on its authorization are delegated by the issuer to its card (more precisely to the payment application on the card).
Below we will consider two threats that may arise with such delegation of PIN verification, i.e. when using the PIN Offline method. Note again that we are talking about threats of the second order of smallness. In practice, the implementation of these threats was not recorded, and they are mainly of an academic nature. Their implementation is too expensive and difficult compared to other known fraudulent methods ...
The first threat is associated with an attempt by a fraudster who had a card with an unknown PIN to bypass the PIN check. To do this, the fraudster "implants" a special microprocessor (the so-called wedge device) into the card, which, on the one hand, is connected to the contact pad of the card, and on the other hand, it works with a real chip of the card, fully controlling the terminal's APDU commands and the card's responses to these commands (Man-in-the-Middle attack). As a result of the constructed structure, all terminal commands are sent to the card's chip through the wedge device. To check the PIN Offline, the terminal sends a Verify command to the card with an encrypted PIN value, which is sent to the wedge device. The PIN value is entered by a fraudster, and therefore with a high probability it does not coincide (the fraudster does not know the PIN value) with the reference value stored on the card.
Further, we will show that on the "correct" card, which is, for example, the "Mir" card, bypassing the PIN verification is possible only by the decision of the issuer, who is ready to take on the risks associated with the lack of PIN verification or even with knowledge of the fact of a failed PIN verification. Offline. I will not bother the reader here with the byte and bit numbers of the data and terminal objects used for this, as well as with a detailed description of the checks performed by the card.
To understand further, the reader will need minimal knowledge about the following data objects:
Card Verification Results (CVR) - a card data object, including fixing the fact of verification by a PIN Offline card, as well as the result of PIN Offline verification (successful / unsuccessful). In addition, the CVR object contains the least significant 4 bits of the binary representation of the number of offline PIN checks available to the cardholder;
Terminal Verification Results - a terminal data object, including indicating the result of cardholder verification, the fact that the PIN Online method was used when processing a transaction, and the fact that the limit for entering incorrect PIN values has been exceeded;
CVM Results - terminal data object indicating the method of cardholder verification (for example, PIN Offline, PIN Online, Signature, CVM no.) And the verification result.
All the listed data objects go to the issuer in an authorization request and are used by it when making a decision on authorizing a transaction.
Note that a number of special checks performed on the card side and the card's support for the combined offline authentication method of the CDA card also play a key role in preventing the PIN Offline verification attack.
The CDA method ensures the integrity of the data transmitted to the card in the commands of the AC terminal and the data returned by the card to the terminal in response to the Generate AC command (a command that requires the card to decide on how to continue processing the operation and a cryptogram (cryptographic signature) of the transaction data and the terminal on which the transaction was initiated).
Further, depending on the malicious behavior of the wedge device, the following cases are possible.
Case 1. The wedge device does not change the content of the Verify command, the PIN Offline check fails. This fact will be recorded in the CVR and CVM Result object, and the card issuer is unlikely to decide in this case to authorize a transaction for a significant amount. Most often, in such cases, the issuer rejects the transaction, regardless of the size of the transaction.
Therefore, in all the cases described below, the wedge device tries to change the dialogue of the terminal with the card in order to deceive the issuer and not demonstrate to him that the cardholder does not know the PIN.
Case 2. The wedge device responds to the Verify command to the terminal with confirmation of the fact of successful PIN verification and does not transmit the command to the card. After that, the options ac described below are possible.
2a. The Generate AC command does not contain a CVM Results object (this object is required for the World map). In this case, the card, based on the fact that the PIN Offline check was not performed, generates an ARQC cryptogram requiring online processing of the operation, or an AAC cryptogram (operation rejection) if the terminal is of the Offline only type (functions only in offline mode).
The issuer, having received an authorization request, compares the flags CVR (PIN Offline not performed) and CVM Results (PIN offline successful) and rejects the transaction due to data inconsistency in these objects.
2b. The Generate AC command contains CVM Results and the wedge device transmits it to the card without distortion (PIN offline successful).
The card detects a contradiction with the CVM Results data (the terminal mistakenly considers the PIN offline check to be successful) and either rejects the operation if the terminal is Offline Only, or sends an authorization request to the issuer to resolve it. The Issuer makes a decision based on its risk management procedures. Of course, the data of the card PIN Offline not Performed and the fact that there was an attempt to cheat the card when making a decision are taken into account.
2c. The Generate AC command contains CVM Results, and the wedge device transfers this data object to the card as modified (for example, specifies Signature as the verification method of the cardholder).
If the card supports CDA (the World card always supports the CDA method), the terminal will reject the offline operation because the CVM Results object has been changed, and this will be detected after decryption of the data signed by the card.
If CDA is not supported, then the transaction will go to the issuer or will be rejected offline for Offline Only terminals. Here there is a complete analogy with item 2a.
Case 3. The wedge device informs the terminal in response to the Get Data command with the PIN Try Counter object tag (9F17) that the PIN is Try Limit Exceeded. The Get Data command is always used by the terminal before starting the PIN Offline check to find out if this check is possible - if the PIN Try Limit is exceeded, the PIN Offline check is not possible and is not performed.
The card must respond with a refusal due to a contradiction in the data of the TVR (PIN Try Limit Exceeded) and CVR (PIN Try Counter is not 0) objects.
The wedge device cannot change the TVR value, because an attempt to do this will either fail CDA (if the card supports CDA, as in the case of the Mir card), or the ARQC check on the issuer's side will fail if the CDA card does not support it.
Case 4: The wedge device sends a series of Verify commands to the card with an invalid PIN until it receives a Try Limit Exceeded PIN in response to the Get Data command.
In this case, the card will require online authorization by the issuer. In all fairness, the chances of the issuer getting the transaction approved in this case are not much higher than in the case when the PIN Offline verification failed. But in theory, when processing a transaction for a negligible amount, such an event could occur.
Another way to bypass PIN Offline verification is to use virtual card cloning. The essence of this fraud scheme is as follows.
Fraudsters control the terminal in some trade and service enterprise (for example, a restaurant). In addition, they manufacture a special microprocessor card that has a standard contact interface ISO 7816 and a radio interface operating in accordance with one of the communication protocols that provide communication at a distance from several tens of centimeters to several meters (for example, ISO 15693, ISO 18000). Using such a radio interface, the card can exchange data with special equipment, which, in addition to supporting communication with the card, provides the organization of a remote radio channel (for example, in accordance with the Wi-Max protocol (IEEE 802.16)) with a terminal controlled by fraudsters.
A fraudster, armed with the card described above and special equipment, comes, for example, to a jewelry store and chooses a piece of jewelry worth 200,000 rubles. At this time in the restaurant the unsuspecting holder of the card finishes his lunch, which he presents to the waiter to pay for the lunch worth 200 rubles. The waiter is an accomplice of our jewelry lover. He calls him and warns that he has a valid visitor card in his hands.
Then the scammers act in the following coordinated way. A fraudulent waiter inserts a visitor's card into a fraud-controlled terminal and enters the cost of the meal into the terminal. At the same time, a fraudster in a jewelry store hands over his counterfeit card to the cashier to pay for the jewelry, which the cashier inserts into the real terminal. Further, all the commands of the terminal installed in the jewelry store, through the fraudster's card, his special equipment and the fraudulent terminal, are transmitted to the real card of the gentleman who had dinner at the restaurant. In this case, the responses of the real card to the commands of the real terminal along the same route, but in the opposite direction, are returned to the real terminal.
However, some commands require transformation of the data they contain. For example, if a real card requires a PIN check, then a fraudster in a jewelry store will enter a random sequence on the terminal. After the VERIFY command from the real terminal is broadcast to the fraudulent terminal, now this terminal will request a PIN from the restaurant visitor, who will enter it at the fraudulent terminal. Then the fraudulent terminal will send the VERIFY command to the real card with the PIN value of its holder, and the card's response will be sent to the real terminal in the jewelry store. It is important to note that the VERIFY command with the correct PIN value must be brought to the card in order for the fact of the PIN Offline verification to be recorded in the CVR object intended for the issuer.
Obviously, even online authorization of the operation will not interfere with the successful completion of the operation according to the scheme described above. In this case, in response to the GENERATE AC command of the real terminal, the real card will generate an ARQC cryptogram, which will be returned to the jewelry store terminal and then transmitted to the issuer host. On the contrary, the issuer's response containing the Issuer Authentication Data will be broadcast with the real card inserted into the fraudulent terminal.
As a result, the operation can end up badly for the visitor of the restaurant and jewelry store. The visitor's bank account can be reduced by 200,000 rubles. In this case, a restaurant visitor will receive a check for the cost of lunch and, most likely, will be in the dark about what happened until he receives a certificate on the status of his bank account or an SMS-notification from the issuer about the online transaction performed by the fraudster. Moreover, it is possible to make it so that a part of his card number will appear on a check issued to a fraudster in a jewelry store, so that a vigilant seller of a jewelry store will not see any problems with the security of the operation here either.
We will not dwell on how the dispute, initiated by the cardholder on the occasion of his deception, will end. We only note that if there is no servicing bank behind the terminal in the restaurant, then formally neither the jewelry store, together with its bank, nor the cardholder, together with its issuer, are to blame for anything. All parties acted in accordance with the rules of the PS. The disadvantage of the EMV technology used is evident - in this case, the authentication of the terminal with a card is not enough.
Obviously, the above scheme does not work when using the PIN Online method. If we analyze the fraud described above, it becomes clear that it turned out to be possible due to the lack of direct interaction (dialogue) between the cardholder and the card. Between the holder and the card there is an intermediary in the form of a terminal, capable of distorting information about the transaction in such a way that the cardholder does not see this distortion during the processing of the transaction. This intermediary, among other things, can steal important information of the card, including the PIN of its holder.
It should be noted that the CDA offline authentication method for combating data corruption by the terminal does not help, since it ensures the integrity of the information sent by the terminal to the card, but does not verify this data. It is also clear that a cryptogram is a means of proving the fact that the cardholder has performed an operation with an accuracy to the degree of trust in the terminal - the card signs the data provided to it by the same terminal.
Nevertheless, in conclusion I would like to say a few words in support of the PIN Offline method. It turns out that if the issuer uses the Visa PVV method to verify the PIN using the PIN Online method (the most common case in practice), then the fraudster's probability of guessing the correct card PIN is higher than the same probability when using the PIN Offline method.
Below we will consider PIN codes with a length of 4 digits. Let us denote by N and M-respectively the cardinalities of all possible values of PIN and PVV, respectively. Obviously, N = M = 〖10〗 ^ 4. In addition, we denote p = 1 / M = 〖10〗 ^ (- 4) and q = 1-p.
Obviously, the probability that the card's PVV value corresponds to exactly k values of different PINs (obviously, this number of PINs is a random variable, which we denote by θ) is equal to
P {θ = k│θ≥1} = (P {θ = k }) / (P {θ≥1}) = (C_N ^ kp ^ kq ^ (Nk)) / (1-q ^ N), whence the probability of guessing the PIN in one attempt is p / (1-q ^ N) ≈ p (1 + q ^ N) ≈ 1.368 ∙ 〖10〗 ^ (- 4).
When using the PIN Offline method, the probability of using m attempts to guess the PIN is mp = m 〖∙ 10〗 ^ (- 4), and when using the PIN Online this probability is approximately mp (1 + q ^ N) = 1.368 〖∙ 10〗 ^ (-4) ∙ m, i.e. 0.0368% higher than in the PIN Offline method. This, of course, is a ridiculous increase in the likelihood of compromising IDUs, but nevertheless, it can be attributed to a value of the second order of smallness.
