1
00:00:00,000 --> 00:00:09,624
<i>preroll music</i>

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.
<i>laughter</i>

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
<i>laughter</i>

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
<i>applause</i>
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
<i>applause</i>

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
<i>laughter</i>

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
<i>laughter</i>

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
<i>applause</i>

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
<i>laughter, applause</i>

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
<i>laughter, applause</i>

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
<i>laughter</i>

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
<i>laughter, applause, hooting</i>

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
<i>applause</i>

577
00:26:54,480 --> 00:27:02,580
Second one.
<i>applause</i>

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
<i>laughter</i>

600
00:27:56,770 --> 00:28:01,788
Alright, the service password, hmm.

601
00:28:10,468 --> 00:28:18,580
<i>laughter</i>

602
00:28:18,580 --> 00:28:24,651
<i>laughter, applause</i>

603
00:28:27,570 --> 00:28:29,770
<i>Bräunlein shrieks</i>

604
00:28:36,990 --> 00:28:40,089
<i>laughter</i>

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
<i>applause</i>

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
<i>laughter</i>

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
<i>laughter</i>
<i>applause</i>

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
<i>laughter</i>

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
<i>laughter</i>

641
00:31:33,302 --> 00:31:35,020
100? Yeah, 100 sounds good.

642
00:31:35,020 --> 00:31:38,063
<i>laughter</i>

643
00:31:45,727 --> 00:32:06,820
<i>applause</i>

644
00:32:06,820 --> 00:32:07,409
Ach!

645
00:32:07,409 --> 00:32:12,279
<i>laughter</i>

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
<i>laughter</i>

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
<i>laughter</i>

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
<i>laughter</i>
Again, those people at the banks, right?

705
00:34:39,709 --> 00:34:50,029
<i>applause</i>

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
<i>laughter, applause</i>

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
<i>laughter</i>

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
<i>applause</i>

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
<i>applause</i>

874
00:42:38,190 --> 00:42:46,710
Yeah, so much for the...
<i>applause</i>

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
<i>applause</i>

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
<i>applause</i>

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
<i>Nohl laughs</i>

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,866
<i>applause</i>

1218
00:57:49,866 --> 00:57:53,266
<i>postroll music</i>

1219
00:57:53,266 --> 00:58:01,000
subtitles created by c3subtitles.de
Join, and help us!