ARQC cryptogram generation

The CAP standard defines the most common OTP generation algorithm in the banking sector.
The essence of CAP technology is as follows. It is assumed that the client has:
a card with a standard EMV application that supports the PIN Offline cardholder verification method;
a special device with a screen, keyboard, special buttons and a card reader for IPC (we will continue to call it a reader, in the literature it is often called PCR-Personal Card Reader).
After the customer has inserted the card into the reader, the latter offers the cardholder to choose one of several options, for example: getting a signature, generating a one-time password, and preparing a response to the cardholder’s verification request.
After selecting an option and possibly entering some operation parameters by the client on the keyboard, the reader prompts the cardholder to enter the value of their PIN code. If the client has selected the option to generate a one-time password and the PIN value entered by the client is correct, the reader displays a number on its screen that is a one-time dynamic password of the cardholder used to authenticate the cardholder during this operation. This password can, for example, be used to authenticate the cardholder by the Issuer’s Access Control Server when the cardholder performs an e-Commerce operation using the 3D Secure Protocol.
If the cardholder has selected the option to get a data signature, the card uses the reader to generate a signature of the data entered by the client on the screen. The received signature is used both for authentication of the cardholder (only the cardholder could form such a signature) and for ensuring the integrity of the signed data. Such a signature can act as a cryptogram of the operation being performed, thereby ensuring that the client cannot refuse the performed operation (non-repudiation).
If the option to prepare a response to the cardholder verification request was selected, the card uses the reader to sign a random number contained in the cardholder verification request. This ensures authentication of the cardholder with reference to a specific operation (a random number is generated by the Issuer for a specific operation).

Readers used in CAP/DPA programs can be standalone (without network interfaces) or connected to the cardholder’s computer. In the latter case, it is easier for the cardholder to enter transaction parameters. You don’t need to enter them using the reader’s keyboard, because a computer program can do this for the card holder. In addition, in this case, if there is a special client application on the cardholder’s computer, it is possible to perform online operations on the card.
However, in most cases, banks use standalone readers. They do this for security reasons (to limit access to the reader with the card over the network) and because the amount of data entered by the cardholder on the reader’s keyboard is small.
The General scheme for implementing the CAP Protocol is as follows. The reader emulates the operation of the POS terminal and initiates the operation after the card is inserted into the reader. At the beginning of the operation, the reader can request information from the cardholder about the size and currency of the transaction, as well as about a random number of challenges, which can be the transaction details provided to the cardholder by the authenticating party. However, the reader does not perform offline card authentication or risk management procedures, and in the first GENERATE AC command, it requires the card to generate an ARQC cryptogram.
The card application must support offline pin Code verification-the Plaintext PIN Offline and/or Encrypted PIN Offline methods. In addition, it must be personalized so that the reader selects one of the PIN Offline cardholder verification methods from the CVM list (for example, the PIN Offline method must be the first CVR rule in the CVM List; it is sufficient that this method is supported by the card and the 7-byte CVM Code bit for all card-supported verification methods is equal to 1). The reader itself only supports the Plaintext PIN Offline and Encrypted PIN Offline cardholder verification methods.
If PIN verification is successful, the reader sends the GENERATE AC command to the card, requiring the generation of the ARQC cryptogram. After completing the risk management procedures and deciding how to complete the transaction, the card can respond to the reader by generating an ARQC or AAC cryptogram. If an AAC is generated, the operation is terminated. If an ARQC cryptogram is generated, the reader sends the second GENERATE AC command to the card, requesting the AAC cryptogram and specifying the authorization Response Code Z3 to the card (the request cannot be transmitted online, it was rejected offline).

