# EMV standard for creating/verifying a digital signature

The data field of the command contains the new parameter value and the value of the Message Authentication Code (MAC), which is used to ensure the integrity of the transmitted data and authenticate its source.

There is no data field in the response to the command. For a successfully completed command, SWl= ’90’h, SW2=’ 00Ti.

Security issues in the EMV standard

The most important feature of IPC is the support of the operating system for cryptographic functions. The use of these features by the card application can significantly improve the security of payment transactions. (Here, before continuing reading, it is strongly recommended to read the Appendix. A and ADJ. C. These applications will provide a deeper understanding of the mathematical foundations of algorithms used in cryptography, as well as familiarize you with the most commonly used algorithms for symmetric and asymmetric encryption today. Applications are written in such a way that the reader with minimal knowledge of mathematics and the corresponding perseverance, could at any time independently, without referring to other sources, deduce the properties of cryptographic transformations necessary for him, evaluate their computational complexity and cryptographic stability. The appendices contain evidence for almost all the statements made in them.)

What tasks are solved by the IPC application using cryptographic functions to improve the security of plastic card transactions?

The most important basic task that the card application solves using cryptographic methods is to provide authentication of the card application (more often, and we will stick to the same terminology, card authentication, although it is more correct to talk about app authentication). Card authentication refers to the process of proving its authenticity, i.e. the fact that this card (application) was issued by a Bank authorized by the corresponding payment system. Successful card authentication means that it has been proved that this card was issued by Bank X, a member of the payment system Y, which allowed Bank X to issue cards of the payment system Y. the Reliability of proof of the issue of a particular card by an authorized Issuer depends on the method of card authentication

As previously mentioned, the IPC is a microcomputer capable of processing input data received from the terminal and / or card Issuer. Data processing is reduced to performing a number of checks, based on the results of which the card makes a decision about the result of processing the transaction. Sometimes the card simply “voices” the decision received from the Issuer. In some cases, the card itself makes a decision delegated to it by the Issuer using the appropriate configuration of the card application.

Examples of checks performed by the card are verification of the cardholder’s PIN code, checks related to risk management( Card Risk Management), authentication of the card Issuer, and checks confirming the integrity of information received from the Issuer.

In the case of an offline transaction, the Issuer fully delegates to the card the function of making a decision on the result of the operation. It is obvious that only the solutions of the card, the authenticity of the Torah is proven and can be trusted. This is why its reliable authentication is so important.

Card authentication is performed 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, the card can be authenticated by both the terminal and the Issuer (for terminals that operate only in real time, the so-called Online Only Terminal, it is allowed that the card is authenticated only by its Issuer). Card authentication by the Issuer is called online Authentication.

Since card authentication is an important element of the Issuer’s decision on the result of transaction authorization, the Issuer must be able to verify that the card authentication terminal has been performed. This is required to avoid fraud by an unscrupulous merchant or service Bank claiming that the card was authenticated, although this statement does not correspond to reality. The reason for deception may be saving money of a merchant or servicing Bank to support the card authentication function on the POS-terminal.** The EMV standard has a mechanism for verifying that the terminal performs card authentication**

Card authentication is an effective tool to combat card fraud (Counterfeit).

In the process of executing an online transaction, the IPC interacts with its Issuer. The Issuer informs the card of its final decision to authorize the operation (reject or approve the operation). In addition, the Issuer can send commands to the card that will modify individual data of the card application, or block the card application or even the entire card. The Issuer’s commands that modify the card data are obviously used not only during the transaction, but also during the card personalization stage.

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 ensure that the card authenticates its Issuer. Issuer authentication is provided by checking the card for some special data element (ARPC) received by the card from the Issuer’s authorization response, as well as checking the card for Message Authentication Code (MAC) values contained in commands received to the card from the Issuer.

The IPC guarantees the Issuer that the cardholder cannot refuse the result of the performed operation (non-repudiation). This is ensured by the fact that for each operation, the Issuer receives a special application cryptogram, which is a signature of the most critical transaction data. The Issuer has the ability to check the applied cryptogram for compliance with the operation data. The compliance of the applied cryptogram with the transaction data confirms the fact of its execution.

The IPC allows you to verify the integrity of data exchange between the card and the Issuer, as well as the card and the terminal. Ensuring the integrity of information exchange between the Issuer and the card is carried out by using the MAC value contained in the commands sent by the Issuer to the card. The integrity of data exchange between the card and the terminal is ensured using the combined Dynamic Data Authentication/Application Cryptogram Generation procedure. This procedure makes it possible to electronically sign the most critical data of the card’s information exchange with the terminal.

