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/882 Thanks!
Imagine you are at the checkout,
at the checkout at the supermarket,
and you take your
cash card, you get something like 35
years to pay and you place
it just on the top of the
terminal. It makes it beep
and you have paid well.
How does near field communication
work and in
particular, what happens
at the protocol levels?
Well, the answers are given
now by Simon Wemyss, who
is a co-founder of Pay Works.
It's a company specialized
in point of sale payment
Gateway Technologies.
Simon has studied
informatics in Munich,
in San Francisco and in
Los Angeles.
So let's welcome now Simon
with his talk on
decoding contactless card
payments.
Simon yachters.
Thanks a lot, Anchia, what
a crowd. Welcome, everybody.
Thanks for joining tonight.
And tonight, I want to talk about
contactless card payments and how we go
from, like, inserting
a card to tapping a card
to, in the end, just tapping your
smartphone.
And full disclosure, I'm not
talking about, like, exposing
new security risks in that format.
And also, I'm not going on the lowest
level of the EMV protocol, which is
basically below
running this.
But I really want to focus on the
status quo.
How is basically a contact conductor's
card transaction working?
How do we do
Apple pay?
How do we do Android pay?
What is involved there?
And why is it not possible to actually
take a card and clone
it to your smartphone, something that
the chip would actually prevent you from,
from doing?
And.
Just to give you some context where this
is coming from, we'll get paperworks
where we run a payment gateway and
develop tools for making transactions
easier for developers to integrate.
And over there, I'm mainly responsible
for integrating new terminals,
connecting new banks.
And I want to take the motto of the
Congress to that and
just to that and give you some
insights and what I learned while working
on that.
And, yeah,
let's get started with this.
Probably everybody here in the room
has heard about contactless payments and
has used it, maybe, maybe not.
I mean, in Germany, adoption rate for
contactless transactions are relatively
slow.
First of all, you get a new card from
your bank or your credit card company.
And even if you have that, you still need
a terminal which is actually able to
handle transactions.
And if you then finally do a contactless
transaction, the cashier is looking at
you curiously and saying, well, it's not
that that's not how it worked basically
before.
And in the end, you get your goods, but
they always some surprises waiting for
you.
And what we are looking at tonight is
basically, first of all, what makes a
contactless transaction the
blueprint? What status do we go through?
And then we need to discuss ways of
actually converting your smartphone
into insulating
or simulating a contactless card.
In addition to that, I want to talk a
little bit about making payments a little
bit more secure at the point of sale
or on the e-commerce side in
general, where we talk about tokenization
and then we have all the information that
we need to actually look into
Apple Pay and Android pay.
And in the end, I just want to give a
quick look out on how I could envision
the next steps when it comes to
contactless transactions and transactions
at the point of sale in general.
So looking at contactless transactions,
this is a relatively new technology.
And you might think, well, somebody came
up with something new that was basically
state of the art.
But if you look at the underlying
protocols, you would see that this just
brings in transactions.
That's the protocol or the
the workflows that are used for
contactless for the traditional chip
cards to the contactless level.
So you basically take what you have and
put basically NFC on it and
and that's it.
And I'm not going into
too much detail when it comes to the
contactless transaction.
Where he was talking about in the
transactions and it's actually going on
the lowest level, looking at those banks,
looking at the protocols and what
actually makes a transaction work
in the end, what data elements are
involved in there.
But for us, it's important to first
have a look what is actually
or who is actually involved in an overall
transaction. And this is not only true
for a contactless transaction, also
contact transaction using a chip card is
basically using the same entities.
So on the one hand, you have
yourself as a shopper, as somebody who
wants to buy something and you have a
credit card.
And this credit card is given to you by
a bank, by your bank.
And because this bank issues
you with the card. This bank is quite an
issuer.
And then on the other side, you have a
merchant who owns a store
and he wants to accept credit card
payments. So it needs a terminal.
But just owning a tunnel doesn't
give him anything.
He needs to have a merchant account
within a separate bank where
in the end the money is basically
put onto and this is called an
acquiring bank or acquirer.
So now we have two sides and
basically they itself look
fine. But in some way we need
to bring those two together.
And, well, we know what we use.
We use the network and in
our case, we use payment networks.
This would be, for example, the Visa
network, the MasterCard network, American
Express Network, the networks that are
available, and they interconnect to the
acquirers and the issuers so that in the
end the payment can be transacted
between all parties.
Not that we know who basically is
involved in a transaction.
Let's have a look the of the different
faces or steps you go through during a
transaction before you can actually make
a transaction.
Well, you need your card.
So this is the card issuer you step and
the merchant needs his terminal.
So this is a terminal provisioning where
he gets a terminal. If it's configured
and gets the correct configuration to
load it there and and set up and
configure what kind of cards should be
accepted.
And then we at this point where
we actually want to make a transaction
and there you basically go through three
distinct phases.
So you have a phase where you tap
your card to the to the terminal.
Then you have a phase where the terminal
is doing some internal stuff, evaluating
what the data that it actually received.
And most likely after that,
it will go in a phase where it basically
goes online. Users network.
Talk to the issuer of your
card to check if you actually have funds
on your account and if this transaction
is genuine and should be actually
approved.
And after that, we have a separate
phase, which is not that important for
us, which is the transaction settlements
or this in the end, make sure that
actually money moves from one account to
the other.
We're going to focus on the on the three
highlighted here.
So imagine you go
into a store and want to pay with your
cart, the first thing is that
on the terminal the amount
is basically shown and you
as a shopper, go there and tap
your cart on on the terminal.
And the terminal in this face basically
says, OK, well, I have a contactless card
in my proximity and I have a basic
idea what kind of cards sources
the Visa card is, as a MasterCard
says, an Amex card, JCB, you name it.
And as a first thing before actually
continuing with the transaction,
it activates a special kernel.
And what a kernel is, is an
implementation of
of a payment workflow that is specified
by the schemes.
So visa mandates a different
workflow, how the card and how much would
interact as part of a contactless
transaction. And then MasterCard, for
example. All this was easier
during a normal chip transaction because
there was only one kernel.
Now we have seven or eight kernels and
each payment scheme has its own kernel.
And after the correct kernel has been
loaded and activated, the kernel now
drives the transactions between
the card and the terminal.
And the next phase is then the
the data exchange phase where the
terminal asks the card for
some data to be given out in
order to complete the transaction.
And what is normally included is, first
of all, the account data.
That's the credit card number, expiry
date information like that, which is
crucial for actually routing the
transaction to the correct bank and
making the transaction work.
In the end, you get
a signature on specific
data elements that the card generates
and which allows the terminal to check if
the card is an actual payment card
and the card also generates
a cryptogram.
That's in the end cryptographic
hash that allows the issuer
in the end to verify
that the transaction is genuine and that
it's like a recent transaction, not a
replay, for example.
And all of this just happens between the
card and the terminal at this point.
After that, you can remove your card.
And that's also one of the big difference
already.
If you would do a contact transaction
with a chip, the chip card needs to be
in the terminal until the complete
transaction is done here.
You can remove it and you don't
accidentally wriggler with it and trigger
a board. Sort this out to provide some
more usability features.
Also, the
next phase we're looking at is then
what's happening on the terminal.
And at this point, only the terminal is
doing something.
And first of all, it checks if this card
should be accepted at this location,
could be that the card should only be
used domestically in a
country. But it's not the country of the
merchant. It could be that
this card is an ATM card and shouldn't be
used at a retail location, for example.
And those things obviously check first
as a second step.
The the terminal is verifying the
authenticity of the the
data it received from the card.
And for that there is a public key
infrastructure in place at the top.
There is a Rutka from from the payment
schemes and below that
we have ACA
from the actual issuer off the card.
And then we have certificates which were
put on the card itself.
And as
a basically as reading data,
it got this this kind of
data. And using public infrastructure,
the terminals can actually check if the
signature that was created by the private
key on the card was provided
or created by an entity which at some
point was signed by the by the rootsier.
And then as a last step, there is
this phase of a customer verification.
You probably know this.
You're going to a supermarket, pay for
a couple of things.
And in the end, you're asked for a
signature or a pin
new with contactless transaction is that
if you're below a certain limit, you're
not asked for anything.
But nevertheless, you are going through
this phase and
most likely, especially with contactless
transactions at the end, the terminal
decides, well, I should go online and
check if this account is actually
valid, has the funds that
I want to get from it.
And then the terminal starts a
chain of transactions or of
of hops and the terminal sends the
data, including the account data and
this cryptogram to
the actual acquirement bank.
And from there, the bank sends to the
global payment network.
And based on the first digits of
the credit card, the payment
networks know what the actual issue is
because every issuer has assigned a
specific number, a range.
And then in the end, the issuer receives
this kind of data, sees
the cryptogram, and basically is able
to verify that this is a genuine
transaction made with the card that
says it is and checks
if the funds are available and then
hopefully approve the.
Transactions in the end, and
then this basically goes from from
the lowest end back to the terminal.
It shows approved and in the end you
get your goods and
can leave.
So that's basically looking at
a whole transaction as a as
a as an entity.
Talk a little bit about what kind of data
is exchanged as that.
I think it's interesting to see what
actually is supposedly saved on their
credit card.
Again, teams talk
about EMV has some more detailed
information on that.
But what you basically get is account
information. You get your
primary account number, your credit card
number, basically, you get your
track to equivalent data.
That's basically a data element which
mimics the data that would normally be on
mag stripe if you still had one.
They are still networks which only wrote
those kind of information and not the
whole transaction data.
And for backward compatibility
and legacy reasons, this is still
present.
So from that, you also, for example, have
the expiry date, then
you have verification information.
So what kind of verification should be
supported?
The card can make some recommendations.
The terminal has some information.
What it actually supports that has a pin
pad does it doesn't have a pin pad.
Should we accept signatures, information
like that?
Then we have the authentication data
where you basically get
the reference to your
see a public key from
from the card schemes.
You get the public key off the card
itself and the resulting
sign data to check offline on the
terminal if the transaction is valid.
And then you have the authorization data,
which is I mean,
aside from the card information, the
amount and currency, which is crucial.
I mean, in the end, you want to get a
specific amount during the transaction
and then you add the date and time
the cryptogram, which allows
the issuer to verify that this
transaction is genuine.
And that's basically
the information that's used during a
transaction.
The format
or the protocol that is used for the
communication between the card and the
terminal is ISO seven eight
one six.
That's basically what's normally talk
between a card reader,
any card reader and a chip card.
And the payload is BRT, LV
and encoded. It's like an S encoding
format which allows
you to add more or less data as
part of your communication.
And we been talk about the communication
then between the terminal and the
acquirer or the entities behind
that.
You have mostly an
ISO variant of ISO eight
five eight three, especially
with the acquirers, but also banking
networks uses.
And that's a bitmap based format
which has a very weird
bitmap combinations and is a it's
a pain to to back if
you if you want to send a valid message
there.
Yeah. So comparing NFC to I.C.C.,
why should I use it.
What's the benefit.
Why actually go for it.
So normally you have a lot
faster transaction times.
There are timing limits
on how how fast a card and money
to interact in this first interaction
face.
And you can also remove the card already
after this phase and this is normally
completed within a second.
You also get some benefits when it comes
to verification, verification
methods and limits.
So they introduced or rediscovered
something which is a no KVM.
So this means you don't have to provide a
signature or a pin.
And they introduced a limit under
which you don't have to basically provide
anything.
In the end, this was probably added to
ease or to incentivize you
as a shopper to use contactless
transactions.
But then again, we also have
legacy. And this means that
NFC transactions run in
two operating modes, EMV
mode, which is basically upgrading I.C.C.
transaction to contactless.
And then we have an extra mode
for those networks
back then in the US, but also in other
countries around the world, which
only can allow to extract information
and not EMV or I.C.C.
information.
And they are. This relies heavily on just
using track to equivalent data.
So now we have seen how
complex this transaction is made, what
steps we go through, what is required as
part of of data elements for actually
making a transaction.
Now we want to talk about how
can we actually make a smart
phone, simulate or emulate
such cards,
and not everybody should be able
to just do it and say, well, I want to
have my card on my phone and
that's it.
And they are two distinctive ways on how
you can do this.
And the first one is especially using
something which is called a secure
element, which is an enclave
for cryptographic and sensitive
information, which
basically, once it receives this kind of
information, no longer gives it out
to a micro HSM, if you like.
And your normal chip card is
basically a secure element.
But nowadays we also
have phones which include this.
So also, again, looking at the parties,
if you talk about secure elements and
providing this information required
for making a transaction to a secure
element, what do we need there?
Well, on the one hand, we need the
smartphone or in this case we are
talking predominantly about a smartphone
which has this kind of secure element
and which at some point receives the
information and data required for
emulating a card.
And then we have something which is
called a trusted service manager.
This exists for a long time.
And this is also the entity which
normally provisions your actual chip
card, and it holds the cryptographic
keys to actually modify data within those
enclaves.
And now this this entity
is also then linked to your
smartphone and has
the power to actually load
information in there.
In the past, we have also seen
secure elements as part of the
SIM card, but they are,
for example, the trusted service manager
was the mobile network operator.
So you had another player in there and
this never really took off.
And so we have our next try
with the smartphone and some entity
which is a trusted service manager.
There is not just only one service
manager, but they are a lot
of them. And the one who is provisioning
your smartphone isn't the one
that also provisions your your smart card
in your traditional credit card.
But those are the two roles which play a
major role when it comes to making
a secure element able to
to make a contactless transaction.
So looking at when do we actually
get the data into the the secure element?
Well, I mean, you want to make a
transaction with this element you have.
So you have to do it before actually
making the transaction.
But most likely, you already have a card.
So this happens right before
your first transaction.
After that, you can make as many
transactions as you like.
And looking at exactly how this
how this works out, in the end,
um, you as a user
normally enter your credit card number
on your smartphone.
You scan it, you enter it manually,
something like that.
And then your smartphone or your
app talks to
the trusted service manager, gets
the information, hey, I want to provision
this kind of card.
And this trusted service manager normally
has a connection to your issuing bank or
a group of issuing banks.
And then there are checks saying, well,
I want to add this card
to my secure element or to this specific
phone, can
I do this?
And normally then the first
thing the issue is doing is talking to
you as the owner of your card
on a second channel, as a mass email
or whatever, and ask you, hey, if
somebody is asking to provision a new new
card to your smartphone, is this
actually you? And do you approve this in
the end?
And as long as you don't do anything,
nothing is happening. So you actually
have to confirm this and then
the issuer gets active again and provides
to the to the trusted service manager
the information, the cryptographic keys
that need to be embedded into the secure
element.
And from there, it goes back to the
to the smartphone.
And from there on your
smartphone is actually able to just
mimic an actual smart
card and drive
a transaction at a a contact
at a contactless transaction.
Contact a credit card terminal.
But well, I mean, in the beginning, I
talked about cloning, I
mean, there's not really true we saw this
what we do, we rather provision an
additional card that is added
to the secure element.
And this means that the issuer has the
means to distinguish between, hey,
we are now doing a transaction with like
an actual card and we're doing a
transaction with a phone which
has been loaded with the the
information about how
to make a card.
Also now we have a smartphone in place.
We don't have the cards.
We have something which has logic there
and most of time also has biometric
sensors, other means of of
verifying that there's actually the right
person using the phone.
And what this basically changed
or added was an additional verification
method, which is called cardholder device
TVM or on device verification.
And those of you have who has used
Apple Pay maybe in the past.
This is when you press
your home button with your finger and
authorize the transaction by this.
And this is basically a station of this
device that the right person used
that term, the smartphone,
for making a transaction.
And when we talk about the data that is
loaded onto the secure element.
This is basically the same as if you were
a chip card or a
NFC card that was actually handed out
by your bank, but most
importantly, it also includes asymmetric
and asymmetric keys that are needed for
generating the same data and the
cryptogram.
And this is really what makes the
the transaction
or at the same security level as
if you would use a
traditional ID card to
the to the level where you use your smart
card for a transaction.
And this uses the same verification
method and on the terminal level and
also on the bank level, to see that
transaction is actually genuine.
This is one way to do it, but not
everybody has a smartphone which
has a secure element, which is
also trusted by all the issuers.
And this is why we have another way of
making a smartphone
able to act as a
as a card provider.
And this is called host card emulation,
and what we
have there is basically we have a
smartphone could be any smartphone.
In the end, you need
NFC capabilities in there.
But other than that, you don't really
have many requirements here.
And then you have your traditional
payment network or the issuer which is
behind that.
And
what is happening here is that
your smartphone no longer receives those
generally
valid crypto cryptographic keys,
but it only gets limited use
keys or one time
keys.
Basically a code book that can be used
for a couple of transactions from the
network, but it cannot be used
for repeated transactions.
Same as is a secure element.
You want to make a transaction
with your newly provided information.
So this host card emulation
provisioning also needs to happen
before actually making the transaction.
But in addition to that or compare
in contrast to the secure element,
you only get information that you can use
a couple of times.
So you need to have a constant network
connection in order to make repeated
transactions.
And if you also look at how this
works out, in the end, you again
enter your credit card information on
your smartphone, you scan it, whatever,
this send directly goes to the payment
networks.
So there is no trusted service manager
involved there.
And then depending on the
solution you are using, either
the payment networks themselves generate
those one times that can be used for
making a transaction or this
is also forwarded then again to the
issuer, to the one who actually gave you
your card.
And they are then generating
those
limited keys and and they are then
basically headed up again to your
to your phone.
But the data that you receive
isn't really stored in a in a secure
element stored within your application
data.
So comparing those two methods,
H.S. versus AC provisioning,
um.
One of the benefits of H.C.
is that you don't need a totally secure
environment, but if you
have it, you can still use it.
So you can also put your one time keys
into a secure element.
For example, um,
and normally with HHC,
you only get limited use
crypto keys, which are then stored
within the app and which need to be
renewed every now and then.
And this is also then the catch here.
Well, what what happens if your
smartphone doesn't have any cell
reception and you want to make a couple
of transactions?
Well, after you have used your
a limited number of of keys
to basically create the cryptograms
for a transaction, you're out of keys.
So at least every once in a while
you need to make network connectivity
to refresh the number of keys
that that you have available.
And you can also see that he
is receiving a big push from the
industry. So actually, the
payment schemes, a payment network
and FOX themselves provide SDK
for app developers to add to into
their applications, which
abstract away the network communication,
which gives predefined interfaces that
you can use for from making the
transaction.
And which basically is I mean,
if you look at it from their side, every
transaction that is made through one of
the networks makes some money.
So they want to basically bring more
people onto that.
And here they actually have an influence,
a secure element they cannot modify, but
they can bring other developers
to use it for their transactions.
Well, now we know how we can get
data on a terminal
and act on a on a credit card
on a smartphone.
And well, now we
we have this data and there and it can
simulate now an actual card.
But well, in the end, I don't want to
have my credit card data lying
around in some kind of of
application written by some app developer
or maybe not even by a bank.
I mean, we have seen what this would
result in.
So there is another thing that was
recently introduced, which is account
data tokenization.
And what this does
is basically it replaces your
credit card number with a
token equivalent.
This is basically same format, same
length, again, for legacy reasons,
probably. And this can be used
interchangeably with your actual credit
card number. And this is something that
can then be stored within your app.
Well, new features
in new players, we have
now a token service provider
that's a service which
stores mappings between
tokens and the actual card number
and provides interfaces to adding new
ones and to converting from one to the
other.
And then you have the token requestor,
which requests
new tokens from from the service provider
or ask.
It's to translate from one from it to the
other.
Luckily, this happens in the same face
as if he would do HHC
or as you provisioning, so you also
want to basically convert your credit
card number to a token before you
actually do a transaction.
And what this then looks
like is that you have your
your phone, which knows about your credit
card, that you want to use, this
then goes to the token requester,
which, for example, could be Apple, could
be Google.
And what they do, they add some
information about who you are,
maybe your credit history with iTunes
or something, or the App Store.
And they then talk to
a token service provider
and provide them with the card number
and basic information, how they know you.
And they then talk
to the payment networks.
And from there
it goes into the issuer and the issuer
can say, well, OK, this account, this is
existing is valid and it's
OK to end it as a as a token, basically.
And then this goes back to
the to the
tokens,
to the token provider.
And it basically stores an extra
number of generates a token and gives it
back through the requester
to your phone. And then you have
a phone which
knows about a token.
It can discard the credit card number and
use this now for every transaction
it it's doing.
Well, why would you want to use
tokenization?
Well, I mean, yeah, provide security
benefits, so the
account number is no longer
used outside of payment networks.
Um, the other benefit is
that you can limit the scope on those
kind of tokens so you can say, well,
this token that was requested was
requested by IEEPA.
So this is only valid for point-of-sale
transactions using NFC
or other kind of transactions through
Amazon through an extra part our declined
because it's not intended to be used like
that.
And the other benefit is that
the tokens can be revoked individually.
So, for example, if you have two devices
and you load your same credit card on
both devices, they will receive
a different token on each device.
And that means if one device is
compromised, you can basically cancel
this token, but the other ones are still
working and do extra credit card numbers,
not compromised because it's not safe
there.
Think of it of A and an F
specific password, if you use Two-Factor
the authorization, something that
you give one entity which you can revoke
all the time without affecting the
others.
And the other benefit is that you can use
a token not only for point
of sale payments.
You can also, for example, use this in an
e-commerce context on Amazon, for
example.
All right, so we know about how
can we make a phone act
as a card, we know how we can
make this a little bit more secure.
And this is now where we can look at
Apple pay and Android pay because they
use actually those kind of information.
Many in charge ever pay users
the secure element
on the iPhone that you have
and an addition, appliance
account, data, tokenization, and as a
result, you get Apple Pay and.
If you look at Android pay and this is
rather similar, but they don't have a
secure element. We have a fragmented
market where you cannot make any
assumptions.
And this is why they basically are
betting on host card emulation.
And in addition to that, they are also
applying account data tokenization.
And in the end, this is Android
pay.
If you look at a transaction, what kind
of workflows are happening there,
what kind of data is exchanged?
Let's assume we already basically went
through the initial stage of presenting a
card of your phone.
Actually, you get rid of the card.
So we presented the phone to the
terminal. It read the data, and now we
end this online phase where we actually
want to talk to the issuer.
Instead of having your credit card
number, you now have the token.
In addition to that, you have the
cryptogram that was generated exactly
for this transaction, for example, by the
secure element.
This traditionally goes then to the
acquirer. From there, it enters a payment
network. And now one additional step is
happening. The payment network says,
well, OK, this is a token.
This is not a card number. I don't know
where to give this to me.
So first, I have to ask the
the token manager, hey, can you convert
this back to a card to me?
And so the token guest goes to the
manager and you get returned
the extra card number.
But this happens within the credit
card networks where more or less every
information that's floating around there
is visible in plain text anyways.
And from there on the payment because
they know, OK, well, OK, this is a Visa
transaction and this Visa card belongs
to, for example,
my Sparkasse here in
Absi.
And then this data
basically is is given
to this bank and the bank can then do
the normal checking of checking.
Is this a valid card?
In this case? It's a smartphone.
Is the
the cryptogram valid for the transaction
and then gives it OK back?
And that's basically what makes
a transaction when using
HCI or a
secure element in particular Apple Pay
or Android pay.
In this scenario,
Google or Apple
would play the role.
Um, I wouldn't play no
role in this because as
soon as the data elements are
provisioned, they are more or less
out of the transaction and they also then
no longer see the actual data.
So now we have seen, OK, Apple
Pay, Android pay, um,
it's at a different security.
What's happening after that?
Well, first of all, especially in
Germany, I want to actually be able to
use empathy.
I envy my friends in the US,
which uses on a daily basis.
I'm still sitting here.
I cannot use Jarobi,
but, well, this is not helping me.
Um, but if you look around,
there are other things happening.
There's something which is called issue a
great HHC.
The issue. I saw that.
Well, we
don't really need a token manager in the
workflow. I mean, I can actually
now give out tokens to
to my customers via my my own app.
I can also give them the keys that are
necessary for that because I'm in the
end, the one who is verifying them and
would be issuing them in the first place.
And this also enables
those issuers to to give out
cards.
But Cardless, just provisioning
a card to your actual
phone without sending you a physical
card.
We have also seen alternative payment
methods.
I mean, traditionally, banks are slow to
adapt to new technologies.
And then there were other players which
basically came in, for example,
especially in the
Asia region, we have new
ways of making a transaction which
removes the card and the terminal all
together. And then we end up with Alpay
or WeChat, which just uses a
QR code on the phone and an application
on the phone of the merchant
to to make a transaction.
And another thing well, I mean,
legacy for the win.
Those are big networks, networks,
this enables you to actually use
your card in Germany, in Spain, in
Mexico, in the US, in Iceland.
Um, this will not change overnight.
They are too many parties
involved and everyone has their
own agenda. They are. So probably
in the next years we see alternative
methods, but will always see
credit card terminals, credit cards
and smartphones acting as credit
cards and to finish
with a personal touch.
I work in this area.
Yes, I know. It's a
it's a very slow progressing
area.
It's use a lot of legacy code.
But in the end, this is a best playing
field for you to actually improve
something to find new
new areas where you want to improve.
And this is actually
why I got into this.
And with that, I want to
thank everybody and thank
you.
All right, we got
enough time for questions, please
line up at the microphones if you are
interested in anything
you want to ask something to.
Simon, do
we have an Internet question?
Apparently not so
oh, microphone number three, please.
Yeah, thanks for all those insights.
That was great.
You mentioned that the token requests
are at some date like credit
history, something when they want a
token. Could you briefly explain why
this is necessary, what this information
is used for?
Well, in the end, this information.
Well, for example, if you talk about
let's use this as a combination.
Apple has like a history of
if you're actually a recent
user of this card, if you have used it
for a long time, how credible you are.
And this is just used for making sure
that a second
card is issued to the right person.
In the end, this is the most likely
attack scenario for Apple Pay, for
example, that somebody is using your card
and add a second one to his phone and not
to your phone.
And those kind of information
is just making sure that the right
person actually you are requesting a
second card on their phone
is kind of a fingerprint.
It's not I wouldn't say
a fingerprint because it's not
reused at a later point.
It's just a point, a
collection of a few of the current moment
of what you have been done and how
authentic this request seems to be.
Or for those who are leaving, please,
a little bit lower
down your voice and the noise
we still have going on here.
So microphone number one, please.
Do I see any difference
as a customer if I use
a secure element or just
emulation?
So the maximum amount or
what happens in case of fraud
or what happens if the Android
phone is routed?
So this depends on basically the provider
of the sea solution.
In general, they are on the same
level, but
the one who gives out this one time could
limit them to a certain amount
they normally are to limit how many one
time keys you normally get at a certain
point. So five or 10 is normal.
And you're right, if your phone is routed
and somebody else gets access to those,
they can be used for actually
imposing a playing imposter
and making a transaction.
But this is limited to the ones
that you receive. This is actually why
you limit the number at the number of
tokens that you get for HCV
because they are not protected, as if you
would be using a secure element
then the bank blaming me or
is it?
So this is an interesting part.
I don't know about any case.
So I don't know.
This probably is a case by case analysis.
OK, let's move on to microphone number
six. There's somebody over there.
In case multiple cuts of
ricin violence range
is collision detection and
cuts no apply to or
just in general ever, and
nothing happens.
So, yeah, this is detected.
The guys who basically
invented the contact aspects
said, well, OK, if you detect a
collision, we say, well, just present one
card.
So you get an error message indicating
to you as the one who was providing the
cards, hey, please just provide one card
and that's it.
Probably to make it easier to
differentiate which contract should be
used and not adding a new selection
interface to prolong the transaction.
Yet I can present my entire
wallet. And you can.
You can, but this will not work.
All right. Microphone number two, please.
Hi.
So if you go back to the
obscure element provisioning step.
Yeah. Would it be nice to see that on the
screen?
Let's have a quick look.
Yeah, so the bottom two
lines is that that's basically a blob
holding the secret keys,
right?
So what
the issuer gives back to the
to the trusted service manager and
then to the government is basically a
well, a standardized, if you want,
which show it's like the private crypto
keys for the asymmetric and symmetric
encryption. Yeah, but those are
encrypted, right?
Well, kind of, yes.
So they are encrypted by
between the issuer and the
service provider and then from there
to the to the phone.
So it's not
like you just apply to Leser or
something, but it's actually they have
shared keys which encrypt this on both
sides so and so only the service
provider can do this.
Yes. And only the service provider
has the knowledge about how
the secure element can be forgiven and
the keys for actually changing data in
there. Yeah, so.
And who is that?
So in case of Apple Pay, this
is Apple and in any
other case, well, I don't
know about any other solution which uses
a secure element to make
a contactless transaction work
and. Well, in the case we don't have this
entity, but it could be, for example, if
you talk about a traditional credit card,
then this could be, for example, about
who Oberoi Gemalto, though, the creators
of the or the the manufacturers of the
actual cards that you get sent by the
bank and the keys of those
secure elements are diversified.
Yes. So there's not one provider who has
every keys, but basically they are a
couple of entities which then have
their own access to their cards,
basically. So what I mean is,
can they go on to the next question?
I mean, this is a dialog some I'm sorry,
that's a little bit too much with an
Internet question. Please just open up
to the Internet.
Wants to know, are tokens static on a
device or are they ever updated?
And would that be an advantage to
changing them?
So the the the one time he said,
are we
we're talking about the tokens.
So the token, once it's basic
provisioned, they are normally static
until you basically say, well, I want to
add another card. Even if the same card,
you would probably get a different token.
But in general, it's basically static.
Yes, there would be a benefit in changes
regularly, just removing
fingerprinting options there,
but I think
the major benefit of actually having this
kind of option is
that you can hide your actual credit card
number. And this, I think, was the
primarily focus on the.
OK, microphone number four, please.
You were talking about payment
networks like MasterCard and Visa.
It's the same technology used for
contactless payment cards known as
zero.
This is completely different.
It's similar.
I mean, the card has its own card,
which should be running on the terminal.
And you don't have this
those global payment network, if you
will. But you have like a local German
network, which is connected to a
different service providers.
But the handling overall is more or less
similar.
And microphone number five, please.
I, I heard or
I often hear that risk management is one
of the most important things for
creditcard institutes or pretty important
thing.
Do you have any experience in this or
do you know if there really is so much
money stolen from the Kennicutt
institutes or during the transaction?
Well, I think you have to differentiate.
I mean, there are credit
card issuers
or companies who have been doing this in
a long time, and especially in Europe,
they are very keen on checking the data
as part of the risk management.
When EMV was introduced in the U.S.,
there were instances where the bank
introduced EMV, but they didn't check any
data. So you could just send in
transaction, they would be approved.
So, yes, this happens from time to time.
But if the correct checking is
implemented, then this
is very hard.
OK, let's get back to microphone
number three.
Hello.
I think you forgot to mention another
alternative you can pay with the phone
or nearly pay with the phone, because
some banks are also issuing near the
card, the near field communication
sticker that you can just put on the
back of the phone.
And it works even when you don't
have the signal. Isn't that the easiest
way? Well, this works.
And yes, you're right. This is also one
of the options that you can use.
In that case, you doesn't even
necessarily need a phone.
You can stick this to anything.
And true, this is like a key FOB
or something that you carry around with
you.
This also works.
This has been tried in Germany, for
example, the network operators,
T-Mobile and so on have tried this,
but it didn't reach critical mass and
never took off and then they borrowed it.
I guess this is now the next try of
getting it to the masses.
My country in Slovenia, that's released
by the bank and you can buy with
it.
Well, this is just an alternative than to
the actual credit card.
Just.
OK, number one microphone,
please. OK, so when I got my
one of the last currence a couple of
years ago, before the first time that
I could pay contactless, I had to pay
with a contact. I had to instruct the
card. Is there a technical reason for
that?
I don't know.
I think this is just checking that
everything is OK and that the account
is still available.
Otherwise you could, for example, use
this card for below
contactless limits without needing
any pin or anything else.
I think this is just a first rate check,
but there is no technical reason for it.
And microphone number six, please,
when using host card emulation, how do
the limited use keys
get updated?
Does that require Cataldo interaction?
Does that happen automatically?
So this normally happens behind
the scenes. So you as a user of the
smartphone don't see this.
This happens basically asynchronously in
the background.
And whenever the phone sees well or the
application says, well, I'm running out
of keys, it refreshes.
Let's go to microphone to please.
Oh, hi.
Could you elaborate a bit on
why the banks are
pushing more for
house cars angulation than
see, I understand why Google
uses host card emulation,
but the banks are pretty powerful entity
and could basically put their weight
behind forcing manufacturers
to use Azeez. Why don't they?
So from what I understand, yes,
they couldn't put more focus on that.
But in the end, you also need
manufacturers who want to support it.
And if you're looking, for example, at
Android, it's pretty fragmented.
There might be one manufacturer who adds
a secret element to their phone.
But, well, first of all, you need to
basically be able to cater that for
markets and sell it in markets.
So in Germany, it doesn't help me if
a Chinese maker is adding this to a
smartphone. And I'm also not
so sure how how how much I
would trust this implementation.
So a secure element is basically
has the same capabilities of a card.
So you need a trusted entity
in there. And this is, I think, why the
why the issuers basically focus
more on host card emulation, because
they can actually influenza's they don't
have any external requirements of
some some manufacturer adding some stuff
there.
For example, with Android, they just need
a recent handset with I think Android for
plus and then they more or less good
to go.
All right, any questions from the
Internet?
No. OK, let's go onto microphone
number four, please.
Thank you for the great talk.
I wonder if there are any liability
changes when this
new workflows with
mobile payments arrive
like secure element and guard demolition.
Who is liable for the
fraud in this case is because
there are no new players.
For example, the trusted service
providers, which basically owns the
secure the Krypto Keys for
the immolated cart.
But overall, this doesn't change anything
the same as if you would use your credit
card.
Yes, there's somebody who says you can
put data in your secure element, but
those types of entities have been
existing in the past.
The ones who basically provisioned your
own actual physical card
and they undergo the same
certifications or I don't know what you
want to call this like the same
requirements in order to become one
when it comes to securing your data.
So in the end, the same liability
is there.
And as long as you use EMV,
you are protected by it, except
for if you use a pin or something,
whatever, with the banks come up with
Indiantown.
But in general, if you use EMV,
the liability is with the with
the bank.
Second question, is there such a thing
as an offline contactless payments?
And if there is, how widespread
are they?
Technically, yes, you can use it,
but this then really shifts the liability
because then you are
ignoring the result of the transaction
and just trying to accept it.
But you have to differentiate between
saying, well, I want to use I want to
work in a in a strictly offline
environment.
And I have an often
approved transaction, which could also
happen. But nowadays,
I think in almost all countries
that I've been working with,
there is this this flaw limit which
indicates the terminal, when should I go
online for a transaction?
And this is at zero.
So normally every transaction is
authorized online.
OK, and microphone number five,
please. I think there is somebody over
there I
had us spin verification work
and how is it different compared to
chip transection?
So when looking at a chip transaction,
you normally have three ways of verifying
a pin, so you can basically
check this offline.
So just between the terminals and the
card and then you have two ways of
encrypting it or doing it plaintext.
So this is how the terminal communicates
with the card and actually wants the pin
to be verified.
And then there's a second third option,
which is online pin, where the
pin that you enter is actually encrypted
on the terminal. And then together with
the authorization sent to the bank and
the bank checks that the pin is actually
valid. And when we're talking about off
of contactless transactions, then only
a third option is actually available.
So if you use a pin for connect this
transaction, there's always goes to the
to the issuer for it for checking
because there is no card anymore for
verifying the pin off-line.
And microphone number three, please.
My question would be about Apapa in
Germany, banks in Germany
seem to be reluctant to accept it and
implement it, unreasoned
seems to be that they have to give
up a little share of the
transaction, the transaction
fee that they receive.
My question would be,
how does how does Apple know
about the transaction and which data is
sent to Apple when I pay with
the phone so I don't want
them to be involved too much.
Yes. And in the end, they actually
aren't.
Well, in order to basically be able to
use Apple Pay on your phone, your issuer
needs to participate in this
charade of provisioning and card.
And this also then means that they enter
an agreement that percentage of every
transaction is basically paid out to
Apple.
And this happens basically independently
of making the transaction.
So the the the issuers are
aggregating basically the transactions
and then basically providing
Apple with information of how much they
get. There is no direct feedback as
as part of every transaction to
Apple. That way. I made a transaction
about this, and this means that you get
that. So this is like a trusting
contractual agreement between the issuer
and the and Apple.
In microphone number one, please.
I also worry about transaction privacy
and is this any different of Android pay?
Do they get any transaction data?
So this is kind of similar.
Also their.
In general, Google doesn't
get any transaction data.
They have access to the same elements
that you have as part of a transaction.
But after you apply the tokenization,
you also just have your replaced
account number.
In theory, they could do more.
To be honest, I don't know, hundred
percent what they actually store and what
is basically transferred as part of a
transaction.
But I would assume that this is similar
to what Apple does because this is a
highly sensitive topic.
And if there's any wrongdoing there, then
this would create a real shitstorm there.
OK, we're getting time, there's one more
question left is it looks like please
microphone for
hello, thanks for the great talk, but
I think you missed something,
OK, and
maybe I missed it, but you
never mentioned number 26
with this QR code paying.
Well, I would say that's similar to
the alternative payment methods, which
basically come up
and this is a way where you no
longer need a card, actually, you just
need your smartphone to display a QR
code. And this is an scanned at the
at the cashier system.
And this basically includes
information of making the transaction.
Yes, you're right. This is a valid way
of doing this, for example, in Germany.
But I wanted
to focus on actually making
like cloning or making
card payments with your smartphone
as a replacement for for normal
credit card. So this is why I didn't
focus on that.
OK, thank you.
OK, thank you very much, Seimone,
apologies again for the small delay.
Thanks a lot. The.