Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The most important property of a microprocessor card is its support for cryptographic functions by the operating system. The use of these functions by the card application can significantly increase the security of financial transactions.
Here, before continuing reading, it is strongly recommended that you familiarize yourself with the appendix. A and adj. B. These applications will allow you to understand the mathematical foundations of the cryptographic algorithms used, as well as get acquainted with the most famous algorithms for symmetric and asymmetric encryption. The appendices are written in such a way that any reader with the most modest knowledge of the basics of mathematics can learn the information they contain with the proper level of perseverance. As a result of acquaintance with applications the reader will be able to deduce the properties of cryptographic transformations necessary for him at any moment of time on his own without referring to other sources, evaluate their computational complexity and cryptographic strength. The appendices contain proofs of almost all of the statements made in them.
What tasks are solved by the IPC application using cryptographic functions to increase the security of transactions with plastic cards?
1. The most important basic problem solved by a card application using cryptographic methods is to ensure reliable authentication of the card application (more often they say, and we will adhere to the same terminology, card authentication, although it is more correct to talk about application authentication). Card authentication is understood as the process of proving its authenticity, i.e. the fact that this card (application) was issued by a bank authorized to issue cards by the corresponding payment system. Successful card authentication means that it has been proven that the card was issued by bank X, which is a member of payment system Y, which authorized bank X to issue cards of payment system Y. The reliability of the proof of the issue of a particular card by an authorized issuer depends on the card authentication method (see p. 4.
As previously mentioned, the IPC is a microcomputer capable of processing commands from a terminal and / or card issuer. Command processing is reduced to a series of checks performed by the card, as a result of which the card decides on the result of transaction processing. Sometimes the card simply "voices" the decision received from the issuer. In some cases, the card independently makes a decision delegated to it by the issuer using the appropriate mechanisms incorporated in the card application.
Examples of checks performed by the card are cardholder PIN verification, Card Risk Management checks, card issuer authentication, checks to confirm the integrity of the information received from the issuer.
In the case of an offline transaction, the issuer completely delegates to the card the function of making a decision on the result of the operation. Obviously, only the solutions of a card that has been proven to be authentic can be trusted. This is why strong authentication is so important.
Card authentication is carried out by the terminal and / or the card issuer. In offline operations, card authentication is performed only by the terminal and is called Offline Authentication. In the case of an online transaction, card authentication can be carried out by both the terminal and the issuer (for terminals operating only in real time, the so-called Online Only terminals, it is allowed that the card is authenticated only by its issuer). The card issuer authentication is called Online Authentication.
Since offline card authentication is an important element in the issuer's decision on the authorization of a transaction, the issuer must be able to verify that the terminal has authenticated the card. This is to avoid being tricked by an unscrupulous merchant (or service bank) into claiming that offline card authentication has been performed, even though this claim is untrue. The reason for the deception may be the savings of the merchant or the service bank in providing support for the card authentication function at the POS terminal.
There is a mechanism for checking the fact that the terminal has performed card authentication in the EMV standard, and it will be described in clause 4.5.
As will be shown in 6.6, card authentication is an effective means of combating card counterfeiting.
2. In the process of performing an online transaction, the IPC (via the terminal and the host of the servicing bank) exchanges messages with its issuer. In response to the authorization request of the servicing bank, the issuer informs the card of its final decision on authorizing the operation (reject or approve the operation). In addition, the issuer can send commands to the card with which the individual data objects of the card application will be modified. With these commands, the issuer can block the card application or even the entire card.
In order to increase confidence in the issuer's decisions (to avoid forgery of the issuer's decision by a third party), it is necessary to provide for the card issuer to authenticate. Issuer authentication is ensured by card verification of some special data item (ARPC) received by the card from the issuer's authorization response, as well as verification by the card of the Message Authentication Code (MAC) values contained in the issuer commands. The MAC value also ensures the integrity of the issuer's command data. All this will be discussed in detail in paragraph 3.15.
3. The IPC guarantees the issuer the inability to the holder of his card to refuse the result of the operation performed (non-repudiation). This is ensured by the fact that for each operation performed, the issuer receives at its disposal a special application cryptogram, which is the signature of the card of the most critical transaction data. The Issuer has the ability to check the applied cryptogram for compliance with the transaction data. The correspondence of the applied cryptogram to the transaction data confirms the fact of its execution.
4. The IPC allows checking the integrity of the data exchange between the card and the issuer, as well as the card and the terminal. The integrity of information exchange between the issuer and the card is ensured by using the MAC value contained in the commands sent by the issuer to the card. The integrity of the data exchange between the card and the terminal is ensured using the Combined Dynamic Data Authentication / Application Cryptogram Generation procedure, which will be described in detail in clause 3.12.2. Thanks to this procedure, it becomes possible to electronically sign the most critical data of information exchange between the card and the terminal.
To ensure the integrity of the data read by the terminal at the beginning of the transaction processing, the static card authentication method is used.
5. The IPC allows ensuring the confidentiality of data in information exchange between the card and the issuer, the card and the terminal. The confidentiality of data circulating between the card and the issuer is ensured by encrypting sensitive data using a symmetric encryption algorithm (3DES). An example is the encryption of the new cardholder PIN value contained in the issuer PIN CHANGE / UNBLOCK command, or the offline counter values of the card application sent by the card to its issuer in the Issuer Application Data object.
Confidentiality of the PIN-code value during its transfer from the terminal to the card during the implementation of the PIN Offline cardholder verification method is ensured using the asymmetric encryption algorithm (RSA) - see clause 3.13.
6. The IPC provides the issuer with mechanisms for reliable verification / authentication of the holder of his card. Here, first of all, it should be mentioned about the constantly expanding use of IPC for verification of the card holder by means of offline verification of the card holder's PIN-code by the card.
In addition, with the help of the IPC and a special reader, two-factor authentication of the IPC holder is realized. The reader, in response to the correct value of the PIN-code verified by the cardholder's card, generates a one-time password using the card's secret data, which is used by the cardholder to authenticate him in high-risk operations, for example, CNP transactions (see clause 6.1.3).
Taking into account the above, it is possible to summarize the contribution made by the microprocessor card to improving the security of financial transactions. The microprocessor card provides:
Let's start with a description of algorithms for computing a digital signature of data using asymmetric encryption algorithms. Digital signature of data is used in the procedures of offline static and dynamic card authentication by the terminal. The need to use asymmetric encryption algorithms in these procedures is due to the fact that the terminal does not have to possess the secrets of the card (symmetric encryption always implies that the participants in the information exchange know the shared secret).
In order for the terminal to be able to verify the digital signature of some card data, it is necessary to create a so-called PKI (Public Key Infrastructure) infrastructure. In the EMV standard, PKI infrastructure generally has a three-tier tree structure, the root of which is the Certificate Authority (CA) of the payment system. The payment system certification center generates pairs of private and public keys (RSA algorithm) and sends public keys to servicing banks for loading them into the payment system terminals.
At the second level of the PKI infrastructure tree, there are certification authorities of issuing banks that are members of the payment system. These authorities also generate RSA public / private key pairs and receive their public key certificates from the payment system certification authority. A public key certificate represents the details of a public key, including the public key itself, its validity period, issuer identifier, etc., signed by one of the private keys of the payment system certification authority. (For the formats of certificates, see clause 3.12.)
Finally, at the lower third level of the PKI infrastructure, the public and private keys of the issuer's cards are located. The private keys, as they should be, are stored in a protected area of the IPC memory and are inaccessible to external programs for the card. The public keys are first certified by the certification authority of the issuing bank. This means that the public keys, along with their details, are signed with one of the private keys of the card issuer. Further, the certificate of the card's public key is located in the memory of the IPC and becomes available to the terminal when it reads the card data.
The digital signature of any data, created using the private key of the card, is verified by the terminal as follows. First, the terminal reads the issuer's and card's public key certificates, as well as the data signed by the card, from the card. Further, using the public key of the system stored on the terminal, the terminal checks the correctness of the certificate (correct signature and format) of the issuer's key.
After proving the correctness of the issuer's public key certificate, the terminal uses this key to verify the correctness of the card's public key certificate. Finally, the terminal can now verify the digital signature of the card using its public key.
The correct signature of the card means that it was made with the card's private key corresponding to its issuer-certified public key. 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 a card by a bank authorized by the payment system to issue cards with its logo is proved. In other words, card authentication is provided in this way.
The procedures for calculating and verifying the digital signature S for a message M of length L bytes (Appendix A of Book 2 of the EMV standard) are described below. Hash hashing - SHA-1 algorithm. In addition, if the module in the RSA algorithm has a length of N bytes, then the digital signature in the EMV standard is calculated only for messages of at least N - 22 bytes in size. In the EMV standard, all signed messages are arranged in such a way that they have a length of at least N - 22 bytes (it should be noted that in EMV 4.0 it was possible to sign data of a shorter length).
Assuming L> N - 22, the algorithm for calculating the signature S for message M is as follows.
In practice, the most commonly used algorithm is 3DES with a double key size (ISO 11568-2), based on three times the DES algorithm described in the ISO 16609 standard. As noted in the appendix. In this book, 3DES is a block algorithm used to encrypt blocks (binary sequences) of 64 bits. If X is a block with a length of 64 bits and K = (K L || K R ) is a double key of 16 bytes, consisting of two parts K, and K R of 8 bytes each, then the result of encryption in blocks is calculated by the formula:
Y = DES3 (K) [X] = DESCKlHDES ^ KrXDESCKlKX]]].
Then, obviously, the decryption procedure is given by the formula:
X = DES -1 (K L ) [DES (K R ) [DES _1 (K L ) [Y]]].
Consider now the general case of applying the ALG symmetric encryption algorithm to an arbitrary length MSG message.
If the length of the MSG message is not a multiple of 8 bytes, you must create a message of the form MSG = (MSG || '80' || '00' || ... || '00'), where the number of added bytes like '00'h is that the length of the generated MSG message is a multiple of 8 bytes and the MSG is the shortest message of the specified type.
If the length of the MSG message is a multiple of 8 bytes, then the following previously agreed cases are possible:
MSG = MSG;
MSG = (MSG || '80' || '00' || '00' || '00' || '00' || '00' || '00' || '00').
The resulting MSG message is split into X 1 blocks ; ..., X k , each of which is 8 bytes long. The EMV standard deals with two data encryption modes called ECB (Electronic Code Book) Mode and CBC (Cipher Block Chaining) Mode.
1. ECB Mode. In this mode, blocks X 15 ..., X k after encryption are converted into blocks Y u ..., Y k , and Yj for i = 1, ..., k are calculated by the formula:
Yi = ALG (K) [XJ.
2. CBC Mode. In this mode, blocks X v ..., X k after encryption are converted into blocks Y], ..., Y k , and Y, for i = 1, ..., k are calculated by the formula:
= ALG (K) [Xj Ф Yi-J;
Y o = ('00' || '00' || '00' || '00' || '00' || '00' || '00' || '00').
Thus, as a result of encrypting the MSG message, the message Y = (Y x || ... || Y k ) is obtained .
Decryption of data is performed using the inverse transformation ALG 1 (K) [Xj] as follows.
1. ECB Mode. In this mode, the blocks Y], Y k after decryption are converted into blocks X ь X k , and X, for i = 1, k is calculated by the formula:
X i = ALG _1 (K) [Yj].
2. CBC Mode. In this mode, the blocks Y H ..., Y k after decryption are converted into blocks X 1? X k , and X, for i = 1, ..., k is calculated by the formula:
Xi = ALG-'CK) ^] © Yi_ i;
Y o = ('00' || '00' || '00' || '00' || '00' || '00' || '00' || '00').
To receive the encrypted message MSG, is necessary in the message MSG = (X x || ... || X to ) of the last block X to remove the tail of the form ( '80' || '00' || ... || '00 ').
In the EMV standard, an asymmetric encryption algorithm (RSA algorithm) can be used to encrypt the PIN-code value during its transfer from the terminal to the card - see clause 3.13.
3.11.3. Calculating the Message Authentication Code (MAC)
The calculation of the MAC value for a message of arbitrary length MSG is performed in accordance with the ISO / IEC 9797-1 standard using the block cipher algorithm used in the CBC mode. The size of the MAC value varies from 4 to 8 bytes. The MAC is calculated according to the algorithm below.
H about = ('00' II '00' II '00' II '00' II '00' II '00' II '00' II '00').
Further, if K = K L , that is, a single key is used, we put H k + ] = H k . If a double key K = (K L || K R ) is used, then we put H k + i = ALG (K L ) [ALG -1 (K R ) [H k ]]. The first case corresponds to ISO / IEC 9797-1 Algorithm 1 and the second to ISO / IEC 9797-1 Algorithm 3.
The MAC value is s (4 <s <8) to the leftmost bytes of the block H to + 1 .
Here, before continuing reading, it is strongly recommended that you familiarize yourself with the appendix. A and adj. B. These applications will allow you to understand the mathematical foundations of the cryptographic algorithms used, as well as get acquainted with the most famous algorithms for symmetric and asymmetric encryption. The appendices are written in such a way that any reader with the most modest knowledge of the basics of mathematics can learn the information they contain with the proper level of perseverance. As a result of acquaintance with applications the reader will be able to deduce the properties of cryptographic transformations necessary for him at any moment of time on his own without referring to other sources, evaluate their computational complexity and cryptographic strength. The appendices contain proofs of almost all of the statements made in them.
What tasks are solved by the IPC application using cryptographic functions to increase the security of transactions with plastic cards?
1. The most important basic problem solved by a card application using cryptographic methods is to ensure reliable authentication of the card application (more often they say, and we will adhere to the same terminology, card authentication, although it is more correct to talk about application authentication). Card authentication is understood as the process of proving its authenticity, i.e. the fact that this card (application) was issued by a bank authorized to issue cards by the corresponding payment system. Successful card authentication means that it has been proven that the card was issued by bank X, which is a member of payment system Y, which authorized bank X to issue cards of payment system Y. The reliability of the proof of the issue of a particular card by an authorized issuer depends on the card authentication method (see p. 4.
As previously mentioned, the IPC is a microcomputer capable of processing commands from a terminal and / or card issuer. Command processing is reduced to a series of checks performed by the card, as a result of which the card decides on the result of transaction processing. Sometimes the card simply "voices" the decision received from the issuer. In some cases, the card independently makes a decision delegated to it by the issuer using the appropriate mechanisms incorporated in the card application.
Examples of checks performed by the card are cardholder PIN verification, Card Risk Management checks, card issuer authentication, checks to confirm the integrity of the information received from the issuer.
In the case of an offline transaction, the issuer completely delegates to the card the function of making a decision on the result of the operation. Obviously, only the solutions of a card that has been proven to be authentic can be trusted. This is why strong authentication is so important.
Card authentication is carried out by the terminal and / or the card issuer. In offline operations, card authentication is performed only by the terminal and is called Offline Authentication. In the case of an online transaction, card authentication can be carried out by both the terminal and the issuer (for terminals operating only in real time, the so-called Online Only terminals, it is allowed that the card is authenticated only by its issuer). The card issuer authentication is called Online Authentication.
Since offline card authentication is an important element in the issuer's decision on the authorization of a transaction, the issuer must be able to verify that the terminal has authenticated the card. This is to avoid being tricked by an unscrupulous merchant (or service bank) into claiming that offline card authentication has been performed, even though this claim is untrue. The reason for the deception may be the savings of the merchant or the service bank in providing support for the card authentication function at the POS terminal.
There is a mechanism for checking the fact that the terminal has performed card authentication in the EMV standard, and it will be described in clause 4.5.
As will be shown in 6.6, card authentication is an effective means of combating card counterfeiting.
2. In the process of performing an online transaction, the IPC (via the terminal and the host of the servicing bank) exchanges messages with its issuer. In response to the authorization request of the servicing bank, the issuer informs the card of its final decision on authorizing the operation (reject or approve the operation). In addition, the issuer can send commands to the card with which the individual data objects of the card application will be modified. With these commands, the issuer can block the card application or even the entire card.
In order to increase confidence in the issuer's decisions (to avoid forgery of the issuer's decision by a third party), it is necessary to provide for the card issuer to authenticate. Issuer authentication is ensured by card verification of some special data item (ARPC) received by the card from the issuer's authorization response, as well as verification by the card of the Message Authentication Code (MAC) values contained in the issuer commands. The MAC value also ensures the integrity of the issuer's command data. All this will be discussed in detail in paragraph 3.15.
3. The IPC guarantees the issuer the inability to the holder of his card to refuse the result of the operation performed (non-repudiation). This is ensured by the fact that for each operation performed, the issuer receives at its disposal a special application cryptogram, which is the signature of the card of the most critical transaction data. The Issuer has the ability to check the applied cryptogram for compliance with the transaction data. The correspondence of the applied cryptogram to the transaction data confirms the fact of its execution.
4. The IPC allows checking the integrity of the data exchange between the card and the issuer, as well as the card and the terminal. The integrity of information exchange between the issuer and the card is ensured by using the MAC value contained in the commands sent by the issuer to the card. The integrity of the data exchange between the card and the terminal is ensured using the Combined Dynamic Data Authentication / Application Cryptogram Generation procedure, which will be described in detail in clause 3.12.2. Thanks to this procedure, it becomes possible to electronically sign the most critical data of information exchange between the card and the terminal.
To ensure the integrity of the data read by the terminal at the beginning of the transaction processing, the static card authentication method is used.
5. The IPC allows ensuring the confidentiality of data in information exchange between the card and the issuer, the card and the terminal. The confidentiality of data circulating between the card and the issuer is ensured by encrypting sensitive data using a symmetric encryption algorithm (3DES). An example is the encryption of the new cardholder PIN value contained in the issuer PIN CHANGE / UNBLOCK command, or the offline counter values of the card application sent by the card to its issuer in the Issuer Application Data object.
Confidentiality of the PIN-code value during its transfer from the terminal to the card during the implementation of the PIN Offline cardholder verification method is ensured using the asymmetric encryption algorithm (RSA) - see clause 3.13.
6. The IPC provides the issuer with mechanisms for reliable verification / authentication of the holder of his card. Here, first of all, it should be mentioned about the constantly expanding use of IPC for verification of the card holder by means of offline verification of the card holder's PIN-code by the card.
In addition, with the help of the IPC and a special reader, two-factor authentication of the IPC holder is realized. The reader, in response to the correct value of the PIN-code verified by the cardholder's card, generates a one-time password using the card's secret data, which is used by the cardholder to authenticate him in high-risk operations, for example, CNP transactions (see clause 6.1.3).
Taking into account the above, it is possible to summarize the contribution made by the microprocessor card to improving the security of financial transactions. The microprocessor card provides:
- physical protection of data stored on the card (tamper resistant & responsive device);
- reliable authentication of the card (card application) by the terminal and / or the card issuer (confirmation of the fact of the card issue by an authorized issuer of a known payment system);
- reliable authentication with the card of its issuer;
- reliable verification of the cardholder by checking the PIN-code online or offline;
- confirmation of the fact that a card transaction has been performed (it is impossible for a client to cancel an operation);
- guarantee of confidentiality and integrity of sensitive data in the “issuer-card” and “terminal-card” dialogs;
- the ability for the issuer to change the parameters of the card after its issue (for example, to block the card or its application, change the risk management parameters, etc.) while ensuring the issuer's authentication and the integrity of the issuer's command data;
- reliable two-factor authentication of the cardholder in high-risk transactions (for example, in CNP transactions);
- confirmation for the issuer of the fact that the terminal has performed offline card authentication.
- 3.11.1. Digital signature using asymmetric encryption algorithms
Let's start with a description of algorithms for computing a digital signature of data using asymmetric encryption algorithms. Digital signature of data is used in the procedures of offline static and dynamic card authentication by the terminal. The need to use asymmetric encryption algorithms in these procedures is due to the fact that the terminal does not have to possess the secrets of the card (symmetric encryption always implies that the participants in the information exchange know the shared secret).
In order for the terminal to be able to verify the digital signature of some card data, it is necessary to create a so-called PKI (Public Key Infrastructure) infrastructure. In the EMV standard, PKI infrastructure generally has a three-tier tree structure, the root of which is the Certificate Authority (CA) of the payment system. The payment system certification center generates pairs of private and public keys (RSA algorithm) and sends public keys to servicing banks for loading them into the payment system terminals.
At the second level of the PKI infrastructure tree, there are certification authorities of issuing banks that are members of the payment system. These authorities also generate RSA public / private key pairs and receive their public key certificates from the payment system certification authority. A public key certificate represents the details of a public key, including the public key itself, its validity period, issuer identifier, etc., signed by one of the private keys of the payment system certification authority. (For the formats of certificates, see clause 3.12.)
Finally, at the lower third level of the PKI infrastructure, the public and private keys of the issuer's cards are located. The private keys, as they should be, are stored in a protected area of the IPC memory and are inaccessible to external programs for the card. The public keys are first certified by the certification authority of the issuing bank. This means that the public keys, along with their details, are signed with one of the private keys of the card issuer. Further, the certificate of the card's public key is located in the memory of the IPC and becomes available to the terminal when it reads the card data.
The digital signature of any data, created using the private key of the card, is verified by the terminal as follows. First, the terminal reads the issuer's and card's public key certificates, as well as the data signed by the card, from the card. Further, using the public key of the system stored on the terminal, the terminal checks the correctness of the certificate (correct signature and format) of the issuer's key.
After proving the correctness of the issuer's public key certificate, the terminal uses this key to verify the correctness of the card's public key certificate. Finally, the terminal can now verify the digital signature of the card using its public key.
The correct signature of the card means that it was made with the card's private key corresponding to its issuer-certified public key. 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 a card by a bank authorized by the payment system to issue cards with its logo is proved. In other words, card authentication is provided in this way.
The procedures for calculating and verifying the digital signature S for a message M of length L bytes (Appendix A of Book 2 of the EMV standard) are described below. Hash hashing - SHA-1 algorithm. In addition, if the module in the RSA algorithm has a length of N bytes, then the digital signature in the EMV standard is calculated only for messages of at least N - 22 bytes in size. In the EMV standard, all signed messages are arranged in such a way that they have a length of at least N - 22 bytes (it should be noted that in EMV 4.0 it was possible to sign data of a shorter length).
Assuming L> N - 22, the algorithm for calculating the signature S for message M is as follows.
- 1.Using the SHA-1 algorithm, the value of the hash function H: = Hash (M) of message M is calculated. The size of H is 20 bytes.
- 2. The header of the data being signed is determined to be equal to the byte T = '6A'h.
- 3. The ending of the data to be signed is determined to be equal to the byte E = 'BCb.
- 4. Message M is divided into two parts M = (Ml | M2), where Ml is a message consisting of the leftmost N - 22 bytes of message M, M2 is a message consisting of the remaining L - N + 22 bytes.
- 5. Block X is determined: = (T || Ml || H || E) length N bytes.
- 6. The digital signature S: = Sign (X) is calculated.
- 1. It is checked that the length of the signature S is equal to N bytes. If this is not the case, the digital signature of the message M is considered invalid. Otherwise, the transition to the next step of the algorithm is performed.
- 2. The value X = Recovery (S) is calculated, where Recovery (S) is the inverse to RSA transformation.
- 3. The block X of length N bytes obtained at the previous step is divided into components T, Ml, H, E, where T and E are the first and last bytes of block X, H is a block of 20 bytes long preceding byte E, Ml is the remaining N - 22 bytes of block X, immediately following byte T to the first byte of block H.
- 4. The equalities E = 'BC'h and T =' 6A'h are checked. If at least one of them is not met, the digital signature of the message M is considered invalid. Otherwise, proceed to the next step.
- 5. Calculate M = (M1 || M2). When verifying the signature, the M2 value must be known. If this is not the case, the digital signature is considered invalid.
- 6. Hash (M) is calculated and the equality H = Hash (M) is checked. If it fails, the digital signature is considered invalid.
- 3.11.2. Encryption of transmitted information
In practice, the most commonly used algorithm is 3DES with a double key size (ISO 11568-2), based on three times the DES algorithm described in the ISO 16609 standard. As noted in the appendix. In this book, 3DES is a block algorithm used to encrypt blocks (binary sequences) of 64 bits. If X is a block with a length of 64 bits and K = (K L || K R ) is a double key of 16 bytes, consisting of two parts K, and K R of 8 bytes each, then the result of encryption in blocks is calculated by the formula:
Y = DES3 (K) [X] = DESCKlHDES ^ KrXDESCKlKX]]].
Then, obviously, the decryption procedure is given by the formula:
X = DES -1 (K L ) [DES (K R ) [DES _1 (K L ) [Y]]].
Consider now the general case of applying the ALG symmetric encryption algorithm to an arbitrary length MSG message.
If the length of the MSG message is not a multiple of 8 bytes, you must create a message of the form MSG = (MSG || '80' || '00' || ... || '00'), where the number of added bytes like '00'h is that the length of the generated MSG message is a multiple of 8 bytes and the MSG is the shortest message of the specified type.
If the length of the MSG message is a multiple of 8 bytes, then the following previously agreed cases are possible:
MSG = MSG;
MSG = (MSG || '80' || '00' || '00' || '00' || '00' || '00' || '00' || '00').
The resulting MSG message is split into X 1 blocks ; ..., X k , each of which is 8 bytes long. The EMV standard deals with two data encryption modes called ECB (Electronic Code Book) Mode and CBC (Cipher Block Chaining) Mode.
1. ECB Mode. In this mode, blocks X 15 ..., X k after encryption are converted into blocks Y u ..., Y k , and Yj for i = 1, ..., k are calculated by the formula:
Yi = ALG (K) [XJ.
2. CBC Mode. In this mode, blocks X v ..., X k after encryption are converted into blocks Y], ..., Y k , and Y, for i = 1, ..., k are calculated by the formula:
= ALG (K) [Xj Ф Yi-J;
Y o = ('00' || '00' || '00' || '00' || '00' || '00' || '00' || '00').
Thus, as a result of encrypting the MSG message, the message Y = (Y x || ... || Y k ) is obtained .
Decryption of data is performed using the inverse transformation ALG 1 (K) [Xj] as follows.
1. ECB Mode. In this mode, the blocks Y], Y k after decryption are converted into blocks X ь X k , and X, for i = 1, k is calculated by the formula:
X i = ALG _1 (K) [Yj].
2. CBC Mode. In this mode, the blocks Y H ..., Y k after decryption are converted into blocks X 1? X k , and X, for i = 1, ..., k is calculated by the formula:
Xi = ALG-'CK) ^] © Yi_ i;
Y o = ('00' || '00' || '00' || '00' || '00' || '00' || '00' || '00').
To receive the encrypted message MSG, is necessary in the message MSG = (X x || ... || X to ) of the last block X to remove the tail of the form ( '80' || '00' || ... || '00 ').
In the EMV standard, an asymmetric encryption algorithm (RSA algorithm) can be used to encrypt the PIN-code value during its transfer from the terminal to the card - see clause 3.13.
3.11.3. Calculating the Message Authentication Code (MAC)
The calculation of the MAC value for a message of arbitrary length MSG is performed in accordance with the ISO / IEC 9797-1 standard using the block cipher algorithm used in the CBC mode. The size of the MAC value varies from 4 to 8 bytes. The MAC is calculated according to the algorithm below.
- 1. The MSG message is converted into a MSG message by adding a mandatory '80' byte to the right and then a number of '00' bytes required for the size of the MSG message to be a multiple of 8 bytes. The received MSG message is split into MSG = (X x || ... || X k ) blocks of 8 bytes each.
- 2. Key K for calculating MAC can be single K = Kj and double K = (K L || K R ).
- 3. First encrypting units X x , ..., X to a CBC mode using the key K - K L . As a result, for i - 1, ..., k we get:
H about = ('00' II '00' II '00' II '00' II '00' II '00' II '00' II '00').
Further, if K = K L , that is, a single key is used, we put H k + ] = H k . If a double key K = (K L || K R ) is used, then we put H k + i = ALG (K L ) [ALG -1 (K R ) [H k ]]. The first case corresponds to ISO / IEC 9797-1 Algorithm 1 and the second to ISO / IEC 9797-1 Algorithm 3.
The MAC value is s (4 <s <8) to the leftmost bytes of the block H to + 1 .