The IPC allows you to ensure data confidentiality in information exchange between the card and the Issuer, the card and the terminal. The confidentiality of data that is circulating between the card and the Issuer is ensured by encrypting the secret data contained in the Issuer’s commands using a symmetric encryption algorithm (3DES). The confidentiality of the PIN code value when it is checked by the card in offline mode is ensured using an asymmetric encryption algorithm (RSA)

**Digital signature using asymmetric encryption algorithms**

Before proceeding to a detailed review of the implementation of the IPC functions listed above, let’s focus on the algorithms used in the EMV standard for creating/verifying a digital signature, calculating the MAC value, and encrypting the transmitted information.

Let’s start with a description of algorithms for calculating digital signatures using asymmetric encryption algorithms. The digital signature of data is used in the procedures for static and dynamic card authentication. The need to use asymmetric encryption algorithms in these procedures is caused by the fact that the terminal must not have card secrets (symmetric encryption always implies that participants in the information exchange know a common secret).

In order for the terminal to verify the digital signature of certain card data, it is necessary to create a so-called PKI infrastructure (PKI— Public Key Infrastructure). In the EMV standard, the PKI infrastructure generally has a three-level tree structure, the root of which is the certificate Authority (CA) of the payment system. The certification authority generates pairs of private and public keys (the RSA algorithm) and sends the certification authority’s public keys to the servicing banks for uploading to the payment system’s terminals.

At the second level of the PKI infrastructure tree, there are certification centers of issuing banks that are members of the payment system. These centers also generate pairs of public and private keys of the RSA algorithm and receive certificates of their public keys from the payment system certification center. A public key certificate represents the details of a public key, including the public key itself, its validity period, holder ID, and so on, signed by one of the payment system certification authority’s private keys.

Finally, the lower third level of the PKI infrastructure contains the public and private keys of the Issuer’s cards. Private keys, as they should be, are stored in a protected area of memory

IPC and are not available to programs external to the card. Public keys are first certified by the issuing Bank’s certification authority. This means that the public keys, along with their details, are signed with one of the private keys of the card Issuer. Then the card public key certificate is located in the MPC memory and is available to the terminal when it reads the card data.

The digital signature of any data on the card key is checked by the terminal as follows. First, the terminal reads the Issuer’s and card’s public key certificates from the card, as well as the data signed by the card. Then, using the system’s public key, the terminal checks the validity of the certificate (the correct signature and format) of the Issuer’s key. Thus, the terminal determines for itself that the scheme uses the key issued by the payment system to its participant. After proving the validity of the Issuer’s public key certificate, the terminal uses this key to verify the validity of the card’s public key certificate, thus establishing that the scheme uses a card issued by a member of the payment system, and that member of the payment system (the Issuer) was authorized by the latter to issue this card.

The terminal can then verify the digital signature. Validating the signature means that it was calculated using the card’s private key that corresponds to its certified public key.

The procedures for calculating and verifying the digital signature 5 for a message M with a length of L bytes are described below (Appendix A Of book 2 of the EMV standard). It is assumed that the RSA algorithm is used to create a digital signature (below, the SIGN function refers to the RSA conversion), and the SHA — 1 algorithm is used as the hash function. In addition, if the module of the RSA algorithm is equal to N bytes, the digital signature in the EMV standard is calculated only for messages of at least N-22 bytes in size. In the 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 even in the EMV 4.0 version, it was possible to sign data of a shorter length).

Under the assumption L>N-22, the algorithm for calculating the signature S for message M looks like this.

The hash function H:=Hash (M) is calculated.

The header of the signed data is defined as byte T = J6A’h.

The end of the signed data is determined to be equal to byte E = ‘ BC’h.

The message M is split into two parts Af = (Ml| / M2), where Ml is the message consisting of the leftmost N — 22 bytes of the message M, and M2 is the message consisting of the remaining L – N + 22 bytes.

A block X is defined with the length of N bytes X:=(T||M1||N||E).

The digital signature S:=Sign(X) is calculated.

Digital signature verification in the EMV standard is performed using the following algorithm.

We check that the length of signature 5 is equal to N bytes. If this is not the case, the digital signature of the message M is considered incorrect. Otherwise, go to the next step.

Calculate X = Recovery(S), where Recovery(S) is the inverse of the RSA conversion.

Divide the block X with a length of N bytes obtained in the previous step into the components X:=(T| / M1||NCE), where H is a block with a length of 20 bytes.

We check the equality E = ‘VS ‘and T =’ 6A’h. If at least one of them is not fulfilled, the digital signature of the message M is considered invalid. Otherwise, go to the next step.

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 incorrect.

