Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!

Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!


======================================================================

Imagine you are at the checkout, at the checkout at the supermarket, and you take your cash card, you get something like 35 years to pay and you place it just on the top of the terminal. It makes it beep and you have paid well. How does near field communication work and in particular, what happens at the protocol levels? Well, the answers are given now by Simon Wemyss, who is a co-founder of Pay Works. It's a company specialized in point of sale payment Gateway Technologies. Simon has studied informatics in Munich, in San Francisco and in Los Angeles. So let's welcome now Simon with his talk on decoding contactless card payments. Simon yachters. Thanks a lot, Anchia, what a crowd. Welcome, everybody. Thanks for joining tonight. And tonight, I want to talk about contactless card payments and how we go from, like, inserting a card to tapping a card to, in the end, just tapping your smartphone. And full disclosure, I'm not talking about, like, exposing new security risks in that format. And also, I'm not going on the lowest level of the EMV protocol, which is basically below running this. But I really want to focus on the status quo. How is basically a contact conductor's card transaction working? How do we do Apple pay? How do we do Android pay? What is involved there? And why is it not possible to actually take a card and clone it to your smartphone, something that the chip would actually prevent you from, from doing? And. Just to give you some context where this is coming from, we'll get paperworks where we run a payment gateway and develop tools for making transactions easier for developers to integrate. And over there, I'm mainly responsible for integrating new terminals, connecting new banks. And I want to take the motto of the Congress to that and just to that and give you some insights and what I learned while working on that. And, yeah, let's get started with this. Probably everybody here in the room has heard about contactless payments and has used it, maybe,
 maybe not. I mean, in Germany, adoption rate for contactless transactions are relatively slow. First of all, you get a new card from your bank or your credit card company. And even if you have that, you still need a terminal which is actually able to handle transactions. And if you then finally do a contactless transaction, the cashier is looking at you curiously and saying, well, it's not that that's not how it worked basically before. And in the end, you get your goods, but they always some surprises waiting for you. And what we are looking at tonight is basically, first of all, what makes a contactless transaction the blueprint? What status do we go through? And then we need to discuss ways of actually converting your smartphone into insulating or simulating a contactless card. In addition to that, I want to talk a little bit about making payments a little bit more secure at the point of sale or on the e-commerce side in general, where we talk about tokenization and then we have all the information that we need to actually look into Apple Pay and Android pay. And in the end, I just want to give a quick look out on how I could envision the next steps when it comes to contactless transactions and transactions at the point of sale in general. So looking at contactless transactions, this is a relatively new technology. And you might think, well, somebody came up with something new that was basically state of the art. But if you look at the underlying protocols, you would see that this just brings in transactions. That's the protocol or the the workflows that are used for contactless for the traditional chip cards to the contactless level. So you basically take what you have and put basically NFC on it and and that's it. And I'm not going into too much detail when it comes to the contactless transaction. Where he was talking about in the transactions and it's actually going on the lowest level, looking at those banks, looking at the protocols and what actually makes 
