How mobile wallets work on the example of the "Mir Pay" application

As you know, in 2015 we launched the Mir payment system, and Mir cards are accepted everywhere in Russia. This is, of course, very cool, but now the use of mobile wallets to pay for purchases is gaining popularity. According to statistics, in 2019, 19% of all transactions are payments using a smartphone. In 2017, there were only 3% of them. In 2018, the Mir Pay payment system also presented its own payment application Mir Pay . Mir Pay is written in Kotlin and can run on phones with NFC support and Android 6.0 and above.







My name is Valery Bogdanov, I am the head of the testing group in the mobile payments team of the information technology department of NSPK, and I will tell you about how mobile wallets work using our Mir Pay application as an example .



First, let's look at how payment using a plastic card works. In the classic case, the card is issued to the holder by the issuing bank. In this case, the card in a protected area of ​​memory stores the MK-AC key ( Application Cryptogram Master Key ) shared with the issuer . At the time of payment (if online -operation) generates a map based on the MK-AC session key SK-AC ( Application Cryptogram Session Key ) and thereon, using the map data and data on the operation received from the terminal, generates a cryptogram ARQC ( Authorization Request Cryptogram ). The generation of the cryptogram is based on the 3DES algorithm (Triple DES ). In the general case, the transaction data is sent from the card to the terminal, then to the host of the acquiring bank (i.e. serving the merchant), then to the payment system and at the very last stage to the issuing bank (i.e., issuing the card) for authorization.







The issuer checks the cryptogram by generating it himself based on the transaction data that came with the ARQC and comparing it with the value from the received data. The issuing bank can approve or reject the operation based on the results of the analysis of card data, cryptograms, established limits, risk assessment, and other parameters.



Now let's take a look at the difference between paying with a mobile wallet. Here, the issuing bank does not give out anything to the wallet holder (except for the card, of course, but it does not directly participate in the payment), instead, the cardholder enters its data into the wallet, and it "appears" in it, or rather, not it, but a special token -profile generated based on this map. It is already clear that it will not be possible to organize payment, as in the classical case, since the phone lacks card data and the issuer's key MK-AC - instead of them, the token profile and its special keys are used. Before dealing with payment, let's understand what happens when a card is β€œadded” to a mobile wallet.







The cardholder enters the data into the application (1), which transfers them in encrypted form (more on that later) through the hosts of the mobile wallet service provider ( WSP - Wallet Service Provider ) to the payment system. In the case of Mir Pay, the wallet service provider is the NSPK, so the data immediately goes to the payment system (2) . Further processing takes place on the mobile payment platform (PMP). The PMP decrypts the data, determines by the card number which issuer it was issued by, and asks him for confirmation of the possibility of adding the card to the wallet (3) . In case of a positive answer (4) for this card, the procedure for generating a token profile (5) and sending it to the phone (6)... Thus, instead of card data, the mobile device will store a token profile associated with this card and this device. Note that the transformation of the token profile into the original card data is not possible outside the mobile payment platform. After saving the token profile on the user's device, Mir Pay requests a pack of one-time keys from the PMP (7) , which will be used by the application when making a purchase as session keys, similar to the SK-AC mentioned above . As the name implies, a one-time key cannot be used more than once, therefore, during use, the Mir Pay application periodically downloads new portions of keys from the PMP. This completes adding the map to the application.



Now let's look at how the payment process has changed in comparison with payment by a plastic card.







The first stage is almost the same, only instead of the card data, the data of the token profile is used, and the ARQC cryptogram is generated on a one-time key received from the PMP as a session SK-AC . Another difference between Mir Pay and plastic cards is that when generating a cryptogram, instead of 3DES , a more modern symmetric block cipher algorithm AES ( Advanced Encryption Standard ) is used.



Further, the data on the operation also passes through the terminal, the host of the acquiring bank and gets into the payment system. By the token number (from the token profile), the payment system determines that it is not dealing with a regular card, but with a token, and sends the operation to the PMP to verify the cryptogram and the so-called detokenization - turning the token back into the data of a real card. Yes, the cryptogram is now verified not by the issuer, but by the PMP, since it is in the depths of the platform that those one-time keys and token profile are generated. Further, the operation with already card data is sent to the issuing bank for authorization. On the way back - reverse transformation.



In Mir Paythe scheme with one-time keys is used, but there is another approach - storing one key on the device. This approach requires a security element on the device and some wallets may apply it given that certain devices have such a security element. In our case, given the huge variety of Android phones, this is simply not achievable. This specificity explains the chosen scheme.



Considering the tokenization process described above, one subtle point can be noticed: when paying with a wallet, the data of the token profile is used, however, when a card is added, its data is sent to the hosts of the payment system, and this data is strictly confidential. To protect card data in Mir Paya multi-stage protection system is provided. At startup, a mechanism for controlling the integrity of the application and checking the environment is automatically enabled, which does not allow the use of a fake application modified by unauthorized persons. If a significant risk is detected, the application informs the user about it and automatically deletes all stored token profiles. Additionally, the results of these checks are also analyzed on the side of the PMP.



For the exchange of confidential data PMP and Mir Paygenerate key pairs and exchange public components. Due to the fact that we cannot 100% trust the built-in key storage, a scheme was developed with the storage of different key components in different places: both in the key storage and in RAM. That is, to initiate a fraudulent operation, it is necessary, firstly, to extract the cryptograms of all these keys, and secondly, they also need to be decrypted! But this is not so easy and not very effective, since strictly one-time keys are used for operations. And only after Mir Payand PMP exchanged public keys, that is, they actually created a secure channel, the transfer of sensitive data is allowed, which is encrypted with crypto-resistant algorithms. Through this mechanism, the token-profile, and one-time keys for conducting transactions, and data on already completed transactions are delivered to the user's device.



As you can see from this description, the security of payments based on mobile wallets is not only maintained at the level of plastic cards, and in some cases even surpasses it! Mir Pay application complies with international and domestic security requirements and allows Mir card holders to use their mobile phone for payment without fear of personal data leakage.



Currently the development of Mir Paycontinues - having released the first versions in a short time, we are already introducing new developments into the application, not forgetting to improve what has already been done.



A number of points require development - it is necessary to take into account the recently released and planned models of smartphones, devoid of Google services, - to switch to Russian counterparts or develop your own solution.



All Articles