The reader will ignore the response received from the card to the second GENERATE AC command (i.e. the ARQC cryptogram received in response to the first GENERATE AC command will be used to calculate THE cap Token). Based on the Z3 code, the application will set the Unable to go online flag in the CVR object. In addition, if the VSDC application does not receive a response from the Issuer, the application will set the last Online Transaction not Completed flag in the CVR object.
After receiving a response from the card to the first GENERATE AC command, the reader uses the data received in the response to calculate a certain amount called CAP Token, the size of which varies from 6 to 16 decimal digits. Since THE cap Token value contains individual bits of the cryptogram, it is used for authentication of the card application. If the value of the CAP Token has successfully passed the verification procedure, then the cryptogram of the transaction that was used to calculate the CAP Token will also pass it with a high probability. The CAP Token value is displayed on the reader display and is then used by the cardholder for authentication, for example, when logging in to an online banking system or performing an e-Commerce transaction.
Thus, the CAP method implements two-factor authentication of the Bank’s client: the latter must have a Bank card (to generate a cryptogram) and know their PIN code.
Two important points should be made here. The first relates to the application that implements the authentication of the card holder. This application can be a special separate application used by the card Issuer solely for authentication of the cardholder in accordance with the CAP Protocol(this application is not used for performing financial transactions). It can also be a General-purpose application that is used, among other things, for performing operations in POS terminals and ATMs. Payment systems recommend that banks use a special separate application to authenticate the cardholder. In the leading payment systems, a special extension of the application ID PIX=8002 is allocated for this particular application.
There are several reasons why payment systems recommend using a separate application for cardholder authentication. First, using the payment app to authenticate the cardholder may result in the transaction being rejected offline (the payment app will return the AAC cryptogram to the reader). The result can change offline card counters (such as in the VSDC app), which will affect the further use of the payment app.
Secondly, the peculiarities of implementing cardholder authentication by the terminal affect the behavior of the payment application. For example, as we remember, in the second command GENERATE AC, if it comes to it, the terminal requires the card to return the AAC cryptogram, passing the authorization code of the response Z3 to the card. As a result, the last online transaction not completed bit of the CVR object of the VSDC application will be set to 1. This fact may require you to perform the following operation using the online payment application (this bit is reset in the CVR only as a result of successful authentication of the card Issuer).
Third, as will be seen below, the size of the CAP Token value generated by a separate application is smaller than the same size for the case of using a regular payment application. The cap Token size is a critical parameter that determines the usability of CAP technology.
Fourth, checking the CAP Token value in the Issuer’s system (the subsystem that verifies the CAP Token values is called the CAP Token Verification System, or CTVS for short) is easier if a separate application is used. When using a regular application for cardholder authentication, you must ensure that the Issuer’s system and CTVS data (keys, card counters, and so on) are synchronized.
Finally, fifth, using different applications increases the security of the payment service and the cardholder authentication service.
The second point concerns the behavior of a special application. We recommend that you personalize the special application so that the reader always receives the ARQC cryptogram from the card in response to the first GENERATE AC command. This behavior allows the application to minimize the amount of data to be transmitted to the Issuer to validate the value Token CAP, making predictable values of all bits of the object CVR, and does not change the values offline counter app that allows you to not care about the values of the limits for these counters. This will be discussed in more detail below.
From the above remarks, the answer to the question of whether to generate AC for the return of the AAC cryptogram follows. This approach would greatly simplify working with the card and reduce the spread of card response values. The answer is simple. The reader requests the arqc cryptogram from the card in order to Cap the card’s payment application. Generate generating AC of the AAC cryptogram can lead to changes in the offline counters of the payment application. For example, this happens in an application in flash Integro when a transaction is rejected offline and the corresponding conditions for changing the offline counter values of this application are met (see clause 11.5.1 of the vis 1.4.0 specification).
Token, Token Cap Token, Cap Cap Token. Transaction data is requested from the cardholder by the reader and entered by the cardholder using the reader’s keyboard. Mod Protocol the following is the Definition of cover.
Mode 1: the call (required element), transaction size and currency (optional), and transaction size only (optional) are used to calculate the AC cryptogram.
Mode 2: AC AC no transaction data is used.
Mode 2 with TDS: AC AC no transaction data is used. Transaction data (up to 10 fields, each with a maximum size of 10 characters) is used to calculate the token cap. During the calculation process, the token cap is determined by the transaction data MPC. To do this, the algorithm IS0 9797-1 algorithm 1, which uses the previously obtained applied cryptogram as the key, and DEZ is used as the ALG algorithm.
Mode 3: Mode 3 Mode 1, challenge AC Challenge challenge.
Mode mode 1 mode 2. Mode 2 with TDS and mode 3 for It are optional.
The client selects the cover mode at the beginning of the authentication procedure. To do this, use the corresponding reader buttons. Sign (signature of transaction details), identification (generating a one-time password for the cardholder) verify verification (generating a response to the cardholder’s verification request). In this case, each button is implemented by one of the cover Protocol modules. Examples of using the header mod to implement various functions
The signature function is useful for organizing services that require not only authentication of the cardholder

