For the secure transfer of the PIN-code value from the terminal to the card, asymmetric encryption (currently the RSA algorithm) is obviously used. The encryption key can be either the public key of the card, used for dynamic card authentication, or the public key of a special pair of PIN Encipherment (PE) Private / Public Key keys, designed to encrypt / decrypt the PIN value.
In this case, the public key certificate PIN Encipherment Public Key Certificate (Tag '9F2D') has the same structure as the public key certificate of the card used for offline card authentication, except that the list of data signed when this certificate is created does not contain the Static element Data to be Authenticated.
The PIN Encipherment Public Key Certificate is created using encryption with the private key of the issuer of the data card shown in Table. 3.22.
Before encrypting the PIN-code, the terminal sequentially verifies the certificates and restores the issuer's and card's public keys (or the card's PIN Encipherment Public Key) from them.
Tab. 3.22. Data signed by the issuer when generating the PE Public Key certificate
In addition, the terminal sends the GET CHALLENGE command to the card and from the data field of the response to this command receives a random 8-byte ICC Unpredictable Number from the card.
After that, the terminal generates the data given in table. 3.23, and signs them with the public key encryption PIN.
Tab. 3.23. PIN block data encrypted for transfer to card
In this table, it is assumed that N = N PE or N - N IC , depending on which key is used to encrypt the PIN-code.
The encrypted data is transferred from the terminal to the card in the data field of the VERIFY command.
To extract the PIN-code value from the encrypted data received in the VERIFY command, the card applies a decryption algorithm to it using the card's secret key, and as a result obtains the PIN-block value.
In order to make sure that the received data is actually signed data of the table. 3.23, the card compares the value of the random number generated by the card in response to the GET CHALLENGE command with the random number obtained from the encrypted data in Table. 3.23. If they are equal, the PIN-code verification continues, if not, it stops, and the card sets the value 1 in the corresponding bit of the Card Verification Results data object (the Offline PIN Failed bit).
In addition, the card verifies that the Data Header value obtained from the encrypted PIN data is correct, and that the length of the encrypted data is equal to the length of the card's public key module used to encrypt the PIN.
The card compares the PIN-code recovered from the "PIN-block" field of encrypted data (see Table 3.23) with the PIN-code stored in the protected area of the card memory. If they are equal, the check was successful. Otherwise, the Offline PIN Failed bit of the Card Verification Results object is set to 1.
It follows from the above that using the ICC Unpredictable Number mechanism when implementing the Enciphered PIN Offline method helps to solve several problems.
First, using this element, the card checks the integrity of the encrypted data received from the terminal (for the same purpose, the Data Header element of Table 3.23 is used).
Second, the ICC Unpredictable Number data element helps fight fraud when the card is stolen or lost, but the value of the PIN is not known to the fraudster. Suppose the fraudster has conspired with the store cashier and made it possible to store the encrypted PIN-block values on the cashier's terminal corresponding to the PIN-codes used by cardholders when performing transactions through the cashier's terminal. If later the fraudster manages to steal one of the cards with the encrypted PIN-block value stored for it (for example, the cashier spoke to the cardholder during the transaction processing and left the card with him), then in this case, without using the ICC Unpredictable Number, the fraudster would have the opportunity to commit fraud. To do this, he needs to carry out an operation on the stolen card in the terminal, which would send the previously stored encrypted PIN-block value to the card in the data field of the VERIFY command. Such a terminal could be a “modernized” cashier's terminal or a fraudster's terminal (the fraudulent terminal could also be used to store the values of encrypted PIN-blocks). In any case, the PIN code check (like other checks - the card is genuine!) Would have been completed successfully, and the cashier (more precisely, the servicing bank of the commercial enterprise) would have all the data necessary to justify the fraudulent operation (applied cryptogram, transaction details ).
Finally, let's consider the purpose of the Random Pad Pattern element, which is present in the list of data to be signed for transmission to the card (see Table 3.23). The Random Pad Pattern element is designed to combat the compromise of PIN-code values on terminals. It is a random sequence of (N-17) bytes long and must be generated by the terminal security module (in particular, it must not be known to the terminal application). Indeed, if the Random Pad Pattern sequence were not used, then, knowing the values of the encrypted PIN-block, the public key of the card, and the ICC Unpredictable Number (this value is not confidential and can be easily obtained by fraudsters), enumerating only 10,000 possible PIN values code, you can determine the PIN-code of the cardholder.
In this case, the public key certificate PIN Encipherment Public Key Certificate (Tag '9F2D') has the same structure as the public key certificate of the card used for offline card authentication, except that the list of data signed when this certificate is created does not contain the Static element Data to be Authenticated.
The PIN Encipherment Public Key Certificate is created using encryption with the private key of the issuer of the data card shown in Table. 3.22.
Before encrypting the PIN-code, the terminal sequentially verifies the certificates and restores the issuer's and card's public keys (or the card's PIN Encipherment Public Key) from them.
Tab. 3.22. Data signed by the issuer when generating the PE Public Key certificate
| Field name | Length, bytes | Description | Format |
| Certificate Format | 1 | '04'h | B |
| PAN | 10 | PAN card number, right padded with 'F'h | cn 20 |
| Certificate Expiration Date | 2 | Date (month and year) after which the certificate is invalid | n4 |
| Certificate Serial Number | 3 | Binary number unique to this certificate assigned by the issuer | b |
| Hash Algorithm Indicator | 1 | Identifies the hashing algorithm; in the current implementation, EMV takes the value '01'h, corresponding to the SHA-1 algorithm | b |
| ICC PE Public Key Algorithm Indicator | 1 | Identifies the digital signature algorithm; in the current implementation EMV takes the value '01 'h, corresponding to the RSA algorithm | b |
| ICC PE Public Key Length | 1 | Length of the card's public key module in bytes - N pe | b |
| ICC PE Public Key Exponent Length | 1 | The exponent length of the card's public key in bytes | b |
| ICC PE Public Key or its leftmost digits | N, -42 | If N pe <N, - 42, then this field must contain the card's public key module in its entirety, padded on the right by bytes with the value 'BB'h. If N pe > N, - 42, then this field contains the N, - 42 most significant bytes of the card's public key | b |
| ICC PE Public Key Reminder | 0 or N PE - N, + 42 | This field is present if N IC > N, - 42, and consists of N, c - N, + 42 least significant bytes of the card's public key | b |
| ICC PE Public Key Exponent | 1 or 3 | Value 3 or 2 16 + 1 | b |
In addition, the terminal sends the GET CHALLENGE command to the card and from the data field of the response to this command receives a random 8-byte ICC Unpredictable Number from the card.
After that, the terminal generates the data given in table. 3.23, and signs them with the public key encryption PIN.
Tab. 3.23. PIN block data encrypted for transfer to card
| Field | Length, bytes | Description | Format |
| Data header | 1 | '7E'h | b |
| PIN block | 8 | PIN block | b |
| ICC Unpredictable Number | 8 | Random number generated by the card | b |
| Random pad pattern | N- 17 | Terminal generated random sequence | b |
In this table, it is assumed that N = N PE or N - N IC , depending on which key is used to encrypt the PIN-code.
The encrypted data is transferred from the terminal to the card in the data field of the VERIFY command.
To extract the PIN-code value from the encrypted data received in the VERIFY command, the card applies a decryption algorithm to it using the card's secret key, and as a result obtains the PIN-block value.
In order to make sure that the received data is actually signed data of the table. 3.23, the card compares the value of the random number generated by the card in response to the GET CHALLENGE command with the random number obtained from the encrypted data in Table. 3.23. If they are equal, the PIN-code verification continues, if not, it stops, and the card sets the value 1 in the corresponding bit of the Card Verification Results data object (the Offline PIN Failed bit).
In addition, the card verifies that the Data Header value obtained from the encrypted PIN data is correct, and that the length of the encrypted data is equal to the length of the card's public key module used to encrypt the PIN.
The card compares the PIN-code recovered from the "PIN-block" field of encrypted data (see Table 3.23) with the PIN-code stored in the protected area of the card memory. If they are equal, the check was successful. Otherwise, the Offline PIN Failed bit of the Card Verification Results object is set to 1.
It follows from the above that using the ICC Unpredictable Number mechanism when implementing the Enciphered PIN Offline method helps to solve several problems.
First, using this element, the card checks the integrity of the encrypted data received from the terminal (for the same purpose, the Data Header element of Table 3.23 is used).
Second, the ICC Unpredictable Number data element helps fight fraud when the card is stolen or lost, but the value of the PIN is not known to the fraudster. Suppose the fraudster has conspired with the store cashier and made it possible to store the encrypted PIN-block values on the cashier's terminal corresponding to the PIN-codes used by cardholders when performing transactions through the cashier's terminal. If later the fraudster manages to steal one of the cards with the encrypted PIN-block value stored for it (for example, the cashier spoke to the cardholder during the transaction processing and left the card with him), then in this case, without using the ICC Unpredictable Number, the fraudster would have the opportunity to commit fraud. To do this, he needs to carry out an operation on the stolen card in the terminal, which would send the previously stored encrypted PIN-block value to the card in the data field of the VERIFY command. Such a terminal could be a “modernized” cashier's terminal or a fraudster's terminal (the fraudulent terminal could also be used to store the values of encrypted PIN-blocks). In any case, the PIN code check (like other checks - the card is genuine!) Would have been completed successfully, and the cashier (more precisely, the servicing bank of the commercial enterprise) would have all the data necessary to justify the fraudulent operation (applied cryptogram, transaction details ).
Finally, let's consider the purpose of the Random Pad Pattern element, which is present in the list of data to be signed for transmission to the card (see Table 3.23). The Random Pad Pattern element is designed to combat the compromise of PIN-code values on terminals. It is a random sequence of (N-17) bytes long and must be generated by the terminal security module (in particular, it must not be known to the terminal application). Indeed, if the Random Pad Pattern sequence were not used, then, knowing the values of the encrypted PIN-block, the public key of the card, and the ICC Unpredictable Number (this value is not confidential and can be easily obtained by fraudsters), enumerating only 10,000 possible PIN values code, you can determine the PIN-code of the cardholder.