a transaction work in the end, what data elements are involved in there. But for us, it's important to first have a look what is actually or who is actually involved in an overall transaction. And this is not only true for a contactless transaction, also contact transaction using a chip card is basically using the same entities. So on the one hand, you have yourself as a shopper, as somebody who wants to buy something and you have a credit card. And this credit card is given to you by a bank, by your bank. And because this bank issues you with the card. This bank is quite an issuer. And then on the other side, you have a merchant who owns a store and he wants to accept credit card payments. So it needs a terminal. But just owning a tunnel doesn't give him anything. He needs to have a merchant account within a separate bank where in the end the money is basically put onto and this is called an acquiring bank or acquirer. So now we have two sides and basically they itself look fine. But in some way we need to bring those two together. And, well, we know what we use. We use the network and in our case, we use payment networks. This would be, for example, the Visa network, the MasterCard network, American Express Network, the networks that are available, and they interconnect to the acquirers and the issuers so that in the end the payment can be transacted between all parties. Not that we know who basically is involved in a transaction. Let's have a look the of the different faces or steps you go through during a transaction before you can actually make a transaction. Well, you need your card. So this is the card issuer you step and the merchant needs his terminal. So this is a terminal provisioning where he gets a terminal. If it's configured and gets the correct configuration to load it there and and set up and configure what kind of cards should be accepted. And then we at this point where we actually want to make a transaction and there you basically go through thre
e distinct phases. So you have a phase where you tap your card to the to the terminal. Then you have a phase where the terminal is doing some internal stuff, evaluating what the data that it actually received. And most likely after that, it will go in a phase where it basically goes online. Users network. Talk to the issuer of your card to check if you actually have funds on your account and if this transaction is genuine and should be actually approved. And after that, we have a separate phase, which is not that important for us, which is the transaction settlements or this in the end, make sure that actually money moves from one account to the other. We're going to focus on the on the three highlighted here. So imagine you go into a store and want to pay with your cart, the first thing is that on the terminal the amount is basically shown and you as a shopper, go there and tap your cart on on the terminal. And the terminal in this face basically says, OK, well, I have a contactless card in my proximity and I have a basic idea what kind of cards sources the Visa card is, as a MasterCard says, an Amex card, JCB, you name it. And as a first thing before actually continuing with the transaction, it activates a special kernel. And what a kernel is, is an implementation of of a payment workflow that is specified by the schemes. So visa mandates a different workflow, how the card and how much would interact as part of a contactless transaction. And then MasterCard, for example. All this was easier during a normal chip transaction because there was only one kernel. Now we have seven or eight kernels and each payment scheme has its own kernel. And after the correct kernel has been loaded and activated, the kernel now drives the transactions between the card and the terminal. And the next phase is then the the data exchange phase where the terminal asks the card for some data to be given out in order to complete the transaction. And what is normally included is, first of al
l, the account data. That's the credit card number, expiry date information like that, which is crucial for actually routing the transaction to the correct bank and making the transaction work. In the end, you get a signature on specific data elements that the card generates and which allows the terminal to check if the card is an actual payment card and the card also generates a cryptogram. That's in the end cryptographic hash that allows the issuer in the end to verify that the transaction is genuine and that it's like a recent transaction, not a replay, for example. And all of this just happens between the card and the terminal at this point. After that, you can remove your card. And that's also one of the big difference already. If you would do a contact transaction with a chip, the chip card needs to be in the terminal until the complete transaction is done here. You can remove it and you don't accidentally wriggler with it and trigger a board. Sort this out to provide some more usability features. Also, the next phase we're looking at is then what's happening on the terminal. And at this point, only the terminal is doing something. And first of all, it checks if this card should be accepted at this location, could be that the card should only be used domestically in a country. But it's not the country of the merchant. It could be that this card is an ATM card and shouldn't be used at a retail location, for example. And those things obviously check first as a second step. The the terminal is verifying the authenticity of the the data it received from the card. And for that there is a public key infrastructure in place at the top. There is a Rutka from from the payment schemes and below that we have ACA from the actual issuer off the card. And then we have certificates which were put on the card itself. And as a basically as reading data, it got this this kind of data. And using public infrastructure, the terminals can actually check if the signature that was cr
eated by the private key on the card was provided or created by an entity which at some point was signed by the by the rootsier. And then as a last step, there is this phase of a customer verification. You probably know this. You're going to a supermarket, pay for a couple of things. And in the end, you're asked for a signature or a pin new with contactless transaction is that if you're below a certain limit, you're not asked for anything. But nevertheless, you are going through this phase and most likely, especially with contactless transactions at the end, the terminal decides, well, I should go online and check if this account is actually valid, has the funds that I want to get from it. And then the terminal starts a chain of transactions or of of hops and the terminal sends the data, including the account data and this cryptogram to the actual acquirement bank. And from there, the bank sends to the global payment network. And based on the first digits of the credit card, the payment networks know what the actual issue is because every issuer has assigned a specific number, a range. And then in the end, the issuer receives this kind of data, sees the cryptogram, and basically is able to verify that this is a genuine transaction made with the card that says it is and checks if the funds are available and then hopefully approve the. Transactions in the end, and then this basically goes from from the lowest end back to the terminal. It shows approved and in the end you get your goods and can leave. So that's basically looking at a whole transaction as a as a as an entity. Talk a little bit about what kind of data is exchanged as that. I think it's interesting to see what actually is supposedly saved on their credit card. Again, teams talk about EMV has some more detailed information on that. But what you basically get is account information. You get your primary account number, your credit card number, basically, you get your track to equivalent data. That's basical
ly a data element which mimics the data that would normally be on mag stripe if you still had one. They are still networks which only wrote those kind of information and not the whole transaction data. And for backward compatibility and legacy reasons, this is still present. So from that, you also, for example, have the expiry date, then you have verification information. So what kind of verification should be supported? The card can make some recommendations. The terminal has some information. What it actually supports that has a pin pad does it doesn't have a pin pad. Should we accept signatures, information like that? Then we have the authentication data where you basically get the reference to your see a public key from from the card schemes. You get the public key off the card itself and the resulting sign data to check offline on the terminal if the transaction is valid. And then you have the authorization data, which is I mean, aside from the card information, the amount and currency, which is crucial. I mean, in the end, you want to get a specific amount during the transaction and then you add the date and time the cryptogram, which allows the issuer to verify that this transaction is genuine. And that's basically the information that's used during a transaction. The format or the protocol that is used for the communication between the card and the terminal is ISO seven eight one six. That's basically what's normally talk between a card reader, any card reader and a chip card. And the payload is BRT, LV and encoded. It's like an S encoding format which allows you to add more or less data as part of your communication. And we been talk about the communication then between the terminal and the acquirer or the entities behind that. You have mostly an ISO variant of ISO eight five eight three, especially with the acquirers, but also banking networks uses. And that's a bitmap based format which has a very weird bitmap combinations and is a it's a pain to to back 
if you if you want to send a valid message there. Yeah. So comparing NFC to I.C.C., why should I use it. What's the benefit. Why actually go for it. So normally you have a lot faster transaction times. There are timing limits on how how fast a card and money to interact in this first interaction face. And you can also remove the card already after this phase and this is normally completed within a second. You also get some benefits when it comes to verification, verification methods and limits. So they introduced or rediscovered something which is a no KVM. So this means you don't have to provide a signature or a pin. And they introduced a limit under which you don't have to basically provide anything. In the end, this was probably added to ease or to incentivize you as a shopper to use contactless transactions. But then again, we also have legacy. And this means that NFC transactions run in two operating modes, EMV mode, which is basically upgrading I.C.C. transaction to contactless. And then we have an extra mode for those networks back then in the US, but also in other countries around the world, which only can allow to extract information and not EMV or I.C.C. information. And they are. This relies heavily on just using track to equivalent data. So now we have seen how complex this transaction is made, what steps we go through, what is required as part of of data elements for actually making a transaction. Now we want to talk about how can we actually make a smart phone, simulate or emulate such cards, and not everybody should be able to just do it and say, well, I want to have my card on my phone and that's it. And they are two distinctive ways on how you can do this. And the first one is especially using something which is called a secure element, which is an enclave for cryptographic and sensitive information, which basically, once it receives this kind of information, no longer gives it out to a micro HSM, if you like. And your normal chip card is basically 
a secure element. But nowadays we also have phones which include this. So also, again, looking at the parties, if you talk about secure elements and providing this information required for making a transaction to a secure element, what do we need there? Well, on the one hand, we need the smartphone or in this case we are talking predominantly about a smartphone which has this kind of secure element and which at some point receives the information and data required for emulating a card. And then we have something which is called a trusted service manager. This exists for a long time. And this is also the entity which normally provisions your actual chip card, and it holds the cryptographic keys to actually modify data within those enclaves. And now this this entity is also then linked to your smartphone and has the power to actually load information in there. In the past, we have also seen secure elements as part of the SIM card, but they are, for example, the trusted service manager was the mobile network operator. So you had another player in there and this never really took off. And so we have our next try with the smartphone and some entity which is a trusted service manager. There is not just only one service manager, but they are a lot of them. And the one who is provisioning your smartphone isn't the one that also provisions your your smart card in your traditional credit card. But those are the two roles which play a major role when it comes to making a secure element able to to make a contactless transaction. So looking at when do we actually get the data into the the secure element? Well, I mean, you want to make a transaction with this element you have. So you have to do it before actually making the transaction. But most likely, you already have a card. So this happens right before your first transaction. After that, you can make as many transactions as you like. And looking at exactly how this how this works out, in the end, um, you as a user normally en
ter your credit card number on your smartphone. You scan it, you enter it manually, something like that. And then your smartphone or your app talks to the trusted service manager, gets the information, hey, I want to provision this kind of card. And this trusted service manager normally has a connection to your issuing bank or a group of issuing banks. And then there are checks saying, well, I want to add this card to my secure element or to this specific phone, can I do this? And normally then the first thing the issue is doing is talking to you as the owner of your card on a second channel, as a mass email or whatever, and ask you, hey, if somebody is asking to provision a new new card to your smartphone, is this actually you? And do you approve this in the end? And as long as you don't do anything, nothing is happening. So you actually have to confirm this and then the issuer gets active again and provides to the to the trusted service manager the information, the cryptographic keys that need to be embedded into the secure element. And from there, it goes back to the to the smartphone. And from there on your smartphone is actually able to just mimic an actual smart card and drive a transaction at a a contact at a contactless transaction. Contact a credit card terminal. But well, I mean, in the beginning, I talked about cloning, I mean, there's not really true we saw this what we do, we rather provision an additional card that is added to the secure element. And this means that the issuer has the means to distinguish between, hey, we are now doing a transaction with like an actual card and we're doing a transaction with a phone which has been loaded with the the information about how to make a card. Also now we have a smartphone in place. We don't have the cards. We have something which has logic there and most of time also has biometric sensors, other means of of verifying that there's actually the right person using the phone. And what this basically changed or 
added was an additional verification method, which is called cardholder device TVM or on device verification. And those of you have who has used Apple Pay maybe in the past. This is when you press your home button with your finger and authorize the transaction by this. And this is basically a station of this device that the right person used that term, the smartphone, for making a transaction. And when we talk about the data that is loaded onto the secure element. This is basically the same as if you were a chip card or a NFC card that was actually handed out by your bank, but most importantly, it also includes asymmetric and asymmetric keys that are needed for generating the same data and the cryptogram. And this is really what makes the the transaction or at the same security level as if you would use a traditional ID card to the to the level where you use your smart card for a transaction. And this uses the same verification method and on the terminal level and also on the bank level, to see that transaction is actually genuine. This is one way to do it, but not everybody has a smartphone which has a secure element, which is also trusted by all the issuers. And this is why we have another way of making a smartphone able to act as a as a card provider. And this is called host card emulation, and what we have there is basically we have a smartphone could be any smartphone. In the end, you need NFC capabilities in there. But other than that, you don't really have many requirements here. And then you have your traditional payment network or the issuer which is behind that. And what is happening here is that your smartphone no longer receives those generally valid crypto cryptographic keys, but it only gets limited use keys or one time keys. Basically a code book that can be used for a couple of transactions from the network, but it cannot be used for repeated transactions. Same as is a secure element. You want to make a transaction with your newly provided informatio
n. So this host card emulation provisioning also needs to happen before actually making the transaction. But in addition to that or compare in contrast to the secure element, you only get information that you can use a couple of times. So you need to have a constant network connection in order to make repeated transactions. And if you also look at how this works out, in the end, you again enter your credit card information on your smartphone, you scan it, whatever, this send directly goes to the payment networks. So there is no trusted service manager involved there. And then depending on the solution you are using, either the payment networks themselves generate those one times that can be used for making a transaction or this is also forwarded then again to the issuer, to the one who actually gave you your card. And they are then generating those limited keys and and they are then basically headed up again to your to your phone. But the data that you receive isn't really stored in a in a secure element stored within your application data. So comparing those two methods, H.S. versus AC provisioning, um. One of the benefits of H.C. is that you don't need a totally secure environment, but if you have it, you can still use it. So you can also put your one time keys into a secure element. For example, um, and normally with HHC, you only get limited use crypto keys, which are then stored within the app and which need to be renewed every now and then. And this is also then the catch here. Well, what what happens if your smartphone doesn't have any cell reception and you want to make a couple of transactions? Well, after you have used your a limited number of of keys to basically create the cryptograms for a transaction, you're out of keys. So at least every once in a while you need to make network connectivity to refresh the number of keys that that you have available. And you can also see that he is receiving a big push from the industry. So actually, the payment scheme
s, a payment network and FOX themselves provide SDK for app developers to add to into their applications, which abstract away the network communication, which gives predefined interfaces that you can use for from making the transaction. And which basically is I mean, if you look at it from their side, every transaction that is made through one of the networks makes some money. So they want to basically bring more people onto that. And here they actually have an influence, a secure element they cannot modify, but they can bring other developers to use it for their transactions. Well, now we know how we can get data on a terminal and act on a on a credit card on a smartphone. And well, now we we have this data and there and it can simulate now an actual card. But well, in the end, I don't want to have my credit card data lying around in some kind of of application written by some app developer or maybe not even by a bank. I mean, we have seen what this would result in. So there is another thing that was recently introduced, which is account data tokenization. And what this does is basically it replaces your credit card number with a token equivalent. This is basically same format, same length, again, for legacy reasons, probably. And this can be used interchangeably with your actual credit card number. And this is something that can then be stored within your app. Well, new features in new players, we have now a token service provider that's a service which stores mappings between tokens and the actual card number and provides interfaces to adding new ones and to converting from one to the other. And then you have the token requestor, which requests new tokens from from the service provider or ask. It's to translate from one from it to the other. Luckily, this happens in the same face as if he would do HHC or as you provisioning, so you also want to basically convert your credit card number to a token before you actually do a transaction. And what this then looks like
 is that you have your your phone, which knows about your credit card, that you want to use, this then goes to the token requester, which, for example, could be Apple, could be Google. And what they do, they add some information about who you are, maybe your credit history with iTunes or something, or the App Store. And they then talk to a token service provider and provide them with the card number and basic information, how they know you. And they then talk to the payment networks. And from there it goes into the issuer and the issuer can say, well, OK, this account, this is existing is valid and it's OK to end it as a as a token, basically. And then this goes back to the to the tokens, to the token provider. And it basically stores an extra number of generates a token and gives it back through the requester to your phone. And then you have a phone which knows about a token. It can discard the credit card number and use this now for every transaction it it's doing. Well, why would you want to use tokenization? Well, I mean, yeah, provide security benefits, so the account number is no longer used outside of payment networks. Um, the other benefit is that you can limit the scope on those kind of tokens so you can say, well, this token that was requested was requested by IEEPA. So this is only valid for point-of-sale transactions using NFC or other kind of transactions through Amazon through an extra part our declined because it's not intended to be used like that. And the other benefit is that the tokens can be revoked individually. So, for example, if you have two devices and you load your same credit card on both devices, they will receive a different token on each device. And that means if one device is compromised, you can basically cancel this token, but the other ones are still working and do extra credit card numbers, not compromised because it's not safe there. Think of it of A and an F specific password, if you use Two-Factor the authorization, something th