Examples of using the header mod

Function Example of using the cover Mods used to implement the function
3D Secure CNP-Mode mode 1, Mode 3
Identification of the electronic banking login mode 2
Sign Mode Mode 2 with TDS
Check the input mode in the electronic banking system 3

Confirmation of the client’s inability to refuse the service provided to him. An example of such a service is Internet banking. Indeed, when ordering a service on the Bank’s website, the cardholder receives a page with a request to confirm the order and insert a signature number in a certain field of the page. The signature number is formed for a decimal number present on the Bank’s website page, usually representing the value of some hash function from the parameters of the service provided to the client, generated by the Internet banking system. The card holder inserts the card into the reader, sign sign, PIN code and number from the Bank’s website page. As a result, the reader displays a decimal number, which is inserted by the customer in the signature field on the Bank’s website page. In this way, the client simultaneously authenticates himself and signs that he has made a transaction in the Internet Bank.
Mode, Mode mode 1, flags flags of the Issuer’s applications (IAF, tag ‘9f55’), whose data field has a size of one byte
Mode 6.2 Mode, Mode, Mode mode 1. Token IAF also determines the need to use PSN Token Cap Token bits, which will be discussed in more detail below. If the IAF data object is not present in the application selected by the reader, the reader considers its default value to be ‘ 00’h.
The General scheme of processing of the transaction
In response to the first Create AC command, the card returns the reader data objects for the SDR, ATC, AC, and IAB. It would be possible to provide the received data, supplemented with information on the card (Pan, PSN) and operations (size and currency of the transaction, Challenge), for verification in the Issuer’s system. The essence of the Issuer’s verification would be to determine the appropriate

Structure of the object’s data field flags Issuer’s application

b8 b7 b6 b5-b1 bit Value
X quantity and currency indicator. Mode mode 1
0 neither the transaction size nor its currency is used for generating AC
1 Or the size of the transaction, AC
X tray sequence number indicator
0 PSN is not included in the cap sign
1 Bits the PSN includes a marker cap
x ignore the currency indicator. Mode mode 1
0 transaction Size and currency are used if B8 = 1
1 only the transaction size is Used if B8 = 1
xxxxx Reserved bits
00000 Not used

The data received by the Issuer corresponds to the value of the applied AC cryptogram.
However, this method of verification is not feasible in practice. When using it, the cap marker value can be a number consisting of 104 decimal digits. Indeed, the data fields of the SDR, ATC, AC, and IAD objects are equal to 1, 2, 8, and 32 bytes, respectively (the size of the IAD data field is 32 bytes for the kVA application). This means that the cap marker resulting from the listed data concatenation will have the size 28(1+2+32) = 2344 ≈ 3,58 · 10103. Obviously, it will be problematic to display such a number on the reader’s display, and even more so to report it to the Issuer’s system without errors. When using this number, it is too likely that the client will make an error when entering it, and typing it on a computer (if the cap is used in e-Commerce or Internet banking) is long and time-consuming.
Therefore, the main purpose of cap is to squeeze the maximum data received in response to the reader generating an alternating current in order for them to establish the value of the cap of the marker, the value of which, despite the compression, on the one hand, it is difficult to guess, and on the other it is still possible to check in the system ctvs (enough data to check).
To determine the data compression algorithm, consider the options that you want to include in the cap of the marker. Once again, the main

General scheme of the authentication procedure

the idea of checking the cap marker is that the system can check the cryptogram of the operation (or its individual bits) obtained as a result of the reader’s dialogue with the card by the value of the cap marker. This means that a necessary condition for the implementation of the cap is the ability of the TTC to calculate on its side the cryptogram returned by the card to the reader.
To calculate a cryptogram, the ctvs system needs to know the values of the following values:
PAN PS PSN for generating a card key intended for generating a cryptogram. This key is calculated using

