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/318 Thanks! 1 00:00:11,720 --> 00:00:13,339 So thank you very much, everybody. 2 00:00:13,340 --> 00:00:15,469 I'm Andrea Barazani from Italy, 3 00:00:15,470 --> 00:00:17,299 which is why I have a girly name for 4 00:00:17,300 --> 00:00:19,459 every country other than Italy. 5 00:00:19,460 --> 00:00:21,079 So but this is me. 6 00:00:23,810 --> 00:00:25,549 This is my first Congress, by the way. 7 00:00:25,550 --> 00:00:27,919 Even if I live so closely here, I'm feel 8 00:00:27,920 --> 00:00:29,359 very privileged to be here. 9 00:00:29,360 --> 00:00:31,429 And so far, I've been very overwhelmed 10 00:00:31,430 --> 00:00:33,559 by the quality and the people 11 00:00:33,560 --> 00:00:35,089 at this event. So I'm really happy to be 12 00:00:35,090 --> 00:00:38,029 here. And thank you for coming to my 13 00:00:38,030 --> 00:00:39,289 lecture. 14 00:00:39,290 --> 00:00:41,419 So I did this talk with Bionicle, 15 00:00:41,420 --> 00:00:42,589 my colleague at the university. 16 00:00:42,590 --> 00:00:44,729 So just to give you a brief introduction, 17 00:00:44,730 --> 00:00:46,279 what we do, we did. 18 00:00:46,280 --> 00:00:47,449 We're consulting company. 19 00:00:47,450 --> 00:00:49,469 We did a lot of exotic talks in the past 20 00:00:49,470 --> 00:00:51,469 years. We're one of the first ones to do 21 00:00:51,470 --> 00:00:53,329 talks about car hacking. 22 00:00:53,330 --> 00:00:55,399 We sniff keystrokes from the power line 23 00:00:55,400 --> 00:00:57,679 and we laser's in 2011, we did 24 00:00:57,680 --> 00:00:58,639 a chip and pin talk. 25 00:00:58,640 --> 00:01:00,169 And this is an updated version of that 26 00:01:00,170 --> 00:01:01,459 with new findings. 27 00:01:01,460 --> 00:01:03,589 Last year we were one of the first ones 28 00:01:03,590 --> 00:01:05,689 to do packaging packets in Ethernet 29 00:01:05,690 --> 00:01:07,789 and so on. And tomorrow, just 30 00:01:07,790 --> 00:01:09,969 a little odd. I will have another talk at 31 00:01:09,970 --> 00:01:12,049 five thirty here about the USB 32 00:01:12,050 --> 00:01:13,939 armorer, which is our latest hardware 33 00:01:13,940 --> 00:01:14,940 project. So 34 00:01:16,400 --> 00:01:19,729 so EMV, I'm going to talk about 35 00:01:19,730 --> 00:01:21,529 the credit cards with a chip that you 36 00:01:21,530 --> 00:01:23,059 have, which is called Chip and PIN and 37 00:01:23,060 --> 00:01:25,399 UK. EMV is the name of the standard 38 00:01:25,400 --> 00:01:27,949 and we address this topic 39 00:01:27,950 --> 00:01:29,899 a few times in the past. 40 00:01:29,900 --> 00:01:31,789 And the reason why I'm doing this talk is 41 00:01:31,790 --> 00:01:34,849 because working in the security industry, 42 00:01:34,850 --> 00:01:37,789 I really dislike where 43 00:01:37,790 --> 00:01:40,009 a technology which is supposed 44 00:01:40,010 --> 00:01:42,589 to be secure but is really not 45 00:01:42,590 --> 00:01:45,289 it used against the users 46 00:01:45,290 --> 00:01:47,679 of that technology because it's bad 47 00:01:47,680 --> 00:01:48,829 everywhere around. Right? 48 00:01:48,830 --> 00:01:51,529 I mean, if you use a secure technology, 49 00:01:51,530 --> 00:01:53,839 whatever that might mean, it should 50 00:01:53,840 --> 00:01:54,949 protect you. 51 00:01:54,950 --> 00:01:56,809 It should be something that works for 52 00:01:56,810 --> 00:01:59,839 you, not against you. 53 00:01:59,840 --> 00:02:01,339 And the problem that we found in the 54 00:02:01,340 --> 00:02:03,559 past, we DMV, along with 55 00:02:03,560 --> 00:02:05,689 the fine folks at Cambridge as well, 56 00:02:05,690 --> 00:02:07,459 they also publish research about this. 57 00:02:07,460 --> 00:02:09,888 Is that the way in these 58 00:02:09,889 --> 00:02:11,869 being marketed and used on a legal 59 00:02:11,870 --> 00:02:13,999 standpoint is in some 60 00:02:14,000 --> 00:02:16,609 cases, not all cases against the users. 61 00:02:16,610 --> 00:02:18,709 And we're strongly against 62 00:02:18,710 --> 00:02:20,209 that, which is why we're making these 63 00:02:20,210 --> 00:02:21,409 talks. 64 00:02:21,410 --> 00:02:23,479 So Ian Lee is a name of a standard that 65 00:02:23,480 --> 00:02:25,279 regulates every time you see a credit 66 00:02:25,280 --> 00:02:27,469 card with a chip, that's 67 00:02:27,470 --> 00:02:28,759 EMV. That's what we're going to talk 68 00:02:28,760 --> 00:02:30,919 about. So you have a smart card, 69 00:02:30,920 --> 00:02:34,039 which, of course, this is undeniable. 70 00:02:34,040 --> 00:02:35,899 It improved the security over the 71 00:02:35,900 --> 00:02:38,179 existing Mac Strib, which you still 72 00:02:38,180 --> 00:02:39,889 have, by the way. I mean, every credit 73 00:02:39,890 --> 00:02:41,989 card nowadays as the chip, the 74 00:02:41,990 --> 00:02:43,969 Mac stripe and the embossing as well. 75 00:02:43,970 --> 00:02:46,099 So you still can fall back 76 00:02:46,100 --> 00:02:48,979 to very old technology there. 77 00:02:48,980 --> 00:02:50,929 So EMV was invented to replace that 78 00:02:50,930 --> 00:02:51,979 magnetic stripe. 79 00:02:51,980 --> 00:02:53,629 It was invented also to promote the 80 00:02:53,630 --> 00:02:55,819 offline car verification and transaction 81 00:02:55,820 --> 00:02:58,339 approval. So to give you the ability 82 00:02:58,340 --> 00:03:00,529 of validate a transaction without taking 83 00:03:00,530 --> 00:03:02,779 the costs and the time of going online 84 00:03:02,780 --> 00:03:04,879 to the actual backend and you 85 00:03:04,880 --> 00:03:06,499 can have multiple applications on one 86 00:03:06,500 --> 00:03:07,969 card. You can have credit and debit if 87 00:03:07,970 --> 00:03:09,499 you want. So these were the main reasons 88 00:03:09,500 --> 00:03:11,359 for moving to EMV, which are very good 89 00:03:11,360 --> 00:03:14,249 reasons in a way. 90 00:03:14,250 --> 00:03:16,379 One of the other reason is that we DMV 91 00:03:16,380 --> 00:03:18,439 you promote a liability shift so the 92 00:03:18,440 --> 00:03:21,259 liability shifts away from the merchant 93 00:03:21,260 --> 00:03:23,179 to the bank in theory. 94 00:03:23,180 --> 00:03:25,399 But the cardholder, which is you, 95 00:03:25,400 --> 00:03:27,949 which are, you know, the user of the car, 96 00:03:27,950 --> 00:03:30,299 is assumed to be liable in most cases, 97 00:03:30,300 --> 00:03:32,629 unless you can unquestionably prove 98 00:03:32,630 --> 00:03:34,549 that you were not at fault into 99 00:03:34,550 --> 00:03:36,739 protecting the pin or 100 00:03:36,740 --> 00:03:38,689 whatever credentials have been used for 101 00:03:38,690 --> 00:03:40,339 the fraudulent transaction. 102 00:03:40,340 --> 00:03:42,709 So this is the core issue here 103 00:03:42,710 --> 00:03:45,019 with EMV. The PIN verification 104 00:03:45,020 --> 00:03:47,569 becomes proof of your presence. 105 00:03:47,570 --> 00:03:50,599 Now, if the technology cannot ultimately 106 00:03:50,600 --> 00:03:52,759 protect the pin, then of 107 00:03:52,760 --> 00:03:54,979 course this liability shift should 108 00:03:54,980 --> 00:03:56,419 not happen at all. 109 00:03:56,420 --> 00:03:58,189 And this is what we're going to address 110 00:03:58,190 --> 00:03:59,449 in this talk. 111 00:03:59,450 --> 00:04:01,519 This is a very nice example. 112 00:04:01,520 --> 00:04:03,080 Canadian per Bank of Commerce, 113 00:04:04,100 --> 00:04:05,809 a guy was brought in for eighty one 114 00:04:05,810 --> 00:04:07,489 thousand two hundred seventy six dollars. 115 00:04:07,490 --> 00:04:09,379 Our records show that this was a chip and 116 00:04:09,380 --> 00:04:11,269 pin transaction. This means the customer, 117 00:04:11,270 --> 00:04:13,339 personal car and personal pin number. 118 00:04:13,340 --> 00:04:14,719 We're using carrying out this 119 00:04:14,720 --> 00:04:17,059 transaction. As a result, the customer is 120 00:04:17,060 --> 00:04:18,739 liable for the transaction. 121 00:04:18,740 --> 00:04:20,328 So this is the problem. 122 00:04:20,329 --> 00:04:23,179 By the way, the the 123 00:04:23,180 --> 00:04:25,969 thief bought a race car. 124 00:04:25,970 --> 00:04:28,279 That's the sum eighty one thousand, which 125 00:04:28,280 --> 00:04:29,869 is what I would do if I would have to 126 00:04:29,870 --> 00:04:31,009 fraud one of your credit cards. 127 00:04:31,010 --> 00:04:32,299 That's what I would do. I would buy a 128 00:04:32,300 --> 00:04:34,339 race car. I think it's a very good thing 129 00:04:34,340 --> 00:04:36,589 to do. But sadly, 130 00:04:36,590 --> 00:04:38,089 with Chip and PIN, you might be liable. 131 00:04:38,090 --> 00:04:39,049 And I don't want to do that. 132 00:04:39,050 --> 00:04:40,879 I mean, if I can get my race car and you 133 00:04:40,880 --> 00:04:42,169 can get your money back, I think it's a 134 00:04:42,170 --> 00:04:44,149 win win scenario. So if anybody wants to 135 00:04:44,150 --> 00:04:45,200 do that, we can talk about it. 136 00:04:46,490 --> 00:04:47,899 So inves broken. 137 00:04:47,900 --> 00:04:50,779 So there's been this is 138 00:04:50,780 --> 00:04:52,939 the best presentations that have 139 00:04:52,940 --> 00:04:53,989 been done about EMV. 140 00:04:53,990 --> 00:04:56,149 One is mine, but I'm not biased by 141 00:04:56,150 --> 00:04:58,249 any means. So the 142 00:04:58,250 --> 00:05:00,109 guys from Cambridge did an excellent job 143 00:05:00,110 --> 00:05:02,539 with the chip and PIN is broken research. 144 00:05:02,540 --> 00:05:04,009 We did one called Chip and PIN is 145 00:05:04,010 --> 00:05:05,899 definitely broken with our friends, the 146 00:05:05,900 --> 00:05:08,209 Percher Labs, Adam, Lorenzen, Francon. 147 00:05:08,210 --> 00:05:10,149 And then it was the next one about. 148 00:05:10,150 --> 00:05:12,219 So I'm going to address all of 149 00:05:12,220 --> 00:05:13,419 these issues that are being presented 150 00:05:13,420 --> 00:05:15,549 here and then one more, which is 151 00:05:15,550 --> 00:05:18,369 a combination interaction between 152 00:05:18,370 --> 00:05:19,629 two of these stocks here, which is 153 00:05:19,630 --> 00:05:20,889 something you that has never been 154 00:05:20,890 --> 00:05:22,779 presented before. 155 00:05:22,780 --> 00:05:25,239 So you're all familiar with ATM skimmers, 156 00:05:25,240 --> 00:05:27,369 I guess. If not, you should like when 157 00:05:27,370 --> 00:05:29,289 you go to an ATM, keep in mind that there 158 00:05:29,290 --> 00:05:31,479 can always be a fake pin pad and 159 00:05:31,480 --> 00:05:33,549 a fake credit card reader. 160 00:05:33,550 --> 00:05:36,009 So EMV and the chip was designed 161 00:05:36,010 --> 00:05:38,169 to prevent these to find ways 162 00:05:38,170 --> 00:05:40,239 where Dimmock stripe can go 163 00:05:40,240 --> 00:05:42,519 away so that we not be so easy 164 00:05:42,520 --> 00:05:45,069 to intercept everything that is read 165 00:05:45,070 --> 00:05:47,619 while you put the card inside. 166 00:05:47,620 --> 00:05:49,719 But our point was that 167 00:05:49,720 --> 00:05:51,159 we can do EMV skimmers. 168 00:05:51,160 --> 00:05:53,319 So this is a very tiny, very 169 00:05:53,320 --> 00:05:55,479 thin EMV skimmer 170 00:05:55,480 --> 00:05:57,999 that we did for research with our friends 171 00:05:58,000 --> 00:06:00,099 at a percher labs that can be covertly 172 00:06:00,100 --> 00:06:02,589 inserted into a point of sale device. 173 00:06:02,590 --> 00:06:05,559 So this device as a reader, 174 00:06:05,560 --> 00:06:08,049 a smart card reader and its 175 00:06:08,050 --> 00:06:10,749 two faces, so it says a shim 176 00:06:10,750 --> 00:06:12,879 as a man in the meta device, and 177 00:06:12,880 --> 00:06:15,039 it can be placed inside a point 178 00:06:15,040 --> 00:06:16,089 of sale device. 179 00:06:16,090 --> 00:06:18,399 So when you insert your card, the card 180 00:06:18,400 --> 00:06:20,739 has been intercepted by this device 181 00:06:20,740 --> 00:06:23,169 and once it's plugged inside, 182 00:06:23,170 --> 00:06:24,819 you cannot even take it out easily. 183 00:06:24,820 --> 00:06:27,489 It's so clever that you will not 184 00:06:27,490 --> 00:06:29,169 see it. Nobody can see it. 185 00:06:29,170 --> 00:06:31,269 And this is a key factor because the 186 00:06:31,270 --> 00:06:33,339 fact that nobody can see this device 187 00:06:33,340 --> 00:06:35,379 or detect these presence means that 188 00:06:35,380 --> 00:06:37,479 you're not negligent in 189 00:06:37,480 --> 00:06:39,519 not knowing that is there, because this 190 00:06:39,520 --> 00:06:41,619 is nothing that you can do to prevent 191 00:06:41,620 --> 00:06:43,839 or to detect this kind of device inside. 192 00:06:43,840 --> 00:06:46,239 And this is a key point from a legal 193 00:06:46,240 --> 00:06:47,229 standpoint. 194 00:06:47,230 --> 00:06:49,649 So we built this device is a proof of 195 00:06:49,650 --> 00:06:51,819 concept because we wanted to say that 196 00:06:51,820 --> 00:06:54,219 EMV skimmers are the likely 197 00:06:54,220 --> 00:06:56,979 next step after mag stripe skimmers, 198 00:06:56,980 --> 00:06:58,419 we move away from the max. 199 00:06:58,420 --> 00:06:59,349 What do we have? 200 00:06:59,350 --> 00:07:00,339 We have the chip. 201 00:07:00,340 --> 00:07:02,439 So criminal activity will focus on 202 00:07:02,440 --> 00:07:04,709 the chip because it is possible to do so. 203 00:07:06,100 --> 00:07:07,659 So we predicted the skimming. 204 00:07:07,660 --> 00:07:09,069 The chip would become extremely 205 00:07:09,070 --> 00:07:11,529 appealing. And because the interface 206 00:07:11,530 --> 00:07:13,599 is accessible, you have to 207 00:07:13,600 --> 00:07:15,399 be able to put your card into the 208 00:07:15,400 --> 00:07:16,959 point-of-sale slot. 209 00:07:16,960 --> 00:07:19,269 So this means that other things 210 00:07:19,270 --> 00:07:20,559 could go inside there. 211 00:07:20,560 --> 00:07:22,299 It becomes impossible, as I said, for the 212 00:07:22,300 --> 00:07:24,369 user to verify that and he could 213 00:07:24,370 --> 00:07:26,559 go undetected for a very long time. 214 00:07:26,560 --> 00:07:28,929 So these were our predictions. 215 00:07:28,930 --> 00:07:30,669 And after we made the first presentation 216 00:07:30,670 --> 00:07:32,769 about this, of course, it came out that 217 00:07:32,770 --> 00:07:35,109 actually there were real 218 00:07:35,110 --> 00:07:37,569 chip skimmers installation in the wild 219 00:07:37,570 --> 00:07:40,359 that have been reported after our talk. 220 00:07:40,360 --> 00:07:42,549 But they were dated before our 221 00:07:42,550 --> 00:07:44,649 talk, which is great because we take the 222 00:07:44,650 --> 00:07:46,749 credit in exposing the issue, but not the 223 00:07:46,750 --> 00:07:48,939 blame for triggering it because that 224 00:07:48,940 --> 00:07:50,019 were dated before. 225 00:07:50,020 --> 00:07:51,760 So that was that was perfect for us. 226 00:07:54,070 --> 00:07:55,070 Thank you. 227 00:07:57,230 --> 00:07:58,849 And this is so this is much more 228 00:07:58,850 --> 00:08:00,449 professional looking at ours. 229 00:08:00,450 --> 00:08:02,779 OK, so this was made this is a real 230 00:08:02,780 --> 00:08:04,249 unit made by criminals. 231 00:08:04,250 --> 00:08:06,349 It has a serial number on it, which you 232 00:08:06,350 --> 00:08:07,569 were you very much. 233 00:08:08,600 --> 00:08:10,699 I don't put serial numbers on the PCBs 234 00:08:10,700 --> 00:08:11,939 I make, OK? 235 00:08:13,100 --> 00:08:15,199 And also, who can tell me what 236 00:08:15,200 --> 00:08:17,419 that little wire that goes up and down 237 00:08:17,420 --> 00:08:20,089 is? Can you tell what that is? 238 00:08:20,090 --> 00:08:22,159 Yes, it is an antenna, so it's 239 00:08:22,160 --> 00:08:23,539 even much more professional than that. 240 00:08:23,540 --> 00:08:24,469 Outsourcing hours. 241 00:08:24,470 --> 00:08:26,809 You would require a special car to plug 242 00:08:26,810 --> 00:08:28,549 it in and to download the data here. 243 00:08:28,550 --> 00:08:31,369 You can just sit in the nearby 244 00:08:31,370 --> 00:08:33,529 Borza coffee, whatever you have here, and 245 00:08:33,530 --> 00:08:35,658 then just get the data 246 00:08:35,659 --> 00:08:37,069 uploaded to you of your Bluetooth. 247 00:08:37,070 --> 00:08:38,209 So this is scary. 248 00:08:38,210 --> 00:08:40,459 And if you can see the plastic 249 00:08:40,460 --> 00:08:41,658 piece on the bottom. 250 00:08:41,659 --> 00:08:42,889 So that's actually. 251 00:08:43,940 --> 00:08:47,069 The plastic, the gray piece there, 252 00:08:47,070 --> 00:08:48,379 it's the same model. 253 00:08:48,380 --> 00:08:49,909 So what they figure out is that they 254 00:08:49,910 --> 00:08:52,189 could unplug the plastic piece 255 00:08:52,190 --> 00:08:54,649 and they could put it inside with this 256 00:08:54,650 --> 00:08:56,569 skimmer hidden inside. 257 00:08:56,570 --> 00:08:58,909 So very professional. 258 00:08:58,910 --> 00:09:01,669 So this is a real threat 259 00:09:01,670 --> 00:09:03,859 or it can be hooked easily 260 00:09:03,860 --> 00:09:06,409 with just a few seconds with the device. 261 00:09:06,410 --> 00:09:08,509 It is powered by the device 262 00:09:08,510 --> 00:09:09,589 itself. 263 00:09:09,590 --> 00:09:11,359 Data can be downloaded wirelessly or with 264 00:09:11,360 --> 00:09:12,299 a special car. 265 00:09:12,300 --> 00:09:14,029 It takes little development effort. 266 00:09:14,030 --> 00:09:16,219 We did it in two weeks 267 00:09:16,220 --> 00:09:18,499 and it's cheap. It doesn't cost too much. 268 00:09:18,500 --> 00:09:20,689 So this is a real problem. 269 00:09:20,690 --> 00:09:21,739 It will happen. 270 00:09:21,740 --> 00:09:23,179 It is happening now. 271 00:09:23,180 --> 00:09:25,339 Cheap skimmers, they're there. 272 00:09:25,340 --> 00:09:26,340 They can be there. 273 00:09:27,770 --> 00:09:29,899 So what can you do with a cheap skimmer? 274 00:09:29,900 --> 00:09:32,089 The question becomes that we accept 275 00:09:32,090 --> 00:09:33,409 that these devices can exist. 276 00:09:33,410 --> 00:09:35,179 What can you do with such a skimmer? 277 00:09:35,180 --> 00:09:37,009 So smartcards, it's a very simple 278 00:09:37,010 --> 00:09:37,969 protocol. 279 00:09:37,970 --> 00:09:40,369 You can read, you can send commands 280 00:09:40,370 --> 00:09:42,079 to them. You send a request and you get a 281 00:09:42,080 --> 00:09:45,049 response from APD messages. 282 00:09:45,050 --> 00:09:47,479 DMV schema can intercept these messages 283 00:09:47,480 --> 00:09:49,789 so you can log them and 284 00:09:49,790 --> 00:09:51,469 you can also men in the middle so it can 285 00:09:51,470 --> 00:09:53,389 decide to prevent certain messages to 286 00:09:53,390 --> 00:09:54,529 reach the card. 287 00:09:54,530 --> 00:09:57,109 And it can send fake responses 288 00:09:57,110 --> 00:09:59,599 to the terminal like a network, 289 00:09:59,600 --> 00:10:01,309 TCP, IP, many, whatever. 290 00:10:05,460 --> 00:10:07,739 This is basically a summary of what 291 00:10:07,740 --> 00:10:10,349 the envy is, envy is divided 292 00:10:10,350 --> 00:10:12,239 into this main four phases. 293 00:10:12,240 --> 00:10:14,189 First of all, we have initiate 294 00:10:14,190 --> 00:10:16,259 application processing where 295 00:10:16,260 --> 00:10:18,809 the terminal gets to know the card. 296 00:10:18,810 --> 00:10:21,149 You know, ask the car, hello, what 297 00:10:21,150 --> 00:10:22,769 are you what kind of features that you 298 00:10:22,770 --> 00:10:25,139 support? Are you a Visa or MasterCard? 299 00:10:25,140 --> 00:10:26,249 What's the application then? I'm going to 300 00:10:26,250 --> 00:10:27,179 select. 301 00:10:27,180 --> 00:10:28,799 So application might be the Visa 302 00:10:28,800 --> 00:10:30,869 application, the massacre application 303 00:10:30,870 --> 00:10:32,849 or debit application. 304 00:10:32,850 --> 00:10:34,589 Then you have the card authentication. 305 00:10:34,590 --> 00:10:36,989 So we authenticate the card. 306 00:10:36,990 --> 00:10:38,819 And this can happening in several 307 00:10:38,820 --> 00:10:40,169 different ways, which I'm going to talk 308 00:10:40,170 --> 00:10:41,519 about. 309 00:10:41,520 --> 00:10:44,059 Um, then you have the card holder 310 00:10:44,060 --> 00:10:46,649 verification, so you verify the person, 311 00:10:46,650 --> 00:10:48,149 you're authenticated the car now you 312 00:10:48,150 --> 00:10:49,469 verify the person. 313 00:10:49,470 --> 00:10:51,239 And this is done with the pin. 314 00:10:51,240 --> 00:10:53,729 The pin is the card glorification 315 00:10:53,730 --> 00:10:54,809 or the signature. 316 00:10:54,810 --> 00:10:56,039 It depends. 317 00:10:56,040 --> 00:10:57,179 And then you have the actual 318 00:10:57,180 --> 00:10:58,180 transactions. 319 00:10:59,310 --> 00:11:01,379 So there are many problems with 320 00:11:01,380 --> 00:11:03,449 the way this protocol has been 321 00:11:03,450 --> 00:11:04,450 designed. 322 00:11:05,170 --> 00:11:07,509 The first problem is that there are 323 00:11:07,510 --> 00:11:10,479 all of these steps are separate 324 00:11:10,480 --> 00:11:13,119 and there are not strongly tied 325 00:11:13,120 --> 00:11:15,219 together, and this is one of the 326 00:11:15,220 --> 00:11:16,220 main issues. 327 00:11:16,960 --> 00:11:19,659 The second problem is that 328 00:11:19,660 --> 00:11:22,059 most of the data that is exchanged 329 00:11:22,060 --> 00:11:24,159 here is completely unencrypted. 330 00:11:24,160 --> 00:11:25,539 So like your credit card number, your 331 00:11:25,540 --> 00:11:27,579 name, it's all exchange and it's 332 00:11:27,580 --> 00:11:29,289 unencrypted. 333 00:11:29,290 --> 00:11:31,239 And the third problem is that the 334 00:11:31,240 --> 00:11:34,239 backend. So the bank relies 335 00:11:34,240 --> 00:11:36,819 on the correct operation of 336 00:11:36,820 --> 00:11:37,959 the terminal. 337 00:11:37,960 --> 00:11:40,059 So the terminal is not just 338 00:11:40,060 --> 00:11:41,139 a dumb middleman. 339 00:11:41,140 --> 00:11:42,849 It is something that is essential to 340 00:11:42,850 --> 00:11:45,009 maintain the security of 341 00:11:45,010 --> 00:11:45,909 the protocol. 342 00:11:45,910 --> 00:11:48,489 So this is not an end to end protocol 343 00:11:48,490 --> 00:11:50,079 by any means. 344 00:11:50,080 --> 00:11:52,779 So these are the three main issues 345 00:11:52,780 --> 00:11:54,429 within EMV. 346 00:11:54,430 --> 00:11:56,529 And you will also see that in the 347 00:11:56,530 --> 00:11:58,359 way that EMV is being designed. 348 00:11:59,430 --> 00:12:01,469 It has a lot of backwards compatibility 349 00:12:01,470 --> 00:12:03,599 issues and some problems were 350 00:12:03,600 --> 00:12:05,459 patched with newer version and so on and 351 00:12:05,460 --> 00:12:07,289 so on, so it's something that is 352 00:12:07,290 --> 00:12:09,719 definitely overengineered and not 353 00:12:09,720 --> 00:12:12,119 secure at all. 354 00:12:12,120 --> 00:12:14,039 So the first thing that you can do, which 355 00:12:14,040 --> 00:12:15,960 was surprising to us, but it's trivial, 356 00:12:17,130 --> 00:12:18,839 it used to be that you can do a Mac Strib 357 00:12:18,840 --> 00:12:20,489 clone from the chip. 358 00:12:20,490 --> 00:12:22,019 Now, you can still do that. 359 00:12:22,020 --> 00:12:24,029 You can get an exact copy of the Mac 360 00:12:24,030 --> 00:12:26,099 except for free digits. 361 00:12:26,100 --> 00:12:28,349 So free digits that you need, which 362 00:12:28,350 --> 00:12:30,119 are on the Mac stripe, are not on the 363 00:12:30,120 --> 00:12:32,439 chip. I don't know that you can do it. 364 00:12:32,440 --> 00:12:33,540 And this is the CSV. 365 00:12:34,710 --> 00:12:37,019 So this means 366 00:12:37,020 --> 00:12:39,239 that you cannot clone 367 00:12:39,240 --> 00:12:41,549 to Macs drive, by the way, unless 368 00:12:41,550 --> 00:12:43,739 you brute force on the nine hundred 369 00:12:43,740 --> 00:12:46,019 ninety nine CVS's 370 00:12:46,020 --> 00:12:48,509 and we know that in it nowadays. 371 00:12:48,510 --> 00:12:50,579 Nine hundred and ninety nine is such 372 00:12:50,580 --> 00:12:52,499 a large number isn't it. 373 00:12:52,500 --> 00:12:54,629 It is a staggering nine 374 00:12:54,630 --> 00:12:56,339 hundred and ninety nine. 375 00:12:56,340 --> 00:12:57,929 Wow. So yeah. 376 00:12:57,930 --> 00:13:00,119 So that's the whole security from 377 00:13:00,120 --> 00:13:01,199 cloning from cheap to Macs. 378 00:13:01,200 --> 00:13:02,639 Stripe is right there on these free 379 00:13:02,640 --> 00:13:04,079 digits. 380 00:13:04,080 --> 00:13:06,269 So and also 381 00:13:06,270 --> 00:13:08,159 there are a lot of websites that 382 00:13:08,160 --> 00:13:09,809 surprisingly nowadays they don't ask for 383 00:13:09,810 --> 00:13:12,419 the TV like, I don't know, Amazon. 384 00:13:12,420 --> 00:13:14,369 So if you buy to Amazon, you don't get 385 00:13:14,370 --> 00:13:15,299 asked for a CVB. 386 00:13:15,300 --> 00:13:17,789 So I got defrauded multiple times, 387 00:13:17,790 --> 00:13:19,919 are with data 388 00:13:19,920 --> 00:13:22,139 that was came from my card and 389 00:13:22,140 --> 00:13:23,489 that was used without the CBB. 390 00:13:23,490 --> 00:13:25,499 So of course you get your money back. 391 00:13:25,500 --> 00:13:27,719 OK, so it is a little hassle for 392 00:13:27,720 --> 00:13:29,339 you, but it's not a big deal. 393 00:13:29,340 --> 00:13:31,529 So you waste time but you will 394 00:13:31,530 --> 00:13:33,689 get your money back and only goods 395 00:13:33,690 --> 00:13:34,980 and services can be 396 00:13:36,690 --> 00:13:39,119 acquired by the fraudster in theory, 397 00:13:39,120 --> 00:13:40,979 because in practice are companies which 398 00:13:40,980 --> 00:13:43,049 they only exist to convert goods 399 00:13:43,050 --> 00:13:44,639 and services into cash. 400 00:13:44,640 --> 00:13:46,299 But anyway, you will get your money back. 401 00:13:46,300 --> 00:13:48,629 So there's no liability shift here. 402 00:13:48,630 --> 00:13:50,819 OK, but it still gives you an idea 403 00:13:50,820 --> 00:13:52,859 of how things could have been a little 404 00:13:52,860 --> 00:13:54,809 better from from the beginning. 405 00:13:54,810 --> 00:13:56,909 Now, if they guess the CV, that's a 406 00:13:56,910 --> 00:13:59,069 different matter entirely. 407 00:13:59,070 --> 00:14:01,049 OK, but, you know, I don't want to delve 408 00:14:01,050 --> 00:14:02,369 into that right now. 409 00:14:02,370 --> 00:14:04,079 So that's the first thing that can 410 00:14:04,080 --> 00:14:06,449 happen, which so is the fact that 411 00:14:06,450 --> 00:14:07,799 also data is not encrypted, 412 00:14:09,120 --> 00:14:10,529 the next part is offline, that 413 00:14:10,530 --> 00:14:12,629 authentication. So EMV 414 00:14:12,630 --> 00:14:15,029 introduces a way to authenticate 415 00:14:15,030 --> 00:14:17,099 the card so that you know that the car 416 00:14:17,100 --> 00:14:19,739 is exactly yours and in principle 417 00:14:19,740 --> 00:14:21,419 they should work. You have a smart card, 418 00:14:21,420 --> 00:14:22,499 very powerful. 419 00:14:22,500 --> 00:14:23,970 There's no reason why they shouldn't work 420 00:14:25,020 --> 00:14:26,020 now. 421 00:14:26,590 --> 00:14:28,629 There are three ways to authenticate a 422 00:14:28,630 --> 00:14:31,029 card. There's the basic 423 00:14:31,030 --> 00:14:33,339 way, which is called Saeda, static 424 00:14:33,340 --> 00:14:35,349 data authentication. 425 00:14:35,350 --> 00:14:37,629 There's a better way called the dynamic 426 00:14:37,630 --> 00:14:39,459 data authentication and there's an even 427 00:14:39,460 --> 00:14:41,199 better way, which is called the combined 428 00:14:41,200 --> 00:14:43,179 date of integration KDA. 429 00:14:43,180 --> 00:14:45,339 Each of these methods patches 430 00:14:45,340 --> 00:14:47,200 the flaws of the previous one. 431 00:14:48,490 --> 00:14:50,439 And this offline date authentication 432 00:14:50,440 --> 00:14:52,299 methods were introduced to support 433 00:14:52,300 --> 00:14:53,419 offline transactions. 434 00:14:53,420 --> 00:14:55,059 So to give you the ability of doing 435 00:14:55,060 --> 00:14:56,979 transaction completely offline so they're 436 00:14:56,980 --> 00:14:59,139 never used by ATMs, which they 437 00:14:59,140 --> 00:15:00,159 only go online. 438 00:15:00,160 --> 00:15:01,839 And nowadays, in theory, you should only 439 00:15:01,840 --> 00:15:05,199 see DDA cards, not SDK 440 00:15:05,200 --> 00:15:06,200 anymore. 441 00:15:06,850 --> 00:15:07,929 So one of the first issues. 442 00:15:07,930 --> 00:15:09,909 So what's the aim is that you have a 443 00:15:09,910 --> 00:15:11,739 static signature, which means that you 444 00:15:11,740 --> 00:15:13,629 can read a card, you can copy the data 445 00:15:13,630 --> 00:15:14,949 and you can copy the signature. 446 00:15:14,950 --> 00:15:17,169 So the signature is basically worthless, 447 00:15:17,170 --> 00:15:19,689 so to speak, because there's no challenge 448 00:15:19,690 --> 00:15:21,969 or response mechanism involved there 449 00:15:21,970 --> 00:15:22,899 at all. 450 00:15:22,900 --> 00:15:25,059 So if you're offline, you 451 00:15:25,060 --> 00:15:27,339 can just present a valid signature 452 00:15:27,340 --> 00:15:29,169 that you skimmed somewhere and then you 453 00:15:29,170 --> 00:15:31,539 can just fake the transaction because 454 00:15:31,540 --> 00:15:33,669 the transaction does not go online. 455 00:15:33,670 --> 00:15:35,559 Nobody will verify that. 456 00:15:35,560 --> 00:15:37,629 The only thing that is verified is 457 00:15:37,630 --> 00:15:39,849 a static data authentication, 458 00:15:39,850 --> 00:15:40,989 which you're cloning. 459 00:15:40,990 --> 00:15:43,479 So well done, EMV 460 00:15:43,480 --> 00:15:45,519 in introducing secure offline 461 00:15:45,520 --> 00:15:46,749 authentication. 462 00:15:46,750 --> 00:15:48,969 So DDA was invented where 463 00:15:48,970 --> 00:15:50,919 a random number is being exchanged and 464 00:15:50,920 --> 00:15:53,169 we're going to talk about that so that 465 00:15:53,170 --> 00:15:54,999 you have a challenge or response. 466 00:15:55,000 --> 00:15:56,509 But it was also a problem with that. 467 00:15:56,510 --> 00:15:58,929 So they invented KDA where they finally 468 00:15:58,930 --> 00:16:01,539 do the authentication and the transaction 469 00:16:01,540 --> 00:16:02,799 at the same time. 470 00:16:02,800 --> 00:16:05,319 So this is to explain how EMV 471 00:16:05,320 --> 00:16:07,719 is basically patched 472 00:16:07,720 --> 00:16:10,029 and KDA is, to me, 473 00:16:10,030 --> 00:16:12,069 are not useful because you can always 474 00:16:12,070 --> 00:16:13,989 fall back to previous authentication 475 00:16:13,990 --> 00:16:15,309 matters. You can always fall back to 476 00:16:15,310 --> 00:16:17,199 Tuesday if you want. 477 00:16:17,200 --> 00:16:20,169 So offline transactions are insecure 478 00:16:20,170 --> 00:16:23,049 if you support DMV standards, 479 00:16:23,050 --> 00:16:24,429 as it should be. 480 00:16:24,430 --> 00:16:26,589 And now when I mentioned the 481 00:16:26,590 --> 00:16:28,779 random number, there's a very, 482 00:16:28,780 --> 00:16:31,209 extremely nice and brilliant 483 00:16:31,210 --> 00:16:33,309 paper for people much more clever than 484 00:16:33,310 --> 00:16:35,619 me, which are to find people at Cambridge 485 00:16:35,620 --> 00:16:37,779 where they highlight the attack, 486 00:16:37,780 --> 00:16:39,609 which this paper really highlights the 487 00:16:39,610 --> 00:16:41,199 poor design choices which were made with 488 00:16:41,200 --> 00:16:43,689 EMV. So the unpredictable 489 00:16:43,690 --> 00:16:45,849 number which is used to 490 00:16:45,850 --> 00:16:48,309 secure the dynamic data 491 00:16:48,310 --> 00:16:50,769 authentication. So the dynamic 492 00:16:50,770 --> 00:16:52,599 component is the random number which is 493 00:16:52,600 --> 00:16:54,969 being exchanged is generated 494 00:16:54,970 --> 00:16:57,219 by the terminal, not by the back 495 00:16:57,220 --> 00:16:59,349 end. So if you have terminals 496 00:16:59,350 --> 00:17:01,749 were ever flawed, random 497 00:17:01,750 --> 00:17:03,789 number generator where you can predict or 498 00:17:03,790 --> 00:17:05,858 manipulate random numbers, 499 00:17:05,859 --> 00:17:09,219 you can effectively clone a transaction. 500 00:17:09,220 --> 00:17:11,559 And you have what they show in the paper 501 00:17:11,560 --> 00:17:13,029 that there are certain terminals where 502 00:17:13,030 --> 00:17:15,219 their definition of random number is 503 00:17:15,220 --> 00:17:17,379 that you need to 504 00:17:17,380 --> 00:17:19,899 give back 10 different numbers. 505 00:17:19,900 --> 00:17:21,909 And even if they repeat themselves, well, 506 00:17:21,910 --> 00:17:23,979 they're random because the PCI 507 00:17:23,980 --> 00:17:26,199 compliance said that the test mandates 508 00:17:26,200 --> 00:17:28,029 that you going to give me 10 numbers and 509 00:17:28,030 --> 00:17:29,199 they all got to be different. 510 00:17:29,200 --> 00:17:31,239 So that was the definition of random, 511 00:17:31,240 --> 00:17:32,410 which is awesome. 512 00:17:34,120 --> 00:17:36,189 So what you 513 00:17:36,190 --> 00:17:38,529 can do, you can collect transaction 514 00:17:38,530 --> 00:17:40,329 data from a genuine transaction. 515 00:17:40,330 --> 00:17:42,279 And when you see that random number 516 00:17:42,280 --> 00:17:44,109 popping up again, you replay that 517 00:17:44,110 --> 00:17:45,429 transaction. 518 00:17:45,430 --> 00:17:47,499 Luckily, there's one limitation here. 519 00:17:47,500 --> 00:17:48,819 You've got to be in the same country. 520 00:17:48,820 --> 00:17:50,079 You've got to spend the same amount and 521 00:17:50,080 --> 00:17:51,519 you've got to be in the same currency and 522 00:17:51,520 --> 00:17:53,709 on the same day, not on the same 523 00:17:53,710 --> 00:17:55,749 merchant, because the merchant 524 00:17:55,750 --> 00:17:58,659 information does not take place 525 00:17:58,660 --> 00:18:00,459 in the transaction between the card 526 00:18:00,460 --> 00:18:01,959 terminal. It is something that only the 527 00:18:01,960 --> 00:18:03,129 terminal knows. 528 00:18:03,130 --> 00:18:05,319 But if you fit within these conditions, 529 00:18:05,320 --> 00:18:07,269 then you can replay a transaction you 530 00:18:07,270 --> 00:18:09,309 don't even need a valid pin in. 531 00:18:09,310 --> 00:18:12,129 Your transaction is close to 100 percent. 532 00:18:12,130 --> 00:18:14,319 So let's think of this 533 00:18:14,320 --> 00:18:15,849 in terms of liability. 534 00:18:15,850 --> 00:18:18,099 We're not talking about massive fraud 535 00:18:18,100 --> 00:18:20,199 here. I'm not going to say that they 536 00:18:20,200 --> 00:18:22,869 can clone millions or car right away. 537 00:18:22,870 --> 00:18:24,939 Let's think about the single 538 00:18:24,940 --> 00:18:26,889 fraud that you might receive and the 539 00:18:26,890 --> 00:18:28,569 liability that is shifted to you. 540 00:18:28,570 --> 00:18:31,629 All of these legal attacks, they 541 00:18:31,630 --> 00:18:33,999 practically destroy every argument 542 00:18:34,000 --> 00:18:35,679 that would shift the liability to you. 543 00:18:35,680 --> 00:18:38,019 And this is the key of this talk and why 544 00:18:38,020 --> 00:18:39,489 it is important to talk about these 545 00:18:39,490 --> 00:18:40,599 things. 546 00:18:40,600 --> 00:18:43,089 So if there's a fraud. 547 00:18:44,170 --> 00:18:46,509 Always check if the same 548 00:18:46,510 --> 00:18:48,759 random number was used in the same 549 00:18:48,760 --> 00:18:50,829 country by a different terminal 550 00:18:50,830 --> 00:18:53,479 or if the random 551 00:18:53,480 --> 00:18:55,449 number of the terminals come predicted or 552 00:18:55,450 --> 00:18:58,839 not, if the bank cannot 553 00:18:58,840 --> 00:19:01,059 conclusively prove this to you, 554 00:19:01,060 --> 00:19:03,579 then there's a chance that this attack 555 00:19:03,580 --> 00:19:05,349 might have happened. 556 00:19:05,350 --> 00:19:06,909 Of course, even if it might not have 557 00:19:06,910 --> 00:19:09,369 happened, just the chance that it could 558 00:19:09,370 --> 00:19:10,959 and the fact that they cannot prove it 559 00:19:10,960 --> 00:19:12,159 means that they cannot shift the 560 00:19:12,160 --> 00:19:13,399 liability to you. 561 00:19:13,400 --> 00:19:14,619 And this is very important. 562 00:19:14,620 --> 00:19:16,659 Now, I'm not a lawyer, so I'm not giving 563 00:19:16,660 --> 00:19:18,519 you legal advice, but this is not what 564 00:19:18,520 --> 00:19:19,520 is. 565 00:19:21,860 --> 00:19:23,929 So and of course, they'll also want 566 00:19:23,930 --> 00:19:25,309 everything, which is called the 567 00:19:25,310 --> 00:19:27,019 application transaction counter, which 568 00:19:27,020 --> 00:19:28,909 gets increased every time use the car, 569 00:19:28,910 --> 00:19:30,709 which can also be used to detect these 570 00:19:30,710 --> 00:19:33,799 kind of frauds and 571 00:19:33,800 --> 00:19:34,819 all of these detection. 572 00:19:34,820 --> 00:19:37,249 By the way, none of this is done 573 00:19:37,250 --> 00:19:40,069 nowadays by backhands whatsoever. 574 00:19:40,070 --> 00:19:41,959 So what they could do, they don't do. 575 00:19:41,960 --> 00:19:43,789 And this is why it is important to know 576 00:19:43,790 --> 00:19:45,319 about these things. 577 00:19:47,060 --> 00:19:48,789 Second attack. 578 00:19:48,790 --> 00:19:51,369 Stolen by Cambridge, Peine Verification 579 00:19:51,370 --> 00:19:53,169 Wch attack. 580 00:19:53,170 --> 00:19:55,539 So this is the way the pin is verified 581 00:19:55,540 --> 00:19:57,729 by the terminal, the terminal 582 00:19:57,730 --> 00:19:58,839 as the car. 583 00:19:58,840 --> 00:20:00,579 Is this a valid pin and then a car? 584 00:20:00,580 --> 00:20:02,649 Yes. That says, yeah, sure. 585 00:20:02,650 --> 00:20:04,269 Or no, it's not. 586 00:20:04,270 --> 00:20:05,359 That's it. 587 00:20:05,360 --> 00:20:06,609 There's no authentication. 588 00:20:06,610 --> 00:20:08,529 There's no encryption whatsoever in the 589 00:20:08,530 --> 00:20:10,629 basic form of this mechanism. 590 00:20:10,630 --> 00:20:12,849 The response is not encrypted is just 591 00:20:12,850 --> 00:20:14,349 a yes or no. 592 00:20:14,350 --> 00:20:16,509 So, of course, a man in the middle 593 00:20:16,510 --> 00:20:18,759 of ised can just spoof 594 00:20:18,760 --> 00:20:20,889 the response and say yes 595 00:20:20,890 --> 00:20:23,559 to anything and create a so-called 596 00:20:23,560 --> 00:20:24,819 yes card. 597 00:20:24,820 --> 00:20:27,069 Now, this specific 598 00:20:27,070 --> 00:20:29,349 attack was anticipated by 599 00:20:29,350 --> 00:20:31,479 a SUB-STANDARD of EMV, which is called 600 00:20:31,480 --> 00:20:32,889 a common payment application 601 00:20:32,890 --> 00:20:34,579 specification. 602 00:20:34,580 --> 00:20:36,649 But guess who's checking 603 00:20:36,650 --> 00:20:39,469 this specific occurrence in Bacons, 604 00:20:39,470 --> 00:20:41,569 nobody so far we've done 605 00:20:41,570 --> 00:20:43,729 consulting for many financial entities 606 00:20:43,730 --> 00:20:45,859 in Europe and abroad, we 607 00:20:45,860 --> 00:20:47,779 have never seen detection for these kind 608 00:20:47,780 --> 00:20:49,879 of attacks, which takes correlation of 609 00:20:49,880 --> 00:20:50,869 two bits. 610 00:20:50,870 --> 00:20:53,539 If these two bits are both one, you could 611 00:20:53,540 --> 00:20:55,909 if one of them is one and one is zero, 612 00:20:55,910 --> 00:20:56,839 then it's not good. 613 00:20:56,840 --> 00:20:58,999 And, you know, mathematically that 614 00:20:59,000 --> 00:21:01,219 this attack takes place, 615 00:21:01,220 --> 00:21:03,050 but this is too difficult to do. 616 00:21:04,430 --> 00:21:06,679 So this is one example of 617 00:21:06,680 --> 00:21:08,839 this of this 618 00:21:08,840 --> 00:21:09,889 fraud taking place. 619 00:21:09,890 --> 00:21:12,079 So we have a clean run where 620 00:21:12,080 --> 00:21:14,029 the pin gets transmitted. 621 00:21:14,030 --> 00:21:16,159 You see, it is the little squares. 622 00:21:16,160 --> 00:21:18,319 We obfuscated the pin one, two, 623 00:21:18,320 --> 00:21:19,699 three, four there. 624 00:21:19,700 --> 00:21:21,019 And you get a response. 625 00:21:21,020 --> 00:21:23,179 And in a matter in the middle 626 00:21:23,180 --> 00:21:25,399 attack, you can just intercept that 627 00:21:25,400 --> 00:21:27,769 and then force saying 628 00:21:27,770 --> 00:21:29,989 yes and you will never relay the actual 629 00:21:29,990 --> 00:21:32,149 PIN verification to the card so 630 00:21:32,150 --> 00:21:33,889 the car will not know. 631 00:21:33,890 --> 00:21:36,439 So where does the detection lie? 632 00:21:36,440 --> 00:21:39,019 The card knows what happen 633 00:21:39,020 --> 00:21:40,879 and the terminal knows what happened. 634 00:21:40,880 --> 00:21:42,949 Each has their own view and 635 00:21:42,950 --> 00:21:45,079 the card signs this 636 00:21:45,080 --> 00:21:47,720 data so you can correlate. 637 00:21:48,900 --> 00:21:50,519 The cardholder ratification matter 638 00:21:50,520 --> 00:21:53,309 results generated by the terminal 639 00:21:53,310 --> 00:21:55,169 and the so-called ISHWAR application 640 00:21:55,170 --> 00:21:57,779 data, which is generated by the car, 641 00:21:57,780 --> 00:21:59,399 these two pieces of information, I will 642 00:21:59,400 --> 00:22:01,619 tell you, if the terminal is verified 643 00:22:01,620 --> 00:22:03,719 in offline and if the card is 644 00:22:03,720 --> 00:22:06,269 verified up of line and when this attack 645 00:22:06,270 --> 00:22:08,999 takes place, the two mismatch 646 00:22:09,000 --> 00:22:11,099 and the ID is signed. 647 00:22:11,100 --> 00:22:13,259 And to see if KVM are, you cannot 648 00:22:13,260 --> 00:22:15,539 intercept with a shim because 649 00:22:15,540 --> 00:22:17,069 the gap is between the terminal and the 650 00:22:17,070 --> 00:22:19,169 back. And so this can be easily 651 00:22:19,170 --> 00:22:21,539 detected, but it's not been 652 00:22:21,540 --> 00:22:23,609 detected. So this is one thing that you 653 00:22:23,610 --> 00:22:24,659 should ask. 654 00:22:24,660 --> 00:22:26,339 If you're involved into a fraud, you 655 00:22:26,340 --> 00:22:27,989 should ask the bank, please show me the 656 00:22:27,990 --> 00:22:29,549 edyta was a change. 657 00:22:29,550 --> 00:22:31,229 Please record it for me because it's 658 00:22:31,230 --> 00:22:33,449 vendor dependent and also showing 659 00:22:33,450 --> 00:22:36,009 the CVR and let's see if they match. 660 00:22:36,010 --> 00:22:37,439 That's one thing they should provide to 661 00:22:37,440 --> 00:22:38,440 you. 662 00:22:39,590 --> 00:22:41,719 Now, our contribution 663 00:22:41,720 --> 00:22:43,999 to chip in being a tax was 664 00:22:44,000 --> 00:22:46,099 to take this even further 665 00:22:46,100 --> 00:22:48,349 and say, OK, 666 00:22:48,350 --> 00:22:49,969 let's assume they fix this flaw, 667 00:22:51,350 --> 00:22:53,929 is the PIN protected? 668 00:22:53,930 --> 00:22:56,659 Can we still do something with it? 669 00:22:56,660 --> 00:22:59,089 And we discovered the KVM downgrade 670 00:22:59,090 --> 00:23:00,090 attack. 671 00:23:00,770 --> 00:23:03,859 So the card 672 00:23:03,860 --> 00:23:06,439 tells to the terminal 673 00:23:06,440 --> 00:23:08,689 how the cardholder should be verified 674 00:23:08,690 --> 00:23:10,969 with what is called the civilized. 675 00:23:10,970 --> 00:23:12,859 So sometimes you might use a signature, 676 00:23:12,860 --> 00:23:15,439 sometimes using mieux and 677 00:23:15,440 --> 00:23:17,629 pin in plaintext. 678 00:23:17,630 --> 00:23:20,749 You can use an ciphered pin woods 679 00:23:20,750 --> 00:23:23,269 who gets to decide that the card 680 00:23:23,270 --> 00:23:24,469 tells to the terminal. 681 00:23:24,470 --> 00:23:26,089 This is what I support. 682 00:23:26,090 --> 00:23:27,799 And then the terminal can decide. 683 00:23:27,800 --> 00:23:29,929 And the card also tells the preference 684 00:23:29,930 --> 00:23:31,309 of support the methods. 685 00:23:31,310 --> 00:23:33,389 So the card can say, I want to try 686 00:23:33,390 --> 00:23:34,849 a signature first, but if you're not 687 00:23:34,850 --> 00:23:37,129 ready to commit to that, let's use a pin 688 00:23:37,130 --> 00:23:38,879 offline pin. And if you don't want that, 689 00:23:38,880 --> 00:23:40,819 let's use an online pin and so on. 690 00:23:40,820 --> 00:23:43,030 And this is the KVM list. 691 00:23:44,060 --> 00:23:46,549 So what we discover is that 692 00:23:46,550 --> 00:23:48,829 even if this information is signed 693 00:23:48,830 --> 00:23:50,959 by the date of authentication phase, 694 00:23:50,960 --> 00:23:52,609 which is supposed to authenticate the 695 00:23:52,610 --> 00:23:55,729 card and the data on the card, 696 00:23:55,730 --> 00:23:57,829 if you tamper with it, the 697 00:23:57,830 --> 00:23:59,899 terminal will still be so 698 00:23:59,900 --> 00:24:02,179 happy to pass it and accept it 699 00:24:02,180 --> 00:24:04,309 and honor it, which is 700 00:24:04,310 --> 00:24:06,949 a problem on its own, because 701 00:24:06,950 --> 00:24:08,659 and I'm going to get into detail for 702 00:24:08,660 --> 00:24:10,639 this. So this is a KVM list. 703 00:24:10,640 --> 00:24:12,619 These are all the the feels that you can 704 00:24:12,620 --> 00:24:14,959 have. So were interesting to plaintext 705 00:24:14,960 --> 00:24:17,419 pin so you can have an ciphered pin, 706 00:24:17,420 --> 00:24:18,769 which means that the pin will send 707 00:24:18,770 --> 00:24:20,209 encrypted to the card. 708 00:24:20,210 --> 00:24:21,919 The response will still be unencrypted, 709 00:24:21,920 --> 00:24:23,899 by the way. The response will still be 710 00:24:23,900 --> 00:24:26,179 yes or no, but at least the pin 711 00:24:26,180 --> 00:24:28,339 is encrypted and you have 712 00:24:28,340 --> 00:24:30,529 online pin, which means that the card 713 00:24:30,530 --> 00:24:32,839 will never see the PIN request 714 00:24:32,840 --> 00:24:34,849 because it's between the terminal and the 715 00:24:34,850 --> 00:24:37,009 Bakken, or you have signature or 716 00:24:37,010 --> 00:24:39,289 you also have no PIN required or no CTM 717 00:24:39,290 --> 00:24:42,059 required whatsoever, which is what we use 718 00:24:42,060 --> 00:24:43,639 in toll roads in Italy. 719 00:24:43,640 --> 00:24:45,019 We pay with a credit card. 720 00:24:45,020 --> 00:24:46,729 There's no signature, there's no pin 721 00:24:46,730 --> 00:24:48,979 because we fall back to that. 722 00:24:49,980 --> 00:24:52,409 So we asked ourself 723 00:24:52,410 --> 00:24:54,569 what we if we use only GDA 724 00:24:54,570 --> 00:24:56,669 cars, which is what banks say, 725 00:24:56,670 --> 00:24:58,889 it's the state of the art, you know, and 726 00:24:58,890 --> 00:25:00,369 we validate the signature. 727 00:25:01,620 --> 00:25:02,849 So this is a problem. 728 00:25:02,850 --> 00:25:05,129 There's one piece of data 729 00:25:05,130 --> 00:25:06,719 on the car, which is called the Issuer 730 00:25:06,720 --> 00:25:08,939 Action Codes, which 731 00:25:08,940 --> 00:25:11,129 specify which failure 732 00:25:11,130 --> 00:25:13,259 conditions should trigger an 733 00:25:13,260 --> 00:25:15,299 online transaction. 734 00:25:15,300 --> 00:25:17,669 So this is what happens. 735 00:25:17,670 --> 00:25:19,829 I'm the card and I'll 736 00:25:19,830 --> 00:25:21,419 tell you to the terminal. 737 00:25:21,420 --> 00:25:24,119 Please do not deny a transaction 738 00:25:24,120 --> 00:25:26,399 without attempt to go online, even 739 00:25:26,400 --> 00:25:28,319 if my signature fails. 740 00:25:28,320 --> 00:25:30,389 So let's think of this in terms of 741 00:25:30,390 --> 00:25:31,349 security. 742 00:25:31,350 --> 00:25:33,809 You have data which is signed 743 00:25:33,810 --> 00:25:36,179 and you can tell to determine what 744 00:25:36,180 --> 00:25:38,460 to do if the signature fails. 745 00:25:41,840 --> 00:25:43,669 That seems obvious to me, right? 746 00:25:43,670 --> 00:25:45,799 It's like a I want to go out with 747 00:25:45,800 --> 00:25:47,509 you. I really don't. 748 00:25:47,510 --> 00:25:49,699 Yes, you do. OK, that's how he goes, 749 00:25:49,700 --> 00:25:50,700 right? 750 00:25:51,970 --> 00:25:54,339 So in every test terminal 751 00:25:54,340 --> 00:25:56,889 and bakin we were able to manipulate 752 00:25:56,890 --> 00:25:59,049 when it was necessary, 753 00:25:59,050 --> 00:26:01,329 these action codes so that if we tamper 754 00:26:01,330 --> 00:26:03,459 with KVM list, we 755 00:26:03,460 --> 00:26:05,079 will not be rejected offline. 756 00:26:05,080 --> 00:26:07,209 And guess what? The KVM list is passed by 757 00:26:07,210 --> 00:26:09,279 the terminal and it's applied so we can 758 00:26:09,280 --> 00:26:11,499 tell the terminal what to do, which means 759 00:26:11,500 --> 00:26:13,749 that whatever car you have, 760 00:26:13,750 --> 00:26:15,219 we can tell the terminal. 761 00:26:15,220 --> 00:26:17,679 Please verify that being offline, 762 00:26:17,680 --> 00:26:20,019 which means that a skimmer 763 00:26:20,020 --> 00:26:22,609 can always force determined 764 00:26:22,610 --> 00:26:24,669 not to transmit what is input on the 765 00:26:24,670 --> 00:26:27,159 pin, but as a pin to the card, 766 00:26:27,160 --> 00:26:28,599 which leaves for interception. 767 00:26:30,340 --> 00:26:32,709 Which makes the whole liability 768 00:26:32,710 --> 00:26:34,929 fall apart, and this is one 769 00:26:34,930 --> 00:26:37,159 example here, we modify the KVM, 770 00:26:37,160 --> 00:26:39,279 so this is a normal car which 771 00:26:39,280 --> 00:26:40,390 goes online. 772 00:26:41,650 --> 00:26:44,319 Because you see on the left side, 773 00:26:44,320 --> 00:26:46,719 the verification phase is empty 774 00:26:46,720 --> 00:26:48,459 because there been none because that went 775 00:26:48,460 --> 00:26:50,649 online, but on the 776 00:26:50,650 --> 00:26:53,289 right side, there's our man in the middle 777 00:26:53,290 --> 00:26:54,939 where we actually invalidate the 778 00:26:54,940 --> 00:26:56,589 civilized. 779 00:26:56,590 --> 00:26:58,719 And we force the transmission to 780 00:26:58,720 --> 00:26:59,720 the car. 781 00:27:00,180 --> 00:27:02,669 And keep in mind that 782 00:27:02,670 --> 00:27:04,799 the back end will know that 783 00:27:04,800 --> 00:27:06,959 the signature failed, 784 00:27:06,960 --> 00:27:09,899 they just don't care about it. 785 00:27:09,900 --> 00:27:11,819 So from a practical standpoint, you could 786 00:27:11,820 --> 00:27:14,039 say that this is somehow anticipated. 787 00:27:14,040 --> 00:27:15,599 The signature fails. 788 00:27:15,600 --> 00:27:18,059 But since the data authentication 789 00:27:18,060 --> 00:27:20,489 of the card is a separate 790 00:27:20,490 --> 00:27:22,679 step from the integration 791 00:27:22,680 --> 00:27:24,809 of the card holder, since 792 00:27:24,810 --> 00:27:27,329 those are treated separately, then 793 00:27:27,330 --> 00:27:29,429 the two phases, they 794 00:27:29,430 --> 00:27:31,559 don't use the knowledge gained from 795 00:27:31,560 --> 00:27:32,669 the other. 796 00:27:32,670 --> 00:27:34,409 So that's why you can always force the 797 00:27:34,410 --> 00:27:36,090 pin to be transmitted plaintext. 798 00:27:38,500 --> 00:27:40,779 The way you detected well, 799 00:27:40,780 --> 00:27:43,239 you have offline authentication, failure, 800 00:27:43,240 --> 00:27:46,509 and, you know, you might even correlate 801 00:27:46,510 --> 00:27:48,579 how the card was issued, you might 802 00:27:48,580 --> 00:27:50,649 have a card which only has online pin in 803 00:27:50,650 --> 00:27:52,029 the KVM list. 804 00:27:52,030 --> 00:27:54,039 So you can tell if the offline PDA 805 00:27:54,040 --> 00:27:55,809 requested something wrong is there? 806 00:27:55,810 --> 00:27:58,089 But that's simply too much data 807 00:27:58,090 --> 00:27:59,019 to keep on the back. 808 00:27:59,020 --> 00:28:00,609 And, you know, the backend would have to 809 00:28:00,610 --> 00:28:02,259 know every configuration for every single 810 00:28:02,260 --> 00:28:04,479 card, which to me is not reasonable, but 811 00:28:04,480 --> 00:28:05,679 apparently it is. 812 00:28:05,680 --> 00:28:07,689 But you could at least reject every 813 00:28:07,690 --> 00:28:09,939 transaction we does doesn't 814 00:28:09,940 --> 00:28:11,499 pass offline that authentication. 815 00:28:11,500 --> 00:28:13,569 But, you know, sometimes you also don't 816 00:28:13,570 --> 00:28:15,309 get offline data authentication 817 00:28:15,310 --> 00:28:17,199 processing at all. 818 00:28:17,200 --> 00:28:19,449 So and one more important 819 00:28:19,450 --> 00:28:21,549 thing, even if you would have these 820 00:28:21,550 --> 00:28:23,709 markers, these are not 821 00:28:23,710 --> 00:28:26,259 conclusive evidence, either positive 822 00:28:26,260 --> 00:28:28,329 or negative, because as 823 00:28:28,330 --> 00:28:31,269 a schema, I can always reset 824 00:28:31,270 --> 00:28:33,849 the terminal as soon as I get the pin, 825 00:28:33,850 --> 00:28:35,949 which means that the back and one 826 00:28:35,950 --> 00:28:38,199 see anything at all and 827 00:28:38,200 --> 00:28:39,729 we don't get any data from the 828 00:28:39,730 --> 00:28:41,049 transaction. 829 00:28:41,050 --> 00:28:43,389 So this is a design flaw 830 00:28:43,390 --> 00:28:45,549 that cannot be even detected 831 00:28:45,550 --> 00:28:47,769 if you implement it completely 832 00:28:47,770 --> 00:28:49,179 covertly. 833 00:28:49,180 --> 00:28:51,339 The only way to fix this is to 834 00:28:51,340 --> 00:28:53,169 have the firmware on the point of sale 835 00:28:53,170 --> 00:28:55,329 device to refuse offline 836 00:28:55,330 --> 00:28:56,709 plaintext verification. 837 00:28:58,950 --> 00:29:01,289 All the time, if you know that your cards 838 00:29:01,290 --> 00:29:03,359 are don't support that, or in 839 00:29:03,360 --> 00:29:05,879 case of signature invalidation at least, 840 00:29:05,880 --> 00:29:08,309 and this is a big problem with liability 841 00:29:08,310 --> 00:29:10,829 because you cannot say that the EMV 842 00:29:10,830 --> 00:29:11,830 protects your pin. 843 00:29:13,020 --> 00:29:15,299 Despite the card configuration, you 844 00:29:15,300 --> 00:29:17,729 might have a car 845 00:29:17,730 --> 00:29:19,979 which doesn't even have a pin on 846 00:29:19,980 --> 00:29:22,079 the card itself, and 847 00:29:22,080 --> 00:29:24,119 I would still be able to do this and to 848 00:29:24,120 --> 00:29:25,229 see your being. 849 00:29:25,230 --> 00:29:27,599 So if I steal your card afterwards, 850 00:29:27,600 --> 00:29:28,799 of course, I would need your physical 851 00:29:28,800 --> 00:29:30,629 card. These are the scenario we're 852 00:29:30,630 --> 00:29:31,829 talking about. 853 00:29:31,830 --> 00:29:33,749 Then you will never be liable. 854 00:29:33,750 --> 00:29:35,669 But the classic case is that if you lose 855 00:29:35,670 --> 00:29:37,739 your card and it gets used and 856 00:29:37,740 --> 00:29:39,719 he has a chip and pin, they will tell you 857 00:29:39,720 --> 00:29:41,309 that you are liable if it's used with a 858 00:29:41,310 --> 00:29:43,139 pin because they tell you that you're 859 00:29:43,140 --> 00:29:45,479 being negligent because maybe 860 00:29:45,480 --> 00:29:47,489 you had your pin written down in the bag 861 00:29:47,490 --> 00:29:48,509 or somewhere. 862 00:29:48,510 --> 00:29:50,579 But it doesn't matter if it's true 863 00:29:50,580 --> 00:29:53,069 or not. They will use the technology 864 00:29:53,070 --> 00:29:55,709 of EMV, which is flogged against 865 00:29:55,710 --> 00:29:58,079 you. And we see this all the time. 866 00:29:58,080 --> 00:30:00,179 And we consult card holders into 867 00:30:00,180 --> 00:30:02,519 preventing these kind of claims 868 00:30:02,520 --> 00:30:04,259 by asking for the right data. 869 00:30:04,260 --> 00:30:06,899 And which is why I'm giving 870 00:30:06,900 --> 00:30:09,089 this talk right now to let you know what 871 00:30:09,090 --> 00:30:10,979 you can ask in order to prevent these 872 00:30:10,980 --> 00:30:12,479 kind of things. Because even if we're not 873 00:30:12,480 --> 00:30:14,639 talking about millions of people being 874 00:30:14,640 --> 00:30:15,809 fraud, I don't care. 875 00:30:15,810 --> 00:30:18,329 As long as one person loses, 876 00:30:18,330 --> 00:30:20,609 I don't care one hundred two thousand 877 00:30:20,610 --> 00:30:22,679 euro because these technologies 878 00:30:22,680 --> 00:30:23,999 turn against them. 879 00:30:24,000 --> 00:30:25,289 I don't think that's right. 880 00:30:25,290 --> 00:30:26,369 And I think as an I.T. 881 00:30:26,370 --> 00:30:29,219 security community, we should work 882 00:30:29,220 --> 00:30:30,220 against that. 883 00:30:31,470 --> 00:30:32,470 Thank you. 884 00:30:39,540 --> 00:30:41,519 So going back to the PIN verification, 885 00:30:41,520 --> 00:30:43,439 which attack the one where we say yes or 886 00:30:43,440 --> 00:30:44,819 no to the pain that was discovered by 887 00:30:44,820 --> 00:30:48,089 Cambridge and their first paper, they say 888 00:30:48,090 --> 00:30:50,339 that depending on the KVM 889 00:30:50,340 --> 00:30:52,149 list, you know, whatever is specified, 890 00:30:52,150 --> 00:30:54,539 Chip, his signature online pin, 891 00:30:54,540 --> 00:30:56,669 you know, they tell that this is 892 00:30:56,670 --> 00:30:58,859 their attack is not applicable to certain 893 00:30:58,860 --> 00:31:01,049 cards. And at the time when we 894 00:31:01,050 --> 00:31:03,309 release the KVM downgrade attack, we 895 00:31:03,310 --> 00:31:05,429 thought of combining the two. 896 00:31:05,430 --> 00:31:07,679 But we you know, we didn't actually 897 00:31:07,680 --> 00:31:10,739 tried this summer. 898 00:31:10,740 --> 00:31:12,179 We tried it. 899 00:31:12,180 --> 00:31:13,799 There's no reason why shouldn't work. 900 00:31:13,800 --> 00:31:15,149 And guess what? 901 00:31:15,150 --> 00:31:16,680 It works just fine. 902 00:31:18,240 --> 00:31:20,369 We can combine the KVM 903 00:31:20,370 --> 00:31:22,679 downgrade attack and the PIN verification 904 00:31:22,680 --> 00:31:25,049 which attack to use stolen cars 905 00:31:25,050 --> 00:31:27,029 regardless of their configuration. 906 00:31:27,030 --> 00:31:29,339 We can use cards which are only 907 00:31:29,340 --> 00:31:30,749 meant to go online. 908 00:31:30,750 --> 00:31:32,489 We can use cars that only have a 909 00:31:32,490 --> 00:31:34,739 signature. We can use cards 910 00:31:34,740 --> 00:31:37,499 where the actual chip on the card 911 00:31:37,500 --> 00:31:40,229 doesn't have the pin stored. 912 00:31:40,230 --> 00:31:41,699 There's a command which you send to the 913 00:31:41,700 --> 00:31:43,859 smart card saying verify pin. 914 00:31:43,860 --> 00:31:46,319 Certain cards do not support that 915 00:31:46,320 --> 00:31:48,479 because they are secure, 916 00:31:48,480 --> 00:31:50,699 secure and 917 00:31:50,700 --> 00:31:52,199 they don't even have knowledge of the 918 00:31:52,200 --> 00:31:53,369 pin. 919 00:31:53,370 --> 00:31:56,729 But we if we combine the two attacks, 920 00:31:56,730 --> 00:31:59,159 we downgrade or upgrade 921 00:31:59,160 --> 00:32:01,589 the card depending on its configuration 922 00:32:01,590 --> 00:32:03,719 and then we force a fake 923 00:32:03,720 --> 00:32:05,849 offline pin reply. 924 00:32:05,850 --> 00:32:08,159 And of course this works regardless 925 00:32:08,160 --> 00:32:09,769 of the card configuration. 926 00:32:09,770 --> 00:32:12,359 We were able to test it with every card, 927 00:32:12,360 --> 00:32:13,679 with different stores. 928 00:32:13,680 --> 00:32:15,449 We tested our own cards. 929 00:32:15,450 --> 00:32:17,849 We were able to fraud our own 930 00:32:17,850 --> 00:32:19,949 cards with PIN, which is 931 00:32:19,950 --> 00:32:21,659 one, two, three, four, which is not our 932 00:32:21,660 --> 00:32:22,660 actual pin. 933 00:32:24,450 --> 00:32:26,519 So it doesn't really matter, 934 00:32:26,520 --> 00:32:28,949 the back end is not even smart enough 935 00:32:28,950 --> 00:32:31,109 to understand that offline 936 00:32:31,110 --> 00:32:33,089 verification took place on a card that 937 00:32:33,090 --> 00:32:35,159 has no pain whatsoever, 938 00:32:35,160 --> 00:32:37,319 even with cards, with a signature, 939 00:32:37,320 --> 00:32:39,509 so that the Cambridge been verification, 940 00:32:39,510 --> 00:32:41,579 which attack can be applied to 941 00:32:41,580 --> 00:32:42,809 every single card. 942 00:32:42,810 --> 00:32:44,369 So if the bank will tell you all, but we 943 00:32:44,370 --> 00:32:46,439 only have cards and you don't even 944 00:32:46,440 --> 00:32:48,419 have a pin on the car or you only go in 945 00:32:48,420 --> 00:32:49,420 line. 946 00:32:50,660 --> 00:32:52,759 It doesn't matter at all because 947 00:32:52,760 --> 00:32:54,619 you can always downgrade. 948 00:32:54,620 --> 00:32:56,509 So this is an example of that run 949 00:32:57,890 --> 00:33:00,379 again on the left side, 950 00:33:00,380 --> 00:33:02,539 there was no verification whatsoever 951 00:33:02,540 --> 00:33:04,799 and this car was set to do online. 952 00:33:04,800 --> 00:33:06,079 So we do two things. 953 00:33:06,080 --> 00:33:08,329 We do the combination of the two attacks. 954 00:33:08,330 --> 00:33:11,269 First of all, we do change to civilized 955 00:33:11,270 --> 00:33:13,369 so that the is being asked to 956 00:33:13,370 --> 00:33:15,470 the car. And then we reply, 957 00:33:16,700 --> 00:33:18,749 yes, this is my pin. 958 00:33:18,750 --> 00:33:20,149 Of course. One, two, three, four is my 959 00:33:20,150 --> 00:33:21,150 pin. 960 00:33:21,680 --> 00:33:24,049 And you get both the textural markers 961 00:33:24,050 --> 00:33:26,660 here because the signature fails. 962 00:33:28,270 --> 00:33:30,429 And the card tells that 963 00:33:30,430 --> 00:33:32,289 he has verified no pain, while the 964 00:33:32,290 --> 00:33:34,419 terminal will say, I have verified a pin, 965 00:33:34,420 --> 00:33:36,879 so we have two things that we can spot. 966 00:33:36,880 --> 00:33:39,129 No back in that we have tested so 967 00:33:39,130 --> 00:33:41,259 far was marked enough to do 968 00:33:41,260 --> 00:33:42,729 this kind of correlation. 969 00:33:42,730 --> 00:33:44,829 Not on the same day, not after a 970 00:33:44,830 --> 00:33:47,409 week, not after a month, 971 00:33:47,410 --> 00:33:48,410 nothing. 972 00:33:50,250 --> 00:33:53,279 So this is a main problem here, 973 00:33:53,280 --> 00:33:54,389 there's another problem, 974 00:33:55,920 --> 00:33:58,059 EMV supports the concept of transaction 975 00:33:58,060 --> 00:33:59,999 certificate, which is the final thing 976 00:34:00,000 --> 00:34:00,989 that happens. 977 00:34:00,990 --> 00:34:03,359 The card will spit out to determine 978 00:34:03,360 --> 00:34:05,069 a transaction certificate, which is to be 979 00:34:05,070 --> 00:34:06,670 the proof of the transaction. 980 00:34:08,159 --> 00:34:10,019 These transactions certificate is not 981 00:34:10,020 --> 00:34:11,669 immediately sent to the back and 982 00:34:11,670 --> 00:34:13,468 sometimes is not sent to the back. 983 00:34:13,469 --> 00:34:15,539 And at all any you know, 984 00:34:15,540 --> 00:34:17,669 it should only be parsed when a dispute 985 00:34:17,670 --> 00:34:18,629 arises. 986 00:34:18,630 --> 00:34:19,859 So guess what? 987 00:34:19,860 --> 00:34:21,269 You can change that. 988 00:34:21,270 --> 00:34:23,669 You can put it to dead beef, whatever 989 00:34:23,670 --> 00:34:25,738 hex lead 990 00:34:25,739 --> 00:34:27,509 sentence you want to put, and the 991 00:34:27,510 --> 00:34:29,579 transaction will go through right away. 992 00:34:29,580 --> 00:34:31,259 So what is supposed to be the actual 993 00:34:31,260 --> 00:34:32,729 proof of the transaction never gets 994 00:34:32,730 --> 00:34:35,158 checked. So I could potentially fake 995 00:34:35,159 --> 00:34:37,259 my transaction certificate on all 996 00:34:37,260 --> 00:34:39,359 of my transactions and then claim all of 997 00:34:39,360 --> 00:34:41,428 them back and ask them, look at 998 00:34:41,429 --> 00:34:42,419 the transaction certificate. 999 00:34:42,420 --> 00:34:44,039 It doesn't really make sense. 1000 00:34:44,040 --> 00:34:46,589 And the bank would be, you know, 1001 00:34:46,590 --> 00:34:48,599 obliged to tell that I'm right. 1002 00:34:48,600 --> 00:34:50,399 Of course, that will be not very smart. 1003 00:34:50,400 --> 00:34:53,069 But this is to give you approve 1004 00:34:53,070 --> 00:34:55,738 of how flawed this is. 1005 00:34:55,739 --> 00:34:57,839 And this also means one thing that when 1006 00:34:57,840 --> 00:34:59,939 you see on the card, the transaction 1007 00:34:59,940 --> 00:35:02,129 certificate, the issuer application 1008 00:35:02,130 --> 00:35:04,229 data, which is what allows 1009 00:35:04,230 --> 00:35:06,809 you to detect the PIN verification 1010 00:35:06,810 --> 00:35:08,519 which attacked or the application 1011 00:35:08,520 --> 00:35:10,619 transaction counter, since those 1012 00:35:10,620 --> 00:35:12,989 are printed on the receipt from these 1013 00:35:12,990 --> 00:35:15,029 last phase, they can all be faked. 1014 00:35:15,030 --> 00:35:17,099 You can put whatever you want there. 1015 00:35:17,100 --> 00:35:19,319 So if the bank will 1016 00:35:19,320 --> 00:35:21,089 ask you to see the receipt or if they 1017 00:35:21,090 --> 00:35:23,759 will show you the receipt as a proof 1018 00:35:23,760 --> 00:35:26,279 of some metadata, that is important. 1019 00:35:26,280 --> 00:35:28,109 You can always say that you don't trust 1020 00:35:28,110 --> 00:35:29,939 that because you can tamper with all of 1021 00:35:29,940 --> 00:35:30,479 that. 1022 00:35:30,480 --> 00:35:32,909 So whatever is on the receipt 1023 00:35:32,910 --> 00:35:34,679 with these specific products can be 1024 00:35:34,680 --> 00:35:35,609 faked. 1025 00:35:35,610 --> 00:35:36,989 No problem about that. 1026 00:35:36,990 --> 00:35:38,329 And this is also important to know. 1027 00:35:39,540 --> 00:35:41,429 So the banks will have the following 1028 00:35:41,430 --> 00:35:44,129 arguments in case of EMV, fraud 1029 00:35:44,130 --> 00:35:45,989 and verification can all be compromised 1030 00:35:45,990 --> 00:35:48,299 with EMV and ciphered 1031 00:35:48,300 --> 00:35:49,199 pin guarantees. 1032 00:35:49,200 --> 00:35:51,269 Security online PIN 1033 00:35:51,270 --> 00:35:53,789 can all be intercepted and plaintext 1034 00:35:53,790 --> 00:35:56,189 is get for backwards compatibility only 1035 00:35:56,190 --> 00:35:58,349 and can only be fores if 1036 00:35:58,350 --> 00:36:00,509 you tamper determinable or on 1037 00:36:00,510 --> 00:36:01,739 specific configuration. 1038 00:36:02,970 --> 00:36:04,559 All of these are not true. 1039 00:36:04,560 --> 00:36:06,479 As we've shown, we can always. 1040 00:36:07,530 --> 00:36:10,259 Fall back to plaintext pin, 1041 00:36:10,260 --> 00:36:12,359 so all the mechanisms that 1042 00:36:12,360 --> 00:36:13,559 are there to protect the PIN 1043 00:36:13,560 --> 00:36:15,689 verification, they do not work and 1044 00:36:15,690 --> 00:36:18,209 we don't tamper determinately itself. 1045 00:36:18,210 --> 00:36:20,279 I could even have my own card, 1046 00:36:20,280 --> 00:36:22,379 which has NFC Bluetooth connection 1047 00:36:22,380 --> 00:36:24,509 to a real car, and it would just 1048 00:36:24,510 --> 00:36:25,829 do this kind of transaction. 1049 00:36:25,830 --> 00:36:28,049 The terminal is intact. 1050 00:36:28,050 --> 00:36:29,699 We don't change the firmware on the 1051 00:36:29,700 --> 00:36:31,799 terminal. We don't do anything wrong 1052 00:36:31,800 --> 00:36:33,929 with it. OK, so don't take the 1053 00:36:33,930 --> 00:36:36,149 fact that we insert Agim as 1054 00:36:36,150 --> 00:36:37,979 an example as terminal tampering, because 1055 00:36:37,980 --> 00:36:39,539 that's not the case. It could be very 1056 00:36:39,540 --> 00:36:40,679 well be my own card. 1057 00:36:41,730 --> 00:36:43,949 So liability falls 1058 00:36:43,950 --> 00:36:46,139 apart, especially in the CVN 1059 00:36:46,140 --> 00:36:48,599 downgrade one where you can have no 1060 00:36:48,600 --> 00:36:50,729 log's in the 1061 00:36:50,730 --> 00:36:51,689 end. 1062 00:36:51,690 --> 00:36:54,779 So if you have a dispute, 1063 00:36:54,780 --> 00:36:57,089 the bank should at least provide you the 1064 00:36:57,090 --> 00:36:59,129 predictable numbers from that same 1065 00:36:59,130 --> 00:37:01,319 terminal or from other terminals that 1066 00:37:01,320 --> 00:37:03,479 were used with your car on the same 1067 00:37:03,480 --> 00:37:04,469 day. 1068 00:37:04,470 --> 00:37:05,819 They should provide you the terminal 1069 00:37:05,820 --> 00:37:07,289 verification results. 1070 00:37:07,290 --> 00:37:09,089 They should provide you the E application 1071 00:37:09,090 --> 00:37:10,499 data. They should provide you the 1072 00:37:10,500 --> 00:37:12,179 application for that can counter all of 1073 00:37:12,180 --> 00:37:14,039 the metadata that I've shown to you. 1074 00:37:14,040 --> 00:37:16,289 They should provide them to you in order 1075 00:37:16,290 --> 00:37:18,269 to give an analysis of exactly what 1076 00:37:18,270 --> 00:37:20,489 happen. If they don't, they 1077 00:37:20,490 --> 00:37:21,599 have no claims. 1078 00:37:21,600 --> 00:37:23,399 And even if they provide them, it really 1079 00:37:23,400 --> 00:37:25,139 depends on what's going on. 1080 00:37:26,220 --> 00:37:28,439 So depending on the different 1081 00:37:28,440 --> 00:37:30,479 kind of attacks, these are the things 1082 00:37:30,480 --> 00:37:31,439 that you should ask. 1083 00:37:31,440 --> 00:37:33,569 And it is essential to acquire the 1084 00:37:33,570 --> 00:37:35,879 backend data, not only the one 1085 00:37:35,880 --> 00:37:38,099 that has the terminal and especially not 1086 00:37:38,100 --> 00:37:40,559 the one that the receipt 1087 00:37:40,560 --> 00:37:42,210 has and. 1088 00:37:43,570 --> 00:37:45,249 So the unpredictable number will give you 1089 00:37:45,250 --> 00:37:47,319 the freshness of the terminal, 1090 00:37:47,320 --> 00:37:49,569 run the numbers the ATC 1091 00:37:49,570 --> 00:37:51,279 will give you if there are any gaps in 1092 00:37:51,280 --> 00:37:53,379 the transaction, which can make you 1093 00:37:53,380 --> 00:37:55,869 understand if something fishy went on at 1094 00:37:55,870 --> 00:37:57,729 the terminal. Verification results will 1095 00:37:57,730 --> 00:37:58,989 tell you of the offline data 1096 00:37:58,990 --> 00:38:01,749 authentication, failed or not. 1097 00:38:01,750 --> 00:38:03,849 And the Kalila verification method result 1098 00:38:03,850 --> 00:38:06,009 will tell you exactly what 1099 00:38:06,010 --> 00:38:08,349 happened. And they must agree 1100 00:38:08,350 --> 00:38:10,509 with the issuer application data which 1101 00:38:10,510 --> 00:38:11,829 is signed. 1102 00:38:11,830 --> 00:38:14,019 If they don't agree, then an 1103 00:38:14,020 --> 00:38:16,659 attack went on in spoofing 1104 00:38:16,660 --> 00:38:17,739 the incorrect being. 1105 00:38:17,740 --> 00:38:19,659 So these are things that you should ask. 1106 00:38:19,660 --> 00:38:21,729 So what happens when we ask 1107 00:38:21,730 --> 00:38:23,739 for these data? 1108 00:38:23,740 --> 00:38:24,740 Two options. 1109 00:38:26,020 --> 00:38:28,929 When we start asking for these data, 1110 00:38:28,930 --> 00:38:31,149 the bank sees that 1111 00:38:31,150 --> 00:38:32,649 the claim goes forward because some 1112 00:38:32,650 --> 00:38:34,689 people, they just want to settle before 1113 00:38:34,690 --> 00:38:36,159 or they get scared and they lose their 1114 00:38:36,160 --> 00:38:37,779 money. And this is what actually happens. 1115 00:38:37,780 --> 00:38:38,780 I have. 1116 00:38:39,110 --> 00:38:41,269 Experience with this, so 1117 00:38:41,270 --> 00:38:43,399 if you get to ask the data at 1118 00:38:43,400 --> 00:38:45,899 some point, depends on the country again 1119 00:38:45,900 --> 00:38:47,989 and not a legal expert, 1120 00:38:47,990 --> 00:38:49,309 but this is how it is. 1121 00:38:49,310 --> 00:38:50,390 You go to the arbiter. 1122 00:38:51,640 --> 00:38:53,829 And the arbiter, guess what, it 1123 00:38:53,830 --> 00:38:55,449 will tell you that the burden of proof in 1124 00:38:55,450 --> 00:38:57,519 fraud claims shall fall in honor of the 1125 00:38:57,520 --> 00:38:59,079 payment infrastructure. 1126 00:38:59,080 --> 00:39:01,269 And at least in Italy, they ruled that 1127 00:39:01,270 --> 00:39:02,979 the pain can be acquired in many ways 1128 00:39:02,980 --> 00:39:04,600 that outside the cardholder control. 1129 00:39:05,710 --> 00:39:07,869 Now, this is the interesting thing, 1130 00:39:07,870 --> 00:39:08,870 every single 1131 00:39:10,090 --> 00:39:12,819 fraud case where the liability 1132 00:39:12,820 --> 00:39:14,679 they attempted to shift the liability to 1133 00:39:14,680 --> 00:39:16,779 the customer, the bank 1134 00:39:16,780 --> 00:39:19,479 tried to do this anyway, 1135 00:39:19,480 --> 00:39:21,849 even if there were dozens of legal 1136 00:39:21,850 --> 00:39:25,119 precedents with response to no one. 1137 00:39:25,120 --> 00:39:27,099 So now we're in a state where this kind 1138 00:39:27,100 --> 00:39:29,169 of response is just, you know, 1139 00:39:29,170 --> 00:39:31,809 as it goes in law, is just quoted 1140 00:39:31,810 --> 00:39:33,189 from previous cases. 1141 00:39:33,190 --> 00:39:35,409 They wouldn't even bother in doing 1142 00:39:35,410 --> 00:39:36,309 the whole dissertation. 1143 00:39:36,310 --> 00:39:38,499 They say, you know, go track 1144 00:39:38,500 --> 00:39:40,359 like they do in law and order in us. 1145 00:39:40,360 --> 00:39:41,459 Go and Tricor. 1146 00:39:41,460 --> 00:39:43,749 Eighty four, it was Johnson versus 1147 00:39:43,750 --> 00:39:44,799 me. This is what happened. 1148 00:39:44,800 --> 00:39:46,359 So that's what it is. 1149 00:39:46,360 --> 00:39:48,549 So but they try anyway, even if 1150 00:39:48,550 --> 00:39:50,349 they know because what do they have to 1151 00:39:50,350 --> 00:39:52,659 lose. Right. So it is important to know 1152 00:39:52,660 --> 00:39:54,369 that at the end of the day, in most 1153 00:39:54,370 --> 00:39:56,439 countries you are protected and they can 1154 00:39:56,440 --> 00:39:58,269 never use the technology against you. 1155 00:39:58,270 --> 00:40:00,999 But you need to have to show 1156 00:40:01,000 --> 00:40:03,199 that you know the technology 1157 00:40:03,200 --> 00:40:04,629 a little to know what to ask for. 1158 00:40:04,630 --> 00:40:06,699 Because, number two, 1159 00:40:06,700 --> 00:40:08,739 in some cases, as soon as we ask for 1160 00:40:08,740 --> 00:40:10,389 detailed logs, guess what? 1161 00:40:10,390 --> 00:40:13,619 The bank settled and we had to refund. 1162 00:40:13,620 --> 00:40:15,749 I don't know why, I don't know 1163 00:40:15,750 --> 00:40:18,149 if it's because the data 1164 00:40:18,150 --> 00:40:20,249 would have proved that some frog was 1165 00:40:20,250 --> 00:40:20,879 taking place. 1166 00:40:20,880 --> 00:40:22,079 I have no idea. 1167 00:40:22,080 --> 00:40:23,759 The only thing that I know is that the 1168 00:40:23,760 --> 00:40:26,819 classic Vendel response in this case is 1169 00:40:26,820 --> 00:40:28,799 there are sufficient security mechanisms 1170 00:40:28,800 --> 00:40:30,449 in the payment industry to prevent this 1171 00:40:30,450 --> 00:40:31,709 kind of things to happen. 1172 00:40:31,710 --> 00:40:33,959 This is a classic response that Visa, 1173 00:40:33,960 --> 00:40:36,029 MasterCard or any bank will 1174 00:40:36,030 --> 00:40:38,309 give you because and 1175 00:40:38,310 --> 00:40:39,929 in a way you would understand them. 1176 00:40:39,930 --> 00:40:42,509 They will never tell you that, of course, 1177 00:40:42,510 --> 00:40:44,639 inves Flarf they would just tell you that 1178 00:40:44,640 --> 00:40:46,349 there's a sufficient number of mechanisms 1179 00:40:46,350 --> 00:40:47,549 in place. 1180 00:40:47,550 --> 00:40:50,609 But as soon as we see fraud cases being 1181 00:40:50,610 --> 00:40:52,619 shifted to the customer, as soon as I'm 1182 00:40:52,620 --> 00:40:55,019 able to fraud my own card and nobody 1183 00:40:55,020 --> 00:40:57,029 calls me, you know, I think that there's 1184 00:40:57,030 --> 00:40:58,379 something wrong with the system, 1185 00:40:58,380 --> 00:41:00,629 especially where that analogy can very 1186 00:41:00,630 --> 00:41:02,459 well do end to end encryption from the 1187 00:41:02,460 --> 00:41:03,509 card to the back end. 1188 00:41:03,510 --> 00:41:05,369 And the terminal would just be a dumb 1189 00:41:05,370 --> 00:41:07,049 relay. But, you know, this is not the 1190 00:41:07,050 --> 00:41:09,209 case. And as long as we don't admit that 1191 00:41:09,210 --> 00:41:11,369 there are these flaws, we will never we 1192 00:41:11,370 --> 00:41:12,599 will never fix them. 1193 00:41:12,600 --> 00:41:13,859 And there's one more thing that I would 1194 00:41:13,860 --> 00:41:16,559 like to say in the US 1195 00:41:16,560 --> 00:41:17,699 very recently. 1196 00:41:17,700 --> 00:41:19,109 There are you know, they're sort of 1197 00:41:19,110 --> 00:41:20,939 moving after saying for many years now, 1198 00:41:20,940 --> 00:41:22,069 we're never going to move away from the 1199 00:41:22,070 --> 00:41:23,669 magistrate, they're going to move to the 1200 00:41:23,670 --> 00:41:24,689 chip. 1201 00:41:24,690 --> 00:41:26,999 And since for 1202 00:41:27,000 --> 00:41:28,589 whatever technical reasons they're going 1203 00:41:28,590 --> 00:41:30,539 to do chip and signature, they're not 1204 00:41:30,540 --> 00:41:31,529 going to do a chip and pin. 1205 00:41:31,530 --> 00:41:33,659 So they're going to remove all of 1206 00:41:33,660 --> 00:41:36,089 the PIN verification part, which 1207 00:41:36,090 --> 00:41:38,159 in some way it's a good thing, 1208 00:41:38,160 --> 00:41:40,079 because if you have a chip, a signature, 1209 00:41:40,080 --> 00:41:41,369 you're not liable. 1210 00:41:41,370 --> 00:41:44,219 The chip protects the actual transaction, 1211 00:41:44,220 --> 00:41:47,039 which is fairly well protected 1212 00:41:47,040 --> 00:41:50,189 if we ignore the unpredictable number. 1213 00:41:50,190 --> 00:41:52,019 But the transaction, that's the only 1214 00:41:52,020 --> 00:41:54,149 thing that, you know, 1215 00:41:54,150 --> 00:41:55,439 is a security issue there. 1216 00:41:55,440 --> 00:41:56,819 But that can be fixed. 1217 00:41:56,820 --> 00:41:58,799 If you would remove the whole cardholder 1218 00:41:58,800 --> 00:42:00,629 verification phase, then the cardholder 1219 00:42:00,630 --> 00:42:03,209 is not liable. So, incidentally, 1220 00:42:03,210 --> 00:42:05,459 by doing less, they're actually doing 1221 00:42:05,460 --> 00:42:08,059 more from a security standpoint. 1222 00:42:08,060 --> 00:42:10,049 So, you know, things can be done. 1223 00:42:10,050 --> 00:42:11,669 And also in the Netherlands, after one of 1224 00:42:11,670 --> 00:42:13,799 our presentation, they they patched 1225 00:42:13,800 --> 00:42:15,389 every single point of sale device in 1226 00:42:15,390 --> 00:42:18,209 order to refuse plaintiffs verification. 1227 00:42:18,210 --> 00:42:20,009 Of course, they did that only for local 1228 00:42:20,010 --> 00:42:20,999 cards. 1229 00:42:21,000 --> 00:42:23,039 And I don't think that the detection of 1230 00:42:23,040 --> 00:42:25,289 local card uses of data, 1231 00:42:25,290 --> 00:42:26,439 which is actually signed. 1232 00:42:26,440 --> 00:42:28,469 So I think there was a bit of a problem 1233 00:42:28,470 --> 00:42:29,699 there. 1234 00:42:29,700 --> 00:42:32,009 But anyway, so this is how it is. 1235 00:42:32,010 --> 00:42:33,010 So 1236 00:42:34,560 --> 00:42:37,049 I think we have about ten minutes for 1237 00:42:37,050 --> 00:42:39,299 questions. So and before 1238 00:42:39,300 --> 00:42:41,339 that, I also have a little demo here. 1239 00:42:41,340 --> 00:42:42,480 So we show you. 1240 00:42:43,940 --> 00:42:46,039 What happens when 1241 00:42:46,040 --> 00:42:47,749 both attacks are combined? 1242 00:42:47,750 --> 00:42:49,279 So this is how we do them. 1243 00:42:49,280 --> 00:42:51,019 We have an FPGA 1244 00:42:52,070 --> 00:42:54,229 which acts as a shim 1245 00:42:54,230 --> 00:42:56,809 between a real car terminal 1246 00:42:56,810 --> 00:42:58,999 and an actual point-of-sale device. 1247 00:42:59,000 --> 00:43:00,559 So you see them here. 1248 00:43:00,560 --> 00:43:02,389 That's the terminal. 1249 00:43:02,390 --> 00:43:04,519 That's a reader attached to the laptop, 1250 00:43:04,520 --> 00:43:06,259 which is doing many in the middle through 1251 00:43:06,260 --> 00:43:08,479 the FPGA and the FPGA will have 1252 00:43:08,480 --> 00:43:10,639 a smartcard card which goes inside 1253 00:43:10,640 --> 00:43:12,919 the terminal. So all of these attacks, 1254 00:43:12,920 --> 00:43:15,229 we test them with the code 1255 00:43:15,230 --> 00:43:17,289 running on the laptop. 1256 00:43:17,290 --> 00:43:19,189 In this case, we're using one of our own 1257 00:43:19,190 --> 00:43:20,190 cards. 1258 00:43:21,870 --> 00:43:24,059 We plug it in so this car has no 1259 00:43:24,060 --> 00:43:26,749 concept of offline in any civilized. 1260 00:43:28,220 --> 00:43:30,319 So we do two things, we downgraded 1261 00:43:30,320 --> 00:43:31,850 the KVM on the fly. 1262 00:43:34,520 --> 00:43:36,739 So we type the amount. 1263 00:43:40,080 --> 00:43:41,429 And then Apennines been asked, so the 1264 00:43:41,430 --> 00:43:43,199 fact that Apennines been asked right 1265 00:43:43,200 --> 00:43:45,509 there before going offline, before 1266 00:43:45,510 --> 00:43:47,549 going offline means that the first part 1267 00:43:47,550 --> 00:43:50,009 of the attack was effective because 1268 00:43:50,010 --> 00:43:52,109 we convinced the terminal 1269 00:43:52,110 --> 00:43:54,449 to be so kind to us. 1270 00:43:54,450 --> 00:43:56,759 The pin to the car and 1271 00:43:56,760 --> 00:43:58,859 the second attack you will see 1272 00:43:58,860 --> 00:44:01,259 is because we will just type one, 1273 00:44:01,260 --> 00:44:03,510 two, three, four, five. 1274 00:44:05,490 --> 00:44:07,199 And I'll gets accepted and then the 1275 00:44:07,200 --> 00:44:09,389 terminal goes online because we said 1276 00:44:09,390 --> 00:44:11,759 yes and from the logs 1277 00:44:11,760 --> 00:44:14,159 we we see that we can tamper both of them 1278 00:44:14,160 --> 00:44:15,160 and so on. 1279 00:44:16,110 --> 00:44:17,880 So that was a demonstration. 1280 00:44:19,110 --> 00:44:20,110 Thank you. 1281 00:44:26,910 --> 00:44:29,219 And before I answer questions from you, 1282 00:44:29,220 --> 00:44:31,559 I got an e-mail from a journalist today, 1283 00:44:31,560 --> 00:44:32,939 maybe easier, I don't know. 1284 00:44:32,940 --> 00:44:34,769 He asked me three things. 1285 00:44:34,770 --> 00:44:36,869 The German finance industry says that 1286 00:44:36,870 --> 00:44:38,609 the weaknesses of EMV in general would 1287 00:44:38,610 --> 00:44:41,369 not be an issue as point one, 1288 00:44:41,370 --> 00:44:43,499 as the cards would not be given out 1289 00:44:43,500 --> 00:44:45,389 to customers. 1290 00:44:45,390 --> 00:44:46,349 Irrelevant. 1291 00:44:46,350 --> 00:44:48,629 ESTA is always present 1292 00:44:48,630 --> 00:44:50,549 as a backward compatibility into every 1293 00:44:50,550 --> 00:44:52,739 card, and this is a reason why you can 1294 00:44:52,740 --> 00:44:54,809 use your car and go abroad because 1295 00:44:54,810 --> 00:44:56,669 some terminals don't even know what day 1296 00:44:56,670 --> 00:44:59,039 is. So every EMV card by 1297 00:44:59,040 --> 00:45:01,349 De Stander has Asda 1298 00:45:01,350 --> 00:45:03,629 and DDA Effi Asda Visa 1299 00:45:03,630 --> 00:45:06,179 as the the only Asda, but every card 1300 00:45:06,180 --> 00:45:09,149 also supports as the is a capability. 1301 00:45:09,150 --> 00:45:11,399 Second point Fulbeck transactions 1302 00:45:11,400 --> 00:45:12,400 will not be allowed. 1303 00:45:13,800 --> 00:45:16,079 This might be, but it's very hard 1304 00:45:16,080 --> 00:45:18,539 to accept that very hard because 1305 00:45:18,540 --> 00:45:20,669 if I come here as a tourist, I can use 1306 00:45:20,670 --> 00:45:22,199 my Visa card. 1307 00:45:22,200 --> 00:45:24,269 And even if they would 1308 00:45:24,270 --> 00:45:26,369 do something smart like detecting 1309 00:45:26,370 --> 00:45:28,919 your own card, I can always fake 1310 00:45:28,920 --> 00:45:30,809 a foreign car in order to do an 1311 00:45:30,810 --> 00:45:33,239 interception. I could make up 1312 00:45:33,240 --> 00:45:35,369 Mickey Mouse credit card, totally 1313 00:45:35,370 --> 00:45:37,079 fake in order to intercept a pin. 1314 00:45:37,080 --> 00:45:38,609 And you will never know because I can 1315 00:45:38,610 --> 00:45:40,679 always reset everything before 1316 00:45:40,680 --> 00:45:42,809 going online so I can always get 1317 00:45:42,810 --> 00:45:44,729 the pin that you're typing on the 1318 00:45:44,730 --> 00:45:45,989 terminal for. 1319 00:45:45,990 --> 00:45:48,059 There were no German EMV card that were 1320 00:45:48,060 --> 00:45:49,060 breached ever. 1321 00:45:57,230 --> 00:45:59,179 I cannot possibly comment on that without 1322 00:45:59,180 --> 00:46:00,530 reaching a lot of India's. 1323 00:46:12,800 --> 00:46:15,249 So any questions from the audience? 1324 00:46:18,010 --> 00:46:20,139 There, please use the microphones. 1325 00:46:25,880 --> 00:46:27,739 Have you ever played around with the idea 1326 00:46:27,740 --> 00:46:29,629 of faking the entire cast? 1327 00:46:29,630 --> 00:46:31,369 I mean, you skim the number and then you 1328 00:46:31,370 --> 00:46:33,599 just use the smart card to play? 1329 00:46:33,600 --> 00:46:35,689 Yes. So we skim 1330 00:46:35,690 --> 00:46:37,729 the real card so the skimmer can read the 1331 00:46:37,730 --> 00:46:39,469 card independently. 1332 00:46:39,470 --> 00:46:41,749 We fake a card 1333 00:46:41,750 --> 00:46:44,029 or we use another card, a previous card, 1334 00:46:44,030 --> 00:46:45,319 like an SD card. 1335 00:46:45,320 --> 00:46:46,729 We get to the point where we do pin 1336 00:46:46,730 --> 00:46:48,979 verification, we intercept the pin, we 1337 00:46:48,980 --> 00:46:50,149 reset everything. 1338 00:46:50,150 --> 00:46:51,319 And then you would just see that our 1339 00:46:51,320 --> 00:46:53,539 terminal resets or it will send 1340 00:46:53,540 --> 00:46:54,799 you reject transaction. 1341 00:46:54,800 --> 00:46:56,119 And we tried one more time. 1342 00:46:57,170 --> 00:46:58,519 The reason I'm asking is because it's 1343 00:46:58,520 --> 00:47:00,709 relatively easy to steal 1344 00:47:00,710 --> 00:47:03,169 the number itself, whether visually 1345 00:47:03,170 --> 00:47:05,179 or for a magnetic stripes. 1346 00:47:05,180 --> 00:47:07,429 Then if you can create a 1347 00:47:07,430 --> 00:47:09,619 fake chip card that 1348 00:47:09,620 --> 00:47:12,109 presents itself as that number, 1349 00:47:12,110 --> 00:47:13,879 but you actually control the chip, then 1350 00:47:13,880 --> 00:47:15,529 you can accept whatever pin. 1351 00:47:15,530 --> 00:47:17,539 And yes, but this is only for PIN 1352 00:47:17,540 --> 00:47:19,579 interception where you actually go to the 1353 00:47:19,580 --> 00:47:22,099 actual transaction that you cannot fake 1354 00:47:22,100 --> 00:47:23,629 unless it's offline. 1355 00:47:23,630 --> 00:47:25,789 So all of this is for either using 1356 00:47:25,790 --> 00:47:28,279 a stolen card with a no win the pin 1357 00:47:28,280 --> 00:47:31,219 or to intercept the pin on any card 1358 00:47:31,220 --> 00:47:33,799 transactions cannot be faked unless 1359 00:47:33,800 --> 00:47:36,289 you can predict the unpredictable number. 1360 00:47:36,290 --> 00:47:37,549 That's the only condition. 1361 00:47:37,550 --> 00:47:38,750 OK, so this is important. 1362 00:47:39,890 --> 00:47:40,890 Thank you. 1363 00:47:44,270 --> 00:47:45,270 Hi. 1364 00:47:45,950 --> 00:47:48,019 So we'll be talking 1365 00:47:48,020 --> 00:47:49,879 only about those couch readers that you 1366 00:47:49,880 --> 00:47:52,129 find in shops because like in 1367 00:47:52,130 --> 00:47:54,259 ATMs, like as far as I 1368 00:47:54,260 --> 00:47:56,389 know, if you go to an ATM 1369 00:47:56,390 --> 00:47:58,609 and and enter your pin, the 1370 00:47:58,610 --> 00:48:01,669 pin is encrypted in the touchpad. 1371 00:48:01,670 --> 00:48:03,919 Right. This is sent to your 1372 00:48:03,920 --> 00:48:06,259 bank. And this is like not 1373 00:48:06,260 --> 00:48:08,419 that bad. This is actually quite 1374 00:48:08,420 --> 00:48:09,259 OK. Right. 1375 00:48:09,260 --> 00:48:11,059 So there are two things that I have to 1376 00:48:11,060 --> 00:48:12,169 say on this. 1377 00:48:12,170 --> 00:48:14,449 First of all, we never play with ATMs 1378 00:48:14,450 --> 00:48:16,579 because it's extremely difficult, 1379 00:48:16,580 --> 00:48:18,649 even as professional, to get to audit 1380 00:48:18,650 --> 00:48:19,729 them. 1381 00:48:19,730 --> 00:48:22,159 But in ATMs is, as you say, 1382 00:48:22,160 --> 00:48:24,409 they should all go online. 1383 00:48:24,410 --> 00:48:26,089 I can tell you from personal experience 1384 00:48:26,090 --> 00:48:27,949 that at least initially, not all of them 1385 00:48:27,950 --> 00:48:30,199 go online. And it's very easy to 1386 00:48:30,200 --> 00:48:32,299 understand that if you 1387 00:48:32,300 --> 00:48:34,399 type the wrong pin, sometimes 1388 00:48:34,400 --> 00:48:36,829 it gets rejected right away, 1389 00:48:36,830 --> 00:48:38,719 like it takes even a millisecond. 1390 00:48:38,720 --> 00:48:41,059 And you can also check by reading 1391 00:48:41,060 --> 00:48:43,129 back the logs on your card 1392 00:48:43,130 --> 00:48:45,289 what was actually use as a 1393 00:48:45,290 --> 00:48:46,789 PIN verification mechanism. 1394 00:48:46,790 --> 00:48:48,889 And at least in certain ATMs, 1395 00:48:48,890 --> 00:48:51,679 I think this was in the migration phase. 1396 00:48:51,680 --> 00:48:54,709 They were not checking the pin online, 1397 00:48:54,710 --> 00:48:56,809 but I cannot say what is it 1398 00:48:56,810 --> 00:48:57,919 today. 1399 00:48:57,920 --> 00:49:00,379 What I would say is that 1400 00:49:00,380 --> 00:49:02,509 I worry much more about point 1401 00:49:02,510 --> 00:49:04,189 of sale devices when it comes to an 1402 00:49:04,190 --> 00:49:06,379 interception, because there are so many 1403 00:49:06,380 --> 00:49:08,659 of them and there are so much more 1404 00:49:08,660 --> 00:49:09,639 insecure. 1405 00:49:09,640 --> 00:49:11,749 You know, you can gain I can gain access 1406 00:49:11,750 --> 00:49:13,939 to a point of sale device much more 1407 00:49:13,940 --> 00:49:15,799 easily than doing it on ATMs. 1408 00:49:15,800 --> 00:49:17,689 I don't have cameras pointed at me. 1409 00:49:17,690 --> 00:49:19,189 I'm not outside a bank. 1410 00:49:19,190 --> 00:49:20,269 You know, I can collude with the 1411 00:49:20,270 --> 00:49:22,249 merchant. There are so many ways and from 1412 00:49:22,250 --> 00:49:24,769 the liability framework perspective, 1413 00:49:24,770 --> 00:49:26,899 all I care is about one point of 1414 00:49:26,900 --> 00:49:28,279 sale, one to the. 1415 00:49:28,280 --> 00:49:29,869 This might happen, right? 1416 00:49:30,950 --> 00:49:32,449 Yeah, I agree 100 percent. 1417 00:49:32,450 --> 00:49:34,909 I was just thinking like what to tell my 1418 00:49:34,910 --> 00:49:37,099 can I tell my grandmother that, 1419 00:49:37,100 --> 00:49:39,179 OK, if you use an ATM, you're 1420 00:49:39,180 --> 00:49:41,449 secure because your pin gets encrypted 1421 00:49:41,450 --> 00:49:43,369 on the touchpad no matter where you are 1422 00:49:43,370 --> 00:49:46,249 in Italy. US, Russia will in principle. 1423 00:49:46,250 --> 00:49:48,349 Yes, but in our 1424 00:49:48,350 --> 00:49:50,419 line of pressure I 1425 00:49:50,420 --> 00:49:51,559 can I'll tell you hundred percent for 1426 00:49:51,560 --> 00:49:53,839 sure. I don't know because 1427 00:49:53,840 --> 00:49:54,799 we never tested them. 1428 00:49:54,800 --> 00:49:56,359 But in theory, that's what should have 1429 00:49:56,360 --> 00:49:58,609 happened. Yes, you are much 1430 00:49:58,610 --> 00:50:00,829 you have much better chances of being 1431 00:50:00,830 --> 00:50:03,109 safe from EMV protocol, 1432 00:50:03,110 --> 00:50:05,419 interception on ATMs, but 1433 00:50:05,420 --> 00:50:07,579 you're much less safe from actually 1434 00:50:07,580 --> 00:50:10,039 physical interception because the 1435 00:50:10,040 --> 00:50:12,079 ATM skimmers that I've shown there are 1436 00:50:12,080 --> 00:50:13,009 still there. 1437 00:50:13,010 --> 00:50:15,079 So, you know, at the end of the day, 1438 00:50:15,080 --> 00:50:16,519 you can always say that there's a hidden 1439 00:50:16,520 --> 00:50:18,409 camera and the whole liability falls 1440 00:50:18,410 --> 00:50:20,419 apart. These are just, you know, more 1441 00:50:20,420 --> 00:50:22,399 cases to say that the pin is not really a 1442 00:50:22,400 --> 00:50:24,289 good way to make you liable. 1443 00:50:26,690 --> 00:50:27,690 Thank you. 1444 00:50:28,050 --> 00:50:30,149 I've got a question regarding 1445 00:50:30,150 --> 00:50:32,909 online payments regarding even 1446 00:50:32,910 --> 00:50:34,979 in some countries I know of Holland, 1447 00:50:34,980 --> 00:50:37,139 they ask for the date of birth and then 1448 00:50:37,140 --> 00:50:38,399 a password. 1449 00:50:38,400 --> 00:50:40,169 You know anything about the security 1450 00:50:40,170 --> 00:50:41,880 behind this and liabilities? 1451 00:50:44,520 --> 00:50:46,799 So a friend of mine colostrum, Lori, 1452 00:50:46,800 --> 00:50:48,989 from a church collapse, very smart 1453 00:50:48,990 --> 00:50:50,549 guy does all the RFID stuff. 1454 00:50:50,550 --> 00:50:51,550 You should check his work 1455 00:50:53,160 --> 00:50:55,319 once said a card with, you know, 1456 00:50:55,320 --> 00:50:57,419 secure code by Visa and MasterCard where 1457 00:50:57,420 --> 00:50:58,409 you go online. 1458 00:50:58,410 --> 00:50:59,969 And in order to provision it, you know, 1459 00:50:59,970 --> 00:51:01,109 you have a password. 1460 00:51:01,110 --> 00:51:02,579 And then if you the password doesn't 1461 00:51:02,580 --> 00:51:05,009 work, it will ask you a question like the 1462 00:51:05,010 --> 00:51:07,349 name of birth, the birth date and so on. 1463 00:51:07,350 --> 00:51:09,509 So his daughter wants to buy 1464 00:51:09,510 --> 00:51:11,129 something with his credit card. 1465 00:51:11,130 --> 00:51:12,689 And Adam gave the credit card to the 1466 00:51:12,690 --> 00:51:14,009 daughter and says, let's see if you can 1467 00:51:14,010 --> 00:51:16,349 hack it. After ten minutes, she came back 1468 00:51:16,350 --> 00:51:18,659 and she totally reset, of course, 1469 00:51:18,660 --> 00:51:20,849 the all secure code thing 1470 00:51:20,850 --> 00:51:22,769 with data that she wasn't supposed to 1471 00:51:22,770 --> 00:51:25,199 know because there was a secret question 1472 00:51:25,200 --> 00:51:26,939 or a secret answer along with a birthday 1473 00:51:26,940 --> 00:51:29,609 and so on. So, you know, 1474 00:51:29,610 --> 00:51:31,979 security and 1475 00:51:31,980 --> 00:51:34,289 birth date and other 1476 00:51:34,290 --> 00:51:36,179 kind of data, they don't really match 1477 00:51:36,180 --> 00:51:38,519 together. You know, we're struggling 1478 00:51:38,520 --> 00:51:40,859 here to get proper SSL encryption 1479 00:51:40,860 --> 00:51:42,929 from browser to websites, you 1480 00:51:42,930 --> 00:51:45,449 know? Well, you know, it's 1481 00:51:45,450 --> 00:51:47,519 just, you know, there 1482 00:51:47,520 --> 00:51:48,749 are meaningless at the end. 1483 00:51:48,750 --> 00:51:50,279 There are not they might have been 1484 00:51:50,280 --> 00:51:52,259 something that I would have vaguely 1485 00:51:52,260 --> 00:51:54,479 respected 10 years ago, 1486 00:51:54,480 --> 00:51:55,829 you know, 20 years ago. 1487 00:51:55,830 --> 00:51:57,689 But nowadays, you know. 1488 00:51:57,690 --> 00:51:58,739 No, just no. 1489 00:51:59,880 --> 00:52:01,709 One of that question, please. 1490 00:52:01,710 --> 00:52:03,299 I have a bunch of questions from the 1491 00:52:03,300 --> 00:52:04,510 Internet. First of all, on 1492 00:52:05,520 --> 00:52:07,769 all the cost of proper security, actually 1493 00:52:07,770 --> 00:52:09,749 larger than the current cost of the 1494 00:52:09,750 --> 00:52:10,750 insecurity. 1495 00:52:11,490 --> 00:52:13,199 So this is the classic argument from the 1496 00:52:13,200 --> 00:52:14,849 bank. They say, OK, I have like zero 1497 00:52:14,850 --> 00:52:16,289 point zero zero one percent. 1498 00:52:16,290 --> 00:52:17,290 So why would I care 1499 00:52:18,390 --> 00:52:20,609 if the customer if the Khairallah gets 1500 00:52:20,610 --> 00:52:21,929 the money back? 1501 00:52:21,930 --> 00:52:24,029 Yes. I mean, you can argue that the time 1502 00:52:24,030 --> 00:52:26,159 spent in getting your 1503 00:52:26,160 --> 00:52:28,349 money back is, of course, as a cost. 1504 00:52:28,350 --> 00:52:30,089 But in principle, you could say, yes, of 1505 00:52:30,090 --> 00:52:31,859 course. But this is the issue here. 1506 00:52:31,860 --> 00:52:34,169 You know, they don't get their money back 1507 00:52:34,170 --> 00:52:36,479 if they don't fight the claim 1508 00:52:36,480 --> 00:52:38,879 properly. So when you see the statistics 1509 00:52:38,880 --> 00:52:41,039 about fraud, they don't put into 1510 00:52:41,040 --> 00:52:43,259 account these cases where 1511 00:52:43,260 --> 00:52:45,119 liability shifted to the customer. 1512 00:52:45,120 --> 00:52:46,589 And that's my old point there. 1513 00:52:46,590 --> 00:52:48,569 Even if you have one person which loses 1514 00:52:48,570 --> 00:52:50,759 two thousand euros that they didn't 1515 00:52:50,760 --> 00:52:53,339 lose because they were negligent, 1516 00:52:53,340 --> 00:52:54,959 whatever that means, you know, they 1517 00:52:54,960 --> 00:52:56,369 shouldn't lose this kind of money. 1518 00:52:56,370 --> 00:52:57,989 So I don't care if that zero point zero 1519 00:52:57,990 --> 00:53:00,089 zero zero zero zero zero one percent 1520 00:53:00,090 --> 00:53:02,519 of the total profit issue didn't happen. 1521 00:53:02,520 --> 00:53:04,739 So we handle about a dozen cases. 1522 00:53:04,740 --> 00:53:06,719 And that's, you know, that's more than 1523 00:53:06,720 --> 00:53:08,999 enough. And we know that if we 1524 00:53:09,000 --> 00:53:11,109 which are very small company, we handle 1525 00:53:11,110 --> 00:53:13,229 a dozen cases. Maybe there are so many 1526 00:53:13,230 --> 00:53:14,699 more and maybe there are so many more 1527 00:53:14,700 --> 00:53:15,899 people that they didn't get their money 1528 00:53:15,900 --> 00:53:16,709 back. 1529 00:53:16,710 --> 00:53:19,379 So, yeah, that's that argument 1530 00:53:19,380 --> 00:53:21,929 is not relevant 1531 00:53:21,930 --> 00:53:23,579 to the kind of discussion that I want to 1532 00:53:23,580 --> 00:53:24,580 have here. 1533 00:53:25,310 --> 00:53:27,479 OK, three last questions, and 1534 00:53:27,480 --> 00:53:29,659 we will be there for more questions for 1535 00:53:29,660 --> 00:53:30,409 you, so please. 1536 00:53:30,410 --> 00:53:32,569 Yes, approach me any time. 1537 00:53:32,570 --> 00:53:34,339 OK, three more question number four, 1538 00:53:34,340 --> 00:53:35,569 starting 14 1539 00:53:36,890 --> 00:53:39,289 on just one quick comment. 1540 00:53:39,290 --> 00:53:41,389 The CPV on the Max Tribe isn't the same 1541 00:53:41,390 --> 00:53:43,249 as the CVB on the back of the car. 1542 00:53:43,250 --> 00:53:45,039 Those are two different values, correct? 1543 00:53:45,040 --> 00:53:46,099 Those are two different ones. 1544 00:53:46,100 --> 00:53:47,539 Yes, at the beginning. 1545 00:53:47,540 --> 00:53:49,729 But in a similar vein, to to what's 1546 00:53:49,730 --> 00:53:51,889 to the to the price or 1547 00:53:51,890 --> 00:53:53,869 the cost of the attack to what's coming 1548 00:53:53,870 --> 00:53:56,509 out. You said you don't necessarily 1549 00:53:56,510 --> 00:53:59,269 have to have a wedge and a stolen card 1550 00:53:59,270 --> 00:54:00,799 if you're doing downgrade attacks, for 1551 00:54:00,800 --> 00:54:03,079 example, because you could maybe 1552 00:54:03,080 --> 00:54:04,759 have a card that communicates to the 1553 00:54:04,760 --> 00:54:07,279 stolen card via Bluetooth and 1554 00:54:07,280 --> 00:54:08,839 yes, a man in the middle. 1555 00:54:08,840 --> 00:54:11,059 But that would make an attack at a post 1556 00:54:11,060 --> 00:54:12,629 pretty expensive for the attacker. 1557 00:54:12,630 --> 00:54:14,989 So it seems that that's 1558 00:54:14,990 --> 00:54:15,990 somewhat 1559 00:54:17,240 --> 00:54:19,499 unlikely attack scenario. 1560 00:54:19,500 --> 00:54:22,159 If I stole cards, I think there's more. 1561 00:54:22,160 --> 00:54:23,869 Is this a question mark? 1562 00:54:23,870 --> 00:54:25,969 Yeah. Is I mean, 1563 00:54:25,970 --> 00:54:28,169 that whole cost of attack things to 1564 00:54:28,170 --> 00:54:29,429 the attacker as well. 1565 00:54:29,430 --> 00:54:30,739 So there are two aspects here. 1566 00:54:30,740 --> 00:54:32,539 So the first aspect is that from a 1567 00:54:32,540 --> 00:54:34,639 liability standpoint, we don't 1568 00:54:34,640 --> 00:54:36,289 care about how likely it is. 1569 00:54:36,290 --> 00:54:37,669 As long as it can happen. 1570 00:54:37,670 --> 00:54:40,039 Then from a legal standpoint, then, 1571 00:54:40,040 --> 00:54:42,019 you know, you are not negligent if this 1572 00:54:42,020 --> 00:54:43,429 can happen. 1573 00:54:43,430 --> 00:54:44,540 The second thing is, 1574 00:54:46,220 --> 00:54:48,319 if I would be a criminal, this is what 1575 00:54:48,320 --> 00:54:50,449 I would do. I would skim every single 1576 00:54:50,450 --> 00:54:52,429 point of sales that I can in a way which 1577 00:54:52,430 --> 00:54:53,430 is covert. 1578 00:54:54,460 --> 00:54:56,979 And then as soon as one car gets stolen, 1579 00:54:56,980 --> 00:54:58,689 there's a very nice database where all 1580 00:54:58,690 --> 00:55:00,939 you stole that car, have the pin 1581 00:55:00,940 --> 00:55:02,109 for that. 1582 00:55:02,110 --> 00:55:04,359 So this is something that you can do now. 1583 00:55:04,360 --> 00:55:06,459 How likely is that happening now? 1584 00:55:06,460 --> 00:55:07,779 I don't know. I don't think it's very 1585 00:55:07,780 --> 00:55:10,299 likely. How likely is it 1586 00:55:10,300 --> 00:55:12,369 that maybe five, 10 years from now 1587 00:55:12,370 --> 00:55:14,499 when the max drive goes away, much 1588 00:55:14,500 --> 00:55:15,429 more likely. 1589 00:55:15,430 --> 00:55:18,189 So we need to address this now. 1590 00:55:18,190 --> 00:55:20,349 And having an industry which is pushing 1591 00:55:20,350 --> 00:55:22,119 this technology is the holy grail of 1592 00:55:22,120 --> 00:55:24,099 security doesn't help. 1593 00:55:24,100 --> 00:55:25,749 So this is my old argument here. 1594 00:55:25,750 --> 00:55:27,310 So you can see both sides 1595 00:55:29,160 --> 00:55:30,309 to please. 1596 00:55:30,310 --> 00:55:32,589 Can you comment on NFC 1597 00:55:32,590 --> 00:55:33,590 payments? 1598 00:55:34,900 --> 00:55:37,479 Yes. So NFC payments, 1599 00:55:37,480 --> 00:55:38,989 it's it's a complicated matter. 1600 00:55:38,990 --> 00:55:40,839 There are many ways of doing them. 1601 00:55:40,840 --> 00:55:43,089 Some of them, they expose very 1602 00:55:43,090 --> 00:55:44,499 similar vulnerabilities of what you see 1603 00:55:44,500 --> 00:55:46,809 here, because it's actually EMV 1604 00:55:46,810 --> 00:55:48,369 going wireless. 1605 00:55:48,370 --> 00:55:50,559 So they sometimes 1606 00:55:50,560 --> 00:55:52,359 they have this classic downgrade 1607 00:55:52,360 --> 00:55:53,259 mechanism. 1608 00:55:53,260 --> 00:55:55,419 You can harvest the 1609 00:55:55,420 --> 00:55:57,159 KVI, the dynamic. 1610 00:55:57,160 --> 00:55:59,259 They have a dynamic c.v you can harvest 1611 00:55:59,260 --> 00:56:01,509 and then replace. So they have their own 1612 00:56:01,510 --> 00:56:03,449 set of issues different. 1613 00:56:03,450 --> 00:56:05,589 They will require another one hour talk 1614 00:56:05,590 --> 00:56:06,639 to address them. 1615 00:56:06,640 --> 00:56:09,129 But let us say that there are similar 1616 00:56:09,130 --> 00:56:10,689 issues there as well. 1617 00:56:10,690 --> 00:56:12,399 And it's not something that was well 1618 00:56:12,400 --> 00:56:14,089 thought of from the beginning. 1619 00:56:14,090 --> 00:56:16,179 OK, you have a smart card, the 1620 00:56:16,180 --> 00:56:18,549 actual signing of the transaction, 1621 00:56:18,550 --> 00:56:20,679 that is, except for the random number, 1622 00:56:20,680 --> 00:56:21,819 it is done correctly. 1623 00:56:21,820 --> 00:56:24,099 If they would just stick to just that 1624 00:56:24,100 --> 00:56:26,289 phase. And the random number comes 1625 00:56:26,290 --> 00:56:28,479 from the backend that would have been so 1626 00:56:28,480 --> 00:56:30,699 much simpler, minimal design 1627 00:56:30,700 --> 00:56:33,069 and to an easy I want to pay this 1628 00:56:33,070 --> 00:56:33,999 done. 1629 00:56:34,000 --> 00:56:36,189 And the fact that they're not following 1630 00:56:36,190 --> 00:56:38,289 this also reflects on 1631 00:56:38,290 --> 00:56:40,719 NFC in a way. 1632 00:56:40,720 --> 00:56:42,669 Another offside question, the last one. 1633 00:56:42,670 --> 00:56:44,589 Thank you. What precautions does your 1634 00:56:44,590 --> 00:56:46,389 team take to prevent being legally 1635 00:56:46,390 --> 00:56:48,549 stomped on by the bank as you probe 1636 00:56:48,550 --> 00:56:49,550 their weaknesses? 1637 00:56:50,470 --> 00:56:52,689 So, first of all, in a many of 1638 00:56:52,690 --> 00:56:54,999 our consulting, we were actually paid 1639 00:56:55,000 --> 00:56:56,920 by the banks to do this, so. 1640 00:56:58,500 --> 00:57:00,659 In our experience, most banks, 1641 00:57:00,660 --> 00:57:02,339 they don't consider these to be serious 1642 00:57:02,340 --> 00:57:03,689 issues, but not all of them. 1643 00:57:03,690 --> 00:57:06,179 There are a few of them which are very 1644 00:57:06,180 --> 00:57:08,399 exemplary in the way they 1645 00:57:08,400 --> 00:57:10,799 consulted us into exposing excessive 1646 00:57:10,800 --> 00:57:12,419 techniques. And they have security things 1647 00:57:12,420 --> 00:57:13,529 which they care. 1648 00:57:13,530 --> 00:57:15,659 They are aware of all of these issues and 1649 00:57:15,660 --> 00:57:17,129 they know that it's a political fight. 1650 00:57:17,130 --> 00:57:18,869 So I don't want to blame the entire 1651 00:57:18,870 --> 00:57:19,829 industry. 1652 00:57:19,830 --> 00:57:21,689 Second of all, from a legal standpoint, I 1653 00:57:21,690 --> 00:57:23,789 mean, we 1654 00:57:23,790 --> 00:57:25,919 have the Cambridge Group which preceded 1655 00:57:25,920 --> 00:57:27,359 us. 1656 00:57:27,360 --> 00:57:28,739 We have done our research. 1657 00:57:28,740 --> 00:57:29,999 All of these you can read through this 1658 00:57:30,000 --> 00:57:32,879 done there. I mean, you know, 1659 00:57:32,880 --> 00:57:35,039 in our job, we it's a double edged 1660 00:57:35,040 --> 00:57:37,079 sword all the time, everything that we 1661 00:57:37,080 --> 00:57:39,119 do. Ninety nine percent of the docs here, 1662 00:57:39,120 --> 00:57:41,039 you do something which you think is for 1663 00:57:41,040 --> 00:57:42,689 the greater good, but it can also be used 1664 00:57:42,690 --> 00:57:44,819 maliciously. This is the thing we're not 1665 00:57:44,820 --> 00:57:47,369 if I think of something, 1666 00:57:47,370 --> 00:57:48,509 I think of an attack. 1667 00:57:48,510 --> 00:57:50,399 There's no reason why you don't have 20 1668 00:57:50,400 --> 00:57:52,589 other people's thinking of that before 1669 00:57:52,590 --> 00:57:54,209 me for criminal activities. 1670 00:57:54,210 --> 00:57:56,819 So there's no reason to keep this 1671 00:57:56,820 --> 00:57:59,009 quiet. You know, that's what 1672 00:57:59,010 --> 00:57:59,909 our industry does. 1673 00:57:59,910 --> 00:58:01,769 And I think most of the audience here 1674 00:58:01,770 --> 00:58:02,669 agrees to that. 1675 00:58:02,670 --> 00:58:04,919 And it's a well known, accepted fact 1676 00:58:04,920 --> 00:58:06,809 of the industry. So so far, we didn't 1677 00:58:06,810 --> 00:58:07,860 have any problems at all. 1678 00:58:09,560 --> 00:58:11,809 OK, so that's it, we have to finish 1679 00:58:11,810 --> 00:58:12,810 now. 1680 00:58:13,250 --> 00:58:14,779 Thank you very much. 1681 00:58:14,780 --> 00:58:16,069 I hope you enjoyed it. 1682 00:58:16,070 --> 00:58:17,300 And if you want tomorrow, 1683 00:58:18,740 --> 00:58:19,740 come see this.