1 00:00:00,000 --> 00:00:09,624 *preroll music* 2 00:00:09,624 --> 00:00:11,789 Herald: So, welcome everybody, 3 00:00:11,789 --> 00:00:14,429 the next talk is under the topic 4 00:00:14,429 --> 00:00:18,550 "shoplifting", uh, "shopshifting", sorry. *laughter* 5 00:00:18,550 --> 00:00:20,480 Shoplifting is something completely different, 6 00:00:20,480 --> 00:00:23,279 it has nothing to do with shopshifting, 7 00:00:23,279 --> 00:00:25,250 the outcome is the same. 8 00:00:25,250 --> 00:00:26,779 *laughter* 9 00:00:26,779 --> 00:00:29,410 And I present to you Karsten Nohl, 10 00:00:29,410 --> 00:00:33,330 Fabian Bräunlein, and Dexter from Berlin 11 00:00:33,330 --> 00:00:35,570 Some of you may have already seen 12 00:00:35,570 --> 00:00:38,230 the one only other face here, 13 00:00:38,230 --> 00:00:40,550 and you may have heard of things like 14 00:00:40,550 --> 00:00:44,140 the Mifare RFID problems that we had, 15 00:00:44,140 --> 00:00:48,120 the gsm sim card hacks, and things like BadUSB 16 00:00:48,120 --> 00:00:50,120 and these people and people around them 17 00:00:50,120 --> 00:00:52,510 are all responsible for that. 18 00:00:52,510 --> 00:00:55,520 So, give them a warm applause, and... 19 00:00:55,520 --> 00:01:04,630 *applause* stage is yours! 20 00:01:04,630 --> 00:01:06,740 Nohl: Thank you very much. 21 00:01:06,740 --> 00:01:09,580 It's great to be back, looking at yet another technology 22 00:01:09,580 --> 00:01:13,540 and searching for security vulnerabilities. 23 00:01:13,540 --> 00:01:15,750 We focus our research on technologies 24 00:01:15,750 --> 00:01:19,300 that most of us use on a daily basis, 25 00:01:19,300 --> 00:01:21,780 that are typically outdated, 26 00:01:21,780 --> 00:01:24,970 very widely deployed, and insecure. 27 00:01:24,970 --> 00:01:26,680 Took us many years to finally come around 28 00:01:26,680 --> 00:01:28,650 to look at payment protocols, 29 00:01:28,650 --> 00:01:31,810 which we'll be discussing today. 30 00:01:31,810 --> 00:01:33,640 In part, it took so long because 31 00:01:33,640 --> 00:01:37,220 we just didn't think we would find anything. 32 00:01:37,220 --> 00:01:41,350 After all, some of the best people in our industry work at banks, 33 00:01:41,350 --> 00:01:45,600 and banks have among the most developed risk management. 34 00:01:45,600 --> 00:01:49,390 So, at least in my experience, 35 00:01:49,390 --> 00:01:53,420 banks are good at reacting to security evolution. 36 00:01:53,420 --> 00:01:56,430 That's what I thought up until maybe the middle of this year, 37 00:01:56,430 --> 00:01:58,020 when we started this research 38 00:01:58,020 --> 00:02:01,909 and we're here now today to take this preconception away 39 00:02:01,909 --> 00:02:04,270 from whoever may still be 40 00:02:04,270 --> 00:02:05,850 suffering from this illusion that 41 00:02:05,850 --> 00:02:09,389 banks actually do keep their systems very secure, 42 00:02:09,389 --> 00:02:11,090 at least we found in two cases, 43 00:02:11,090 --> 00:02:14,209 two very widely deployed protocols, 44 00:02:14,209 --> 00:02:17,579 that there's gaping holes and have been for a couple of years. 45 00:02:17,579 --> 00:02:20,739 Both of these protocols are involved in payment, 46 00:02:20,739 --> 00:02:22,159 that is if you go into a store 47 00:02:22,159 --> 00:02:23,659 and you pay with a card, 48 00:02:23,659 --> 00:02:25,260 those protocols are invoked, 49 00:02:25,260 --> 00:02:26,659 at least in Germany, 50 00:02:26,659 --> 00:02:30,749 and protocols are called ZVT and Poseidon. 51 00:02:30,749 --> 00:02:33,430 They're used for very different purposes, 52 00:02:33,430 --> 00:02:36,930 but they both terminate at a payment terminal. 53 00:02:36,930 --> 00:02:39,480 The one protocol ZVT is spoken between 54 00:02:39,480 --> 00:02:42,049 a cashier station and this payment terminal, 55 00:02:42,049 --> 00:02:44,450 so somebody would scan some items 56 00:02:44,450 --> 00:02:47,459 or type in some amount into this cashier station, 57 00:02:47,459 --> 00:02:49,529 and then say, "now please pay", 58 00:02:49,529 --> 00:02:52,499 and a command is sent to the payment terminal, 59 00:02:52,499 --> 00:02:53,919 which then requests a card, 60 00:02:53,919 --> 00:02:55,959 and perhaps a pin number, 61 00:02:55,959 --> 00:02:58,459 for most transactions in Germany, 62 00:02:58,459 --> 00:03:01,209 and then in turns invokes another protocol 63 00:03:01,209 --> 00:03:04,609 that this payment terminal speaks with a payment processor. 64 00:03:04,609 --> 00:03:06,989 That's a service provider that connects 65 00:03:06,989 --> 00:03:09,359 these terminals to banks, 66 00:03:09,359 --> 00:03:13,579 and basically facilitates the actual payment. 67 00:03:13,579 --> 00:03:15,519 And then the payment processor or the bank, 68 00:03:15,519 --> 00:03:18,549 they validate the account details and so forth, 69 00:03:18,549 --> 00:03:19,680 they send a confirmation, 70 00:03:19,680 --> 00:03:22,359 and that confirmation again over ZVT 71 00:03:22,359 --> 00:03:25,560 is sent back to the cashier station. 72 00:03:25,560 --> 00:03:29,019 That is, in a nutshell, how a payment transaction works. 73 00:03:29,019 --> 00:03:32,069 So it's based on two protocols, 74 00:03:32,069 --> 00:03:35,129 both of them fairly old, 75 00:03:35,129 --> 00:03:39,059 and probably by virtue of being so old, 76 00:03:39,059 --> 00:03:40,909 very widely deployed. 77 00:03:40,909 --> 00:03:43,249 In Germany, you will hardly find anything 78 00:03:43,249 --> 00:03:46,489 other than these two protocols being used. 79 00:03:46,489 --> 00:03:47,949 We'll look at an international angle 80 00:03:47,949 --> 00:03:50,329 towards the end of the talk, 81 00:03:50,329 --> 00:03:51,519 just a short summary, 82 00:03:51,519 --> 00:03:53,529 most of these problems will probably exist 83 00:03:53,529 --> 00:03:57,599 in most other countries as well. 84 00:03:57,599 --> 00:04:01,230 So let's in turn look at ZVT and then Poseidon 85 00:04:01,230 --> 00:04:04,139 to identify their security issues. 86 00:04:04,139 --> 00:04:05,299 Starting with ZVT, 87 00:04:05,299 --> 00:04:07,079 this is again the protocol that's spoken 88 00:04:07,079 --> 00:04:11,309 in the shop, between a cashier station and a terminal, 89 00:04:11,309 --> 00:04:14,760 but in almost all cases, over a network connection. 90 00:04:14,760 --> 00:04:17,048 Very old systems would use a serial cable, 91 00:04:17,048 --> 00:04:19,690 but today a network is used. 92 00:04:19,690 --> 00:04:22,300 So assuming that a fraudster 93 00:04:22,300 --> 00:04:24,819 somehow can get access to a local network, 94 00:04:24,819 --> 00:04:26,509 by plugging into some open ports, 95 00:04:26,509 --> 00:04:28,810 or by even being a customer at your hotel 96 00:04:28,810 --> 00:04:33,830 and just being connected to the same wifi as your cashier system, 97 00:04:33,830 --> 00:04:35,930 what can this attacker do? 98 00:04:35,930 --> 00:04:37,860 Let's start with something simple 99 00:04:37,860 --> 00:04:42,699 that doesn't even really require any hacking. 100 00:04:42,699 --> 00:04:44,479 In this case, somebody wants to steal 101 00:04:44,479 --> 00:04:47,870 the magnetic stripe details of the card. 102 00:04:47,870 --> 00:04:48,870 So the way that it should work 103 00:04:48,870 --> 00:04:51,729 is that the cashier station sends a command 104 00:04:51,729 --> 00:04:52,599 to the payment terminal, 105 00:04:52,599 --> 00:04:53,879 and then gets a confirmation back 106 00:04:53,879 --> 00:04:55,960 after some processing. 107 00:04:55,960 --> 00:04:57,710 Now what the attacker does in this case 108 00:04:57,710 --> 00:05:01,069 is get in between those two, 109 00:05:01,069 --> 00:05:02,780 in their connection. 110 00:05:02,780 --> 00:05:05,400 Through, just traditional ARP spoofing. 111 00:05:05,400 --> 00:05:07,259 So, you proxy the connection 112 00:05:07,259 --> 00:05:11,439 between the cashier station and the payment terminal, 113 00:05:11,439 --> 00:05:13,539 sitting in the local network again. 114 00:05:13,539 --> 00:05:16,129 We'll look at Internet-wide attacks 115 00:05:16,129 --> 00:05:17,539 in a few minutes, but for now 116 00:05:17,539 --> 00:05:19,610 we're talking about inside the shop, 117 00:05:19,610 --> 00:05:22,639 or in wifi range of that shop. 118 00:05:22,639 --> 00:05:23,879 So you ARP spoof 119 00:05:23,879 --> 00:05:28,180 and you receive that authorisation request 120 00:05:28,180 --> 00:05:29,960 that's supposed to be sent to the payment terminal. 121 00:05:29,960 --> 00:05:31,840 What the cashier station basically says, 122 00:05:31,840 --> 00:05:32,919 "There's a customer here, 123 00:05:32,919 --> 00:05:34,780 the customer wants to pay something, 124 00:05:34,780 --> 00:05:36,509 please authorise the payment." 125 00:05:36,509 --> 00:05:39,539 Right? We take that command 126 00:05:39,539 --> 00:05:40,680 and do not forward it, 127 00:05:40,680 --> 00:05:42,229 but instead send another command, 128 00:05:42,229 --> 00:05:45,550 which basically says, "read a card". 129 00:05:45,550 --> 00:05:47,949 So the terminal will then display 130 00:05:47,949 --> 00:05:49,159 what the customer expects, 131 00:05:49,159 --> 00:05:50,569 "please insert a card", 132 00:05:50,569 --> 00:05:54,680 customer does so, and the magnetic stripe information is read, 133 00:05:54,680 --> 00:05:57,900 and sent back over the network to the attacker. 134 00:05:57,900 --> 00:06:00,599 No transaction has been done yet. 135 00:06:00,599 --> 00:06:05,340 Immediately following these magnetic stripe details, 136 00:06:05,340 --> 00:06:06,280 the attacker would then send 137 00:06:06,280 --> 00:06:09,769 an actual authorisation request message 138 00:06:09,769 --> 00:06:12,750 supplying the magnetic stripe info. 139 00:06:12,750 --> 00:06:15,069 So, instead of asking for a card, 140 00:06:15,069 --> 00:06:16,949 the payment terminal just takes this magstripe now, 141 00:06:16,949 --> 00:06:20,240 and goes through the transaction. 142 00:06:20,240 --> 00:06:21,270 So two things happen. 143 00:06:21,270 --> 00:06:24,900 First, the attacker did receive a copy of the magstripe, 144 00:06:24,900 --> 00:06:26,780 second, the actual transaction, 145 00:06:26,780 --> 00:06:28,960 the intended transaction did go through. 146 00:06:28,960 --> 00:06:31,120 So neither the customer nor the merchant 147 00:06:31,120 --> 00:06:32,780 sees any different. 148 00:06:32,780 --> 00:06:35,900 But the attacker does have a copy of the magstripe now. 149 00:06:35,900 --> 00:06:38,030 And then, countries where magstripe is enough, 150 00:06:38,030 --> 00:06:40,879 let's say US, prior to chip-and-pin, 151 00:06:40,879 --> 00:06:44,469 this is enough to completely clone the card. 152 00:06:44,469 --> 00:06:46,930 Fortunately, most other countries 153 00:06:46,930 --> 00:06:49,099 do require pin numbers, 154 00:06:49,099 --> 00:06:52,699 making this attack ineffective. 155 00:06:52,699 --> 00:06:55,360 But perhaps motivating a slightly improved attack. 156 00:06:55,360 --> 00:06:57,979 So, let's say the fraudster wanted 157 00:06:57,979 --> 00:07:00,069 to also steal the pin number remotely. 158 00:07:00,069 --> 00:07:02,139 Right? Magstripe and pin number, 159 00:07:02,139 --> 00:07:06,979 that's really all you need to pay in Germany, say. 160 00:07:06,979 --> 00:07:09,930 So the way pin transactions are supposed to work, 161 00:07:09,930 --> 00:07:12,229 they are much more secure, 162 00:07:12,229 --> 00:07:14,099 well, they're secured at all, 163 00:07:14,099 --> 00:07:16,050 versus magstripe, which isn't secure, 164 00:07:16,050 --> 00:07:17,520 so the top part of this slide 165 00:07:17,520 --> 00:07:23,690 shows how a pin transaction is supposed to work. 166 00:07:23,690 --> 00:07:28,680 Again, over ZVT, the cashier desk 167 00:07:28,680 --> 00:07:32,240 or whatever's speaking to the terminal in the store, 168 00:07:32,240 --> 00:07:34,020 sends an authorisation request 169 00:07:34,020 --> 00:07:35,469 this time specifically saying 170 00:07:35,469 --> 00:07:37,560 "do require pin number" 171 00:07:37,560 --> 00:07:39,830 or perhaps that is even configured in the terminal, 172 00:07:39,830 --> 00:07:42,199 to always require pin number. 173 00:07:42,199 --> 00:07:44,449 Either way, inside the terminal, 174 00:07:44,449 --> 00:07:46,460 all the security magic happens now. 175 00:07:46,460 --> 00:07:49,020 There's different components of the terminal. 176 00:07:49,020 --> 00:07:52,699 There's a main CPU that does all the network communication, 177 00:07:52,699 --> 00:07:55,300 both ZVT and Poseidon, 178 00:07:55,300 --> 00:07:56,849 which is supposed to be somewhat secure 179 00:07:56,849 --> 00:07:59,409 but really isn't, as, by the way, 180 00:07:59,409 --> 00:08:01,020 some research a couple of years has shown, 181 00:08:01,020 --> 00:08:02,610 that specifically looked at the security 182 00:08:02,610 --> 00:08:04,370 of one of these terminals, 183 00:08:04,370 --> 00:08:05,509 but that's not the topic of today, 184 00:08:05,509 --> 00:08:09,090 we're looking at the standard's security. 185 00:08:09,090 --> 00:08:10,289 So inside this terminal, 186 00:08:10,289 --> 00:08:14,439 there's also a hardware security module, an HSM, 187 00:08:14,439 --> 00:08:18,360 and that HSM does all the heavy lifting 188 00:08:18,360 --> 00:08:21,449 when it comes to cryptographic keys and so forth. 189 00:08:21,449 --> 00:08:23,249 The HSM is also directly connected 190 00:08:23,249 --> 00:08:28,199 to the display and the pin pad of the machine. 191 00:08:28,199 --> 00:08:31,090 So you tell the HSM, inside the terminal, 192 00:08:31,090 --> 00:08:32,809 "do a pin transaction", 193 00:08:32,809 --> 00:08:34,240 it shows something on the display, 194 00:08:34,240 --> 00:08:36,830 "enter pin", it receives the input, 195 00:08:36,830 --> 00:08:39,220 and instead of giving out the pin number 196 00:08:39,220 --> 00:08:41,530 to the less secure side of the terminal 197 00:08:41,530 --> 00:08:45,130 it encrypts it with a key that only the payment processor 198 00:08:45,130 --> 00:08:46,540 is supposed to have. 199 00:08:46,540 --> 00:08:49,210 So, the main CPU, 200 00:08:49,210 --> 00:08:51,540 or anybody really outside of the HSM, 201 00:08:51,540 --> 00:08:53,280 does not see the pin number. 202 00:08:53,280 --> 00:08:56,690 That's how things are supposed to work. 203 00:08:56,690 --> 00:08:58,780 Now, the lower part of the slide 204 00:08:58,780 --> 00:09:01,070 develops an attack idea with one catch, 205 00:09:01,070 --> 00:09:03,460 we'll resolve that in a minute though. 206 00:09:03,460 --> 00:09:06,400 This attack here would use a different message 207 00:09:06,400 --> 00:09:08,800 to actually receive the pin number. 208 00:09:08,800 --> 00:09:11,890 So instead of saying, "do a pin transaction", 209 00:09:11,890 --> 00:09:16,500 it would just say "display some text and give me the input". 210 00:09:16,500 --> 00:09:17,780 That would work beautifully, right, 211 00:09:17,780 --> 00:09:20,790 so you display the text "give me the pin number" 212 00:09:20,790 --> 00:09:24,910 and whatever's typed in, you get that input. 213 00:09:24,910 --> 00:09:27,230 This very flexible functionality 214 00:09:27,230 --> 00:09:29,270 we don't really know what it's ever used for, 215 00:09:29,270 --> 00:09:30,510 we've never seen it, 216 00:09:30,510 --> 00:09:33,100 but we're suspecting it's used for things like, 217 00:09:33,100 --> 00:09:36,060 asking customers for their zip code or something, right? 218 00:09:36,060 --> 00:09:40,150 Type something in and send it over the network. 219 00:09:40,150 --> 00:09:41,200 And we've partly never seen this 220 00:09:41,200 --> 00:09:42,740 because it really can't be used, 221 00:09:42,740 --> 00:09:45,120 these messages need to be signed. 222 00:09:45,120 --> 00:09:45,900 We don't know who's supposed 223 00:09:45,900 --> 00:09:47,430 to sign these messages, 224 00:09:47,430 --> 00:09:49,010 we've tried to find a person 225 00:09:49,010 --> 00:09:50,890 but nobody feels responsible. 226 00:09:50,890 --> 00:09:53,450 So there's some functionality in the standard here 227 00:09:53,450 --> 00:09:55,880 that's never used and nobody knows how to use it. 228 00:09:55,880 --> 00:09:58,020 The use of this cryptographic signature 229 00:09:58,020 --> 00:10:01,930 on the slide called message authentication code, MAC, 230 00:10:01,930 --> 00:10:03,670 that's required and it's actually 231 00:10:03,670 --> 00:10:05,340 checked by the HSM. 232 00:10:05,340 --> 00:10:09,620 So if you want to do your "please enter zip code" scheme 233 00:10:09,620 --> 00:10:10,680 across all your stores, 234 00:10:10,680 --> 00:10:12,590 you've got to get your message signed, 235 00:10:12,590 --> 00:10:15,110 and that signed message then works across all terminals. 236 00:10:15,110 --> 00:10:19,870 And if we want our "please enter pin number" message to be shown, 237 00:10:19,870 --> 00:10:21,270 we've got to get to sign, 238 00:10:21,270 --> 00:10:24,310 or find some way to sign this ourselves 239 00:10:24,310 --> 00:10:26,180 and no entering the real hacking 240 00:10:26,180 --> 00:10:29,840 so I'm handing over to Fabian 241 00:10:29,840 --> 00:10:31,940 who did almost all this research, 242 00:10:31,940 --> 00:10:35,810 so that was just my attempt to introduce these two guys here. 243 00:10:35,810 --> 00:10:37,530 Bräunlein: Thank you. 244 00:10:37,530 --> 00:10:43,650 *applause* 245 00:10:43,650 --> 00:10:46,030 Alright, so, to find valid MACs 246 00:10:46,030 --> 00:10:47,340 for arbitrary texts, 247 00:10:47,340 --> 00:10:50,900 we exploited a time-based side-channel vulnerability 248 00:10:50,900 --> 00:10:53,980 within one HSM implementation. 249 00:10:53,980 --> 00:10:55,880 So, for those to work reliably, 250 00:10:55,880 --> 00:10:57,740 we had to have the ability to 251 00:10:57,740 --> 00:11:01,160 send messages directly to the HSM. 252 00:11:01,160 --> 00:11:03,120 To accomplish that, we used 253 00:11:03,120 --> 00:11:08,500 an active JTAG interface we found for the main CPU on the PCP, 254 00:11:08,500 --> 00:11:11,370 and loaded our custom assembly program. 255 00:11:11,370 --> 00:11:14,780 What this wanted was just sending messages 256 00:11:14,780 --> 00:11:18,800 with our texts and some MACs to the HSM, 257 00:11:18,800 --> 00:11:22,600 and stop the time that it needs to respond. 258 00:11:22,600 --> 00:11:26,930 So, we are doing that and are trying every single possibility, 259 00:11:26,930 --> 00:11:31,220 every single value for the first byte of this 8-byte MAC. 260 00:11:31,220 --> 00:11:33,180 When you do that, you will see that... 261 00:11:33,180 --> 00:11:35,270 so, that's a bit oversimplified, 262 00:11:35,270 --> 00:11:36,710 but you will get the gist. 263 00:11:36,710 --> 00:11:40,070 You will see that for one particular value, 264 00:11:40,070 --> 00:11:42,500 the HSM needs a bit longer to respond, 265 00:11:42,500 --> 00:11:46,520 so like, just 5 CPU cycles within the HSM. 266 00:11:46,520 --> 00:11:51,450 Now you already have the first byte of this 8-byte MAC, 267 00:11:51,450 --> 00:11:55,380 you can set this and do the same thing for the second one. 268 00:11:55,380 --> 00:11:58,120 So, why does that work? 269 00:11:58,120 --> 00:12:01,830 This works because they use a symmetric key 270 00:12:01,830 --> 00:12:03,680 for the calculation of the MAC 271 00:12:03,680 --> 00:12:05,330 within the HSM. 272 00:12:05,330 --> 00:12:07,370 There is a key that the payment processor has, 273 00:12:07,370 --> 00:12:09,320 and this is stored inside the HSM, 274 00:12:09,320 --> 00:12:14,920 which is able to calculate the correct MAC for any text. 275 00:12:14,920 --> 00:12:15,860 And what happens next, 276 00:12:15,860 --> 00:12:17,800 so this is the first minor issue 277 00:12:17,800 --> 00:12:20,810 because you should use asymmetric cryptography. 278 00:12:20,810 --> 00:12:22,260 The next thing is, 279 00:12:22,260 --> 00:12:25,370 that the comparison between the correct MAC 280 00:12:25,370 --> 00:12:28,560 that has been calculated within the HSM, 281 00:12:28,560 --> 00:12:32,040 and the MAC we have input through this display text message, 282 00:12:32,040 --> 00:12:34,730 is compared byte by byte. 283 00:12:34,730 --> 00:12:37,080 So it checks if the first byte of the input message 284 00:12:37,080 --> 00:12:39,500 matches the first byte of the correct MAC 285 00:12:39,500 --> 00:12:40,440 and if it doesn't match, 286 00:12:40,440 --> 00:12:42,100 it will return immediately, 287 00:12:42,100 --> 00:12:45,640 if it matches, it will try to compare the second byte, 288 00:12:45,640 --> 00:12:47,160 and if that doesn't match it will return immediately, 289 00:12:47,160 --> 00:12:51,250 so, this time it needs to check one more byte, 290 00:12:51,250 --> 00:12:52,760 we can measure, 291 00:12:52,760 --> 00:12:55,140 with some more work. 292 00:12:55,140 --> 00:12:58,190 So, with this thing, 293 00:12:58,190 --> 00:13:01,920 with the correct MAC for the "please enter pin" screen, 294 00:13:01,920 --> 00:13:04,220 we can give you a quick demonstration 295 00:13:04,220 --> 00:13:06,170 of how this works in real life. 296 00:13:06,170 --> 00:13:09,330 And for that we would need the GoPro... 297 00:13:09,330 --> 00:13:15,540 that you already have. 298 00:13:15,540 --> 00:13:17,400 Ah, the GoPro, yeah. 299 00:13:17,400 --> 00:13:20,080 *laughter* 300 00:13:20,080 --> 00:13:24,240 So, this is the setup here. 301 00:13:24,240 --> 00:13:27,810 Here we need the computer with the green text on the black terminal. 302 00:13:27,810 --> 00:13:30,870 Alright. Here we have a normal cashier register, 303 00:13:30,870 --> 00:13:33,250 it's some Windows XP software running, 304 00:13:33,250 --> 00:13:35,880 here we have the actual payment terminal, 305 00:13:35,880 --> 00:13:40,750 these two are connected through this Fritz box standing here, 306 00:13:40,750 --> 00:13:43,440 just some normal internal home network. 307 00:13:43,440 --> 00:13:47,300 Now, there's also another participant in the setup, 308 00:13:47,300 --> 00:13:49,560 which is the attacker, 309 00:13:49,560 --> 00:13:51,530 in this case I'm connected via LAN, 310 00:13:51,530 --> 00:13:52,630 but you could also be connected 311 00:13:52,630 --> 00:13:56,310 by wifi in the car outside in the street and so on, 312 00:13:56,310 --> 00:13:58,580 so what we have running here 313 00:13:58,580 --> 00:14:01,310 is the attacker software. 314 00:14:01,310 --> 00:14:03,080 When we will introduce now, 315 00:14:03,080 --> 00:14:04,830 initiate a payment, 316 00:14:04,830 --> 00:14:06,020 through this cashier register, 317 00:14:06,020 --> 00:14:07,920 the attacker as a man in the middle 318 00:14:07,920 --> 00:14:09,560 between these two devices 319 00:14:09,560 --> 00:14:11,500 will simply drop this message 320 00:14:11,500 --> 00:14:17,750 and replace it with the first "read card" message. 321 00:14:17,750 --> 00:14:22,930 We will pay with the card. 322 00:14:22,930 --> 00:14:25,230 Yeah, alright. 323 00:14:25,230 --> 00:14:27,180 Please insert the card. 324 00:14:27,180 --> 00:14:30,510 Now, yeah, here we can also see, 325 00:14:30,510 --> 00:14:32,950 we can already see the card data. 326 00:14:32,950 --> 00:14:35,020 Partially censored for our own safety. 327 00:14:35,020 --> 00:14:37,100 *laughter* 328 00:14:37,100 --> 00:14:39,190 And, here's "enter the pin" already, 329 00:14:39,190 --> 00:14:40,820 so what you have seen, 330 00:14:40,820 --> 00:14:43,290 it was a bit fast, but what you have seen 331 00:14:43,290 --> 00:14:46,500 was, the pin he has entered appeared here 332 00:14:46,500 --> 00:14:47,750 as soon as he entered it, 333 00:14:47,750 --> 00:14:50,490 because it wasn't the real pin entry screen, 334 00:14:50,490 --> 00:14:52,720 it was just our fake pin entry screen. 335 00:14:52,720 --> 00:14:56,440 I hope you have seen, that you saw that on the terminal. 336 00:14:56,440 --> 00:14:59,090 That's the first demo, that's how we steal the pin number. 337 00:14:59,090 --> 00:15:10,540 *applause* 338 00:15:10,540 --> 00:15:15,250 Dexter: Alright. Zweite demo. 339 00:15:15,250 --> 00:15:18,070 Nohl: The terminal printed out your receipt, though. 340 00:15:18,070 --> 00:15:20,420 Gives out the attack a little bit, right? 341 00:15:20,420 --> 00:15:23,730 Can we show this receipt? 342 00:15:23,730 --> 00:15:26,860 GoPro, while you're here. 343 00:15:26,860 --> 00:15:29,750 So, this line and then in the normal transaction, 344 00:15:29,750 --> 00:15:30,690 when you enter pin number, 345 00:15:30,690 --> 00:15:32,290 is supposed to say Girocard, 346 00:15:32,290 --> 00:15:36,080 and instead does now say ELV offline, 347 00:15:36,080 --> 00:15:37,890 so in some cases it's actually apparent, 348 00:15:37,890 --> 00:15:41,070 but who actually pays attention to these details, right? 349 00:15:41,070 --> 00:15:42,590 Bräunlein: RIght. In addition to this, 350 00:15:42,590 --> 00:15:44,630 this means that the transaction 351 00:15:44,630 --> 00:15:47,510 has gone through with "Lastschrift" without the pin, 352 00:15:47,510 --> 00:15:50,310 however we can also choose our attack 353 00:15:50,310 --> 00:15:52,870 to simply fail the first time, 354 00:15:52,870 --> 00:15:54,650 so it says, like, "system failure" 355 00:15:54,650 --> 00:15:55,670 or "pin incorrect", 356 00:15:55,670 --> 00:15:57,620 and we'll do a second transaction, 357 00:15:57,620 --> 00:15:59,120 again with pin authorisation, 358 00:15:59,120 --> 00:16:01,220 that's fine, or in bigger setups, 359 00:16:01,220 --> 00:16:03,930 it's not the terminal that prints the receipt, 360 00:16:03,930 --> 00:16:07,380 but an external printer that's connected to the cashier register, 361 00:16:07,380 --> 00:16:10,620 and for that to work, the terminal again has to send 362 00:16:10,620 --> 00:16:14,200 the receipt line by line to the cashier register, 363 00:16:14,200 --> 00:16:16,690 again without any encryption or authentication, 364 00:16:16,690 --> 00:16:20,100 so we can simply replace the line with Girocard, or drop some lines, 365 00:16:20,100 --> 00:16:23,190 and do whatever we want. 366 00:16:23,190 --> 00:16:24,350 Nohl: Very cool. 367 00:16:24,350 --> 00:16:27,610 So, that was an attack against the customer, 368 00:16:27,610 --> 00:16:29,540 that is, pretty much everybody here, 369 00:16:29,540 --> 00:16:34,490 unless you really only ever pay with cash. 370 00:16:34,490 --> 00:16:36,150 There's some other attacks 371 00:16:36,150 --> 00:16:38,530 that target merchants instead, 372 00:16:38,530 --> 00:16:40,520 so everybody who operates one of these terminals, 373 00:16:40,520 --> 00:16:42,750 and, according to the banks, 374 00:16:42,750 --> 00:16:46,750 there's 770 thousand such terminals in operation 375 00:16:46,750 --> 00:16:47,640 today in Germany, 376 00:16:47,640 --> 00:16:49,610 so I guess at this point in time, 377 00:16:49,610 --> 00:16:52,130 everybody, even the tiniest of shops, 378 00:16:52,130 --> 00:16:54,400 will accept cashless payment, 379 00:16:54,400 --> 00:16:57,940 so, let's look at that next. 380 00:16:57,940 --> 00:16:59,620 Bräunlein: So, for the next attack, 381 00:16:59,620 --> 00:17:03,170 we are trying to get all the money 382 00:17:03,170 --> 00:17:05,290 that's been transferred on this terminal 383 00:17:05,290 --> 00:17:07,820 to our own bank account. 384 00:17:07,820 --> 00:17:11,689 Again, we assume we have local access to the network, 385 00:17:11,689 --> 00:17:13,689 but this time we won't try to become 386 00:17:13,689 --> 00:17:17,069 man in the middle between the cashier register and the terminal, 387 00:17:17,069 --> 00:17:19,999 but between the terminal and the Internet, 388 00:17:19,999 --> 00:17:23,730 in this case the payment processor. 389 00:17:23,730 --> 00:17:25,560 By ARP spoofing again. 390 00:17:25,560 --> 00:17:28,820 So ZVT includes a message, 391 00:17:28,820 --> 00:17:31,450 and defines this message in the specification 392 00:17:31,450 --> 00:17:32,980 to reset the terminal ID, 393 00:17:32,980 --> 00:17:35,990 which is basically the identifier 394 00:17:35,990 --> 00:17:38,120 that says to which bank account 395 00:17:38,120 --> 00:17:40,370 the terminal is linked to. 396 00:17:40,370 --> 00:17:42,910 We can reset and set this again 397 00:17:42,910 --> 00:17:48,100 with password, more on that we will show later. 398 00:17:48,100 --> 00:17:51,650 If we have set this, we will now 399 00:17:51,650 --> 00:17:56,460 tell the terminal to initiate an extended diagnose to the backend again. 400 00:17:56,460 --> 00:17:59,900 So we tell it via the ZVT protocol 401 00:17:59,900 --> 00:18:03,940 to initiate a message on the Poseidon protocol. 402 00:18:03,940 --> 00:18:05,540 We need that because, 403 00:18:05,540 --> 00:18:08,190 when we reset the terminal ID, 404 00:18:08,190 --> 00:18:10,280 the terminal will get reconfigured 405 00:18:10,280 --> 00:18:13,740 for the attacker terminal ID, so for my one. 406 00:18:13,740 --> 00:18:15,780 And this also means that the merchant banner, 407 00:18:15,780 --> 00:18:17,960 so in German it's the Händler-Logo, 408 00:18:17,960 --> 00:18:20,980 the thing that's printed on the top of every receipt, 409 00:18:20,980 --> 00:18:22,310 this would also be my one, 410 00:18:22,310 --> 00:18:23,110 the attacker's one, 411 00:18:23,110 --> 00:18:24,610 but we don't want that. 412 00:18:24,610 --> 00:18:27,370 So we tell the terminal to make another transaction, 413 00:18:27,370 --> 00:18:29,050 another extended diagnose, 414 00:18:29,050 --> 00:18:31,290 we will simply pass that through to the backend 415 00:18:31,290 --> 00:18:32,750 as a man in the middle, 416 00:18:32,750 --> 00:18:37,770 and the response includes some limits for offline electronic cash and so on, 417 00:18:37,770 --> 00:18:39,400 and also the merchant banner. 418 00:18:39,400 --> 00:18:41,250 And this, again, we can simply swap, 419 00:18:41,250 --> 00:18:44,030 we can swap with the original one, 420 00:18:44,030 --> 00:18:49,560 and so no one will get that this ID actually occurred, 421 00:18:49,560 --> 00:18:56,030 and this is again possible because no authentication is implemented here. 422 00:18:56,030 --> 00:18:58,390 Now for the actual transaction. 423 00:18:58,390 --> 00:19:00,870 If the backend port is already the correct one, 424 00:19:00,870 --> 00:19:03,970 we can simply pass all the messages through. 425 00:19:03,970 --> 00:19:07,370 So, the backend port is, 426 00:19:07,370 --> 00:19:08,680 each payment processor has 427 00:19:08,680 --> 00:19:11,350 that one IP address responding for all the terminals. 428 00:19:11,350 --> 00:19:12,900 However, for load-balancing reasons 429 00:19:12,900 --> 00:19:14,850 or something like that, 430 00:19:14,850 --> 00:19:17,270 they have like 100 different ports, 431 00:19:17,270 --> 00:19:20,570 each port responsible for 50 thousand terminals, 432 00:19:20,570 --> 00:19:25,790 but each terminal can only be managed by one specific port. 433 00:19:25,790 --> 00:19:27,110 So if this port already matches, 434 00:19:27,110 --> 00:19:28,820 we can simply pass through, 435 00:19:28,820 --> 00:19:31,340 every payment done by this terminal 436 00:19:31,340 --> 00:19:35,030 will now result in some more money in our bank account. 437 00:19:35,030 --> 00:19:36,560 If this one doesn't match, 438 00:19:36,560 --> 00:19:38,060 we as a man in the middle can simply 439 00:19:38,060 --> 00:19:42,180 redirect the messages to the correct backend parameters. 440 00:19:42,180 --> 00:19:45,300 And, again, let's see it in action. 441 00:19:53,070 --> 00:19:56,020 So what we have here is a terminal, 442 00:19:56,020 --> 00:19:59,790 we have configured it to be configured as another merchant, 443 00:19:59,790 --> 00:20:03,340 you will see in the end which one it was. 444 00:20:03,340 --> 00:20:05,970 Again we have the attacker's PC 445 00:20:05,970 --> 00:20:15,660 that's running the malicious software, and... 446 00:20:15,660 --> 00:20:18,550 now we will issue the registration, 447 00:20:18,550 --> 00:20:20,640 just that we are able to send ZVT messages 448 00:20:20,640 --> 00:20:23,300 to the terminal. 449 00:20:23,300 --> 00:20:25,360 And now we will reset the terminal ID 450 00:20:25,360 --> 00:20:27,010 from the one that's correctly set 451 00:20:27,010 --> 00:20:28,309 to our own one, 452 00:20:28,309 --> 00:20:31,410 the one we have got from our contract 453 00:20:31,410 --> 00:20:34,309 with the payment processor. 454 00:20:34,309 --> 00:20:36,550 We are setting this terminal ID. 455 00:20:42,240 --> 00:20:46,540 And now the terminal already gets its new configuration, 456 00:20:46,540 --> 00:20:50,490 encrypted, as you will see. 457 00:20:50,490 --> 00:20:54,060 But it receives it. 458 00:20:54,060 --> 00:20:56,160 Nohl: So this is all happening with 459 00:20:56,160 --> 00:20:59,260 real terminals for real transactions, 460 00:20:59,260 --> 00:21:02,120 so, whoever is watching this at the bank, 461 00:21:02,120 --> 00:21:04,550 thank you for not blocking us yet. 462 00:21:04,550 --> 00:21:14,320 *laughter, applause* 463 00:21:14,320 --> 00:21:16,740 Bräunlein: But we use the 3G network, 464 00:21:16,740 --> 00:21:21,490 so in case they block the IP address range here. 465 00:21:21,490 --> 00:21:25,160 Alright, so, normally this thing, 466 00:21:25,160 --> 00:21:26,800 you recognise that this would have been 467 00:21:26,800 --> 00:21:29,730 printed on the terminal itself. 468 00:21:29,730 --> 00:21:31,500 And we can see now, 469 00:21:31,500 --> 00:21:33,740 this terminal now prints as 470 00:21:33,740 --> 00:21:36,050 belonging to srlabs, 471 00:21:36,050 --> 00:21:38,850 normally this would be the full terminal ID, 472 00:21:38,850 --> 00:21:40,820 that we censored a bit, 473 00:21:40,820 --> 00:21:43,760 and you can see this is the whole configuration, 474 00:21:43,760 --> 00:21:46,490 and it's also configured to be able to 475 00:21:46,490 --> 00:21:49,860 issue prepaid cards. 476 00:21:49,860 --> 00:21:51,880 Normally this would be printed on the terminal, 477 00:21:51,880 --> 00:21:54,620 but because that would be pretty uncool, 478 00:21:54,620 --> 00:21:56,520 because then you would recognise it, 479 00:21:56,520 --> 00:22:02,040 we transferred all the output to our own notebook. 480 00:22:02,040 --> 00:22:04,880 Now we will start the man in the middle server 481 00:22:04,880 --> 00:22:09,030 for this last part, exchanging the terminal banner. 482 00:22:09,030 --> 00:22:14,350 We will change the logo. 483 00:22:14,350 --> 00:22:19,170 And we will now issue a demo transaction, 484 00:22:19,170 --> 00:22:21,900 so just like the cashier register software did, 485 00:22:21,900 --> 00:22:25,480 we will now issue a transaction, 486 00:22:25,480 --> 00:22:31,100 and, as you will see, this terminal now belongs to... 487 00:22:31,100 --> 00:22:33,550 or still belongs to... 488 00:22:33,550 --> 00:22:38,490 Can you see that? 489 00:22:38,490 --> 00:22:40,530 Put it on the table, yeah. 490 00:22:48,130 --> 00:23:01,790 *laughter, applause* 491 00:23:01,790 --> 00:23:06,240 Nohl: Can we switch back to the slides? 492 00:23:06,240 --> 00:23:08,540 Thank you. 493 00:23:08,540 --> 00:23:10,220 So that's how we steal money 494 00:23:10,220 --> 00:23:12,309 from an actual merchant, 495 00:23:12,309 --> 00:23:13,720 while in the store. 496 00:23:13,720 --> 00:23:15,590 That'd perhaps be the first catch, 497 00:23:15,590 --> 00:23:16,940 that you have to be in the store, 498 00:23:16,940 --> 00:23:20,850 the second catch, as probably the ones following along noted, 499 00:23:20,850 --> 00:23:24,180 is, the attacker also needs to be merchant here, 500 00:23:24,180 --> 00:23:27,840 you just change from money going to one merchant account, 501 00:23:27,840 --> 00:23:29,920 from that to going to another merchant account, 502 00:23:29,920 --> 00:23:32,870 but you need to be registered as a merchant somehow, right? 503 00:23:32,870 --> 00:23:33,940 There may a catch, 504 00:23:33,940 --> 00:23:35,690 I don't know how well set up criminals are, 505 00:23:35,690 --> 00:23:37,720 with actual businesses, 506 00:23:37,720 --> 00:23:40,750 but the next attack we're going to show 507 00:23:40,750 --> 00:23:42,510 does not come with this catch, 508 00:23:42,510 --> 00:23:44,720 it does not require you to be in the store 509 00:23:44,720 --> 00:23:48,960 and does not require you to have anything preconfigured 510 00:23:48,960 --> 00:23:52,630 and this is an attack on the Poseidon protocol. 511 00:23:52,630 --> 00:23:53,770 Remember, that's the protocol 512 00:23:53,770 --> 00:23:55,750 spoken between the terminal 513 00:23:55,750 --> 00:23:58,960 and the payment processor, right? 514 00:23:58,960 --> 00:23:59,950 Take it away. 515 00:23:59,950 --> 00:24:03,070 Bräunlein: Alright! So, now for the third attack. 516 00:24:03,070 --> 00:24:05,980 In that case, what we are taking a specific look at 517 00:24:05,980 --> 00:24:09,190 is the initialisation routine of Poseidon. 518 00:24:09,190 --> 00:24:10,350 This part is normally done 519 00:24:10,350 --> 00:24:11,880 at the payment processor, 520 00:24:11,880 --> 00:24:15,290 when you get your terminal preconfigured. 521 00:24:15,290 --> 00:24:16,390 Here's done this configuration 522 00:24:16,390 --> 00:24:20,410 to assign your terminal to your bank account, 523 00:24:20,410 --> 00:24:22,420 to make this match. 524 00:24:22,420 --> 00:24:24,130 And how is this done? 525 00:24:24,130 --> 00:24:28,090 The terminal sends a Poseidon initialisation routine, 526 00:24:28,090 --> 00:24:29,480 with the terminal ID, 527 00:24:29,480 --> 00:24:32,030 to the backend. 528 00:24:32,030 --> 00:24:37,130 The backend then will get the configuration for that terminal ID, 529 00:24:37,130 --> 00:24:40,420 send it to the payment terminal, 530 00:24:40,420 --> 00:24:42,220 in an encrypted way. 531 00:24:42,220 --> 00:24:43,820 Symmetrically encrypted 532 00:24:43,820 --> 00:24:48,580 with a key only within the HSM and the payment processor has. 533 00:24:48,580 --> 00:24:49,880 So far, so good. 534 00:24:49,880 --> 00:24:53,500 That's the normal pre-shared key thing that we know. 535 00:24:53,500 --> 00:24:56,510 However, what we have found is that this key, 536 00:24:56,510 --> 00:24:57,990 this exact same key, 537 00:24:57,990 --> 00:25:00,330 is used not in only one terminal, 538 00:25:00,330 --> 00:25:02,679 but in many, many terminals. 539 00:25:02,679 --> 00:25:05,230 So what is left of this authentication? 540 00:25:05,230 --> 00:25:08,860 It's just a username, the terminal ID. 541 00:25:08,860 --> 00:25:14,070 And this username is public, as you will see. 542 00:25:14,070 --> 00:25:18,330 So, the idea now is to have our own terminal, 543 00:25:18,330 --> 00:25:19,770 that we got from eBay, 544 00:25:19,770 --> 00:25:22,740 we got like 3 of them for 7 euros, 545 00:25:22,740 --> 00:25:24,580 including shipping cost. 546 00:25:24,580 --> 00:25:27,590 *laughter* 547 00:25:27,590 --> 00:25:29,250 And configure our terminal 548 00:25:29,250 --> 00:25:33,480 to act like just some random terminal, 549 00:25:33,480 --> 00:25:34,640 somewhere for example in Bonn, 550 00:25:34,640 --> 00:25:38,550 the mouse shop, as we have demonstrated. 551 00:25:38,550 --> 00:25:42,870 At that point, I almost feel like apologising because, 552 00:25:42,870 --> 00:25:45,929 for this hack, no actual hacking is involved, 553 00:25:45,929 --> 00:25:50,890 it's just... it's just broken in that case. 554 00:25:50,890 --> 00:25:53,530 You will see. 555 00:25:53,530 --> 00:25:55,640 So, you just need a few parameters 556 00:25:55,640 --> 00:25:58,410 to configure your terminal as another one. 557 00:25:58,410 --> 00:26:01,520 And this is at first the server's management password 558 00:26:01,520 --> 00:26:03,750 only server technicians should have. 559 00:26:03,750 --> 00:26:07,020 The second one is the terminal ID of your victim, 560 00:26:07,020 --> 00:26:10,830 and the last one is the backend port 561 00:26:10,830 --> 00:26:12,900 that is responsible for managing 562 00:26:12,900 --> 00:26:16,360 your victim's terminal ID. 563 00:26:16,360 --> 00:26:18,460 So the first one. How do we get that? 564 00:26:18,460 --> 00:26:21,230 You will simply google and find it on the Internet 565 00:26:21,230 --> 00:26:23,530 in some internal documents. 566 00:26:23,530 --> 00:26:34,500 *laughter, applause, hooting* 567 00:26:34,500 --> 00:26:36,910 This one is the same across all terminals 568 00:26:36,910 --> 00:26:38,290 of one payment processor, 569 00:26:38,290 --> 00:26:41,009 so, completely independent of the model, 570 00:26:41,009 --> 00:26:43,770 every terminal you got from the same payment processor, 571 00:26:43,770 --> 00:26:44,850 the same password. 572 00:26:44,850 --> 00:26:46,530 So the second one, the terminal ID. 573 00:26:46,530 --> 00:26:48,000 As you have already seen, 574 00:26:48,000 --> 00:26:50,240 you can find it on every receipt. 575 00:26:50,240 --> 00:26:53,570 And you can guess them as they're assigned incrementally. 576 00:26:53,570 --> 00:26:54,480 *applause* 577 00:26:54,480 --> 00:27:02,580 Second one. *applause* 578 00:27:02,580 --> 00:27:05,220 And, for the last one, there are like 579 00:27:05,220 --> 00:27:07,690 100 different possibilities, 580 00:27:07,690 --> 00:27:08,950 so just try them all, 581 00:27:08,950 --> 00:27:11,059 and see which one of these 100 ports 582 00:27:11,059 --> 00:27:13,960 doesn't answer with a message saying "I don't know you", 583 00:27:13,960 --> 00:27:15,309 but with a merchant banner. 584 00:27:15,309 --> 00:27:18,750 So have all three things set, 585 00:27:18,750 --> 00:27:23,710 let's demonstrate it. 586 00:27:23,710 --> 00:27:26,110 So, for this demonstration, 587 00:27:26,110 --> 00:27:28,730 we've already told you we don't have to be 588 00:27:28,730 --> 00:27:30,140 on the same network, 589 00:27:30,140 --> 00:27:33,740 so this is the terminal here for CCC 590 00:27:33,740 --> 00:27:34,690 that we have shown you, 591 00:27:34,690 --> 00:27:37,170 we will simply disconnect that, 592 00:27:37,170 --> 00:27:39,220 it's not on the same network. 593 00:27:39,220 --> 00:27:42,440 What we have here is a terminal 594 00:27:42,440 --> 00:27:43,950 without any terminal ID, 595 00:27:43,950 --> 00:27:47,760 we just set that into factory reset. 596 00:27:47,760 --> 00:27:50,340 This is how you would get it from eBay, 597 00:27:50,340 --> 00:27:51,690 if the seller did a good job 598 00:27:51,690 --> 00:27:53,539 and put it in factory reset. 599 00:27:53,539 --> 00:27:56,770 *laughter* 600 00:27:56,770 --> 00:28:01,788 Alright, the service password, hmm. 601 00:28:10,468 --> 00:28:18,580 *laughter* 602 00:28:18,580 --> 00:28:24,651 *laughter, applause* 603 00:28:27,570 --> 00:28:29,770 *Bräunlein shrieks* 604 00:28:36,990 --> 00:28:40,089 *laughter* 605 00:28:44,030 --> 00:28:46,590 Good. Aha, no cameras, good. 606 00:28:58,770 --> 00:29:01,920 Alright. We've entered the terminal ID, 607 00:29:01,920 --> 00:29:07,100 the backend port is already correct. 608 00:29:07,100 --> 00:29:11,179 And we will issue an extended diagnose 609 00:29:11,179 --> 00:29:14,284 to get the new configuration. 610 00:29:28,719 --> 00:29:32,840 Nohl: And once you're registered, 611 00:29:32,840 --> 00:29:34,870 what can you actually do 612 00:29:34,870 --> 00:29:38,490 to that victim merchant? 613 00:29:38,490 --> 00:29:42,179 Bräunlein: We will show the prepaid top-up, 614 00:29:42,179 --> 00:29:44,799 so if the victim merchant 615 00:29:44,799 --> 00:29:49,880 has the prepaid feature activated, 616 00:29:49,880 --> 00:29:51,240 we will have it activated as well, 617 00:29:51,240 --> 00:29:54,049 because we are the victim's terminal. 618 00:29:54,049 --> 00:29:59,200 So what we can do is simply print and print prepaid top-ups 619 00:29:59,200 --> 00:30:01,559 and for example call our own premium number 620 00:30:01,559 --> 00:30:02,860 to make it actual money, 621 00:30:02,860 --> 00:30:04,450 or try to sell it. 622 00:30:04,450 --> 00:30:06,210 So let's try that. 623 00:30:06,210 --> 00:30:11,350 So... O2, maybe. 15 euros is enough. 624 00:30:11,350 --> 00:30:14,113 Of course, we paid in cash. 625 00:30:25,430 --> 00:30:37,000 *applause* 626 00:30:37,000 --> 00:30:39,980 Nohl: Does anybody actually use O2 prepaid? 627 00:30:39,980 --> 00:30:41,350 *laughter* 628 00:30:41,350 --> 00:30:53,450 No? Well, I'm sure somebody will find this useful. 629 00:30:53,450 --> 00:31:06,910 *laughter* *applause* 630 00:31:06,910 --> 00:31:09,160 Bräunlein: We will also shortly demonstrate the second way 631 00:31:09,160 --> 00:31:11,630 to get money, and this is simply 632 00:31:11,630 --> 00:31:14,730 to transfer ourselves some money. 633 00:31:14,730 --> 00:31:16,750 *laughter* 634 00:31:16,750 --> 00:31:19,320 Nohl: So there's a feature called refund, 635 00:31:19,320 --> 00:31:21,070 but it's completely independent 636 00:31:21,070 --> 00:31:22,460 from previous transactions, 637 00:31:22,460 --> 00:31:25,890 so a "refund" is a transaction with a negative value. 638 00:31:25,890 --> 00:31:27,469 You can do this to any bank account. 639 00:31:27,469 --> 00:31:28,410 Bräunlein: So... 640 00:31:28,410 --> 00:31:33,302 *laughter* 641 00:31:33,302 --> 00:31:35,020 100? Yeah, 100 sounds good. 642 00:31:35,020 --> 00:31:38,063 *laughter* 643 00:31:45,727 --> 00:32:06,820 *applause* 644 00:32:06,820 --> 00:32:07,409 Ach! 645 00:32:07,409 --> 00:32:12,279 *laughter* 646 00:32:12,279 --> 00:32:14,390 Nohl: Can we go back to the slides? 647 00:32:14,390 --> 00:32:17,300 *laughter* 648 00:32:17,300 --> 00:32:20,650 Alright, that was pretty fast, 649 00:32:20,650 --> 00:32:24,409 so let's summarise what just happened. 650 00:32:24,409 --> 00:32:25,840 Somewhere in Germany there's a terminal 651 00:32:25,840 --> 00:32:28,090 configured with a certain terminal ID, 652 00:32:28,090 --> 00:32:29,950 and that terminal ID says, 653 00:32:29,950 --> 00:32:32,030 this terminal belongs to a certain merchant. 654 00:32:32,030 --> 00:32:35,140 So everything, every money that's put into that terminal 655 00:32:35,140 --> 00:32:36,429 goes to that merchant's account, 656 00:32:36,429 --> 00:32:37,870 and everything that's paid with that terminal 657 00:32:37,870 --> 00:32:39,580 comes out from that account. 658 00:32:39,580 --> 00:32:41,309 Now here's a second terminal, 659 00:32:41,309 --> 00:32:42,840 and we configured that second terminal 660 00:32:42,840 --> 00:32:46,660 to the same terminal ID. 661 00:32:46,660 --> 00:32:48,480 And it goes through a cryptographic process 662 00:32:48,480 --> 00:32:51,780 by which it registers itself with the backend. 663 00:32:51,780 --> 00:32:54,870 This leaves the original terminal completely working, 664 00:32:54,870 --> 00:32:56,840 so the merchant still do in the shop, 665 00:32:56,840 --> 00:32:57,929 whatever he wants, 666 00:32:57,929 --> 00:32:59,130 but there's a second terminal, 667 00:32:59,130 --> 00:33:01,690 a complete clone of the first one, 668 00:33:01,690 --> 00:33:03,640 that now can do the exact same things. 669 00:33:03,640 --> 00:33:06,080 If we were to send money into that terminal, 670 00:33:06,080 --> 00:33:07,460 the merchant would get the money, 671 00:33:07,460 --> 00:33:10,250 but if we do refunds or sim card top-up 672 00:33:10,250 --> 00:33:11,380 from that terminal, 673 00:33:11,380 --> 00:33:14,480 the money comes out from that merchant's account. 674 00:33:14,480 --> 00:33:16,660 Right? Very straightforward. 675 00:33:16,660 --> 00:33:17,700 You saw what it took. 676 00:33:17,700 --> 00:33:21,780 Three little numbers, all of which are easy to find, right? 677 00:33:21,780 --> 00:33:24,360 Based on a terminal that we purchased on eBay. 678 00:33:24,360 --> 00:33:26,240 Now what's the maximum scale of fraud 679 00:33:26,240 --> 00:33:28,970 that somebody could take this towards? 680 00:33:28,970 --> 00:33:32,940 First of all you don't have to do this manually on your terminal. 681 00:33:32,940 --> 00:33:35,899 Everything we just did, you can do over ZVT, 682 00:33:35,899 --> 00:33:37,480 so you can script this. 683 00:33:37,480 --> 00:33:39,100 And it's attractive to script it 684 00:33:39,100 --> 00:33:43,179 if you had a long list of valid terminal IDs. 685 00:33:43,179 --> 00:33:45,880 Now we should note that these are assigned incrementally, 686 00:33:45,880 --> 00:33:47,780 so if you know one terminal ID... 687 00:33:47,780 --> 00:33:48,969 *laughter* 688 00:33:48,969 --> 00:33:50,590 If you know one terminal ID, 689 00:33:50,590 --> 00:33:52,210 you know hundreds of thousands 690 00:33:52,210 --> 00:33:54,490 of valid terminal IDs. 691 00:33:54,490 --> 00:33:59,450 Right? So, you register your terminal over ZVT, 692 00:33:59,450 --> 00:34:01,049 with one merchant at a time, 693 00:34:01,049 --> 00:34:02,710 go through a long succession, 694 00:34:02,710 --> 00:34:04,830 thousands, tens of thousands, 695 00:34:04,830 --> 00:34:07,910 and send refunds or print top-up money 696 00:34:07,910 --> 00:34:10,690 from every single account. 697 00:34:10,690 --> 00:34:13,748 In Germany, through this Poseidon protocol, 698 00:34:13,748 --> 00:34:15,609 probably you take this to other countries too. 699 00:34:15,609 --> 00:34:20,759 Poseidon is one dialect of a more internationally spoken ISO standard, 700 00:34:20,759 --> 00:34:24,539 so, chances are this works in other countries as well. 701 00:34:24,539 --> 00:34:30,179 So this could really be a pretty large fraud scheme 702 00:34:30,179 --> 00:34:32,559 that fortunately hasn't occurred yet, 703 00:34:32,559 --> 00:34:35,179 and there's still time to fix it. 704 00:34:35,179 --> 00:34:39,709 *laughter* Again, those people at the banks, right? 705 00:34:39,709 --> 00:34:50,029 *applause* 706 00:34:50,029 --> 00:34:53,259 Summarising over the 3 attacks we've seen so far. 707 00:34:53,259 --> 00:34:56,319 So there's two protocols in Germany 708 00:34:56,319 --> 00:34:57,479 that are used for payments. 709 00:34:57,479 --> 00:34:59,640 Both of them are severely broken, 710 00:34:59,640 --> 00:35:01,829 and that affects customers, 711 00:35:01,829 --> 00:35:03,039 mostly in the store, 712 00:35:03,039 --> 00:35:05,150 by stealing their pin numbers and magstripes, 713 00:35:05,150 --> 00:35:06,950 they affect merchants, 714 00:35:06,950 --> 00:35:09,099 in the store or even over the Internet, 715 00:35:09,099 --> 00:35:11,450 we've tried this Poseidon attack over tor, 716 00:35:11,450 --> 00:35:12,560 works beautifully. 717 00:35:12,560 --> 00:35:21,270 *laughter, applause* 718 00:35:21,270 --> 00:35:25,130 And, coincidentally, these protocols 719 00:35:25,130 --> 00:35:27,430 of course were designed completely independently 720 00:35:27,430 --> 00:35:28,329 from one another, 721 00:35:28,329 --> 00:35:30,069 they're both vulnerable because of 722 00:35:30,069 --> 00:35:31,369 the same root cause. 723 00:35:31,369 --> 00:35:34,710 They share secret keys across terminals. 724 00:35:34,710 --> 00:35:36,369 You saw in the ZVT case 725 00:35:36,369 --> 00:35:38,930 that we needed to sign a message, 726 00:35:38,930 --> 00:35:41,799 that sign message was valid across all the different terminals 727 00:35:41,799 --> 00:35:44,420 because they all have the same signing key in them. 728 00:35:44,420 --> 00:35:46,670 We saw in Poseidon that we could just 729 00:35:46,670 --> 00:35:49,669 register one terminal as another one 730 00:35:49,669 --> 00:35:52,279 with all of them actually properly authenticated 731 00:35:52,279 --> 00:35:54,309 to the backend cryptographically, 732 00:35:54,309 --> 00:35:56,200 all of which with the same key, though, 733 00:35:56,200 --> 00:35:57,670 so they're not distinguishable. 734 00:35:57,670 --> 00:36:02,390 It's secure as long as every terminal is in good hands, 735 00:36:02,390 --> 00:36:05,319 which of course is a silly assumption 736 00:36:05,319 --> 00:36:07,759 in a scheme like that. 737 00:36:07,759 --> 00:36:12,410 So, each of these protocols is severely broken, 738 00:36:12,410 --> 00:36:17,130 and we should have just stopped our research here, but... 739 00:36:17,130 --> 00:36:18,410 *laughter* 740 00:36:18,410 --> 00:36:20,069 We wanted to get those keys, 741 00:36:20,069 --> 00:36:22,450 and Dexter wouldn't be here with us today 742 00:36:22,450 --> 00:36:25,170 if there weren't some hardware hacking involved. 743 00:36:25,170 --> 00:36:27,020 So we snuck in a few weeks 744 00:36:27,020 --> 00:36:29,470 of actual hardware hacking, 745 00:36:29,470 --> 00:36:32,609 and Dex is going to tell you what he did. 746 00:36:32,609 --> 00:36:40,779 *applause* 747 00:36:40,779 --> 00:36:44,650 Dexter: Okay, well, you know, 748 00:36:44,650 --> 00:36:49,499 yeah, let's go. 749 00:36:49,499 --> 00:36:55,260 Yeah, let's talk about the HSM, 750 00:36:55,260 --> 00:36:57,760 with the HSM module, 751 00:36:57,760 --> 00:37:00,699 this is our research, so, 752 00:37:00,699 --> 00:37:02,849 the HSM module is where the magic happens, 753 00:37:02,849 --> 00:37:07,789 so let's see, the grey box you see on the picture above, 754 00:37:07,789 --> 00:37:10,509 that's the HSM module, 755 00:37:10,509 --> 00:37:12,430 and this is basically a smartcard on steroids, 756 00:37:12,430 --> 00:37:14,170 so it has a display directly connected, 757 00:37:14,170 --> 00:37:16,749 there's a keypad connected, 758 00:37:16,749 --> 00:37:20,730 and it processes all the sensitive data. 759 00:37:20,730 --> 00:37:23,789 Of course, you want to have this area 760 00:37:23,789 --> 00:37:25,370 at least of the terminal write-protected, 761 00:37:25,370 --> 00:37:28,279 so you want to have it separate from the application processor 762 00:37:28,279 --> 00:37:33,490 where the insecure stuff happens. 763 00:37:33,490 --> 00:37:36,210 There are a couple of protection measures, 764 00:37:36,210 --> 00:37:39,440 for example, one important characteristic 765 00:37:39,440 --> 00:37:42,670 is that the static RAM, the SRAM, 766 00:37:42,670 --> 00:37:45,549 that holds the secret keys, 767 00:37:45,549 --> 00:37:46,869 is battery backed-up, 768 00:37:46,869 --> 00:37:50,729 so if the battery dies, you lose the keys, 769 00:37:50,729 --> 00:37:54,249 and that's because it's simpler 770 00:37:54,249 --> 00:37:56,539 to erase a battery backed-up SRAM, 771 00:37:56,539 --> 00:37:59,980 you just shut down the power. 772 00:37:59,980 --> 00:38:10,050 Around the module is a couple of switches, 773 00:38:10,050 --> 00:38:12,099 and if an attacker unscrews the case 774 00:38:12,099 --> 00:38:13,210 it will lift the switches 775 00:38:13,210 --> 00:38:15,159 and then it trips the tamper protection 776 00:38:15,159 --> 00:38:18,290 and... but that's no problem, 777 00:38:18,290 --> 00:38:19,650 that's easy to defeat. 778 00:38:19,650 --> 00:38:24,539 There's a more elaborate protection measure as well, 779 00:38:24,539 --> 00:38:28,999 so there's a mesh underneath this cap, 780 00:38:28,999 --> 00:38:33,339 there's a thin metallised mesh 781 00:38:33,339 --> 00:38:44,180 that is printed to the inner surface of the HSM cap 782 00:38:44,180 --> 00:38:45,819 and if an attacker would drill or cut 783 00:38:45,819 --> 00:38:47,809 or even rip off the cap, 784 00:38:47,809 --> 00:38:52,619 then you would trip the tamper protection of course. 785 00:38:52,619 --> 00:38:54,579 We found an exploitable mechanical weakness 786 00:38:54,579 --> 00:38:56,160 in this particular implementation, 787 00:38:56,160 --> 00:38:59,970 we found it on these terminals there, 788 00:38:59,970 --> 00:39:01,309 if you look carefully at the picture 789 00:39:01,309 --> 00:39:02,849 you'll see on the right cap, 790 00:39:02,849 --> 00:39:03,789 you'll see in the corners, 791 00:39:03,789 --> 00:39:05,809 you'll see these little dents. 792 00:39:05,809 --> 00:39:12,970 That's where the mesh is electrically connected to the underlying PCB, 793 00:39:12,970 --> 00:39:16,239 so there it's connected to the secret insides 794 00:39:16,239 --> 00:39:20,959 that measure, continually monitor the mesh, 795 00:39:20,959 --> 00:39:23,970 continuous monitoring, unlike smartcards, 796 00:39:23,970 --> 00:39:25,579 where you don't have a continuous monitoring, 797 00:39:25,579 --> 00:39:28,890 if they're off, they're off, but this is always on. 798 00:39:28,890 --> 00:39:30,519 And yeah, it's a problem, 799 00:39:30,519 --> 00:39:33,899 the connection is only in the four corners, 800 00:39:33,899 --> 00:39:35,809 not at the sides. 801 00:39:35,809 --> 00:39:38,920 So at the sides, there is a possibility 802 00:39:38,920 --> 00:39:42,339 to enter the edges in the confined space 803 00:39:42,339 --> 00:39:46,729 with some metallic piece or something, 804 00:39:46,729 --> 00:39:49,220 and furthermore, this cap, 805 00:39:49,220 --> 00:39:51,140 during the manufacturing process, 806 00:39:51,140 --> 00:39:52,700 this is glued on top of the PCB 807 00:39:52,700 --> 00:39:54,670 with a slightly rubbery glue, 808 00:39:54,670 --> 00:39:57,400 and this glue leaves a small slot, 809 00:39:57,400 --> 00:39:59,779 and we thought of... 810 00:39:59,779 --> 00:40:04,299 how can we try to push something under it? 811 00:40:04,299 --> 00:40:07,650 And probably defeat the tamper protection. 812 00:40:07,650 --> 00:40:10,809 And we found something from doctors, basically, 813 00:40:10,809 --> 00:40:13,859 that's a syringe needle we flattened with a pair of pliers, 814 00:40:13,859 --> 00:40:16,849 and indeed we managed to push that 815 00:40:16,849 --> 00:40:18,239 underneath the cap, 816 00:40:18,239 --> 00:40:19,630 underneath the mesh, 817 00:40:19,630 --> 00:40:22,249 and right into the HSM. 818 00:40:22,249 --> 00:40:23,519 And we made an experimentation, 819 00:40:23,519 --> 00:40:25,109 we found a weak spot, 820 00:40:25,109 --> 00:40:28,749 in our case it was just the power supply of the tamper protection 821 00:40:28,749 --> 00:40:30,930 we need to short out to ground, 822 00:40:30,930 --> 00:40:33,099 so then it's defeated, then it's off. 823 00:40:33,099 --> 00:40:35,880 And then we can safely open the mesh, 824 00:40:35,880 --> 00:40:39,439 you see the grounding clip on the left side. 825 00:40:39,439 --> 00:40:46,859 That's the short-circuit of the tamper protection detection circuit. 826 00:40:46,859 --> 00:40:50,239 And we used a soldering iron to cut it, 827 00:40:50,239 --> 00:40:53,910 because we wanted to avoid any vibrations of course, 828 00:40:53,910 --> 00:40:56,039 this is a delicate task, 829 00:40:56,039 --> 00:40:58,539 and then you have... 830 00:40:58,539 --> 00:41:00,319 then the fruits are exposed, 831 00:41:00,319 --> 00:41:02,499 you have physical access to the flash, 832 00:41:02,499 --> 00:41:05,410 to the SRAM, to the microcontroller, 833 00:41:05,410 --> 00:41:06,269 even to the JTAG, 834 00:41:06,269 --> 00:41:08,279 and in case JTAG doesn't work, 835 00:41:08,279 --> 00:41:10,450 and you're only interested in the flash, 836 00:41:10,450 --> 00:41:12,989 there are ways to do it. 837 00:41:12,989 --> 00:41:16,990 That's how we did it the first time. 838 00:41:16,990 --> 00:41:22,810 So, here we have attached the JTAG interface to the HSM, 839 00:41:22,810 --> 00:41:24,779 and the HSM is still alive, 840 00:41:24,779 --> 00:41:25,779 we have a terminal right there, 841 00:41:25,779 --> 00:41:28,430 you can look, the HSM's, bleargh, 842 00:41:28,430 --> 00:41:30,230 kind of working, 843 00:41:30,230 --> 00:41:35,579 and you can do all sorts of things, 844 00:41:35,579 --> 00:41:36,910 you can of course debug, 845 00:41:36,910 --> 00:41:38,269 you can do experiments, 846 00:41:38,269 --> 00:41:39,640 reverse-engineer stuff, 847 00:41:39,640 --> 00:41:41,539 and you can also dump the RAM 848 00:41:41,539 --> 00:41:42,989 and the RAM, the SRAM, 849 00:41:42,989 --> 00:41:44,349 might contain some secrets, 850 00:41:44,349 --> 00:41:46,489 in our case we did a little experiment, 851 00:41:46,489 --> 00:41:50,019 we tried to use the HSM module as an oracle, 852 00:41:50,019 --> 00:41:51,499 as you have seen before, you need 853 00:41:51,499 --> 00:41:54,119 some MACs, the message authentication code 854 00:41:54,119 --> 00:41:57,549 for the pin entry screen, 855 00:41:57,549 --> 00:41:59,130 the fake screen you've probably seen 856 00:41:59,130 --> 00:42:02,779 in the image that said that was protected with such a MAC. 857 00:42:02,779 --> 00:42:05,259 What you just do, 858 00:42:05,259 --> 00:42:07,199 the text string you want to have signed, 859 00:42:07,199 --> 00:42:08,900 you send it to the HSM, 860 00:42:08,900 --> 00:42:10,359 with an obviously wrong MAC, 861 00:42:10,359 --> 00:42:13,640 that's the 41 41 here, you know that, 862 00:42:13,640 --> 00:42:15,380 that's the wrong MAC, 863 00:42:15,380 --> 00:42:17,369 doesn't matter which value that is, 864 00:42:17,369 --> 00:42:18,749 you just send it in, 865 00:42:18,749 --> 00:42:20,729 and then the blue stuff you see there 866 00:42:20,729 --> 00:42:23,729 is the text we want to have signed, 867 00:42:23,729 --> 00:42:27,460 and then, the HSM just happily compares the two 868 00:42:27,460 --> 00:42:30,040 and says, error, doesn't match, 869 00:42:30,040 --> 00:42:32,339 but no problem, we just hold CCPU 870 00:42:32,339 --> 00:42:33,830 via JTAG dumps the RAM, 871 00:42:33,830 --> 00:42:35,289 we just look up the correct MAC, 872 00:42:35,289 --> 00:42:37,309 that's it then. 873 00:42:37,309 --> 00:42:38,190 *applause* 874 00:42:38,190 --> 00:42:46,710 Yeah, so much for the... *applause* 875 00:42:46,710 --> 00:42:50,809 so much for the not-so-secure hardware security module, 876 00:42:50,809 --> 00:42:56,349 and now let's go back to Karsten here. 877 00:42:56,349 --> 00:42:58,079 Nohl: Thanks. Yeah, good job. 878 00:42:58,079 --> 00:43:05,500 *applause* 879 00:43:05,500 --> 00:43:08,349 Yeah, just a bit of hardware hacking fun. 880 00:43:08,349 --> 00:43:11,339 This wasn't actually necessary for anything, 881 00:43:11,339 --> 00:43:16,119 but I think it is important 882 00:43:16,119 --> 00:43:17,450 to note that it is possible, 883 00:43:17,450 --> 00:43:20,359 to drive one key point home. 884 00:43:20,359 --> 00:43:22,229 So, in this next chapter, 885 00:43:22,229 --> 00:43:25,630 we'll talk about what would actually need to change 886 00:43:25,630 --> 00:43:27,819 for these protocols to be secure, 887 00:43:27,819 --> 00:43:29,049 and one thing that can not happen 888 00:43:29,049 --> 00:43:31,589 is for them to again bury some secret key 889 00:43:31,589 --> 00:43:33,829 in some "security" module 890 00:43:33,829 --> 00:43:36,569 that they give hundreds of thousands of copies out. 891 00:43:36,569 --> 00:43:38,249 HSMs and generally the idea 892 00:43:38,249 --> 00:43:39,950 of security by obscurity 893 00:43:39,950 --> 00:43:45,049 is broken and we need a better approach here. 894 00:43:45,049 --> 00:43:47,219 What exactly do we need, though? 895 00:43:47,219 --> 00:43:49,279 Let's first revisit why these two protocols 896 00:43:49,279 --> 00:43:51,359 are so severely broken. 897 00:43:51,359 --> 00:43:53,009 As I said earlier, both of them 898 00:43:53,009 --> 00:43:55,969 have the issues of keys that are spread 899 00:43:55,969 --> 00:43:58,999 over a very large population of terminals, 900 00:43:58,999 --> 00:44:00,150 some of which may be secure, 901 00:44:00,150 --> 00:44:02,049 others are very insecure, 902 00:44:02,049 --> 00:44:05,690 like this ancient model that we are looking at here. 903 00:44:05,690 --> 00:44:07,479 The weakest link of the system 904 00:44:07,479 --> 00:44:09,140 then obviously determines 905 00:44:09,140 --> 00:44:13,190 the protection of these system-wide keys. 906 00:44:13,190 --> 00:44:14,099 These system-wide keys, 907 00:44:14,099 --> 00:44:15,460 they play out very differently 908 00:44:15,460 --> 00:44:17,700 in these two protocols here, though. 909 00:44:17,700 --> 00:44:21,880 Remember in ZVT, there's a MAC, a message signature, 910 00:44:21,880 --> 00:44:23,769 which can actually be made very secure 911 00:44:23,769 --> 00:44:25,660 even this system-wide key 912 00:44:25,660 --> 00:44:28,599 as long as you're using pubic-key crypto. 913 00:44:28,599 --> 00:44:30,680 If only one person can sign messages, 914 00:44:30,680 --> 00:44:31,900 it's fine for everybody to have 915 00:44:31,900 --> 00:44:34,960 the same public key to verify the messages. 916 00:44:34,960 --> 00:44:37,380 Now, in this case, these terminals 917 00:44:37,380 --> 00:44:39,650 I guess, when they were designed, 918 00:44:39,650 --> 00:44:41,390 they didn't hear about this great invention 919 00:44:41,390 --> 00:44:44,229 of asymmetric cryptography, 920 00:44:44,229 --> 00:44:46,670 and they're using symmetric signatures, 921 00:44:46,670 --> 00:44:48,460 so the signing key is distributed 922 00:44:48,460 --> 00:44:51,499 in 700-some thousand copies, 923 00:44:51,499 --> 00:44:53,619 throughout Germany. 924 00:44:53,619 --> 00:44:55,180 Amplifying the problem and further of course 925 00:44:55,180 --> 00:44:59,599 amplifying by putting them in shady HSMs 926 00:44:59,599 --> 00:45:03,489 that are, well, not just vulnerable to Dexter-style hacking, 927 00:45:03,489 --> 00:45:06,539 but to simple timing side-channel attacks. 928 00:45:06,539 --> 00:45:10,200 Right? On the Poseidon side of things, 929 00:45:10,200 --> 00:45:11,410 it's a little bit cleaner, 930 00:45:11,410 --> 00:45:13,640 we're not talking about cryptographic signatures here, 931 00:45:13,640 --> 00:45:16,029 but about authentication, 932 00:45:16,029 --> 00:45:18,749 and look at these as online banking, right, 933 00:45:18,749 --> 00:45:20,029 each of these terminals is kind of like 934 00:45:20,029 --> 00:45:23,479 an online banking login to a merchant account, 935 00:45:23,479 --> 00:45:26,809 and if they're all using similar usernames, 936 00:45:26,809 --> 00:45:29,420 and everybody uses the exact same password, 937 00:45:29,420 --> 00:45:30,779 cryptographic key in this case, 938 00:45:30,779 --> 00:45:32,789 this cannot possibly be secure, 939 00:45:32,789 --> 00:45:35,390 this cannot be fixed with public-key crypto, 940 00:45:35,390 --> 00:45:37,400 as long as everybody uses the same, 941 00:45:37,400 --> 00:45:39,809 in that case then, digital certificate, 942 00:45:39,809 --> 00:45:42,719 this is not going to be secure either. 943 00:45:42,719 --> 00:45:44,029 In both these cases though, 944 00:45:44,029 --> 00:45:48,069 we need more individual keys. 945 00:45:48,069 --> 00:45:51,009 As at least a mid-term goal, right? 946 00:45:51,009 --> 00:45:54,619 Fortunately, these protocols do have a provision 947 00:45:54,619 --> 00:45:56,930 to distribute a new key to a terminal 948 00:45:56,930 --> 00:45:58,829 and this mechanism could be used 949 00:45:58,829 --> 00:46:00,369 to give a different key 950 00:46:00,369 --> 00:46:02,059 to every single terminal. 951 00:46:02,059 --> 00:46:05,479 So, the road ahead should be clear, 952 00:46:05,479 --> 00:46:07,670 some of the backend systems probably need to be adapted 953 00:46:07,670 --> 00:46:10,499 to work with individual keys per terminal, 954 00:46:10,499 --> 00:46:13,930 it's already clear how we would get out of this mess: 955 00:46:13,930 --> 00:46:16,570 give a different key to every single terminal. 956 00:46:16,570 --> 00:46:18,499 That not going to save us in the long run 957 00:46:18,499 --> 00:46:22,749 when people start attacking the HSM chips again individually 958 00:46:22,749 --> 00:46:25,579 and then defrauding these merchants individually, 959 00:46:25,579 --> 00:46:28,950 but it would at least get rid of the possibility 960 00:46:28,950 --> 00:46:31,979 of very scalable fraud 961 00:46:31,979 --> 00:46:34,869 against tens of thousands, hundreds of thousands 962 00:46:34,869 --> 00:46:37,710 of merchants or consumers, in this case. 963 00:46:37,710 --> 00:46:40,460 So. The long-term goal is clear, better protocol, 964 00:46:40,460 --> 00:46:43,160 the mid-term goal needs to be 965 00:46:43,160 --> 00:46:45,249 individual keys for each of these terminals, 966 00:46:45,249 --> 00:46:48,150 and the short-term goal could be things like, 967 00:46:48,150 --> 00:46:51,529 switch off functionality that you don't actually need. 968 00:46:51,529 --> 00:46:54,079 How many shops do need to print sim card top-ups? 969 00:46:54,079 --> 00:46:55,690 Certainly not every hotel 970 00:46:55,690 --> 00:46:58,660 and other establishments. 971 00:46:58,660 --> 00:47:02,279 How many stores do really need to refund through a card? 972 00:47:02,279 --> 00:47:03,989 Right, maybe you just do refund in cash 973 00:47:03,989 --> 00:47:06,739 and switch off that functionality too. 974 00:47:06,739 --> 00:47:09,539 Similarly, in ZVT, how many merchants 975 00:47:09,539 --> 00:47:10,779 actually want a terminal 976 00:47:10,779 --> 00:47:14,160 to be reconfigurable over a network, 977 00:47:14,160 --> 00:47:17,119 with no confirmation whatsoever on the terminal? 978 00:47:17,119 --> 00:47:19,930 Perhaps a little "is this okay?" message, 979 00:47:19,930 --> 00:47:21,430 and somebody has to press a button 980 00:47:21,430 --> 00:47:23,619 would already fix a lot of this. 981 00:47:23,619 --> 00:47:26,059 So, switch off what's not necessary, 982 00:47:26,059 --> 00:47:28,769 and detect suspicious behaviour, 983 00:47:28,769 --> 00:47:30,529 you can read faster than I can speak, 984 00:47:30,529 --> 00:47:32,140 you probably already went through this list, 985 00:47:32,140 --> 00:47:34,789 so I'll save you that. 986 00:47:34,789 --> 00:47:36,109 I promised a couple of times 987 00:47:36,109 --> 00:47:38,229 a more international perspective on this, 988 00:47:38,229 --> 00:47:39,609 everything we discussed so far 989 00:47:39,609 --> 00:47:44,430 is focused on Germany and some neighbouring countries, 990 00:47:44,430 --> 00:47:47,160 depending on which of these protocols it is, 991 00:47:47,160 --> 00:47:49,630 but we suspect very similar issues 992 00:47:49,630 --> 00:47:52,979 to exist in most other countries. 993 00:47:52,979 --> 00:47:55,829 The ZVT alternative that's used more internationally 994 00:47:55,829 --> 00:47:59,539 is called OPI, the open payment initiative, 995 00:47:59,539 --> 00:48:01,809 and that is a much newer protocol, 996 00:48:01,809 --> 00:48:04,509 that still does not have any encryption though. 997 00:48:04,509 --> 00:48:06,209 Whoever thought, in 2003, 998 00:48:06,209 --> 00:48:08,269 to specify a payment protocol 999 00:48:08,269 --> 00:48:10,589 and not to add in encryption, 1000 00:48:10,589 --> 00:48:11,859 please send me an email, 1001 00:48:11,859 --> 00:48:14,739 I'm curious. 1002 00:48:14,739 --> 00:48:18,890 They did however do the, what would seem smart thing 1003 00:48:18,890 --> 00:48:22,469 of leaving out functionality that nobody needs anyway, 1004 00:48:22,469 --> 00:48:24,579 and in fact functionality that we're exploiting, 1005 00:48:24,579 --> 00:48:27,719 like remote manageability of these terminals. 1006 00:48:27,719 --> 00:48:29,819 Though the few instances of OPI 1007 00:48:29,819 --> 00:48:31,709 we have found in Germany, however, 1008 00:48:31,709 --> 00:48:33,769 they reintroduce that functionality 1009 00:48:33,769 --> 00:48:35,319 as custom extensions, 1010 00:48:35,319 --> 00:48:38,039 so apparently the terminal manufacturers, 1011 00:48:38,039 --> 00:48:42,589 they find it very useful to have remote manageability, 1012 00:48:42,589 --> 00:48:45,640 and if the protocol doesn't give it to them, 1013 00:48:45,640 --> 00:48:48,459 they will reintroduce it as an extension. 1014 00:48:48,459 --> 00:48:50,859 So, exact same level of vulnerability, 1015 00:48:50,859 --> 00:48:53,819 in those few instances that we looked at. 1016 00:48:53,819 --> 00:48:56,819 Of course, the research community at large 1017 00:48:56,819 --> 00:49:01,199 is needed to verify this in different countries 1018 00:49:01,199 --> 00:49:05,289 and just with a little of wireshark on the wire, 1019 00:49:05,289 --> 00:49:08,519 you typically can. 1020 00:49:08,519 --> 00:49:10,119 Similarly for Poseidon, 1021 00:49:10,119 --> 00:49:12,089 as I said earlier, this is just one dialect 1022 00:49:12,089 --> 00:49:17,279 of an ISO standard that originally came from MasterCard and Visa, 1023 00:49:17,279 --> 00:49:20,859 so this the suggested payment backend protocol 1024 00:49:20,859 --> 00:49:23,700 pretty much worldwide, 1025 00:49:23,700 --> 00:49:26,849 and we have seen encryption in some cases, 1026 00:49:26,849 --> 00:49:28,170 no encryption in others, 1027 00:49:28,170 --> 00:49:29,569 it doesn't matter though, 1028 00:49:29,569 --> 00:49:31,359 remember the attack actually goes through 1029 00:49:31,359 --> 00:49:33,650 a full cycle of authentication, 1030 00:49:33,650 --> 00:49:35,430 it establishes all keys well, 1031 00:49:35,430 --> 00:49:37,049 it does all of this correctly, 1032 00:49:37,049 --> 00:49:39,579 but everybody has the same key. 1033 00:49:39,579 --> 00:49:41,630 What we are yet to see is a protocol 1034 00:49:41,630 --> 00:49:43,249 by which you could exchange keys 1035 00:49:43,249 --> 00:49:44,690 with these individual terminals, 1036 00:49:44,690 --> 00:49:47,690 either put a key in or find which key it's using 1037 00:49:47,690 --> 00:49:50,249 to establish individual keys. 1038 00:49:50,249 --> 00:49:52,069 If anybody has more information on that, 1039 00:49:52,069 --> 00:49:54,130 definitely look us up, 1040 00:49:54,130 --> 00:49:56,390 but as far as we're informed, 1041 00:49:56,390 --> 00:49:59,499 there isn't a single instance where this ISO protocol 1042 00:49:59,499 --> 00:50:03,670 actually is used with a meaningful key management protocol 1043 00:50:03,670 --> 00:50:06,859 and where this would at least 1044 00:50:06,859 --> 00:50:08,959 have the foundation to be secure. 1045 00:50:08,959 --> 00:50:12,729 But again, you, the international research community, 1046 00:50:12,729 --> 00:50:16,579 over to you for looking at this in your countries. 1047 00:50:16,579 --> 00:50:19,299 That was that. 1048 00:50:19,299 --> 00:50:24,099 To quickly conclude, two protocols 1049 00:50:24,099 --> 00:50:27,030 used for payment in Germany, 1050 00:50:27,030 --> 00:50:29,419 both of them to be considered insecure, 1051 00:50:29,419 --> 00:50:31,699 and very outdated, 1052 00:50:31,699 --> 00:50:33,160 they both have the same root cause, 1053 00:50:33,160 --> 00:50:35,099 something that fortunately can quickly be fixed, 1054 00:50:35,099 --> 00:50:37,529 so there is time to improve the system 1055 00:50:37,529 --> 00:50:40,229 before actual fraud hits, 1056 00:50:40,229 --> 00:50:41,930 we as a research community 1057 00:50:41,930 --> 00:50:43,140 should keep up to pressure 1058 00:50:43,140 --> 00:50:45,359 for them to actually do that, 1059 00:50:45,359 --> 00:50:46,569 but we as customers, 1060 00:50:46,569 --> 00:50:48,880 we should not believe them anymore 1061 00:50:48,880 --> 00:50:52,609 when they say "you must have given your pin number to somebody, 1062 00:50:52,609 --> 00:50:56,470 hence this fraudulent transaction on your account". 1063 00:50:56,470 --> 00:50:58,440 There've been a number of cases like that 1064 00:50:58,440 --> 00:51:00,279 in Germany this year, 1065 00:51:00,279 --> 00:51:02,190 and I think it's time to show them 1066 00:51:02,190 --> 00:51:05,519 who's really responsible for the security vulnerabilities, 1067 00:51:05,519 --> 00:51:09,259 and for leaving them open for so many years. 1068 00:51:09,259 --> 00:51:10,573 Thank you very much. 1069 00:51:10,573 --> 00:51:34,040 *applause* 1070 00:51:34,040 --> 00:51:35,969 Herald: We have 7 minutes for Q&A. 1071 00:51:35,969 --> 00:51:37,130 Thanks to our speakers again 1072 00:51:37,130 --> 00:51:41,009 for a only theoretical threat on the payment systems, of course, 1073 00:51:41,009 --> 00:51:45,069 strictly lab environment, as the press wrote, 1074 00:51:45,069 --> 00:51:48,319 please leave quickly and quietly through the side doors now 1075 00:51:48,319 --> 00:51:50,839 so we have 5 minutes of Q&A. 1076 00:51:50,839 --> 00:51:52,869 And, mike 2 starts. 1077 00:51:52,869 --> 00:51:54,770 Q: How did you handle the question of disclosure, 1078 00:51:54,770 --> 00:51:56,429 so did you do full disclosure, 1079 00:51:56,429 --> 00:51:57,329 responsible disclosure, 1080 00:51:57,329 --> 00:52:01,299 how much time did you give them? 1081 00:52:01,299 --> 00:52:04,959 Nohl: We went through responsible disclosure I guess, 1082 00:52:04,959 --> 00:52:07,130 meaning that we in detail tried to explain 1083 00:52:07,130 --> 00:52:09,279 all of these attacks to an audience 1084 00:52:09,279 --> 00:52:15,899 that we thought could fix this, about a month ago. Right. 1085 00:52:15,899 --> 00:52:17,719 Q: And have you seen any reaction to that? 1086 00:52:17,719 --> 00:52:19,599 Like, have they tried fixing it? 1087 00:52:19,599 --> 00:52:22,170 Nohl: I'm sure somebody's working on a fix, 1088 00:52:22,170 --> 00:52:26,499 but nobody would tell me. 1089 00:52:26,499 --> 00:52:29,519 Herald: Okay, and we have one question from the Internet. 1090 00:52:29,519 --> 00:52:32,059 Signal angel: So, can you say if there's an easy fix 1091 00:52:32,059 --> 00:52:37,800 like just flashing a new firmware into all terminals? 1092 00:52:37,800 --> 00:52:39,790 Bräunlein: Like, flashing firmware to all terminals? 1093 00:52:39,790 --> 00:52:42,289 Nohl: It's an easy fix. 1094 00:52:42,289 --> 00:52:44,950 Bräunlein: Yeah, you have shown the fixes. 1095 00:52:44,950 --> 00:52:47,759 These are, the difference between this research 1096 00:52:47,759 --> 00:52:49,930 and the research done 3 years before 1097 00:52:49,930 --> 00:52:53,749 is that this are now flaws in the protocol, 1098 00:52:53,749 --> 00:52:55,769 so these need new protocols, 1099 00:52:55,769 --> 00:52:59,629 new versions and new... yeah. That's it. 1100 00:52:59,629 --> 00:53:01,989 So these are no implementation flaws right now. 1101 00:53:01,989 --> 00:53:04,059 Q: But would you have to scrap all terminals 1102 00:53:04,059 --> 00:53:08,479 and buy or construct new ones? 1103 00:53:08,479 --> 00:53:10,589 Nohl: I think the honest answer is 1104 00:53:10,589 --> 00:53:13,959 that criminals are slow too, 1105 00:53:13,959 --> 00:53:17,779 so this will have to be a somewhat longer journey 1106 00:53:17,779 --> 00:53:21,019 in which we first replace these system-wide keys 1107 00:53:21,019 --> 00:53:22,130 by individual keys, 1108 00:53:22,130 --> 00:53:24,160 that would already help tremendously 1109 00:53:24,160 --> 00:53:26,269 in making it less attractive 1110 00:53:26,269 --> 00:53:28,700 to do these types of attack, 1111 00:53:28,700 --> 00:53:31,079 but then in the meantime work on better protocols 1112 00:53:31,079 --> 00:53:33,739 so we don't keep finding ourselves in this situation 1113 00:53:33,739 --> 00:53:36,599 where it would take years to fix protocols, 1114 00:53:36,599 --> 00:53:39,539 well let's use those years ahead of us to do that. 1115 00:53:39,539 --> 00:53:40,480 Q: Thanks. 1116 00:53:40,480 --> 00:53:42,680 Herald: Okay. Microphone 8, please. 1117 00:53:42,680 --> 00:53:44,589 Q: How many tries did it take 1118 00:53:44,589 --> 00:53:46,709 to clone the keys of the terminal, 1119 00:53:46,709 --> 00:53:48,489 how many boxes did you have to blow? 1120 00:53:48,489 --> 00:53:50,609 *Nohl laughs* 1121 00:53:50,609 --> 00:53:52,539 Dexter: 3 or so. 1122 00:53:52,539 --> 00:53:53,539 Nohl: Yeah. 1123 00:53:53,539 --> 00:53:57,979 Dexter: I mean the first one was surprisingly an immediate success, 1124 00:53:57,979 --> 00:54:01,729 we managed to withdraw the SRAM without destroying it, 1125 00:54:01,729 --> 00:54:03,589 second one, we broke immediately, 1126 00:54:03,589 --> 00:54:06,529 and the third one had issues, 1127 00:54:06,529 --> 00:54:09,399 but we managed to fix it. 1128 00:54:09,399 --> 00:54:14,009 Q: So you didn't wipe any keys bypassing the mesh? 1129 00:54:14,009 --> 00:54:16,369 Dexter: I didn't understand acoustically, sorry. 1130 00:54:16,369 --> 00:54:17,819 Q: When you're bypassing the mesh, 1131 00:54:17,819 --> 00:54:19,539 you got that the first try? 1132 00:54:19,539 --> 00:54:20,940 Bräunlein: Yeah, I tried it the first time. 1133 00:54:20,940 --> 00:54:21,440 Q: Wow. 1134 00:54:21,440 --> 00:54:22,690 Bräunlein: So like, I think... 1135 00:54:22,690 --> 00:54:23,200 Dexter: Yeah. 1136 00:54:23,200 --> 00:54:24,489 Bräunlein: Bit of preparation, 1137 00:54:24,489 --> 00:54:26,609 and then one hour of actual work. 1138 00:54:26,609 --> 00:54:28,150 Nohl: Well, he destroyed the first terminal 1139 00:54:28,150 --> 00:54:30,829 but for just looking at how it's built, right? 1140 00:54:30,829 --> 00:54:33,119 Dexter: Yeah, he knew how it was made up 1141 00:54:33,119 --> 00:54:36,489 because we took a few apart before, of course. 1142 00:54:36,489 --> 00:54:39,160 But not with intention to do that, 1143 00:54:39,160 --> 00:54:40,150 just because they broke, 1144 00:54:40,150 --> 00:54:41,259 and then we took it apart 1145 00:54:41,259 --> 00:54:43,529 to look up, to read out the flash, 1146 00:54:43,529 --> 00:54:45,109 this bug bonded thingy 1147 00:54:45,109 --> 00:54:46,989 that was one of the very first ones, 1148 00:54:46,989 --> 00:54:49,169 that broke. 1149 00:54:49,169 --> 00:54:52,240 Herald: Okay, microphone 7, please. 1150 00:54:52,240 --> 00:54:54,140 Q: Would you please briefly describe 1151 00:54:54,140 --> 00:54:56,699 what will do the terminal in case, 1152 00:54:56,699 --> 00:55:00,339 if some transaction wasn't processed by the bank, 1153 00:55:00,339 --> 00:55:02,619 what kind of information it will store 1154 00:55:02,619 --> 00:55:06,210 in the memory and how long? 1155 00:55:06,210 --> 00:55:08,059 Bräunlein: It will store the error. 1156 00:55:08,059 --> 00:55:10,449 Nohl: I don't think the terminal stores anything, 1157 00:55:10,449 --> 00:55:11,789 it's pretty much stateless. 1158 00:55:11,789 --> 00:55:14,769 It receives a command, 1159 00:55:14,769 --> 00:55:16,209 looks up its configuration, 1160 00:55:16,209 --> 00:55:17,390 like terminal ID, 1161 00:55:17,390 --> 00:55:19,989 it pushes it down to HSM to get signed 1162 00:55:19,989 --> 00:55:21,249 or get a pin number, 1163 00:55:21,249 --> 00:55:22,959 pushes it over Poseidon, 1164 00:55:22,959 --> 00:55:25,160 and forgets all about that transaction. 1165 00:55:25,160 --> 00:55:31,460 Q: So it's not trying to resend the transaction again somehow later? 1166 00:55:31,460 --> 00:55:33,510 Nohl: Um, good question. 1167 00:55:33,510 --> 00:55:37,410 Bräunlein: So this is not part of the attacks we have demonstrated 1168 00:55:37,410 --> 00:55:39,549 but what happens is that, 1169 00:55:39,549 --> 00:55:41,630 normally you would do an end of day command, 1170 00:55:41,630 --> 00:55:43,719 or a Kassenschnitt in Germany, 1171 00:55:43,719 --> 00:55:48,040 where all the transactions that have been accumulated throughout the day 1172 00:55:48,040 --> 00:55:50,170 will be sent to the payment processor, 1173 00:55:50,170 --> 00:55:52,150 and this is the exact moment 1174 00:55:52,150 --> 00:55:54,049 where all these transactions are then sent 1175 00:55:54,049 --> 00:55:57,079 by the transaction processor to the bank. 1176 00:55:57,079 --> 00:55:58,449 So at this point for example, 1177 00:55:58,449 --> 00:56:01,829 no reversal is anymore possible, 1178 00:56:01,829 --> 00:56:06,309 reversal that'll reverse one purchase on the same day, 1179 00:56:06,309 --> 00:56:08,749 because then the bank has already the information, 1180 00:56:08,749 --> 00:56:11,259 and then no information is stored anymore 1181 00:56:11,259 --> 00:56:12,709 on the terminal, 1182 00:56:12,709 --> 00:56:14,790 if this one was successful. 1183 00:56:14,790 --> 00:56:16,309 Q: Okay, thank you. 1184 00:56:16,309 --> 00:56:18,229 Herald: One more remote question, please. 1185 00:56:18,229 --> 00:56:21,670 Signal angel: So is the communication that you use 1186 00:56:21,670 --> 00:56:23,049 in the man in the middle attacks 1187 00:56:23,049 --> 00:56:25,849 also susceptible to replay attacks? 1188 00:56:25,849 --> 00:56:28,440 Can you just do it without a terminal 1189 00:56:28,440 --> 00:56:29,869 if you recorded the conversation 1190 00:56:29,869 --> 00:56:33,790 between terminal and processing server? 1191 00:56:33,790 --> 00:56:37,209 Nohl: Sure, we can inject messages, ZVT messages, 1192 00:56:37,209 --> 00:56:40,299 most of them are not actually protected with a MAC, 1193 00:56:40,299 --> 00:56:43,390 for instance you can query a magstripe 1194 00:56:43,390 --> 00:56:44,859 with no protection, 1195 00:56:44,859 --> 00:56:46,930 however there needs to be somebody in the store 1196 00:56:46,930 --> 00:56:49,529 who expects you to do that, right? 1197 00:56:49,529 --> 00:56:51,489 So it's convenient to just be man in the middle 1198 00:56:51,489 --> 00:56:52,569 in an actual transaction 1199 00:56:52,569 --> 00:56:56,130 because you know there's somebody waiting for you to stick in a card, 1200 00:56:56,130 --> 00:56:58,759 there's a customer waiting to stick in that card, 1201 00:56:58,759 --> 00:57:02,739 so you wouldn't get that from just sending random messages, 1202 00:57:02,739 --> 00:57:05,779 there's just nobody there with a card. 1203 00:57:05,779 --> 00:57:07,319 Herald: Okay, one last question, 1204 00:57:07,319 --> 00:57:09,459 a quick question from microphone 1. 1205 00:57:09,459 --> 00:57:11,449 Q: Yes, you said there's a possibility 1206 00:57:11,449 --> 00:57:15,099 to give an individual key to each terminal. 1207 00:57:15,099 --> 00:57:18,789 So you have an identical terminal to another one, 1208 00:57:18,789 --> 00:57:23,039 so if the payment processor sends out individual keys to each terminal, 1209 00:57:23,039 --> 00:57:25,560 and there are two of one terminal, 1210 00:57:25,560 --> 00:57:27,189 what will happen? 1211 00:57:27,189 --> 00:57:28,239 Nohl: Yeah, good question. 1212 00:57:28,239 --> 00:57:31,940 So if the fraudsters first take over all the terminals, 1213 00:57:31,940 --> 00:57:33,709 and you then send individual keys, 1214 00:57:33,709 --> 00:57:34,380 it's not going to help, 1215 00:57:34,380 --> 00:57:37,550 you have to be ahead of the bad guys here. 1216 00:57:42,730 --> 00:57:46,561 Herald: Okay! Thanks again to Karsten, Fabian and Dexter. 1217 00:57:46,561 --> 00:57:49,500 *applause* 1218 00:57:49,500 --> 00:57:59,940 *postroll music*