key of the Issuer, CT ctvs. The card number is passed to the Issuer separately from the token cap within the operation in which the cardholder is authenticated. Token PSN (or its individual bits), Token, Token cap token;
Issuer key index the key derivation index (DKI), CT ctvs defines the Issuer key for generating the cryptogram. This index is a component of the IAD object, generate generate AC;
the ATC transaction number returned to the reader in response to the AC generation command;
CVR card data returned to the reader as part of the iAd;
transaction and reader data passed to the card in the AC generation command according to the CDOL1 list.
Data used by the card to generate an applied cryptogram

Data used by the card when generating a cryptogram

Data element Value
Amount authorized, tag ‘ F02 ‘ by default 00 00 00 00 00 00
Amount, other, tag ‘9F03 ‘ 00 00 00 00 00 00
The country code of the terminal tag ‘9F1A’ 00 00
Terminal Verification Results, Tag ‘ 95’ 80 00 00 00 00
Transaction currency code, tag ‘5F2A’ By default 00 00
Date of the transaction, the tag ‘9A ‘ 00 00 00
Type of transaction, the tag ‘9C ‘ 00
Unpredictable number, tag ‘9F37’ By default 00 00 00 00
App sharing profile, tag ‘ 82 ‘ XX XX
Application transaction counter (ATC), tag ‘9F36’ XX XX
card validation results (CVR) the data Field for this object is 4 vs VSDC, 5 C CPA, and 6 M M / Chip 4

As can be seen from table 6.3, all data, at ATC and CVR, are fixed, and therefore known to the card Issuer.

