*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*