From the outside, everything looks as if it were simple - you bring your phone to the terminal - and the payment went through. And it seems that there should not be anything particularly complicated under the hood ... However, it turned out to be difficult to figure it out. And the reason for this is the history of technology. More precisely, the story of human greed. Normally. Although without greed there would be no competition ...
Dear subscribers should already be well versed in how plastic cards with a chip on board work. Well, at least imagine that the chip of such a card is a pretty serious and very secure device.
It is thanks to the high security of this piece of silicon that all modern technologies of plastic cards have become possible.
Within the framework of what I'm going to talk about, this piece of silicon in this infrastructure performs some rather narrow function. By storing keys, performing cryptographic operations, and executing fewer applications. Therefore, it was called the Secure Element (SE) - a secure element. Although I have not met the official name in Russian.
Well, since we are talking about a chip, the thought comes to mind that this chip can not only be carried in a wallet, but also screwed to some electronic device that is always with you ... Let me think about what kind of device it could be ?... The electric toothbrush? - I guess wrong, two more attempts ...
Well, it seems that God Himself ordered the SIM card to be used as a storage for plastic cards on the phone.
This is how I reasoned until I set out to prepare an introductory training course on this topic. The reality turned out to be much more exciting.
it seems that at the dawn of the development of NFC technology there was such a difficult competition. The main prize was the elusive shoulder straps of the monopolist who controlled access to the user's heart ... uh ... to the user's phone.
Of course, mobile operators were the first to get involved in this race, because they are the ones who issue SIM cards and control their use. At one point, this was the only relatively centralized technical solution available to anyone with an NFC phone. Technically, it would probably be possible to somehow put an additional application in the SIM card through the air. But in practice, it boiled down to the fact that the phone holder had to come to the office and replace the SIM card with a new one. I don’t know the exact details, but it’s easy to guess that the new SIM card differed, at least, in an additionally installed application in which it was possible to store card data. Perhaps this SIM card had more resources (the same memory). Maybe not. Basically, SIM-cards are one of the most resource-rich EMV chips.
Cellular operators (and this is not the Russian troika, there are mastodons like Verizon, AT&T and T-Mobile) already happily rubbing their hands in anticipation of a golden rain. How do you want? Whose SIM? Operators. Want to offer your customers a competitive service like paying by phone? Pay money to us, Operators. Cellular. Connections. And a satisfied smile.
This solution is called SIM-centric.
I came across information that they were going to throw 4 cents for each transaction, like that.
The guys agreed to cut down a joint project. They called it Isis Mobile Wallet. Isis is in their language the goddess of fertility, the wife of Osiris and the mother of Horus. And ISIS is, in our opinion, ISIS (a group banned in Russia). In general, they later renamed their wallet to Softcard.
Google then still tried to come to an agreement with them - guys, let me into the project, let's come to an agreement in an amicable way, huh? The guys arrogantly and cautiously did not let us in. What they probably bitterly regretted later. By the way, Google at the end bought this Softcard for itself, when the opsos already realized that they would not see a golden rain for them. Only in a figurative sense if. Google then used these developments in its Wallet. But I got ahead of myself.
After all, this chip exists not only in the form of a chip module (in this form it comes off the assembly line so that it can then be baked into a card), but also in the form of a completely ordinary microcircuit that can be soldered onto a board. Well, smartphone manufacturers have started to solder it into the phone. This solution is called eSE - Embedded Secure Element, an embedded secure element.
Are you grinning already? In vain, in one ecosystem it turned out to be a very working solution, but more on that in one of the following parts.
Nice solution, but there is one problem. The fact is that this solution is suitable for those who buy a new smartphone with SE on board. But there are still those who have a smartphone and money (on the card), but they do not want to buy a new smartphone yet. Here is either a SIM-centric solution, or ...
Well, we did it.
Now you can go buy such a tricky MicroSD card - and your phone, which didn't even have NFC, will get both a Secure Element and an NFC controller along with an antenna. By the way, as for my taste - a very elegant technical solution, I applaud while standing.
You want to provide your customers with a service - the ability to rewrite their payment cards in the Secure Element of their smartphones. To whom should I go to negotiate such an opportunity?
Yeah. You need to find out from the client what he has: eSE or SIM which he already needs. And then - look for contact with the manufacturer of the phone or with the cellular operator. So that those, for an extra money, were allowed to write data to the eSE or SIM. And the zoo of phones and mobile operators is quite large, and then there are MicroSD-SE manufacturers ...
Well, yes, another monster on the market suggests itself - the aggregator of Everything and Everything. To have one window for banks. Well, the aggregator is not at a loss - it will be a little money for the service to collect.
A colossus with feet of clay turned out. Fat, powerful, but swaying, about to crash.
And then those who find themselves far from precipitation from precious metals come up with a "fresh" idea of software emulation. True, there are security issues, as usual. After all, the main protection was hardware - the chip (Secure Element) did not give the keys to anyone, only he encrypted everything himself. And here it is proposed to completely abandon it. I didn't want to, but this horror with a thousand Trusted Secure Providers left no other choice. (This is the name of the manufacturers of SIM cards, phones and memory cards - all those who have access to their Secure Element in the user's smartphone).
And that is why it happened why all these market mastodons spat in disappointment and said: "Guys, we are disagreeing." But about thisskaz - next time (part 2).
Last time I told a brief history of mobile payment technology using Secure Element (SE). Today I will tell you how this technology works.
Let's remember why this Secure Element is needed at all, why there was so much excitement around it. Yes, it's like a piece of a plastic card (its main part), but what does he do that? In principle, I wrote a lot about this, but it doesn't hurt to repeat it, repetitio est mater studiorum (it was not for nothing that I memorized several Latin phrases as a child).
So, the chip of the plastic card (and the Secure Element chip) is designed in such a way that you can write data there, but you cannot pull it out. Nipple. In a sense, he gives out some data, of course, but - strictly meaningful. So if you want to write a PIN-code into it, then this can be done quite boldly: then he will not give this code out, even under torture. Moreover, if the chip suspects that they are trying to hack, it can be irreversibly blocked. Quite such a safe.
If you need to check the PIN, just send him the command: "dear chip, please check if PIN 1234 is right for you?" And he will say in response whether it came up or not. And if you ask for the wrong PIN several times in a row, it will be blocked after some attempts. Well, not all, only a payment application on it ... So it won't be brute-force to pick it up, the chip is not a fool. Those. inside himself, he stores a lot of information, most of which is inaccessible from the outside. And inside himself he knows how to use this information, as required by the verification procedure, electronic signature, encryption, etc.
To write an application to this chip, you need to present the control key to the chip, which got there, in short, during its production, and the manufacturer secretly transfers this key to the issuer (the bank in the case of a bank card, the cellular operator in the case of a SIM card or phone manufacturer in the case of embedded SE). As a result, the payment application is written into the chip, with the help of which payment transactions take place. However, one application is not enough, for its operation it still needs keys, with the help of which cryptograms for transactional requests are calculated. These keys are also placed there by the publisher (bank). You can't just write them down, you need to present the control key to the chip.
In general, a very thoughtful thing, a real digital mini-safe. Such a chip in the form of a special SIM card, or in the form of a Secure Element built into the board, or in the form of a combined MicroSD-SE card, is in the phone.
To make your phone a "bank card", you need to install a payment application with the necessary settings and write down the keys of the issuing bank (by presenting the control key). And in our case, there are many offices who can have this control key. If we have a smartphone with built-in SE, then the phone manufacturer has the key. If we have a SIM-centric solution, then the key is with the cellular operator. If we have a special MicroSD-SE, then the key is from the manufacturer of this card.
Nah ... It is difficult to build business processes. Moreover, each of these offices just won't allow you to write down your applications and keys, they want money. And as I said, the market could not stand this complexity. Except for one ecosystem.
The Apple ecosystem is the system where such a solution has taken root, which is not surprising at all. Because it is a very closed ecosystem, completely controlled by one vendor. There is not even close to such a variety of solutions as there is on other mobile platforms. If you add to this the rather tough policy of Apple to control the software of their smartphones, then suddenly you get a fairly manageable platform. For all my rejection of many of the values of this platform, I cannot but appreciate the advantages that are available in this case.
That is why the only sufficiently large-scale system built around the Secure Element was and remains Apple. He was also a pioneer in the smartphone payments market. The rest of the player pulled himself up a little later.
By the way, the watch has a separate Secure Element.
So, you need to write down the data of your plastic card on your smartphone, and then the smartphone can pretend to be a card.
The transactional request must be signed with a cryptogram, and for this, the keys located in the Secure Element are used. Just like a contactless card signs a request with the keys in its chip.
One of the operating modes of the NFC controller is card emulation, and the payment takes place in this mode.
NXP NFC Controller
The cashier enters the amount, the reader turns on the electromagnetic field, transmitting the request to read. You bring the phone up and the phone "hears" the request using the NFC controller, which is turned on in card emulation mode. A dialogue takes place between the terminal and the NFC controller, as if instead of a phone there was a regular contactless card. At some point, the application in the Secure Element signs the transaction request with the keys hidden in the chip and issues the signed request to the terminal via the NFC controller. The terminal, if you do not take into account a couple of details, does not even understand that it is not a map, but a phone in front of it.
Then the request is sent to the acquiring bank, and ... then it looks like normal transaction path, except that at one point the original PAN of your card appears instead of the token. But we will analyze this another time.
In general, there is no need for the phone to be connected to the Internet or even to catch the network at all. Everything you need is in the Secure Element.
A phone with NFC and Secure Element can theoretically even be turned off: for a contactless card, the induced field of the terminal reader is enough to turn on and answer. So the NFC controller can theoretically work without the rest of the phone, interacting directly with the Secure Element. This is one of the modes of operation of the NFC controller.
But they don’t do that now - it’s not secret, so it’s not possible to pay with a dead phone. What can you do ... Everything in this world has a price.
Last time we talked about a tokenization technology built around a hardware solution based on the Secure Element. Today we'll talk about how to be those who do not have a fruit phone.
"Since we do not have a special chip on board for storing payment application keys, we must somehow emulate it," thought one of the engineers. But keeping the key in the phone itself is a bit unsafe ... A lot of threats are possible - from viruses to phone theft. In principle, blocking with all sorts of passwords and graphic keys (plus fingerprints, Face ID, etc.) protects against theft a little, but there is a theoretical possibility to get access to the inside of the phone bypassing all these locks (for example, via Recovery). And then the attacker can get the key to the payment application of the card. And this is a serious danger.
Therefore, the natural solution was to locate the key "in the most reliable place" - on the servers of the all-seeing Big Brother (seriously, the percentage of coverage of the areas of privacy where the Search Engine got access starts to worry me seriously, and we will talk about it today).
Then the payment procedure should have looked something like this: when interacting with the terminal, the phone contacts the wallet server, the server signs the EMV transaction, returns the result to the phone, and the latter presents this signature to the terminal. From t.zr. security has improved, but there are clear concerns about the availability of such a service. Small communication delays, being somewhere in difficult reception conditions - and it becomes impossible to complete a transaction. Obviously, this is one of the bottlenecks of the technology. But then they came up with a rather elegant solution.
There are different counters and logs on the EMV card, and one of these counters is ATC (Application Transaction Counter). It stores the sequential transaction number. Those. if you try to cheat an EMV card by successively submitting two absolutely identical payment requests (even with the same date and time), you will fail, because for the second transaction this internal counter will already be different (increased by one). Plus, there is still an unpredictable random number in the transactional request - I remind you of this so that you remember why it is absolutely pointless to copy a dialogue with a card in EMV technology.
So, the idea is as follows. We take the application's payment master key (which is located on the wallet's server), and from it, using various cryptographic algorithms, we form a dozen or two one-time keys. When forming each next key, we sequentially use an increasing ATC. Those. to form the first key, for example, ATC = 731 is used, for the second ATC = 732, for the third ATC = 733, etc. And now we load this pack of disposable keys into the phone.
Now, when you pay with your phone, one of the generated keys is used, which was assigned to a specific transaction number. This bundle of disposable keys is stored on the phone and therefore does not require any direct connection to the wallet server. Very comfortably.
It is clear that after some time the pack of disposable keys will run out, and they will need to be replenished. It is important at this moment (or in advance) to contact the server in order to generate and download a stock of disposable shreds.
Those. "You can't store keys on your phone, but if you really want to, you can." More precisely, in this way two tasks are solved. On the one hand, we keep the master key safe and there is no way you can steal it. On the other hand, by the number of disposable keys on the phone, we can somehow regulate the payment activity in which case, without especially spoiling the life of a law-abiding user. Quite a solution. At the same time, one-time keys are completely useless if copied to another device. And that's why:
In addition to all these one-time keys, the wallet application generates a couple of important values during installation and initialization.
One of them is the so-called. device token. It's no secret that every device (phone, tablet, watch) is quite unique: IMEI, model, operating system identifiers, etc. In general, the passionate desire of various offices to offer the user a mobile application (instead of web access) is largely due to the fact that in this scheme the office gets the opportunity to track the phone and its activity. Therefore, the problem of uniquely identifying a specific device has long been successfully solved, there is no difficulty here. Therefore, it is very easy to generate some kind of unique programmatic identifier for a specific device, in order to somehow associate payment activity with it. In this case, it is good for security, since makes it impossible (or critically difficult) to mechanically transfer keys, settings, etc.
The second important token that is generated by the wallet application is the user's token. Everything is more interesting here.
The fact is that in EMV technology there is such a thing as CVM - Cardholder Verification Method - a method for verifying a user. Prior to tokenization technology, this included verification of PIN and handwritten signature in various combinations. Those. the buyer presented the card and then entered the PIN or signed the check, or somehow a combination of these methods.
But modern mobile devices have several additional, rather interesting ways to check who is using them. This includes fingerprint scanning, Face ID, and various alternative identification methods. Be that as it may, instead of a completely non-interactive card, now in the hands of the buyer is a user device (Customer Device), which itself is able to interact with the user, and the POS terminal now does not need to receive a PIN through its keyboard. The phone now does it instead. This is one of the places where an EMV transaction with a phone for a terminal is still different from an EMV transaction with a contactless card. The terminal must be able to process CDCVM - Customer Device Cardholder Verification Method. Those. stupidly, he must recognize the corresponding value that the phone sends to him,
Well, on the phone itself, when the wallet application is initialized, a user token is generated and stored - a certain value calculated from what the user enters into the phone - the usual PIN code, his interface ... just a face, a nose print, a voice, and so on. This user token is sent to the wallet server along with the payment request and the device token. It is clear that a hacker's phone must have all these tokens in order to forge a transaction, which is either impossible at all or critically difficult.
From now on, the requirements for the phone have sharply decreased - it does not need to have a Secure Element on board, just an NFC controller and an adequate version of the operating system. The generous Big Brother does not charge a cent for all these luxurious amenities. Moreover, kind Big Brother made his wallet part of the operating system. If you are a large enough bank that develops its own application, or generally a third-party developer, then in order to add the possibility of contactless payment, you can use the libraries built into the operating system of the phone, everything is simple and convenient.
What for? So that you can make purchases without a POS terminal. For example, buying paid apps or paying for goods over the Internet.
Directly a developer's and user's dream! Again - no commissions for all this luxury!
Why does Big Brother need it?
It's simple.
If before Big Brother knew what kind of phone you have, where you live and work, what applications are installed on your phone, how actively you use them, who is in your contacts, how your voice sounds, how you look, what you correspond with colleagues and friends, how often and who do you call, what do you look for in his search engine, what do you photograph, what fingerprints you have, etc. and so on, now he got one more little. Now he knows where, how often and what you spend your money on.
It seems that all this just helps to offer you advertising as targeted as possible. For your own convenience: you will not have to look for something for a long time, dear Brother will tell you everything himself.
The user, however, is left with some ephemeral opportunity to choose which particular Brother to entrust the data on his payment activity. For example, if you have a Gnusmas phone, then you can surrender to the Korean giant, not the American one. And then the American Brother will be left without data on your payment activity (however, he will know for sure that the Korean has this data).
And in the next series, we will finally find out what a token is (this time - the one in the word "tokenization"), and how it is substituted for a PAN card.
Although, if suddenly I explained something not very clear - write in the comments, we will add interactivity to our tokenized series. And do not regret the likes - I would like to understand what you are interested in
In the past series of Smartphone Games, we learned about the fate of the homes of Cellular Operators and Search Giants. Viewers managed to understand the dramatic rehearsals of the fate of Secure Element and the mass of minor characters involved in the main storyline. And today we are ready to learn about the fate of the main character - Token Skarta.
In this regard, it becomes interesting, and where, in fact, is the substitution of one for the other? And the answer is a bit unexpected. We are accustomed to the fact that there are loud names for wallets - Apple-Pei and Ge-Pei. In the minds of some people, these brands are associated with the operation of infrastructure. But in fact, it generates a token and produces a reverse staging .... International Payment System (MPS)! Well, or, as it is more correct to call them, the Card Association.
When you add a card to your Ge-Pei, there is a complex exchange of data between the MPS and the wallet server. There is nothing particularly interesting there to consider step by step, so I did not shoot this part of the plot. I will only say that there are two options: when the bank application initiates tokenization, if it exists (and for this, at some point, it calls the system components of the Wallet application), and when the wallet itself initiates tokenization (Ge-Pei, Yablo-Pei, Gnusmas-pei). There, in the process, it is also important to make sure that this particular card can be tokenized.
As a result of all these recorded moves, at one of the steps, the Payment System itself generates a token and notifies the issuing bank of the card. In order for the Payment System to be able to do this, the issuing bank must be connected to the special infrastructure of the payment system. For MasterCard, for example, this infrastructure is called the MasterCard Digital Enablement Service (MDES). After that, the publisher bank will have access to some tokenization aids.
Not much, because the issuing bank, by and large, may not even know what specific token a particular user has. Because the request that arrives at the issuing bank for authorization contains the PAN of the card that it issued to the client! And the bank simply processes this transaction as if the client made a payment by card, and not by the phone to which it was "added"!
In fact, in the message of the Payment System, there is still a mention that the transaction is made using a token, and even sends this token in additional fields. But, I repeat, the processing of the transaction further at the issuing bank is already proceeding as if it were the most ordinary transaction.
The token that generates the IPS is not arbitrary, but in the same way begins with several digits redeemed by a specific bank. Let me remind you that these few initial digits of the card number (prefix) are called BIN - Bank Identification Number. To issue cards starting with these numbers (with this BIN), the bank buys one or more prefixes from the Payment System. As you can see, something similar happens with the BIN for tokens. But in the case of ordinary cards, the bank itself generates the full card number (and issues the card). But in the case of tokens, it is a little different. The bank bought them, possibly transferred a special publishing key to the Payment System (for cases when the bank has its own application that can innovate tokenization), but the Payment System is already engaged in generating tokens and linking it to a specific number of a live card (more precisely,
Now we have filmed all flashbacks and lyrical digressions, and we can trace the path of traction.
You go to the payment terminal. The cashier activates the terminal. In the meantime, you open the phone, enter the PIN-code or there a fingerprint or scan your face there. Here, the very user and device tokens are used to make sure that it is you, and it is from your phone that you are trying to make a payment. The Wallet app is ready to pay.
The terminal signals into the air "Waiting for a card. Waiting for a card". And here you bring your phone. Ice and fire converge ... And the phone, pretending to be a card, sends to the terminal a token previously added to it (which is instead of a card).
The terminal performs all the checks that it would perform with a conventional contactless card. And it sends a request to the acquiring bank (whose terminal). The acquiring bank sees that the "card" number is not his, and sends it further to the payment system. Let him figure it out.
The payment system looks at this number ... And it seems vaguely familiar to her. "Oh yes!" - exclaims the Payment System, slaps himself on the forehead and takes out the hidden number of the original card. And substitutes it into the transaction. The received transaction is forwarded to the issuing bank.
The issuing bank looks at the transaction and sees there the usual, familiar card number, which he himself issued. It checks the linked balance and additional checks. If all is well, it sends an answer to the Payment System "let him go there ...". The Payment System receives the card number, slaps itself on the forehead a second time (but on the other hand) and replaces the card number with the token that was there initially. And the result with the confirmation of the issuer is sent to the acquiring bank.
Then everything is as usual. The acquiring bank transfers the permission to the terminal. Then he credits money to the merchant's account, creates a request for a refund from the payment system, etc. If interested, we do all these actions already considered.
The end credits have gone, a satisfied customer leaves with the purchase, backstage footage is on the screen.
PS I only mentioned MasterCard here. He is, as usual, a pioneer in payment technology. The rest of the payment system pulled up on the sly, but so that you know, in terms of the number of transactions and the amount, Yablo-Pei exceeds Ge-Pei by about three times, taking up about 3/4 of all turnovers of tokenized payments. There are no exact numbers, there are draconian disclosure rules, but information on proportions is available. And Yablo-Pay works at MasterCard. Accordingly, it is easy to imagine that the share of other Payment Systems is still quite low.
Dear subscribers should already be well versed in how plastic cards with a chip on board work. Well, at least imagine that the chip of such a card is a pretty serious and very secure device.
It is thanks to the high security of this piece of silicon that all modern technologies of plastic cards have become possible.
Within the framework of what I'm going to talk about, this piece of silicon in this infrastructure performs some rather narrow function. By storing keys, performing cryptographic operations, and executing fewer applications. Therefore, it was called the Secure Element (SE) - a secure element. Although I have not met the official name in Russian.
Well, since we are talking about a chip, the thought comes to mind that this chip can not only be carried in a wallet, but also screwed to some electronic device that is always with you ... Let me think about what kind of device it could be ?... The electric toothbrush? - I guess wrong, two more attempts ...
SIM
A SIM card, as I once told you, is, in fact, exactly the same chip as in a bank card. Well, more precisely, it conforms to the same specification EMV. There can be (and usually is) a little more (or less) resources on a SIM card chip than on a bank. Otherwise, if you do not quibble, then this is almost the same card as a payment card. It is no coincidence that SIM cards are sold in the form of cards very similar to bank cards, only with perforations to break the SIM card in size.Well, it seems that God Himself ordered the SIM card to be used as a storage for plastic cards on the phone.
This is how I reasoned until I set out to prepare an introductory training course on this topic. The reality turned out to be much more exciting.
it seems that at the dawn of the development of NFC technology there was such a difficult competition. The main prize was the elusive shoulder straps of the monopolist who controlled access to the user's heart ... uh ... to the user's phone.
Of course, mobile operators were the first to get involved in this race, because they are the ones who issue SIM cards and control their use. At one point, this was the only relatively centralized technical solution available to anyone with an NFC phone. Technically, it would probably be possible to somehow put an additional application in the SIM card through the air. But in practice, it boiled down to the fact that the phone holder had to come to the office and replace the SIM card with a new one. I don’t know the exact details, but it’s easy to guess that the new SIM card differed, at least, in an additionally installed application in which it was possible to store card data. Perhaps this SIM card had more resources (the same memory). Maybe not. Basically, SIM-cards are one of the most resource-rich EMV chips.
Cellular operators (and this is not the Russian troika, there are mastodons like Verizon, AT&T and T-Mobile) already happily rubbing their hands in anticipation of a golden rain. How do you want? Whose SIM? Operators. Want to offer your customers a competitive service like paying by phone? Pay money to us, Operators. Cellular. Connections. And a satisfied smile.
This solution is called SIM-centric.
I came across information that they were going to throw 4 cents for each transaction, like that.
The guys agreed to cut down a joint project. They called it Isis Mobile Wallet. Isis is in their language the goddess of fertility, the wife of Osiris and the mother of Horus. And ISIS is, in our opinion, ISIS (a group banned in Russia). In general, they later renamed their wallet to Softcard.
Google then still tried to come to an agreement with them - guys, let me into the project, let's come to an agreement in an amicable way, huh? The guys arrogantly and cautiously did not let us in. What they probably bitterly regretted later. By the way, Google at the end bought this Softcard for itself, when the opsos already realized that they would not see a golden rain for them. Only in a figurative sense if. Google then used these developments in its Wallet. But I got ahead of myself.
Embedded SE
Meanwhile, phone makers - not fools either - also dreamed of this golden shower. SIM card, but the NFC controller is in the phone! Who is stopping us from screwing a similar chip there?After all, this chip exists not only in the form of a chip module (in this form it comes off the assembly line so that it can then be baked into a card), but also in the form of a completely ordinary microcircuit that can be soldered onto a board. Well, smartphone manufacturers have started to solder it into the phone. This solution is called eSE - Embedded Secure Element, an embedded secure element.
Are you grinning already? In vain, in one ecosystem it turned out to be a very working solution, but more on that in one of the following parts.
Nice solution, but there is one problem. The fact is that this solution is suitable for those who buy a new smartphone with SE on board. But there are still those who have a smartphone and money (on the card), but they do not want to buy a new smartphone yet. Here is either a SIM-centric solution, or ...
MicroSD
The bubble of the "security" Klondike was blowing up before our eyes. Those whom no one expected at all began to connect. What else is removable in your smartphone (if it's not an apple phone)? Besides the SIM card? Yeah, memory card. MicroSD. And she, by the way, has a USB interface, if someone suddenly did not know. So they guessed in a MicroSD card to place not one device (in fact, the card itself), but several, among which there is the same Secure Element. The USB bus allows you to connect a whole tree of devices there. By the way, this is a good option for those smartphones that do not have an NFC controller and antennas on board. Because, in principle, in the same memory card, you can, if you wish, cram both the NFC controller and the antenna Well, we did it.Now you can go buy such a tricky MicroSD card - and your phone, which didn't even have NFC, will get both a Secure Element and an NFC controller along with an antenna. By the way, as for my taste - a very elegant technical solution, I applaud while standing.
Where to go?
Just now imagine yourself in the place of a bank.You want to provide your customers with a service - the ability to rewrite their payment cards in the Secure Element of their smartphones. To whom should I go to negotiate such an opportunity?
Yeah. You need to find out from the client what he has: eSE or SIM which he already needs. And then - look for contact with the manufacturer of the phone or with the cellular operator. So that those, for an extra money, were allowed to write data to the eSE or SIM. And the zoo of phones and mobile operators is quite large, and then there are MicroSD-SE manufacturers ...
Well, yes, another monster on the market suggests itself - the aggregator of Everything and Everything. To have one window for banks. Well, the aggregator is not at a loss - it will be a little money for the service to collect.
A colossus with feet of clay turned out. Fat, powerful, but swaying, about to crash.
And then those who find themselves far from precipitation from precious metals come up with a "fresh" idea of software emulation. True, there are security issues, as usual. After all, the main protection was hardware - the chip (Secure Element) did not give the keys to anyone, only he encrypted everything himself. And here it is proposed to completely abandon it. I didn't want to, but this horror with a thousand Trusted Secure Providers left no other choice. (This is the name of the manufacturers of SIM cards, phones and memory cards - all those who have access to their Secure Element in the user's smartphone).
And that is why it happened why all these market mastodons spat in disappointment and said: "Guys, we are disagreeing." But about thisskaz - next time (part 2).
Last time I told a brief history of mobile payment technology using Secure Element (SE). Today I will tell you how this technology works.
Let's remember why this Secure Element is needed at all, why there was so much excitement around it. Yes, it's like a piece of a plastic card (its main part), but what does he do that? In principle, I wrote a lot about this, but it doesn't hurt to repeat it, repetitio est mater studiorum (it was not for nothing that I memorized several Latin phrases as a child).
So, the chip of the plastic card (and the Secure Element chip) is designed in such a way that you can write data there, but you cannot pull it out. Nipple. In a sense, he gives out some data, of course, but - strictly meaningful. So if you want to write a PIN-code into it, then this can be done quite boldly: then he will not give this code out, even under torture. Moreover, if the chip suspects that they are trying to hack, it can be irreversibly blocked. Quite such a safe.
If you need to check the PIN, just send him the command: "dear chip, please check if PIN 1234 is right for you?" And he will say in response whether it came up or not. And if you ask for the wrong PIN several times in a row, it will be blocked after some attempts. Well, not all, only a payment application on it ... So it won't be brute-force to pick it up, the chip is not a fool. Those. inside himself, he stores a lot of information, most of which is inaccessible from the outside. And inside himself he knows how to use this information, as required by the verification procedure, electronic signature, encryption, etc.
To write an application to this chip, you need to present the control key to the chip, which got there, in short, during its production, and the manufacturer secretly transfers this key to the issuer (the bank in the case of a bank card, the cellular operator in the case of a SIM card or phone manufacturer in the case of embedded SE). As a result, the payment application is written into the chip, with the help of which payment transactions take place. However, one application is not enough, for its operation it still needs keys, with the help of which cryptograms for transactional requests are calculated. These keys are also placed there by the publisher (bank). You can't just write them down, you need to present the control key to the chip.
In general, a very thoughtful thing, a real digital mini-safe. Such a chip in the form of a special SIM card, or in the form of a Secure Element built into the board, or in the form of a combined MicroSD-SE card, is in the phone.
To make your phone a "bank card", you need to install a payment application with the necessary settings and write down the keys of the issuing bank (by presenting the control key). And in our case, there are many offices who can have this control key. If we have a smartphone with built-in SE, then the phone manufacturer has the key. If we have a SIM-centric solution, then the key is with the cellular operator. If we have a special MicroSD-SE, then the key is from the manufacturer of this card.
Nah ... It is difficult to build business processes. Moreover, each of these offices just won't allow you to write down your applications and keys, they want money. And as I said, the market could not stand this complexity. Except for one ecosystem.
The Apple ecosystem is the system where such a solution has taken root, which is not surprising at all. Because it is a very closed ecosystem, completely controlled by one vendor. There is not even close to such a variety of solutions as there is on other mobile platforms. If you add to this the rather tough policy of Apple to control the software of their smartphones, then suddenly you get a fairly manageable platform. For all my rejection of many of the values of this platform, I cannot but appreciate the advantages that are available in this case.
That is why the only sufficiently large-scale system built around the Secure Element was and remains Apple. He was also a pioneer in the smartphone payments market. The rest of the player pulled himself up a little later.
By the way, the watch has a separate Secure Element.
So, you need to write down the data of your plastic card on your smartphone, and then the smartphone can pretend to be a card.
Token with t.zr. terminal is very similar to a payment card, it is a number like PAN, and it is processed in almost the same way, with the exception of some details, which I will also talk about in another part. If you do not find fault with the details, then the terminal does not see the difference between the contactless card attached to it and the phone.
The transactional request must be signed with a cryptogram, and for this, the keys located in the Secure Element are used. Just like a contactless card signs a request with the keys in its chip.
As a result, it turns out that everything you need to form and sign a transaction request is on board the phone. And for this work, he does not need not only the Internet, but even a connection to the cellular network.
One of the operating modes of the NFC controller is card emulation, and the payment takes place in this mode.
NXP NFC Controller
The cashier enters the amount, the reader turns on the electromagnetic field, transmitting the request to read. You bring the phone up and the phone "hears" the request using the NFC controller, which is turned on in card emulation mode. A dialogue takes place between the terminal and the NFC controller, as if instead of a phone there was a regular contactless card. At some point, the application in the Secure Element signs the transaction request with the keys hidden in the chip and issues the signed request to the terminal via the NFC controller. The terminal, if you do not take into account a couple of details, does not even understand that it is not a map, but a phone in front of it.
Then the request is sent to the acquiring bank, and ... then it looks like normal transaction path, except that at one point the original PAN of your card appears instead of the token. But we will analyze this another time.
In general, there is no need for the phone to be connected to the Internet or even to catch the network at all. Everything you need is in the Secure Element.
A phone with NFC and Secure Element can theoretically even be turned off: for a contactless card, the induced field of the terminal reader is enough to turn on and answer. So the NFC controller can theoretically work without the rest of the phone, interacting directly with the Secure Element. This is one of the modes of operation of the NFC controller.
But they don’t do that now - it’s not secret, so it’s not possible to pay with a dead phone. What can you do ... Everything in this world has a price.
Let's summarize
The presence of the Secure Element on board the phone makes it independent of the network connection, and generally speaking, it is the most secure solution in all tokenization technologies. But thanks to the abundance of mobile platforms, this has fully taken root only in the Apple ecosystem. And in other ecosystems there is a less reliable, but more versatile way to do without the Secure Element, which is what we'll start talking about next time.
Last time we talked about a tokenization technology built around a hardware solution based on the Secure Element. Today we'll talk about how to be those who do not have a fruit phone.
"Since we do not have a special chip on board for storing payment application keys, we must somehow emulate it," thought one of the engineers. But keeping the key in the phone itself is a bit unsafe ... A lot of threats are possible - from viruses to phone theft. In principle, blocking with all sorts of passwords and graphic keys (plus fingerprints, Face ID, etc.) protects against theft a little, but there is a theoretical possibility to get access to the inside of the phone bypassing all these locks (for example, via Recovery). And then the attacker can get the key to the payment application of the card. And this is a serious danger.
Therefore, the natural solution was to locate the key "in the most reliable place" - on the servers of the all-seeing Big Brother (seriously, the percentage of coverage of the areas of privacy where the Search Engine got access starts to worry me seriously, and we will talk about it today).
Then the payment procedure should have looked something like this: when interacting with the terminal, the phone contacts the wallet server, the server signs the EMV transaction, returns the result to the phone, and the latter presents this signature to the terminal. From t.zr. security has improved, but there are clear concerns about the availability of such a service. Small communication delays, being somewhere in difficult reception conditions - and it becomes impossible to complete a transaction. Obviously, this is one of the bottlenecks of the technology. But then they came up with a rather elegant solution.
LUK / SUK (Limited-use keys / single-use key)
There are different counters and logs on the EMV card, and one of these counters is ATC (Application Transaction Counter). It stores the sequential transaction number. Those. if you try to cheat an EMV card by successively submitting two absolutely identical payment requests (even with the same date and time), you will fail, because for the second transaction this internal counter will already be different (increased by one). Plus, there is still an unpredictable random number in the transactional request - I remind you of this so that you remember why it is absolutely pointless to copy a dialogue with a card in EMV technology.
So, the idea is as follows. We take the application's payment master key (which is located on the wallet's server), and from it, using various cryptographic algorithms, we form a dozen or two one-time keys. When forming each next key, we sequentially use an increasing ATC. Those. to form the first key, for example, ATC = 731 is used, for the second ATC = 732, for the third ATC = 733, etc. And now we load this pack of disposable keys into the phone.
Now, when you pay with your phone, one of the generated keys is used, which was assigned to a specific transaction number. This bundle of disposable keys is stored on the phone and therefore does not require any direct connection to the wallet server. Very comfortably.
It is clear that after some time the pack of disposable keys will run out, and they will need to be replenished. It is important at this moment (or in advance) to contact the server in order to generate and download a stock of disposable shreds.
Those. "You can't store keys on your phone, but if you really want to, you can." More precisely, in this way two tasks are solved. On the one hand, we keep the master key safe and there is no way you can steal it. On the other hand, by the number of disposable keys on the phone, we can somehow regulate the payment activity in which case, without especially spoiling the life of a law-abiding user. Quite a solution. At the same time, one-time keys are completely useless if copied to another device. And that's why:
Device token and user token
In addition to all these one-time keys, the wallet application generates a couple of important values during installation and initialization.
One of them is the so-called. device token. It's no secret that every device (phone, tablet, watch) is quite unique: IMEI, model, operating system identifiers, etc. In general, the passionate desire of various offices to offer the user a mobile application (instead of web access) is largely due to the fact that in this scheme the office gets the opportunity to track the phone and its activity. Therefore, the problem of uniquely identifying a specific device has long been successfully solved, there is no difficulty here. Therefore, it is very easy to generate some kind of unique programmatic identifier for a specific device, in order to somehow associate payment activity with it. In this case, it is good for security, since makes it impossible (or critically difficult) to mechanically transfer keys, settings, etc.
The second important token that is generated by the wallet application is the user's token. Everything is more interesting here.
The fact is that in EMV technology there is such a thing as CVM - Cardholder Verification Method - a method for verifying a user. Prior to tokenization technology, this included verification of PIN and handwritten signature in various combinations. Those. the buyer presented the card and then entered the PIN or signed the check, or somehow a combination of these methods.
But modern mobile devices have several additional, rather interesting ways to check who is using them. This includes fingerprint scanning, Face ID, and various alternative identification methods. Be that as it may, instead of a completely non-interactive card, now in the hands of the buyer is a user device (Customer Device), which itself is able to interact with the user, and the POS terminal now does not need to receive a PIN through its keyboard. The phone now does it instead. This is one of the places where an EMV transaction with a phone for a terminal is still different from an EMV transaction with a contactless card. The terminal must be able to process CDCVM - Customer Device Cardholder Verification Method. Those. stupidly, he must recognize the corresponding value that the phone sends to him,
Well, on the phone itself, when the wallet application is initialized, a user token is generated and stored - a certain value calculated from what the user enters into the phone - the usual PIN code, his interface ... just a face, a nose print, a voice, and so on. This user token is sent to the wallet server along with the payment request and the device token. It is clear that a hacker's phone must have all these tokens in order to forge a transaction, which is either impossible at all or critically difficult.
About Big Brother
From now on, the requirements for the phone have sharply decreased - it does not need to have a Secure Element on board, just an NFC controller and an adequate version of the operating system. The generous Big Brother does not charge a cent for all these luxurious amenities. Moreover, kind Big Brother made his wallet part of the operating system. If you are a large enough bank that develops its own application, or generally a third-party developer, then in order to add the possibility of contactless payment, you can use the libraries built into the operating system of the phone, everything is simple and convenient.
What for? So that you can make purchases without a POS terminal. For example, buying paid apps or paying for goods over the Internet.
Directly a developer's and user's dream!
Again - no commissions for all this luxury!Why does Big Brother need it?
It's simple.
If before Big Brother knew what kind of phone you have, where you live and work, what applications are installed on your phone, how actively you use them, who is in your contacts, how your voice sounds, how you look, what you correspond with colleagues and friends, how often and who do you call, what do you look for in his search engine, what do you photograph, what fingerprints you have, etc. and so on, now he got one more little. Now he knows where, how often and what you spend your money on.
It seems that all this just helps to offer you advertising as targeted as possible. For your own convenience: you will not have to look for something for a long time, dear Brother will tell you everything himself.
The user, however, is left with some ephemeral opportunity to choose which particular Brother to entrust the data on his payment activity. For example, if you have a Gnusmas phone, then you can surrender to the Korean giant, not the American one. And then the American Brother will be left without data on your payment activity (however, he will know for sure that the Korean has this data).
And in the next series, we will finally find out what a token is (this time - the one in the word "tokenization"), and how it is substituted for a PAN card.
Although, if suddenly I explained something not very clear - write in the comments, we will add interactivity to our tokenized series. And do not regret the likes - I would like to understand what you are interested in
In the past series of Smartphone Games, we learned about the fate of the homes of Cellular Operators and Search Giants. Viewers managed to understand the dramatic rehearsals of the fate of Secure Element and the mass of minor characters involved in the main storyline. And today we are ready to learn about the fate of the main character - Token Skarta.
So what is a token?
The token looks quite like an ordinary person ... like an ordinary card number. Without knowing the details, you won't be able to tell them apart. And this was done intentionally. Technically, the terminal should be indifferent to whether it works with a contactless card or a phone that pretends to be a card. In fact, this is not entirely true, I wrote about it. The terminal should at least work correctly with the fact that the PIN is not checked on it, but on the phone. But in many other nuances, the token is like an ordinary card number.In this regard, it becomes interesting, and where, in fact, is the substitution of one for the other? And the answer is a bit unexpected. We are accustomed to the fact that there are loud names for wallets - Apple-Pei and Ge-Pei. In the minds of some people, these brands are associated with the operation of infrastructure. But in fact, it generates a token and produces a reverse staging .... International Payment System (MPS)! Well, or, as it is more correct to call them, the Card Association.
When you add a card to your Ge-Pei, there is a complex exchange of data between the MPS and the wallet server. There is nothing particularly interesting there to consider step by step, so I did not shoot this part of the plot. I will only say that there are two options: when the bank application initiates tokenization, if it exists (and for this, at some point, it calls the system components of the Wallet application), and when the wallet itself initiates tokenization (Ge-Pei, Yablo-Pei, Gnusmas-pei). There, in the process, it is also important to make sure that this particular card can be tokenized.
As a result of all these recorded moves, at one of the steps, the Payment System itself generates a token and notifies the issuing bank of the card. In order for the Payment System to be able to do this, the issuing bank must be connected to the special infrastructure of the payment system. For MasterCard, for example, this infrastructure is called the MasterCard Digital Enablement Service (MDES). After that, the publisher bank will have access to some tokenization aids.
Not much, because the issuing bank, by and large, may not even know what specific token a particular user has. Because the request that arrives at the issuing bank for authorization contains the PAN of the card that it issued to the client! And the bank simply processes this transaction as if the client made a payment by card, and not by the phone to which it was "added"!
In fact, in the message of the Payment System, there is still a mention that the transaction is made using a token, and even sends this token in additional fields. But, I repeat, the processing of the transaction further at the issuing bank is already proceeding as if it were the most ordinary transaction.
The token that generates the IPS is not arbitrary, but in the same way begins with several digits redeemed by a specific bank. Let me remind you that these few initial digits of the card number (prefix) are called BIN - Bank Identification Number. To issue cards starting with these numbers (with this BIN), the bank buys one or more prefixes from the Payment System. As you can see, something similar happens with the BIN for tokens. But in the case of ordinary cards, the bank itself generates the full card number (and issues the card). But in the case of tokens, it is a little different. The bank bought them, possibly transferred a special publishing key to the Payment System (for cases when the bank has its own application that can innovate tokenization), but the Payment System is already engaged in generating tokens and linking it to a specific number of a live card (more precisely,
Let's take it one more time to secure it.
The user starts adding a card to his Wallet, the Payment System generates a token, this token is returned to the wallet. Now the original PAN card is no longer stored in the Wallet (neither in the phone, nor on the Wallet server). Only the token is stored in the Wallet. And the Payment System stores the link between the PAN card and the Token.Now we have filmed all flashbacks and lyrical digressions, and we can trace the path of traction.
Motor!
You have a Wallet application on your phone, which stores a token (which is instead of a card), plus a user token (linked specifically to you, your account) and a device token. The last two tokens on the card are completely different, although they are also called tokens. They are needed in order for the Wallet server to perceive your manipulations with the "added cards" as authorized.You go to the payment terminal. The cashier activates the terminal. In the meantime, you open the phone, enter the PIN-code or there a fingerprint or scan your face there. Here, the very user and device tokens are used to make sure that it is you, and it is from your phone that you are trying to make a payment. The Wallet app is ready to pay.
The terminal signals into the air "Waiting for a card. Waiting for a card". And here you bring your phone. Ice and fire converge ... And the phone, pretending to be a card, sends to the terminal a token previously added to it (which is instead of a card).
The terminal performs all the checks that it would perform with a conventional contactless card. And it sends a request to the acquiring bank (whose terminal). The acquiring bank sees that the "card" number is not his, and sends it further to the payment system. Let him figure it out.
The payment system looks at this number ... And it seems vaguely familiar to her. "Oh yes!" - exclaims the Payment System, slaps himself on the forehead and takes out the hidden number of the original card. And substitutes it into the transaction. The received transaction is forwarded to the issuing bank.
The issuing bank looks at the transaction and sees there the usual, familiar card number, which he himself issued. It checks the linked balance and additional checks. If all is well, it sends an answer to the Payment System "let him go there ...". The Payment System receives the card number, slaps itself on the forehead a second time (but on the other hand) and replaces the card number with the token that was there initially. And the result with the confirmation of the issuer is sent to the acquiring bank.
Then everything is as usual. The acquiring bank transfers the permission to the terminal. Then he credits money to the merchant's account, creates a request for a refund from the payment system, etc. If interested, we do all these actions already considered.
The end credits have gone, a satisfied customer leaves with the purchase, backstage footage is on the screen.
PS I only mentioned MasterCard here. He is, as usual, a pioneer in payment technology. The rest of the payment system pulled up on the sly, but so that you know, in terms of the number of transactions and the amount, Yablo-Pei exceeds Ge-Pei by about three times, taking up about 3/4 of all turnovers of tokenized payments. There are no exact numbers, there are draconian disclosure rules, but information on proportions is available. And Yablo-Pay works at MasterCard. Accordingly, it is easy to imagine that the share of other Payment Systems is still quite low.