Thus, the task of compressing the data included in the cap sign is reduced to compressing the following data:
ARQC cryptograms generated by the card in response to the reader’s first command to generate AC;
PSN;
AIR TRAFFIC CONTROL;
DKI;
KAPPA.
Let’s run through this data and see to what extent it can be compressed.
The cryptogram contains 64 bits of information and is a cryptographic function of the variables specified in table 6.3. the Fraudster, not knowing the card key to generate the cryptogram, can only guess the value of the cryptogram. If we leave only n bits in THE cap Token (out of 64 possible ones), then the probability of their guessing is 2–n. Obviously, there is no point in making the probability of guessing the cryptogram bits left in the CAP Token higher than the probability of guessing the client’s PIN code (the second factor of cardholder authentication). The probability of guessing both factors will be negligible even if the probability of guessing each factor is at the level of the probability of compromising the PIN code.
If a 4-digit PIN code is used and the fraudster has three attempts to match its value, the probability of guessing the PIN code value is approximately 3 · 10-4. A similar probability of guessing the bits of a cryptogram can be obtained using 12 bits of the cryptogram (the cryptogram can only be guessed once, since it is a dynamic value and will take a different value the next time you try to guess it). Since the CAP Token is checked in HSM modules, it is desirable that the size of the part of the cryptogram left in the CAP Token be a multiple of 8 bits (byte size). Therefore, payment systems recommend leaving at least 16 bits of cryptogram in THE cap Token.
The PSN parameter can be used by an Issuer to issue multiple cards under the same number. Often issuers do not use PSN. In this case, the PSN will not be included in THE cap Token either. As noted above, the fact that the PSN is used to generate the CAP Token is reflected by bit 7 of the IAF object.
If THE PSN is still used by the Issuer, it consists of two decimal digits (encoded by a single byte). The highest digit of the PSN is usually used to identify different cardholders using a common card number (for example, members of the same family). The lower digit of the PSN determines the reissue cycle of the card with this number. If, for example, the number of reissues of the card is no more than 3 and the number of holders per card is no more than 3, then it is enough to leave the last two digits of EACH nimbus of the byte representing the PSN in THE cap Token. In this case, it will be enough to include 4 PSN bits in THE cap Token instead of the initial 8 bits.
The value of the ATC transaction counter is encoded in two bytes. It is obvious that the maximum number of transactions, which is equal to 65,535 transactions, is not likely to be reached during the entire life cycle of the card in practice. Indeed, if you consider a very active cardholder who performs 14 transactions every day during the entire three-year validity period of the card, they will be able to make only 15,330 transactions. To encode ATC in this case, it is sufficient to allocate 14 ATC bits.
You can also split the ATC number into two parts: the lower m bits that are included in THE cap Token, and the remaining higher bits that are stored in CTVS and not included in the CAP Token. In this case, if m is large enough, the CTVS system will be able to uniquely determine the ATC value from the m value when performing the next cardholder authentication. Indeed, if the m digits of the current ATC value received by CTVS are greater than the last m digits of the last ATC value stored in CTVS, then the highest ATC bits stored in CTVS are added to the digits received from THE cap Token to form the ATC. Otherwise (CTVS received m digits of the current value of the ATC is not greater than the last m digits memorized the last value in ATC CTVS) CTVS increments the number of bits of the ATC rooms, stores it in a binary representation instead of the old value and adds new value to the left high-order bits to m bits, from the received CAP Token.
If m is large enough, for example, m = 7, this mechanism will allow you to reliably restore the ATC value, provided that no more than 255 payment transactions are performed between two consecutive authentications of the cardholder. In practice, this m value is sufficient to restore the ATC value in the CTVS system.
The Issuer can use different keys to generate their card keys. Usually, each bin of the Issuer corresponds to a certain set of its keys. This is done for reasons of ease of key management. For example, this correspondence between BIN and the Issuer’s key sets exists in the backup authorization systems of the leading payment systems. In backup authorization systems, there is a limit on the number of Issuer keys assigned to a single BIN value. For example, in the VISA system, this number is limited to 24 keys. This means that it is sufficient to use 5 bits of information to encode the DKI index. In practice, it is often enough for the Issuer to have no more than 7 keys per BIN, for which it is enough to include three lower bits of the DKI representation in THE cap Token.
Finally, let’s look at ways to compress information for a CVR object. It is obvious that the number of CVR bits that are sufficient to leave in THE cap Token in order to restore the entire CVR data object in the CTVS system depends significantly on whether the application used is a special application for cardholder authentication, or it is a normal payment application of the Issuer. Let’s illustrate this with the example of the CVR application VSDC of the VISA payment system. Table 6.4 shows the CVR bit values for the case of a dedicated application. Recall that this CVR value is generated by the card as a result of performing the risk management procedure after receiving the first GENERATE AC command. It is also assumed that the special application is configured in such a way that the standard reader requests always return the ARQC cryptogram.

CVR bit values of the dedicated VSDC application

Byte number Bits Purpose of bits and their possible values Expected value of bits
Byte 1 Bits 8-1 Length of the CVR data field 00000100
Byte 2 Bits 8-7 00-AAC in response to 2nd GENERATE AC 01– TC in response to 2nd GENERATE AC 10-command 2nd GENERATE AC
not requested
11-the value is not used
00– AAC in response to 1st GENERATE AC 01– TC in response to 1st GENERATE AC 10– ARQC in response to 1st GENERATE AC 11– AAR in response to 1st GENERATE AC
1= Issuer Authentication was performed and failed
1= PIN Offline verification was performed 1= PIN Offline verification failed
1= the terminal cannot send a transaction to the Issuer (unable to go online) 10

The end of the table.

Byte number Bits Purpose of bits and their possible values Expected value of bits
Byte 3 Bit 8 1= last online transaction not completed
1= PTL is exceeded
1= exceeded offline counters 1= new card
1= Issuer authentication failed during the last transaction
1= Issuer authentication was not performed after online authorization
1= the app is blocked by the card because the PTL is exceeded
The SDA failed during the last transaction and the transaction was rejected
offline 1
Bit 7 0
Bit 6 0
Bit 5 1
Bit 4 0
Bit 3 0
Bit 2 0
Bit 1 0
Byte 4 Bits 8-5 Number of issues Script Processing commands processed in the last transaction
1= the issue Script Processing Procedure failed during the last transaction
1= DDA/CDA failed during the last transaction and the transaction was rejected offline
1= offline dynamic authentication was performed
Not used 0000
Bit 4 0
Bit 3 0
Bit 2 0
Bit 1 0