at you give one entity which you can revoke all the time without affecting the others. And the other benefit is that you can use a token not only for point of sale payments. You can also, for example, use this in an e-commerce context on Amazon, for example. All right, so we know about how can we make a phone act as a card, we know how we can make this a little bit more secure. And this is now where we can look at Apple pay and Android pay because they use actually those kind of information. Many in charge ever pay users the secure element on the iPhone that you have and an addition, appliance account, data, tokenization, and as a result, you get Apple Pay and. If you look at Android pay and this is rather similar, but they don't have a secure element. We have a fragmented market where you cannot make any assumptions. And this is why they basically are betting on host card emulation. And in addition to that, they are also applying account data tokenization. And in the end, this is Android pay. If you look at a transaction, what kind of workflows are happening there, what kind of data is exchanged? Let's assume we already basically went through the initial stage of presenting a card of your phone. Actually, you get rid of the card. So we presented the phone to the terminal. It read the data, and now we end this online phase where we actually want to talk to the issuer. Instead of having your credit card number, you now have the token. In addition to that, you have the cryptogram that was generated exactly for this transaction, for example, by the secure element. This traditionally goes then to the acquirer. From there, it enters a payment network. And now one additional step is happening. The payment network says, well, OK, this is a token. This is not a card number. I don't know where to give this to me. So first, I have to ask the the token manager, hey, can you convert this back to a card to me? And so the token guest goes to the manager and you get returned the e
xtra card number. But this happens within the credit card networks where more or less every information that's floating around there is visible in plain text anyways. And from there on the payment because they know, OK, well, OK, this is a Visa transaction and this Visa card belongs to, for example, my Sparkasse here in Absi. And then this data basically is is given to this bank and the bank can then do the normal checking of checking. Is this a valid card? In this case? It's a smartphone. Is the the cryptogram valid for the transaction and then gives it OK back? And that's basically what makes a transaction when using HCI or a secure element in particular Apple Pay or Android pay. In this scenario, Google or Apple would play the role. Um, I wouldn't play no role in this because as soon as the data elements are provisioned, they are more or less out of the transaction and they also then no longer see the actual data. So now we have seen, OK, Apple Pay, Android pay, um, it's at a different security. What's happening after that? Well, first of all, especially in Germany, I want to actually be able to use empathy. I envy my friends in the US, which uses on a daily basis. I'm still sitting here. I cannot use Jarobi, but, well, this is not helping me. Um, but if you look around, there are other things happening. There's something which is called issue a great HHC. The issue. I saw that. Well, we don't really need a token manager in the workflow. I mean, I can actually now give out tokens to to my customers via my my own app. I can also give them the keys that are necessary for that because I'm in the end, the one who is verifying them and would be issuing them in the first place. And this also enables those issuers to to give out cards. But Cardless, just provisioning a card to your actual phone without sending you a physical card. We have also seen alternative payment methods. I mean, traditionally, banks are slow to adapt to new technologies. And then there were other 
players which basically came in, for example, especially in the Asia region, we have new ways of making a transaction which removes the card and the terminal all together. And then we end up with Alpay or WeChat, which just uses a QR code on the phone and an application on the phone of the merchant to to make a transaction. And another thing well, I mean, legacy for the win. Those are big networks, networks, this enables you to actually use your card in Germany, in Spain, in Mexico, in the US, in Iceland. Um, this will not change overnight. They are too many parties involved and everyone has their own agenda. They are. So probably in the next years we see alternative methods, but will always see credit card terminals, credit cards and smartphones acting as credit cards and to finish with a personal touch. I work in this area. Yes, I know. It's a it's a very slow progressing area. It's use a lot of legacy code. But in the end, this is a best playing field for you to actually improve something to find new new areas where you want to improve. And this is actually why I got into this. And with that, I want to thank everybody and thank you. All right, we got enough time for questions, please line up at the microphones if you are interested in anything you want to ask something to. Simon, do we have an Internet question? Apparently not so oh, microphone number three, please. Yeah, thanks for all those insights. That was great. You mentioned that the token requests are at some date like credit history, something when they want a token. Could you briefly explain why this is necessary, what this information is used for? Well, in the end, this information. Well, for example, if you talk about let's use this as a combination. Apple has like a history of if you're actually a recent user of this card, if you have used it for a long time, how credible you are. And this is just used for making sure that a second card is issued to the right person. In the end, this is the most like
ly attack scenario for Apple Pay, for example, that somebody is using your card and add a second one to his phone and not to your phone. And those kind of information is just making sure that the right person actually you are requesting a second card on their phone is kind of a fingerprint. It's not I wouldn't say a fingerprint because it's not reused at a later point. It's just a point, a collection of a few of the current moment of what you have been done and how authentic this request seems to be. Or for those who are leaving, please, a little bit lower down your voice and the noise we still have going on here. So microphone number one, please. Do I see any difference as a customer if I use a secure element or just emulation? So the maximum amount or what happens in case of fraud or what happens if the Android phone is routed? So this depends on basically the provider of the sea solution. In general, they are on the same level, but the one who gives out this one time could limit them to a certain amount they normally are to limit how many one time keys you normally get at a certain point. So five or 10 is normal. And you're right, if your phone is routed and somebody else gets access to those, they can be used for actually imposing a playing imposter and making a transaction. But this is limited to the ones that you receive. This is actually why you limit the number at the number of tokens that you get for HCV because they are not protected, as if you would be using a secure element then the bank blaming me or is it? So this is an interesting part. I don't know about any case. So I don't know. This probably is a case by case analysis. OK, let's move on to microphone number six. There's somebody over there. In case multiple cuts of ricin violence range is collision detection and cuts no apply to or just in general ever, and nothing happens. So, yeah, this is detected. The guys who basically invented the contact aspects said, well, OK, if you detect a collision, we
 say, well, just present one card. So you get an error message indicating to you as the one who was providing the cards, hey, please just provide one card and that's it. Probably to make it easier to differentiate which contract should be used and not adding a new selection interface to prolong the transaction. Yet I can present my entire wallet. And you can. You can, but this will not work. All right. Microphone number two, please. Hi. So if you go back to the obscure element provisioning step. Yeah. Would it be nice to see that on the screen? Let's have a quick look. Yeah, so the bottom two lines is that that's basically a blob holding the secret keys, right? So what the issuer gives back to the to the trusted service manager and then to the government is basically a well, a standardized, if you want, which show it's like the private crypto keys for the asymmetric and symmetric encryption. Yeah, but those are encrypted, right? Well, kind of, yes. So they are encrypted by between the issuer and the service provider and then from there to the to the phone. So it's not like you just apply to Leser or something, but it's actually they have shared keys which encrypt this on both sides so and so only the service provider can do this. Yes. And only the service provider has the knowledge about how the secure element can be forgiven and the keys for actually changing data in there. Yeah, so. And who is that? So in case of Apple Pay, this is Apple and in any other case, well, I don't know about any other solution which uses a secure element to make a contactless transaction work and. Well, in the case we don't have this entity, but it could be, for example, if you talk about a traditional credit card, then this could be, for example, about who Oberoi Gemalto, though, the creators of the or the the manufacturers of the actual cards that you get sent by the bank and the keys of those secure elements are diversified. Yes. So there's not one provider who has every keys, but bas
