preroll music
Herald: So, welcome everybody,
the next talk is under the topic
"shoplifting", uh, "shopshifting", sorry.
laughter
Shoplifting is something completely different,
it has nothing to do with shopshifting,
the outcome is the same.
laughter
And I present to you Karsten Nohl,
Fabian Bräunlein, and Dexter from Berlin
Some of you may have already seen
the one only other face here,
and you may have heard of things like
the Mifare RFID problems that we had,
the gsm sim card hacks,
and things like BadUSB
and these people and people around them
are all responsible for that.
So, give them a warm applause, and...
applause
stage is yours!
Nohl: Thank you very much.
It's great to be back,
looking at yet another technology
and searching for
security vulnerabilities.
We focus our research on technologies
that most of us use on a daily basis,
that are typically outdated,
very widely deployed, and insecure.
Took us many years to finally come around
to look at payment protocols,
which we'll be discussing today.
In part, it took so long because
we just didn't think
we would find anything.
After all, some of the best people
in our industry work at banks,
and banks have among the most
developed risk management.
So, at least in my experience,
banks are good at reacting
to security evolution.
That's what I thought up until
maybe the middle of this year,
when we started this research
and we're here now today to take
this preconception away
from whoever may still be
suffering from this illusion that
banks actually do keep
their systems very secure,
at least we found in two cases,
two very widely deployed protocols,
that there's gaping holes and have been
for a couple of years.
Both of these protocols are
involved in payment,
that is if you go into a store
and you pay with a card,
those protocols are invoked,
at least in Germany,
and protocols are called ZVT and Poseidon.
They're used for very different purposes,
but they both terminate at
a payment terminal.
The one protocol ZVT is spoken between
a cashier station and
this payment terminal,
so somebody would scan some items
or type in some amount
into this cashier station,
and then say, "now please pay",
and a command is sent to
the payment terminal,
which then requests a card,
and perhaps a pin number,
for most transactions in Germany,
and then in turns invokes another protocol
that this payment terminal speaks with
a payment processor.
That's a service provider that connects
these terminals to banks,
and basically facilitates
the actual payment.
And then the payment processor
or the bank,
they validate the account details
and so forth,
they send a confirmation,
and that confirmation again over ZVT
is sent back to the cashier station.
That is, in a nutshell, how
a payment transaction works.
So it's based on two protocols,
both of them fairly old,
and probably by virtue of being so old,
very widely deployed.
In Germany, you will hardly find anything
other than these two protocols being used.
We'll look at an international angle
towards the end of the talk,
just a short summary,
most of these problems will probably exist
in most other countries as well.
So let's in turn look at ZVT
and then Poseidon
to identify their security issues.
Starting with ZVT,
this is again the protocol that's spoken
in the shop, between a cashier station
and a terminal,
but in almost all cases,
over a network connection.
Very old systems would use
a serial cable,
but today a network is used.
So assuming that a fraudster
somehow can get access to a local network,
by plugging into some open ports,
or by even being a customer at your hotel
and just being connected to the same wifi
as your cashier system,
what can this attacker do?
Let's start with something simple
that doesn't even really
require any hacking.
In this case, somebody wants to steal
the magnetic stripe details of the card.
So the way that it should work
is that the cashier station
sends a command
to the payment terminal,
and then gets a confirmation back
after some processing.
Now what the attacker does in this case
is get in between those two,
in their connection.
Through, just traditional ARP spoofing.
So, you proxy the connection
between the cashier station
and the payment terminal,
sitting in the local network again.
We'll look at Internet-wide attacks
in a few minutes, but for now
we're talking about inside the shop,
or in wifi range of that shop.
So you ARP spoof
and you receive that authorisation request
that's supposed to be sent to
the payment terminal.
What the cashier station basically says,
"There's a customer here,
the customer wants to pay something,
please authorise the payment."
Right? We take that command
and do not forward it,
but instead send another command,
which basically says, "read a card".
So the terminal will then display
what the customer expects,
"please insert a card",
customer does so, and the
magnetic stripe information is read,
and sent back over the network
to the attacker.
No transaction has been done yet.
Immediately following
these magnetic stripe details,
the attacker would then send
an actual authorisation request message
supplying the magnetic stripe info.
So, instead of asking for a card,
the payment terminal just takes
this magstripe now,
and goes through the transaction.
So two things happen.
First, the attacker did receive
a copy of the magstripe,
second, the actual transaction,
the intended transaction did go through.
So neither the customer nor the merchant
sees any different.
But the attacker does have
a copy of the magstripe now.
And then, countries where
magstripe is enough,
let's say US, prior to chip-and-pin,
this is enough to completely
clone the card.
Fortunately, most other countries
do require pin numbers,
making this attack ineffective.
But perhaps motivating
a slightly improved attack.
So, let's say the fraudster wanted
to also steal the pin number remotely.
Right? Magstripe and pin number,
that's really all you need
to pay in Germany, say.
So the way pin transactions are
supposed to work,
they are much more secure,
well, they're secured at all,
versus magstripe, which isn't secure,
so the top part of this slide
shows how a pin transaction is
supposed to work.
Again, over ZVT, the cashier desk
or whatever's speaking
to the terminal in the store,
sends an authorisation request
this time specifically saying
"do require pin number"
or perhaps that is even configured
in the terminal,
to always require pin number.
Either way, inside the terminal,
all the security magic happens now.
There's different components
of the terminal.
There's a main CPU that does
all the network communication,
both ZVT and Poseidon,
which is supposed to be somewhat secure
but really isn't, as, by the way,
some research a couple of years has shown,
that specifically looked at the security
of one of these terminals,
but that's not the topic of today,
we're looking at the standard's security.
So inside this terminal,
there's also a hardware
security module, an HSM,
and that HSM does all the heavy lifting
when it comes to
cryptographic keys and so forth.
The HSM is also directly connected
to the display and the pin pad
of the machine.
So you tell the HSM, inside the terminal,
"do a pin transaction",
it shows something on the display,
"enter pin", it receives the input,
and instead of giving out the pin number
to the less secure side of the terminal
it encrypts it with a key that only
the payment processor
is supposed to have.
So, the main CPU,
or anybody really outside of the HSM,
does not see the pin number.
That's how things are supposed to work.
Now, the lower part of the slide
develops an attack idea with one catch,
we'll resolve that in a minute though.
This attack here would use
a different message
to actually receive the pin number.
So instead of saying,
"do a pin transaction",
it would just say "display some text
and give me the input".
That would work beautifully, right,
so you display the text
"give me the pin number"
and whatever's typed in,
you get that input.
This very flexible functionality
we don't really know what it's
ever used for,
we've never seen it,
but we're suspecting it's used
for things like,
asking customers for their zip code
or something, right?
Type something in and
send it over the network.
And we've partly never seen this
because it really can't be used,
these messages need to be signed.
We don't know who's supposed
to sign these messages,
we've tried to find a person
but nobody feels responsible.
So there's some functionality
in the standard here
that's never used and
nobody knows how to use it.
The use of this cryptographic signature
on the slide called message
authentication code, MAC,
that's required and it's actually
checked by the HSM.
So if you want to do your "please
enter zip code" scheme
across all your stores,
you've got to get your message signed,
and that signed message then
works across all terminals.
And if we want our "please enter
pin number" message to be shown,
we've got to get to sign,
or find some way to sign this ourselves
and no entering the real hacking
so I'm handing over to Fabian
who did almost all this research,
so that was just my attempt to introduce
these two guys here.
Bräunlein: Thank you.
applause
Alright, so, to find valid MACs
for arbitrary texts,
we exploited a time-based
side-channel vulnerability
within one HSM implementation.
So, for those to work reliably,
we had to have the ability to
send messages directly to the HSM.
To accomplish that, we used
an active JTAG interface we found
for the main CPU on the PCP,
and loaded our custom assembly program.
What this wanted was just sending messages
with our texts and some MACs to the HSM,
and stop the time that
it needs to respond.
So, we are doing that and are trying
every single possibility,
every single value for the first byte
of this 8-byte MAC.
When you do that, you will see that...
so, that's a bit oversimplified,
but you will get the gist.
You will see that for
one particular value,
the HSM needs a bit longer to respond,
so like, just 5 CPU cycles within the HSM.
Now you already have the first byte
of this 8-byte MAC,
you can set this and do the same thing
for the second one.
So, why does that work?
This works because they use
a symmetric key
for the calculation of the MAC
within the HSM.
There is a key that the payment
processor has,
and this is stored inside the HSM,
which is able to calculate
the correct MAC for any text.
And what happens next,
so this is the first minor issue
because you should use
asymmetric cryptography.
The next thing is,
that the comparison
between the correct MAC
that has been calculated within the HSM,
and the MAC we have input through
this display text message,
is compared byte by byte.
So it checks if the first byte
of the input message
matches the first byte of the correct MAC
and if it doesn't match,
it will return immediately,
if it matches, it will try to compare
the second byte,
and if that doesn't match
it will return immediately,
so, this time it needs to check
one more byte,
we can measure,
with some more work.
So, with this thing,
with the correct MAC for the
"please enter pin" screen,
we can give you a quick demonstration
of how this works in real life.
And for that we would need the GoPro...
that you already have.
Ah, the GoPro, yeah.
laughter
So, this is the setup here.
Here we need the computer with
the green text on the black terminal.
Alright. Here we have a normal
cashier register,
it's some Windows XP software running,
here we have the actual payment terminal,
these two are connected through
this Fritz box standing here,
just some normal internal home network.
Now, there's also another
participant in the setup,
which is the attacker,
in this case I'm connected via LAN,
but you could also be connected
by wifi in the car outside
in the street and so on,
so what we have running here
is the attacker software.
When we will introduce now,
initiate a payment,
through this cashier register,
the attacker as a man in the middle
between these two devices
will simply drop this message
and replace it with
the first "read card" message.
We will pay with the card.
Yeah, alright.
Please insert the card.
Now, yeah, here we can also see,
we can already see the card data.
Partially censored for our own safety.
laughter
And, here's "enter the pin" already,
so what you have seen,
it was a bit fast, but what you have seen
was, the pin he has entered appeared here
as soon as he entered it,
because it wasn't
the real pin entry screen,
it was just our fake pin entry screen.
I hope you have seen,
that you saw that on the terminal.
That's the first demo, that's
how we steal the pin number.
applause
Dexter: Alright. Zweite demo.
Nohl: The terminal printed out
your receipt, though.
Gives out the attack a little bit, right?
Can we show this receipt?
GoPro, while you're here.
So, this line and then
in the normal transaction,
when you enter pin number,
is supposed to say Girocard,
and instead does now say ELV offline,
so in some cases it's actually apparent,
but who actually pays attention
to these details, right?
Bräunlein: RIght. In addition to this,
this means that the transaction
has gone through with "Lastschrift" without the pin,
however we can also choose our attack
to simply fail the first time,
so it says, like, "system failure"
or "pin incorrect",
and we'll do a second transaction,
again with pin authorisation,
that's fine, or in bigger setups,
it's not the terminal
that prints the receipt,
but an external printer that's
connected to the cashier register,
and for that to work, the terminal
again has to send
the receipt line by line to
the cashier register,
again without any encryption
or authentication,
so we can simply replace the line
with Girocard, or drop some lines,
and do whatever we want.
Nohl: Very cool.
So, that was an attack
against the customer,
that is, pretty much everybody here,
unless you really only ever pay with cash.
There's some other attacks
that target merchants instead,
so everybody who operates
one of these terminals,
and, according to the banks,
there's 770 thousand such
terminals in operation
today in Germany,
so I guess at this point in time,
everybody, even the tiniest of shops,
will accept cashless payment,
so, let's look at that next.
Bräunlein: So, for the next attack,
we are trying to get all the money
that's been transferred on this terminal
to our own bank account.
Again, we assume we have local
access to the network,
but this time we won't try to become
man in the middle between
the cashier register and the terminal,
but between the terminal and the Internet,
in this case the payment processor.
By ARP spoofing again.
So ZVT includes a message,
and defines this message
in the specification
to reset the terminal ID,
which is basically the identifier
that says to which bank account
the terminal is linked to.
We can reset and set this again
with password, more on
that we will show later.
If we have set this, we will now
tell the terminal to initiate
an extended diagnose to the backend again.
So we tell it via the ZVT protocol
to initiate a message on
the Poseidon protocol.
We need that because,
when we reset the terminal ID,
the terminal will get reconfigured
for the attacker terminal ID,
so for my one.
And this also means that
the merchant banner,
so in German it's the Händler-Logo,
the thing that's printed on the top
of every receipt,
this would also be my one,
the attacker's one,
but we don't want that.
So we tell the terminal to make
another transaction,
another extended diagnose,
we will simply pass that
through to the backend
as a man in the middle,
and the response includes some limits
for offline electronic cash and so on,
and also the merchant banner.
And this, again, we can simply swap,
we can swap with the original one,
and so no one will get
that this ID actually occurred,
and this is again possible because
no authentication is implemented here.
Now for the actual transaction.
If the backend port is already
the correct one,
we can simply pass all the messages through.
So, the backend port is,
each payment processor has
that one IP address responding
for all the terminals.
However, for load-balancing reasons
or something like that,
they have like 100 different ports,
each port responsible
for 50 thousand terminals,
but each terminal can only be managed
by one specific port.
So if this port already matches,
we can simply pass through,
every payment done by this terminal
will now result in some more money
in our bank account.
If this one doesn't match,
we as a man in the middle can simply
redirect the messages to
the correct backend parameters.
And, again, let's see it in action.
So what we have here is a terminal,
we have configured it
to be configured as another merchant,
you will see in the end which one it was.
Again we have the attacker's PC
that's running the malicious
software, and...
now we will issue the registration,
just that we are able to send ZVT messages
to the terminal.
And now we will reset the terminal ID
from the one that's correctly set
to our own one,
the one we have got from our contract
with the payment processor.
We are setting this terminal ID.
And now the terminal already
gets its new configuration,
encrypted, as you will see.
But it receives it.
Nohl: So this is all happening with
real terminals for real transactions,
so, whoever is watching this at the bank,
thank you for not blocking us yet.
laughter, applause
Bräunlein: But we use the 3G network,
so in case they block
the IP address range here.
Alright, so, normally this thing,
you recognise that this would have been
printed on the terminal itself.
And we can see now,
this terminal now prints as
belonging to srlabs,
normally this would be
the full terminal ID,
that we censored a bit,
and you can see this is
the whole configuration,
and it's also configured to be able to
issue prepaid cards.
Normally this would be printed
on the terminal,
but because that would be pretty uncool,
because then you would recognise it,
we transferred all the output
to our own notebook.
Now we will start the man
in the middle server
for this last part, exchanging
the terminal banner.
We will change the logo.
And we will now issue a demo transaction,
so just like the cashier
register software did,
we will now issue a transaction,
and, as you will see, this terminal
now belongs to...
or still belongs to...
Can you see that?
Put it on the table, yeah.
laughter, applause
Nohl: Can we switch back to the slides?
Thank you.
So that's how we steal money
from an actual merchant,
while in the store.
That'd perhaps be the first catch,
that you have to be in the store,
the second catch, as probably the
ones following along noted,
is, the attacker also needs
to be merchant here,
you just change from money going
to one merchant account,
from that to going to another
merchant account,
but you need to be registered
as a merchant somehow, right?
There may a catch,
I don't know how well
set up criminals are,
with actual businesses,
but the next attack we're going to show
does not come with this catch,
it does not require you to be in the store
and does not require you to have
anything preconfigured
and this is an attack on
the Poseidon protocol.
Remember, that's the protocol
spoken between the terminal
and the payment processor, right?
Take it away.
Bräunlein: Alright! So, now
for the third attack.
In that case, what we are
taking a specific look at
is the initialisation routine of Poseidon.
This part is normally done
at the payment processor,
when you get your terminal preconfigured.
Here's done this configuration
to assign your terminal
to your bank account,
to make this match.
And how is this done?
The terminal sends a Poseidon
initialisation routine,
with the terminal ID,
to the backend.
The backend then will get
the configuration for that terminal ID,
send it to the payment terminal,
in an encrypted way.
Symmetrically encrypted
with a key only within the HSM
and the payment processor has.
So far, so good.
That's the normal pre-shared
key thing that we know.
However, what we have found
is that this key,
this exact same key,
is used not in only one terminal,
but in many, many terminals.
So what is left of this authentication?
It's just a username, the terminal ID.
And this username is public,
as you will see.
So, the idea now is to have
our own terminal,
that we got from eBay,
we got like 3 of them for 7 euros,
including shipping cost.
laughter
And configure our terminal
to act like just some random terminal,
somewhere for example in Bonn,
the mouse shop, as we have demonstrated.
At that point, I almost feel like
apologising because,
for this hack, no actual
hacking is involved,
it's just... it's just broken
in that case.
You will see.
So, you just need a few parameters
to configure your terminal
as another one.
And this is at first the server's
management password
only server technicians should have.
The second one is the
terminal ID of your victim,
and the last one is the backend port
that is responsible for managing
your victim's terminal ID.
So the first one. How do we get that?
You will simply google
and find it on the Internet
in some internal documents.
laughter, applause, hooting
This one is the same across all terminals
of one payment processor,
so, completely independent of the model,
every terminal you got
from the same payment processor,
the same password.
So the second one, the terminal ID.
As you have already seen,
you can find it on every receipt.
And you can guess them
as they're assigned incrementally.
applause
Second one.
applause
And, for the last one, there are like
100 different possibilities,
so just try them all,
and see which one of these 100 ports
doesn't answer with a message saying
"I don't know you",
but with a merchant banner.
So have all three things set,
let's demonstrate it.
So, for this demonstration,
we've already told you we don't have to be
on the same network,
so this is the terminal here for CCC
that we have shown you,
we will simply disconnect that,
it's not on the same network.
What we have here is a terminal
without any terminal ID,
we just set that into factory reset.
This is how you would get it from eBay,
if the seller did a good job
and put it
in factory reset.
laughter
Alright, the service password, hmm.
laughter
laughter, applause
Bräunlein shrieks
laughter
Good. Aha, no cameras, good.
Alright. We've entered the terminal ID,
the backend port is already correct.
And we will issue an extended diagnose
to get the new configuration.
Nohl: And once you're registered,
what can you actually do
to that victim merchant?
Bräunlein: We will show
the prepaid top-up,
so if the victim merchant
has the prepaid feature activated,
we will have it activated as well,
because we are the victim's terminal.
So what we can do is simply
print and print prepaid top-ups
and for example call
our own premium number
to make it actual money,
or try to sell it.
So let's try that.
So... O2, maybe. 15 euros is enough.
Of course, we paid in cash.
applause
Nohl: Does anybody actually
use O2 prepaid?
laughter
No? Well, I'm sure somebody
will find this useful.
laughter
applause
Bräunlein: We will also shortly
demonstrate the second way
to get money, and this is simply
to transfer ourselves some money.
laughter
Nohl: So there's a feature called refund,
but it's completely independent
from previous transactions,
so a "refund" is a transaction
with a negative value.
You can do this to any bank account.
Bräunlein: So...
laughter
100? Yeah, 100 sounds good.
laughter
applause
Ach!
laughter
Nohl: Can we go back to the slides?
laughter
Alright, that was pretty fast,
so let's summarise what just happened.
Somewhere in Germany there's a terminal
configured with a certain terminal ID,
and that terminal ID says,
this terminal belongs
to a certain merchant.
So everything, every money
that's put into that terminal
goes to that merchant's account,
and everything that's paid
with that terminal
comes out from that account.
Now here's a second terminal,
and we configured that second terminal
to the same terminal ID.
And it goes through
a cryptographic process
by which it registers itself
with the backend.
This leaves the original terminal
completely working,
so the merchant still do in the shop,
whatever he wants,
but there's a second terminal,
a complete clone of the first one,
that now can do the exact same things.
If we were to send money
into that terminal,
the merchant would get the money,
but if we do refunds or sim card top-up
from that terminal,
the money comes out from
that merchant's account.
Right? Very straightforward.
You saw what it took.
Three little numbers, all of which
are easy to find, right?
Based on a terminal that
we purchased on eBay.
Now what's the maximum scale of fraud
that somebody could take this towards?
First of all you don't have to
do this manually on your terminal.
Everything we just did,
you can do over ZVT,
so you can script this.
And it's attractive to script it
if you had a long list of
valid terminal IDs.
Now we should note that these
are assigned incrementally,
so if you know one terminal ID...
laughter
If you know one terminal ID,
you know hundreds of thousands
of valid terminal IDs.
Right? So, you register
your terminal over ZVT,
with one merchant at a time,
go through a long succession,
thousands, tens of thousands,
and send refunds or print top-up money
from every single account.
In Germany, through
this Poseidon protocol,
probably you take this to
other countries too.
Poseidon is one dialect of a more
internationally spoken ISO standard,
so, chances are this works
in other countries as well.
So this could really be
a pretty large fraud scheme
that fortunately hasn't occurred yet,
and there's still time to fix it.
laughter
Again, those people at the banks, right?
applause
Summarising over the 3 attacks
we've seen so far.
So there's two protocols in Germany
that are used for payments.
Both of them are severely broken,
and that affects customers,
mostly in the store,
by stealing their pin numbers
and magstripes,
they affect merchants,
in the store or even over the Internet,
we've tried this Poseidon attack over tor,
works beautifully.
laughter, applause
And, coincidentally, these protocols
of course were designed
completely independently
from one another,
they're both vulnerable because of
the same root cause.
They share secret keys across terminals.
You saw in the ZVT case
that we needed to sign a message,
that sign message was valid across
all the different terminals
because they all have the same
signing key in them.
We saw in Poseidon that we could just
register one terminal as another one
with all of them actually
properly authenticated
to the backend cryptographically,
all of which with the same key, though,
so they're not distinguishable.
It's secure as long as every
terminal is in good hands,
which of course is a silly assumption
in a scheme like that.
So, each of these protocols
is severely broken,
and we should have just stopped
our research here, but...
laughter
We wanted to get those keys,
and Dexter wouldn't be here with us today
if there weren't some hardware hacking involved.
So we snuck in a few weeks
of actual hardware hacking,
and Dex is going to tell you what he did.
applause
Dexter: Okay, well, you know,
yeah, let's go.
Yeah, let's talk about the HSM,
with the HSM module,
this is our research, so,
the HSM module is where the magic happens,
so let's see, the grey box
you see on the picture above,
that's the HSM module,
and this is basically
a smartcard on steroids,
so it has a display directly connected,
there's a keypad connected,
and it processes all the sensitive data.
Of course, you want to have this area
at least of the terminal write-protected,
so you want to have it separate
from the application processor
where the insecure stuff happens.
There are a couple of protection measures,
for example, one important characteristic
is that the static RAM, the SRAM,
that holds the secret keys,
is battery backed-up,
so if the battery dies, you lose the keys,
and that's because it's simpler
to erase a battery backed-up SRAM,
you just shut down the power.
Around the module is a couple of switches,
and if an attacker unscrews the case
it will lift the switches
and then it trips the tamper protection
and... but that's no problem,
that's easy to defeat.
There's a more elaborate
protection measure as well,
so there's a mesh underneath this cap,
there's a thin metallised mesh
that is printed to the
inner surface of the HSM cap
and if an attacker would drill or cut
or even rip off the cap,
then you would trip the tamper
protection of course.
We found an exploitable
mechanical weakness
in this particular implementation,
we found it on these terminals there,
if you look carefully at the picture
you'll see on the right cap,
you'll see in the corners,
you'll see these little dents.
That's where the mesh is electrically
connected to the underlying PCB,
so there it's connected
to the secret insides
that measure, continually
monitor the mesh,
continuous monitoring, unlike smartcards,
where you don't have
a continuous monitoring,
if they're off, they're off,
but this is always on.
And yeah, it's a problem,
the connection is only
in the four corners,
not at the sides.
So at the sides, there is a possibility
to enter the edges in the confined space
with some metallic piece or something,
and furthermore, this cap,
during the manufacturing process,
this is glued on top of the PCB
with a slightly rubbery glue,
and this glue leaves a small slot,
and we thought of...
how can we try to push something under it?
And probably defeat the tamper protection.
And we found something
from doctors, basically,
that's a syringe needle we flattened
with a pair of pliers,
and indeed we managed to push that
underneath the cap,
underneath the mesh,
and right into the HSM.
And we made an experimentation,
we found a weak spot,
in our case it was just the power supply
of the tamper protection
we need to short out to ground,
so then it's defeated, then it's off.
And then we can safely open the mesh,
you see the grounding clip
on the left side.
That's the short-circuit of
the tamper protection detection circuit.
And we used a soldering iron to cut it,
because we wanted to avoid
any vibrations of course,
this is a delicate task,
and then you have...
then the fruits are exposed,
you have physical access to the flash,
to the SRAM, to the microcontroller,
even to the JTAG,
and in case JTAG doesn't work,
and you're only interested in the flash,
there are ways to do it.
That's how we did it the first time.
So, here we have attached
the JTAG interface to the HSM,
and the HSM is still alive,
we have a terminal right there,
you can look, the HSM's, bleargh,
kind of working,
and you can do all sorts of things,
you can of course debug,
you can do experiments,
reverse-engineer stuff,
and you can also dump the RAM
and the RAM, the SRAM,
might contain some secrets,
in our case we did a little experiment,
we tried to use the HSM
module as an oracle,
as you have seen before, you need
some MACs, the message
authentication code
for the pin entry screen,
the fake screen you've probably seen
in the image that said that was
protected with such a MAC.
What you just do,
the text string you want to have signed,
you send it to the HSM,
with an obviously wrong MAC,
that's the 41 41 here, you know that,
that's the wrong MAC,
doesn't matter which value that is,
you just send it in,
and then the blue stuff you see there
is the text we want to have signed,
and then, the HSM just happily
compares the two
and says, error, doesn't match,
but no problem, we just hold CCPU
via JTAG dumps the RAM,
we just look up the correct MAC,
that's it then.
applause
Yeah, so much for the...
applause
so much for the not-so-secure
hardware security module,
and now let's go back to Karsten here.
Nohl: Thanks. Yeah, good job.
applause
Yeah, just a bit of hardware hacking fun.
This wasn't actually
necessary for anything,
but I think it is important
to note that it is possible,
to drive one key point home.
So, in this next chapter,
we'll talk about what would
actually need to change
for these protocols to be secure,
and one thing that can not happen
is for them to again bury some secret key
in some "security" module
that they give hundreds of
thousands of copies out.
HSMs and generally the idea
of security by obscurity
is broken and we need
a better approach here.
What exactly do we need, though?
Let's first revisit why
these two protocols
are so severely broken.
As I said earlier, both of them
have the issues of keys that are spread
over a very large population of terminals,
some of which may be secure,
others are very insecure,
like this ancient model
that we are looking at here.
The weakest link of the system
then obviously determines
the protection of these system-wide keys.
These system-wide keys,
they play out very differently
in these two protocols here, though.
Remember in ZVT, there's a MAC,
a message signature,
which can actually be made very secure
even this system-wide key
as long as you're using pubic-key crypto.
If only one person can sign messages,
it's fine for everybody to have
the same public key
to verify the messages.
Now, in this case, these terminals
I guess, when they were designed,
they didn't hear about
this great invention
of asymmetric cryptography,
and they're using symmetric signatures,
so the signing key is distributed
in 700-some thousand copies,
throughout Germany.
Amplifying the problem
and further of course
amplifying by putting them in shady HSMs
that are, well, not just vulnerable
to Dexter-style hacking,
but to simple timing
side-channel attacks.
Right? On the Poseidon side of things,
it's a little bit cleaner,
we're not talking about
cryptographic signatures here,
but about authentication,
and look at these as
online banking, right,
each of these terminals is kind of like
an online banking login
to a merchant account,
and if they're all using
similar usernames,
and everybody uses the exact
same password,
cryptographic key in this case,
this cannot possibly be secure,
this cannot be fixed
with public-key crypto,
as long as everybody uses the same,
in that case then, digital certificate,
this is not going to be secure either.
In both these cases though,
we need more individual keys.
As at least a mid-term goal, right?
Fortunately, these protocols
do have a provision
to distribute a new key to a terminal
and this mechanism could be used
to give a different key
to every single terminal.
So, the road ahead should be clear,
some of the backend systems probably
need to be adapted
to work with individual keys per terminal,
it's already clear how we would
get out of this mess:
give a different key to
every single terminal.
That not going to save us
in the long run
when people start attacking
the HSM chips again individually
and then defrauding
these merchants individually,
but it would at least get rid
of the possibility
of very scalable fraud
against tens of thousands,
hundreds of thousands
of merchants or consumers, in this case.
So. The long-term goal is clear,
better protocol,
the mid-term goal needs to be
individual keys for each
of these terminals,
and the short-term goal
could be things like,
switch off functionality
that you don't actually need.
How many shops do need to
print sim card top-ups?
Certainly not every hotel
and other establishments.
How many stores do really need
to refund through a card?
Right, maybe you just do refund in cash
and switch off that functionality too.
Similarly, in ZVT, how many merchants
actually want a terminal
to be reconfigurable over a network,
with no confirmation whatsoever
on the terminal?
Perhaps a little "is this okay?" message,
and somebody has to press a button
would already fix a lot of this.
So, switch off what's not necessary,
and detect suspicious behaviour,
you can read faster than I can speak,
you probably already
went through this list,
so I'll save you that.
I promised a couple of times
a more international perspective on this,
everything we discussed so far
is focused on Germany and
some neighbouring countries,
depending on which of
these protocols it is,
but we suspect very similar issues
to exist in most other countries.
The ZVT alternative that's used
more internationally
is called OPI, the open
payment initiative,
and that is a much newer protocol,
that still does not have
any encryption though.
Whoever thought, in 2003,
to specify a payment protocol
and not to add in encryption,
please send me an email,
I'm curious.
They did however do the,
what would seem smart thing
of leaving out functionality
that nobody needs anyway,
and in fact functionality
that we're exploiting,
like remote manageability
of these terminals.
Though the few instances of OPI
we have found in Germany, however,
they reintroduce that functionality
as custom extensions,
so apparently the terminal manufacturers,
they find it very useful to have
remote manageability,
and if the protocol doesn't
give it to them,
they will reintroduce it as an extension.
So, exact same level of vulnerability,
in those few instances that we looked at.
Of course, the research community at large
is needed to verify this
in different countries
and just with a little of wireshark
on the wire,
you typically can.
Similarly for Poseidon,
as I said earlier,
this is just one dialect
of an ISO standard that originally
came from MasterCard and Visa,
so this the suggested payment
backend protocol
pretty much worldwide,
and we have seen
encryption in some cases,
no encryption in others,
it doesn't matter though,
remember the attack actually goes through
a full cycle of authentication,
it establishes all keys well,
it does all of this correctly,
but everybody has the same key.
What we are yet to see is a protocol
by which you could exchange keys
with these individual terminals,
either put a key in or
find which key it's using
to establish individual keys.
If anybody has more information on that,
definitely look us up,
but as far as we're informed,
there isn't a single instance where
this ISO protocol
actually is used with a meaningful
key management protocol
and where this would at least
have the foundation to be secure.
But again, you, the international
research community,
over to you for looking at this
in your countries.
That was that.
To quickly conclude, two protocols
used for payment in Germany,
both of them to be considered insecure,
and very outdated,
they both have the same root cause,
something that fortunately
can quickly be fixed,
so there is time to improve the system
before actual fraud hits,
we as a research community
should keep up to pressure
for them to actually do that,
but we as customers,
we should not believe them anymore
when they say "you must have
given your pin number to somebody,
hence this fraudulent transaction
on your account".
There've been a number of cases like that
in Germany this year,
and I think it's time to show them
who's really responsible for
the security vulnerabilities,
and for leaving them open
for so many years.
Thank you very much.
applause
Herald: We have 7 minutes for Q&A.
Thanks to our speakers again
for a only theoretical threat
on the payment systems, of course,
strictly lab environment,
as the press wrote,
please leave quickly and quietly
through the side doors now
so we have 5 minutes of Q&A.
And, mike 2 starts.
Q: How did you handle
the question of disclosure,
so did you do full disclosure,
responsible disclosure,
how much time did you give them?
Nohl: We went through responsible
disclosure I guess,
meaning that we in detail tried to explain
all of these attacks to an audience
that we thought could fix this,
about a month ago. Right.
Q: And have you seen any reaction to that?
Like, have they tried fixing it?
Nohl: I'm sure somebody's working on a fix,
but nobody would tell me.
Herald: Okay, and we have one
question from the Internet.
Signal angel: So, can you say if there's an easy fix
like just flashing a new firmware
into all terminals?
Bräunlein: Like, flashing firmware
to all terminals?
Nohl: It's an easy fix.
Bräunlein: Yeah, you have shown the fixes.
These are, the difference
between this research
and the research done 3 years before
is that this are now
flaws in the protocol,
so these need new protocols,
new versions and new... yeah. That's it.
So these are no implementation
flaws right now.
Q: But would you have to
scrap all terminals
and buy or construct new ones?
Nohl: I think the honest answer is
that criminals are slow too,
so this will have to be
a somewhat longer journey
in which we first replace
these system-wide keys
by individual keys,
that would already help tremendously
in making it less attractive
to do these types of attack,
but then in the meantime
work on better protocols
so we don't keep finding ourselves
in this situation
where it would take years
to fix protocols,
well let's use those years
ahead of us to do that.
Q: Thanks.
Herald: Okay. Microphone 8, please.
Q: How many tries did it take
to clone the keys of the terminal,
how many boxes did you have to blow?
Nohl laughs
Dexter: 3 or so.
Nohl: Yeah.
Dexter: I mean the first one was
surprisingly an immediate success,
we managed to withdraw the SRAM
without destroying it,
second one, we broke immediately,
and the third one had issues,
but we managed to fix it.
Q: So you didn't wipe any keys
bypassing the mesh?
Dexter: I didn't understand
acoustically, sorry.
Q: When you're bypassing the mesh,
you got that the first try?
Bräunlein: Yeah, I tried it the first time.
Q: Wow.
Bräunlein: So like, I think...
Dexter: Yeah.
Bräunlein: Bit of preparation,
and then one hour of actual work.
Nohl: Well, he destroyed
the first terminal
but for just looking at
how it's built, right?
Dexter: Yeah, he knew how it was made up
because we took a few apart before,
of course.
But not with intention to do that,
just because they broke,
and then we took it apart
to look up, to read out the flash,
this bug bonded thingy
that was one of the very first ones,
that broke.
Herald: Okay, microphone 7, please.
Q: Would you please briefly describe
what will do the terminal in case,
if some transaction wasn't
processed by the bank,
what kind of information it will store
in the memory and how long?
Bräunlein: It will store the error.
Nohl: I don't think the terminal
stores anything,
it's pretty much stateless.
It receives a command,
looks up its configuration,
like terminal ID,
it pushes it down to HSM to get signed
or get a pin number,
pushes it over Poseidon,
and forgets all about that transaction.
Q: So it's not trying to resend
the transaction again somehow later?
Nohl: Um, good question.
Bräunlein: So this is not part of
the attacks we have demonstrated
but what happens is that,
normally you would do
an end of day command,
or a Kassenschnitt in Germany,
where all the transactions that have been
accumulated throughout the day
will be sent to the payment processor,
and this is the exact moment
where all these transactions are then sent
by the transaction processor to the bank.
So at this point for example,
no reversal is anymore possible,
reversal that'll reverse one
purchase on the same day,
because then the bank has
already the information,
and then no information
is stored anymore
on the terminal,
if this one was successful.
Q: Okay, thank you.
Herald: One more remote question, please.
Signal angel: So is the communication that you use
in the man in the middle attacks
also susceptible to replay attacks?
Can you just do it without a terminal
if you recorded the conversation
between terminal and processing server?
Nohl: Sure, we can inject messages,
ZVT messages,
most of them are not actually
protected with a MAC,
for instance you can query a magstripe
with no protection,
however there needs to be
somebody in the store
who expects you to do that, right?
So it's convenient to just be
man in the middle
in an actual transaction
because you know there's somebody
waiting for you to stick in a card,
there's a customer waiting
to stick in that card,
so you wouldn't get that from just
sending random messages,
there's just nobody there with a card.
Herald: Okay, one last question,
a quick question from microphone 1.
Q: Yes, you said there's a possibility
to give an individual key
to each terminal.
So you have an identical terminal
to another one,
so if the payment processor sends out
individual keys to each terminal,
and there are two of one terminal,
what will happen?
Nohl: Yeah, good question.
So if the fraudsters first take over
all the terminals,
and you then send individual keys,
it's not going to help,
you have to be ahead of the bad guys here.
Herald: Okay! Thanks again to
Karsten, Fabian and Dexter.
applause
postroll music
subtitles created by c3subtitles.de
Join, and help us!