We check the equality of H = Hash (M). If it is not executed, the digital signature is considered invalid.** Encryption of transmitted information**

The ALG symmetric encryption algorithm is used to encrypt data transmitted from the Issuer to the card. The choice of encryption algorithm is the Issuer’s choice, since the algorithm is used to encrypt data that circulates between the host and the Issuer’s card.

In practice, the 3DES algorithm with a double-size key (ISO 11568-2) is most often used, based on a three-time application of 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 64-bit blocks (binary sequences). If X is a 64-bit block and K = (KL\KR) is a 16 — byte double key consisting of two parts KL and KR of 8 bytes each, the encryption result of block X is calculated using the formula:

Y = DES3(K) [X] = DES(Kl) [DES~\Kr) [DES(KL) [X] ] ].

Then, obviously, the decryption procedure is given by the formula:

X=DE^(Kl) [DES(Kr) [DE^(Kl) [Y]]].

Let’s now consider the General case of applying the symmetric ALG 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 like MSG = (MSG||’80’||’00’||…||’00’), where the number of bytes added ’00’ is such that the length of the created MSG message is a multiple of 8 bytes, and MSG is the shortest message of the type specified above.

If the length of the MSG message is a multiple of 8 bytes, the following pre-specified cases are possible:

MSG = MSG;

MSG = (MSG| |’80’| |’00’| |’00’| |’00’| |’00’| | W| |’00’| / W).

The resulting MSG message is split into Xu blocks …, XP each of which is 8 bytes long. The EMV standard covers two data encryption modes, called ERU (Electronic Code Book) Mode and CBC (Cipher Block Chaining) Mode.

ECB Mode. In this case, the Hg blocks, …, XCS are converted to Yv blocks after encryption …, Y^ and Y. when / = 1,…, K is calculated using the formula:

^=A1_C(K) [X;].

CBC Mode. In this case, blocks Xv …, HC after encryption are converted to y blocks, …, Y^ and Y. when /=1, …,K is calculated using the formula:

Y0 = (‘OO’i I ’OO’i I ‘OO’i I ‘OO’i I ‘OO’i I’ OO’i I ’00’).

Thus, the result of encrypting the MSG message is the message Y = (KJ |… | |By^).

Data is decrypted using the reverse transformation ALG~l (K) [X] as follows.

- ERU Mode. In this case, yy blocks …, Yk after decryption are converted to XX blocks, …. X^ and X. for i = 1,…,K is calculated using the formula:
- SVS Mode. In this case, Yv blocks …, Yk after decryption are converted to XX blocks, …, X^ and X. when ; = 1,…, K is calculated using the formula:

Hg=M. 6-\K)\U,]®U, _i

Y0 = {‘OO’i I ‘OO’i I ‘OO’i I ‘OO’i I ‘OO’i I ’00’ (I ’00’).

To get an encrypted MSG message, you must use the message MSG = (Ha| |… CH*) remove the tail from the last block of the HC

The EMV standard uses an asymmetric encryption algorithm (RSA algorithm) to encrypt the PIN code value when it is transmitted from the terminal to the card (see clause 3.13).

The calculation of the Message Authentication Code (MAC)

The MAC value for an arbitrary length MSG message is calculated in accordance with the IS0/IEC 9797-1 standard using a block encryption algorithm with a block size of 64 bits, used in SHS mode. The size of the MAC value varies from 4 to 8 bytes. MAC is calculated using the algorithm below. - The MSG message is converted to an MSG message by adding the required byte ’80’ to its right and then a certain number of bytes ’00’ required for the MSG message size to be a multiple of 8 bytes. The received MSG message is divided into blocks MSG = (A’1| |… | size of 8 bytes each.

The key To calculate MAC can be single K=(KL) and double K = (KL\KR). In the first case, DES is used as the encryption algorithm, and in the second case, 3DES is used.

First, blocks XX, Are encrypted …, HC in SVS mode using the key (KL). As a result, for /=1, we get

H^ALG^m ®N^],

H0 = soo and I ‘and OO ‘OO and I OO I I I I OO ’OO and ‘OO and ’00’).

Further, if K = [KL), we assume HM = HK. If K = (KL\ \ CR), then we assume HK+1=ALG (KL)[ALG~1 (CR) [HK]]. The first case corresponds to the algorithm 1 IS0 / IEC 9797-1, and the second-3 3 IS0/IEC 9797-1.

Mac Mac equals S (4 < S < 8) to the leftmost bytes of the NC+y block

