How mobile wallets work on the example of the “Mir Pay” application
My name is Valery Bogdanov, I am the head of the testing group in the mobile payments team of the NSPK information technology department, and I will tell you about how mobile wallets work using our application as an example Mir Pay…
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 key with the issuer MK-AC (Application Cryptogram Master Key). At the time of making a payment (if online-operations) the map generates based on MK-AC session key SK-AC (Application Cryptogram Session Key) and on it, using the card data and transaction data received from the terminal, generates a cryptogram ARQC (Authorization Request Cryptogram). The cryptogram generation is based on the algorithm 3DES (Triple DES). In the general case, data on the operation comes 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 verifies the cryptogram by generating it himself based on the transaction data that came with 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 issue 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 work to arrange payment, as in the classical case, since the phone lacks card data and the issuer’s key MK-AC – a token profile and its special keys are used instead. Before dealing with payment, let’s understand what happens when a card is “added” to a mobile wallet.
The cardholder enters data into the application (1), which transmits 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 case of Mir Pay the wallet service provider is NSPK, so the data immediately goes to the payment system (2)… Further processing takes place on the mobile payment platform (PMP). 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 occurs (five) 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 conversion of the token profile to the original card data is not possible outside the mobile payment platform. After saving the token profile on the user’s device Mir Pay asks the PMP (7) a pack of one-time keys that will be used by the application when making a purchase as session keys, similar to those mentioned above SK-AC… As the name implies, a one-time key cannot be used more than once, so during use the application Mir Pay periodically loads new key portions 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 the token profile data is used instead of the card data, and the cryptogram ARQC generated on a one-time key received from the PMP as a session key SK-AC… Another difference Mir Pay from plastic cards is that when generating a cryptogram, instead of 3DES a more modern symmetric block cipher is used AES (Advanced Encryption Standard).
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 real card data. Yes, the cryptogram is now verified not by the issuer, but by the PMP, since it is in the depths of the platform that the very 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 Pay the 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 phones with OS Android it’s just 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 Pay a 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 this 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 PMP data and Mir Pay generate key pairs and exchange public components. Due to the fact that we cannot 100% trust the built-in key store, a scheme was developed with the storage of different key components in different places: both in the key store 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 Pay and 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! application Mir Pay complies with international and domestic security requirements and allows MIR cardholders to use a mobile phone for payment without fear of personal data leakage.
Currently development Mir Pay continues – 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.
