WEBVTT
00:00:00.000 --> 00:00:09.624
preroll music
00:00:09.624 --> 00:00:11.789
Herald: So, welcome everybody,
00:00:11.789 --> 00:00:14.429
the next talk is under the topic
00:00:14.429 --> 00:00:18.550
"shoplifting", uh, "shopshifting", sorry.
laughter
00:00:18.550 --> 00:00:20.480
Shoplifting is something completely different,
00:00:20.480 --> 00:00:23.279
it has nothing to do with shopshifting,
00:00:23.279 --> 00:00:25.250
the outcome is the same.
00:00:25.250 --> 00:00:26.779
laughter
00:00:26.779 --> 00:00:29.410
And I present to you Karsten Nohl,
00:00:29.410 --> 00:00:33.330
Fabian Bräunlein, and Dexter from Berlin
00:00:33.330 --> 00:00:35.570
Some of you may have already seen
00:00:35.570 --> 00:00:38.230
the one only other face here,
00:00:38.230 --> 00:00:40.550
and you may have heard of things like
00:00:40.550 --> 00:00:44.140
the Mifare RFID problems that we had,
00:00:44.140 --> 00:00:48.120
the gsm sim card hacks,
and things like BadUSB
00:00:48.120 --> 00:00:50.120
and these people and people around them
00:00:50.120 --> 00:00:52.510
are all responsible for that.
00:00:52.510 --> 00:00:55.520
So, give them a warm applause, and...
00:00:55.520 --> 00:01:04.630
applause
stage is yours!
00:01:04.630 --> 00:01:06.740
Nohl: Thank you very much.
00:01:06.740 --> 00:01:09.580
It's great to be back,
looking at yet another technology
00:01:09.580 --> 00:01:13.540
and searching for
security vulnerabilities.
00:01:13.540 --> 00:01:15.750
We focus our research on technologies
00:01:15.750 --> 00:01:19.300
that most of us use on a daily basis,
00:01:19.300 --> 00:01:21.780
that are typically outdated,
00:01:21.780 --> 00:01:24.970
very widely deployed, and insecure.
00:01:24.970 --> 00:01:26.680
Took us many years to finally come around
00:01:26.680 --> 00:01:28.650
to look at payment protocols,
00:01:28.650 --> 00:01:31.810
which we'll be discussing today.
00:01:31.810 --> 00:01:33.640
In part, it took so long because
00:01:33.640 --> 00:01:37.220
we just didn't think
we would find anything.
00:01:37.220 --> 00:01:41.350
After all, some of the best people
in our industry work at banks,
00:01:41.350 --> 00:01:45.600
and banks have among the most
developed risk management.
00:01:45.600 --> 00:01:49.390
So, at least in my experience,
00:01:49.390 --> 00:01:53.420
banks are good at reacting
to security evolution.
00:01:53.420 --> 00:01:56.430
That's what I thought up until
maybe the middle of this year,
00:01:56.430 --> 00:01:58.020
when we started this research
00:01:58.020 --> 00:02:01.909
and we're here now today to take
this preconception away
00:02:01.909 --> 00:02:04.270
from whoever may still be
00:02:04.270 --> 00:02:05.850
suffering from this illusion that
00:02:05.850 --> 00:02:09.389
banks actually do keep
their systems very secure,
00:02:09.389 --> 00:02:11.090
at least we found in two cases,
00:02:11.090 --> 00:02:14.209
two very widely deployed protocols,
00:02:14.209 --> 00:02:17.579
that there's gaping holes and have been
for a couple of years.
00:02:17.579 --> 00:02:20.739
Both of these protocols are
involved in payment,
00:02:20.739 --> 00:02:22.159
that is if you go into a store
00:02:22.159 --> 00:02:23.659
and you pay with a card,
00:02:23.659 --> 00:02:25.260
those protocols are invoked,
00:02:25.260 --> 00:02:26.659
at least in Germany,
00:02:26.659 --> 00:02:30.749
and protocols are called ZVT and Poseidon.
00:02:30.749 --> 00:02:33.430
They're used for very different purposes,
00:02:33.430 --> 00:02:36.930
but they both terminate at
a payment terminal.
00:02:36.930 --> 00:02:39.480
The one protocol ZVT is spoken between
00:02:39.480 --> 00:02:42.049
a cashier station and
this payment terminal,
00:02:42.049 --> 00:02:44.450
so somebody would scan some items
00:02:44.450 --> 00:02:47.459
or type in some amount
into this cashier station,
00:02:47.459 --> 00:02:49.529
and then say, "now please pay",
00:02:49.529 --> 00:02:52.499
and a command is sent to
the payment terminal,
00:02:52.499 --> 00:02:53.919
which then requests a card,
00:02:53.919 --> 00:02:55.959
and perhaps a pin number,
00:02:55.959 --> 00:02:58.459
for most transactions in Germany,
00:02:58.459 --> 00:03:01.209
and then in turns invokes another protocol
00:03:01.209 --> 00:03:04.609
that this payment terminal speaks with
a payment processor.
00:03:04.609 --> 00:03:06.989
That's a service provider that connects
00:03:06.989 --> 00:03:09.359
these terminals to banks,
00:03:09.359 --> 00:03:13.579
and basically facilitates
the actual payment.
00:03:13.579 --> 00:03:15.519
And then the payment processor
or the bank,
00:03:15.519 --> 00:03:18.549
they validate the account details
and so forth,
00:03:18.549 --> 00:03:19.680
they send a confirmation,
00:03:19.680 --> 00:03:22.359
and that confirmation again over ZVT
00:03:22.359 --> 00:03:25.560
is sent back to the cashier station.
00:03:25.560 --> 00:03:29.019
That is, in a nutshell, how
a payment transaction works.
00:03:29.019 --> 00:03:32.069
So it's based on two protocols,
00:03:32.069 --> 00:03:35.129
both of them fairly old,
00:03:35.129 --> 00:03:39.059
and probably by virtue of being so old,
00:03:39.059 --> 00:03:40.909
very widely deployed.
00:03:40.909 --> 00:03:43.249
In Germany, you will hardly find anything
00:03:43.249 --> 00:03:46.489
other than these two protocols being used.
00:03:46.489 --> 00:03:47.949
We'll look at an international angle
00:03:47.949 --> 00:03:50.329
towards the end of the talk,
00:03:50.329 --> 00:03:51.519
just a short summary,
00:03:51.519 --> 00:03:53.529
most of these problems will probably exist
00:03:53.529 --> 00:03:57.599
in most other countries as well.
00:03:57.599 --> 00:04:01.230
So let's in turn look at ZVT
and then Poseidon
00:04:01.230 --> 00:04:04.139
to identify their security issues.
00:04:04.139 --> 00:04:05.299
Starting with ZVT,
00:04:05.299 --> 00:04:07.079
this is again the protocol that's spoken
00:04:07.079 --> 00:04:11.309
in the shop, between a cashier station
and a terminal,
00:04:11.309 --> 00:04:14.760
but in almost all cases,
over a network connection.
00:04:14.760 --> 00:04:17.048
Very old systems would use
a serial cable,
00:04:17.048 --> 00:04:19.690
but today a network is used.
00:04:19.690 --> 00:04:22.300
So assuming that a fraudster
00:04:22.300 --> 00:04:24.819
somehow can get access to a local network,
00:04:24.819 --> 00:04:26.509
by plugging into some open ports,
00:04:26.509 --> 00:04:28.810
or by even being a customer at your hotel
00:04:28.810 --> 00:04:33.830
and just being connected to the same wifi
as your cashier system,
00:04:33.830 --> 00:04:35.930
what can this attacker do?
00:04:35.930 --> 00:04:37.860
Let's start with something simple
00:04:37.860 --> 00:04:42.699
that doesn't even really
require any hacking.
00:04:42.699 --> 00:04:44.479
In this case, somebody wants to steal
00:04:44.479 --> 00:04:47.870
the magnetic stripe details of the card.
00:04:47.870 --> 00:04:48.870
So the way that it should work
00:04:48.870 --> 00:04:51.729
is that the cashier station
sends a command
00:04:51.729 --> 00:04:52.599
to the payment terminal,
00:04:52.599 --> 00:04:53.879
and then gets a confirmation back
00:04:53.879 --> 00:04:55.960
after some processing.
00:04:55.960 --> 00:04:57.710
Now what the attacker does in this case
00:04:57.710 --> 00:05:01.069
is get in between those two,
00:05:01.069 --> 00:05:02.780
in their connection.
00:05:02.780 --> 00:05:05.400
Through, just traditional ARP spoofing.
00:05:05.400 --> 00:05:07.259
So, you proxy the connection
00:05:07.259 --> 00:05:11.439
between the cashier station
and the payment terminal,
00:05:11.439 --> 00:05:13.539
sitting in the local network again.
00:05:13.539 --> 00:05:16.129
We'll look at Internet-wide attacks
00:05:16.129 --> 00:05:17.539
in a few minutes, but for now
00:05:17.539 --> 00:05:19.610
we're talking about inside the shop,
00:05:19.610 --> 00:05:22.639
or in wifi range of that shop.
00:05:22.639 --> 00:05:23.879
So you ARP spoof
00:05:23.879 --> 00:05:28.180
and you receive that authorisation request
00:05:28.180 --> 00:05:29.960
that's supposed to be sent to
the payment terminal.
00:05:29.960 --> 00:05:31.840
What the cashier station basically says,
00:05:31.840 --> 00:05:32.919
"There's a customer here,
00:05:32.919 --> 00:05:34.780
the customer wants to pay something,
00:05:34.780 --> 00:05:36.509
please authorise the payment."
00:05:36.509 --> 00:05:39.539
Right? We take that command
00:05:39.539 --> 00:05:40.680
and do not forward it,
00:05:40.680 --> 00:05:42.229
but instead send another command,
00:05:42.229 --> 00:05:45.550
which basically says, "read a card".
00:05:45.550 --> 00:05:47.949
So the terminal will then display
00:05:47.949 --> 00:05:49.159
what the customer expects,
00:05:49.159 --> 00:05:50.569
"please insert a card",
00:05:50.569 --> 00:05:54.680
customer does so, and the
magnetic stripe information is read,
00:05:54.680 --> 00:05:57.900
and sent back over the network
to the attacker.
00:05:57.900 --> 00:06:00.599
No transaction has been done yet.
00:06:00.599 --> 00:06:05.340
Immediately following
these magnetic stripe details,
00:06:05.340 --> 00:06:06.280
the attacker would then send
00:06:06.280 --> 00:06:09.769
an actual authorisation request message
00:06:09.769 --> 00:06:12.750
supplying the magnetic stripe info.
00:06:12.750 --> 00:06:15.069
So, instead of asking for a card,
00:06:15.069 --> 00:06:16.949
the payment terminal just takes
this magstripe now,
00:06:16.949 --> 00:06:20.240
and goes through the transaction.
00:06:20.240 --> 00:06:21.270
So two things happen.
00:06:21.270 --> 00:06:24.900
First, the attacker did receive
a copy of the magstripe,
00:06:24.900 --> 00:06:26.780
second, the actual transaction,
00:06:26.780 --> 00:06:28.960
the intended transaction did go through.
00:06:28.960 --> 00:06:31.120
So neither the customer nor the merchant
00:06:31.120 --> 00:06:32.780
sees any different.
00:06:32.780 --> 00:06:35.900
But the attacker does have
a copy of the magstripe now.
00:06:35.900 --> 00:06:38.030
And then, countries where
magstripe is enough,
00:06:38.030 --> 00:06:40.879
let's say US, prior to chip-and-pin,
00:06:40.879 --> 00:06:44.469
this is enough to completely
clone the card.
00:06:44.469 --> 00:06:46.930
Fortunately, most other countries
00:06:46.930 --> 00:06:49.099
do require pin numbers,
00:06:49.099 --> 00:06:52.699
making this attack ineffective.
00:06:52.699 --> 00:06:55.360
But perhaps motivating
a slightly improved attack.
00:06:55.360 --> 00:06:57.979
So, let's say the fraudster wanted
00:06:57.979 --> 00:07:00.069
to also steal the pin number remotely.
00:07:00.069 --> 00:07:02.139
Right? Magstripe and pin number,
00:07:02.139 --> 00:07:06.979
that's really all you need
to pay in Germany, say.
00:07:06.979 --> 00:07:09.930
So the way pin transactions are
supposed to work,
00:07:09.930 --> 00:07:12.229
they are much more secure,
00:07:12.229 --> 00:07:14.099
well, they're secured at all,
00:07:14.099 --> 00:07:16.050
versus magstripe, which isn't secure,
00:07:16.050 --> 00:07:17.520
so the top part of this slide
00:07:17.520 --> 00:07:23.690
shows how a pin transaction is
supposed to work.
00:07:23.690 --> 00:07:28.680
Again, over ZVT, the cashier desk
00:07:28.680 --> 00:07:32.240
or whatever's speaking
to the terminal in the store,
00:07:32.240 --> 00:07:34.020
sends an authorisation request
00:07:34.020 --> 00:07:35.469
this time specifically saying
00:07:35.469 --> 00:07:37.560
"do require pin number"
00:07:37.560 --> 00:07:39.830
or perhaps that is even configured
in the terminal,
00:07:39.830 --> 00:07:42.199
to always require pin number.
00:07:42.199 --> 00:07:44.449
Either way, inside the terminal,
00:07:44.449 --> 00:07:46.460
all the security magic happens now.
00:07:46.460 --> 00:07:49.020
There's different components
of the terminal.
00:07:49.020 --> 00:07:52.699
There's a main CPU that does
all the network communication,
00:07:52.699 --> 00:07:55.300
both ZVT and Poseidon,
00:07:55.300 --> 00:07:56.849
which is supposed to be somewhat secure
00:07:56.849 --> 00:07:59.409
but really isn't, as, by the way,
00:07:59.409 --> 00:08:01.020
some research a couple of years has shown,
00:08:01.020 --> 00:08:02.610
that specifically looked at the security
00:08:02.610 --> 00:08:04.370
of one of these terminals,
00:08:04.370 --> 00:08:05.509
but that's not the topic of today,
00:08:05.509 --> 00:08:09.090
we're looking at the standard's security.
00:08:09.090 --> 00:08:10.289
So inside this terminal,
00:08:10.289 --> 00:08:14.439
there's also a hardware
security module, an HSM,
00:08:14.439 --> 00:08:18.360
and that HSM does all the heavy lifting
00:08:18.360 --> 00:08:21.449
when it comes to
cryptographic keys and so forth.
00:08:21.449 --> 00:08:23.249
The HSM is also directly connected
00:08:23.249 --> 00:08:28.199
to the display and the pin pad
of the machine.
00:08:28.199 --> 00:08:31.090
So you tell the HSM, inside the terminal,
00:08:31.090 --> 00:08:32.809
"do a pin transaction",
00:08:32.809 --> 00:08:34.240
it shows something on the display,
00:08:34.240 --> 00:08:36.830
"enter pin", it receives the input,
00:08:36.830 --> 00:08:39.220
and instead of giving out the pin number
00:08:39.220 --> 00:08:41.530
to the less secure side of the terminal
00:08:41.530 --> 00:08:45.130
it encrypts it with a key that only
the payment processor
00:08:45.130 --> 00:08:46.540
is supposed to have.
00:08:46.540 --> 00:08:49.210
So, the main CPU,
00:08:49.210 --> 00:08:51.540
or anybody really outside of the HSM,
00:08:51.540 --> 00:08:53.280
does not see the pin number.
00:08:53.280 --> 00:08:56.690
That's how things are supposed to work.
00:08:56.690 --> 00:08:58.780
Now, the lower part of the slide
00:08:58.780 --> 00:09:01.070
develops an attack idea with one catch,
00:09:01.070 --> 00:09:03.460
we'll resolve that in a minute though.
00:09:03.460 --> 00:09:06.400
This attack here would use
a different message
00:09:06.400 --> 00:09:08.800
to actually receive the pin number.
00:09:08.800 --> 00:09:11.890
So instead of saying,
"do a pin transaction",
00:09:11.890 --> 00:09:16.500
it would just say "display some text
and give me the input".
00:09:16.500 --> 00:09:17.780
That would work beautifully, right,
00:09:17.780 --> 00:09:20.790
so you display the text
"give me the pin number"
00:09:20.790 --> 00:09:24.910
and whatever's typed in,
you get that input.
00:09:24.910 --> 00:09:27.230
This very flexible functionality
00:09:27.230 --> 00:09:29.270
we don't really know what it's
ever used for,
00:09:29.270 --> 00:09:30.510
we've never seen it,
00:09:30.510 --> 00:09:33.100
but we're suspecting it's used
for things like,
00:09:33.100 --> 00:09:36.060
asking customers for their zip code
or something, right?
00:09:36.060 --> 00:09:40.150
Type something in and
send it over the network.
00:09:40.150 --> 00:09:41.200
And we've partly never seen this
00:09:41.200 --> 00:09:42.740
because it really can't be used,
00:09:42.740 --> 00:09:45.120
these messages need to be signed.
00:09:45.120 --> 00:09:45.900
We don't know who's supposed
00:09:45.900 --> 00:09:47.430
to sign these messages,
00:09:47.430 --> 00:09:49.010
we've tried to find a person
00:09:49.010 --> 00:09:50.890
but nobody feels responsible.
00:09:50.890 --> 00:09:53.450
So there's some functionality
in the standard here
00:09:53.450 --> 00:09:55.880
that's never used and
nobody knows how to use it.
00:09:55.880 --> 00:09:58.020
The use of this cryptographic signature
00:09:58.020 --> 00:10:01.930
on the slide called message
authentication code, MAC,
00:10:01.930 --> 00:10:03.670
that's required and it's actually
00:10:03.670 --> 00:10:05.340
checked by the HSM.
00:10:05.340 --> 00:10:09.620
So if you want to do your "please
enter zip code" scheme
00:10:09.620 --> 00:10:10.680
across all your stores,
00:10:10.680 --> 00:10:12.590
you've got to get your message signed,
00:10:12.590 --> 00:10:15.110
and that signed message then
works across all terminals.
00:10:15.110 --> 00:10:19.870
And if we want our "please enter
pin number" message to be shown,
00:10:19.870 --> 00:10:21.270
we've got to get to sign,
00:10:21.270 --> 00:10:24.310
or find some way to sign this ourselves
00:10:24.310 --> 00:10:26.180
and no entering the real hacking
00:10:26.180 --> 00:10:29.840
so I'm handing over to Fabian
00:10:29.840 --> 00:10:31.940
who did almost all this research,
00:10:31.940 --> 00:10:35.810
so that was just my attempt to introduce
these two guys here.
00:10:35.810 --> 00:10:37.530
Bräunlein: Thank you.
00:10:37.530 --> 00:10:43.650
applause
00:10:43.650 --> 00:10:46.030
Alright, so, to find valid MACs
00:10:46.030 --> 00:10:47.340
for arbitrary texts,
00:10:47.340 --> 00:10:50.900
we exploited a time-based
side-channel vulnerability
00:10:50.900 --> 00:10:53.980
within one HSM implementation.
00:10:53.980 --> 00:10:55.880
So, for those to work reliably,
00:10:55.880 --> 00:10:57.740
we had to have the ability to
00:10:57.740 --> 00:11:01.160
send messages directly to the HSM.
00:11:01.160 --> 00:11:03.120
To accomplish that, we used
00:11:03.120 --> 00:11:08.500
an active JTAG interface we found
for the main CPU on the PCP,
00:11:08.500 --> 00:11:11.370
and loaded our custom assembly program.
00:11:11.370 --> 00:11:14.780
What this wanted was just sending messages
00:11:14.780 --> 00:11:18.800
with our texts and some MACs to the HSM,
00:11:18.800 --> 00:11:22.600
and stop the time that
it needs to respond.
00:11:22.600 --> 00:11:26.930
So, we are doing that and are trying
every single possibility,
00:11:26.930 --> 00:11:31.220
every single value for the first byte
of this 8-byte MAC.
00:11:31.220 --> 00:11:33.180
When you do that, you will see that...
00:11:33.180 --> 00:11:35.270
so, that's a bit oversimplified,
00:11:35.270 --> 00:11:36.710
but you will get the gist.
00:11:36.710 --> 00:11:40.070
You will see that for
one particular value,
00:11:40.070 --> 00:11:42.500
the HSM needs a bit longer to respond,
00:11:42.500 --> 00:11:46.520
so like, just 5 CPU cycles within the HSM.
00:11:46.520 --> 00:11:51.450
Now you already have the first byte
of this 8-byte MAC,
00:11:51.450 --> 00:11:55.380
you can set this and do the same thing
for the second one.
00:11:55.380 --> 00:11:58.120
So, why does that work?
00:11:58.120 --> 00:12:01.830
This works because they use
a symmetric key
00:12:01.830 --> 00:12:03.680
for the calculation of the MAC
00:12:03.680 --> 00:12:05.330
within the HSM.
00:12:05.330 --> 00:12:07.370
There is a key that the payment
processor has,
00:12:07.370 --> 00:12:09.320
and this is stored inside the HSM,
00:12:09.320 --> 00:12:14.920
which is able to calculate
the correct MAC for any text.
00:12:14.920 --> 00:12:15.860
And what happens next,
00:12:15.860 --> 00:12:17.800
so this is the first minor issue
00:12:17.800 --> 00:12:20.810
because you should use
asymmetric cryptography.
00:12:20.810 --> 00:12:22.260
The next thing is,
00:12:22.260 --> 00:12:25.370
that the comparison
between the correct MAC
00:12:25.370 --> 00:12:28.560
that has been calculated within the HSM,
00:12:28.560 --> 00:12:32.040
and the MAC we have input through
this display text message,
00:12:32.040 --> 00:12:34.730
is compared byte by byte.
00:12:34.730 --> 00:12:37.080
So it checks if the first byte
of the input message
00:12:37.080 --> 00:12:39.500
matches the first byte of the correct MAC
00:12:39.500 --> 00:12:40.440
and if it doesn't match,
00:12:40.440 --> 00:12:42.100
it will return immediately,
00:12:42.100 --> 00:12:45.640
if it matches, it will try to compare
the second byte,
00:12:45.640 --> 00:12:47.160
and if that doesn't match
it will return immediately,
00:12:47.160 --> 00:12:51.250
so, this time it needs to check
one more byte,
00:12:51.250 --> 00:12:52.760
we can measure,
00:12:52.760 --> 00:12:55.140
with some more work.
00:12:55.140 --> 00:12:58.190
So, with this thing,
00:12:58.190 --> 00:13:01.920
with the correct MAC for the
"please enter pin" screen,
00:13:01.920 --> 00:13:04.220
we can give you a quick demonstration
00:13:04.220 --> 00:13:06.170
of how this works in real life.
00:13:06.170 --> 00:13:09.330
And for that we would need the GoPro...
00:13:09.330 --> 00:13:15.540
that you already have.
00:13:15.540 --> 00:13:17.400
Ah, the GoPro, yeah.
00:13:17.400 --> 00:13:20.080
laughter
00:13:20.080 --> 00:13:24.240
So, this is the setup here.
00:13:24.240 --> 00:13:27.810
Here we need the computer with
the green text on the black terminal.
00:13:27.810 --> 00:13:30.870
Alright. Here we have a normal
cashier register,
00:13:30.870 --> 00:13:33.250
it's some Windows XP software running,
00:13:33.250 --> 00:13:35.880
here we have the actual payment terminal,
00:13:35.880 --> 00:13:40.750
these two are connected through
this Fritz box standing here,
00:13:40.750 --> 00:13:43.440
just some normal internal home network.
00:13:43.440 --> 00:13:47.300
Now, there's also another
participant in the setup,
00:13:47.300 --> 00:13:49.560
which is the attacker,
00:13:49.560 --> 00:13:51.530
in this case I'm connected via LAN,
00:13:51.530 --> 00:13:52.630
but you could also be connected
00:13:52.630 --> 00:13:56.310
by wifi in the car outside
in the street and so on,
00:13:56.310 --> 00:13:58.580
so what we have running here
00:13:58.580 --> 00:14:01.310
is the attacker software.
00:14:01.310 --> 00:14:03.080
When we will introduce now,
00:14:03.080 --> 00:14:04.830
initiate a payment,
00:14:04.830 --> 00:14:06.020
through this cashier register,
00:14:06.020 --> 00:14:07.920
the attacker as a man in the middle
00:14:07.920 --> 00:14:09.560
between these two devices
00:14:09.560 --> 00:14:11.500
will simply drop this message
00:14:11.500 --> 00:14:17.750
and replace it with
the first "read card" message.
00:14:17.750 --> 00:14:22.930
We will pay with the card.
00:14:22.930 --> 00:14:25.230
Yeah, alright.
00:14:25.230 --> 00:14:27.180
Please insert the card.
00:14:27.180 --> 00:14:30.510
Now, yeah, here we can also see,
00:14:30.510 --> 00:14:32.950
we can already see the card data.
00:14:32.950 --> 00:14:35.020
Partially censored for our own safety.
00:14:35.020 --> 00:14:37.100
laughter
00:14:37.100 --> 00:14:39.190
And, here's "enter the pin" already,
00:14:39.190 --> 00:14:40.820
so what you have seen,
00:14:40.820 --> 00:14:43.290
it was a bit fast, but what you have seen
00:14:43.290 --> 00:14:46.500
was, the pin he has entered appeared here
00:14:46.500 --> 00:14:47.750
as soon as he entered it,
00:14:47.750 --> 00:14:50.490
because it wasn't
the real pin entry screen,
00:14:50.490 --> 00:14:52.720
it was just our fake pin entry screen.
00:14:52.720 --> 00:14:56.440
I hope you have seen,
that you saw that on the terminal.
00:14:56.440 --> 00:14:59.090
That's the first demo, that's
how we steal the pin number.
00:14:59.090 --> 00:15:10.540
applause
00:15:10.540 --> 00:15:15.250
Dexter: Alright. Zweite demo.
00:15:15.250 --> 00:15:18.070
Nohl: The terminal printed out
your receipt, though.
00:15:18.070 --> 00:15:20.420
Gives out the attack a little bit, right?
00:15:20.420 --> 00:15:23.730
Can we show this receipt?
00:15:23.730 --> 00:15:26.860
GoPro, while you're here.
00:15:26.860 --> 00:15:29.750
So, this line and then
in the normal transaction,
00:15:29.750 --> 00:15:30.690
when you enter pin number,
00:15:30.690 --> 00:15:32.290
is supposed to say Girocard,
00:15:32.290 --> 00:15:36.080
and instead does now say ELV offline,
00:15:36.080 --> 00:15:37.890
so in some cases it's actually apparent,
00:15:37.890 --> 00:15:41.070
but who actually pays attention
to these details, right?
00:15:41.070 --> 00:15:42.590
Bräunlein: RIght. In addition to this,
00:15:42.590 --> 00:15:44.630
this means that the transaction
00:15:44.630 --> 00:15:47.510
has gone through with "Lastschrift" without the pin,
00:15:47.510 --> 00:15:50.310
however we can also choose our attack
00:15:50.310 --> 00:15:52.870
to simply fail the first time,
00:15:52.870 --> 00:15:54.650
so it says, like, "system failure"
00:15:54.650 --> 00:15:55.670
or "pin incorrect",
00:15:55.670 --> 00:15:57.620
and we'll do a second transaction,
00:15:57.620 --> 00:15:59.120
again with pin authorisation,
00:15:59.120 --> 00:16:01.220
that's fine, or in bigger setups,
00:16:01.220 --> 00:16:03.930
it's not the terminal
that prints the receipt,
00:16:03.930 --> 00:16:07.380
but an external printer that's
connected to the cashier register,
00:16:07.380 --> 00:16:10.620
and for that to work, the terminal
again has to send
00:16:10.620 --> 00:16:14.200
the receipt line by line to
the cashier register,
00:16:14.200 --> 00:16:16.690
again without any encryption
or authentication,
00:16:16.690 --> 00:16:20.100
so we can simply replace the line
with Girocard, or drop some lines,
00:16:20.100 --> 00:16:23.190
and do whatever we want.
00:16:23.190 --> 00:16:24.350
Nohl: Very cool.
00:16:24.350 --> 00:16:27.610
So, that was an attack
against the customer,
00:16:27.610 --> 00:16:29.540
that is, pretty much everybody here,
00:16:29.540 --> 00:16:34.490
unless you really only ever pay with cash.
00:16:34.490 --> 00:16:36.150
There's some other attacks
00:16:36.150 --> 00:16:38.530
that target merchants instead,
00:16:38.530 --> 00:16:40.520
so everybody who operates
one of these terminals,
00:16:40.520 --> 00:16:42.750
and, according to the banks,
00:16:42.750 --> 00:16:46.750
there's 770 thousand such
terminals in operation
00:16:46.750 --> 00:16:47.640
today in Germany,
00:16:47.640 --> 00:16:49.610
so I guess at this point in time,
00:16:49.610 --> 00:16:52.130
everybody, even the tiniest of shops,
00:16:52.130 --> 00:16:54.400
will accept cashless payment,
00:16:54.400 --> 00:16:57.940
so, let's look at that next.
00:16:57.940 --> 00:16:59.620
Bräunlein: So, for the next attack,
00:16:59.620 --> 00:17:03.170
we are trying to get all the money
00:17:03.170 --> 00:17:05.290
that's been transferred on this terminal
00:17:05.290 --> 00:17:07.820
to our own bank account.
00:17:07.820 --> 00:17:11.689
Again, we assume we have local
access to the network,
00:17:11.689 --> 00:17:13.689
but this time we won't try to become
00:17:13.689 --> 00:17:17.069
man in the middle between
the cashier register and the terminal,
00:17:17.069 --> 00:17:19.999
but between the terminal and the Internet,
00:17:19.999 --> 00:17:23.730
in this case the payment processor.
00:17:23.730 --> 00:17:25.560
By ARP spoofing again.
00:17:25.560 --> 00:17:28.820
So ZVT includes a message,
00:17:28.820 --> 00:17:31.450
and defines this message
in the specification
00:17:31.450 --> 00:17:32.980
to reset the terminal ID,
00:17:32.980 --> 00:17:35.990
which is basically the identifier
00:17:35.990 --> 00:17:38.120
that says to which bank account
00:17:38.120 --> 00:17:40.370
the terminal is linked to.
00:17:40.370 --> 00:17:42.910
We can reset and set this again
00:17:42.910 --> 00:17:48.100
with password, more on
that we will show later.
00:17:48.100 --> 00:17:51.650
If we have set this, we will now
00:17:51.650 --> 00:17:56.460
tell the terminal to initiate
an extended diagnose to the backend again.
00:17:56.460 --> 00:17:59.900
So we tell it via the ZVT protocol
00:17:59.900 --> 00:18:03.940
to initiate a message on
the Poseidon protocol.
00:18:03.940 --> 00:18:05.540
We need that because,
00:18:05.540 --> 00:18:08.190
when we reset the terminal ID,
00:18:08.190 --> 00:18:10.280
the terminal will get reconfigured
00:18:10.280 --> 00:18:13.740
for the attacker terminal ID,
so for my one.
00:18:13.740 --> 00:18:15.780
And this also means that
the merchant banner,
00:18:15.780 --> 00:18:17.960
so in German it's the Händler-Logo,
00:18:17.960 --> 00:18:20.980
the thing that's printed on the top
of every receipt,
00:18:20.980 --> 00:18:22.310
this would also be my one,
00:18:22.310 --> 00:18:23.110
the attacker's one,
00:18:23.110 --> 00:18:24.610
but we don't want that.
00:18:24.610 --> 00:18:27.370
So we tell the terminal to make
another transaction,
00:18:27.370 --> 00:18:29.050
another extended diagnose,
00:18:29.050 --> 00:18:31.290
we will simply pass that
through to the backend
00:18:31.290 --> 00:18:32.750
as a man in the middle,
00:18:32.750 --> 00:18:37.770
and the response includes some limits
for offline electronic cash and so on,
00:18:37.770 --> 00:18:39.400
and also the merchant banner.
00:18:39.400 --> 00:18:41.250
And this, again, we can simply swap,
00:18:41.250 --> 00:18:44.030
we can swap with the original one,
00:18:44.030 --> 00:18:49.560
and so no one will get
that this ID actually occurred,
00:18:49.560 --> 00:18:56.030
and this is again possible because
no authentication is implemented here.
00:18:56.030 --> 00:18:58.390
Now for the actual transaction.
00:18:58.390 --> 00:19:00.870
If the backend port is already
the correct one,
00:19:00.870 --> 00:19:03.970
we can simply pass all the messages through.
00:19:03.970 --> 00:19:07.370
So, the backend port is,
00:19:07.370 --> 00:19:08.680
each payment processor has
00:19:08.680 --> 00:19:11.350
that one IP address responding
for all the terminals.
00:19:11.350 --> 00:19:12.900
However, for load-balancing reasons
00:19:12.900 --> 00:19:14.850
or something like that,
00:19:14.850 --> 00:19:17.270
they have like 100 different ports,
00:19:17.270 --> 00:19:20.570
each port responsible
for 50 thousand terminals,
00:19:20.570 --> 00:19:25.790
but each terminal can only be managed
by one specific port.
00:19:25.790 --> 00:19:27.110
So if this port already matches,
00:19:27.110 --> 00:19:28.820
we can simply pass through,
00:19:28.820 --> 00:19:31.340
every payment done by this terminal
00:19:31.340 --> 00:19:35.030
will now result in some more money
in our bank account.
00:19:35.030 --> 00:19:36.560
If this one doesn't match,
00:19:36.560 --> 00:19:38.060
we as a man in the middle can simply
00:19:38.060 --> 00:19:42.180
redirect the messages to
the correct backend parameters.
00:19:42.180 --> 00:19:45.300
And, again, let's see it in action.
00:19:53.070 --> 00:19:56.020
So what we have here is a terminal,
00:19:56.020 --> 00:19:59.790
we have configured it
to be configured as another merchant,
00:19:59.790 --> 00:20:03.340
you will see in the end which one it was.
00:20:03.340 --> 00:20:05.970
Again we have the attacker's PC
00:20:05.970 --> 00:20:15.660
that's running the malicious
software, and...
00:20:15.660 --> 00:20:18.550
now we will issue the registration,
00:20:18.550 --> 00:20:20.640
just that we are able to send ZVT messages
00:20:20.640 --> 00:20:23.300
to the terminal.
00:20:23.300 --> 00:20:25.360
And now we will reset the terminal ID
00:20:25.360 --> 00:20:27.010
from the one that's correctly set
00:20:27.010 --> 00:20:28.309
to our own one,
00:20:28.309 --> 00:20:31.410
the one we have got from our contract
00:20:31.410 --> 00:20:34.309
with the payment processor.
00:20:34.309 --> 00:20:36.550
We are setting this terminal ID.
00:20:42.240 --> 00:20:46.540
And now the terminal already
gets its new configuration,
00:20:46.540 --> 00:20:50.490
encrypted, as you will see.
00:20:50.490 --> 00:20:54.060
But it receives it.
00:20:54.060 --> 00:20:56.160
Nohl: So this is all happening with
00:20:56.160 --> 00:20:59.260
real terminals for real transactions,
00:20:59.260 --> 00:21:02.120
so, whoever is watching this at the bank,
00:21:02.120 --> 00:21:04.550
thank you for not blocking us yet.
00:21:04.550 --> 00:21:14.320
laughter, applause
00:21:14.320 --> 00:21:16.740
Bräunlein: But we use the 3G network,
00:21:16.740 --> 00:21:21.490
so in case they block
the IP address range here.
00:21:21.490 --> 00:21:25.160
Alright, so, normally this thing,
00:21:25.160 --> 00:21:26.800
you recognise that this would have been
00:21:26.800 --> 00:21:29.730
printed on the terminal itself.
00:21:29.730 --> 00:21:31.500
And we can see now,
00:21:31.500 --> 00:21:33.740
this terminal now prints as
00:21:33.740 --> 00:21:36.050
belonging to srlabs,
00:21:36.050 --> 00:21:38.850
normally this would be
the full terminal ID,
00:21:38.850 --> 00:21:40.820
that we censored a bit,
00:21:40.820 --> 00:21:43.760
and you can see this is
the whole configuration,
00:21:43.760 --> 00:21:46.490
and it's also configured to be able to
00:21:46.490 --> 00:21:49.860
issue prepaid cards.
00:21:49.860 --> 00:21:51.880
Normally this would be printed
on the terminal,
00:21:51.880 --> 00:21:54.620
but because that would be pretty uncool,
00:21:54.620 --> 00:21:56.520
because then you would recognise it,
00:21:56.520 --> 00:22:02.040
we transferred all the output
to our own notebook.
00:22:02.040 --> 00:22:04.880
Now we will start the man
in the middle server
00:22:04.880 --> 00:22:09.030
for this last part, exchanging
the terminal banner.
00:22:09.030 --> 00:22:14.350
We will change the logo.
00:22:14.350 --> 00:22:19.170
And we will now issue a demo transaction,
00:22:19.170 --> 00:22:21.900
so just like the cashier
register software did,
00:22:21.900 --> 00:22:25.480
we will now issue a transaction,
00:22:25.480 --> 00:22:31.100
and, as you will see, this terminal
now belongs to...
00:22:31.100 --> 00:22:33.550
or still belongs to...
00:22:33.550 --> 00:22:38.490
Can you see that?
00:22:38.490 --> 00:22:40.530
Put it on the table, yeah.
00:22:48.130 --> 00:23:01.790
laughter, applause
00:23:01.790 --> 00:23:06.240
Nohl: Can we switch back to the slides?
00:23:06.240 --> 00:23:08.540
Thank you.
00:23:08.540 --> 00:23:10.220
So that's how we steal money
00:23:10.220 --> 00:23:12.309
from an actual merchant,
00:23:12.309 --> 00:23:13.720
while in the store.
00:23:13.720 --> 00:23:15.590
That'd perhaps be the first catch,
00:23:15.590 --> 00:23:16.940
that you have to be in the store,
00:23:16.940 --> 00:23:20.850
the second catch, as probably the
ones following along noted,
00:23:20.850 --> 00:23:24.180
is, the attacker also needs
to be merchant here,
00:23:24.180 --> 00:23:27.840
you just change from money going
to one merchant account,
00:23:27.840 --> 00:23:29.920
from that to going to another
merchant account,
00:23:29.920 --> 00:23:32.870
but you need to be registered
as a merchant somehow, right?
00:23:32.870 --> 00:23:33.940
There may a catch,
00:23:33.940 --> 00:23:35.690
I don't know how well
set up criminals are,
00:23:35.690 --> 00:23:37.720
with actual businesses,
00:23:37.720 --> 00:23:40.750
but the next attack we're going to show
00:23:40.750 --> 00:23:42.510
does not come with this catch,
00:23:42.510 --> 00:23:44.720
it does not require you to be in the store
00:23:44.720 --> 00:23:48.960
and does not require you to have
anything preconfigured
00:23:48.960 --> 00:23:52.630
and this is an attack on
the Poseidon protocol.
00:23:52.630 --> 00:23:53.770
Remember, that's the protocol
00:23:53.770 --> 00:23:55.750
spoken between the terminal
00:23:55.750 --> 00:23:58.960
and the payment processor, right?
00:23:58.960 --> 00:23:59.950
Take it away.
00:23:59.950 --> 00:24:03.070
Bräunlein: Alright! So, now
for the third attack.
00:24:03.070 --> 00:24:05.980
In that case, what we are
taking a specific look at
00:24:05.980 --> 00:24:09.190
is the initialisation routine of Poseidon.
00:24:09.190 --> 00:24:10.350
This part is normally done
00:24:10.350 --> 00:24:11.880
at the payment processor,
00:24:11.880 --> 00:24:15.290
when you get your terminal preconfigured.
00:24:15.290 --> 00:24:16.390
Here's done this configuration
00:24:16.390 --> 00:24:20.410
to assign your terminal
to your bank account,
00:24:20.410 --> 00:24:22.420
to make this match.
00:24:22.420 --> 00:24:24.130
And how is this done?
00:24:24.130 --> 00:24:28.090
The terminal sends a Poseidon
initialisation routine,
00:24:28.090 --> 00:24:29.480
with the terminal ID,
00:24:29.480 --> 00:24:32.030
to the backend.
00:24:32.030 --> 00:24:37.130
The backend then will get
the configuration for that terminal ID,
00:24:37.130 --> 00:24:40.420
send it to the payment terminal,
00:24:40.420 --> 00:24:42.220
in an encrypted way.
00:24:42.220 --> 00:24:43.820
Symmetrically encrypted
00:24:43.820 --> 00:24:48.580
with a key only within the HSM
and the payment processor has.
00:24:48.580 --> 00:24:49.880
So far, so good.
00:24:49.880 --> 00:24:53.500
That's the normal pre-shared
key thing that we know.
00:24:53.500 --> 00:24:56.510
However, what we have found
is that this key,
00:24:56.510 --> 00:24:57.990
this exact same key,
00:24:57.990 --> 00:25:00.330
is used not in only one terminal,
00:25:00.330 --> 00:25:02.679
but in many, many terminals.
00:25:02.679 --> 00:25:05.230
So what is left of this authentication?
00:25:05.230 --> 00:25:08.860
It's just a username, the terminal ID.
00:25:08.860 --> 00:25:14.070
And this username is public,
as you will see.
00:25:14.070 --> 00:25:18.330
So, the idea now is to have
our own terminal,
00:25:18.330 --> 00:25:19.770
that we got from eBay,
00:25:19.770 --> 00:25:22.740
we got like 3 of them for 7 euros,
00:25:22.740 --> 00:25:24.580
including shipping cost.
00:25:24.580 --> 00:25:27.590
laughter
00:25:27.590 --> 00:25:29.250
And configure our terminal
00:25:29.250 --> 00:25:33.480
to act like just some random terminal,
00:25:33.480 --> 00:25:34.640
somewhere for example in Bonn,
00:25:34.640 --> 00:25:38.550
the mouse shop, as we have demonstrated.
00:25:38.550 --> 00:25:42.870
At that point, I almost feel like
apologising because,
00:25:42.870 --> 00:25:45.929
for this hack, no actual
hacking is involved,
00:25:45.929 --> 00:25:50.890
it's just... it's just broken
in that case.
00:25:50.890 --> 00:25:53.530
You will see.
00:25:53.530 --> 00:25:55.640
So, you just need a few parameters
00:25:55.640 --> 00:25:58.410
to configure your terminal
as another one.
00:25:58.410 --> 00:26:01.520
And this is at first the server's
management password
00:26:01.520 --> 00:26:03.750
only server technicians should have.
00:26:03.750 --> 00:26:07.020
The second one is the
terminal ID of your victim,
00:26:07.020 --> 00:26:10.830
and the last one is the backend port
00:26:10.830 --> 00:26:12.900
that is responsible for managing
00:26:12.900 --> 00:26:16.360
your victim's terminal ID.
00:26:16.360 --> 00:26:18.460
So the first one. How do we get that?
00:26:18.460 --> 00:26:21.230
You will simply google
and find it on the Internet
00:26:21.230 --> 00:26:23.530
in some internal documents.
00:26:23.530 --> 00:26:34.500
laughter, applause, hooting
00:26:34.500 --> 00:26:36.910
This one is the same across all terminals
00:26:36.910 --> 00:26:38.290
of one payment processor,
00:26:38.290 --> 00:26:41.009
so, completely independent of the model,
00:26:41.009 --> 00:26:43.770
every terminal you got
from the same payment processor,
00:26:43.770 --> 00:26:44.850
the same password.
00:26:44.850 --> 00:26:46.530
So the second one, the terminal ID.
00:26:46.530 --> 00:26:48.000
As you have already seen,
00:26:48.000 --> 00:26:50.240
you can find it on every receipt.
00:26:50.240 --> 00:26:53.570
And you can guess them
as they're assigned incrementally.
00:26:53.570 --> 00:26:54.480
applause
00:26:54.480 --> 00:27:02.580
Second one.
applause
00:27:02.580 --> 00:27:05.220
And, for the last one, there are like
00:27:05.220 --> 00:27:07.690
100 different possibilities,
00:27:07.690 --> 00:27:08.950
so just try them all,
00:27:08.950 --> 00:27:11.059
and see which one of these 100 ports
00:27:11.059 --> 00:27:13.960
doesn't answer with a message saying
"I don't know you",
00:27:13.960 --> 00:27:15.309
but with a merchant banner.
00:27:15.309 --> 00:27:18.750
So have all three things set,
00:27:18.750 --> 00:27:23.710
let's demonstrate it.
00:27:23.710 --> 00:27:26.110
So, for this demonstration,
00:27:26.110 --> 00:27:28.730
we've already told you we don't have to be
00:27:28.730 --> 00:27:30.140
on the same network,
00:27:30.140 --> 00:27:33.740
so this is the terminal here for CCC
00:27:33.740 --> 00:27:34.690
that we have shown you,
00:27:34.690 --> 00:27:37.170
we will simply disconnect that,
00:27:37.170 --> 00:27:39.220
it's not on the same network.
00:27:39.220 --> 00:27:42.440
What we have here is a terminal
00:27:42.440 --> 00:27:43.950
without any terminal ID,
00:27:43.950 --> 00:27:47.760
we just set that into factory reset.
00:27:47.760 --> 00:27:50.340
This is how you would get it from eBay,
00:27:50.340 --> 00:27:51.690
if the seller did a good job
00:27:51.690 --> 00:27:53.539
and put it
in factory reset.
00:27:53.539 --> 00:27:56.770
laughter
00:27:56.770 --> 00:28:01.788
Alright, the service password, hmm.
00:28:10.468 --> 00:28:18.580
laughter
00:28:18.580 --> 00:28:24.651
laughter, applause
00:28:27.570 --> 00:28:29.770
Bräunlein shrieks
00:28:36.990 --> 00:28:40.089
laughter
00:28:44.030 --> 00:28:46.590
Good. Aha, no cameras, good.
00:28:58.770 --> 00:29:01.920
Alright. We've entered the terminal ID,
00:29:01.920 --> 00:29:07.100
the backend port is already correct.
00:29:07.100 --> 00:29:11.179
And we will issue an extended diagnose
00:29:11.179 --> 00:29:14.284
to get the new configuration.
00:29:28.719 --> 00:29:32.840
Nohl: And once you're registered,
00:29:32.840 --> 00:29:34.870
what can you actually do
00:29:34.870 --> 00:29:38.490
to that victim merchant?
00:29:38.490 --> 00:29:42.179
Bräunlein: We will show
the prepaid top-up,
00:29:42.179 --> 00:29:44.799
so if the victim merchant
00:29:44.799 --> 00:29:49.880
has the prepaid feature activated,
00:29:49.880 --> 00:29:51.240
we will have it activated as well,
00:29:51.240 --> 00:29:54.049
because we are the victim's terminal.
00:29:54.049 --> 00:29:59.200
So what we can do is simply
print and print prepaid top-ups
00:29:59.200 --> 00:30:01.559
and for example call
our own premium number
00:30:01.559 --> 00:30:02.860
to make it actual money,
00:30:02.860 --> 00:30:04.450
or try to sell it.
00:30:04.450 --> 00:30:06.210
So let's try that.
00:30:06.210 --> 00:30:11.350
So... O2, maybe. 15 euros is enough.
00:30:11.350 --> 00:30:14.113
Of course, we paid in cash.
00:30:25.430 --> 00:30:37.000
applause
00:30:37.000 --> 00:30:39.980
Nohl: Does anybody actually
use O2 prepaid?
00:30:39.980 --> 00:30:41.350
laughter
00:30:41.350 --> 00:30:53.450
No? Well, I'm sure somebody
will find this useful.
00:30:53.450 --> 00:31:06.910
laughter
applause
00:31:06.910 --> 00:31:09.160
Bräunlein: We will also shortly
demonstrate the second way
00:31:09.160 --> 00:31:11.630
to get money, and this is simply
00:31:11.630 --> 00:31:14.730
to transfer ourselves some money.
00:31:14.730 --> 00:31:16.750
laughter
00:31:16.750 --> 00:31:19.320
Nohl: So there's a feature called refund,
00:31:19.320 --> 00:31:21.070
but it's completely independent
00:31:21.070 --> 00:31:22.460
from previous transactions,
00:31:22.460 --> 00:31:25.890
so a "refund" is a transaction
with a negative value.
00:31:25.890 --> 00:31:27.469
You can do this to any bank account.
00:31:27.469 --> 00:31:28.410
Bräunlein: So...
00:31:28.410 --> 00:31:33.302
laughter
00:31:33.302 --> 00:31:35.020
100? Yeah, 100 sounds good.
00:31:35.020 --> 00:31:38.063
laughter
00:31:45.727 --> 00:32:06.820
applause
00:32:06.820 --> 00:32:07.409
Ach!
00:32:07.409 --> 00:32:12.279
laughter
00:32:12.279 --> 00:32:14.390
Nohl: Can we go back to the slides?
00:32:14.390 --> 00:32:17.300
laughter
00:32:17.300 --> 00:32:20.650
Alright, that was pretty fast,
00:32:20.650 --> 00:32:24.409
so let's summarise what just happened.
00:32:24.409 --> 00:32:25.840
Somewhere in Germany there's a terminal
00:32:25.840 --> 00:32:28.090
configured with a certain terminal ID,
00:32:28.090 --> 00:32:29.950
and that terminal ID says,
00:32:29.950 --> 00:32:32.030
this terminal belongs
to a certain merchant.
00:32:32.030 --> 00:32:35.140
So everything, every money
that's put into that terminal
00:32:35.140 --> 00:32:36.429
goes to that merchant's account,
00:32:36.429 --> 00:32:37.870
and everything that's paid
with that terminal
00:32:37.870 --> 00:32:39.580
comes out from that account.
00:32:39.580 --> 00:32:41.309
Now here's a second terminal,
00:32:41.309 --> 00:32:42.840
and we configured that second terminal
00:32:42.840 --> 00:32:46.660
to the same terminal ID.
00:32:46.660 --> 00:32:48.480
And it goes through
a cryptographic process
00:32:48.480 --> 00:32:51.780
by which it registers itself
with the backend.
00:32:51.780 --> 00:32:54.870
This leaves the original terminal
completely working,
00:32:54.870 --> 00:32:56.840
so the merchant still do in the shop,
00:32:56.840 --> 00:32:57.929
whatever he wants,
00:32:57.929 --> 00:32:59.130
but there's a second terminal,
00:32:59.130 --> 00:33:01.690
a complete clone of the first one,
00:33:01.690 --> 00:33:03.640
that now can do the exact same things.
00:33:03.640 --> 00:33:06.080
If we were to send money
into that terminal,
00:33:06.080 --> 00:33:07.460
the merchant would get the money,
00:33:07.460 --> 00:33:10.250
but if we do refunds or sim card top-up
00:33:10.250 --> 00:33:11.380
from that terminal,
00:33:11.380 --> 00:33:14.480
the money comes out from
that merchant's account.
00:33:14.480 --> 00:33:16.660
Right? Very straightforward.
00:33:16.660 --> 00:33:17.700
You saw what it took.
00:33:17.700 --> 00:33:21.780
Three little numbers, all of which
are easy to find, right?
00:33:21.780 --> 00:33:24.360
Based on a terminal that
we purchased on eBay.
00:33:24.360 --> 00:33:26.240
Now what's the maximum scale of fraud
00:33:26.240 --> 00:33:28.970
that somebody could take this towards?
00:33:28.970 --> 00:33:32.940
First of all you don't have to
do this manually on your terminal.
00:33:32.940 --> 00:33:35.899
Everything we just did,
you can do over ZVT,
00:33:35.899 --> 00:33:37.480
so you can script this.
00:33:37.480 --> 00:33:39.100
And it's attractive to script it
00:33:39.100 --> 00:33:43.179
if you had a long list of
valid terminal IDs.
00:33:43.179 --> 00:33:45.880
Now we should note that these
are assigned incrementally,
00:33:45.880 --> 00:33:47.780
so if you know one terminal ID...
00:33:47.780 --> 00:33:48.969
laughter
00:33:48.969 --> 00:33:50.590
If you know one terminal ID,
00:33:50.590 --> 00:33:52.210
you know hundreds of thousands
00:33:52.210 --> 00:33:54.490
of valid terminal IDs.
00:33:54.490 --> 00:33:59.450
Right? So, you register
your terminal over ZVT,
00:33:59.450 --> 00:34:01.049
with one merchant at a time,
00:34:01.049 --> 00:34:02.710
go through a long succession,
00:34:02.710 --> 00:34:04.830
thousands, tens of thousands,
00:34:04.830 --> 00:34:07.910
and send refunds or print top-up money
00:34:07.910 --> 00:34:10.690
from every single account.
00:34:10.690 --> 00:34:13.748
In Germany, through
this Poseidon protocol,
00:34:13.748 --> 00:34:15.609
probably you take this to
other countries too.
00:34:15.609 --> 00:34:20.759
Poseidon is one dialect of a more
internationally spoken ISO standard,
00:34:20.759 --> 00:34:24.539
so, chances are this works
in other countries as well.
00:34:24.539 --> 00:34:30.179
So this could really be
a pretty large fraud scheme
00:34:30.179 --> 00:34:32.559
that fortunately hasn't occurred yet,
00:34:32.559 --> 00:34:35.179
and there's still time to fix it.
00:34:35.179 --> 00:34:39.709
laughter
Again, those people at the banks, right?
00:34:39.709 --> 00:34:50.029
applause
00:34:50.029 --> 00:34:53.259
Summarising over the 3 attacks
we've seen so far.
00:34:53.259 --> 00:34:56.319
So there's two protocols in Germany
00:34:56.319 --> 00:34:57.479
that are used for payments.
00:34:57.479 --> 00:34:59.640
Both of them are severely broken,
00:34:59.640 --> 00:35:01.829
and that affects customers,
00:35:01.829 --> 00:35:03.039
mostly in the store,
00:35:03.039 --> 00:35:05.150
by stealing their pin numbers
and magstripes,
00:35:05.150 --> 00:35:06.950
they affect merchants,
00:35:06.950 --> 00:35:09.099
in the store or even over the Internet,
00:35:09.099 --> 00:35:11.450
we've tried this Poseidon attack over tor,
00:35:11.450 --> 00:35:12.560
works beautifully.
00:35:12.560 --> 00:35:21.270
laughter, applause
00:35:21.270 --> 00:35:25.130
And, coincidentally, these protocols
00:35:25.130 --> 00:35:27.430
of course were designed
completely independently
00:35:27.430 --> 00:35:28.329
from one another,
00:35:28.329 --> 00:35:30.069
they're both vulnerable because of
00:35:30.069 --> 00:35:31.369
the same root cause.
00:35:31.369 --> 00:35:34.710
They share secret keys across terminals.
00:35:34.710 --> 00:35:36.369
You saw in the ZVT case
00:35:36.369 --> 00:35:38.930
that we needed to sign a message,
00:35:38.930 --> 00:35:41.799
that sign message was valid across
all the different terminals
00:35:41.799 --> 00:35:44.420
because they all have the same
signing key in them.
00:35:44.420 --> 00:35:46.670
We saw in Poseidon that we could just
00:35:46.670 --> 00:35:49.669
register one terminal as another one
00:35:49.669 --> 00:35:52.279
with all of them actually
properly authenticated
00:35:52.279 --> 00:35:54.309
to the backend cryptographically,
00:35:54.309 --> 00:35:56.200
all of which with the same key, though,
00:35:56.200 --> 00:35:57.670
so they're not distinguishable.
00:35:57.670 --> 00:36:02.390
It's secure as long as every
terminal is in good hands,
00:36:02.390 --> 00:36:05.319
which of course is a silly assumption
00:36:05.319 --> 00:36:07.759
in a scheme like that.
00:36:07.759 --> 00:36:12.410
So, each of these protocols
is severely broken,
00:36:12.410 --> 00:36:17.130
and we should have just stopped
our research here, but...
00:36:17.130 --> 00:36:18.410
laughter
00:36:18.410 --> 00:36:20.069
We wanted to get those keys,
00:36:20.069 --> 00:36:22.450
and Dexter wouldn't be here with us today
00:36:22.450 --> 00:36:25.170
if there weren't some hardware hacking involved.
00:36:25.170 --> 00:36:27.020
So we snuck in a few weeks
00:36:27.020 --> 00:36:29.470
of actual hardware hacking,
00:36:29.470 --> 00:36:32.609
and Dex is going to tell you what he did.
00:36:32.609 --> 00:36:40.779
applause
00:36:40.779 --> 00:36:44.650
Dexter: Okay, well, you know,
00:36:44.650 --> 00:36:49.499
yeah, let's go.
00:36:49.499 --> 00:36:55.260
Yeah, let's talk about the HSM,
00:36:55.260 --> 00:36:57.760
with the HSM module,
00:36:57.760 --> 00:37:00.699
this is our research, so,
00:37:00.699 --> 00:37:02.849
the HSM module is where the magic happens,
00:37:02.849 --> 00:37:07.789
so let's see, the grey box
you see on the picture above,
00:37:07.789 --> 00:37:10.509
that's the HSM module,
00:37:10.509 --> 00:37:12.430
and this is basically
a smartcard on steroids,
00:37:12.430 --> 00:37:14.170
so it has a display directly connected,
00:37:14.170 --> 00:37:16.749
there's a keypad connected,
00:37:16.749 --> 00:37:20.730
and it processes all the sensitive data.
00:37:20.730 --> 00:37:23.789
Of course, you want to have this area
00:37:23.789 --> 00:37:25.370
at least of the terminal write-protected,
00:37:25.370 --> 00:37:28.279
so you want to have it separate
from the application processor
00:37:28.279 --> 00:37:33.490
where the insecure stuff happens.
00:37:33.490 --> 00:37:36.210
There are a couple of protection measures,
00:37:36.210 --> 00:37:39.440
for example, one important characteristic
00:37:39.440 --> 00:37:42.670
is that the static RAM, the SRAM,
00:37:42.670 --> 00:37:45.549
that holds the secret keys,
00:37:45.549 --> 00:37:46.869
is battery backed-up,
00:37:46.869 --> 00:37:50.729
so if the battery dies, you lose the keys,
00:37:50.729 --> 00:37:54.249
and that's because it's simpler
00:37:54.249 --> 00:37:56.539
to erase a battery backed-up SRAM,
00:37:56.539 --> 00:37:59.980
you just shut down the power.
00:37:59.980 --> 00:38:10.050
Around the module is a couple of switches,
00:38:10.050 --> 00:38:12.099
and if an attacker unscrews the case
00:38:12.099 --> 00:38:13.210
it will lift the switches
00:38:13.210 --> 00:38:15.159
and then it trips the tamper protection
00:38:15.159 --> 00:38:18.290
and... but that's no problem,
00:38:18.290 --> 00:38:19.650
that's easy to defeat.
00:38:19.650 --> 00:38:24.539
There's a more elaborate
protection measure as well,
00:38:24.539 --> 00:38:28.999
so there's a mesh underneath this cap,
00:38:28.999 --> 00:38:33.339
there's a thin metallised mesh
00:38:33.339 --> 00:38:44.180
that is printed to the
inner surface of the HSM cap
00:38:44.180 --> 00:38:45.819
and if an attacker would drill or cut
00:38:45.819 --> 00:38:47.809
or even rip off the cap,
00:38:47.809 --> 00:38:52.619
then you would trip the tamper
protection of course.
00:38:52.619 --> 00:38:54.579
We found an exploitable
mechanical weakness
00:38:54.579 --> 00:38:56.160
in this particular implementation,
00:38:56.160 --> 00:38:59.970
we found it on these terminals there,
00:38:59.970 --> 00:39:01.309
if you look carefully at the picture
00:39:01.309 --> 00:39:02.849
you'll see on the right cap,
00:39:02.849 --> 00:39:03.789
you'll see in the corners,
00:39:03.789 --> 00:39:05.809
you'll see these little dents.
00:39:05.809 --> 00:39:12.970
That's where the mesh is electrically
connected to the underlying PCB,
00:39:12.970 --> 00:39:16.239
so there it's connected
to the secret insides
00:39:16.239 --> 00:39:20.959
that measure, continually
monitor the mesh,
00:39:20.959 --> 00:39:23.970
continuous monitoring, unlike smartcards,
00:39:23.970 --> 00:39:25.579
where you don't have
a continuous monitoring,
00:39:25.579 --> 00:39:28.890
if they're off, they're off,
but this is always on.
00:39:28.890 --> 00:39:30.519
And yeah, it's a problem,
00:39:30.519 --> 00:39:33.899
the connection is only
in the four corners,
00:39:33.899 --> 00:39:35.809
not at the sides.
00:39:35.809 --> 00:39:38.920
So at the sides, there is a possibility
00:39:38.920 --> 00:39:42.339
to enter the edges in the confined space
00:39:42.339 --> 00:39:46.729
with some metallic piece or something,
00:39:46.729 --> 00:39:49.220
and furthermore, this cap,
00:39:49.220 --> 00:39:51.140
during the manufacturing process,
00:39:51.140 --> 00:39:52.700
this is glued on top of the PCB
00:39:52.700 --> 00:39:54.670
with a slightly rubbery glue,
00:39:54.670 --> 00:39:57.400
and this glue leaves a small slot,
00:39:57.400 --> 00:39:59.779
and we thought of...
00:39:59.779 --> 00:40:04.299
how can we try to push something under it?
00:40:04.299 --> 00:40:07.650
And probably defeat the tamper protection.
00:40:07.650 --> 00:40:10.809
And we found something
from doctors, basically,
00:40:10.809 --> 00:40:13.859
that's a syringe needle we flattened
with a pair of pliers,
00:40:13.859 --> 00:40:16.849
and indeed we managed to push that
00:40:16.849 --> 00:40:18.239
underneath the cap,
00:40:18.239 --> 00:40:19.630
underneath the mesh,
00:40:19.630 --> 00:40:22.249
and right into the HSM.
00:40:22.249 --> 00:40:23.519
And we made an experimentation,
00:40:23.519 --> 00:40:25.109
we found a weak spot,
00:40:25.109 --> 00:40:28.749
in our case it was just the power supply
of the tamper protection
00:40:28.749 --> 00:40:30.930
we need to short out to ground,
00:40:30.930 --> 00:40:33.099
so then it's defeated, then it's off.
00:40:33.099 --> 00:40:35.880
And then we can safely open the mesh,
00:40:35.880 --> 00:40:39.439
you see the grounding clip
on the left side.
00:40:39.439 --> 00:40:46.859
That's the short-circuit of
the tamper protection detection circuit.
00:40:46.859 --> 00:40:50.239
And we used a soldering iron to cut it,
00:40:50.239 --> 00:40:53.910
because we wanted to avoid
any vibrations of course,
00:40:53.910 --> 00:40:56.039
this is a delicate task,
00:40:56.039 --> 00:40:58.539
and then you have...
00:40:58.539 --> 00:41:00.319
then the fruits are exposed,
00:41:00.319 --> 00:41:02.499
you have physical access to the flash,
00:41:02.499 --> 00:41:05.410
to the SRAM, to the microcontroller,
00:41:05.410 --> 00:41:06.269
even to the JTAG,
00:41:06.269 --> 00:41:08.279
and in case JTAG doesn't work,
00:41:08.279 --> 00:41:10.450
and you're only interested in the flash,
00:41:10.450 --> 00:41:12.989
there are ways to do it.
00:41:12.989 --> 00:41:16.990
That's how we did it the first time.
00:41:16.990 --> 00:41:22.810
So, here we have attached
the JTAG interface to the HSM,
00:41:22.810 --> 00:41:24.779
and the HSM is still alive,
00:41:24.779 --> 00:41:25.779
we have a terminal right there,
00:41:25.779 --> 00:41:28.430
you can look, the HSM's, bleargh,
00:41:28.430 --> 00:41:30.230
kind of working,
00:41:30.230 --> 00:41:35.579
and you can do all sorts of things,
00:41:35.579 --> 00:41:36.910
you can of course debug,
00:41:36.910 --> 00:41:38.269
you can do experiments,
00:41:38.269 --> 00:41:39.640
reverse-engineer stuff,
00:41:39.640 --> 00:41:41.539
and you can also dump the RAM
00:41:41.539 --> 00:41:42.989
and the RAM, the SRAM,
00:41:42.989 --> 00:41:44.349
might contain some secrets,
00:41:44.349 --> 00:41:46.489
in our case we did a little experiment,
00:41:46.489 --> 00:41:50.019
we tried to use the HSM
module as an oracle,
00:41:50.019 --> 00:41:51.499
as you have seen before, you need
00:41:51.499 --> 00:41:54.119
some MACs, the message
authentication code
00:41:54.119 --> 00:41:57.549
for the pin entry screen,
00:41:57.549 --> 00:41:59.130
the fake screen you've probably seen
00:41:59.130 --> 00:42:02.779
in the image that said that was
protected with such a MAC.
00:42:02.779 --> 00:42:05.259
What you just do,
00:42:05.259 --> 00:42:07.199
the text string you want to have signed,
00:42:07.199 --> 00:42:08.900
you send it to the HSM,
00:42:08.900 --> 00:42:10.359
with an obviously wrong MAC,
00:42:10.359 --> 00:42:13.640
that's the 41 41 here, you know that,
00:42:13.640 --> 00:42:15.380
that's the wrong MAC,
00:42:15.380 --> 00:42:17.369
doesn't matter which value that is,
00:42:17.369 --> 00:42:18.749
you just send it in,
00:42:18.749 --> 00:42:20.729
and then the blue stuff you see there
00:42:20.729 --> 00:42:23.729
is the text we want to have signed,
00:42:23.729 --> 00:42:27.460
and then, the HSM just happily
compares the two
00:42:27.460 --> 00:42:30.040
and says, error, doesn't match,
00:42:30.040 --> 00:42:32.339
but no problem, we just hold CCPU
00:42:32.339 --> 00:42:33.830
via JTAG dumps the RAM,
00:42:33.830 --> 00:42:35.289
we just look up the correct MAC,
00:42:35.289 --> 00:42:37.309
that's it then.
00:42:37.309 --> 00:42:38.190
applause
00:42:38.190 --> 00:42:46.710
Yeah, so much for the...
applause
00:42:46.710 --> 00:42:50.809
so much for the not-so-secure
hardware security module,
00:42:50.809 --> 00:42:56.349
and now let's go back to Karsten here.
00:42:56.349 --> 00:42:58.079
Nohl: Thanks. Yeah, good job.
00:42:58.079 --> 00:43:05.500
applause
00:43:05.500 --> 00:43:08.349
Yeah, just a bit of hardware hacking fun.
00:43:08.349 --> 00:43:11.339
This wasn't actually
necessary for anything,
00:43:11.339 --> 00:43:16.119
but I think it is important
00:43:16.119 --> 00:43:17.450
to note that it is possible,
00:43:17.450 --> 00:43:20.359
to drive one key point home.
00:43:20.359 --> 00:43:22.229
So, in this next chapter,
00:43:22.229 --> 00:43:25.630
we'll talk about what would
actually need to change
00:43:25.630 --> 00:43:27.819
for these protocols to be secure,
00:43:27.819 --> 00:43:29.049
and one thing that can not happen
00:43:29.049 --> 00:43:31.589
is for them to again bury some secret key
00:43:31.589 --> 00:43:33.829
in some "security" module
00:43:33.829 --> 00:43:36.569
that they give hundreds of
thousands of copies out.
00:43:36.569 --> 00:43:38.249
HSMs and generally the idea
00:43:38.249 --> 00:43:39.950
of security by obscurity
00:43:39.950 --> 00:43:45.049
is broken and we need
a better approach here.
00:43:45.049 --> 00:43:47.219
What exactly do we need, though?
00:43:47.219 --> 00:43:49.279
Let's first revisit why
these two protocols
00:43:49.279 --> 00:43:51.359
are so severely broken.
00:43:51.359 --> 00:43:53.009
As I said earlier, both of them
00:43:53.009 --> 00:43:55.969
have the issues of keys that are spread
00:43:55.969 --> 00:43:58.999
over a very large population of terminals,
00:43:58.999 --> 00:44:00.150
some of which may be secure,
00:44:00.150 --> 00:44:02.049
others are very insecure,
00:44:02.049 --> 00:44:05.690
like this ancient model
that we are looking at here.
00:44:05.690 --> 00:44:07.479
The weakest link of the system
00:44:07.479 --> 00:44:09.140
then obviously determines
00:44:09.140 --> 00:44:13.190
the protection of these system-wide keys.
00:44:13.190 --> 00:44:14.099
These system-wide keys,
00:44:14.099 --> 00:44:15.460
they play out very differently
00:44:15.460 --> 00:44:17.700
in these two protocols here, though.
00:44:17.700 --> 00:44:21.880
Remember in ZVT, there's a MAC,
a message signature,
00:44:21.880 --> 00:44:23.769
which can actually be made very secure
00:44:23.769 --> 00:44:25.660
even this system-wide key
00:44:25.660 --> 00:44:28.599
as long as you're using pubic-key crypto.
00:44:28.599 --> 00:44:30.680
If only one person can sign messages,
00:44:30.680 --> 00:44:31.900
it's fine for everybody to have
00:44:31.900 --> 00:44:34.960
the same public key
to verify the messages.
00:44:34.960 --> 00:44:37.380
Now, in this case, these terminals
00:44:37.380 --> 00:44:39.650
I guess, when they were designed,
00:44:39.650 --> 00:44:41.390
they didn't hear about
this great invention
00:44:41.390 --> 00:44:44.229
of asymmetric cryptography,
00:44:44.229 --> 00:44:46.670
and they're using symmetric signatures,
00:44:46.670 --> 00:44:48.460
so the signing key is distributed
00:44:48.460 --> 00:44:51.499
in 700-some thousand copies,
00:44:51.499 --> 00:44:53.619
throughout Germany.
00:44:53.619 --> 00:44:55.180
Amplifying the problem
and further of course
00:44:55.180 --> 00:44:59.599
amplifying by putting them in shady HSMs
00:44:59.599 --> 00:45:03.489
that are, well, not just vulnerable
to Dexter-style hacking,
00:45:03.489 --> 00:45:06.539
but to simple timing
side-channel attacks.
00:45:06.539 --> 00:45:10.200
Right? On the Poseidon side of things,
00:45:10.200 --> 00:45:11.410
it's a little bit cleaner,
00:45:11.410 --> 00:45:13.640
we're not talking about
cryptographic signatures here,
00:45:13.640 --> 00:45:16.029
but about authentication,
00:45:16.029 --> 00:45:18.749
and look at these as
online banking, right,
00:45:18.749 --> 00:45:20.029
each of these terminals is kind of like
00:45:20.029 --> 00:45:23.479
an online banking login
to a merchant account,
00:45:23.479 --> 00:45:26.809
and if they're all using
similar usernames,
00:45:26.809 --> 00:45:29.420
and everybody uses the exact
same password,
00:45:29.420 --> 00:45:30.779
cryptographic key in this case,
00:45:30.779 --> 00:45:32.789
this cannot possibly be secure,
00:45:32.789 --> 00:45:35.390
this cannot be fixed
with public-key crypto,
00:45:35.390 --> 00:45:37.400
as long as everybody uses the same,
00:45:37.400 --> 00:45:39.809
in that case then, digital certificate,
00:45:39.809 --> 00:45:42.719
this is not going to be secure either.
00:45:42.719 --> 00:45:44.029
In both these cases though,
00:45:44.029 --> 00:45:48.069
we need more individual keys.
00:45:48.069 --> 00:45:51.009
As at least a mid-term goal, right?
00:45:51.009 --> 00:45:54.619
Fortunately, these protocols
do have a provision
00:45:54.619 --> 00:45:56.930
to distribute a new key to a terminal
00:45:56.930 --> 00:45:58.829
and this mechanism could be used
00:45:58.829 --> 00:46:00.369
to give a different key
00:46:00.369 --> 00:46:02.059
to every single terminal.
00:46:02.059 --> 00:46:05.479
So, the road ahead should be clear,
00:46:05.479 --> 00:46:07.670
some of the backend systems probably
need to be adapted
00:46:07.670 --> 00:46:10.499
to work with individual keys per terminal,
00:46:10.499 --> 00:46:13.930
it's already clear how we would
get out of this mess:
00:46:13.930 --> 00:46:16.570
give a different key to
every single terminal.
00:46:16.570 --> 00:46:18.499
That not going to save us
in the long run
00:46:18.499 --> 00:46:22.749
when people start attacking
the HSM chips again individually
00:46:22.749 --> 00:46:25.579
and then defrauding
these merchants individually,
00:46:25.579 --> 00:46:28.950
but it would at least get rid
of the possibility
00:46:28.950 --> 00:46:31.979
of very scalable fraud
00:46:31.979 --> 00:46:34.869
against tens of thousands,
hundreds of thousands
00:46:34.869 --> 00:46:37.710
of merchants or consumers, in this case.
00:46:37.710 --> 00:46:40.460
So. The long-term goal is clear,
better protocol,
00:46:40.460 --> 00:46:43.160
the mid-term goal needs to be
00:46:43.160 --> 00:46:45.249
individual keys for each
of these terminals,
00:46:45.249 --> 00:46:48.150
and the short-term goal
could be things like,
00:46:48.150 --> 00:46:51.529
switch off functionality
that you don't actually need.
00:46:51.529 --> 00:46:54.079
How many shops do need to
print sim card top-ups?
00:46:54.079 --> 00:46:55.690
Certainly not every hotel
00:46:55.690 --> 00:46:58.660
and other establishments.
00:46:58.660 --> 00:47:02.279
How many stores do really need
to refund through a card?
00:47:02.279 --> 00:47:03.989
Right, maybe you just do refund in cash
00:47:03.989 --> 00:47:06.739
and switch off that functionality too.
00:47:06.739 --> 00:47:09.539
Similarly, in ZVT, how many merchants
00:47:09.539 --> 00:47:10.779
actually want a terminal
00:47:10.779 --> 00:47:14.160
to be reconfigurable over a network,
00:47:14.160 --> 00:47:17.119
with no confirmation whatsoever
on the terminal?
00:47:17.119 --> 00:47:19.930
Perhaps a little "is this okay?" message,
00:47:19.930 --> 00:47:21.430
and somebody has to press a button
00:47:21.430 --> 00:47:23.619
would already fix a lot of this.
00:47:23.619 --> 00:47:26.059
So, switch off what's not necessary,
00:47:26.059 --> 00:47:28.769
and detect suspicious behaviour,
00:47:28.769 --> 00:47:30.529
you can read faster than I can speak,
00:47:30.529 --> 00:47:32.140
you probably already
went through this list,
00:47:32.140 --> 00:47:34.789
so I'll save you that.
00:47:34.789 --> 00:47:36.109
I promised a couple of times
00:47:36.109 --> 00:47:38.229
a more international perspective on this,
00:47:38.229 --> 00:47:39.609
everything we discussed so far
00:47:39.609 --> 00:47:44.430
is focused on Germany and
some neighbouring countries,
00:47:44.430 --> 00:47:47.160
depending on which of
these protocols it is,
00:47:47.160 --> 00:47:49.630
but we suspect very similar issues
00:47:49.630 --> 00:47:52.979
to exist in most other countries.
00:47:52.979 --> 00:47:55.829
The ZVT alternative that's used
more internationally
00:47:55.829 --> 00:47:59.539
is called OPI, the open
payment initiative,
00:47:59.539 --> 00:48:01.809
and that is a much newer protocol,
00:48:01.809 --> 00:48:04.509
that still does not have
any encryption though.
00:48:04.509 --> 00:48:06.209
Whoever thought, in 2003,
00:48:06.209 --> 00:48:08.269
to specify a payment protocol
00:48:08.269 --> 00:48:10.589
and not to add in encryption,
00:48:10.589 --> 00:48:11.859
please send me an email,
00:48:11.859 --> 00:48:14.739
I'm curious.
00:48:14.739 --> 00:48:18.890
They did however do the,
what would seem smart thing
00:48:18.890 --> 00:48:22.469
of leaving out functionality
that nobody needs anyway,
00:48:22.469 --> 00:48:24.579
and in fact functionality
that we're exploiting,
00:48:24.579 --> 00:48:27.719
like remote manageability
of these terminals.
00:48:27.719 --> 00:48:29.819
Though the few instances of OPI
00:48:29.819 --> 00:48:31.709
we have found in Germany, however,
00:48:31.709 --> 00:48:33.769
they reintroduce that functionality
00:48:33.769 --> 00:48:35.319
as custom extensions,
00:48:35.319 --> 00:48:38.039
so apparently the terminal manufacturers,
00:48:38.039 --> 00:48:42.589
they find it very useful to have
remote manageability,
00:48:42.589 --> 00:48:45.640
and if the protocol doesn't
give it to them,
00:48:45.640 --> 00:48:48.459
they will reintroduce it as an extension.
00:48:48.459 --> 00:48:50.859
So, exact same level of vulnerability,
00:48:50.859 --> 00:48:53.819
in those few instances that we looked at.
00:48:53.819 --> 00:48:56.819
Of course, the research community at large
00:48:56.819 --> 00:49:01.199
is needed to verify this
in different countries
00:49:01.199 --> 00:49:05.289
and just with a little of wireshark
on the wire,
00:49:05.289 --> 00:49:08.519
you typically can.
00:49:08.519 --> 00:49:10.119
Similarly for Poseidon,
00:49:10.119 --> 00:49:12.089
as I said earlier,
this is just one dialect
00:49:12.089 --> 00:49:17.279
of an ISO standard that originally
came from MasterCard and Visa,
00:49:17.279 --> 00:49:20.859
so this the suggested payment
backend protocol
00:49:20.859 --> 00:49:23.700
pretty much worldwide,
00:49:23.700 --> 00:49:26.849
and we have seen
encryption in some cases,
00:49:26.849 --> 00:49:28.170
no encryption in others,
00:49:28.170 --> 00:49:29.569
it doesn't matter though,
00:49:29.569 --> 00:49:31.359
remember the attack actually goes through
00:49:31.359 --> 00:49:33.650
a full cycle of authentication,
00:49:33.650 --> 00:49:35.430
it establishes all keys well,
00:49:35.430 --> 00:49:37.049
it does all of this correctly,
00:49:37.049 --> 00:49:39.579
but everybody has the same key.
00:49:39.579 --> 00:49:41.630
What we are yet to see is a protocol
00:49:41.630 --> 00:49:43.249
by which you could exchange keys
00:49:43.249 --> 00:49:44.690
with these individual terminals,
00:49:44.690 --> 00:49:47.690
either put a key in or
find which key it's using
00:49:47.690 --> 00:49:50.249
to establish individual keys.
00:49:50.249 --> 00:49:52.069
If anybody has more information on that,
00:49:52.069 --> 00:49:54.130
definitely look us up,
00:49:54.130 --> 00:49:56.390
but as far as we're informed,
00:49:56.390 --> 00:49:59.499
there isn't a single instance where
this ISO protocol
00:49:59.499 --> 00:50:03.670
actually is used with a meaningful
key management protocol
00:50:03.670 --> 00:50:06.859
and where this would at least
00:50:06.859 --> 00:50:08.959
have the foundation to be secure.
00:50:08.959 --> 00:50:12.729
But again, you, the international
research community,
00:50:12.729 --> 00:50:16.579
over to you for looking at this
in your countries.
00:50:16.579 --> 00:50:19.299
That was that.
00:50:19.299 --> 00:50:24.099
To quickly conclude, two protocols
00:50:24.099 --> 00:50:27.030
used for payment in Germany,
00:50:27.030 --> 00:50:29.419
both of them to be considered insecure,
00:50:29.419 --> 00:50:31.699
and very outdated,
00:50:31.699 --> 00:50:33.160
they both have the same root cause,
00:50:33.160 --> 00:50:35.099
something that fortunately
can quickly be fixed,
00:50:35.099 --> 00:50:37.529
so there is time to improve the system
00:50:37.529 --> 00:50:40.229
before actual fraud hits,
00:50:40.229 --> 00:50:41.930
we as a research community
00:50:41.930 --> 00:50:43.140
should keep up to pressure
00:50:43.140 --> 00:50:45.359
for them to actually do that,
00:50:45.359 --> 00:50:46.569
but we as customers,
00:50:46.569 --> 00:50:48.880
we should not believe them anymore
00:50:48.880 --> 00:50:52.609
when they say "you must have
given your pin number to somebody,
00:50:52.609 --> 00:50:56.470
hence this fraudulent transaction
on your account".
00:50:56.470 --> 00:50:58.440
There've been a number of cases like that
00:50:58.440 --> 00:51:00.279
in Germany this year,
00:51:00.279 --> 00:51:02.190
and I think it's time to show them
00:51:02.190 --> 00:51:05.519
who's really responsible for
the security vulnerabilities,
00:51:05.519 --> 00:51:09.259
and for leaving them open
for so many years.
00:51:09.259 --> 00:51:10.573
Thank you very much.
00:51:10.573 --> 00:51:34.040
applause
00:51:34.040 --> 00:51:35.969
Herald: We have 7 minutes for Q&A.
00:51:35.969 --> 00:51:37.130
Thanks to our speakers again
00:51:37.130 --> 00:51:41.009
for a only theoretical threat
on the payment systems, of course,
00:51:41.009 --> 00:51:45.069
strictly lab environment,
as the press wrote,
00:51:45.069 --> 00:51:48.319
please leave quickly and quietly
through the side doors now
00:51:48.319 --> 00:51:50.839
so we have 5 minutes of Q&A.
00:51:50.839 --> 00:51:52.869
And, mike 2 starts.
00:51:52.869 --> 00:51:54.770
Q: How did you handle
the question of disclosure,
00:51:54.770 --> 00:51:56.429
so did you do full disclosure,
00:51:56.429 --> 00:51:57.329
responsible disclosure,
00:51:57.329 --> 00:52:01.299
how much time did you give them?
00:52:01.299 --> 00:52:04.959
Nohl: We went through responsible
disclosure I guess,
00:52:04.959 --> 00:52:07.130
meaning that we in detail tried to explain
00:52:07.130 --> 00:52:09.279
all of these attacks to an audience
00:52:09.279 --> 00:52:15.899
that we thought could fix this,
about a month ago. Right.
00:52:15.899 --> 00:52:17.719
Q: And have you seen any reaction to that?
00:52:17.719 --> 00:52:19.599
Like, have they tried fixing it?
00:52:19.599 --> 00:52:22.170
Nohl: I'm sure somebody's working on a fix,
00:52:22.170 --> 00:52:26.499
but nobody would tell me.
00:52:26.499 --> 00:52:29.519
Herald: Okay, and we have one
question from the Internet.
00:52:29.519 --> 00:52:32.059
Signal angel: So, can you say if there's an easy fix
00:52:32.059 --> 00:52:37.800
like just flashing a new firmware
into all terminals?
00:52:37.800 --> 00:52:39.790
Bräunlein: Like, flashing firmware
to all terminals?
00:52:39.790 --> 00:52:42.289
Nohl: It's an easy fix.
00:52:42.289 --> 00:52:44.950
Bräunlein: Yeah, you have shown the fixes.
00:52:44.950 --> 00:52:47.759
These are, the difference
between this research
00:52:47.759 --> 00:52:49.930
and the research done 3 years before
00:52:49.930 --> 00:52:53.749
is that this are now
flaws in the protocol,
00:52:53.749 --> 00:52:55.769
so these need new protocols,
00:52:55.769 --> 00:52:59.629
new versions and new... yeah. That's it.
00:52:59.629 --> 00:53:01.989
So these are no implementation
flaws right now.
00:53:01.989 --> 00:53:04.059
Q: But would you have to
scrap all terminals
00:53:04.059 --> 00:53:08.479
and buy or construct new ones?
00:53:08.479 --> 00:53:10.589
Nohl: I think the honest answer is
00:53:10.589 --> 00:53:13.959
that criminals are slow too,
00:53:13.959 --> 00:53:17.779
so this will have to be
a somewhat longer journey
00:53:17.779 --> 00:53:21.019
in which we first replace
these system-wide keys
00:53:21.019 --> 00:53:22.130
by individual keys,
00:53:22.130 --> 00:53:24.160
that would already help tremendously
00:53:24.160 --> 00:53:26.269
in making it less attractive
00:53:26.269 --> 00:53:28.700
to do these types of attack,
00:53:28.700 --> 00:53:31.079
but then in the meantime
work on better protocols
00:53:31.079 --> 00:53:33.739
so we don't keep finding ourselves
in this situation
00:53:33.739 --> 00:53:36.599
where it would take years
to fix protocols,
00:53:36.599 --> 00:53:39.539
well let's use those years
ahead of us to do that.
00:53:39.539 --> 00:53:40.480
Q: Thanks.
00:53:40.480 --> 00:53:42.680
Herald: Okay. Microphone 8, please.
00:53:42.680 --> 00:53:44.589
Q: How many tries did it take
00:53:44.589 --> 00:53:46.709
to clone the keys of the terminal,
00:53:46.709 --> 00:53:48.489
how many boxes did you have to blow?
00:53:48.489 --> 00:53:50.609
Nohl laughs
00:53:50.609 --> 00:53:52.539
Dexter: 3 or so.
00:53:52.539 --> 00:53:53.539
Nohl: Yeah.
00:53:53.539 --> 00:53:57.979
Dexter: I mean the first one was
surprisingly an immediate success,
00:53:57.979 --> 00:54:01.729
we managed to withdraw the SRAM
without destroying it,
00:54:01.729 --> 00:54:03.589
second one, we broke immediately,
00:54:03.589 --> 00:54:06.529
and the third one had issues,
00:54:06.529 --> 00:54:09.399
but we managed to fix it.
00:54:09.399 --> 00:54:14.009
Q: So you didn't wipe any keys
bypassing the mesh?
00:54:14.009 --> 00:54:16.369
Dexter: I didn't understand
acoustically, sorry.
00:54:16.369 --> 00:54:17.819
Q: When you're bypassing the mesh,
00:54:17.819 --> 00:54:19.539
you got that the first try?
00:54:19.539 --> 00:54:20.940
Bräunlein: Yeah, I tried it the first time.
00:54:20.940 --> 00:54:21.440
Q: Wow.
00:54:21.440 --> 00:54:22.690
Bräunlein: So like, I think...
00:54:22.690 --> 00:54:23.200
Dexter: Yeah.
00:54:23.200 --> 00:54:24.489
Bräunlein: Bit of preparation,
00:54:24.489 --> 00:54:26.609
and then one hour of actual work.
00:54:26.609 --> 00:54:28.150
Nohl: Well, he destroyed
the first terminal
00:54:28.150 --> 00:54:30.829
but for just looking at
how it's built, right?
00:54:30.829 --> 00:54:33.119
Dexter: Yeah, he knew how it was made up
00:54:33.119 --> 00:54:36.489
because we took a few apart before,
of course.
00:54:36.489 --> 00:54:39.160
But not with intention to do that,
00:54:39.160 --> 00:54:40.150
just because they broke,
00:54:40.150 --> 00:54:41.259
and then we took it apart
00:54:41.259 --> 00:54:43.529
to look up, to read out the flash,
00:54:43.529 --> 00:54:45.109
this bug bonded thingy
00:54:45.109 --> 00:54:46.989
that was one of the very first ones,
00:54:46.989 --> 00:54:49.169
that broke.
00:54:49.169 --> 00:54:52.240
Herald: Okay, microphone 7, please.
00:54:52.240 --> 00:54:54.140
Q: Would you please briefly describe
00:54:54.140 --> 00:54:56.699
what will do the terminal in case,
00:54:56.699 --> 00:55:00.339
if some transaction wasn't
processed by the bank,
00:55:00.339 --> 00:55:02.619
what kind of information it will store
00:55:02.619 --> 00:55:06.210
in the memory and how long?
00:55:06.210 --> 00:55:08.059
Bräunlein: It will store the error.
00:55:08.059 --> 00:55:10.449
Nohl: I don't think the terminal
stores anything,
00:55:10.449 --> 00:55:11.789
it's pretty much stateless.
00:55:11.789 --> 00:55:14.769
It receives a command,
00:55:14.769 --> 00:55:16.209
looks up its configuration,
00:55:16.209 --> 00:55:17.390
like terminal ID,
00:55:17.390 --> 00:55:19.989
it pushes it down to HSM to get signed
00:55:19.989 --> 00:55:21.249
or get a pin number,
00:55:21.249 --> 00:55:22.959
pushes it over Poseidon,
00:55:22.959 --> 00:55:25.160
and forgets all about that transaction.
00:55:25.160 --> 00:55:31.460
Q: So it's not trying to resend
the transaction again somehow later?
00:55:31.460 --> 00:55:33.510
Nohl: Um, good question.
00:55:33.510 --> 00:55:37.410
Bräunlein: So this is not part of
the attacks we have demonstrated
00:55:37.410 --> 00:55:39.549
but what happens is that,
00:55:39.549 --> 00:55:41.630
normally you would do
an end of day command,
00:55:41.630 --> 00:55:43.719
or a Kassenschnitt in Germany,
00:55:43.719 --> 00:55:48.040
where all the transactions that have been
accumulated throughout the day
00:55:48.040 --> 00:55:50.170
will be sent to the payment processor,
00:55:50.170 --> 00:55:52.150
and this is the exact moment
00:55:52.150 --> 00:55:54.049
where all these transactions are then sent
00:55:54.049 --> 00:55:57.079
by the transaction processor to the bank.
00:55:57.079 --> 00:55:58.449
So at this point for example,
00:55:58.449 --> 00:56:01.829
no reversal is anymore possible,
00:56:01.829 --> 00:56:06.309
reversal that'll reverse one
purchase on the same day,
00:56:06.309 --> 00:56:08.749
because then the bank has
already the information,
00:56:08.749 --> 00:56:11.259
and then no information
is stored anymore
00:56:11.259 --> 00:56:12.709
on the terminal,
00:56:12.709 --> 00:56:14.790
if this one was successful.
00:56:14.790 --> 00:56:16.309
Q: Okay, thank you.
00:56:16.309 --> 00:56:18.229
Herald: One more remote question, please.
00:56:18.229 --> 00:56:21.670
Signal angel: So is the communication that you use
00:56:21.670 --> 00:56:23.049
in the man in the middle attacks
00:56:23.049 --> 00:56:25.849
also susceptible to replay attacks?
00:56:25.849 --> 00:56:28.440
Can you just do it without a terminal
00:56:28.440 --> 00:56:29.869
if you recorded the conversation
00:56:29.869 --> 00:56:33.790
between terminal and processing server?
00:56:33.790 --> 00:56:37.209
Nohl: Sure, we can inject messages,
ZVT messages,
00:56:37.209 --> 00:56:40.299
most of them are not actually
protected with a MAC,
00:56:40.299 --> 00:56:43.390
for instance you can query a magstripe
00:56:43.390 --> 00:56:44.859
with no protection,
00:56:44.859 --> 00:56:46.930
however there needs to be
somebody in the store
00:56:46.930 --> 00:56:49.529
who expects you to do that, right?
00:56:49.529 --> 00:56:51.489
So it's convenient to just be
man in the middle
00:56:51.489 --> 00:56:52.569
in an actual transaction
00:56:52.569 --> 00:56:56.130
because you know there's somebody
waiting for you to stick in a card,
00:56:56.130 --> 00:56:58.759
there's a customer waiting
to stick in that card,
00:56:58.759 --> 00:57:02.739
so you wouldn't get that from just
sending random messages,
00:57:02.739 --> 00:57:05.779
there's just nobody there with a card.
00:57:05.779 --> 00:57:07.319
Herald: Okay, one last question,
00:57:07.319 --> 00:57:09.459
a quick question from microphone 1.
00:57:09.459 --> 00:57:11.449
Q: Yes, you said there's a possibility
00:57:11.449 --> 00:57:15.099
to give an individual key
to each terminal.
00:57:15.099 --> 00:57:18.789
So you have an identical terminal
to another one,
00:57:18.789 --> 00:57:23.039
so if the payment processor sends out
individual keys to each terminal,
00:57:23.039 --> 00:57:25.560
and there are two of one terminal,
00:57:25.560 --> 00:57:27.189
what will happen?
00:57:27.189 --> 00:57:28.239
Nohl: Yeah, good question.
00:57:28.239 --> 00:57:31.940
So if the fraudsters first take over
all the terminals,
00:57:31.940 --> 00:57:33.709
and you then send individual keys,
00:57:33.709 --> 00:57:34.380
it's not going to help,
00:57:34.380 --> 00:57:37.550
you have to be ahead of the bad guys here.
00:57:42.730 --> 00:57:46.561
Herald: Okay! Thanks again to
Karsten, Fabian and Dexter.
00:57:46.561 --> 00:57:49.866
applause
00:57:49.866 --> 00:57:53.266
postroll music
00:57:53.266 --> 00:58:01.000
subtitles created by c3subtitles.de
Join, and help us!