Offline card authentication methods

As previously noted, the card authentication procedure is a key element of the security of operations performed using IPC. Em EMV (V. 4. 1) distinguishes three methods of offline card authentication:

SDA (static data authentication, static authentication)

DDA (dynamic data authentication, dynamic authentication).

CDA (Combined Dynamic Data Authentication/Application Cryptogram Generation, combined authentication).

The DDA and CDA methods REQUIRE the card to SUPPORT the RSA ALGORITHM.

The terminal selects the authentication method based on the AIP data (application exchange profile, tag ’82’) and the terminal’s capabilities (see clause 4.5). Let’s start our review of offline card authentication methods by considering the simplest method of static authentication.

Static data authentication (Static data authentication, sda)

The meaning of static authentication is that some of the most” important “(functionality-critical) card application data contained in the static data object for authentication is signed with the card Issuer’s secret key and stored on the card at the stage of its personalization as a data object signed by the static data application (tag ’93’).

During the transaction, the terminal reads the signature of this data from the card, and the signed static application checks its data as well. If the signature is correct, the card is considered to have successfully passed the static authentication procedure.

Thus, static authentication of the card is not actually an authentication (confirmation of the card’s authenticity). Static authentication is only a means of ensuring the integrity of certain data that is critical to the card application, i.e. that it is not possible to modify this data in such a way that its change is not noticed during the transaction.

Data critical to the application is determined by the card Issuer. This data usually includes the card number, its expiration date, data on the geography of card servicing and operations available on the card (application usage control), Profile (application exchange profile) , and others.

When performing a static authentication procedure, critical data is taken from the static data object for authentication. This object is not stored on the card and is generated during the transaction using the AFL object (application file locator) list list of SDA tags

Note that card support for the static authentication method is mandatory, unless the card is only used in ATMs (Card is only an ATM card).

Static authentication is essentially the equivalent of CVV / CVC verification performed for magnetic stripe cards. The only difference is that sda allows you to ensure the integrity of a much larger amount of data in the Issuer’s application, as well as perform offline authentication of the card using the Bank’s terminal (CVV / CVC is verified by the card Issuer). In order for static authentication to be performed by any terminal in the system, asymmetric encryption (the RSA algorithm) and a two-level PKI structure are used

Distributed to the buyer (located in the terminal)

Buyer

P, certified

Connection between the IC card and the terminal

The card provides access to the terminal:

P., certified by the certification body

Digitally signed card data

Terminal;

Uses the PCA to verify that the Issuer’s P was certified C A

Uses P to verify the digital signature of the card data

Rice. 3.11. Diagram of static authentication of the card

To perform static authentication, the card must store the following data elements:

Index of the certification authority’s public key (Tag ‘8F);

Issuer’s Public Key Certificate (Tag ’90’);

The remainder of the Issuer’s public key (tag ’92’), if the length difference between the system’s public key modules and the Issuer’s public key is less than 36 bytes;

The Issuer’s public key exponent (tag ‘9F32’);

Signed Static Application Data (Tag ’93’).

To describe the SDA method, enter the following notation:

Nca-length (in bytes) of the payment system certification authority public key module;

NI-length (in bytes) of the card Issuer’s public key module. Em EMV performs inequality 248.

As already noted, the payment system transmits its public keys to its servicing banks for uploading them to the terminals that service the cards. In accordance with paragraph 5 of Book 2 of the EMV 4.1 standard, the terminal must be able to store up to 6 public keys with their details for each RID (currently, RID defines the payment system). Index rid Index the index of the certification center’s public key (tag ‘8F) with the size of 1 byte. Index public key index of the certification center, rid rid, Aid 5 Aid Aid. If the terminal does not find the key with the ID received from the card, it is considered that static authentication failed (traffic rules failed).

Certificate certificate of the Issuer’s public key (tag ’90’). The size of the value field for this data object is zero. In table. 3.12 Certificate signed by the payment system certification authority, Issuer certificate of the Issuer’s public key (tag ’90’).

Authentication the 2-byte data authentication code (DAC) is a static characteristic of the card USED by the ISSUER to VERIFY that the TERMINAL HAS completed the STATIC card AUTHENTICATION PROCEDURE. The DAC element is either some random variable stored for each card in the Issuer’s database, by the Issuer, or is calculated, for example, by the card number (tray) and tray sequence number. As an algorithm for calculating the DAC, 3DES is often used with a separate Issuer key specially designed for this purpose. The DAC element is loaded to the card during the personalization process.

In accordance with EMМ 4.1, static application data signed by the Issuer is defined in static authentication data.