The table shows that all bits of the CVR object are predictable when using a dedicated application for cardholder authentication, so there is no need to include them in THE cap Token.
The situation changes when using a regular payment app. See table below. 6.5 the values of the CVR bits in this case are shown.
The bit values indicated by x are not predictable and depend on the VSDC application configuration and the card application background. As a result, the CAP Token will need to include 10 CVR bits, whose values are not predictable and cannot be restored in CTVS.
Above, we have considered the data bits that need to be included in THE cap Token so that it is possible to calculate the cryptogram in CTVS. Now let’s focus on the method of calculating THE cap Token. Obviously, all the bits included in THE cap Token can be obtained from the card’s response to the first GENERATE AC command(CID, ATC,AC,IAD) and PSN. Indeed, the DKI and CVR are included in the AID object. The ATC and cryptogram values are directly contained in the response to the GENERATE AC command.

CVR bit values when using the VSDC payment application

Byte number Bits Purpose of bits and their possible values Expected value of bits
Byte 1 Bits 8-1 Length of the CVR data field 00000100
Byte 2 Bits 8-7 00-AAC in response to 2nd GENERATE AC 01– TC in response to 2nd GENERATE AC
10-the 2nd GENERATE AC command was not requested 11-the value is not used
00– AAC in response to 1st GENERATE AC 01– TC in response to 1st GENERATE AC 10– ARQC in response to 1st GENERATE AC 11– AAR in response to 1st GENERATE AC
1= Issuer Authentication was performed and failed
1= PIN Offline verification was performed 1= PIN Offline verification failed
1= the terminal cannot send a transaction to the Issuer (unable to go online) 10
Bits 6-5
x0

Bit 4
0
Bit 3 1
Bit 2 0
Bit 1 0
Byte 3 Bit 8 1= last online transaction not completed
1= PTL is exceeded
1= exceeded offline counters 1= new card
1= Issuer authentication failed during the last transaction
1= Issuer authentication was not performed after online authorization
1= the app is blocked by the card because the PTL is exceeded
The SDA failed during the last transaction and the transaction was rejected
offline x
Bit 7
Bit 6
Bit 5
Bit 4 0
x x x
Bit 3 0
Bit 2 0
1 x bit
Byte 4 Bits 8-5 Number of issues Script Processing commands processed in the last transaction
1= the issue Script Processing Procedure failed during the last transaction
1= DDA/CDA failed during the last transaction and the transaction was rejected offline
1= offline dynamic authentication was performed
00xx is not used
Bit 4 x
Bit 3 x
Bit 2 0
Bit 1 0

Therefore, to get the CAP Token, the reader generates the data string shown in figure 6.3.the String is formed from the card response to the GENERATE AC command, which is joined to the PSN data element on the left, if necessary.

Data used to generate the CAP Token

The need to attach a PSN is determined by bit 7 of the IAF object. Now, in order to get the CAP Token value, the Issuer Proprietary Bitcard data object (IPB, Tag ‘9F56’) is used. It is superimposed on the reader’s data string and the values of the bits opposite the ‘1’ IPB bits are extracted from it. The resulting binary sequence is represented as a decimal number, which is the CAP Token.
The structure of the IPB object obviously defines the data compression mechanism discussed above. Bits ‘ 1 ‘ correspond to the bits of the string in figure 6.3 that should be included in the CAP Token object.
If the IPB data object is not present in the app, the reader uses its default value, which is stored in the reader and determined by the payment system.
It should be recalled that the above algorithm for calculating THE cap Token is valid for all cap modes with the exception of Mode 2 with TDS. When using this mode, the string from figure 6.2 uses the MAC value generated by the algorithm described earlier instead of the AC cryptogram. Table 6.6 shows THE cap Token size values depending on the number of bits included in the CAP Token of the main CAP parameters. The “number of CVR bits” column is set to 0 for the case of a dedicated application and 10 for the case of a normal payment method-

