0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/882 Thanks! 1 00:00:16,670 --> 00:00:18,829 Imagine you are at the checkout, 2 00:00:18,830 --> 00:00:21,379 at the checkout at the supermarket, 3 00:00:21,380 --> 00:00:23,479 and you take your 4 00:00:23,480 --> 00:00:25,099 cash card, you get something like 35 5 00:00:25,100 --> 00:00:27,169 years to pay and you place 6 00:00:27,170 --> 00:00:29,269 it just on the top of the 7 00:00:29,270 --> 00:00:30,979 terminal. It makes it beep 8 00:00:32,180 --> 00:00:33,829 and you have paid well. 9 00:00:33,830 --> 00:00:36,019 How does near field communication 10 00:00:36,020 --> 00:00:38,089 work and in 11 00:00:38,090 --> 00:00:40,339 particular, what happens 12 00:00:40,340 --> 00:00:41,590 at the protocol levels? 13 00:00:42,920 --> 00:00:45,049 Well, the answers are given 14 00:00:45,050 --> 00:00:47,149 now by Simon Wemyss, who 15 00:00:47,150 --> 00:00:49,249 is a co-founder of Pay Works. 16 00:00:49,250 --> 00:00:52,189 It's a company specialized 17 00:00:52,190 --> 00:00:54,529 in point of sale payment 18 00:00:54,530 --> 00:00:56,299 Gateway Technologies. 19 00:00:56,300 --> 00:00:59,029 Simon has studied 20 00:00:59,030 --> 00:01:01,189 informatics in Munich, 21 00:01:01,190 --> 00:01:03,379 in San Francisco and in 22 00:01:03,380 --> 00:01:04,759 Los Angeles. 23 00:01:04,760 --> 00:01:07,339 So let's welcome now Simon 24 00:01:07,340 --> 00:01:09,499 with his talk on 25 00:01:09,500 --> 00:01:11,569 decoding contactless card 26 00:01:11,570 --> 00:01:12,529 payments. 27 00:01:12,530 --> 00:01:13,780 Simon yachters. 28 00:01:19,260 --> 00:01:21,539 Thanks a lot, Anchia, what 29 00:01:21,540 --> 00:01:23,159 a crowd. Welcome, everybody. 30 00:01:23,160 --> 00:01:24,240 Thanks for joining tonight. 31 00:01:26,310 --> 00:01:28,079 And tonight, I want to talk about 32 00:01:28,080 --> 00:01:30,149 contactless card payments and how we go 33 00:01:30,150 --> 00:01:32,759 from, like, inserting 34 00:01:32,760 --> 00:01:35,669 a card to tapping a card 35 00:01:35,670 --> 00:01:37,799 to, in the end, just tapping your 36 00:01:37,800 --> 00:01:38,969 smartphone. 37 00:01:38,970 --> 00:01:41,159 And full disclosure, I'm not 38 00:01:41,160 --> 00:01:43,289 talking about, like, exposing 39 00:01:43,290 --> 00:01:45,149 new security risks in that format. 40 00:01:45,150 --> 00:01:47,039 And also, I'm not going on the lowest 41 00:01:47,040 --> 00:01:48,929 level of the EMV protocol, which is 42 00:01:48,930 --> 00:01:49,930 basically below 43 00:01:51,060 --> 00:01:52,139 running this. 44 00:01:52,140 --> 00:01:54,209 But I really want to focus on the 45 00:01:54,210 --> 00:01:55,679 status quo. 46 00:01:55,680 --> 00:01:57,179 How is basically a contact conductor's 47 00:01:57,180 --> 00:01:59,159 card transaction working? 48 00:01:59,160 --> 00:02:00,160 How do we do 49 00:02:01,230 --> 00:02:02,219 Apple pay? 50 00:02:02,220 --> 00:02:03,689 How do we do Android pay? 51 00:02:03,690 --> 00:02:04,889 What is involved there? 52 00:02:04,890 --> 00:02:07,499 And why is it not possible to actually 53 00:02:07,500 --> 00:02:09,899 take a card and clone 54 00:02:09,900 --> 00:02:12,059 it to your smartphone, something that 55 00:02:12,060 --> 00:02:13,979 the chip would actually prevent you from, 56 00:02:13,980 --> 00:02:14,980 from doing? 57 00:02:16,960 --> 00:02:17,960 And. 58 00:02:19,490 --> 00:02:20,839 Just to give you some context where this 59 00:02:20,840 --> 00:02:23,299 is coming from, we'll get paperworks 60 00:02:23,300 --> 00:02:24,949 where we run a payment gateway and 61 00:02:24,950 --> 00:02:28,369 develop tools for making transactions 62 00:02:28,370 --> 00:02:30,820 easier for developers to integrate. 63 00:02:31,970 --> 00:02:33,709 And over there, I'm mainly responsible 64 00:02:33,710 --> 00:02:35,809 for integrating new terminals, 65 00:02:35,810 --> 00:02:37,159 connecting new banks. 66 00:02:37,160 --> 00:02:39,529 And I want to take the motto of the 67 00:02:39,530 --> 00:02:41,749 Congress to that and 68 00:02:41,750 --> 00:02:43,819 just to that and give you some 69 00:02:43,820 --> 00:02:45,799 insights and what I learned while working 70 00:02:45,800 --> 00:02:46,800 on that. 71 00:02:48,890 --> 00:02:51,499 And, yeah, 72 00:02:51,500 --> 00:02:52,550 let's get started with this. 73 00:02:58,610 --> 00:03:00,739 Probably everybody here in the room 74 00:03:00,740 --> 00:03:03,229 has heard about contactless payments and 75 00:03:03,230 --> 00:03:06,199 has used it, maybe, maybe not. 76 00:03:06,200 --> 00:03:08,209 I mean, in Germany, adoption rate for 77 00:03:08,210 --> 00:03:10,399 contactless transactions are relatively 78 00:03:10,400 --> 00:03:11,479 slow. 79 00:03:11,480 --> 00:03:13,729 First of all, you get a new card from 80 00:03:13,730 --> 00:03:16,189 your bank or your credit card company. 81 00:03:16,190 --> 00:03:18,019 And even if you have that, you still need 82 00:03:18,020 --> 00:03:19,819 a terminal which is actually able to 83 00:03:19,820 --> 00:03:21,559 handle transactions. 84 00:03:21,560 --> 00:03:23,239 And if you then finally do a contactless 85 00:03:23,240 --> 00:03:25,279 transaction, the cashier is looking at 86 00:03:25,280 --> 00:03:27,649 you curiously and saying, well, it's not 87 00:03:27,650 --> 00:03:29,359 that that's not how it worked basically 88 00:03:29,360 --> 00:03:30,360 before. 89 00:03:30,900 --> 00:03:32,929 And in the end, you get your goods, but 90 00:03:32,930 --> 00:03:34,729 they always some surprises waiting for 91 00:03:34,730 --> 00:03:35,730 you. 92 00:03:35,960 --> 00:03:38,089 And what we are looking at tonight is 93 00:03:38,090 --> 00:03:39,979 basically, first of all, what makes a 94 00:03:39,980 --> 00:03:42,049 contactless transaction the 95 00:03:42,050 --> 00:03:43,759 blueprint? What status do we go through? 96 00:03:44,870 --> 00:03:47,179 And then we need to discuss ways of 97 00:03:47,180 --> 00:03:49,489 actually converting your smartphone 98 00:03:49,490 --> 00:03:52,009 into insulating 99 00:03:52,010 --> 00:03:53,780 or simulating a contactless card. 100 00:03:55,580 --> 00:03:57,029 In addition to that, I want to talk a 101 00:03:57,030 --> 00:03:58,999 little bit about making payments a little 102 00:03:59,000 --> 00:04:01,459 bit more secure at the point of sale 103 00:04:01,460 --> 00:04:03,559 or on the e-commerce side in 104 00:04:03,560 --> 00:04:06,649 general, where we talk about tokenization 105 00:04:06,650 --> 00:04:08,269 and then we have all the information that 106 00:04:08,270 --> 00:04:10,639 we need to actually look into 107 00:04:10,640 --> 00:04:12,649 Apple Pay and Android pay. 108 00:04:12,650 --> 00:04:14,629 And in the end, I just want to give a 109 00:04:14,630 --> 00:04:17,509 quick look out on how I could envision 110 00:04:17,510 --> 00:04:18,979 the next steps when it comes to 111 00:04:18,980 --> 00:04:21,169 contactless transactions and transactions 112 00:04:21,170 --> 00:04:22,429 at the point of sale in general. 113 00:04:24,380 --> 00:04:27,109 So looking at contactless transactions, 114 00:04:27,110 --> 00:04:29,479 this is a relatively new technology. 115 00:04:29,480 --> 00:04:31,189 And you might think, well, somebody came 116 00:04:31,190 --> 00:04:33,419 up with something new that was basically 117 00:04:33,420 --> 00:04:34,399 state of the art. 118 00:04:34,400 --> 00:04:35,989 But if you look at the underlying 119 00:04:35,990 --> 00:04:37,879 protocols, you would see that this just 120 00:04:37,880 --> 00:04:39,739 brings in transactions. 121 00:04:39,740 --> 00:04:41,540 That's the protocol or the 122 00:04:42,890 --> 00:04:44,329 the workflows that are used for 123 00:04:44,330 --> 00:04:46,129 contactless for the traditional chip 124 00:04:46,130 --> 00:04:47,779 cards to the contactless level. 125 00:04:47,780 --> 00:04:50,209 So you basically take what you have and 126 00:04:50,210 --> 00:04:52,399 put basically NFC on it and 127 00:04:52,400 --> 00:04:53,869 and that's it. 128 00:04:53,870 --> 00:04:55,939 And I'm not going into 129 00:04:55,940 --> 00:04:58,549 too much detail when it comes to the 130 00:04:58,550 --> 00:04:59,689 contactless transaction. 131 00:05:09,890 --> 00:05:11,689 Where he was talking about in the 132 00:05:11,690 --> 00:05:13,639 transactions and it's actually going on 133 00:05:13,640 --> 00:05:15,169 the lowest level, looking at those banks, 134 00:05:15,170 --> 00:05:16,789 looking at the protocols and what 135 00:05:16,790 --> 00:05:19,099 actually makes a transaction work 136 00:05:19,100 --> 00:05:21,079 in the end, what data elements are 137 00:05:21,080 --> 00:05:22,080 involved in there. 138 00:05:22,910 --> 00:05:25,159 But for us, it's important to first 139 00:05:25,160 --> 00:05:27,799 have a look what is actually 140 00:05:27,800 --> 00:05:29,869 or who is actually involved in an overall 141 00:05:29,870 --> 00:05:31,699 transaction. And this is not only true 142 00:05:31,700 --> 00:05:33,649 for a contactless transaction, also 143 00:05:33,650 --> 00:05:35,719 contact transaction using a chip card is 144 00:05:35,720 --> 00:05:37,789 basically using the same entities. 145 00:05:37,790 --> 00:05:40,069 So on the one hand, you have 146 00:05:40,070 --> 00:05:42,019 yourself as a shopper, as somebody who 147 00:05:42,020 --> 00:05:43,459 wants to buy something and you have a 148 00:05:43,460 --> 00:05:44,460 credit card. 149 00:05:45,770 --> 00:05:47,869 And this credit card is given to you by 150 00:05:47,870 --> 00:05:49,529 a bank, by your bank. 151 00:05:49,530 --> 00:05:51,589 And because this bank issues 152 00:05:51,590 --> 00:05:53,209 you with the card. This bank is quite an 153 00:05:53,210 --> 00:05:54,210 issuer. 154 00:05:54,860 --> 00:05:56,599 And then on the other side, you have a 155 00:05:56,600 --> 00:05:58,579 merchant who owns a store 156 00:05:59,660 --> 00:06:01,819 and he wants to accept credit card 157 00:06:01,820 --> 00:06:04,009 payments. So it needs a terminal. 158 00:06:04,010 --> 00:06:06,109 But just owning a tunnel doesn't 159 00:06:06,110 --> 00:06:07,110 give him anything. 160 00:06:07,910 --> 00:06:10,249 He needs to have a merchant account 161 00:06:10,250 --> 00:06:12,559 within a separate bank where 162 00:06:12,560 --> 00:06:14,719 in the end the money is basically 163 00:06:14,720 --> 00:06:16,999 put onto and this is called an 164 00:06:17,000 --> 00:06:19,369 acquiring bank or acquirer. 165 00:06:19,370 --> 00:06:22,009 So now we have two sides and 166 00:06:22,010 --> 00:06:24,259 basically they itself look 167 00:06:24,260 --> 00:06:26,419 fine. But in some way we need 168 00:06:26,420 --> 00:06:27,740 to bring those two together. 169 00:06:29,030 --> 00:06:31,009 And, well, we know what we use. 170 00:06:31,010 --> 00:06:33,109 We use the network and in 171 00:06:33,110 --> 00:06:35,539 our case, we use payment networks. 172 00:06:35,540 --> 00:06:36,889 This would be, for example, the Visa 173 00:06:36,890 --> 00:06:39,169 network, the MasterCard network, American 174 00:06:39,170 --> 00:06:41,149 Express Network, the networks that are 175 00:06:41,150 --> 00:06:43,069 available, and they interconnect to the 176 00:06:43,070 --> 00:06:44,989 acquirers and the issuers so that in the 177 00:06:44,990 --> 00:06:47,569 end the payment can be transacted 178 00:06:47,570 --> 00:06:48,570 between all parties. 179 00:06:50,420 --> 00:06:51,769 Not that we know who basically is 180 00:06:51,770 --> 00:06:53,179 involved in a transaction. 181 00:06:53,180 --> 00:06:54,829 Let's have a look the of the different 182 00:06:54,830 --> 00:06:56,659 faces or steps you go through during a 183 00:06:56,660 --> 00:06:58,639 transaction before you can actually make 184 00:06:58,640 --> 00:06:59,719 a transaction. 185 00:06:59,720 --> 00:07:01,069 Well, you need your card. 186 00:07:01,070 --> 00:07:03,559 So this is the card issuer you step and 187 00:07:03,560 --> 00:07:05,329 the merchant needs his terminal. 188 00:07:05,330 --> 00:07:07,249 So this is a terminal provisioning where 189 00:07:07,250 --> 00:07:08,779 he gets a terminal. If it's configured 190 00:07:08,780 --> 00:07:10,909 and gets the correct configuration to 191 00:07:10,910 --> 00:07:12,799 load it there and and set up and 192 00:07:12,800 --> 00:07:14,899 configure what kind of cards should be 193 00:07:14,900 --> 00:07:16,159 accepted. 194 00:07:16,160 --> 00:07:18,379 And then we at this point where 195 00:07:18,380 --> 00:07:20,659 we actually want to make a transaction 196 00:07:20,660 --> 00:07:22,279 and there you basically go through three 197 00:07:22,280 --> 00:07:23,209 distinct phases. 198 00:07:23,210 --> 00:07:25,579 So you have a phase where you tap 199 00:07:25,580 --> 00:07:27,469 your card to the to the terminal. 200 00:07:27,470 --> 00:07:28,639 Then you have a phase where the terminal 201 00:07:28,640 --> 00:07:30,829 is doing some internal stuff, evaluating 202 00:07:30,830 --> 00:07:33,019 what the data that it actually received. 203 00:07:33,020 --> 00:07:35,419 And most likely after that, 204 00:07:35,420 --> 00:07:37,669 it will go in a phase where it basically 205 00:07:37,670 --> 00:07:39,169 goes online. Users network. 206 00:07:39,170 --> 00:07:41,269 Talk to the issuer of your 207 00:07:41,270 --> 00:07:43,459 card to check if you actually have funds 208 00:07:43,460 --> 00:07:46,009 on your account and if this transaction 209 00:07:46,010 --> 00:07:47,809 is genuine and should be actually 210 00:07:47,810 --> 00:07:48,979 approved. 211 00:07:48,980 --> 00:07:51,049 And after that, we have a separate 212 00:07:51,050 --> 00:07:52,969 phase, which is not that important for 213 00:07:52,970 --> 00:07:55,339 us, which is the transaction settlements 214 00:07:55,340 --> 00:07:56,779 or this in the end, make sure that 215 00:07:56,780 --> 00:07:58,669 actually money moves from one account to 216 00:07:58,670 --> 00:07:59,909 the other. 217 00:07:59,910 --> 00:08:01,819 We're going to focus on the on the three 218 00:08:01,820 --> 00:08:02,820 highlighted here. 219 00:08:04,940 --> 00:08:07,729 So imagine you go 220 00:08:07,730 --> 00:08:09,349 into a store and want to pay with your 221 00:08:09,350 --> 00:08:11,989 cart, the first thing is that 222 00:08:11,990 --> 00:08:14,359 on the terminal the amount 223 00:08:14,360 --> 00:08:16,759 is basically shown and you 224 00:08:16,760 --> 00:08:18,889 as a shopper, go there and tap 225 00:08:18,890 --> 00:08:20,630 your cart on on the terminal. 226 00:08:21,980 --> 00:08:24,229 And the terminal in this face basically 227 00:08:24,230 --> 00:08:26,239 says, OK, well, I have a contactless card 228 00:08:26,240 --> 00:08:28,579 in my proximity and I have a basic 229 00:08:28,580 --> 00:08:30,679 idea what kind of cards sources 230 00:08:30,680 --> 00:08:33,079 the Visa card is, as a MasterCard 231 00:08:33,080 --> 00:08:35,689 says, an Amex card, JCB, you name it. 232 00:08:35,690 --> 00:08:37,428 And as a first thing before actually 233 00:08:37,429 --> 00:08:38,539 continuing with the transaction, 234 00:08:39,650 --> 00:08:42,379 it activates a special kernel. 235 00:08:42,380 --> 00:08:44,599 And what a kernel is, is an 236 00:08:44,600 --> 00:08:46,819 implementation of 237 00:08:46,820 --> 00:08:49,339 of a payment workflow that is specified 238 00:08:49,340 --> 00:08:50,599 by the schemes. 239 00:08:50,600 --> 00:08:53,059 So visa mandates a different 240 00:08:53,060 --> 00:08:55,069 workflow, how the card and how much would 241 00:08:55,070 --> 00:08:56,779 interact as part of a contactless 242 00:08:56,780 --> 00:08:58,219 transaction. And then MasterCard, for 243 00:08:58,220 --> 00:09:00,499 example. All this was easier 244 00:09:00,500 --> 00:09:01,999 during a normal chip transaction because 245 00:09:02,000 --> 00:09:03,139 there was only one kernel. 246 00:09:03,140 --> 00:09:05,419 Now we have seven or eight kernels and 247 00:09:05,420 --> 00:09:07,759 each payment scheme has its own kernel. 248 00:09:07,760 --> 00:09:09,589 And after the correct kernel has been 249 00:09:09,590 --> 00:09:11,569 loaded and activated, the kernel now 250 00:09:11,570 --> 00:09:13,939 drives the transactions between 251 00:09:13,940 --> 00:09:15,469 the card and the terminal. 252 00:09:15,470 --> 00:09:17,809 And the next phase is then the 253 00:09:17,810 --> 00:09:19,849 the data exchange phase where the 254 00:09:19,850 --> 00:09:22,429 terminal asks the card for 255 00:09:22,430 --> 00:09:24,589 some data to be given out in 256 00:09:24,590 --> 00:09:25,849 order to complete the transaction. 257 00:09:25,850 --> 00:09:28,069 And what is normally included is, first 258 00:09:28,070 --> 00:09:29,029 of all, the account data. 259 00:09:29,030 --> 00:09:31,189 That's the credit card number, expiry 260 00:09:31,190 --> 00:09:32,869 date information like that, which is 261 00:09:32,870 --> 00:09:34,429 crucial for actually routing the 262 00:09:34,430 --> 00:09:37,099 transaction to the correct bank and 263 00:09:37,100 --> 00:09:38,509 making the transaction work. 264 00:09:38,510 --> 00:09:40,850 In the end, you get 265 00:09:42,590 --> 00:09:44,749 a signature on specific 266 00:09:44,750 --> 00:09:47,299 data elements that the card generates 267 00:09:47,300 --> 00:09:49,099 and which allows the terminal to check if 268 00:09:49,100 --> 00:09:51,439 the card is an actual payment card 269 00:09:51,440 --> 00:09:53,689 and the card also generates 270 00:09:53,690 --> 00:09:55,189 a cryptogram. 271 00:09:55,190 --> 00:09:57,349 That's in the end cryptographic 272 00:09:57,350 --> 00:09:59,449 hash that allows the issuer 273 00:09:59,450 --> 00:10:01,519 in the end to verify 274 00:10:01,520 --> 00:10:03,229 that the transaction is genuine and that 275 00:10:03,230 --> 00:10:04,759 it's like a recent transaction, not a 276 00:10:04,760 --> 00:10:05,760 replay, for example. 277 00:10:06,710 --> 00:10:08,479 And all of this just happens between the 278 00:10:08,480 --> 00:10:10,190 card and the terminal at this point. 279 00:10:11,630 --> 00:10:13,939 After that, you can remove your card. 280 00:10:13,940 --> 00:10:15,349 And that's also one of the big difference 281 00:10:15,350 --> 00:10:16,609 already. 282 00:10:16,610 --> 00:10:18,409 If you would do a contact transaction 283 00:10:18,410 --> 00:10:20,509 with a chip, the chip card needs to be 284 00:10:20,510 --> 00:10:22,069 in the terminal until the complete 285 00:10:22,070 --> 00:10:24,049 transaction is done here. 286 00:10:24,050 --> 00:10:26,149 You can remove it and you don't 287 00:10:26,150 --> 00:10:28,339 accidentally wriggler with it and trigger 288 00:10:28,340 --> 00:10:30,559 a board. Sort this out to provide some 289 00:10:30,560 --> 00:10:32,389 more usability features. 290 00:10:32,390 --> 00:10:34,579 Also, the 291 00:10:34,580 --> 00:10:35,899 next phase we're looking at is then 292 00:10:35,900 --> 00:10:36,979 what's happening on the terminal. 293 00:10:36,980 --> 00:10:38,449 And at this point, only the terminal is 294 00:10:38,450 --> 00:10:39,859 doing something. 295 00:10:39,860 --> 00:10:41,599 And first of all, it checks if this card 296 00:10:41,600 --> 00:10:44,389 should be accepted at this location, 297 00:10:44,390 --> 00:10:46,099 could be that the card should only be 298 00:10:46,100 --> 00:10:48,169 used domestically in a 299 00:10:48,170 --> 00:10:50,209 country. But it's not the country of the 300 00:10:50,210 --> 00:10:52,369 merchant. It could be that 301 00:10:52,370 --> 00:10:53,989 this card is an ATM card and shouldn't be 302 00:10:53,990 --> 00:10:56,419 used at a retail location, for example. 303 00:10:56,420 --> 00:10:58,789 And those things obviously check first 304 00:10:58,790 --> 00:11:00,379 as a second step. 305 00:11:00,380 --> 00:11:02,659 The the terminal is verifying the 306 00:11:02,660 --> 00:11:04,909 authenticity of the the 307 00:11:04,910 --> 00:11:06,290 data it received from the card. 308 00:11:07,400 --> 00:11:09,289 And for that there is a public key 309 00:11:09,290 --> 00:11:10,879 infrastructure in place at the top. 310 00:11:10,880 --> 00:11:12,709 There is a Rutka from from the payment 311 00:11:12,710 --> 00:11:15,289 schemes and below that 312 00:11:15,290 --> 00:11:18,259 we have ACA 313 00:11:18,260 --> 00:11:20,839 from the actual issuer off the card. 314 00:11:20,840 --> 00:11:22,489 And then we have certificates which were 315 00:11:22,490 --> 00:11:24,469 put on the card itself. 316 00:11:24,470 --> 00:11:26,539 And as 317 00:11:26,540 --> 00:11:28,699 a basically as reading data, 318 00:11:28,700 --> 00:11:30,409 it got this this kind of 319 00:11:31,730 --> 00:11:33,919 data. And using public infrastructure, 320 00:11:33,920 --> 00:11:35,359 the terminals can actually check if the 321 00:11:35,360 --> 00:11:37,219 signature that was created by the private 322 00:11:37,220 --> 00:11:39,649 key on the card was provided 323 00:11:39,650 --> 00:11:41,779 or created by an entity which at some 324 00:11:41,780 --> 00:11:43,789 point was signed by the by the rootsier. 325 00:11:45,500 --> 00:11:47,599 And then as a last step, there is 326 00:11:47,600 --> 00:11:49,549 this phase of a customer verification. 327 00:11:49,550 --> 00:11:50,749 You probably know this. 328 00:11:50,750 --> 00:11:53,509 You're going to a supermarket, pay for 329 00:11:53,510 --> 00:11:54,469 a couple of things. 330 00:11:54,470 --> 00:11:56,029 And in the end, you're asked for a 331 00:11:56,030 --> 00:11:57,469 signature or a pin 332 00:11:58,910 --> 00:12:00,919 new with contactless transaction is that 333 00:12:00,920 --> 00:12:02,239 if you're below a certain limit, you're 334 00:12:02,240 --> 00:12:04,069 not asked for anything. 335 00:12:04,070 --> 00:12:05,539 But nevertheless, you are going through 336 00:12:05,540 --> 00:12:08,089 this phase and 337 00:12:08,090 --> 00:12:09,889 most likely, especially with contactless 338 00:12:09,890 --> 00:12:11,869 transactions at the end, the terminal 339 00:12:11,870 --> 00:12:13,849 decides, well, I should go online and 340 00:12:13,850 --> 00:12:16,729 check if this account is actually 341 00:12:16,730 --> 00:12:18,799 valid, has the funds that 342 00:12:18,800 --> 00:12:20,389 I want to get from it. 343 00:12:20,390 --> 00:12:22,489 And then the terminal starts a 344 00:12:22,490 --> 00:12:24,739 chain of transactions or of 345 00:12:24,740 --> 00:12:26,869 of hops and the terminal sends the 346 00:12:26,870 --> 00:12:29,149 data, including the account data and 347 00:12:29,150 --> 00:12:31,249 this cryptogram to 348 00:12:31,250 --> 00:12:33,049 the actual acquirement bank. 349 00:12:33,050 --> 00:12:35,269 And from there, the bank sends to the 350 00:12:35,270 --> 00:12:36,799 global payment network. 351 00:12:36,800 --> 00:12:39,039 And based on the first digits of 352 00:12:39,040 --> 00:12:41,239 the credit card, the payment 353 00:12:41,240 --> 00:12:43,429 networks know what the actual issue is 354 00:12:43,430 --> 00:12:44,989 because every issuer has assigned a 355 00:12:44,990 --> 00:12:47,329 specific number, a range. 356 00:12:47,330 --> 00:12:49,339 And then in the end, the issuer receives 357 00:12:49,340 --> 00:12:51,439 this kind of data, sees 358 00:12:51,440 --> 00:12:53,689 the cryptogram, and basically is able 359 00:12:53,690 --> 00:12:55,669 to verify that this is a genuine 360 00:12:55,670 --> 00:12:57,139 transaction made with the card that 361 00:12:58,250 --> 00:13:00,319 says it is and checks 362 00:13:00,320 --> 00:13:01,969 if the funds are available and then 363 00:13:01,970 --> 00:13:03,069 hopefully approve the. 364 00:13:03,070 --> 00:13:05,169 Transactions in the end, and 365 00:13:05,170 --> 00:13:07,269 then this basically goes from from 366 00:13:07,270 --> 00:13:10,119 the lowest end back to the terminal. 367 00:13:10,120 --> 00:13:12,339 It shows approved and in the end you 368 00:13:12,340 --> 00:13:14,469 get your goods and 369 00:13:14,470 --> 00:13:15,470 can leave. 370 00:13:18,050 --> 00:13:20,719 So that's basically looking at 371 00:13:20,720 --> 00:13:22,849 a whole transaction as a as 372 00:13:22,850 --> 00:13:23,850 a as an entity. 373 00:13:24,980 --> 00:13:26,479 Talk a little bit about what kind of data 374 00:13:26,480 --> 00:13:27,979 is exchanged as that. 375 00:13:27,980 --> 00:13:29,779 I think it's interesting to see what 376 00:13:29,780 --> 00:13:31,069 actually is supposedly saved on their 377 00:13:31,070 --> 00:13:32,539 credit card. 378 00:13:32,540 --> 00:13:34,609 Again, teams talk 379 00:13:34,610 --> 00:13:36,649 about EMV has some more detailed 380 00:13:36,650 --> 00:13:38,119 information on that. 381 00:13:38,120 --> 00:13:40,129 But what you basically get is account 382 00:13:40,130 --> 00:13:42,829 information. You get your 383 00:13:42,830 --> 00:13:44,359 primary account number, your credit card 384 00:13:44,360 --> 00:13:46,549 number, basically, you get your 385 00:13:46,550 --> 00:13:47,899 track to equivalent data. 386 00:13:47,900 --> 00:13:49,549 That's basically a data element which 387 00:13:49,550 --> 00:13:51,289 mimics the data that would normally be on 388 00:13:51,290 --> 00:13:53,629 mag stripe if you still had one. 389 00:13:53,630 --> 00:13:55,669 They are still networks which only wrote 390 00:13:55,670 --> 00:13:56,989 those kind of information and not the 391 00:13:56,990 --> 00:13:58,849 whole transaction data. 392 00:13:58,850 --> 00:14:00,919 And for backward compatibility 393 00:14:00,920 --> 00:14:03,199 and legacy reasons, this is still 394 00:14:03,200 --> 00:14:04,200 present. 395 00:14:04,880 --> 00:14:06,079 So from that, you also, for example, have 396 00:14:06,080 --> 00:14:08,359 the expiry date, then 397 00:14:08,360 --> 00:14:10,459 you have verification information. 398 00:14:10,460 --> 00:14:12,409 So what kind of verification should be 399 00:14:12,410 --> 00:14:13,489 supported? 400 00:14:13,490 --> 00:14:14,939 The card can make some recommendations. 401 00:14:14,940 --> 00:14:16,189 The terminal has some information. 402 00:14:16,190 --> 00:14:17,749 What it actually supports that has a pin 403 00:14:17,750 --> 00:14:19,669 pad does it doesn't have a pin pad. 404 00:14:19,670 --> 00:14:21,289 Should we accept signatures, information 405 00:14:21,290 --> 00:14:22,290 like that? 406 00:14:22,820 --> 00:14:25,159 Then we have the authentication data 407 00:14:25,160 --> 00:14:27,339 where you basically get 408 00:14:27,340 --> 00:14:28,640 the reference to your 409 00:14:29,690 --> 00:14:32,269 see a public key from 410 00:14:32,270 --> 00:14:33,270 from the card schemes. 411 00:14:34,460 --> 00:14:36,079 You get the public key off the card 412 00:14:36,080 --> 00:14:38,689 itself and the resulting 413 00:14:38,690 --> 00:14:40,489 sign data to check offline on the 414 00:14:40,490 --> 00:14:43,219 terminal if the transaction is valid. 415 00:14:43,220 --> 00:14:44,840 And then you have the authorization data, 416 00:14:45,980 --> 00:14:47,299 which is I mean, 417 00:14:48,320 --> 00:14:50,059 aside from the card information, the 418 00:14:50,060 --> 00:14:52,069 amount and currency, which is crucial. 419 00:14:52,070 --> 00:14:54,349 I mean, in the end, you want to get a 420 00:14:54,350 --> 00:14:57,049 specific amount during the transaction 421 00:14:57,050 --> 00:14:59,719 and then you add the date and time 422 00:14:59,720 --> 00:15:01,939 the cryptogram, which allows 423 00:15:01,940 --> 00:15:03,409 the issuer to verify that this 424 00:15:03,410 --> 00:15:04,669 transaction is genuine. 425 00:15:04,670 --> 00:15:06,829 And that's basically 426 00:15:06,830 --> 00:15:08,449 the information that's used during a 427 00:15:08,450 --> 00:15:09,450 transaction. 428 00:15:11,240 --> 00:15:13,849 The format 429 00:15:13,850 --> 00:15:16,729 or the protocol that is used for the 430 00:15:16,730 --> 00:15:18,049 communication between the card and the 431 00:15:18,050 --> 00:15:20,179 terminal is ISO seven eight 432 00:15:20,180 --> 00:15:21,180 one six. 433 00:15:21,740 --> 00:15:22,999 That's basically what's normally talk 434 00:15:23,000 --> 00:15:25,279 between a card reader, 435 00:15:25,280 --> 00:15:27,109 any card reader and a chip card. 436 00:15:27,110 --> 00:15:29,209 And the payload is BRT, LV 437 00:15:29,210 --> 00:15:30,829 and encoded. It's like an S encoding 438 00:15:30,830 --> 00:15:33,199 format which allows 439 00:15:33,200 --> 00:15:35,329 you to add more or less data as 440 00:15:35,330 --> 00:15:37,369 part of your communication. 441 00:15:37,370 --> 00:15:39,229 And we been talk about the communication 442 00:15:39,230 --> 00:15:40,519 then between the terminal and the 443 00:15:40,520 --> 00:15:42,649 acquirer or the entities behind 444 00:15:42,650 --> 00:15:43,789 that. 445 00:15:43,790 --> 00:15:45,949 You have mostly an 446 00:15:45,950 --> 00:15:48,019 ISO variant of ISO eight 447 00:15:48,020 --> 00:15:50,299 five eight three, especially 448 00:15:50,300 --> 00:15:51,889 with the acquirers, but also banking 449 00:15:51,890 --> 00:15:53,329 networks uses. 450 00:15:53,330 --> 00:15:56,539 And that's a bitmap based format 451 00:15:56,540 --> 00:15:58,759 which has a very weird 452 00:15:58,760 --> 00:16:00,879 bitmap combinations and is a it's 453 00:16:00,880 --> 00:16:02,959 a pain to to back if 454 00:16:02,960 --> 00:16:04,639 you if you want to send a valid message 455 00:16:04,640 --> 00:16:05,640 there. 456 00:16:07,550 --> 00:16:11,149 Yeah. So comparing NFC to I.C.C., 457 00:16:11,150 --> 00:16:12,269 why should I use it. 458 00:16:12,270 --> 00:16:13,609 What's the benefit. 459 00:16:13,610 --> 00:16:15,499 Why actually go for it. 460 00:16:15,500 --> 00:16:17,689 So normally you have a lot 461 00:16:17,690 --> 00:16:20,129 faster transaction times. 462 00:16:20,130 --> 00:16:22,189 There are timing limits 463 00:16:22,190 --> 00:16:24,349 on how how fast a card and money 464 00:16:24,350 --> 00:16:25,969 to interact in this first interaction 465 00:16:25,970 --> 00:16:26,970 face. 466 00:16:27,920 --> 00:16:29,809 And you can also remove the card already 467 00:16:29,810 --> 00:16:31,519 after this phase and this is normally 468 00:16:31,520 --> 00:16:32,870 completed within a second. 469 00:16:34,580 --> 00:16:36,649 You also get some benefits when it comes 470 00:16:36,650 --> 00:16:38,899 to verification, verification 471 00:16:38,900 --> 00:16:39,900 methods and limits. 472 00:16:40,970 --> 00:16:44,299 So they introduced or rediscovered 473 00:16:44,300 --> 00:16:46,669 something which is a no KVM. 474 00:16:46,670 --> 00:16:48,019 So this means you don't have to provide a 475 00:16:48,020 --> 00:16:49,939 signature or a pin. 476 00:16:49,940 --> 00:16:52,039 And they introduced a limit under 477 00:16:52,040 --> 00:16:54,289 which you don't have to basically provide 478 00:16:54,290 --> 00:16:55,290 anything. 479 00:16:56,330 --> 00:16:58,039 In the end, this was probably added to 480 00:16:58,040 --> 00:17:00,319 ease or to incentivize you 481 00:17:00,320 --> 00:17:02,239 as a shopper to use contactless 482 00:17:02,240 --> 00:17:03,240 transactions. 483 00:17:04,160 --> 00:17:06,379 But then again, we also have 484 00:17:06,380 --> 00:17:08,479 legacy. And this means that 485 00:17:08,480 --> 00:17:11,328 NFC transactions run in 486 00:17:11,329 --> 00:17:13,459 two operating modes, EMV 487 00:17:13,460 --> 00:17:15,858 mode, which is basically upgrading I.C.C. 488 00:17:15,859 --> 00:17:18,348 transaction to contactless. 489 00:17:18,349 --> 00:17:20,449 And then we have an extra mode 490 00:17:20,450 --> 00:17:22,848 for those networks 491 00:17:22,849 --> 00:17:25,338 back then in the US, but also in other 492 00:17:25,339 --> 00:17:27,919 countries around the world, which 493 00:17:27,920 --> 00:17:29,989 only can allow to extract information 494 00:17:29,990 --> 00:17:32,239 and not EMV or I.C.C. 495 00:17:32,240 --> 00:17:33,259 information. 496 00:17:33,260 --> 00:17:35,479 And they are. This relies heavily on just 497 00:17:35,480 --> 00:17:37,369 using track to equivalent data. 498 00:17:40,690 --> 00:17:42,910 So now we have seen how 499 00:17:44,320 --> 00:17:46,329 complex this transaction is made, what 500 00:17:46,330 --> 00:17:48,279 steps we go through, what is required as 501 00:17:48,280 --> 00:17:50,139 part of of data elements for actually 502 00:17:50,140 --> 00:17:51,759 making a transaction. 503 00:17:51,760 --> 00:17:53,919 Now we want to talk about how 504 00:17:53,920 --> 00:17:56,319 can we actually make a smart 505 00:17:56,320 --> 00:17:58,839 phone, simulate or emulate 506 00:17:58,840 --> 00:17:59,840 such cards, 507 00:18:00,940 --> 00:18:03,189 and not everybody should be able 508 00:18:03,190 --> 00:18:04,719 to just do it and say, well, I want to 509 00:18:04,720 --> 00:18:06,819 have my card on my phone and 510 00:18:06,820 --> 00:18:08,079 that's it. 511 00:18:08,080 --> 00:18:10,179 And they are two distinctive ways on how 512 00:18:10,180 --> 00:18:11,499 you can do this. 513 00:18:11,500 --> 00:18:14,349 And the first one is especially using 514 00:18:14,350 --> 00:18:16,299 something which is called a secure 515 00:18:16,300 --> 00:18:18,639 element, which is an enclave 516 00:18:18,640 --> 00:18:20,829 for cryptographic and sensitive 517 00:18:20,830 --> 00:18:23,079 information, which 518 00:18:23,080 --> 00:18:25,209 basically, once it receives this kind of 519 00:18:25,210 --> 00:18:27,309 information, no longer gives it out 520 00:18:27,310 --> 00:18:30,129 to a micro HSM, if you like. 521 00:18:30,130 --> 00:18:32,199 And your normal chip card is 522 00:18:32,200 --> 00:18:34,179 basically a secure element. 523 00:18:34,180 --> 00:18:36,399 But nowadays we also 524 00:18:36,400 --> 00:18:38,889 have phones which include this. 525 00:18:38,890 --> 00:18:41,209 So also, again, looking at the parties, 526 00:18:41,210 --> 00:18:43,479 if you talk about secure elements and 527 00:18:43,480 --> 00:18:45,609 providing this information required 528 00:18:45,610 --> 00:18:47,769 for making a transaction to a secure 529 00:18:47,770 --> 00:18:49,689 element, what do we need there? 530 00:18:49,690 --> 00:18:50,739 Well, on the one hand, we need the 531 00:18:50,740 --> 00:18:52,869 smartphone or in this case we are 532 00:18:52,870 --> 00:18:54,849 talking predominantly about a smartphone 533 00:18:54,850 --> 00:18:57,489 which has this kind of secure element 534 00:18:57,490 --> 00:18:59,529 and which at some point receives the 535 00:18:59,530 --> 00:19:01,689 information and data required for 536 00:19:01,690 --> 00:19:03,339 emulating a card. 537 00:19:03,340 --> 00:19:05,019 And then we have something which is 538 00:19:05,020 --> 00:19:06,849 called a trusted service manager. 539 00:19:06,850 --> 00:19:08,259 This exists for a long time. 540 00:19:08,260 --> 00:19:10,449 And this is also the entity which 541 00:19:10,450 --> 00:19:12,399 normally provisions your actual chip 542 00:19:12,400 --> 00:19:14,679 card, and it holds the cryptographic 543 00:19:14,680 --> 00:19:17,769 keys to actually modify data within those 544 00:19:17,770 --> 00:19:18,770 enclaves. 545 00:19:19,630 --> 00:19:22,629 And now this this entity 546 00:19:22,630 --> 00:19:24,789 is also then linked to your 547 00:19:24,790 --> 00:19:26,889 smartphone and has 548 00:19:26,890 --> 00:19:29,079 the power to actually load 549 00:19:29,080 --> 00:19:30,080 information in there. 550 00:19:31,570 --> 00:19:33,759 In the past, we have also seen 551 00:19:33,760 --> 00:19:35,979 secure elements as part of the 552 00:19:35,980 --> 00:19:38,169 SIM card, but they are, 553 00:19:38,170 --> 00:19:39,799 for example, the trusted service manager 554 00:19:39,800 --> 00:19:41,859 was the mobile network operator. 555 00:19:41,860 --> 00:19:43,149 So you had another player in there and 556 00:19:43,150 --> 00:19:44,200 this never really took off. 557 00:19:46,180 --> 00:19:48,369 And so we have our next try 558 00:19:48,370 --> 00:19:51,069 with the smartphone and some entity 559 00:19:51,070 --> 00:19:53,289 which is a trusted service manager. 560 00:19:53,290 --> 00:19:55,119 There is not just only one service 561 00:19:55,120 --> 00:19:57,369 manager, but they are a lot 562 00:19:57,370 --> 00:19:59,829 of them. And the one who is provisioning 563 00:19:59,830 --> 00:20:02,139 your smartphone isn't the one 564 00:20:02,140 --> 00:20:04,119 that also provisions your your smart card 565 00:20:05,950 --> 00:20:08,979 in your traditional credit card. 566 00:20:08,980 --> 00:20:10,449 But those are the two roles which play a 567 00:20:10,450 --> 00:20:13,569 major role when it comes to making 568 00:20:13,570 --> 00:20:15,909 a secure element able to 569 00:20:15,910 --> 00:20:17,440 to make a contactless transaction. 570 00:20:19,050 --> 00:20:21,179 So looking at when do we actually 571 00:20:21,180 --> 00:20:24,359 get the data into the the secure element? 572 00:20:24,360 --> 00:20:25,769 Well, I mean, you want to make a 573 00:20:25,770 --> 00:20:27,309 transaction with this element you have. 574 00:20:27,310 --> 00:20:28,649 So you have to do it before actually 575 00:20:28,650 --> 00:20:29,999 making the transaction. 576 00:20:30,000 --> 00:20:32,429 But most likely, you already have a card. 577 00:20:32,430 --> 00:20:34,619 So this happens right before 578 00:20:34,620 --> 00:20:35,849 your first transaction. 579 00:20:35,850 --> 00:20:37,679 After that, you can make as many 580 00:20:37,680 --> 00:20:38,969 transactions as you like. 581 00:20:40,620 --> 00:20:42,959 And looking at exactly how this 582 00:20:42,960 --> 00:20:45,059 how this works out, in the end, 583 00:20:45,060 --> 00:20:47,159 um, you as a user 584 00:20:47,160 --> 00:20:49,289 normally enter your credit card number 585 00:20:49,290 --> 00:20:50,249 on your smartphone. 586 00:20:50,250 --> 00:20:51,759 You scan it, you enter it manually, 587 00:20:51,760 --> 00:20:53,099 something like that. 588 00:20:53,100 --> 00:20:55,169 And then your smartphone or your 589 00:20:55,170 --> 00:20:57,299 app talks to 590 00:20:57,300 --> 00:20:59,629 the trusted service manager, gets 591 00:20:59,630 --> 00:21:01,709 the information, hey, I want to provision 592 00:21:01,710 --> 00:21:03,269 this kind of card. 593 00:21:03,270 --> 00:21:04,889 And this trusted service manager normally 594 00:21:04,890 --> 00:21:07,379 has a connection to your issuing bank or 595 00:21:07,380 --> 00:21:09,119 a group of issuing banks. 596 00:21:09,120 --> 00:21:11,249 And then there are checks saying, well, 597 00:21:11,250 --> 00:21:13,409 I want to add this card 598 00:21:13,410 --> 00:21:15,539 to my secure element or to this specific 599 00:21:15,540 --> 00:21:17,729 phone, can 600 00:21:17,730 --> 00:21:18,809 I do this? 601 00:21:18,810 --> 00:21:21,089 And normally then the first 602 00:21:21,090 --> 00:21:23,279 thing the issue is doing is talking to 603 00:21:23,280 --> 00:21:25,619 you as the owner of your card 604 00:21:25,620 --> 00:21:27,809 on a second channel, as a mass email 605 00:21:27,810 --> 00:21:30,059 or whatever, and ask you, hey, if 606 00:21:30,060 --> 00:21:32,279 somebody is asking to provision a new new 607 00:21:32,280 --> 00:21:34,379 card to your smartphone, is this 608 00:21:34,380 --> 00:21:36,389 actually you? And do you approve this in 609 00:21:36,390 --> 00:21:37,390 the end? 610 00:21:37,980 --> 00:21:40,079 And as long as you don't do anything, 611 00:21:40,080 --> 00:21:41,279 nothing is happening. So you actually 612 00:21:41,280 --> 00:21:44,039 have to confirm this and then 613 00:21:44,040 --> 00:21:45,749 the issuer gets active again and provides 614 00:21:45,750 --> 00:21:47,879 to the to the trusted service manager 615 00:21:47,880 --> 00:21:50,399 the information, the cryptographic keys 616 00:21:50,400 --> 00:21:52,289 that need to be embedded into the secure 617 00:21:52,290 --> 00:21:52,769 element. 618 00:21:52,770 --> 00:21:54,539 And from there, it goes back to the 619 00:21:55,560 --> 00:21:56,729 to the smartphone. 620 00:21:56,730 --> 00:21:59,189 And from there on your 621 00:21:59,190 --> 00:22:01,979 smartphone is actually able to just 622 00:22:01,980 --> 00:22:04,079 mimic an actual smart 623 00:22:04,080 --> 00:22:06,389 card and drive 624 00:22:06,390 --> 00:22:08,489 a transaction at a a contact 625 00:22:08,490 --> 00:22:10,049 at a contactless transaction. 626 00:22:10,050 --> 00:22:11,569 Contact a credit card terminal. 627 00:22:13,970 --> 00:22:15,649 But well, I mean, in the beginning, I 628 00:22:15,650 --> 00:22:18,019 talked about cloning, I 629 00:22:18,020 --> 00:22:19,730 mean, there's not really true we saw this 630 00:22:20,840 --> 00:22:22,939 what we do, we rather provision an 631 00:22:22,940 --> 00:22:25,489 additional card that is added 632 00:22:25,490 --> 00:22:27,319 to the secure element. 633 00:22:27,320 --> 00:22:29,059 And this means that the issuer has the 634 00:22:29,060 --> 00:22:31,579 means to distinguish between, hey, 635 00:22:31,580 --> 00:22:33,409 we are now doing a transaction with like 636 00:22:33,410 --> 00:22:34,999 an actual card and we're doing a 637 00:22:35,000 --> 00:22:37,669 transaction with a phone which 638 00:22:37,670 --> 00:22:40,009 has been loaded with the the 639 00:22:40,010 --> 00:22:42,169 information about how 640 00:22:42,170 --> 00:22:43,170 to make a card. 641 00:22:44,220 --> 00:22:46,909 Also now we have a smartphone in place. 642 00:22:46,910 --> 00:22:48,019 We don't have the cards. 643 00:22:48,020 --> 00:22:49,819 We have something which has logic there 644 00:22:49,820 --> 00:22:52,009 and most of time also has biometric 645 00:22:52,010 --> 00:22:54,469 sensors, other means of of 646 00:22:54,470 --> 00:22:56,389 verifying that there's actually the right 647 00:22:56,390 --> 00:22:58,039 person using the phone. 648 00:22:58,040 --> 00:23:00,259 And what this basically changed 649 00:23:00,260 --> 00:23:02,479 or added was an additional verification 650 00:23:02,480 --> 00:23:04,729 method, which is called cardholder device 651 00:23:04,730 --> 00:23:07,300 TVM or on device verification. 652 00:23:08,510 --> 00:23:10,639 And those of you have who has used 653 00:23:10,640 --> 00:23:12,290 Apple Pay maybe in the past. 654 00:23:13,370 --> 00:23:15,709 This is when you press 655 00:23:15,710 --> 00:23:17,299 your home button with your finger and 656 00:23:17,300 --> 00:23:18,859 authorize the transaction by this. 657 00:23:19,970 --> 00:23:21,739 And this is basically a station of this 658 00:23:21,740 --> 00:23:23,719 device that the right person used 659 00:23:25,100 --> 00:23:27,649 that term, the smartphone, 660 00:23:27,650 --> 00:23:28,669 for making a transaction. 661 00:23:29,750 --> 00:23:31,519 And when we talk about the data that is 662 00:23:31,520 --> 00:23:33,200 loaded onto the secure element. 663 00:23:35,850 --> 00:23:38,099 This is basically the same as if you were 664 00:23:38,100 --> 00:23:40,169 a chip card or a 665 00:23:40,170 --> 00:23:42,449 NFC card that was actually handed out 666 00:23:42,450 --> 00:23:44,669 by your bank, but most 667 00:23:44,670 --> 00:23:47,009 importantly, it also includes asymmetric 668 00:23:47,010 --> 00:23:49,679 and asymmetric keys that are needed for 669 00:23:49,680 --> 00:23:51,089 generating the same data and the 670 00:23:51,090 --> 00:23:51,599 cryptogram. 671 00:23:51,600 --> 00:23:53,700 And this is really what makes the 672 00:23:55,160 --> 00:23:57,269 the transaction 673 00:23:57,270 --> 00:23:59,489 or at the same security level as 674 00:23:59,490 --> 00:24:01,589 if you would use a 675 00:24:01,590 --> 00:24:03,689 traditional ID card to 676 00:24:03,690 --> 00:24:06,029 the to the level where you use your smart 677 00:24:06,030 --> 00:24:07,319 card for a transaction. 678 00:24:07,320 --> 00:24:08,879 And this uses the same verification 679 00:24:08,880 --> 00:24:10,979 method and on the terminal level and 680 00:24:10,980 --> 00:24:13,259 also on the bank level, to see that 681 00:24:13,260 --> 00:24:14,490 transaction is actually genuine. 682 00:24:17,180 --> 00:24:18,649 This is one way to do it, but not 683 00:24:18,650 --> 00:24:20,809 everybody has a smartphone which 684 00:24:20,810 --> 00:24:22,939 has a secure element, which is 685 00:24:22,940 --> 00:24:24,500 also trusted by all the issuers. 686 00:24:25,730 --> 00:24:27,439 And this is why we have another way of 687 00:24:27,440 --> 00:24:28,670 making a smartphone 688 00:24:29,930 --> 00:24:32,029 able to act as a 689 00:24:32,030 --> 00:24:33,989 as a card provider. 690 00:24:33,990 --> 00:24:36,839 And this is called host card emulation, 691 00:24:36,840 --> 00:24:38,939 and what we 692 00:24:38,940 --> 00:24:40,709 have there is basically we have a 693 00:24:40,710 --> 00:24:42,479 smartphone could be any smartphone. 694 00:24:42,480 --> 00:24:45,179 In the end, you need 695 00:24:45,180 --> 00:24:46,889 NFC capabilities in there. 696 00:24:46,890 --> 00:24:48,089 But other than that, you don't really 697 00:24:48,090 --> 00:24:50,879 have many requirements here. 698 00:24:50,880 --> 00:24:52,409 And then you have your traditional 699 00:24:52,410 --> 00:24:54,689 payment network or the issuer which is 700 00:24:56,430 --> 00:24:57,569 behind that. 701 00:24:57,570 --> 00:24:58,570 And 702 00:25:00,840 --> 00:25:02,579 what is happening here is that 703 00:25:03,600 --> 00:25:06,149 your smartphone no longer receives those 704 00:25:06,150 --> 00:25:07,150 generally 705 00:25:08,220 --> 00:25:10,889 valid crypto cryptographic keys, 706 00:25:10,890 --> 00:25:12,989 but it only gets limited use 707 00:25:12,990 --> 00:25:15,539 keys or one time 708 00:25:15,540 --> 00:25:16,619 keys. 709 00:25:16,620 --> 00:25:18,569 Basically a code book that can be used 710 00:25:18,570 --> 00:25:20,429 for a couple of transactions from the 711 00:25:20,430 --> 00:25:22,709 network, but it cannot be used 712 00:25:22,710 --> 00:25:24,480 for repeated transactions. 713 00:25:27,050 --> 00:25:28,429 Same as is a secure element. 714 00:25:28,430 --> 00:25:30,589 You want to make a transaction 715 00:25:30,590 --> 00:25:33,019 with your newly provided information. 716 00:25:33,020 --> 00:25:35,749 So this host card emulation 717 00:25:35,750 --> 00:25:37,849 provisioning also needs to happen 718 00:25:37,850 --> 00:25:40,219 before actually making the transaction. 719 00:25:40,220 --> 00:25:42,859 But in addition to that or compare 720 00:25:42,860 --> 00:25:45,049 in contrast to the secure element, 721 00:25:45,050 --> 00:25:47,119 you only get information that you can use 722 00:25:47,120 --> 00:25:48,649 a couple of times. 723 00:25:48,650 --> 00:25:50,719 So you need to have a constant network 724 00:25:50,720 --> 00:25:52,249 connection in order to make repeated 725 00:25:52,250 --> 00:25:53,250 transactions. 726 00:25:54,370 --> 00:25:56,799 And if you also look at how this 727 00:25:56,800 --> 00:25:59,049 works out, in the end, you again 728 00:25:59,050 --> 00:26:02,529 enter your credit card information on 729 00:26:02,530 --> 00:26:04,510 your smartphone, you scan it, whatever, 730 00:26:05,710 --> 00:26:07,329 this send directly goes to the payment 731 00:26:07,330 --> 00:26:08,229 networks. 732 00:26:08,230 --> 00:26:09,909 So there is no trusted service manager 733 00:26:09,910 --> 00:26:10,910 involved there. 734 00:26:11,620 --> 00:26:13,869 And then depending on the 735 00:26:13,870 --> 00:26:16,089 solution you are using, either 736 00:26:16,090 --> 00:26:18,189 the payment networks themselves generate 737 00:26:18,190 --> 00:26:20,199 those one times that can be used for 738 00:26:20,200 --> 00:26:22,269 making a transaction or this 739 00:26:22,270 --> 00:26:23,739 is also forwarded then again to the 740 00:26:23,740 --> 00:26:25,359 issuer, to the one who actually gave you 741 00:26:25,360 --> 00:26:26,739 your card. 742 00:26:26,740 --> 00:26:28,809 And they are then generating 743 00:26:28,810 --> 00:26:29,810 those 744 00:26:31,150 --> 00:26:33,069 limited keys and and they are then 745 00:26:33,070 --> 00:26:35,019 basically headed up again to your 746 00:26:36,310 --> 00:26:37,310 to your phone. 747 00:26:38,200 --> 00:26:40,539 But the data that you receive 748 00:26:40,540 --> 00:26:42,669 isn't really stored in a in a secure 749 00:26:42,670 --> 00:26:44,649 element stored within your application 750 00:26:44,650 --> 00:26:45,650 data. 751 00:26:47,670 --> 00:26:50,309 So comparing those two methods, 752 00:26:50,310 --> 00:26:53,609 H.S. versus AC provisioning, 753 00:26:53,610 --> 00:26:54,610 um. 754 00:26:55,500 --> 00:26:56,819 One of the benefits of H.C. 755 00:26:56,820 --> 00:26:59,129 is that you don't need a totally secure 756 00:26:59,130 --> 00:27:01,199 environment, but if you 757 00:27:01,200 --> 00:27:02,279 have it, you can still use it. 758 00:27:02,280 --> 00:27:03,869 So you can also put your one time keys 759 00:27:03,870 --> 00:27:04,769 into a secure element. 760 00:27:04,770 --> 00:27:07,019 For example, um, 761 00:27:07,020 --> 00:27:09,209 and normally with HHC, 762 00:27:09,210 --> 00:27:11,369 you only get limited use 763 00:27:11,370 --> 00:27:14,099 crypto keys, which are then stored 764 00:27:14,100 --> 00:27:15,959 within the app and which need to be 765 00:27:15,960 --> 00:27:17,549 renewed every now and then. 766 00:27:17,550 --> 00:27:19,979 And this is also then the catch here. 767 00:27:19,980 --> 00:27:22,109 Well, what what happens if your 768 00:27:22,110 --> 00:27:23,939 smartphone doesn't have any cell 769 00:27:23,940 --> 00:27:25,289 reception and you want to make a couple 770 00:27:25,290 --> 00:27:26,729 of transactions? 771 00:27:26,730 --> 00:27:29,099 Well, after you have used your 772 00:27:29,100 --> 00:27:31,829 a limited number of of keys 773 00:27:31,830 --> 00:27:34,049 to basically create the cryptograms 774 00:27:34,050 --> 00:27:36,449 for a transaction, you're out of keys. 775 00:27:36,450 --> 00:27:38,639 So at least every once in a while 776 00:27:38,640 --> 00:27:40,949 you need to make network connectivity 777 00:27:40,950 --> 00:27:43,169 to refresh the number of keys 778 00:27:43,170 --> 00:27:44,670 that that you have available. 779 00:27:45,780 --> 00:27:48,119 And you can also see that he 780 00:27:48,120 --> 00:27:49,439 is receiving a big push from the 781 00:27:49,440 --> 00:27:52,259 industry. So actually, the 782 00:27:52,260 --> 00:27:54,749 payment schemes, a payment network 783 00:27:54,750 --> 00:27:56,489 and FOX themselves provide SDK 784 00:27:57,720 --> 00:27:59,789 for app developers to add to into 785 00:27:59,790 --> 00:28:01,859 their applications, which 786 00:28:01,860 --> 00:28:03,749 abstract away the network communication, 787 00:28:03,750 --> 00:28:05,699 which gives predefined interfaces that 788 00:28:05,700 --> 00:28:07,319 you can use for from making the 789 00:28:07,320 --> 00:28:08,320 transaction. 790 00:28:10,460 --> 00:28:12,979 And which basically is I mean, 791 00:28:12,980 --> 00:28:14,659 if you look at it from their side, every 792 00:28:14,660 --> 00:28:16,549 transaction that is made through one of 793 00:28:16,550 --> 00:28:17,869 the networks makes some money. 794 00:28:17,870 --> 00:28:20,029 So they want to basically bring more 795 00:28:20,030 --> 00:28:21,469 people onto that. 796 00:28:21,470 --> 00:28:23,939 And here they actually have an influence, 797 00:28:23,940 --> 00:28:25,819 a secure element they cannot modify, but 798 00:28:25,820 --> 00:28:28,279 they can bring other developers 799 00:28:28,280 --> 00:28:30,380 to use it for their transactions. 800 00:28:33,390 --> 00:28:35,849 Well, now we know how we can get 801 00:28:35,850 --> 00:28:38,429 data on a terminal 802 00:28:38,430 --> 00:28:41,189 and act on a on a credit card 803 00:28:41,190 --> 00:28:42,149 on a smartphone. 804 00:28:42,150 --> 00:28:44,339 And well, now we 805 00:28:44,340 --> 00:28:45,989 we have this data and there and it can 806 00:28:45,990 --> 00:28:47,759 simulate now an actual card. 807 00:28:47,760 --> 00:28:49,499 But well, in the end, I don't want to 808 00:28:49,500 --> 00:28:51,929 have my credit card data lying 809 00:28:51,930 --> 00:28:54,089 around in some kind of of 810 00:28:54,090 --> 00:28:56,519 application written by some app developer 811 00:28:56,520 --> 00:28:57,989 or maybe not even by a bank. 812 00:28:57,990 --> 00:28:59,669 I mean, we have seen what this would 813 00:28:59,670 --> 00:29:00,670 result in. 814 00:29:01,170 --> 00:29:02,729 So there is another thing that was 815 00:29:02,730 --> 00:29:04,259 recently introduced, which is account 816 00:29:04,260 --> 00:29:05,189 data tokenization. 817 00:29:05,190 --> 00:29:06,190 And what this does 818 00:29:07,620 --> 00:29:10,259 is basically it replaces your 819 00:29:10,260 --> 00:29:12,539 credit card number with a 820 00:29:12,540 --> 00:29:13,649 token equivalent. 821 00:29:13,650 --> 00:29:15,389 This is basically same format, same 822 00:29:15,390 --> 00:29:17,219 length, again, for legacy reasons, 823 00:29:17,220 --> 00:29:19,169 probably. And this can be used 824 00:29:19,170 --> 00:29:21,029 interchangeably with your actual credit 825 00:29:21,030 --> 00:29:22,859 card number. And this is something that 826 00:29:22,860 --> 00:29:24,319 can then be stored within your app. 827 00:29:26,170 --> 00:29:28,539 Well, new features 828 00:29:28,540 --> 00:29:30,639 in new players, we have 829 00:29:30,640 --> 00:29:32,769 now a token service provider 830 00:29:32,770 --> 00:29:34,959 that's a service which 831 00:29:34,960 --> 00:29:37,239 stores mappings between 832 00:29:37,240 --> 00:29:39,429 tokens and the actual card number 833 00:29:39,430 --> 00:29:41,349 and provides interfaces to adding new 834 00:29:41,350 --> 00:29:43,449 ones and to converting from one to the 835 00:29:43,450 --> 00:29:44,379 other. 836 00:29:44,380 --> 00:29:46,419 And then you have the token requestor, 837 00:29:46,420 --> 00:29:47,619 which requests 838 00:29:49,450 --> 00:29:51,549 new tokens from from the service provider 839 00:29:53,020 --> 00:29:55,239 or ask. 840 00:29:55,240 --> 00:29:57,219 It's to translate from one from it to the 841 00:29:57,220 --> 00:29:58,220 other. 842 00:30:00,480 --> 00:30:02,699 Luckily, this happens in the same face 843 00:30:02,700 --> 00:30:05,639 as if he would do HHC 844 00:30:05,640 --> 00:30:07,919 or as you provisioning, so you also 845 00:30:07,920 --> 00:30:09,779 want to basically convert your credit 846 00:30:09,780 --> 00:30:11,369 card number to a token before you 847 00:30:11,370 --> 00:30:12,370 actually do a transaction. 848 00:30:14,670 --> 00:30:16,799 And what this then looks 849 00:30:16,800 --> 00:30:19,349 like is that you have your 850 00:30:19,350 --> 00:30:21,389 your phone, which knows about your credit 851 00:30:21,390 --> 00:30:23,589 card, that you want to use, this 852 00:30:23,590 --> 00:30:26,009 then goes to the token requester, 853 00:30:26,010 --> 00:30:27,809 which, for example, could be Apple, could 854 00:30:27,810 --> 00:30:28,810 be Google. 855 00:30:29,340 --> 00:30:30,659 And what they do, they add some 856 00:30:30,660 --> 00:30:33,089 information about who you are, 857 00:30:33,090 --> 00:30:35,159 maybe your credit history with iTunes 858 00:30:35,160 --> 00:30:36,929 or something, or the App Store. 859 00:30:36,930 --> 00:30:38,999 And they then talk to 860 00:30:39,000 --> 00:30:41,400 a token service provider 861 00:30:42,750 --> 00:30:44,999 and provide them with the card number 862 00:30:45,000 --> 00:30:47,489 and basic information, how they know you. 863 00:30:47,490 --> 00:30:49,559 And they then talk 864 00:30:49,560 --> 00:30:50,969 to the payment networks. 865 00:30:50,970 --> 00:30:53,159 And from there 866 00:30:53,160 --> 00:30:54,629 it goes into the issuer and the issuer 867 00:30:54,630 --> 00:30:56,489 can say, well, OK, this account, this is 868 00:30:56,490 --> 00:30:58,679 existing is valid and it's 869 00:30:58,680 --> 00:31:00,839 OK to end it as a as a token, basically. 870 00:31:00,840 --> 00:31:02,969 And then this goes back to 871 00:31:02,970 --> 00:31:03,970 the to the 872 00:31:05,970 --> 00:31:06,970 tokens, 873 00:31:08,490 --> 00:31:10,229 to the token provider. 874 00:31:10,230 --> 00:31:12,299 And it basically stores an extra 875 00:31:12,300 --> 00:31:14,219 number of generates a token and gives it 876 00:31:14,220 --> 00:31:16,319 back through the requester 877 00:31:16,320 --> 00:31:18,569 to your phone. And then you have 878 00:31:18,570 --> 00:31:20,639 a phone which 879 00:31:20,640 --> 00:31:22,589 knows about a token. 880 00:31:22,590 --> 00:31:24,659 It can discard the credit card number and 881 00:31:24,660 --> 00:31:27,089 use this now for every transaction 882 00:31:27,090 --> 00:31:28,090 it it's doing. 883 00:31:29,650 --> 00:31:30,849 Well, why would you want to use 884 00:31:30,850 --> 00:31:31,749 tokenization? 885 00:31:31,750 --> 00:31:33,879 Well, I mean, yeah, provide security 886 00:31:33,880 --> 00:31:36,069 benefits, so the 887 00:31:36,070 --> 00:31:38,129 account number is no longer 888 00:31:38,130 --> 00:31:40,429 used outside of payment networks. 889 00:31:40,430 --> 00:31:42,609 Um, the other benefit is 890 00:31:42,610 --> 00:31:44,619 that you can limit the scope on those 891 00:31:44,620 --> 00:31:46,809 kind of tokens so you can say, well, 892 00:31:46,810 --> 00:31:48,369 this token that was requested was 893 00:31:48,370 --> 00:31:49,269 requested by IEEPA. 894 00:31:49,270 --> 00:31:51,369 So this is only valid for point-of-sale 895 00:31:51,370 --> 00:31:53,859 transactions using NFC 896 00:31:53,860 --> 00:31:55,449 or other kind of transactions through 897 00:31:55,450 --> 00:31:57,669 Amazon through an extra part our declined 898 00:31:57,670 --> 00:31:59,679 because it's not intended to be used like 899 00:31:59,680 --> 00:32:00,680 that. 900 00:32:01,210 --> 00:32:02,680 And the other benefit is that 901 00:32:04,180 --> 00:32:06,699 the tokens can be revoked individually. 902 00:32:06,700 --> 00:32:08,319 So, for example, if you have two devices 903 00:32:08,320 --> 00:32:10,659 and you load your same credit card on 904 00:32:10,660 --> 00:32:12,969 both devices, they will receive 905 00:32:12,970 --> 00:32:14,130 a different token on each device. 906 00:32:15,290 --> 00:32:16,759 And that means if one device is 907 00:32:16,760 --> 00:32:18,079 compromised, you can basically cancel 908 00:32:18,080 --> 00:32:19,789 this token, but the other ones are still 909 00:32:19,790 --> 00:32:21,799 working and do extra credit card numbers, 910 00:32:21,800 --> 00:32:23,059 not compromised because it's not safe 911 00:32:23,060 --> 00:32:24,060 there. 912 00:32:24,780 --> 00:32:26,849 Think of it of A and an F 913 00:32:26,850 --> 00:32:28,529 specific password, if you use Two-Factor 914 00:32:28,530 --> 00:32:30,719 the authorization, something that 915 00:32:30,720 --> 00:32:32,729 you give one entity which you can revoke 916 00:32:32,730 --> 00:32:33,989 all the time without affecting the 917 00:32:33,990 --> 00:32:34,990 others. 918 00:32:35,790 --> 00:32:38,159 And the other benefit is that you can use 919 00:32:38,160 --> 00:32:40,409 a token not only for point 920 00:32:40,410 --> 00:32:41,339 of sale payments. 921 00:32:41,340 --> 00:32:43,559 You can also, for example, use this in an 922 00:32:43,560 --> 00:32:45,629 e-commerce context on Amazon, for 923 00:32:45,630 --> 00:32:46,630 example. 924 00:32:49,660 --> 00:32:51,909 All right, so we know about how 925 00:32:51,910 --> 00:32:54,309 can we make a phone act 926 00:32:54,310 --> 00:32:56,409 as a card, we know how we can 927 00:32:56,410 --> 00:32:58,449 make this a little bit more secure. 928 00:32:58,450 --> 00:33:00,429 And this is now where we can look at 929 00:33:00,430 --> 00:33:02,499 Apple pay and Android pay because they 930 00:33:02,500 --> 00:33:04,390 use actually those kind of information. 931 00:33:07,150 --> 00:33:09,789 Many in charge ever pay users 932 00:33:09,790 --> 00:33:11,200 the secure element 933 00:33:12,220 --> 00:33:14,289 on the iPhone that you have 934 00:33:14,290 --> 00:33:16,659 and an addition, appliance 935 00:33:16,660 --> 00:33:18,699 account, data, tokenization, and as a 936 00:33:18,700 --> 00:33:20,920 result, you get Apple Pay and. 937 00:33:23,220 --> 00:33:25,379 If you look at Android pay and this is 938 00:33:25,380 --> 00:33:27,279 rather similar, but they don't have a 939 00:33:27,280 --> 00:33:28,889 secure element. We have a fragmented 940 00:33:28,890 --> 00:33:30,329 market where you cannot make any 941 00:33:30,330 --> 00:33:31,330 assumptions. 942 00:33:32,220 --> 00:33:34,289 And this is why they basically are 943 00:33:34,290 --> 00:33:36,179 betting on host card emulation. 944 00:33:36,180 --> 00:33:38,129 And in addition to that, they are also 945 00:33:38,130 --> 00:33:39,749 applying account data tokenization. 946 00:33:39,750 --> 00:33:42,089 And in the end, this is Android 947 00:33:42,090 --> 00:33:43,090 pay. 948 00:33:45,940 --> 00:33:47,799 If you look at a transaction, what kind 949 00:33:47,800 --> 00:33:49,929 of workflows are happening there, 950 00:33:49,930 --> 00:33:51,759 what kind of data is exchanged? 951 00:33:51,760 --> 00:33:53,499 Let's assume we already basically went 952 00:33:53,500 --> 00:33:55,129 through the initial stage of presenting a 953 00:33:55,130 --> 00:33:56,649 card of your phone. 954 00:33:56,650 --> 00:33:58,779 Actually, you get rid of the card. 955 00:33:58,780 --> 00:34:00,819 So we presented the phone to the 956 00:34:00,820 --> 00:34:02,739 terminal. It read the data, and now we 957 00:34:02,740 --> 00:34:04,269 end this online phase where we actually 958 00:34:04,270 --> 00:34:05,289 want to talk to the issuer. 959 00:34:06,820 --> 00:34:08,408 Instead of having your credit card 960 00:34:08,409 --> 00:34:10,359 number, you now have the token. 961 00:34:10,360 --> 00:34:11,619 In addition to that, you have the 962 00:34:11,620 --> 00:34:13,809 cryptogram that was generated exactly 963 00:34:13,810 --> 00:34:15,399 for this transaction, for example, by the 964 00:34:15,400 --> 00:34:16,569 secure element. 965 00:34:16,570 --> 00:34:18,039 This traditionally goes then to the 966 00:34:18,040 --> 00:34:19,988 acquirer. From there, it enters a payment 967 00:34:19,989 --> 00:34:22,359 network. And now one additional step is 968 00:34:22,360 --> 00:34:24,459 happening. The payment network says, 969 00:34:24,460 --> 00:34:26,198 well, OK, this is a token. 970 00:34:26,199 --> 00:34:27,279 This is not a card number. I don't know 971 00:34:27,280 --> 00:34:28,809 where to give this to me. 972 00:34:28,810 --> 00:34:30,999 So first, I have to ask the 973 00:34:31,000 --> 00:34:32,769 the token manager, hey, can you convert 974 00:34:32,770 --> 00:34:34,539 this back to a card to me? 975 00:34:34,540 --> 00:34:36,129 And so the token guest goes to the 976 00:34:36,130 --> 00:34:37,780 manager and you get returned 977 00:34:39,610 --> 00:34:40,629 the extra card number. 978 00:34:40,630 --> 00:34:42,698 But this happens within the credit 979 00:34:42,699 --> 00:34:44,948 card networks where more or less every 980 00:34:44,949 --> 00:34:46,238 information that's floating around there 981 00:34:46,239 --> 00:34:48,429 is visible in plain text anyways. 982 00:34:49,719 --> 00:34:51,439 And from there on the payment because 983 00:34:51,440 --> 00:34:53,049 they know, OK, well, OK, this is a Visa 984 00:34:53,050 --> 00:34:55,509 transaction and this Visa card belongs 985 00:34:55,510 --> 00:34:57,969 to, for example, 986 00:34:57,970 --> 00:35:00,549 my Sparkasse here in 987 00:35:00,550 --> 00:35:01,550 Absi. 988 00:35:02,030 --> 00:35:04,189 And then this data 989 00:35:04,190 --> 00:35:07,279 basically is is given 990 00:35:07,280 --> 00:35:09,479 to this bank and the bank can then do 991 00:35:09,480 --> 00:35:10,999 the normal checking of checking. 992 00:35:11,000 --> 00:35:12,139 Is this a valid card? 993 00:35:12,140 --> 00:35:14,269 In this case? It's a smartphone. 994 00:35:14,270 --> 00:35:16,519 Is the 995 00:35:16,520 --> 00:35:18,049 the cryptogram valid for the transaction 996 00:35:18,050 --> 00:35:20,029 and then gives it OK back? 997 00:35:20,030 --> 00:35:22,789 And that's basically what makes 998 00:35:22,790 --> 00:35:25,069 a transaction when using 999 00:35:25,070 --> 00:35:27,199 HCI or a 1000 00:35:27,200 --> 00:35:29,569 secure element in particular Apple Pay 1001 00:35:29,570 --> 00:35:30,570 or Android pay. 1002 00:35:31,790 --> 00:35:34,969 In this scenario, 1003 00:35:34,970 --> 00:35:37,549 Google or Apple 1004 00:35:37,550 --> 00:35:38,550 would play the role. 1005 00:35:39,900 --> 00:35:42,109 Um, I wouldn't play no 1006 00:35:42,110 --> 00:35:44,209 role in this because as 1007 00:35:44,210 --> 00:35:45,679 soon as the data elements are 1008 00:35:45,680 --> 00:35:48,019 provisioned, they are more or less 1009 00:35:48,020 --> 00:35:49,909 out of the transaction and they also then 1010 00:35:49,910 --> 00:35:51,729 no longer see the actual data. 1011 00:35:54,430 --> 00:35:56,709 So now we have seen, OK, Apple 1012 00:35:56,710 --> 00:35:59,229 Pay, Android pay, um, 1013 00:35:59,230 --> 00:36:00,909 it's at a different security. 1014 00:36:04,210 --> 00:36:05,409 What's happening after that? 1015 00:36:06,730 --> 00:36:08,199 Well, first of all, especially in 1016 00:36:08,200 --> 00:36:10,209 Germany, I want to actually be able to 1017 00:36:10,210 --> 00:36:11,210 use empathy. 1018 00:36:11,920 --> 00:36:13,989 I envy my friends in the US, 1019 00:36:13,990 --> 00:36:15,519 which uses on a daily basis. 1020 00:36:17,470 --> 00:36:18,519 I'm still sitting here. 1021 00:36:18,520 --> 00:36:19,780 I cannot use Jarobi, 1022 00:36:20,860 --> 00:36:22,519 but, well, this is not helping me. 1023 00:36:22,520 --> 00:36:24,790 Um, but if you look around, 1024 00:36:26,170 --> 00:36:27,370 there are other things happening. 1025 00:36:28,450 --> 00:36:29,799 There's something which is called issue a 1026 00:36:29,800 --> 00:36:31,199 great HHC. 1027 00:36:32,500 --> 00:36:33,879 The issue. I saw that. 1028 00:36:33,880 --> 00:36:36,129 Well, we 1029 00:36:36,130 --> 00:36:38,139 don't really need a token manager in the 1030 00:36:38,140 --> 00:36:40,719 workflow. I mean, I can actually 1031 00:36:40,720 --> 00:36:42,959 now give out tokens to 1032 00:36:42,960 --> 00:36:46,059 to my customers via my my own app. 1033 00:36:46,060 --> 00:36:47,589 I can also give them the keys that are 1034 00:36:47,590 --> 00:36:49,359 necessary for that because I'm in the 1035 00:36:49,360 --> 00:36:51,069 end, the one who is verifying them and 1036 00:36:51,070 --> 00:36:52,449 would be issuing them in the first place. 1037 00:36:53,680 --> 00:36:55,809 And this also enables 1038 00:36:55,810 --> 00:36:58,150 those issuers to to give out 1039 00:36:59,320 --> 00:37:00,759 cards. 1040 00:37:00,760 --> 00:37:02,889 But Cardless, just provisioning 1041 00:37:02,890 --> 00:37:05,229 a card to your actual 1042 00:37:05,230 --> 00:37:07,269 phone without sending you a physical 1043 00:37:07,270 --> 00:37:08,270 card. 1044 00:37:08,830 --> 00:37:10,869 We have also seen alternative payment 1045 00:37:10,870 --> 00:37:11,870 methods. 1046 00:37:12,350 --> 00:37:14,139 I mean, traditionally, banks are slow to 1047 00:37:14,140 --> 00:37:16,509 adapt to new technologies. 1048 00:37:16,510 --> 00:37:17,889 And then there were other players which 1049 00:37:17,890 --> 00:37:20,289 basically came in, for example, 1050 00:37:20,290 --> 00:37:21,290 especially in the 1051 00:37:22,360 --> 00:37:24,459 Asia region, we have new 1052 00:37:24,460 --> 00:37:26,109 ways of making a transaction which 1053 00:37:26,110 --> 00:37:27,789 removes the card and the terminal all 1054 00:37:27,790 --> 00:37:29,829 together. And then we end up with Alpay 1055 00:37:29,830 --> 00:37:31,929 or WeChat, which just uses a 1056 00:37:31,930 --> 00:37:34,449 QR code on the phone and an application 1057 00:37:34,450 --> 00:37:35,450 on the phone of the merchant 1058 00:37:36,610 --> 00:37:38,050 to to make a transaction. 1059 00:37:39,640 --> 00:37:41,919 And another thing well, I mean, 1060 00:37:41,920 --> 00:37:43,479 legacy for the win. 1061 00:37:45,580 --> 00:37:47,709 Those are big networks, networks, 1062 00:37:47,710 --> 00:37:50,049 this enables you to actually use 1063 00:37:50,050 --> 00:37:52,269 your card in Germany, in Spain, in 1064 00:37:52,270 --> 00:37:54,869 Mexico, in the US, in Iceland. 1065 00:37:54,870 --> 00:37:56,800 Um, this will not change overnight. 1066 00:37:58,300 --> 00:38:00,639 They are too many parties 1067 00:38:00,640 --> 00:38:02,769 involved and everyone has their 1068 00:38:02,770 --> 00:38:04,959 own agenda. They are. So probably 1069 00:38:04,960 --> 00:38:07,059 in the next years we see alternative 1070 00:38:07,060 --> 00:38:09,129 methods, but will always see 1071 00:38:09,130 --> 00:38:11,559 credit card terminals, credit cards 1072 00:38:11,560 --> 00:38:13,809 and smartphones acting as credit 1073 00:38:13,810 --> 00:38:15,969 cards and to finish 1074 00:38:15,970 --> 00:38:17,289 with a personal touch. 1075 00:38:17,290 --> 00:38:19,329 I work in this area. 1076 00:38:19,330 --> 00:38:20,830 Yes, I know. It's a 1077 00:38:22,780 --> 00:38:25,449 it's a very slow progressing 1078 00:38:25,450 --> 00:38:26,799 area. 1079 00:38:26,800 --> 00:38:29,109 It's use a lot of legacy code. 1080 00:38:29,110 --> 00:38:31,239 But in the end, this is a best playing 1081 00:38:31,240 --> 00:38:32,709 field for you to actually improve 1082 00:38:32,710 --> 00:38:34,600 something to find new 1083 00:38:35,620 --> 00:38:38,169 new areas where you want to improve. 1084 00:38:38,170 --> 00:38:41,079 And this is actually 1085 00:38:41,080 --> 00:38:42,109 why I got into this. 1086 00:38:42,110 --> 00:38:44,199 And with that, I want to 1087 00:38:44,200 --> 00:38:46,329 thank everybody and thank 1088 00:38:46,330 --> 00:38:47,330 you. 1089 00:38:58,970 --> 00:39:01,349 All right, we got 1090 00:39:01,350 --> 00:39:03,629 enough time for questions, please 1091 00:39:03,630 --> 00:39:05,129 line up at the microphones if you are 1092 00:39:05,130 --> 00:39:07,619 interested in anything 1093 00:39:07,620 --> 00:39:09,239 you want to ask something to. 1094 00:39:09,240 --> 00:39:11,399 Simon, do 1095 00:39:11,400 --> 00:39:12,889 we have an Internet question? 1096 00:39:20,390 --> 00:39:22,649 Apparently not so 1097 00:39:22,650 --> 00:39:25,399 oh, microphone number three, please. 1098 00:39:25,400 --> 00:39:26,839 Yeah, thanks for all those insights. 1099 00:39:26,840 --> 00:39:28,009 That was great. 1100 00:39:28,010 --> 00:39:30,169 You mentioned that the token requests 1101 00:39:30,170 --> 00:39:32,419 are at some date like credit 1102 00:39:32,420 --> 00:39:34,429 history, something when they want a 1103 00:39:34,430 --> 00:39:36,619 token. Could you briefly explain why 1104 00:39:36,620 --> 00:39:38,389 this is necessary, what this information 1105 00:39:38,390 --> 00:39:39,390 is used for? 1106 00:39:40,370 --> 00:39:43,339 Well, in the end, this information. 1107 00:39:43,340 --> 00:39:45,679 Well, for example, if you talk about 1108 00:39:45,680 --> 00:39:47,060 let's use this as a combination. 1109 00:39:48,710 --> 00:39:51,589 Apple has like a history of 1110 00:39:51,590 --> 00:39:53,719 if you're actually a recent 1111 00:39:53,720 --> 00:39:55,219 user of this card, if you have used it 1112 00:39:55,220 --> 00:39:57,799 for a long time, how credible you are. 1113 00:39:57,800 --> 00:39:59,959 And this is just used for making sure 1114 00:39:59,960 --> 00:40:02,329 that a second 1115 00:40:02,330 --> 00:40:05,299 card is issued to the right person. 1116 00:40:05,300 --> 00:40:08,119 In the end, this is the most likely 1117 00:40:08,120 --> 00:40:09,739 attack scenario for Apple Pay, for 1118 00:40:09,740 --> 00:40:12,169 example, that somebody is using your card 1119 00:40:12,170 --> 00:40:14,389 and add a second one to his phone and not 1120 00:40:14,390 --> 00:40:16,039 to your phone. 1121 00:40:16,040 --> 00:40:18,169 And those kind of information 1122 00:40:18,170 --> 00:40:20,299 is just making sure that the right 1123 00:40:20,300 --> 00:40:22,609 person actually you are requesting a 1124 00:40:22,610 --> 00:40:24,929 second card on their phone 1125 00:40:24,930 --> 00:40:26,959 is kind of a fingerprint. 1126 00:40:26,960 --> 00:40:29,029 It's not I wouldn't say 1127 00:40:29,030 --> 00:40:30,860 a fingerprint because it's not 1128 00:40:32,340 --> 00:40:33,589 reused at a later point. 1129 00:40:33,590 --> 00:40:36,049 It's just a point, a 1130 00:40:36,050 --> 00:40:38,659 collection of a few of the current moment 1131 00:40:38,660 --> 00:40:40,039 of what you have been done and how 1132 00:40:40,040 --> 00:40:41,479 authentic this request seems to be. 1133 00:40:44,670 --> 00:40:47,039 Or for those who are leaving, please, 1134 00:40:47,040 --> 00:40:49,439 a little bit lower 1135 00:40:49,440 --> 00:40:52,199 down your voice and the noise 1136 00:40:52,200 --> 00:40:53,459 we still have going on here. 1137 00:40:53,460 --> 00:40:55,080 So microphone number one, please. 1138 00:40:56,270 --> 00:40:58,619 Do I see any difference 1139 00:40:58,620 --> 00:41:00,839 as a customer if I use 1140 00:41:00,840 --> 00:41:03,779 a secure element or just 1141 00:41:03,780 --> 00:41:04,679 emulation? 1142 00:41:04,680 --> 00:41:06,929 So the maximum amount or 1143 00:41:06,930 --> 00:41:09,089 what happens in case of fraud 1144 00:41:09,090 --> 00:41:11,249 or what happens if the Android 1145 00:41:11,250 --> 00:41:13,139 phone is routed? 1146 00:41:13,140 --> 00:41:15,539 So this depends on basically the provider 1147 00:41:15,540 --> 00:41:18,449 of the sea solution. 1148 00:41:18,450 --> 00:41:20,729 In general, they are on the same 1149 00:41:20,730 --> 00:41:23,279 level, but 1150 00:41:23,280 --> 00:41:25,499 the one who gives out this one time could 1151 00:41:25,500 --> 00:41:27,659 limit them to a certain amount 1152 00:41:27,660 --> 00:41:29,639 they normally are to limit how many one 1153 00:41:29,640 --> 00:41:31,319 time keys you normally get at a certain 1154 00:41:31,320 --> 00:41:33,539 point. So five or 10 is normal. 1155 00:41:34,770 --> 00:41:36,539 And you're right, if your phone is routed 1156 00:41:36,540 --> 00:41:38,489 and somebody else gets access to those, 1157 00:41:38,490 --> 00:41:40,589 they can be used for actually 1158 00:41:40,590 --> 00:41:42,929 imposing a playing imposter 1159 00:41:42,930 --> 00:41:44,130 and making a transaction. 1160 00:41:45,430 --> 00:41:47,789 But this is limited to the ones 1161 00:41:47,790 --> 00:41:48,989 that you receive. This is actually why 1162 00:41:48,990 --> 00:41:51,089 you limit the number at the number of 1163 00:41:51,090 --> 00:41:53,879 tokens that you get for HCV 1164 00:41:53,880 --> 00:41:55,439 because they are not protected, as if you 1165 00:41:55,440 --> 00:41:56,809 would be using a secure element 1166 00:41:57,990 --> 00:42:00,299 then the bank blaming me or 1167 00:42:00,300 --> 00:42:01,289 is it? 1168 00:42:01,290 --> 00:42:03,779 So this is an interesting part. 1169 00:42:03,780 --> 00:42:05,119 I don't know about any case. 1170 00:42:05,120 --> 00:42:06,659 So I don't know. 1171 00:42:08,250 --> 00:42:10,230 This probably is a case by case analysis. 1172 00:42:12,090 --> 00:42:14,099 OK, let's move on to microphone number 1173 00:42:14,100 --> 00:42:15,389 six. There's somebody over there. 1174 00:42:17,690 --> 00:42:20,119 In case multiple cuts of 1175 00:42:20,120 --> 00:42:22,729 ricin violence range 1176 00:42:22,730 --> 00:42:24,859 is collision detection and 1177 00:42:24,860 --> 00:42:26,959 cuts no apply to or 1178 00:42:26,960 --> 00:42:28,280 just in general ever, and 1179 00:42:29,480 --> 00:42:30,979 nothing happens. 1180 00:42:30,980 --> 00:42:32,090 So, yeah, this is detected. 1181 00:42:33,650 --> 00:42:35,899 The guys who basically 1182 00:42:35,900 --> 00:42:38,119 invented the contact aspects 1183 00:42:38,120 --> 00:42:39,439 said, well, OK, if you detect a 1184 00:42:39,440 --> 00:42:41,269 collision, we say, well, just present one 1185 00:42:41,270 --> 00:42:42,169 card. 1186 00:42:42,170 --> 00:42:44,779 So you get an error message indicating 1187 00:42:44,780 --> 00:42:46,159 to you as the one who was providing the 1188 00:42:46,160 --> 00:42:47,929 cards, hey, please just provide one card 1189 00:42:47,930 --> 00:42:48,949 and that's it. 1190 00:42:48,950 --> 00:42:50,239 Probably to make it easier to 1191 00:42:50,240 --> 00:42:51,649 differentiate which contract should be 1192 00:42:51,650 --> 00:42:53,959 used and not adding a new selection 1193 00:42:53,960 --> 00:42:55,679 interface to prolong the transaction. 1194 00:42:55,680 --> 00:42:57,949 Yet I can present my entire 1195 00:42:57,950 --> 00:42:59,269 wallet. And you can. 1196 00:42:59,270 --> 00:43:00,850 You can, but this will not work. 1197 00:43:03,060 --> 00:43:06,149 All right. Microphone number two, please. 1198 00:43:06,150 --> 00:43:07,529 Hi. 1199 00:43:07,530 --> 00:43:10,129 So if you go back to the 1200 00:43:10,130 --> 00:43:12,210 obscure element provisioning step. 1201 00:43:13,710 --> 00:43:15,599 Yeah. Would it be nice to see that on the 1202 00:43:15,600 --> 00:43:16,499 screen? 1203 00:43:16,500 --> 00:43:17,500 Let's have a quick look. 1204 00:43:22,730 --> 00:43:24,949 Yeah, so the bottom two 1205 00:43:24,950 --> 00:43:27,409 lines is that that's basically a blob 1206 00:43:27,410 --> 00:43:29,539 holding the secret keys, 1207 00:43:29,540 --> 00:43:30,649 right? 1208 00:43:30,650 --> 00:43:31,650 So what 1209 00:43:32,780 --> 00:43:35,210 the issuer gives back to the 1210 00:43:36,260 --> 00:43:38,389 to the trusted service manager and 1211 00:43:38,390 --> 00:43:40,309 then to the government is basically a 1212 00:43:40,310 --> 00:43:42,589 well, a standardized, if you want, 1213 00:43:42,590 --> 00:43:44,749 which show it's like the private crypto 1214 00:43:44,750 --> 00:43:46,549 keys for the asymmetric and symmetric 1215 00:43:46,550 --> 00:43:48,229 encryption. Yeah, but those are 1216 00:43:48,230 --> 00:43:49,729 encrypted, right? 1217 00:43:49,730 --> 00:43:50,969 Well, kind of, yes. 1218 00:43:50,970 --> 00:43:53,419 So they are encrypted by 1219 00:43:53,420 --> 00:43:55,699 between the issuer and the 1220 00:43:55,700 --> 00:43:58,189 service provider and then from there 1221 00:43:58,190 --> 00:43:59,179 to the to the phone. 1222 00:43:59,180 --> 00:44:01,249 So it's not 1223 00:44:01,250 --> 00:44:02,659 like you just apply to Leser or 1224 00:44:02,660 --> 00:44:04,639 something, but it's actually they have 1225 00:44:04,640 --> 00:44:06,829 shared keys which encrypt this on both 1226 00:44:06,830 --> 00:44:09,139 sides so and so only the service 1227 00:44:09,140 --> 00:44:10,579 provider can do this. 1228 00:44:10,580 --> 00:44:12,679 Yes. And only the service provider 1229 00:44:12,680 --> 00:44:15,619 has the knowledge about how 1230 00:44:15,620 --> 00:44:17,209 the secure element can be forgiven and 1231 00:44:17,210 --> 00:44:18,559 the keys for actually changing data in 1232 00:44:18,560 --> 00:44:19,639 there. Yeah, so. 1233 00:44:19,640 --> 00:44:21,259 And who is that? 1234 00:44:21,260 --> 00:44:23,419 So in case of Apple Pay, this 1235 00:44:23,420 --> 00:44:25,579 is Apple and in any 1236 00:44:25,580 --> 00:44:27,769 other case, well, I don't 1237 00:44:27,770 --> 00:44:29,119 know about any other solution which uses 1238 00:44:29,120 --> 00:44:30,559 a secure element to make 1239 00:44:31,640 --> 00:44:33,829 a contactless transaction work 1240 00:44:33,830 --> 00:44:35,929 and. Well, in the case we don't have this 1241 00:44:35,930 --> 00:44:37,969 entity, but it could be, for example, if 1242 00:44:37,970 --> 00:44:40,459 you talk about a traditional credit card, 1243 00:44:40,460 --> 00:44:42,289 then this could be, for example, about 1244 00:44:42,290 --> 00:44:44,359 who Oberoi Gemalto, though, the creators 1245 00:44:44,360 --> 00:44:46,249 of the or the the manufacturers of the 1246 00:44:46,250 --> 00:44:48,019 actual cards that you get sent by the 1247 00:44:48,020 --> 00:44:50,149 bank and the keys of those 1248 00:44:50,150 --> 00:44:52,759 secure elements are diversified. 1249 00:44:52,760 --> 00:44:54,499 Yes. So there's not one provider who has 1250 00:44:54,500 --> 00:44:55,909 every keys, but basically they are a 1251 00:44:55,910 --> 00:44:58,159 couple of entities which then have 1252 00:44:58,160 --> 00:45:00,259 their own access to their cards, 1253 00:45:00,260 --> 00:45:02,389 basically. So what I mean is, 1254 00:45:02,390 --> 00:45:04,189 can they go on to the next question? 1255 00:45:04,190 --> 00:45:06,149 I mean, this is a dialog some I'm sorry, 1256 00:45:06,150 --> 00:45:07,759 that's a little bit too much with an 1257 00:45:07,760 --> 00:45:09,829 Internet question. Please just open up 1258 00:45:09,830 --> 00:45:11,869 to the Internet. 1259 00:45:11,870 --> 00:45:13,819 Wants to know, are tokens static on a 1260 00:45:13,820 --> 00:45:15,499 device or are they ever updated? 1261 00:45:15,500 --> 00:45:16,879 And would that be an advantage to 1262 00:45:16,880 --> 00:45:17,880 changing them? 1263 00:45:19,100 --> 00:45:21,289 So the the the one time he said, 1264 00:45:21,290 --> 00:45:23,479 are we 1265 00:45:23,480 --> 00:45:24,919 we're talking about the tokens. 1266 00:45:24,920 --> 00:45:26,569 So the token, once it's basic 1267 00:45:26,570 --> 00:45:29,179 provisioned, they are normally static 1268 00:45:29,180 --> 00:45:30,739 until you basically say, well, I want to 1269 00:45:30,740 --> 00:45:32,419 add another card. Even if the same card, 1270 00:45:32,420 --> 00:45:34,339 you would probably get a different token. 1271 00:45:34,340 --> 00:45:36,229 But in general, it's basically static. 1272 00:45:38,420 --> 00:45:40,519 Yes, there would be a benefit in changes 1273 00:45:40,520 --> 00:45:43,039 regularly, just removing 1274 00:45:43,040 --> 00:45:44,230 fingerprinting options there, 1275 00:45:45,470 --> 00:45:48,379 but I think 1276 00:45:48,380 --> 00:45:50,449 the major benefit of actually having this 1277 00:45:50,450 --> 00:45:53,239 kind of option is 1278 00:45:53,240 --> 00:45:55,159 that you can hide your actual credit card 1279 00:45:55,160 --> 00:45:56,449 number. And this, I think, was the 1280 00:45:56,450 --> 00:45:57,499 primarily focus on the. 1281 00:45:59,510 --> 00:46:02,529 OK, microphone number four, please. 1282 00:46:02,530 --> 00:46:04,759 You were talking about payment 1283 00:46:04,760 --> 00:46:06,709 networks like MasterCard and Visa. 1284 00:46:06,710 --> 00:46:08,719 It's the same technology used for 1285 00:46:08,720 --> 00:46:11,179 contactless payment cards known as 1286 00:46:11,180 --> 00:46:12,180 zero. 1287 00:46:12,620 --> 00:46:14,119 This is completely different. 1288 00:46:14,120 --> 00:46:15,109 It's similar. 1289 00:46:15,110 --> 00:46:17,179 I mean, the card has its own card, 1290 00:46:17,180 --> 00:46:18,890 which should be running on the terminal. 1291 00:46:20,000 --> 00:46:22,399 And you don't have this 1292 00:46:22,400 --> 00:46:24,169 those global payment network, if you 1293 00:46:24,170 --> 00:46:26,479 will. But you have like a local German 1294 00:46:26,480 --> 00:46:28,519 network, which is connected to a 1295 00:46:28,520 --> 00:46:30,289 different service providers. 1296 00:46:30,290 --> 00:46:32,499 But the handling overall is more or less 1297 00:46:32,500 --> 00:46:33,500 similar. 1298 00:46:35,350 --> 00:46:38,419 And microphone number five, please. 1299 00:46:38,420 --> 00:46:40,569 I, I heard or 1300 00:46:40,570 --> 00:46:42,789 I often hear that risk management is one 1301 00:46:42,790 --> 00:46:44,289 of the most important things for 1302 00:46:44,290 --> 00:46:46,509 creditcard institutes or pretty important 1303 00:46:46,510 --> 00:46:47,229 thing. 1304 00:46:47,230 --> 00:46:49,359 Do you have any experience in this or 1305 00:46:49,360 --> 00:46:51,279 do you know if there really is so much 1306 00:46:51,280 --> 00:46:53,469 money stolen from the Kennicutt 1307 00:46:53,470 --> 00:46:55,479 institutes or during the transaction? 1308 00:46:57,160 --> 00:46:58,599 Well, I think you have to differentiate. 1309 00:46:58,600 --> 00:47:00,729 I mean, there are credit 1310 00:47:00,730 --> 00:47:02,949 card issuers 1311 00:47:02,950 --> 00:47:04,539 or companies who have been doing this in 1312 00:47:04,540 --> 00:47:05,979 a long time, and especially in Europe, 1313 00:47:05,980 --> 00:47:08,619 they are very keen on checking the data 1314 00:47:08,620 --> 00:47:10,629 as part of the risk management. 1315 00:47:10,630 --> 00:47:12,879 When EMV was introduced in the U.S., 1316 00:47:12,880 --> 00:47:14,559 there were instances where the bank 1317 00:47:14,560 --> 00:47:16,569 introduced EMV, but they didn't check any 1318 00:47:16,570 --> 00:47:17,949 data. So you could just send in 1319 00:47:17,950 --> 00:47:19,300 transaction, they would be approved. 1320 00:47:21,490 --> 00:47:24,519 So, yes, this happens from time to time. 1321 00:47:24,520 --> 00:47:26,199 But if the correct checking is 1322 00:47:26,200 --> 00:47:28,359 implemented, then this 1323 00:47:28,360 --> 00:47:29,360 is very hard. 1324 00:47:31,980 --> 00:47:34,139 OK, let's get back to microphone 1325 00:47:34,140 --> 00:47:35,140 number three. 1326 00:47:35,880 --> 00:47:36,779 Hello. 1327 00:47:36,780 --> 00:47:39,299 I think you forgot to mention another 1328 00:47:39,300 --> 00:47:41,549 alternative you can pay with the phone 1329 00:47:41,550 --> 00:47:43,589 or nearly pay with the phone, because 1330 00:47:43,590 --> 00:47:45,539 some banks are also issuing near the 1331 00:47:45,540 --> 00:47:47,829 card, the near field communication 1332 00:47:47,830 --> 00:47:49,979 sticker that you can just put on the 1333 00:47:49,980 --> 00:47:50,939 back of the phone. 1334 00:47:50,940 --> 00:47:53,189 And it works even when you don't 1335 00:47:53,190 --> 00:47:54,659 have the signal. Isn't that the easiest 1336 00:47:54,660 --> 00:47:56,669 way? Well, this works. 1337 00:47:56,670 --> 00:47:58,199 And yes, you're right. This is also one 1338 00:47:58,200 --> 00:48:00,119 of the options that you can use. 1339 00:48:00,120 --> 00:48:01,679 In that case, you doesn't even 1340 00:48:01,680 --> 00:48:02,909 necessarily need a phone. 1341 00:48:02,910 --> 00:48:04,080 You can stick this to anything. 1342 00:48:05,250 --> 00:48:07,499 And true, this is like a key FOB 1343 00:48:07,500 --> 00:48:09,239 or something that you carry around with 1344 00:48:09,240 --> 00:48:10,240 you. 1345 00:48:10,500 --> 00:48:11,729 This also works. 1346 00:48:11,730 --> 00:48:13,469 This has been tried in Germany, for 1347 00:48:13,470 --> 00:48:16,199 example, the network operators, 1348 00:48:16,200 --> 00:48:18,329 T-Mobile and so on have tried this, 1349 00:48:18,330 --> 00:48:20,459 but it didn't reach critical mass and 1350 00:48:20,460 --> 00:48:22,559 never took off and then they borrowed it. 1351 00:48:22,560 --> 00:48:24,479 I guess this is now the next try of 1352 00:48:24,480 --> 00:48:26,339 getting it to the masses. 1353 00:48:26,340 --> 00:48:28,559 My country in Slovenia, that's released 1354 00:48:28,560 --> 00:48:30,629 by the bank and you can buy with 1355 00:48:30,630 --> 00:48:31,049 it. 1356 00:48:31,050 --> 00:48:32,549 Well, this is just an alternative than to 1357 00:48:32,550 --> 00:48:33,719 the actual credit card. 1358 00:48:33,720 --> 00:48:34,720 Just. 1359 00:48:35,990 --> 00:48:38,269 OK, number one microphone, 1360 00:48:38,270 --> 00:48:41,059 please. OK, so when I got my 1361 00:48:41,060 --> 00:48:43,039 one of the last currence a couple of 1362 00:48:43,040 --> 00:48:45,199 years ago, before the first time that 1363 00:48:45,200 --> 00:48:47,929 I could pay contactless, I had to pay 1364 00:48:47,930 --> 00:48:49,519 with a contact. I had to instruct the 1365 00:48:49,520 --> 00:48:51,649 card. Is there a technical reason for 1366 00:48:51,650 --> 00:48:52,650 that? 1367 00:48:53,000 --> 00:48:54,319 I don't know. 1368 00:48:54,320 --> 00:48:55,909 I think this is just checking that 1369 00:48:55,910 --> 00:48:58,219 everything is OK and that the account 1370 00:48:58,220 --> 00:48:59,220 is still available. 1371 00:49:01,430 --> 00:49:03,079 Otherwise you could, for example, use 1372 00:49:03,080 --> 00:49:05,359 this card for below 1373 00:49:05,360 --> 00:49:07,579 contactless limits without needing 1374 00:49:07,580 --> 00:49:09,229 any pin or anything else. 1375 00:49:09,230 --> 00:49:11,299 I think this is just a first rate check, 1376 00:49:11,300 --> 00:49:12,800 but there is no technical reason for it. 1377 00:49:14,540 --> 00:49:16,750 And microphone number six, please, 1378 00:49:18,050 --> 00:49:20,129 when using host card emulation, how do 1379 00:49:20,130 --> 00:49:22,279 the limited use keys 1380 00:49:22,280 --> 00:49:23,239 get updated? 1381 00:49:23,240 --> 00:49:25,339 Does that require Cataldo interaction? 1382 00:49:25,340 --> 00:49:26,959 Does that happen automatically? 1383 00:49:26,960 --> 00:49:29,299 So this normally happens behind 1384 00:49:29,300 --> 00:49:30,949 the scenes. So you as a user of the 1385 00:49:30,950 --> 00:49:32,150 smartphone don't see this. 1386 00:49:33,350 --> 00:49:35,359 This happens basically asynchronously in 1387 00:49:35,360 --> 00:49:36,709 the background. 1388 00:49:36,710 --> 00:49:38,449 And whenever the phone sees well or the 1389 00:49:38,450 --> 00:49:39,799 application says, well, I'm running out 1390 00:49:39,800 --> 00:49:41,599 of keys, it refreshes. 1391 00:49:44,520 --> 00:49:46,289 Let's go to microphone to please. 1392 00:49:48,550 --> 00:49:49,739 Oh, hi. 1393 00:49:51,030 --> 00:49:53,279 Could you elaborate a bit on 1394 00:49:53,280 --> 00:49:55,409 why the banks are 1395 00:49:55,410 --> 00:49:57,809 pushing more for 1396 00:49:57,810 --> 00:49:59,939 house cars angulation than 1397 00:49:59,940 --> 00:50:02,459 see, I understand why Google 1398 00:50:02,460 --> 00:50:04,679 uses host card emulation, 1399 00:50:04,680 --> 00:50:07,079 but the banks are pretty powerful entity 1400 00:50:07,080 --> 00:50:09,299 and could basically put their weight 1401 00:50:09,300 --> 00:50:11,639 behind forcing manufacturers 1402 00:50:11,640 --> 00:50:13,349 to use Azeez. Why don't they? 1403 00:50:14,740 --> 00:50:17,399 So from what I understand, yes, 1404 00:50:17,400 --> 00:50:18,839 they couldn't put more focus on that. 1405 00:50:18,840 --> 00:50:19,889 But in the end, you also need 1406 00:50:19,890 --> 00:50:21,659 manufacturers who want to support it. 1407 00:50:21,660 --> 00:50:23,639 And if you're looking, for example, at 1408 00:50:23,640 --> 00:50:25,229 Android, it's pretty fragmented. 1409 00:50:25,230 --> 00:50:27,119 There might be one manufacturer who adds 1410 00:50:27,120 --> 00:50:29,069 a secret element to their phone. 1411 00:50:29,070 --> 00:50:31,019 But, well, first of all, you need to 1412 00:50:31,020 --> 00:50:32,399 basically be able to cater that for 1413 00:50:32,400 --> 00:50:34,409 markets and sell it in markets. 1414 00:50:34,410 --> 00:50:37,289 So in Germany, it doesn't help me if 1415 00:50:37,290 --> 00:50:38,619 a Chinese maker is adding this to a 1416 00:50:38,620 --> 00:50:40,949 smartphone. And I'm also not 1417 00:50:40,950 --> 00:50:43,079 so sure how how how much I 1418 00:50:43,080 --> 00:50:44,399 would trust this implementation. 1419 00:50:44,400 --> 00:50:46,949 So a secure element is basically 1420 00:50:46,950 --> 00:50:49,319 has the same capabilities of a card. 1421 00:50:49,320 --> 00:50:51,539 So you need a trusted entity 1422 00:50:51,540 --> 00:50:53,819 in there. And this is, I think, why the 1423 00:50:53,820 --> 00:50:55,979 why the issuers basically focus 1424 00:50:55,980 --> 00:50:58,079 more on host card emulation, because 1425 00:50:58,080 --> 00:50:59,579 they can actually influenza's they don't 1426 00:50:59,580 --> 00:51:01,739 have any external requirements of 1427 00:51:01,740 --> 00:51:03,839 some some manufacturer adding some stuff 1428 00:51:03,840 --> 00:51:05,039 there. 1429 00:51:05,040 --> 00:51:06,569 For example, with Android, they just need 1430 00:51:06,570 --> 00:51:08,429 a recent handset with I think Android for 1431 00:51:08,430 --> 00:51:10,529 plus and then they more or less good 1432 00:51:10,530 --> 00:51:11,530 to go. 1433 00:51:13,790 --> 00:51:15,829 All right, any questions from the 1434 00:51:15,830 --> 00:51:16,830 Internet? 1435 00:51:19,470 --> 00:51:21,779 No. OK, let's go onto microphone 1436 00:51:21,780 --> 00:51:23,789 number four, please. 1437 00:51:23,790 --> 00:51:25,889 Thank you for the great talk. 1438 00:51:25,890 --> 00:51:28,079 I wonder if there are any liability 1439 00:51:28,080 --> 00:51:30,749 changes when this 1440 00:51:30,750 --> 00:51:33,119 new workflows with 1441 00:51:33,120 --> 00:51:35,699 mobile payments arrive 1442 00:51:35,700 --> 00:51:38,159 like secure element and guard demolition. 1443 00:51:38,160 --> 00:51:40,259 Who is liable for the 1444 00:51:40,260 --> 00:51:42,449 fraud in this case is because 1445 00:51:42,450 --> 00:51:44,159 there are no new players. 1446 00:51:44,160 --> 00:51:46,169 For example, the trusted service 1447 00:51:46,170 --> 00:51:47,969 providers, which basically owns the 1448 00:51:47,970 --> 00:51:50,429 secure the Krypto Keys for 1449 00:51:50,430 --> 00:51:51,539 the immolated cart. 1450 00:51:52,750 --> 00:51:55,229 But overall, this doesn't change anything 1451 00:51:55,230 --> 00:51:56,639 the same as if you would use your credit 1452 00:51:56,640 --> 00:51:57,809 card. 1453 00:51:57,810 --> 00:52:00,029 Yes, there's somebody who says you can 1454 00:52:00,030 --> 00:52:02,639 put data in your secure element, but 1455 00:52:02,640 --> 00:52:04,799 those types of entities have been 1456 00:52:04,800 --> 00:52:06,299 existing in the past. 1457 00:52:06,300 --> 00:52:07,709 The ones who basically provisioned your 1458 00:52:07,710 --> 00:52:09,779 own actual physical card 1459 00:52:09,780 --> 00:52:11,159 and they undergo the same 1460 00:52:12,270 --> 00:52:14,099 certifications or I don't know what you 1461 00:52:14,100 --> 00:52:15,389 want to call this like the same 1462 00:52:15,390 --> 00:52:17,819 requirements in order to become one 1463 00:52:17,820 --> 00:52:20,429 when it comes to securing your data. 1464 00:52:20,430 --> 00:52:22,619 So in the end, the same liability 1465 00:52:22,620 --> 00:52:23,819 is there. 1466 00:52:23,820 --> 00:52:27,209 And as long as you use EMV, 1467 00:52:27,210 --> 00:52:29,279 you are protected by it, except 1468 00:52:29,280 --> 00:52:31,649 for if you use a pin or something, 1469 00:52:31,650 --> 00:52:32,849 whatever, with the banks come up with 1470 00:52:32,850 --> 00:52:33,359 Indiantown. 1471 00:52:33,360 --> 00:52:35,519 But in general, if you use EMV, 1472 00:52:35,520 --> 00:52:37,829 the liability is with the with 1473 00:52:37,830 --> 00:52:38,830 the bank. 1474 00:52:39,390 --> 00:52:41,609 Second question, is there such a thing 1475 00:52:41,610 --> 00:52:44,099 as an offline contactless payments? 1476 00:52:44,100 --> 00:52:46,419 And if there is, how widespread 1477 00:52:46,420 --> 00:52:47,459 are they? 1478 00:52:47,460 --> 00:52:49,140 Technically, yes, you can use it, 1479 00:52:50,370 --> 00:52:52,379 but this then really shifts the liability 1480 00:52:54,330 --> 00:52:55,950 because then you are 1481 00:52:57,720 --> 00:52:59,459 ignoring the result of the transaction 1482 00:52:59,460 --> 00:53:01,409 and just trying to accept it. 1483 00:53:02,550 --> 00:53:03,749 But you have to differentiate between 1484 00:53:03,750 --> 00:53:05,789 saying, well, I want to use I want to 1485 00:53:05,790 --> 00:53:07,979 work in a in a strictly offline 1486 00:53:07,980 --> 00:53:08,969 environment. 1487 00:53:08,970 --> 00:53:11,309 And I have an often 1488 00:53:11,310 --> 00:53:13,529 approved transaction, which could also 1489 00:53:13,530 --> 00:53:16,619 happen. But nowadays, 1490 00:53:16,620 --> 00:53:19,049 I think in almost all countries 1491 00:53:19,050 --> 00:53:21,210 that I've been working with, 1492 00:53:22,320 --> 00:53:24,329 there is this this flaw limit which 1493 00:53:24,330 --> 00:53:26,069 indicates the terminal, when should I go 1494 00:53:26,070 --> 00:53:27,209 online for a transaction? 1495 00:53:27,210 --> 00:53:28,319 And this is at zero. 1496 00:53:28,320 --> 00:53:29,969 So normally every transaction is 1497 00:53:29,970 --> 00:53:30,970 authorized online. 1498 00:53:32,570 --> 00:53:34,909 OK, and microphone number five, 1499 00:53:34,910 --> 00:53:36,109 please. I think there is somebody over 1500 00:53:36,110 --> 00:53:38,479 there I 1501 00:53:38,480 --> 00:53:40,619 had us spin verification work 1502 00:53:40,620 --> 00:53:42,679 and how is it different compared to 1503 00:53:42,680 --> 00:53:44,089 chip transection? 1504 00:53:44,090 --> 00:53:45,949 So when looking at a chip transaction, 1505 00:53:45,950 --> 00:53:47,959 you normally have three ways of verifying 1506 00:53:47,960 --> 00:53:50,389 a pin, so you can basically 1507 00:53:50,390 --> 00:53:51,349 check this offline. 1508 00:53:51,350 --> 00:53:52,849 So just between the terminals and the 1509 00:53:52,850 --> 00:53:54,349 card and then you have two ways of 1510 00:53:54,350 --> 00:53:56,959 encrypting it or doing it plaintext. 1511 00:53:56,960 --> 00:53:58,699 So this is how the terminal communicates 1512 00:53:58,700 --> 00:54:00,619 with the card and actually wants the pin 1513 00:54:00,620 --> 00:54:01,789 to be verified. 1514 00:54:01,790 --> 00:54:03,319 And then there's a second third option, 1515 00:54:03,320 --> 00:54:05,419 which is online pin, where the 1516 00:54:05,420 --> 00:54:06,889 pin that you enter is actually encrypted 1517 00:54:06,890 --> 00:54:08,569 on the terminal. And then together with 1518 00:54:08,570 --> 00:54:10,519 the authorization sent to the bank and 1519 00:54:10,520 --> 00:54:12,049 the bank checks that the pin is actually 1520 00:54:12,050 --> 00:54:14,319 valid. And when we're talking about off 1521 00:54:14,320 --> 00:54:16,429 of contactless transactions, then only 1522 00:54:16,430 --> 00:54:18,109 a third option is actually available. 1523 00:54:18,110 --> 00:54:19,939 So if you use a pin for connect this 1524 00:54:19,940 --> 00:54:22,129 transaction, there's always goes to the 1525 00:54:22,130 --> 00:54:24,739 to the issuer for it for checking 1526 00:54:24,740 --> 00:54:26,839 because there is no card anymore for 1527 00:54:26,840 --> 00:54:27,979 verifying the pin off-line. 1528 00:54:30,620 --> 00:54:32,380 And microphone number three, please. 1529 00:54:33,750 --> 00:54:35,879 My question would be about Apapa in 1530 00:54:35,880 --> 00:54:38,159 Germany, banks in Germany 1531 00:54:38,160 --> 00:54:40,169 seem to be reluctant to accept it and 1532 00:54:40,170 --> 00:54:42,329 implement it, unreasoned 1533 00:54:42,330 --> 00:54:44,519 seems to be that they have to give 1534 00:54:44,520 --> 00:54:46,919 up a little share of the 1535 00:54:46,920 --> 00:54:49,229 transaction, the transaction 1536 00:54:49,230 --> 00:54:51,629 fee that they receive. 1537 00:54:51,630 --> 00:54:52,630 My question would be, 1538 00:54:54,300 --> 00:54:56,489 how does how does Apple know 1539 00:54:56,490 --> 00:54:58,469 about the transaction and which data is 1540 00:54:58,470 --> 00:55:01,079 sent to Apple when I pay with 1541 00:55:01,080 --> 00:55:03,269 the phone so I don't want 1542 00:55:03,270 --> 00:55:05,189 them to be involved too much. 1543 00:55:05,190 --> 00:55:07,019 Yes. And in the end, they actually 1544 00:55:07,020 --> 00:55:08,020 aren't. 1545 00:55:08,820 --> 00:55:10,499 Well, in order to basically be able to 1546 00:55:10,500 --> 00:55:13,319 use Apple Pay on your phone, your issuer 1547 00:55:13,320 --> 00:55:15,449 needs to participate in this 1548 00:55:15,450 --> 00:55:18,209 charade of provisioning and card. 1549 00:55:18,210 --> 00:55:20,339 And this also then means that they enter 1550 00:55:20,340 --> 00:55:22,319 an agreement that percentage of every 1551 00:55:22,320 --> 00:55:24,389 transaction is basically paid out to 1552 00:55:24,390 --> 00:55:25,390 Apple. 1553 00:55:25,740 --> 00:55:27,539 And this happens basically independently 1554 00:55:27,540 --> 00:55:28,829 of making the transaction. 1555 00:55:28,830 --> 00:55:31,049 So the the the issuers are 1556 00:55:31,050 --> 00:55:33,179 aggregating basically the transactions 1557 00:55:33,180 --> 00:55:35,259 and then basically providing 1558 00:55:35,260 --> 00:55:37,109 Apple with information of how much they 1559 00:55:37,110 --> 00:55:39,639 get. There is no direct feedback as 1560 00:55:39,640 --> 00:55:41,789 as part of every transaction to 1561 00:55:41,790 --> 00:55:43,289 Apple. That way. I made a transaction 1562 00:55:43,290 --> 00:55:45,209 about this, and this means that you get 1563 00:55:45,210 --> 00:55:47,219 that. So this is like a trusting 1564 00:55:47,220 --> 00:55:48,959 contractual agreement between the issuer 1565 00:55:48,960 --> 00:55:49,960 and the and Apple. 1566 00:55:51,690 --> 00:55:53,879 In microphone number one, please. 1567 00:55:53,880 --> 00:55:56,249 I also worry about transaction privacy 1568 00:55:56,250 --> 00:55:58,469 and is this any different of Android pay? 1569 00:55:58,470 --> 00:56:00,699 Do they get any transaction data? 1570 00:56:01,800 --> 00:56:03,949 So this is kind of similar. 1571 00:56:03,950 --> 00:56:04,950 Also their. 1572 00:56:07,420 --> 00:56:09,609 In general, Google doesn't 1573 00:56:09,610 --> 00:56:11,499 get any transaction data. 1574 00:56:11,500 --> 00:56:13,209 They have access to the same elements 1575 00:56:13,210 --> 00:56:15,159 that you have as part of a transaction. 1576 00:56:16,420 --> 00:56:19,029 But after you apply the tokenization, 1577 00:56:19,030 --> 00:56:21,609 you also just have your replaced 1578 00:56:21,610 --> 00:56:22,610 account number. 1579 00:56:23,620 --> 00:56:25,599 In theory, they could do more. 1580 00:56:25,600 --> 00:56:27,159 To be honest, I don't know, hundred 1581 00:56:27,160 --> 00:56:28,689 percent what they actually store and what 1582 00:56:28,690 --> 00:56:30,669 is basically transferred as part of a 1583 00:56:30,670 --> 00:56:31,389 transaction. 1584 00:56:31,390 --> 00:56:33,009 But I would assume that this is similar 1585 00:56:33,010 --> 00:56:34,659 to what Apple does because this is a 1586 00:56:34,660 --> 00:56:36,249 highly sensitive topic. 1587 00:56:36,250 --> 00:56:38,319 And if there's any wrongdoing there, then 1588 00:56:38,320 --> 00:56:40,019 this would create a real shitstorm there. 1589 00:56:41,530 --> 00:56:43,569 OK, we're getting time, there's one more 1590 00:56:43,570 --> 00:56:45,579 question left is it looks like please 1591 00:56:45,580 --> 00:56:46,630 microphone for 1592 00:56:47,830 --> 00:56:50,199 hello, thanks for the great talk, but 1593 00:56:50,200 --> 00:56:52,719 I think you missed something, 1594 00:56:52,720 --> 00:56:54,280 OK, and 1595 00:56:55,390 --> 00:56:57,549 maybe I missed it, but you 1596 00:56:57,550 --> 00:57:00,819 never mentioned number 26 1597 00:57:00,820 --> 00:57:03,129 with this QR code paying. 1598 00:57:04,570 --> 00:57:06,759 Well, I would say that's similar to 1599 00:57:06,760 --> 00:57:08,579 the alternative payment methods, which 1600 00:57:08,580 --> 00:57:09,580 basically come up 1601 00:57:10,690 --> 00:57:13,029 and this is a way where you no 1602 00:57:13,030 --> 00:57:14,769 longer need a card, actually, you just 1603 00:57:14,770 --> 00:57:16,239 need your smartphone to display a QR 1604 00:57:16,240 --> 00:57:18,559 code. And this is an scanned at the 1605 00:57:18,560 --> 00:57:19,749 at the cashier system. 1606 00:57:19,750 --> 00:57:21,969 And this basically includes 1607 00:57:21,970 --> 00:57:24,719 information of making the transaction. 1608 00:57:24,720 --> 00:57:26,889 Yes, you're right. This is a valid way 1609 00:57:26,890 --> 00:57:28,540 of doing this, for example, in Germany. 1610 00:57:29,830 --> 00:57:32,079 But I wanted 1611 00:57:32,080 --> 00:57:34,269 to focus on actually making 1612 00:57:34,270 --> 00:57:36,579 like cloning or making 1613 00:57:36,580 --> 00:57:38,199 card payments with your smartphone 1614 00:57:39,250 --> 00:57:41,349 as a replacement for for normal 1615 00:57:41,350 --> 00:57:42,609 credit card. So this is why I didn't 1616 00:57:42,610 --> 00:57:43,610 focus on that. 1617 00:57:44,760 --> 00:57:45,760 OK, thank you. 1618 00:57:46,690 --> 00:57:49,869 OK, thank you very much, Seimone, 1619 00:57:49,870 --> 00:57:51,900 apologies again for the small delay. 1620 00:57:55,370 --> 00:57:56,370 Thanks a lot. The.