Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/318 Thanks!
So thank you very much, everybody.
I'm Andrea Barazani from Italy,
which is why I have a girly name for
every country other than Italy.
So but this is me.
This is my first Congress, by the way.
Even if I live so closely here, I'm feel
very privileged to be here.
And so far, I've been very overwhelmed
by the quality and the people
at this event. So I'm really happy to be
here. And thank you for coming to my
lecture.
So I did this talk with Bionicle,
my colleague at the university.
So just to give you a brief introduction,
what we do, we did.
We're consulting company.
We did a lot of exotic talks in the past
years. We're one of the first ones to do
talks about car hacking.
We sniff keystrokes from the power line
and we laser's in 2011, we did
a chip and pin talk.
And this is an updated version of that
with new findings.
Last year we were one of the first ones
to do packaging packets in Ethernet
and so on. And tomorrow, just
a little odd. I will have another talk at
five thirty here about the USB
armorer, which is our latest hardware
project. So
so EMV, I'm going to talk about
the credit cards with a chip that you
have, which is called Chip and PIN and
UK. EMV is the name of the standard
and we address this topic
a few times in the past.
And the reason why I'm doing this talk is
because working in the security industry,
I really dislike where
a technology which is supposed
to be secure but is really not
it used against the users
of that technology because it's bad
everywhere around. Right?
I mean, if you use a secure technology,
whatever that might mean, it should
protect you.
It should be something that works for
you, not against you.
And the problem that we found in the
past, we DMV, along with
the fine folks at Cambridge as well,
they also publish research about this.
Is that the way in these
being marketed and used on a legal
standpoint is in some
cases, not all cases against the users.
And we're strongly against
that, which is why we're making these
talks.
So Ian Lee is a name of a standard that
regulates every time you see a credit
card with a chip, that's
EMV. That's what we're going to talk
about. So you have a smart card,
which, of course, this is undeniable.
It improved the security over the
existing Mac Strib, which you still
have, by the way. I mean, every credit
card nowadays as the chip, the
Mac stripe and the embossing as well.
So you still can fall back
to very old technology there.
So EMV was invented to replace that
magnetic stripe.
It was invented also to promote the
offline car verification and transaction
approval. So to give you the ability
of validate a transaction without taking
the costs and the time of going online
to the actual backend and you
can have multiple applications on one
card. You can have credit and debit if
you want. So these were the main reasons
for moving to EMV, which are very good
reasons in a way.
One of the other reason is that we DMV
you promote a liability shift so the
liability shifts away from the merchant
to the bank in theory.
But the cardholder, which is you,
which are, you know, the user of the car,
is assumed to be liable in most cases,
unless you can unquestionably prove
that you were not at fault into
protecting the pin or
whatever credentials have been used for
the fraudulent transaction.
So this is the core issue here
with EMV. The PIN verification
becomes proof of your presence.
Now, if the technology cannot ultimately
protect the pin, then of
course this liability shift should
not happen at all.
And this is what we're going to address
in this talk.
This is a very nice example.
Canadian per Bank of Commerce,
a guy was brought in for eighty one
thousand two hundred seventy six dollars.
Our records show that this was a chip and
pin transaction. This means the customer,
personal car and personal pin number.
We're using carrying out this
transaction. As a result, the customer is
liable for the transaction.
So this is the problem.
By the way, the the
thief bought a race car.
That's the sum eighty one thousand, which
is what I would do if I would have to
fraud one of your credit cards.
That's what I would do. I would buy a
race car. I think it's a very good thing
to do. But sadly,
with Chip and PIN, you might be liable.
And I don't want to do that.
I mean, if I can get my race car and you
can get your money back, I think it's a
win win scenario. So if anybody wants to
do that, we can talk about it.
So inves broken.
So there's been this is
the best presentations that have
been done about EMV.
One is mine, but I'm not biased by
any means. So the
guys from Cambridge did an excellent job
with the chip and PIN is broken research.
We did one called Chip and PIN is
definitely broken with our friends, the
Percher Labs, Adam, Lorenzen, Francon.
And then it was the next one about.
So I'm going to address all of
these issues that are being presented
here and then one more, which is
a combination interaction between
two of these stocks here, which is
something you that has never been
presented before.
So you're all familiar with ATM skimmers,
I guess. If not, you should like when
you go to an ATM, keep in mind that there
can always be a fake pin pad and
a fake credit card reader.
So EMV and the chip was designed
to prevent these to find ways
where Dimmock stripe can go
away so that we not be so easy
to intercept everything that is read
while you put the card inside.
But our point was that
we can do EMV skimmers.
So this is a very tiny, very
thin EMV skimmer
that we did for research with our friends
at a percher labs that can be covertly
inserted into a point of sale device.
So this device as a reader,
a smart card reader and its
two faces, so it says a shim
as a man in the meta device, and
it can be placed inside a point
of sale device.
So when you insert your card, the card
has been intercepted by this device
and once it's plugged inside,
you cannot even take it out easily.
It's so clever that you will not
see it. Nobody can see it.
And this is a key factor because the
fact that nobody can see this device
or detect these presence means that
you're not negligent in
not knowing that is there, because this
is nothing that you can do to prevent
or to detect this kind of device inside.
And this is a key point from a legal
standpoint.
So we built this device is a proof of
concept because we wanted to say that
EMV skimmers are the likely
next step after mag stripe skimmers,
we move away from the max.
What do we have?
We have the chip.
So criminal activity will focus on
the chip because it is possible to do so.
So we predicted the skimming.
The chip would become extremely
appealing. And because the interface
is accessible, you have to
be able to put your card into the
point-of-sale slot.
So this means that other things
could go inside there.
It becomes impossible, as I said, for the
user to verify that and he could
go undetected for a very long time.
So these were our predictions.
And after we made the first presentation
about this, of course, it came out that
actually there were real
chip skimmers installation in the wild
that have been reported after our talk.
But they were dated before our
talk, which is great because we take the
credit in exposing the issue, but not the
blame for triggering it because that
were dated before.
So that was that was perfect for us.
Thank you.
And this is so this is much more
professional looking at ours.
OK, so this was made this is a real
unit made by criminals.
It has a serial number on it, which you
were you very much.
I don't put serial numbers on the PCBs
I make, OK?
And also, who can tell me what
that little wire that goes up and down
is? Can you tell what that is?
Yes, it is an antenna, so it's
even much more professional than that.
Outsourcing hours.
You would require a special car to plug
it in and to download the data here.
You can just sit in the nearby
Borza coffee, whatever you have here, and
then just get the data
uploaded to you of your Bluetooth.
So this is scary.
And if you can see the plastic
piece on the bottom.
So that's actually.
The plastic, the gray piece there,
it's the same model.
So what they figure out is that they
could unplug the plastic piece
and they could put it inside with this
skimmer hidden inside.
So very professional.
So this is a real threat
or it can be hooked easily
with just a few seconds with the device.
It is powered by the device
itself.
Data can be downloaded wirelessly or with
a special car.
It takes little development effort.
We did it in two weeks
and it's cheap. It doesn't cost too much.
So this is a real problem.
It will happen.
It is happening now.
Cheap skimmers, they're there.
They can be there.
So what can you do with a cheap skimmer?
The question becomes that we accept
that these devices can exist.
What can you do with such a skimmer?
So smartcards, it's a very simple
protocol.
You can read, you can send commands
to them. You send a request and you get a
response from APD messages.
DMV schema can intercept these messages
so you can log them and
you can also men in the middle so it can
decide to prevent certain messages to
reach the card.
And it can send fake responses
to the terminal like a network,
TCP, IP, many, whatever.
This is basically a summary of what
the envy is, envy is divided
into this main four phases.
First of all, we have initiate
application processing where
the terminal gets to know the card.
You know, ask the car, hello, what
are you what kind of features that you
support? Are you a Visa or MasterCard?
What's the application then? I'm going to
select.
So application might be the Visa
application, the massacre application
or debit application.
Then you have the card authentication.
So we authenticate the card.
And this can happening in several
different ways, which I'm going to talk
about.
Um, then you have the card holder
verification, so you verify the person,
you're authenticated the car now you
verify the person.
And this is done with the pin.
The pin is the card glorification
or the signature.
It depends.
And then you have the actual
transactions.
So there are many problems with
the way this protocol has been
designed.
The first problem is that there are
all of these steps are separate
and there are not strongly tied
together, and this is one of the
main issues.
The second problem is that
most of the data that is exchanged
here is completely unencrypted.
So like your credit card number, your
name, it's all exchange and it's
unencrypted.
And the third problem is that the
backend. So the bank relies
on the correct operation of
the terminal.
So the terminal is not just
a dumb middleman.
It is something that is essential to
maintain the security of
the protocol.
So this is not an end to end protocol
by any means.
So these are the three main issues
within EMV.
And you will also see that in the
way that EMV is being designed.
It has a lot of backwards compatibility
issues and some problems were
patched with newer version and so on and
so on, so it's something that is
definitely overengineered and not
secure at all.
So the first thing that you can do, which
was surprising to us, but it's trivial,
it used to be that you can do a Mac Strib
clone from the chip.
Now, you can still do that.
You can get an exact copy of the Mac
except for free digits.
So free digits that you need, which
are on the Mac stripe, are not on the
chip. I don't know that you can do it.
And this is the CSV.
So this means
that you cannot clone
to Macs drive, by the way, unless
you brute force on the nine hundred
ninety nine CVS's
and we know that in it nowadays.
Nine hundred and ninety nine is such
a large number isn't it.
It is a staggering nine
hundred and ninety nine.
Wow. So yeah.
So that's the whole security from
cloning from cheap to Macs.
Stripe is right there on these free
digits.
So and also
there are a lot of websites that
surprisingly nowadays they don't ask for
the TV like, I don't know, Amazon.
So if you buy to Amazon, you don't get
asked for a CVB.
So I got defrauded multiple times,
are with data
that was came from my card and
that was used without the CBB.
So of course you get your money back.
OK, so it is a little hassle for
you, but it's not a big deal.
So you waste time but you will
get your money back and only goods
and services can be
acquired by the fraudster in theory,
because in practice are companies which
they only exist to convert goods
and services into cash.
But anyway, you will get your money back.
So there's no liability shift here.
OK, but it still gives you an idea
of how things could have been a little
better from from the beginning.
Now, if they guess the CV, that's a
different matter entirely.
OK, but, you know, I don't want to delve
into that right now.
So that's the first thing that can
happen, which so is the fact that
also data is not encrypted,
the next part is offline, that
authentication. So EMV
introduces a way to authenticate
the card so that you know that the car
is exactly yours and in principle
they should work. You have a smart card,
very powerful.
There's no reason why they shouldn't work
now.
There are three ways to authenticate a
card. There's the basic
way, which is called Saeda, static
data authentication.
There's a better way called the dynamic
data authentication and there's an even
better way, which is called the combined
date of integration KDA.
Each of these methods patches
the flaws of the previous one.
And this offline date authentication
methods were introduced to support
offline transactions.
So to give you the ability of doing
transaction completely offline so they're
never used by ATMs, which they
only go online.
And nowadays, in theory, you should only
see DDA cards, not SDK
anymore.
So one of the first issues.
So what's the aim is that you have a
static signature, which means that you
can read a card, you can copy the data
and you can copy the signature.
So the signature is basically worthless,
so to speak, because there's no challenge
or response mechanism involved there
at all.
So if you're offline, you
can just present a valid signature
that you skimmed somewhere and then you
can just fake the transaction because
the transaction does not go online.
Nobody will verify that.
The only thing that is verified is
a static data authentication,
which you're cloning.
So well done, EMV
in introducing secure offline
authentication.
So DDA was invented where
a random number is being exchanged and
we're going to talk about that so that
you have a challenge or response.
But it was also a problem with that.
So they invented KDA where they finally
do the authentication and the transaction
at the same time.
So this is to explain how EMV
is basically patched
and KDA is, to me,
are not useful because you can always
fall back to previous authentication
matters. You can always fall back to
Tuesday if you want.
So offline transactions are insecure
if you support DMV standards,
as it should be.
And now when I mentioned the
random number, there's a very,
extremely nice and brilliant
paper for people much more clever than
me, which are to find people at Cambridge
where they highlight the attack,
which this paper really highlights the
poor design choices which were made with
EMV. So the unpredictable
number which is used to
secure the dynamic data
authentication. So the dynamic
component is the random number which is
being exchanged is generated
by the terminal, not by the back
end. So if you have terminals
were ever flawed, random
number generator where you can predict or
manipulate random numbers,
you can effectively clone a transaction.
And you have what they show in the paper
that there are certain terminals where
their definition of random number is
that you need to
give back 10 different numbers.
And even if they repeat themselves, well,
they're random because the PCI
compliance said that the test mandates
that you going to give me 10 numbers and
they all got to be different.
So that was the definition of random,
which is awesome.
So what you
can do, you can collect transaction
data from a genuine transaction.
And when you see that random number
popping up again, you replay that
transaction.
Luckily, there's one limitation here.
You've got to be in the same country.
You've got to spend the same amount and
you've got to be in the same currency and
on the same day, not on the same
merchant, because the merchant
information does not take place
in the transaction between the card
terminal. It is something that only the
terminal knows.
But if you fit within these conditions,
then you can replay a transaction you
don't even need a valid pin in.
Your transaction is close to 100 percent.
So let's think of this
in terms of liability.
We're not talking about massive fraud
here. I'm not going to say that they
can clone millions or car right away.
Let's think about the single
fraud that you might receive and the
liability that is shifted to you.
All of these legal attacks, they
practically destroy every argument
that would shift the liability to you.
And this is the key of this talk and why
it is important to talk about these
things.
So if there's a fraud.
Always check if the same
random number was used in the same
country by a different terminal
or if the random
number of the terminals come predicted or
not, if the bank cannot
conclusively prove this to you,
then there's a chance that this attack
might have happened.
Of course, even if it might not have
happened, just the chance that it could
and the fact that they cannot prove it
means that they cannot shift the
liability to you.
And this is very important.
Now, I'm not a lawyer, so I'm not giving
you legal advice, but this is not what
is.
So and of course, they'll also want
everything, which is called the
application transaction counter, which
gets increased every time use the car,
which can also be used to detect these
kind of frauds and
all of these detection.
By the way, none of this is done
nowadays by backhands whatsoever.
So what they could do, they don't do.
And this is why it is important to know
about these things.
Second attack.
Stolen by Cambridge, Peine Verification
Wch attack.
So this is the way the pin is verified
by the terminal, the terminal
as the car.
Is this a valid pin and then a car?
Yes. That says, yeah, sure.
Or no, it's not.
That's it.
There's no authentication.
There's no encryption whatsoever in the
basic form of this mechanism.
The response is not encrypted is just
a yes or no.
So, of course, a man in the middle
of ised can just spoof
the response and say yes
to anything and create a so-called
yes card.
Now, this specific
attack was anticipated by
a SUB-STANDARD of EMV, which is called
a common payment application
specification.
But guess who's checking
this specific occurrence in Bacons,
nobody so far we've done
consulting for many financial entities
in Europe and abroad, we
have never seen detection for these kind
of attacks, which takes correlation of
two bits.
If these two bits are both one, you could
if one of them is one and one is zero,
then it's not good.
And, you know, mathematically that
this attack takes place,
but this is too difficult to do.
So this is one example of
this of this
fraud taking place.
So we have a clean run where
the pin gets transmitted.
You see, it is the little squares.
We obfuscated the pin one, two,
three, four there.
And you get a response.
And in a matter in the middle
attack, you can just intercept that
and then force saying
yes and you will never relay the actual
PIN verification to the card so
the car will not know.
So where does the detection lie?
The card knows what happen
and the terminal knows what happened.
Each has their own view and
the card signs this
data so you can correlate.
The cardholder ratification matter
results generated by the terminal
and the so-called ISHWAR application
data, which is generated by the car,
these two pieces of information, I will
tell you, if the terminal is verified
in offline and if the card is
verified up of line and when this attack
takes place, the two mismatch
and the ID is signed.
And to see if KVM are, you cannot
intercept with a shim because
the gap is between the terminal and the
back. And so this can be easily
detected, but it's not been
detected. So this is one thing that you
should ask.
If you're involved into a fraud, you
should ask the bank, please show me the
edyta was a change.
Please record it for me because it's
vendor dependent and also showing
the CVR and let's see if they match.
That's one thing they should provide to
you.
Now, our contribution
to chip in being a tax was
to take this even further
and say, OK,
let's assume they fix this flaw,
is the PIN protected?
Can we still do something with it?
And we discovered the KVM downgrade
attack.
So the card
tells to the terminal
how the cardholder should be verified
with what is called the civilized.
So sometimes you might use a signature,
sometimes using mieux and
pin in plaintext.
You can use an ciphered pin woods
who gets to decide that the card
tells to the terminal.
This is what I support.
And then the terminal can decide.
And the card also tells the preference
of support the methods.
So the card can say, I want to try
a signature first, but if you're not
ready to commit to that, let's use a pin
offline pin. And if you don't want that,
let's use an online pin and so on.
And this is the KVM list.
So what we discover is that
even if this information is signed
by the date of authentication phase,
which is supposed to authenticate the
card and the data on the card,
if you tamper with it, the
terminal will still be so
happy to pass it and accept it
and honor it, which is
a problem on its own, because
and I'm going to get into detail for
this. So this is a KVM list.
These are all the the feels that you can
have. So were interesting to plaintext
pin so you can have an ciphered pin,
which means that the pin will send
encrypted to the card.
The response will still be unencrypted,
by the way. The response will still be
yes or no, but at least the pin
is encrypted and you have
online pin, which means that the card
will never see the PIN request
because it's between the terminal and the
Bakken, or you have signature or
you also have no PIN required or no CTM
required whatsoever, which is what we use
in toll roads in Italy.
We pay with a credit card.
There's no signature, there's no pin
because we fall back to that.
So we asked ourself
what we if we use only GDA
cars, which is what banks say,
it's the state of the art, you know, and
we validate the signature.
So this is a problem.
There's one piece of data
on the car, which is called the Issuer
Action Codes, which
specify which failure
conditions should trigger an
online transaction.
So this is what happens.
I'm the card and I'll
tell you to the terminal.
Please do not deny a transaction
without attempt to go online, even
if my signature fails.
So let's think of this in terms of
security.
You have data which is signed
and you can tell to determine what
to do if the signature fails.
That seems obvious to me, right?
It's like a I want to go out with
you. I really don't.
Yes, you do. OK, that's how he goes,
right?
So in every test terminal
and bakin we were able to manipulate
when it was necessary,
these action codes so that if we tamper
with KVM list, we
will not be rejected offline.
And guess what? The KVM list is passed by
the terminal and it's applied so we can
tell the terminal what to do, which means
that whatever car you have,
we can tell the terminal.
Please verify that being offline,
which means that a skimmer
can always force determined
not to transmit what is input on the
pin, but as a pin to the card,
which leaves for interception.
Which makes the whole liability
fall apart, and this is one
example here, we modify the KVM,
so this is a normal car which
goes online.
Because you see on the left side,
the verification phase is empty
because there been none because that went
online, but on the
right side, there's our man in the middle
where we actually invalidate the
civilized.
And we force the transmission to
the car.
And keep in mind that
the back end will know that
the signature failed,
they just don't care about it.
So from a practical standpoint, you could
say that this is somehow anticipated.
The signature fails.
But since the data authentication
of the card is a separate
step from the integration
of the card holder, since
those are treated separately, then
the two phases, they
don't use the knowledge gained from
the other.
So that's why you can always force the
pin to be transmitted plaintext.
The way you detected well,
you have offline authentication, failure,
and, you know, you might even correlate
how the card was issued, you might
have a card which only has online pin in
the KVM list.
So you can tell if the offline PDA
requested something wrong is there?
But that's simply too much data
to keep on the back.
And, you know, the backend would have to
know every configuration for every single
card, which to me is not reasonable, but
apparently it is.
But you could at least reject every
transaction we does doesn't
pass offline that authentication.
But, you know, sometimes you also don't
get offline data authentication
processing at all.
So and one more important
thing, even if you would have these
markers, these are not
conclusive evidence, either positive
or negative, because as
a schema, I can always reset
the terminal as soon as I get the pin,
which means that the back and one
see anything at all and
we don't get any data from the
transaction.
So this is a design flaw
that cannot be even detected
if you implement it completely
covertly.
The only way to fix this is to
have the firmware on the point of sale
device to refuse offline
plaintext verification.
All the time, if you know that your cards
are don't support that, or in
case of signature invalidation at least,
and this is a big problem with liability
because you cannot say that the EMV
protects your pin.
Despite the card configuration, you
might have a car
which doesn't even have a pin on
the card itself, and
I would still be able to do this and to
see your being.
So if I steal your card afterwards,
of course, I would need your physical
card. These are the scenario we're
talking about.
Then you will never be liable.
But the classic case is that if you lose
your card and it gets used and
he has a chip and pin, they will tell you
that you are liable if it's used with a
pin because they tell you that you're
being negligent because maybe
you had your pin written down in the bag
or somewhere.
But it doesn't matter if it's true
or not. They will use the technology
of EMV, which is flogged against
you. And we see this all the time.
And we consult card holders into
preventing these kind of claims
by asking for the right data.
And which is why I'm giving
this talk right now to let you know what
you can ask in order to prevent these
kind of things. Because even if we're not
talking about millions of people being
fraud, I don't care.
As long as one person loses,
I don't care one hundred two thousand
euro because these technologies
turn against them.
I don't think that's right.
And I think as an I.T.
security community, we should work
against that.
Thank you.
So going back to the PIN verification,
which attack the one where we say yes or
no to the pain that was discovered by
Cambridge and their first paper, they say
that depending on the KVM
list, you know, whatever is specified,
Chip, his signature online pin,
you know, they tell that this is
their attack is not applicable to certain
cards. And at the time when we
release the KVM downgrade attack, we
thought of combining the two.
But we you know, we didn't actually
tried this summer.
We tried it.
There's no reason why shouldn't work.
And guess what?
It works just fine.
We can combine the KVM
downgrade attack and the PIN verification
which attack to use stolen cars
regardless of their configuration.
We can use cards which are only
meant to go online.
We can use cars that only have a
signature. We can use cards
where the actual chip on the card
doesn't have the pin stored.
There's a command which you send to the
smart card saying verify pin.
Certain cards do not support that
because they are secure,
secure and
they don't even have knowledge of the
pin.
But we if we combine the two attacks,
we downgrade or upgrade
the card depending on its configuration
and then we force a fake
offline pin reply.
And of course this works regardless
of the card configuration.
We were able to test it with every card,
with different stores.
We tested our own cards.
We were able to fraud our own
cards with PIN, which is
one, two, three, four, which is not our
actual pin.
So it doesn't really matter,
the back end is not even smart enough
to understand that offline
verification took place on a card that
has no pain whatsoever,
even with cards, with a signature,
so that the Cambridge been verification,
which attack can be applied to
every single card.
So if the bank will tell you all, but we
only have cards and you don't even
have a pin on the car or you only go in
line.
It doesn't matter at all because
you can always downgrade.
So this is an example of that run
again on the left side,
there was no verification whatsoever
and this car was set to do online.
So we do two things.
We do the combination of the two attacks.
First of all, we do change to civilized
so that the is being asked to
the car. And then we reply,
yes, this is my pin.
Of course. One, two, three, four is my
pin.
And you get both the textural markers
here because the signature fails.
And the card tells that
he has verified no pain, while the
terminal will say, I have verified a pin,
so we have two things that we can spot.
No back in that we have tested so
far was marked enough to do
this kind of correlation.
Not on the same day, not after a
week, not after a month,
nothing.
So this is a main problem here,
there's another problem,
EMV supports the concept of transaction
certificate, which is the final thing
that happens.
The card will spit out to determine
a transaction certificate, which is to be
the proof of the transaction.
These transactions certificate is not
immediately sent to the back and
sometimes is not sent to the back.
And at all any you know,
it should only be parsed when a dispute
arises.
So guess what?
You can change that.
You can put it to dead beef, whatever
hex lead
sentence you want to put, and the
transaction will go through right away.
So what is supposed to be the actual
proof of the transaction never gets
checked. So I could potentially fake
my transaction certificate on all
of my transactions and then claim all of
them back and ask them, look at
the transaction certificate.
It doesn't really make sense.
And the bank would be, you know,
obliged to tell that I'm right.
Of course, that will be not very smart.
But this is to give you approve
of how flawed this is.
And this also means one thing that when
you see on the card, the transaction
certificate, the issuer application
data, which is what allows
you to detect the PIN verification
which attacked or the application
transaction counter, since those
are printed on the receipt from these
last phase, they can all be faked.
You can put whatever you want there.
So if the bank will
ask you to see the receipt or if they
will show you the receipt as a proof
of some metadata, that is important.
You can always say that you don't trust
that because you can tamper with all of
that.
So whatever is on the receipt
with these specific products can be
faked.
No problem about that.
And this is also important to know.
So the banks will have the following
arguments in case of EMV, fraud
and verification can all be compromised
with EMV and ciphered
pin guarantees.
Security online PIN
can all be intercepted and plaintext
is get for backwards compatibility only
and can only be fores if
you tamper determinable or on
specific configuration.
All of these are not true.
As we've shown, we can always.
Fall back to plaintext pin,
so all the mechanisms that
are there to protect the PIN
verification, they do not work and
we don't tamper determinately itself.
I could even have my own card,
which has NFC Bluetooth connection
to a real car, and it would just
do this kind of transaction.
The terminal is intact.
We don't change the firmware on the
terminal. We don't do anything wrong
with it. OK, so don't take the
fact that we insert Agim as
an example as terminal tampering, because
that's not the case. It could be very
well be my own card.
So liability falls
apart, especially in the CVN
downgrade one where you can have no
log's in the
end.
So if you have a dispute,
the bank should at least provide you the
predictable numbers from that same
terminal or from other terminals that
were used with your car on the same
day.
They should provide you the terminal
verification results.
They should provide you the E application
data. They should provide you the
application for that can counter all of
the metadata that I've shown to you.
They should provide them to you in order
to give an analysis of exactly what
happen. If they don't, they
have no claims.
And even if they provide them, it really
depends on what's going on.
So depending on the different
kind of attacks, these are the things
that you should ask.
And it is essential to acquire the
backend data, not only the one
that has the terminal and especially not
the one that the receipt
has and.
So the unpredictable number will give you
the freshness of the terminal,
run the numbers the ATC
will give you if there are any gaps in
the transaction, which can make you
understand if something fishy went on at
the terminal. Verification results will
tell you of the offline data
authentication, failed or not.
And the Kalila verification method result
will tell you exactly what
happened. And they must agree
with the issuer application data which
is signed.
If they don't agree, then an
attack went on in spoofing
the incorrect being.
So these are things that you should ask.
So what happens when we ask
for these data?
Two options.
When we start asking for these data,
the bank sees that
the claim goes forward because some
people, they just want to settle before
or they get scared and they lose their
money. And this is what actually happens.
I have.
Experience with this, so
if you get to ask the data at
some point, depends on the country again
and not a legal expert,
but this is how it is.
You go to the arbiter.
And the arbiter, guess what, it
will tell you that the burden of proof in
fraud claims shall fall in honor of the
payment infrastructure.
And at least in Italy, they ruled that
the pain can be acquired in many ways
that outside the cardholder control.
Now, this is the interesting thing,
every single
fraud case where the liability
they attempted to shift the liability to
the customer, the bank
tried to do this anyway,
even if there were dozens of legal
precedents with response to no one.
So now we're in a state where this kind
of response is just, you know,
as it goes in law, is just quoted
from previous cases.
They wouldn't even bother in doing
the whole dissertation.
They say, you know, go track
like they do in law and order in us.
Go and Tricor.
Eighty four, it was Johnson versus
me. This is what happened.
So that's what it is.
So but they try anyway, even if
they know because what do they have to
lose. Right. So it is important to know
that at the end of the day, in most
countries you are protected and they can
never use the technology against you.
But you need to have to show
that you know the technology
a little to know what to ask for.
Because, number two,
in some cases, as soon as we ask for
detailed logs, guess what?
The bank settled and we had to refund.
I don't know why, I don't know
if it's because the data
would have proved that some frog was
taking place.
I have no idea.
The only thing that I know is that the
classic Vendel response in this case is
there are sufficient security mechanisms
in the payment industry to prevent this
kind of things to happen.
This is a classic response that Visa,
MasterCard or any bank will
give you because and
in a way you would understand them.
They will never tell you that, of course,
inves Flarf they would just tell you that
there's a sufficient number of mechanisms
in place.
But as soon as we see fraud cases being
shifted to the customer, as soon as I'm
able to fraud my own card and nobody
calls me, you know, I think that there's
something wrong with the system,
especially where that analogy can very
well do end to end encryption from the
card to the back end.
And the terminal would just be a dumb
relay. But, you know, this is not the
case. And as long as we don't admit that
there are these flaws, we will never we
will never fix them.
And there's one more thing that I would
like to say in the US
very recently.
There are you know, they're sort of
moving after saying for many years now,
we're never going to move away from the
magistrate, they're going to move to the
chip.
And since for
whatever technical reasons they're going
to do chip and signature, they're not
going to do a chip and pin.
So they're going to remove all of
the PIN verification part, which
in some way it's a good thing,
because if you have a chip, a signature,
you're not liable.
The chip protects the actual transaction,
which is fairly well protected
if we ignore the unpredictable number.
But the transaction, that's the only
thing that, you know,
is a security issue there.
But that can be fixed.
If you would remove the whole cardholder
verification phase, then the cardholder
is not liable. So, incidentally,
by doing less, they're actually doing
more from a security standpoint.
So, you know, things can be done.
And also in the Netherlands, after one of
our presentation, they they patched
every single point of sale device in
order to refuse plaintiffs verification.
Of course, they did that only for local
cards.
And I don't think that the detection of
local card uses of data,
which is actually signed.
So I think there was a bit of a problem
there.
But anyway, so this is how it is.
So
I think we have about ten minutes for
questions. So and before
that, I also have a little demo here.
So we show you.
What happens when
both attacks are combined?
So this is how we do them.
We have an FPGA
which acts as a shim
between a real car terminal
and an actual point-of-sale device.
So you see them here.
That's the terminal.
That's a reader attached to the laptop,
which is doing many in the middle through
the FPGA and the FPGA will have
a smartcard card which goes inside
the terminal. So all of these attacks,
we test them with the code
running on the laptop.
In this case, we're using one of our own
cards.
We plug it in so this car has no
concept of offline in any civilized.
So we do two things, we downgraded
the KVM on the fly.
So we type the amount.
And then Apennines been asked, so the
fact that Apennines been asked right
there before going offline, before
going offline means that the first part
of the attack was effective because
we convinced the terminal
to be so kind to us.
The pin to the car and
the second attack you will see
is because we will just type one,
two, three, four, five.
And I'll gets accepted and then the
terminal goes online because we said
yes and from the logs
we we see that we can tamper both of them
and so on.
So that was a demonstration.
Thank you.
And before I answer questions from you,
I got an e-mail from a journalist today,
maybe easier, I don't know.
He asked me three things.
The German finance industry says that
the weaknesses of EMV in general would
not be an issue as point one,
as the cards would not be given out
to customers.
Irrelevant.
ESTA is always present
as a backward compatibility into every
card, and this is a reason why you can
use your car and go abroad because
some terminals don't even know what day
is. So every EMV card by
De Stander has Asda
and DDA Effi Asda Visa
as the the only Asda, but every card
also supports as the is a capability.
Second point Fulbeck transactions
will not be allowed.
This might be, but it's very hard
to accept that very hard because
if I come here as a tourist, I can use
my Visa card.
And even if they would
do something smart like detecting
your own card, I can always fake
a foreign car in order to do an
interception. I could make up
Mickey Mouse credit card, totally
fake in order to intercept a pin.
And you will never know because I can
always reset everything before
going online so I can always get
the pin that you're typing on the
terminal for.
There were no German EMV card that were
breached ever.
I cannot possibly comment on that without
reaching a lot of India's.
So any questions from the audience?
There, please use the microphones.
Have you ever played around with the idea
of faking the entire cast?
I mean, you skim the number and then you
just use the smart card to play?
Yes. So we skim
the real card so the skimmer can read the
card independently.
We fake a card
or we use another card, a previous card,
like an SD card.
We get to the point where we do pin
verification, we intercept the pin, we
reset everything.
And then you would just see that our
terminal resets or it will send
you reject transaction.
And we tried one more time.
The reason I'm asking is because it's
relatively easy to steal
the number itself, whether visually
or for a magnetic stripes.
Then if you can create a
fake chip card that
presents itself as that number,
but you actually control the chip, then
you can accept whatever pin.
And yes, but this is only for PIN
interception where you actually go to the
actual transaction that you cannot fake
unless it's offline.
So all of this is for either using
a stolen card with a no win the pin
or to intercept the pin on any card
transactions cannot be faked unless
you can predict the unpredictable number.
That's the only condition.
OK, so this is important.
Thank you.
Hi.
So we'll be talking
only about those couch readers that you
find in shops because like in
ATMs, like as far as I
know, if you go to an ATM
and and enter your pin, the
pin is encrypted in the touchpad.
Right. This is sent to your
bank. And this is like not
that bad. This is actually quite
OK. Right.
So there are two things that I have to
say on this.
First of all, we never play with ATMs
because it's extremely difficult,
even as professional, to get to audit
them.
But in ATMs is, as you say,
they should all go online.
I can tell you from personal experience
that at least initially, not all of them
go online. And it's very easy to
understand that if you
type the wrong pin, sometimes
it gets rejected right away,
like it takes even a millisecond.
And you can also check by reading
back the logs on your card
what was actually use as a
PIN verification mechanism.
And at least in certain ATMs,
I think this was in the migration phase.
They were not checking the pin online,
but I cannot say what is it
today.
What I would say is that
I worry much more about point
of sale devices when it comes to an
interception, because there are so many
of them and there are so much more
insecure.
You know, you can gain I can gain access
to a point of sale device much more
easily than doing it on ATMs.
I don't have cameras pointed at me.
I'm not outside a bank.
You know, I can collude with the
merchant. There are so many ways and from
the liability framework perspective,
all I care is about one point of
sale, one to the.
This might happen, right?
Yeah, I agree 100 percent.
I was just thinking like what to tell my
can I tell my grandmother that,
OK, if you use an ATM, you're
secure because your pin gets encrypted
on the touchpad no matter where you are
in Italy. US, Russia will in principle.
Yes, but in our
line of pressure I
can I'll tell you hundred percent for
sure. I don't know because
we never tested them.
But in theory, that's what should have
happened. Yes, you are much
you have much better chances of being
safe from EMV protocol,
interception on ATMs, but
you're much less safe from actually
physical interception because the
ATM skimmers that I've shown there are
still there.
So, you know, at the end of the day,
you can always say that there's a hidden
camera and the whole liability falls
apart. These are just, you know, more
cases to say that the pin is not really a
good way to make you liable.
Thank you.
I've got a question regarding
online payments regarding even
in some countries I know of Holland,
they ask for the date of birth and then
a password.
You know anything about the security
behind this and liabilities?
So a friend of mine colostrum, Lori,
from a church collapse, very smart
guy does all the RFID stuff.
You should check his work
once said a card with, you know,
secure code by Visa and MasterCard where
you go online.
And in order to provision it, you know,
you have a password.
And then if you the password doesn't
work, it will ask you a question like the
name of birth, the birth date and so on.
So his daughter wants to buy
something with his credit card.
And Adam gave the credit card to the
daughter and says, let's see if you can
hack it. After ten minutes, she came back
and she totally reset, of course,
the all secure code thing
with data that she wasn't supposed to
know because there was a secret question
or a secret answer along with a birthday
and so on. So, you know,
security and
birth date and other
kind of data, they don't really match
together. You know, we're struggling
here to get proper SSL encryption
from browser to websites, you
know? Well, you know, it's
just, you know, there
are meaningless at the end.
There are not they might have been
something that I would have vaguely
respected 10 years ago,
you know, 20 years ago.
But nowadays, you know.
No, just no.
One of that question, please.
I have a bunch of questions from the
Internet. First of all, on
all the cost of proper security, actually
larger than the current cost of the
insecurity.
So this is the classic argument from the
bank. They say, OK, I have like zero
point zero zero one percent.
So why would I care
if the customer if the Khairallah gets
the money back?
Yes. I mean, you can argue that the time
spent in getting your
money back is, of course, as a cost.
But in principle, you could say, yes, of
course. But this is the issue here.
You know, they don't get their money back
if they don't fight the claim
properly. So when you see the statistics
about fraud, they don't put into
account these cases where
liability shifted to the customer.
And that's my old point there.
Even if you have one person which loses
two thousand euros that they didn't
lose because they were negligent,
whatever that means, you know, they
shouldn't lose this kind of money.
So I don't care if that zero point zero
zero zero zero zero zero one percent
of the total profit issue didn't happen.
So we handle about a dozen cases.
And that's, you know, that's more than
enough. And we know that if we
which are very small company, we handle
a dozen cases. Maybe there are so many
more and maybe there are so many more
people that they didn't get their money
back.
So, yeah, that's that argument
is not relevant
to the kind of discussion that I want to
have here.
OK, three last questions, and
we will be there for more questions for
you, so please.
Yes, approach me any time.
OK, three more question number four,
starting 14
on just one quick comment.
The CPV on the Max Tribe isn't the same
as the CVB on the back of the car.
Those are two different values, correct?
Those are two different ones.
Yes, at the beginning.
But in a similar vein, to to what's
to the to the price or
the cost of the attack to what's coming
out. You said you don't necessarily
have to have a wedge and a stolen card
if you're doing downgrade attacks, for
example, because you could maybe
have a card that communicates to the
stolen card via Bluetooth and
yes, a man in the middle.
But that would make an attack at a post
pretty expensive for the attacker.
So it seems that that's
somewhat
unlikely attack scenario.
If I stole cards, I think there's more.
Is this a question mark?
Yeah. Is I mean,
that whole cost of attack things to
the attacker as well.
So there are two aspects here.
So the first aspect is that from a
liability standpoint, we don't
care about how likely it is.
As long as it can happen.
Then from a legal standpoint, then,
you know, you are not negligent if this
can happen.
The second thing is,
if I would be a criminal, this is what
I would do. I would skim every single
point of sales that I can in a way which
is covert.
And then as soon as one car gets stolen,
there's a very nice database where all
you stole that car, have the pin
for that.
So this is something that you can do now.
How likely is that happening now?
I don't know. I don't think it's very
likely. How likely is it
that maybe five, 10 years from now
when the max drive goes away, much
more likely.
So we need to address this now.
And having an industry which is pushing
this technology is the holy grail of
security doesn't help.
So this is my old argument here.
So you can see both sides
to please.
Can you comment on NFC
payments?
Yes. So NFC payments,
it's it's a complicated matter.
There are many ways of doing them.
Some of them, they expose very
similar vulnerabilities of what you see
here, because it's actually EMV
going wireless.
So they sometimes
they have this classic downgrade
mechanism.
You can harvest the
KVI, the dynamic.
They have a dynamic c.v you can harvest
and then replace. So they have their own
set of issues different.
They will require another one hour talk
to address them.
But let us say that there are similar
issues there as well.
And it's not something that was well
thought of from the beginning.
OK, you have a smart card, the
actual signing of the transaction,
that is, except for the random number,
it is done correctly.
If they would just stick to just that
phase. And the random number comes
from the backend that would have been so
much simpler, minimal design
and to an easy I want to pay this
done.
And the fact that they're not following
this also reflects on
NFC in a way.
Another offside question, the last one.
Thank you. What precautions does your
team take to prevent being legally
stomped on by the bank as you probe
their weaknesses?
So, first of all, in a many of
our consulting, we were actually paid
by the banks to do this, so.
In our experience, most banks,
they don't consider these to be serious
issues, but not all of them.
There are a few of them which are very
exemplary in the way they
consulted us into exposing excessive
techniques. And they have security things
which they care.
They are aware of all of these issues and
they know that it's a political fight.
So I don't want to blame the entire
industry.
Second of all, from a legal standpoint, I
mean, we
have the Cambridge Group which preceded
us.
We have done our research.
All of these you can read through this
done there. I mean, you know,
in our job, we it's a double edged
sword all the time, everything that we
do. Ninety nine percent of the docs here,
you do something which you think is for
the greater good, but it can also be used
maliciously. This is the thing we're not
if I think of something,
I think of an attack.
There's no reason why you don't have 20
other people's thinking of that before
me for criminal activities.
So there's no reason to keep this
quiet. You know, that's what
our industry does.
And I think most of the audience here
agrees to that.
And it's a well known, accepted fact
of the industry. So so far, we didn't
have any problems at all.
OK, so that's it, we have to finish
now.
Thank you very much.
I hope you enjoyed it.
And if you want tomorrow,
come see this.