THE cap Token size is approximately 3 digits longer when using a regular payment app instead of a dedicated app.
It should be repeated that payment systems in CAP/ DPA programs recommend using a dedicated application. Note also that the personalized data of a dedicated application usually takes up only 400-500 bytes of EEPROM memory. This is due to the fact that when you personalize such an application, you do not need to store data that is necessary for dynamic card authentication and takes up a significant amount of memory (offline authentication of the application by the reader is not performed).
Today, there are several providers of reader solutions on the market, including Gemalto, VASCO, Xiring, TODOS, ActivCard, and others.
As noted earlier, in order to implement the CAP method, the card application must support the PIN Offline cardholder verification method. More precisely, the card application data (CVM List) should determine whether the PIN code can be verified. However, not all applications support this method, and therefore they cannot be used when implementing the CAP method. As a result, MasterCard has the idea to develop an extension of the CAP Protocol so that it can be used for all EMV-compatible applications, regardless of whether they are able to verify the PIN code of the cardholder or not. As a result, there is a version of the CAP Protocol, conventionally called PLA (PIN Less Application). The PLA Protocol functions similarly to the CAP Protocol, with the only difference that it does not require the client to enter a PIN code. Thus, the PLA method implements one-factor authentication of the Bank’s client: the latter must only have a Bank’s microprocessor card.
The new version of the m/Chip 4 standard (M/Chip 4 R2) allows replacing the cardholder PIN code for a separate CAP application used only for client authentication in an isolated reader (unconnected PCR). However, if the app supports the Encrypted PIN Offline method, the reader must use this method to verify the cardholder.
So far, authentication of a microprocessor card holder using a reader has been considered. Payment systems have long been studying the possibility of using a cell phone, the most popular tool in the hands of the inhabitants of our planet, to authenticate their customers. One of the solutions in this area was offered by MasterCard. This solution is called MasterCard Mobile Authentication (MMA) and is based on the CAP Protocol.
The solution can be used on cell phones that support the Java 2 Micro Edition (J2ME) operating environment. The J2ME infrastructure (especially when using the MIPD 2.0 profile) covers procedures for securely downloading, activating, upgrading, and executing phone applications written in a shortened version of the Java language called MIDlets.
To implement the MMA Protocol, a stand-alone application (MIDlet) is loaded on the phone that implements the CAP algorithm in its distributed version (later we will understand that the MMA Protocol is a version of CAP, in which the client’s PIN code is checked not in the phone application, but indirectly on the Issuer’s server). This application contains an encrypted card key for generating an applied cryptogram. A double-length key (112 bits) is used. We will denote the card key for generating the Kac application cryptogram below.
To ensure the confidentiality of the KAC key when it is transmitted from the Issuer’s server and stored on the phone, it is encrypted using the PBE (Password-Based Encryption) algorithm defined in the PKCS standard#5. The secret key of the PBE algorithm (the 3DES algorithm is used for data encryption) is the client’s mobile PIN code (the client’s PIN code used only for client authentication via a cell phone), supplemented on the right with zero bytes.
If you need to generate a password, the client opens the MMA MIDlet on the phone and enters their mobile PIN code. The MIDlet uses the PIN value to create a key to decrypt the KAC key and disclose it. Then, using this key, the MIDlet calculates the CAP Token value according to the CAP algorithm described above. However, before calculating THE cap Token value, the MIDlet can request the client to set the cap Protocol mode. When selecting Mode 1, Mode 2 with TDS, or Mode 3, the client will have to enter additional operation data that the MIDlet needs to calculate the CAP Token value.
The MMA algorithm implements two-factor authentication of the client: the client must have the downloaded MIDlet of the Issuer on their phone along with the encrypted Kac secret key and must know the value of the mobile PIN code.
If the client entered the wrong mobile PIN code value, the decrypted KAC key value will be incorrect, and, consequently, the CAP Token value will not be successfully verified in the CTVS system.

The client has several attempts to enter the correct PIN code value, after unsuccessful use of which the client is blocked in the CTVS system and further use of the MIDlet on his phone for client authentication will become impossible.
Note that the MMA Protocol allows you to authenticate any client of any information system, including a Bank client. However, the customer does not need to have a Bank card. In the case of MMA, the phone simultaneously acts as a card and reader!