<i>preroll music</i>

Herald: So, welcome everybody,

the next talk is under the topic

"shoplifting", uh, "shopshifting", sorry.
<i>laughter</i>

Shoplifting is something completely different,

it has nothing to do with shopshifting,

the outcome is the same.

<i>laughter</i>

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

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

<i>applause</i>

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.

<i>laughter</i>

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.

<i>laughter</i>

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.

<i>applause</i>

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.

<i>laughter, applause</i>

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.

<i>laughter, applause</i>

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.

<i>laughter</i>

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.

<i>laughter, applause, hooting</i>

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.

<i>applause</i>

Second one.
<i>applause</i>

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.

<i>laughter</i>

Alright, the service password, hmm.

<i>laughter</i>

<i>laughter, applause</i>

<i>Bräunlein shrieks</i>

<i>laughter</i>

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.

<i>applause</i>

Nohl: Does anybody actually
use O2 prepaid?

<i>laughter</i>

No? Well, I'm sure somebody
will find this useful.

<i>laughter</i>
<i>applause</i>

Bräunlein: We will also shortly
demonstrate the second way

to get money, and this is simply

to transfer ourselves some money.

<i>laughter</i>

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

<i>laughter</i>

100? Yeah, 100 sounds good.

<i>laughter</i>

<i>applause</i>

Ach!

<i>laughter</i>

Nohl: Can we go back to the slides?

<i>laughter</i>

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

<i>laughter</i>

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.

<i>laughter</i>
Again, those people at the banks, right?

<i>applause</i>

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.

<i>laughter, applause</i>

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

<i>laughter</i>

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.

<i>applause</i>

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.

<i>applause</i>

Yeah, so much for the...
<i>applause</i>

so much for the not-so-secure
hardware security module,

and now let's go back to Karsten here.

Nohl: Thanks. Yeah, good job.

<i>applause</i>

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.

<i>applause</i>

Herald: We have 7 minutes for Q&amp;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&amp;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?

<i>Nohl laughs</i>

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.

<i>applause</i>

<i>postroll music</i>

subtitles created by c3subtitles.de
Join, and help us!