ically they are a couple of entities which then have their own access to their cards, basically. So what I mean is, can they go on to the next question? I mean, this is a dialog some I'm sorry, that's a little bit too much with an Internet question. Please just open up to the Internet. Wants to know, are tokens static on a device or are they ever updated? And would that be an advantage to changing them? So the the the one time he said, are we we're talking about the tokens. So the token, once it's basic provisioned, they are normally static until you basically say, well, I want to add another card. Even if the same card, you would probably get a different token. But in general, it's basically static. Yes, there would be a benefit in changes regularly, just removing fingerprinting options there, but I think the major benefit of actually having this kind of option is that you can hide your actual credit card number. And this, I think, was the primarily focus on the. OK, microphone number four, please. You were talking about payment networks like MasterCard and Visa. It's the same technology used for contactless payment cards known as zero. This is completely different. It's similar. I mean, the card has its own card, which should be running on the terminal. And you don't have this those global payment network, if you will. But you have like a local German network, which is connected to a different service providers. But the handling overall is more or less similar. And microphone number five, please. I, I heard or I often hear that risk management is one of the most important things for creditcard institutes or pretty important thing. Do you have any experience in this or do you know if there really is so much money stolen from the Kennicutt institutes or during the transaction? Well, I think you have to differentiate. I mean, there are credit card issuers or companies who have been doing this in a long time, and especially in Europe, they are very keen on checking th
e data as part of the risk management. When EMV was introduced in the U.S., there were instances where the bank introduced EMV, but they didn't check any data. So you could just send in transaction, they would be approved. So, yes, this happens from time to time. But if the correct checking is implemented, then this is very hard. OK, let's get back to microphone number three. Hello. I think you forgot to mention another alternative you can pay with the phone or nearly pay with the phone, because some banks are also issuing near the card, the near field communication sticker that you can just put on the back of the phone. And it works even when you don't have the signal. Isn't that the easiest way? Well, this works. And yes, you're right. This is also one of the options that you can use. In that case, you doesn't even necessarily need a phone. You can stick this to anything. And true, this is like a key FOB or something that you carry around with you. This also works. This has been tried in Germany, for example, the network operators, T-Mobile and so on have tried this, but it didn't reach critical mass and never took off and then they borrowed it. I guess this is now the next try of getting it to the masses. My country in Slovenia, that's released by the bank and you can buy with it. Well, this is just an alternative than to the actual credit card. Just. OK, number one microphone, please. OK, so when I got my one of the last currence a couple of years ago, before the first time that I could pay contactless, I had to pay with a contact. I had to instruct the card. Is there a technical reason for that? I don't know. I think this is just checking that everything is OK and that the account is still available. Otherwise you could, for example, use this card for below contactless limits without needing any pin or anything else. I think this is just a first rate check, but there is no technical reason for it. And microphone number six, please, when using host card emulatio
n, how do the limited use keys get updated? Does that require Cataldo interaction? Does that happen automatically? So this normally happens behind the scenes. So you as a user of the smartphone don't see this. This happens basically asynchronously in the background. And whenever the phone sees well or the application says, well, I'm running out of keys, it refreshes. Let's go to microphone to please. Oh, hi. Could you elaborate a bit on why the banks are pushing more for house cars angulation than see, I understand why Google uses host card emulation, but the banks are pretty powerful entity and could basically put their weight behind forcing manufacturers to use Azeez. Why don't they? So from what I understand, yes, they couldn't put more focus on that. But in the end, you also need manufacturers who want to support it. And if you're looking, for example, at Android, it's pretty fragmented. There might be one manufacturer who adds a secret element to their phone. But, well, first of all, you need to basically be able to cater that for markets and sell it in markets. So in Germany, it doesn't help me if a Chinese maker is adding this to a smartphone. And I'm also not so sure how how how much I would trust this implementation. So a secure element is basically has the same capabilities of a card. So you need a trusted entity in there. And this is, I think, why the why the issuers basically focus more on host card emulation, because they can actually influenza's they don't have any external requirements of some some manufacturer adding some stuff there. For example, with Android, they just need a recent handset with I think Android for plus and then they more or less good to go. All right, any questions from the Internet? No. OK, let's go onto microphone number four, please. Thank you for the great talk. I wonder if there are any liability changes when this new workflows with mobile payments arrive like secure element and guard demolition. Who is liable for the fraud i
n this case is because there are no new players. For example, the trusted service providers, which basically owns the secure the Krypto Keys for the immolated cart. But overall, this doesn't change anything the same as if you would use your credit card. Yes, there's somebody who says you can put data in your secure element, but those types of entities have been existing in the past. The ones who basically provisioned your own actual physical card and they undergo the same certifications or I don't know what you want to call this like the same requirements in order to become one when it comes to securing your data. So in the end, the same liability is there. And as long as you use EMV, you are protected by it, except for if you use a pin or something, whatever, with the banks come up with Indiantown. But in general, if you use EMV, the liability is with the with the bank. Second question, is there such a thing as an offline contactless payments? And if there is, how widespread are they? Technically, yes, you can use it, but this then really shifts the liability because then you are ignoring the result of the transaction and just trying to accept it. But you have to differentiate between saying, well, I want to use I want to work in a in a strictly offline environment. And I have an often approved transaction, which could also happen. But nowadays, I think in almost all countries that I've been working with, there is this this flaw limit which indicates the terminal, when should I go online for a transaction? And this is at zero. So normally every transaction is authorized online. OK, and microphone number five, please. I think there is somebody over there I had us spin verification work and how is it different compared to chip transection? So when looking at a chip transaction, you normally have three ways of verifying a pin, so you can basically check this offline. So just between the terminals and the card and then you have two ways of encrypting it or doing it pla
intext. So this is how the terminal communicates with the card and actually wants the pin to be verified. And then there's a second third option, which is online pin, where the pin that you enter is actually encrypted on the terminal. And then together with the authorization sent to the bank and the bank checks that the pin is actually valid. And when we're talking about off of contactless transactions, then only a third option is actually available. So if you use a pin for connect this transaction, there's always goes to the to the issuer for it for checking because there is no card anymore for verifying the pin off-line. And microphone number three, please. My question would be about Apapa in Germany, banks in Germany seem to be reluctant to accept it and implement it, unreasoned seems to be that they have to give up a little share of the transaction, the transaction fee that they receive. My question would be, how does how does Apple know about the transaction and which data is sent to Apple when I pay with the phone so I don't want them to be involved too much. Yes. And in the end, they actually aren't. Well, in order to basically be able to use Apple Pay on your phone, your issuer needs to participate in this charade of provisioning and card. And this also then means that they enter an agreement that percentage of every transaction is basically paid out to Apple. And this happens basically independently of making the transaction. So the the the issuers are aggregating basically the transactions and then basically providing Apple with information of how much they get. There is no direct feedback as as part of every transaction to Apple. That way. I made a transaction about this, and this means that you get that. So this is like a trusting contractual agreement between the issuer and the and Apple. In microphone number one, please. I also worry about transaction privacy and is this any different of Android pay? Do they get any transaction data? So this is kind of
 similar. Also their. In general, Google doesn't get any transaction data. They have access to the same elements that you have as part of a transaction. But after you apply the tokenization, you also just have your replaced account number. In theory, they could do more. To be honest, I don't know, hundred percent what they actually store and what is basically transferred as part of a transaction. But I would assume that this is similar to what Apple does because this is a highly sensitive topic. And if there's any wrongdoing there, then this would create a real shitstorm there. OK, we're getting time, there's one more question left is it looks like please microphone for hello, thanks for the great talk, but I think you missed something, OK, and maybe I missed it, but you never mentioned number 26 with this QR code paying. Well, I would say that's similar to the alternative payment methods, which basically come up and this is a way where you no longer need a card, actually, you just need your smartphone to display a QR code. And this is an scanned at the at the cashier system. And this basically includes information of making the transaction. Yes, you're right. This is a valid way of doing this, for example, in Germany. But I wanted to focus on actually making like cloning or making card payments with your smartphone as a replacement for for normal credit card. So this is why I didn't focus on that. OK, thank you. OK, thank you very much, Seimone, apologies again for the small delay. Thanks a lot. The.